- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

by Max Leske

> On 17.10.2014, at 16:41, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Max, > > On Oct 17, 2014, at 7:24 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > >> >>> On 17.10.2014, at 15:52, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote: >>> >>> >>> >>> 2014-10-17 15:49 GMT+02:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: >>> >>>> On 17.10.2014, at 15:25, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >>>> >>>> Hi Max, >>>> >>>> On Oct 17, 2014, at 12:34 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >>>> >>>>> >>>>>> On 17.10.2014, at 02:46, Ben Coman <btc(a)openInWorld.com <mailto:btc@openInWorld.com>> wrote: >>>>>> >>>>>> Richard Sargent wrote: >>>>>>> Eliot Miranda-2 wrote >>>>>>>> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent < >>>>>>>> richard.sargent@ >>>>>>>>> wrote: >>>>>>>>> One of the best things about Smalltalk is how easily we can say what we >>>>>>>>> mean. I think you would be better off creating a method named something >>>>>>>>> like >>>>>>>>> #hasSameEffectAs: to answer what you are presently using #= to do, and >>>>>>>>> change #= to answer the, in my opinion, more sensible "is the same as" >>>>>>>>> that >>>>>>>>> we conventionally think of #= meaning. >>>>>>>>> >>>>>>>> But that's the point. #= has to mean something and having it mean #== >>>>>>>> isn't useful, so one has to choose some value-based semantic for >>>>>>>> CompiledMethod>>#= and the one that's there is useful. Defining what #= >>>>>>>> means for some value type is far easier than defining what it might mean >>>>>>>> for something as complex as a CompiledMethod. The definition in >>>>>>>> Squeak/Pharo has been useful to me in implementing a closure-based system, >>>>>>>> so I'm unapologetic about the current definition. It is a good one but it >>>>>>>> doesn't preclude defining others. >>>>>>> An interesting response. You ignored the point that e.g. #hasSameEffectAs: >>>>>>> provides greater clarity and add an argument against something I didn't say. >>>>>>> I also don't think defining equality for a CompiledMethod is particularly >>>>>>> difficult. If I were to recompile a method's source code, I would get a new >>>>>>> instance of a CompiledMethod that would, in my opinion, be equal to the one >>>>>>> already installed in the class (and perhaps cached in the VM's >>>>>>> optimizations). So one would be able to say that we would not replace an >>>>>>> existing CompiledMethod with an equal one. The current implementation of #= >>>>>>> has no such characteristic, since it proclaims a CompiledMethod named #a to >>>>>>> be equal to one named #z. >>>>>> >>>>>> @Richard >>>>>> >>>>>> That doesn't seem to be a good example for what your trying to say. >>>>>> Given... >>>>>> >>>>>> [1] SomeClass>>a "original instance" >>>>>> ^1 >>>>>> >>>>>> [2] SomeClass>>a "recompiled instance" >>>>>> ^1 >>>>>> >>>>>> [3] SomeClass>>z >>>>>> ^1 >>>>>> >>>>>> ...you seem to be saying that its useful to know if [1]=[2], >>>>>> but imply that is invalidated by [2]=[3] ? >>>>>> >>>>>> But [1]=[2] remains true, and just as useful for your example. >>>>>> >>>>>> >>>>>> @Max >>>>>> >>>>>> I guess to call it a bug, you bumped into a different use case >>>>>> where [2]=[3] is problematic. Can you describe that? >>>>> >>>>> Well, not problematic. Once you accept that neither selector nor class are part of a CompiledMethod it is obvious that two instances with the same byte codes produce the same hash. >>>>> >>>>> The actual problem is more one of understanding and use. The following code answers a collection with the CompiledMethods Collection>>add:, Collection>>do: and Collection>>remove:ifAbsent: >>>>> >>>>> Collection methods select: #isAbstract. >>>>> >>>>> All three CompiledMethods are implemented as â^ self subclassResponsibilityâ, so they have the same byte codes. Now, if you take that collection and make a set out of it youâll lose Collection>>do: since #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because the number of arguments is calculated into the hash (actually the CompiledMethod header is). >>>> >>>> Surely the issue is that "aClass methods" should answer an IdentitySet right? >>> >>> Well, in the case of my example that wouldnât change anything. As soon as you put the methods into a set youâll end up with less entries than before again. Selectors are unique per class anyway so I donât quite see the benefit of using an IdentitySet over an OrderedCollection (or a Bag for that matter), except for making it more obvious that the result of the message #methods doesnât need to be filtered further. >>> >>> I should add that the code, the student who discovered the clash wrote, looked more like this: >>> >>> result := Set new. >>> Collection methods do: [ :m | >>> m isAbstract ifTrue: [ result add: m ] ]. >>> >>> Max >>> >>> >>> Why not just keep a dictionary, like methodDictionary select: #isAbstract or something like thatâ¦ >> >> Youâre right of course, thereâs no need to put methods into a set. The code is from an exercise and the students arenât used to Smalltalk, so they end up with all sorts of code. > > And so they learn... > :p > >>>>> So, as long as you think of CompiledMethods as objects that have a name, it looks like a bug and in my opinion this behaviour is something that messes with the mind of newcomers. Just a (silly) idea: something like a CompiledMethodWrapper might solve the problem (at least from the user perspective; everything is slightly different from the VM perspective :) ), as it could hold on to the class and the selector independently of the actual CompiledMethod. >>>>> >>>>> In the end however, one doesnât work with compiled methods a lot and the hash situation is unlikely to cause a lot of problems (people working with CompiledMethod usually know what they are doing). >>>>> >>>>> Cheers, >>>>> Max >>>>> >>>>>> >>>>>> >>>>>> cheers -ben >>>>>> >>>>>> >>>>>>> The blue book say #= means "Answer whether the receiver and the argument >>>>>>> represent the same component." The current implementation does so only for >>>>>>> some, in my opinion, counter-intuitive definition of "same component". >>>>>>> -- >>>>>>> View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p478… <http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p478…> >>>>>>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>. >>>> >>>> Eliot (phone) > > > Eliot (phone)

