- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

Oct. 17, 2014

[pharo-project/pharo-core] cd6a30: 40310

by GitHub

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

Oct. 17, 2014

Re: [Pharo-dev] PharoNOS

by Pavel Krivanek

Here's the image: https://drive.google.com/file/d/0BzSsmZhqtUTeaURYRnA0eHgycXM/view?usp=shari… 2014-10-17 11:47 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Hi, > > do you plan to develop it as a plugin? When I played with TinyCore > Linux and Pharo (using framebuffer), I directly applied required the > plugins on the filesystem. > > -- Pavel > > 2014-10-17 11:09 GMT+02:00 Torsten Bergmann <astares(a)gmx.de>: >> Hi Mike, >> >> tried to swap the image using the following procedure: >> >> 1. Run the following code to download latest Pharo 4.0 >> >> ZnClient new >> url: 'http://files.pharo.org/image/40/latest.zip'; >> downloadTo: '/mnt/universe/pharo-image/latest.zip'. >> ZipArchive extractAllIn: '/mnt/universe/pharo-image/latest.zip'. >> >> and extract to "/mnt/universe/pharo-image/" >> >> 2. Now I wanted to change /mnt/universe/image file name >> to point to the new image. Unfortunately I can not write or delete/recreate >> this file from Pharo's file browser. >> >> Can you provide the build script for the ISO also on GitHub? >> >> Thx >> T. >>

Oct. 17, 2014

[Ann] Phratch 4.0

by jannik laval

Phratch 4.0 is out of the box ! Phratch 4.0 is cleaner, faster and more stable than phratch 3.0. After the version 3.0 that was a release for usability and stability, phratch 4.0 is released to prepare the future. The new features are: - phratch is more modular, eg having a kernel and lots of addons. - cleaning a lot the source code - customizable environment - each block can be made visible or invisible - each category can be made visible or invisible - it is possible to add translation for addons with the pragma <phratchTranslation: âfrâ> in the class PhratchTranslator. This make the translation more modular. - first integration of phratch with the pharo environment. Using the pragma at the class side of any class in Pharo make the class visible and usable in phratch. - There is a lot of things to do with phratch, you are welcome to contribute ! The documentation for new features will arrive soon. See you on phratch.com -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info http://car.mines-douai.fr/

Oct. 17, 2014

Re: [Pharo-dev] PharoNOS

by Denis Kudriashov

