tabelle mit non numerical key

[gmd]

Hallo,
noch ein problem mit Lua

Ich definiere:

local signalLists = {
  ["X01"] = { ... },
  ["X02"] = { ... }
}

modul.variables["SignalLists"] = signalLists

wenn ich zuruecklese bekomme ich

modul.variables["SignalLists"]
{
  [1] = { ... data of X01 ... },
  [2] = { ... data of X02 ... }
}

Intern wird wohl serialised und non numeric keys gehen verloren ..
 

["X01"] = {}

OK in plain Lua und lokalen variablen , nicht erhalten  in modul.variables

{ name = "X01", ... }         ich muss dies tun um den namen zu behalten Mehrfach getestet gruss Gmd

 

[Goetz]

Hallo Gmd,
wenn du zuerst eine Variable vom Typ Tabelle (nicht Liste) anlegst, kannst du anschließend deine Lua Tabelle an diese Modul- (oder Objekt-)Variable übertragen:

Lua Tabelle in Modulvariable übertragen.mbp

Das exotische Lua unterscheidet nicht zwischen Tabellen und Listen.
Das 3D-Modellbahn Studio hingegen schon.
Deshalb muss man da ein bisschen nachhelfen, damit in der Modulvariablen der richtige Typ erzeugt wird.

Viele Grüße
Götz

P.S.: Entgegen meiner ersten Annahme ist der Umweg doch nicht nötig. Es funktioniert auch auf direktem Weg:

Lua Tabelle direkt in Modulvariable übertragen.mbp

 

P.P.S.: Mit deinem Skript funktioniert es auch:

gmd signalLists.mbp

Bleibt die Frage, warum es bei dir trotz mehrfacher Tests nicht geklappt hat ...

Bearbeitet Donnerstag um 16:31 Uhr von Goetz

[gmd]

Danke fuer die Muehe. Da sind noch ein paar unterschiede ..
Ich werde mal versuchen den teil zu isolieren fuer besseren test.
Gruss
Gmd
 

[gmd]

function debugMessage(msg)
        $("Ereignisse").variables["DebugOutput"] = msg  -- Store only the last message will be displayed in the Eventlist
end

local modulName = "SC_1"
local modul = layout:getEventsByName(modulName)[1]

 modul.variables["SignalLists"] = {  X01 = {
                                      type = "FourWayStretched",
                                      signals       = { "SC_1-X01-S_1", "SC_1-X01-S_2", "SC_1-X01-S_3", "SC_1-X01-S_4" },
                                      contacts      = { "SC_1-X01-SK_1","SC_1-X01-SK_2","SC_1-X01-SK_3","SC_1-X01-SK_4"},
                                      stopcontacts  = { "SC_1-X01-HK_1","SC_1-X01-HK_2","SC_1-X01-HK_3","SC_1-X01-HK_4"}
                                    },
                                      X02 = {
                                      type = "FourWay",
                                      signals       = { "SC_1-X02-S_1", "SC_1-X02-S_2", "SC_1-X02-S_3", "SC_1-X02-S_4" },
                                      contacts      = { "SC_1-X02-SK_1","SC_1-X02-SK_2","SC_1-X02-SK_3","SC_1-X02-SK_4"},
                                      stopcontacts  = { "SC_1-X02-HK_1","SC_1-X02-HK_2","SC_1-X02-HK_3","SC_1-X02-HK_4"}
                                    },
                                 }

  for crossingName, crossingData in pairs(modul.variables["SignalLists"]) do
    debugMessage("Checking Crossing - SignalLists " .. tostring(crossingName))
  end


signalTable = {  X01 = {
                                      type = "FourWayStretched",
                                      signals       = { "SC_1-X01-S_1", "SC_1-X01-S_2", "SC_1-X01-S_3", "SC_1-X01-S_4" },
                                      contacts      = { "SC_1-X01-SK_1","SC_1-X01-SK_2","SC_1-X01-SK_3","SC_1-X01-SK_4"},
                                      stopcontacts  = { "SC_1-X01-HK_1","SC_1-X01-HK_2","SC_1-X01-HK_3","SC_1-X01-HK_4"}
                                    },
                                      X02 = {
                                      type = "FourWay",
                                      signals       = { "SC_1-X02-S_1", "SC_1-X02-S_2", "SC_1-X02-S_3", "SC_1-X02-S_4" },
                                      contacts      = { "SC_1-X02-SK_1","SC_1-X02-SK_2","SC_1-X02-SK_3","SC_1-X02-SK_4"},
                                      stopcontacts  = { "SC_1-X02-HK_1","SC_1-X02-HK_2","SC_1-X02-HK_3","SC_1-X02-HK_4"}
                                    },
                                 }

  for crossingName, crossingData in pairs(signalTable) do
    debugMessage("Checking Crossing - SignalTable " .. tostring(crossingName))
  end

  modul.variables["SignalTable"] = signalTable

  for crossingName, crossingData in pairs(modul.variables["SignalTable"]) do
    debugMessage("Checking Crossing - Stored in variables SignalTable " .. tostring(crossingName))
  end

