It is currently September 16th, 2019, 11:26 pm

Escaping %N at display time

Help with creating, editing & fixing problems with skins
User avatar
jsmorley
Developer
Posts: 19456
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Escaping %N at display time

jsmorley » March 10th, 2019, 4:11 pm

This can be demonstrated with a skin like this:

Code: Select all

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

[Variables]

[MeasureFile]
Measure=WebParser
URL=file://#CURRENTPATH#Test.html
RegExp=(?siU)<item>(.*)</item>
UpdateRate=5

[MeasureValue]
Measure=WebParser
URL=[MeasureFile]
StringIndex=1
UpdateDivider=-1
OnChangeAction=[!Log "Child changed"]

[MeterValue]
Meter=String
MeasureName=MeasureValue
FontSize=13
FontWeight=400
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
AntiAlias=1
Test.html:

Code: Select all

<item>Value 1</item>

Run this, and in your text editor, change the string "Value 1" to "Value 99" or whatever, and save that.

Within 5 seconds, the value of [MeasureValue] will change, and that change will be reflected in [MeterValue], but the OnChangeAction will never be fired.

This will in fact be true, in exactly the same way, if you set Disabled=1 on [MeasureValue]. You simply can't disable the string value of the measure, which is set by the parent.
Yincognito
Posts: 652
Joined: February 27th, 2015, 2:38 pm

Re: Escaping %N at display time

Yincognito » March 10th, 2019, 5:08 pm

jsmorley wrote:
March 10th, 2019, 4:11 pm
Within 5 seconds, the value of [MeasureValue] will change, and that change will be reflected in [MeterValue], but the OnChangeAction will never be fired.
I asked in order to know if it would cause issues like CPU usage increase (or example, somehow generate an endless loop or something - you were once talking with balala on this and I thought of eliminating all the invalid possibilities as to what would cause such a CPU increase). Other than that, I update the WebParser child using an !UpdateMeasureGroup bang from within the parent's FinishAction anyway, so I never had any issues with something not updating. I'm even doing like this in the Weather skin - that's just how I always update WebParser children.
jsmorley wrote:
March 10th, 2019, 4:11 pm
This will in fact be true, in exactly the same way, if you set Disabled=1 on [MeasureValue]. You simply can't disable the string value of the measure, which is set by the parent.
Yeah, my intention wasn't to disable the string value of the measure, but to be sure it won't fire unexpectedly (which would probably result in a CPU spike) unless on demand. Apart from this, I wasn't using it before, but now I've "disabled" the string value of both WebParser (parent+child) by [!CommandMeasure WebParserParentMeasure "Reset"] anyway. Their values are both empty, yet the CPU usage stays the same, LOL. It seems like I'm playing hide and seek with the cause of this increase... :twisted:
User avatar
jsmorley
Developer
Posts: 19456
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Escaping %N at display time

jsmorley » March 10th, 2019, 5:17 pm

I would point out that regular expression can be VERY expensive on a long string if it isn't carefully optimized.
User avatar
jsmorley
Developer
Posts: 19456
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Escaping %N at display time

jsmorley » March 10th, 2019, 5:25 pm

What I'm getting at with that is two-fold.

1) If you have a RegExpSubstitute on a String measure that is thousands of lines and 10's of thousands of characters long, each of the separate Substitute components will do a search and replace in the entire string for each component of the Substitute.

2) A poorly constructed regular expression can easily cause tons of "backtracking" through the string in order to resolve all the conditions. I'm no expert in regular expression for sure, but I have seen discussions about this that can get pretty scary on a really long chunk of text.

Not saying that regular expression / substitute is the issue, but it's one more thing to explore.
Yincognito
Posts: 652
Joined: February 27th, 2015, 2:38 pm

Re: Escaping %N at display time

Yincognito » March 10th, 2019, 5:42 pm

