March 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Making Git and Pharo More Accessible

by Yuriy Tymchuk

Hi Sean, Well Pharo 3 provided FileTree pre-intalled. We can make a job that loads gitfiletree, but you can load it from conf. browser so itâs really easy. I can provide my workflow, but the thing is, that this week Max Leske was going to work on a better and different git support and Iâm waiting for it (because I donât like my current workflow a lot). Uko On 12 Mar 2014, at 01:02, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Two things: > - Are the current git workflow options documented anywhere besides our > mailing lists? If not, will someone who has been using Git successfully > capture their process somewhere more permanent... > - Can "we" (proverbially, not that I'm intending to help ;)) make a > git-ready image on the community CI server? > > TIA > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Making-Git-and-Pharo-More-Accessible-tp4748695.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

March 12, 2014

Re: [Pharo-dev] Sort by property

by Eliot Miranda

We could indeed, but it offends my sense of value (excuse the pun), since Symbol>>value: is implemented in terms of #perform: and so is slower. Since this is a general library routine performance is an issue (the sort block is used N log N times in sorting the collection) and so I prefer the use of perform: when the arg is a symbol and value: when it's a block. Eliot (phone) On Mar 11, 2014, at 3:54 PM, Carlo <snoobabk(a)gmail.com> wrote: > Hi > > Since Symbol and Blocks are polymorphic could we not simplify the code to be: > > SequenceableCollection>>sortedAs: aSortBlockOrSymbol > "Answer a SortedCollection whose elements are the elements of the receiver. The sort order is defined by the argument, aSortBlockOrSymbol. The receiver cannot be empty. Answer a new collection. This method does not side effect the receiver. e.g. > SequenceableCollection withAllSubclasses sortedAs: #name. > SequenceableCollection withAllSubclasses sortedAs: [:class | class methodDict size]." > | aSortBlock | > aSortBlock := (#(true false ) > includes: (aSortBlockOrSymbol value: self first)) > ifTrue: [[:a :b | aSortBlockOrSymbol value: a]] > ifFalse: [[:a :b | (aSortBlockOrSymbol value: a) < (aSortBlockOrSymbol value: b)]]. > ^ (SortedCollection new: self size) sortBlock: aSortBlock; > addAll: self; > yourself > > > > > <SequenceableCollection-sortedAs.st> > > Cheers > Carlo > > > > > On 12 Mar 2014, at 12:32 AM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > > Thanks eliot. > > > On 11 Mar 2014, at 20:51, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >> and here's one with a better comment that includes examples >> >> >> On Tue, Mar 11, 2014 at 12:19 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> Hi Alexandre, >>> >>> IMO the isKindOf:, apart from being ugly, will hurt performance badly. Why not apply aSortBlockOrSymbol to the first element and then choose the block appropriately? e.g. >>> >>> aSortBlockOrSymbol isSymbol >>> ifTrue: >>> [(#(true false) includes: (self first perform: aSortBlockOrSymbol) >>> ifTrue: >>> [[:a :b | (a perform: aSortBlockOrSymbol)]] >>> ifFalse: >>> [[:a :b | (a perform: aSortBlockOrSymbol) < (b perform: aSortBlockOrSymbol)]]] >>> ... >>> >>> Nicer to read and faster, no? >>> >>> On Tue, Mar 11, 2014 at 8:17 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>>> hi Uko, >>>> >>>> For Roassal, we have a #sortedAs: defined on all collections >>>> >>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>> SequenceableCollection>>sortedAs: aSortBlockOrSymbol >>>> "Answer a SortedCollection whose elements are the elements of the >>>> receiver. The sort order is defined by the argument, aSortBlock." >>>> "Return a new collection. This method does not do a side effect" >>>> >>>> | aSortedCollection aSortBlock | >>>> aSortedCollection := SortedCollection new: self size. >>>> aSortBlock := >>>> aSortBlockOrSymbol isSymbol >>>> ifTrue: [ [:a :b | |t1 t2| >>>> t1 := (a perform: aSortBlockOrSymbol). >>>> t2 := (b perform: aSortBlockOrSymbol). >>>> ((t1 isKindOf: Boolean) and: [t2 isKindOf: Boolean]) >>>> ifTrue: [ t1 ] >>>> ifFalse: [ t1 < t2 ] ] ] >>>> ifFalse: [ >>>> (aSortBlockOrSymbol numArgs = 1) >>>> ifTrue: [ [ :v1 :v2 | (aSortBlockOrSymbol value: v1) < (aSortBlockOrSymbol value: v2) ] ] >>>> ifFalse: [ aSortBlockOrSymbol ] ]. >>>> aSortedCollection sortBlock: aSortBlock. >>>> aSortedCollection addAll: self. >>>> ^ aSortedCollection >>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>> >>>> You can use it for example: >>>> (1 to: 4) sortedAs: #odd >>>> => a SortedCollection(1 3 2 4) >>>> >>>> Collection withAllSubclasses sortedAs: #numberOfMethods >>>> => a SortedCollection(HashBag IdentityHashBag â¦) >>>> >>>> This is really handy. It should be part of Pharo I believe. >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>> On Mar 11, 2014, at 5:19 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>>> >>>> > Hi guys. >>>> > >>>> > This is a thing that I encounter quite often. >>>> > >>>> > Eg I have a collection of projects and I want to sort them by creation date. It would be nice to be able to do something like: >>>> > >>>> > projects sortByProp: #creationDate >>>> > >>>> > or by birth date of the author >>>> > >>>> > projects sortByProp: [ :proj | proj author birthDate ] >>>> > >>>> > Maybe Iâm wrong, but as Iâve told already I encounter it quite often and writing something like >>>> > >>>> > projects sortBy: [ :prev :next | prev creationDate <= next creationDate ] >>>> > >>>> > is boring for me. >>>> > >>>> > Cheers. >>>> > Uko >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> -- >>> best, >>> Eliot >> >> >> >> -- >> best, >> Eliot >> <SequenceableCollection-sortedAs.st> > >

March 12, 2014

Re: [Pharo-dev] Sort by property

by Tudor Girba

Exactly! Essentially, value: should replace pretty much all usages of perform:. For example, if Morphic would use value: variants instead of perform: we could script them without being obliged to create model classes. It would serve the spirit of fast prototyping much better. Cheers, Doru On Tue, Mar 11, 2014 at 11:54 PM, Carlo <snoobabk(a)gmail.com> wrote: > Hi > > Since Symbol and Blocks are polymorphic could we not simplify the code to > be: > > SequenceableCollection>>sortedAs: aSortBlockOrSymbol > "Answer a SortedCollection whose elements are the elements of the receiver. > The sort order is defined by the argument, aSortBlockOrSymbol. The receiver > cannot be empty. Answer a new collection. This method does not side effect > the receiver. e.g. > SequenceableCollection withAllSubclasses sortedAs: #name. > SequenceableCollection withAllSubclasses sortedAs: [:class | class methodDict > size]." > | aSortBlock | > aSortBlock := (#(true false ) > includes: (aSortBlockOrSymbol value: self first)) > ifTrue: [[:a :b | aSortBlockOrSymbol value: a]] > ifFalse: [[:a :b | (aSortBlockOrSymbol value: a) < (aSortBlockOrSymbol > value: b)]]. > ^ (SortedCollection new: self size) sortBlock: aSortBlock; > addAll: self; > yourself > > > > > > > Cheers > Carlo > > > > > On 12 Mar 2014, at 12:32 AM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > > Thanks eliot. > > > On 11 Mar 2014, at 20:51, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > and here's one with a better comment that includes examples > > > On Tue, Mar 11, 2014 at 12:19 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> Hi Alexandre, >> >> IMO the isKindOf:, apart from being ugly, will hurt performance >> badly. Why not apply aSortBlockOrSymbol to the first element and then >> choose the block appropriately? e.g. >> >> aSortBlockOrSymbol isSymbol >> ifTrue: >> [(#(true false) includes: (self first perform: >> aSortBlockOrSymbol) >> ifTrue: >> [[:a :b | (a perform: aSortBlockOrSymbol)]] >> ifFalse: >> [[:a :b | (a perform: aSortBlockOrSymbol) < (b >> perform: aSortBlockOrSymbol)]]] >> ... >> >> Nicer to read and faster, no? >> >> On Tue, Mar 11, 2014 at 8:17 AM, Alexandre Bergel < >> alexandre.bergel(a)me.com> wrote: >> >>> hi Uko, >>> >>> For Roassal, we have a #sortedAs: defined on all collections >>> >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> SequenceableCollection>>sortedAs: aSortBlockOrSymbol >>> "Answer a SortedCollection whose elements are the elements of the >>> receiver. The sort order is defined by the argument, aSortBlock." >>> "Return a new collection. This method does not do a side effect" >>> >>> | aSortedCollection aSortBlock | >>> aSortedCollection := SortedCollection new: self size. >>> aSortBlock := >>> aSortBlockOrSymbol isSymbol >>> ifTrue: [ [:a :b | |t1 t2| >>> t1 := (a >>> perform: aSortBlockOrSymbol). >>> t2 := (b >>> perform: aSortBlockOrSymbol). >>> ((t1 isKindOf: >>> Boolean) and: [t2 isKindOf: Boolean]) >>> ifTrue: >>> [ t1 ] >>> ifFalse: >>> [ t1 < t2 ] ] ] >>> ifFalse: [ >>> (aSortBlockOrSymbol numArgs = 1) >>> ifTrue: [ [ :v1 :v2 | >>> (aSortBlockOrSymbol value: v1) < (aSortBlockOrSymbol value: v2) ] ] >>> ifFalse: [ aSortBlockOrSymbol ] >>> ]. >>> aSortedCollection sortBlock: aSortBlock. >>> aSortedCollection addAll: self. >>> ^ aSortedCollection >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> >>> You can use it for example: >>> (1 to: 4) sortedAs: #odd >>> => a SortedCollection(1 3 2 4) >>> >>> Collection withAllSubclasses sortedAs: #numberOfMethods >>> => a SortedCollection(HashBag IdentityHashBag ...) >>> >>> This is really handy. It should be part of Pharo I believe. >>> >>> Cheers, >>> Alexandre >>> >>> >>> On Mar 11, 2014, at 5:19 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>> > Hi guys. >>> > >>> > This is a thing that I encounter quite often. >>> > >>> > Eg I have a collection of projects and I want to sort them by creation >>> date. It would be nice to be able to do something like: >>> > >>> > projects sortByProp: #creationDate >>> > >>> > or by birth date of the author >>> > >>> > projects sortByProp: [ :proj | proj author birthDate ] >>> > >>> > Maybe I'm wrong, but as I've told already I encounter it quite often >>> and writing something like >>> > >>> > projects sortBy: [ :prev :next | prev creationDate <= next >>> creationDate ] >>> > >>> > is boring for me. >>> > >>> > Cheers. >>> > Uko >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >> >> >> -- >> best, >> Eliot >> > > > > -- > best, > Eliot > <SequenceableCollection-sortedAs.st> > > > > > -- www.tudorgirba.com "Every thing has its own flow"

March 12, 2014

Re: [Pharo-dev] Sort by property

by Otto Behrens

Why do we need one method that takes either a block or symbol? > SequenceableCollection>>sortedAs: aSortBlockOrSymbol Perhaps sort: can take a block and sortedAs: a symbol?

March 12, 2014

Making Git and Pharo More Accessible

by Sean P. DeNigris

Two things: - Are the current git workflow options documented anywhere besides our mailing lists? If not, will someone who has been using Git successfully capture their process somewhere more permanent... - Can "we" (proverbially, not that I'm intending to help ;)) make a git-ready image on the community CI server? TIA ----- Cheers, Sean -- View this message in context: http://forum.world.st/Making-Git-and-Pharo-More-Accessible-tp4748695.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 12, 2014

Re: [Pharo-dev] Touch Events VM changes

by phil＠highoctane.be

I have a pretty decent lineup of devices with touch. The interactions aren't the same on the iPhone as they are on a Galaxy SII phone, not are the same on iPads or on a Nexus7. Magic mouses are also special things. Also my Samsung Windows 8 laptop has a 10 points touch screen. With Windows8.1, I find myself using swipes and touches for a lot of things. And it improves my productivity. Once equipped with a thing like Classic Shell and boot into the desktop right away, Metro apps are really nice little things running in the background and can come fast with a little swipe (cool ones: Skype, Music, PDF reader of a documentation, like a chapter of a Pharo book: swipe: PDF, swipe: Pharo, swiper: PDF... and mouse pointer not moving around). When using my MacBook Pro, I am reaching for the screen and being disappointed to realize it is not touch (Apple, give us touch screens on laptops). Form factors affect the usage patterns as well. But touch is not going displace touchpads or mouses for fine grained control. On the contrary, I tested a Leap motion controller and it felt like crap. Phil On Tue, Mar 11, 2014 at 12:54 PM, J.F. Rick <self(a)je77.com> wrote: > Hi Sergi, > > Based on my experience developing touch interfaces since 2007, I believe > in touch. I believe it will be the future of interfaces and I believe it > can be better than mouse-keyboard interfaces. That said, it is not there > yet. Now is the time to innovate and get it there so that touch interfaces > won't be poor replicas of their desktop forebears. Currently, text entry is > a real problem for touch exclusive devices, but there is progress being > made on that front. We don't have the answer yet but I think it will be a > significantly different landscape in five years. In regards to touch vs > physical pointers, this is not as large of a problem as people make it out > to be. It is just that our widgets tend to be created for mouse-based > interfaces and therefore don't transition well to touch. Interfaces > designed with touch in mind can be just as smooth (if not smoother) as > mouse-based interfaces. You just have to take advantage of what touch does > well (faster, more precise routes; multi-touch gestures; bimanual > interaction) and stay clear of things it does poorly (precise touch down, > covering the target with the finger). > > Cheers, > > Jeff > > > On Tue, Mar 11, 2014 at 12:34 PM, Sergi Reyner <sergi.reyner(a)gmail.com>wrote: > >> 2014-03-11 10:37 GMT+00:00 J.F. Rick <self(a)je77.com>: >> >> As we move from mouse-keyboard devices to touch-based ones >> >> >> I certainly hope that "we" refers to a small group of people, unless we >> get onscreen keyboards as good as physical ones, feedback included. The >> same goes for touch versus physical pointer :) >> >> Cheers, >> Sergi >> > > > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick >

March 11, 2014

Re: [Pharo-dev] Touch Events VM changes

by phil＠highoctane.be

I've got a Windows 8 laptop with a touch screen. So, I now have to look how the events are provided. Phil On Tue, Mar 11, 2014 at 12:03 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > Hi, > > I agree that we need a unified event model. Now... our vision is to solve > that in image side, not in vm (and vm should send the raw events "as is"). > The reason of why we want it in image is easy: image means pharo, and it > means more hands (or eyes) over it. Then is easier to maintain :) > Anyway, we are slowly working on it (See Igor & Ronnie work around > OSWindow). But is probably too slow :) > > Esteban > > On 11 Mar 2014, at 11:37, J.F. Rick <self(a)je77.com> wrote: > > As we move from mouse-keyboard devices to touch-based ones, it would be > nice if we could unify touch development across the different Pharo > platforms (iOS, Android, Windows 8, Linux, etc.), so that we can start to > build touch-aware widgets and frameworks. Currently, there's a lot of > interest but no unified movement. For instance, I've got a very nice > multi-touch 27" computer that I run in Linux. I develop the applications in > Pharo but I currently use a hack to get the touch events: I use OSProcess > to start the mtdev2tuio application that takes touch input and sends it via > TUIO. I then use a UDP socket to read the events on Pharo. If I am to share > my work, I need to get beyond the hack. I (or rather Igor as I watched) > investigated the possibility of using NativeBoost calls to do the same, but > it would not work since mtdev2tuio has to run as superuser, meaning Pharo > would have to run as superuser. We came to the conclusion that this must be > a VM-level change. > > I'm not a VM hacker but would like to reach the people who maintain the > linux and windows VM to see if this might not be a reasonable addition to > the standard VM. There does seem to be standard support for touch events in > XFree86, so it shouldn't be too large a change on Linux. I assume that > Windows 8 similarly makes touch events available. Is this the right place > to ask or is there another mailing list (e.g., the cog-vm)? > > Cheers, > > Jeff > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick > > >

March 11, 2014

Re: [Pharo-dev] [ANN] RenoirSt 1.0.0 Release for Pharo 3.0

by Sven Van Caekenberghe

Yes, there seems to be a hype of every improving documentation, blog posts, screen casts and so on. Could this be a sign of a maturing community ? Great work, Gabriel ! On 11 Mar 2014, at 22:06, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > Gabriel > > your tutorial is really cool :) > > Stef > > On 11 Mar 2014, at 21:04, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > >> Gabriel >> >> I would love to write a chapter based on your tutorial for the next book. >> Is it ok for you? >> I can do that during a boring meeting. :) >> Stef >> >> On 11 Mar 2014, at 14:13, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >> >>> Hi, >>> >>> I'm announcing the first official release of RenoirSt, a DSL enabling programmatic cascading style sheet generation for Pharo. >>> >>> For the impatient, you can load it in your 3.0 image evaluating: >>> >>> Gofer it >>> url: 'http://smalltalkhub.com/mc/gcotelli/RenoirSt/main'; >>> configurationOf: 'RenoirSt'; >>> loadStable >>> >>> or download a ready to use image from the Contribution CI Server ( a ConfigurationBrowser option comming soon). >>> >>> Visit the project page and GitHub repository for more information on the supported and planned features, and check-out the online tutorial. >>> >>> I hope you find it useful. Feel free to ask any questions, suggest ideas and improvements, or report bugs (the issue tracker is in GitHub). >>> >>> Gabriel >> >

