[Allegro] acon : weitere Einsichten

[Thomas Berger]

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

Lieber Herr Eversberg,


>> Es ist komischerweise an der Demo-Datenbank nicht reproduzierbar,
>> an anderen kommt der Crash stets nach 924 Saetzen in der Ausgabedatei,
>> egal was ich durchsuche...
>>
> Dies konnte eindeutig dem Vorhandensein undeklarierter Kategorien
> zugeordnet werden. (#10 und #M0)

Hm.

Jedenfalls liefern Exporte mit i-1.apr nun identische Ergebnisse.

(in srch.job steht noch "set L 0" statt "set Z 0").

Export (durch "otto" selektierter Saetze) mittels i-1 bringt bei
einer grossen Datenbank folgende Laufzeiten:

srch -f4 (muss ja v14-expandieren): 70 Minuten
acon mit srch.job:                  52 Minuten

Export ohne Suchbegriff nach NUL:
srch -f6 (muss nicht v14-expandieren): 85 Minuten
acon mit srch.job:                     56 Minuten

Umgekehrter Fall Export kleine Datei mit vielen expliziten Nachladungen
(ca 50:1), keine v14-Ersetzungen (das neulich beschriebene Verhalten
betrifft nur die Grunddatei, nachgeladene Saetze hingegen werden in
angemessen grossen Portionen eingelesen):

srch -f6 (muss nicht v14-expandieren): 22,5 Minuten
acon mit srch.job:                     14 Minuten
a99 (Download der entspr. Erg.-Menge): 13 Minuten

[Insbesondere identische Ergebnisse bei srch und acon, d.h. mein
Ausgangsproblem ist endlich geregelt. Danke.]

> Das Grundproblem ist jetzt noch dieses: acon öffnet zuerst die
> Datenbank, die im srch.job auf der @-Zeile angegeben ist.
> Dort ist aber im Standard keine angegeben! Dann öffnet es die
> Demo-Datenbank, die in avanti.con unter [avdemo] angegeben ist.

C:\allegro habe ich wohlweislich auf keinem meiner Rechner.

Allerdings habe ich auch in der "Herkunftsdatenbank" meines Problems
jetzt eine Standard-avanti.con im Programmverzeichnis entdeckt.

Ich bekam aber beim mixen durchaus die "ueblichen" Fehlermeldungen zu
in den Parametern genutzten und in der CFG nicht deklarierten
Kategorien und konnte die durch Aenderung in der (einzigen ueberhaupt
findbaren, zutreffenden) .CFG beheben.


> Man trägt folglich darunter die eigene Datenbank ein, dann
> klappt alles. Denn nur dann werden die CFG und die Parameter vom
> richtigen Verzeichnis geholt.

Das Problem scheint viel fundamentaler: avanti.con sollte - wie
der Name schon sagt - primaer eine Konfigurationsdatei fuer avanti
sein und nicht fuer acon (Konsequenterweise haben die acon-Jobs srch.job
und update.job auch keine Zeilen "@..." und "&..."). Man koennte
ueberlegen, dass acon mittels eines Schalters -A (Alias) den symbolischen
Namen uebergeben bekommt und in diesem Fall Werte fuer -b, den Namen
der Logdatei und -a? aus der Konfigurationsdatei zieht. Der Normalfall sollte
aber sein, avanti.con nicht zu beruecksichtigen.

Und das mal dahingestellt - die Schalter auf der Kommandozeile sollten
stets Vorrang haben!


> Eine richtig gute Lösung ist das natürlich (?) nicht. Man wünscht
> sich, daß man -d und -k wie bei srch angeben kann und acon
> dann Bescheid weiß. Um diese Sache müssen wir uns jetzt noch

- -k funktioniert zumindest dann, wenn die im Abschnitt [avdemo] der
avanti.con angegebene Datenbank nicht existiert.

Beim Durchsuchen von .ald-Dateien muss man zusaetzlich -b angeben,
selbst wenn es .ald-Dateien im Kontext "ihrer" Datenbank sind.
Das ist ein Unterschied zu SRCH, das /waere/ behebbar durch zusaetzliche
Magie in acon (fehlt -b, dann -d untersuchen), die Kompatiblitaet ist
aber auch durchbrochen beim fuehrenden "*" an -d, wenn mehrere
Dateien durchsucht werden sollen.



> kümmern. Z.B. einen Befehl einbauen, mit dem man das Datenverzeichnis
> und die Konfig wechseln kann, im laufenden FLEX.
> 
> acon wurde nochmals erneuert, aber das Grundproblem bleibt noch.

Ich sehe noch folgende Grundprobleme (bei acon als SRCH-Ersatz):

* Es muss einen Schalter geben, der v14-Expansion /fuer die Suche/
  steuert. Wie die dann ausgefuehrt wird, ist mir nicht klar:
  a99: export R und/oder export V
  acon: set a und/oder export V
  wirken nur auf write's und zerstoeren den Satz (ich will aber erst
  Testen, dann exportieren und mir den Umstand mit obj1/obj2 ersparen
  (und wuesste auch nicht, wohin mit dem Resultat von "write")

  Ich stelle mir vor, die M-Befehle zu "var" so erweitert werden koennten,
  auf den aktuellen iV-Inhalt diese Operationen anzuwenden. Oder ein
  zusaetzlicher Parameter fuer "copy obj": Die Expansionen sind ein Grenzfall,
  auf einen Datensatz angewandt ergeben sie einen Datensatz, man *will* sie
  bloss nicht speichern.

  Konzeptionell eine Erweiterung waere eine Vorbehandlung mittels einer
  Parameterdatei: Eine Modifikation von "export", so dass das Resultat
  in der iV oder im Object 2 landet und nicht in einer Datei...


* srch.job und update.job sollten mittels "switch download" so umgestrickt
  werden, dass parallele Ausgabe (etwa Fortschrittsbericht, Warnungen etc)
  nach STDOUT moeglich ist. M.E. zu klaeren waere aber zunaechst, was die
  Standard-Ausgaben sind (STDOUT und STDERR?), was Avanti damit macht
  (erwartet STDOUT, was passiert mit STDERR) und ob sich STDOUT und/oder
  STDERR ueber open x irgendwie auch nachtraeglich wieder oeffnen lassen.

viele Grusse
Thomas Berger








-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBSxfB3WITJZieluOzAQKBigP9FYxgv4e/w83fZ3uWxAAbv6DOxeFrZlfu
+NjDcWGtgAnYc+1z79UoMq2gLXdlOAIfJE4klVqCP7Qls6NCptz4fh9JtGtM8fZZ
gRL10iqQiFcPq5xaTQLW4QuSmAdIs1pqnV/at73mhbWpSlYA/MEZrW+6Zro8RK1r
jtLjvUe+/O8=
=WAlL
-----END PGP SIGNATURE-----