Lua for conditional operators with strings as result.

[Yincognito]

So while testing your SectionIndex function, I encountered another error regarding invalid options.

If you have for example

Code: Select all

[Meter5]
Meter=String
Y=50

[Another5Meter]
Meter=String
Y=([&Meter[&S:SI()]:Y])

You get the error: Formula: "[" is unknown: ([&Meter0:Y])

if you take the () out eg. Y=[&Meter[&S:SI()]:Y] , then there's no problem. In this example this is possible, but when math is absolutely needed, then we have a stone in the shoe lol.

This, as the container one, can be "fixed" by having a dummy [Meter0], but yeah well, not everyone might like having dummy meters all around.

IF the error persists beyond the initial skin load (which might be more or less normal, given how Rainmeter's Lua works), you should add this to the bug report I posted here, to help narrow the cause of it and maybe shed some light on why it happens:
https://forum.rainmeter.net/viewtopic.php?t=44706
Also, you could try using either the long versions of it from the bug report, or the ones in the other thread, to see if it changes anything. Those versions are basically identical except one is using long names and a variable number of arguments (in the bug report), and one is using long names and a fixed number of arguments (in the other thread). If, as I suspect, the issue is related to the variable number of arguments, requesting the value of CURRENTSECTION, a tricky syntax to parse, or a combination of them, it could indicate the actual culprit.

From my point of view, the function is correctly written and working perfectly in other cases, so the problem must be elsewhere...

[RicardoTM]

I can't test right now as I'm on the phone, but no, the error is exactly the same as the other cases, it only shows on first load and refresh without affecting the functionality.

However, I did test both with the earlier "sectionIndex" function and with the newer "SI" function, both giving the same results.

Maybe later, or tomorrow I can test a little bit more, since today's busy day.

One workaround that has come to my mind but I haven't tested, is using lua for the math that requires the use of the function. Something like:

Y=[&S:Math([&Meter[&S:SI()]:Y])]

[Yincognito]

I can't test right now as I'm on the phone, but no, the error is exactly the same as the other cases, it only shows on first load and refresh without affecting the functionality.

However, I did test both with the earlier "sectionIndex" function and with the newer "SI" function, both giving the same results.

Maybe later, or tomorrow I can test a little bit more, since today's busy day.

One workaround that has come to my mind but I haven't tested, is using lua for the math that requires the use of the function. Something like:

Y=[&S:Math([&Meter[&S:SI()]:Y])]

Not sure what "Math()" function you're referring to, but I tested now with the SectionIndex() functions from the other thread, and indeed my reported bug and the load error still occur, while the positioning of the meter works otherwise (bar the initial error). Meaning that only the reported bug is actually not working.

[RicardoTM]

Sorry, I was referring to a hypothetical Math() function.

I was thinking of something like:

Code: Select all

function Math(formula)
 return math(formula)
end

Obviously I ignore if that syntax would work lol maybe not.

I digress, I have only tested for the invalid option error and not for the bug you refer on your other thread. I guess if you do something like Y=([&S:SI()]+[&S:sectionIndex('[#CurrentSection]','first','<x>')]) the bug would appear as well.

[RicardoTM]

I just tested it real quick, and it doesn't cause any error, couriously.

Code: Select all

[Num8ber94]
Measure=Calc
Formula=([&S:SectionIndex('[#CurrentSection]','first','<x>')] + [&S:SI()])
UpdateDivider=-1
DynamicVariables=1

This correctly returns 102 (8+94)

[Yincognito]

I just tested it real quick, and it doesn't cause any error, couriously.

Yeah, even in the bug report, it returns in most cases while it doesn't on harmless changes like swapping parts of the code.

If it wouldn't work at all I would understand that the problem was in the function, but since the latter usually works there's a really strange thing going on. It's not my first time when using Function(...) or getting CURRENTSECTION from Lua, and these should work. By the way, not just SKIN:GetVariable() doesn't work in providing the value of CURRENTSECTION in the SI(), but also SKIN:ReplaceVariables() - something you can easily see if trying to print() either of them in the beginning of the function (I'm still talking about the bug report case or similar).

But of course the initial error is a different thing, being mentioned in the manual (see Important Final Note there) and having a negative impact only at (or better said, before) the skin load time, given that afterwards the correct value is always provided.

[RicardoTM]

Yeah, even in the bug report, it returns in most cases while it doesn't on harmless changes like swapping parts of the code.

If it wouldn't work at all I would understand that the problem was in the function, but since the latter usually works there's a really strange thing going on. It's not my first time when using Function(...) or getting CURRENTSECTION from Lua, and these should work. By the way, not just SKIN:GetVariable() doesn't work in providing the value of CURRENTSECTION in the SI(), but also SKIN:ReplaceVariables() - something you can easily see if trying to print() either of them in the beginning of the function (I'm still talking about the bug report case or similar).

But of course the initial error is a different thing, being mentioned in the manual (see Important Final Note there) and having a negative impact only at (or better said, before) the skin load time, given that afterwards the correct value is always provided.

So, I've tested with 3 functions after the OV function. Both SectionIndex and SI are returning 0 only if they are placed after OV, they both work fine if they're before OV. Both SectionIndex and SI have one thing in common: SKIN:ParseFormula.

Code: Select all

function OV(...) local s = arg[1] or SKIN:GetVariable('CURRENTSECTION'); local f, v = SKIN:GetMeasure(s), SKIN:GetMeter(s); return ((f or v) and (f or v):GetOption(arg[2] or (f and 'Measure' or 'Meter'), '', arg[3]) or '') end

function SI(...) local I = {}; for i in (arg[1] or SKIN:GetVariable('CURRENTSECTION')):gmatch('%d+') do I[#I+1] = i end; return tostring(SKIN:ParseFormula((arg[3] or 'i'):gsub('i', I[arg[2] or #I] or '0'))) or '0' end

function SectionIndex(section, occurrence, formula)
  local indexes = {}
  for index in section:gmatch('%d+') do table.insert(indexes, index) end
  if occurrence == 'first' then occurrence = 1 elseif occurrence == 'last' then occurrence = #indexes end
  return tostring(SKIN:ParseFormula(string.gsub(formula, '<x>', tostring(indexes[tonumber(occurrence)] or '0')))) or '0'
end

So I've added this other function to the test with SKIN:parseFormula:

Code: Select all

function cond2(cond_str, true_str, false_str)
    if SKIN:ParseFormula(SKIN:ReplaceVariables(cond_str)) == 1 then
        return true_str
    else
        return false_str
    end
end

That's one of the conditional functions discussed here on this topic. So as I suspected, it doesn't work correctly. This is the measure:

Code: Select all

[12]
Measure=String
String=[&S:OV()][&S:cond2('([#CurrentSection]=12)','1','2')]
UpdateDivider=-1
DynamicVariables=1

it incorrectly returns "String2", instead of the expected "String1" (since the statement 12=12 is true).

If I do the oposite:

Code: Select all

[12]
Measure=String
String=[&S:cond2('([#CurrentSection] = 12)','1','2')][&S:OV()]
UpdateDivider=-1
DynamicVariables=1

Now the result is "1String" which is correct.

So, now to try to be sure, I added another function, the simplest:

Code: Select all

function con(cond, true_str, false_str)
    if cond == 0 then
        return false_str
    else
        return true_str
    end
end

If I place it before OV, the result is "1String" as expected

Code: Select all

[12]
Measure=String
String=[&S:con(([#CurrentSection] = 12),'1','2')][&S:OV()]
UpdateDivider=-1
DynamicVariables=1

However, if I do the oposite.

Code: Select all

[12]
Measure=String
String=[&S:OV()][&S:con(([#CurrentSection] = 12),'1','2')]
UpdateDivider=-1
DynamicVariables=1

The result is: String[&S:con(( = 12),'1','2')]

This took me to test without any other function:

Code: Select all

[12]
Measure=String
String=[&S:OV()][#CurrentSection]
UpdateDivider=-1
DynamicVariables=1

Which, only returns: "String" (the oposite does return 12String correctly).

Whatever is causing this is inside the OV function, since I can use any other function with as many [#CurrentSection]s as I want and they work properly.

Code: Select all

[12]
Measure=String
String=[&S:SI()]-[#CurrentSection]-[&S:con(([#CurrentSection] = 12),'1','2')]-[&S:cond2('([#CurrentSection] = 12)','1','2')]
UpdateDivider=-1
DynamicVariables=1

This returns 12-12-1-1 which is correct.

However this:

Code: Select all

[12]
Measure=String
String=[&S:SI()]-[#CurrentSection]-[&S:con(([#CurrentSection] = 12),'1','2')]-[&S:cond2('([#CurrentSection] = 12)','1','2')]-[&S:OV()]-[&S:SI()]-[#CurrentSection]-[&S:con(([#CurrentSection] = 12),'1','2')]-[&S:cond2('([#CurrentSection] = 12)','1','2')]
UpdateDivider=-1
DynamicVariables=1

returns: 12-12-1-1-String-0--[&S:con(( = 12),'1','2')]-2

*Note I just placed the same before and after [&S:OV()]. The correct result should be 12-12-1-1-String-12-12-1-1

Finally, I tested the same with the long version of the OV function: OptionValue but without using [#CurrentSection], I simply used the name of the measure directly (12)

Code: Select all

[12]
Measure=String
String=[&S:SI()]-[#CurrentSection]-[&S:con(([#CurrentSection] = 12),'1','2')]-[&S:cond2('([#CurrentSection] = 12)','1','2')]-[&S:OptionValue('12','Measure',nil)]-[&S:SI()]-[#CurrentSection]-[&S:con(([#CurrentSection] = 12),'1','2')]-[&S:cond2('([#CurrentSection] = 12)','1','2')]
UpdateDivider=-1
DynamicVariables=1

Surprisingly, this doesn't work either, the result is the same: 12-12-1-1-String-0--[&S:con(( = 12),'1','2')]-2

So, I've started changing sections, like selecting other measure/meters and the result was the same, then I tried various options with the same result, until I changed option to nil, then the result was: 12-12-1-1--12-12-1-1

So maybe the problem has more to do with GetOption and little with [#CurrentSection].

To test further, I wrote this dummy function:

Code: Select all

function OptionValue2(section, option, resolve)
  return ((SKIN:GetMeasure(section) or SKIN:GetMeter(section)) and option or '')
end

I said dummy because all it does is to return 'option' if the section exists. I just did it to remove the GetOption part of the original function. It works.

Code: Select all

[12]
Measure=String
String=[&S:SI()]-[#CurrentSection]-[&S:con(([#CurrentSection] = 12),'1','2')]-[&S:cond2('([#CurrentSection] = 12)','1','2')]-[&S:OptionValue2('[#CurrentSection]','Hola',nil)]-[&S:SI()]-[#CurrentSection]-[&S:con(([#CurrentSection] = 12),'1','2')]-[&S:cond2('([#CurrentSection] = 12)','1','2')]
UpdateDivider=-1
DynamicVariables=1

This correctly returns: 12-12-1-1-Hola-12-12-1-1. Notice I used [#CurrentSection] on all functions this time.

Sorry for the super long post, I'm typing as I'm testing.

[Yincognito]

This correctly returns: 12-12-1-1-Hola-12-12-1-1. Notice I used [#CurrentSection] on all functions this time.

Thanks for testing this out! While in both your 'surprising' and 'dummy' tests you actually requested twice CURRENTSECTION from Lua in the SI() function - as its 1st occurrence could potentially sabotage the 2nd one -, the 'dummy' test does indeed seem to indicate that CURRENTSECTION might not be the problem. Might worth to link these tests / discussion to the bug report if you can. If not, I'll do it either later on today or tomorrow. Thanks again for taking the time to explore this!

[RicardoTM]

Thanks for testing this out! While in both your 'surprising' and 'dummy' tests you actually requested twice CURRENTSECTION from Lua in the SI() function - as its 1st occurrence could potentially sabotage the 2nd one -, the 'dummy' test does indeed seem to indicate that CURRENTSECTION might not be the problem. Might worth to link these tests / discussion to the bug report if you can. If not, I'll do it either later on today or tomorrow. Thanks again for taking the time to explore this!

I was on my cousin's birthday party earlier, I had more fun testing this than on that party lol.

I'll repost it on your thread and link to this discussion as well.

Done

[Yincognito]

I was on my cousin's birthday party earlier, I had more fun testing this than on that party lol.

I'll repost it on your thread and link to this discussion as well.

Ouch, it was that bad?
Just joking, may he live to throw better and better parties - and thanks! A good mystery is sometimes more interesting than mundane stuff, though both should be appreciated while they last.