October 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] hash and collections

by Richard Uttner

Esteban, it is defined that #hash and #= always have to be implemented accordingly. What you are expecting seems to me be more appropriate for object identity considerations as already mentioned correctly in this thread. One of the clearest explanations concerning this topic I know is: http://www.javaranch.com/journal/2002/10/equalhash.html In fact, it would not lead to a wrong behaviour if #hash had been implemented as you expected, but to unnecessary compares when searching within a hashed collection (meaning: the implementation would sometimes consider two collections wrongly to be equal due to their identical hash code, but when comparing them with #=, recognize the difference and check the next one with the same hash code). More important is the opposite relation: Two objects considered as equal when compared with #= always MUST produce the same hash code, otherwise the system would behave badly in an unpredictable way. Richard > On 09 Oct 2015, at 16:21, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > > > If the collection implements = using the objects it holds then you need > to consider at least some of them in the hash calculation. I can't conceive > a hash calculation for this case independent of the contents (well, just > hardcode a number but this will lead to always collide if used as a key in > a hashed collection). > > it is not :) > > > > > I'm with Levente here, I think the hash implementation is reasonable. > And I wouldn't use a mutable object as key in a hashed collection. > > no idea? I?m not using it, just arrive to that method random and I cannot > understand it. > I still believe is wrong. > > Esteban > > > > > On Fri, Oct 9, 2015 at 11:07 AM, Esteban Lorenzano <estebanlm(a)gmail.com > <mailto:estebanlm@gmail.com>> wrote: > > but that?s an error, I think. > > a collection has to have always same hash? no matter its size (because > is not an array) and no matter his elements. > > > > > > > On 09 Oct 2015, at 15:21, Levente Uzonyi <leves(a)elte.hu <mailto: > leves(a)elte.hu>> wrote: > > > > > > You simply don't modify _objects_ which are used as keys in hashed > collections. Or if you do so, you'll have to deal with the consequences > yourself. > > > > > > Levente > > > > > > On Fri, 9 Oct 2015, Esteban Lorenzano wrote: > > > > > >> Hi, > > >> > > >> Can anyone explain me how this is correct? > > >> > > >> Collection>>#hash > > >> "Answer an integer hash value for the receiver such that, > > >> -- the hash value of an unchanged object is constant over > time, and > > >> -- two equal objects have equal hash values" > > >> > > >> | hash | > > >> > > >> hash := self species hash. > > >> self size <= 10 ifTrue: > > >> [self do: [:elem | hash := hash bitXor: elem hash]]. > > >> ^hash bitXor: self size hash > > >> > > >> > > >> I mean? a hash that changes when I add elements to the collection? > how can this work? > > >> > > >> Esteban > > > > > > > >

Oct. 9, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50380 Home: https://github.com/pharo-project/pharo-core

Oct. 9, 2015

[pharo-project/pharo-core] a785f4: 50380

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: a785f41a9f3da00652dfdb5ec943a39a65ca492a https://github.com/pharo-project/pharo-core/commit/a785f41a9f3da00652dfdb5e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-10-09 (Fri, 09 Oct 2015) Changed paths: M Monticello.package/MCMergeResolutionRequest.class/instance/testing/hasConflicts.st A Monticello.package/MCMerger.class/instance/testing/hasConflicts.st A Morphic-Widgets-FastTable.package/FTSearchFunction.class/instance/initialization/reset.st M Morphic-Widgets-FastTable.package/FTSearchFunction.class/instance/private/showSearchFieldFromKeystrokeEvent_.st R Reflectivity-Examples.package/ExecutionDisplayMorph.class/instance/as yet unclassified/noteExecution.st M Reflectivity.package/MetaLink.class/instance/link api/condition_.st M Reflectivity.package/MetaLink.class/instance/link api/metaObject_.st M Reflectivity.package/ReflectiveMethod.class/instance/invalidate/installCompiledMethod.st A Reflectivity.package/extension/ProtoObject/instance/metaLinkOptions.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50379.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50380.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50379.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50380.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M UIManager.package/CommandLineUIManager.class/instance/ui requests/merge_informing_.st A UIManager.package/NonInteractiveUIManager.class/instance/ui requests/merge_informing_.st Log Message: ----------- 50380 16752 problems with new search function in FastTable https://pharo.fogbugz.com/f/cases/16752 16753 Invalidate ProtoObject https://pharo.fogbugz.com/f/cases/16753 15713 CommandLineUIManager>>#merge:informing: is not doing anything https://pharo.fogbugz.com/f/cases/15713 http://files.pharo.org/image/50/50380.zip

