Delay in Tcl
Cameron Laird
Per =?iso-8859-1?Q?Lindstr=F6m?= <uab...@osd.uab.ericsson.se> wrote:
>Hi everyone,
>
>is thee a Tcl equivalent to the UNIX sleep command, to make a delay in
>the execution of the program.
.
.
.
Yes. <URL:http://dev.scriptics.com/man/tcl8.4/TclCmd/after.htm>
provides details.
--
Cameron Laird <cla...@NeoSoft.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Glenn W Jackman
>is thee a Tcl equivalent to the UNIX sleep command, to make a delay in
>the execution of the program.
The TclX extension has a 'sleep' command. In vanilla Tcl, use 'after'.
--
Glenn Jackman E-mail: gle...@nortelnetworks.com
PLS Development Tel: 613-763-9193 (ESN 393-9193)
Nortel Networks
Phil Ehrens
>>is thee a Tcl equivalent to the UNIX sleep command, to make a delay in
>>the execution of the program.
> .
>provides details.
This procedure will "sleep", allowing the event loop to continue
to process background tasks, but will prevent the line after it
from being evaluated until the sleep has elapsed.
proc sleep { ms } {
set sleeping 1
after $ms set sleeping 0
vwait sleeping
}
# example:
after 3000 puts foo!
sleep 4000
puts bar!
Phil Ehrens
Hmmm... weird that that worked with "sleeping" being a local
variable! You may actually need to do this:
proc sleep { ms } {
set ::__sleep__tmp 0
after $ms set ::__sleep__tmp 1
vwait ::__sleep__tmp
unset ::__sleep__tmp
}
Phil Ehrens
proc uniqkey { } {
set key [ expr { pow(2,31) + [ clock clicks ] } ]
set key [ string range $key end-8 end-3 ]
set key [ clock seconds ]$key
return $key
}
proc sleep { ms } {
set uniq [ uniqkey ]
set ::__sleep__tmp__$uniq 0
after $ms set ::__sleep__tmp__$uniq 1
vwait ::__sleep__tmp__$uniq
unset ::__sleep__tmp__$uniq
}
--
Phil
Donal K. Fellows
.ligo.caltech.edu> writes
>Okay, okay... enuf foolin' around:
>
>proc uniqkey { } {
> set key [ expr { pow(2,31) + [ clock clicks ] } ]
> set key [ string range $key end-8 end-3 ]
> set key [ clock seconds ]$key
> return $key
>}
Why not use the simpler:
set ::seqvar 0
proc uniqkey {{prefix ""}} {format "%s%d" $prefix [incr ::seqvar]}
(If you need more than 2**31 identifiers in your program, you should
consider seeking counselling! Or coding differently... :^)
>proc sleep { ms } {
> set uniq [ uniqkey ]
> set ::__sleep__tmp__$uniq 0
> after $ms set ::__sleep__tmp__$uniq 1
> vwait ::__sleep__tmp__$uniq
> unset ::__sleep__tmp__$uniq
>}
It is not a good idea to do nested [sleep]s, because they are really
nested [vwait]s, which is usually not what you want. The correct (as in
most useful in practise) solution is to arrange for the next section of
the program to be executed at the later time. That requires a different
structure of code though...
Donal.
--
Donal K. Fellows (at home)
--
FOOLED you! Absorb EGO SHATTERING impulse rays, polyester poltroon!!
(WARNING: There is precisely one error in this message.)
Phil Ehrens
>In article <8ooki3$q...@gap.cco.caltech.edu>, Phil Ehrens <pehrens@nospam
>.ligo.caltech.edu> writes
>>
>> set key [ expr { pow(2,31) + [ clock clicks ] } ]
>> set key [ string range $key end-8 end-3 ]
>> set key [ clock seconds ]$key
>> return $key
>>}
>
>Why not use the simpler:
> set ::seqvar 0
> proc uniqkey {{prefix ""}} {format "%s%d" $prefix [incr ::seqvar]}
>
>(If you need more than 2**31 identifiers in your program, you should
>consider seeking counselling! Or coding differently... :^)
Well, I guess I just like a unique integer, Donal.
Are you on the rag today or what? Maybe you need some sleep?
>>proc sleep { ms } {
>> set uniq [ uniqkey ]
>> set ::__sleep__tmp__$uniq 0
>> after $ms set ::__sleep__tmp__$uniq 1
>> vwait ::__sleep__tmp__$uniq
>> unset ::__sleep__tmp__$uniq
>>}
>
>It is not a good idea to do nested [sleep]s, because they are really
>nested [vwait]s, which is usually not what you want. The correct (as in
>most useful in practise) solution is to arrange for the next section of
>the program to be executed at the later time. That requires a different
>structure of code though...
I agree completely re. nested sleeps. My code doesn't nest sleeps.
My code DOES arrange for the next section of the program to be
evaluated at a later time.
Just what code are you looking at, Donal?
Donal K. Fellows
.ligo.caltech.edu> writes
>Donal K. Fellows wrote:
>>In article <8ooki3$q...@gap.cco.caltech.edu>, Phil Ehrens <pehrens@nospam
>>.ligo.caltech.edu> writes
>>>
>>>proc uniqkey { } {
>>> set key [ expr { pow(2,31) + [ clock clicks ] } ]
>>> set key [ string range $key end-8 end-3 ]
>>> set key [ clock seconds ]$key
>>> return $key
>>>}
>>
>>Why not use the simpler:
>> set ::seqvar 0
>> proc uniqkey {{prefix ""}} {format "%s%d" $prefix [incr ::seqvar]}
>>
>>(If you need more than 2**31 identifiers in your program, you should
>>consider seeking counselling! Or coding differently... :^)
>
>Well, I guess I just like a unique integer, Donal.
How unique do you need? And are you aware that [clock clicks] has an
absolutely horrendous resolution on some platforms (i.e. Windows)?
Apparently, the OS offers other counters but they are not calibrated...
>Are you on the rag today or what? Maybe you need some sleep?
Definitely. But I fail to see why this brought on your response.
>I agree completely re. nested sleeps. My code doesn't nest sleeps.
>My code DOES arrange for the next section of the program to be
>evaluated at a later time.
>
>Just what code are you looking at, Donal?
I was thinking of sleeps placed in timer callbacks. Probably. I find
life is easiest if you only ever use a single event loop, and do
everything else with callbacks. (Writing dialogs to work this way is
interesting, but it is a long time since I last did it so I don't recall
all the cunning bits; I'd have to look them up...)