As one of the people involved in the implementation, I apologize for 
that, I didn't notice that effect.

Note that an in-the-image fix (or rather, hack) is to take those 
variables outside Behavior, and store them in an IdentityDictionary. 
This is simple to code, but it is not necessarily trivial to convert to 
this (requires recompiling all metaclasses, again).

Since in the stable state, the right thing to do is probably to have 
those variables in Behavior, it might be better to bite the bullet and 
change the VM. BTW, any chance this dependecy of the VM on the image can 
be removed, instead of just changed? that would make the VM change 
backwards compatible...

While I can see that, for example, printing a debug stack requires the 
VM to know about class names, it is not obvious to me that type checks 
should use names rather than identities. Then again, there is a lot 
about the VM that I don't understand...

Daniel

Andreas Raab wrote:

> Marcus Denker wrote:
>
>>
>> What does Traits have do do with this?
>
>
> Quite a bit. The traits installation adds two variables to Behavior 
> (traitComposition and localSelectors) and it looks like this isn't as 
> harmless for the VM as most people (including myself) thought. It 
> seems like there are a few places where the class name is assumed in a 
> specific position, including Interpreter>>printNameOfClass:count: and 
> Interpreter>>classNameOf:is:. The latter is what's causing the problem 
> since it is used by Interpreter>>is:KindOf: which in turn is used by 
> SmartSyntaxPluginCodeGenerator>>ccgLoad:expr:asKindOf:from: which is 
> applied as the generic prologue for classes that have no more specific 
> type checks (in this case we have a Form argument to which this applies).
>
> Therefore, all primitives using this pattern will fail with post 6706 
> images. What's potentially worse is that we don't know where else any 
> of those functions are being used (I wonder if they are used in the 
> FFI for some of the type checks...)
>
> Fixing this will not be easy - if a VM change is required it means 
> that older images will fail on newer VMs and vice versa.
>
> Cheers,
>   - Andreas
>
>