Starting Tk from tclsh

1 view
Skip to first unread message

Edmund Lai

unread,
Jun 18, 1999, 3:00:00 AM6/18/99
to
I am using Windows 95/NT and I tried to get the Tk package into Tclsh81
by
the following command:

package require Tk

But the interpreter cannot find package Tk. Did I miss some initial
paths?
Where does the tclsh gets its packages?

Thanks for any help.

Edmund Lai
el...@iinet.net.au

Jan Nijtmans

unread,
Jun 18, 1999, 3:00:00 AM6/18/99
to Edmund Lai
Edmund Lai wrote:
> I am using Windows 95/NT and I tried to get the Tk package into Tclsh81
> by
> the following command:
>
> package require Tk
>
> But the interpreter cannot find package Tk. Did I miss some initial
> paths?

Currently the standard distribution doesn't support this, but
the plus-patches do. See:
http://home.wxs.nl/~nijtmans/plus.html

A full binary distribution for Windows 95/98/NT is available at:
ftp://ftp.neosoft.com/pub/tcl/sorted/packages-8.0/devel/tcl811plus.exe

Most fixes needed to accomplish this are already contributed to
Scriptics, but didn't appear in the source yet. Hopefully soon.

Regards,
--
Jan Nijtmans, CMG Arnhem B.V.
email: Jan.Ni...@wxs.nl (private)
Jan.Ni...@cmg.nl (work)
url: http://home.wxs.nl/~nijtmans/

Cameron Laird

unread,
Jun 18, 1999, 3:00:00 AM6/18/99
to
In article <3769D5D9...@wxs.nl>,

Jan Nijtmans <Jan.Ni...@wxs.nl> wrote:
>Edmund Lai wrote:
>> I am using Windows 95/NT and I tried to get the Tk package into Tclsh81
>> by
>> the following command:
>>
>> package require Tk
.
.
.

>Currently the standard distribution doesn't support this, but
>the plus-patches do. See:
> http://home.wxs.nl/~nijtmans/plus.html
>
>A full binary distribution for Windows 95/98/NT is available at:
> ftp://ftp.neosoft.com/pub/tcl/sorted/packages-8.0/devel/tcl811plus.exe
>
>Most fixes needed to accomplish this are already contributed to
>Scriptics, but didn't appear in the source yet. Hopefully soon.
.
.
.
An alternative is TclKit <URL:http://
starbase.neosoft.com/~claird/comp.lang.tcl/tclkit.html>.

I need to explain a bit of background first. Jan has done
superb work for the plus-patches, and I hope more of his en-
hancements make their way into the Tcl core swiftly.

I'm catching on, though, that some users might find plus-patch
most conveniently usable in its TclKit manifestation, as Jean-
Claude Wippler has packaged it. TclKit plus-patches and a
shocking amount of other functionality in a single-file
executable. It's available at no charge for Win*, several
Unixes, and I believe more Unixes and MacOS are on the way.

The choice, then, is between the more conventional installation
design of plus-patches, and TclKit's single-file executable.
Both have a place. I think beginners, in particular, might
find the latter convenient.
--

Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 281 996 8546 FAX

lvi...@cas.org

unread,
Jun 20, 1999, 3:00:00 AM6/20/99
to

According to Jan Nijtmans <Jan.Ni...@wxs.nl>:

:Edmund Lai wrote:
:> I am using Windows 95/NT and I tried to get the Tk package into Tclsh81
:> by
:> the following command:
:>
:> package require Tk
:>
:> But the interpreter cannot find package Tk. Did I miss some initial
:> paths?
:
:Currently the standard distribution doesn't support this, but

Jan, I am curious about something. What patches are required in Tcl just
to find the Tk package - which is the problem the original poster
mentioned. I understand that the package might not _work_ with some
patches - I am more interested initially in what bugs remain in the
package require aspect of things.

--
<URL: mailto:lvi...@cas.org> Quote: Saving the world before bedtime.
<*> O- <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.

Jan Nijtmans

unread,
Jun 20, 1999, 3:00:00 AM6/20/99
to lvi...@cas.org
lvi...@cas.org wrote:
> Jan, I am curious about something. What patches are required in Tcl just
> to find the Tk package - which is the problem the original poster
> mentioned.

Compared to Tk8.1.1, 2 additional things are absolutely needed:
- Bug fix (2121), assuring that libtk is always built with
"-lX11". In 8.1.2 this will be fully corrected (finally :), if
I can beleave the current CVS code.
- Missing pkgIndex.tcl file for Tk, which is rather trivial.

Further on, three more things are needed to make the event handling
of tclsh81.exe+tk81.dll work identical to wish81.exe:

- Implementation of Tcl_MainLoop () (BugID 1525)
- Adaptation of Tk to use the above function (BugID 1540)
- Rewrite of the Tcl_Main() function, adding support for non-blocking
stdin/stdout channels. Not submitted to the Scriptics BUG database
yet because it requires the above two fixes first.

Let's hope that Scriptics takes a little time to evaluate at least
BugID's 1525 and 1540 soon (8.1.2 ?????), then I will submit the final
fixes to make Tk a fully compliant Tcl package to the Bug database.

Jan Nijtmans

unread,
Jun 20, 1999, 3:00:00 AM6/20/99
to lvi...@cas.org
Jan Nijtmans wrote:
> Let's hope that Scriptics takes a little time to evaluate at least
> BugID's 1525 and 1540 soon (8.1.2 ?????), then I will submit the final
^^^^

Oops, The event fix for Tk is BugID 2074, not 1540!!!!!!
^^^^

Alexandre Ferrieux

unread,
Jun 21, 1999, 3:00:00 AM6/21/99
to
Jan Nijtmans wrote:
>
> lvi...@cas.org wrote:
> > Jan, I am curious about something. What patches are required in Tcl just
> > to find the Tk package - which is the problem the original poster
> > mentioned.
>
> Compared to Tk8.1.1, 2 additional things are absolutely needed:
> - Bug fix (2121), assuring that libtk is always built with
> "-lX11". In 8.1.2 this will be fully corrected (finally :), if
> I can beleave the current CVS code.
> - Missing pkgIndex.tcl file for Tk, which is rather trivial.
>
> Further on, three more things are needed to make the event handling
> of tclsh81.exe+tk81.dll work identical to wish81.exe:
>
> - Implementation of Tcl_MainLoop () (BugID 1525)
> - Adaptation of Tk to use the above function (BugID 1540)

Sorry, but as stated before, this flashes all my red
modularity-breaking-alert lights. It is none of Tcl's (nor tclsh's)
business to know that certain executables (wish) using certain
extensions (Tk) happen to branch to a [tkwait window .] after the EOF of
the script.

In other words, I do *not* want to sacrifice modularity so that

#! /bin/sh
#\
exec tclsh $0
package require Tk

works like

#! /bin/sh
#\
exec wish $0

Instead, I am ready to enforce and document the two following
alternatives:

1) Provide the small *script* "wish" that does basically
[package require Tk] and [tkwait window .], PLUS the
fileevent on stdin/console-widget to handle interactive use.

2) Just require the programmer to say [tkwait window .] at the
end of a script of the first form above, if he wants a
wishlike semantics.

-Alex

Jean-Claude Wippler

unread,
Jun 21, 1999, 3:00:00 AM6/21/99
to
Alexandre Ferrieux wrote:
>
> Jan Nijtmans wrote:
[...]

> > - Implementation of Tcl_MainLoop () (BugID 1525)
> > - Adaptation of Tk to use the above function (BugID 1540)
>
> Sorry, but as stated before, this flashes all my red
> modularity-breaking-alert lights. It is none of Tcl's (nor tclsh's)
> business to know that certain executables (wish) using certain
> extensions (Tk) happen to branch to a [tkwait window .] after the EOF
> of the script.
>
> In other words, I do *not* want to sacrifice modularity so that
>
> #! /bin/sh
> #\
> exec tclsh $0
> package require Tk
>
> works like
>
> #! /bin/sh
> #\
> exec wish $0
>
> Instead, I am ready to enforce and document the two following
> alternatives:
>
> 1) Provide the small *script* "wish" that does basically
> [package require Tk] and [tkwait window .], PLUS the
> fileevent on stdin/console-widget to handle interactive use.
>
> 2) Just require the programmer to say [tkwait window .] at the
> end of a script of the first form above, if he wants a
> wishlike semantics.

Isn't there a way to do this semi-automatically?

Supposed "package require Tk" invokes something like the following?
after idle {tkwait window .}
(in the Tk init, or in the pkgIndex.tcl file for Tk, even)

I know the above is not good enough, but it would mean we can simply
slap "package require Tk" at the front of a script, and voila... the
script enters an event loop at the end. Another difference I think, is
that "package require Tk" needs to source "~/.wishrc", since again Tcl
itself should not be bothered with its drivers "wishes", so to speak...

-- Jean-Claude

Alexandre Ferrieux

unread,
Jun 21, 1999, 3:00:00 AM6/21/99
to
Jean-Claude Wippler wrote:
>
> > 2) Just require the programmer to say [tkwait window .] at the
> > end of a script of the first form above, if he wants a
> > wishlike semantics.
>
> Isn't there a way to do this semi-automatically?
>
> Supposed "package require Tk" invokes something like the following?
> after idle {tkwait window .}
> (in the Tk init, or in the pkgIndex.tcl file for Tk, even)
>
> I know the above is not good enough, but it would mean we can simply
> slap "package require Tk" at the front of a script, and voila...

Yes, but just why ? There is absolutely no backward compatibility issue
here, since by definition no scripts exist that say [package require Tk]
(apart from those using Jan's patches of course).

To sum it up:

- I find wish's behavior (vwait at EOF) useful in its domain
- I find tclsh's behavior (exit at EOF) useful in its domain
- We all realize that wish can now be rewritten in terms of tclsh

- I do not want a [package require] to affect tclsh so that it
behaves like wish. This BTW doesn't scale up. What if a second
package wants to start its own loop at the end ? While clearly
they can perfectly coexist in peace (each with its own event
callbacks) if the vwait is done by the programmer !

- I even believe it will be a bonus from a pedagogic standpoint to
make the vwait explicit (I say this from experience on clt !) in
scripts starting with [exec tclsh ... package require Tk].

-Alex

Jan Nijtmans

unread,
Jun 21, 1999, 3:00:00 AM6/21/99
to Alexandre Ferrieux
Alexandre Ferrieux wrote:
> - I do not want a [package require] to affect tclsh so that it
> behaves like wish.

Well, I want it. And I know a lot of other people who agree with me.
Maybe it's time for a new Ouster-vote on this subject..... ;-)
Anyway, I never received a bug-report which told me there was anything
wrong with my approach. On the other hand, there appear regular
postings on comp.lang.tcl asking why Tk isn't a regular package.
Those postings only are talking about a "package require Tk" in
the beginning, not about adding an event loop. In my opionion,
an event loop doesn't belong in an application, but should be
taken care of by the library.

> This BTW doesn't scale up. What if a second
> package wants to start its own loop at the end ? While clearly
> they can perfectly coexist in peace (each with its own event
> callbacks) if the vwait is done by the programmer !

Well, actually the Tcl_MainLoop() function adds a mechanism for other
applications (or extensions) to interfere with the event loop. I
didn't document that yet because currently there are no other
extensions than Tk which provide their own event loop. The
code is small enough to be understandable.

Alexandre Ferrieux

unread,
Jun 22, 1999, 3:00:00 AM6/22/99
to
Jan Nijtmans wrote:
>
> Alexandre Ferrieux wrote:
> > - I do not want a [package require] to affect tclsh so that it
> > behaves like wish.
>
> Well, I want it. And I know a lot of other people who agree with me.
> Maybe it's time for a new Ouster-vote on this subject..... ;-)

Yes, and I'd remove the smiley. When we talk about 'historical baggage'
(in the negative sense) for a language, it often amounts to a series of
questionable design choices made hastily like the one you're about to
make.

> Anyway, I never received a bug-report which told me there was anything
> wrong with my approach.

So what ? Had you ever noticed that [concat] was not list-aware before I
posted the report ? Enormous things can stay unnoticed forever, because
not everybody has the time to stick his nose into the internals. The
same applies to more 'philosophical' issues like the one we're talking
about. Your user population is primarily focussed on Tk. No suprise they
don't care about modularity concerns in (the purer thing some of us are
trying to abstract from) Tcl.

