Archive vom Februar, 2011

Last time, they dried up on me; these germinated within a few days, so let's see if I can keep them alive a bit longer...

4 Kommentaredeutschsuomi

Gerade gefunden: Ein Link für alle, die wissen, was eine Turingmaschine ist.

Kein Kommentar

Ein Tsunami löscht innerhalb von Minuten fast alles Leben auf einem kleinen Südseearchipel aus. Unter der etwas wackeligen Ägide eines Jungen, den die Welle gerade während seiner Initiation zum Mann überrascht hat, findet sich ein Häufchen Überlebender zusammen. Außerdem ist da noch Ghost Girl, ein dreizehnjähriges Mädchen aus gutem britischem Hause, der die "Wilden" zwar etwas suspekt sind, andererseits aber auch willkommene Gelegenheit zur Auflehnung gegen gesellschaftliche Regeln. Während wir das Schicksal unserer buntgemischten Truppe verfolgen, lernen wir manches darüber, wie die Welt funktioniert und wie wir mit ihr umgehen. Daß man anständige Hosen tragen muß, um etwas entdecken zu können, weiß der Fan ja schon etwas länger...

So ganz fern der Scheibenwelt ist Nation doch ein echter Pratchett. Wie bereits in den späteren Scheibenweltromanen übt der Autor hier recht deutliche Gesellschaftskritik, und das Buch ist an manchen Stellen durchaus traurig, wenngleich der gewohnte Humor natürlich nicht zu kurz kommt.

Ja, und wenn der Erzähler am Schluß als the old man noch kurz aus der Anonymität heraustritt, dann werde ich das Gefühl nicht los, daß Pratchett sich hier selbst in seine Geschichte geschlichen hat. Überhaupt drängt sich dem Leser die Charakterisierung Spätwerk auf -- die Leichtigkeit etwa der Hexengeschichten scheint verflogen, und der Blick auf die Welt ist ein wenig melancholisch, aber doch voller Hoffnung.

2 Kommentare

Zur Abwechslung gibt es hier mal wieder etwas zum Anschauen: das obligatorische Eulenbild.

1 Kommentar

Ja, da war ich wohl ein wenig voreilig, das Verständnis des Buildsystems anzunehmen. Das stellte sich heraus, als ich den erfolgreich kompilierten gcc unter einem Debugger1 betreiben wollte. Wer schon einmal versucht hat, ein Kompilat mit eingeschalteter Optimierung zu debuggen, weiß, was ich meine: Variablen lassen sich nicht mehr auslesen, das Programm scheint im Code wirr vor und zurück zu springen -- selbst ein sehr einfaches, selbst geschriebenes Programm ist kaum noch nachvollziehbar. Nicht so schlimm, dachte ich mir, und habe mit CFLAGS='-g -O0' configure gleich den nächsten Build angestoßen. Die Ernüchterung folgte allerdings auf dem Fuße:2 die Flags waren irgendwo unterwegs verlorengegangen, und das Resultat kein bißchen brauchbarer als beim ersten Versuch.

Dabei bin ich eigentlich froh und dankbar, daß der gcc als Buildsystem die GNU Autotools verwendet. Sie werden zwar manchmal als veraltet und zu kompliziert abgetan, aber ich komme mit ihnen immer noch weit besser klar als mit CMake, Python Distutils und allem anderen, das ich bislang gesehen habe. Die Probleme beim gcc rühren allein daher, daß es mit dem bloßen Kompilieren nicht getan ist; stattdessen wird der dabei erzeugte Compiler dazu verwendet, aus dem Sourcecode noch einen Compiler (Stage2) zu erzeugen, und dieser wiederum erzeugt dann das fertige Kompilat (Stage3).3 Of will man in verschiedenen Stadien verschiedene Optionen verwenden, und deshalb gibt es auch einen ganzen Zoo von Umgebungsvariablen, deren Zweck nicht immer ohne weiteres klar ist.

Ach so, die Lösung: nach dem Konfigurieren einfach make BOOT_CFLAGS='-g -O0' bootstrap eingeben, und schon klappt es.

  1. Für den Fall, daß noch nicht alle des Programmierens nicht mächtigen Leser aufgegeben haben, sei gesagt: Ein Debugger ist ein Programm, mit dem man den Ablauf und den Zustand eines anderen -- möglicherweise fehlerhaften -- Programmen schrittweise verfolgen kann. []
  2. Jedenfalls halbwegs -- so ein Notebook ist nicht gerade die schnellste aller Entwicklungsmaschinen []
  3. Dieser Bootstrap genannte Zauber dient dazu, den fertigen Compiler mit sich selbst zu kompilieren, was ein guter Test für seine Zuverlässigkeit ist. []
