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

Andreas Raab andreas.raab at gmx.de
Tue Feb 2 19:30:40 UTC 2010


Levente Uzonyi wrote:
> On Tue, 2 Feb 2010, Andreas Raab wrote:
> 
>> 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.
> 
> Great, it works. But two tests are failing now which passed before:
> TraitsTestCase >> #testChangeSuperclass
> PureBehaviorTest >> #testChangeSuperclass

I noticed that too. The failures are genuine, the bug that I fixed had 
some ugly side effects which made the tests pass in situations where 
they shouldn't. I'll look at it tonight.

Cheers,
   - Andreas

> 
> 
> Levente
> 
>>
>> Cheers,
>>  - 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