[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
|