Oct. 17, 2014

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

by Eliot Miranda

Hi Max, On Oct 17, 2014, at 7:24 AM, Max Leske <maxleske(a)gmail.com> wrote: > >> On 17.10.2014, at 15:52, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> >> >> 2014-10-17 15:49 GMT+02:00 Max Leske <maxleske(a)gmail.com>: >>> >>>> On 17.10.2014, at 15:25, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>> >>>> Hi Max, >>>> >>>> On Oct 17, 2014, at 12:34 AM, Max Leske <maxleske(a)gmail.com> wrote: >>>> >>>>> >>>>>> On 17.10.2014, at 02:46, Ben Coman <btc(a)openInWorld.com> wrote: >>>>>> >>>>>> Richard Sargent wrote: >>>>>>> Eliot Miranda-2 wrote >>>>>>>> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent < >>>>>>>> richard.sargent@ >>>>>>>>> wrote: >>>>>>>>> One of the best things about Smalltalk is how easily we can say what we >>>>>>>>> mean. I think you would be better off creating a method named something >>>>>>>>> like >>>>>>>>> #hasSameEffectAs: to answer what you are presently using #= to do, and >>>>>>>>> change #= to answer the, in my opinion, more sensible "is the same as" >>>>>>>>> that >>>>>>>>> we conventionally think of #= meaning. >>>>>>>> But that's the point. #= has to mean something and having it mean #== >>>>>>>> isn't useful, so one has to choose some value-based semantic for >>>>>>>> CompiledMethod>>#= and the one that's there is useful. Defining what #= >>>>>>>> means for some value type is far easier than defining what it might mean >>>>>>>> for something as complex as a CompiledMethod. The definition in >>>>>>>> Squeak/Pharo has been useful to me in implementing a closure-based system, >>>>>>>> so I'm unapologetic about the current definition. It is a good one but it >>>>>>>> doesn't preclude defining others. >>>>>>> An interesting response. You ignored the point that e.g. #hasSameEffectAs: >>>>>>> provides greater clarity and add an argument against something I didn't say. >>>>>>> I also don't think defining equality for a CompiledMethod is particularly >>>>>>> difficult. If I were to recompile a method's source code, I would get a new >>>>>>> instance of a CompiledMethod that would, in my opinion, be equal to the one >>>>>>> already installed in the class (and perhaps cached in the VM's >>>>>>> optimizations). So one would be able to say that we would not replace an >>>>>>> existing CompiledMethod with an equal one. The current implementation of #= >>>>>>> has no such characteristic, since it proclaims a CompiledMethod named #a to >>>>>>> be equal to one named #z. >>>>>> >>>>>> @Richard >>>>>> >>>>>> That doesn't seem to be a good example for what your trying to say. >>>>>> Given... >>>>>> >>>>>> [1] SomeClass>>a "original instance" >>>>>> ^1 >>>>>> >>>>>> [2] SomeClass>>a "recompiled instance" >>>>>> ^1 >>>>>> >>>>>> [3] SomeClass>>z >>>>>> ^1 >>>>>> >>>>>> ...you seem to be saying that its useful to know if [1]=[2], >>>>>> but imply that is invalidated by [2]=[3] ? >>>>>> >>>>>> But [1]=[2] remains true, and just as useful for your example. >>>>>> >>>>>> >>>>>> @Max >>>>>> >>>>>> I guess to call it a bug, you bumped into a different use case >>>>>> where [2]=[3] is problematic. Can you describe that? >>>>> >>>>> Well, not problematic. Once you accept that neither selector nor class are part of a CompiledMethod it is obvious that two instances with the same byte codes produce the same hash. >>>>> >>>>> The actual problem is more one of understanding and use. The following code answers a collection with the CompiledMethods Collection>>add:, Collection>>do: and Collection>>remove:ifAbsent: >>>>> >>>>> Collection methods select: #isAbstract. >>>>> >>>>> All three CompiledMethods are implemented as â^ self subclassResponsibilityâ, so they have the same byte codes. Now, if you take that collection and make a set out of it youâll lose Collection>>do: since #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because the number of arguments is calculated into the hash (actually the CompiledMethod header is). >>>> >>>> Surely the issue is that "aClass methods" should answer an IdentitySet right? >>> >>> Well, in the case of my example that wouldnât change anything. As soon as you put the methods into a set youâll end up with less entries than before again. Selectors are unique per class anyway so I donât quite see the benefit of using an IdentitySet over an OrderedCollection (or a Bag for that matter), except for making it more obvious that the result of the message #methods doesnât need to be filtered further. >>> >>> I should add that the code, the student who discovered the clash wrote, looked more like this: >>> >>> result := Set new. >>> Collection methods do: [ :m | >>> m isAbstract ifTrue: [ result add: m ] ]. >>> >>> Max >> >> Why not just keep a dictionary, like methodDictionary select: #isAbstract or something like thatâ¦ > > Youâre right of course, thereâs no need to put methods into a set. The code is from an exercise and the students arenât used to Smalltalk, so they end up with all sorts of code. And so they learn... >>>>> So, as long as you think of CompiledMethods as objects that have a name, it looks like a bug and in my opinion this behaviour is something that messes with the mind of newcomers. Just a (silly) idea: something like a CompiledMethodWrapper might solve the problem (at least from the user perspective; everything is slightly different from the VM perspective :) ), as it could hold on to the class and the selector independently of the actual CompiledMethod. >>>>> >>>>> In the end however, one doesnât work with compiled methods a lot and the hash situation is unlikely to cause a lot of problems (people working with CompiledMethod usually know what they are doing). >>>>> >>>>> Cheers, >>>>> Max >>>>> >>>>>> >>>>>> >>>>>> cheers -ben >>>>>> >>>>>> >>>>>>> The blue book say #= means "Answer whether the receiver and the argument >>>>>>> represent the same component." The current implementation does so only for >>>>>>> some, in my opinion, counter-intuitive definition of "same component". >>>>>>> -- >>>>>>> View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p478… >>>>>>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >>>> >>>> Eliot (phone) Eliot (phone)

