ActiveState is pleased to announce the 220.127.116.11 release of the ActiveTcl
distribution for the Tcl scripting language. This is the second release
based on the Tcl/Tk 8.3.3 language core. More details can be found below.
Where to get the new releases:
ActiveTcl 18.104.22.168 binaries for Windows, Linux and Solaris are available
at our web site:
What is in this release:
ActiveTcl 22.214.171.124 is made up of the latest stable core of Tcl (8.3.3),
plus the following extensions:
* Tk 8.3.3 <http://tktoolkit.sourceforge.net/>
* [incr Tcl/Tk] 3.2 <http://incrtcl.sourceforge.net/>
* iwidgets 3.0.2 <http://incrtcl.sourceforge.net/>
* Tcllib 1.0 <http://tcllib.sourceforge.net/>
* Bwidgets 1.3.1 <http://tcllib.sourceforge.net/>
* tktable 2.7 <http://tktable.sourceforge.net/>
* tkcon 2.2 <http://tkcon.sourceforge.net/>
* TclX 8.3 <http://tclx.sourceforge.net/>
* expect 5.32 <http://expect.nist.gov/> (Unix only).
For additional information:
For more information on Tcl and its many extensions, please visit the
Tcl Developer Xchange web site:
This site contains a variety of information about Tcl/Tk in general,
the core Tcl and Tk distributions, the TclPro tool suite, and much more.
Tcl/Tk is maintained by the Tcl community, with the sources and bug
database at SourceForge:
Everyone is encouraged to participate in making Tcl an even better
language. For bugs related to the ActiveTcl packaged distribution,
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
I'm surprised Blt and Tix isn't included (less surprised about Tix). Are they on
Otherwise, looks like a nice distribution. Thanks.
We will be making update releases as new versions of constituent
packages come out. In fact, it may be that future releases are
a bit leaner, with more optional packages.
> I'm surprised Blt and Tix isn't included (less surprised about Tix). Are they on
> the roadmap?
One of the main keys is TEA compliance, or basic ease of auto-build
and install. Also, this isn't meant to be the last version. There
will definitely be more. However, ActiveState's next push will be
to create a repository of modules that a base ActiveTcl release
will draw from.
As I noted above, this may not be the face of the final ActiveTcl
base, this is just a stepping stone. There are pieces missing
that an extensible ActiveTcl will need, and there are pieces that
could be removed.
As a side note, I really am interested in hearing others opinions
on what is and is not in the release, how the release is organized
(size vs. extensibility), and other such issues.
I will be holding a BoF at the OSCON next week to discuss these
in depth, and allow everyone to give their input on how they
would like to see ActiveTcl progress in the future.
since, i'm going to have to miss your BoF, due to an important concert just
down the street, i'll weigh in for BLT here also; the graph widget in
particular. in addition to that, though, i'd like to see some of the Windows
interface extensions (printing and ActiveX and it's ilk come immediately to
mind) rise to the surface of the distributions. Windows is so pervasive
that, like it or not, if there is the slightest of bumps in the road, a
Windows-centric manager or engineer will nix a Tcl-based solution
immediately. It's happening to me, almost as I write.
email - craig_denson at ttmengineering dot com
Nice work, dude!
ps - isn't GAH a butthead? :b
>Windows is so pervasive
>that, like it or not, if there is the slightest of bumps in the road, a
>Windows-centric manager or engineer will nix a Tcl-based solution
>immediately. It's happening to me, almost as I write.
`--- I vote that quote-of-the week :)
David Gravereaux <davy...@pobox.com>
-=[ Ray's Pizza, NYC on every street corner, to serve you best.
Right next to Gray's Papaya and the korean market ]=-
>Can it be? The fabled BI distribution of Tcl finally come
>to fruition? Truly, you sir are a prophet, a savior, come
>to lead us out of darkness into a glorious new age!
Your eloquence of words, dear sir, are true to the milestone acquired, and thust
thou speaks for all in thine glory of what has been achieved for all to share in
thus magical binary. May it be mirrored and copied in a great logarithmic
growth. May it spread like the great plains grasses across the land...
Now if we could only get an Expect porting project going for windows..
> Where to get the new releases:
> ActiveTcl 126.96.36.199 binaries for Windows, Linux and Solaris are available
> at our web site:
> What is in this release:
> ActiveTcl 188.8.131.52 is made up of the latest stable core of Tcl (8.3.3),
> plus the following extensions:
> * Tk 8.3.3 <http://tktoolkit.sourceforge.net/>
> * [incr Tcl/Tk] 3.2 <http://incrtcl.sourceforge.net/>
> * iwidgets 3.0.2 <http://incrtcl.sourceforge.net/>
> * Tcllib 1.0 <http://tcllib.sourceforge.net/>
> * Bwidgets 1.3.1 <http://tcllib.sourceforge.net/>
> * tktable 2.7 <http://tktable.sourceforge.net/>
> * tkcon 2.2 <http://tkcon.sourceforge.net/>
> * TclX 8.3 <http://tclx.sourceforge.net/>
> * expect 5.32 <http://expect.nist.gov/> (Unix only).
I will add my praise for a job well done!
I will also add a vote to get BLT added if/when possible.
After OSCON I will be looking into a few more platforms to
add to the standard distributions, HP-11 included.
I definitely sympathize. I've been having fun playing around
with optcl and tcom on Windows, and I'd definitely like others
to be able to use them in an out-of-the-box manner.
The question is how large should this standard distro be, and
how much should we depend on a (soon-to-be-coming) repository
> The question is how large should this standard distro be, and how
> much should we depend on a (soon-to-be-coming) repository of
If they are easy to get, lots... I can't wait to see this happen
though, we need it *really, really* badly:-)
I'm quite excited by this new release; I'd noticed one or two
"Batteries Included" builds done experimentally by various
individuals, but I hadn't realized that plans for a supported,
"official" BI distribution were so far advanced. Kudos to
all involved, and I'm eager to see how it develops.
The one piece that's missing, from my point of
view, is the Img extension.
I thought Img had been merged into the core?
As MIT is not "Massachusetts" neither is RPI "Rensselaer"
The Img patches have been, but not Img itself. The reason is that
it has the outside library dependencies of a sort that the core has
not had to deal with before. This is likely going to be part of
ActiveTcl in the future, but in the base package or in the
repository hasn't yet been determined.
I downloaded the windows as well as the solaris version. The download
times were reasonable (just about right) and the installation process
itself is fairly quick. I especially liked the support for both:
text-based as well as gui-based installation on solaris platform.
I liked the idea of making this distribution even leaner, and having
more optional packages. Moving forward, I would like to see the
o a central repository of extensions under purl
(I beleive this is already being planned)
o flexibility to download and install an extension from
any other web-server, which is compliant with ActiveTcl's
method of hosting optional packages
o support for a configuration file which can be used with
the installer to download a pre-configured list of
optional packages (without requiring user intervention).
o support for uninstalling a package, if the user decides
to save on disk space
o I noticed that the gui-based installer does not have
an "Exit" button. One has to kill the window if she
decides to abort the installation.
o I also noticed that the solaris distribution contains
tclsh (71120b), tclsh83 (39049b), wish (72152b) and
wish83 (39606b). What is the difference between these
Once again, thank you for providing this release.
One of the things I did at Tcl'Europe, after the roadmap poll, was to ask
the audience to
nominate extensions which should be in a BI distribution. When the
nominations died down
I took a vote to determine their relative importance. I posted the results
here, as part of my
report on Tcl'Europe.
I can repost them if that is wanted ... Hm, I don't remember placing it on
the wiki. I guess
I'll do this now.
Andreas Kupries <andr...@ActiveState.com>
Developer @ http://www.ActiveState.com
You saw the recent announcement of a LA (linear algebra) package ?
sorry, but you mixed "Img the extension" with the Img-patch.
The latter was included in the core AFAIK
Only the modifications for Tk to support transparency and a few other
odds and ends. The various image type support is still split out into
"See, he's not just anyone ... he's my son." Mark Schultz
<URL: mailto:lvi...@cas.org> <URL: http://www.purl.org/NET/lvirden/>
Even if explicitly stated to the contrary, nothing in this posting
Version 1.4 can be downloaded from the site:
The second (supplementary) link contains additional examples - the separate
downloads are necessary only due to file size limitations. The README file
for the second link explains how to amalgamate the two downloads.
A paper is being presented to the 8th Annual Tcl Conference, San Diago, 23rd
to 27th July 2001.
The download contains all binaries needed for Linux. The README files give
full details on building the necessary releases of Tcl and extensions.
The software should be regarded as being at an alpha stage. Any feedback
would be most welcome.
> * [incr Tcl/Tk] 3.2 <http://incrtcl.sourceforge.net/>
Actually, it's 3.2.1 . I just checked. Just a bug fix release that's improved
upon since 3.2.0 from last August(?). I don't recall the exact number, but at
least 30 items got repaired.
Jeff, thanks for using the head on CVS!
David Gravereaux <davy...@pobox.com>
Does this mean that AS is working on some kind of extension installer for
Tcl? One thing I've suggested we discuss on the tclish list is just this.
It would be good if package descriptions and formats could be standardised
in some way.
The application I imagined would query a repository of extensions and
present a list to the user, download selected extensions and install them
on the local system.
Steve Cassidy............SHLRC, Macquarie University, Sydney, Australia
> The application I imagined would query a repository of extensions and
> present a list to the user, download selected extensions and install them
> on the local system.
That's the general idea. ActiveState would create the repository
as well, one that would work across multiple languages, so it gets
a little more complex (which is why it isn't done already).
Thanks to you and Chad for doing a great job keeping this extension
up to date! I'm always watching...
I have a question about that though.
When are you going to include 'expect 5.32 (Windows NT/2000 version)'?
I think expect is one of the most important part in Tcl/tk.
But always, it's not included in new release, specially for windows. :(
with Appreciating your support...
Wouldn't it be neat if, during OSCON, we could all get together several
times - maybe once on Monday since there isn't anything specifically Tcl
organized then yet! - and plan out what contributions people were interested
to make. Even neater, if by the end of the week a dozen or two new platforms
were ready to be imported into the repository (once the ActiveState gang
makes it back to home base...)
This sounds like good fodder for a BoF this week at Open Source Convention -
will active tclish members be around?
Is there a port of the newest version available? I just checked and
Expect 5.21 is the last version ported to Windows. No one from the
Windows development community has stepped forward to do much about it
as far as I can tell. The http://expect.nist.gov/ site does mention
something about a cygwin port of Expect, but following the link didn't
seem to lead me to a site where I was able to find it.
Jeff, do you have any comments on this issue - what is the common thread
in the extensions included - why some TEA compliant extensions and not
others? Were the ones included the ones that ActiveState deemed
most useful, the ones that were able to be built without trouble, the ones
that developers at ActiveState were most interested in supporting, ...
Some time ago I thought about a package system and got to the conclusion
that a system with two stages would be much better. Create a repository
with package description files only (XML files, one per package, with
version, dependency information and all in it) and point in that
description file to the actual download location for the package itself
(which can be somewhere out in the net).
The installer then can offer the user a list of packages build from that
XML-files in the repository. After selecting a package the installer
first reads the description file from the repository and presents the
user a list of download locations for the package. After selecting one
location, the installer downloads the package itself and installs it
along with its description file. A developer then just has to write such
an description file for his package and submit it to the repository to
make his package available. If he has a new version of his
package/software he submits another description file and so on. This way
the description files hold meta information (especially dependencies)
that can be used by the installer application to query the users system
as well as available packages in the repository.
The description file could look like this:
<description lang="en">blah blah</description>
Does that make sense? OK, I made this example out of thin air, but in
principle this would allow both "battery included" distributions (just
distribute Tcl/Tk preloaded with a bunch of packages and their
description files) and bare bones distributions (which then can be
spiced up by the user by pointing the installer to the repository and
install what he needs).
Somebody has already defined an XML document for this sort of thing. Check
out the W3C note on "OSD" (Open Software Description)
Searching for "Open Software Description" on google yields many more links
on the subject, including this one:
... which makes me think activestate may already be going down this path.
> Somebody has already defined an XML document for this sort of thing. Check
> out the W3C note on "OSD" (Open Software Description)
> Searching for "Open Software Description" on google yields many more links
> on the subject, including this one:
> ... which makes me think activestate may already be going down this path.
It would be useful to know if this is the case. The OSD format seems to
contain much of the useful info that might be needed for an installer and
is of course extensible since it's XML. Support for this format from AS
would be a good argument for using it in the tcl installer project.
Ah! Nice to see that Microsoft cares for Open Software packages. This is
a very simple format, though. I can't imagine that this is usable also
as meta data format for *installed* software, since dependecies are
expressed as URL pointing to another description file out on the net.
There is too little abstraction in it IMHO.
Example of an OSD file:
<SOFTPKG NAME="com.foobar.www.Solitaire" VERSION="1,0,0,0">
<ABSTRACT>Solitaire by FooBar Corporation</ABSTRACT>
<LICENSE HREF="http://www.foobar.com/solitaire/license.html" />
<!--FooBar Solitaire is implemented in native code for Win32, Java code for other platforms -->
<OS VALUE="WinNT"><OSVERSION VALUE="4,0,0,0"/></OS>
<PROCESSOR VALUE="x86" />
<LANGUAGE VALUE="en" />
<CODEBASE HREF="http://www.foobar.org/solitaire.cab" />
<IMPLTYPE VALUE="Java" />
<CODEBASE HREF="http://www.foobar.org/solitaire.jar" />
<!-- The Java implementation needs the DeckOfCards object -->
<CODEBASE HREF="http://www.foobar.org/cards.osd" />
A dependency should IMHO be expressed as an ID for the needed Software,
not a real URL somewhere. Otherwise this is just usable for describing
downloadable packages but not for already installed packages or packages
already delivered with a distribution. The ID being just the NAME
attribute of another description file (which then can be looked up on
the local machine or the repository) seems Ok, but using the hardcoded
*location* as a dependency makes it impossible to check if the needed
other package is already installed or on the nifty distribution CD you
> Searching for "Open Software Description" on google yields many more links
> on the subject, including this one:
> .... which makes me think activestate may already be going down this path.
Activestate seems to use this for its Win32 Perl packages. I'm wondering
if this is also used for installer software keeping track of installed
packages and untangling dependecies between them. Most probably not.
It is a nice base though. Some changes and it might work out. A system
like this would be especially great since one could instantly start to
use it. Just write an installer app, start to write description files
for existing packages, fill the repository with those and it's already
"I love deadlines. I love the whooshing sound they make as they fly by."
-- Douglas Adams
Of course, this is why we need an installer package...
> A dependency should IMHO be expressed as an ID for the needed Software,
> not a real URL somewhere.
I suppose you could always put »sw://tcl/8.3.2« instead of an URL that
points to a real WWW server ... Once we have something like C[PT]AN in
place, we can fix our installer to translate this into something
retrievable. (You could probably even make it work for other stuff
using something like FTPsearch.)
Anselm Lingnau .......................................... ans...@strathspey.org
All men dream: but not equally. Those who dream by night in the dusty recesses
of their minds wake up in the day to find that it was vanity: but the dreamers
of the day are dangerous men, for they may act their dreams with open eyes,
to make it possible. -- T. E. Lawrence, *Seven Pillars of Wisdom*
This is more or less what I meant with an ID (instead a location), just
that I would put the version information apart from that in an element
or attribute of its own...
An URL is needed anyway to download the package. Or several URLs to give
the user an option to select one download location.
>The question is how large should this standard distro be, and
>how much should we depend on a (soon-to-be-coming) repository
Play each one by ear. If a given module is easy to add, add it. If
it's hard, wait for the repository.
"The optimist proclaims that we live in the best of all possible worlds;
and the pessimist fears this is true."
-- James Branch Cabell, from 'The Silver Stallion', 1926.
Thanks for the note. Please submit it also to http://bugs.activestate.com/
if you haven't already.
Thanks for the note. Please submit it also to http://bugs.activestate.com/
You are a very close to what we are working on. It will be
a solution with XML metadata. In fact, you can find part of
it now in the ActivePerl PPM (programmer's package manager).
That's just a part though - the actual code repository takes
a bit as well (because it is a web service).
Ah, but sometimes the hard ones are the most worth working on,
because they improve functionality for all.
There is no recent expect port to Windows, and noone so far has
been willing to step forward and do the port or foot the bill for
it to be done...
> Jeff, do you have any comments on this issue - what is the common thread
> in the extensions included - why some TEA compliant extensions and not
> others? Were the ones included the ones that ActiveState deemed
> most useful, the ones that were able to be built without trouble, the ones
> that developers at ActiveState were most interested in supporting, ...
It was a mixture of value level, and comfort level. We wanted
to get things like [incr Tcl] and TclX in because of the value
for others, even though the builds aren't super-TEA clean.
Others were just easy to add in. This was just the first step
in what I hope will become the defining standard for BI Tcl
distros. That doesn't mean it won't change (and likely it will,
especially once we get the repository working).
Seems like Expect can be split into two parts. One part that deals
with Unix tty communication. The other part that does the text
matching on data receviced from a channel.
On windows, most people would be satisfied with just the second part,
processing data received from any Tcl channel. This part should be
very portable. For my work, we are using Expect to talk to router
devices via Telnet and we wanted to use Expect on Windows/Solari. But
it was too difficult trying to get Expect compiled on Windows. We had
to write our own version of cross-platform Expect (in Tcl) that works
on top of Tcl channels.
-- Jiang Wu
I won't be able to attended OSCON but the current bundle looks
pretty good for a start.
Things I would like to see in the future:
an absolute must unless there is something better
or something better?
I'm not currently using this but have in the passed and
I'm sure others would like to see this package included
Comments on what you currently have included.
[incr Tcl/Tk] and iwidgets
I used to uses this packages but since the user community
seems to be focused on using namespaces I am probably going
to give up on these packages
I am starting to use these but there are some really major
holes (like an html widget for help etc.)
I am currently using the Protcl distribution which didn't
include this package and since it needs to be compiled it is
a hassle. I will undoubtedly use it now that I don't have to
mess with the compile.
I don't use this. I assume its primary benefit is on a
Windows machine. I do my work on Unix.
I used to use this package all the time but now most of the
useful functionally is in the core. I think you could
consider dropping this package.
I've used this package and been glad it was available.
> Steve Cassidy wrote:
>> There is a bug in the windows installer which manifests when Tcl is
>> installed on a path with spaces, the registry entries and start menu
>> items need to have quotes wrapped around them if there are spaces in the
> Thanks for the note. Please submit it also to
> http://bugs.activestate.com/ if you haven't already.
Hmm.. I tried to just now, created an account and logged in to ASPN but it
doesn't seem to know me at bugs.activestate.com. I guess there's a time
lag between the servers??? I'll try again later but this isn't going to
help getting bug reports submitted.
You should try tkcon, Tom. It has lots of benefits, but it is even
better on Unix, where the default interactive tclsh/wish console is a
little weak. (unless you never use command recall or command
> You are a very close to what we are working on. It will be a
> solution with XML metadata. In fact, you can find part of it now in
> the ActivePerl PPM (programmer's package manager). That's just a
> part though - the actual code repository takes a bit as well
> (because it is a web service).
Will this stuff be free software?
The actual web service code? Likely not, however the PPM code
will most likely be open source (distributed with ActiveTcl),
and the binaries in the repository won't require any
subscription or anything (kinda like CPAN, but better).
Actually, the latter is available in the core now, in the
test code. It is testchannel stack and unstack (or perhaps
the subcommand is transform). This is an adaptation of
Andreas Kupries' iogt (IO generic transform) package. I'm
hoping that a near future version of Tcl exposes the Tcl
level commands in the core.
I'm confused by your comment - incr Tcl INVENTED the basis of the
current Tcl namespace functionality; it works very well on it.
Or do you mean that you are giving up on writing OO code and
now only doing name space management (a smaller domain)?
:I don't use this. I assume its primary benefit is on a
:Windows machine. I do my work on Unix.
Actually, it's primary benefit is on Unix, where people continue
to ask for the ability to have command history, etc. Windows
has come with this tool for quite some time - now the 2 unix binary
distributions that ActiveTcl supports come also with it.
:I used to use this package all the time but now most of the
:useful functionally is in the core. I think you could
:consider dropping this package.
Please don't - this is yet another indispensible package, since it is
the primary place to get things like the tcl binding for kill and other
Posix OS interfaces exposed to Tcl.
:I've used this package and been glad it was available.
Is that a "we" as in ActiveState?
If so, and from what I see around the conference that sounds like
about right, then the rest of the community needs to continue on the
path of working on parallel, or at least complementary, services, right?
Because ActiveState is unlikely to allow Joe Smoo have the build scripts
and code necessary to make HPUX, or VMS, or IRIX, or ... binary packages
available, right? Or is this one of those deals where people build
things on their own, using whatever config options and hacks they
wish, and then submit their binaries for inclusion in a central 'library'?
> Tom Krehbiel wrote:
> > tkcon
> > I don't use this. I assume its primary benefit is on a
> > Windows machine. I do my work on Unix.
> You should try tkcon, Tom. It has lots of benefits, but it is even
> better on Unix, where the default interactive tclsh/wish console is a
> little weak. (unless you never use command recall or command
"tclreadline" is better on UNIX
with tclreadline you can work as you work with bash, ...
and start curses based application's like vi, ....
and eval/test Tcl statements
the goal for tkcon is every place there term/readline
does not work ... Win, Mac, Browser, ...
(C) Compiler-Factory Phone: ++49-(0)8152-399540
Dipl.-Ing Andreas Otto mailto:in...@compiler-factory.com
Business Solutions http://www.compiler-factory.com
Ulmenstrasse 3 => "Compiler", FastWeb, OpMenu
D-34289 Zierenberg => C, C++, Tcl, HTML, database,
> "David N. Welton" wrote:
> > Jeffrey Hobbs <Je...@ActiveState.com> writes:
> > > You are a very close to what we are working on. It will be a
> > > solution with XML metadata. In fact, you can find part of it now in
> > > the ActivePerl PPM (programmer's package manager). That's just a
> > > part though - the actual code repository takes a bit as well
> > > (because it is a web service).
> > Will this stuff be free software?
> The actual web service code? Likely not, however the PPM code will
> most likely be open source (distributed with ActiveTcl), and the
> binaries in the repository won't require any subscription or
> anything (kinda like CPAN, but better).
I guess what I'm trying to figure out is how entangled this system is
going to be with activestate. Tcl desperately needs a repository of
packages that have had at least a minimal amount of QA. For instance,
a few days ago, some individual was seeking an XML package. Half the
URLs that he tried weren't even functional. With Python, all I have
to do is:
@ashland [~] $ python
>>> import xmllib
And I'm ready to go.
Anyway, that's besides the point... What I want to know is whether we
will have a system that will work, or could be made to work quickly,
should activestate drop out of the picture.
I suppose I'm a little confused about what role activestate intends to
play in everything... I don't want 'activestate' tcl, particularly -
plain old Tcl is fine with me. If activestate wants to sponsor Tcl
development and brag about it, that's great too, I'm just a bit unsure
as to what's what. Please don't read this as a complaint/flame, but
more as a rambling question not posited in the clearest of language:-)
> Anyway, that's besides the point... What I want to know is whether we
> will have a system that will work, or could be made to work quickly,
> should activestate drop out of the picture.
> I suppose I'm a little confused about what role activestate intends to
> play in everything... I don't want 'activestate' tcl, particularly -
> plain old Tcl is fine with me. If activestate wants to sponsor Tcl
> development and brag about it, that's great too, I'm just a bit unsure
> as to what's what. Please don't read this as a complaint/flame, but
> more as a rambling question not posited in the clearest of language:-)
I hope we can take the initiative here. ActiveState obviously has a
commercial interest in setting this up and will hopefully be around for
long enough to provide a useful repository. However, even if they do set
this up soon, I wouldn't like them to be the *only* extension repository
I think we need a distributed model like the C?AN networks based on an open
software architecture and package description format. If we can begin to
put this into place now, we may be able to do it with AS rather than
setting up an alternative system (don't take this as criticism of AS, just
an acknowledgement that they have commercial interests and that tcl
shouldn't rely purely on todays sponsor company).
I'd invite you to subscribe to the tclish list and discuss this over there:
> If so, and from what I see around the conference that sounds like
> about right, then the rest of the community needs to continue on the
> path of working on parallel, or at least complementary, services, right?
> Because ActiveState is unlikely to allow Joe Smoo have the build scripts
> and code necessary to make HPUX, or VMS, or IRIX, or ... binary packages
> available, right? Or is this one of those deals where people build
> things on their own, using whatever config options and hacks they
> wish, and then submit their binaries for inclusion in a central 'library'?
To be completely honest, I haven't gotten that far yet.
That is unfortunately not a decision that I make alone.