On Tue, 14 May 2013, Levente Uzonyi wrote:

> On Tue, 14 May 2013, Frank Shearar wrote:
>
>> On 14 May 2013 12:28, Levente Uzonyi <leves at elte.hu> wrote:
>>> On Mon, 13 May 2013, Chris Muller wrote:
>>> 
>>>> Usually this sort of problem is due to changing the hash key of an
>>>> object in the dictionary -- but you said an IdentityDictionary so..
>>>> unless there was a become: of some kind (with copyHash: false) then it
>>>> may be something else..
>>> 
>>> 
>>> It's enough to change the key of the association to a different object.
>> 
>> Which explains why it's something called #testClassRenamed causing the 
>> problem.
>
> Well, it caused no problems before Environments, because the association was 
> removed from the SystemDictionary before renaming, and added again after it.
>
> With Environments it's a bit more complicated, because there are two 
> dictionaries in an Environment: 'contents' and 'bindins'. I'm not sure what 
> the role of these are, but #renameClass:from:to: only removes the association 
> from 'contents'. If it's also present in 'bindings', then 'bindings' will get 
> into an invalid state.
>
> It's also a bit suspicious, that #associationAt: and #associationAt:ifAbsent: 
> both use 'contents' to get the association, but #associationOrUndeclaredAt: 
> uses 'bindings'.

By chasing the pointers I found that some associations are stored in the 
Environment's exports variable's namespace variable. That is the 
IdentityDictionary which breaks during renaming, because it holds on the 
same association.


Levente

>
>
> Levente
>
>> 
>> frank
>> 
>>> Levente
>>> 
>>> 
>>>> 
>>>> On Sun, May 12, 2013 at 6:30 AM, Frank Shearar <frank.shearar at gmail.com>
>>>> wrote:
>>>>> 
>>>>> This test fails because, as far as I can tell, SystemChangeFileTest >>
>>>>> #testClassRenamed breaks the integrity of an IdentityDictionary.
>>>>> 
>>>>> This IdentityDictionary (call it dict) reports having a key in
>>>>> #keysAndValuesDo: such that dict at: key raises a KeyNotFound.
>>>>> 
>>>>> Inspecting dict verifies this weirdness, even though you can see the
>>>>> key in the inspector's right hand pane.
>>>>> 
>>>>> Ideas?
>>>>> 
>>>>> The diff in the manifests between the last version where this test
>>>>> didn't fail and where it did looks like this:
>>>>> 
>>>>> $ diff /home/frank/Downloads/TrunkImage.313.manifest
>>>>> /home/frank/Downloads/TrunkImage.314.manifest
>>>>> 22c22
>>>>> < Monticello (bf.541)
>>>>> ---
>>>>>> 
>>>>>> Monticello (bf.542)
>>>>> 
>>>>> 26c26
>>>>> < MorphicTests (ar.18)
>>>>> ---
>>>>>> 
>>>>>> MorphicTests (fbs.20)
>>>>> 
>>>>> 49c49
>>>>> < Tests (fbs.207)
>>>>> ---
>>>>>> 
>>>>>> * Tests (fbs.212)
>>>>> 
>>>>> 62,63d61
>>>>> 
>>>>> Not terribly enlightening...
>>>>> 
>>>>> frank
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>
>