On Mon, 10 Feb 2003, Alejandro F. Reimondo wrote:

You can also build images with even smaller footprint using and alternative like the SystemTracer. Here I attach two images in binary format that can work on win* machines (use FFI during runtime) one of 62kb and the other of 120kb They are runtime only, like java programs... Ale.

Can you describe how you built them?

"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

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

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@sumeru.stanford.edu To: squeak-dev@lists.squeakfoundation.org Sent: Tuesday, February 11, 2003 7:16 PM Subject: Re: Mythical small kernel images?

"Alejandro F. Reimondo" aleReimondo@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@sumeru.stanford.edu, http://sumeru.stanford.edu/tim

Hi Ale., I've managed to make an image, though it seems to have a mutual recursion somewhere between print and printf:, but I'll work that out soon.

Do you have any architecture documents I could see? Working through code is good, but some understanding of your _intent_ would be very helpful. For example, I don't really see what you intend with the .bigbang files and all the includes of other bigbang and chachara files.

Oh, and is it ok with you if I mention to Jon Hylands the stuff you've done for remote debugging? It could certainly help him, and would mean I could concentrate on the core parts.

tim

Here is a rough translation of Alejandro's paper "Generating Smalltalk". And I do empasize /rough/. It should be at least marginally better than what the automatic translators will give you, though. Attached is the same document (with the original drawings) as a Word Doc.

Alejandro - Bueno, intente. Pero te digo que me parecio bien raro tu espanol. ;) Talvez fue nada mas que el "voz" que se usa con temas tecnicas. Pero, que quiere decir "se proponen técnicas de armado individual"? Y que es un "condón umbilical"? Ya que hay un cordon umbilical es un poco tarde usar condon, no? ;)

david

----

Generating Smalltalk. Alejandro F. Reimondo

Introduction: The most important aspect of Smalltalk lies in what is an Object Environment (OE). Understanding an Object Environment to be a place where things are found. This permits the study of computation using manipulation techniques; techniques that an individual has used from early on.

The understanding of this difference changes the person that uses Smalltalk and the difficulty that some people experience learning is because, generally, they do not expect so much from the software. Once they understand that Smalltalk is a place, that everything is contained in it and also related making the environment as a whole "stable"; it is easier to also understand that these things evolve in an interactive way attempting a general evolution of the environment. Usually the evolution is a general improvement ... So we have in an Object Environment a jar where we place things and watch how they develop thanks to the interaction between ourselves or themselves. These Object Environments are nourished by the intelligence contributed by human beings, which they utilize and refine. The techniques of reuse and programming permit the aggregation of intelligence in an incremental way to the extent that it is necessary, whether aggregating new concepts and objects or maintaining stability in general. Since present hardware does not permit (in a practical way) an infinite lifespan for a piece of software (at present the base is unstable and increasingly complex) Smalltalk has used for a very long time the concept of a "snapshot" or "image". What it manages to do is "to freeze" the whole environment in the state in which it is found and to keep it in passive storage, to bring it back to life later on. In this document we will use the word "image" to mean the set of objects that makes up a Smalltalk in a specific instant. Inside an image are found a great number of objects, and it is common that these represent various subsystems that coexist within the same world. We define a subsystem (machine or organism) as a set of objects that are related in an independant way; having as its most prominent property the characteristic of existing for an interesting period of time. The subsystem will be able to change in order to subsist. Generally, subsystems are not independent, so changes in one system can cause changes in others. Also it happens that changes in one system affect the environment in which it is found; and changes in the environment affect the systems that form it. This wave of effects tends to diminish in intensity in time in a way proportional to the age/stability of the environment. Cloning The traditional method of working in Smalltalk is to begin to work from an initial image and make it evolve until it reflects the desired environment. Here is where one asks: How is that initial image obtained?

