<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Am 15.07.2011 10:50, schrieb Fischer, Thomas:<br>
    <span style="white-space: pre;">> <br>
      > ich bin dabei, für meine Datenbanken ein XML-Exportformat für
      solr zu<br>
      > schreiben. Wie üblich bei neuen Projekten wird man da massiv
      mit den<br>
      > Eigenheiten von Allegro konfrontiert.<br>
      > <br>
      > 1. Das zentrale Problem ist, dass (im Gegensatz zu allen
      anderen mir<br>
      > bekannten Skriptsprachen) syntaktische Fehler (z.B.
      Tippfehler) nicht<br>
      > zu einem Abbruch des Skriptes (möglichst mit Fehlermeldung)
      führen,<br>
      > sondern mit schwer vorhersehbaren (und damit umgekehrt schwer<br>
      > analysierbaren) Ergebnissen durchlaufen. Beispiele: ##ufk
      statt #ufk;<br>
      > v2.9 statt v2,9; #) statt #)L.<br>
      > <br>
    </span>Dies ist der Effizienz geschuldet. Grundsätzlich was dran zu
    ändern<br>
    oder es gar gänzlich abzustellen, wäre in der Hinsicht eher
    kontraproduktiv.<br>
    Konkrete einzelne Verbesserungen wären natürlich denkbar.<br>
    Immerhin sind die Quellen nun offen, es handelt sich um die Module<br>
    exet.cpp  : Abarbeitung der Parameter (Anwendung auf aktuellen Satz)<br>
    exet2.cpp : Einlesen der Parameter, Überführung in interne Form<br>
                 (Zusätzliche Erkennung von Fehlern wäre hier
    anzusiedeln)<br>
    exet3.cpp : einige Hilfsroutinen<br>
    im Paket ac15.<br>
    Schwer verdaulich, zugegeben, obwohl mit einigem Kommentar versehen.<br>
    Diesbezügliche Fragen beantworten wir gerne.<br>
    <br>
    <br>
    <span style="white-space: pre;">> 2. Damit zusammenhängend ist
      das Debugging der Exportskripte extrem<br>
      > zeitaufwändig, es gibt auch keine Unterstützung wie z.B. ein<br>
      > zeilenweises Durcharbeiten des Skriptes.<br>
      > <br>
    </span>Das hat dieselben Gründe. Die interne Form eignet sich z.B.
    nicht, um<br>
    als Fehlerhinweis angezeigt zu werden.<br>
    <br>
    <span style="white-space: pre;">> 3. Die Exportsprache ist durch
      ihre GOTO-Konstrukten extrem<br>
      > fehleranfällig (bzw. fehlertolerant, siehe 1): - Sprünge nach
      +b oder<br>
      > +#30 springen auch aus Unterprogrammen heraus - Sprünge nach
      +#30 und<br>
      > Unterprogrammaufrufe (!) springen nur nach folgenden (dann
      aber<br>
      > beliebigen) Marken. - "Unterprogramme" sind nur Paare von<br>
      > Sprungmarken<br>
      > <br>
    </span>Ja, alles aus heutiger Sicht eher primitiv. Aber schnell.<br>
    <br>
    <span style="white-space: pre;">> 4. Ersetzung funktioniert bei
      ersten vier Buchstaben nicht, daher <br>
      > #uLa p'XXXX' ,", ,_," y1 b4 dLa =La<br>
      > <br>
    </span>Ja, weil der Feldanfang ja normalerweise die Kategorienummer
    ist und<br>
    diese i.d.R. nicht betroffen sein soll. Der Trick umgeht dies.<br>
    <br>
    <span style="white-space: pre;">> 5. Ich habe das schon früher
      moniert und noch immer nicht begriffen: <br>
      > In meiner Exportparameterdatei steht im Kopfbefehl<br>
      > <br>
      > #t{'<!-- Dateianfang -->' C} #t{'<add>' C}<br>
      > <br>
      > daraus ergibt sich <add> <!-- Dateianfang --><br>
      > <br>
      > ohne Zeilenwechsel dahinter. Warum? </span><br>
    Der sog. "Kopfabschnitt" war ursprünglich konzipiert für
    Katalogkarten<br>
    und hat intern einen Bereich von nur 2 Zeilen. Wenn der output
    länger<br>
    wird, geht das leider schief. Empfehlung: An den Anfang der
    Parameter<br>
    einen Abschnitt setzen, der nur einmal durchlaufen wird, eben vor<br>
    Beginn des ersten Datensatzes. <br>
    <br>
    <span style="white-space: pre;">> <br>
      > 6. Ob Skriptfehler oder A99-Eigenschaft (das gibt/gab(?) es
      auch bei<br>
      > Avanti, ich fange das da durch eine geeignete Konstruktion
      ab) : <br>
      > Manchmal erscheinen vor den tatsächlichen Export Teile der<br>
      > Parameterdatei oder mysteriöse Ausgaben (z.B.: field
      name="'ë'">'ì<br>
      > )<br>
      > <br>
    </span>Da müßten wir ein konkretes Beispiel sehen, ein echter Fehler
    mit solchem<br>
    Resultat ist nicht bekannt.<br>
    <br>
    <span style="white-space: pre;">> Ich denke, dass sich daran
      nicht leicht etwas ändern lässt, aber<br>
      > vielleicht könnte man mal eine Liste dieser Eigenheiten
      erstellen, um<br>
      > sie Neulingen zur Verfügung zu stellen und im Zuge der<br>
      > Weiterentwicklung doch das eine oder andere zu verbessern.<br>
      > <br>
    </span>Was im Rahmen der Möglichkeiten machbar ist, wird gemacht.<br>
    <br>
    B.Eversberg<br>
    <br>
    <br>
  </body>
</html>