Oct. 17, 2014

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

by Eliot Miranda

Hi Max, On Oct 17, 2014, at 6:49 AM, Max Leske <maxleske(a)gmail.com> wrote: > >> On 17.10.2014, at 15:25, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Max, >> >> On Oct 17, 2014, at 12:34 AM, Max Leske <maxleske(a)gmail.com> wrote: >> >>> >>>> On 17.10.2014, at 02:46, Ben Coman <btc(a)openInWorld.com> wrote: >>>> >>>> Richard Sargent wrote: >>>>> Eliot Miranda-2 wrote >>>>>> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent < >>>>>> richard.sargent@ >>>>>>> wrote: >>>>>>> One of the best things about Smalltalk is how easily we can say what we >>>>>>> mean. I think you would be better off creating a method named something >>>>>>> like >>>>>>> #hasSameEffectAs: to answer what you are presently using #= to do, and >>>>>>> change #= to answer the, in my opinion, more sensible "is the same as" >>>>>>> that >>>>>>> we conventionally think of #= meaning. >>>>>> But that's the point. #= has to mean something and having it mean #== >>>>>> isn't useful, so one has to choose some value-based semantic for >>>>>> CompiledMethod>>#= and the one that's there is useful. Defining what #= >>>>>> means for some value type is far easier than defining what it might mean >>>>>> for something as complex as a CompiledMethod. The definition in >>>>>> Squeak/Pharo has been useful to me in implementing a closure-based system, >>>>>> so I'm unapologetic about the current definition. It is a good one but it >>>>>> doesn't preclude defining others. >>>>> An interesting response. You ignored the point that e.g. #hasSameEffectAs: >>>>> provides greater clarity and add an argument against something I didn't say. >>>>> I also don't think defining equality for a CompiledMethod is particularly >>>>> difficult. If I were to recompile a method's source code, I would get a new >>>>> instance of a CompiledMethod that would, in my opinion, be equal to the one >>>>> already installed in the class (and perhaps cached in the VM's >>>>> optimizations). So one would be able to say that we would not replace an >>>>> existing CompiledMethod with an equal one. The current implementation of #= >>>>> has no such characteristic, since it proclaims a CompiledMethod named #a to >>>>> be equal to one named #z. >>>> >>>> @Richard >>>> >>>> That doesn't seem to be a good example for what your trying to say. >>>> Given... >>>> >>>> [1] SomeClass>>a "original instance" >>>> ^1 >>>> >>>> [2] SomeClass>>a "recompiled instance" >>>> ^1 >>>> >>>> [3] SomeClass>>z >>>> ^1 >>>> >>>> ...you seem to be saying that its useful to know if [1]=[2], >>>> but imply that is invalidated by [2]=[3] ? >>>> >>>> But [1]=[2] remains true, and just as useful for your example. >>>> >>>> >>>> @Max >>>> >>>> I guess to call it a bug, you bumped into a different use case >>>> where [2]=[3] is problematic. Can you describe that? >>> >>> Well, not problematic. Once you accept that neither selector nor class are part of a CompiledMethod it is obvious that two instances with the same byte codes produce the same hash. >>> >>> The actual problem is more one of understanding and use. The following code answers a collection with the CompiledMethods Collection>>add:, Collection>>do: and Collection>>remove:ifAbsent: >>> >>> Collection methods select: #isAbstract. >>> >>> All three CompiledMethods are implemented as â^ self subclassResponsibilityâ, so they have the same byte codes. Now, if you take that collection and make a set out of it youâll lose Collection>>do: since #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because the number of arguments is calculated into the hash (actually the CompiledMethod header is). >> >> Surely the issue is that "aClass methods" should answer an IdentitySet right? > > Well, in the case of my example that wouldnât change anything. As soon as you put the methods into a set youâll end up with less entries than before again. No. An IdentitySet uses #== and identityHash so that won't be the case. Also IIRC. anIdentitySet collect: answers another IdentitySet. > Selectors are unique per class anyway so I donât quite see the benefit of using an IdentitySet over an OrderedCollection (or a Bag for that matter), except for making it more obvious that the result of the message #methods doesnât need to be filtered further. Well then (IdentitySet withAll: aClass methods) collect: will not lose elements. You'd have exactly the same issue if you tried to collect the set of all literals in the system. Unless you used an IdentitySet you'd collect only the different values, not all literals. Or any set of all objects that represent values. > I should add that the code, the student who discovered the clash wrote, looked more like this: > > result := Set new. > Collection methods do: [ :m | > m isAbstract ifTrue: [ result add: m ] ]. So change it to IdentitySet new. This is good for the student to encounter. It is one of the essential differences between OO and functional languages. We have state and identity. > Max > >> >> >>> So, as long as you think of CompiledMethods as objects that have a name, it looks like a bug and in my opinion this behaviour is something that messes with the mind of newcomers. Just a (silly) idea: something like a CompiledMethodWrapper might solve the problem (at least from the user perspective; everything is slightly different from the VM perspective :) ), as it could hold on to the class and the selector independently of the actual CompiledMethod. >>> >>> In the end however, one doesnât work with compiled methods a lot and the hash situation is unlikely to cause a lot of problems (people working with CompiledMethod usually know what they are doing). >>> >>> Cheers, >>> Max >>> >>>> >>>> >>>> cheers -ben >>>> >>>> >>>>> The blue book say #= means "Answer whether the receiver and the argument >>>>> represent the same component." The current implementation does so only for >>>>> some, in my opinion, counter-intuitive definition of "same component". >>>>> -- >>>>> View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p478… >>>>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >> Eliot (phone) Cheers, Eliot

