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

Development of 7.0 on windows

by Nicolas Cellier

Many of you are probably aware, but since I rediscovered, let's remind: Before cloning pharo.git, git must be configured for long file names on windows, even with tonel git config --system core.longpaths true Borrowed from: http://www.brycevandyk.com/of-too-long-file-names-in-windows-and-git/ This worked for me, otherwise i get a broken clone

Nov. 7, 2017

[Pharo 7.0-dev] Build #267: 20648-Provide-Bitmap-variant-of-Source-Code-fonts

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #267 was: SUCCESS. The Pull Request #441 was integrated: "20648-Provide-Bitmap-variant-of-Source-Code-fonts" Pull request url: https://github.com/pharo-project/pharo/pull/441 Issue Url: https://pharo.fogbugz.com/f/cases/20648 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 7, 2017

[Pharo 7.0-dev] Build #266: 20648-Provide-Bitmap-variant-of-Source-Code-fonts

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #266 was: FAILURE. The Pull Request #441 was integrated: "20648-Provide-Bitmap-variant-of-Source-Code-fonts" Pull request url: https://github.com/pharo-project/pharo/pull/441 Issue Url: https://pharo.fogbugz.com/f/cases/20648 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 7, 2017

Re: [Pharo-dev] [Pharo 7.0-dev] Build #265: 20648-Provide-Bitmap-variant-of-Source-Code-fonts

by Pavel Krivanek

It was stuck on the release cleanup. It is not the only case. Instance of GlobalVariable did not understand #bitAnd: [32] [0mGlobalVariable(Object)>>doesNotUnderstand: #bitAnd: [32] CompiledMethod(CompiledCode)>>numLiterals [32] CompiledMethod(CompiledCode)>>literals [32] [:method | | obsoleteBindings | [32] obsoleteBindings := method literals select: [:literal | literal isVariableBinding and: [ literal value isBehavior and: [ literal value isObsolete ] ] ]. [32] obsoleteBindings do: [:binding | | obsName realName realClass | [32] obsName := binding value name. [32] self [32] trace: 'Binding: '; [32] traceCr: obsName. [32] realName := obsName copyReplaceAll: 'AnObsolete' with: ''. [32] realClass := Smalltalk globals at: realName asSymbol ifAbsent: [ UndefinedObject ]. [32] binding key: binding key value: realClass ]. [32] [32] "do not forget to flush the JIT cache"obsoleteBindings ifNotEmpty: [ method flushCache ] ] in SmalltalkImage>>fixObsoleteBindings in Block: [:method | | obsoleteBindings |... [32] Array(SequenceableCollection)>>do: [32] SmalltalkImage>>fixObsoleteBindings [32] SmalltalkImage>>fixObsoleteReferences [32] BaselineOfIDE>>postload:package: 2017-11-07 16:35 GMT+01:00 <ci-pharo-ci-jenkins2(a)inria.fr>: > There is a new Pharo build available! > > The status of the build #265 was: FAILURE. > > The Pull Request #441 was integrated: "20648-Provide-Bitmap-variant- > of-Source-Code-fonts" > Pull request url: https://github.com/pharo-project/pharo/pull/441 > > Issue Url: https://pharo.fogbugz.com/f/cases/20648 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending% > 20pull%20request%20and%20branch%20Pipeline/job/development/265/ >

Nov. 7, 2017

[Pharo 7.0-dev] Build #265: 20648-Provide-Bitmap-variant-of-Source-Code-fonts

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #265 was: FAILURE. The Pull Request #441 was integrated: "20648-Provide-Bitmap-variant-of-Source-Code-fonts" Pull request url: https://github.com/pharo-project/pharo/pull/441 Issue Url: https://pharo.fogbugz.com/f/cases/20648 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 7, 2017

Re: [Pharo-dev] change weird String compare: method (was about SortFunctions)

by Nicolas Cellier

