June 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Modification on CollectionsExtensions

by Frank Shearar

#gather: directly applies the stream fusion technique as its implementation, so is faster than the current implementation of #flatCollect: Stef's saying "why not move #gather:'s implemenation to #flatCollect:, and make the old #gather: call the new #flatCollect:" frank On 12 June 2013 10:33, Sebastian Tleye <stleye(a)gmail.com> wrote: > As far as i know the implementation of gather: is faster than the > implementation of flatCollect: > > > 2013/6/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >> Why not the inverse. >> They are much more users of flatCollect: then gather: >> >> and again gather: sucks. It does not convey that this is a mapcan >> ie happening the results of each iteration into the >> >> So flatCollect: is 10 times more explicit and better. >> you flatten the results of the collect: >> >> Stef >> >> >> I think the simplest solution is to keep both and that flatCollect >> directly call gather: >> >> If you agree with that, I will correct the moose extension package >> >> >> 2013/6/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> >>> gather: sucks as a name. >>> flatCollect: is much better so do not remove it. >>> >>> On Jun 11, 2013, at 4:53 PM, Sebastian Tleye <stleye(a)gmail.com> wrote: >>> >>> If they are not different so a better way would be replace >>> #flatenCollect: by #gather: >>> but anyway, moose people should decide and commit the change since i am >>> not a moose developer. >>> >>> >>> 2013/6/11 Marcus Denker <marcus.denker(a)inria.fr> >>>> >>>> >>>> On Jun 11, 2013, at 4:24 PM, Frank Shearar <frank.shearar(a)gmail.com> >>>> wrote: >>>> >>>> > On 11 June 2013 14:18, Sebastian Tleye <stleye(a)gmail.com> wrote: >>>> >> Hello, >>>> >> >>>> >> Fixing some bugs in Traits we realized that it would be good idea to >>>> >> use >>>> >> CollectionsExtensions package (it has some useful functions), also it >>>> >> would >>>> >> be great to include CollectionsExtensions in Pharo 3.0. >>>> > >>>> > Is this the HPI library? I seem to recall TraitClasses [1] using it. >>>> >>>> CollectionExtension is from Moose. >>>> >>>> the Trait based Stream refactoring was done some years ago but has not >>>> been used >>>> or maintained. >>>> >>>> Marcus >>> >>> >>> >> >> >> >> -- >> Guillaume Larcheveque >> >> >

June 12, 2013

Re: [Pharo-dev] Modification on CollectionsExtensions

by Sebastian Tleye

As far as i know the implementation of gather: is faster than the implementation of flatCollect: 2013/6/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Why not the inverse. > They are much more users of flatCollect: then gather: > > and again gather: sucks. It does not convey that this is a mapcan > ie happening the results of each iteration into the > > So flatCollect: is 10 times more explicit and better. > you flatten the results of the collect: > > Stef > > > I think the simplest solution is to keep both and that flatCollect > directly call gather: > > If you agree with that, I will correct the moose extension package > > > 2013/6/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> gather: sucks as a name. >> flatCollect: is much better so do not remove it. >> >> On Jun 11, 2013, at 4:53 PM, Sebastian Tleye <stleye(a)gmail.com> wrote: >> >> If they are not different so a better way would be replace >> #flatenCollect: by #gather: >> but anyway, moose people should decide and commit the change since i am >> not a moose developer. >> >> >> 2013/6/11 Marcus Denker <marcus.denker(a)inria.fr> >> >>> >>> On Jun 11, 2013, at 4:24 PM, Frank Shearar <frank.shearar(a)gmail.com> >>> wrote: >>> >>> > On 11 June 2013 14:18, Sebastian Tleye <stleye(a)gmail.com> wrote: >>> >> Hello, >>> >> >>> >> Fixing some bugs in Traits we realized that it would be good idea to >>> use >>> >> CollectionsExtensions package (it has some useful functions), also it >>> would >>> >> be great to include CollectionsExtensions in Pharo 3.0. >>> > >>> > Is this the HPI library? I seem to recall TraitClasses [1] using it. >>> >>> CollectionExtension is from Moose. >>> >>> the Trait based Stream refactoring was done some years ago but has not >>> been used >>> or maintained. >>> >>> Marcus >>> >> >> >> > > > -- > *Guillaume Larcheveque* > > >

June 12, 2013

Cairo vs openGL

by StÃ©phane Ducasse

Hi I discuss with an graphics expert and he asked me why we went to use cairo vs opengl And I could not answer. Stef

June 12, 2013

Re: [Pharo-dev] Modification on CollectionsExtensions

by StÃ©phane Ducasse

