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

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

by Pharo4Stef

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] [Pharo-users] Phratch one-click

by jannik laval

Hi Hilaire, 2014-03-11 17:27 GMT+01:00 Hilaire Fernandes <hilaire.fernandes(a)gmail.com>: > Hi Jannik, > > Don't use the change/update event mecanism. > This mean a lot of changes in your model. > Yes, this is what I understand :) > In DrGeo I use a simple loop to update the sketch, but i guess it is > more complicated with Pratch as you have parallel threads. In the other > hand, is the original Scratch implemented with change/update? If so why > it is not as slow? > I don't know why, probably due to the evolution of Pharo. But, with JB we found some code that we changed: now it is really faster. It is integrated in Phratch2.0. We also saw a lot of other things to improve, it will come soon. Cheers, Jannik > > Hilaire > > > Le 06/03/2014 20:42, jannik laval a Ã©crit : > > Hi Hilaire, > > > > Hum, probably this comes from there... > > Could you explain a bit more how to change it ? > > > > Cheers, > > Jannik > > > > > > 2014-03-05 11:19 GMT+01:00 Hilaire Fernandes > > <hilaire.fernandes(a)gmail.com > > <mailto:hilaire.fernandes@gmail.com>>: > > > > For event, how is it developed? > > > > I remember, when I started developing DrGeo I used the change/update > > event mecanism. Then I dropped it for a simple linear top/down > update of > > the geometric tree model, it becames much faster after that. > > > > Hilaire > > > > Le 05/03/2014 10:44, jannik laval a Ã©crit : > > > > > > I think now that we need some profiling. > > > Any expert for that ? > > > > > > > -- > > Dr. Geo http://drgeo.eu > > > > > > > > > > > > -- > > > > ~~Jannik Laval~~ > > Ãcole des Mines de Douai > > Enseignant-chercheur > > http://www.jannik-laval.eu > > http://car.mines-douai.fr/ > > > > -- > Dr. Geo http://drgeo.eu > > > -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/

March 11, 2014

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

by Pharo4Stef

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] [ANN] RenoirSt 1.0.0 Release for Pharo 3.0

by Pharo4Stef

Hi torsten for what is the px unit stand for? Stef On 11 Mar 2014, at 16:07, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Gabriel, > > nice work - now designers should start learning Smalltalk to be able to refactor large > style definitions :) > > Some feedback: > ============= > the new "RenoirSt" project unfortunately conflicts with the "Unit" package when both get loaded from the > config browser in Pharo 3.0: > > - RenoirSt loaded: "2 px" returns an instance of CssLength (px is an extension method on Integer) > - Units loaded: "2 px" returns an instance of UnitValue (px is an extension method on Number) > as you have defined own custom "units" in category "RenoirSt-Units". > > I would really like to see that RenoirSt is reusing the common Units package instead of reinventing/conflicting > as the Unit package already provides pixels, millimeters, ... support including conversion. Reuse is key > and would avoid duplicated effort. > > For instance Artefact, the PDF framework is using Units as a prerequisite already too - as it also > has to deal with mm, pixels, points, ... > > Should be no problem to add missing CSS lengths like #em to Units project as well. Just ask Marcus Denker > to add you as a contributor to http://smalltalkhub.com/#!/~MarcusDenker/Units/ > Then add Units as a prerequisite similar to ConfigurationOfArtefact and use it in your code. > > Regarding features: > =================== > For Seaside there is a project called "Seafox" generating Seaside #renderContentOn: methods from > HTML. http://lists.squeakfoundation.org/pipermail/seaside/2010-August/023993.html > > Maybe you want to build something similar for #cssContentOn: to support a better roundtrip with designers. > > Bye > T. > > > Gesendet: Dienstag, 11. MÃ¤rz 2014 um 14:13 Uhr > Von: "Gabriel Cotelli" <g.cotelli(a)gmail.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: [Pharo-dev] [ANN] RenoirSt 1.0.0 Release for Pharo 3.0 > > 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[https://ci.inria.fr/pharo-contribution/job/RenoirSt/] ( a ConfigurationBrowser option comming soon). > > Visit the project page[http://gcotelli.github.io/RenoirSt/] and GitHub repository[https://github.com/gcotelli/RenoirSt] for more information on the supported and planned features, and check-out the online tutorial.[https://github.com/gcotelli/RenoirSt/blob/stable/docs/tutorial/Tu… > > 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 Eliot Miranda

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

March 11, 2014

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

by Gabriel Cotelli

