On a more...(Inboard Squeak sources)
mike at twinsun.com
Tue Mar 3 04:40:44 UTC 1998
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
More information about the Squeak-dev