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.


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