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.

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