On 2006-12-14, G.H. <[EMAIL PROTECTED]> wrote:
> Is better to fetch mail using 'cron' + 'fetchmail' or 'getmail'. I think.
That's a fair comment, but I just figured I wanted the fetchmail call to
complete before I did my mail counting (to avoid partial maildir
counts), so I went ahead and put it into the Ion script. I don't,
though, think ion-statusd is any less capable of handling "cron" jobs,
and the memory footprint is about the same. Actually, I was earlier
thinking about using a modified ion-statusd as a more robust supplement
to cron. The first benefit is that polling can be finer-grained than a
minute, which is useful if I want to replace some statically built
daemons I currently use that serve a very rigid purpose (ion-statusd
meter modules are wonderfully user configurable).
As for the remainder of your post, I think you misunderstood my question
(hopefully I didn't similarly misunderstand your response). I was never
talking about making my own timer method. I was just just refering to
the fact that `create_timer' is in two places... one is the
`statusd.create_timer' available to ion-statusd meter modules, but
that's not visible to general Ion scripts. The other is
`ioncore.create_timer', which /is/ available to general Ion scripts. I
haven't looked at the source code, but my suspicion is that there's
shared code between the two functions.
To make a statusbar monitor, pretty much all you need is a timer and an
`inform' command. But `inform' appears to be in too places too:
`statusd.inform' for the meter modules and `mod_statusbar.inform' for
general Ion. So it seems very possible to have a statusbar monitor
that's independant of ion-statusd. Which is useful to me only because
it allows me the hack of keybinding to functions I've already written in
my monitors.
In the course of writing this post, though, I just thought about
breaking off the functions I want to bind to keystrokes into a separate
file. . . one that can be read by the ion-statusd monitors and also read
into a general ion key-binding script. That might be the recommended
solution even if it puts the same functions in memory twice (because
memory is so cheap and the redundancy is pretty small).
Otherwise, I agree. . . making a timer from scratch in Ion is prone to
not work well.
- Sukant
> But, the question is worth the trouble (statusd_dgs.lua by Jeremy Hankins is
> a good example
> on this). I will draw some answers, actually, I only tried the third answer:
>
> Lets assume: defaults = { update_interval = 4*1000, foo_interval =
> 2.5*60*1000 }
> local settings = table.join( ... )
>
>
> 1-) A simple statement accumulating time running in some foo variable:
>
> local foo = settings.update_interval --> foo is actually a global
> variable
>
> if [ foo >= foo_interval ] then
> fetch_something()
> foo = settings.update_interval --> If its done, re-init foo
> else
> foo = foo + settings.update_interval --> Acummulate time
> running
> end
>
> -- The bad thing about this is that the real foo_interval is not exactly 2.5
> minutes for some
> -- possible cases. Also, an update_interval bigger than foo_interval will
> make useless the
> -- foo_interval, but could work for some body. Lets Move on.
>
>
> 2-) A function to calculate internal times:
>
> local init_time = os.time()*1000 --> A fallacy to calculate
> update_interval milliseconds
> local new_update = settings.update_interval
> --> A declaration like this must be done at the top of the script.
>
> function check_foo()
> local time = os.time()*1000 - init_time
> if time == foo_interval then
> fetch_something()
> init_time = init_time + foo_interval
> new_update = settings.update_interval --> Re-init
> normal update_interval
> return
> elseif ( time + settings.update_interval > foo_interval ) and
> ( foo_interval - time < settings.update_interval) then
> new_update = foo_interval - time
> return
> end
> end
>
> function update_foo()
> check_foo()
> show_foo()
> foo_timer:set(new_update, update_foo) --> Internal
> 'update_interval' is new_update
> end
>