> On the other hand, there appear regular
> postings on comp.lang.tcl asking why Tk isn't a regular package.
> Those postings only are talking about a "package require Tk" in
> the beginning, not about adding an event loop.

They don't mention it, they don't say "I don't want it".
See the focus remark above: most of these posts come from people who
scarcely know what 'update' does.

> In my opionion,
> an event loop doesn't belong in an application, but should be
> taken care of by the library.

I beg to differ strongly. In all C-level GUI toolkit the final call to
the event loop is done explicitly by the client. To follow your advice,
the event loop would be called by atexit()...

More generally, the very statement above is the basis for all the
misconceptions about event-driven programming at least in the Tcl
community: people think it's just plain magical, because they've never
seen the true vwait that's hidden in wish. I'm not saying wish should be
changed or removed, for obvious compat reasons. Instead I'm saying wish
should be a pure-Tcl script that does [package require Tk] *and* [vwait
forever] (I mean [tkwait window .]). It would first serve as such (the
one true wish), and also as an important idiom; hence people wanting to
[package require Tk] would naturally add the vwait, just like in wish !

Another - so far unmentioned - point is that an explicit vwait allows
more intuitive cleanup code: the code after the vwait !

> > This BTW doesn't scale up. What if a second
> > package wants to start its own loop at the end ? While clearly
> > they can perfectly coexist in peace (each with its own event
> > callbacks) if the vwait is done by the programmer !
>
> Well, actually the Tcl_MainLoop() function adds a mechanism for other
> applications (or extensions) to interfere with the event loop. I
> didn't document that yet because currently there are no other
> extensions than Tk which provide their own event loop. The
> code is small enough to be understandable.

Yet all this is unneeded complexity: it simply doesn't pass the Occam
test.

-Alex

John Ellson

unread,
Jun 22, 1999, 3:00:00 AM6/22/99
to
Alexandre Ferrieux wrote:
>
> Jan Nijtmans wrote:
> >
> > Alexandre Ferrieux wrote:
> > > - I do not want a [package require] to affect tclsh so that it
> > > behaves like wish.

Well I'd liked to see this argument resolved because I'd like to see the
plus (and dash) patches in the core a.s.a.p. so that I can count on their
features in scripts and tclets.

> Another - so far unmentioned - point is that an explicit vwait allows
> more intuitive cleanup code: the code after the vwait !

This sounds like it might have some validity, but so far I've never needed
to write tcl code after the "vwait forever". Can you give a more concrete
example? (Any C cleanup code can be written either way, so that doesn't count.)

> > > This BTW doesn't scale up. What if a second
> > > package wants to start its own loop at the end ? While clearly
> > > they can perfectly coexist in peace (each with its own event
> > > callbacks) if the vwait is done by the programmer !
> >
> > Well, actually the Tcl_MainLoop() function adds a mechanism for other
> > applications (or extensions) to interfere with the event loop. I
> > didn't document that yet because currently there are no other
> > extensions than Tk which provide their own event loop. The
> > code is small enough to be understandable.
>
> Yet all this is unneeded complexity: it simply doesn't pass the Occam
> test.

Why is it unneeded? If I have a package that extends the event loop
then I would want to extend it with the same mechanism for both wish and tclsh.
You don't want to modify wish, so doesn't tclsh need to be modified to
recognize event loop registrants? (BTW. In Lucent. we have developed
a package that extended the event loop, so I can vouch for the real need for
packages to be able to do this.)

John Ellson

Christopher Nelson

unread,
Jun 22, 1999, 3:00:00 AM6/22/99
to
Alexandre Ferrieux wrote:
>
> Jan Nijtmans wrote:
> >
> > Alexandre Ferrieux wrote:
> > > - I do not want a [package require] to affect tclsh so that it
> > > behaves like wish.
> >
> > Well, I want it. And I know a lot of other people who agree with me.
> > Maybe it's time for a new Ouster-vote on this subject..... ;-)
>
> Yes, and I'd remove the smiley. When we talk about 'historical baggage'
> (in the negative sense) for a language, it often amounts to a series of
> questionable design choices made hastily like the one you're about to
> make.

FWIW, I'll chime in for Alex's view: [package require Tk] should NOT alter the
behaviour of the invoking interpreter, it should just make new functionality
available to it.

Chris
--
Rens-se-LEER is a county. RENS-se-ler is a city. R-P-I is a school!

Alexandre Ferrieux

unread,
Jun 22, 1999, 3:00:00 AM6/22/99
to
John Ellson wrote:

>
> Alexandre Ferrieux wrote:
> >
> > Another - so far unmentioned - point is that an explicit vwait allows
> > more intuitive cleanup code: the code after the vwait !
>
> This sounds like it might have some validity, but so far I've never needed
> to write tcl code after the "vwait forever". Can you give a more concrete
> example? (Any C cleanup code can be written either way, so that doesn't count.)

For example, removal of temporary files (eg locks). Of course you can
bind <Destroy> among other things. But doing the cleanup in flat
toplevel code after the vwait has some aesthetic appeal:

set tmp /tmp/mystuff.[pid]
...
vwait forever

puts stderr "Cleanup"
file delete $tmp

> > > > This BTW doesn't scale up. What if a second
> > > > package wants to start its own loop at the end ? While clearly
> > > > they can perfectly coexist in peace (each with its own event
> > > > callbacks) if the vwait is done by the programmer !
> > >
> > > Well, actually the Tcl_MainLoop() function adds a mechanism for other
> > > applications (or extensions) to interfere with the event loop. I
> > > didn't document that yet because currently there are no other
> > > extensions than Tk which provide their own event loop. The
> > > code is small enough to be understandable.
> >
> > Yet all this is unneeded complexity: it simply doesn't pass the Occam
> > test.
>
> Why is it unneeded? If I have a package that extends the event loop
> then I would want to extend it with the same mechanism for both wish and tclsh.

There is a semantic drift here: it's not about *extending* the event
loop (for which there are already complete APIs, like
Tcl_CreateEventSource), but about just *starting* it (ie calling vwait)
on EOF of tclsh's input stream. Please read the previous messages of
this thread.

> You don't want to modify wish, so doesn't tclsh need to be modified to
> recognize event loop registrants?

??? Nonsense - I *do* want to modify the implementation of wish (rewrite
it in vanilla Tcl), within the bounds of backward compatibility. I also
find it perfectly acceptable to extend it in whatever Tk-dependent way
you see fit. I just can't accept to resort to tinkering with
Tcl_MainLoop just to avoid one line of Tcl ([vwait forever]).

>(BTW. In Lucent. we have developed
> a package that extended the event loop, so I can vouch for the real need for
> packages to be able to do this.)

Please give details: in what way is the Tcl_CreateEventSource API
insufficient for your case ?

-Alex

John Ellson

unread,
Jun 22, 1999, 3:00:00 AM6/22/99
to
Alexandre Ferrieux wrote:
>
> John Ellson wrote:
> >
> > Alexandre Ferrieux wrote:
> > >
> > > Another - so far unmentioned - point is that an explicit vwait allows
> > > more intuitive cleanup code: the code after the vwait !
> >
> > This sounds like it might have some validity, but so far I've never needed
> > to write tcl code after the "vwait forever". Can you give a more concrete
> > example? (Any C cleanup code can be written either way, so that doesn't count.)
>
> For example, removal of temporary files (eg locks). Of course you can
> bind <Destroy> among other things. But doing the cleanup in flat
> toplevel code after the vwait has some aesthetic appeal:
>
> set tmp /tmp/mystuff.[pid]
> ...
> vwait forever
>
> puts stderr "Cleanup"
> file delete $tmp

Maybe, but bind <destroy> works in an unmodified wish as well, where this
"aeshetic" code approach is unavailable.

So what "cleabup" can't I do in a bind <destroy>, or in the C code of the extension?

> > Why is it unneeded? If I have a package that extends the event loop
> > then I would want to extend it with the same mechanism for both wish and tclsh.
>
> There is a semantic drift here: it's not about *extending* the event
> loop (for which there are already complete APIs, like
> Tcl_CreateEventSource), but about just *starting* it (ie calling vwait)
> on EOF of tclsh's input stream. Please read the previous messages of
> this thread.

OK, so as I understand it, the issue is, should any package that extends
the event loop be able to flag that the event loop should be started
at the end of initialization of all packages. Possibly multiple packages
would want to set this flag. In fact, interactive tclsh might be one example.

> > You don't want to modify wish, so doesn't tclsh need to be modified to
> > recognize event loop registrants?
>
> ??? Nonsense - I *do* want to modify the implementation of wish (rewrite
> it in vanilla Tcl), within the bounds of backward compatibility.

Fine, but you said that you didn't want to modify -this aspect- of wish. In particular
I believe that you were -not- proposing to require users to add "vwait forever"
to the end of existing wish scripts?

> I also find it perfectly acceptable to extend it in whatever
> Tk-dependent way you see fit.

Thanks ;-) But we were talking about subtracting the feature of
automatically starting the event loop, so it would be a backwards
compatibility issue.

But you were -not- proposing it, so we agree on this point.

> I just can't accept to resort to tinkering with
> Tcl_MainLoop just to avoid one line of Tcl ([vwait forever]).

I'm still struggling to understand why this should be a big deal? I'm
looking for a real technical reason to go one way or the other.

I know Jan's code worked nicely in tcl7.6, and I know that I always
forget to add "vwait forwever" in tcl8.1.1plus (although its easy to
recognize the symptom and fix it). So I'm in favor of Jan's
approach unless you can show me something that I can't do with it.

> >(BTW. In Lucent. we have developed
> > a package that extended the event loop, so I can vouch for the
> > real need for packages to be able to do this.)
>
> Please give details: in what way is the Tcl_CreateEventSource API
> insufficient for your case ?

The application was a distributed computing framework which
we extended to allow components to be programmed in Tcl.
The code is old, now broken, and it was written prior to the
Tcl_CreateEventSource API, but I would think that the API
would be fine. My point was only that there are real needs for
such an extension mechanism to the event loop other than just
for Tk.

John

Alexandre Ferrieux

unread,
Jun 22, 1999, 3:00:00 AM6/22/99
to
John Ellson wrote:
>
> Alexandre Ferrieux wrote:
> >
> > John Ellson wrote:
> > >
> > > Alexandre Ferrieux wrote:
> > > >
> > > > Another - so far unmentioned - point is that an explicit vwait allows
> > > > more intuitive cleanup code: the code after the vwait !
> > >
> > > This sounds like it might have some validity, but so far I've never needed
> > > to write tcl code after the "vwait forever". Can you give a more concrete
> > > example? (Any C cleanup code can be written either way, so that doesn't count.)
> >
> > For example, removal of temporary files (eg locks). Of course you can
> > bind <Destroy> among other things. But doing the cleanup in flat
> > toplevel code after the vwait has some aesthetic appeal:
> >
> > set tmp /tmp/mystuff.[pid]
> > ...
> > vwait forever
> >
> > puts stderr "Cleanup"
> > file delete $tmp
>
> Maybe, but bind <destroy> works in an unmodified wish as well, where this
> "aeshetic" code approach is unavailable.

??? Are you having fun runnning full circle like this ?
The example shown above is obviously meant for a tclsh. It shows that
the minimalistic approach that I'm advocating ([package require Tk] +
*explicit* vwait) allows a more intuitive coding style, in tclsh. Now we
all agree that the alternative in wish so far is the bind-destroy. So
what ?

> So what "cleabup" can't I do in a bind <destroy>, or in the C code of the extension?

I'll only repeat the words 'intuitive' and 'aesthetic appeal'.
Please reread the thread, in chronological order :)

> > > Why is it unneeded? If I have a package that extends the event loop
> > > then I would want to extend it with the same mechanism for both wish and tclsh.
> >
> > There is a semantic drift here: it's not about *extending* the event
> > loop (for which there are already complete APIs, like
> > Tcl_CreateEventSource), but about just *starting* it (ie calling vwait)
> > on EOF of tclsh's input stream. Please read the previous messages of
> > this thread.
>
> OK, so as I understand it, the issue is, should any package that extends
> the event loop be able to flag that the event loop should be started
> at the end of initialization of all packages.

Yes, this description is accurate.

> Possibly multiple packages
> would want to set this flag. In fact, interactive tclsh might be one example.

My point is, why this special handling of the event loop ??? Obvious
generalization leads to also add a flag to:

- switch off the backyard light on exit
- verify our stock of pet food on exit
- brew coffee on exit

> > > You don't want to modify wish, so doesn't tclsh need to be modified to
> > > recognize event loop registrants?
> >
> > ??? Nonsense - I *do* want to modify the implementation of wish (rewrite
> > it in vanilla Tcl), within the bounds of backward compatibility.
>
> Fine, but you said that you didn't want to modify -this aspect- of wish. In particular
> I believe that you were -not- proposing to require users to add "vwait forever"
> to the end of existing wish scripts?

Are you again playing your full-circle song ? Of course I'm not


proposing to require users to add "vwait forever" to the end of existing

wish scripts, for obvious backward compatibility. Instead I want to
require them to do so (if they want an event loop!) at the end (or
earlier!) of a *tclsh* script even if it calls [package require Tk].

> > I also find it perfectly acceptable to extend it in whatever
> > Tk-dependent way you see fit.
>
> Thanks ;-) But we were talking about subtracting the feature of
> automatically starting the event loop, so it would be a backwards
> compatibility issue.
>
> But you were -not- proposing it, so we agree on this point.

