Mir ist aufgefallen, das folgendes nicht funktioniert:
(1) (set du4 [du1:read2:"(-?\d+(\.\d+)?)":$1 ? $1 : 0])
Wenn read2 im Dummy du1 den Wert abc hat, sollte eigentlich du4 auf 0 gesetzt werden.
du4 wird aber auf :read2:"(-?\d+(\.\d+)?)":$1 ? $1 : 0 gesetzt.
Ist das Absicht?
Es funktioniert mit
(1) (set du4 [du1:read2:"(-?\d+(\.\d+)?)":($1*1 ? $1 : 0)])
ja, intern wird die eigene Split-Funktion benutzt. Sie hat im Gegensatz zu Perl-Split die Eigenschaft mit geschützten Trennzeichen umgehen zu können. Hier wird der Doppelpunkt als Trennzeichen durch die zusätzlichen Klammern geschützt.
Der Störfaktor ist $1 = undef, denn dies funktioniert ohne ().
(1) (set du4 [du1:read2:"(-?\d+(\.\d+)?)":$1*1 ? $1 : 0])
ok. Der letzte Doppelpunkt ist dann wohl egal, weil kein weiteres Trennzeichen von DOIF an dieser Stelle erwartet wird.
Die Sache mit $1=undef ist dann offenbar auf Perl-Warning zurückzuführen.
Nach dem Motto it´s not a feature, it´s a bug
Die internen Variablen $1, $2 usw. waren vom internen match vorbelegt. Wenn der User-regExp match nicht zutrifft, werden diese Variablen leider nicht zurückgesetzt.
Da sie read only sind, kann ich sie nicht direkt vorbelegen.
Ich habe folgenden Hack angewandt: "" =~ /()()()()()()()()()/
damit werden $1, $2, usw. mit einem leeren String vorbelegt.
Kannst mal die angehängte Version testen.
Zitat von: Damian am 09 April 2017, 14:50:42
Nach dem Motto it´s not a feature, it´s a bug
Die internen Variablen $1, $2 usw. waren vom internen match vorbelegt. Wenn der User-regExp match nicht zutrifft, werden diese Variablen leider nicht zurückgesetzt.
Da sie read only sind, kann ich sie nicht direkt vorbelegen.
Ich habe folgenden Hack angewandt: "" =~ /()()()()()()()()()/
damit werden $1, $2, usw. mit einem leeren String vorbelegt.
Kannst mal die angehängte Version testen.
Klappt wie erwartet, den Hack werde ich mir mal merken.
Zitat von: Ellert am 09 April 2017, 18:40:40
Klappt wie erwartet, den Hack werde ich mir mal merken.
ich wüsste mal gerne, wie man diese Variablen sonst resetet.