Losing track of time

Robert Brenstein rjb at rz.uni-potsdam.de
Mon Aug 11 16:21:01 EDT 2003


>  >The send is based on the date and time.  Though you specify it as a 
>>delta, you are really creating a message that is readied for execution 
>>at a time.
>
>Now you've got me confused. I thought the send parameter was a value in
>seconds, not a date & time. Obviously seconds can be converted, but it's
>the lowest common denominator (other than ticks). So doesn't it just set
>up an internal timer and "ring back" after so many seconds have elapsed?
>
>>Another is to calculate the delay in the send based on the time.  
>>Calculate the seconds of the date/time you want the chime, 
>>chimeSeconds.
>
>Isn't that exactly what I'm doing (minus the calculation) when I say
>"send 'reminder' to me in 3600 seconds"?
>
>Ok, let's start all over. Tell me where I'm wrong in my thinking.
>
>You use send with a parameter of seconds. It goes off into Metacard
>engine-land and probably sets up an OS timer. It then sits there fat,
>dumb, and ugly (assuming you're doing nothing else, as in my case) until
>the time elapses. Then it comes back to your app and says "It's Soup!".
>It just counts seconds, right? Baring other system delays and blocking
>operations, it should come back to you in the number of seconds you asked
>for.
>
>All I'm trying to do is to see if the obvserved delay is due to other
>system resources being used or if a blocking command (possibly "play" for
>example) is happening or something else I haven't thought of.
>Fortunately, I'm not trying to use this to navigate a space ship, so
>little delays aren't really a problem. I'm just curious.
>
>Regards,
>
>Howard

I doubt that engine counts seconds. It probably sets the wakeup time 
(as seconds()?) when it receives the request and then keeps checking 
whether it passed.

Dar is right. At least this is how I would have done it. The point is 
that you should not send to run again in exactly 3660 seconds but you 
calculate what the actual time difference is. This allows you to 
avoid accumulation of error.

To illustrate what I mean: with your script, if each execution lasts 
5 seconds, then

you send at 18:00:00
the script executes and plays sound and resends the request at 19:00:05
the script executes and plays sound and resends the request at 19:00:10
the script executes and plays sound and resends the request at 19:00:15
...

You see the execution time shifting. So instead of asking to send in 
3600 seconds, you should calculate the actual wait time for each 
send. For example, to chime on each full hour, you could

on fullhourchime
play sound # first play
get seconds()
convert it to dateitems
add 1 to item 5 of it # up hour to next
if item 5 of it is 24 then # account for crossing midnight
   put zero into item 5 of it
   add 1 to item 4 of it
   ## similar checks for month and year overflow here
end if
put zero into item 6 of it # zero out minutes
convert it to seconds
send fullhourchime to me in (it-seconds())
end fullhourchime

Using dateitems allows very explicit calculations, although handling 
the overflows complicate the coding. And such a code also 
autocorrects for delays with activation due to other scripts or 
programs.

Robert



More information about the use-livecode mailing list