Trunc(x)/Franc(x) in lua

[jsmorley]

To be honest though, there is no great advantage to defining variables as "local" in our implementation of the interface between Lua and Rainmeter. Each Lua script runs in its own "tablespace", which means that all variables, local or not, are in fact local to that script measure. The only real reason to define a variable as "local" would be to allow using the same variable name in different contexts within the script, and getting different results. I'm not sure I see a good use case for that.

There really isn't a "global-global" construct, in the sense that setting a variable in one Lua Script measure can be seen by a different Lua Script measure. The Lua Script measures are "sandboxed" in their own distinct Lua environments.

[jsmorley]

Another use for "local" that I can envision is if you have a function that just does a boatload of calculating, creating a huge number of variables or table entries in order to arrive at a result, and at the end simply "returns" a single value that is the result of all that work.

In that case, making the variables and tables that are only used in the context of that function "local" means that when the function is complete, the variables and tables are "released" from memory, which in an extreme example could be a bit more "memory efficient". It would have to be a boatload indeed though, to make any real difference.

[jsmorley]

An example of using "local" that way is:

Code: Select all

function Function1()

	myVar1 = 5
	myVar2 = Function2()
		
	return myVar2
		
end

function Function2()

	local numToAdd = 10 + 10
	return numToAdd + myVar1

end

So numToAdd only exists in the context of Function2(), and isn't maintained outside of that context.

[kyriakos876]

Right... I was using "local" as a memory efficiency technique, but I now realize that my script will run for a good 100ms? And does little to no calculations, compared to what can be considered enough to even start to stress a CPU.
I made all my variables global and nothing changed, except for a part where I was using the same variable name while I wanted a different result as you said above. Changed the name to avoid confusing myself in the future and made that global as well. A plus also is that, now, I don't need to pass it in every function that's going to use it, or even worse call it again, adding up unnecessary lines of code.

Thanks, and sorry for any inconvenience I may have caused.

[jsmorley]

Right... I was using "local" as a memory efficiency technique, but I now realize that my script will run for a good 100ms? And does little to no calculations, compared to what can be considered enough to even start to stress a CPU.
I made all my variables global and nothing changed, except for a part where I was using the same variable name while I wanted a different result as you said above. Changed the name to avoid confusing myself in the future and made that global as well. A plus also is that, now, I don't need to pass it in every function that's going to use it, or even worse call it again, adding up unnecessary lines of code.

Thanks, and sorry for any inconvenience I may have caused.

It's all good!

[jsmorley]

I'm not opposed to, nor discouraging, fine tuning for maximum efficiency. There is some charm to that, no matter small the benefit. As long as you understand how local works and doesn't work, I'm all for using it and being as anal-retentive as possible in your code.

[kyriakos876]

I'm not opposed to, nor discouraging, fine tuning for maximum efficiency. There is some charm to that, no matter low small the benefit. As long as you understand how local works and doesn't work, I'm all for using it and being as anal-retentive as possible in your code.

If you don't mind checking this out, I can't figure something out... Please get the skin below load the Calendar.ini
Then open the #@#DaysOfFebruary.lua and check line 110 that says
monthLua = tostring(SKIN:GetVariable('CurrentMonth'))
now that is global so no matter where I put it, I can call it from everywhere.
Now copy that line, delete it, and move it in the initialize function on the very top of the script.
Then on the loaded skin, click the meter that says Update (Dev) and you will see an error in the log that comes back to changing this variable from inside the function to the initialize function. Why is it that when I move this GLOBAL variable I get an error related to it? It's GLOBAL inside the function and it's also GLOBAL in the initialize function which is called whenever the script is called (if I'm not wrong).

Btw, don't mind the syntax error in the log. It works fine even while throwing that.

[jsmorley]

Initialize() is run one time, when the skin is refreshed. The important bit is that it is run BEFORE the rest of the skin is updated the first time, so any [Variables] that you create in the skin are not available yet to the Initialize() function. Don't resolve them there. Either resolve them in an Update() function that you set with UpdateDivider=-1 (if they are static variables), or have an OnRefreshAction in the [Rainmeter] section of the skin that calls a GetSkinVars() function or some such.

[kyriakos876]

Initialize() is run one time, when the skin is refreshed. The important bit is that it is run BEFORE the rest of the skin is updated the first time, so any [Variables] that you create in the skin are not available yet to the Initialize() function. Don't resolve them there. Either resolve them in an Update() function that you set with UpdateDivider=-1 (if they are static variables), or have an OnRefreshAction in the [Rainmeter] section of the skin that calls a GetSkinVars() function or some such.

oooooh okay.... I get it... I will keep it in the function then.