Oct. 9, 2015

Re: [Pharo-dev] hash and Collections

by Alexandre Bergel

Hi Esteban, I understand your surprise, but it has to be like that. Two objects that are equals have to have the same hash value. This is part of the contract. And to comply with this rule with collections, the hash value has to reflect the content of the collection. Java has the same behavior. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Oct 9, 2015, at 11:07 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > but thatâs an error, I think. > a collection has to have always same hashâ¦ no matter its size (because is not an array) and no matter his elements. > > >> On 09 Oct 2015, at 15:21, Levente Uzonyi <leves(a)elte.hu> wrote: >> >> You simply don't modify _objects_ which are used as keys in hashed collections. Or if you do so, you'll have to deal with the consequences yourself. >> >> Levente >> >> On Fri, 9 Oct 2015, Esteban Lorenzano wrote: >> >>> Hi, >>> >>> Can anyone explain me how this is correct? >>> >>> Collection>>#hash >>> "Answer an integer hash value for the receiver such that, >>> -- the hash value of an unchanged object is constant over time, and >>> -- two equal objects have equal hash values" >>> >>> | hash | >>> >>> hash := self species hash. >>> self size <= 10 ifTrue: >>> [self do: [:elem | hash := hash bitXor: elem hash]]. >>> ^hash bitXor: self size hash >>> >>> >>> I meanâ¦ a hash that changes when I add elements to the collectionâ¦ how can this work? >>> >>> Esteban > >

Oct. 9, 2015

Re: [Pharo-dev] [Slots] Slides from ESUG: Variables in Pharo5

by Marcus Denker

On Fri, Jul 17, 2015 at 3:05 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > The slides from the second talk are online: > > http://www.slideshare.net/MarcusDenker/variables-in-pharo5 > > Video is finally online, too: Video Part1: https://www.youtube.com/watch?v=hEWKV9eWAGY Video Part2: https://www.youtube.com/watch?v=hEWKV9eWAGY

Oct. 9, 2015

Re: [Pharo-dev] hash and Collections

by Henrik Johansen

> On 09 Oct 2015, at 4:33 , Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 09 Oct 2015, at 16:21, Gabriel Cotelli <g.cotelli(a)gmail.com <mailto:g.cotelli@gmail.com>> wrote: >> >> If the collection implements = using the objects it holds then you need to consider at least some of them in the hash calculation. I can't conceive a hash calculation for this case independent of the contents (well, just hardcode a number but this will lead to always collide if used as a key in a hashed collection). > > it is not :) > >> >> I'm with Levente here, I think the hash implementation is reasonable. And I wouldn't use a mutable object as key in a hashed collection. > > no ideaâ¦ Iâm not using it, just arrive to that method random and I cannot understand it. > I still believe is wrong. It's not. Either Dictionary >> #= or IdentityDictionary >> #species in Pharo *is* broken though. dic1 := Dictionary newFrom:{1 -> 4}. dic2 := IdentityDictionary newFrom: dic1 associations . dic1 = dic2 true dic1 hash = dic2 hash false Cheers, Henry

Oct. 9, 2015

Re: [Pharo-dev] hash and Collections

by Esteban Lorenzano