The answer is simple: it is already there, you just have to copy it. Current computing mediums have a notable characteristic, they permit us to duplicate easily, without loss. The inquiring person never stops asking; but ... how was the image that we just copied obtained? And the one before that? How was the first image obtained? The first image was built object by object, they are told. This image had very few objects. Back in the 70's the first Smalltalk image was generated from a small set of objects and then it was made to grow and grow until it became the images that we use nowadays. In current images there are objects that were in those first images; yes, clearly much older and robust! The idea is that since those days we have used copying facilities to obtain clones of that initial image. Each stage of the evolution of Smalltalk passed through a refinement of an initial image, until it arrived at a degree of stability so as to be distributed as new initial image. The beginning generally accepted as the point of departure is cloning. The model of propagation by cloning is a horizontal model; so that has a high index of contagion, but prone to uncontrolled propagation. (Generally horizontal propagation has these characteristics and never arrives at equilibrium, save for external forces that control reproduction) The Network

The network gives us a new medium for information propagation; the network allows us to have a virtually infinite space. If the image represented a World of objects, the network allows us to have a Universe of objects. The technique of cloning was satisfactory for individual work with an environment of objects, although somewhat inadequate for group work. The inconveniences of group work in Smalltalk with various worlds via the technique of "snapshots" are known. Therefore it is common to see that generally techniques are proposed of armed individual and joined of subsystems (through interfaces) or the centralization of services (as in the objects bases case with a centralized server). How to spread Smalltalk?

We try to find a more "natural" form of generating images (worlds of objects). By "more natural" we mean, less idealistic, more dynamic and thus with the possibility of errors and imperfections. We assume that, although the universe of objects is infinite, we will continue working with Smalltalk images, with the condition that these will be able "to reproduce" by vertical propagation (parent-child). The idea is to generate a seed inside a Smalltalk world. This seed [embryo] contains almost nothing, just the possibility to place some object inside it. As soon as we place an object inside the seed this object should try to live inside it. In order to live (to function or whatever you want to call it), the object must know things that are not yet found inside the seed. It must learn things that it doesn't yet know. The seed will be a mini-Smalltalk/mini-World inside the parent. With the difference that it does not have anything and that everything it needs it will obtain by being nourished by the parent. This seed/embryo is a subsystem and to live it is nourished by (and learns from) the parent thanks to the transparent migration of classes (methods, etc.) from the Smalltalk parent. Once we have the objects desired inside the embryo and it has already "learned" all it needs from the parent (and is independant), we can to remove it from the parent! Thus after birth it will be transformed into a Smalltalk with ONLY what it needs to live, but having inherited the genetic traits of the parent. There are several interesting things about this scheme: 1. It will probably generate images much smaller and less risky than those obtained by shrinking (trimming what is not needed). 2. We would have a way of generating Smalltalk by gestation, with inheritance and with the concept of genetic traits inherited from the parent! (this could possibly change our view of software, once again :-) 3. It is a tempting plan for the Internet. Not only would we have mobile and independant images but we would also be able to encapsulate objects in mini images that migrate from machine to machine in order to learn etc. 4. This is just the beginning. Imagine this on web sites with the possibility of easily embedding miniatures in mini images that are alive! A user can interact with them, to embed them in his image or save them to disk for later user. Implementation (Preliminary: WARNING! It is possible that this could change significantly) The parent has the usual composition, with the possibility of generating embryos and umbilical cords so that they can be nourished during their gestation. The parent has a SystemDictionary [Smalltalk] that defines the World (global names).

What do we need to generate a seed/embryo? 1. A SystemDictionary [microSmalltalk] that defines Globality in the embryonic world 2. Base MicroClasses. 3. Which classes constitute the necessary minimum set? 4. Are all the methods of the base classes necessary? [no] 5. Which methods will be necessary? 6. Micro VM kernel 7. Primitives? 8. Which? 9. A proxy mechanism to guarantee transparent feeding of the child.

