November 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] SortedCollection>>=

by HernÃ¡n Morales Durand

You should ask Norberto Manzanos, he implemented an IdentitySolver which mitigates the lack of these "philosophical" objects in Smalltalk. Besides he has real experience working with objects difficult to identify and compare. I don't think he's willing to share it with the Pharo community, but who knows... Cheers, HernÃ¡n El 19/11/2012 21:20, Hernan Wilkinson escribiÃ³: > I think the problem is related to the fact that different objects can > represent the same thing, as 1/2 that represents the same "final" number > as 2/4, but you could also say that they are different, or 1 meter and > 100 centimeters and different measures that represent the same distance, > and so on. > So, an empty collection represents an empty collection no matter if it > is a sorted one or not, and a SortedCollection with 1, 2 and 3 and > sortblock a SortedCollection with 1, 2 and 3 and block a<=b. > The problem is that the message #= is not enough. We should have more > messages to represent the different "equivalent relationship" where > equality is one of it. For example, one message could be > #representsSameEntityAs: where 1 meter and 100 centimeter would return > true, but 1 meter = 100 centimiter would return false (but I would not > use the #= message for that, it is confusing). > > Anyway, going back to the current problem, it is my opinion that with > the current implementation of BlockClosure>>#= I would change how > SortedCollection>>#= is implemented and use super #= > implementation, because currently ((SortedCollection sortBlock: [:a :b | > a :b | a really really astonishing.... and least in other smalltalks returns true. > > Hernan. > > > On Mon, Nov 19, 2012 at 8:27 PM, Camillo Bruni <camillobruni(a)gmail.com > <mailto:camillobruni@gmail.com>> wrote: > > maybe I am just too naive, but to me this equality check is fairly > simple: > > - compare inner collection > - compare block > > now of course we don't have a block compare, so I wrote a simple > approximation: > > - compare block args / temp size > - compare temps > - compare block byte codes > - check if the blocks are Clean (no outside references) > > in this case it is pretty safe to assume that the blocks are equal. > > On 2012-11-19, at 20:15, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com > <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote: > > > Certainly, but whether this behavior was designed on purpose or > > casually due to difficulty of implementing closure equality is > hard to > > tell. > > > > Even, with a "better" implementation of block closure, the notion of > > equality is not that clear... > > For example take > > (SortedCollection sortBlock: [:a :b l a < b]) = (SortedCollection > > sortBlock: [:a :b l b > a]). > > It might well answer false, even if they will sort any Interval > the same. > > > > What I wanted to emphasize was more "is there a natural/canocical > > definition of object equality" > > If yes, I'm very interested, but I don't think so. > > If not, then we happen to have a collection of arbitrary definitions > > of equality. > > So, the question whether one definition is better than the other is > > difficult to answer. > > That's what I call interesting. > > I doubt we have explicit rationale, well written tests or > standards (I > > didn't check ANSI) specifying the behaviour... > > We just have principles of least astonishment and principles of > > utility (is it used in the image, is it vital, etc...). > > > > Nicolas > > > > 2012/11/19 Frank Shearar <frank.shearar(a)gmail.com > <mailto:frank.shearar@gmail.com>>: > >> I would guess because there is no general equality for anonymous > functions. > >> If the two collections used the same block (as opposed to > equivalent blocks) > >> I'd expect them to be =. > >> > >> frank > >> > >> On 19 Nov 2012, at 21:59, Hernan Wilkinson > <hernan.wilkinson(a)10pines.com <mailto:hernan.wilkinson@10pines.com>> > >> wrote: > >> > >> Interesting... > >> > >> But then why (SortedCollection sortBlock: [ :a :b | a >> (SortedCollection sortBlock: [ :a :b | a >> > >> Hernan > >> > >> > >> On Mon, Nov 19, 2012 at 5:54 PM, Nicolas Cellier > >> <nicolas.cellier.aka.nice(a)gmail.com > <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote: > >>> > >>> Interesting... > >>> > >>> We could ask such questions too with definition of > >>> - Heap equality (since they are partially sorted...) > >>> (Heap withAll: (1 to: 10) asArray) = (Heap withAll: (1 to: 10) > >>> asArray shuffled). > >>> - Interval equality, could you tell me which one is true? > >>> (3 to: 2) = (2 to: 1). > >>> (1 to: 7 by: 2) = (1 to: 8 by: 2). > >>> (1 to: 2 by: 2) = (1 to: 2 by: 3). > >>> > >>> Nicolas > >>> > >>> 2012/11/19 Hernan Wilkinson <hernan.wilkinson(a)10pines.com > <mailto:hernan.wilkinson@10pines.com>>: > >>>> Hi, > >>>> I'm a little surprised with the current SortedCollection #= > >>>> implementation... it is: > >>>> > >>>> = aSortedCollection > >>>> "Answer true if my and aSortedCollection's species are the same, > >>>> and if our blocks are the same, and if our elements are the same." > >>>> > >>>> self species = aSortedCollection species ifFalse: [^ false]. > >>>> sortBlock = aSortedCollection sortBlock > >>>> ifTrue: [^ super = aSortedCollection] > >>>> ifFalse: [^ false] > >>>> > >>>> and my surprise is because it compares the sortBlocks that > makes the > >>>> simplest case to fail like this one: > >>>> > >>>> (SortedCollection sortBlock: [ :a :b | a (SortedCollection > >>>> sortBlock: [ :a :b | a >>>> > >>>> One could argue that if we remove the sortBlock comparison then : > >>>> > >>>> (SortedCollection sortBlock: [ :a :b | a (SortedCollection > >>>> sortBlock: [ :a :b | a > b ]) > >>>> > >>>> would return true... but is that wrong? ... or is the > philosophy to use > >>>> the > >>>> message #hasEqualElements: on this cases? > >>>> > >>>> BTW, VisualWorks implementation is the same as pharo, but the > >>>> BlockClosure>>= is different and that's why it works as at least I > >>>> expected > >>>> :-) > >>>> > >>>> Bye, > >>>> Hernan > >>>> > >>>> -- > >>>> HernÃ¡n Wilkinson > >>>> Agile Software Development, Teaching & Coaching > >>>> Phone: +54 - 011 - 6091 - 3125 > >>>> Mobile: +54 - 911 - 4470 - 7207 > >>>> email: hernan.wilkinson(a)10Pines.com > >>>> site: http://www.10Pines.com > >>>> Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > >>>> > >>> > >> > >> > >> > >> -- > >> HernÃ¡n Wilkinson > >> Agile Software Development, Teaching & Coaching > >> Phone: +54 - 011 - 6091 - 3125 > >> Mobile: +54 - 911 - 4470 - 7207 > >> email: hernan.wilkinson(a)10Pines.com > >> site: http://www.10Pines.com > >> Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > >> > > > > > > > > -- > *HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching* > *Phone: +54 - 011 - *6091 - 3125* > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com <http://www.10pines.com/>* > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina >

Nov. 20, 2012

Re: [Pharo-project] SortedCollection>>=

by Hernan Wilkinson

I think the problem is related to the fact that different objects can represent the same thing, as 1/2 that represents the same "final" number as 2/4, but you could also say that they are different, or 1 meter and 100 centimeters and different measures that represent the same distance, and so on. So, an empty collection represents an empty collection no matter if it is a sorted one or not, and a SortedCollection with 1, 2 and 3 and sortblock a<b represents the same collection of elements as a SortedCollection with 1, 2 and 3 and block a<=b. The problem is that the message #= is not enough. We should have more messages to represent the different "equivalent relationship" where equality is one of it. For example, one message could be #representsSameEntityAs: where 1 meter and 100 centimeter would return true, but 1 meter = 100 centimiter would return false (but I would not use the #= message for that, it is confusing). Anyway, going back to the current problem, it is my opinion that with the current implementation of BlockClosure>>#= I would change how SortedCollection>>#= is implemented and use super #= implementation, because currently ((SortedCollection sortBlock: [:a :b | a < b ]) add: 1; add: 2; yourself) = ((SortedCollection sortBlock: [:a :b | a < b ]) add: 1; add: 2; yourself) returns false that is really really astonishing.... and least in other smalltalks returns true. Hernan. On Mon, Nov 19, 2012 at 8:27 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > maybe I am just too naive, but to me this equality check is fairly simple: > > - compare inner collection > - compare block > > now of course we don't have a block compare, so I wrote a simple > approximation: > > - compare block args / temp size > - compare temps > - compare block byte codes > - check if the blocks are Clean (no outside references) > > in this case it is pretty safe to assume that the blocks are equal. > > On 2012-11-19, at 20:15, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > Certainly, but whether this behavior was designed on purpose or > > casually due to difficulty of implementing closure equality is hard to > > tell. > > > > Even, with a "better" implementation of block closure, the notion of > > equality is not that clear... > > For example take > > (SortedCollection sortBlock: [:a :b l a < b]) = (SortedCollection > > sortBlock: [:a :b l b > a]). > > It might well answer false, even if they will sort any Interval the same. > > > > What I wanted to emphasize was more "is there a natural/canocical > > definition of object equality" > > If yes, I'm very interested, but I don't think so. > > If not, then we happen to have a collection of arbitrary definitions > > of equality. > > So, the question whether one definition is better than the other is > > difficult to answer. > > That's what I call interesting. > > I doubt we have explicit rationale, well written tests or standards (I > > didn't check ANSI) specifying the behaviour... > > We just have principles of least astonishment and principles of > > utility (is it used in the image, is it vital, etc...). > > > > Nicolas > > > > 2012/11/19 Frank Shearar <frank.shearar(a)gmail.com>: > >> I would guess because there is no general equality for anonymous > functions. > >> If the two collections used the same block (as opposed to equivalent > blocks) > >> I'd expect them to be =. > >> > >> frank > >> > >> On 19 Nov 2012, at 21:59, Hernan Wilkinson < > hernan.wilkinson(a)10pines.com> > >> wrote: > >> > >> Interesting... > >> > >> But then why (SortedCollection sortBlock: [ :a :b | a >> (SortedCollection sortBlock: [ :a :b | a >> > >> Hernan > >> > >> > >> On Mon, Nov 19, 2012 at 5:54 PM, Nicolas Cellier > >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >>> > >>> Interesting... > >>> > >>> We could ask such questions too with definition of > >>> - Heap equality (since they are partially sorted...) > >>> (Heap withAll: (1 to: 10) asArray) = (Heap withAll: (1 to: 10) > >>> asArray shuffled). > >>> - Interval equality, could you tell me which one is true? > >>> (3 to: 2) = (2 to: 1). > >>> (1 to: 7 by: 2) = (1 to: 8 by: 2). > >>> (1 to: 2 by: 2) = (1 to: 2 by: 3). > >>> > >>> Nicolas > >>> > >>> 2012/11/19 Hernan Wilkinson <hernan.wilkinson(a)10pines.com>: > >>>> Hi, > >>>> I'm a little surprised with the current SortedCollection #= > >>>> implementation... it is: > >>>> > >>>> = aSortedCollection > >>>> "Answer true if my and aSortedCollection's species are the same, > >>>> and if our blocks are the same, and if our elements are the same." > >>>> > >>>> self species = aSortedCollection species ifFalse: [^ false]. > >>>> sortBlock = aSortedCollection sortBlock > >>>> ifTrue: [^ super = aSortedCollection] > >>>> ifFalse: [^ false] > >>>> > >>>> and my surprise is because it compares the sortBlocks that makes the > >>>> simplest case to fail like this one: > >>>> > >>>> (SortedCollection sortBlock: [ :a :b | a >>>> sortBlock: [ :a :b | a >>>> > >>>> One could argue that if we remove the sortBlock comparison then : > >>>> > >>>> (SortedCollection sortBlock: [ :a :b | a >>>> sortBlock: [ :a :b | a > b ]) > >>>> > >>>> would return true... but is that wrong? ... or is the philosophy to > use > >>>> the > >>>> message #hasEqualElements: on this cases? > >>>> > >>>> BTW, VisualWorks implementation is the same as pharo, but the > >>>> BlockClosure>>= is different and that's why it works as at least I > >>>> expected > >>>> :-) > >>>> > >>>> Bye, > >>>> Hernan > >>>> > >>>> -- > >>>> HernÃ¡n Wilkinson > >>>> Agile Software Development, Teaching & Coaching > >>>> Phone: +54 - 011 - 6091 - 3125 > >>>> Mobile: +54 - 911 - 4470 - 7207 > >>>> email: hernan.wilkinson(a)10Pines.com > >>>> site: http://www.10Pines.com > >>>> Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > >>>> > >>> > >> > >> > >> > >> -- > >> HernÃ¡n Wilkinson > >> Agile Software Development, Teaching & Coaching > >> Phone: +54 - 011 - 6091 - 3125 > >> Mobile: +54 - 911 - 4470 - 7207 > >> email: hernan.wilkinson(a)10Pines.com > >> site: http://www.10Pines.com > >> Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > >> > > > > > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching* *Phone: +54 - 011 - *6091 - 3125* Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Alem 693, Floor 5 B, Buenos Aires, Argentina

