lslua and timer Thread last updated on 2006-05-03 13:27:26

Posted by member 212670 on 2006-04-27 00:41:53

function bang_woot ()
local ls = lslua
timer.pause ("5s")
ls.message_box ("done")
end


I've never used lslua's timer module before, but I think I'm doing it right? message_box never fires. I'm finding anything after a timer.pause doesn't happen in longer functions. Even weirder, if I have 2 instances of timer.pause (in different functions) Litestep immediately crashes on recycle. And even weirder, I have the previously mentioned problems even if I don't require "timer".

Using the last experimental build of LS that was released, and lslua .05.

Any clues?

Posted by member 5575 on 2006-04-27 15:28:08 link

The timer functions in lslua never worked quite right for me, either; I ended up just writing my own little delay loop to get short pauses where I needed them. Only other thing I could suggest is to bug the module author to try and update/fix the timer stuff.

Posted by member 212670 on 2006-04-27 17:15:05 link

Here's my super-i'm-an-lua-newbie way of doing a loop pause for 1 second...
local start = os.time ()
repeat
--nothing
until os.time ()-(start) == 1

What do you use?

Posted by member 5575 on 2006-04-27 17:26:51 link

mytimer = {}

function mytimer.pause(time_in_ms)
local now,later

now = os.time()+lslua.milli()/1000.
later = now+tonumber(time_in_ms)/1000.
while now < later do
now = os.time()+lslua.milli()/1000.
end

end

Posted by member 212670 on 2006-04-27 18:46:35 link

Ahh nice. More accurate than what I have.

Posted by member 5575 on 2006-04-27 19:23:35 link

I also worry about the possibiity of missing the time period when os.time ()-(start) == 1 - if there's a period of high CPU use, for instance.

Posted by member 212670 on 2006-04-27 20:44:54 link

Ahh good point.

I changed it a bit (no lslua.milli needed). See anything wrong with this? Testing shows it's accurate (arg is in milliseconds):
function pauseit (arg)
local start = os.clock ()
local finish = start + tonumber (arg)/1000
while start < finish do
start = os.clock() + .001
end
end

Posted by member 5575 on 2006-04-27 21:35:37 link

Does os.clock() give you a decimal time in seconds? If so, then that's an easier way to get the time than using os.time()+lslua.milli()/1000. as I did. os.time() only gave integer seconds, IIRC.

The loop you've made there seems to assume that each passage through the loop takes one millsecond though; I don't think you can assume that, generally speaking. I think you'll find that it takes much less time than that, and so you'll end up with shorter pauses than you anticipated. If os.clock()is a decimal time in seconds, then you could do something like the followinbg instead:

function pauseit (arg)
local finish = os.clock () + tonumber (arg)/1000
while os.clock() < finish do
-- nothing
end
end

Posted by member 212670 on 2006-04-27 22:11:30 link

Ya, os.clock () counts in seconds, returning a number to 1/1000th of a second (ex: 1234.567).

My last way was actually very accurate... because each pass through the loop pulled os.clock again, resulting in the os.clock + .0001. So when my timer went off, it was actually ahead by .001 of a second. Silly me...This is the same thing as what I had:
function bang_pauseit (arg)
local start = os.clock () --this line being pretty pointless
local finish = start + tonumber (arg)/1000
while start < finish do
start = os.clock() --note the absense of the + .001
end
end

It looks like you fell in to the same sort of thing with your original way. The first "now" line could be left out by just having "later = (os.time()+lslua.milli()/1000)+(tonumber(time_in_ms)/1000)", since the second "now" has nothing to do with the first...like my first "start" had nothing to do with the second "start".

Anyway... seems like we've arrived at the most efficient work-around. =) Thx etc. I'm learning stuff weeee

Posted by member 5575 on 2006-04-27 22:40:36 link

Me too. Time to update my script as well...

Posted by member 12798 on 2006-04-28 18:57:38 link

ask tnl, he'll probably know a way. all those scripts with while or repeat are evil, because what they're doing is active waiting... your cpu will dislike that. :D

Posted by member 5575 on 2006-04-28 19:01:04 link

Yep, but I only use it to slow things down enough to let textedit finish disk/file access before recycling and stuff like that. For any repetitive actions I use timer.dll instead.

Posted by member 212670 on 2006-04-28 23:29:21 link

I'm using it for a pause after a netreloadmodule, before I call a bang for that module. Without like a .25s pause, I get a nasty error.

Besides, tnl is probably too busy laughing at newbie coding to respond... :D

Posted by member 37809 on 2006-05-03 11:29:00 link

tnl is probably too busy laughing at newbie coding to respond... :D
more like, too busy with school. one down, a project and one (more exam) to go. and where do you get the idea that i laugh at newbie coding? i laugh at most code. especially when the code laughs at you first. doesn't matter who writes it.

anyhow, when i released 0.5, i forgot to include the sample lua file for tests. it's in the 0.5 source, and likely has a test case that will use timer.lua.dll; an important detail that isn't explicitly documented is that, yes, timer.lua.dll still requires that you load timer-0.5, since by peeking in that file you will notice that it calls its bangs.

personally i don't use timer.lua.dll because i'm accustomed to timer-0.5's way of doing things (asynchronously). except i don't like step.rc *Timer config.

i use http://tnl.iamserio.us/litestep/lslua/timer.lua [already i see something broken with my code (it doesn't free timer instances)].

untested, but then your thing looks like:
local timer = require 'timer'
local msgbox = lslua.message_box

bang_woot = timer.new {
  delay = 5000;
  action = function() msgbox 'done' end
}