At last !!! Frankly I fail to follow the exact shape of your full-circle
trajectory, but the final position is okay :)

> > I just can't accept to resort to tinkering with
> > Tcl_MainLoop just to avoid one line of Tcl ([vwait forever]).
>
> I'm still struggling to understand why this should be a big deal? I'm
> looking for a real technical reason to go one way or the other.

Here is what I consider the strongest technical reason of all: Occam's
razor. Minimality. KISS.
If you cannot be touched by that, then I give up. Build whatever heap of
crap you want with whatever arbitrary subdvisions and special cases you
like. Make Tcl another Perl. Go ahead.

> > Please give details: in what way is the Tcl_CreateEventSource API
> > insufficient for your case ?
>

> The code is old, now broken, and it was written prior to the
> Tcl_CreateEventSource API, but I would think that the API
> would be fine.

So what ???

> My point was only that there are real needs for
> such an extension mechanism to the event loop other than just
> for Tk.

Again, this "extension mechanism to the event loop" exists, is *not*
restricted to Tk, and is called Tcl_CreateEventSource. Now can you get
back to the subject please ?

-Alex

Don Porter

unread,
Jun 22, 1999, 3:00:00 AM6/22/99
to
Christopher Nelson <ch...@pinebush.com> wrote:
> FWIW, I'll chime in for Alex's view: [package require Tk] should NOT
> alter the behaviour of the invoking interpreter, it should just make
> new functionality available to it.

Let me join the chorus. One thing I would like to do with a truly
loadable Tk is write some image format conversion filter scripts
for tclsh. Read in an image in one format from stdin and write
out the image converted to another format (or otherwise processed)
to stdout. Tk's [image] command, possibly combined with the Img
extension, provides the powerful guts needed for this task.
However with no loadable Tk, you must use wish, and on MS Windows,
this means no usable stdin and stdout channels.

I don't want tclsh converting itself into wish when it loads Tk.
tclsh has features I need. If I want wish, it's there for me to use.

Some other issues with a loadable Tk:

1. Tk insists on connecting to an X display at initialization. Image
format conversion filter scripts need the [image] command, but
don't necessarily need a display. Perhaps connection to a display
by Tk should be programmable, or commands like [image] which can
be useful without a display should be factored out into another
extension? (I know, there's always the Xvfb workaround).

2. Tk consumes options from $::argv. When Tk is exclusively part of
wish, this is not a problem, but when a [package require Tk]
can cause a Tk initialization at an arbitrary place in a
program, the programmer needs to be warned that $::argv better be
in acceptable shape before the call, and it may be modified by
the call. (For example, a "-h" in $::argv will bring the
program to a halt with a Tk help message written to stderr.)

--
| Don Porter, D.Sc. Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/mcsd/Staff/DPorter/ NIST |
|______________________________________________________________________|

John Ellson

unread,
Jun 22, 1999, 3:00:00 AM6/22/99
to
Alexandre Ferrieux wrote:
>
> John Ellson wrote:

> > OK, so as I understand it, the issue is, should any package that extends
> > the event loop be able to flag that the event loop should be started
> > at the end of initialization of all packages.
>
> Yes, this description is accurate.
>
> > Possibly multiple packages
> > would want to set this flag. In fact, interactive tclsh might be one example.
>
> My point is, why this special handling of the event loop ??? Obvious
> generalization leads to also add a flag to:
>
> - switch off the backyard light on exit
> - verify our stock of pet food on exit
> - brew coffee on exit


Now who is getting off topic?

Why do you consider this to be special handling? It seems completely
general to me. Any extension that needs an event loop also needs the
event loop to be started after all packages have been initialized.

Included in this category are wish, and the interactive "extension" to tcl
that provides tclsh.

John Ellson

Darren New

unread,
Jun 22, 1999, 3:00:00 AM6/22/99
to
John Ellson wrote:
> Why do you consider this to be special handling? It seems completely
> general to me. Any extension that needs an event loop also needs the
> event loop to be started after all packages have been initialized.

Here's one case where I think such a thing might be useful:

If you have a package that starts an event loop at the end (say, a new
version of Expect or something) and you want to source that (unmodified)
to use parts of it or perhaps invoke it later, a [tkwait window .] at
the end will make [source] hang up. Setting a flag will not, especially
if there's a mechanism to unset the flag as well.

I've never done this, but it might be something to consider.

--
Darren New / Senior Software Architect / MessageMedia, Inc.
San Diego, CA, USA (PST). Cryptokeys on demand.
There is no "best" programming language. Only "least worst."

Jan Nijtmans

unread,
Jun 22, 1999, 3:00:00 AM6/22/99
to Alexandre Ferrieux
Alexandre Ferrieux wrote:
> > OK, so as I understand it, the issue is, should any package that extends
> > the event loop be able to flag that the event loop should be started
> > at the end of initialization of all packages.
>
> Yes, this description is accurate.

Let me give some example why I think that it is very useful to have
an implicit start of the event loop at the end of the script (which
is different from the end of the application)

Some simple minimal code:
# hello.tcl variant
package require Tk
button .b -text "button"
pack .b
vwait forever ;# This line causes the problems described below
# end

- This code hangs forever if the window is closed manually.
Nothing is visible, but the process still runs in the background.
- This code cannot be "source"'d from the console, neither the one
from tclsh, neither the one from wish. The script would be stuk
in the "vwait". This makes debugging GUI applications almost
impossible.
- If other functions call vwait in turn, we have multiple
vwait's running inside each other. We already know what
unexpected bugs that programming style can cause.

"event-driven" programming is fundamentally different from
"procedural" programming. The traditional approach of procedural
languages is indeed that the end of the application is where the
code ends. It has been shown that this appoach is not practical
for GUI's, because of the event loop. Making the loop
implicit, as is currently the case in wish, is soooo
useful!!!!!! It has nothing to do with good or bad programming
style, it's just a different style. Further on, "procedural"
programming can be seen as a subset of "event-driven"
programming: If there are no events to be processed,
the application will still finish at the end of the code.
I really don't see what's the big deal!!!!!!

If the main point is programming style, then the "vwait"
command should be totally forbidden. Much better is
to use "after", which can do exactly the same things
but depends on the event loop. In my opinion, using
"after" shows a much better programming style than
using "vwait" or "tkwait". How many unexpected infinite
loops did the "vwait" command already cause in applications?
If the author would have used "after" instead, those
bugs would not have occured.

So far. we seem to have 2 votes in favor and 3 against:

In Favor:
Jan Nijtmans
John Ellson
Against:
Alexandre Ferrieux
Christopher Nelson
Don Porter

Anyone else who wants to join one of the groups, (preferably mine)......... ;-)?
Do more people have problems with the plus-patch approach? I suggest
anyone who has a strong opinion about this to email me.
In one week (say july 1st) I'll publish the results on
comp.lang.tcl together with the names of the voters.
That's the only way to find out how the Tcl community
really feels about this subject.

Bob Techentin

unread,
Jun 22, 1999, 3:00:00 AM6/22/99
to
Jan Nijtmans wrote:
>
> Alexandre Ferrieux wrote:
> > - I do not want a [package require] to affect tclsh so that it
> > behaves like wish.
>
> Well, I want it. And I know a lot of other people who agree with me.
> Maybe it's time for a new Ouster-vote on this subject..... ;-)

I am building applications by incorporating my C++ code into a custom
tclsh using SWIG 1.1p5. I have been building against the plus patches
(8.0.4+, at the moment) specifically because I wanted to exploit
[package require Tk] to add a GUI to a (normally) batch program.

When I run the GUI code through my custom tclsh, I *must* include a
[tkwait] at the end. I assumed that it was because the plus patches'
tclAppInit.c was different than the code included by SWIG. But now that
I've looked at the code, I don't see exactly where the difference lies.
Is it because the default console is (was) TkCon, which includes Tk and
the event loop already?

I would vote for an explicit call to the event loop from tclsh. That
makes good intuitive sense to me.

Bob

--
Bob Techentin techenti...@mayo.edu
Mayo Foundation (507) 284-2702
Rochester MN, 55905 USA http://www.mayo.edu/sppdg/sppdg_home_page.html

Chang LI

unread,
Jun 22, 1999, 3:00:00 AM6/22/99
to
Jan Nijtmans wrote:
>

> Let me give some example why I think that it is very useful to have
> an implicit start of the event loop at the end of the script (which
> is different from the end of the application)
>
> Some simple minimal code:
> # hello.tcl variant
> package require Tk
> button .b -text "button"
> pack .b
> vwait forever ;# This line causes the problems described below
> # end
>

I do not like the 'vwait forever' to be added into the Tk code.
You will have two versions of Tk code. It is not necessary to
maintain two versions.

I think 'vwait' and 'after' are two different commands.
Can you use 'after' replace 'vwait'?



> So far. we seem to have 2 votes in favor and 3 against:
>