> On 09 Oct 2015, at 16:21, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > If the collection implements = using the objects it holds then you need to consider at least some of them in the hash calculation. I can't conceive a hash calculation for this case independent of the contents (well, just hardcode a number but this will lead to always collide if used as a key in a hashed collection). it is not :) > > I'm with Levente here, I think the hash implementation is reasonable. And I wouldn't use a mutable object as key in a hashed collection. no ideaâ¦ Iâm not using it, just arrive to that method random and I cannot understand it. I still believe is wrong. Esteban > > On Fri, Oct 9, 2015 at 11:07 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > but thatâs an error, I think. > a collection has to have always same hashâ¦ no matter its size (because is not an array) and no matter his elements. > > > > On 09 Oct 2015, at 15:21, Levente Uzonyi <leves(a)elte.hu <mailto:leves@elte.hu>> wrote: > > > > You simply don't modify _objects_ which are used as keys in hashed collections. Or if you do so, you'll have to deal with the consequences yourself. > > > > Levente > > > > On Fri, 9 Oct 2015, Esteban Lorenzano wrote: > > > >> Hi, > >> > >> Can anyone explain me how this is correct? > >> > >> Collection>>#hash > >> "Answer an integer hash value for the receiver such that, > >> -- the hash value of an unchanged object is constant over time, and > >> -- two equal objects have equal hash values" > >> > >> | hash | > >> > >> hash := self species hash. > >> self size <= 10 ifTrue: > >> [self do: [:elem | hash := hash bitXor: elem hash]]. > >> ^hash bitXor: self size hash > >> > >> > >> I meanâ¦ a hash that changes when I add elements to the collectionâ¦ how can this work? > >> > >> Esteban > > >

Oct. 9, 2015

Re: [Pharo-dev] hash and Collections

by Gabriel Cotelli

If the collection implements = using the objects it holds then you need to consider at least some of them in the hash calculation. I can't conceive a hash calculation for this case independent of the contents (well, just hardcode a number but this will lead to always collide if used as a key in a hashed collection). I'm with Levente here, I think the hash implementation is reasonable. And I wouldn't use a mutable object as key in a hashed collection. On Fri, Oct 9, 2015 at 11:07 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > but thatâs an error, I think. > a collection has to have always same hashâ¦ no matter its size (because is > not an array) and no matter his elements. > > > > On 09 Oct 2015, at 15:21, Levente Uzonyi <leves(a)elte.hu> wrote: > > > > You simply don't modify _objects_ which are used as keys in hashed > collections. Or if you do so, you'll have to deal with the consequences > yourself. > > > > Levente > > > > On Fri, 9 Oct 2015, Esteban Lorenzano wrote: > > > >> Hi, > >> > >> Can anyone explain me how this is correct? > >> > >> Collection>>#hash > >> "Answer an integer hash value for the receiver such that, > >> -- the hash value of an unchanged object is constant over time, > and > >> -- two equal objects have equal hash values" > >> > >> | hash | > >> > >> hash := self species hash. > >> self size <= 10 ifTrue: > >> [self do: [:elem | hash := hash bitXor: elem hash]]. > >> ^hash bitXor: self size hash > >> > >> > >> I meanâ¦ a hash that changes when I add elements to the collectionâ¦ how > can this work? > >> > >> Esteban > > >

Oct. 9, 2015

Re: [Pharo-dev] hash and Collections

by Henrik Nergaard

The identityHash should stay the same for any number of changes to the array.. | c1 c2 | c1 := { #a . #b } asOrderedCollection. c2 := { #a . #b } asOrderedCollection. { c1 hash. c1 identityHash. c2 hash. c2 identityHash . (c2 add: #c; yourself) identityHash. } "inspect" Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Esteban Lorenzano Sent: Friday, October 9, 2015 4:08 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] hash and Collections but thatâs an error, I think. a collection has to have always same hashâ¦ no matter its size (because is not an array) and no matter his elements. > On 09 Oct 2015, at 15:21, Levente Uzonyi <leves(a)elte.hu> wrote: > > You simply don't modify _objects_ which are used as keys in hashed collections. Or if you do so, you'll have to deal with the consequences yourself. > > Levente > > On Fri, 9 Oct 2015, Esteban Lorenzano wrote: > >> Hi, >> >> Can anyone explain me how this is correct? >> >> Collection>>#hash >> "Answer an integer hash value for the receiver such that, >> -- the hash value of an unchanged object is constant over time, and >> -- two equal objects have equal hash values" >> >> | hash | >> >> hash := self species hash. >> self size <= 10 ifTrue: >> [self do: [:elem | hash := hash bitXor: elem hash]]. >> ^hash bitXor: self size hash >> >> >> I meanâ¦ a hash that changes when I add elements to the collectionâ¦ how can this work? >> >> Esteban

Oct. 9, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] b4f208: 50379

by Stephan Eggermont

On 09-10-15 15:38, Andrei Chis wrote: > Strange. This version just merged a few deprecated calls and typos. > Nothing related to rubric or nautilus. > > Are you sure these errors are from this version? You're right, they might be from a few versions earlier Stephan

Oct. 9, 2015