Beiträge mit tag "Fehler

Java

Java Toolkit-Sync verschluckt Interrupted-Flag

0

Da mir im Moment der Sinn nicht ganz nach irgendeinem Politikum steht, worüber ich meinen Senf ausgießen müsste, werde ich vorerst noch mehr Softwareentwickler-Kram posten, mit dem ich die geneigten, aber uninteressierten Leser erfolgreich abschrecken kann. Wir danken für Ihr Verständnis.

Wer sich im Internet gezielt über aktives Rendering mittels Canvas in Java informiert, also etwas, das direkt im Zusammenhang mit Java-Spieleentwicklung steht, der wird wahrscheinlich irgendwann über die Methode sync() in java.awt.Toolkit stolpern, also meistens in der Form Toolkit.getDefaultToolkit().sync(). Nun gehe ich stark davon aus, dass die meisten Entwickler diese Codeschnipsel als gegeben ansehen und 1:1 in ihre eigene Klasse einfügen, da sie wahrscheinlich vielfach erprobt sind. So war das bei mir anfangs leider auch. In einem eigenen Render-Thread habe ich Bilder gerendert und anschließend brav das Toolkit “synchronisiert”, was laut Dokumentation irgendwie “gut für Animationen” ist.

Seit der Umstellung auf aktives Rendering jedoch hatte ich plötzlich Schwierigkeiten damit, den Render-Thread mittels interrupt() vorzeitig zu stoppen, also etwa wenn der Nutzer das Rendering über das Menü beendet oder wenn ein bestimmtes Ereignis auftritt. Zuvor war das nie ein Problem gewesen. Neuerdings läuft der Thread in drei von vier Fällen einfach weiter, sobald ich ihn gezielt unterbrechen will. Das war eine mittlere Katastrophe, denn ich konnte mich jetzt nicht mehr darauf verlassen, dass das Programm das macht, was ich davon erwartete. Mein Programm funktionierte so nicht mehr, und ich wusste nicht, was ich falsch gemacht haben könnte.

Etwa einen halben Tag hat es gedauert, bis ich den Fehler gefunden hatte: java.awt.Toolkit.sync() verschluckt ganz frech das Interrupted-Flag. Es scheint leider wirklich so zu sein. Die Implementation der Java Virtual Machine von Oracle ist hier offenbar fehlerhaft, denn alles funktioniert einwandfrei wenn ich auf sync() verzichte. Sobald ich die Zeile verwende, klappt das Unterbrechen des Threads nicht mehr. Meine Vermutung ist daher, dass das blockierende sync() das Interrupted-Flag mittels interrupted() abfragt (und dadurch löscht!), und dann leider nicht mehr setzt und leider auch keine Exception wirft. Es verschluckt die Thread-Unterbrechung völlig. So wird dieser Mechanismus sogar ganz offiziell in der Java-Doku erklärt:

if (Thread.interrupted()) // Clears interrupted status!

Nun hält sich Oracle selbst nicht daran. Ich habe anschließend in meinem Code keine Möglichkeit mehr, diese Unterbrechung zu erkennen und gegebenenfalls selbst eine InterruptedException auszulösen. Oracle hat hier eindeutig Scheiße gebaut, denn eigentlich ist das Konsens, das Interrupted-Flag nach dem Löschen erneut zu setzen, damit die Unterbrechung nach oben eskaliert werden kann, so dass auch andere Programmteile auf die Unterbrechung korrekt reagieren können. Hier wurde ganz einfach geschlampt.

Und was macht sync() eigentlich? Tja, keine Ahnung. So ganz scheint das nämlich niemand zu wissen. Ich liebe es, wenn die Java-Dokumentation von Oracle so explizit ist, dass man trotzdem keine Ahnung hat, was genau vor sich geht. So auch zur Methode sync() der Klasse Toolkit:

void java.awt.Toolkit.sync()

Synchronizes this toolkit’s graphics state. Some window systems may do buffering of graphics events.

