Is it safe for stack?

[ZB]

I mean the quite often (as I see) used construction of the type:

proc eventLoop {} {
...
after 100 eventLoop
}

Seems to me very recursion-like, and I'm wondering, will it cause
overflow in the end?
--
ZB

[Helmut Giese]

> proc eventLoop {} {
> ...
> after 100 eventLoop
> }
>
>Seems to me very recursion-like, and I'm wondering, will it cause
>overflow in the end?

Hi ZB,
no recursion there. Here is what happens:
proc eventLoop {} {
...
(t1) after 100 eventLoop
(t2) }

At time t1 the statement
after 100 eventLoop
is executed which arranges for 'eventLoop' to be called again at time
't3 = t1 + 100 ms'.
At time t2 (some microseconds after t1) the current invocation of
'eventLoop' is terminated and your app is now free to respond to other
events (button clicks, read events, whatever).

At time t3 'eventLoop' is invoked again (or a bit later if at that
particular moment your app is already busy processing another event),
and the scenario is repeated.

You would have recursion if you had a proc like
proc recurse {} {
...
recurse
}
where 'recurse' is _called directly_ - understand the difference
between _calling_ a proc and _arranging_ for a proc to be called at a
certain moment in the future.

HTH
Helmut Giese

[ZB]

Dnia 11.10.2008 Helmut Giese <hgi...@ratiosoft.com> napisał/a:

> understand the difference
> between _calling_ a proc and _arranging_ for a proc to be called at a
> certain moment in the future.

Thanks, you're right - confused "after" with kind of "delay" or "pause".
--
ZB

[Cameron Laird]

In article <slrngf1h45.605...@sarge.my.own.domain.no-net>,

.
.
.
No.

We'll eventually follow-up with details,
explanations of how it could seem to do
so, and other matters. Briefly, though:
"no".

[Helmut Giese]

On 11 Oct 2008 16:16:53 GMT, ZB <zbREMOVE_THIS@AND_THISispid.com.pl>
wrote:

Hm,
this sounds to me like there might be some confusion left: 'after'
_can_ also mean 'pause'.
Consider this modification to your original example:

proc eventLoop {} {
...
(t1) after 100

(t2) eventLoop
}

At t1 an unconditional wait is started - your app will do nothing (not
even respond to other events) for 100 ms.
At t2 (== t1 + 100 ms) it will recurse.

Have a look at after's man page.
HTH
Helmut Giese

[ZB]

Dnia 11.10.2008 Helmut Giese <hgi...@ratiosoft.com> napisał/a:

> Have a look at after's man page.

Hmmm... I think, the better solution would be separate, special "wait
command" (wait, delay, sleep... whatever) - instead of "overloading" `after'.

Of course, too late now.
--
ZB

[Les Cargill]

it's not overloading - "after" installs a callback on an
opaque timer chain, regardless of context.

"Opaque" in that you can't see it except through its abstraction.

--
Les Cargill

[Robert Heller]

At 11 Oct 2008 16:16:53 GMT ZB <zbREMOVE_THIS@AND_THISispid.com.pl> wrote:

>
> Dnia 11.10.2008 Helmut Giese <hgi...@ratiosoft.com> napisa³/a:

>
> > understand the difference
> > between _calling_ a proc and _arranging_ for a proc to be called at a
> > certain moment in the future.
>
> Thanks, you're right - confused "after" with kind of "delay" or "pause".

After with *one* argument *is* a 'kind of "delay" or "pause"'.

--
Robert Heller -- Get the Deepwoods Software FireFox Toolbar!
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
hel...@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk

[David Gravereaux]

proc QueueAnother {when what} {
after $when $what
}

proc thisProc {} {
return [dict get [info frame -1] proc]
}

proc eventLoop {} {
...
QueueAnother 100 [thisProc]
}

Is that more readable?

[ZB]

Dnia 12.10.2008 David Gravereaux <davy...@pobox.com> napisał/a:

> Is that more readable?

Yes, I'm aware, that I'm able to rename available functions on my own. But
such solution has its limit: it'll be readable for me, but not necessarily
for the others, for those using "common" syntax. And, from the other side,
if I'll be using "my own version of TCL", I won't feel comfortable looking
at the "common syntax" listing.

In conclusion: one has to live with that, I'm afraid. At least some time.
--
ZB

[David Gravereaux]

Making your own procs isn't creating your own version of Tcl. On the
other hand, using stuff like tcllib's uevent
<http://tcllib.sourceforge.net/doc/uevent.html> is what people do get
interfaces to a more palatable level one can use more freely. Although
not exactly the interface you are looking for, make your own. Don't
forget the comments and do your best to make it readable.

By restricting yourself from "overloading" you've lost the entire
concept of how to simplify and customize interfaces.