Montag, 24. August 2009

Exotische Linuxprogramme

Auf ubuntublog.ch wird gerade die Frage gestellt: Exotische Linux-Applikationen gesucht. Dabei ist "exotisch" über "wenig bekannt" definiert. Mit dieser Definition könnte ich hier Werbung für meine eigenen Programme machen. Nun, warum auch nicht?
Jedenfalls weiss ich nichts davon, dass eines davon weit verbreitet wäre. Falls doch, he Leute, es schadet nichts dem Autor auch mal eine Rückmeldung zu geben, wenn euch ein Programm gefällt. Gerade bei kleineren Sachen hebt das die Motivation, und erhöht die Chanzen auch noch mehr davon zu hören. Es gibt keinen Grund, mit Anerkennung schwäbisch umzugehen.

Was es von mir an die Öffentlichkeit geschafft hat, ist bei freshmeat zu ersehen. Mit ausnahme des Projektionsrechners, der sich in der Weltenbastlercommunity eine Zeitlang einer gewissen Bekanntheit erfreute. Auch wenn er meines Wissens nie auf einem anderen, als dem meinen Rechner gelaufen ist. Wenn schon nichts anderes, als exotisch ist dieses Programm auf jeden Fall qualifiziert.

Nun, was sind exoten, die ich selbst verwende? Als jemand, der selbst für Geschäftskommunikation vim und TeX verwendet, bevorzuge ich ausgereifte Programme, die nicht alle halbe Stunde gepacht werden müssen. Die meisten davon haben es an sich, dass sie zumindest irgendwann recht bekannt waren.

Zu erwähnen ist vielleicht der Data Display Debugger, ein Debuggerfrontend, das, wie der Name schon sagt, Daten graphisch aufzubereiten und anzuzeigen. Ich sah noch keinen Debugger, der in diesem Bereich an den DDD auch nur annähernd hinkommt. Als Frontend ist der DDD ursprünglich mal für den gdb geschrieben worden, kann aber mittlerweile mit vielen anderen Backends umgehen. Wenn jetzt noch das Zusammenspiel mit Qt besser funktionierte (siehe unten), so wäre ich restlos zufrieden.

Konfigurationsmöglichkeiten

Zur Zeit bin ich immer noch dabei, mich mit Objekten, deren Anzeige und Konfiguration zu beschäftigen. Objekte in diesem Sinne ist alles, was auf dem Spielfeld steht, und nicht bewegt werden kann. Wenn es bewegt werden kann, so ist es eine Figur.
Nun hatte ich ja schon die Möglichkeit, ein Bild anzuzeigen und Klickgebiete zu definieren, die ein Script auslösen. Mein erster Zusammenstoß mit QtScript. Yea.
So auf Anhieb fand ich allerdings keine sinnvolle Möglichkeit, über das Script Werte einzugeben und zu verändern. Was tun? Selbst eine Eingaberoutine schreiben? Ach was. Zu was gibt es denn in Qt die schönen UiTools. Also Widgets zur Laufzeit beschreiben und anzeigen können. Also werden zusätzlich zum Hintergrundbild nun so schöne ui Dateien übertragen, mit Anzeigeposition und diese dann auf dem Bild platziert. Das ergibt zusammen mit der Möglichkeit, diese dann in den Scripts zu verwenden recht flexible Möglichkeiten für den Szenariobauer.

So langsam frage ich mich, ob es überhaupt ein Qt Modul gibt, dass in diesem Programm nirgends Verwendung findet. Nun, für das SQL Modul sieht es bisher nicht so aus. Auch OpenGl habe ich bisher nicht verwendet, könnte jedoch noch kommen. Ansonsten, ach ja, ActiveQt wird es mit hoher sicherheit auch nicht hinein schaffen. Sonst will ich da mal nichts ausschließen.

Montag, 10. August 2009

Umfangreiche Debuggingsession


Mit neuen Features gehen neue Fehler einher. Das ist so weit nichts neues. Tippfehler sind da die einfachsten, die erkennt der Compiler, und sie sind schnell behoben.
Gelegentlich bringen neue Features auch Fehler ans Licht, die schon länger existieren, aber bisher nicht zuschlugen. So einen hatte ich jetzt. Besonders unangenehm: Ein Fehler der meistens auftritt, aber nicht immer.