2017-11-07 14:48 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > 2017-11-07 14:45 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> 2017-11-07 14:40 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai >> l.com>: >> >>> >>> >>> 2017-11-07 14:20 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>> >>>> I have new question. Why we really need threeWayCompareTo:? >>>> DefaultSortFunction can implement it using standard comparison methods. >>>> >>>> >>> But what would the DefaultSortFunction use? >>> 2 among the 3 selectors < = > ? >>> It's just that we might scan String twice when <=> would do it once, but >>> apart that is OK >>> >> >> Yes, you are right. >> And we already have VM based String compare: with strange logic returning >> 1, 2, 3. So we already can optimize current String>>threeWayCompareTo:. >> > > Maybe good idea to open ticket and modify image level methods to return > standard -1,0,1 values. > > We should have done that for long. But we want to avoid images to behave differentlly depending on VM version. Possibility 1: add a new primitive, marking the old as for backward compatibility, and modify image side with backward compatibility support (try new prim, if failure try old, if failure revert to Smalltalk code) Since this primitive is only for accelerating things and not strictly necessary, we don't need backward compatibility so: Possibility 2: add a new primitive, and modify image side (try new prim if failure then revert to Smalltalk code)

Nov. 7, 2017

Re: [Pharo-dev] about SortFunctions

by Denis Kudriashov

2017-11-07 14:45 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > 2017-11-07 14:40 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> >> >> 2017-11-07 14:20 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >>> I have new question. Why we really need threeWayCompareTo:? >>> DefaultSortFunction can implement it using standard comparison methods. >>> >>> >> But what would the DefaultSortFunction use? >> 2 among the 3 selectors < = > ? >> It's just that we might scan String twice when <=> would do it once, but >> apart that is OK >> > > Yes, you are right. > And we already have VM based String compare: with strange logic returning > 1, 2, 3. So we already can optimize current String>>threeWayCompareTo:. > Maybe good idea to open ticket and modify image level methods to return standard -1,0,1 values. > > >> >> >> 2017-11-05 0:37 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai >>> l.com>: >>> >>>> Hi all, >>>> I started a discussion with Denis in a pull request >>>> https://github.com/pharo-project/pharo/pull/430 >>>> But since it's going beyond simple code review, it probably has a >>>> better place here. >>>> >>>> First, I want to say thanks for enriching this original work of Travis >>>> Griggs. >>>> http://objology.blogspot.fr/2010/11/tag-sortfunctions-redux.html >>>> http://objology.blogspot.fr/2010/11/tag-sortfunctions.html >>>> <http://objology.blogspot.fr/2010/11/tag-sortfunctions-redux.html> >>>> >>>> Of course, I'm never satisfied. >>>> So I don't really appreciate the rewrite of space ship operator <=> >>>> into a more heavy threeWayCompareTo: >>>> >>>> In my eyes, it's so obvious that <=> means < or = or > in the context >>>> of SortFunction >>>> And also that the order matches the signs >>>> < = > >>>> -1 0 1 >>>> IOW result will be -1 if receiver is <, 0 if equal, +1 if superior >>>> >>>> #threeWayCompareTo: does not tell as well. >>>> But maybe It's a question of taste and I don't have the same eyes as >>>> Pharo people? >>>> To me it's also a question of respect to the original author, don't >>>> change a good selector for the sake of changing. >>>> >>>> Apart this detail, I wanted to speak about SortByPropertyFunction. >>>> SortByProperty is super usefull for composing / chaining like this: >>>> >>>> population sortBy: #name ascending , #age descending. >>>> >>>> But currently, SortByPropertyFunction is allways using the default >>>> hardcoded collation <=> ... He he, it's also notice it's shorter to write ;) >>>> >>>> Imagine that my properties are neither String nor Magnitude, or they >>>> are, but I want a different collation policy, because in French $Ã© must not >>>> be sorted too far from $e. >>>> >>>> It could be written quite simply with: >>>> >>>> c sortBy: #name collatedInFrench ascending , #age descending >>>> >>>> With current implementation, collatedInFrench would have to use a block >>>> (thru a CollatorBlockFunction which is a proxy to the block in a >>>> SortFunction disguise): >>>> >>>> Symbol>>collatedInFrench >>>> "interpret self as a property" >>>> ^[:a :b | FrenchCollator collate: (self value: a) with: (self >>>> value: b)] >>>> >>>> But IMO SortByPropertyFunction should better feed a reified >>>> CollatorFunction, or said differently a SortFunction, as Denis said. >>>> >>>> Symbol>>collatedInFrench >>>> ^FrenchCollator new onProperty: self >>>> >>>> SortFunction>>onProperty: aValuable >>>> ^SortByPropertyFunction sortProperty: aValuable with: self >>>> >>>> What do you think? >>>> >>>> Nicolas >>>> >>>> >>> >> >