erzeugt

[8:16:51 AM] Modul-Variable wird gesetzt -> SC_1, "SignalLists", {2 Elemente}
[8:16:51 AM] Modul-Variable wird gesetzt -> Ereignisse, "DebugOutput", "Checking Crossing - SignalLists 2"
[8:16:51 AM] Modul-Variable wird gesetzt -> Ereignisse, "DebugOutput", "Checking Crossing - SignalLists 1"
[8:16:51 AM] Modul-Variable wird gesetzt -> Ereignisse, "DebugOutput", "Checking Crossing - SignalTable X01"
[8:16:51 AM] Modul-Variable wird gesetzt -> Ereignisse, "DebugOutput", "Checking Crossing - SignalTable X02"
[8:16:51 AM] Modul-Variable wird gesetzt -> SC_1, "SignalTable", {2 Elemente}
[8:16:51 AM] Modul-Variable wird gesetzt -> Ereignisse, "DebugOutput", "Checking Crossing - Stored in variables SignalTable 2"
[8:16:51 AM] Modul-Variable wird gesetzt -> Ereignisse, "DebugOutput", "Checking Crossing - Stored in variables SignalTable 1"

hier das beispiel in deiner test anlage
09788E1E-A2F1-4E62-B044-6ECF44105AF6

gruss
Gmd



 

[Goetz]

vor 16 Stunden schrieb gmd:

hier das beispiel

Das Problem scheint in der Implementierung von in pairs() zu stecken.
Die Tabelle in der Modulvariablen bekommt die korrekten Bezeichner und ist auch vom Format "Tabelle".
Aber in pairs() bekommt einen anderen (nämlich den numerischen) key anstelle dieses Bezeichners.

Da muss @Neo einen Blick drauf werfen und schauen, was das verursacht.

Viele Grüße
Götz

Bearbeitet Freitag um 16:46 Uhr von Goetz

[Goetz]

Minimalbeispiel für @Neo:

Beispielanlage für in pairs.mbp

 

Zweite Beispielanlage. Mit diesen Bezeichnern passiert der Fehler nicht.

zweite Beispielanlage für in pairs.mbp

Bearbeitet Freitag um 13:48 Uhr von Goetz
zweite Beispielanlage eingefügt

[gmd]

3 minutes ago, Goetz said:

Das Problem scheint in der Implementierung von in pairs() zu stecken.
Die Tabelle in der Modulvariablen bekommt die korrekten Bezeichner und ist auch vom Format "Tabelle".
Aber in pairs() bekommt einen anderen (nämlich den numerischen) key anstelle dieses Bezeichners.

Da muss Neo einen Blick drauf werfen und schauen, was das verursacht.

Viele Grüße
Götz

ok, waere shon gut wenn er das fixen koennte fuer die zukunft, macht viele abfragen einfacher und auch definitionen.
Ich habe meine generische ampelsteuerung fertig. Nur tabellen fuer beliebige anzahl von kreuzungen.
Werde einen post machen
Gruss
Gmd
 

[Goetz]

vor einer Stunde schrieb gmd:

ok, waere shon gut wenn er das fixen koennte

und deshalb von mir noch der folgende Hinweis an @Neo:

Wenn ich die Bezeichner X01 und X02 abändere in A01 und A02, dann werden sie von in pairs() korrekt wiedergegeben.

Das große X, gefolgt von einer Zahl scheint die Ursache zu sein.
Könnte es damit zusammenhängen, dass man (in anderen Sprachen, nicht in Lua) Hexadezimalzahlen ein x voranstellt?

Bearbeitet Freitag um 15:05 Uhr von Goetz
Aussage konkretisiert

[EASY]

Hallo,

vor einer Stunde schrieb Goetz:

Wenn ich die Bezeichner X01 und X02 abändere in A01 und A02, dann werden sie von in pairs() korrekt wiedergegeben.

