File size problem in lua

[balala]

Wow! I had no idea you could get file sizes that way!

Me neither, however Google is my (and probably yours as well) friend!

[Brian]

So, in short, this isn't a file size problem in Lua, it is a parsing problem in Rainmeter.

You are correct, this is a parsing problem, specifically with the nesting syntax.

When the parser searches for section variables within brackets and doesn't find a variable, the parser starts again after the ending bracket - totally skipping any other section variables before that previous ending bracket.

The parsing function basically does this: Find the first ending bracket, then from that position, reverse find the starting bracket. This usually finds the inner-most section variable. However, if the inner most brackets do not represent a variable, the next starting point for the parser is after that first ending bracket.

The problem is, after it finds the next ending bracket and when it searches again for the starting bracket, it should start BEFORE that last occurrence of the staring bracket.

Here's a basic breakdown:

Code: Select all

"^" means the next occurrence of the ending bracket
"|" means the next occurrence of the starting bracket (reverse find from ending bracket)


First pass:
[&Script:Function([3].png)] Other Text [MeasureName]
                  | ^
Result of first pass: No substitutions. Variable evaluated: "3" (doesn't exist)


Second pass:
[&Script:Function([3].png)] Other Text [MeasureName]
                  |       ^
Result of second pass: No Substitutions. Variable evaluted: "3].png)" (obviously doesn't exist)


Third pass:
[&Script:Function([3].png)] Other Text [MeasureName]
                                       |           ^
Result of third pass: Substitution occurs (if it exists). Variable evaluated: MeasureName (if it exists)

Hopefully that makes.

This hasn't come up before since skins are usually carefully crafted with respect to brackets, since they represent section names.

I will attempt to fix this parsing issue shortly, but it might not solve all the issues. For instance, in this case, if there was a measure named [3], then that measure's value would replace [3], even though the skin author meant to reference an actual file that contained [3] in it, like File[3].png (which is a totally valid filename). I am not sure how best to stop the parsing of section names when it is not desired.

-Brian

[SilverAzide]

I will attempt to fix this parsing issue shortly, but it might not solve all the issues.

Wow... this seems a somewhat insurmountable problem! Best of luck on this challenge!

[Yincognito]

You are correct, this is a parsing problem, specifically with the nesting syntax.
[...]
-Brian

I'll use this thread instead of creating another one, taking advantage that you'll be working on this issue, and ask: is there any way to combine Lua's inline syntax with the section variable parameters? I'm thinking of something like:

Code: Select all

[&MS_Script_Timer:td:/100]

where MS_Script_Timer is my Script measure, td is a Lua variable holding a number / string made of 3 digits (i.e. from '000' to '999' or if I convert it to a number in Lua, from 0 to 999), and the idea of dividing this by 100 is to shorten a specific display of it in the skin down to just its first digit without creating another variable for that purpose.

If it's not possible yet, can it be reasonably easily implemented, since you're working on such related parsing? I'll take a no for an answer, I just wanted to find out if such a syntax combination is possible or not.

If anyone is interested, this is part of my newly developed Lua timer, which looks like:

Code: Select all

function Initialize()
  state, th, tm, ts, td, ih, im, is, id, value, pt, ct, dt, it = 'Idle', '00', '00', '00', '000', '00', '00', '00', '000', '', os.clock(), 0, 0, 0
end

function Update()
  ct = os.clock()
  if state == 'Reset' then st = ct elseif state == 'Start' or state == 'Idle' then st = ct - dt end
  dt = ct - st
  td = string.format('%03d', math.floor(dt * 1000 % 1000))
  ts = string.format('%02d', math.floor(dt % 60))
  tm = string.format('%02d', math.floor(dt % 3600 / 60))
  th = string.format('%02d', math.floor(dt / 3600))
  if state ~= 'Idle' and state ~= 'Busy' then it = ct - pt; pt = ct end
  id = string.format('%03d', math.floor(it * 1000 % 1000))
  is = string.format('%02d', math.floor(it % 60))
  im = string.format('%02d', math.floor(it % 3600 / 60))
  ih = string.format('%02d', math.floor(it / 3600))
  if state ~= 'Idle' and state ~= 'Busy' then value = (state == 'Reset' and '' or value .. '∆ ' .. state .. ' (total: ' .. th .. ':' .. tm .. ':' .. ts .. '.' .. td .. ', interval: ' .. ih .. ':' .. im .. ':' .. is .. '.' .. id .. ')\n') end
  state = ((state == 'Start' or state == 'Split' or state == 'Busy') and 'Busy' or 'Idle')
  return value
end

function StartPause()
  if state == 'Idle' then state = 'Start' else state = 'Pause' end
  return true
end

function ResetSplit()
  if state == 'Idle' then state = 'Reset' else state = 'Split' end
  return true
end

with the relevant skin part like:

Code: Select all

[MT_Rainmeter_Time]
Meter=String
MeterStyle=SCell | SPrimaryColText
Text="[&MS_Script_Timer:th]:[&MS_Script_Timer:tm]:[&MS_Script_Timer:ts].[&MS_Script_Timer:td:/100]"

Basically, the td variable holds the number of milliseconds in the timer, which I'm trying to fit in a limited space in the skin (letting it full in the tooltip though).

EDIT: Just tried a nested syntax like Text=".[&[&MS_Script_Timer:td]:/100,0]" and it didn't work either.
EDIT2: In the end I managed to fit everything as desired without shortening stuff, but I'd still be interested if the above is possible, out of curiosity.

[Yincognito]

However, is there any solution? Can you find a solution?

Besides the few solutions and ideas already provided - including yours - here's another one:
Script.lua:

Code: Select all

function Function(variable)
  variable = variable:gsub('&%S-;', {['['] = '[', [']'] = ']'})
  return variable
end

Test.ini:

Code: Select all

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1

---Measures---

[FileName]
Measure=String
String=[3].png
Substitute="[":"[","]":"]"
UpdateDivider=-1

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

---Meters---

[MeterTest]
Meter=String
FontFace=Consolas
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
Text="Script = [&Script:Function('[&FileName]')]"
UpdateDivider=-1
DynamicVariables=1

This basically uses the character reference encoding from HTML to turn the brackets into corresponding encodings before sending them to Lua, then turn the encodings back into brackets once they safely got into Lua. I used Brian's simplified syntax above, instead of your specific example.

I am not sure how best to stop the parsing of section names when it is not desired.

Using something similar to magic quotes but for brackets, regex escaping but for brackets, or a new section variable parameter designed for this purpose are some options. Unfortunately, none of them work at this time, but luckily this is not a no alternative situation, as already mentioned in this thread. Even 'lame' alternatives, like SilverAzide said, can still get the expected result.

[balala]

I will attempt to fix this parsing issue shortly, but it might not solve all the issues.

Ok, let's see how will this work. Thank you for all your work.

[balala]

Besides the few solutions and ideas already provided - including yours - here's another one:

To be honest don't really realize what are you trying to tell me with this code. The skin doesn't return the size of the file, or am I just missing something?

[Yincognito]

To be honest don't really realize what are you trying to tell me with this code. The skin doesn't return the size of the file, or am I just missing something?

As I said in the same reply...

I used Brian's simplified syntax above, instead of your specific example.

The issue is more or less about square brackets in an inline Lua string. The fact that you encountered it while working to get a file's size is not that relevant to the problem at hand. That being said, I am indeed at fault of not making my code suit yours - pardon my lazyness. I guess I hoped you could adapt the code yourself to your case, if that was needed (but then you found a feasible solution already, so I skipped that).

In other words, all you need to do to make it work is to add a substitute like mentioned to your file name measure(s) and then convert the "encoded" parts back into brackets in Lua using a similar gsub() ...

[balala]

As I said in the same reply...

The issue is more or less about square brackets in an inline Lua string. The fact that you encountered it while working to get a file's size is not that relevant to the problem at hand. That being said, I am indeed at fault of not making my code suit yours - pardon my lazyness. I guess I hoped you could adapt the code yourself to your case, if that was needed (but then you found a feasible solution already, so I skipped that).

In other words, all you need to do to make it work is to add a substitute like mentioned to your file name measure(s) and then convert the "encoded" parts back into brackets in Lua using a similar gsub() ...

Right, now makes sense. Thank you for the suggestion, even if in meantime, as you saw, I switched to another solution. But it's good to see all the help we can get here.

[Yincognito]

Right, now makes sense. Thank you for the suggestion, even if in meantime, as you saw, I switched to another solution. But it's good to see all the help we can get here.

Indeed - no problem. Whatever solution works for your case, it is the right one. Just thought of offering alternatives, even though I'm sure SilverAzide already described in words what I just wrote. Of course, the "encoding" doesn't have to be the HTML one, any encoding would work, as long as it doesn't "conflict" (i.e. is less likely to be part of) actual filenames. My favorite way to avoid such resemblances is to use the zero width space character (aka [\x200B]) somewhere in the said "encoding", as that is very unlikely to be found in any normal text, including paths or filenames.