Es war klar, dass dieser irgendwie mit der Datenübertragung zusammenhängen muss. Allerdings sahen sowohl Server, als auch Client Code korrekt aus. Also hole ich Wireshark raus (Schlimmes Hackerprogramm. Ich fühle mich ja ach so böse.) und schneide die Kommunikation mit. Sieht alles ganz gut aus. Das in Frage kommende Datum - ein Bild - ist zu groß für ein Datenpaket, wird daher aufgeteilt. Dieses Vorgehen ist integraler Bestandteil von IP, und sollte daher kein Problem darstellen.

Doch was ist das? Meine Fehlerausgabe reklamiert unerkannte Daten, die genau so aussehen, wie die des zweiten Paketes. Ist nun IP kaputt? Kann doch nicht sein, dann würde ja viel mehr nicht funktionieren.

Die Lösung brachte ein Blick in die Qt Dokumentation. Ich verwende zum einlesen die QIODevice::readLine Funktion. Funktioniert meistens. Die liest eine Zeile, und eine Zeile endet mit '\n'. So weit so gut. Aber eine Zeile endet auch bei: "The end of the device data is detected."
Und das ist eine race condition. Wenn ich es schaffe readLine aufzurufen, bevor das zweite Paket ankommt, wird der Inhalt des ersten Paketes als vollständige Zeile zurückgeliefert.

Race Conditions sind recht unangenehme Fehler. Sie lassen sich fast nur durch hinzufügen eines zusätzlichen Endkriteriums beseitigen. Ich war ja der Meinung, '\n' sei ein solches Kriterium, ich übertrage das Bild ja nicht umsonst Base64 codiert. Ist es aber nach obiger Definition nicht.

Also brauche ich ein weiteres Ende Signal. Das Problem ist, dass ein solches Signal sich in der gesamten Datenübertragung auswirkt, deren allergrößter Teil bereits funktioniert hat, und funktionierenden Code lasse ich gerne stehen.
Hilft aber nichts, wenn es sein muss, wird eben ein Endesignal übertragen, dass dann auf der anderen Seite abgefangen werden will.

Nebeneffekte des Ganzen:


  • Ein paar kleinere Bugs konnten in diesem Prozess ebenfalls eliminiert werden.
  • Die Anzahl der ASSERTs ist merklich angestiegen.
  • Note to self: Dinge die begründet an einer Stelle anders gemacht werden, als überall sonst, dürfen gerne eine Kommentarzeile bekommen. Beim Aufräumen im Code ist sonst ein solcher Grund nicht immer im Hinterkopf präsent und es gibt gar wunderliche Effekte.


Ps.: Qt macht mir das Debuggen nicht gerade leicht. Immernoch halte ich DDD für den Besten mir bekannten Debugger. Aber wenn die Datenaufschlüsselung so aussieht wie in obigem Bild, werde ich daraus nicht wirklich schlau.

Sonntag, 9. August 2009

Objekte anzeigen


Das nächste implementierte Teil ist die Darstellung von Objekten. Und die Vorbereitung zur Konfiguration der selbigen.
Momentan lässt sich ein Bild für das Objekt definieren, und darauf "heisse" Bereiche.  Für diese heissen Bereiche sind momentan zwei unterschiedliche Möglichkeiten vorgesehen: Einmal wird ein einfacher Text angezeigt, mit der anderen Aktion ein Script ausgeführt.
Noch zu erledigen ist eine Rückmeldung an den Server, dass da was gemacht wurde.

Die Scriptausführung funktioniert noch nicht, wird ein heisser Bereich angeclickt sieht das momentan so aus, wie in obigem Bild dargestellt. Das Hintergrundbild ist das, was ich momentan für das Objekt "Stadt" hinterlegt habe. Die Übertragung des Bildes vom Server an den Client ist identisch der für Figurenbilder beschriebenen.

In diesem Bereich auf der TODO Liste:

  • Rückmeldung an den Server
  • Ausführung von Scripts
  • Teilbilder (Sprites) nachladen

Und bessere Bilder, aber das hat Zeit. Zu Testzwecken reicht das, was ich schnell fabrizieren kann vollständig aus.