jsmorley wrote:
March 10th, 2019, 5:17 pm
I would point out that regular expression can be VERY expensive on a long string if it isn't carefully optimized.
Yeah, I got that since you told me the first time. But the thing is, there's no regexp action happening when the CPU gets to 13%, in fact, no action at all bar the animation - and this is precisely the thing that's confusing me. Even with the animation paused, the CPU stays at 6%, which is curious, to say the least, since everything in the skin is on "stand-by" in that moment. The sliding string isn't long either (which would be a valid cause of increased CPU usage), so, at this moment, the real cause for this eludes me... :confused:
jsmorley wrote:
March 10th, 2019, 5:25 pm
What I'm getting at with that is two-fold.

1) If you have a RegExpSubstitute on a String measure that is thousands of lines and 10's of thousands of characters long, each of the separate Substitute components will do a search and replace in the entire string for each component of the Substitute.

2) A poorly constructed regular expression can easily cause tons of "backtracking" through the string in order to resolve all the conditions. I'm no expert in regular expression for sure, but I have seen discussions about this that can get pretty scary on a really long chunk of text.
This is my custom "debug output" of what I get in my skin (don't worry, it's not a skin, but the processed output itself). The FeedAggregator variable is the whole aggregator, and the variables starting with FeedInfoEntry at the end are the ones I'm actually displaying or using one way or another. As you can see, it's not that long, IMHO (had to add .txt at the end of it to be accepted as an attachement here):
Feed Aggregator.inc.txt
And this is the regex I'm using to "extract" a single FeedInfoEntry entity (which I then split up to the rest of the variables at the end of the attached file):

Code: Select all

RegExpSubstitute=1
Substitute="(?siU)^(?:.*<0f>.*</0f>){0,#FeedURLIndex#}+(.*?)$":"\1","(?siU)(?<=</0f>).*?":"","(?siU)^(.*<0f>.*(?=<0e>))(?:.*<0e>.*</0e>){0,#FeedEntryIndex#}+(.*?)$":"\1\2","(?siU)(?<=</0e>).*?":"","(?:^\\1|\\2$)":""
It's basically removing the unneeded content and keeps only the "item" I'm on, based on FeedURLIndex and FeedEntryIndex. This doesn't look overkill to me, but maybe I'm wrong. Anyway, like I said, the CPU stays at 13% even after the substitute did its job. Again, this is the thing that's confusing me, because logically, this has nothing to do with animation, regex parsing, etc. ... because it happens even when those are not "active" or "working" anymore.
You do not have the required permissions to view the files attached to this post.
User avatar
jsmorley
Developer
Posts: 19456
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Escaping %N at display time

jsmorley » March 10th, 2019, 5:52 pm

Just pointing out things that occur to me. I would note that RegExpSubstitute / Substitute is executed by whatever entity is "asking" for the string value, every time it "asks", and not by the measure itself.
User avatar
jsmorley
Developer
Posts: 19456
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Escaping %N at display time

jsmorley » March 10th, 2019, 5:56 pm

Following up on that, note this variant of my above skin:

Code: Select all

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

[Variables]

[MeasureFile]
Measure=WebParser
URL=file://#CURRENTPATH#Test.html
RegExp=(?siU)<item>(.*)</item>
UpdateRate=5

[MeasureValue]
Measure=WebParser
URL=[MeasureFile]
StringIndex=1
Disabled=1
OnChangeAction=[!Log "Child changed"]
Substitute="Value":"Number"

[MeterValue]
Meter=String
MeasureName=MeasureValue
FontSize=13
FontWeight=400
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
AntiAlias=1
1.jpg

So the child measure's string value is set by the parent once a second, and the Substitute is done by the meter once a second. If I disabled the parent, after it is done, it will stop updating the string value of the child, but the Substitute will continue to be done once a second.
You do not have the required permissions to view the files attached to this post.
Yincognito
Posts: 652
Joined: February 27th, 2015, 2:38 pm

Re: Escaping %N at display time

Yincognito » March 10th, 2019, 6:06 pm