MicroObject For now (maybe this will change) I call the class Object in the embryo MicroObject. Possible definitions: nil subclass: #microObject ... [Parent] Object subclass: #MicroObject ... (where Object is not in the MicroSystemDictionary!) Thus comes the role of #doesNotUnderstand: it transports methods from the parent using the umbilical cord in a transparent way. Could this be the ONLY necessary connection with the parent? MicroWorld MicroWorld = MicroSmalltalk + MicroVMKernel + MicroBaseClasses MicroSmalltalk isA: MicroSystemDictionary with the globals of the world in gestation. MicroVMKernel = MicroVMConstants Necessary for the operation of the virtual machine (eg. Semaphore, Process, Point, Smalltalk etc). It corresponds to SpecialObjects in the virtual machine. It is constant in the world that is being executed. MicroBaseClasses = The set of classes necessary for the operation of the world (eg. Class, CompiledMethod, Symbol, Process, Context, SystemDictionary, etc) Creation A MicroWorld is born in the context of a world (image) parent. It is connected the parent through a feeding mechanism in the presence of ignorance (for example the mechanism of #doesNotUnderstand: decouples the lookup logic in the parent through a communications channel). As soon as it is stable and knows how "to live alone" it can be disconnected from the parent, born by being cloned (via SystemTracer) into another medium or into one created for it. Feeding Feeding occurs in the face of a lack of knowledge (via #doesNotUnderstand:). In the face of a lack of knowledge it makes a connection with the parent (via the umbilical cord, to feed itself new methods taken from the parent). The migration of methods from the parent generates new objects and classes (from method literals); which lets the child accumulate only what is necessary. The transfer of classes to the child is done through the creation of a class in the child. The class should be created with all the methods it has so that they can migrate in case they are needed (this is important because the mechanism of #doesNotUnderstand: does not suffice; polymorphism in classes of the same level). Birth vs. Cloning At the moment of the birth it is possible to eliminate the methods imported but not used by the child. Then the child can be detached from the parent. Proposed steps: 1. The child is traversed eliminating ties with the parent (should unused methods be deleted or should it just be disconnected from the parent?) 2. A new symbol table is constructed for the child. 3. An image is constructed by traversing the child (SystemTracer). 4. The sources are compacted. Tools to work on the child · Browsing the child

Should it be possible to create/modify methods in the child during gestation? Or only in the parent. If only in the parent should the infection of the child be immediate, defered or not done at all? · Inspectors on the child

Should it be possible to change objects in the child via inspection? If so; perhaps it should be compiled in the parent, migrate the method to the child and evaluate it there. It is not sufficient with infecting the child... Is it vile to kill the stupid child and to create a new one? Is infection sufficient? Isn't it problematic? It isn't [Isn't it] necessary to have a map of transformations between the parent and child. The transfer of objects only occurs from parent to child. No? · To run/To simulate/To debug

It is fundamental to be able to debug the child while it is being gestated. Possibly the simulator of the parent VM can be used for the child. Logging in the umbilical cord would be very useful at the beginning. Genetic propagation of traits Asexual creation 1. A parent is a traditional Smalltalk with the classes that know to generate a seed, build the feeding mechanism and are sufficient to create a complete child. The parent will contain a SystemDictionary (Smalltalk) that defines globals, the set of classes and objects that guarantee its stability.

2. It generates the seed, with a SystemDictionary for this and at least one object that will be the life motive of the child environment. This prepares the generation of classes in the child during gestation.

3. The child is born as an independant image but it can still have an (occasional) link to the parent.

Sexual creation 1. The father contains one (or more) object(s) that will serve as a point of departure for the gestation of the seed. The mother has the backup for seed generation and the basics for gestation.

2. The seed is created in the mother with objects contributed by the father.

3. The child will contain parts from the father and the mother. It might happen that the mother does not have all the nutrients necessary during the gestation, and she [or the child?] can communicate with the father to obtain them.

4. If the child contains a link to the father it will be able to be nourished directly without using the mother.

5. If the child has various feeding links, it can decide which to use; try in various parents or even to decide which information to feed itself (given the several alternatives offered by the parents).

Observe that in this case the father does not need support to generate children! Could it be a virgin Smalltalk?

-- David Farber dfarber@numenor.com

"Alejandro F. Reimondo" aleReimondo@smalltalking.net wrote:

You can also build images with even smaller footprint using and alternative like the SystemTracer. Here I attach two images in binary format that can work on win* machines (use FFI during runtime) one of 62kb and the other of 120kb They are runtime only, like java programs... Ale.

Wow! I have never seen anything like this in Squeak before. Very impressive!

A humble little question: Is there any chance your work would result in some little tool for creating such small images? Under Squeak-L?

Hehe. Now if we could get a nice binding with a good crossplatform UI toolkit (Gtk or wxWindows etc) and a superfast Jitter from Ian and/or Marcus then Squeak would become REALLY attractive to a lot of developers. ;-)

