On 2 August 2011 15:31, Henrik Johansen <henrik.s.johan...@veloxit.no> wrote: > > On Aug 2, 2011, at 3:14 15PM, Igor Stasenko wrote: > >> On 2 August 2011 14:18, Henrik Johansen <henrik.s.johan...@veloxit.no> wrote: >>> >>> On Aug 1, 2011, at 8:43 53AM, Igor Stasenko wrote: >>> >>>> I found that #testBecomeIdentityHash sometimes failing, sometimes not. >>>> >>>> It seems like VM 'forgets' to produce different identityHash bits for >>>> two consequently allocated objects, >>>> while test assumes that they are always different. >>>> >>>> If i insert a statement (see the code), test no longer fails. >>>> >>>> testBecomeIdentityHash >>>> "Note. The identity hash of both objects seems to change after the >>>> become:" >>>> >>>> | a b c d | >>>> >>>> a := 'ab' copy. >>>> b := 'cd' copy. >>>> >>>>>>> [ b identityHash = a identityHash ] whileTrue: [ b := b copy ]. >>>> >>>> c := a. >>>> d := b. >>>> >>>> a become: b. >>>> >>>> self >>>> assert: a identityHash = c identityHash; >>>> assert: b identityHash = d identityHash; >>>> deny: a identityHash = b identityHash. >>>> >>>> A simple piece of code reveals the problem: >>>> >>>> (1 to: 20) collect: [:i | >>>> 'ab' copy basicIdentityHash ] #(954 954 955 955 956 956 957 957 958 >>>> 958 959 959 960 960 961 961 962 962 963 963) >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>> >>> What is the point of this test in the first place? >>> To me it seems to test whether a VM's implementation of become: adheres to >>> some properties. >>> At least, VM bugs in traversal of references during become is the only way >>> I could see the two first asserts EVER being false. >>> >>> As for the last assert (well, deny actually), in the context of what it's >>> supposed to test as established above, it seems to me to say a VM should >>> never give the same identityHash to subsequently copied objects. Which means >>> a) It has nothing to do with become and identityHash, thus is in the test. >>> b) Is this a property any code actually rely on? >>> >>> If not, why would we assert such a restriction on the VM implementation, or >>> is it harmless? >>> >>> Either way, modifying the test to iterate till they ARE different, would >>> make it meaningless in either case (and possible infinite loop in case of a >>> really bad VM). >>> >> >> There is strong reason to test identityHashes, because VM should >> preserve an identity hash for oops. >> >> But of course test is wrong , because to test that , it should be like >> following: >> >> | a b hash1 hash2 | >> >> a := 'ab' copy. >> b := 'cd' copy. >> hash1 := a identityHash. >> hash2 := b identityHash. >> >> a become: b. >> >> self >> assert: a identityHash = hash1; >> assert: b identityHash = hash2. >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > Please include a comment with that. :) > Like this has shown, it's rather hard to know wtf to do when you can't > unambiguously read what its actually intended to test from the code itself. >
The intent for preserving a hash is to not break hashed collections which using identityhash: a := 'aver' copy. dict := IdentityDictionary new. dict at: a put: 10. a become: 'ijoewfj' copy. self assert: (dict at: a) = 10 > Cheers, > Henry > > > -- Best regards, Igor Stasenko AKA sig.