I prefer the implicit event loop.



> In Favor:
> Jan Nijtmans
> John Ellson
> Against:
> Alexandre Ferrieux
> Christopher Nelson
> Don Porter
>
> Anyone else who wants to join one of the groups, (preferably mine)......... ;-)?
> Do more people have problems with the plus-patch approach? I suggest
> anyone who has a strong opinion about this to email me.
> In one week (say july 1st) I'll publish the results on
> comp.lang.tcl together with the names of the voters.
> That's the only way to find out how the Tcl community
> really feels about this subject.
>
> Regards,
> --
> Jan Nijtmans, CMG Arnhem B.V.
> email: Jan.Ni...@wxs.nl (private)
> Jan.Ni...@cmg.nl (work)
> url: http://home.wxs.nl/~nijtmans/

--
--------------------------------------------------------------
Chang LI, Neatware
email: cha...@neatware.com
web: http://www.neatware.com
--------------------------------------------------------------

Chang LI

unread,
Jun 22, 1999, 3:00:00 AM6/22/99
to
Don Porter wrote:
>

On windows there are two kinds of applications: console and windows.
In the console application there is no event loop from the windows
OS. In the windows application Windows itself includes an event loop.
Tclsh is just a console application. When add Tk it became a
windows applicaion. So I did not clear why you need the vwait in the
Tk script if you let tclsh as a windows application.

In other words, why you need a console tclsh? The console in windows
has very limited functions. For example, you can not embed the
console window to a normal window. MS had fundamental trouble to
integrate the console into the normal window loop.



> Christopher Nelson <ch...@pinebush.com> wrote:
> > FWIW, I'll chime in for Alex's view: [package require Tk] should NOT
> > alter the behaviour of the invoking interpreter, it should just make
> > new functionality available to it.
>
> Let me join the chorus. One thing I would like to do with a truly
> loadable Tk is write some image format conversion filter scripts
> for tclsh. Read in an image in one format from stdin and write
> out the image converted to another format (or otherwise processed)
> to stdout. Tk's [image] command, possibly combined with the Img
> extension, provides the powerful guts needed for this task.
> However with no loadable Tk, you must use wish, and on MS Windows,
> this means no usable stdin and stdout channels.
>

You need to create a console window to get stdin and stdout.



> I don't want tclsh converting itself into wish when it loads Tk.
> tclsh has features I need. If I want wish, it's there for me to use.
>


