Mythical small kernel images?

Les Tyrrell lestyrrell at spamcop.net
Wed Feb 12 19:44:54 UTC 2003


Sounds like you're doing many of the same things I once did in Oasis...

In Oasis, I created OasisBehavior/Class/Metaclass mainly because I did not
want to damage Behavior/Class/Metaclass as I undid the pervasive use of
directly referencing "Smalltalk" everywhere.  The classes created in an
OasisModule ( or environment ) were instances of the Oasis behaviors.
OasisClass was the parent of all of those classes.  This meant that those
classes, living inside some module, were instances of OasisBehavior classes,
living outside that module ( actually within the original Smalltalk
environment ).  At some point, the OasisBehavior classes would have replaced
the original Behaviors, and a Smalltalk module would replace the original
SystemDictionary Smalltalk.  I never did this, but chances are good that they
were functionally able to do it for a long time.

The OasisModule was a refactoring of the things commonly done by the
SystemDictionary Smalltalk.  It was not a dictionary, because environments are
not just dictionaries.  Development tools ( including the Refactoring tools )
were refactored to remove all of the explicit references to Smalltalk, and
instead were changed to plug into a given module/environment.  Once upon a
time I had a web page showing 6 different Smalltalk implementations in six
different environments, visible through six different code browsers, but all
within the same image.  At a certain point, once you've found all the places
that had formerly directly referenced Smalltalk, you should be able to do this
as well.

The other thing I did in Oasis that is immensely helpful is to make it far
more tolerant of incomplete code fragments- I didn't want to have to have an
entire 2000-class library in place before being able to browse some code.
It's actually quite simple in many cases to fill in the blanks- don't have a
class for the method you are filing in?  Create one!  Missing a superclass?
Create it!  Do that, and suddenly the order of things in the file-in is not so
important anymore.  There are lots of clues in the code about what you need to
fill in the blanks ( missing instance variables, etc ).

Then you can tackle class initialization, which is the very next thing on the
list of things that have to get done before you can easily use classes inside
one of these environments.  Squeak ( and VisualWorks 3.x ) is probably chock
full of class initialization inter-dependencies.  Either figure out a way to
initialize anyway, or re-write to remove those inter-dependencies.  There is
hope on both paths, but the second alternative is probably the most proper.
FWIW, there are dialects which do not have this problem... PocketSt was one of
them.

At one point I had PocketSmalltalk loaded and operational inside one of these
modules.  I had done it by remapping the primitive numbers to those in
VisualWorks.  However, the Squeak version of the PocketSmalltalk development
IDE used an approach where the original PocketSmalltalk source code was left
alone, but the compiler was modified/replaced? to do the mapping
transparently.  This is a pretty good approach, so one of the things I had
thought about doing was to create dialect-specific environments/domains that
provided proper compilation/infrastructure support for whichever dialect you
wanted to load.  It should be feasible ( ignoring past difficulties in
achieving "feasible" ) to do such things as provide Squeak version XX-specific
& PocketSmalltalk-specific environments that would allow one to run Squeak or
PocketSmalltalk applications "without modification" in VisualWorks ( or in
Squeak, once you get there ).

good luck-

- les


----- Original Message -----
From: "Tim Rowledge" <tim at sumeru.stanford.edu>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Tuesday, February 11, 2003 7:16 PM
Subject: Re: Mythical small kernel images?


> "Alejandro F. Reimondo" <aleReimondo at smalltalking.net> appears to have
written:
>
> > I have an Image model and it can fileIn code...
> >
> > Simple steps:
> [snip]
> Hmm, interesting. I've been able to build an Environment and persuaded
> ClassBuilder to create classes 'within' it.
> > [*] Note that in a child image the ProtoObject class inherits from
> >  a normal class in Squeak (e.g. Object);
> Using an environment we can actually make subclasses of nil quite easily
> and having aanother class 'Object' is wierd seeming but feasible. Aside
> from getting sidtracked by the compiler bug stopping me installing a top
> environment (I'll be able to spell that without having to stop and think
> by the end of this thread!) I was getting a bit puzzled by the prospect
> of making the metaclasses be correct; I think I'm right in thinking that
> the metaclasses created for my new classes were actually subclasses of
> the Metaclass in the top environment. Eventually of course we would want
> to make our own class 'Metaclass' within our environment and then
> recompile all previous classes to correct the problem. Somewhere in
> there is a recursion that hurts my brain. Maybe your approach of having
> some special bootstrap code is better!
>
> I really want to see your code!
>
> tim
>
> --
> +================================================================+
> |Though a nation watched her falling, yet a world could only cry |
> |As they passed from us to Glory , riding fire in the sky.       |
> |(Jordin Kare, Fire In The Sky)                                  |
> |Farewell Columbia.                                              |
> +================================================================+
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
>
>
>



More information about the Squeak-dev mailing list