(unknown charset) Re: 3.99.3

From: (unknown charset) Russ McManus <russell.mcmanus_at_gs.com>
Date: 03 Oct 1998 16:03:56 -0400

Erick Gallesio <eg_at_unice.fr> writes:

> BTW, there are far less developers for STk than for these toolkits, I
> don't know why and it is not that I only want a cathedral development
> style for STk. This is tsimply that nobody else seems to be interested
> to co-maintain it ;-)
> > My impression is that STk has a relatively low profile --- you don't
> > even find a mension of it on the Tcl/Tk web pages (where PerlTk and
> > Python are).
> >
> My interpretation is that the rms Tcl-war which arose 5 years ago
> explains that. Guile is also connected to Tk and I suppose that it is
> not mentioned too ;-)

I would like to make a potentially controversial suggestion. Perhaps
guile could become the base for STk. I know some guile/stk work has
gone on already, and that STk and bigloo are getting closer together,

I love to use STk, but I tend to use guile for it's ease of embedding.
Then I can't use STk. The Tk binding for guile stinks, compared to
STk. If I could have STk in guile, I would stand up and do a Snoopy
dance, I'd be so happy. I'm quite familiar with guile, so I could be
a resource for answering questions about how to get something working
that is currently implemented in the STk interpreter.

Some of the work is already done; there is a significant piece of
STklos implemented and downloadable from

Using guile has it's own set of issues, but there are some
considerable advantages, too. For one thing, there is a dedicated
maintainer for the interpreter itself. Also, there is a growing
developer community. There is a C compiler for Scheme code in guile
(not as nice as bigloo, I agree), too.


There is always free cheese in a mousetrap.
Received on Sat Oct 03 1998 - 22:04:42 CEST

This archive was generated by hypermail 2.3.0 : Mon Jul 21 2014 - 19:38:59 CEST