regards, Göran

PS. Marcus - how is it going with your project? Just curious. :-)

Alejandro, this is very interesting.

I remember you told me about this long time ago, and I still have the same doubts: How stable are the images produced with this process? The final image includes only methods that have been activated in the nurturing process, right? What about the methods that have not been activated, but that are needed later? How long do you have to nurture an image before it stabilizes? Does it stabilize at all?

I guess at some point you would be able to generate a new image for the child, start a new vm and continue the nurturing process through the network. Are you doing that?

Please try to realise this project under the Squeak-L. A lot of us are eager to play with it. Luciano.-

--- "Alejandro F. Reimondo" aleReimondo@smalltalking.net wrote:

Hi G�ran,

...

Wow! I have never seen anything like this in

Squeak before. Very

...

impressive!

Yes, it is impressive also for us :-) The FractalPlants image (124k) is the bigger image we have created. Images normally takes 64-100kb but do very little things...

...

A humble little question: Is there any chance your

work would result in

...

some little tool for creating such small images?

Under Squeak-L?

If it is really needed we can ask for a permition to made it under Squeak-L.

...

Hehe. Now if we could get a nice binding with a

good crossplatform UI

...

toolkit (Gtk or wxWindows etc) and a superfast

Jitter from Ian and/or

...

Marcus then Squeak would become REALLY attractive

to a lot of

...

developers. ;-)

Out images can determine the minimum requirements for the VM... They can also be used to build the minimum VM that can run them.

regards, Ale.

----- Original Message ----- From: goran.hultgren@bluefish.se To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Tuesday, February 11, 2003 5:43 AM Subject: Re: Mythical small kernel images?

...

"Alejandro F. Reimondo"

aleReimondo@smalltalking.net wrote:

...

...

You can also build images with even smaller

footprint

...

...

using and alternative like the SystemTracer. Here I attach two images in binary format that can work on win* machines (use FFI during

runtime)

...

...

one of 62kb and the other of 120kb They are runtime only, like java programs... Ale.

Wow! I have never seen anything like this in

Squeak before. Very

...

impressive!

A humble little question: Is there any chance your

work would result in

...

some little tool for creating such small images?

Under Squeak-L?

...

Hehe. Now if we could get a nice binding with a

good crossplatform UI

...

toolkit (Gtk or wxWindows etc) and a superfast

Jitter from Ian and/or

...

Marcus then Squeak would become REALLY attractive

to a lot of

...

developers. ;-)

regards, G�ran

PS. Marcus - how is it going with your project?

Just curious. :-)

...

__________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com

Diego

I did not see this mini image where can I find it?

Stef

On Tuesday, February 11, 2003, at 09:45 PM, diegogomezdeck@consultar.com wrote:

Hi Luciano,

You get confused by the paper "engendrando un smalltalk" (generating a smalltalk) and the jod done to create a minimal image.

The images that Alejandro has sent to this list are images created BEFORE the process of growing them using the parent-child process. This process allows you to create the image you want, with or without the mechanism described in the paper.

Cheers,

Diego Gomez Deck

...

Alejandro, this is very interesting.

I remember you told me about this long time ago, and I still have the same doubts: How stable are the images produced with this process? The final image includes only methods that have been activated in the nurturing process, right? What about the methods that have not been activated, but that are needed later? How long do you have to nurture an image before it stabilizes? Does it stabilize at all?

I guess at some point you would be able to generate a new image for the child, start a new vm and continue the nurturing process through the network. Are you doing that?

