- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Strange behavior of blocks

by Serge Stinckwich

On Fri, Aug 1, 2014 at 4:43 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hello, > > Nice way to reproduce easily the SmallInteger bug :) > > | state values | > values := (1 to: 100000) collect: [ :t | state := { t . t + 1 . t + 2 }]. > values select: [ :e | e isInteger ] Maybe we should convert this as a test in order to avoid any regression in the future ? > This bug was present in some VMs and it is fixed in the latest VMs. Ok, thank you ClÃ©ment. I was not aware of this bug until now. > The stable Mac VM still have the bug. > > If you need a VM without the bug, go there: > > http://files.pharo.org/vm/pharo/30/ > > Click on your OS, then select the zip file named 'latest.zip' and download > it. > > The latest VM does not have the bug. I'm using PharoLauncher and apparently the mac OS X version still use the buggy VM. Thank you. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Aug. 1, 2014

Re: [Pharo-dev] Has someone ever built a "sort block generator"

by Henrik Johansen

On 01 Aug 2014, at 4:47 , Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Fri, Aug 1, 2014 at 11:31 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Y asked for the same thing a few days ago in http://forum.world.st/Multiple-sorting-helper-td4770613.html > > Something like: > sorter := MultipleSortCriteria new > add: #lastName; > add: [:each | each personalInfo age ] ascending: false. > aCollection asSortedCollection: sorter. > > > Exactly!!! > And... what is most important for me, is that to the MultipleSortCriteria I would like to ask #sortBlock :) > > Thanks Esteban for better explaining what I was looking for ;) I always liked this approach: http://objology.blogspot.no/2010/11/tag-sortfunctions-redux.html Donât think anyoneâs ported it to Pharo yet though. Cheers, Henry

Aug. 1, 2014

Re: [Pharo-dev] Has someone ever built a "sort block generator"

by Mariano Martinez Peck

On Fri, Aug 1, 2014 at 11:31 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Y asked for the same thing a few days ago in > http://forum.world.st/Multiple-sorting-helper-td4770613.html > > Something like: > sorter := MultipleSortCriteria new > add: #lastName; > add: [:each | each personalInfo age ] ascending: false. > aCollection asSortedCollection: sorter. > > Exactly!!! And... what is most important for me, is that to the MultipleSortCriteria I would like to ask #sortBlock :) Thanks Esteban for better explaining what I was looking for ;) > > you could add something like: > sorter := MultipleSortCriteria new > add: #lastName; > add: #firstName ascending: false nullsFirst: true. > aCollection asSortedCollection: sorter. > > Regards! > > > Esteban A. Maringolo > > > 2014-08-01 2:40 GMT-03:00 Damien Cassou <damien.cassou(a)gmail.com>: > > On Thu, Jul 31, 2014 at 10:50 PM, stepharo <stepharo(a)free.fr> wrote: >> > what are you doing? >> >> >> I think Mariano would like something like this: >> >> persons sorted: #(lastname firstname birthdate) asSortBlock >> >> that would sort by lastname, and if lastnames are equal by firstnames >> and if both lastnames and firstnames are equal by birthdate. >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Success is the ability to go from one failure to another without >> losing enthusiasm." >> Winston Churchill >> >> > -- Mariano http://marianopeck.wordpress.com

Aug. 1, 2014

Re: [Pharo-dev] Strange behavior of blocks

by ClÃ©ment Bera

Hello, Nice way to reproduce easily the SmallInteger bug :) | state values | values := (1 to: 100000) collect: [ :t | state := { t . t + 1 . t + 2 }]. values select: [ :e | e isInteger ] This bug was present in some VMs and it is fixed in the latest VMs. The stable Mac VM still have the bug. If you need a VM without the bug, go there: http://files.pharo.org/vm/pharo/30/ Click on your OS, then select the zip file named 'latest.zip' and download it. The latest VM does not have the bug. 2014-08-01 15:20 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > Dear all, > > using Sci-Smalltalk, we found with Natalia that sometimes blocks have > strange behavior : > https://groups.google.com/forum/#!topic/scismalltalk/HmGpTkzLOdQ > > I was able to create a more simpler example using only Pharo. > If you try, the following expression, there is no problem: > > |state values | > values := (1 to: 10000) collect: [ : t| state := { t. t+1. t+2.}]. > (1 to: 10000) do:[:i | (values at:i) at:2]. > > and you do more iterations, an error appears (Instances of > SmallInteger are not indexable), > because from time to time, an array is replaced by an integer: > > |state values | > values := (1 to: 100000) collect: [ : t| state := { t. t+1. t+2.}]. > (1 to: 100000) do:[:i | (values at:i) at:2]. > > and if you move the state variable inside the block, it works again : > > | values | > values := (1 to: 100000) collect: [ : t| |state| state := { t. t+1. t+2.}]. > (1 to: 100000) do:[:i | (values at:i) at:2]. > > Same problem in Pharo 3.0 or Pharo 4.0 > > Regards, > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > >

Aug. 1, 2014

Re: [Pharo-dev] Has someone ever built a "sort block generator"

by Esteban A. Maringolo

Y asked for the same thing a few days ago in http://forum.world.st/Multiple-sorting-helper-td4770613.html Something like: sorter := MultipleSortCriteria new add: #lastName; add: [:each | each personalInfo age ] ascending: false. aCollection asSortedCollection: sorter. you could add something like: sorter := MultipleSortCriteria new add: #lastName; add: #firstName ascending: false nullsFirst: true. aCollection asSortedCollection: sorter. Regards! Esteban A. Maringolo 2014-08-01 2:40 GMT-03:00 Damien Cassou <damien.cassou(a)gmail.com>: > On Thu, Jul 31, 2014 at 10:50 PM, stepharo <stepharo(a)free.fr> wrote: > > what are you doing? > > > I think Mariano would like something like this: > > persons sorted: #(lastname firstname birthdate) asSortBlock > > that would sort by lastname, and if lastnames are equal by firstnames > and if both lastnames and firstnames are equal by birthdate. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > >

Aug. 1, 2014

Re: [Pharo-dev] Strange behavior of blocks

by Henrik Johansen

On 01 Aug 2014, at 3:20 , Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > Dear all, > > using Sci-Smalltalk, we found with Natalia that sometimes blocks have > strange behavior : > https://groups.google.com/forum/#!topic/scismalltalk/HmGpTkzLOdQ > > I was able to create a more simpler example using only Pharo. > If you try, the following expression, there is no problem: > > |state values | > values := (1 to: 10000) collect: [ : t| state := { t. t+1. t+2.}]. > (1 to: 10000) do:[:i | (values at:i) at:2]. > > and you do more iterations, an error appears (Instances of > SmallInteger are not indexable), > because from time to time, an array is replaced by an integer: > > |state values | > values := (1 to: 100000) collect: [ : t| state := { t. t+1. t+2.}]. > (1 to: 100000) do:[:i | (values at:i) at:2]. > > and if you move the state variable inside the block, it works again : > > | values | > values := (1 to: 100000) collect: [ : t| |state| state := { t. t+1. t+2.}]. > (1 to: 100000) do:[:i | (values at:i) at:2]. > > Same problem in Pharo 3.0 or Pharo 4.0 > > Regards, Speaking of which, when trying to inspect the array, itâs incredibly slowâ¦ The main reason for this? BasicIndexedEyeElement >> hash ^super hash bitXor: index hash The super implementation? AbstractEyeElement >> hash ^host hash Guess what the host of an indexedEyeElement is? Thatâs right, the collectionâ¦ So every time it tries to find the cached icon of a line (which is, 10-20 times per refresh cycle depending on the view), it iterates through the 100000 element array to calculate its hashâ¦ Iâd recommend either removing the super call from BasicIndexedEyeElement, or tell the AbstractEyeElement to use the identityHash of its host instead. Bonus: It also invokes a #DNU hander every time, since DictionaryValueHolder >> at:ifAbsentPut: is implemented self at: key ifAbsent: []. instead of value at: key ifAbsent: []. Code quality progress. Yay. Cheers, Henry

Aug. 1, 2014

Re: [Pharo-dev] Floating point literals in debugger

by Sven Van Caekenberghe

Note that inspecting her expression does work, it is the debugging that fails (I am not sure why you would want to that). Pharo does answer whole numbers from scientific notation if it can (try 1e6 for example), I think that is cool (maintaining maximum precision). You can always do #asFloat if you want. So the calculation is correct 1 - 1e-6 or 1 - 1/1000000 which equals 999999/1000000 On 01 Aug 2014, at 15:40, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > Yes, I see also the same problem. > > I didn't realize until now that : 1-1e-6 > is printed as a fraction (try print-it): > (999999/1000000) > > A little bit strange, no ? > > On Fri, Aug 1, 2014 at 3:05 PM, Natalia Tymchuk > <natalia.tymchuk(a)unikernel.net> wrote: >> Hello. >> When I have the following expression >> {1-1e-6. 1e-6. 0} >> in the code and then I debug it I get >> {(1 - '<an unprintable nonliteral value>'). >> '<an unprintable nonliteral value>'. >> 0}. >> >> Is it a known problem or should I report an issue on debug tracker? >> >> Best regards, >> Natalia >> > > > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ >

Aug. 1, 2014

Re: [Pharo-dev] Floating point literals in debugger

by Serge Stinckwich

Yes, I see also the same problem. I didn't realize until now that : 1-1e-6 is printed as a fraction (try print-it): (999999/1000000) A little bit strange, no ? On Fri, Aug 1, 2014 at 3:05 PM, Natalia Tymchuk <natalia.tymchuk(a)unikernel.net> wrote: > Hello. > When I have the following expression > {1-1e-6. 1e-6. 0} > in the code and then I debug it I get > {(1 - '<an unprintable nonliteral value>'). > '<an unprintable nonliteral value>'. > 0}. > > Is it a known problem or should I report an issue on debug tracker? > > Best regards, > Natalia > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Aug. 1, 2014

Strange behavior of blocks

by Serge Stinckwich

Dear all, using Sci-Smalltalk, we found with Natalia that sometimes blocks have strange behavior : https://groups.google.com/forum/#!topic/scismalltalk/HmGpTkzLOdQ I was able to create a more simpler example using only Pharo. If you try, the following expression, there is no problem: |state values | values := (1 to: 10000) collect: [ : t| state := { t. t+1. t+2.}]. (1 to: 10000) do:[:i | (values at:i) at:2]. and you do more iterations, an error appears (Instances of SmallInteger are not indexable), because from time to time, an array is replaced by an integer: |state values | values := (1 to: 100000) collect: [ : t| state := { t. t+1. t+2.}]. (1 to: 100000) do:[:i | (values at:i) at:2]. and if you move the state variable inside the block, it works again : | values | values := (1 to: 100000) collect: [ : t| |state| state := { t. t+1. t+2.}]. (1 to: 100000) do:[:i | (values at:i) at:2]. Same problem in Pharo 3.0 or Pharo 4.0 Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Aug. 1, 2014

Floating point literals in debugger

by Natalia Tymchuk

Hello. When I have the following expression {1-1e-6. 1e-6. 0} in the code and then I debug it I get {(1 - '<an unprintable nonliteral value>'). '<an unprintable nonliteral value>'. 0}. Is it a known problem or should I report an issue on debug tracker? Best regards, Natalia

Aug. 1, 2014