Thank you Torsten. Issues #21 and #22 added to reflect this feedback and further research. On Tue, Mar 11, 2014 at 12:07 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Gabriel, > > nice work - now designers should start learning Smalltalk to be able to > refactor large > style definitions :) > > Some feedback: > ============= > the new "RenoirSt" project unfortunately conflicts with the "Unit" package > when both get loaded from the > config browser in Pharo 3.0: > > - RenoirSt loaded: "2 px" returns an instance of CssLength (px is an > extension method on Integer) > - Units loaded: "2 px" returns an instance of UnitValue (px is an > extension method on Number) > as you have defined own custom "units" in category "RenoirSt-Units". > > I would really like to see that RenoirSt is reusing the common Units > package instead of reinventing/conflicting > as the Unit package already provides pixels, millimeters, ... support > including conversion. Reuse is key > and would avoid duplicated effort. > > For instance Artefact, the PDF framework is using Units as a prerequisite > already too - as it also > has to deal with mm, pixels, points, ... > > Should be no problem to add missing CSS lengths like #em to Units project > as well. Just ask Marcus Denker > to add you as a contributor to > http://smalltalkhub.com/#!/~MarcusDenker/Units/ > Then add Units as a prerequisite similar to ConfigurationOfArtefact and > use it in your code. > > Regarding features: > =================== > For Seaside there is a project called "Seafox" generating Seaside > #renderContentOn: methods from > HTML. > http://lists.squeakfoundation.org/pipermail/seaside/2010-August/023993.html > > Maybe you want to build something similar for #cssContentOn: to support a > better roundtrip with designers. > > Bye > T. > > > Gesendet: Dienstag, 11. MÃ¤rz 2014 um 14:13 Uhr > Von: "Gabriel Cotelli" <g.cotelli(a)gmail.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: [Pharo-dev] [ANN] RenoirSt 1.0.0 Release for Pharo 3.0 > > 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[ > https://ci.inria.fr/pharo-contribution/job/RenoirSt/] ( a > ConfigurationBrowser option comming soon). > > Visit the project page[http://gcotelli.github.io/RenoirSt/] and GitHub > repository[https://github.com/gcotelli/RenoirSt] for more information on > the supported and planned features, and check-out the online tutorial.[ > https://github.com/gcotelli/RenoirSt/blob/stable/docs/tutorial/Tutorial%20-… > ] > > 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 Eliot Miranda

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

March 11, 2014

Re: [Pharo-dev] About inspectors

by Tudor Girba

Hi Juan, Just download the latest Moose image and you can explore the file system. Cheers, Doru On Tue, Mar 11, 2014 at 6:17 PM, Juan <smalltalker.marcelo(a)gmail.com> wrote: > Tudor > > > what steps I need to follow to load the file-exploration example of > video ? > any ConfigurationOfxx . package, monticello repository etc... > > best > > > jmdc > > > On Tue, Mar 11, 2014 at 2:11 PM, Juan <smalltalker.marcelo(a)gmail.com>wrote: > >> Tudor >> >> Thanks for amazing work, just report a trouble , i follow the >> http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-… >> Instructions and trying with one postgres database, one table with date >> fields fire problem's SqNumberParser class is missing in moose image, and >> the postgres >> use this to read dates or timestamps fields . >> >> best regards >> jmdc >> >> >> >> >> On Sun, Mar 9, 2014 at 7:06 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Thanks for the interest. >>> >>> I added now a new blog post in which I detail an investigation scenario >>> of a Postgres DB with the GTInspector: >>> >>> http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-… >>> >>> The post includes a video that kind of gets you through the most >>> important parts: >>> - use the playground >>> - query the DB and preview the results through dedicated presentations >>> - navigate through objects and code to learn the API >>> - build a visualization in place and continue exploration >>> - extend the inspector with a dedicated presentation >>> >>> Please let me know what you think. >>> >>> Cheers, >>> Doru >>> >>> >>> >>> On Sat, Mar 8, 2014 at 8:48 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: >>> >>>> Doru, >>>> >>>> Where to look on your blog for a view on the essentials of this? I see >>>> http://www.humane-assessment.com/blog/making-the-pharo-settings-browser-ope… example. A video? >>>> >>>> I look at the blog and vids but it is a bit hard to find a basic demo >>>> to grasp things. >>>> >>>> TIA >>>> Phil >>>> >>>> >>>> On Sat, Mar 8, 2014 at 8:16 AM, Tudor Girba <tudor(a)tudorgirba.com>wrote: >>>> >>>>> I hope not. What are we trying to optimize? >>>>> >>>>> If you look closely at the GT work, you might notice that it is not >>>>> just a tool, it's a whole new philosophy for coding. The EyeInspector >>>>> picked only one aspect out of a whole. >>>>> >>>>> One high goal is to change programming such that the inspector + >>>>> debugger to capture most of the coding experience. This is what live means. >>>>> Right now, in the default Pharo we only code small things in the debugger >>>>> and nothing in the inspector. We work on the idea of a moldable IDE that >>>>> will change all that. >>>>> >>>>> Let's look at some facts. Right now, in my image I have 75 different >>>>> extensions for GTInspector. And the total amount of lines of code has >>>>> barely passed 1000 LOC (including all utility code). These are not just >>>>> independent views, but they are combinable. The amount of use cases >>>>> supported span a wide range: querying source code, visualizing performance, >>>>> navigating file system, querying DB, and more (read the posts from >>>>> humane-assessment.com for hints in this direction). >>>>> >>>>> We programmed most of these extensions from within the inspector both >>>>> because it's fun and because it's significantly more productive. And I am >>>>> not the only one. This power is not serendipity, it's by design. And we >>>>> only started to untap this potential. >>>>> >>>>> There is still a long way for the concept of inspector and I believe >>>>> there is a large payoff in it, too. >>>>> >>>>> Optimizing for a small thing now should not be the way to go :) >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Mar 7, 2014 at 11:23 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: >>>>> >>>>>> Well I would hope that some kind of convergence would be possible in >>>>>> the future. Maybe some kind of abstract meta description like magritte, >>>>>> that different tools can use. >>>>>> >>>>>> On 07 Mar 2014, at 16:43, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>>>>> >>>>>> > Hi everyone. >>>>>> > >>>>>> > This day I've attended Moose dojo and I'm pretty impressed with the >>>>>> possibilities of GTInspector. The one thing that I've noticed is that both >>>>>> GTInspactor and EyeInspector support custom inspections for objects. I'm >>>>>> wandering if we can come up with a common protocol to give an object >>>>>> specific infector view, and not develop a separate thing for each inspector. >>>>>> > >>>>>> > Uko >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every thing has its own flow" >>>>> >>>> >>>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> > -- www.tudorgirba.com "Every thing has its own flow"

