if-de :: Forum Foren-Übersicht
Autor Nachricht
<  Indexed Text in Text wandeln
proc
BeitragVerfasst am: Do, 16 Aug 2012 - 0:02  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 08.12.2009
Beiträge: 881
Wohnort: Berlin

Kleine Frage an die Superfreaks aus der finalen Verzweiflung heraus: Ich habs bis heute nicht rausgekriegt, wie man in I7 erzeugten Indexed Text in reinen ZSCII-Text wandeln kann, selbst wenn die out-of-ZSCII-UTF8-Zeichen keine Rolle spielen und beispielsweise durch ein '?' ersetzt werden könnten. Es geht einfach nur darum, komplexe Concat- und Regex-Operationen in I7 durchzuführen (weil es so schön einfach ist) und das Ergebnis als trivialen Textstring in I6 zu verarbeiten. An der undokumentierten IT_GetBlob-Funktion bin ich bereits verzweifelt und heute bin ich zufällig auf die Eingangspassage in der I7-Doku 19.7. gestoßen, dass die "Rückwärtskonvertierung" prinzipiell nicht möglich sein soll. Das kann doch alles nicht wahr sein! Hat sich da schon jemand daran versucht? Ich gebe nach einem halben Jahr auf. Und weiß jemand, weshalb die IT_GetBlob-Funktion nicht dokumentiert ist? Das hat mich nun wirklich unter dem Strich ergebnislos mehrere Tage beschäftigt. BIN VERZWEIFELT!!!
_________________
interactive fiction database
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
ChristianB
BeitragVerfasst am: Do, 16 Aug 2012 - 0:25  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 05.05.2004
Beiträge: 633
Wohnort: Hamburg

proc hat folgendes geschrieben:
Das kann doch alles nicht wahr sein!

Ist es aber.

Indexed text ist in I6 ein indiziertes Array. Der "triviale" Textstring ist konstant und kann nicht verändert werden, eben auch nicht durch ein (nachträglich geändertes) Array ausgetauscht werden. Ich fürchte, Du musst in I6 mit dem Array weiterarbeiten. Was hast Du denn mit dem Textstring vor? Einfach nur ausgeben? Das geht natürlich auch mit dem Array.

Und was bitte ist IT_GetBlob?
_________________
Worichtung willst du ingehen?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
proc
BeitragVerfasst am: Do, 16 Aug 2012 - 0:43  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 08.12.2009
Beiträge: 881
Wohnort: Berlin

ChristianB hat folgendes geschrieben:
Indexed text ist in I6 ein indiziertes Array.

Nicht wirklich, hab ich schon mehrfach durch und in der I7-Doku 19.7 ist die Rede von "specially compacted, read-only form: it's really part of the program, not part of the data". Das muss auch so sein, da im Indexed Textstring Pointer auf Operationen eingebaut sein müssten. Es fehlt einfach nur die Dokumentation, was ich für richtig daneben halte. Das wäre doch mal ein Ansatzpunkt für einen Guru-Wettbewerb "Ersinne eine Funktion, die Indexed Text in Text wandelt":
Code:
To decide what text is (txt - indexed text): blah.

Ich hab's nicht hingekriegt. Es geht übrigens um Verbflexionen und die Möglichkeit, auf einer Makrosprachenebene Grammatik handzuhaben.
_________________
interactive fiction database
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
proc
BeitragVerfasst am: Do, 16 Aug 2012 - 1:27  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 08.12.2009
Beiträge: 881
Wohnort: Berlin

ChristianB hat folgendes geschrieben:
Und was bitte ist IT_GetBlob?

Oops, ganz vergessen: I6-Handhabung von Indexed Text
http://inform7.com/sources/src/stdrules/Woven/A-sr5.pdf
Steht aber alles auch schon in Standard Rules von Graham Nelson, Doku kann man das nicht nennen.
_________________
interactive fiction database
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
ChristianB
BeitragVerfasst am: Fr, 17 Aug 2012 - 21:36  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 05.05.2004
Beiträge: 633
Wohnort: Hamburg

proc hat folgendes geschrieben:
Das wäre doch mal ein Ansatzpunkt für einen Guru-Wettbewerb "Ersinne eine Funktion, die Indexed Text in Text wandelt": ...