> Some other issues with a loadable Tk:
>
> 1. Tk insists on connecting to an X display at initialization. Image
> format conversion filter scripts need the [image] command, but
> don't necessarily need a display. Perhaps connection to a display
> by Tk should be programmable, or commands like [image] which can
> be useful without a display should be factored out into another
> extension? (I know, there's always the Xvfb workaround).
>
> 2. Tk consumes options from $::argv. When Tk is exclusively part of
> wish, this is not a problem, but when a [package require Tk]
> can cause a Tk initialization at an arbitrary place in a
> program, the programmer needs to be warned that $::argv better be
> in acceptable shape before the call, and it may be modified by
> the call. (For example, a "-h" in $::argv will bring the
> program to a halt with a Tk help message written to stderr.)
>
> --
> | Don Porter, D.Sc. Mathematical and Computational Sciences Division |
> | donald...@nist.gov Information Technology Laboratory |
> | http://math.nist.gov/mcsd/Staff/DPorter/ NIST |
> |______________________________________________________________________|

--

Don Porter

unread,
Jun 22, 1999, 3:00:00 AM6/22/99
to
Rather than an immediate vote, how about some discussion? I'm learning
more about how other people want to use Tcl and Tk from the followups.

It seems to me there may be a more general issue lurking here. How
should scripts control the interpreter which evaluates them? Should
they explicitly select a shell which is known to support their commands?
Or should they take whatever shell they get, and load whatever missing
packages they need? Or some combination?

A script -- a file containing Tcl commands -- needs a shell for its
evaluation. Unix systems -- the original home of Tcl -- let you enable
the executable bit of the script, and start the script with a "#!"
indication of what evaluating shell should be used to interpret the
script. If a script includes Tk commands, the "#!" must select "wish"
or some other shell which provides Tk.

On Windows, the evaluating shell gets selected according to an
association with the file extension of the script. That association is
stored in the Windows registry. The script doesn't get a direct say
in what shell evaluates it.

Since loadable extensions and the [package] command appeared in Tcl 7.5,
scripts have the power to modify the interpreter in which they are being
evaluated by adding any missing packages they require, so long as those
packages are loadable and installed where they can be loaded into
whatever interpreter is evaluating the script.

Loadable extensions hold out the promise that the days of having
a separate "big shell" for every extension combination can be driven
into the past. Instead, there could be only one shell which is
supplied with whatever capabilities are required by loading more
extensions. That is nearly true now, but since Tk is not loadable
(out of the box), there are still two "big shells" left, tclsh and
wish.

Since Windows doesn't (easily) support selection of the evaluating
shell by a script, and because package loading appears to scale
more reasonably than having multiple shells available with different
package combinations, it looks like having scripts control their
interpreters entirely with [package require] is the way to go.
For Tk, this means doing away with wish, and having tclsh as the
sole remaining shell, and [package require Tk] as the means to
access the Tk commands.

Sadly, the two remaining "big shells" -- tclsh and wish -- differ in
more than the packages they include. They also differ in the logic of
their main loop, their support for standard channels on Windows, and
whether their interactive command loop is event driven or not.

So, any scripts written for wish probably won't quite work in tclsh +
[package require Tk] unless [package require Tk] has the side effects
proposed by Jan.

Of course, scripts written for wish likely don't have
[package require Tk] in them anyway since Tk doesn't have to be loaded
into wish. Since script writers have to add that to their scripts
anyway to join the new "one shell" world, how much more would be
reasonable to ask of them? Adding an explicit [tkwait window .]
at the end of their scripts doesn't seem to be popular.

Perhaps the "side-effect" portion of [package require Tk] proposed by
Jan could be provided by another extension named "wish"? Then those
with wish scripts would have to add both [package require Tk] and
[package require wish] to their scripts to be compatible with the new
"one shell" world. Those of us who want the Tk commands but not the
wish-style main loop and channel handling could [package require Tk]
alone.

#----------------------------------------------------------------------#
Regarding some issues that Jan brought up in favor of an implicit
event loop started by the initialization of the Tk package...

Jan Nijtmans <Jan.Ni...@wxs.nl> wrote:
> - This code hangs forever if the window is closed manually.
> Nothing is visible, but the process still runs in the background.

Isn't that why Alex suggested [tkwait window .] rather than
[vwait forever] ?

> - This code cannot be "source"'d from the console, neither the one
> from tclsh, neither the one from wish. The script would be stuk
> in the "vwait". This makes debugging GUI applications almost
> impossible.

Making a script "sourceable" from an interactive console always requires
some special programming styles, doesn't it? F.e., if a window is going
to be created, you must check that it doesn't already exist, if you want
your script to be "sourceable" again and again while debugging.
Likewise, you could check whether $::argv0 and [info script] are the
same and call or not call [tkwait window .] accordingly.

> - If other functions call vwait in turn, we have multiple
> vwait's running inside each other. We already know what
> unexpected bugs that programming style can cause.

But those bugs always come out of a misunderstanding about how [vwait]
works. The [vwait forever] idiom can only cause trouble if you
actually set a global variable named 'forever' and expect the script to
exit. That expectation could be frustrated by a nested [vwait]. An
explicit [exit] is probably preferred anyway. Other than that,
[vwait forever] just means "start the event loop".

> Do more people have problems with the plus-patch approach?

I confess I've never used the plus patches, so maybe my opinion
shouldn't count for much. I hope it's enough to get other people
thinking and commenting though.

Paul Alexander

unread,
Jun 22, 1999, 3:00:00 AM6/22/99
to
In article <376FA3A4...@lucent.com>, John Ellson <ell...@lucent.com> writes:
>
>I'm still struggling to understand why this should be a big deal? I'm
>looking for a real technical reason to go one way or the other.
>
>I know Jan's code worked nicely in tcl7.6, and I know that I always
>forget to add "vwait forwever" in tcl8.1.1plus (although its easy to
>recognize the symptom and fix it). So I'm in favor of Jan's
>approach unless you can show me something that I can't do with it.
>
I can see many reasons for not wanting package require Tk to start the event
loop, here are some:

1. Enter event loop via tkwait .someWindow and not "."
2. Allow essentially command-line applications, i.e. applications using Tcl
as an imbeded interpreter to pop up a window. For example I have a number of
data processing and simulation applications all of which use Tcl, it would be
really nice to be able to be able to "pop up" a visualisation window even
from an initially non-X application started in an Xterm. This would be easy
to do if I have control of when the event loop is started.
3. If screenless Tk is ever implemented you would be able to do say canvas
rendering to provide (again for non-windows applications) graphics output
behind the scenes. This again needs control over starting/stopping the event
loop.

There are of course ways round these in other schemes, but having a clean
implementation with an explicit tkwait seems to me to be the best option.


--
Dr. Paul Alexander
Mullard Radio Astronomy Observatory,
Department of Physics, Cavendish Laboratory,
University of Cambridge, Cambridge, UK.

FAX: 44 1223 354 599
Tel: 44 1223 337 308

Bob Techentin

unread,
Jun 22, 1999, 3:00:00 AM6/22/99
to
Don Porter wrote:
> ...

> So, any scripts written for wish probably won't quite work in tclsh +
> [package require Tk] unless [package require Tk] has the side effects
> proposed by Jan.

I believe that Alexandre was proposing to reimplement wish as a Tcl
script which performs [package require Tk], argument processing,
starting the event loop, and all those other nice side effects. The new
wish would behave exactly as before, and no scripts would break.

On the other hand, scripts that *may* choose to load Tk with an explicit
[package require] would have to also start the event loop. These
scripts would also have to handle colormaps, geometries, and other
whatnots that are presently taken care of by wish. This extra effort
would be required whether the Tcl interpreter is tclsh or embedded in
some other application.

This approach seems consistent.

Slaven Rezic

unread,
Jun 22, 1999, 3:00:00 AM6/22/99
to
d...@clover.cam.nist.gov (Don Porter) writes:

>
> Christopher Nelson <ch...@pinebush.com> wrote:
> > FWIW, I'll chime in for Alex's view: [package require Tk] should NOT
> > alter the behaviour of the invoking interpreter, it should just make
> > new functionality available to it.
>
> Let me join the chorus. One thing I would like to do with a truly
> loadable Tk is write some image format conversion filter scripts
> for tclsh. Read in an image in one format from stdin and write
> out the image converted to another format (or otherwise processed)
> to stdout. Tk's [image] command, possibly combined with the Img
> extension, provides the powerful guts needed for this task.
> However with no loadable Tk, you must use wish, and on MS Windows,
> this means no usable stdin and stdout channels.
>

> I don't want tclsh converting itself into wish when it loads Tk.
> tclsh has features I need. If I want wish, it's there for me to use.
>
> Some other issues with a loadable Tk:
>
> 1. Tk insists on connecting to an X display at initialization. Image
> format conversion filter scripts need the [image] command, but
> don't necessarily need a display. Perhaps connection to a display
> by Tk should be programmable, or commands like [image] which can
> be useful without a display should be factored out into another
> extension? (I know, there's always the Xvfb workaround).
>
> 2. Tk consumes options from $::argv. When Tk is exclusively part of
> wish, this is not a problem, but when a [package require Tk]
> can cause a Tk initialization at an arbitrary place in a
> program, the programmer needs to be warned that $::argv better be
> in acceptable shape before the call, and it may be modified by
> the call. (For example, a "-h" in $::argv will bring the
> program to a halt with a Tk help message written to stderr.)
>

Maybe it is worth to take a look on the perl solution of loading Tk. A
minimal perl/Tk program looks like:

use Tk;
$top = new MainWindow;
MainLoop;

which would translate to Tcl/Tk:

package require Tk
mainwindow .
tk_mainloop

Command line processing is done in the package Tk::CmdLine, which is
called when the mainwindow is created. The event loop is explicitely
started with MainLoop.

Regards,
Slaven

--
use Tk;$c=tkinit->Canvas->pack;$x=5;for(split/_/,'KPI1_+09IPK_K;-OA1_+K!;A__1;
Q!7G_1+QK_3CLPI90,_+K!;A_+1!KQ!.N_K+1Q!.F_1+KN.Q__1+KN._K+1Q!.F_1+KN.Q_+1Q__+1!
KQ!.N_1;Q!7G_K3,09Q_+1!K.Q_K+1Q!.F_1+KN.Q'){s/\n//g;for(split/!/){$c->create(
'line',map{$a=-43+ord;($x+($a>>3)*2,5+($a&7)*2)}split//)}$x+=12}MainLoop

Don Porter

unread,
Jun 22, 1999, 3:00:00 AM6/22/99
to
Chang LI <cha...@neatware.com> wrote:
> On windows there are two kinds of applications: console and windows.

Thanks for replying. Perhaps if I offer an example you can
explain some of the subtleties in this MS Windows difference
between a console app and a windows app which appears to break
Unix-style use of standard channels in wish.

Consider this Tcl script:
# FILE: demo.tcl
while {[gets stdin line] != -1} {
puts stdout $line
flush stdout
}
exit 0
# END FILE: demo.tcl

And consider this interactive tclsh session:
C:\> tclsh80
% info patch
8.0.5
% set f [open "|tclsh80 demo.tcl" w+]
file7
% foreach line {foo bar snafu} {
puts $f $line
flush $f
gets $f backLine
puts stdout "Back from demo: $backLine"
}
Back from demo: foo
Back from demo: bar
Back from demo: snafu

Using tclsh as the child shell works fine.

Now, another interactive tclsh session using wish as the child:
C:\> tclsh80
% set f [open "|wish80 demo.tcl" w+]
file7
% foreach line {foo bar snafu} {
puts $f $line
flush $f
gets $f backLine
puts stdout "Back from demo: $backLine"
}

It just sits there.

On Unix it works the same whether the child shell is tclsh
or wish. If the child script needs to use Tk commands on
Windows, I'm stuck.

Now the good news. I tried to reproduce this problem on
Tcl/Tk 8.1.1 for Windows and I can't. The problem with
wish's standard channels seems to be fixed in Tk 8.1.1, at
least for this example.

Any words of Windows wisdom would be welcome.

Chang LI

unread,
Jun 22, 1999, 3:00:00 AM6/22/99
to
Don Porter wrote:
>

> On Unix it works the same whether the child shell is tclsh
> or wish. If the child script needs to use Tk commands on
> Windows, I'm stuck.
>
> Now the good news. I tried to reproduce this problem on
> Tcl/Tk 8.1.1 for Windows and I can't. The problem with
> wish's standard channels seems to be fixed in Tk 8.1.1, at
> least for this example.
>

I think 8.1 fixed the console and standard channel bugs on Windows.
Most Unix style commands should be available for 8.1 on Windows.
That is one reason I think 8.1 is more platform independent than
8.0 and the 8.0 should be die.



> Any words of Windows wisdom would be welcome.
>
> --
> | Don Porter, D.Sc. Mathematical and Computational Sciences Division |
> | donald...@nist.gov Information Technology Laboratory |
> | http://math.nist.gov/mcsd/Staff/DPorter/ NIST |
> |______________________________________________________________________|

--

Chang LI

unread,
Jun 22, 1999, 3:00:00 AM6/22/99
to
Don Porter wrote:
>
> Rather than an immediate vote, how about some discussion? I'm learning
> more about how other people want to use Tcl and Tk from the followups.
>
> It seems to me there may be a more general issue lurking here. How
> should scripts control the interpreter which evaluates them? Should
> they explicitly select a shell which is known to support their commands?
> Or should they take whatever shell they get, and load whatever missing
> packages they need? Or some combination?

Many applications did not use shell at all.

>
> A script -- a file containing Tcl commands -- needs a shell for its
> evaluation. Unix systems -- the original home of Tcl -- let you enable
> the executable bit of the script, and start the script with a "#!"
> indication of what evaluating shell should be used to interpret the
> script. If a script includes Tk commands, the "#!" must select "wish"
> or some other shell which provides Tk.
>

You can write a short C program and call your Tcl script.
I am not sure if #! is a good idea to launch a shell.
In CGI program it is very useful. But I think it is low performance.



> On Windows, the evaluating shell gets selected according to an
> association with the file extension of the script. That association is
> stored in the Windows registry. The script doesn't get a direct say
> in what shell evaluates it.
>

You just need double click a script to start run it. It is much simple.

> Since loadable extensions and the [package] command appeared in Tcl 7.5,
> scripts have the power to modify the interpreter in which they are being
> evaluated by adding any missing packages they require, so long as those
> packages are loadable and installed where they can be loaded into
> whatever interpreter is evaluating the script.
>
> Loadable extensions hold out the promise that the days of having
> a separate "big shell" for every extension combination can be driven
> into the past. Instead, there could be only one shell which is
> supplied with whatever capabilities are required by loading more
> extensions. That is nearly true now, but since Tk is not loadable
> (out of the box), there are still two "big shells" left, tclsh and
> wish.
>

yes. one shell is enough if you need a interactive environment.
When you do not require the interactive no shell is needed.
Why wish is needed? Using tclsh as a windows application rather than
console application and Tk as loadable extension I did not see the
reasons that wish should exist on Windows.



> Since Windows doesn't (easily) support selection of the evaluating
> shell by a script, and because package loading appears to scale
> more reasonably than having multiple shells available with different
> package combinations, it looks like having scripts control their
> interpreters entirely with [package require] is the way to go.
> For Tk, this means doing away with wish, and having tclsh as the
> sole remaining shell, and [package require Tk] as the means to
> access the Tk commands.
>
> Sadly, the two remaining "big shells" -- tclsh and wish -- differ in
> more than the packages they include. They also differ in the logic of
> their main loop, their support for standard channels on Windows, and
> whether their interactive command loop is event driven or not.
>
> So, any scripts written for wish probably won't quite work in tclsh +
> [package require Tk] unless [package require Tk] has the side effects
> proposed by Jan.
>

It should work. Most event processings have moved from Tk to Tcl.

> Of course, scripts written for wish likely don't have
> [package require Tk] in them anyway since Tk doesn't have to be loaded
> into wish. Since script writers have to add that to their scripts
> anyway to join the new "one shell" world, how much more would be
> reasonable to ask of them? Adding an explicit [tkwait window .]
> at the end of their scripts doesn't seem to be popular.
>
> Perhaps the "side-effect" portion of [package require Tk] proposed by
> Jan could be provided by another extension named "wish"? Then those
> with wish scripts would have to add both [package require Tk] and
> [package require wish] to their scripts to be compatible with the new
> "one shell" world. Those of us who want the Tk commands but not the
> wish-style main loop and channel handling could [package require Tk]
> alone.
>

Just add one command [package require Tk] and moved to one shell world
have no many troubles. But I think add vwait in the end of the script
will cause many troubles. The meaning to attach the vwait in the end
of a script is difficult to understand. So I am sure many people will
forget it and generate many FAQ. And I think it is an ugly tail.

--

Bryan Oakley

unread,
Jun 22, 1999, 3:00:00 AM6/22/99
to
Don Porter wrote:
>
> Rather than an immediate vote, how about some discussion? I'm learning
> more about how other people want to use Tcl and Tk from the followups.
>
> It seems to me there may be a more general issue lurking here. How
> should scripts control the interpreter which evaluates them? Should
> they explicitly select a shell which is known to support their commands?
> Or should they take whatever shell they get, and load whatever missing
> packages they need? Or some combination?

I think it would be a Good Thing to allow a tcl script to decide at some
point whether it needs Tk or not. I personally think it's a bit odd we
have both tclsh and wish when the only difference is one has a package
loaded by default that the other one doesn't. Especially since we know
it's possible to dynamically load Tk, as proven by the plus (or is it
dash) patch.

So, first off, count me in the camp of want to be able to do "package
require Tk" fresh outta da box.

My gut reaction to whether or not an event loop starts up or not is to
have it start up if one loads tk. That seems like a handy thing to have,
and would require the least amount of modification to existing scripts.
But the programmer in me kicks in and says I should be able to control
the event loop. I don't like controlling it by what is essentially a
hack -- calling tkwait.

What I would rather see is a specific command that can be used to start
an event loop. This could be a tk command or a tcl command, I haven't
thought it out that much.

So, I guess I would like to see all tcl scripts initially run by tclsh
(or the local equivalent), but be able to turn that into a wish
equivalent with something like this:

if {$someCondition} {
package require Tk
tk::initEventLoop
}

This makes it painfully obvious that you want an event loop or not, and
gives you control over when it starts. So, someone could just as easily
structure their tk scripts like this:

#!/bin/tclsh
package require Tk

proc main {} {
# do really cool and useful stuff
}

<define other procs here>

# call the main program after all the code has been loaded
main

# start the event loop
tk::initEventLoop


... or maybe use "eventloop start" (with an "eventloop stop" to round
out the set).


--
Bryan Oakley mailto:oak...@channelpoint.com
ChannelPoint, Inc. http://purl.oclc.org/net/oakley

Education is full of oversimplified lies which can be
refined into the truth later.

Tom Poindexter

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
In article <377034AB...@channelpoint.com>,
Bryan Oakley <oak...@channelpoint.com> wrote:

>Don Porter wrote:
>>
>> Rather than an immediate vote, how about some discussion? I'm learning
>> more about how other people want to use Tcl and Tk from the followups.
>
>
>My gut reaction to whether or not an event loop starts up or not is to
>have it start up if one loads tk. That seems like a handy thing to have,
>and would require the least amount of modification to existing scripts.
>But the programmer in me kicks in and says I should be able to control
>the event loop. I don't like controlling it by what is essentially a
>hack -- calling tkwait.

> #!/bin/tclsh


> package require Tk
>
> proc main {} {
> # do really cool and useful stuff
> }
>
> <define other procs here>
>
> # call the main program after all the code has been loaded
> main
>
> # start the event loop
> tk::initEventLoop


Count me also in the camp to have Tk loaded into Tcl. I also like the idea of
having the event loop started implicitly, but I'd add the restriction to
only start the event loop if root window "." has any children. That
way I could 'package require Tk' early on, but if I didn't instantiate any
widgets, the event loop would not be started.

I think it is unnecessary to have 'tk::initEventLoop' (or similar) to manually
start the event loop. In this case, you can simply use 'exit' to terminate
your non-Tk tclsh, a command that already exists.


--
Tom Poindexter
tpoi...@nyx.net
http://www.nyx.net/~tpoindex/

Jan Nijtmans

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
Slaven Rezic wrote:
> Maybe it is worth to take a look on the perl solution of loading Tk. A
> minimal perl/Tk program looks like:
>
> use Tk;
> $top = new MainWindow;
> MainLoop;
>
> which would translate to Tcl/Tk:
>
> package require Tk
> mainwindow .
> tk_mainloop

That's indeed another issue. Loading Tk has another side
effect: The creation of the main window '.'. In my
view there is nothing wrong with that. Since
using "package require Tk" implies that we
are writing a GUI, it is only handy that the
main window is already created by Tk. In
the same way, it is handy that the main loop
is automatically started. The main point
here is not saving a few commands from the
script, but maintenance: Just because handling the
main event loop by applications is so complicated, why
not just releave the user from that!!

Should perl really provide the standard how programming
in Tcl should look like .......... ;-)

Don Porter wrote:
> On Unix it works the same whether the child shell is tclsh
> or wish. If the child script needs to use Tk commands on
> Windows, I'm stuck.
>
> Now the good news. I tried to reproduce this problem on
> Tcl/Tk 8.1.1 for Windows and I can't. The problem with
> wish's standard channels seems to be fixed in Tk 8.1.1, at
> least for this example.
>

> Any words of Windows wisdom would be welcome.

In 8.1.1 the Windows channel code was rewritten in order to
support non-blocking channels to the console. This is
crucial for GUI's. Therefore it is now no longer necessary
to have a special console for wish, and it is also the
reason that I no longer distrubute TkCon with the
plus-patches. My proposal of having only one shell is only
really possible on Windows using 8.1.

Great discussion!!!!!!

Slaven Rezic

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
Jan Nijtmans <Jan.Ni...@wxs.nl> writes:

>
> Slaven Rezic wrote:
> > Maybe it is worth to take a look on the perl solution of loading Tk. A
> > minimal perl/Tk program looks like:
> >
> > use Tk;
> > $top = new MainWindow;
> > MainLoop;
> >
> > which would translate to Tcl/Tk:
> >
> > package require Tk
> > mainwindow .
> > tk_mainloop
>
> That's indeed another issue. Loading Tk has another side
> effect: The creation of the main window '.'. In my
> view there is nothing wrong with that. Since
> using "package require Tk" implies that we
> are writing a GUI, it is only handy that the
> main window is already created by Tk. In
> the same way, it is handy that the main loop
> is automatically started. The main point
> here is not saving a few commands from the
> script, but maintenance: Just because handling the
> main event loop by applications is so complicated, why
> not just releave the user from that!!

Not creating the main window implicitly would enable to use tk
commands like "image" in a batch, without graphical interface. In
perl/Tk, it's also possible to create more than one "main window", but
I'm not sure about the benefits of this one over toplevels.

Volker Hetzer

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
Don Porter wrote:

> Sadly, the two remaining "big shells" -- tclsh and wish -- differ in
> more than the packages they include. They also differ in the logic of
> their main loop, their support for standard channels on Windows, and
> whether their interactive command loop is event driven or not.
>
> So, any scripts written for wish probably won't quite work in tclsh +
> [package require Tk] unless [package require Tk] has the side effects
> proposed by Jan.

The point of the explicit-event-loop guys was NOT to require all scripts
to be changed, but to reimplement wish as tclsh + tkwait/vwait.
This would lead to a cleaner architecture (IMHO).
I'm in favour of it.


> > - If other functions call vwait in turn, we have multiple
> > vwait's running inside each other. We already know what
> > unexpected bugs that programming style can cause.
>
> But those bugs always come out of a misunderstanding about how [vwait]
> works.

You mean, there is more to it than the manpage?

> > Do more people have problems with the plus-patch approach?
>
> I confess I've never used the plus patches, so maybe my opinion
> shouldn't count for much. I hope it's enough to get other people
> thinking and commenting though.

Same for me.

Greetings!
Volker

Alexandre Ferrieux

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
Don Porter wrote:
>
> [cannot pipe commands to a wish on Windoze]

> Any words of Windows wisdom would be welcome.

Don, I don't remember exactly when (on the 8.1 patch timescale) it
happened, but at least as of today (8.1.1), wish.exe is able to listen
to things on its stdin if it is launched between pipes. I even remember
congratulating the Scriptics spokesperson of the time (whoever it was)
for this outstanding deed.

-Alex

Alexandre Ferrieux

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
Jan Nijtmans wrote:
>
> Slaven Rezic wrote:
> > Maybe it is worth to take a look on the perl solution of loading Tk. A
> > minimal perl/Tk program looks like:
> >
> > use Tk;
> > $top = new MainWindow;
> > MainLoop;
> >
> > which would translate to Tcl/Tk:
> >
> > package require Tk
> > mainwindow .
> > tk_mainloop
>
> That's indeed another issue. Loading Tk has another side
> effect: The creation of the main window '.'. In my
> view there is nothing wrong with that.

<grin> Thanks for reminding me of this: yet another point where we
differ !
To sum it up, you really want [package require Tk] to make tclsh totally
equivalent to wish. Argh. With this, Tk is Tcl's Brutus: a faithful
child (I do recognize that Tk has been a key promoter of Tcl over the
years) that eventually takes over in a totally self-centered fashion.

> Since
> using "package require Tk" implies that we
> are writing a GUI,

You have very restrictive views about Tk. See Don's remarks about image
filters.

> it is only handy that the
> main window is already created by Tk.

Since 'only handy' means 'but could otherwise be trivially emulated by
[toplevel .]', and also 'and is just a pain in the backside when you
don't want a GUI nor even have an X connection', you'll admit that this
argument of yours is self-detructing.

> In
> the same way, it is handy that the main loop
> is automatically started. The main point
> here is not saving a few commands from the
> script, but maintenance: Just because handling the
> main event loop by applications is so complicated, why
> not just releave the user from that!!

Hear, hear boys: [tkwait window .] is too complicated for most of you,
Jan says.

> Great discussion!!!!!!

I'm happy you're having fun with this, but at the same time I am very
surprised to discover your position; I try to interpret it as a
consequence of your Tk focus...

-Alex

Alexandre Ferrieux

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
John Ellson wrote:
>
> Alexandre Ferrieux wrote:
> >
> > John Ellson wrote:
>
> > > OK, so as I understand it, the issue is, should any package that extends
> > > the event loop be able to flag that the event loop should be started
> > > at the end of initialization of all packages.
> >
> > Yes, this description is accurate.
> >
> > > Possibly multiple packages
> > > would want to set this flag. In fact, interactive tclsh might be one example.
> >
> > My point is, why this special handling of the event loop ??? Obvious
> > generalization leads to also add a flag to:
> >
> > - switch off the backyard light on exit
> > - verify our stock of pet food on exit
> > - brew coffee on exit
>
> Now who is getting off topic?
>
> Why do you consider this to be special handling? It seems completely
> general to me.

This is *special*, in the sense that the flag tells you to start the
loop, which is [vwait forever], which is *one* call among several dozens
in the Tcl library. IOW I'd understand more easily a request to have a
kind of robust Tcl-level "ateof" so that arbitrary Tcl code can be
called after the EOF of the script. I hope this time you'll see that my
coffee-brewing example was right on spot indeed. I won't try a third
time to walk you through basic logic reasoning.

> Any extension that needs an event loop also needs the
> event loop to be started after all packages have been initialized.

"Needs an event loop" doesn't imply that the [package require] starts it
!!!
For example, the sound extension Snack needs an event loop to play
sounds in background. It simply says so in the manual; any sane
programmer understands that:
1) In a sound-only tclsh script, he needs to add a [vwait]
2) In a wish script, the async sound playing will gracefully integrate
with the existing event loop that drives his GUI.

