Try this:
Code: Select all
function Initialize()
i=0
loadstring("print(i+1)")()
end
Code: Select all
function Initialize()
i=0
loadstring("print(i+1)")()
end
Code: Select all
function Initialize()
i=0
loadstring("print(" .. (i + 1) .. ")")()
end
Code: Select all
function Initialize()
loadstring("local i = 0; print(i + 1)")()
end
No, actually it's not. It can access global variables, just not local.Brian wrote: ↑September 10th, 2021, 11:09 pm I think you have to do string concatenation for this to work since loadstring cannot access variables directly.
If I'm not mistaken, loadstring declares a "chunk" of code to be executed later (or in this case, the trailing () calls the function).Code: Select all
function Initialize() i=0 loadstring("print(" .. (i + 1) .. ")")() end
Another option might be:-BrianCode: Select all
function Initialize() loadstring("local i = 0; print(i + 1)")() end
I think it's something in the compiler, because in the log it says, Attempt to do arithmetic on global i, a nil value, which it isn't.However, the two codes are not completely equivalent, because loadstring does not compile with lexical scoping. To see the difference, let us change the previous examples a little:
local i = 0
f = loadstring("i = i + 1")
g = function () i = i + 1 end
The g function manipulates the local i, as expected, but f manipulates a global i, because loadstring always compiles its strings in a global environment.
The most typical use of loadstring is to run external code, that is, pieces of code that come from outside your program. For instance, you may want to plot a function defined by the user; the user enters the function code and then you use loadstring to evaluate it. Note that loadstring expects a chunk, that is, statements. If you want to evaluate an expression, you must prefix it with return, so that you get a statement that returns the value of the given expression.
That online compiler uses Lua 5.3. Rainmeter uses Lua 5.1.5.death.crafter wrote: ↑September 11th, 2021, 3:00 am No, actually it's not. It can access global variables, just not local.
Check out the execution here.
Hmm, not sure really. I suspect this has to do with each script is considered a non-global environment. Meaning you can load several scripts per skin (or in different skins) and they have their own environment....meaning multiple scripts can use the same function names/variables etc.death.crafter wrote: ↑September 11th, 2021, 3:00 am No, actually it's not. It can access global variables, just not local.
Check out the execution here.
Also the lua documentation:
I think it's something in the compiler, because in the log it says, Attempt to do arithmetic on global i, a nil value, which it isn't.
Code: Select all
function Initialize()
i = 0
local func = loadstring("print (i + 1)")
setfenv(func, getfenv())
func()
--loadstring("local i = 0; print(i + 1)")()
end
I just figured it out and was gonna ask, is a script measure really global?
Code: Select all
loadstring("i=1")()
function Initialize()
loadstring("print(i+1)")()
end
But I can make a dostring() function using setfenv(). Thanks for the information.Brian wrote: ↑September 11th, 2021, 4:23 amCode: Select all
function Initialize() i = 0 local func = loadstring("print (i + 1)") setfenv(func, getfenv()) func() --loadstring("local i = 0; print(i + 1)")() end
We tried to upgrade a while back (2017), but it literally broke most existing scripts. The problem with LUA is that the authors often add or remove functions that break existing scripts. For most (non-Rainmeter) LUA users, upgrading a script is easy since it's not like these breaking changes happen all that often.death.crafter wrote: ↑September 11th, 2021, 4:32 am P.S. shouldn't we upgrade to Lua 5.3? Ofc, I don't have any idea of the amount of work involved. So just asking.
Ohh I see. Backwards compatibility holds back Rainmeter a lot.Brian wrote: ↑September 11th, 2021, 4:50 am We tried to upgrade a while back (2017), but it literally broke most existing scripts. The problem with LUA is that the authors often add or remove functions that break existing scripts. For most (non-Rainmeter) LUA users, upgrading a script is easy since it's not like these breaking changes happen all that often.
For Rainmeter, the problem is we have tens of thousands of skins out there. Quite a few of them use LUA scripts. If all the sudden those skins no longer work correctly, people either complain to us that something is broken, or they stay on a old version of Rainmeter....or worse, they stop using Rainmeter altogether.
We will probably leave LUA at 5.1.5.
However, we open to running different versions of LUA simultaneously if someone wants to submit the changes for it. If it is possible.
-Brian
Well, I wouldn't exactly say backwards compatibility "holds back Rainmeter a lot"; it's more like: backwards compatibility "prevents a firehose of whining and screaming on the forums and DA and every other place about 'your skin is broken!' or 'Rainmeter doesn't work!' or 'you guys suck!' or etc etc..."death.crafter wrote: ↑September 11th, 2021, 5:09 am Ohh I see. Backwards compatibility holds back Rainmeter a lot.