Oct. 17, 2014

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

by Max Leske

> On 17.10.2014, at 15:52, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > > 2014-10-17 15:49 GMT+02:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: > >> On 17.10.2014, at 15:25, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >> >> Hi Max, >> >> On Oct 17, 2014, at 12:34 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >> >>> >>>> On 17.10.2014, at 02:46, Ben Coman <btc(a)openInWorld.com <mailto:btc@openInWorld.com>> wrote: >>>> >>>> Richard Sargent wrote: >>>>> Eliot Miranda-2 wrote >>>>>> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent < >>>>>> richard.sargent@ >>>>>>> wrote: >>>>>>> One of the best things about Smalltalk is how easily we can say what we >>>>>>> mean. I think you would be better off creating a method named something >>>>>>> like >>>>>>> #hasSameEffectAs: to answer what you are presently using #= to do, and >>>>>>> change #= to answer the, in my opinion, more sensible "is the same as" >>>>>>> that >>>>>>> we conventionally think of #= meaning. >>>>>>> >>>>>> But that's the point. #= has to mean something and having it mean #== >>>>>> isn't useful, so one has to choose some value-based semantic for >>>>>> CompiledMethod>>#= and the one that's there is useful. Defining what #= >>>>>> means for some value type is far easier than defining what it might mean >>>>>> for something as complex as a CompiledMethod. The definition in >>>>>> Squeak/Pharo has been useful to me in implementing a closure-based system, >>>>>> so I'm unapologetic about the current definition. It is a good one but it >>>>>> doesn't preclude defining others. >>>>> An interesting response. You ignored the point that e.g. #hasSameEffectAs: >>>>> provides greater clarity and add an argument against something I didn't say. >>>>> I also don't think defining equality for a CompiledMethod is particularly >>>>> difficult. If I were to recompile a method's source code, I would get a new >>>>> instance of a CompiledMethod that would, in my opinion, be equal to the one >>>>> already installed in the class (and perhaps cached in the VM's >>>>> optimizations). So one would be able to say that we would not replace an >>>>> existing CompiledMethod with an equal one. The current implementation of #= >>>>> has no such characteristic, since it proclaims a CompiledMethod named #a to >>>>> be equal to one named #z. >>>> >>>> @Richard >>>> >>>> That doesn't seem to be a good example for what your trying to say. >>>> Given... >>>> >>>> [1] SomeClass>>a "original instance" >>>> ^1 >>>> >>>> [2] SomeClass>>a "recompiled instance" >>>> ^1 >>>> >>>> [3] SomeClass>>z >>>> ^1 >>>> >>>> ...you seem to be saying that its useful to know if [1]=[2], >>>> but imply that is invalidated by [2]=[3] ? >>>> >>>> But [1]=[2] remains true, and just as useful for your example. >>>> >>>> >>>> @Max >>>> >>>> I guess to call it a bug, you bumped into a different use case >>>> where [2]=[3] is problematic. Can you describe that? >>> >>> Well, not problematic. Once you accept that neither selector nor class are part of a CompiledMethod it is obvious that two instances with the same byte codes produce the same hash. >>> >>> The actual problem is more one of understanding and use. The following code answers a collection with the CompiledMethods Collection>>add:, Collection>>do: and Collection>>remove:ifAbsent: >>> >>> Collection methods select: #isAbstract. >>> >>> All three CompiledMethods are implemented as â^ self subclassResponsibilityâ, so they have the same byte codes. Now, if you take that collection and make a set out of it youâll lose Collection>>do: since #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because the number of arguments is calculated into the hash (actually the CompiledMethod header is). >> >> Surely the issue is that "aClass methods" should answer an IdentitySet right? > > Well, in the case of my example that wouldnât change anything. As soon as you put the methods into a set youâll end up with less entries than before again. Selectors are unique per class anyway so I donât quite see the benefit of using an IdentitySet over an OrderedCollection (or a Bag for that matter), except for making it more obvious that the result of the message #methods doesnât need to be filtered further. > > I should add that the code, the student who discovered the clash wrote, looked more like this: > > result := Set new. > Collection methods do: [ :m | > m isAbstract ifTrue: [ result add: m ] ]. > > Max > > > Why not just keep a dictionary, like methodDictionary select: #isAbstract or something like thatâ¦ Youâre right of course, thereâs no need to put methods into a set. The code is from an exercise and the students arenât used to Smalltalk, so they end up with all sorts of code. > >> >> >>> So, as long as you think of CompiledMethods as objects that have a name, it looks like a bug and in my opinion this behaviour is something that messes with the mind of newcomers. Just a (silly) idea: something like a CompiledMethodWrapper might solve the problem (at least from the user perspective; everything is slightly different from the VM perspective :) ), as it could hold on to the class and the selector independently of the actual CompiledMethod. >>> >>> In the end however, one doesnât work with compiled methods a lot and the hash situation is unlikely to cause a lot of problems (people working with CompiledMethod usually know what they are doing). >>> >>> Cheers, >>> Max >>> >>>> >>>> >>>> cheers -ben >>>> >>>> >>>>> The blue book say #= means "Answer whether the receiver and the argument >>>>> represent the same component." The current implementation does so only for >>>>> some, in my opinion, counter-intuitive definition of "same component". >>>>> -- >>>>> View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p478… <http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p478…> >>>>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>. >> >> Eliot (phone)