-Alex

Alexandre Ferrieux

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
Darren New wrote:

>
> John Ellson wrote:
> > Why do you consider this to be special handling? It seems completely
> > general to me. Any extension that needs an event loop also needs the

> > event loop to be started after all packages have been initialized.
>
> Here's one case where I think such a thing might be useful:
>
> If you have a package that starts an event loop at the end (say, a new
> version of Expect or something) and you want to source that (unmodified)
> to use parts of it or perhaps invoke it later, a [tkwait window .] at
> the end will make [source] hang up.

Yes, because *tclsh* scripts are not *wish* scripts nor are they
*your-expect-variant* scripts. That's all. All your purposefully-crafted
"examples" are just consequences of this stubborn *confusion* of
a-Tcl-file-that-should-be-parsed-by-executable-A and
a-Tcl-file-that-should-be-parsed-by-executable-B, where obviously A and
B have different intentions regarding the presence of an event loop.

> Setting a flag will not, especially
> if there's a mechanism to unset the flag as well.

Argh ! Even worse: since the flag is a logical OR of all the extensions
that have formulated the request of an event loop, if you reset it,
you'll draw the mat under all the others' feet. Hopeless.

-Alex

Alexandre Ferrieux

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
Bryan Oakley wrote:

>
> Don Porter wrote:
> >
> > Rather than an immediate vote, how about some discussion? I'm learning
> > more about how other people want to use Tcl and Tk from the followups.
> >
> > It seems to me there may be a more general issue lurking here. How
> > should scripts control the interpreter which evaluates them? Should
> > they explicitly select a shell which is known to support their commands?
> > Or should they take whatever shell they get, and load whatever missing
> > packages they need? Or some combination?
>
> I think it would be a Good Thing to allow a tcl script to decide at some
> point whether it needs Tk or not. I personally think it's a bit odd we
> have both tclsh and wish when the only difference is one has a package
> loaded by default that the other one doesn't. Especially since we know
> it's possible to dynamically load Tk, as proven by the plus (or is it
> dash) patch.
>
> So, first off, count me in the camp of want to be able to do "package
> require Tk" fresh outta da box.

Ahem. Nobody argues against this: [package require Tk] is an obvious
prerequisite of all the rest of the discussion :)

> My gut reaction to whether or not an event loop starts up or not is to
> have it start up if one loads tk. That seems like a handy thing to have,
> and would require the least amount of modification to existing scripts.

First, see Bob Techentin's clear and accurate comment about the problem:
wish will still be around so you'll never *need* to modify anything.
Only if you *want* some GUI scripts to have the style
tclsh+package-requireTk, is there some editing (Hey - style change means
editing. Surprised ?)

And once you edit, what does it cost you to add [tkwait window .] at the
end ???

> But the programmer in me kicks in and says I should be able to control
> the event loop. I don't like controlling it by what is essentially a
> hack -- calling tkwait.

??? Why is 'tkwait' a hack?
[vwait] and [tkwait] are just the script-level API (the latter slightly
above the former) of the event loop. A lower-level one (without the
blocking semantics) is [update].

> What I would rather see is a specific command that can be used to start
> an event loop. This could be a tk command or a tcl command, I haven't
> thought it out that much.

Obviously. Otherwise you would have noticed that this command already
exists - see above :)

> So, I guess I would like to see all tcl scripts initially run by tclsh
> (or the local equivalent), but be able to turn that into a wish
> equivalent with something like this:
>
> if {$someCondition} {
> package require Tk
> tk::initEventLoop
> }
>
> This makes it painfully obvious that you want an event loop or not, and
> gives you control over when it starts. So, someone could just as easily
> structure their tk scripts like this:
>

> #!/bin/tclsh
> package require Tk
>
> proc main {} {
> # do really cool and useful stuff
> }
>
> <define other procs here>
>
> # call the main program after all the code has been loaded
> main
>
> # start the event loop
> tk::initEventLoop
>

> ... or maybe use "eventloop start" (with an "eventloop stop" to round
> out the set).

So, in the end, the "programmer in you" agrees with me: Great !!! :)

The "programmer in me" has long taken over the other parts :^)

-Alex

