Hi Gabriel,
On Tue, Nov 2, 2010 at 3:50 AM, Gabriel Hernán Barbuto
<[hidden email]> wrote:
Hi
I am looking at MicroSqueak and trying to make it work in a new image.
I run MicroSqueak in a new VM and it works. What is a bit odd is that
MicroSqueak has a different class hierarchy for String. It doesn't
know about ByteString nor WideString and the String class in
MicroSqueak has a different format than the one in recent images.
How is it possible that a MicroSqueak generated image runs on the
recent VMs? The special objects array that MicroSqueak creates is
different. For example, at index 7 MicroSqueak put its own version of
String instead of ByteString. I have tried it on Mac OS X on the
Squeak 4.2.5b1 VM and on Windows on the 4.0.2 VM.
My guess is that it works because MicroSqueak String has the same
structure as ByteString in current images. So the VM does not notice
that it is working with a different object.
Exactly. In Smalltalk-80 v2.0 there was no wide string support so String was the concrete string class with 8-bit elements. Now we have wide string support and hence ByteSymbol ByteString WideSymbol and WideString. The VM requires that specialObjectsArray at: 7 is an 8-bit string class which is ByteString in contemporary Squeaks and String in older Squeaks.
Remember the major goal of the MicroSqueak work is to produce a kernel image that can bootstrap a contemporary Squeak image. So it is important to bring MicroSqueak up-to-date, and make it's classes match the current system. For example, its use of System in place of SmalltalkImage and SystemDIctionary as well as its use of String in place of ByteString and String makes sense if the goal is as small an image as possible but doesn't make sense if the goal is bootstrapping current images. So please update these areas of MicroSqueak.
best
Eliot
Thanks
Gabriel
Locked
