Hi Yoshiki.

I'm reading your paper on the design and implementation of these
changes. It is very interesting. If I understand correctly, the only
reason that a system tracer is needed, is that String's superclass
cannot be changed by recompilation. You explain that this is caused by
the VM holding a pointer to the String class.

I was wondering if we shouldn't consider that to be a kernel bug. This
would allow the work in question to be released as a simple loadable
change set or two, without the need for cloning.

>From a look at the error raised when I try to run change the superclass,
it appears that String is hard coded as one of the classes known by the
VM, and therefore are dangerous. Since your work doesn't actually change
the class structure, it seems this should not be forbidden. In fact,
removing String from the tooDangerous method actually allows me to do
the required change without a problem (as far as I can tell). 

I'm not arguing that removing String from tooDangerous is itself a good
idea permanently, but it's a work-around for what appears like a
too-strict limit in ClassBuilder.

Daniel

Yoshiki.Ohshima at acm.org wrote:
>   Hello,
> 
>   I just updated a couple of Swiki page and uploaded the multilingual
> Squeak code.  This is nothing more than pre-alpha (or pre-pre-alpha),
> which I barely hope that it conveys the general design idea.
> 
>   For those who wants to try it, visit 
> 
> http://minnow.cc.gatech.edu/squeak/919
> 
> and follow the instructions.
> 
>   I really like to improve the system and hope one day we can make the
> unified version of Squeak which works as a vehicle for the world-wide
> communication and idea-sharing.  So, feel free to send comment,
> critic, and of course, code.
> 
>   Hopefully, I can set up a update stream for this particular version
> of Squeak to track the changes we are going to make.
> 
>   Enjoy and Thank you!
> 
> -- Yoshiki