Mike Newman writes in his e-mail message:

I hope there will be some sort of checkpointing facility which will
allow one to look at big presentations - this does not seem to be
routinely available in GAP which somewhat surprised me.

Let me first provide my definition of a checkpoint, so that you can make
sure we are talking about the same thing.

A *checkpoint* allows a user of a computer system to undo or cancel
everything the system has been doing since the time the checkpoint
was passed. (Note that usually only internal changes of the state
are undone. External changes, such as writing to external files,
are usually not undone.)

For example, suppose you are playing a computer adventure game. You are
about to drink a potion you just found. However, you are not certain
that this is a good idea. So you insert a checkpoint. Then you try the
potion. If it turns out that the potion is lethal, you undo everything
back to the checkpoint and put the potion in your bag (to offer it to
monsters later).

For a more serious example, suppose you are working with a big
presentation in GAP. You are about to replace a certain generator by a
word in the other generators. However, you are not certain that this is
a good idea. If GAP supported checkpoints, you could now simply insert
one. Then you could try the substitution. If it turns out later that
this was not a good idea, you could undo everything back to the
checkpoint and could try another substitution.

One way to implement checkpoints is to journal all commands the user
issued, and to remember how each of them changed the state of the system.
To go back to a checkpoint you go backwards through the history, undoing
every single step. Some editors do this.

The more usual way to implement checkpoints is to save the state of the
system as a workspace file. To go back to the checkpoint you can then
simply load this workspace file.

I think this is what Mike had in mind. Certainly Frank and Joachim
understood it this way, because they wrote:

We think what you mean with checkpoints is that one can break the
execution at prearranged points and save the workspace to disk.

With workspaces it would also be possible to save the state of a
computation to a file, log out, go home, come back the next evening, log
on, start GAP again, and continue the computation by loading the
workspace. Note that this has very little to do with checkpoints.
Frank and Joachim show that most of this effect can be achieved
without workspaces:

If you need to logout or want to change terminals you should install
'screen' (a PD program) which will give you pseudo terminals. Using
this program you can break GAP, stay in the breakloop and detach your
terminal from the pseudo terminal. It is possible to resume execution
at exactly the same point of the calculation. Of course GAP will
still use parts of the swap space this way.

Sidenote 1: there are many ways you can *break* GAP,
but what you mean here is to *interrupt* GAP (I hope ;-)
Sidenote 2: some users achieve this by simply refusing to lock out ;-)

Werner Nickel points out that there is even another use for checkpoints:

In their comment on the issue of `checkpoints' in GAP Frank Celler
and Prof. Neubueser don't mention a point that I find very important.
If one runs a calculation that might take several weeks (or even
months) of CPU time, it is crucial to have the possibility to save
the current status of a computation at a given time. The reasons why
it is so crucial is simple: During the calculation the [computer]
system might crash, be taken down for maintenance, or GAP might run
out of memory and one would like to continue the computation at a
time when the system is less busy. Checkpoints would simply be a
safeguard against the various uncertainties that might occur during a
long calculation. For this purpose it is not necessary to have a
very flexible way of saving the GAP workspace; I don't think that
portability across different computer architectures is really an
issue.

Precaution against uncertainties is the main reason for checkpoints
in commercial database systems. For this to work it is important
that the state is save at some place that is not volatile, e.g.,
on a workspace file.

After repeating all this stuff let me now finally come to my own
comments.

For presentations something like checkpointing this is actually possible.
A presentation (in GAP 3.2, 3.1 doesn't allow you to work with
presentation, only with finitely presented groups) is represented by a
record. If you work with the presentation, e.g., if you replace one
generator by a word in the other generators, you change this record. So
what you can do is the following. Before trying something, you simply
make a copy of the presentation record. If it turns out that what you
did was not a good idea, you simply throw away the presentation record
and continue to work with the copy.

Implementing workspaces is not a trivial task. How difficult it really
is depends on the features it should provide. To find out what exactly
you want, I submit the following questionaire. Please do take the time
to fill it out. For each feature replace the 'O' with 'Y' (yes), 'N'
(no), or 'X' (don't care). Please send you answer as e-mail message
to me. I will summarize the answers in this forum.

O It should be possible to save the current state of GAP to a workspace
file and load it later back into GAP.

O It should be possible to load a workspace file back into a GAP that
was started with different options, e.g., a different amount of
working memory.

O It should be possible to load a workspace file back into a different
version of GAP, e.g., it should be possible to load a 3.1 workspace
back into GAP 3.2.

O It should be possible to move workspace files between different
computers, e.g., it should be possible to save a workspace on a
DECstation and load it back on a Sun.

O It should be possible to create a workspace file not only when you
see the 'gap>' prompt, but also from within functions and from the
break loop (this is probably very difficult).

O  It should provide the following additional features:
   ____________________________________________________

Martin.

--
Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551
Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany