[Allegro] V33.5beta und Vb.255-Vorab

[Thomas Berger]

Lieber Herr Eversberg,

>> Die Daten von etwa srch.exe und index.exe sind 31.7.2013, im SVN
>> gibt es aber seitdem Aenderungen: Sind die in inst-beta dennoch
>> auf dem aktuellsten Stand?
>>
> Von der Sache her ja, weil diese Programme von den späteren Änderungen
> nicht betroffen waren.
> Zwecks Irritationsvermeidung wollen wir aber gerne die Programme
> nochmal kompilieren.

Das waere gut: Ich habe gestern stundenlang ein Problem eingekreist,
in dem sich srch.exe in Abhaengigkeit von der Laenge einer bestimmten
Kommentarzeile beim Start aufhaengte. Mit dem selbstcompilierten aus
dem svn trat das Problem nicht auf (mit acon -j srch.job auch nicht)
und jetzt ist die Frage, ob es an Zufaelligkeiten der Compilation
(andere Debugging-Schalter oder was auch immer: die von mir hier
compilierten allegro-Module sind stets deutlich groesser als die
aktuellen) liegt oder an einem inzwischen in den Quellen behobenen
Problem...



> Da wäre es jetzt nett gewesen, diese Mini-Parameterdatei zur
> Nachnutzung mitzuliefern. Aber schau'mer mal, vielleicht können wir

wenn ich mich recht entsinne:


#-#
#655 y2 p"#655" M
#+#

q $ ▼


(offensichtlich also nicht fuer A.CFG ...)



> da noch was tun, und kommen wir zur Sache, zu der etwas weiter
> auszuholen ist:
> 
> Zum einen haben wir dem Problem schon mal einen Beitrag in unserer
> Trick-Serie gewidmet und einen universellen FLEX dafür geliefert:
> 
>   http://www.allegro-c.de/flex/tricks/trick74.htm

Ah. Wieso ist "$" bei der lokalen Ersetzung nicht der
"Abzwack-Operator"?
Das ist nicht als rhetorische Frage gemeint: Im Prinzip
ist die Nutzung des "$" in den Ersetzungen, wo das Zeichen
eine Sonderbedeutung hat, ja genau entgegen der ueblichen
Semantik (jener in regulaeren Ausdruecken): Dort ist $ ein
Anker, d.h. ein Match gibt es dann, wenn das vorige genau
am Ende steht...


> Was also zu tun wäre, ist die Modifizierung der Funktion SrRp() in
> der RECORD-Klasse.
> Das ginge NICHT so, daß wir einfach die Eingabe von $ in der Form
> ^036 ermöglichen, denn solche Codierungen werden in der neuen Routine
> zunächst in die eigentlich gemeinten Bytes umgesetzt, was ja
> normalerweise nicht-druck- und -eingebbare Zeichen sind, weswegen die
> Möglichkeit erst geschaffen wurde. Nach dieser Vorbereitung steht
> im Ersetzungsbefehl also nicht mehr ^036, sondern $, und das Problem
> wäre nicht weg. Schlagen Sie einen anderen Weg vor, bevor wir einen
> ersinnen, der dann aus anderen Gründen wieder nicht genehm ist.

PRESTO-Ersetzungsbefehler erlaubten \nnn als Eingabekonvention,
ob speziell \036 dann wiederum doch nicht funktionierte, weiss
ich nicht.

Wenn ich Sie recht verstehe, ist ein Zeichen entweder das Zeichen
als solches oder eines mit Steuerfunktion, wenn letzteres, dann
ist es als solches dem Ersetzungsmechanismus prinzipiell nicht
zugaenglich. Das kriegen andere besser hin.

Ist eigentlich nur das $ in den Ersetzungen ein Steuerzeichen, dann
sollte man das evtl. abschaffen und mittelfristig auf die Einfuehrung
einer Ersetzungsmimik mit regulaeren Ausdruecken bauen.

viele Gruesse
Thomas Berger