Programmieren

Letzte Woche waren meine Holde und ich ja im Urlaub und wie das so ist kommt man da ja meist zu den Sachen, für die man sonst nie Zeit hat. Da ich schon seit längerer Zeit mal TDD ausprobieren wollte, war die Zeit also günstig. Herausgekommen ist ein kleines Spielzeug namens StateMachine (kreativere Namensvorschläge werden in den Kommentaren gern entgegengenommen): eine kleine Bibliothek für State Machines in Java. Brauch ich demnächst wahrscheinlich sowieso für verschiedene Dinge, so dass die Zeit nicht vergeudet war.

Fazit der testgetriebenen Entwicklung? Anfangs etwas gewöhnungsbedürftig, weil man den klassischen Entwicklungsprozess (Entwickeln-Testen) quasi rumdreht. Für so Sachen wie die Entwicklung von Bibliotheken ist das allerdings ganz interessant, weil man relativ früh merkt, wenn die Schnittstellen murksig zu benutzen sind. Durch das "auf den grünen Test" hin programmieren hat man auch klar abgesteckte Aufgaben für jeden Entwicklungsschritt. Ich werd das also bei der Library (und auch sonst wo sich's lohnt) durchaus weiter ausprobieren.

Ach ja: bitbucket.org ist richtig angenehm zu benutzen. So angenehm, dass ich zu faul war, den Kram selbst aufzusetzen. Mercurial ist eh geil. Sag ich ja meiner Frau immer, aber die hört ja nicht...

Eclipse ist ja auch gerade wegen der Code Completion die Java-IDE. Blöd nur, wenn die nicht tut. Wenn weder nach Eingabe eines Punktes noch nach Strg+Space die erwartete Vervollständigung kommt, sondern stattdessen in der Statusleiste nur "No completions available" erscheint, dann hat man unter Umständen in den Projekteinstellungen oder in den generellen Einstellungen für den Java-Editor (unter Window->Preferences: Java->Editor->Content Assist->Advanced) die Vervollständigung verkonfiguriert. Im Zweifelsfall einfach in beiden Listen alle Einträge aktivieren (die obere Liste ist das, was im normalen Assitententenpopup hochploppt, die untere das, wo man mit Strg+Space durchschalten kann). Aus irgendeinem Grund war das bei mir verpfriemelt (ich hab ja das JBoss-Plugin in Verdacht, kann ihm aber nix nachweisen *grml*) und ich hatte daher keine Code-Completion mehr. Naja, wieder mal was gelernt und gestandene Eclipser zum Rätseln gebracht.

Wer mal entspannt Webapplikationen entwickeln will/muss, dem sei Pylons ans Herz gelegt. Nettes Framework, noch einige kleinere Ecken, aber schonmal sehr angenehm zum Entwickeln geeignet. Meist liegt hinter einer Webapplikation ja ein entsprechendes Datenmodell in Form einer Datenbank. Um die bequem ansteuern zu können (SQL von Hand zu coden ist mittlerweile definitiv nicht mehr schön) bringt Pylons eine Integration für SQLAlchemy mit. Nun ist SQLAlchemy flexibel und mächtig, dafür aber manchmal etwas komplexer als nötig. Für viele Anwendungsfälle reichen die Möglichkeiten, die Elixir mitbringt (Elixir ist eine auf SQLAlchemy aufsetzende Bibliothek, die einen deklarativen Stil zur Erstellung des Datenmodells ermöglicht). Mit diesem Trio kann man schonmal recht viel Interessantes tun.

Blöd nur, wenn man ein wenig faul bei der Einbindung der verschiedenen Module ist. Dann kann es nämlich dazu kommen, dass plötzlich folgende Fehlermeldung auftritt, wenn man versucht was in der Nutzersession im Pylons zu speichern:

TypeError: 'ScopedSession' object is unsubscriptable

Der Datentyp deutet es an: das session-Objekt von Pylons ist unter diesem Namen nicht verfügbar. Der Fehler ist simpel: im Datenmodell der Applikation stand mal from elixir import * (um Schreibarbeit bei den Elixir-Datentypen zu sparen). Im Controller wiederum wurde das Datenmodell mit from app.model import * importiert. Tja... Elixir definiert dummerweise ein eigenes session-Objekt, welches durch diese Import-Kette in den Namensraum der Applikation gerät und dort dann das eigentliche Pylons-Objekt überschreibt.

Als Lösung bleiben drei Möglichkeiten: man kann den Import im Datenmodell in import elixir ändern und allen Datentypen ein elixir. voransetzen, die benötigten Elixirtypen mittels from elixir import Field, .... im Datenmodell importieren (und dabei keinesfalls session mit reinnehmen) oder in der Applikation das Datenmodell mittels import app.model as m und dann jedem Zugriff auf Elemente des Modells ein m. voranstellen. Danach hat man wieder wie gewünscht Zugriff auf seine Session und kann Daten darin speichern und daraus lesen.

Manchmal kann man sich auch einen Wolf suchen. Ziel war: ein Widget in dem sich mehrere Children befinden (QLineEdit, Checkboxen, QTableView) immer auf die minimal notwendige Größe zu bringen. Das gilt speziell dann, wenn der QTableView unsichtbar wird. Mit etwas um die Ecke denken geht's: widget->setMaximumHeight(0). (Im dem Fall ging es nur um die Höhe). Muss man erstmal drauf kommen...

Update: Unsinn gelöscht. Man schaue sich mal QWidget::adjustSize() an...

Nach zweitägiger Suche: Python und QT können manchmal sehr hässlich zusammenstoßen, wenn es um die Lebensdauer von Objekten geht. Folgender Code:

class MainWindow(QMainWindow):
    [...]
    def initTreeView(self, top_level_cats):
        model = CategoryModel(top_level_cats)
        self.treeview.setModel(model)
    [...]

Sieht an sich erstmal unverdächtig aus: ein Model wird erzeugt (wie auch immer geartet) und dem QTreeView als Model übergeben. Scheint alles wunderbar, bis man es ausführt. Aus irgendeinem Grund bleibt der QTreeView grundsätzlich leer. Es werden zwar von dem Model unter Umständen noch einige Funktionen aufgerufen (in meinem speziellen Fall waren das headerData() und columnCount(). Keine Ahnung, ob das immer so ist), aber die eigentlich Daten werden nie dargestellt. Soweit, so schlecht.

Ein winzig kleine Änderung des Codes bringt die Lösung. Hier fast die gleiche Funktion:

class MainWindow(QMainWindow):
    [...]
    def initTreeView(self, top_level_cats):
        self.model = CategoryModel(top_level_cats)
        self.treeview.setModel(self.model)
    [...]

Der einzige Unterschied: statt einer lokalen Variable ist model nun ein Feld der umgebenden Klasse. Und siehe da: plötzlich funktioniert es. Wie kommt's? (Fast) ganz einfach: man könnte zwar annehmen, dass self.treeview.setModel(...) sich das Model irgendwie speichert, wenn es noch benötigt wird, aber das scheint nicht der Fall zu sein. Anscheinend werden die entsprechenden Aufrufe nur von der dünnen Schicht von PyQt4 an die zugrundeliegende QT-Bibliothek durchgereicht und die entsprechenden Pythonobjekte dann nicht weiter beachtet. Am Ende der Funktion geht das Element im ersten Fall out-of-scope und wird dann irgendwann mal vernichtet. Blöd nur, wenn QT dann bei der Darstellung des Views plötzlich was von dem Model will, dessen Objekt zu dem Zeitpunkt nicht mehr existiert. Weißt man es hingegen einem Feld in der umgebenden Klasse (zum Beispiel dem Fenster) zu, so existiert es so lang, bis dieses vernichtet wird (und damit auch sein View). Dann kann die QT natürlich nach Herzenslust nach den Daten des Views fragen und wird immer auf unserem Model-Objekt landen, wie das gewünscht ist.

Eigentlich logisch. Wenn man's einmal weiß...

Der Titel sagt es schon: es geht um Eclipse Ganymede und Subversion. Beides meiner Meinung fantastische Tools zur Softwareentwicklung, in Kombination allerdings gerade etwas zickig. Das Problem: bei Eclipse Europa (3.3) wurde meist für die Subversion-Integration das Plugin Subclipse verwendet. Für Ganymede (3.4) gibt's das allerdings noch nicht. Dafür gibt es ein neues Plugin direkt im Ganymede-Repository: Subversive. Dieses Plugin soll wohl bald standardmäßig in Eclipse integriert werden. Es ist quasi deckungsgleich mit dem schon bestehenden CVS-Plugin und integriert sich sehr gut in die Oberfläche.

So schick das Plugin ist: mir scheint, die Eclipse-Jungs und -Mädels haben bei der Zusammenstellung von Ganymede gepennt. Dummerweise ist nämlich der eigentliche Team-Provider integriert, die Library zum Zugriff auf die SVN-Repositories allerdings nicht. Die darf man sich zu Fuß nachinstallieren. Dabei darf man sich dann auch noch entscheiden, welche man nimmt. Ich hab mich letztlich für SVNKit entschieden, weil mir die Idee gefällt, allen Kram gleich in Java abzuwickeln, statt externe Libs einbinden zu müssen. Dummerweise begrüßt mich mein Eclipse bei der Installation von SVNKit mit folgenden Zeilen:

Cannot find a solution where both Match[requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.team.svn.feature.group/[0.7.1.I20080612-1500,0.7.1.I20080612-1500]] and Match[requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.team.svn.feature.group/[0.7.2.I20080801-1500,1.0.0)] can be satisfied. Unsatisfied dependency: [org.polarion.eclipse.team.svn.connector.svnkit.feature.group 2.0.2.I20080801-1500] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.team.svn.feature.group/[0.7.2.I20080801-1500,1.0.0) Unsatisfied dependency: [org.polarion.eclipse.team.svn.connector.svnkit.feature.group 2.0.2.I20080801-1500] requiredCapability: org.eclipse.equinox.p2.iu/org.polarion.eclipse.team.svn.connector.feature.group/0.0.0 Unsatisfied dependency: [org.polarion.eclipse.team.svn.connector.svnkit15.feature.group 2.0.2.I20080801-1500] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.team.svn.feature.group/[0.7.2.I20080801-1500,1.0.0) Unsatisfied dependency: [org.polarion.eclipse.team.svn.connector.svnkit15.feature.group 2.0.2.I20080801-1500] requiredCapability: org.eclipse.equinox.p2.iu/org.polarion.eclipse.team.svn.connector.feature.group/0.0.0 Unsatisfied dependency: [org.polarion.eclipse.team.svn.connector.feature.group 2.0.2.I20080801-1500] requiredCapability: org.eclipse.equinox.p2.iu/org.eclipse.team.svn.feature.group/[0.7.2.I20080801-1500,1.0.0)

Ja, diese Fehlermeldung ist auch im Original so unlesbar. Nach längerem Suchen bin ich in einem Blog auf die Lösung gestoßen: Seit 3. August möchte SVNKit eine neuere Version von Subversive haben (oder andersrum, so 100% schlau bin ich noch nicht draus geworden). Die ist dummerweise nicht in den Ganymede-Repositories, sondern muss unter http://download.eclipse.org/technology/subversive/0.7/update-site/ extra bezogen werden. Diese URL packt man in die Update-Site, muss sie dann noch einmalig via "Manage Sites..." aktivieren und schon kann man sich ein neueres Subversive installieren, was dann auch mit SVNKit spielen mag. Schade, dass die Standardintegration in Ganymede so kaputt ist. Bis zum Nachfolger dauert es ja doch ein wenig und bis dahin sind wahrscheinlich schon einige an Subversion und Eclipse verzweifelt und benutzen glatt wieder CVS *brrrr*...

Update: Wie Deka in den Kommentaren angemerkt hat scheint es mit Subclipse 1.4 wohl doch einen Release für Ganymede zu geben.

Installiert man Pylons nach Anleitung mittels easy_install auf einem Ubuntu Feisty Fawn, dann bricht der Compilerlauf von Cheetah (welches als Abhängigkeit mit installiert wird) unter Umständen irgendwann mit folgender Meldung ab:

src/_namemapper.c:15:58: error: Python.h: No such file or directory

Das liegt daran, daß die passenden Headerfiles nicht in /usr/include/ liegen, sondern in /usr/include/python2.5 (bspw.), wo sie natürlich vom Compiler erstmal nicht gefunden werden. Ein

CFLAGS='-I/usr/include/python2.5' easy_install Pylons

behebt das Problem.

Grad von Achim geschickt bekommen: Random Number. Wer's nicht versteht: macht nix. Ich find's lustig. :)

