Purpose: to describe the Extended Tcl extension's capabilities.
'official' tclx home page is http://tclx.sf.net/
see ftp://ftp.tcl.tk/pub/tcl/nightly-cvs/ for a tar file of the sf.net cvs head .
IMPORTANT: the Neosoft TclX home page is out-of-date and perhaps even gone by this time. In fact, most of the online resources formerly at Neosoft are now at ProcPlace. Most crucially, ftp access to the NeoSoft archive is broken, and it's apparently necessary to go here [L1 ] for downloads. Mirrors exist at several places, including Red Hat [L2 ], SourceForge [L3 ] (the real home of TclX), Slackware, Marty Backe's pages [L4 ], Andreas Kupries' personal snapshot repository [L5 ], ...
Moreover, the ActiveTcl Batteries Included distribution includes TclX.
TclX (http://tclx.sf.net/ ) is an essential package of extensions for Tcl. This package creates interpreters known as tcl. It adds advanced code loading facility, new programming constructs, debugging and profiling facilities, unix access commands, file I/O facilities including awk-like scanning for strings, extended list and a new key list capability, extended character and string manipulation commands, and time and date manipulation commands.
Extended Tcl is oriented towards system programming tasks and large application development. It provides a variety of additional interfaces to the underlying operating system, as well as many new programming constructs, text manipulation tools, and debugging capabilities.
Over the years, a variety of features originally appeared in TclX, and then, as the ideas were proven, migrated to the Tcl core. These features include Tcl's I/O system, its associative arrays, Internet networking interfaces, upvar, memory debugging... even incr.
TclX includes documentation on debugging memory problems on how to use its keyed list data type, manipulating binary structures via handles, a guide to writing Tcl commands in C , and a reference manual for the new TclX commands themselves.
On SourceForge it can be found at http://sourceforge.net/projects/tclx
In the past, there was also a TkX (aka wishx) component. This part is being removed, as is the code for creating stand-alone interpreters tcl and wishx.
(Give an alternate description of TclX as Tcl augmented with POSIX stuff, such as fork, plus other conveniences common among Unixoids, including keyed lists, profiling, ...)
R. T. Wurth finds loop, commandloop, keyed lists, cmdtrace, edprocs, profile, lvarpush, system, and set and string operations indispensable.
Extended Tcl has:
The following variables are set and/or used by the Tcl shell.
argv0
Contains the name of the Tcl program specified on the com-
mand line or the name that the Tcl shell was invoked under
if no program was specified. argc Contains a count of the
number of argv arguments (0 if none). argv A list contain-
ing the arguments passed in from the command line, excluding
arguments used by the Tcl shell. The first element is the
first passed argument, not the program name.
tcl_interactive
Set to 1 if Tcl shell is invoked interactively, or 0 if the
Tcl shell is directly executing a script. Normally checked
by scripts so that they can function as a standalone appli-
cation if specified on the command line, but merely load in
and not execute if loaded during an interactive invocation
of Tcl.
auto_path
Path to search to locate Tcl autoload libraries. Used by
the both the Tcl and TclX library autoloading facility.
tclx_library
Path to the TclX runtime library. If your running the TclX
shell or an application based on it (like wishx). The TclX
initialization file normally adds this to the auto_path.
tkx_library
Path to the TkX runtime library. This is set only if your
application has called Tkx_Init. The TkX initialization
file normally adds this to the auto_path.
tcl_prompt1
Contains code to run to output the prompt used when interac-
tively prompting for commands.
tcl_prompt2
Contains code to run to output the prompt used when interac-
tively prompting for continuation of an incomplete command.
TCLXENV
Array that contains information used internally by various
Tcl procedures that are part of the TclX shell.
Karl Lehenbauer first wrote TclX, and he and Mark Diekhans maintained it for a long time. In spring 2002, Jeffrey Hobbs is "reforming" TclX, although he doesn't "own" it.
CMcC: thinking about gutting TclX and moving some more useful functionality into tcl core. To that end, here are some think-pages:
The most frequent request is to move the TclX signal handling commands into Tcl.
TclX is a grab-bag of useful functionality, a proving ground for new/nice facilities. They should be handled independently, so I have three categories.
Another suggestion that's been made in the past is to create an extension that provides Tcl bindings for the most useful Posix functions.
DKF: Useful Posix stuff (to me) has been: all the signal stuff, fork/execl, id and times. YMMV. :^)
Andreas Otto: (23 may 2004) I ported tclx to 8.4.6
the current state of tclx :
the future of tclx:
future tclx extensions:
CMcC: Oh! I've been charging along trying to gut tclx, and not aware of your work, Andreas.
I'd like to see a lot more of tclx's functionality incorporated into core tcl, because a lot of it is very useful, and the hassle of making an extension is probably beyond a lot of newbie tclers.
Is it better to
CMcC: My personal feeling is that something between 1. (gut tclx) and 4. (keep some integrity) is best, but I think some of the file commands, for example, should completely disappear into tcl's file command. That kind of leaves the signal, posix and miscellaneous facilities. Signal and posix could remain as distinct modules, but they ought to be tied more to the core IMHO. Which leaves us with miscellaneous category (help and such) which aren't core facilities, things like keyed lists which are superceded/obsoleted by new tcl developments (qv dict), and useful stuff like intersect3 which should be in tcllib.
That's how I see it, anyway ... move useful stuff into core, leave tclx behind because it now has a long history and can't function as a new facilities proving ground because of the need to remain compatible. Then another such extension collection can be made, and the cycle continues.
I hope this isn't perceived as cruel or uncaring, I just think TclX has succeeded beyond the point where it should be kept distinct from the core. Although creating a distinct binary tcllib umbrella and calling that TclX is a very appealing concept, it would necessarily have to carry along TclX's baggage, wouldn't it? I love the idea of a binary tcllib, but I think it has to be a clean break with TclX because otherwise we might perpetuate the disparate interfaces, the obsolete commands, and other stuff which TclX compatibility entails.
I hope the idea of a binary tcllib succeeds so well that whole slabs of core tcl functionality could move into it.
Personally, I don't love the idea of extensions containing generally useful, and sometimes essential functionality, because they are hard for newbies to get and load, and their lack impoverishes tcl relative to some other systems and languages.
The best possible solution would be for a packaging system for tcl which made it trivially easy to acquire essential functionality. Tcl doesn't have it, Python does, PERL does, and that's (I think) why they are perceived more positively. We're not close to having a universally workable trivially easy distribution/packaging solution for tcl, (StarKit notwithstanding), so the only reasonable solution is for tcl core to cannibalise essential functionality.
Moreover, if TclX, expect, et al are to provide essential functionality, I think they need to take over all of the functionality for Tcl - it makes no sense to me to have some essential (or at least wildly useful) file functionality in Tcl, and some in TclX, without a coherent interface. The extensions aren't modular, and to get the functionality people need, they have to cobble together disparate extensions, using incompatible build systems, with different degrees of interoperability (e.g. TclX hangs tclhttpd, apparently.)
There's possibly a reasonable question of how much of the TclX functionality TCT want to own, given the added maintenance workload. It seems to me that tcl core has to either support concepts like file completely, or not at all. If tcl core can't/won't support file in all its possible expressive richness, then it should simply move all file functionality into a distinct module.
The other consideration is that at least some of TclX is a thin wrapper around standard POSIX functions. Things like critcl are useful in that, as userid shows. This raises questions of packaging and building ... which are interesting challenges to the way we look at tcl.
I didn't intend to turn this into a political rant, but ... stuff happens :)