Why not the inverse. They are much more users of flatCollect: then gather: and again gather: sucks. It does not convey that this is a mapcan ie happening the results of each iteration into the So flatCollect: is 10 times more explicit and better. you flatten the results of the collect: Stef > I think the simplest solution is to keep both and that flatCollect directly call gather: > > If you agree with that, I will correct the moose extension package > > > 2013/6/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > gather: sucks as a name. > flatCollect: is much better so do not remove it. > > On Jun 11, 2013, at 4:53 PM, Sebastian Tleye <stleye(a)gmail.com> wrote: > >> If they are not different so a better way would be replace #flatenCollect: by #gather: >> but anyway, moose people should decide and commit the change since i am not a moose developer. >> >> >> 2013/6/11 Marcus Denker <marcus.denker(a)inria.fr> >> >> On Jun 11, 2013, at 4:24 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> >> > On 11 June 2013 14:18, Sebastian Tleye <stleye(a)gmail.com> wrote: >> >> Hello, >> >> >> >> Fixing some bugs in Traits we realized that it would be good idea to use >> >> CollectionsExtensions package (it has some useful functions), also it would >> >> be great to include CollectionsExtensions in Pharo 3.0. >> > >> > Is this the HPI library? I seem to recall TraitClasses [1] using it. >> >> CollectionExtension is from Moose. >> >> the Trait based Stream refactoring was done some years ago but has not been used >> or maintained. >> >> Marcus >> > > > > > -- > Guillaume Larcheveque >

June 12, 2013

Re: [Pharo-dev] [ANN]: Magritte for Morphic (alpha)

by StÃ©phane Ducasse

On Jun 12, 2013, at 11:09 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-06-12, at 10:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Camillo >> >> First we should get the >> classBuilder > done > >> athens >> slots fully working > > requires a decent compiler (AKA Opal) for fancy slots. > Simple slots work perfectly. And "just" metadata on them will be enough to get something like magritte running in the core :). Here the question arises more on how to store this additional information in monticello.. the semantics of slot is not defined in method? Stef

June 12, 2013

Re: [Pharo-dev] [ANN]: Magritte for Morphic (alpha)

by Norbert Hartl

Am 12.06.2013 um 10:47 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Camillo > > First we should get the > classBuilder > athens > slots fully working > So it would be good to have that soon in 3.0 :) > > > then naturally people will build MagicMagicMagritte using slots because this will be really cool > Agreed. It will change a huge load of things. This is exciting! Norbert > > > On Jun 12, 2013, at 9:26 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> cool! >> >> I start to sound like a salesman for vaporware ;) but I think eventually we >> should replace Magritte with something more explicit directly on Slots + Layouts. >> >> That means you can model everything directly in Pharo without an extension... >> >> On 2013-06-12, at 08:52, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> Cool (music) indeed ! >>> >>> On 11 Jun 2013, at 23:18, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: >>> >>>> Tired of writing the same UI boilerplate over and over? I mean, basically an >>>> object has fields, which have certain properties relevant to the UI. If we >>>> could just capture that info once in the right place, a basic UI should >>>> almost fall out on its own. Magritte could be the answers to our lazy >>>> utopian dreams. The thing is that the Morphic implementation as fallen >>>> behind what can be done in Seaside... until now. I took a first pass at >>>> bringing Morphic up to date here. It doesn't seem like it will be too hard >>>> to have reasonably useful functionality. >>>> >>>> Here's a short screencast showing the improvements: >>>> http://vimeo.com/68166920 >>>> Magritte is an awesome framework to automate common UI tasks. Describe your >>>> object's field once, get views everywhere. Everywhere most commonly refers >>>> to both the web, via Seaside, and desktop via Morphic. But the Morphic >>>> implementation had fallen behind due to disuse. Now, some steps have been >>>> taken to bring the Morphic functionality up to date with that of Seaside. >> > >

June 12, 2013

Re: [Pharo-dev] Modification on CollectionsExtensions

by Sebastian Tleye

