JMN 2005-08-22
tarpack is an experimental Tcl-only package for loading & creating Tcl Modules that are also valid tar archives.
This is done by adding the 1st file in the archive with a special name.. such as the Tcl comment character # or a short piece of Tcl script. I chose "package require tarpack;tarpack " as the 1st file's name and this also acts as a sort of file 'signature'. (To bootstrap the tarpack-1.0.tm module itself, the # character was used)
This first file also contains the ctrl-z (\u001A) character as a terminator at the end so that Tcl can source the tar archive.
You can examine the .tm files with a text editor and any standard tar archiving programs to get a feel for what's going on.
It is available here: http://vectorstream.com/tcl/packages/ along with the Thread & trofs packages wrapped using tarpack.. I refer to them as 'tarpacks'.
I've been playing around with modules in an attempt to reduce interp startup time. For installations with a large number of packages on auto_path and/or with network connections on the auto_path, load time for packages can be significant.
I don't know how useful tarpack will end up being - It was intended to be tcl-only so that an installation including binary packages can be created such that all packages are Tcl Modules rather than the usual packages on auto_path.
I was initially playing around with trofs as an archiver - and presumably trofs as a binary package will be much more efficient, but by wrapping trofs with tarpack, I can at least bootstrap trofs into the system without relying on auto_path.
Like trofs tarpack doesn't depend on vfs, but unlike trofs, tarpack doesn't actually 'mount' the module as part of the filesystem.
Here's a rough example of how the Thread package was wrapped as a tarpack:
%package require tarpack 1.0 %tarpack::create Thread-2.6.1.tm [list ttrace.tcl Windows-x86 FreeBSD-x86] Thread-2.6.1.tm
At this point the tar archive (and Tcl Module!) Thread-2.6.1.tm has been created with a default basic load-script. This default load-script will simply source any .tcl files we gave in the list to tarpack::create above. If there were .so or .dll files directly listed there it would have called 'load' on them. (after copying out to file system)
The load-script is also left as a separate file in the working directory. It's named {package require tarpack;tarpack }
Note the space on the end to allow the 'tarpack' command to absorb the rest of the tar header as it's 'args'.
This separate load-script can now be edited to make 'tarpack::source' & 'tarpack::load' calls to any of the wrapped files.
A subsequent tarpack::create call with the same arguments above will now use the modified load-script instead of the default.
Sorry there's no separate documentation - just some comments in the source.
More info to come soon. Hope I haven't missed any other work in this area - but it was fun and educational to play with this anyway! Would love to hear comments.