This method ensures that the display is up-to-date. It is useful for animation.

Wenn jemand mal im Internet in einschlägigen Entwicklerforen versucht danach zu fragen, was das genau bedeutet, wird die Frage mit “synchronizes the graphics state” “beantwortet”, und anschließend als Off-Topic geschlossen. Zurecht wurde wenigstens noch darauf hingewiesen, dass das die Frage kaum beantwortet.

Da ich weder sagen kann, was die Methode macht, in welchen Fällen ich sie brauchen könnte, und welche Vorteile oder Nachteile damit zusammenhängen, werde ich auf sync() gerne verzichten, schon da ich mit dem Interrupt-Problem einen ziemlich schwerwiegenden Fehler entdeckt habe, den ich nicht bereit bin zu akzeptieren – ganz egal wie toll die Funktion ansonsten arbeiten möge.

goldenpoo

Eclipse Mars ist scheiße

2

Vor zwei Tagen ist Eclipse Mars (Version 4.5) erschienen. Voller Vorfreude habe ich mir das neue Release direkt am Erscheinungstag installiert, sowohl im Büro als auch zuhause. Heute habe ich das blöde Mistding immer noch nicht fehlerfrei am laufen. So lautet mein Fazit nach zwei verschwendeten Tagen, in denen ich weitestgehend irgendwelche Fehlermeldungen googlen durfte: Eclipse Mars ist einfach scheiße. Die Vorgängerversion Eclipse Luna hat mir in einem ganzen Jahr nicht soviel Ärger gemacht.

Wo sind “Check for Updates” und “Install New Software” hin?

Nach dem Entpacken und dem ersten Start sieht das “Help”-Menü folgendermaßen aus:

eclipsemarsfirst

Auch wenn ich Eclipse mehrmals schließe und wieder starte, ändert sich nichts. Doch sobald ich irgendein Plugin installiere, und Eclipse mich zum Neustart auffordert, verschwinden im “Help”-Menü alle wichtigen Menüpunkte:

eclipsemarssecond

Und sie tauchen auch nicht mehr auf. Neuinstallieren hilft, dann sind die Menüpunkte wieder da, bis sie irgendwann erneut verschwinden. Bis jetzt konnte ich nichts darüber herausfinden. Eclipse mit Administratorrechten zu starten, macht die Menüpunkte kurzzeitig sichtbar, aber nie wieder als normaler User, außerdem ist das kein befriedigender Workaround für diesen Fehler. Andere scheinen von diesem Problem ebenfalls betroffen zu sein, aber eine funktionierende Lösung oder eine Begründung dafür gibt es nicht.

Eclipse%20Mars

Im Büro hatte ich Eclipse zuerst mehr oder weniger versehentlich in einen Pfad mit Leerzeichen installiert. Sowas würde normalerweise gar nicht auffallen, da Programme seit mindestens 15 Jahren damit umgehen können, doch nicht Eclipse: Ein Ant-Build-Script ließ sich ums Verrecken nicht mehr ausführen, da die Eclipse-Ant-Version, die ohne ersichtlichen Grund von irgendeinem Additional Task im Zusammenhang mit SWT abhängig ist, die entsprechende JAR-Datei im Eclipse-Pfad nicht finden konnte. Die Fehlermeldung dazu sah ungefähr wie folgt aus:

The archive: C:\Program%20Files\Eclipse%20Mars\plugins\org.eclipse.swt.win32.win32.x86_64_3.104.0.v20150528-0211.jar which is referenced by the classpath, does not exist.

Stundenlanges Recherchieren im Netz brachte mich nicht weiter, nicht einmal die unnötige Abhängigkeit ließ sich rausnehmen, da der “Remove”-Button schlauerweise immer ausgegraut ist. Der Fehlermeldung konnte ich schließlich bei genauerem Hinsehen entnehmen, dass Ant das Leerzeichen im Pfad mit “%20″ kodieren wollte, was im lokalen Dateisystem nicht funktioniert. Eclipse-Ant versteht offenbar keine Leerzeichen. Das Umbenennen des Installationsverzeichnisses hat dann geholfen, aber eine Lösung ist das ja nicht. Schade um die vergeudete Zeit. Danke für nichts, Eclipse.