jsmorley wrote:
March 10th, 2019, 5:52 pm
Just pointing out things that occur to me. I would note that RegExpSubstitute / Substitute is executed by whatever entity is "asking" for the string value, every time it "asks", and not by the measure itself.
I see - good to know. Well, the only entities that are "asking" for this "base" string value above are it's "String measure children" (basically the measures that get the variables from the split of this measure), and of course, the meter that displays the entry's title+summary. All of them have UpdateDivider=-1 set on them and are executed only on demand. Of course, the meter is sliding (so it "asks" for the value to be displayed every 24 milliseconds), but then, since everything has UpdateDivider=-1, it shouldn't be a problem at all - they should all get the last value of the measures (despite DynamicVariables=1 on every measure and meter, right?). It certainly was not a problem for 7 feed sites (so half of 14 which I am testing now), since, as I said, the impact was basically 0% - much better than in my wildest dreams, actually.
Yincognito
Posts: 652
Joined: February 27th, 2015, 2:38 pm

Re: Escaping %N at display time

Yincognito » March 10th, 2019, 6:17 pm

jsmorley wrote:
March 10th, 2019, 5:56 pm
Following up on that, note this variant of my above skin. So the child measure's string value is set by the parent once a second, and the Substitute is done by the meter once a second. If I disabled the parent, after it is done, it will stop updating the string value of the child, but the Substitute will continue to be done once a second.
I fully understand what you're saying, but I'm having only UpdateDivider=-1 on everything in my skin, except the webparser parent measure, the aggregator string measure and the measure getting the next URL to be interrogated, all 3 being set to update once every hour (yes, I paid attention to the low update of 24 millisecond in the skin, it is indeed 1 freaking hour, LOL)...
Yincognito
Posts: 652
Joined: February 27th, 2015, 2:38 pm

Re: Escaping %N at display time

Yincognito » March 10th, 2019, 7:45 pm

Just to let you know, jsmorley, I finally found the culprit. I took the rude approach and just commented every freaking measure or meter till nothing else but the webparser parent, aggregator and two other measures were "active". The issue was with the WebParser parent, which was like this:

Code: Select all

[MS_WebParser_Feeds]
Measure=WebParser
Url=[&MS_Rainmeter_FeedURL]
RegExp="(?siU)(#Feed#)"
UpdateRate=(#DetectionUpdateDivider#*#UpdateInterval#/#FeedSlidingUpdate#)
FinishAction=[!UpdateMeasureGroup "FeedGroup"][!UpdateMeasureGroup "FeedDerivativeGroup"]
OnConnectErrorAction=[!UpdateMeasureGroup "FeedGroup"][!UpdateMeasureGroup "FeedDerivativeGroup"]
OnRegExpErrorAction=[!UpdateMeasureGroup "FeedGroup"][!UpdateMeasureGroup "FeedDerivativeGroup"]
DynamicVariables=1
The thing that got the CPU crazy was the combination of Url=[&MS_Rainmeter_FeedURL] and DynamicVariables=1 (MS_Rainmeter_FeedURL was providing the URL to interrogate, obviously). As soon as I changed approach, removed DynamicVariables=1 from the webparser parent and set the URL using a bang like [!SetOption MS_WebParser_Feeds URL "[MS_Rainmeter_FeedURL]"] from MS_Rainmeter_FeedURL, puff, the high CPU usage issue was gone, and Rainmeter was back to a 0.39% "normal" CPU usage (Feed skin animation included).

I have no idea what was wrong above, it all seemed ok to me, The webparser parent took the url by referencing the appropriate measure using [&measure] syntax that's described in the manual, DynamicVariables=1 should have had no effect on the webparser since its UpdateRate was set to one hour, etc. Could this be because I didn't set an UpdateDivider on the webparser parent (thus making it continuously update due to dynamic variables being set on it)? Even if was that, I just followed your advice of using only UpdateRate on a WebParser parent, as the other options were prone to "problems", as you explained over and over on this forum...