Oct. 17, 2014

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

by Nicolas Cellier

2014-10-17 15:49 GMT+02:00 Max Leske <maxleske(a)gmail.com>: > > On 17.10.2014, at 15:25, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Max, > > On Oct 17, 2014, at 12:34 AM, Max Leske <maxleske(a)gmail.com> wrote: > > > On 17.10.2014, at 02:46, Ben Coman <btc(a)openInWorld.com> wrote: > > Richard Sargent wrote: > > Eliot Miranda-2 wrote > > On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent < > > richard.sargent@ > > wrote: > One of the best things about Smalltalk is how easily we can say what we > mean. I think you would be better off creating a method named something > like > #hasSameEffectAs: to answer what you are presently using #= to do, and > change #= to answer the, in my opinion, more sensible "is the same as" > that > we conventionally think of #= meaning. > > But that's the point. #= has to mean something and having it mean #== > isn't useful, so one has to choose some value-based semantic for > CompiledMethod>>#= and the one that's there is useful. Defining what #= > means for some value type is far easier than defining what it might mean > for something as complex as a CompiledMethod. The definition in > Squeak/Pharo has been useful to me in implementing a closure-based system, > so I'm unapologetic about the current definition. It is a good one but it > doesn't preclude defining others. > > An interesting response. You ignored the point that e.g. #hasSameEffectAs: > provides greater clarity and add an argument against something I didn't > say. > I also don't think defining equality for a CompiledMethod is particularly > difficult. If I were to recompile a method's source code, I would get a new > instance of a CompiledMethod that would, in my opinion, be equal to the one > already installed in the class (and perhaps cached in the VM's > optimizations). So one would be able to say that we would not replace an > existing CompiledMethod with an equal one. The current implementation of #= > has no such characteristic, since it proclaims a CompiledMethod named #a to > be equal to one named #z. > > > @Richard > > That doesn't seem to be a good example for what your trying to say. > Given... > > [1] SomeClass>>a "original instance" > ^1 > > [2] SomeClass>>a "recompiled instance" > ^1 > > [3] SomeClass>>z > ^1 > > ...you seem to be saying that its useful to know if [1]=[2], > but imply that is invalidated by [2]=[3] ? > > But [1]=[2] remains true, and just as useful for your example. > > > @Max > > I guess to call it a bug, you bumped into a different use case > where [2]=[3] is problematic. Can you describe that? > > > Well, not problematic. Once you accept that neither selector nor class are > part of a CompiledMethod it is obvious that two instances with the same > byte codes produce the same hash. > > The actual problem is more one of understanding and use. The following > code answers a collection with the CompiledMethods Collection>>add:, > Collection>>do: and Collection>>remove:ifAbsent: > > Collection methods select: #isAbstract. > > > All three CompiledMethods are implemented as â^ self > subclassResponsibilityâ, so they have the same byte codes. Now, if you take > that collection and make a set out of it youâll lose Collection>>do: since > #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because > the number of arguments is calculated into the hash (actually the > CompiledMethod header is). > > > Surely the issue is that "aClass methods" should answer an IdentitySet > right? > > > Well, in the case of my example that wouldnât change anything. As soon as > you put the methods into a set youâll end up with less entries than before > again. Selectors are unique per class anyway so I donât quite see the > benefit of using an IdentitySet over an OrderedCollection (or a Bag for > that matter), except for making it more obvious that the result of the > message #methods doesnât need to be filtered further. > > I should add that the code, the student who discovered the clash wrote, > looked more like this: > > result := Set new. > Collection methods do: [ :m | > m isAbstract ifTrue: [ result add: m ] ]. > > Max > > Why not just keep a dictionary, like methodDictionary select: #isAbstract or something like that... > > > So, as long as you think of CompiledMethods as objects that have a name, > it looks like a bug and in my opinion this behaviour is something that > messes with the mind of newcomers. Just a (silly) idea: something like a > CompiledMethodWrapper might solve the problem (at least from the user > perspective; everything is slightly different from the VM perspective :) ), > as it could hold on to the class and the selector independently of the > actual CompiledMethod. > > In the end however, one doesnât work with compiled methods a lot and the > hash situation is unlikely to cause a lot of problems (people working with > CompiledMethod usually know what they are doing). > > Cheers, > Max > > > > cheers -ben > > > The blue book say #= means "Answer whether the receiver and the argument > represent the same component." The current implementation does so only for > some, in my opinion, counter-intuitive definition of "same component". > -- > View this message in context: > http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p478… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com <http://nabble.com/>. > > > Eliot (phone) > > >

Oct. 17, 2014

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

by Max Leske

