----- Original Message ----- 
From: "Les Tyrrell" <tyrrell at iserve11.lis.uiuc.edu>
To: <squeak-dev at lists.squeakfoundation.org>; "Dan Ingalls" <Dan at SqueakLand.org>
Cc: <modsqueak at bluefish.se>
Sent: Sunday, August 19, 2001 5:07 PM
Subject: Re: [modules] What should be the first step?


> > I have a message pending (I just need to type it) on why ChangeSets may not
> > be the answer.
> 
> It's sort of how I started out with Oasis... I just wanted a place to dump code where I could look at it
> without it causing trouble for my image.  Later on I made that into a place where I could compile the code,
> instantiate objects, and interact with them, without clobbering my image.  Which sounds very straightforward-
> but nothing that I did in Oasis was easy to accomplish.
> 
> What I found as I built Oasis was that there were very deep-seated non-modularities permeating everything.
> It's not just the tools, or even the code, but perhaps even more significantly, the attitude.  Everything
> *knows* that there is only one namespace.  That was true, of course, an entirely reasonable assumption at the
> time.  But that means that there are much bigger mountains to move ( forget about getting to do something as
> easy as climbing them ) than you may be thinking.  To give an example- In Oasis, I can load the entire class
> library for VisualWorks into a single module.  There you have all the code in one module, just like it wanted
> to be.  But... you can't use it, because you can't initialize this class library- over 200 classes need to be
> initialized, but the code to do it trips over itself... if I remember correctly, it went something like this:
> can't initialize Object, because Collections are initialized... can't do Collections, because something else
> isn't ready... Symbol and String are cyclicly dependent on each other, neither can proceed...  The issues go
> deeper than just having some mechanisms like namespaces.  "Just add namespaces" will not solve these problems.
> 
> As a counter-example, I *can* load a modified version of PocketSmalltalk's class library into a module, and I
> *can* instantiate and interact with objects defined by PocketST's classes.  The reason is simple- I *can*
> initialize PocketSt's class library, because it was designed to be brought up from scratch.  So, this is the
> route I would pursue, given that I already have Oasis- construct a class library similar to PocketSt's, but
> using Squeak's code ( I'd just use PocketSt's, but I don't believe it is open-source, though I could easily be
> wrong about that ).

All the PocketSt work is under an open-source license similar to the Apache license.

>                               The benefit of such an approach is that I have a very clear picture of just what I have
> in the module, and whether it works.  The hurdles I would have to overcome are that I would have to be able to
> generate Squeak's bytecodes, ( meaning that I might have to either port Squeak's parser and compiler to
> VisualWorks, since that is where Oasis lives these days, or run them on top of PocketSt inside Oasis, which
> I've explored a bit in the past ), and I would have to know how to generate a new Squeak image from scratch.
> Both of these things are justifiable extensions to the existing Oasis capabilities, as far as I'm concerned,
> so I'd be willing to give it a try if someone will tell me what I need to know about the image formats, and
> what the VM expects.
> 
> - les
> 
> 
>