Purpose: to discuss the tcllib, uses, got-chas, etc. Most of this document is for "insiders". Newcomers might find "How to start with tcllib" useful.
Location: http://sourceforge.net/projects/tcllib/ is the official home. Additionally ftp://www.tcl.tk/pub/tcl/nightly-cvs/ is a source for snapshots of the library. A mailing list is maintained at sourceforge for reporting bugs. Manual pages for each module are available through http://tcllib.sourceforge.net/doc/index.html .
This package (and everything it contains) is part of the ActiveTcl Batteries Included distribution.
The sf project http://tcllib.sf.net/ is also home for efforts such as:
tcllib is a distribution of several packages for Tcl, all written entirely in Tcl. Here is a summary of (some of) the packages in the tcllib (version 1.6 has been released in early 2004) distributions and (some of) the commands each package provides:
A tklib module in the sourceforge tcllib project ( http://tcllib.sourceforge.net/ ) has begun, providing the structure for submitting script only tk add-on commands as well.
When Tcllib was originally released, the following was written:
In response to popular demand, the Tcl core group is introducing tcllib, a Tcl standard library. This meta-package will contain many modules, each of which is itself a standalone Tcl package. The intention is to provide commonly used functions and libraries, bundled together under a single license (BSD), and with no binary dependencies. This will encourage use and growth of the library. Once tcllib is downloaded and installed, users will be able to "package require tcllib" or "package require any_module_in_tcllib".
Releases of tcllib will be made mostly independently of releases of the Tcl/Tk core. This will allow a faster release cycle, which is important in the early stages of development. It is possible that future releases of the core will include a snapshot of the tcllib.
Initially, we have seeded the library with several modules, some written in-house at Scriptics and by the core group:
* struct: Tcl implementations of common data structures * profiler: Function level Tcl profiler * [cmdline]: getopt style command-line parser * base64: base64 encoder/decoder * fileutil: Tcl implementations of file utilities (grep, find, ...) * [pop3]: pop3 client * math: math functions (min, max, ...)
We want this to be a community-driven library, so we encourage submissions to this library. If you have a function or set of functions that you find you use frequently, send it in! Ultimately, we want community members to be responsible for modules in tcllib, having CVS write access directly to specific modules in the tree. Please do not feel that you must have a "complete" module in order to contribute -- individual functions are welcome as well.
In order to encourage growth and use of tcllib, there are some ground rules that modules added to tcllib must follow:
We feel that these rules will help to encourage contribution to the library and use of the library. Remember that almost everybody can use the BSD license, and not everybody is willing or able to compile extensions. Our ultimate goal is to encourage the use of Tcl by providing a broad, robust library of functionality.
The current status of tcllib is open alpha. We would like users to check out the current module, and see what they could add. After some period of discussion (a couple of weeks), we'd like to settle on something for an initial 1.0 release.
With regards to stdtcl, tcllib supercedes that module. Some of the packages from stdtcl were moved into tcllib, some were not. Those that were not were left out because they did not follow one or more of the guidelines above. cgitcl, for example, is not in a namespace. ftpd lacks documentation and a test suite. tcldebugger is only really useful to people with tclpro debugger. Proper replacements for these would be welcome.
Eric Melski Scriptics Corporation
A follow up article by Jeff Hobbes said:
Several have asked some basic questions of tcllib, which I will address here. We will also be creating a FAQ and web space for it (just after we figure out the best way to do it on http://tcl.activestate.com/ ). If you respond to this, please change the subject line to something appropriate and trim down this (rather long) message for your points.
The Tcl core group, with help from the community, will manage the toplevel package structure. This will prevent unlimited proliferation of names and confusing structure. We will also rely on a source like NICS:
http://pitch.nist.gov/cgi-bin/nics/cgibin/domain_list.cgi
to make sure that uniqueness is maintained amongst all packages (those in tcllib and external ones).
Names should follow some reasonable/logical structure. Expanded math functions under ::math (like setmin, setmax), extended string functions under ::str (like (un)tabify, wrap_lines), etc. We'd like to make the 1.0 release have a good set of logical packages (namespaces).
Modules (packages) within tcllib will be assigned maintainers (1+). Each maintainer will have CVS write access to that module. We would expect maintainers to follow all the basic style and quality standards for the tcllib, or risk losing CVS write privileges (not something we'd do without warning or good reason). If you want to become a module maintainer, you would just make the request to the Tcl Core Team.
tcllib can be populated with any Tcl-only packages that adhere to the tcllib standards (built as package, all in one namespace). We don't want to include C packages, following basic KISS principles. Included packages may contain reqs for C-based extensions, but they must have a Tcl-only fallback. Also, any submitted software should be under BSD, so people know that they can pick this up and use it just as they do the Tcl/Tk core now.
For the moment, we are in the alpha state, where we have only established CVS access. The framework is not yet complete (like missing easy installers and such). For that, community input would be helpful. Also, as I already said, we want to ensure that the 1.0 release is fairly "package" complete, meaning most of the toplevel packages are there, even if sparsely populated. When ready, the package will be at the Scriptics FTP site. BTW, for those who want to give us better installers, a prereq assumption is that Tcl is installed, so you could use it in the installer.
We'd like to make a 1.0.0 release sometime in April (arbitrary date chosen). After the 1.0 release, we would basically make checkpoint releases every couple of months or as a certain amount of new stuff comes in. The version management is planned as follows:
# Major version bump: reserved for when new toplevel packages are added # Minor version bump: reserved for when new subpackages are added or significant functionality (like changed API) is made to existing packages # Patch version bump: bug fixes to existing packages
We could go to a S.M.m.p system, where the new significant digit "S" refers to Structure, to allow ourselves versions in which we restructure tcllib.
Likely starting with 8.4, the core will include a snapshot release of tcllib, where tcllib maintains its own version number and is installed as a sibling to tcl<M.m>. tcllib would continue to be released separately.
A subsequent article said
From: Dan Kuchler <[email protected]> Newsgroups: comp.lang.tcl Subject: Re: Math extensions to TCLlib Date: Sun, 05 Nov 2000 08:37:57 -0800 Organization: Ajuba Solutions Message-ID: <[email protected]> References: <[email protected]> To: Morgan <[email protected]> Morgan wrote: > > [interesting proposed changes snipped] > > Also, are there any specific procedures for contributing to the > TCLlib? Anyone I need to contact or specific software I need to use? > Would this go better in a sub-package of the math portion of the TCLlib? >
It's great to hear that you are interested in helping contribute to tcllib. I thought your proposed set of functionality sounded interesting.
Some folks have shown interest in having access to the functionality available through the NumPy package (a python package) in tcl.
This might give you ideas for things that people might want.
The NumPy package is at:
http://sourceforge.net/projects/numpy/
Currently tcllib is in the process of being moved to sourceforge where it will live in the tcllib project:
http://tcllib.sourceforge.net/
I think the process for volunteering to work on a project there is to contact an admin for a project. Currently Eric Melski has been organizing tcllib development, so it might be worthwhile to contact him ( [email protected] )
Currently the web page that talks about tcllib (a little out of date) is at:
http://www.purl.org/tcl/home/software/tcllib/
As far as guidelines for contributing, I think the current requirement is that things in tcllib must be able to be run in a tcl-only mode (i.e. no binary package dependencies), and the contributed code should have either tests or documents, but preferably will have both.
There are good contribution guidelines (that also contain a link to the Tcl Sytle Guidelines) at:
http://www.purl.org/tcl/home/software/tcltk/contributing.tml
(while that page is focused on contributing to tcl/tk, most of it is relevent to tcllib as well).
I hope that helps get you started!
--Dan
Info about reporting bugs relating to tcllib was posted:
I'm the primary maintainer of Tcllib, with lots of help from various people in the community who are responsible for different bits. The library now lives at:
http://tcllib.sourceforge.net/
You can submit a bug there. Be sure to include:
- your name - your email address (so you can be contacted when the bug is fixed) - a description of the behavior you expected to see - a description of the behavior you actually saw - the version of Tcl you are using - the version of tcllib you are using - the os you are using, and the version of the os - anything else you think might be relevant
A sample script demonstrating the problem is always very helpful.
Eric Melski The Other Tcl Guy ericm at interwoven.com Interwoven, Inc.
The README [L1 ] for tcllib reads, in part, :
RCS: @(#) $Id: 1246,v 1.74 2004-07-24 06:00:15 jcw Exp $
Welcome to the tcllib, the Tcl Standard Library. This package is intended to be a collection of Tcl packages that provide utility functions useful to a large collection of Tcl programmers.
The structure of the tcllib source hierarchy is:
tcllib
+- modules
+- <module1>
+- <module2>
+- ...The install heirarchy is:
.../lib/tcllib
+- <module1>
+- <module2>
+- ...There are some base requirements that a module must meet before it will be added to tcllib:
When adding a module to tcllib, be sure to add it to the Makefile.in so it will be installed. Add a line like:
MYNEWMODULE=mynewmodule
to the list of modules at the top of the Makefile.in, and then add $(MYNEWMODULE) to the definition of the MODULES variable. This will allow users to choose which modules to install by commenting or uncommenting lines in the Makefile.
Each module source directory should have no subdirectories (other than the CVS directory), and should contain the following files:
If you do not follow this directory structure, the tcllib Makefile will fail to locate the files from the new module.
Cameron Laird has, at least in principle, sanction to comment and update tcllib. So far I've worked mostly with mime, base64, smtp, ftp, pop3, ... If you're having tcllib problems, do get in touch with me [L2 ]; it might be something I've already studied, without having yet checked in an update.
Q. What are the rules, requirements, restrictions for adding code to the tcllib?
Q. Who decides what does, or does not, get included into tcllib?
Q. Does anything get added into the library that someone submits?
Q. Can Tk specific commands be added to the tcllib?
Q. Can Expect/Tix/Snack/etc. specific commands, which depend on some outside extension but which themselves are only script based, be added?
From Andreas Kupries, this msg was provided:
1) What are the rules, requirements, restrictions for adding code to the tcllib?
See (5). Also note that a patch of an existing module or a new module should contain not only the code, but extend the testsuite and documentation (manpages) too. Both of the latter will make acceptance easier as they allow to check the correctness of the code now and in the future.
If there is trouble to write a manpage in *roff see
Mike Hall <[email protected]> Steve Simmons <[email protected]> [email protected] (Joe English)
who volunteered to help Larry Virden with writing such. Maybe they are willing to help others too. Note that I (AK) am also able to write basic *roff now.
2) Who decides what does, or does not, get included into tcllib?
Essentially the people who are registered as developers for the Tcllib SF project.
3) Does anything get added into the library that someone submits?
Yes. Recent changes were the acceptance of a patch [x] fixing a bug in pop3 and several new modules ("md5" [*], "csv", "matrix" (as part of "struct"), "report", "log" and "htmlparse").
[x] Well, the patch was accepted a long time but Scott had troubles with committing it. When he tried yesterday it worked and so this bug finally squashed too.
[*] Based upon Don Libes implementation of MD5, "md5pure", with changes by me (Trf soft dependency).
4) Can Tk specific commands be added to the tcllib?
I personally would prefer to collect such in a "tklib" project.
5) Can Expect/Tix/Snack/etc. specific commands, which depend on some outside extension but which themselves are only script based, be added?
The main rule/restriction which was setup at the beginning was that 'tcllib' is a script-only library which should work without any C-level extension. So the answer to the above is 'no'.
This however does not exclude the usage of extensions to make tcllib faster, if it does work without the extensions too, albeit slower.
Examples of this are the "mime" and "md5" modules. Both have a soft-dependency on the C-level extension "Trf". If "Trf" is present, "mime" and "md5" will use it in their implementations to make certain operations faster (base64 and md5 respectively). If it is not present, both modules will fallback to pure-tcl implementations.
In general I (AK) would advise the following:
tclguy has written, "From http://tcllib.sf.net/ go to the patch manager and post your code. You might want to examine the tcllib distro first, to see if it already fits well into an existing module, or whether one should be created for it."
See cgraph for a C version of the tcllib graph command.
Recently someone on the Tcllib mailing list (sponsered at SourceForge) asked What would one have to do to be added as a developer to Tcllib?. The answer by AK was One of the project administrators (like me) needs the name of your sourceforge user account to be able to add you to the list of developers for the project.
Other things mentioned in the recent thread were:
25 May 2004 Has the tcllib team considered adding some form of Michael Cleverly's package, nstcl? http://michael.cleverly.com/nstcl/ While most functionality is duplicated in the current distribution of tcllib, the nsset datatype is a wonderful thing to have; an indexed array! index - key - value ]. His api has some commands to utilize it as well. As an aolserver tcl coder, I work with it extensively and for me it renders the array command obsolete.
set id [ns_set create] %t2 ns_set put $id fname Michael %0 ns_set put $id lname Cleverly %1 ns_set get $id fname %Michael
As documented above, it generally isn't a matter of some team determining whether some code is worthy to add. It is typically a matter of some interested party contacting the tcllib maintainers to work out the details of their adding a new module to the library. Why not contact Michael and ask if he would like to add his code to tcllib? Over the years, it has turned out to work better if the author is involved with this process, so that no misunderstandings, etc. occur.
[ Category Package | Category Mailing List ]
http://cvs.sourceforge.net/viewcvs.py/tcllib/tcllib/README?rev=1.8&view=auto