Alexandre Ferrieux

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
Jan Nijtmans wrote:
>
> Alexandre Ferrieux wrote:
> > > OK, so as I understand it, the issue is, should any package that extends
> > > the event loop be able to flag that the event loop should be started
> > > at the end of initialization of all packages.
> >
> > Yes, this description is accurate.
>
> Let me give some example why I think that it is very useful to have
> an implicit start of the event loop at the end of the script (which
> is different from the end of the application)
>
> Some simple minimal code:
> # hello.tcl variant
> package require Tk
> button .b -text "button"
> pack .b
> vwait forever ;# This line causes the problems described below

Yes. Reread my messages. I'm using [vwait] as a general name, but all my
detailed examples used [tkwait window .], which is what wish does.

> "event-driven" programming is fundamentally different from

> "prlanguages is indeed that the end of the application is where the


> code ends. It has been shown that this appoach is not practical
> for GUI's, because of the event loop.

Nonsense. Of course, in procedural style, if you don't call an event
loop, you don't get an event loop. Big deal.

> Making the loop
> implicit, as is currently the case in wish, is soooo
> useful!!!!!!

*This* is a reasonable statement. Now tell me Jan, do you believe I want
to remove this feature from wish ? Is my English so bad that I have to
find five different wordings to get this idea out of your mind ?

> It has nothing to do with good or bad programming
> style, it's just a different style.

Yes. And you select the one you want by choosing tclsh or wish, even if
wish is itself a Tcl script !

> Further on, "procedural"
> programming can be seen as a subset of "event-driven"
> programming: If there are no events to be processed,
> the application will still finish at the end of the code.

I hope you mean "if there are no event *sources*"...

> I really don't see what's the big deal!!!!!!

The big deal is, you want this admittedly handy wish-behavior to be
obtained in tclsh by only

package require Tk
# traditional "wish" code here

while, for obvious and many times stated purity/orthogonality/minimality
reasons, I want the very *same* behavior to be obtained through:

package require Tk
# traditional "wish" code here
tkwait window .

Notice that for clarity I temporarily removed my other claim regarding
the creation of the toplevel "." window. Bringing it back, it would be:

package require Tk
tk::wishinit ;# includes [toplevel .]
# traditional "wish" code here
tkwait window . ;# call it 'tk::wishloop' if
# you...wish :) I don't.

While a non-GUI image filter program would do:

package require Tk
set im [image create ...]
...

Notice that at the end of the code above I'm falling through to exit the
shell, *not* to an event loop. I don't want to *have* to call [exit]
here, just like in all my non-GUI tclsh scripts. I especially don't want
to have the following discussion with my son someday:

- Dad, why is there an [exit 0] at the end of all your
image-filtering tools ?

- Boy, that's historical baggage. Some GUI-focussed people
long ago completely forgot the distinction between Tk and
wish, and they won for some obscure reason (maybe
majority vote :^)

> If the main point is programming style, then the "vwait"
> command should be totally forbidden. Much better is
> to use "after", which can do exactly the same things
> but depends on the event loop.

I'll add the missing context :)
I'd guess that what you're trying to say here, despite the blatant
nonsensical touch of the sentence, is that most nested-vwait cases can
be solved by linearization through [after].

Yes indeed. But what the heck does it have to do with the
explicit/implicit tkwait issue above ?

> So far. we seem to have 2 votes in favor and 3 against:
>

> In Favor:
> Jan Nijtmans
> John Ellson
> Against:
> Alexandre Ferrieux
> Christopher Nelson
> Don Porter

Ahem. A majority vote, eh ?
Nope. I believe in *arguments*, and final *decision* by someone in a
position to do so, eg Brent or John or Jeff or somebody@scr. (Yes I'm a
cathedralist in some regards).

> That's the only way to find out how the Tcl community
> really feels about this subject.

This is true. But technical decision by head-counting scares me.
Notice that I'll still think so even if my side wins the vote !

-Alex

Donal K. Fellows

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
In article <376EA062...@wxs.nl>,

Jan Nijtmans <Jan.Ni...@wxs.nl> wrote:
> Alexandre Ferrieux wrote:
>> - I do not want a [package require] to affect tclsh so that it
>> behaves like wish.
>
> Well, I want it. And I know a lot of other people who agree with me.
> Maybe it's time for a new Ouster-vote on this subject..... ;-)
> Anyway, I never received a bug-report which told me there was anything
> wrong with my approach.

Quite possibly because those who disagree with your approach simply do
not use your patches. Moaning about one's fundamental differences
over the basic principles of a system in a bug report seems... well...
wrong. I don't complain that my refrigerator doesn't walk the dog, no
matter how convenient that would be...

> On the other hand, there appear regular
> postings on comp.lang.tcl asking why Tk isn't a regular package.

They are a self-selecting group. Basing important decisions (like
this one - making [package require Tk] force the eventloop at the end
of the script) purely on the views of a minority is not wise.

> Those postings only are talking about a "package require Tk" in
> the beginning, not about adding an event loop. In my opionion,
> an event loop doesn't belong in an application, but should be
> taken care of by the library.

I respect your opinion, despite its utter wrong-headedness in this
matter. Obviously, [package require] must make some changes to the
behaviour of a script (or we wouldn't do it) but changing the gross
termination semantics does not strike me as elegant; the phrase
"blecherous hack with massive potential for being a legacy code
headache and stick for others to beat use with" springs rapidly to
mind.

Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>

Donal K. Fellows

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
In article <37703D...@neatware.com>, Chang LI <cha...@neatware.com> wrote:
> Don Porter wrote:
>> Rather than an immediate vote, how about some discussion? I'm learning
>> more about how other people want to use Tcl and Tk from the followups.
>>
>> It seems to me there may be a more general issue lurking here. How
>> should scripts control the interpreter which evaluates them? Should
>> they explicitly select a shell which is known to support their commands?
>> Or should they take whatever shell they get, and load whatever missing
>> packages they need? Or some combination?
>
> Many applications did not use shell at all.

What exactly do you mean?

>> A script -- a file containing Tcl commands -- needs a shell for its
>> evaluation. Unix systems -- the original home of Tcl -- let you enable
>> the executable bit of the script, and start the script with a "#!"
>> indication of what evaluating shell should be used to interpret the
>> script. If a script includes Tk commands, the "#!" must select "wish"
>> or some other shell which provides Tk.
>
> You can write a short C program and call your Tcl script. I am not
> sure if #! is a good idea to launch a shell. In CGI program it is
> very useful. But I think it is low performance.

It isn't, actually. #! processing is done in kernel space, and the
leading bytes of any executable file need to be read in order to
determine how to execve() it in the first place. Windows also does
this - there is no distinguishing feature of the file name that
indicates whether a particular .exe is a console or a graphical
application.

>> On Windows, the evaluating shell gets selected according to an
>> association with the file extension of the script. That association is
>> stored in the Windows registry. The script doesn't get a direct say
>> in what shell evaluates it.
>
> You just need double click a script to start run it. It is much simple.

WRONG. It is not simple at all. That you believe it is merely
indicates that MicroBorg are eating away at your common sense.

[...]


> yes. one shell is enough if you need a interactive environment.

Not always.

> When you do not require the interactive no shell is needed.
> Why wish is needed? Using tclsh as a windows application rather than
> console application and Tk as loadable extension I did not see the
> reasons that wish should exist on Windows.

There are existing Tcl applications that require the presence of stdin
and stdout for data access. Those applications require the console on
Windows. This is a problem (one of many) with Windows.

> Just add one command [package require Tk] and moved to one shell world
> have no many troubles. But I think add vwait in the end of the script
> will cause many troubles. The meaning to attach the vwait in the end
> of a script is difficult to understand.

No. You still have a wish program, but it is implemented as a tcl
script. This is dead simple to perform on Windows...

> So I am sure many people will forget it and generate many FAQ.

They'll notice pretty quickly when their application exits
immediately...

> And I think it is an ugly tail.

Your input on aesthetics is valued. But making the core more
semantically horrid (needed to implemenbt this sort of trick) should
tip you the wink that the beauty of scripts is not the only aesthetic
issue at stake here.

[ I have no idea why, but suspect I disagree with about 90% of
everything you write on this newsgroup. How can two people, both of
whom support the wide use of Tcl/Tk, have such differing views? ]

Volker Hetzer

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
Alexandre Ferrieux wrote:

>
> Jan Nijtmans wrote:
> > If the main point is programming style, then the "vwait"
> > command should be totally forbidden. Much better is
> > to use "after", which can do exactly the same things
> > but depends on the event loop.
>
> I'll add the missing context :)
> I'd guess that what you're trying to say here, despite the blatant
> nonsensical touch of the sentence, is that most nested-vwait cases can
> be solved by linearization through [after].
How would you wait for a variable to change without vwait?
Greetings!
Volker

Alexandre Ferrieux

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to

(I changed the subject since this has nothing to do with the initial
[package require Tk] issue)

You're right to point out that such serialization does need some
modification of the code: you have to move your imperative-blocking
style (nested vwaits) to an event-driven state-machine. In other words,
you need to replace

E ;# setup event handler that sets var)

A
vwait var
B

by

E ;# setup event handler that calls B,
# or [after idle B], or [after 0 B])
A

But please refer to the already long thread dealing with your
nested-vwait code.

-Alex

Volker Hetzer

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
Alexandre Ferrieux wrote:
[reordered]

> But please refer to the already long thread dealing with your
> nested-vwait code.
I dont know how to reply to you without offending you further, but I'll
reply nevertheless. (Hope you won't kill me :-) )

> You're right to point out that such serialization does need some
> modification of the code: you have to move your imperative-blocking
> style (nested vwaits) to an event-driven state-machine.

Nested vwaits are not my style but an implementation choice of Tcl.

>
> E ;# setup event handler that calls B,
> # or [after idle B], or [after 0 B])
> A

But this implies that you can't synchronize events back into the normal
program flow!
AND that you have to capture the remainder of your tcl-script into
the trace!
Since real programs are NOT state machines (apart from the finite stack)
it is rather difficult to transform any program into a state machine.
Since you can't have a return in a trace this implies unrolling procedure
calls which is contrary to modular programming.

I certainly don't insist on vwait, but am I supposed to accept that there is
no way to do an rpc package where a function sends a command down a socket,
waits for a response without blocking the whole app and returns with the result?

Am I really the first one to try this?

Is it really bad programming style to encapsule rpcs into normal function
calls?

like
set A [rpc $rpcchannel "expr 1 + 1"]
?

Greetings!
Volker

Donal K. Fellows

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
In article <376FC8DB...@wxs.nl>,

Jan Nijtmans <Jan.Ni...@wxs.nl> wrote:
> Let me give some example why I think that it is very useful to have
> an implicit start of the event loop at the end of the script (which
> is different from the end of the application)
>
> Some simple minimal code:
> # hello.tcl variant
> package require Tk
> button .b -text "button"
> pack .b
> vwait forever ;# This line causes the problems described below
> # end

I think that Alex would be perfectly happy if we instead did the
following:

#! /usr/local/bin/tclsh
# This file is /usr/local/bin/wish
package require Tk
# Well, this is a little oversimplistic. It'll do for a news posting...
source [lindex $argv 0]
tkwait window .; # This is what Alex means by [vwait forever] :^)

And:

#! /usr/local/bin/wish
# This file is foo.tcl


button .b -text "button"
pack .b

Like this, we have the orthogonality that Alex likes (many others too,
including myself) while still maintaining the ease of use for normal
scripts.

> - This code hangs forever if the window is closed manually.
> Nothing is visible, but the process still runs in the background.

This is a brain-o of Alex. Stop flogging this dead horse...

> - This code cannot be "source"'d from the console, neither the one
> from tclsh, neither the one from wish. The script would be stuk
> in the "vwait". This makes debugging GUI applications almost
> impossible.

But my above version can.

> - If other functions call vwait in turn, we have multiple
> vwait's running inside each other. We already know what
> unexpected bugs that programming style can cause.

But that is effectively what happens in Tk now. Nested waits are
awkward. Period. I don't think you're about to change that!

[Summarising since these paragraphs are *long* ]
[... people should not use procedural programs with wish ...]
[... use after instead ...]

All true. But it doesn't change the fact that your proposal is a bad
idea. If someone was to write some (ill-advised[*]) code that ran Tcl
programs received from an external source, and one of these programs
did [package require Tk], that would cause the server to block in a
way that would be tough to detect for all but the most experienced.

> So far. we seem to have 2 votes in favor and 3 against:
>
> In Favor:
> Jan Nijtmans
> John Ellson
> Against:
> Alexandre Ferrieux
> Christopher Nelson
> Don Porter

Make that four against. I suspect that you've not considered all the
possiblilities for foul-ups at your end, and there are ways of making
our scheme work like yours for most normal use.

Donal.
[* Letting someone at the remote end load Tk cannot be smart. But
that isn't the point I'm interested in right now... ]

Volker Hetzer

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
Donal K. Fellows wrote:
>
> In article <376FC8DB...@wxs.nl>,
> Jan Nijtmans <Jan.Ni...@wxs.nl> wrote:
> > So far. we seem to have 2 votes in favor and 3 against:
> >
> > In Favor:
> > Jan Nijtmans
> > John Ellson
> > Against:
> > Alexandre Ferrieux
> > Christopher Nelson
> > Don Porter
I'm against package require starting up the event loop.

Greetings!
Volker

Don Porter

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
Jan Nijtmans <Jan.Ni...@wxs.nl> wrote:
>...using "package require Tk" implies that we
>are writing a GUI,...

Goodness, no! Calling [package require Tk] implies that I want
to use at least one of the commands and variables provided by
the Tk package. Nothing more. Some of the Tk commands are
useful for non-GUI programming.

Alexandre Ferrieux

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
Volker Hetzer wrote:
>
> Alexandre Ferrieux wrote:
> [reordered]
> > But please refer to the already long thread dealing with your
> > nested-vwait code.
> I dont know how to reply to you without offending you further, but I'll
> reply nevertheless. (Hope you won't kill me :-) )

You're not offending me; it's just that I am at a high risk of repeating
stuff already present in the other thread - which I purposefully don't
read, like most FAQs:)

> > You're right to point out that such serialization does need some
> > modification of the code: you have to move your imperative-blocking
> > style (nested vwaits) to an event-driven state-machine.

> Nested vwaits are not my style but an implementation choice of Tcl.

Not either. Its a necessary consequence of blockingly expecting new
events from within an event handler, which is:

1) itself a consequence of making an rpc from within an ev handler.
2) potentially dangerous if you aren't careful enough (see below)
3) yet unavoidable if you're calling some black box that does an
rpc/vwait behind the scenes.

