Hi Eliot,

On Fri, Nov 25, 2022 at 11:28:58AM -0800, Eliot Miranda wrote:
> Hi David,
> 
>    this seems backwards to me.  It seems to me that one would want to cache
> the sources but keep the changes gfile for crash recovery.

You can already do that, see the "Cache sources file" preference.

>  Sicne the
> changes file should mbe empty at the start of a release this would mean
> that all sources were cached.  What am I getting wrong?  And how does your
> scheme do crash recovery, if at all?
>

There is no crash recovery.

Some earlier discussion (well I suppose it was more of a monologue) is at
http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-October/222570.html.

The original 1996 implementation is referenced here
http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-March/007670.html

As Dan said at that time: "It has one wonderful property - you can run for
long periods without spinning up the disk of a portable computer.  -- and the
analogous awful property -- if anything crashes, there's nothing to replay :-(

Nowadays we are not so worried about wearing out the bearings on our
hard drives, but we do have cases where it is useful to be able to
move an image around without carrying extra disk file references along
with it.

This is definitely /not/ intended for use in distributing Squeak release
images. And putting the changes file back out on your file system is just
a matter of "SourceFileArray internalizeChanges: false" (a preference).

Here are some use cases that are of interest to me:

1) Forking the running VM on Unix with #forkSqueak. The changes file
management in this case works by accident, but it really would be better
if two or more images were not attempting to share the same changes file
on disk.

2) SqueakJS. It would be nice to run an image on SqueakJS without
worrying about keeping the associated files with the image.

3) SnapshotServer resume image on another server, one of my hobby
projects at http://www.squeaksource.com/SnapshotServer

I should note that although the sources file is compressed when the
source file is inboarded ("Cache sources file" preference), so such
optimization is attempted for "Cache changes file". That might be
a topic for some other day.

Dave