[Allegro] A99-Exportskripte

[Bernhard Eversberg]

Am 15.07.2011 10:50, schrieb Fischer, Thomas:
>
>  ich bin dabei, für meine Datenbanken ein XML-Exportformat für solr zu
>  schreiben. Wie üblich bei neuen Projekten wird man da massiv mit den
>  Eigenheiten von Allegro konfrontiert.
>
>  1. Das zentrale Problem ist, dass (im Gegensatz zu allen anderen mir
>  bekannten Skriptsprachen) syntaktische Fehler (z.B. Tippfehler) nicht
>  zu einem Abbruch des Skriptes (möglichst mit Fehlermeldung) führen,
>  sondern mit schwer vorhersehbaren (und damit umgekehrt schwer
>  analysierbaren) Ergebnissen durchlaufen. Beispiele: ##ufk statt #ufk;
>  v2.9 statt v2,9; #) statt #)L.
>
Dies ist der Effizienz geschuldet. Grundsätzlich was dran zu ändern
oder es gar gänzlich abzustellen, wäre in der Hinsicht eher kontraproduktiv.
Konkrete einzelne Verbesserungen wären natürlich denkbar.
Immerhin sind die Quellen nun offen, es handelt sich um die Module
exet.cpp  : Abarbeitung der Parameter (Anwendung auf aktuellen Satz)
exet2.cpp : Einlesen der Parameter, Überführung in interne Form
              (Zusätzliche Erkennung von Fehlern wäre hier anzusiedeln)
exet3.cpp : einige Hilfsroutinen
im Paket ac15.
Schwer verdaulich, zugegeben, obwohl mit einigem Kommentar versehen.
Diesbezügliche Fragen beantworten wir gerne.


>  2. Damit zusammenhängend ist das Debugging der Exportskripte extrem
>  zeitaufwändig, es gibt auch keine Unterstützung wie z.B. ein
>  zeilenweises Durcharbeiten des Skriptes.
>
Das hat dieselben Gründe. Die interne Form eignet sich z.B. nicht, um
als Fehlerhinweis angezeigt zu werden.

>  3. Die Exportsprache ist durch ihre GOTO-Konstrukten extrem
>  fehleranfällig (bzw. fehlertolerant, siehe 1): - Sprünge nach +b oder
>  +#30 springen auch aus Unterprogrammen heraus - Sprünge nach +#30 und
>  Unterprogrammaufrufe (!) springen nur nach folgenden (dann aber
>  beliebigen) Marken. - "Unterprogramme" sind nur Paare von
>  Sprungmarken
>
Ja, alles aus heutiger Sicht eher primitiv. Aber schnell.

>  4. Ersetzung funktioniert bei ersten vier Buchstaben nicht, daher
>  #uLa p'XXXX' ,", ,_," y1 b4 dLa =La
>
Ja, weil der Feldanfang ja normalerweise die Kategorienummer ist und
diese i.d.R. nicht betroffen sein soll. Der Trick umgeht dies.

>  5. Ich habe das schon früher moniert und noch immer nicht begriffen:
>  In meiner Exportparameterdatei steht im Kopfbefehl
>
>  #t{'<!-- Dateianfang -->' C} #t{'<add>' C}
>
>  daraus ergibt sich <add> <!-- Dateianfang -->
>
>  ohne Zeilenwechsel dahinter. Warum?
Der sog. "Kopfabschnitt" war ursprünglich konzipiert für Katalogkarten
und hat intern einen Bereich von nur 2 Zeilen. Wenn der output länger
wird, geht das leider schief. Empfehlung: An den Anfang der Parameter
einen Abschnitt setzen, der nur einmal durchlaufen wird, eben vor
Beginn des ersten Datensatzes.

>
>  6. Ob Skriptfehler oder A99-Eigenschaft (das gibt/gab(?) es auch bei
>  Avanti, ich fange das da durch eine geeignete Konstruktion ab) :
>  Manchmal erscheinen vor den tatsächlichen Export Teile der
>  Parameterdatei oder mysteriöse Ausgaben (z.B.: field name="'ë'">'ì
>  )
>
Da müßten wir ein konkretes Beispiel sehen, ein echter Fehler mit solchem
Resultat ist nicht bekannt.

>  Ich denke, dass sich daran nicht leicht etwas ändern lässt, aber
>  vielleicht könnte man mal eine Liste dieser Eigenheiten erstellen, um
>  sie Neulingen zur Verfügung zu stellen und im Zuge der
>  Weiterentwicklung doch das eine oder andere zu verbessern.
>
Was im Rahmen der Möglichkeiten machbar ist, wird gemacht.

B.Eversberg


-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20110721/1d7ac2ca/attachment.html>