Ach ja, und der jetzt kleinere Font sieht auch (zumindest auf meinem kleinen Netbook) ziemlich bescheiden aus.

Warum um Himmels Willen tut ihr so etwas?

Als Einstieg in die Programmiersprache Eiffel, wollte ich nun hergehen und diese Bibliothek auch nach Eiffel portieren.

Die Sprache Eiffel selbst, ist, wenn man sich erstmal an die etwas andere Syntax im Gegensatz zu anderen Sprachen gewöhnt hat, eigentlich recht hübsch und flexibel. Ich wollte mich also etwas näher mit Eiffel beschäftigen.

Die Installation auf einem kleinen Netbook mit Windows 7 Starter war unproblematisch. Eigene kleine Beispielprogramme ließen sich übersetzen und funktionierten auch.

Da ich gerne testgetrieben entwickle, habe ich mir das Tool Etest von Jim Weirich (richtig geschrieben?) geholt, welches automatisierte Tests, wie ich sie von Ruby her kenne, durchführen kann. Dazu geht man ähnlich wie bei Ruby vor. Man erstellt eine Klasse namens ‘TEST_’ + Name der eigenen zu testenden Klasse. Dann ruft man das Kommando etest auf, welches temporäre Klassen erstellt, die dann kompiliert und ausgeführt werden (alles innerhalb des etest-Aufrufs). Als Ergebnis von etest erhält man die Anzahl der korrekten Testfälle und die fehlgeschlagenen Tests ausgegeben (wie auch bei Ruby Unittests).

Eine kleine Überraschung war, daß zum Erzeugen der temporären Testklassen tatsächlich Perl verwendet wurde (mußte ich dann auch noch installieren, machte aber auch keine Probleme). Warum um Himmels Willen Perl? Na ja – Hauptsache es funktioniert.

Funktionieren tat es dann doch nicht so ganz. Ich weiß nicht, auf welcher Basis bzw. welcher Version dieses Tool geschrieben wurde, mit meiner jetzigen SmartEiffel-Version (2.3) lief es nicht so ganz rund. Die assert_equal Methode kann man leider nicht verwenden, weil da in der etest-Methode der Parameter vom Typ ANY angegeben ist, ich dafür in meinem Test aber keine Integer-Zahl übergeben kann. Ich muß zugeben, ich verstehe noch zu wenig von Eiffel, um mit der Fehlermeldung etwas anfangen zu können. Nach meinem bisherigen naiven Verständnis sollte bei ANY dann doch beliebige Parameter angegeben werden können, oder nicht?

Was aber funktonierte war die Methode assert (die nur einen booleschen Wert verlangt). Ich mußte also meine Tests nur etwas umformulieren und konnte damit auf assert_equal verzichten und nur assert verwenden. Das sieht zwar nicht ganz so elegant aus, funktioniert aber.

So baute ich meine Klassen – testgetrieben – noch weiter aus.

Dann kam ich an den Punkt, wo ich XML-Files parsen mußte.

Halt – vorher noch etwas anderes. In Ruby gibt es fertige Libraries, um ZIP-gepackte Dateien zu entpacken bzw. auf die gepackten Daten wie auf ein Filesystem zugreifen zu können. In Eiffel: Fehlanzeige. Keine Library dazu gefunden, in de.comp.lang.misc nachgefragt – niemand wußte etwas darüber (genauer gesagt, habe ich noch nicht mal eine Antwort bekommen). Gut. Ich habe mir dann erst mal damit beholfen, daß ich ein unpack-Kommando extern aufrufe und dann innerhalb der entpackten Files auf meine benötigten Files zugreife.