> On 17.10.2014, at 15:25, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Max, > > On Oct 17, 2014, at 12:34 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > >> >>> On 17.10.2014, at 02:46, Ben Coman <btc(a)openInWorld.com <mailto:btc@openInWorld.com>> wrote: >>> >>> Richard Sargent wrote: >>>> Eliot Miranda-2 wrote >>>>> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent < >>>>> richard.sargent@ >>>>>> wrote: >>>>>> One of the best things about Smalltalk is how easily we can say what we >>>>>> mean. I think you would be better off creating a method named something >>>>>> like >>>>>> #hasSameEffectAs: to answer what you are presently using #= to do, and >>>>>> change #= to answer the, in my opinion, more sensible "is the same as" >>>>>> that >>>>>> we conventionally think of #= meaning. >>>>>> >>>>> But that's the point. #= has to mean something and having it mean #== >>>>> isn't useful, so one has to choose some value-based semantic for >>>>> CompiledMethod>>#= and the one that's there is useful. Defining what #= >>>>> means for some value type is far easier than defining what it might mean >>>>> for something as complex as a CompiledMethod. The definition in >>>>> Squeak/Pharo has been useful to me in implementing a closure-based system, >>>>> so I'm unapologetic about the current definition. It is a good one but it >>>>> doesn't preclude defining others. >>>> An interesting response. You ignored the point that e.g. #hasSameEffectAs: >>>> provides greater clarity and add an argument against something I didn't say. >>>> I also don't think defining equality for a CompiledMethod is particularly >>>> difficult. If I were to recompile a method's source code, I would get a new >>>> instance of a CompiledMethod that would, in my opinion, be equal to the one >>>> already installed in the class (and perhaps cached in the VM's >>>> optimizations). So one would be able to say that we would not replace an >>>> existing CompiledMethod with an equal one. The current implementation of #= >>>> has no such characteristic, since it proclaims a CompiledMethod named #a to >>>> be equal to one named #z. >>> >>> @Richard >>> >>> That doesn't seem to be a good example for what your trying to say. >>> Given... >>> >>> [1] SomeClass>>a "original instance" >>> ^1 >>> >>> [2] SomeClass>>a "recompiled instance" >>> ^1 >>> >>> [3] SomeClass>>z >>> ^1 >>> >>> ...you seem to be saying that its useful to know if [1]=[2], >>> but imply that is invalidated by [2]=[3] ? >>> >>> But [1]=[2] remains true, and just as useful for your example. >>> >>> >>> @Max >>> >>> I guess to call it a bug, you bumped into a different use case >>> where [2]=[3] is problematic. Can you describe that? >> >> Well, not problematic. Once you accept that neither selector nor class are part of a CompiledMethod it is obvious that two instances with the same byte codes produce the same hash. >> >> The actual problem is more one of understanding and use. The following code answers a collection with the CompiledMethods Collection>>add:, Collection>>do: and Collection>>remove:ifAbsent: >> >> Collection methods select: #isAbstract. >> >> All three CompiledMethods are implemented as â^ self subclassResponsibilityâ, so they have the same byte codes. Now, if you take that collection and make a set out of it youâll lose Collection>>do: since #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because the number of arguments is calculated into the hash (actually the CompiledMethod header is). > > Surely the issue is that "aClass methods" should answer an IdentitySet right? Well, in the case of my example that wouldnât change anything. As soon as you put the methods into a set youâll end up with less entries than before again. Selectors are unique per class anyway so I donât quite see the benefit of using an IdentitySet over an OrderedCollection (or a Bag for that matter), except for making it more obvious that the result of the message #methods doesnât need to be filtered further. I should add that the code, the student who discovered the clash wrote, looked more like this: result := Set new. Collection methods do: [ :m | m isAbstract ifTrue: [ result add: m ] ]. Max > > >> So, as long as you think of CompiledMethods as objects that have a name, it looks like a bug and in my opinion this behaviour is something that messes with the mind of newcomers. Just a (silly) idea: something like a CompiledMethodWrapper might solve the problem (at least from the user perspective; everything is slightly different from the VM perspective :) ), as it could hold on to the class and the selector independently of the actual CompiledMethod. >> >> In the end however, one doesnât work with compiled methods a lot and the hash situation is unlikely to cause a lot of problems (people working with CompiledMethod usually know what they are doing). >> >> Cheers, >> Max >> >>> >>> >>> cheers -ben >>> >>> >>>> The blue book say #= means "Answer whether the receiver and the argument >>>> represent the same component." The current implementation does so only for >>>> some, in my opinion, counter-intuitive definition of "same component". >>>> -- >>>> View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p478… <http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p478…> >>>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com <http://nabble.com/>. > > Eliot (phone)

Oct. 17, 2014

Re: [Pharo-dev] CompiledMethod>>hash can produce clashes

by Eliot Miranda