Wer diesen Wettbewerb gewinnt, müsste die Z-Maschine neu erfinden, denke ich. Texte sind -- wie Vokabeln auch -- nach dem Compilieren des Quelltextes in ihre Speicherbereiche gepfercht. Man kann (statischen) Texte auslesen, aber nicht verändern. Oder doch? Dann hätten wir ja auch die Möglichkeit, ein dynamisches Wörterbuch realisieren. Aber ich fürchte, das ist, zumindest auf direktem Wege, nicht möglich.
_________________
Worichtung willst du ingehen?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
proc
BeitragVerfasst am: So, 19 Aug 2012 - 1:43  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 08.12.2009
Beiträge: 881
Wohnort: Berlin

Mit Text Capture by Eric Eve ließe sich einiges machen, aber das ist schon ziemlich gemurxt. Mein Ergebnis ist jedenfalls: Es geht nicht wirklich und Grammatik müsste I7 beigebracht werden und nicht I6. Das wirft wieder die Frage auf, weshalb Language.i6t? Das Ding kann doch komplett rausfallen und die Library Messages können über eine simple Tabelle gehandhabt werden. Es ist praktisch unmöglich, auf andere Weise auf die Library Messages zuzugreifen und ich sehe auch keine Performance- oder Speichervorteile durch Language.i6t, zumal Nelson in Section SR5/8/2 - Message support - der Standárd Rules ohnehin ein Einfallstor dafür vorgesehen hat. Ich plädiere dafür, GerX3 dahingehend zu überarbeiten und besser German Default Messages by Team GerX als Standard zu vewenden. Es ist ziemlich ätzend, in Grammatikfragen zweihundert Fallungscheidungen treffen zu müssen obwohl ein "[Du] [musst] ein Hauptwort angeben[*]" für alle Eventualitäten ausreichen würde.
_________________
interactive fiction database
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
ChristianB
BeitragVerfasst am: Mo, 20 Aug 2012 - 10:52  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 05.05.2004
Beiträge: 633
Wohnort: Hamburg

proc hat folgendes geschrieben:
Es geht nicht wirklich und Grammatik müsste I7 beigebracht werden und nicht I6.

Grammatik wird demnächst, d.h. in GerX 4, durch eine dritte Sprache, die auch schon einen Namen hat, formuliert -- so ist zumindest der Stand der Dinge. Deshalb werde ich als GerX-Bibliothekar keine Arbeit in diese Baustelle investieren.
_________________
Worichtung willst du ingehen?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
proc
BeitragVerfasst am: Di, 21 Aug 2012 - 0:00  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 08.12.2009
Beiträge: 881
Wohnort: Berlin

ChristianB hat folgendes geschrieben:
Grammatik wird demnächst, d.h. in GerX 4, durch eine dritte Sprache, die auch schon einen Namen hat, formuliert -- so ist zumindest der Stand der Dinge. Deshalb werde ich als GerX-Bibliothekar keine Arbeit in diese Baustelle investieren.

Danke für die Info, alles super mit Default Messages by Team GerX das auch einige I6-Probleme mit Messages löst, die nicht aus Language.i6t stammen. Mir sind keine Widrigkeiten durch die Nutzung von I7-Messages aufgefallen, einzig der Speicherbedarf von Indexed Text-Tabellen fällt negativ auf. Die Halbwertszeit einer Baustelle liegt in Berlin übrigens bei über einem Jahr...
_________________
interactive fiction database
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Martin
BeitragVerfasst am: Sa, 24 Nov 2012 - 11:12  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München

Ich verstehe nicht, wozu du diese Rückwärtskonvertierung benötigst. So ziemlich das Einzige, was man mit normalen Texten machen kann, ist, sie auszugeben. Und das kann man mit Indexed Texts doch auch prima machen. Die Büchse mit den Dingen, die das Arbeiten mit Indexed Texts kompliziert machen - mögliche Speicherüberläufe, zusätzlicher Speicherplatz - hast Du ja schon aufgemacht. Das würde auch eine Rückkonvertierung nicht wieder zurückstopfen können. Außerdem wüdest du noch mehr Speicherplatz für die Darstellung der normalen Texte (außerhalb des statischen Speichers) benötigen.