If SqueakNOS wil continued and moved to Pharo this name (PharoNOS) should be free. Maybe this project should be renamed? PharoLinux? Anyway great job. I remember many yeas ago squeak had similar project by some japanese guy 2014-10-17 12:39 GMT+04:00 Rafael Luque <rafael.luque.leiva(a)gmail.com>: > Then, PharoNOS does not mean No Operating System, but minimun operating > system? > > A few days ago I answered in this list about Smalltalk-based unikernels, > similar to Mirage OS (http://www.openmirage.org/) > > Do you think PharoNOS can evolve into this kind of tool? > > > > 2014-10-17 10:28 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > >> I see, I dont have experience with TinyCore linux, but I do have >> experience with puppy linux which I really liked and used several times on >> my older pcs. Interest concept , good work :) >> >> Actually puppy linux is similar to what you do, in the sense that it uses >> its own programming language , genie >> >> >> https://wiki.gnome.org/action/show/Projects/Genie?action=show&redirect=Genie >> >> On Fri, Oct 17, 2014 at 10:59 AM, mikefilonov <mikefilonov(a)gmail.com> >> wrote: >> >>> Yes, the idea of PharoNOS is to have the Smalltalk-only environment with >>> as >>> little external stuff as possible. >>> >>> Current PharoNOS implementation based on TinyCore Linux - the smallest >>> Linux >>> distro - in order to have the smallest possible system footprint. >>> >>> >Why not just download a small linux distro and install Pharo ? >>> >>> Well, basically this what PharoNOS is :) >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/PharoNOS-tp4784982p4785089.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at >>> Nabble.com. >>> >>> >> >

Oct. 17, 2014

Re: [Pharo-dev] PharoNOS

by Pavel Krivanek

Hi, do you plan to develop it as a plugin? When I played with TinyCore Linux and Pharo (using framebuffer), I directly applied required the plugins on the filesystem. -- Pavel 2014-10-17 11:09 GMT+02:00 Torsten Bergmann <astares(a)gmx.de>: > Hi Mike, > > tried to swap the image using the following procedure: > > 1. Run the following code to download latest Pharo 4.0 > > ZnClient new > url: 'http://files.pharo.org/image/40/latest.zip'; > downloadTo: '/mnt/universe/pharo-image/latest.zip'. > ZipArchive extractAllIn: '/mnt/universe/pharo-image/latest.zip'. > > and extract to "/mnt/universe/pharo-image/" > > 2. Now I wanted to change /mnt/universe/image file name > to point to the new image. Unfortunately I can not write or delete/recreate > this file from Pharo's file browser. > > Can you provide the build script for the ISO also on GitHub? > > Thx > T. >

Oct. 17, 2014

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

by Max Leske

> On 17.10.2014, at 11:39, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 17 Oct 2014, at 11:12, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Exactly. So, the problem with Set is not in hash at all, but in equality. Of course, we can still enhance hash, but we should first focus on equality. >> >> And I am also of the opinion that equality should take the name of the selector and even the name of the class into account. > > From a modelling standpoint it sounds as if one object (CompiledMethod) is used for two different things which results in the conflicting ideas about implementing equality and hashing. A CompiledMethod should hold a CompiledCode object while adding the selector and class. The CompiledCode object could then be equivalent or even be optionally shared among similar methods (like all those implementing ^self). > > Just an external observation / idea. Yes, pretty much what I was thinking. I donât know what the consequences would be for the VM though... > >> Doru >> >> On Fri, Oct 17, 2014 at 9:52 AM, Max Leske <maxleske(a)gmail.com> wrote: >> >>> On 17.10.2014, at 09:37, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> But why is Set being affected by hash? Hash is never guaranteed to be unique. Set should be affected by equality. >> >> Well, actually itâs both #hash and #=. First the set tries to find a suitable place for the element using the elements hash. If that place is already taken it then checks equality. Since the equality definition is mostly the same (same literals, same byte codes etc.), the second element is rejected because itâs already in the set. >> >>> >>> Doru >>> >>> On Fri, Oct 17, 2014 at 9: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). >>> >>> 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. >>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > >

Oct. 17, 2014

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

by Max Leske

> On 17.10.2014, at 11:12, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Exactly. So, the problem with Set is not in hash at all, but in equality. Of course, we can still enhance hash, but we should first focus on equality. > > And I am also of the opinion that equality should take the name of the selector and even the name of the class into account. Did you read Eliotâs argument? He needs the equality definition to find duplicates. I donât agree with you (anymore). The selector and the class are simply associated with a given CompiledMethod. But the CompiledMethod is still one without a name and without a class it is installed in. From that point of view, neither the class nor the selector should be included in the definition of equality. I do agree however, that it kind of goes against the way programmers tend to think of methods, thus my idea (which I did not think through at all) to have something like CompiledMethodWrapper, that lets CompiledMethod be what it is and abstracts the object for use with class and selector (see my answer to Benâs e-mail). Cheers, Max > > Doru > > On Fri, Oct 17, 2014 at 9:52 AM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > >> On 17.10.2014, at 09:37, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: >> >> But why is Set being affected by hash? Hash is never guaranteed to be unique. Set should be affected by equality. > > Well, actually itâs both #hash and #=. First the set tries to find a suitable place for the element using the elements hash. If that place is already taken it then checks equality. Since the equality definition is mostly the same (same literals, same byte codes etc.), the second element is rejected because itâs already in the set. > >> >> Doru >> >> On Fri, Oct 17, 2014 at 9: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). >> >> 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/>. >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com/> >> >> "Every thing has its own flow" > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

Oct. 17, 2014

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

by Sven Van Caekenberghe

On 17 Oct 2014, at 11:12, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Exactly. So, the problem with Set is not in hash at all, but in equality. Of course, we can still enhance hash, but we should first focus on equality. > > And I am also of the opinion that equality should take the name of the selector and even the name of the class into account. >From a modelling standpoint it sounds as if one object (CompiledMethod) is used for two different things which results in the conflicting ideas about implementing equality and hashing. A CompiledMethod should hold a CompiledCode object while adding the selector and class. The CompiledCode object could then be equivalent or even be optionally shared among similar methods (like all those implementing ^self). Just an external observation / idea. > Doru > > On Fri, Oct 17, 2014 at 9:52 AM, Max Leske <maxleske(a)gmail.com> wrote: > >> On 17.10.2014, at 09:37, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> But why is Set being affected by hash? Hash is never guaranteed to be unique. Set should be affected by equality. > > Well, actually itâs both #hash and #=. First the set tries to find a suitable place for the element using the elements hash. If that place is already taken it then checks equality. Since the equality definition is mostly the same (same literals, same byte codes etc.), the second element is rejected because itâs already in the set. > >> >> Doru >> >> On Fri, Oct 17, 2014 at 9: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). >> >> 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. >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Oct. 17, 2014

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

by Tudor Girba

Exactly. So, the problem with Set is not in hash at all, but in equality. Of course, we can still enhance hash, but we should first focus on equality. And I am also of the opinion that equality should take the name of the selector and even the name of the class into account. Doru On Fri, Oct 17, 2014 at 9:52 AM, Max Leske <maxleske(a)gmail.com> wrote: > > On 17.10.2014, at 09:37, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > But why is Set being affected by hash? Hash is never guaranteed to be > unique. Set should be affected by equality. > > > Well, actually itâs both #hash and #=. First the set tries to find a > suitable place for the element using the elements hash. If that place is > already taken it then checks equality. Since the equality definition is > mostly the same (same literals, same byte codes etc.), the second element > is rejected because itâs already in the set. > > > Doru > > On Fri, Oct 17, 2014 at 9: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). >> >> 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/>. >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 17, 2014