[Allegro] Differenzen. Untersuchung Teil 1

[Thomas Berger]

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

Lieber Herr Eversberg,

>> beim kreieren eines maessig komplexen Flex (Tabelle
>> mit Rohdaten einlesen, in Suchbegriffe umbauen,
>> gegen die aktuelle Datenbank testen), habe ich wegen
>> bekannter a99-Unzulaenglichkeiten (v.a. der schlechten
>> Moeglichkeit des Abbruchs, wenn etwas schief geht)
> In Schleifen, und nur dann wird's ja kritisch, bauen Sie
> einen  keycheck  ein, und dann wird es per Tastendruck abbrechbar.
> Das bietet  acon  nicht!

Schon klar, leider fuehrte der auf ein doppelt vergebenes
Sprunglabel, und dann hatte ich trotzdem eine Endlosschleife...
[Anregung: Zumindest beim Zu-X-en des a99-Fensters sollte
a99 versuchen, einen laufenden Flex zu stoppen]


>> * [Bug in a99, acon korrekt]: Das "get first" nach find scheint
>>   mit dem Zeiger auf der geoeffneten Datei zu interferieren,
>>   ein folgendes "get" liefert nicht die naechste, sondern
>>   die uebernaechste Zeile der Eingangsdatei
>>
> Lassen Sie das "get" weg, es ist für a99 nicht korrekt (was die Doku
> auch andeutet) und auch bei avanti inzwischen redundant - also
> interoperabel.

Sie meinen "first" statt "get first"? Aber geht dann auch
"second" anstatt "get 2"? Jedenfalls hatte "get 1" in a99 denselben
falschen Einfluss auf den Pointer der Eingangsdatei wie "get first".


>> * Im konkreten Fall konnte ich mich mit "f1nd" statt "find"
>>   retten, jedoch: acon kennt "f1nd" nicht???.
>>
> Doch, seit V28.8. Eben nochmal getestet.

Werde noch einmal testen: Jedenfalls fand acon nichts und
a99 fand.


>> * nervig (a99 und acon): auf den Erfolg von "f1nd" muss man
>>   mit "if no" testen, auf den Erfolg von "find" kann man nur
>>   mit "if empty", "if g0" etc. testen, jedoch nicht mit "if no".
>>
> f1nd läßt die bestehende Ergebnismenge unangetastet. Daher *muß*
> es anders getestet werden als find. Mit "if empty" wird die
> bestehende Ergebnismenge getestet, auch wenn inzwischen andere
> Befehle ausgeführt wurden - dann hätte "if no" möglicherweise
> eine andere Wirkung. Sie wollen, ich verstehe, *direkt* nach dem
> "find" mit "if no" testen. Vielleicht kann man das noch einrichten.

Genau.


Neu hinzugekommen auf der Liste, allerdings etwas vage, weil
ich im Zuge von Reparaturen keine Testfaelle uebrig behalten
hatte: Aufgrund der Eingangsdaten habe ich sukzessive Suchbegriffe
aufgebaut, also etwa

var #uQU ' and REG "' #uxx '"'
ins #uQU

oder auch andersherum

var 'REG "' #uxx '" and ' #uQV
ins #uQV

Dabei wird in der Anfangssituation (Variable nicht belegt)
fuer die u-Variable[!] jeweils ein Inhalt gebildet, der mit
Spatium beginnt oder mit Spatium endet. Beides sollte (im
Gegensatz zu regulaeren Kategorien) funktinieren. Ich habe
nun den Eindruck, dass a99 fuehrende Spatien toetet und
acon abschliessende oder umgekehrt, jedenfalls wird da etwas
"bereinigt" und zwar uneinheitlich. Koennen Sie das ohne
konkreteren Testfall ueberpruefen?

viele Gruesse
Thomas Berger


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

iQCVAwUBSdM/22ITJZieluOzAQIqMQP9HXRoqGHSt+6SDfeEqsIZOL1K2qtbEQpa
2qpnx9Dj/Qy/Gg1X2V9x+psnf6JPuMn4O6Idap1l2g/1yO0sS9CCNvlbGhhkDRix
8Ruqo8wali42Ny5+tMFcZmZORwxD8clTg6MMrbb3fkOrHmTjUIUEsVq9BeCzYP8F
8c4ha70AQKU=
=CrU9
-----END PGP SIGNATURE-----