1) I would never give up the security of the change log.  I want the sources
   internally in addition.  (You people saving hard-disk power can disable
   if you want...)
   
2) Having to distribute a new changes file with each new revision kind of
   defeats the purpose of having an unchanging sources file.  Besides,
   The changes file is almost twice the size of the sources.  Does the
   changes file contain the source of every released method (including
   past released versions)?
   
3) I know that it's easy to change.  But if I do it in my own little world,
   all of those people who are getting their first take on Smalltalk from
   Squeak do not benefit.  (I am an experienced Smalltalker, and my first
   take on Squeak was: "Sheesh... I can't seem to get the line end convention
   to show all of the methods properly.... what a hassle").
   
4) Having things internal has the nice feature of not needing weirdo platform-
   specific configuration.  If the windows come up, "everything" works.
   
5) A quick dig around in Squeak  (especially internalizeSources, etc.)
   reveals a rather annoying problem:  CompiledMethod is a byte-type object,
   and therefore cannot store a pointer to a source object.  It can only store
   some number that the source code system must then translate to the source.
   So much for non-string based source code...
   
   -- Mike Klein

> Folks -
> 
> It's not hard to bring the Squeak source code inboard -- it actually all
> worked once.  Look at the methods like SystemDictionary makeSourceInternal
> (or the like -- I'm away from my machine right now).
> 
> 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 :-(
> 
> 	- Dan
>