Ich hatte mal wieder etwas Langeweile und wollte ein wenig mehr Python lernen. Also hab ich mich mal damit beschäftigt, wie das mit Parsing in Python so aussieht. Ich bin ja in C++ von boost::Spirit recht angetan und hab sowas ähnliches für Python gesucht. Das, was dem noch am nächsten kommt, ist pyparsing. Leider hat dieses einen gravierenden (aus meiner Sicht) Nachteil: es scheint nicht möglich zu sein, den Parser dazu zu bringen, Whitespaces NICHT zu ignorieren. Dummerweise brauchte ich das aber für die selbstgestellte Aufgabe an einigen Stellen...

Wie der geneigte Informatiker dann so ist, schreibt er sich den Kram halt selbst und lernt noch was dabei. Rausgekommen ist yeanpypa (bevor einer fragt: YEt ANother PYthon PArser framework. Hat da wer gelacht?!), ein kleines Framework, mit dem sich eine EBNF-Grammatik fast 1:1 in Python-Code übertragen läßt. Die Schnittstelle ist zum Teil bei pyparsing und zum Teil bei boost::Spirit abgeschaut. Das ganze dürfte noch einige Fehler haben, aber erscheint mir bisher schon ganz brauchbar. Der Code steht wieder mal unter einer public domain Lizenz, kann also vollkommen frei verwendet werden. Natürlich freue ich mich über eine kurze Nachricht, wenn jemand damit irgendwas tut.