Hi Max, On Oct 17, 2014, at 12:34 AM, Max Leske <maxleske(a)gmail.com> wrote: > >> On 17.10.2014, at 02:46, Ben Coman <btc(a)openInWorld.com> wrote: >> >> Richard Sargent wrote: >>> Eliot Miranda-2 wrote >>>> On Wed, Oct 15, 2014 at 10:50 AM, Richard Sargent < >>>> richard.sargent@ >>>>> wrote: >>>>> One of the best things about Smalltalk is how easily we can say what we >>>>> mean. I think you would be better off creating a method named something >>>>> like >>>>> #hasSameEffectAs: to answer what you are presently using #= to do, and >>>>> change #= to answer the, in my opinion, more sensible "is the same as" >>>>> that >>>>> we conventionally think of #= meaning. >>>> But that's the point. #= has to mean something and having it mean #== >>>> isn't useful, so one has to choose some value-based semantic for >>>> CompiledMethod>>#= and the one that's there is useful. Defining what #= >>>> means for some value type is far easier than defining what it might mean >>>> for something as complex as a CompiledMethod. The definition in >>>> Squeak/Pharo has been useful to me in implementing a closure-based system, >>>> so I'm unapologetic about the current definition. It is a good one but it >>>> doesn't preclude defining others. >>> An interesting response. You ignored the point that e.g. #hasSameEffectAs: >>> provides greater clarity and add an argument against something I didn't say. >>> I also don't think defining equality for a CompiledMethod is particularly >>> difficult. If I were to recompile a method's source code, I would get a new >>> instance of a CompiledMethod that would, in my opinion, be equal to the one >>> already installed in the class (and perhaps cached in the VM's >>> optimizations). So one would be able to say that we would not replace an >>> existing CompiledMethod with an equal one. The current implementation of #= >>> has no such characteristic, since it proclaims a CompiledMethod named #a to >>> be equal to one named #z. >> >> @Richard >> >> That doesn't seem to be a good example for what your trying to say. >> Given... >> >> [1] SomeClass>>a "original instance" >> ^1 >> >> [2] SomeClass>>a "recompiled instance" >> ^1 >> >> [3] SomeClass>>z >> ^1 >> >> ...you seem to be saying that its useful to know if [1]=[2], >> but imply that is invalidated by [2]=[3] ? >> >> But [1]=[2] remains true, and just as useful for your example. >> >> >> @Max >> >> I guess to call it a bug, you bumped into a different use case >> where [2]=[3] is problematic. Can you describe that? > > Well, not problematic. Once you accept that neither selector nor class are part of a CompiledMethod it is obvious that two instances with the same byte codes produce the same hash. > > The actual problem is more one of understanding and use. The following code answers a collection with the CompiledMethods Collection>>add:, Collection>>do: and Collection>>remove:ifAbsent: > > Collection methods select: #isAbstract. > > All three CompiledMethods are implemented as â^ self subclassResponsibilityâ, so they have the same byte codes. Now, if you take that collection and make a set out of it youâll lose Collection>>do: since #do: and #add: produce the same hash, but #remove:ifAbsent: doesnât because the number of arguments is calculated into the hash (actually the CompiledMethod header is). Surely the issue is that "aClass methods" should answer an IdentitySet right? > So, as long as you think of CompiledMethods as objects that have a name, it looks like a bug and in my opinion this behaviour is something that messes with the mind of newcomers. Just a (silly) idea: something like a CompiledMethodWrapper might solve the problem (at least from the user perspective; everything is slightly different from the VM perspective :) ), as it could hold on to the class and the selector independently of the actual CompiledMethod. > > In the end however, one doesnât work with compiled methods a lot and the hash situation is unlikely to cause a lot of problems (people working with CompiledMethod usually know what they are doing). > > Cheers, > Max > >> >> >> cheers -ben >> >> >>> The blue book say #= means "Answer whether the receiver and the argument >>> represent the same component." The current implementation does so only for >>> some, in my opinion, counter-intuitive definition of "same component". >>> -- >>> View this message in context: http://forum.world.st/CompiledMethod-hash-can-produce-clashes-tp4784722p478… >>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. Eliot (phone)

Oct. 17, 2014

Re: [Pharo-dev] [squeak-dev] New Spur trunk image available

by Eliot Miranda

Hi Levente, On Oct 17, 2014, at 5:40 AM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Thu, 16 Oct 2014, Eliot Miranda wrote: > >> Hi All, >> finally the Spur Squeak trunk image is updateable. The image in http://www.mirandabanda.org/files/Cog/SpurImages/2014-10-16/ was created today and thanks to Bert Freudenberg's latest Monticello work can >> be updated independently of the non-Spur trunk. Spur VMs are available in http://www.mirandabanda.org/files/Cog/VM/VM.r3105/ (and later as they appear). Without wanting to appear too overconfident the Spur >> system looks to be ready for use apart from image segments (which I hope to have working some time next month). I'm really interested in having this stress tested by as many people as possible. Spur really >> does offer a significant performance and functionality improvement over the current system, but it needs testing to ensure its reliability. > > Great news. > >> Esteban Lorenzano is hard at work on the Pharo bootstrap for Spur so I hope Pharo 4 Spur will be available soon. >> As far as trunk goes, using Spur alongside non-Spur trunk is going to be difficult to manage for the near future. Right now, Spur modifies the Collections, Compiler, Kernel and System packages, and this is >> done by auto-editing the non-Spur versions of those packages, something I do periodically as new versions arrive. I also auto-edit trunk configurations (the part of the image update scheme that ensures >> packages are loaded in the right order when there are dependencies between packages) from non-Spur "update" to Spur "update.spur" forms. This at east means that Spur can keep up with trunk. But it does >> /not/ provide a way of committing to Collections.spur, Compiler.spur, Kernel.spur or System.spur without getting out of sync with non-Spur trunk. Note that apart from these packages, one /can/ safely commit >> any other package from a Spur image to trunk. >> Right now the plan is to release both V3 (the pre-Spur format) and Spur versions of Squeak 4.6 (I hope it'll be called Squeak 5.0). This isn't my preference. I'd like to see just Spur released, once >> reliability is verified. But I understand the safety and backward-compatibility concerns (Spur won't be able to load V3 image segments, and vice verse). The issue is of course that we have this tricky >> package situation to manage where, to keep the two systems in sync, modifications to Collections, Compiler, Kernel and System need to be committed from V3 and auto-edited to Spur. I think that's too clumsy to >> be practicable. Perhaps allowing the two systems to fork and doing a manual merge will be acceptable, but it'll be work to keep them in sync. > > How about releasing the V3 version as Squeak 4.6, and the Spur version as Squeak 5.0 at the same time? > This way we could keep Trunk as is; pushing all changes to Trunk until 4.6 is released, then - leaving V3 behind - use the Trunk for Spur-only. > Then any changes could be backported manually to the future squeak46 repository if needed. Works for me. Good idea! Objections? > Levente > >> -- >> best,Eliot Eliot (phone)