Please try to realise this project under the Squeak-L. A lot of us are eager to play with it. Luciano.-

Prof. Dr. Stéphane DUCASSE (ducasse@iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes

Thanks this was so small that I missed them. Now I get them. My next question is what can I do with them, how do I interact with them, I drop them on a Squeak VM it works but then do we have to specify parameter and get value....

Ale this is ***really*** exciting. Impressive. If we could rebuild Squeak on top of such a mini image this would be ****really**** good. Or a kind of dream :).

Diego what was the paper you talked about?

Stef

On Tuesday, February 11, 2003, at 10:14 PM, diegogomezdeck@consultar.com wrote:

Hi,

Alejandro Reimondo has atached them in an email. You can find them at http://groups.yahoo.com/group/squeak/message/55613

Diego

...

Diego

I did not see this mini image where can I find it?

Stef

On Tuesday, February 11, 2003, at 09:45 PM, diegogomezdeck@consultar.com wrote:

...

Hi Luciano,

You get confused by the paper "engendrando un smalltalk" (generating a smalltalk) and the jod done to create a minimal image.

The images that Alejandro has sent to this list are images created BEFORE the process of growing them using the parent-child process. This process allows you to create the image you want, with or without the mechanism described in the paper.

Cheers,

Diego Gomez Deck

...

Alejandro, this is very interesting.

I remember you told me about this long time ago, and I still have the same doubts: How stable are the images produced with this process? The final image includes only methods that have been activated in the nurturing process, right? What about the methods that have not been activated, but that are needed later? How long do you have to nurture an image before it stabilizes? Does it stabilize at all?

I guess at some point you would be able to generate a new image for the child, start a new vm and continue the nurturing process through the network. Are you doing that?

Please try to realise this project under the Squeak-L. A lot of us are eager to play with it. Luciano.-

Prof. Dr. Stéphane DUCASSE (ducasse@iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes

Prof. Dr. Stéphane DUCASSE (ducasse@iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes

Hi all,

My next question is what can I do with them, how

Well, you can play a tango... (win* and FFI requiered)

Ale.

----- Original Message ----- From: "Alejandro F. Reimondo" aleReimondo@smalltalking.net To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Tuesday, February 11, 2003 10:31 PM Subject: Re: Mythical small kernel images?

Hi all,

...

My next question is what can I do with them, how do I interact with them, I drop them on a Squeak VM it works but then do we have to specify parameter and get value....

We have implemented consode I/O... We also has implemented an image (aprox 40kb) that get a web page given an URL (using WinInet because Squeak sockets implementation is very complex). They ONLY do simple things but we plan to expand the framework to support dynamic exchange with parents (nutrition from parents) when needed. It is a work in progress that we have from a long time in Smalltalking (we also advocates to do a social activities for the community, here in Argentina).

...

Ale this is ***really*** exciting. Impressive. If we could rebuild Squeak on top of such a mini image this would be ****really**** good. Or a kind of dream :).

Diego what was the paper you talked about?

I think that it can't be very difficult to build a mechanism to support dynamic embedding of mini-images, but provably it must be supported by primitives (this will require VM changes :-( ).

cheers, Ale.

----- Original Message ----- From: "Stephane Ducasse" ducasse@iam.unibe.ch To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Tuesday, February 11, 2003 5:51 PM Subject: Re: Mythical small kernel images?

...

Thanks this was so small that I missed them. Now I get them. My next question is what can I do with them, how do I interact with them, I drop them on a Squeak VM it works but then do we have to specify parameter and get value....

Ale this is ***really*** exciting. Impressive. If we could rebuild Squeak on top of such a mini image this would be ****really**** good. Or a kind of dream :).

Diego what was the paper you talked about?

Stef

On Tuesday, February 11, 2003, at 10:14 PM, diegogomezdeck@consultar.com wrote:

...

Hi,

Alejandro Reimondo has atached them in an email. You can find them at http://groups.yahoo.com/group/squeak/message/55613

Diego

...

Diego

I did not see this mini image where can I find it?

Stef

On Tuesday, February 11, 2003, at 09:45 PM, diegogomezdeck@consultar.com wrote:

...

Hi Luciano,

You get confused by the paper "engendrando un smalltalk" (generating a smalltalk) and the jod done to create a minimal image.

The images that Alejandro has sent to this list are images created BEFORE the process of growing them using the parent-child process. This process allows you to create the image you want, with or without the mechanism described in the paper.

Cheers,

Diego Gomez Deck

...

Alejandro, this is very interesting.

I remember you told me about this long time ago, and I still have the same doubts: How stable are the images produced with this process? The final image includes only methods that have been activated in the nurturing process, right? What about the methods that have not been activated, but that are needed later? How long do you have to nurture an image before it stabilizes? Does it stabilize at all?

I guess at some point you would be able to generate a new image for the child, start a new vm and continue the nurturing process through the network. Are you doing that?

Please try to realise this project under the Squeak-L. A lot of us are eager to play with it. Luciano.-

Prof. Dr. Stéphane DUCASSE (ducasse@iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes

Prof. Dr. Stéphane DUCASSE (ducasse@iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes

Hi Alejandro,

You are my hero ;-)

If it is really needed we can ask for a permition to made it under Squeak-L.

Please do so. I am looking forward for your package in SqueakMap.

Out images can determine the minimum requirements for the VM... They can also be used to build the minimum VM that can run them.

Would you please elaborate on this.

BTW, I put your 'sample2.image' thru the analyzer :

1/- There are 124 classes in the image.

1/- 34 classes with 0 instances (so shouldn't be in the image): - ProtoObject Class -ArrayedCollection -Behavior -Bitmap -Boolean -ByteArray -Class -ClassDescription -ClassOrganizer -Collection -ContextPart -Environment -ExternalFunction -ExternalLibrary -ExternalObject -ExternalStructure -IdentityDictionary -InstructionStream -Integer -Link -LookupKey -Magnitude -Message -Number -Object -ReadOnlyVariableBinding -Rectangle -SequenceableCollection -Set -SmallInteger -SystemDictionary -TranslatedMethod -Win32Console -Win32Handle

2/- Consequently : - 33 classes of above classes respectively are not needed in the image.

- The following 8 classes can be removed from the specialObjects: * ExternalLibrary * ExternalFunction * ExternalStructure * TranslatedMethod * ByteArray * Message * SmallInteger * Bitmap 3/- The rest of the classes (57) and number of instances are: (What is that sole instance of Float, Point is doing in this sample2.image ?

For that matter, would you please verify that these 57 classes are really needed ? and what does Fenix mean ?)

1 BlockContext 1 FenixEnvironment 1 Float 1 LargePositiveInteger 1 Point 1 Process 1 ProcessorScheduler 1 Semaphore 1 UndefinedObject 2 False 2 MethodContext 2 True 3 OrderedCollection 7 ExternalAddress 7 ExternalLibraryFunction 10 WordArray 10 ExternalType 17 Dictionary 62 Metaclass 80 LinkedList 96 String 117 CompiledMethod 124 MethodDictionary 181 Association 227 Array 256 Character 320 Symbol

If you can spare sometime, would you please confirm or deny the validity of this analysis. It would be very helpful for me to fine tune the analyzer.

Also, if the analysis is correct, can your technology create an image without 'cruft' and micro-kitchen-sink ;-)

I heard a lot about the '3 + 4' image but never saw one.

Thanks a lot for your time and effort, my dream of an ImageBuilder is now coming true.

Cheers,

PhiHo.

Tim Rowledge certainly wrote :

...

    1/-  34 classes with 0 instances  (so shouldn't be in the

image):

completely wrong. Just for one example, if you want to have integers you

Now I realise that the superclass chain analysis is completely broken. So those classes with 0 instances may still be needed. This must be fixed.

But, there may still be un-needed stuff in there ?

Cheers,

PhiHo.

----- Original Message ----- From: "Tim Rowledge" tim@sumeru.stanford.edu To: squeak-dev@lists.squeakfoundation.org Sent: Tuesday, February 11, 2003 3:58 PM Subject: Re: Image Builder (Re: Mythical small kernel images?)

"PhiHo Hoang" phiho.hoang@rogers.com appears to have written:

...

    1/-  34 classes with 0 instances  (so shouldn't be in the

image):

completely wrong. Just for one example, if you want to have integers you need the integer branch of the hierarchy available SmallInteger (probably Large*Integer as well), Number, Magnitude, Object. Oh and you need Class and thus Metaclass, ClassDescription, Behavior etc. in order to have methods to run (so you need CompiledMethod, MethodDictionary - and Dictionary, Set, Collection). Then again if you want to have almost any control structure avaialble you need True and False and thus Boolean. MethodContexts and BlockContexts are rather useful in actually running code, so ContextPart has to come along. Unless one proposes a single threaded system you might like Process (and thus Link and ProcessorScheduler and Semaphore - bringing in LinkedList and SequencableCollection)

It takes a village, of sorts, to make a child image.

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

Alejandro,

You can know the primitives that the image use and build the VM contaning only this primitives.

Yes, now I get it. I also thought of Interpreter/InterpreterEx and Primitives/PrimitivesEx plugins ;-)