Nov. 7, 2017

Re: [Pharo-dev] about SortFunctions

by Denis Kudriashov

2017-11-07 14:40 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > 2017-11-07 14:20 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> I have new question. Why we really need threeWayCompareTo:? >> DefaultSortFunction can implement it using standard comparison methods. >> >> > But what would the DefaultSortFunction use? > 2 among the 3 selectors < = > ? > It's just that we might scan String twice when <=> would do it once, but > apart that is OK > Yes, you are right. And we already have VM based String compare: with strange logic returning 1, 2, 3. So we already can optimize current String>>threeWayCompareTo:. > > > 2017-11-05 0:37 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai >> l.com>: >> >>> Hi all, >>> I started a discussion with Denis in a pull request >>> https://github.com/pharo-project/pharo/pull/430 >>> But since it's going beyond simple code review, it probably has a better >>> place here. >>> >>> First, I want to say thanks for enriching this original work of Travis >>> Griggs. >>> http://objology.blogspot.fr/2010/11/tag-sortfunctions-redux.html >>> http://objology.blogspot.fr/2010/11/tag-sortfunctions.html >>> <http://objology.blogspot.fr/2010/11/tag-sortfunctions-redux.html> >>> >>> Of course, I'm never satisfied. >>> So I don't really appreciate the rewrite of space ship operator <=> into >>> a more heavy threeWayCompareTo: >>> >>> In my eyes, it's so obvious that <=> means < or = or > in the context of >>> SortFunction >>> And also that the order matches the signs >>> < = > >>> -1 0 1 >>> IOW result will be -1 if receiver is <, 0 if equal, +1 if superior >>> >>> #threeWayCompareTo: does not tell as well. >>> But maybe It's a question of taste and I don't have the same eyes as >>> Pharo people? >>> To me it's also a question of respect to the original author, don't >>> change a good selector for the sake of changing. >>> >>> Apart this detail, I wanted to speak about SortByPropertyFunction. >>> SortByProperty is super usefull for composing / chaining like this: >>> >>> population sortBy: #name ascending , #age descending. >>> >>> But currently, SortByPropertyFunction is allways using the default >>> hardcoded collation <=> ... He he, it's also notice it's shorter to write ;) >>> >>> Imagine that my properties are neither String nor Magnitude, or they >>> are, but I want a different collation policy, because in French $Ã© must not >>> be sorted too far from $e. >>> >>> It could be written quite simply with: >>> >>> c sortBy: #name collatedInFrench ascending , #age descending >>> >>> With current implementation, collatedInFrench would have to use a block >>> (thru a CollatorBlockFunction which is a proxy to the block in a >>> SortFunction disguise): >>> >>> Symbol>>collatedInFrench >>> "interpret self as a property" >>> ^[:a :b | FrenchCollator collate: (self value: a) with: (self >>> value: b)] >>> >>> But IMO SortByPropertyFunction should better feed a reified >>> CollatorFunction, or said differently a SortFunction, as Denis said. >>> >>> Symbol>>collatedInFrench >>> ^FrenchCollator new onProperty: self >>> >>> SortFunction>>onProperty: aValuable >>> ^SortByPropertyFunction sortProperty: aValuable with: self >>> >>> What do you think? >>> >>> Nicolas >>> >>> >> >

Nov. 7, 2017

Re: [Pharo-dev] about SortFunctions

by Nicolas Cellier