So, zuguterletzt noch die passenden Links:
Download (yeanpypa.py runterladen)
Einführende Doku (Englisch). Leider alles andere als vollständig. Vielleicht irgendwann mehr...
Vollständige API-Doku. Generiert mit Epydoc.

Nachdem ich heute seit langer Zeit mal wieder im Blog von Andreas Bogk gestöbert hab, bin ich über ein sehr interessantes Paper von ihm und Hannes Mehnert zum Thema "Secure Networking" gestolpert. Grob gesagt isses zwar (natürlich) wieder eins der Dylan-Propagandapaper (er mag die Sprache halt wirklich), aber dieses ist echt sehr nett. Ich hoffe doch, daß das Framework, was sie da vorstellen, sich weiterentwickelt.

Die letzten drei Tage hab ich einen Fehler aus der Kategorie "In den Fuß schießen mit C++" gesucht. Da gibt man sich nun schon alle Mühe, verwendet die gut getesteten Datenstrukturen der STL und trotzdem grinst einen ein ums andere Mal ein Segmentation Fault an. *gnaa*

Folgender Code (vereinfacht, das Original ist in eine Klasse eingebettet):

#include <iostream>
#include <list>

std::list<int> bla;

std::list<int> const getBla() {
        return bla;
}

int main() {
        bla.push_back(10);
        for (std::list<int>::const_iterator i=getBla().begin(); i!=getBla().end(); ++i) {
                std::cerr << *i << std::endl;
        }
}

