skykooler, I'm either almost at the point where I can present you (and everyone else, really) with a working model of processor and memory usage monitoring in the clock style, OR I'm almost at the point where I throw my hands up in the air in frustration and go with your sleeps using thing. Memory was easy as hell, but this processor thing has hit a little snag.

I figured out a method that doesn't use sleeps, but as a result, the intervals between measuring /proc/stat values are so small, that it almost always gives 1 or 0 as the value to the equation of time CPU spent in non-idle processes, vs. time spent in total (or anything at all. If you do the cpumem applet route and compare ONLY idle, it never reports anything but 0, because there's no idle time in the time spent processing the script, I suspect, during the two moments it fetches info from /proc/stat. (I am pretty sure it's not a math screw up, because other than the idle times, all the others do have time to change, and under the right circumstances, 2, 3, and even up to 6 has shown up [when comparing differences between different moments of the first three numbers of /proc/stat together. Division of that difference by the difference in 'total' time also yields either 1, 0, or [until I figured out to account for possible zeroes in the 'total' time, which is the denominator] errors.)

Mathematically all of this basically comes down to exactly that: I can't make python wait long enough between checks for the stats in procs to accumulate enough 'Jiffies'/USER_HZ to change significantly. The only reason I got any changes at all was by placing one /proc/stat opening and closing before the opening and closing of /proc/meminfo, then calculating the mem part of the script, then fetching the second instance of /proc/stat.

The main thing tripping this up is needing to declare a variable in python before you can use it (it's probably not a problem in all of python, but I couldn't figure out how to do it within a clock-style once, without that first declaration either crashing the clock style, or being run every new iteration of the clock - you can put that down to lack of Python knowledge or some unintended behavior, I don't know.

But right now, this is what I was trying to do for about two days straight, before stumbling upon the above, which still isn't actually a practical solution (if you pad it with enough code between the two accessings of /proc/stat, it either just ends up wasting more processing power on running the padding, and it becomes more efficient to use your sleep approach.

Wonko: Am I missing something here? Is there a way I can set a variable from within the clock style once, just so that it's initialized, and then have later looping parts of the draw clock code use it?

To be clear, I'm going for something like this:

cpuprevious = 0 [or NoneType, doesn't matter]
[blah blah blah various code]
cpulist = file("/proc/stat", 'r')
[more code]
cpucurrent = [stuff taken from cpulist.readline().whatever]
cpu = cpucurrent - cpuprevious
cpuprevious = cpucurrent

The point being, I want the initializing cpuprevious = 0 code to just run once, and I want cpuprevious = cpucurrent to run every execution. That way the last run's current /proc/stat gets uses as the previous value for the next run, etc. The very first initial calculation ends up off, but you only see it during boot/restart of hildon-status-menu, and then processor load would be on-off anyway. I have tried putting "cpuprevious = 0" [my variable names are a bit different, but for example's sake, we're going with "cpuprevious"], in various places in the code. It always has to run before the cpuprevious = cpucurrent, because if it doesn't, Python will throw a fit about cpuprevious not being defined when it hits "cpu = cpucurrent - cpuprevious". Naturally making them equal each other before you run that "cpu =" is counter productive, because then it'll just make cpu = 0 the entire time, so again, you have to define cpuprevious before you run "cpu =", but the only places I've been able to put it within the clock style without crashing the clock causes that line to be run on every clock-refresh, thus wiping whatever the 'last' value may have been. I also tried using "try cpuprevious/except NameError/else/finally" combinations, but so far, they seem to get stuck on the one choice they're given. So, the clock style initializes, it hits the "try", hits the exception, and then runs the exception (defining the variable as whatever). Then it does the rest (cpuprevious = cpucurrent at the end), and I thought that from there, when it hits the next loop, it will have a defined cpuprevious, so the try/except thing won't get a name error, and would move on. But, apparently, it gets stuck running whatever the exception suite was, even when the exception is no longer valid. I also tried some stuff with while loops, but failed at that too, since I couldn't find anything in the last few days of non-stop working (literally, this has become addictive, most of my day is doing this) that would check for the variable not existing. I tried "while cpuprevious not in locals()" and "while cpuprevious not in globals()", but near as I could tell, that doesn't do it either.

I mean, I haven't literally done every conceivable combination of code possible, but pretty close, and I haven't found it to be doable within the clock style with my limited skills.

Oh, also, "from __future__ import division" didn't work from within my clock style. Anything I'm missing about python on the N900, that could explain why this didn't work for me? (Of course, I also manage to have a bunch of other stuff I thought I imitated just fine from other example python code just not work... so I'm sure there's something really important I just don't know about importing.)

- While I wrote this, Wonko posted about the new update -
Wonko, I'll tell you if I get any bugs tomorrow. I just spend an all-nighter again working on the above problem (this is day 4 or 5 I did that in a row now... lol), so I want to sleep.