Here I attach our very first running image (15kb). It only has the quitPrimitive method and do 3+4. We use this image to test the proper initialization of running process and context; and it run during the second try! It was VERY exiting. Debuggin the VM and seen de bytecodes for 3+4 was lived as an unique event!

Thanks a lot. I can't wait to play with your tools.

Cheers,

PhiHo.

----- Original Message ----- From: "Alejandro F. Reimondo" aleReimondo@smalltalking.net To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Tuesday, February 11, 2003 8:16 PM Subject: Re: Image Builder (Re: Mythical small kernel images?)

Hi,

...

...

Out images can determine the minimum requirements for the VM... They can also be used to build the minimum VM that can run them.

Would you please elaborate on this.

You can know the primitives that the image use and build the VM contaning only this primitives.

...

BTW, I put your 'sample2.image' thru the analyzer :
    1/- There are 124 classes in the image.

They are not the minimal set of classes... An image with minimal classes are aprox 15kb. Here I attach an image that do a garbageCollect and exit and a "3+4" image (only do 3+4 and exit)

...

    1/-  34 classes with 0 instances  (so shouldn't be in the

image):

...

            - ProtoObject Class
            -ArrayedCollection

.....

...

            -Win32Console
            -Win32Handle

Most classes are mantained to preserve Squeak hierarchy. The only thing you must preserve is the critic classes shape for the VM to work as usual.

...

    2/- Consequently :
            - 33 classes of above classes respectively
                are not needed in the image.

........

...

    3/- The rest of the classes (57) and number of instances are:
            (What is that sole instance of Float, Point is doing
              in this sample2.image ?

They are prototipycal instances required by the VM; but they can be

replaced

by nil in this images because we do not instantiate the classes during runtime...

...

              For that matter, would you please verify that these 57
              classes are really needed ?

There are classes that can be removed, but other are really needed to

build

the image (e.g. MethodDictionary, Array, Symbol)

...

and what does Fenix mean ?)

It is our extension to environments (simple changes to work as we want). (Smalltalk is a FenixEnvironment in our image)

...

If you can spare sometime, would you please confirm or deny
the validity of this analysis. It would be very helpful for me
to fine tune the analyzer.

The contents are provably fine, but some classes can´t be removed without breaking the image.

...

Also, if the analysis is correct, can your technology create an
image without 'cruft' and micro-kitchen-sink ;-)

I heard a lot about the '3 + 4' image but never saw one.

Here I attach our very first running image (15kb). It only has the quitPrimitive method and do 3+4. We use this image to test the proper initialization of running process and context; and it run during the second try! It was VERY exiting. Debuggin the VM and seen de bytecodes for 3+4 was lived as an unique event!

...

Thanks a lot for your time and effort, my dream
of an ImageBuilder is now coming true.

cheers, Ale.

---------------------------------------------------------------------------- ----

Hi!

Aaron J Reichow reic0024@d.umn.edu wrote:

While it may not be as nice as ~250k, one can make a pretty small image using majorShrink and a little category deletion. I'd say an MVC image with networking could be attainable by most general Squeak programmers that is 500k-1MB in size. Still a lot smaller than that 9 MB JRE! :)

Ah, sounds nice. Last time I played with the shrinking stuff I got it down to about 5Mb but that still included Morphic and the complete toolset (but no games etc).

Perhaps I should give it a go myself.

regards, Göran

Hello Goran:

I need to make some tests with a small image, including Morphic, but I'm inexperienced yet to play myself with majorShrink and similar stuff.

Your 5MB image is available in some place to download?

Thanks and Best Regards.

--- Germán S. Arduino. http://gsa.swiki.net

--- goran.hultgren@bluefish.se escribió: > Hi!

Aaron J Reichow reic0024@d.umn.edu wrote:

...

While it may not be as nice as ~250k, one can make

a pretty small image

...

using majorShrink and a little category deletion.

I'd say an MVC image

...

with networking could be attainable by most

general Squeak programmers

...

that is 500k-1MB in size. Still a lot smaller

than that 9 MB JRE! :)

Ah, sounds nice. Last time I played with the shrinking stuff I got it down to about 5Mb but that still included Morphic and the complete toolset (but no games etc).

Perhaps I should give it a go myself.

regards, Göran

Ahora podés usar Yahoo! Messenger desde tu celular. Aprendé cómo hacerlo en Yahoo! Móvil: http://ar.mobile.yahoo.com/sms.html

Hi!

I got a little confused by your "Hello Goran:" so I responded a bit silly to the list. Anyway, after searching my Celeste folder with good stuff from the mailinglist I came up with my answer to Russel Allen on the subject, repeated below.

The VirtualHome project is very much sleeping/dead now btw. ;-)

regards, Göran ----------------- Hi!

Ok, here we go. First you go to:

http://anakin.bluefish.se:8000/vh/12

...and download the source package. When we deploy "VH" we essentially do this:

1. Read and follow comment of VHUtilities>>stripAndSave 2. Run stripAndSave. The strip method is something I gobbled together from Swiki etc. Don't ask me for details... :-) 3. Run the "deploy script" which is just a simple bash script. Nothing complicated.

I use this on a Debian box for packaging zips for both Linux and Win32. You can also see the .bat files etc for starting up "different apps" using the same image.

Mail me if you have questions.

regards, Göran

Russell Allen russell.allen@firebirdmedia.com wrote:

goran.hultgren@bluefish.se wrote:

...

Well, we have some deployment scripts working with 3.2 for both Windows and Linux. We keep all tools, morphic and networking in the image.

It will land you around 5-6 for the image and as a total "installer" at 3-3.5 Mb zip.

Perhaps you could tweak it further. Just say "Hit me" and I can post a .cs with the relevant methods and some other files showing how we do it.

Hi Goran,

I'd love to be able to get a copy of those scripts...

Russell

German S. Arduino wrote:

Thanks You Goran by the data.

I will see and try.

Also, sorry if my "Hello" sound confusing, but *all* my English may sound counfusing sometimes :-(

Thanks Again and Regards.

Hello German,

Don't worry about your English. It's not Göran's native language either. This list is very blessed to be multi-national and multi-lingual. Unfortunately most Americans do not write English as well as most of the non-native people on this list. (Isn't that right Tim.) :)

So don't sweat the small stuff. The Squeak list is full of friendly people. (But we all can have our grumpy moments.) :)

Jimmie Houchin

...

So don't sweat the small stuff. The Squeak list is

full of friendly

...

people. (But we all can have our grumpy moments.)

:)

Yes, and just so that noone misunderstood me (I mailed German privately), I just mistook the personal greeting to mean that it was a personal email.

...

Jimmie Houchin

regards, Göran

Thanks People!

(But have caution with my English :-)

Ahora podés usar Yahoo! Messenger desde tu celular. Aprendé cómo hacerlo en Yahoo! Móvil: http://ar.mobile.yahoo.com/sms.html