getBla() ist im Original ein Getter für ein Klassenmember. Eigentlich ein gängiges Konstrukt. Der Crash passiert in der Schleife bei der Dereferenzierung des Iterators i. (Im Original war das etwas komplizierter, aber das ist hier nebensächlich.). Nach einigem Rumprobieren stelle ich fest, daß die Schleife zweimal durchlaufen wird, obwohl bla ja eigentlich nur ein Element enthält. Die Dereferenzierung des Iterators knallt im zweiten Durchlauf der Schleife (logisch, der zeigt dann ja irgendwo ins Nirvana).

Die Ursache des Fehlers liegt in einem fehlenden Zeichen in der Deklaration von getBla(). Eigentlich müßte das wie folgt aussehen (der Unterschied ist der Einfachheit halber rot markiert):

[...]
std::list<int> const &getBla() {
[...]

Standardmäßig übergibt C++ Parameter und Rückgabewerte by value, d.h. es wird eine Kopie des Wertes auf dem Stack gemacht. Das ganze ist von C geerbt. Mit der Einführung von abstrakten Datentypen kann so eine Kopie natürlich richtig teuer werden, weswegen zusätzlich die Möglichkeit der Übergabe by reference eingeführt wurde. Gekennzeichnet wird solch eine Referenz durch ein & hinter dem Datentyp. Dann wird eben statt der Kopie nur ein Verweis übergeben. Kann ungeheuer Zeit und Speicherplatz sparen.

Wie führt das nun in dem Code zum Crash? Nun dafür muss man sich mal den Kopf der for-Schleife näher anschauen:

[...]
        for (std::list<int>::const_iterator i=getBla().begin(); i!=getBla().end(); ++i) {
[...]

Im rot markierten Teil wird der Iterator i initialisiert und zeigt auf das erste Element der von getBla() zurückgelieferten Liste – einer Kopie der Originalliste, die durch die Rückgabe angefertigt wird. Im blau markierten Teil wird der Iterator vor jedem Schleifendurchlauf mit dem Endezeiger der von getBla() zurückgelieferten Liste verglichen – einer anderen Kopie, die ebenfalls wieder durch die Rückgabe by value entsteht. Nun, da der Iterator ursprünglich von der ersten Kopie an hochzählt, kann er nie den Endezeiger der zweiten erreichen, der komplett woanders liegt. Also bricht die Schleife nicht ab, wie es korrekt wäre, sondern läuft ein zweites mal durch. Durch das Hochzählen zeigt der Iterator nun hinter das Ende der ersten Kopie, per Definition also ins Nichts. *BUMM*

Ändert man den Rückgabetype von getBla() auf eine Referenz, so bekommt man bei jedem Aufruf dieselbe Liste (nämlich bla selbst). Und siehe da, dann funktioniert's! Also merke: Der Rückgabewert eines Getters ist grundsätzlich eine konstante Referenz!*grmpf* (Konstant übrigens deswegen, damit einem nicht irgendein Genie plötzlich die eigenen Daten unterm Hintern wegändert.)

Ein besonders schönes Stück Dokumentation aus einem Codestück, an dem ich gerade sitze:

/*---------------------------------------------------------------------------*/
/*     FUNCTION: <function>
 */
/*!    @brief    <short>
 *
 *               <detailed>
 *
 *     @param    <parmetername> [IN:|OUT:|INOUT:] <description> [range: x .. y] 
 *     @param    <parmetername> [IN:|OUT:|INOUT:] <description> [range: x .. y]
 *     @returns  <description>
 * 
 *     @pre      <contractual>
 *     @post     <contractual>
 *
 *     @warning  <warning>
 *     @todo     <features>
 *//*------------------------------------------------------------------------*/

Nein, er ist übrigens nicht von uns.

Grad im ICQ:

******** 16:45:51: puuh, jetzt hab ich mich aber selber verarscht
NAMENLOS 16:46:07: Wieso?
******** 16:46:28: typedef enum{true=0, false=1} tBool;
******** 16:47:04: wie doof
NAMENLOS 16:48:07: ROTFL. Schön.
NAMENLOS 16:49:49: Ich darf dich bloggen?
******** 16:50:08: jaja, tu nur
NAMENLOS 16:50:24: :) Ich mach's auch anonym
******** 16:51:42: *g* danke

Hihi...

P.S: Weil ich weiß, daß er/sie/es es liest: es ist im allgemeinen keine Gute Idee (TM) schlüsselwörter von C++ in C zu verwenden...

Vorhin eben habe ich mal wieder ein paar kleinere Probleme an A-Gen behoben und eine neue Version veröffentlicht. Jetzt sollte das Package wieder unter Debian unstable und Ubuntu installieren und der Code mit GCC 4.x kompilieren. Damit ist Version 0.1 soweit am Ende ihrer Entwicklung. Welche Features Version 0.2 genau bieten wird, weiß ich noch nicht. Auf jeden Fall soll die Möglichkeit zum automatischen Aufsplitten der Index-Seite kommen.

Die schon vor längerer Zeit mal vorgestellten Templatespielereien sind irgendwann tatsächlich mal in ein paar Projekten benutzt worden. Aus verschiedenen Gründen kam plötzlich die Anforderung: "Mach den Logger doch mal bitte thread-safe!". Äh, ja...

Konkret sollte der Ausdruck logger << LEVEL_DEBUG << "Eine Debug-Nachricht." << endl; nicht unterbrechbar sein, damit sich in der Ausgabe keine Nachrichten überlappen. Das ist nicht ganz so trivial, wie es scheint, denn in Wirklichkeit ist das nicht ein einziger Ausdruck, sondern dort stehen insgesamt 3 mehr oder minder unabhängige Teilausdrücke. Formt man dieses Zeile in die klassische Aufrufform um, so sieht das so aus (mal die Version der freien Operatoren, die nicht Element eines Typs sind, verwendet): operator<<(operator<<(operator<<(logger, LEVEL_DEBUG), "Eine Debug-Nachricht."), endl);. Man sieht also, daß hier dreimal ein operator<< aufgerufen wird, dessen Rückgabewert als Parameter für weitere Aufrufe verwendet wird. Um nun die gesamte Zeile thread-safe zu bekommen, muss der innerste Aufruf (welcher zuerst ausgeführt wird) einen Mutex locken und der äußerste muss ihn freigeben. Ersteres ist einfach: da das erste Element einer Zeile immer ein Level sein soll, kann man das locken des Mutex in diesen verlagern. Die zweite Anforderung ist schon schwieriger. Es ist für einen Operator nicht feststellbar, daß er der äußerste (und damit letzte einer Zeile) ist. Nun könnte man festlegen, daß jede Zeile mit endl angeschlossen werden muss und dann bei Empfang dieses Modifiers den Mutex wieder freigeben. Aus demselben Grund, wieso ein Operator nicht feststellen kann, daß er der letzte ist, kann man allerdings die Regel mit dem endl nicht erzwingen. Es ist zwar möglich, zu verhindern, daß auf ein endl noch etwas folgt, allerdings kann nicht erzwungen werden, daß überhaupt eines auftauchen muss.

Um nun zu vermeiden, daß sich der Programmierer um diese internen Details kümmern muss, kann man die Lebenszeitregeln von C++-Objekten nutzen. Dazu modifiziert man die Ausgabeoperatoren so, daß der Typ von logger direkt nur noch Loglevel-Typen als Parameter akzeptiert. So erzwingt man, daß das erste einer Zeile ein Level ist. Der Ausgabeoperator verpackt den übergebenen Logger dann in ein temporäres Objekt und liefert dieses zurück. Außerdem lockt er den Mutex. Die folgenden Ausgabeoperatoren nehmen als ersten Parameter dieses temporäre Objekt, führen ihre Ausgabeoperation auf den enthaltenen Logger aus und liefern das Objekt wieder zurück. Auch der letzte Operator in der Zeile liefert dieses Objekt zurück. Da es von niemandem mehr entgegen genommen wird, wird es vernichtet. Dabei wird sein Destruktor aufgerufen, welcher den gelockten Mutex wieder freigibt. Auf diese Weise ist die gesamte Zeile vor Unterbrechung geschützt.

Um den Logger nun portabel zu halten, sollte das schützende Mutex-Objekt nicht Element des Loggers sein. Leider ist Multithreading meist mit der Verwendung systemspezifischer Bibliotheken verbunden, so daß der Logger dadurch auf ein bestimmtes System festgelegt würde. Um das zu vermeiden, verwendet man ein Proxy-Objekt, welches eine Schnittstelle Lock() und Unlock() anbietet. Dieses nutzerdefinierte Objekt kapselt den eigentlichen, systemspezifischen Mutex. Dieses Objekt (bzw. genaugenommen dessen Typ) wird dem Logger in Form eines Templateparameters übergeben. Dieser ruft die entsprechenden Funktionen dann bei Bedarf auf. Auf diese Weise bleibt der eigentliche Logger-Code unabhängig vom zugrundeliegenden Threadframework.

Diese skizzierten Ansätze habe ich im ursprünglichen Logger implementiert, den Code noch etwas aufgeräumt und auf einer eigenen Seite (Vorsicht: Englisch) abgelegt. Dort findet sich auch die Schnittstellendokumentation und etwas übersichtlichere Hinweise zur Benutzung.