[squeak-dev] ALL CLEAR (Re: Class>>binding broken)

Andreas Raab andreas.raab at gmx.de
Tue Feb 2 18:12:08 UTC 2010

Okay, the issue should be fixed now. If you're at update 8964 or sooner, 
you can just update and won't see any issues. If you're past 8964 
already, run ReadStreamTests and if they fail, please reload 
CollectionTests-ar.138 manually to ensure it's loaded properly.

   - Andreas

Andreas Raab wrote:
> Levente Uzonyi wrote:
>> After updating my image, most tests in ReadStreamTest fails or raises 
>> an error. If I open a Monticello Browser, select CollectionTests and 
>> Trunk, click changes, I see lots of methods changed. So this is 
>> probably a new MC issue. Loading the .mcz from the Trunk solves the 
>> problem.
> This is an interesting issue that arises from the new traits 
> implementation but its root cause is elsewhere. What happens is that 
> when reshaping a class that uses traits it may "loose" it's local 
> methods due to Class>>binding being just plain wrong. When reshaping a 
> class, a new class is created in which the methods get compiled but due 
> to the incorrect usage of Class>>binding these newly compiled method 
> will bind to the old class.
> The only reason this works at all is that at the end of the reshape we 
> do a forward #become: which corrects this problem but the installation 
> of the traits happens before the #become: has fixed them up.
> There are two possible solutions: Fix Class>>binding to test whether the 
> association actually points to the class. This is straightforward but 
> has a major disadvantage - it means that when adding ivars and stuff we 
> will create new bindings for every method. Effectively that makes the 
> class binding unsharable unless one adds another .
> The alternative is to defer the installation of traits until *after* the 
> reshape is complete. This is not exactly trivial either but it would 
> avoid the issue raised above.
> Opinions? Other alternatives?
> Cheers,
>   - Andreas

More information about the Squeak-dev mailing list