+1 2013/6/12 Guillaume Larcheveque <guillaume.larcheveque(a)gmail.com> > I think the simplest solution is to keep both and that flatCollect > directly call gather: > > If you agree with that, I will correct the moose extension package > > > 2013/6/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> gather: sucks as a name. >> flatCollect: is much better so do not remove it. >> >> On Jun 11, 2013, at 4:53 PM, Sebastian Tleye <stleye(a)gmail.com> wrote: >> >> If they are not different so a better way would be replace >> #flatenCollect: by #gather: >> but anyway, moose people should decide and commit the change since i am >> not a moose developer. >> >> >> 2013/6/11 Marcus Denker <marcus.denker(a)inria.fr> >> >>> >>> On Jun 11, 2013, at 4:24 PM, Frank Shearar <frank.shearar(a)gmail.com> >>> wrote: >>> >>> > On 11 June 2013 14:18, Sebastian Tleye <stleye(a)gmail.com> wrote: >>> >> Hello, >>> >> >>> >> Fixing some bugs in Traits we realized that it would be good idea to >>> use >>> >> CollectionsExtensions package (it has some useful functions), also it >>> would >>> >> be great to include CollectionsExtensions in Pharo 3.0. >>> > >>> > Is this the HPI library? I seem to recall TraitClasses [1] using it. >>> >>> CollectionExtension is from Moose. >>> >>> the Trait based Stream refactoring was done some years ago but has not >>> been used >>> or maintained. >>> >>> Marcus >>> >> >> >> > > > -- > *Guillaume Larcheveque* > >

June 12, 2013

Re: [Pharo-dev] [ANN]: Magritte for Morphic (alpha)

by Camillo Bruni

On 2013-06-12, at 10:47, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Camillo > > First we should get the > classBuilder done > athens > slots fully working requires a decent compiler (AKA Opal) for fancy slots. Simple slots work perfectly. And "just" metadata on them will be enough to get something like magritte running in the core :). Here the question arises more on how to store this additional information in monticello.. > So it would be good to have that soon in 3.0 :) > then naturally people will build MagicMagicMagritte using slots because this will be really cool exactly :)

June 12, 2013

Re: [Pharo-dev] Modification on CollectionsExtensions

by Guillaume Larcheveque

I think the simplest solution is to keep both and that flatCollect directly call gather: If you agree with that, I will correct the moose extension package 2013/6/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > gather: sucks as a name. > flatCollect: is much better so do not remove it. > > On Jun 11, 2013, at 4:53 PM, Sebastian Tleye <stleye(a)gmail.com> wrote: > > If they are not different so a better way would be replace #flatenCollect: > by #gather: > but anyway, moose people should decide and commit the change since i am > not a moose developer. > > > 2013/6/11 Marcus Denker <marcus.denker(a)inria.fr> > >> >> On Jun 11, 2013, at 4:24 PM, Frank Shearar <frank.shearar(a)gmail.com> >> wrote: >> >> > On 11 June 2013 14:18, Sebastian Tleye <stleye(a)gmail.com> wrote: >> >> Hello, >> >> >> >> Fixing some bugs in Traits we realized that it would be good idea to >> use >> >> CollectionsExtensions package (it has some useful functions), also it >> would >> >> be great to include CollectionsExtensions in Pharo 3.0. >> > >> > Is this the HPI library? I seem to recall TraitClasses [1] using it. >> >> CollectionExtension is from Moose. >> >> the Trait based Stream refactoring was done some years ago but has not >> been used >> or maintained. >> >> Marcus >> > > > -- *Guillaume Larcheveque*

June 12, 2013

Re: [Pharo-dev] [ANN]: Magritte for Morphic (alpha)

by StÃ©phane Ducasse

Camillo First we should get the classBuilder athens slots fully working So it would be good to have that soon in 3.0 :) then naturally people will build MagicMagicMagritte using slots because this will be really cool Stef On Jun 12, 2013, at 9:26 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > cool! > > I start to sound like a salesman for vaporware ;) but I think eventually we > should replace Magritte with something more explicit directly on Slots + Layouts. > > That means you can model everything directly in Pharo without an extension... > > On 2013-06-12, at 08:52, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Cool (music) indeed ! >> >> On 11 Jun 2013, at 23:18, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: >> >>> Tired of writing the same UI boilerplate over and over? I mean, basically an >>> object has fields, which have certain properties relevant to the UI. If we >>> could just capture that info once in the right place, a basic UI should >>> almost fall out on its own. Magritte could be the answers to our lazy >>> utopian dreams. The thing is that the Morphic implementation as fallen >>> behind what can be done in Seaside... until now. I took a first pass at >>> bringing Morphic up to date here. It doesn't seem like it will be too hard >>> to have reasonably useful functionality. >>> >>> Here's a short screencast showing the improvements: >>> http://vimeo.com/68166920 >>> Magritte is an awesome framework to automate common UI tasks. Describe your >>> object's field once, get views everywhere. Everywhere most commonly refers >>> to both the web, via Seaside, and desktop via Morphic. But the Morphic >>> implementation had fallen behind due to disuse. Now, some steps have been >>> taken to bring the Morphic functionality up to date with that of Seaside. >

June 12, 2013