i just noticed that Rainmeter crashes when the output is very large. (a redirected text file with the same output is about 10 KB).
not sure if there is anything that can (or even should) be done about that. maybe a short note in the docs would do.
in my case i was reading an email with cURL/IMAP. that seems to be too much for Rainmeter as soon as there are images/attachments involved. "solved" it by reading the header section only.
moshi wrote:i just noticed that Rainmeter crashes when the output is very large. (a redirected text file with the same output is about 10 KB).
not sure if there is anything that can (or even should) be done about that. maybe a short note in the docs would do.
This should be fixed in the next version. Hopefully, it won't crash anymore. With the previous version I tried to read a 2MB text file (with the "type" command), and plugin crashed Rainmeter. With the new version, the plugin read the 2MB file just fine (took a second or so). However, Rainmeter took a while to display to that amount of text (and it used a lot of memory) - but obviously this isn't a practical use of Rainmeter at all.
moshi wrote:in my case i was reading an email with cURL/IMAP. that seems to be too much for Rainmeter as soon as there are images/attachments involved. "solved" it by reading the header section only.
The next version should also help with this, at least with the "size" being read. However, I am not sure if any images/attachments are useful in the context of Rainmeter.
Brian wrote:The next version should also help with this, at least with the "size" being read. However, I am not sure if any images/attachments are useful in the context of Rainmeter.
very nice. for sure not that useful. it can never replace a mail client. but i have not figured out yet how to read header and text together without the attachments.
moshi wrote:i just noticed that Rainmeter crashes when the output is very large. (a redirected text file with the same output is about 10 KB).
This has been fixed in the 0.0.1.4 beta. It was a simple mistake that caused the problem (a buffer overrun).
This version also sets the number value of the measure to the "status" of plugin. You can get the number value of a measure with section variables. A status of "-1" means the command has not ran yet. A status of "0", means the command is still running. A status of "1" means the command ran without errors (errors from the plugin, not the program). When the plugin has an error, it sets the number value to its error number (starting from 100 to 106). This will allow you to use IfActions to perform different actions for different status's (see the test skin in the first post).
Brian wrote:Version 0.0.1.4 Beta is now available here: ...
works great so far. i still experienced a few crashes when using cURL and IMAP with Gmail (Yandex.Mail and Yahoo! Mail work fine). i'd blame the substitions i use for filtering and my crappy laptop rather than your plugin though.
the sub-skin i experience the crashes is more like a proof of concept than something for daily use.
Brian wrote:
0.0.1.3+: If the Timeout is reached, the program terminates via Close unless hidden, then via Kill. If the program is still running when the skin closed or refreshed, it terminates via Close unless hidden. If any program prevents itself from closing (like cancelling any changes in Notepad), the plugin will not keep running and stop expecting any output (the Kill or Close commands should no longer work either).
i noticed a glitch here (wouldn't call it a bug).
in a skin i use bc to convert a decimal number to binary. like this:
now when i refresh this skin a few times and then close it (i think milliseconds of timing matter here), i am likely to end up with one or more instances of bc.exe and/or cmd.exe still running.
i guess the piping is the problem here.
Although I cannot pinpoint the problem, I do believe you are correct that a piping problem is to blame. The plugin attempts to pipe to the program which is then piping to another program. This is actually dangerous when running a program that is really expecting input (like bc.exe does).
I would suggest taking a different route to accomplish this task. Since you are just converting a decimal number to binary, I would just use Lua to do this. Here is a quick and dirty example using your skin:
function Update()
local t = os.date('%I')
return bin(t)
end
function bin(dec)
local result = ''
repeat
local int, frac = math.modf(dec / 2)
dec = int
result = math.ceil(frac) .. result
until dec == 0
return result
end
function Update()
local t = os.date('%M')
return bin(t)
end
function bin(dec)
local result = ''
repeat
local int, frac = math.modf(dec / 2)
dec = int
result = math.ceil(frac) .. result
until dec == 0
return result
end
function Update()
local t = os.date('%S')
return bin(t + 1)
end
function bin(dec)
local result = ''
repeat
local int, frac = math.modf(dec / 2)
dec = int
result = math.ceil(frac) .. result
until dec == 0
return result
end
Also, I took out your [MeasureFull] measure because as of Rainmeter 2.4 (r1645), Roundline's do not need to bind to a measure.