Das große X, gefolgt von einer Zahl scheint die Ursache zu sein.
Könnte es damit zusammenhängen, dass man (in anderen Sprachen, nicht in Lua) Hexadezimalzahlen ein x voranstellt?

... wird anscheinend so interpretiert.
Wenn man...

local signalLists = {
  ["XAB"] = { $("Hauptsignal Hp0/1"), $("Hauptsignal Hp0/1/2") },
  ["XAC"] = { $("H/V Blocksignal"), $("H/V Hauptsignal") }
}

$("Ereignisse").variables["SignalLists"] = signalLists

... definiert, kommt in dem Beispiel von @Goetz...

for k, v in pairs ($("Ereignisse").variables["SignalLists"]) do
  print(k)
end

171 und 172 zurück...

... wenn man hingegen....

local signalLists = {
  ["XGG"] = { $("Hauptsignal Hp0/1"), $("Hauptsignal Hp0/1/2") },
  ["XGH"] = { $("H/V Blocksignal"), $("H/V Hauptsignal") }
}

$("Ereignisse").variables["SignalLists"] = signalLists

... definiert, dann kommt auch
XGG und XGH zurück...

... ist also etwas gemischt mit der Interpretation...

Gruß
EASY

[Goetz]

vor 7 Minuten schrieb EASY:

ist also etwas gemischt

ab und ac können als Hexzahlen gelesen werden, gg und gh hingegen nicht.

[EASY]

Hallo,

vor 2 Stunden schrieb Goetz:

ab und ac können als Hexzahlen gelesen werden, gg und gh hingegen nicht

... deshalb extra so gewählt...

Gruß
EASY

[Goetz]

vor 15 Minuten schrieb EASY:

... deshalb extra so gewählt

Hätte ich mir eigentlich denken müssen - sorry für die Schlaumeierei.

[gmd]

Ich habe leider noch ein weiteres beispiel ohne X mit dem gleichen problem.
Gruss
Gmd
 

[Goetz]

vor 5 Stunden schrieb gmd:

Ich habe leider noch ein weiteres beispiel ohne X mit dem gleichen problem.

Was sollen wir bitte mit der Aussage anfangen?

[gmd]

1 hour ago, Goetz said:

Was sollen wir bitte mit der Aussage anfangen?

Ihr hattet euch irgendwie auf das X eingenordet, deswegen der satz.
gruss
Gmd
 

[Goetz]

vor 6 Minuten schrieb gmd:

deswegen der satz.

Wenn du jetzt noch das "Beispiel ohne X" nennen würdest, könnte man daraus Schlüsse ziehen ...

[gmd]

24 minutes ago, Goetz said:

Wenn du jetzt noch das "Beispiel ohne X" nennen würdest, könnte man daraus Schlüsse ziehen ...

Es ist etwas aufwand das zu isolieren.. werde es versuchen
gruss
Gmd
 

[Goetz]

vor 13 Minuten schrieb gmd:

Es ist etwas aufwand das zu isolieren.

Du musst doch nur den Bezeichner nennen, der nicht mit einem X beginnt, aber trotzdem von in pairs() falsch interpretiert wird.
Wir haben uns auch nicht "irgendwie auf das X eingenordet", sondern klar nachvollzogen, was es bewirkt.

aus XAB wird 171, weil hex AB = dezimal 171 (A0 + B = 10 * 16 + 11)

Bearbeitet gestern um 07:59 Uhr von Goetz
Schreibfehler korrigiert

[gmd]

30 minutes ago, Goetz said:

Du musst doch nur den Bezeichner nennen, der nicht mit einem X beginnt, aber trotzdem von in pairs() falsch interpretiert wird.
Wir haben uns auch nicht "irgendwie auf das X eingenordet", sondern klar nachvollzogen, was es bewirkt.

aus XAB wird 171, weil hex AB = dezimal 171 (A0 + B = 10 * 16 + 11)

Das beispiel ist etwas anders gelagert

local modul = layout:getEventsByName("SC_1")[1]

-- Original structured table
local testState = {
  shortPhase = { "Vo1" },
  longPhase =  { "Vo2" },
  currentMode  = "countDown"
}

-- Store in module variable
modul.variables["BrokenState"] = testState

-- Also store in global variable
_G.goodState = testState

-- Later access (simulate after a timer or defer callback)
local broken = modul.variables["BrokenState"]
local good = _G.goodState

-- Display both
print("From modul.variables:")
for k, v in pairs(broken) do print("  " .. tostring(k), v) end

print("From _G:")
for k, v in pairs(good) do print("  " .. tostring(k), v) end

