Problem mit CASEALL [FIXED]

[SLC]

Moin!

Hallo,

könnte es sein das Caseall eigentlich immer ausgeführt wird egal was für ein ausdruck dahinter steht es aber erwartet wird, dass da ein "*" zu stehen hat und sollte dies nicht der Fall sein er in der Zählung der Scope durcheinander kommt und damit im gesamten Programmablauf oder wie ist es zu erklären das er plötzlich eine Rücksprung von Scope 0 auf -1 machen will?

Code:

(01:25:04) S < Rücksprung von Scope 0 nach Scope -1 in Zeile 19 (WHO)

Gruß Niki

Scope -1 steht für "no scope". Dann ist das Programm "idle"
und kann nur durch ein EVENT aktiviert werden, etwa @-Befehl
oder Antellen oder Erscheinen oder...

In Klammern dahinter steht, welche lokalen Variablen das betrifft...

Grüße, SLC

[Stechmuck]

P.S. @Stechi: Kannst Du mal in Zeile 3035 schauen:

Code:

for (i = a.length - 1; i >= 0; i--)

Das kommt mir verdächtig falsch vor...
Komisch, daß das nicht für mehr Chaos gesorgt hat...

Ahoi

Da kenne ich mich wohl zu wenig aus im Code.
Vermuten würde ich:

Code:

for (i = a.length - 2; i > 0; i--)

Grüßle Stechi

[Chazar]

Gefunden und behoben. Solche Bugs kannst Du immer auch zwischendurch melden...

Das hatte ich doch vor langer einiger Zeit getan, der Bug war aber letztens immer noch da gewesen! Da Du damals auf ein Unter-thema des Threads ja geantwortet hast, ging ich eben davon aus, das Du Dir dieser Sache schon bewusst warst, aber als unwichtig/korrekt (im Sinne von GETINFO und undefinierten Werten falls offline) abgetan hast und habe eben als Workaround die Error-Routinen jedesmal unmittelbar davor verbogen. Ist ja einfach und ich will sicherlich nicht wegen Kleinigkeiten herumnerven! Ich meld' schon alles was ich so finde!