March 11, 2014

Re: [Pharo-dev] Sort by property

by Carlo

Hi Since Symbol and Blocks are polymorphic could we not simplify the code to be: SequenceableCollection>>sortedAs: aSortBlockOrSymbol "Answer a SortedCollection whose elements are the elements of the receiver. The sort order is defined by the argument, aSortBlockOrSymbol. The receiver cannot be empty. Answer a new collection. This method does not side effect the receiver. e.g. SequenceableCollection withAllSubclasses sortedAs: #name. SequenceableCollection withAllSubclasses sortedAs: [:class | class methodDict size]." | aSortBlock | aSortBlock := (#(true false ) includes: (aSortBlockOrSymbol value: self first)) ifTrue: [[:a :b | aSortBlockOrSymbol value: a]] ifFalse: [[:a :b | (aSortBlockOrSymbol value: a) < (aSortBlockOrSymbol value: b)]]. ^ (SortedCollection new: self size) sortBlock: aSortBlock; addAll: self; yourself Cheers Carlo On 12 Mar 2014, at 12:32 AM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: Thanks eliot. On 11 Mar 2014, at 20:51, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > and here's one with a better comment that includes examples > > > On Tue, Mar 11, 2014 at 12:19 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Alexandre, > > IMO the isKindOf:, apart from being ugly, will hurt performance badly. Why not apply aSortBlockOrSymbol to the first element and then choose the block appropriately? e.g. > > aSortBlockOrSymbol isSymbol > ifTrue: > [(#(true false) includes: (self first perform: aSortBlockOrSymbol) > ifTrue: > [[:a :b | (a perform: aSortBlockOrSymbol)]] > ifFalse: > [[:a :b | (a perform: aSortBlockOrSymbol) < (b perform: aSortBlockOrSymbol)]]] > ... > > Nicer to read and faster, no? > > On Tue, Mar 11, 2014 at 8:17 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > hi Uko, > > For Roassal, we have a #sortedAs: defined on all collections > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > SequenceableCollection>>sortedAs: aSortBlockOrSymbol > "Answer a SortedCollection whose elements are the elements of the > receiver. The sort order is defined by the argument, aSortBlock." > "Return a new collection. This method does not do a side effect" > > | aSortedCollection aSortBlock | > aSortedCollection := SortedCollection new: self size. > aSortBlock := > aSortBlockOrSymbol isSymbol > ifTrue: [ [:a :b | |t1 t2| > t1 := (a perform: aSortBlockOrSymbol). > t2 := (b perform: aSortBlockOrSymbol). > ((t1 isKindOf: Boolean) and: [t2 isKindOf: Boolean]) > ifTrue: [ t1 ] > ifFalse: [ t1 < t2 ] ] ] > ifFalse: [ > (aSortBlockOrSymbol numArgs = 1) > ifTrue: [ [ :v1 :v2 | (aSortBlockOrSymbol value: v1) < (aSortBlockOrSymbol value: v2) ] ] > ifFalse: [ aSortBlockOrSymbol ] ]. > aSortedCollection sortBlock: aSortBlock. > aSortedCollection addAll: self. > ^ aSortedCollection > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > You can use it for example: > (1 to: 4) sortedAs: #odd > => a SortedCollection(1 3 2 4) > > Collection withAllSubclasses sortedAs: #numberOfMethods > => a SortedCollection(HashBag IdentityHashBag â¦) > > This is really handy. It should be part of Pharo I believe. > > Cheers, > Alexandre > > > On Mar 11, 2014, at 5:19 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > Hi guys. > > > > This is a thing that I encounter quite often. > > > > Eg I have a collection of projects and I want to sort them by creation date. It would be nice to be able to do something like: > > > > projects sortByProp: #creationDate > > > > or by birth date of the author > > > > projects sortByProp: [ :proj | proj author birthDate ] > > > > Maybe Iâm wrong, but as Iâve told already I encounter it quite often and writing something like > > > > projects sortBy: [ :prev :next | prev creationDate <= next creationDate ] > > > > is boring for me. > > > > Cheers. > > Uko > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > -- > best, > Eliot > > > > -- > best, > Eliot > <SequenceableCollection-sortedAs.st>

March 11, 2014

Re: [Pharo-dev] Sort by property

by Pharo4Stef

Thanks eliot. On 11 Mar 2014, at 20:51, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > and here's one with a better comment that includes examples > > > On Tue, Mar 11, 2014 at 12:19 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Alexandre, > > IMO the isKindOf:, apart from being ugly, will hurt performance badly. Why not apply aSortBlockOrSymbol to the first element and then choose the block appropriately? e.g. > > aSortBlockOrSymbol isSymbol > ifTrue: > [(#(true false) includes: (self first perform: aSortBlockOrSymbol) > ifTrue: > [[:a :b | (a perform: aSortBlockOrSymbol)]] > ifFalse: > [[:a :b | (a perform: aSortBlockOrSymbol) < (b perform: aSortBlockOrSymbol)]]] > ... > > Nicer to read and faster, no? > > On Tue, Mar 11, 2014 at 8:17 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > hi Uko, > > For Roassal, we have a #sortedAs: defined on all collections > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > SequenceableCollection>>sortedAs: aSortBlockOrSymbol > "Answer a SortedCollection whose elements are the elements of the > receiver. The sort order is defined by the argument, aSortBlock." > "Return a new collection. This method does not do a side effect" > > | aSortedCollection aSortBlock | > aSortedCollection := SortedCollection new: self size. > aSortBlock := > aSortBlockOrSymbol isSymbol > ifTrue: [ [:a :b | |t1 t2| > t1 := (a perform: aSortBlockOrSymbol). > t2 := (b perform: aSortBlockOrSymbol). > ((t1 isKindOf: Boolean) and: [t2 isKindOf: Boolean]) > ifTrue: [ t1 ] > ifFalse: [ t1 < t2 ] ] ] > ifFalse: [ > (aSortBlockOrSymbol numArgs = 1) > ifTrue: [ [ :v1 :v2 | (aSortBlockOrSymbol value: v1) < (aSortBlockOrSymbol value: v2) ] ] > ifFalse: [ aSortBlockOrSymbol ] ]. > aSortedCollection sortBlock: aSortBlock. > aSortedCollection addAll: self. > ^ aSortedCollection > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > You can use it for example: > (1 to: 4) sortedAs: #odd > => a SortedCollection(1 3 2 4) > > Collection withAllSubclasses sortedAs: #numberOfMethods > => a SortedCollection(HashBag IdentityHashBag â¦) > > This is really handy. It should be part of Pharo I believe. > > Cheers, > Alexandre > > > On Mar 11, 2014, at 5:19 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > Hi guys. > > > > This is a thing that I encounter quite often. > > > > Eg I have a collection of projects and I want to sort them by creation date. It would be nice to be able to do something like: > > > > projects sortByProp: #creationDate > > > > or by birth date of the author > > > > projects sortByProp: [ :proj | proj author birthDate ] > > > > Maybe Iâm wrong, but as Iâve told already I encounter it quite often and writing something like > > > > projects sortBy: [ :prev :next | prev creationDate <= next creationDate ] > > > > is boring for me. > > > > Cheers. > > Uko > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > -- > best, > Eliot > > > > -- > best, > Eliot > <SequenceableCollection-sortedAs.st>

March 11, 2014