Retrieving table elements using inline Lua

[Yincognito]

This is probably not a bug, maybe an omission or a mismatch between what the manual says and what's available in practice...

The manual:

Inline Lua can also be used to simply retrieve the current value of any variable that that you may set in the Lua, either in Update() or in a Function() that you call with !CommandMeasure or other inline Lua.

In practice:

Code: Select all

function Initialize()
  t, v = {7}, 5
end

Code: Select all

[Rainmeter]
Update=1000
AccurateText=1
DynamicWindowSize=1
BackgroundMode=2
SolidColor=47,47,47,255

---Measures---

[Script]
Measure=Script
ScriptFile=#@#Script.lua
UpdateDivider=-1
DynamicVariables=1

---Meters---

[Result]
Meter=String
FontColor=255,255,255,255
FontFace=Consolas
FontSize=16
Padding=5,5,5,5
AntiAlias=1
Text=Result = [&Script:t[1]]
UpdateDivider=-1
DynamicVariables=1

So, it looks like one cannot get table elements with inline Lua. I can see a potential reason for that behavior as it could maybe cause some confusion in using the square brackets inside a square bracket enclosed inline Lua, but then Rainmeter parses nested variables just fine in similar cases. To check if the brackets were the issue, I also tried the dot referencing of a table element, aka [&Script:t.1], and it didn't work either.

So, should / will this be possible or not, and if not, should the manual be adjusted to mention this particularity of the inline Lua, or should we always go with the somewhat redundant workaround of using a function to retrieve a table element's value?

[jsmorley]

This is probably not a bug, maybe an omission or a mismatch between what the manual says and what's available in practice...

The manual:

In practice:

Code: Select all

function Initialize()
  t, v = {7}, 5
end

Code: Select all

[Rainmeter]
Update=1000
AccurateText=1
DynamicWindowSize=1
BackgroundMode=2
SolidColor=47,47,47,255

---Measures---

[Script]
Measure=Script
ScriptFile=#@#Script.lua
UpdateDivider=-1
DynamicVariables=1

---Meters---

[Result]
Meter=String
FontColor=255,255,255,255
FontFace=Consolas
FontSize=16
Padding=5,5,5,5
AntiAlias=1
Text=Result = [&Script:t[1]]
UpdateDivider=-1
DynamicVariables=1

So, it looks like one cannot get table elements with inline Lua. I can see a potential reason for that behavior as it could maybe cause some confusion in using the square brackets inside a square bracket enclosed inline Lua, but then Rainmeter parses nested variables just fine in similar cases. To check if the brackets were the issue, I also tried the dot referencing of a table element, aka [&Script:t.1], and it didn't work either.

So, should / will this be possible or not, and if not, should the manual be adjusted to mention this particularity of the inline Lua, or should we always go with the somewhat redundant workaround of using a function to retrieve a table element's value?

I think this might be alluded to here:

https://docs.rainmeter.net/manual/lua-scripting/inline-lua/#Notes

Lua tables, myTable[index], may not be directly used in a parameter to the Lua function, you will need to pass the table name and the index number or string as separate parameters and use them to access the table in Lua. However, the Lua may return a single value from a table with return myTable[index]. The TranslateDay example below demonstrates this.

[Yincognito]

I think this might be alluded to here:

https://docs.rainmeter.net/manual/lua-scripting/inline-lua/#Notes

Indeed, though it only refers to functions(), which was quite clear otherwise from this:
https://docs.rainmeter.net/manual/lua-scripting/inline-lua/#CallingAFunction
where it only mentions the number, boolean, string and nil types of parameters that can be passed to the Lua function().

In other words, the reader might think it's perfectly fine to try and retrieve table elements as variables (and not functions) instead.
Or maybe I'm just too pedantic here, which I'm usually not...

P.S. Another thing that differentiate the two is that in terms of code (which might not be the same internally, of course), the reference to a variable is an identifier / name, and not a parameter / value.

[jsmorley]

Indeed, though it only refers to functions(), which was quite clear otherwise from this:
https://docs.rainmeter.net/manual/lua-scripting/inline-lua/#CallingAFunction
where it only mentions the number, boolean, string and nil types of parameters that can be passed to the Lua function().

In other words, the reader might think it's perfectly fine to try and retrieve table elements as variables (and not functions) instead.
Or maybe I'm just too pedantic here, which I'm usually not...

Just the right amount of pedantic really. I'll look at adjusting the manual.

[Yincognito]

Just the right amount of pedantic really. I'll look at adjusting the manual.

Sure thing - see my P.S. for better clarity, if needed.

[jsmorley]

The underlying issue is that the "glue" functionality that binds Rainmeter and Lua together just doesn't support any direct reference to any table indexes through the interface. Not as a function parameter, not as a variable retrieval, just not at all.

As mentioned, the only way is to pass the name of the table and the index desired as separate parameters, and using a function() in Lua, get and return the desired value.

[jsmorley]

See, your example:

Code: Select all

function Initialize()
  t, v = {7}, 5
end

Means that the variable "t" is actually a table object in Lua. That can't be addressed directly in Rainmeter.

What I mean is that the functionality of a table is built into Lua, Lua understands tables completely. Rainmeter has no idea what a Lua table is all about, nor any idea how to even begin dealing with it. When you do anything that asks Rainmeter to get a table index from Lua, the only way that can happen is if the Lua resolves the value first, and passes it as a value to Rainmeter. The glue functionality between Rainmeter and Lua just doesn't make any attempt to replicate the functionality in Lua supporting tables.

[Yincognito]

The underlying issue is that the "glue" functionality that binds Rainmeter and Lua together just doesn't support any direct reference to any table indexes through the interface. Not as a function parameter, not as a variable retrieval, just not at all.

As mentioned, the only way is to pass the name of the table and the index desired as separate parameters, and using a function() in Lua, get and return the desired value.

Of course. I've been doing the same in my scripts as well in the past, getting table elements through functions and all, it just seemed appropriate to mention it for a better understanding by other potential readers, or, if by any chance it was the case (which is not, as you just mentioned) to allow such references when retrieving a variable.

Means that the variable "t" is actually a table object in Lua. That can't be addressed directly in Rainmeter.

Indeed. It makes some sense judging by how Rainmeter operates otherwise, since nearly all, if not all measures in a skin must return a single value, while a table is by definition a set of (multiple) values encapsulated in the object you mentioned. Same for a return somevalue, anothervalue from a Lua function.

[jsmorley]

I made the following change to the Inline Lua section:

https://docs.rainmeter.net/manual/lua-scripting/inline-lua/#Notes

1.jpg

Feel free to suggest more / other changes you think appropriate.

[Yincognito]

I made the following change to the Inline Lua section:

https://docs.rainmeter.net/manual/lua-scripting/inline-lua/#Notes


1.jpg


Feel free to suggest more / other changes you think appropriate.

Thanks, I think it's an excellent change.

Personally, I would have written it even simpler, as "or as a way of retrieving a variable from Lua" instead of "or as a reference to a table object set as a variable in Lua", since it's shorter and makes an obvious connection to the "Retrieving a Variable" chapter earlier - might matter for non native speakers or people reading it for the first time. The way you put it might be more technically accurate though, so I'll let you decide on that. For me, after already knowing what's all about, mentioning this is enough, thanks again for considering it.