March 11, 2014

Re: [Pharo-dev] Sort by property

by Eliot Miranda

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

March 11, 2014

Re: [Pharo-dev] About inspectors

by Juan

Tudor what steps I need to follow to load the file-exploration example of video ? any ConfigurationOfxx . package, monticello repository etc... best jmdc On Tue, Mar 11, 2014 at 2:11 PM, Juan <smalltalker.marcelo(a)gmail.com> wrote: > Tudor > > Thanks for amazing work, just report a trouble , i follow the > http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-… > Instructions and trying with one postgres database, one table with date > fields fire problem's SqNumberParser class is missing in moose image, and > the postgres > use this to read dates or timestamps fields . > > best regards > jmdc > > > > > On Sun, Mar 9, 2014 at 7:06 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Thanks for the interest. >> >> I added now a new blog post in which I detail an investigation scenario >> of a Postgres DB with the GTInspector: >> >> http://www.humane-assessment.com/blog/dynamic-exploration-of-a-postgres-db-… >> >> The post includes a video that kind of gets you through the most >> important parts: >> - use the playground >> - query the DB and preview the results through dedicated presentations >> - navigate through objects and code to learn the API >> - build a visualization in place and continue exploration >> - extend the inspector with a dedicated presentation >> >> Please let me know what you think. >> >> Cheers, >> Doru >> >> >> >> On Sat, Mar 8, 2014 at 8:48 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: >> >>> Doru, >>> >>> Where to look on your blog for a view on the essentials of this? I see >>> http://www.humane-assessment.com/blog/making-the-pharo-settings-browser-ope… example. A video? >>> >>> I look at the blog and vids but it is a bit hard to find a basic demo to >>> grasp things. >>> >>> TIA >>> Phil >>> >>> >>> On Sat, Mar 8, 2014 at 8:16 AM, Tudor Girba <tudor(a)tudorgirba.com>wrote: >>> >>>> I hope not. What are we trying to optimize? >>>> >>>> If you look closely at the GT work, you might notice that it is not >>>> just a tool, it's a whole new philosophy for coding. The EyeInspector >>>> picked only one aspect out of a whole. >>>> >>>> One high goal is to change programming such that the inspector + >>>> debugger to capture most of the coding experience. This is what live means. >>>> Right now, in the default Pharo we only code small things in the debugger >>>> and nothing in the inspector. We work on the idea of a moldable IDE that >>>> will change all that. >>>> >>>> Let's look at some facts. Right now, in my image I have 75 different >>>> extensions for GTInspector. And the total amount of lines of code has >>>> barely passed 1000 LOC (including all utility code). These are not just >>>> independent views, but they are combinable. The amount of use cases >>>> supported span a wide range: querying source code, visualizing performance, >>>> navigating file system, querying DB, and more (read the posts from >>>> humane-assessment.com for hints in this direction). >>>> >>>> We programmed most of these extensions from within the inspector both >>>> because it's fun and because it's significantly more productive. And I am >>>> not the only one. This power is not serendipity, it's by design. And we >>>> only started to untap this potential. >>>> >>>> There is still a long way for the concept of inspector and I believe >>>> there is a large payoff in it, too. >>>> >>>> Optimizing for a small thing now should not be the way to go :) >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> >>>> On Fri, Mar 7, 2014 at 11:23 PM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: >>>> >>>>> Well I would hope that some kind of convergence would be possible in >>>>> the future. Maybe some kind of abstract meta description like magritte, >>>>> that different tools can use. >>>>> >>>>> On 07 Mar 2014, at 16:43, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>>>> >>>>> > Hi everyone. >>>>> > >>>>> > This day I've attended Moose dojo and I'm pretty impressed with the >>>>> possibilities of GTInspector. The one thing that I've noticed is that both >>>>> GTInspactor and EyeInspector support custom inspections for objects. I'm >>>>> wandering if we can come up with a common protocol to give an object >>>>> specific infector view, and not develop a separate thing for each inspector. >>>>> > >>>>> > Uko >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > >

March 11, 2014