"Stephen Pair" <spair at acm.org>  wrote...

>AFAICT, there are two primary reasons for keeping source code outside of
>the image:
>
>1.  To keep the image size smaller
>2.  To allow recovery of source code after an image crash
>
>It would be nice to have an option to keep all source code inside the
>image. 

I have good news for you, Stephen.  I did this 6 years ago (although it looks like Scott worked on the method back then as well).  There is no need for new compiled methods.  Check out

	SystemDictionary>>internalizeSources

You'll need to define ReadWriteStream>>isReadOnly to return false (a minor case of bit rot), and then you can execute the above method.  Presto!  You're browsing and the disk is asleep.

A few things to note: 

1.  You'll need a lot less space to do this if you first condenseSources (internalizeSources is not smart)

2.  The code for saveAs needs to be made aware of internal sources.  It SHOULD just copy the image, but right now it re-externalizes the changes.  While you're at it, it would be cool if condenseChanges and condenseSources were also internal-aware.  That would take care of (1) above, since you could just condense after internalization.

3.  I put some thought last year into how to compress the sources while still being able to read and write them (this was looking forward to module files with inboard compact and browsable sources).  You can get nearly a factor of four in space with reasonable browsing speed by making up a file of 16k or 32k gzipped segments, with an index at the front.  Call for details.

4.  I think your idea of maintaining a short-lived external changes is a good compromise, since the crash-recover value of a changes file is so great.  This would be handled pretty simply by using internal sources and external changes, and making condenseSources internal-aware.

Enjoy
	- Dan

>As for reason #1, if you need to reduce the image size for deployment,
>you could easily jettison all the sources.  It should also be easy to
>switch between having sources inside the image and having them stored in
>external sources and changes files.  And, if the sources are stored in
>some compressed form, we could save a lot of the space that source code
>uses (compressing SqueakV3.sources with WinZip shrinks the file from
>14,202KB to 3,395KB).
>
>To address reason #2, we could still write changes to a changes file,
>however, after a successful image save, the changes file could be
>cleared (thus, the changes file would only ever contain changes since
>the last image save).  There could be setting that controlled how long
>old versions of class defs and methods are retained, etc. 
>
>Just a thought.  With today's large memory machines, it seems like we
>should at least have the option of keeping sources in the image.
>
>(also, I suppose we'd need the new compiled method format before this
>could be done)
>
>- Stephen