Now how to do it carefully ?
A nested vwait can work correctly if:

- the exit condition of the outer vwait is not triggered by a handler
during the inner vwait, OR it breaks the inner too (ie they look at the
same variable)

- the event handlers normally active for the outer continue to make
sense during the inner vwait, and don't interfere badly with the
specific action of the inner (eg: GUI events vs. RPC).

Notice that the possibility of *disabling* the "outer" handlers during
the inner vwait only makes sense if the disabling operation stops the
consumption of data from the corresponding event queue (eg fileevent).
Remarkably, this is not the case of GUI events: if you remove a binding
and the corresponding event fires, then it's lost. All this suggest a
need for *filtered* vwaits/updates (one for afters, one for fileevents,
one for GUI, one for idletasks); I have posted a feature request to that
effect eons ago...

> > E ;# setup event handler that calls B,
> > # or [after idle B], or [after 0 B])
> > A
> But this implies that you can't synchronize events back into the normal
> program flow!
> AND that you have to capture the remainder of your tcl-script into
> the trace!
> Since real programs are NOT state machines (apart from the finite stack)
> it is rather difficult to transform any program into a state machine.
> Since you can't have a return in a trace this implies unrolling procedure
> calls which is contrary to modular programming.

I'd prefer to rephrase this whole paragraph as "the migration from
nested vwaits to an event-driven state-machine *is* quite a task in the
general case".

With which I agree. I'd just add:

- the caveats above may help you keep the nested paradigm alive if
you're desperate. Consider it as a quick and dirty solution, which may
save lives :)
- *if* you decide to make the leap towards state machines, you'll in
general be glad you did, because the resulting automaton will be able to
handle properly more cases, including pathologically disordered events
(which are not so unfrequent if they come through separate channels).

> I certainly don't insist on vwait, but am I supposed to accept that there is
> no way to do an rpc package where a function sends a command down a socket,
> waits for a response without blocking the whole app and returns with the result?

There's still hope - see above.

> Is it really bad programming style to encapsule rpcs into normal function
> calls?
>
> like
> set A [rpc $rpcchannel "expr 1 + 1"]

Not at all; it is good and natural style. All this simply brings back to
light the need for filtered vwaits.

-Alex

Alexandre Ferrieux

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
Donal K. Fellows wrote:
>
> In article <376FC8DB...@wxs.nl>,
> Jan Nijtmans <Jan.Ni...@wxs.nl> wrote:
> > Let me give some example why I think that it is very useful to have
> > an implicit start of the event loop at the end of the script (which
> > is different from the end of the application)
> >
> > Some simple minimal code:
> > # hello.tcl variant
> > package require Tk
> > button .b -text "button"
> > pack .b
> > vwait forever ;# This line causes the problems described below
> > # end
>
> I think that Alex would be perfectly happy if we instead did the
> following:
>
> #! /usr/local/bin/tclsh
> # This file is /usr/local/bin/wish
> package require Tk
> # Well, this is a little oversimplistic. It'll do for a news posting...
> source [lindex $argv 0]
> tkwait window .; # This is what Alex means by [vwait forever] :^)

Yes :)))

>
> And:
>
> #! /usr/local/bin/wish
> # This file is foo.tcl
> button .b -text "button"
> pack .b
>
> Like this, we have the orthogonality that Alex likes (many others too,
> including myself) while still maintaining the ease of use for normal
> scripts.


Exactly. Thanks Donal for saying (again) better than I ever managed to,
the obvious reality. I hereby yield control of this thread to you :^)
since we're clearly in total sync and your style blatantly outperforms
mine in both efficiency and linguistic quality !!!

-Alex

Don Porter

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> wrote:
> Yes, because *tclsh* scripts are not *wish* scripts nor are they
> *your-expect-variant* scripts.

I guess we'll put you down for the "scripts should select their shells"
camp. :)

I think in the longer term we should either get away from the
requirement that scripts select a particular shell, or else build up a
cross-platform mechanism to support shell-selection, with each shell
somehow registering what packages and other features it provides.

For the next stage of Tcl evolution, though, the move to "wish
implemented as a Tcl script" seems as if it ought to satisfy everyone.

The current "out of the box" situation: Some scripts are tclsh scripts.
Some are wish scripts. Any script containing Tk commands is a wish
script because Tk is not loadable into tclsh. Each script must use
some platform-specific mechanism to select the appropriate shell for
its evaluation because there is no cross-platform mechanism for shell
selection. Any script which wants to run in both tclsh and wish and
behave the same way in either shell must explicitly end in either
[exit 0] or [vwait forever].

The next stage: Tk becomes a loadable extension. wish gets
re-implemented as a pure Tcl script. Scripts are still tclsh scripts
or wish scripts. They still must use some platform-specific
mechanism to select the appropriate shell. The re-implementation
of wish is invisible to the scripts it evaluates. No changes are
required in them. Yet Tk is now usable in more situations since it
can be loaded into tclsh. No losses, plus a big win.

The longer term future: Scripts construct their own shells at run
time by dynamically loading extensions they need into a base
shell. There is no issue of shell-selection because all scripts start
running in the same base shell. If that base interpreter is tclsh,
then any wish scripts will need both [package require Tk] and
[tkwait window .] to work in the new framework. Perhaps the base
shell won't even be tclsh, though, but an even smaller Tcl "kernel"
shell such as has been discussed before. Then, maybe both today's
tclsh scripts and today's wish scripts will need to add new
[package require] and other commands to keep working the same way
using a Tcl kernel + loadable extensions.

I suspect Jan has a vision something like the "one base shell"
world I just described when he proposes that [package require Tk]
should convert that base shell completely into wish-behavior.

All IMHO, of course.

Jan Nijtmans

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
Alexandre Ferrieux wrote:
> > Since

> > using "package require Tk" implies that we
> > are writing a GUI,
>
> You have very restrictive views about Tk. See Don's remarks about image
> filters.

I don't think that my view are restrictive at all. But I don't want
to start a discussion about that. The point here is another historical
design fault comes into view: Images are basically unrelated to user
interfaces so shouln't be part of Tk. It would be much better if you
could use "package require Image" to give Tcl access to image code,
and "package require Tk" if you are creating a GUI. If you
want to use Images in your GUI, load both packages. In this
way Don's image filters don't need Tk at all!!!!!

Maybe the name Tk is misleading. It would be more logical to use
"package require GUI" in order to indicate that we are writing
a GUI. But currently Tk is focussed for GUI applications, so to
me this is an equivalent. If you are not writing a GUI application,
then don't use Tk. Great image filters can still be written using
John Ellson's Gdtclft package, which doesn't need Tk at all.
Speaking of good examples............

> > In
> > the same way, it is handy that the main loop
> > is automatically started. The main point
> > here is not saving a few commands from the
> > script, but maintenance: Just because handling the
> > main event loop by applications is so complicated, why
> > not just releave the user from that!!
>

> Hear, hear boys: [tkwait window .] is too complicated for most of you,
> Jan says.

The general problem of handling event loops is indeed complicated.
"tkwait" is just one easy example of an event loop, but not
the only one. Did you ever program an event loop involving Tk
and Xt at the same time?????????

Jan Nijtmans

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
Don Porter wrote:
> I suspect Jan has a vision something like the "one base shell"
> world I just described when he proposes that [package require Tk]
> should convert that base shell completely into wish-behavior.
>
> All IMHO, of course.

Yes, but unfortunately I never wrote it down. It all started
with TkPvm needing its own event loop which conflicted with
Tk's event loop. Since then I already wrote 3 different
implementations of a general event-loop which was able
to change behavior when the application was already
running. I'm open to any input what's the best way
to implement this, but currently the implementation is
pretty stable. I understand that for people
who never experimented with the plus-patch
implementation of a Tcl event loop, it is difficult to
imagine the implications that it has. But the
biggest advantage is that it is 100% upwards
compatible with both tclsh as wish, so no
current code needs to be modified.

Jan Nijtmans

unread,
Jun 23, 1999, 3:00:00 AM6/23/99
to
Alexandre Ferrieux wrote:
> > ... or maybe use "eventloop start" (with an "eventloop stop" to round
> > out the set).
>
> So, in the end, the "programmer in you" agrees with me: Great !!! :)
>
> The "programmer in me" has long taken over the other parts :^)

So, any "programmer" _should_ vote against implicit starting of
the event loop. Thus I'm not a programmer!!!!!! Well, I wonder
what I have been doing then the past years........ ;-)

Chang LI

unread,
Jun 23, 1999, 3:00:00 AM6/23/99