Oct. 17, 2014

Re: [Pharo-dev] [squeak-dev] New Spur trunk image available

by Levente Uzonyi

On Thu, 16 Oct 2014, Eliot Miranda wrote: > Hi All, > Â Â finally the Spur Squeak trunk image is updateable.Â The image inÂ http://www.mirandabanda.org/files/Cog/SpurImages/2014-10-16/ was created today and thanks to Bert Freudenberg's latest Monticello work can > be updated independently of the non-Spur trunk.Â Spur VMs are available inÂ http://www.mirandabanda.org/files/Cog/VM/VM.r3105/ (and later as they appear).Â Without wanting to appear too overconfident the Spur > system looks to be ready for use apart from image segments (which I hope to have working some time next month).Â I'm really interested in having this stress tested by as many people as possible.Â Spur really > does offer a significant performance and functionality improvement over the current system, but it needs testing to ensure its reliability. Great news. > > Esteban Lorenzano is hard at work on the Pharo bootstrap for Spur so I hope Pharo 4 Spur will be available soon. > > As far as trunk goes, using Spur alongside non-Spur trunk is going to be difficult to manage for the near future.Â Right now, Spur modifies the Collections, Compiler, Kernel and System packages, and this is > done by auto-editing the non-Spur versions of those packages, something I do periodically as new versions arrive.Â I also auto-edit trunk configurations (the part of the image update scheme that ensures > packages are loaded in the right order when there are dependencies between packages) from non-Spur "update" to Spur "update.spur" forms.Â This at east means that Spur can keep up with trunk.Â But it does > /not/ provide a way of committing toÂ Collections.spur, Compiler.spur, Kernel.spur or System.spur without getting out of sync with non-Spur trunk.Â Note that apart from these packages, one /can/ safely commit > any other package from a Spur image to trunk. > > Right now the plan is to release both V3 (the pre-Spur format) and Spur versions of Squeak 4.6 (I hope it'll be called Squeak 5.0).Â This isn't my preference.Â I'd like to see just Spur released, once > reliability is verified.Â But I understand the safety and backward-compatibility concerns (Spur won't be able to load V3 image segments, and vice verse).Â The issue is of course that we have this tricky > package situation to manage where, to keep the two systems in sync, modifications to Collections, Compiler, Kernel and System need to be committed from V3 and auto-edited to Spur. I think that's too clumsy to > be practicable.Â Perhaps allowing the two systems to fork and doing a manual merge will be acceptable, but it'll be work to keep them in sync. How about releasing the V3 version as Squeak 4.6, and the Spur version as Squeak 5.0 at the same time? This way we could keep Trunk as is; pushing all changes to Trunk until 4.6 is released, then - leaving V3 behind - use the Trunk for Spur-only. Then any changes could be backported manually to the future squeak46 repository if needed. Levente > -- > best,Eliot > >

Oct. 17, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] cd6a30: 40310

by Marcus Denker

--Â Marcus Denker Sent with Airmail On 17 Oct 2014 at 12:46:28, Esteban Lorenzano (estebanlm(a)gmail.com) wrote: that i donât know.Â the change is already there or the slice is actually empty.Â nothing to do with the app, in that case :) But I checked: the Slices did show me content when I reviewed them, these change are *not* there, yet, the merge is empty. Esteban On 17 Oct 2014, at 12:28, Marcus Denker <marcus.denker(a)inria.fr> wrote: On 17 Oct 2014, at 12:21, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: that means most probably a merge conflict (still not handled by new integrator app).Â Sorry, I will fix it soon :) But I wonder why when I merge the not-integrated slices, it claims that there is no change? Esteban On 17 Oct 2014, at 12:19, Marcus Denker <marcus.denker(a)inria.fr> wrote: We will have to revert this. -> the changes are not there -> yet when I merge the Slice it claims there are no changes. -> So we have to revert. On Fri, Oct 17, 2014 at 11:56 AM, GitHub <noreply(a)github.com> wrote: Â Branch: refs/heads/4.0 Â Home:Â Â https://github.com/pharo-project/pharo-core Â Commit: cd6a3036bde6d73d3e2502aca8caacaac75dc1db Â Â Â https://github.com/pharo-project/pharo-core/commit/cd6a3036bde6d73d3e2502ac… Â Author: Jenkins Build Server <board(a)pharo-project.org> Â Date:Â Â 2014-10-17 (Fri, 17 Oct 2014) Â Changed paths: Â Â A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script310.st Â Â A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40310.st Â Â M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Â Log Message: Â ----------- Â 40310 14246 CompiledMethod>>hash can produce clashes Â Â Â Â https://pharo.fogbugz.com/f/cases/14246 14257 Replace Announcer>>#on:send:to:s senders in NativeBoost-Core Â Â Â Â https://pharo.fogbugz.com/f/cases/14257 14253 MC dependency warning should name which package is failing to load Â Â Â Â https://pharo.fogbugz.com/f/cases/14253 http://files.pharo.org/image/40/40310.zip -- -- Marcus DenkerÂ --Â denker(a)acm.org http://www.marcusdenker.de

Oct. 17, 2014