Nov. 20, 2012

Re: [Pharo-project] SortedCollection>>=

by Camillo Bruni

maybe I am just too naive, but to me this equality check is fairly simple: - compare inner collection - compare block now of course we don't have a block compare, so I wrote a simple approximation: - compare block args / temp size - compare temps - compare block byte codes - check if the blocks are Clean (no outside references) in this case it is pretty safe to assume that the blocks are equal. On 2012-11-19, at 20:15, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Certainly, but whether this behavior was designed on purpose or > casually due to difficulty of implementing closure equality is hard to > tell. > > Even, with a "better" implementation of block closure, the notion of > equality is not that clear... > For example take > (SortedCollection sortBlock: [:a :b l a < b]) = (SortedCollection > sortBlock: [:a :b l b > a]). > It might well answer false, even if they will sort any Interval the same. > > What I wanted to emphasize was more "is there a natural/canocical > definition of object equality" > If yes, I'm very interested, but I don't think so. > If not, then we happen to have a collection of arbitrary definitions > of equality. > So, the question whether one definition is better than the other is > difficult to answer. > That's what I call interesting. > I doubt we have explicit rationale, well written tests or standards (I > didn't check ANSI) specifying the behaviour... > We just have principles of least astonishment and principles of > utility (is it used in the image, is it vital, etc...). > > Nicolas > > 2012/11/19 Frank Shearar <frank.shearar(a)gmail.com>: >> I would guess because there is no general equality for anonymous functions. >> If the two collections used the same block (as opposed to equivalent blocks) >> I'd expect them to be =. >> >> frank >> >> On 19 Nov 2012, at 21:59, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> >> wrote: >> >> Interesting... >> >> But then why (SortedCollection sortBlock: [ :a :b | a > (SortedCollection sortBlock: [ :a :b | a > >> Hernan >> >> >> On Mon, Nov 19, 2012 at 5:54 PM, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>> Interesting... >>> >>> We could ask such questions too with definition of >>> - Heap equality (since they are partially sorted...) >>> (Heap withAll: (1 to: 10) asArray) = (Heap withAll: (1 to: 10) >>> asArray shuffled). >>> - Interval equality, could you tell me which one is true? >>> (3 to: 2) = (2 to: 1). >>> (1 to: 7 by: 2) = (1 to: 8 by: 2). >>> (1 to: 2 by: 2) = (1 to: 2 by: 3). >>> >>> Nicolas >>> >>> 2012/11/19 Hernan Wilkinson <hernan.wilkinson(a)10pines.com>: >>>> Hi, >>>> I'm a little surprised with the current SortedCollection #= >>>> implementation... it is: >>>> >>>> = aSortedCollection >>>> "Answer true if my and aSortedCollection's species are the same, >>>> and if our blocks are the same, and if our elements are the same." >>>> >>>> self species = aSortedCollection species ifFalse: [^ false]. >>>> sortBlock = aSortedCollection sortBlock >>>> ifTrue: [^ super = aSortedCollection] >>>> ifFalse: [^ false] >>>> >>>> and my surprise is because it compares the sortBlocks that makes the >>>> simplest case to fail like this one: >>>> >>>> (SortedCollection sortBlock: [ :a :b | a >>> sortBlock: [ :a :b | a >>> >>>> One could argue that if we remove the sortBlock comparison then : >>>> >>>> (SortedCollection sortBlock: [ :a :b | a >>> sortBlock: [ :a :b | a > b ]) >>>> >>>> would return true... but is that wrong? ... or is the philosophy to use >>>> the >>>> message #hasEqualElements: on this cases? >>>> >>>> BTW, VisualWorks implementation is the same as pharo, but the >>>> BlockClosure>>= is different and that's why it works as at least I >>>> expected >>>> :-) >>>> >>>> Bye, >>>> Hernan >>>> >>>> -- >>>> HernÃ¡n Wilkinson >>>> Agile Software Development, Teaching & Coaching >>>> Phone: +54 - 011 - 6091 - 3125 >>>> Mobile: +54 - 911 - 4470 - 7207 >>>> email: hernan.wilkinson(a)10Pines.com >>>> site: http://www.10Pines.com >>>> Address: Alem 693, Floor 5 B, Buenos Aires, Argentina >>>> >>> >> >> >> >> -- >> HernÃ¡n Wilkinson >> Agile Software Development, Teaching & Coaching >> Phone: +54 - 011 - 6091 - 3125 >> Mobile: +54 - 911 - 4470 - 7207 >> email: hernan.wilkinson(a)10Pines.com >> site: http://www.10Pines.com >> Address: Alem 693, Floor 5 B, Buenos Aires, Argentina >> >

Nov. 19, 2012

Re: [Pharo-project] SortedCollection>>=

by Nicolas Cellier

Certainly, but whether this behavior was designed on purpose or casually due to difficulty of implementing closure equality is hard to tell. Even, with a "better" implementation of block closure, the notion of equality is not that clear... For example take (SortedCollection sortBlock: [:a :b l a < b]) = (SortedCollection sortBlock: [:a :b l b > a]). It might well answer false, even if they will sort any Interval the same. What I wanted to emphasize was more "is there a natural/canocical definition of object equality" If yes, I'm very interested, but I don't think so. If not, then we happen to have a collection of arbitrary definitions of equality. So, the question whether one definition is better than the other is difficult to answer. That's what I call interesting. I doubt we have explicit rationale, well written tests or standards (I didn't check ANSI) specifying the behaviour... We just have principles of least astonishment and principles of utility (is it used in the image, is it vital, etc...). Nicolas 2012/11/19 Frank Shearar <frank.shearar(a)gmail.com>: > I would guess because there is no general equality for anonymous functions. > If the two collections used the same block (as opposed to equivalent blocks) > I'd expect them to be =. > > frank > > On 19 Nov 2012, at 21:59, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> > wrote: > > Interesting... > > But then why (SortedCollection sortBlock: [ :a :b | a (SortedCollection sortBlock: [ :a :b | a > Hernan > > > On Mon, Nov 19, 2012 at 5:54 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> Interesting... >> >> We could ask such questions too with definition of >> - Heap equality (since they are partially sorted...) >> (Heap withAll: (1 to: 10) asArray) = (Heap withAll: (1 to: 10) >> asArray shuffled). >> - Interval equality, could you tell me which one is true? >> (3 to: 2) = (2 to: 1). >> (1 to: 7 by: 2) = (1 to: 8 by: 2). >> (1 to: 2 by: 2) = (1 to: 2 by: 3). >> >> Nicolas >> >> 2012/11/19 Hernan Wilkinson <hernan.wilkinson(a)10pines.com>: >> > Hi, >> > I'm a little surprised with the current SortedCollection #= >> > implementation... it is: >> > >> > = aSortedCollection >> > "Answer true if my and aSortedCollection's species are the same, >> > and if our blocks are the same, and if our elements are the same." >> > >> > self species = aSortedCollection species ifFalse: [^ false]. >> > sortBlock = aSortedCollection sortBlock >> > ifTrue: [^ super = aSortedCollection] >> > ifFalse: [^ false] >> > >> > and my surprise is because it compares the sortBlocks that makes the >> > simplest case to fail like this one: >> > >> > (SortedCollection sortBlock: [ :a :b | a > > sortBlock: [ :a :b | a > > >> > One could argue that if we remove the sortBlock comparison then : >> > >> > (SortedCollection sortBlock: [ :a :b | a > > sortBlock: [ :a :b | a > b ]) >> > >> > would return true... but is that wrong? ... or is the philosophy to use >> > the >> > message #hasEqualElements: on this cases? >> > >> > BTW, VisualWorks implementation is the same as pharo, but the >> > BlockClosure>>= is different and that's why it works as at least I >> > expected >> > :-) >> > >> > Bye, >> > Hernan >> > >> > -- >> > HernÃ¡n Wilkinson >> > Agile Software Development, Teaching & Coaching >> > Phone: +54 - 011 - 6091 - 3125 >> > Mobile: +54 - 911 - 4470 - 7207 >> > email: hernan.wilkinson(a)10Pines.com >> > site: http://www.10Pines.com >> > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina >> > >> > > > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Phone: +54 - 011 - 6091 - 3125 > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina >

Nov. 19, 2012

Re: [Pharo-project] SortedCollection>>=

by Frank Shearar

I would guess because there is no general equality for anonymous functions. If the two collections used the same block (as opposed to equivalent blocks) I'd expect them to be =. frank On 19 Nov 2012, at 21:59, Hernan Wilkinson <hernan.wilkinson(a)10pines.com> wrote: > Interesting... > > But then why (SortedCollection sortBlock: [ :a :b | a > Hernan > > > On Mon, Nov 19, 2012 at 5:54 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Interesting... > > We could ask such questions too with definition of > - Heap equality (since they are partially sorted...) > (Heap withAll: (1 to: 10) asArray) = (Heap withAll: (1 to: 10) > asArray shuffled). > - Interval equality, could you tell me which one is true? > (3 to: 2) = (2 to: 1). > (1 to: 7 by: 2) = (1 to: 8 by: 2). > (1 to: 2 by: 2) = (1 to: 2 by: 3). > > Nicolas > > 2012/11/19 Hernan Wilkinson <hernan.wilkinson(a)10pines.com>: > > Hi, > > I'm a little surprised with the current SortedCollection #= > > implementation... it is: > > > > = aSortedCollection > > "Answer true if my and aSortedCollection's species are the same, > > and if our blocks are the same, and if our elements are the same." > > > > self species = aSortedCollection species ifFalse: [^ false]. > > sortBlock = aSortedCollection sortBlock > > ifTrue: [^ super = aSortedCollection] > > ifFalse: [^ false] > > > > and my surprise is because it compares the sortBlocks that makes the > > simplest case to fail like this one: > > > > (SortedCollection sortBlock: [ :a :b | a > sortBlock: [ :a :b | a > > > One could argue that if we remove the sortBlock comparison then : > > > > (SortedCollection sortBlock: [ :a :b | a > sortBlock: [ :a :b | a > b ]) > > > > would return true... but is that wrong? ... or is the philosophy to use the > > message #hasEqualElements: on this cases? > > > > BTW, VisualWorks implementation is the same as pharo, but the > > BlockClosure>>= is different and that's why it works as at least I expected > > :-) > > > > Bye, > > Hernan > > > > -- > > HernÃ¡n Wilkinson > > Agile Software Development, Teaching & Coaching > > Phone: +54 - 011 - 6091 - 3125 > > Mobile: +54 - 911 - 4470 - 7207 > > email: hernan.wilkinson(a)10Pines.com > > site: http://www.10Pines.com > > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > > > > > > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Phone: +54 - 011 - 6091 - 3125 > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina >

Nov. 19, 2012

Re: [Pharo-project] SortedCollection>>=

by Hernan Wilkinson

Interesting... But then why (SortedCollection sortBlock: [ :a :b | a wrote: > Interesting... > > We could ask such questions too with definition of > - Heap equality (since they are partially sorted...) > (Heap withAll: (1 to: 10) asArray) = (Heap withAll: (1 to: 10) > asArray shuffled). > - Interval equality, could you tell me which one is true? > (3 to: 2) = (2 to: 1). > (1 to: 7 by: 2) = (1 to: 8 by: 2). > (1 to: 2 by: 2) = (1 to: 2 by: 3). > > Nicolas > > 2012/11/19 Hernan Wilkinson <hernan.wilkinson(a)10pines.com>: > > Hi, > > I'm a little surprised with the current SortedCollection #= > > implementation... it is: > > > > = aSortedCollection > > "Answer true if my and aSortedCollection's species are the same, > > and if our blocks are the same, and if our elements are the same." > > > > self species = aSortedCollection species ifFalse: [^ false]. > > sortBlock = aSortedCollection sortBlock > > ifTrue: [^ super = aSortedCollection] > > ifFalse: [^ false] > > > > and my surprise is because it compares the sortBlocks that makes the > > simplest case to fail like this one: > > > > (SortedCollection sortBlock: [ :a :b | a > sortBlock: [ :a :b | a > > > One could argue that if we remove the sortBlock comparison then : > > > > (SortedCollection sortBlock: [ :a :b | a > sortBlock: [ :a :b | a > b ]) > > > > would return true... but is that wrong? ... or is the philosophy to use > the > > message #hasEqualElements: on this cases? > > > > BTW, VisualWorks implementation is the same as pharo, but the > > BlockClosure>>= is different and that's why it works as at least I > expected > > :-) > > > > Bye, > > Hernan > > > > -- > > HernÃ¡n Wilkinson > > Agile Software Development, Teaching & Coaching > > Phone: +54 - 011 - 6091 - 3125 > > Mobile: +54 - 911 - 4470 - 7207 > > email: hernan.wilkinson(a)10Pines.com > > site: http://www.10Pines.com > > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina > > > > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching* *Phone: +54 - 011 - *6091 - 3125* Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Alem 693, Floor 5 B, Buenos Aires, Argentina

Nov. 19, 2012

Re: [Pharo-project] SortedCollection>>=

by Nicolas Cellier

Interesting... We could ask such questions too with definition of - Heap equality (since they are partially sorted...) (Heap withAll: (1 to: 10) asArray) = (Heap withAll: (1 to: 10) asArray shuffled). - Interval equality, could you tell me which one is true? (3 to: 2) = (2 to: 1). (1 to: 7 by: 2) = (1 to: 8 by: 2). (1 to: 2 by: 2) = (1 to: 2 by: 3). Nicolas 2012/11/19 Hernan Wilkinson <hernan.wilkinson(a)10pines.com>: > Hi, > I'm a little surprised with the current SortedCollection #= > implementation... it is: > > = aSortedCollection > "Answer true if my and aSortedCollection's species are the same, > and if our blocks are the same, and if our elements are the same." > > self species = aSortedCollection species ifFalse: [^ false]. > sortBlock = aSortedCollection sortBlock > ifTrue: [^ super = aSortedCollection] > ifFalse: [^ false] > > and my surprise is because it compares the sortBlocks that makes the > simplest case to fail like this one: > > (SortedCollection sortBlock: [ :a :b | a sortBlock: [ :a :b | a > One could argue that if we remove the sortBlock comparison then : > > (SortedCollection sortBlock: [ :a :b | a sortBlock: [ :a :b | a > b ]) > > would return true... but is that wrong? ... or is the philosophy to use the > message #hasEqualElements: on this cases? > > BTW, VisualWorks implementation is the same as pharo, but the > BlockClosure>>= is different and that's why it works as at least I expected > :-) > > Bye, > Hernan > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Phone: +54 - 011 - 6091 - 3125 > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina >

Nov. 19, 2012

Re: [Pharo-project] [ANN] Limbo: a simple shell wrapper for NativeBoost

by Igor Stasenko

On 19 November 2012 17:45, Max Leske <maxleske(a)gmail.com> wrote: > > On 19.11.2012, at 21:37, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> Okay, after i saw C code in limbo.c >> i can clearly tell, that read_buffers() function can be implemented >> purely on smalltalk using nativeboost. >> >> as for run_command() function, you should try to also implement it as >> a series of system calls using nativeboost ffi. >> it is possible. >> >> The most issues would be is to account for scheduler to make sure that >> no-one can interrupt the process between critical parts of code (like >> VM scheduler). > > :-/ sounds trickyâ¦ > nope. this part is actually easy: [ something which should not interrupt] forkAt: Processor highestPriority. >> >> You should really consider avoiding having C code at all.. because at >> the end it doesn't makes things any simpler comparing to having extra >> VM plugin (and knowing how to deal with it - compile/copy/distribute >> with VM) for users. >> > > Good to know! > Now that I have a working version in C I think that it should be a lot easier to write the equivalent NativeBoost code since I know what actually to code :) Indeed. :) > It's also pretty easy to just replace the call to the library with the NB code in Limbo, so any code using the library will keep on working. > > Anybody willing to write this in NativeBoost is more than welcome, I'll have to stop working on it for the moment. > >> But anyways, good to see there's brave people who don't fear to swim >> in those waters :) >> > > Thanks :) > >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Nov. 19, 2012

Re: [Pharo-project] [ANN] Limbo: a simple shell wrapper for NativeBoost

by Igor Stasenko

On 19 November 2012 17:30, Max Leske <maxleske(a)gmail.com> wrote: > > On 19.11.2012, at 21:26, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 19 November 2012 17:17, Max Leske <maxleske(a)gmail.com> wrote: >>> Hi everyone. >>> >>> I want to announce the first (and *very* basic) version of Limbo. >>> Limbo is a simple wrapper around NativeBoost that lets you run commands on the shell (via sh) or directly (no shell expansion). >>> >> >> why you need to wrap around NativeBoost? perhaps a more correct >> phrasing would be 'using nativeboost'? > > True. I chose "wrapper" with the idea that the NativeBoost part is hidden from the user. The user does not need to know how to use NativeBoost. > >> >>> To use Limbo you will need the NBCog VM and install NativeBoost into your image (with "NBInstaller install"). You will also need to build the shared library from the archive attached to this e-mail and put it into the "Plugins" directory of the VM (instructions inside the archive). I also attached the xcode project. >>> >>> The Limbo repo: >>> >>> MCGemstoneRepository >>> location: 'http://ss3.gemstone.com/ss/Limbo' >>> user: '' >>> password: '' >>> >>> I am *not* an experienced C coder so there might be some horrible stuff in the box. If you have any suggestions / requests / bug reports or would like to contribute, let me know. >>> >>> Disclaimer: >>> NativeBoost uses direct memory access. I have written Limbo to the best of my memory layout knowledge (I'm quite a n00b there) but cannot and will not guarantee that you might not experience memory leaks or VM crashes (or any type of crash for that matter). This is just a warning, I haven't had any troubles at all with Limbo so far. >>> >> >> Hmm.. what is the C part for? The whole idea of using NativeBoost is >> to avoid writing a single line of C code. Because if you cannot avoid >> that, writing a VM plugin turns to be more preferable. >> But i didn't saw your code yet, so just commenting what on surface :) > > Very well possible that I got something wrong :) > Anyway, I figured that it would be easier for me to write C than NativeBoost. Also, I use pipe / fork / execute, not sure how I would have done that in NativeBoost (although it's probably possible) :) > Sure thing it is easier to use C functions from C code :) But then think that anyone who would like to use your stuff will need to build this library by himself, copy it to right place etc etc.. Which means, less work for you turns into more work for users. Providing bindings to fork/pipe kernel functions is piece of cake. But writing a wrapper around it would be a bit of work.. but still it is possible. And you should try. And yes, using fork() stuff having many treacherous pitfalls, but don't think that if you call this function from code written in C instead of NB will make it less treacherous. I think Dave can give some more input on that, because he also using fork() in OSProcess. I am surely don't have good experience with this function to clearly tell if its usage is correct in context of VM or not. -- Best regards, Igor Stasenko.

Nov. 19, 2012

Re: [Pharo-project] [ANN] Limbo: a simple shell wrapper for NativeBoost

by Max Leske

On 19.11.2012, at 21:37, Igor Stasenko <siguctua(a)gmail.com> wrote: > Okay, after i saw C code in limbo.c > i can clearly tell, that read_buffers() function can be implemented > purely on smalltalk using nativeboost. > > as for run_command() function, you should try to also implement it as > a series of system calls using nativeboost ffi. > it is possible. > > The most issues would be is to account for scheduler to make sure that > no-one can interrupt the process between critical parts of code (like > VM scheduler). :-/ sounds trickyâ¦ > > You should really consider avoiding having C code at all.. because at > the end it doesn't makes things any simpler comparing to having extra > VM plugin (and knowing how to deal with it - compile/copy/distribute > with VM) for users. > Good to know! Now that I have a working version in C I think that it should be a lot easier to write the equivalent NativeBoost code since I know what actually to code :) It's also pretty easy to just replace the call to the library with the NB code in Limbo, so any code using the library will keep on working. Anybody willing to write this in NativeBoost is more than welcome, I'll have to stop working on it for the moment. > But anyways, good to see there's brave people who don't fear to swim > in those waters :) > Thanks :) > -- > Best regards, > Igor Stasenko. >

Nov. 19, 2012