Zurück zu XML. Es gibt in SmartEiffel ein tutorial-Verzeichnis, in dem zu vielen mitgelieferten Libraries Beispielprogramme enthalten sind, was natürlich eine gute Idee ist. Hier habe ich dann auch Beispiele für die Bearbeitung von XML-Dateien gefunden, sowohl für DOM als auch für SAX. Prima, dachte ich, ist ja alles da, was du brauchst. Ich habe also dieses Beispiel genommen und in mein eigenes Programm eingebaut. Versucht zu übersetzen – Peng. Der Compiler schmiert damit komplett ab. Nicht etwa, daß mir das Frontend einen Fehler in meinem Programm melden würde (was vielleicht noch erklärbar wäre), nein, der Compiler generiert C-Code, der nicht übersetzt werden kann. Daraufhin habe ich das originale Tutorial-Beispielprogramm übersetzt – wieder das gleiche Ergebnis. Es sind also noch nicht mal die eigenen Tutorial-Beispiele alle kompilierbar. Den gleichen Effekt habe ich auch bei dem curses (oder ncurses?) Tutorial-Programm bemerkt (obwohl es hier vielleicht auch an fehlenden externen curses-Libraries hätte liegen können, was ich aber nicht weiter untersucht habe.

Meine Vermutung ist, daß es vielleicht mit dem von mir verwendeten Betriebssystem Windows 7 Starter zu tun hat, worauf der SmartEiffel Compiler (bei mir Version 2.3) noch nicht angepaßt wurde, da SmartEiffel wohl seit einiger Zeit nicht mehr gewartet werden zu scheint (Mitte 2007). Anfragen an die Mailingliste wurden (man ahnt es schon fast) ignoriert. Beim Bugtracker zu SmartEiffel kann man überhaupt keine neuen Bugs eintragen (oder ich bin zu blöd dazu, eine diesbezügliche Anfrage an die Mailing-List wurden auch nicht beantwortet).

Ich finde das ein ziemlich schwaches Bild dafür, daß SmartEiffel das „offizielle“ Eiffel von GNU ist.

Mein vorläufiges Fazit: Eiffel ist in der Theorie eine schöne Sprache, aber wenn man damit praktische Aufgaben erledigen will, leider kaum zu gebrauchen. Ich spreche hier natürlich nur über SmartEiffel. Es gibt andere Compiler, aber die schienen mir persönlich nicht so passend:

Eiffelstudio: zu fette und komplexe IDE, die ich erstmal nicht haben wollte, in der freien Version von EiffelStudio darf man nur Open-Source Projekte entwickeln

tecomp: Ist so weit ich weiß nur ein Interpreter, und ich weiß nicht, wie ausgereift der mittlerweile ist.

Da ist leider noch so ein Punkt, der mit bei den existierenden Eiffel-Compilern extrem stört: Jeder scheint irgendwie sein eigenes Eiffel zu machen, Quelltexte des einen Compilers müssen zum Kompilieren mit einem anderen Compiler an einigen Stellen angepaßt werden – fast so wie bei den unterschiedlichen COBOL-Compilern früher in den Achtzigern.

Sollte mich doch noch jemand davon überzeugen können, daß Eiffel nicht nur in der Theorie toll ist, sondern man damit auch praktische Aufgaben lösen kann, bin ich gerne bereit mich wieder damit zu beschäftigen, aber ansonsten werde ich in der Kategorie der kompilierten Programme wieder eher auf Ada setzen (Halt! Da muß ich aber auch erst testen, ob das mit mit meinem Betrübssystem zusammen funktioniert – aber ich würde bei Ada eher ein Ja vermuten).

Seit kurzem gibt es aber ein neue Seite, die es sich zur Aufgabe gemacht hat, zusammenzutragen, welche gems mit Ruby 1.9 funktionieren und welche nicht.

www.isitruby19.com Logo

Man kann dort ein Gem auswählen, Version, Betriebssystem, Kommentar und seinen eigenen Namen angeben, sowie, ob das betreffende gem bei einem funktioniert hat oder nicht.

Eine sehr gute Sache, wie ich finde.

Andere Besucher können dann wiederum sehen, ob es bei einem bestimmten gem Probleme mit Ruby 1.9 gibt oder nicht, ohne es erst selbst ausprobieren zu müssen.

Man sollte natürlich auf die Versionsnummer der getesteten gems achten, da die neueste Version eventuell schon korrigiert wurde und nun keine Probleme mit Ruby 1.9 mehr macht.

Desweiteren ist das natürlich auch eine gute Sache für die Autoren der gems, da sie sehen, ob ihre Programme auch in Ruby 1.9 fehlerfrei laufen – insbesondere auch in Bezug auf unterschiedliche Plattformen

Ich weiß, daß meine eigenen gems auch noch nicht ganz perfekt unter Ruby 1.9 laufen, aber es sollte eigentlich keine allzugroßen Fehlerkorrekturen geben. Leider kann ich da aber zur Zeit nicht so recht weiter machen, da mir auch für die Entwicklung und Veröffentlichung noch einige Tools fehlen, die derzeit halt auch noch nicht nach Ruby 1.9 rübergezogen wurden. Das ist leider etwas frustrierend.

Randomplay wird von der Kommandozeile aus aufgerufen. Es wurde unter Linux entwickelt, läßt ich mit ein paar Modifikationen im Code aber wahrscheinlich auch leicht für Windows oder andere Systemem anpassen (nicht getestet, aber wenn sich jemand daran versuchen möchte, das Code-Repository kann von jedem heruntergeladen werden).

Die Handhabung von Randomplay ist denkbar einfach: In das Directory wechseln, welches die Mediendaten enthält und dort einfach randomplay eintippen. Es werden dann alle Stücke in diesem Directory und eventuell vorhandenen Unterdirectories in zufälliger Reihenfolge abgespielt.

Während ein Stück gespielt wird, entspricht die Steuerung mittels Tasten dem Programm ‘mplayer’:
Ein Druck auf die Taste q beendet das gerade laufende Stück und springt zum nächsten Stück. Mit den Cursor-Tasten links und rechts kann man im Stück vor- und zurückspulen.

Anreiz für mich, dieses Programm zu erstellen, war auch, daß man damit sehr schön zeigen kann, wie man die Möglichkeiten von Ada-Tasks (d. h. unabhängig laufenden Programmabschnitten) in einem Programm wie diesem verwenden kann. Es gibt im wesentlichen zwei Tasks. Eine ist dafür verantwortlich eine zufällig zusammengestellte Playlist intern zu erstellen, während die zweite Task für das Abspielen zuständig ist.

Das Programm spielt die Einträge nicht ganz rein zufällig, sondern versucht auch zu vermeiden, daß ein Stück zu oft hintereinander abgespielt wird. Nach einem bestimmten Stück müssen deshalb mindestens N andere Stücke gespielt werden. Falls insgesamt aber zu wenige Stücke vorhanden sind, läßt sich diese Regel nicht einhalten. Das Programm ist auch darauf vorbereitet und es wird der Bereich dynamisch verringert (wenn es insgesamt zu wenige Stücke zum Spielen gibt, dann läßt es sich eben nicht vermeiden, daß man ein Stück kurz darauf schon wieder abspielen muß).

Zum einen scheint es öfters generell in Rails-Anwendungen verwendet zu werden. Diesen Eindruck habe ich gewonnen anhand der Fragen und Feature-Requests in der roo-Group.

Ein kurzes Tutorial unter http://rubyonwindows.blogspot.com/2008/01/parsing-spreadsheets-with-roo-gem.html.

Ein Beispielprogramm zum Benutzen von Google-Spreadsheets von iamarf unter http://iamarf.wordpress.com/2008/11/19/cck08-a-little-learning-experience/.

Bei koders.com (http://www.koders.com/ruby/fidD47DEFAE86EEF70EE26921E8F46C0A52138EFDFC.aspx?s=proxy) ein paar Beispielprogramme, aber das sind auch nur die Beispielsprogramme innerhalb meines Gems.

Ein italienisches Beispielprogramm: http://www.ruby-forum.com/topic/170477

Oh, roo wird hier sogar aufgeführt als eine der coolsten Tools, die in der letzten Zeit für Rails erschienen sind (roo ist zwar nicht ausschließlich für Rails gedacht, kann aber auch da natürlich benutzt werden):

http://www.ozmox.com/?p=33

Und dann, was ich überhaupt nicht mitbekommen habe, in einem Rails-Podcast aus Amerika wird roo auch kurz erwähnt (http://www.railsenvy.com/2007/12/19/rails-envy-podcast-episode-11)

Es handelt sich dabei um kleine, in der Art von Legosteinen aneinandersteckbare, Module, mit denen je nach Kombination verschiedene Geräte zustammengebaut werden können.

Es gibt ein Basismodul, weitere Module mit Kamera, GPS-Empfänger, Bewegunsmelder oder Touchscreen-LC Display.

Das ganze basiert auf einem Linux-System und soll, laut der verkaufenden Firma, in Java programmiert werden können.

Ich denke, das werde ich mir besorgen. Das hört sich wirklich interessant an. Allerdings kann das derzeit noch nicht von außerhalb der USA bestellt werden.

Weiterer Artikel bei www.linux.com

BUG Community: http://community.buglabs.net/

Heute folgendes gefunden

Es wird erklärt, warum durch den LHC ein schwarzes Loch entstehen und die ganze Erde (mindestens) vernichten könnte. Belegt wird das mit einer skurrilen Mischung aus Vorhersagen von Nostradamus, Zitaten aus der Bibel, kabbalistischen Zusammenhängen und Erkentnissen aus dem sogenannten Bibel-Code der auch Andeutungen enthalten soll. Echt skurril das ganze.

Aber was mich dann wieder interessiert hat, ist, daß es sogar eine Software für diese Bibel-Code Sache gibt – muß ich mir mal näher ansehen. Schade, das Programm ist leider keine Open-Source Software und kostet ca. 67 US-Dollar, das ist mir dann doch zu wenige interessant.

Um’s klarzustellen, ich persönlich glaube aber weder daran, daß es physikalisch zu einer Katastrophe kommen könnte, noch daran, was die obigen Quellen angeblich hergeben – das ist dann doch zu weit hergeholt.

Zugute halten muß man dem Video aber, daß es in astreinem klaren und langsam gesprochenen Englisch gesprochen ist, was es auch weniger geübten Zuhörern erlaubt, das zu verstehen.

Andererseits: Vielleicht haben wir ja deshalb noch nichts von außerirdischem intelligenten Leben mitbekommen, weil diese im Laufe ihrer Entwicklung ähnliche Experimente durchgeführt haben und auch daran gescheitert sind …

$ randomplay
randomplay: error while loading shared libraries: libgnarl-4.1.so.1: cannot open shared object file: No such file or directory

Was ist das für ‘ne Library? Direkt mache ich damit in meinem Programm überhaupt nichts.

Gut, man kann das Problem durch einfaches Neucompilieren des Programms beheben. Aber sollte bei solchen Sachen nicht auf einen symbolischen Link verwiesen werden, der bei Bedarf dann auf neue Releases der entsprechenden Library verweist? Ich will mal zu GNATs Gunsten annehmen, daß nur bei meiner lokalen Installation irgendwas nicht richtig war – obwohl ich mir keiner Schuld bewußt bin, da irgend etwas großartig verbogen zu haben.