[Allegro] das "radeberg-syndrom" -> ALL-register

Thomas Berger ThB at Gymel.com
Fr Jan 16 12:54:13 CET 2015


Am 16.01.2015 um 09:36 schrieb Bernhard Eversberg:
> Am 16.01.2015 08:48, schrieb Klaus Lehmann:
>>
>>
>> #-0      Kurzeintragung fuer .STL-Datei zusammensetzen (verbessert)
>> #nr dGR e0    V30.7
>> #uGW dGW e0               tip von thb 15.1.2015, damit die überall geltende
>> anwendervaribale gelöscht wird!
>> #nr dGW e0               tip von thb 15.1.2015, damit die überall geltende
>> anwendervaribale gelöscht wird!
>> #nr dty dtz p"|3" e2 aty e0    Vorbesetzung
>> #uss dss e0      SW-Stammsatz-Sachgr.
>> ...
>> scheint so, daß ein kleiner fehler in der ALL-konstruktion gefunden
>> wurde. und wir haben ihn weg bekommen?!
>> müssen da noch mehr dXX-zeilen rein?
>>
> Soweit es sich um unsere Parameter handelt, nein.

Leider doch. Herr Lehmann hat zwar (so mein Eindruck) ziemlich
im Dunklen gestochert, mit #uGW allerdings einen Volltreffer
gelandet (Demo-Datenbank, all-Index zu "Braunschweig" enthaelt
einen rein britischen Treffer Oxford, Pergamon Press: Satz #807
hat das "Braunschweig" von Satz #806 geerbt). Das Problem hat
noch nicht einmal etwas mit zweistufiger Indexierung zu tun
und laesst sich reprodizieren, wenn man zunaechst Satz #806
aufschlaegt, F7 gibt, und dann mit Satz #807 dasselbe tut...


~Eigentlich~ sieht in der .api ja alles ganz harmlos aus:

ak=uGR"[ /\20]"+z
bzw.
ak=uGR"[ -/\20]"+z

...

  V30.7 Abschnitt f. ALL^, Reg.1 von cat.aex
#-z
#u1 dGW =GW e0
#-{
...
#uGW +{ b"['-/]" =GW
#+#


(und nur hier kommt #uGW ueberhaupt vor). D.h. *wenn* #uGR
belegt ist, dann wird es zerhackt und die Bestandteile sind
bei #-z als #u1 sichtbar, das wird nach #uGW gespeichert,
und allmaehlich aufgegessen. Am Schluss bleibt noch der
letzte Wortbestandteil in #uGW zurueck, aber das sollte nicht
stoeren, immerhin wird es ja stets vorher neu besetzt...

Der Denkfehler dabei ist folgender:
#uGR beginnt oft mit einem Spatium, und dann wird zwar
der Code bei #-z ausgefuehrt, aber #u1 ist leer! In diesem
Fall wird eben nicht #uGW geleert, sondern der alte Inhalt
wird erneut verarbeitet, und das ist dann oft einmal ein
Wortfragment aus einem vorangehenden Datensatz.

Ich habe das nicht weiter ermittelt, ob dieser Grenzfall mit
dem Trennzeichen am Kategorieanfang zu tun hat, generell
auftritt wenn Anfang/Ende/mehrere Trennzeichen direkt beieinander
stehen und ob es sich um eine Spezialitaet von Anwendervariablen
handelt. Vermutlich sollte der Code bei #-z gar nicht aufgerufen
werden in solchen Faellen, aber evtl. ist das schon seit immer
so und massig Anwendungen werden zerbrechen, falls das repariert
wird?

Es laesst sich aber einfach umschiffen, der Abschnitt bei #-z
kann etwas defensiver formuliert werden:

#-z
#nr dGW Z        % Sicher ist sicher
#u1 f"['-/]" F"['-/]" aGW     % Trenner am Anfang und Ende direkt bereinigen
                 % dGW =GW war Pleonasmus,
                 % #u1 =GW e0   benoetigt das e0, ist also auch nicht kuerzer
#-{
...
#uGW +{ dGW b"['-/]" f"['-/]" AGW   %  doppelte Trenner optimieren
                          % Schutz durch y0 ... b0 seit V33 nicht mehr noetig
    % #uGW nach der Schleife nun garantiert leer, das entschlackt den
    % Kategorienspeicher und erspart anderen Abschnitten das Bereinigen vorab
#+#

("/" kommt in allen ak-Konstrukten bereits als "aeusserer" Trenner vor,
ist in den Konstruktionen "['-/]" fuer die inneren Trenner der -{-Schleife
also ueberfluessig, "-" hingegen kommt mal vor und mal nicht...

(/In/ der Schleife wird einiges mit "-" getestet, das deutet darauf hin,
dass "-" noch weiter "innen" gedacht ist als "'" und "/". Wie folgt
umformuliert wird es vielleicht etwas uebersichtlicher:

#-{
!uGW e"['/]" e"_" y2 f"&*$#[(<" F"&]-`'*§)>,.;:?!=" p{ 8 "~e1" }
!uGW e"['/]" e"_" c"-" ,"_-__" y2 f"&*$#[(<" F"&]-`'*§)>,.;:?!=" p{ 8 "~e1" }
!uGW e"['/]" e"_" c"-" e"-" y2 f"&*$#[(<" F"&]-`'*§)>,.;:?!=" p{ 8 "~e1" }
#uGW +{ ...

(e"['/]" e"_" laesst sich dann noch zu e"['/_]" zusammenfassen, Die Behandlung
von "_" hat evtl. mit den Nicht-Verknuepfungen in der Demo-Datenbank zu tun:
Es gab einmal Importparameter, die #31er der Form

#31 Schlagwort_Identnr ; Noch ein Schlagwort_Identnr ; ...

produzierten (vgl. Satz #00 321364236 in der Demo-Datenbank, wobei es sich
da um GBV-PPNs zu handeln scheint). Mich wuerde interessieren, ob dies
auch ausserhalb der Demo-Datenbank eine Form von #31ern ist, die irgendwo
vorkommt.

viele Gruesse
Thomas Berger



Mehr Informationen über die Mailingliste Allegro