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

Re: [Pharo-dev] Modification on CollectionsExtensions

by StÃ©phane Ducasse

On Jun 12, 2013, at 1:02 PM, Sebastian Tleye <stleye(a)gmail.com> wrote: > ok, i understood, > > Discussing with Marcus we believe that it would be better to keep Collecition>>gather: and add Collection>>flatCollect: (with the same implementation) and put a comment in gather: saying that is kept for compatibility purposes. > > flatCollect: will be included in Pharo and will be removed from CollectionExtensions. > + 1 >

June 12, 2013

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

by Sean P. DeNigris

For Esteban ;) Much nicer (but not pretty yet) Date handling... <http://forum.world.st/file/n4692999/Screen_Shot_2013-06-12_at_9.08.47_AM.png> ----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-Magritte-for-Morphic-alpha-tp4692877p4692999.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 12, 2013

Re: [Pharo-dev] Cairo vs openGL

by S Krish

+1. Cairo for 2D and OpenGL for 3D / ( 2D if what Cairo provides is inadequate for that use case.. ) http://artgrammer.blogspot.in/2011/05/drawing-nearly-perfect-2d-line-segmen… On Wed, Jun 12, 2013 at 5:45 PM, ClÃ©ment Bera <bera.clement(a)gmail.com>wrote: > I asked Igor a few weeks ago. Basically his answers were : > > Cairo is for 2D. > OpenGL is for 3D. > > If you do 2D with openGL it is possible but much more complex : a lot of > API are missing fr 2D rendering. > Moreover, Cairo is faster for 2D. > > Then other guys than me can give other explanations. > > > 2013/6/12 kilon <thekilon(a)yahoo.co.uk> > >> I think its a smart move you started from cairo and then moved to opengl. >> Its >> possible afterall to mix cairo with opengl. I think its inevitable . It >> does >> not matter that opengl does not specialize on vector graphics, it can do >> vector graphics and offer massive accelerations in the process. >> >> As soon as I learn opengl my focus will be shifted to porting morphic (at >> least the base part) and drag Athens in the process. So tell your friend >> that opengl support is definetly coming ;) . Just dont tell him "soon" :D >> >> I am not going to be rewriting Cairo into smalltalk of course, or doing >> any >> kind of major coding / rewrite , just using the existing methods Cairo has >> for communicating with opengl. From the little I know it creates a quad >> polygon in opengl ,apply a texture on it and Cairo is used to draw the >> texture. >> >> One of things people who are not familiar with graphics is general are not >> aware of is the massive acceleration a GPU can give, that in some cases >> can >> outperform CPUs by 100 times. But thats not the mind blowing stuff, the >> mind >> blowing stuff is that this acceleration is not even graphics specific. >> CUDA >> technology is already used in physics, maths and other extremely demanding >> computing tasks. Pharo can tap on this massive power (eg . language >> parsers >> ) that is even available even on 100 euros nvidia cards and soon will be >> available for every pc and mac out there for peanuts. Probably its a >> matter >> of time before penetrate the mobile market too. >> >> We coders in blender (3d app) have already seen blender's new render >> engine >> offer the unthinkable , real time full renders with minor delays using the >> CUDA technology through the new render engine called "cycles". The >> previous >> render engine would take at least minutes to offer a same quality render, >> so >> its a massive move forward. >> >> So my conclusion is that eveything has its place . Cairo + Opengl + CUDA , >> makes a trio of ustopable benefits that pharo cannot afford to ignore in >> any >> case. I will try to offer my little part in this process, it wont be easy >> I >> know , it could take years, but it will certainly be a lot of fun . >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Pharo-dev-Cairo-vs-openGL-tp4692947p4692975.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> > > > -- > ClÃ©ment BÃ©ra > Mate Virtual Machine Engineer > BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq* >

June 12, 2013

Re: [Pharo-dev] Cairo vs openGL

by ClÃ©ment Bera

I asked Igor a few weeks ago. Basically his answers were : Cairo is for 2D. OpenGL is for 3D. If you do 2D with openGL it is possible but much more complex : a lot of API are missing fr 2D rendering. Moreover, Cairo is faster for 2D. Then other guys than me can give other explanations. 2013/6/12 kilon <thekilon(a)yahoo.co.uk> > I think its a smart move you started from cairo and then moved to opengl. > Its > possible afterall to mix cairo with opengl. I think its inevitable . It > does > not matter that opengl does not specialize on vector graphics, it can do > vector graphics and offer massive accelerations in the process. > > As soon as I learn opengl my focus will be shifted to porting morphic (at > least the base part) and drag Athens in the process. So tell your friend > that opengl support is definetly coming ;) . Just dont tell him "soon" :D > > I am not going to be rewriting Cairo into smalltalk of course, or doing any > kind of major coding / rewrite , just using the existing methods Cairo has > for communicating with opengl. From the little I know it creates a quad > polygon in opengl ,apply a texture on it and Cairo is used to draw the > texture. > > One of things people who are not familiar with graphics is general are not > aware of is the massive acceleration a GPU can give, that in some cases can > outperform CPUs by 100 times. But thats not the mind blowing stuff, the > mind > blowing stuff is that this acceleration is not even graphics specific. CUDA > technology is already used in physics, maths and other extremely demanding > computing tasks. Pharo can tap on this massive power (eg . language parsers > ) that is even available even on 100 euros nvidia cards and soon will be > available for every pc and mac out there for peanuts. Probably its a matter > of time before penetrate the mobile market too. > > We coders in blender (3d app) have already seen blender's new render engine > offer the unthinkable , real time full renders with minor delays using the > CUDA technology through the new render engine called "cycles". The previous > render engine would take at least minutes to offer a same quality render, > so > its a massive move forward. > > So my conclusion is that eveything has its place . Cairo + Opengl + CUDA , > makes a trio of ustopable benefits that pharo cannot afford to ignore in > any > case. I will try to offer my little part in this process, it wont be easy I > know , it could take years, but it will certainly be a lot of fun . > > > > -- > View this message in context: > http://forum.world.st/Pharo-dev-Cairo-vs-openGL-tp4692947p4692975.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- ClÃ©ment BÃ©ra Mate Virtual Machine Engineer BÃ¢timent B 40, avenue Halley 59650 *Villeneuve d'Ascq*

June 12, 2013

Re: [Pharo-dev] Cairo vs openGL

by kilon

I think its a smart move you started from cairo and then moved to opengl. Its possible afterall to mix cairo with opengl. I think its inevitable . It does not matter that opengl does not specialize on vector graphics, it can do vector graphics and offer massive accelerations in the process. As soon as I learn opengl my focus will be shifted to porting morphic (at least the base part) and drag Athens in the process. So tell your friend that opengl support is definetly coming ;) . Just dont tell him "soon" :D I am not going to be rewriting Cairo into smalltalk of course, or doing any kind of major coding / rewrite , just using the existing methods Cairo has for communicating with opengl. From the little I know it creates a quad polygon in opengl ,apply a texture on it and Cairo is used to draw the texture. One of things people who are not familiar with graphics is general are not aware of is the massive acceleration a GPU can give, that in some cases can outperform CPUs by 100 times. But thats not the mind blowing stuff, the mind blowing stuff is that this acceleration is not even graphics specific. CUDA technology is already used in physics, maths and other extremely demanding computing tasks. Pharo can tap on this massive power (eg . language parsers ) that is even available even on 100 euros nvidia cards and soon will be available for every pc and mac out there for peanuts. Probably its a matter of time before penetrate the mobile market too. We coders in blender (3d app) have already seen blender's new render engine offer the unthinkable , real time full renders with minor delays using the CUDA technology through the new render engine called "cycles". The previous render engine would take at least minutes to offer a same quality render, so its a massive move forward. So my conclusion is that eveything has its place . Cairo + Opengl + CUDA , makes a trio of ustopable benefits that pharo cannot afford to ignore in any case. I will try to offer my little part in this process, it wont be easy I know , it could take years, but it will certainly be a lot of fun . -- View this message in context: http://forum.world.st/Pharo-dev-Cairo-vs-openGL-tp4692947p4692975.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 12, 2013

Re: [Pharo-dev] Modification on CollectionsExtensions

by Sebastian Tleye

sorry, gather will call flatCollect: is not the same code. 2013/6/12 Sebastian Tleye <stleye(a)gmail.com> > ok, i understood, > > Discussing with Marcus we believe that it would be better to keep > Collecition>>gather: and add Collection>>flatCollect: (with the same > implementation) and put a comment in gather: saying that is kept for > compatibility purposes. > > flatCollect: will be included in Pharo and will be removed from > CollectionExtensions. > > > > > 2013/6/12 Frank Shearar <frank.shearar(a)gmail.com> > >> On 12 June 2013 10:54, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> > #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:" >> >> Er, and that would mean moving #flatCollect: out of >> CollectionsExtensions into the base image. >> >> > 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] ZeroConf and write permission

by Sean P. DeNigris

Frank Shearar-3 wrote > Or curl http://get.pharo.org/vm | sudo bash. Ha ha, I see Frank beat me to it ;) ----- Cheers, Sean -- View this message in context: http://forum.world.st/ZeroConf-and-write-permission-tp4692903p4692972.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 12, 2013

Re: [Pharo-dev] ZeroConf and write permission

by Sean P. DeNigris

Camillo Bruni-3 wrote > => > http://stackoverflow.com/questions/5560442/how-to-run-two-commands-in-sudo Thank you for not GTFAing me ;) It was a long day. Now that I remember how to search, how about (from http://innovationsts.com/?p=2758) curl get.pharo.org/vm | sudo bash Camillo Bruni-3 wrote > BTW the "-L" option is no longer needed ;) ZeroConf is getting simpler and simpler! https://pharo.fogbugz.com/f/cases/10891/Zeroconf-Remove-L-from-Help ----- Cheers, Sean -- View this message in context: http://forum.world.st/ZeroConf-and-write-permission-tp4692903p4692969.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 12, 2013

Re: [Pharo-dev] Modification on CollectionsExtensions

by Sebastian Tleye

ok, i understood, Discussing with Marcus we believe that it would be better to keep Collecition>>gather: and add Collection>>flatCollect: (with the same implementation) and put a comment in gather: saying that is kept for compatibility purposes. flatCollect: will be included in Pharo and will be removed from CollectionExtensions. 2013/6/12 Frank Shearar <frank.shearar(a)gmail.com> > On 12 June 2013 10:54, Frank Shearar <frank.shearar(a)gmail.com> wrote: > > #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:" > > Er, and that would mean moving #flatCollect: out of > CollectionsExtensions into the base image. > > > 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] ZeroConf and write permission

by Frank Shearar

On 12 June 2013 11:51, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-06-12, at 12:49, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> On 12 June 2013 11:40, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> >>> On 2013-06-12, at 12:13, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>> >>>> Or curl http://get.pharo.org/vm | sudo bash. >>> >>> that was my first guess, but it didn't work under my zsh shell and mac... >> >> Strange. It works in bash. > > I have to enter a password for sudo, maybe it's that? I had to, too. Er, hang on. I ran `echo "foo" | sugo grep f` first, so when I actually ran the curl stuff I didn't have to enter a password. frank

June 12, 2013