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 [http://www.neosoft.com/tcl/ftparchive/TclX/] for downloads. Mirrors exist at several places, including Red Hat [ftp://ftp.redhat.com/], SourceForge [http://tclx.sourceforge.net/] (the real home of TclX), Slackware, [Marty Backe]'s pages [http://www.lucidway.org/Marty/Tcl/Extensions/tclx8.3.tar.gz], [Andreas Kupries]' personal snapshot repository [http://www.purl.org/net/akupries/soft/cvs-snapshots/], ... 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 * Please report bugs to http://sourceforge.net/bugs/?group_id=13247 * and place patches at http://sourceforge.net/patch/?group_id=13247 ---- 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 list]s, [cmdtrace], [edprocs], [profile], [lvarpush], [system], and set and string operations indispensable. ---- Extended Tcl has: * [abs] * [acos] * [alarm] * [asin] * [atan2] * [atan] * [bsearch] * [catclose] * [catgets] * [catopen] * [ccollate] * [cconcat] * [ceil] * [cequal] * [chgrp] * [chmod] * [chown] * [chroot] * [cindex] * [clength] * [cmdtrace] * [commandloop] * [cosh] * [cos] * [crange] * [csubstr] * [ctoken] * [ctype] * [double] * [dup] * [echo] * [edprocs] * [execl] * [exp] * [fcntl] * [flock] * [floor] * [fmod] * [fork] * [for_array_keys] * [for_recursive_glob] * [ftruncate] * [funlock] * [host_info] * [hypot] * [id] * [infox] * [intersect3] * [intersect] * [int] * [keyldel] * [keylget] * [keylkeys] * [keylset] * [kill] * [lassign] * [lcontain] * [lempty] * [lgets] * [link] * [lmatch] * [log10] * [log] * [loop] * [lrmdups] * [lvarcat] * [lvarpop] * [lvarpush] * [mainloop] * [max] * [min] * [nice] * [pipe] * [popd] * [pow] * [profile] * [profrep] * [pushd] * [random] * [readdir] * [read_file] * [recursive_glob] * [replicate] * [round] * [saveprocs] * [scancontext] * [scanfile] * [scanmatch] * [select] * [showproc] * [signal] * [sinh] * [sin] * [sleep] * [sqrt] * [sync] * [system] * [tanh] * [tan] * [times] * [translit] * [try_eval] * [umask] * [union] * [wait] * [write_file] * [help] * [helpcd] * [helppwd] * [apropos] * [auto_commands] * [buildpackageindex] * [convert_lib] * [loadlibindex] * [auto_packages] * [auto_load_file] * [searchpath] 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: * [tclx file commands for core] * [tclx signal commands for core] * [tclx system control commands for core] 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 : * build on Mac OS X, Linux (Unix) and Windows (SFU) with '''all''' features * ''all'' test-cases are now tcltest 2.2 ready * the tclx shell ''tcl'' now uses the ''tclsh'' setup * the ''configure'' is now Windows (SFU) ready * the very limited win32 support is now fully gone -> use Windows (SFU) the future of tclx: * this release (8.4.6) is the last traditional tclx release * the next release will split the different features of tclx into sparat extensions under the roof of tclx * tclx will be the startingpoint for something like binary tcllib future tclx extensions: * POSIX (collection of all POSIX commands) * signal (signal handling) * ... [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 1. gut everything useful from tclx, move it into tcl core, and leave tclx a hollow/compatibility shell? 2. move useful stuff to tcl core, leave tclx a compatibility extension and a proving/testing ground for new and out-there features? (The two sub-goals are mutually exclusive, really, because you can't be both compatible and a place for new stuff) 3. leave tclx exactly as it is and not steal functionality? (I don't think this is really viable) 4. roll much of the tclx functionality into a loadable module which is part of tcl core? 5. some other alternative, suggest ... [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. ---- [Category Package]