Ich teste das morgen also nochmal - und bin auch gespannt darauf welchen Wert [ROOM] dann hat! (auch wenn's für mein Puppet wurscht ist was da drin steht.)

Falls es keine NullPointerException mehr gibt: Danke! Falls doch: Danke trotzdem für das befassen mit dem Thema. 



(EDIT/PS: Dieses Unterthema in den oben verlinkten Thread mit EXISTS/ISEMPTY - wurde das auch behoben? Muss ich auch nochmal testen... )

[SLC]

Moin!

Falls es keine NullPointerException mehr gibt: Danke! Falls doch: Danke trotzdem für das befassen mit dem Thema. 

Also, zum Puppet sollen eigentlich allenfalls IllegalParameterExceptions
durchdringen - vielleicht noch numerische Fehler. Auf keinen Fall solch
unvermittelte NullPointerExceptions! ROOM wird in dem Fall nicht gesetzt sein.
Die ganze Sache ist mir dann wohl durchgerutscht...

Was genau war noch mit ISEMPTY/EXISTS?

Grüße, SLC

P.S.@Stechi: Jo, so oder so ähnlich dachte ich mir das... Schaue ich mir nachher genauer an...

[Chazar]

Was genau war noch mit ISEMPTY/EXISTS?

Es gilt derzeit das ISEMPTY immer die Verneinung von EXISTS ist, was offensichtlich nicht in jedem Fall gelten sollte!

Anders gesagt, gilt nach LOCAL name noch nicht EXISTS name, was falsch ist.

Ich habe den Test-Code dazu aus dem oben verlinkten Thread gerade eben noch einmal wiederholt: Das Problem besteht immer noch!

Hier noch einmal der Test-Code, gefolgt vom Ergebnis.

Code:

ACTION test
    -- EXISTS nixda: [=EXISTS nixda]
    -- ISEMPTY nixda: [=ISEMPTY [nixda]]
    -- ISINTEGER nixda: [=ISINTEGER [nixda]]
    LOCAL nixda
    -- LOCAL nixda
    -- EXISTS nixda: [=EXISTS nixda]
    -- ISEMPTY nixda: [=ISEMPTY [nixda]]
    -- ISINTEGER nixda: [=ISINTEGER [nixda]]
    EVAL nixda = "123"
    -- EVAL nixda = "123"
    -- EXISTS nixda: [=EXISTS nixda]
    -- ISEMPTY nixda: [=ISEMPTY [nixda]]
    -- ISINTEGER nixda: [=ISINTEGER [nixda]]
    UNSET nixda
    -- UNSET nixda
    -- EXISTS nixda: [=EXISTS nixda]
    -- ISEMPTY nixda: [=ISEMPTY [nixda]]
    -- ISINTEGER nixda: [=ISINTEGER [nixda]]
END

Ausgabe:

Code:

Chazar: @test
-- [TestdummyY] EXISTS nixda: FALSE
-- [TestdummyY] ISEMPTY nixda: TRUE
-- [TestdummyY] ISINTEGER nixda: FALSE
-- [TestdummyY] LOCAL nixda
-- [TestdummyY] EXISTS nixda: FALSE
-- [TestdummyY] ISEMPTY nixda: TRUE
-- [TestdummyY] ISINTEGER nixda: FALSE
-- [TestdummyY] EVAL nixda = "123"
-- [TestdummyY] EXISTS nixda: TRUE
-- [TestdummyY] ISEMPTY nixda: FALSE
-- [TestdummyY] ISINTEGER nixda: TRUE
-- [TestdummyY] UNSET nixda
-- [TestdummyY] EXISTS nixda: FALSE
-- [TestdummyY] ISEMPTY nixda: TRUE
-- [TestdummyY] ISINTEGER nixda: FALSE
-- [TestdummyN] EXISTS nixda: FALSE
-- [TestdummyN] ISEMPTY nixda: TRUE
-- [TestdummyN] ISINTEGER nixda: FALSE
-- [TestdummyN] LOCAL nixda
-- [TestdummyN] EXISTS nixda: FALSE
-- [TestdummyN] ISEMPTY nixda: TRUE
-- [TestdummyN] ISINTEGER nixda: FALSE
-- [TestdummyN] EVAL nixda = "123"
-- [TestdummyN] EXISTS nixda: TRUE
-- [TestdummyN] ISEMPTY nixda: FALSE
-- [TestdummyN] ISINTEGER nixda: TRUE
-- [TestdummyN] UNSET nixda
-- [TestdummyN] EXISTS nixda: FALSE
-- [TestdummyN] ISEMPTY nixda: TRUE
-- [TestdummyN] ISINTEGER nixda: FALSE

wobei Y/N am Ende des Namens die Einstellung von ZEROINTVARS: YES/NO widerspiegelt (ohne Auswirkung auf den Test).


PS@SLC: Soll ich also in Zukunft besser solange nachhaken bis ich ein JA oder NEIN erhalten habe? Musst's nur sagen!

PPS@SLC:Wobei eine Änderung vermutlich einige bewährte Puppets aus dem Tritt bringen könnte. Mir ist's wurscht, ich nutze ausschliesslich ISEMPTY, weil da die Semantik klar ist.

[SLC]

Puh!

EXISTS vor Zuweisung eines Wertes, das ist harter Tobak!
Ich vermute mal stark, Du hast mit Deiner Beobachtung recht,
ich wäre allerdings auch nicht drauf gekommen, EXISTS aufzurufen,
bevor ein Wert zugewiesen wird. Oder ich benutze LOCAL x = y...

Derzeit ist es so, daß ein LOCAL x ein möglicherweise vorhandenes
globale(re)s x überdecken wird, also

Code:

EXISTS x | Kommando
---------+-----------------
FALSE    | ACTION start
TRUE     |   LOCAL x = "blubber"
TRUE     |   DO unter
...
TRUE     | ACTION unter
FALSE    |   LOCAL x
TRUE     |   EVAL x = "blah"
...

Über die Vor- und Nachteile muß ich dann noch mal nachdenken...

Grüße, SLC

[SLC]

Moin!

Ab Neustart sollten keine NullPointerExceptions mehr auftreten bei

- WHEREIS STARTER
- WHEREIS OWNER
- WHEREIS PUPPET
- CASEALL ...

Grüße, SLC

[Chazar]

EXISTS vor Zuweisung eines Wertes, das ist harter Tobak!

Häh??? Ein gewisser SLC hat mich damals in diesem Thread ja gerade belehrt das dies der Unterschied zwischen EXISTS und ISEMPTY sein soll!

Oder habe ich das damals falsch verstanden, d.h. gibt es einen echten Unterschied zwischen

Code:

LOCAL xyz

und

Code:

LOCAL xyz = ""

Wenn ja, dann hatte ich das wohl nur falsch verstanden. Ansonsten wären EXISTS und ISEMPTY wirklich identisch, mal von Verneinung und Auswertung der Variablen abgesehen.


Wie gesagt, mir ist's eigentlich wurscht, da es mich bisher eigentlich nie interessiert hat ob eine Variable existiert oder nicht. (Das Überdecken von globalen oder auch lokalen (!) Variablen mit neuen lokalen Variablen nach Funktionsaufruf/Rekursion nutze ich dagegen oft aus, um Werte nur temporär zu ändern).

Anstelle von

Code:

EXISTS foo

schreibe ich derzeit halt immer

Code:

NOT ( ISEMPTY [foo] )

da ich nach Deiner Antwort in dem Thread von März verunsichert war, ob sich das mal ändern könnte.

Danke für die Bugfixes! (Noch nicht von mir getestet, aber ich melde mich falls es nicht klappen sollte. )

[SLC]

Moin!

Die Klammer kannst Du Dir eh abgewöhnen...

Code:

NOT ISEMPTY [foo]

... und ja, natürlich gibt es einen Unterschied zwischen diesen beiden:

Code:

LOCAL xyz
...
LOCAL xyz = ""

Ersterer deklariert xyz als LOCAL (geht ja auch nur einmal in einem Scope),
weist aber KEINEN Wert zu. D.h. streng genommen gibt es die Variable noch nicht.

Die zweiter Version legt dagegen eine Variable mit dem Wert "" an,
d.h. EXISTS xyz -> TRUE / NOT ISEMPTY [xyz] -> FALSE...

Grüße, SLC

[Chazar]

Schon klar, aber was ist der beobachtbare Unterschied, abgesehen von EXISTS?

BEISPIEL-FRAGE:

Code:

FOR x IN [bar]
BEGIN
  LOCAL y = [x] * [pi]
  ADDLIST foo y
END

sollte ich dann besser LOCAL foo = "" oder LOCAL foo davor schreiben, wenn die Liste foo lokal sein soll?

Soweit ich das jetzt verstehe, ist das doch vollkommen egal, oder?

PS: Oder habe ich dann das Problem mit der ein-elementigen Liste, welche die leere Liste enthaelt? Davon sprichst Du immer wieder, aber verstanden, bzw. ein Beispiel wo sich das auswirkt, habe ich (es) nicht.

[SLC]

Moin!

Wie ich hörte, gibt es heute eine DEBUG-Meldung umsonst,
wenn man SWITCH/CASE anwendet, diese ist aber morgen raus.
Irgendwie ist die vorletzte Version auf dem Server gelandet!

Grüße, SLC

[SLC]

Moin!

Viel zu beobachten ist da nicht, da es ein totaler Spezialfall ist
(also LOCAL x bis zur Zuweisung eines Wertes; dort wird normalerweise
noch nicht einmal jeder EXISTS aufrufen... )

• liefert in beiden Fällen natürlich "", was nicht zu unterscheiden ist.

EXISTS ist eigentlich nur etwas genauer (es gilt: NOT ISEMPTY

• => EXISTS x)...

Schon klar, aber was ist der beobachtbare Unterschied, abgesehen von EXISTS?

BEISPIEL-FRAGE:

Code:

FOR x IN [bar]
BEGIN
  LOCAL y = [x] * [pi]
  ADDLIST foo y
END

sollte ich dann besser LOCAL foo = "" oder LOCAL foo davor schreiben, wenn die Liste foo lokal sein soll?

Soweit ich das jetzt verstehe, ist das doch vollkommen egal, oder?

PS: Oder habe ich dann das Problem mit der ein-elementigen Liste, welche die leere Liste enthaelt? Davon sprichst Du immer wieder, aber verstanden, bzw. ein Beispiel wo sich das auswirkt, habe ich (es) nicht.

Der Code ist eigentlich völlig okay; wenn Du foo aber nur in der ACTION
brachst, würde ich schon sagen, daß Du LOCAL foo vor die FOR-Schleife
packen solltest. Für den ADDLIST-Befehl ist das allerdings erstmal egal.

Zu dem Beispiel, wo sich das auswirkt...

Code:

LOCAL Liste
>> "[Liste]" [=LISTLENGTH [Liste]] [=LENGTH [Liste]]
ADDLIST Liste ""
>> "[Liste]" [=LISTLENGTH [Liste]] [=LENGTH [Liste]]
ADDLIST Liste ""
>> "[Liste]" [=LISTLENGTH [Liste]] [=LENGTH [Liste]]

Ausgabe in etwa:

Code:

"" 0 0
"" 1 0
" " 2 1

Du siehst also, daß sich das erste ADDLIST anders verhält
als das zweite, obwohl in beiden Fällen [Liste] == "" und
LENGTH [Liste] == 0, also ohne sichtbaren Unterschied, nur
die LISTLENGTH ist anders.

Dasselbe Beispiel mit "x":

Code:

LOCAL Liste
>> "[Liste]" [=LISTLENGTH [Liste]] [=LENGTH [Liste]]
ADDLIST Liste "x"
>> "[Liste]" [=LISTLENGTH [Liste]] [=LENGTH [Liste]]
ADDLIST Liste "x"
>> "[Liste]" [=LISTLENGTH [Liste]] [=LENGTH [Liste]]

Ausgabe in etwa:

Code:

"" 0 0
"x" 1 1
"x x" 2 3

Bei nichtleeren Elementen ist es einfach: Die LENGTH ist mit 0 bzw. >0 (1)
unterschiedlich und auch der Wert ist unterschiedlich ("" vs. "x").

Soweit verstanden? Der Fall hat bei mir damals einige Kopfschmerzen
verursacht, aber am Ende hatte ich eine konsistente Lösung. Lange
Zeit waren davor leere Einträge gar nicht möglich, was z.T. für
Verwirrung gesorgt hatte...

Grüße, SLC

[Chazar]

Super! Danke für die Erklärung! 

Das erklärt auch ein Problem, das ich gerade erst vor 3 Tagen hatte. Ich sah in den Debug-Meldungen sowas wie:

Code:

>> Wert: "[lst]" Länge: [=LISTLENGTH [lst]]

Wert: "1 2 3 4 5 6 7 " Länge: 36

Als Fehlerquelle fand ich ein vergessenes BEGIN...END hinter einem ELSE, doch richtig erklären konnte ich mir das nicht. Jetzt verstehe ich das aber: Per ADDLIST wurden leere Elemente hinzugefügt!

[Chazar]

Ab Neustart sollten keine NullPointerExceptions mehr auftreten bei

- WHEREIS STARTER

Ich erhalte immer noch Null Pointer Exceptions, wenn ich ausgeloggt bin und mein Puppet WHEREIS STARTER ausführt.