Sollte jemand versuchen, mit der aktuellen deutschen Inform-Library und im Quellcode aktiviertem NO_PUNCTUATION etwas für Glulx zu kompilieren, wird ihn der Biplattformcompiler ebenso wie der neue Inform-6.30-Compiler mit folgender Fehlermeldung begrüßen:

Inform 6.21 (biplatform, G0.37) (24th Aug 2000):

include\German.h(329): Error: Expected expression but found ]

]

include\German.h(329): Error: Expected assignment or statement but found <constant>

]

...

Der Fehler befindet sich laut Zeilenangabe in der PreProcessGerman:

! Routine, with is called first to do some dirty work

[ PreProcessGerman  x;

#ifndef NO_PUNCTUATION;

    x=0; !Warnung über unbenutze Variable (wenn TARGET_ZCODE,

    !PUNCTUATION gesetzt ist) verhindern

#endif;

! Glulx does not lower the ASCII-chars, so do it now

#ifdef TARGET_GLULX;

for (x = WORDSIZE: x < WORDSIZE + (buffer-->0): x++) {

  buffer->x = glk_char_to_lower(buffer->x);

}

#endif; ! TARGET_

   

#ifdef NO_PUNCTUATION;

#ifdef TARGET_ZCODE;

!Eingefügt von Max Kalus

!ändert alle "?", "!" und Anführungszeichen in Leerzeichen

   for (x=2:x<2+buffer->1:x++)

      if (buffer->x == '?' or '!' or '"' or 39) buffer->x = ' ';

#ifnot; ! TARGET_GLULX

   for (x = 0: x < (parse-->0 - 1): x++) {

      if (buffer->(parse-->(x*3+3)) == '?' or '!' or '"' or 39)

          buffer->x = ' ';

#endif; ! TARGET_

#endif; ! NO_PUNCTUATION

];```

In der fünftletzten Zeile wird offenbar eine geschweifte Klammer geöffnet, die dann nirgendwo wieder geschlossen wird. Kein Problem, dachte ich mir, und habe diese schon vor einer ganzen Weile einfach entfernt.

Erst jetzt ist mir aufgefallen, dass es im Zusammenhang mit Ausrufezeichen und aktiviertem NO_PUNCTUATION hier wohl einen noch unschöneren Bug gibt: Gibt man an der Eingabezeile des Interpreters ein Ausrufezeichen, gefolgt von einem Leerzeichen und beliebigem Mist ein, verabschiedet sich der Interpreter ohne weitere Meldung ins Datennirvana.

Hat man den SD-Mode aktiviert, kommen immerhin folgende Meldungen:

[** Programming error: tried to read from ->260 in the array "buffer", which has entries 0 up to 259 **]

[** Programming error: tried to read from ->261 in the array "buffer", which has entries 0 up to 259 **]

[** Programming error: tried to read from ->262 in the array "buffer", which has entries 0 up to 259 **]

usw.

Ein Ende findet er nicht, ich hab ihn bis 210000 laufen lassen. Nun vermute ich, dass der Fehler eben in jenen oben zitierten Zeilen der PreProcessGerman liegt. Eine Vermutung deshalb, weil ich insbesondere bei den letzten fünf Zeilen zwar im Groben, aber nicht im Detail verstehe, was da überhaupt vorgeht.

Tja, wenn ihr eine Erklärung oder sogar einen Lösungsvorschlag hättet, wär ich euch sehr dankbar.

Im Glulx-Code oben fallen zwei Sachen auf: Es wird *buffer->(parse-->(x3+3) abgefragt, dann aber buffer->x ein Wert zugewiesen. Und es wird mit einer mir unverständichen Kombination aus buffer, dem Feld für die engegebenen Buchstaben und parse, dem Feld für die Wortanalyse, gearbeitet. Das Entfernen von einzelnen Zeichen läuft allerdings auf Zeichenebene ab, parse** hat da gar nichts zu suchen. (Und wenn Zeichen als Wörter herausgefilter werden, dann sollte man auch auf Wörter ('?//', '!//') testen, nicht auf Zeichen ('?', '!').

(Ich habe in Andrew Plotkins "The Game Author's Guide to Glulx Inform" nichts über die Belegung der beiden Felder gefunden, glaube aber, dass diese relativ analog zum z-Code sind, man muss halt nur die geänderte Wordsize berücksichtigen. parse ist, glaube ich, kein Mischfeld mehr, sondern enthält Dreiergruppen von Wörtern (hab's nicht genau untersucht), buffer jedenfalls enthält ein 4 Byte langes Wort, das die Länge der Eingabe n angibt, danach folgen n Bytes mit den eingegebenen Zeichen.)

Ich habe die german.h einmal analog zur z-Code-Schleife abgeändert:

#ifdef NO_PUNCTUATION;

#ifdef TARGET_ZCODE;

!Eingefügt von Max Kalus

!ändert alle "?", "!" und Anführungszeichen in Leerzeichen

   for (x=2:x<2+buffer->1:x++)

      if (buffer->x == '?' or '!' or '"' or 39) buffer->x = ' ';

#ifnot; ! TARGET_GLULX

   for (x = 0: x < (buffer-->0): x++)

      if (buffer->(x + WORDSIZE) == '?' or '!' or '"' or 39)

          buffer->(x + WORDSIZE) = ' ';

#endif; ! TARGET_

#endif; ! NO_PUNCTUATION

Das hat bei mir geklappt - bitte mal testen, Christoph - und Glulxe nicht mehr abstürzen lassen. (Es war vielmehr ein Aufhängen, so dass ich Glulxe aus dem Task-Manager heraus abschießen musste, und das passierte sogar mit Strict und Debug.)

Außerdem hat informbp die Routinen irgendwas_to_upper und _to_Lower nicht gefunden. (Das habe ich einfach herausgeschmissen, ohne auf die Folgen zu achten. Vermutlich gehen jetzt Gder usw. nicht mehr.)

P.S.: Wie die beiden Felder belegt werden steht natürlich in Roger Firths Inform FAQ.

irgendwas_to_upper usw. kennt er bei mir, da gibts keine Probleme. Was das mit dem parse dort sollte, hat sich mir auch nicht erschlossen, aber wegen der übriggebliebenen geschweiften Klammer gehe ich mal davon aus, dass dort vor einigen Versionen entweder noch mehr oder gänzlich anderer Code stand.

Dein Ersatz funktioniert bei mir absolut einwandfrei, danke! Satzzeichen vor oder hinter Wörtern, am Satzanfang und Satzende, mit wievielen Leerzeichen auch immer getrennt, bei mir hat jetzt alles geklappt.