Nachtrag vom 29.06.: Inzwischen habe ich herausgefunden, dass dieser Fehler ein registrierer Bug in Eclipse 4.5 ist. Ich bilde mir also zum Glück noch nichts ein.

Zuhause überraschte mich mein eigenes Ant-Build-Script in Eclipse Mars neuerdings mit dieser Fehlermeldung:

No editor descriptor for id org.eclipse.ant.ui.internal.editor.AntEditor

Wenn ich die External Tools Configuration aufrufen will, hagelt es weitere Fehlermeldungen, z.B.:

Exception occurred creating launch configuration tabs

Reason:
No tab group defined for launch configuration type
org.eclipse.ant.AntLaunchConfigurationType

Und damit lässt sich das Build-Script weder vernünftig bearbeiten noch in irgendeiner Form ausführen oder konfigurieren. Wurde Eclipse-Ant heimlich aus der “Eclipse IDE for Java Developers” entfernt? Eigentlich scheint Apache Ant 1.9.4 dem Paket wie erwartet beizuliegen, aber in der IDE selbst wurde jede Ant-Referenz entfernt. Google weiß zu dem Thema auch nichts. In Eclipse Luna hat das alles noch einwandfrei funktioniert. Beim erneuten Entpacken des Programms war Ant plötzlich wieder da – fragt sich nur wie lange noch. Egal woran es hängt, die Fehler gehen mir mächtig auf die Nerven, und ich hätte gerne, dass das behoben wird.

Cannot complete the install wegen was auch immer

Eclipse ist hässlich, aber zum Glück gibt es Abhilfe: Das Plugin “Jeeeyul’s Eclipse Themes” lässt die Entwicklungsumgebung einigermaßen brauchbar aussehen und verbessert die Laune beim Arbeiten erheblich. Seit zwei Jahren bin ich ein echter Fan dieses Plugins, und so wollte ich auch Eclipse Mars damit ein wenig aufhübschen. Offenbar ist die Installation aber total schwierig:

Cannot complete the install because one or more required items could not be found. Software being installed: Jeeeyul’s Themes 2.3.0.I20150604-134826 (net.jeeeyul.eclipse.themes.feature.feature.group 2.3.0.I20150604-134826) Missing requirement: Jeeeyul’s Themes 2.3.0.I20150604-134826 (net.jeeeyul.eclipse.themes.feature.feature.group 2.3.0.I20150604-134826) requires ‘org.eclipse.xtend.lib 0.0.0′ but it could not be found

Im Anschluss bietet der Eclipse Marketplace mir als mageren Ersatz eine hoffnungslos veraltete Version des Plugins an, die mit Eclipse Mars überhaupt nicht kompatibel ist und das Programm entweder im Betrieb zum Absturz bringt, oder erst gar nicht starten lässt, je nachdem ob die Theme bereits im Workspace hinterlegt war, oder erst nachträglich gewechselt wird. Der Eclipse Marketplace ist nicht nur völlig unfähig darin, eine bestimmte Abhängigkeit für mich aufzutreiben, wenn ich ein Plugin installieren will, er ist auch noch so unfähig, dass er mir eine total falsche Version installiert, die die Eclipse-Installation im Endeffekt unbrauchbar macht.

Wegen solch lästiger Kinderkrankheiten erwäge ich zum ersten Mal nach elf Jahren Eclipse endlich links liegen zu lassen, und es stattdessen doch mal mit einer professionellen Entwicklungsumgebung zu versuchen, die mich nicht mit Fehlermeldungen überhäuft und Menüpunkte versteckt.