Dass man mit den Indexed Texts selbst bei Kleinstbeispielen schon z8 benötigt, ist mir auch schon aufgefallen. Ich denke, dass die RegExes zusätzlich ganz gut was reinholen.

Ich habe außerdem so ein wenig das Gefühl, dass du dich da in etwas verrennst, das man vielleicht anders besser lösen könnte. (Nur so ein Gefühl, ich kenne die genaue Aufgabenstellung nicht. Aber das obligatorische Zitat von Jamie Zawinsky rollt schon hinten in meinem Kopf herum.)

proc hat folgendes geschrieben:
Das wäre doch mal ein Ansatzpunkt für einen Guru-Wettbewerb "Ersinne eine Funktion, die Indexed Text in Text wandelt": ...


Oh, das kann man eigentlich ganz leicht machen:
Code:

Array tbuf buffer "Piece of cake!";
Array tstr -> 200;

[ main;
    buf2str(tbuf, tstr, 200);

    print (address) tstr;
    new_line;
];

Die Funktion buf2str wandelt den Textpuffer in eine interne
Das ist relativ leicht, der Code dazu, der Abschnitt 3 des Z-Maschinen-Standards nachprogrammiert, steht unten und ist noch nicht einmal besonders kompliziert.

Aber - er löst Dein Problem nicht. Man hat nun eine Z-Maschinen-Darstellung des Buffers (I6 für Indexed Text), die der Codierung entspricht, mit der intern Strings (I6 für Text) abgelegt werden. Man kann diese Darstellung auch per (address) ausgeben lassen.

Aber halt nicht per (string). Eigentlich, das dachte ich zumindest, ist der einzige Unterschied zwischen (string) und (address) beziehungsweise zwischen @print_paddr und @print_addr, dass man beim einen die Adresse als packed address, beim anderen als tatsächliche Adresse angibt. Es gibt da aber noch mehr Tücken.

