In der Tcllib sammeln Entwickler praktische Werkzeuge, die typische Programmieraufgaben lösen oder ganze Netzwerkprotokolle implementieren. Da sie sich auf eine reine Tcl-Erweiterung ohne kompilierten Code beschränkt, ist die Bibliothek sofort einsatzbereit. Dieser Streifzug stellt einige Teile vor.
Die Tcllib ist selbst unter Tcl-Entwicklern noch recht unbekannt - schade, denn sie hat eine Menge zu bieten. Von Datenstrukturen über Mathematik bis hin zu Netzwerkprotokollen enthält sie knapp 100 Tcl-Pakete. Viele Linux-Distributionen liefern die Tcllib bereits mit, sie ist aber auch bei Sourceforge[1] erhältlich, aktuell in Version 1.6.1. Linux-Programmierer laden am besten das Tar-Archiv. Nach dem Auspacken muss Root die Bibliothek mit dem mitgelieferten grafischen Installer aufspielen: »wish installer.tcl«.
Neben den Bibliotheken enthält das Archiv auch Beispielanwendungen sowie die Dokumentation im Manpage- und HTML-Format. Wer vor der Installation einen Blick auf die Dokumentation werfen möchte, findet sie auf der Sourceforge-Seite unter[2].
Die Tcllib hat mit der Tklib einen kleinen Bruder, der GUI-Funktionen sammelt. Wer diese Library ebenfalls nutzen möchte, muss sie derzeit noch aus dem CVS-Repository holen. Auch dies ist mit wenigen Schritten erledigt:
cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/tcllib login cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/tcllib co tklib cd tklib wish installer.tcl
Für den anonymen CVS-Zugang ist kein Passwort notwendig, ein einfaches Return genügt als Reaktion auf die Nachfrage »CVS password:«.
Eine EDV-Weisheit sagt: Computer helfen uns Probleme zu lösen, die wir ohne sie nicht hätten. Auch beim Programmieren wird das deutlich. Immer wieder müssen Entwickler Aufgaben bewältigen, die wenig mit dem eigentlichen Zweck ihrer Software zu tun haben. Zum Beispiel die typische Frage, was die Anwendung gerade tut - beim Debugging die wichtigste Erkenntnis.
Der einfachste Ansatz sind »puts stdout Meldung«-Anweisungen an allen kritischen Stellen. Leider muss man diese später löschen oder auskommentieren. Einfacher und eleganter geht es mit dem Logger-Paket. Mit ihm definiert der Entwickler Logkanäle, in die das Programm Nachrichten mit einem Loglevel von »debug« bis »critical« schreibt. Dank des Loglevels genügt ein Parameter, um die Ausgabe von unerwünschten Debug-Informationen auf ein Anwender-verträgliches Maß zu reduzieren. Logger kennt mehrere Ausgabeformate und schreibt auf Wunsch direkt in eine Datei. Neben dem reinen Beobachten der Anwendung ist die Dauer einzelner Aufrufe oft interessant. Hier hilft das Profiler-Paket, es speichert für alle Prozeduren die Anzahl der Aufrufe, die dazu benötigte Zeit und weitere Timing-Informationen.
Das Skript in Listing 1 verwendet beide Pakete. In den Zeilen 5 und 6 fordert es sie mit »package require« an. Den Profiler muss das Programm vor allen weiteren Aufrufen initialisieren, das erledigt »::profiler::init« in Zeile 11. Statt einer kompletten Anwendung enthält das Beispiel nur einen Namensraum mit zwei Prozeduren »A« und »B« sowie den Logkanal »$log«. Diesen legt es per »logger::init Name« an.
|
Listing 1: Logging und |
|---|
01 #!/bin/sh
02 # Beispiel für Profiler und Logger
03 exec tclsh $0 $@
04
05 package require logger
06 package require profiler
07
08 puts stdout "Listing 1n"
09
10 # Initialisierung
11 profiler::init
12
13 namespace eval anwendung {
14 variable log
15 set log [logger::init Anwendung]
16 ${log}::setlevel info
17
18 proc A {} {
19 variable log
20 ${log}::info "1"
21 B 1
22 ${log}::notice "2"
23 B 2
24 ${log}::debug "erscheint nicht"
25 B 3
26 ${log}::setlevel debug
27 B 4
28 }
29
30 proc B {i} {
31 variable log
32 ${log}::debug "B $i"
33 }
34 }
35
36 anwendung::A
37 puts stderr [::profiler::print ::anwendung::*]
|
Da das Logger-Paket seine Funktionen in einem Namensraum versammelt, muss die Kanalvariable in geschweiften Klammern stehen. Zeile 16 setzt den Loglevel auf »info« und unterdrückt damit alle »debug«-Meldungen. Erst nach dem dritten Aufruf setzt ihn Zeile 26 auf »debug« herab. Ab diesem Zeitpunkt sind alle Meldungen in der Ausgabe zu sehen. Mit einem eigenen Logger je Prozedur oder je Namensraum ist der Überblick jederzeit gewährleistet.
Das Ergebnis ist in Abbildung 1 zu sehen. Sie zeigt die Logging- und Profiler-Ausgaben von Listing 1. Mit »::profiler::print« gibt Zeile 37 Informationen über die Prozeduren aus. Neben der Anzahl der Aufrufe und ihrer Herkunft sind mehrere Zeitinformationen enthalten. Auf der Suche nach Performance-Killern sind die hauptschuldigen Programmteile damit schnell entlarvt.
Abbildung 1: Mit dem Logger-Paket sind ausführliche Log-Ausgaben in Tcl einfach erledigt (blau). Auch das Profiling einer Applikation (rot) ist mit dem passenden Modul in wenigen Codezeilen erledigt (Listing 1).
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