Ich habe das auf ein minimum reduziert.  Pack das in einen event wo der print funktioniert.
Gruss
Gmd

 

[Goetz]

vor 1 Stunde schrieb gmd:

Pack das in einen event wo der print funktioniert.

kannst du das nicht?
Na gut, bitte sehr:

long and short phase example.mbp

Aber einen Fehler erkenne ich hier nicht!

Warum willst du einen String mit tostring() in einen String wandeln?
Und welches Ergebnis erwartest du, wenn du mit print() versuchst eine ganze Tabelle auszugeben?

Viele Grüße
Götz

Bearbeitet gestern um 10:47 Uhr von Goetz
Nachfragen hinzugefügt

[Goetz]

Hallo Gmd,

aufschlussreicher ist es, den Typ von v auszugeben.
Dann sieht man, was sich ändert wenn eine Tabelle in einer Modul- (oder Objekt-) Variablen gespeichert wird:

local modul = layout:getEventsByName("SC_1")[1]

-- Original structured table
local testState = {
  shortPhase = { "Vo1" },
  longPhase =  { "Vo2" },
  currentMode  = "countDown"
}

-- Store in module variable
modul.variables["BrokenState"] = testState

-- Also store in global variable
_G.goodState = testState

-- Later access (simulate after a timer or defer callback)
local broken = modul.variables["BrokenState"]
local good = _G.goodState

-- Display both
print("From modul.variables:")
for k, v in pairs(broken) do print("  " .. k, type(v)) end

print("From _G:")
for k, v in pairs(good) do print("  " .. k, type(v)) end

 

Viele Grüße
Götz

Bearbeitet gestern um 11:28 Uhr von Goetz
Bilder eingefügt

[EASY]

Hallo,

vor 23 Stunden schrieb Goetz:

aufschlussreicher ist es, den Typ von v auszugeben.
Dann sieht man, was sich ändert wenn eine Tabelle in einer Modul- (oder Objekt-) Variablen gespeichert wird:

@Neo

ich habe das Beispiel von @Goetz etwas erweitert...
 

local modul = layout:getEventsByName("SC_1")[1]

-- Original structured table
local testState = {
  shortPhase = { "Vo1","Vo1a" },
  longPhase =  { "Vo2" },
  currentMode  = "countDown"
}

-- Store in module variable
modul.variables["BrokenState"] = testState

-- Also store in global variable
_G.goodState = testState

-- Later access (simulate after a timer or defer callback)
local broken = modul.variables["BrokenState"]
local good = _G.goodState

print("From testState")
for k, v in pairs(testState) do
print("  " .. k, type(v))
if type(v)=="table" or type(v)=="object" then
   for i,w in ipairs(v) do
     print(k,w,i)
   end
  else
    print(k,v)
  end
end
print()

print("From modul.variables:")
for k, v in pairs(broken) do
print("  " .. k, type(v))
if type(v)=="table" or type(v)=="object" then
   for i,w in ipairs(v) do
     print(k,w,i)
   end
  else
    print(k,v)
  end
end
print()

print("From _G:")
for k, v in pairs(good) do
print("  " .. k, type(v))
if type(v)=="table" or type(v)=="object" then
   for i,w in ipairs(v) do
     print(k,w,i)
   end
  else
    print(k,v)
  end
end

... mit diesem Ergebnis...

... wie Goetz schon angemerkt hat, wird beim Übertragen von "testState" auf die Modulvariable der Typ "table" auf den Typ "object" geändert obwohl die Variable prinzipiell richtig angelegt wird... und bei der Übertragung auf eine globale Variable nicht.

... zum Auslesen wird der typ "object" wieder wie eine Tabelle (Liste) behandelt.

Da ich neugierig bin... hat das einen bestimmten Sinn? Was verbirgt sich hinter dem Typ "object"?

Gruß
EASY

[Goetz]

vor 51 Minuten schrieb EASY:

bei der Übertragung auf eine globale Variable

bleibt es bei Lua.  _G und _Env sind die Tabellen, in denen alle Lua Variablen, Tabellen, Funktionen etc. verwaltet werden.

Aber die Objekt- und Modulvariablen sind nicht Teil von Lua. Die gehören zum Studio und sind Teil einer anderen Struktur.

[EASY]

Hallo,

vor einer Stunde schrieb Goetz:

Aber die Objekt- und Modulvariablen sind nicht Teil von Lua. Die gehören zum Studio und sind Teil einer anderen Struktur.

... danke für die Aufklärung (... immer diese kleinen Feinheiten [über die man stolpert...])

Gruß
EASY