Oh, I hope we will be able improve this process. But personally when I set up it first time everything start to be smooth. And when I repeat it from scratch it takes just couple of minutes.
2017-11-06 10:37 GMT+01:00 Nicolas Cellier < [email protected]>: > Because it's a cross dialect library and because contributing in Squeak is > so much easier for me. > > I like the social power provided by github and i know how to use git, at > least as an expert beginner. > But it took me two hours to pick a pharo image, fork and clone the pharo > repository, pick a pharo VM (I ended up building my own), > retrieve my ssh pass phrase to avoid using github thru https, > search documentation of where should I put the image wrt to my cloned git > repository, > search how to use iceberg, > and finally realized that the author/date would not even be preserved if > we want to port this cross dialect library. > The dark theme upsets me, especially the green on blue, I could have > searched how to change it, but there I stopped. > > While doing all these things, I did not spent a minute focusing on the > SortFunction subject. > I can see that as an investment, maybe I should have done it before, but > it was too much for a Sunday evening. > > 2017-11-06 10:13 GMT+01:00 Denis Kudriashov <[email protected]>: > >> It is difficult to compare to current Pharo version. >> Why you not produce Pharo pull request? >> >> 2017-11-06 0:06 GMT+01:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmai >> l.com>: >> >>> I've put some of the proposed composition features into >>> >>> http://source.squeak.org/inbox/Collections-nice.766.mcz >>> http://source.squeak.org/inbox/CollectionsTests-nice.283.mcz >>> >>> http://source.squeak.org/inbox/Collections-nice.766.diff >>> http://source.squeak.org/inbox/CollectionsTests-nice.283.diff >>> >>> SInce it's Squeak based, it uses <=>, but never mind, that's the same >>> functions. >>> >>> >>> Stephane: the original comments were from Travis Griggs. >>> It's more a tutorial for using the SortFunction than a detailed >>> explanation of implementation. >>> >>> The original idea is that oSortFunction are composable. >>> For example, it's possible to chain sorting on a first criterion, then >>> resort on a second criterion if objects have same rank with first. >>> >>> For this, we need a to distinguish when objects have same rank (=) and >>> cannot use a binary result (Boolean) like legacy sortBlock, >>> So we rather need a ternary comparison (<=>). >>> >>> This thread is about extending composition, and generalizing >>> implementation by composition (like Xtreams) >>> - for sorting nil first (or last) >>> - for reversing the order >>> - for sorting properties with any collation order, and not just default >>> <=> >>> >>> 2017-11-05 17:52 GMT+01:00 Stephane Ducasse <[email protected]>: >>> >>>> Hi guys >>>> >>>> Do you have some nice comments somewhere? because I do not understand >>>> anything about this thread. >>>> I check the code and the comments are well... unclear and confusing. >>>> >>>> Stef >>>> >>>> On Sun, Nov 5, 2017 at 4:15 PM, Nicolas Cellier >>>> <[email protected]> wrote: >>>> > >>>> > >>>> > 2017-11-05 16:06 GMT+01:00 Denis Kudriashov <[email protected]>: >>>> >> >>>> >> >>>> >> 2017-11-05 11:33 GMT+01:00 Nicolas Cellier >>>> >> <[email protected]>: >>>> >>> >>>> >>> >>>> >>> Ah, I messed up, UndefinedSorter must not be chained, it must be a >>>> >>> wrapper! >>>> >>> Otherwise comparing to nil will resort to sorting by properties and >>>> >>> fail... >>>> >>> >>>> >>> SortFunction>>undefinedFirst >>>> >>> ^UndefinedSorter descending wrap: self >>>> >>> >>>> >>> UndefinedSorter>> collate: value1 with: value2 >>>> >>> "sort all nil according to the direction (first if -1, last >>>> if >>>> >>> +1), then" >>>> >>> value1 ifNil: [value2 ifNil: [^0] ifNotNil: [^direction]]. >>>> >>> value2 ifNil: [^direction negated]. >>>> >>> ^sorterForNonNil collate: value1 with: value2 >>>> >>> >>>> >>> It's important to have the UndefinedSorter : >>>> >>> - decoupled from property sort, because it can be generally >>>> usefull >>>> >>> - collating 2 nil as 0, so that another property can be chained >>>> >> >>>> >> >>>> >> I like your idea. >>>> >> It also forced me to think that direction itself should be >>>> implemented as >>>> >> wrapper. I would name it InvertedSortFunction: >>>> >> >>>> >> InvertedSortFunction>>collate: value1 with: value2 >>>> >> ^(actualSortFunction collate: value1 with: value2) * -1 >>>> >> >>>> >> >>>> >> If we will do it then direction will be not part of SortFunction. >>>> And all >>>> >> current functions will be in fact ascending. >>>> >> And to explicitly reflect this fact I would introduce >>>> >> AscendingSortFunction as their superclass. >>>> >> InvertedSortFunction and ChainedSortFunction will stay subclasses of >>>> >> SortFunction. >>>> >> >>>> >> So what you think? >>>> > >>>> > >>>> > Yes, I was thinking the same. >>>> > On another hand, direction makes thing symmetric and has its elegance >>>> too. >>>> > What I don't like with it is that it forces the library to have two >>>> > different messages for the same thing: >>>> > - collate:with: in base class accounting for direction >>>> > - threeWayCompare:with: in every subclass >>>> > >>>> > The fact to hardcode the direction in base class could be seen as an >>>> > optimization too. >>>> > I'm not sure what Sista optimization could bring in this case, >>>> because the >>>> > selectors may get megamorphic... >>>> > >>>> > >>>> >> >>>> >>> >>>> >>> >>>> >>> In >>>> >>> >>>> >>> people sortBy: #name ascending undefinedFirst , #age descending >>>> >>> >>>> >>> we could then have people with name nil still sorted by age, what >>>> is not >>>> >>> possible with current implementation >>>> >>> >>>> >> >>>> > >>>> >>>> >>> >> >