Nachtrag vom 29.06.: Weiter gehts. Noch nicht einmal ein Update klappt richtig, wenn denn der Menüpunkt ausnahmsweise mal auftaucht:

Unable to read repository at http://download.eclipse.org/releases/mars.
No repository found at http://download.eclipse.org/technology/epp/packages/mars/.

Spacola_Disks1

SPACOLA Eclipse WIP 0.42

0

spaclipse042_2

Bevor hier tatsächlich noch Schimmel ansetzt, belästige ich die werte Leserschaft lieber nochmal mit den aktuellsten Vorgängen in Bezug auf die Webseite und SPACOLA Eclipse. Hierzu habe ich mir eine kleine Liste bereitgelegt, die ich jetzt in einem mehr oder weniger kurzen Artikel abfrühstücken möchte. Am liebsten hätte ich die Gelegenheit genutzt, meine Meinung zur kürzlich angekündigten st-computer-Ausgabe kundzutun, doch wie es scheint, bekommen die Käufer die Februar-Ausgabe frühestens Mitte März, daher wird das wohl noch etwas dauern.

Stattdessen habe ich die Aufmerksamkeit für mein kleines Dongleware-Museum in kreative Energie umgewandelt und einige Einträge hinzugefügt bzw. erweitert. Hinzugekommen ist das wenig bekannte Spiel “The Dragon’s Power”, das von Dongleware 1994 vertrieben wurde, von welchem ich erst vor wenigen Monaten erfuhr. Ebenfalls ist mir entgangen, dass ich doch tatsächlich eines der Schneider’schen TOS-Gimmicks vergessen habe: Das Accessory “Blackhole”, das den Papierkorb in ein schwarzes Loch verwandelt. Es war eigentlich nur eine Beilage zum TOS-Gimmick “Trashy”. Die Beschreibungen der Gimmicks habe ich zusätzlich erweitert und mir auch die Quelltexte der kleinen Programme abgespeichert. Einen Teil der Codes kann ich vielleicht in das Remake-Projekt einbringen.

Besonderen Dank möchte ich an dieser Stelle übrigens einer Leserin des Blogs aussprechen, die mir aus heiterem Himmel ihr OXYD-Buch (guterhalten), und das passende Spiel auf CD per Post geschickt hat. Das war eine äußerst schöne Überraschung. Eine kleine Aufwandsentschädigung habe ich ihr dafür natürlich zukommen lassen. Meine Dongleware-Büchersammlung wurde auch durch einen weiteren SPACOLA Sternenatlas vergrößert, den ich für nicht einmal vier Euro bestellen konnte. Der Einband ist leider ein wenig beschmiert, und auch kleine Eselsohren waren wie erwartet drin, aber ich denke ich kann mich nicht beklagen. Damit habe ich nun also vier SPACOLA-Codebücher in meinem Besitz. Einem weiteren Leser und fleißigen Bolo-Spieler ist es zu verdanken, dass ich bei nächster Gelegenheit eine kleine Levelgalerie für Bolo (1995) und Dia-Bolo einweihen kann. Diese ist zwar nicht ganz vollständig, aber was nicht ist, kann ja noch werden. Der nächste Urlaub ist insoweit schon verplant.

Was gibts über SPACOLA Eclipse zu sagen? Der Fortschritt ist unverändert langsam, aber beständig. Der Zähler steht jetzt bei 20.000 Java-Codezeilen. Jeden Tag bemühe ich mich um ein oder zwei Änderungen, ein paar Fehler zu beheben, ein paar Grafikdateien zu korrigieren, etc. Die Februar-Version steht ganz im Geiste der Originaltreue und Platzersparnis. Ich habe herausgefunden, dass das PNG-Dateiformat sogar 1-Bit-Farbtiefe kennt (echt monochrom!) und habe sämtliche 700+ Grafikdateien einzeln umgewandelt und neu gespeichert. Am Ende hatte ich 64 Kilobyte von 415 gespart. 15% unnötige Daten entfernt, also wenn das nichts ist. Außerdem ist es mir gelungen, mit einem Hexeditor und viel Geduld in mühsamer Kleinstarbeit den SPACOLA-Rentenbescheid aus einem Memory-Dump des ST-Spiels zu extrahieren, und zusätzlich (endlich byte-genau) fast alle SDD-Sounddateien, also exakt so wie sie vor der “Kopierschutz-Kompression” aussahen. Anschließend habe ich die Soundbibliothek meines Remakes so erweitert, dass sie die Original-8-Bit-PCM-Dateien importieren und verwenden kann. Damit wäre ich wieder einen kleinen Schritt näher am Atari-Vorbild.

