Hi all,
I had got as far as building new classes within a sub-environment but the tools were starting to get in the way. Lots of Browser and compiler related code explicitly works with 'Smalltalk' rather than 'self class environment' or whatever. In fact the compiler bug I reported a week or so ago arose when I tried to work around a few of those problems by using the SmalltalkEnvironment>reorganiseSystem code. What did you do ?
I have an Image model and it can fileIn code...
Simple steps: 1[creation].- anImage is created (with #new) 2[bigBang].- main root classes are created 2.1.- ProtoObject[*], Object, UndefinedObject and nil are created using special messages (ClassBuilder refuse to build classes like them :-( ) 2.2.- a class hierarchy is built for minimum classes the SqueakVM requires. Only classes are created (no methods) mantaining original shape. 3[growing].- a FileIn of remaining classes and methods is performed (here you can alter hierarchy and exchange frameworks completelly, e.g. double-dispatching for numbers, ... also you can reshape basic classes and change implementation)
[*] Note that in a child image the ProtoObject class inherits from a normal class in Squeak (e.g. Object); then you can send it messages during image trace. The tracer must be configured to dump "nil" instead of the superclass of ProtoObject and and mutate all Squeak objects encountered during tracing to embedded classes (liek Array, CompiledMethod,String, Symbol...).
My hope was to (ab)use the Environment work to build a sub-environment into which I could write the class tree I really wanted and then (as you did) Trace it out.
Exactly, I am doing that. Also we can test the image, browse and rebuild it with changes...
regards, Ale.
----- Original Message ----- From: "Tim Rowledge" tim@sumeru.stanford.edu To: squeak-dev@lists.squeakfoundation.org Sent: Monday, February 10, 2003 9:38 PM Subject: Re: Mythical small kernel images?
"Alejandro F. Reimondo" aleReimondo@smalltalking.net appears to have
written:
Can you describe how you built them?
I have built them creating a child environment inside a running Squeak (compiling in an internal environment) and placing only the methods requiered to run. Then a tracer, like SystemTracer has been used to write a minimal image (only with methods required to run).
Well dang - that's exactly what I've been trying to do in between all the other stuff. I guess I'm pleased to hear it actually works! Congratulations.
I had got as far as building new classes within a sub-environment but the tools were starting to get in the way. Lots of Browser and compiler related code explicitly works with 'Smalltalk' rather than 'self class environment' or whatever. In fact the compiler bug I reported a week or so ago arose when I tried to work around a few of those problems by using the SmalltalkEnvironment>reorganiseSystem code. What did you do ?
My hope was to (ab)use the Environment work to build a sub-environment into which I could write the class tree I really wanted and then (as you did) Trace it out. I wasn't worried about the SystemTracer work since I've probably commited more EvilHacks(tm) with the tracer than most people could ever have nightmares about. If everything can work in a subenvironment and be created using the normal tools then the remaining hard work is simply a matter of designing the class hierarchy :-)
An initial paper can be reached at http://www.smalltalking.net/Papers/stGen/stGen.htm ( sorry but it is written in spanish... you can translate it using translation facilities of google [search for "engendrando un smalltalk" ] )
Sadly it makes for very wierd reading - and it stopped translating less than halfway through the paper as well. Maybe this is deliberate to get one to pay for a full translation.
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@sumeru.stanford.edu, http://sumeru.stanford.edu/tim