AW: [Allegro] Nachladen mit |i3

[Manecke, Mathias]

Lieber Herr Berger,

es funktioniert bestens. Herzlichen Dank!

Mit freundlichen Grüßen
Mathias Manecke

>-----Ursprüngliche Nachricht-----
>Von: allegro-bounces at biblio.tu-bs.de 
>[mailto:allegro-bounces at biblio.tu-bs.de] Im Auftrag von Thomas Berger
>Gesendet: Donnerstag, 4. August 2005 20:02
>An: Allegro-C Diskussionsliste
>Betreff: Re: [Allegro] Nachladen mit |i3
>
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Lieber Herr Manecke, liebe Liste,
>
>> In der Demo-DB wird mit der Konstruktion:
>> 
>>    ***** Es koennten noch selbstaendig gespeicherte Baende 
>da sein: *******
>>          deshalb wird eine Nachladung ueber Index 9 versucht:
>> #00 +#99J e"=" F" " P"+" |92    wenn ja, dann den ersten nachladen
>> ...
>> #-j
>> ...
>> #00 +j e"=" e"" P"+" |93     naechsten Band laden, dasselbe nochmal
>> 
>> eine Auflistung der Bände erzeugt.
>> 
>> Das geht schief, wenn zwischen der Sprungmarke und dem laden des 
>> nächsten Bandes noch ein anderer Nachladebefehl für das gleiche 
>> Register
>> steht:
>
>Bekannt, soweit ich weiss jedoch undokumentiert. Hintergrund 
>ist, dass fuer solche Nachladekonstruktionen wie |i2, |i3 etc. 
>ein sogenannter "Iterator" benoetigt wird, der sich die letzte 
>Position merkt. Und diese Iteratoren gibt es nur global, pro 
>Register 1-11 jeweils einen.
>
>
>> #-j
>> ...
>> #xx p"quatsch" |93
>> #00 +j e"=" e"" P"+" |93     naechsten Band laden, dasselbe nochmal
>> 
>> Sobald #xx eine gültige Kategorie und im aktuellen Satz 
>vorhanden ist, 
>> wird offensichtlich der Zähler von |i3 um eins hochgezählt. 
>Jedenfalls 
>> wird bei einer solchen Konstruktion nur noch jeder zweit Band 
>> angezeigt. Dabei spielt es keine Rolle, ob #nn P"quatsch" einen 
>> gültigen Schlüssel in Index 9 erzeugt oder nicht.
>
>Ob bei "|i3" der Arbeitstext ueberhaupt eine Rolle spielt, ist 
>eine Frage, der ich noch nie nachgegangen bin.
>
>> Ich hatte angenommen, dass |im nur wirkt, wenn in i ein dem 
>> Arbeitstext und der Bedeutung von m entsprechender Schlüssel 
>> existiert.
>
>Das waere die Variante, dass der Arbeitstext jeweils einen 
>individuellen Iterator definiert. Sehr interessante Loesung 
>des Problems und ausserdem eine Antwort auf die obige Frage. 
>Aber leider nicht bei allegro. 640kB sind bekanntlich genug!
>
>
>> Was das eigentliche Nachladen angeht, stimmt das ja auch. 
>Was aber das 
>> Zählen der Nachladeversuche angeht, offensichtlich nicht. 
>Ist das so, 
>> oder habe ich irgendwo einen Denkfehler? Wenn dem so ist, 
>ist es also 
>> unmöglich, alternative Schlüssel für eine Nachladung mit |i3 
>> abzufragen?
>
>Seit ca. Version 15 gluecklicherweise nicht mehr: Man kann den 
>aktuellen Indexeintrag zwischenspeichern und mit ">" und |92 
>an derselben Stelle aufsetzen, vorausgesetzt, die 
>Indexeintraege haben nie mehr als einen Treffer. Unumgaenglich 
>ist das z.B. in der rekursiven Situation, wo man einen 
>Registerbereich mit Exemplarsaetzen durchlaeuft und pro 
>gefundenen Satz auf den zugehoerigen Bestellsatz ueber einen 
>Schluessel im gleichen Register zugreifen muss.
>
>Ihr Fall ist gluecklicherweise einfacher gelagert:
>
>
>> Hintergrund meiner Frage:
>> Ich verwende für die Bandverknüpfung alternativ die #00 und 
>die Pica-Produktionsnummer, die bei uns in #89P gespeichert ist:
>> 
>> #00 +#99J e"[=]" F" " P"+" |92     % wenn B"nde vorhanden, 
>ersten nachladen
>> #89P +#99J e"[=]" F" " y2 p"ppn" P"+" |92    
>> ...
>> #-j
>> ...
>> #89P +j e"[=]" F" " y2 p"ppn" P"+" |93     
>> #00 +j e"[=]" F" " P"+" |93     % naechsten Band laden, 
>dasselbe nochmal
>> 
>> Das geht immer dann schief, wenn #89P vorhanden ist, aber mit #00 
>> verknüpft wurde.
>
>Wenn Sie eine zweite Sprungmarke spendieren, koennen Sie sogar 
>den Fall abdecken, dass teils ueber #00 und teils ueber #89P 
>verknuepft wurde (allerdings wird keine sinnvolle Reihenfolge 
>hergestellt, dafuer muesste man ziemlich tricksen: nach der 
>Anzeige jeden Bandes erst die Zaehlungen der jeweils naechsten 
>Kandidaten aller Identnummerkandidaten ermitteln und 
>miteinander vergleichen: Dann geht der Iterator stets kaputt 
>und man muss mit der oben angedeuteten Methode vorgehen)
>
>Die folgende Skizze ist etwas komplizierter, denn man koennte 
>ja ganz einfach auch #00 |92 #-j #00 +j |93
>
>#89P |92
>#-k
>#89P +j |93
>
>veranstalten, was nicht sonderlich erhellend ist.
>
>
>#nr dpk Z
>#00 P"|" Apk    % Identnummernkandidaten einsammeln
>#89P y2 p"ppn" P"|" Apk
>...
>#-k       % aeussere Schleife ueber alle Identnummernkandidaten
>#upk +j e"|" e"=" F32 P"+" |92
>#nr +#99k Z
>
>#-j       % innere Schleife ueber alle Baende zu einem Schluessel
>...
>#<        % rueckstapeln nicht vergessen
>#upk +j e"|" e"=" F32 P"+" |93
>
>#99k      % naechster Identnummernkandidat
>#upk +k y0 dpk b"|" F"|" b0 Apk
>
>Alternativ geht es auch mit einer Sprungmarke plus einem 
>Unterprogramm...
>
>
>viele Gruesse
>Thomas Berger
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.3-nr1 (Windows XP)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFC8lgZENVh3bB0lwMRAqntAKC2zUbX1OXFswIirwPVT4mCENtk4wCeNC6f
>9U/jYXHR5A3hdFQOf2BR/i8=
>=8RO3
>-----END PGP SIGNATURE-----
>