AK's weblog

Nach schätzungsweise 6 Jahren Pascal-Abstinenz hab ich letzten Freitag abend/nachmittag wieder ein paar Zeilen Pascal-Code geschrieben, um meine Kenntnisse wieder etwas aufzufrischen. Und nun bin ich erstaunt, wie schnell und produktiv man in Pascal vorankommt und produktiv sein kann. Wer den Code sehen will, der sehe ihn sich bitte hier an. Es handelt sich um eine Implementierung von RFC 569. So richtig sinnvoll ist der Code nicht (jeder noch so einfache Editor heutzutage hat 10mal mehr Funktionalität und Komfort), aber ein gute Aufgabe, um einen Nachmittag mit der Ausimplementierung zu füllen.

Übrigens, das meiner Erfahrung nach bessere freie Pascal-System ist Free Pascal. GNU Pascal ist im Gegensatz dazu etwas buggy (auch wenn darum workarounden kann), und generiert wesentlich größere Binaries als Free Pascal.

Ich hab mir grad den Spaß gemacht, mit Google Translate das zu übersetzen, was Borland Japan über den SilkPerformer 2007 schreibt. Google Translate hat anscheinend die Eigenschaft, Wörter, die es nicht kennt, in ihrer Transkription in lateinischen Großbuchstaben auszugeben. Im Inhalt der verlinkten Seite war das besonders interessant, da offenbar einige englische Begriffe bzw. Eigennamen in japanischen Schriftzeichen niedergeschrieben wurde. Eine Auswahl der Wörter, die ich so gefunden habe, und meine, die Bedeutung erkannt zu haben:

• Borland SHIRUKUPAFOMA 2007 (ボーランド・シルクパフォーマー 2007) - Borland SilkPerformer 2007
• TESUTOSORYUSHON (テストソリューション) - test solution
• YUZARAISENSUPAKKU (ユーザーライセンスパック) - user license pack
• KODOKABAREJJITSURU (コードカバレッジツール) - code coverage tool (das hab ich allerdings auf der Produktseite zu "Silk & Gauntlet" gefunden)
• ROKARIZESHONTESUTO (ローカリゼーションテスト) - localization test (von der SilkTest Produktseite)
• TESUTOKABAREJJI (テストカバレッジ) - test coverage (von der SilkCentral Test Manager Produktseite)
• SUKURIPUTOREKODA (スクリプトレコーダ) - script recorder
• WAKUFUROUIZADO (ワークフローウィザード) - workflow wizard

Sehr witzig.

Vor einiger Zeit hab ich zufällig Szene geschaut, und beim nicht sehr anspruchsvollen Quiz, wer denn bei der CD-Release-Party des PBH Club dabei war (wer den Bericht 1 min davor gesehen hat, wusste, dass dies Michael Gaissmaier, der Sänger von Heinz aus Wien war), mitgemacht. Eigentlich hatte ich darauf schon wieder vollkommen vergessen, doch heute fand ich einen eigenartigen Briefumschlag in meinem Briefkasten. Und tatsächlich: ich hab gewonnen, und zwar das aktuelle PBH-Club-Album. Sehr fein. Auch wenn ich finde, dass der PBH Club Kommerz-Sellouts sind.

Inspiriert durch bestimmte Ideen, die DJB in seinem Paper "Some thoughts on security after ten years of qmail 1.0" formuliert hat, hab ich mich am Wochenende dran gemacht, ein neues Projekt zu starten, und zwar einen LDAP-Server. "Ja", werden sich manche denken, "der AK ist aber ein handfester Trottel, dabei gibt es ja schon OpenLDAP, Fedora Directory Server, OpenDS, tinyldap, und noch ein paar andere Implementierungen". Nun, ja, oberflächlich betrachtet stimmt das, mein Ziel ist allerdings ganz spezifisch, und zwar werde ich als Storage-Backend das Filesystem selbst verwenden. Dabei mache ich mir den Umstand zunutze, dass die Baumstruktur unter Unix (naja, eigentlich sind Verzeichnisstrukturen unter Unix ja DAGs, aber egal) der hierarchischen Struktur von LDAP sehr ähnlich ist.

Die Idee ist, einen Distinguished Name (DN) durch ein Verzeichnis zu repräsentieren, und die dazugehörenden Attribute durch Dateien, wobei der Dateiname den Attributsnamen codiert, und der Dateiinhalt den Attributswert repräsentiert. Die Vorteile liegen auf der Hand: einerseits lassen sich damit quasi alle Operationen auf der Hierarchie von LDAP fast 1:1 auf Datei- bzw. Verzeichnisoperationen abbilden (was auch die Komplexität der Implementierung stark verringern sollte), andererseits schiebe ich etliche Probleme des parallelen Zugriffs und des Caching von der Applikation hin zum Betriebssystem. Und nachdem pro LDAP-Session ein Prozess verantwortlich ist (ein simpler forkender Server also), sollte die Performance meiner LDAP-Server-Implementierung quasi nur von der Performance der Prozesserzeugung und der Performance des eingesetzten Dateisystems abhängig sein. Gleiches gilt für die Skalierbarkeit. Im wesentlichen geht es vorerst einmal darum, ungefähre Performancewerte zu erhalten, und eventuelle Bottlenecks identifizieren zu können. Bis dahin muss ich allerdings einmal das LDAP-Protokoll völlständig ausimplementieren. Bisher geht nämlich nur der Use-Case BindRequest -> AddRequest(s) -> UnbindRequest.

