> Heh, you convinced me to try it. :-)
>
> -Matt
>
Me too. I'm impressed by the package so far. And it'll finally force me to
learn some Lisp/Scheme, anyway. I haven't noticed it being any faster tho'
(maybe even a little slower?).
Indeed.
I just grabbed the Stk-2.1.3 source distribution and built it on my
486/33 Linux-1.1.51 box. Here are my impressions:
+ The build went very smoothly. There were a bunch of warnings:
In file included from tclInt.h:60,
from tclGet.c:33:
/usr/include/stdlib.h:197: warning: `malloc' redefined
But for the supported platforms, I would expect no installation problems.
- Every occurence of malloc() in STk is replaced by must_malloc(),
which lonjump()s to the toplevel. Hmmm... I'm not sure how this
non-local exit would affect the correctness of code throughout the
system.
+ There are small, medium, and large demo applications to verify the
build. The demo apps did signal a few strange errors, but mostly they
worked well. In the floorplan demo, after switching floors a couple
times, I got this error:
*** Error:
bad screen distance "U":
**** Tk error ("") ""
The inspector window reported this traceback:
(storereference (w (quote create) (quote polygon) 175 168 97 168 97 131 175 131 :fill "" :tags "floor3 room") "317")
(fg3 w color_offices)
(cond ((eqv? active (quote 1)) (fg1 w color_offices)) ((eqv? active (quote 2)) (fg2 w color_offices)) ((eqv? active (quote 3)) (fg3 w color_offices) ...
(begin (w (quote delete) (quote all)) (set! activefloor active) (bg1 w color_bg1 color_outline1) (bg2 w color_bg2 color_outline2) (bg3 w color_bg3 c ...
(if (not (equal? activefloor active)) (begin (w (quote delete) (quote all)) (set! activefloor active) (bg1 w color_bg1 color_outline1) (bg2 w color_ ...
(name)
- STk doesn't seem to be _exacly_ compatible with Tk. For example, I
have Tk shared libraries, and I don't think I can use them with STk
because the Tk source in the STk distribution has been modified. The ability
to go from one menu to another without releasing the mouse is present
in my "wish" demos, and not in my stk demos. I assume this is because
the version of Tk used in STk is slightly out of date.
- STk start-up is noticeably slower than Tk. The STk "widget" demo
takes about 5 seconds to start up. The Tk version takes less than a
second. This is not a precide measurement, but I believe it is
significant enough to blame it on the STk implementation or design,
and not system fluctuations.
- STk seemed to operate noticeably slower. For example, the floor plan
takes a little longer to come up in STk than in Tk. I have no data to
back this up -- just an observation. STk still seemed plenty fast
enough for any sort of application I might be interested in. We can
assume the impelementation will improve. Still -- this shows that
despite the laguage features of Tcl that might seem slow, in practice,
it's quite speedy.
+ STk includes bignums, implemented with the GNU mpz library. A
slower, non-GPL implementation is included.
+ STk includes a CLOS style object system. Typical code
looks like:
(define f (make <Frame>))
(define l (make <Label> :parent f :text "A simple demo written in STklos"))
(define c (make <Canvas> :parent f :relief "groove" :height 400 :width 700))
(define m (make <Label> :parent f :font "fixed"
:foreground "red"
:text "Button 1 to move squares. Button2 to move circles"))
I didn't see any big performance problems with this object system.
= Aside from the fact that STk has real closures and continuations
to take advantage of lexical scoping, STk does little to solve the
global-namespace problem. There's one big namespace of functions
to keep track of. Oh well, no worse than C. But not as good as
Modual-3 or python, for my purposes.
- STk does not support TK's feature of multiple interpreters. The
interpreter state is global. BIG LOSE.
= Executable size of STk is roughly the same as Tk's wish, I think.
I have shared libraries for Tcl and Tk:
-rwxr-xr-x 1 connolly users 562194 Sep 27 23:52 stk-bin*
-rwxr-xr-x 1 slackwar opt 357380 Nov 24 1993 /usr/X11/lib/libtk.so.3.1*
-rwxr-xr-x 1 slackwar opt 1452 Nov 24 1993 /usr/bin/X11/wish*
-rwxr-xr-x 1 slackwar opt 140292 Nov 24 1993 /usr/lib/libtcl.so.3.1*
total: 499124
- STk seemed more memory intensive. After brigning up the floorplan
demo on each platform, here's some data (I have a heck of a time
reading ps output, but here it is):
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
connolly 5626 2.3 7.5 405 1148 pp3 S 12:01 0:01 wish -f widget
connolly 5628 26.8 10.5 1341 1608 pp0 S 12:01 0:05 ../Src/stk-bin -f wid
^^^^ ^^^^
+ Documentation is good, though I'm not in a very good position to
judge, since I'm already intimately familiar with Tcl, Tk, and scheme.
The best doc for me was the demo code. The STk reference documentation
assumes a certain familiarity with the scheme specification R^4RS.
+ Foreign Function Interface seems quite good, though I haven't looked
closely at the garbage collection issues. It seems to have a lot of
the simplicity of the Tcl FFI, without the reference counting
nightmares of the python FFI. Tcl style FFI is also supported. I'm
not sure what the type-safety considerations are. The exception/error
handling mechanism isn't clear to me either.
- The STk library uses global names that might conflict
with other C libraries. For example:
libstk.a(stklos.o):00000eb0 T _class_of
libstk.a(tk-util.o):00000200 T _widget_name
libstk.a(error.o):000000b0 T _err
Summary: Stk works, and is fairly stable. The performance is no better
than Tk/Tcl -- perhaps a little worse. It lacks some of Tcl's maturity
-- especially it's squeaky-clean foreign function interface and
disciplined use of the C namespaces. But you like scheme's language
features, they're all available in STk.
The question for me is: which facilitates the development of large
bodies of reusable code, and which has large bodies of reusable code
available for building applications? It appears that Tcl has more
large bodies of reusable code (expect, tcl-dp), though I don't know
how much of the scheme code out there in various archives is usable
with STk.
I would like to think that scheme is superior to Tcl for development
of reuable code -- superior enough that STk libraries will be
developed and deployed faster than Tcl/Tk libraries, and eventually
scheme will be the way to go.
Scheme has suffered from an emphasis on theoretical computer science
to the exclusion of large scale software engineering principals. But
that trend is changing. The lessons learned from wigged-out analysis
of scheme are being employed in practical implementations like STk,
scheme48, and others that I'm not as familiar with (EuLisp, Dylan,
etc.).
"We want to take over the World"
Ian Horswill --- ian@ai.mit.edu
in "The Scheme Underground"
at http://www.ai.mit.edu/projects/su/su.html
I hope to see large bodies of reusable, interoperable scheme code
emerge over the coming months. Specifically, I'm interested in
distributed hypermedia applicatoins. For this, I need networking and
threads support. The trouble with scheme right now is that there are
so many ways to do things like objects that large bodies of scheme
code tend to be incompatible.
The reason I'm so big on Modula-3 is that there are large bodies of
code built around a well-specified thread interface. For example, they
have an X11 library called Tresle with the best features of
Interviews, decent performance, and an interactive applications
builder.
Perhaps there will be a marrying of the minds between the scheme48
folks and the STk folks, and we'll end up with something similar.
Dan
-- Daniel W. Connolly "We believe in the interconnectedness of all things" Software Engineer, Hal Software Systems, OLIAS project (512) 834-9962 x5010 <connolly@hal.com> http://www.hal.com/%7Econnolly/index.html