Die Adresse von tstr im Beispiel ist nicht unbedingt als packed address darstellbar. Das kann man reparieren, indem man eine lokale Variable auf die erste gültige packed address, die durch den packing factor 4 oder 8 teilbar sein muss, im Array zeigen lässt. Aber selbst dann meckert der Strict Mode, dass die Rückkonvertierung kein gültiger String ist, weil er halt nicht in dem Speicherbereich liegt, in dem die vom Compiler erzegten statischen Strings liegen. (Mit -~S funktioniert's aber.)

Aus dem selben Grund ist
Code:
metaclass(tstr) ~= Object

- zur Klassifizierung der I6-Objekte werden auch die Speicherbereiche zur Klassifizierung herangezogen.

Christian hat folgendes geschrieben:
Dann hätten wir ja auch die Möglichkeit, ein dynamisches Wörterbuch realisieren.

Oh, diese Möglichkeit besteht schon lange. Die Platypus-Lib hat sie benutzt, um dem Autoren die Möglichkeit zu geben, eigene Vokabeln zu erzeugen.

Ab der Version 5 der Z-Maschine kann man dem Op-Code @tokenise zwei zusätzliche Parameter übergeben. Der erste Zusatzparameter gibt die Adresse eines Dictionary an, das zum Parsen verwendet werden soll. Dieses Dictionary muss dasselbe Format wie das Haupt-Dictionary haben, grob gesprochen:

  • 1 Byte: Anzahl der word separators, n
  • n Bytes: ZSCII-Codes der word separators
  • 1 Byte: Länge eines Eintrags in Bytes, mindestens 6
  • 1 Word: Anzahl der Einträge N
  • N Einträge
Man kann hier eigentlich all das verändern, worauf man bei Inform keinen Einfluss hat: Man kann außer Punkt, Komma und Gänsefüßchen weitere Wortbegrenzer definieren (1), man kann die festgelegte Eintragslänge von 9 Bytes ändern (2) und man kann die Anzahl der Einträge während des Spiels ändern. Man kann sogar zulassen, dass das Wörterbuch nicht wie das Hauptwörterbuch alphabetisch geordnet sein muss, damit man sich um die Sortierung nicht kümmern muss.

Der zweite Zusatzparameter von @tokenise ist eine Flagge, die angibt, ob die Wörter regulär untersucht werden oder ob nur nicht bereits gefundene Wörter aufgefüllt werden sollen, so dass man nach und nach alle Dictionaries über den Input drüberlaufen lassen kann.

Und man muss gar nicht die Klimmzüge machen, eine eigene Kodierung zu implementieren: Es gibt einen Opcode @encode_text, der - Tada! - ZSCII-Zeichen im Speicher in z-Maschinen-codierte Strings umwandelt. Allerdings funktioniert dieser Opcode nur für Vokabeln. Und er macht natürlich auch keinen String aus dem ZSCII-Puffer.

(1) Das Leerzeichen ist immer implizit dabei.
(2) Das heißt aber nicht, dass man die Aufösung der Vokabeln verbessern könnte, die auf 9 Zeichen in 6 Bytes festgelegt ist.

P.S.: Hier wie versprochen der Code. Ein Kleinstbeispiel für ein eigenes Dictionary gibt es auch.

Code:

Array alphabet -> 256;

Array default_atable ->
 $61 $62 $63 $64 $65 $66 $67 $68 $69
 $6a $6b $6c $6d $6e $6f $70 $71 $72
 $73 $74 $75 $76 $77 $78 $79 $7a
 $41 $42 $43 $44 $45 $46 $47 $48 $49
 $4a $4b $4c $4d $4e $4f $50 $51 $52
 $53 $54 $55 $56 $57 $58 $59 $5a
 $20 $5e $30 $31 $32 $33 $34 $35 $36
 $37 $38 $39 $2e $2c $21 $3f $5f $23
 $27 $22 $2f $5c $2d $3a $28 $29;

Global atable;

[ atable_init
    i;
   
    atable = default_atable;
    if ($34-->0) atable = $34-->0;
   
    i = 256; while (i--) alphabet->i = -1;
    i = 78; while (i--) alphabet->(atable->i) = i;
];

[ str_encode c str pos
    m n;
   
    m = (2 - pos % 3) * 5;
    n = pos / 3;
   
    if (m == 2) str-->n = 0;
   
    @log_shift c m -> c;
    str-->n = str-->n | c;
];

[ buf2str
    buf             ! buffer with length in buf-->0
    str             ! word buffer for string
    size            ! max number of words in string
    pad             ! pad string to pad zchars, mainly for dict words
   
    i l n c a;
   
    if (atable == 0) atable_init();
    while (size % 3) size++;
    if (pad > size) pad = size;
   
    l = size / 3 * 2;
    @copy_table str 0 l;
   
    l = buf-->0 + 2;
    for (i = 2 : i < l : i++) {
        c = buf->i;
        a = alphabet->c;
       
        if (c == $20) {
            str_encode(0, str, n++);
        } else if (a < 0) {
            str_encode(5, str, n++);
            if (n == size) break;
            str_encode(6, str, n++);
            if (n == size) break;
            str_encode(c / 32, str, n++);
            if (n == size) break;
            str_encode(c % 32, str, n++);
        } else {
            if (a >= 26) {
                str_encode(3 + a/26, str, n++);
                if (n == size) break;
            }
            str_encode(6 + a%26, str, n++);
        }
        if (n == size) break;
    }
    while (n % 3 || n < pad) str_encode(5, str, n++);
   
    a = n / 3 - 1;
    str-->a = str-->a | $8000;
   
    return n;
];

_________________
Every silver lining has a cloud.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
ChristianB
BeitragVerfasst am: So, 25 Nov 2012 - 0:45  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 05.05.2004
Beiträge: 633
Wohnort: Hamburg

Martin hat folgendes geschrieben:
Oh, diese Möglichkeit besteht schon lange. Die Platypus-Lib hat sie benutzt, um dem Autoren die Möglichkeit zu geben, eigene Vokabeln zu erzeugen.

Das muss ich mir unbedingt mal näher ansehen! Danke, Martin, für die interessanten Ausführungen!
_________________
Worichtung willst du ingehen?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
proc
BeitragVerfasst am: Mo, 26 Nov 2012 - 15:22  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 08.12.2009
Beiträge: 881
Wohnort: Berlin

Martin hat folgendes geschrieben:
Ich verstehe nicht, wozu du diese Rückwärtskonvertierung benötigst.

Die Idee war, verschiedene Erzählzeiten zuzulassen, die dann beim Umswitchen korrekt rüberkommen. Die I7-Stringkommandos auf Indexed Text sind einfach zu verlockend als alles gleich in I6 zu lösen, und die Schnittstelle ist eine Einbahnstraße. Das hat sich insofern erledigt als alles auch komplett und unter Missachtung der Speicherökonomie in I7 handhabbar ist. IT im Buffer abzufangen und dann weiterzuverarbeiten erschien mir etwas zu murksig und es hätte sein können, dass ein Guru da schon eine elegante Lösung gefunden hat.

Martin hat folgendes geschrieben:
proc hat folgendes geschrieben:
Das wäre doch mal ein Ansatzpunkt für einen Guru-Wettbewerb "Ersinne eine Funktion, die Indexed Text in Text wandelt": ...

Oh, das kann man eigentlich ganz leicht machen:

Und ohne Buffermanipulation, mit Mitteln aus IndexedText.i6t :o?

Martin hat folgendes geschrieben:
Dass man mit den Indexed Texts selbst bei Kleinstbeispielen schon z8 benötigt, ist mir auch schon aufgefallen. Ich denke, dass die RegExes zusätzlich ganz gut was reinholen.

Für jeden Indexed Text, und sei es auch nur ein "[line break]", werden ein paar KB (> 512 * WORDSIZE, also > 2KB in Glulx) angelegt und dabei erstmal mit Nullbytes gefüllt, die nach hinten zumeist dann auch übribleiben. Ich hab das mal spaßhalber auf der Spring Thing "durchgemessen": "The Lost Islands of Alabaz" (3,6 MB) besteht aus 1,118 MB (30%) aus Folgen von 256 oder mehr Nullbytes...
_________________
interactive fiction database
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Martin
BeitragVerfasst am: Mo, 26 Nov 2012 - 15:38  Antworten mit Zitat
Experte
Experte


Anmeldungsdatum: 25.08.2002
Beiträge: 677
Wohnort: München

proc hat folgendes geschrieben:
Und ohne Buffermanipulation, mit Mitteln aus IndexedText.i6t :o?

Real gurus don't use I7. ;-)

Text on the fly zu codieren, ist leicht, aber etwas nutzlos, wenn ich statt Konvertierung und print (address) auch gleich eine Routine zum Schreiben des Puffers, also des indexed texts, benutzen kann und dazu keinen zweiten Hilfspuffer benötige.

proc hat folgendes geschrieben:
Ich hab das mal spaßhalber auf der Spring Thing "durchgemessen": "The Lost Islands of Alabaz" (3,6 MB) besteht aus 1,118 MB (30%) aus Folgen von 256 oder mehr Nullbytes...

Das verstehe ich allerdings nicht. Glulx hat doch die schöne Eigenschaft, dass die Dateigröße im Glulxe-Speicher mit Null-Einträgen aufgeblasen werden kann. Wenn die physikalische Datei 1MB groß ist und im Header aber steht, dass sie 2MB groß sein soll, stehen dem Autoren tatsächlich alle 2MB zur Verfügung. Sie sind halt von 1MB bis 2MB mit Nullen initialisiert.

So umgeht man ja das Problem der Z-Maschine, dass alle Felder Speicherbereiche in der Spieldatei sein müssen. Ist aber offenbar nicht so gelöst.
_________________
Every silver lining has a cloud.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
Beiträge der letzten Zeit anzeigen:   
Alle Zeiten sind GMT + 1 Stunde (MEZ)

Nächstes Thema anzeigen
Vorheriges Thema anzeigen
Seite 1 von 1
if-de :: Forum Foren-Übersicht  >  Inform & Glulx

Neues Thema eröffnen   Neue Antwort erstellen


 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.



Kontakt: Administrator

Powered by phpBB and NoseBleed v1.05