spaclipse042_1

Nachdem ich mich also im Februar weitestgehend nur um die Technik unter der Haube gekümmert habe, ist diesen Monat wieder mal das Gameplay dran. Die letzten Tage gelang es mir, alle 14 Minenfeld-Konstellationen aus den Levels des Originals zu analysieren und in meinem Code umzusetzen. Nun steht dem geplanten Parser für die Levelkonfiguration der ST-Version nicht mehr viel im Wege. Das Level-“Skript” habe ich inzwischen zu etwa 80% entschlüsselt, nur einige wenige Parameter, die etwa das Standardverhalten der Gegner ändern, oder Häufigkeitsmodifikatoren sind mir leider nicht ganz klar. In meinem Analyseprozess ist mir übrigens aufgefallen, dass die Entwickler in ihrer Levelkonfiguration eindeutig einen Fehler gemacht haben: In Level 14 müssten laut Skript sämtliche Sektoren mit Minenfeldern ausgestattet sein, doch da taucht kein einziges auf. Das Problem ist, dass sich dort im Skript jemand vertippt hat, so dass gar keine Minenfelder erzeugt werden. Im Debugger konnte ich bereits nachstellen, dass sich das Level deutlich ändert, wenn man den Tippfehler im Speicher korrigiert. Wenn ich nicht von dem Spiel besessen wäre, wäre das wahrscheinlich nie jemandem aufgefallen.

Jetzt stehe ich vor einer merkwürdigen Entscheidung: Tippfehler im Remake korrigieren und das Level so nachstellen, wie die Entwickler es sich eigentlich gedacht hatten – oder Tippfehler beibehalten, und das Level so nachstellen, wie es das Originalspiel auch wirklich dargestellt hat? Vor einem ähnlichen Problem stand vor einigen Jahren der Entwickler des Dungeon-Keeper-Remakes “KeeperFX”, der bei seiner Reverse-Engineering-Odyssee herausgefunden hat, dass die Bullfrog-Programmierer einen ganz blöden Fehler im Zusammenhang mit dem “Machtwort”-Zauberspruch nie richtig beheben konnten. In der Folge war der Zauberspruch viel schwächer als er eigentlich sein müsste. Nachdem er den Fehler nun also gefunden und im Remake behoben hatte, und der Zauberspruch plötzlich genau die Wirkung zeigte, wie es von Anfang an gedacht war, war das Balancing im Spiel leider total im Arsch. Logisch: Das Spiel war immer nur mit dem “verkrüppelten” Zauberspruch getestet und feingeschliffen worden. Tatsächlich gibt es im Remake nun die Möglichkeit, den Fehler für die Originalkampagne wieder zu “aktivieren”, um das bekannte Spielbalancing nicht zu verändern. Vielleicht sollte ich das Problem auch via Optionsmenü lösen, und so dem Spieler die Entscheidung überlassen.

Windows

Not so monthly rant: Die wertlose Windows-Dateisuche

4