2017-11-07 14:20 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > I have new question. Why we really need threeWayCompareTo:? > DefaultSortFunction can implement it using standard comparison methods. > > But what would the DefaultSortFunction use? 2 among the 3 selectors < = > ? It's just that we might scan String twice when <=> would do it once, but apart that is OK 2017-11-05 0:37 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com>: > >> Hi all, >> I started a discussion with Denis in a pull request >> https://github.com/pharo-project/pharo/pull/430 >> But since it's going beyond simple code review, it probably has a better >> place here. >> >> First, I want to say thanks for enriching this original work of Travis >> Griggs. >> http://objology.blogspot.fr/2010/11/tag-sortfunctions-redux.html >> http://objology.blogspot.fr/2010/11/tag-sortfunctions.html >> <http://objology.blogspot.fr/2010/11/tag-sortfunctions-redux.html> >> >> Of course, I'm never satisfied. >> So I don't really appreciate the rewrite of space ship operator <=> into >> a more heavy threeWayCompareTo: >> >> In my eyes, it's so obvious that <=> means < or = or > in the context of >> SortFunction >> And also that the order matches the signs >> < = > >> -1 0 1 >> IOW result will be -1 if receiver is <, 0 if equal, +1 if superior >> >> #threeWayCompareTo: does not tell as well. >> But maybe It's a question of taste and I don't have the same eyes as >> Pharo people? >> To me it's also a question of respect to the original author, don't >> change a good selector for the sake of changing. >> >> Apart this detail, I wanted to speak about SortByPropertyFunction. >> SortByProperty is super usefull for composing / chaining like this: >> >> population sortBy: #name ascending , #age descending. >> >> But currently, SortByPropertyFunction is allways using the default >> hardcoded collation <=> ... He he, it's also notice it's shorter to write ;) >> >> Imagine that my properties are neither String nor Magnitude, or they are, >> but I want a different collation policy, because in French $Ã© must not be >> sorted too far from $e. >> >> It could be written quite simply with: >> >> c sortBy: #name collatedInFrench ascending , #age descending >> >> With current implementation, collatedInFrench would have to use a block >> (thru a CollatorBlockFunction which is a proxy to the block in a >> SortFunction disguise): >> >> Symbol>>collatedInFrench >> "interpret self as a property" >> ^[:a :b | FrenchCollator collate: (self value: a) with: (self >> value: b)] >> >> But IMO SortByPropertyFunction should better feed a reified >> CollatorFunction, or said differently a SortFunction, as Denis said. >> >> Symbol>>collatedInFrench >> ^FrenchCollator new onProperty: self >> >> SortFunction>>onProperty: aValuable >> ^SortByPropertyFunction sortProperty: aValuable with: self >> >> What do you think? >> >> Nicolas >> >> >

Nov. 7, 2017

Re: [Pharo-dev] about SortFunctions

by Thierry Goubier

2017-11-07 13:59 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > 2017-11-07 13:50 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> >> 10 years ago now, we designed a DSL above our parallel language, with the >>>> same kind of tradeoffs you described there. We ended up discarding it, >>>> because we had to maintain the full procedural code for the cases we >>>> couldn't cover. Discarding it was a wise decision. >>>> >>> >>> That's why SortFunction is now abstract class. If you want some complex >>> logic you are able to create custom function class which will incapsulate >>> it and make it reusable. >>> >> >> Then we agree: a good choice is having a proper place (sort function >> object, a method in simple cases) to implement that business logic if it is >> not obvious. >> >> >>> I already mentioned possible SortMethodFunction. It takes care about >>> binary method order which should be always on top of ascending list. It >>> would be ugly to implement it in block or with composition of selectors. >>> And I don't think that method should define #> >>> >> >> On a short analysis, I could give you half a dozen valid orderings for >> SortMethodFunction... You've chosen one, put it as the master one, and gave >> it a general name 'Ordering of Methods'. You could have written it as #>, >> the way you're doing it. >> > > Sorry Thierry that it is not obvious: given name is an example. Of course > it is better to have explicit name. > Understood :) Thierry > > >> >> Regards, >> >> Thierry >> >> >>> >>> >>>> >>>> Now, if you explained me something like that: >>>> >>>> people nilFirst ascending >>>> >>>> Then I'd be more convinced. Or even >>>> >>>> people sorted nilFirst ascending (if one would prefer restricting the >>>> implementations of #nilFirst). >>>> >>>> Could the symbol use be a smell of not putting the right >>>> responsabilities into the People class? >>>> >>>> Thierry >>>> >>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >> >

Nov. 7, 2017