Prev: disabling/ignoring ctrl+c
Next: passing variable as default value to procedure parameter
From: Alexandre Ferrieux on 4 Sep 2009 02:41
On Sep 3, 11:25 pm, Don Porter <d...(a)nist.gov> wrote:
>
> > just do it with a [catch].
>
> Um, why?  What error are you expecting that a [catch] would
> be the right remedy.

He did that to catch "would wait forever", in order to detect the fact
that no event sources are present. Which is a reasonable approximation
of "no event loop at the end", though not perfect. (eg if this code is
called at startup and handlers are rigged later, it will make the
wrong decision).

But anyway the OP's motivation for doing this escapes me.

-Alex
From: APN on 4 Sep 2009 05:16
Alex,

My primary motivation, as Cameron guessed, is to have a script that
can be passed to either wish or tclsh. The script itself needs an
event loop to be running, for example it might be a simple network
server using async sockets.

Doing a 'wish foo.tcl' and 'tclsh foo.tcl' should both result in the
network server running and responding to requests. Doing a source
foo.tcl inside wish (or tkcon) and tclsh should also result in the
same.

What I currently do is check in the script if Tk is loaded and if not,
do a 'vwait forever' to kick off the event loop (of course after
setting up the async i/o). I was not entirely happy with this because
I do not want to do the vwait if in fact it is being sourced by some
modified tclsh (without Tk) that is running its own event loop.

Here is a concrete example: I have a single file http server,
myhttpserver.tcl.
- if I do a 'tclsh myhttpserver.tcl' I want to run as a standalone web
server and need to do a vwait to get the event loop running
- if I do a 'wish myhttpserver.tcl' I want the same thing except I
should NOT do a vwait if the event loop is already running.
- if a tclsh application which is already running an event loop does a
'source myhttpserver.tcl', I want to run as an embedded http server
and I very clearly should not be doing a vwait.

What checks should I have in myhttpserver.tcl to meet all three
objectives above?

The simplest solution is of course to have the caller specify/control
whether a vwait is required or not. I was hoping to be able to
automatically detect this, that's all.

Hope that clarifies my original question.

/Ashok
On Sep 4, 11:41 am, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com>
wrote:
> On Sep 3, 11:25 pm, Don Porter <d...(a)nist.gov> wrote:
>
>
>
> > > just do it with a [catch].
>
> > Um, why?  What error are you expecting that a [catch] would
> > be the right remedy.
>
> He did that to catch "would wait forever", in order to detect the fact
> that no event sources are present. Which is a reasonable approximation
> of "no event loop at the end", though not perfect. (eg if this code is
> called at startup and handlers are rigged later, it will make the
> wrong decision).
>
> But anyway the OP's motivation for doing this escapes me.
>
> -Alex

From: Alexandre Ferrieux on 4 Sep 2009 05:47
On Sep 4, 11:16 am, APN <palm...(a)yahoo.com> wrote:
>
> - if I do a 'tclsh myhttpserver.tcl' I want to run as a standalone web
> server and need to do a vwait to get the event loop running

This one is OK :)

> - if I do a 'wish myhttpserver.tcl' I want the same thing except I
> should NOT do a vwait if the event loop is already running.

Why would one do that ? What's the purpose of starting a GUI-less app
with wish ?
Do you try to open pdf files with Audacity ???

> - if a tclsh application which is already running an event loop does a
> 'source myhttpserver.tcl', I want to run as an embedded http server
> and I very clearly should not be doing a vwait.

Yes and this is a programmatically different case: 'source
myhttpserver.tcl' is explicitly written. So, without much effort, the
programmer could for example set a global variable before sourcing, or
source a different file.

If I were in your shoes, I would simply distribute two files:

- a.tcl containing the bulk of the code, no vwait
- b.tcl containing "source a.tcl;vwait forever"

and then let the programmer use his brains and fingers.

Bottom line: when situations are clearly different in the caller's
site, it is not a good idea to make the API lose the info and
rediscover it afterwards.

-Alex
From: Uwe Klein on 4 Sep 2009 05:47
APN wrote:

> What checks should I have in myhttpserver.tcl to meet all three
> objectives above?

At the end your "started with eventloop" script will linger
at the file end ( doing an implicit "vwait forever" ).

As far as I can see you can have a catch {vwait forever}
in that position ( and in all cases ) without detrimental
effects?

uwe

From: Neil Madden on 4 Sep 2009 07:52
APN wrote:
[...]
> Here is a concrete example: I have a single file http server,
> myhttpserver.tcl.
> - if I do a 'tclsh myhttpserver.tcl' I want to run as a standalone web
> server and need to do a vwait to get the event loop running
> - if I do a 'wish myhttpserver.tcl' I want the same thing except I
> should NOT do a vwait if the event loop is already running.
> - if a tclsh application which is already running an event loop does a
> 'source myhttpserver.tcl', I want to run as an embedded http server
> and I very clearly should not be doing a vwait.

To check if your script is the main application, you can use the {$argv0
eq [info script]} check. There is no reliable way to determine if the
event loop is running, short of creating an event and seeing if it
occurs or your script exits :-)

-- Neil
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: disabling/ignoring ctrl+c
Next: passing variable as default value to procedure parameter