Lange habe ich mich nicht mehr so sehr über etwas geärgert wie die Windows-Dateisuche. Aus einem bestimmten Ordner mit sehr vielen unterschiedlichen Dateien wollte ich anhand eines entsprechenden Namensmusters einige davon in einen anderen Ordner verschieben. Nichts leichter als das, dachte ich mir, denn die Windows-Suche unterstützt ja schließlich Wildcards (“*” und “?”), und auf den Kopf gefallen bin ich zum Glück auch nicht. Die erwartete Trefferliste lieferte mir die Suchfunktion in Nullkommanix. Mittels Ausschneiden und Einfügen waren mehrere hundert Dateien blitzschnell an den neuen Ort verschoben.

Durch Zufall fiel mir eine Datei ins Auge, die in dem neuen Ordner aber definitiv nichts verloren hatte. Hat die Windows-Suche sich da ein wenig vertan? Konnte ja eigentlich kaum sein. Vielleicht habe ich beim Markieren der Dateien irgendetwas verkehrt gemacht? Auch unwahrscheinlich. Um sicherzugehen, machte ich den Verschiebevorgang rückgängig und führte die Suche erneut aus. Wieder wollte ich die gefundenen Dateien verschieben. Und wieder waren Dateien dabei, die nicht auf das Namensmuster zutreffen konnten. Spinnt Windows oder versagt hier der Faktor Mensch? Ich beschloss also, den Test zu machen:

windowssuche

Was für ein unbrauchbarer Dreck ist das denn bitte? Die Windows-Dateisuchfunktion ist völlig wertlos! Sie hält sich nicht an das Pattern, das ich eingegeben habe, und spuckt neben den richtigen auch falsche Treffer aus. Die Klammern werden einfach ignoriert, so als hätte ich sie nur aus Spaß eingegeben. Meine Recherche im weltweiten Netz bestätigt meine Vermutung: Microsoft hält nichts von Konventionen, sondern bastelt lieber wieder irgendeinen eigenbrötlerischen Schrott zusammen, den man als professioneller Nutzer nicht vernünftig verwenden kann. Das “Escapen” der Klammern mit Backslashes oder Punkten bringt leider nichts, Windows scheint meine Eingabe nur als grobe Empfehlung zu betrachten. Was richtige Suchergebnisse sind, muss ich offenbar gänzlich dem Betriebssystem überlassen. Die Suchfunktion genügt meinen Ansprüchen hier leider absolut nicht. Bevor ich mir die Microsoft’sche Syntax zur Dateisuche anlerne, sofern eine solche überhaupt existiert, nehme ich lieber ein ordentliches Third Party Tool, mit dem man arbeiten kann.

Beinahe hätte ich meine Dateien unbewusst falsch sortiert. Na danke, Microsoft, ihr verdammten Trolle. Wer weiß wie oft ich darauf bislang schon hereingefallen bin ohne es zu merken. Wie schwer kann es sein, eine Suchfunktion mit Wildcards richtig zu implementieren. Ich verlange ja gar nicht, dass hier reguläre Ausdrücke ausgewertet werden, aber eine simple Suchfunktion, die keinen Mist baut, wäre mir WIRKLICH wichtig. Echt mal.

So habe ich nun in meiner Verzweiflung einige – wie sich herausstellte – ebenfalls ziemlich nutzlose Tools heruntergeladen, die meine Erwartungen nicht erfüllen können, darunter “Everything”, “Snowbird”, “Locate32″ und “UltraSearch”. Entweder ließ sich die Suche nur auf (langwierig) vorindizierte Festplatten anwenden (und ich wollte nicht drei Stunden auf mein Suchergebnis warten müssen), oder die Suche ließ sich überhaupt nicht auf Verzeichnisse, sondern im Fall von “Everything” nur auf ALLES anwenden, oder die Suche kannte keine Wildcards, was ich bei einem Dateisuch-Tool als übles Versäumnis betrachte. Nun habe ich schließlich den “FreeCommander” ausprobiert. Der hat alle gewünschten Dateien problemlos gefunden, mit exakt demselben Suchmuster, wie ich es zuvor dem Windows Explorer vorgesetzt hatte – und zwar im Gegensatz dazu fehlerfrei.

nach oben