Analagous to an APL Workspace - a [tclsh] which is [persistent] between restarts ... checkpoints its entire contents to disk.

http://wiki.tcl.tk/_repo/coldtcl/ holds the remnant of coldtcl, which hasn't been worked on for years.

One such is Coldtcl
----
'''Purpose''':

If you have a large enough persistent process, you don't really need external storage.
Per-process VM size is around 2Gb.

So, you don't need a db, you can just store stuff in tcl data types.

----
'''Coldtcl - tcl workspace'''

- ''[Colin McCormack] <coldstore at users dot sf dot net> 30/05/2004''

Coldtcl makes tcl 8.5 (and earlier) checkpointable.  Runs under [Linux], YMMV.
It's based on my work on ColdStore.

Run it using ./coldtcl and you'll get a tclsh in all respects identical to your usual.

It provides a single command - [[suspend]] which writes the complete running state
of tclsh to disk in a file called coldtcl.store containing all current state of the tclsh.

A subsequent invocation of coldtcl will load coldtcl.store and restart with the entire
tclsh state restored exactly as it was when [[suspend]] was called.

The only complication is open files.  It is necessary to close all open files in
any interpreter under {} before calling [[suspend]], not doing so will cause
unpredictable results ... I doubt you'll enjoy them.
The exceptions are stdin, stdout and stderr, which are recreated anew on
every invocation.

If your workspace calls [exit] (for example as a result of an error,) you'll be left with
an unusable store.  It's probably a good idea, therefore, to modify [exit] accordingly.
I'll come up with a simple example, if people need it.

There's always the possibility that coldtcl leaks memory ... I can't be sure yet.

There's not a chance it'll suspend and resume multiple threads.  It might work if you
shut down all but the original thread, I don't know.  Quite possible.

coldtcl depends upon mmalloc, which is [GPL]'d, it is therefore, perforce, also GPL'd.

'''Performance''':

Coldtcl uses an mmap malloc to write its per-process swap to a file.  This means it'll run as fast as normal tclsh, there should be no real difference to the usual tclsh.



----
This delights [CL], who hopes to write more about it in the future.