Gestern in Switch Reloaded, heute im Hitler-Blog:

Weil ich gerade einen herzlich sinnlosen Patch für das newsbeuter-Makefile gekriegt hab, der pkg-config dazu einsetzt, diverse Libraries zu finden, hab ich im Issue Tracker gleich mal ordentlich gerantet. Und eigentlich sollte dieser pkg-config-Rant auch meinen werten Lesern hier nicht vorenthalten werden:

Rejected.
(a) Mentioned libraries are installed in system-wide directories by definition.
(b) When a user is capable installing it outside of the usual system-wide directories, he's also capable of adapting the Makefile accordingly.
(c) IMHO, it's very unlikely that somebody installs the library somewhere outside of a system-wide directory, but then takes care that the according .pc files are installed when pkg-config is searching for it.

A great example for the utter failure of pkg-config is how it fails to work with libraries that are installed via Fink on Mac OS X. Fink installs all its software under /sw, which is definitely not one of the "usual" prefixes such as /usr and /usr/local. And of course, the pkg-config that is delivered with Mac OS X fails to find any of the .pc file that are installed under /sw. When using the pkg-config that is delivered with Fink, the .pc files that are installed under /usr aren't found. In theory, pkg-config is great, but in practise, it's absolutely awful and IMHO less reliable than not using any semi-magic auto-detection mechanism.

Additionally, it depends on glib2, and I'm not going to endorse the installation of a plethora of bloated software that is of no direct use to users of newsbeuter.

Es ist immer wieder praktisch, die Code Coverage von Programmen bei automatischen und manuellen Tests zu bestimmen, um feststellen zu können, welche Codeteile getestet und welche nicht getestet sind. Die GNU-Lösung für Code Coverage ist GCOV, ein eher krudes Commandline-Tool. Mir persönlich ist das Tool bei weitem nicht mächtig genug, und so habe ich heute LCOV, ein Wrapper um GCOV, der nicht nur farblich ansprechende und übersichtliche Ausgaben zur Code Coverage generiert, sondern mit dem es auch möglich ist, die Code Coverage von verschiedenen Testläufen problemlos zu akkumulieren. Und zwar geht das so:

Zuerst compiled man das zu testende Programm mit den CFLAGS (bzw. CXXFLAGS) "-fprofile-arcs -ftest-coverage". Dann lässt man das Programm laufen, und führt seine Tests durch (z.B. typische Use-Cases, oder aber auch ausprobieren aller vorhandenen Features, oder ...), und am Ende sammelt man die von GCOV geschriebenen Ergebnisse mit "lcov -d . -b . -o programm.info". Dann kann man einen weiteren Testlauf starten, z.B. Unit-Tests, oder einen anderen Use-Case, und mit einem weiteren Aufruf von "lcov -d . -b . -o programm.info" wird die Coverage dieses Testlaufs gesammelt. Wenn man dann alle Testläufe abgeschlossen hat, kann man aus dern Datei programm.info, welche die akkumulierte Code Coverage des getesteten Programms enthält, schöne übersichtliche Charts generieren, und zwar mit "genhtml programm.info". Man kann auch nach jedem Testlauf und Sammeln der Ergebnisse die HTML-Files generieren, um daraufhin für den nächsten Testlauf entscheiden zu können, welche Features noch genauer zu testen sind, usw. usf. Auf jeden Fall ist LCOV meiner heutigen Erfahrung nach wesentlich übersichtlicher und angenehmer, als GCOV per Hand zu bedienen.

Gerade hab ich Hudson ausprobiert, es hat sich als wirklich nettes Continuous-Integration-Tool herausgestellt. Primär interessiert bin ich natürlich an Continuous Integration für newsbeuter, gleichzeitig dient diese Evaluierung aber auch küntigen potentiellen anderen Einsätzen.

Das Setup von Hudson ist einfach: das .jar-File von der Website herunterladen, "java -jar hudson.jar" ausführen, und nach kurzer Zeit ist das Hudson-Webinterface schon auf localhost:8080 verfügbar (alternativ ist das Deployment in einem Servlet-Container auch möglich, aber sowas hab und brauch ich nicht). In diesem Webinterface erstellt man dann einen neuen Job, bei dem man angibt, as welchem CVS- oder SVN-Repository der Code ausgecheckt werden soll, wie ein Build getriggert werden soll, welche Kommandos ausgeführt werden sollen (bei nicht-Java-Dingen ist das Ausführen von Shellkommandos am zweckmäßigsten, um Buildtools wie make sowie das Ausführen von Unit-Tests zu steuern), und wie die Email-Notification ablaufen soll. Dann ist der Job schon einsatzbereit, und man kann einen Build starten, um zu testen, ob der Build auch korrekt abläuft.

Abgesehen von der Abhängigkeit von Java ist Hudson wirklich sehr angenehm, und ich kann es voll und ganz weiterempfehlen, vorausgesetzt, man setzt kein exotisches SCM ein (CVS und Subversion werden unterstützt). Auch für künftige Projekte werde ich es sicher einsetzen.