Kein Kommentar

Eine kurze Statusmeldung: Inzwischen läuft der Build durch, und ein passendes Problemchen zur Analyse habe ich auch schon gefunden. Am Anfang ist es immer ratsam, sich einen weniger drängenden Bug zu suchen, weil es sonst leicht passiert, daß jemand mit mehr Erfahrung und Überblick schneller ist...

1 Kommentar

Es war vor ein paar Tagen, da saß ich in meinem Lieblingssessel, es war etwas früher als üblich, und es sollte ein schöner Abend werden. Endlich die Gelegenheit, etwas zu tun, zu dem mir sonst die Zeit fehlt -- doch was nur? Lesen mochte ich aus irgendeinem Grund nicht, und der Vokabelkasten neben mir wirkte auch nicht gerade verlockend. Ein Computerspiel vielleicht, dachte ich mir, wenn die Monster zur Tür hereinkommen und du die Taschenlampen und Bumerangs strategisch ums Bett herum verteilst ist das sehr befriedigend, weil die Kiste dir mit jeder Monsterwelle eine neue Herausforderung vorwirft aber du löst sie jedesmal und die Lösung ist so einfach und so elegant wenn du nur die Taschenlampen hinten in die Kurven und die Shuriken vorne an die Geraden stellst, aber nein irgendwie ist das ja auch alles repetitiv und ein bißchen langeweilig, und dann wußte ich du brauchst Code code CODE und es ist völlig egal daß du jeden Tag acht Stunden am Rechner verbringst du mußt jetzt und gerade den Compiler anwerfen und ein programmieren und jedes Problem ist eine Herausforderung aber das Programm löst sie und der Code ist so elegant nur ist es gar nicht repetitiv wenn du nur das richtige Problem hast und hinterher können tatsächlich Leute dein Programm benutzen und...

Nun ja, ich habe dann ein bißchen nach einem passenden Projekt gesucht. Vielleicht ein schönes buntes Mac-Programm? Aber bald fiel mir wieder ein, daß ich vor fünf oder sechs Jahren schonmal ein bißchen im gcc herumgefuhrwerkt hatte, und das hat mir eigentlich von allen Projekten immer noch am meisten Spaß gemacht: einerseits ist der Compilerbau schon soetwas wie die Königsdisziplin der angewandten Informatik, und andererseits gibt es beim gcc unglaublich viele kleine Nischen und Unterprojekte, in denen man sich nicht gegenseitig auf die Füße tritt, man aber auch Chancen hat, daß der eigene Code hinterher im fertigen Produkt Verwendung findet. Naja, und dann hat der gcc natürlich eine sehr zentrale Rolle im GNU-Projekt und eine unglaublich breite Nutzerschaft, und das schmeichelt dem Ego dann auch irgendwie.

Für's erste ist aber statt Blood, Sweat & Code noch der Kampf mit dem Buildsystem angesagt, damit ich den ersten Bootstrap hinbekomme.

3 Kommentare

Guter Druck, ein angenehmer Satzspiegel, und das Titelbild mit dem Samurai, der eine Ecke vom Goban schlägt, verleihen der Kunst des Angriffs von Kato Masao einen angenehmen ersten Eindruck.

Wie sieht es mit dem Inhalt aus? Ich muß vorwegschicken, daß mein Blickwinkel nur ein sehr eingeschränkter ist: Wigo gibt als angemessene Spielstärke den 10. bis 3. kyu an, ich bin aber mindestens zehn Steine schwächer. Daß diese Diskrepanz nicht völlig aus der Luft gegriffen ist, wurde bei der Lektüre auch schnell klar. Während ich das erste Kapitel, Grundlagen des Angriffs, noch recht gut verstand, war ich bei den Problemen des zweiten Kapitels durchweg überfordert. Das soll nicht heißen, daß ich an dem Werk keinen Gefallen gefunden oder keinen Nutzen daraus gezogen hätte -- vielmehr saß ich staunend vor den Aufgabenlösungen, die meist sehr anders aussahen, als meine eigenen, plumpen Überlegungen.

Das dritte und letzte Kapitel bringt schließlich kommentierte Partien aus Katos früher Profizeit. Den Aufbau (Grundlagen, Probleme, Partien) finde ich gelungen, und weil auch schwächere Spieler aus dem Buch -- vor allem, aber nicht nur, aus dem ersten Kapitel -- etwas mitnehmen können, gebe ich etwas vorsichtige vier von fünf Hoshi, äh, Sternen.

Kein Kommentar