[Allegro] acon und srch.job im SVN erneuert

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg,

> Ja, bei den Befehlen "var" und "write" ist die Erkennung des
> Befehlstrenners ; leider unzuverlässig. Weiß nicht warum, sonst hätte
> ich's schon behoben.

dafuer manchmal umso "zuverlaessiger", s.u.

Ich versuche momentan srch.job so zu optimieren, dass geloeschte
Saetze fruehzeitig als solche erkannt und uebersprungen werden.
Derzeit wird der Satz ja in die iV gelesen, mit "ins" in einen
neuen Datensatz verwandelt, dann dessen #u1 in die iV gehoben und
auf den Anfangsstring "@@@@@" getestet.

Meine Beobachtungen:

fetch b
und
fetch b4

funktionieren nicht.

"fetch rec" bringt folgenden String in die iV:

#u1    @@@@@;#00 b35....

d.h. es wird der unguenstige Trenner ";" eingesetzt, der dann wieder
zusaetzliche Magie bei ";#" erzwingt. Das Padding mit vielen Spatien
vor "@@@@" liegt daran, dass acon nicht darueber nachdenken mag, wo
der Kategorieanfang im jeweiligen Schema ist?

Jedenfalls ist zu testen, ob #u1 die erste Kategorieaehnliche Konstruktion
in der iV ist und darin dann der erste nicht-Blank- Inhalt "@@@@@":

1. Versuch: drei Zeichen ueberspringen, Spatien eliminieren, testen:

if "#u1 " var (3,0 f" ");if "@@@@@" ...
  funktioniert nicht


2. Versuch: Test auf "@@@@@" irgendwo am Feldende (nicht sehr sauber):

if "#u1 " if %@@@@@;#% Write "test2" newline

grotesk:
J:<E111> #% Write "test2" newline fehlerhaft


3. Versuch: "u1" ueberspringen, Spatien eliminieren, testen:

if "#u1 " var (b"u1 " f" ");if "@@@@@" ...
  funktioniert!


4. Versuch: beim ersten Kategorieende ";#" abschneiden, test auf "@@@@@"
   irgendwo:

if "#u1 " var (e";#");if %@@@@@% ...
   funktioniert



Kann denn uebrigens nicht bei "fetch rec" die Form in der iV entstehen, wie
sie auch nach "ins" und "var kn" erreicht wird, also .adt-Format mit ^J
als Trenner zwischen (Roh-)Kategorien: Das wuerde alles einheitlicher machen
und auch die oft diskutierte Spezialbehandlung von ";#" vermeiden helfen.


Desweiteren: Bereits "fetch rec" belegt den CString iR (interne Satznummer),
obwohl man ja noch keinen Datensatz hat, das ist prima (irgendwie muss man
ja rankommen).
Bei .alg-Dateien ist iR konstant Satznr. 18495496, hier sollte besser
mitgezaehlt werden (oder auf 0 gesetzt).

In vom Job ausgeloesten Exporten ist allerdings #nr in allen Faellen
konstant "0", hier scheint also die Initialisierung aus der acon bekannten
internen Satznummer nicht zu funktionieren.


viele Gruesse
Thomas Berger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iJwEAQECAAYFAkwXVi4ACgkQYhMlmJ6W47OixQQApBAW98P4ERlqTBgJNH1Y1IpS
73MWjVzz3CsQUZe7wJWA6HeNpEV8Lyjy7HSABYYj4zQObSIUP4LQTWHamD1UUR1O
/KyLmVLBAIXyBtjYBdXmM2ehStAF816ydTCMr9IMQM2MlxircM2QPW85yqadtMYm
NWz4kKjNwScTr8wthbc=
=diWT
-----END PGP SIGNATURE-----