On 2 August 2011 15:31, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On Aug 2, 2011, at 3:14 15PM, Igor Stasenko wrote:
On 2 August 2011 14:18, Henrik Johansen <henrik.s.johansen@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.