May 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Recompile all in ImageForDevelopers ?

by Mariano Martinez Peck

2010/5/31 laurent laffont <laurent.laffont(a)gmail.com> > 2010/5/31 Mariano Martinez Peck <marianopeck(a)gmail.com> > >> Hi folks. The official Pharo 1.0 has a little bug that you can see here: >> >> http://code.google.com/p/pharo/issues/detail?id=2341 >> >> In order to avoid such problems, I though about evaluating "Compiler >> recompileAll" during the ImageForDeveloper >> install method >> With this, when I or you are using ConfigurationOfPharo to build a Dev >> image, you will automatically realize there is a problem. >> >> What do you think? >> > > How much time does it take ? > MessageTally time: [Compiler recompileAll] -> 116142 so...2 minutes ;) > > Laurent Laffont > > http://pharocasts.blogspot.com/ > http://magaloma.blogspot.com/ > > >> >> Cheers >> >> Mariano >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 31, 2010

Re: [Pharo-project] Recompile all in ImageForDevelopers ?

by laurent laffont

2010/5/31 Mariano Martinez Peck <marianopeck(a)gmail.com> > Hi folks. The official Pharo 1.0 has a little bug that you can see here: > > http://code.google.com/p/pharo/issues/detail?id=2341 > > In order to avoid such problems, I though about evaluating "Compiler > recompileAll" during the ImageForDeveloper >> install method > With this, when I or you are using ConfigurationOfPharo to build a Dev > image, you will automatically realize there is a problem. > > What do you think? > How much time does it take ? Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ > > Cheers > > Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 31, 2010

[Pharo-project] Recompile all in ImageForDevelopers ?

by Mariano Martinez Peck

Hi folks. The official Pharo 1.0 has a little bug that you can see here: http://code.google.com/p/pharo/issues/detail?id=2341 In order to avoid such problems, I though about evaluating "Compiler recompileAll" during the ImageForDeveloper >> install method With this, when I or you are using ConfigurationOfPharo to build a Dev image, you will automatically realize there is a problem. What do you think? Cheers Mariano

May 31, 2010

Re: [Pharo-project] Change Author full name prompt text in PharoCore 1.1

by StÃ©phane Ducasse

thanks! On May 31, 2010, at 7:35 AM, Miguel Enrique CobÃ¡ Martinez wrote: > I have changed the text of the message prompt and the text of the > setting for author full name in PharoCore 1.1 so that is similar > (shorter) to the text of PharoCore 1.0. > > Issue: > http://code.google.com/p/pharo/issues/detail?id=2491 > > fixed in PharoInbox in: > > SLICE-rewriteAuthorMessageText-MiguelCoba.2 > > Ready for verification and integration. > > Cheers > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 31, 2010

Re: [Pharo-project] Trip to Pharo land

by StÃ©phane Ducasse

got it well don't worry. Stef On May 31, 2010, at 12:02 AM, GÃ¶ran Krampe wrote: > Hi! > > On 05/30/2010 11:17 PM, StÃ©phane Ducasse wrote: >>> Hi! >>> >>> So much discussion about that little post... :) >>> >>> On 05/30/2010 10:10 PM, StÃ©phane Ducasse wrote: >>>> Yes but in that case >>>> try 1.0 >>>> try 1.1 alpha >>> >>> Hmmm, Stephane still likes to top post I notice :) >> >> I do not know what you are implying. > > Eh, "top posting". See this: > > http://en.wikipedia.org/wiki/Posting_style > > So it was not an implication of anything, I just joked a little. > > ...but I see in this post that you are interleaving instead :) > >> But I think that we are trying to building a process for pharo >> so this discussion is only about that: what are the expectations of people and what can we deliver >> and if all these stuff make sense. >> Conclusion >> - we can only retrofit showstoppers fixes >> - even good documentation of changes may not make people not failed but we can try something simple. >> - short release cycles is a must and we are doing it now. > > Yeah, I am all with you. > > Just wondering if... well, I chose 1.0 since it is clearly what the website "wants me to do" so to speak. And 1.1 is mentioned as "bleeding edge" etc. > > But if you think I will have a smoother ride in 1.1, then perhaps the site should somehow indicate that. But again, I really don't know if that is a good idea. > >>> Anyway, Igor nailed it pretty good with his post actually - I was merely documenting "what I was trying to do and ended up doing". >>> >>> And one thing to note is that I should have tried 1.1. But... why didn't I? >>> > >> I really (stupid I know, but hey...) didn't think it was to be considered "outdated" already :) >> >> Yes it really is. >> Get the feel with 1.1. It is ***really*** better. > > Then perhaps you *should* write that on the website somehow. Like: > > "Even though 1.1 is still in alpha development we feel it is even in its current state a much better environment than 1.0 for development. But it is of course not yet a stable baseline." > > Also, if you only backport showstoppers (and not "bugs") then 1.0 is as of today not even preferrable from a stability standpoint, or? > > regards, GÃ¶ran > > PS. I am really trying to be constructive here, these problems are generic in nature and Squeak.org suffer from the exact same issues of course - devel vs stable etc. Just curious how Pharo should "talk to newcomers" about it. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 31, 2010

[Pharo-project] Change Author full name prompt text in PharoCore 1.1

by Miguel Enrique CobÃ¡ Martinez

I have changed the text of the message prompt and the text of the setting for author full name in PharoCore 1.1 so that is similar (shorter) to the text of PharoCore 1.0. Issue: http://code.google.com/p/pharo/issues/detail?id=2491 fixed in PharoInbox in: SLICE-rewriteAuthorMessageText-MiguelCoba.2 Ready for verification and integration. Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

May 31, 2010

Re: [Pharo-project] Trip to Pharo land

by GÃ¶ran Krampe

Hi! On 05/30/2010 11:17 PM, StÃ©phane Ducasse wrote: >> Hi! >> >> So much discussion about that little post... :) >> >> On 05/30/2010 10:10 PM, StÃ©phane Ducasse wrote: >>> Yes but in that case >>> try 1.0 >>> try 1.1 alpha >> >> Hmmm, Stephane still likes to top post I notice :) > > I do not know what you are implying. Eh, "top posting". See this: http://en.wikipedia.org/wiki/Posting_style So it was not an implication of anything, I just joked a little. ...but I see in this post that you are interleaving instead :) > But I think that we are trying to building a process for pharo > so this discussion is only about that: what are the expectations of people and what can we deliver > and if all these stuff make sense. > Conclusion > - we can only retrofit showstoppers fixes > - even good documentation of changes may not make people not failed but we can try something simple. > - short release cycles is a must and we are doing it now. Yeah, I am all with you. Just wondering if... well, I chose 1.0 since it is clearly what the website "wants me to do" so to speak. And 1.1 is mentioned as "bleeding edge" etc. But if you think I will have a smoother ride in 1.1, then perhaps the site should somehow indicate that. But again, I really don't know if that is a good idea. >> Anyway, Igor nailed it pretty good with his post actually - I was merely documenting "what I was trying to do and ended up doing". >> >> And one thing to note is that I should have tried 1.1. But... why didn't I? >> > I really (stupid I know, but hey...) didn't think it was to be considered "outdated" already :) > > Yes it really is. > Get the feel with 1.1. It is ***really*** better. Then perhaps you *should* write that on the website somehow. Like: "Even though 1.1 is still in alpha development we feel it is even in its current state a much better environment than 1.0 for development. But it is of course not yet a stable baseline." Also, if you only backport showstoppers (and not "bugs") then 1.0 is as of today not even preferrable from a stability standpoint, or? regards, GÃ¶ran PS. I am really trying to be constructive here, these problems are generic in nature and Squeak.org suffer from the exact same issues of course - devel vs stable etc. Just curious how Pharo should "talk to newcomers" about it.

May 30, 2010

Re: [Pharo-project] Trip to Pharo land

by Henrik Sperre Johansen

On 30.05.2010 23:17, StÃ©phane Ducasse wrote: >> Hi! >> >> So much discussion about that little post... :) >> >> On 05/30/2010 10:10 PM, StÃ©phane Ducasse wrote: >>> Yes but in that case >>> try 1.0 >>> try 1.1 alpha >> Hmmm, Stephane still likes to top post I notice :) > I do not know what you are implying. But I think that we are trying to building a process for pharo > so this discussion is only about that: what are the expectations of people and what can we deliver > and if all these stuff make sense. > Conclusion > - we can only retrofit showstoppers fixes > - even good documentation of changes may not make people not failed but we can try something simple. > - short release cycles is a must and we are doing it now. > >> Anyway, Igor nailed it pretty good with his post actually - I was merely documenting "what I was trying to do and ended up doing". >> >> And one thing to note is that I should have tried 1.1. But... why didn't I? >> >> I am not sure the website can/should be different - but fact remains that I got "fooled" by the fact that 1.0 was just released and I really (stupid I know, but hey...) didn't think it was to be considered "outdated" already :) > Yes it really is. > Get the feel with 1.1. It is ***really*** better. Sort of like 4.0 and 4.1, although the gap is a bit smaller :) Cheers, Henry

May 30, 2010

Re: [Pharo-project] Rome/Athens notes

by Igor Stasenko

On 31 May 2010 00:20, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On May 30, 2010, at 10:57 PM, Igor Stasenko wrote: > >> On 30 May 2010 23:08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> cool post >>> >> >> Yeah, these things are quite interesting. Except that not much people >> actually interested in it :) > > I do not think so. > Good posts are read more that you believe. Now in mailing-list the numbers of mails > cut the knowledge after a point. > But i posted here mainly to discuss these ideas. If we don't have a discussion, then we won't have a resolution, and its not matters how good post is or not, because a true value of any idea can be determined by considering all alternatives and discussing them. But maybe i'm a bit too hurry , because you mentioned that first things which needs to be done is to make current stuff working. The other thing is, that i am writing GL stuff from scratch (mostly), so i tend to pay more attention on design first, and then on implementation. >> Here's another thing, which can be done right (if we want). >> >> Rome/OpenVG Paths is actually nothing else than a special kind of more >> general thing - shape. >> >> So, at very basis, we should have only two components for painting: >> shape and paint. >> And in fact we need to support only a single operation: fill the shape >> with given paint. >> (The path stroke could be seen as a special kind of fill) >> >> >> So the question is: Really. Why we should constrain ourselves with >> specific things >> from a very starting, by cutting out a most basic (and abstact ideas) behind? >> >> There are infinite number of ways, how one could define a shape. >> While paths is only a small, yet effective representation of shapes. >> In same way there are infinite number of ways how one could define a paint. >> >> Then this looks like a strong basis for building-up a powerful & >> flexible graphics engine :) > > I do not know. Do the other frameworks outside smalltalk use something else > than paths? Yes. In 3D you have meshes, NURB surfaces , constructive-solid geometry and tons of other stuff. > I think that we should start > Â Â Â Â - making rome working. We are nearly there > Â Â Â Â - test it > Â Â Â Â - refactor it. > Â Â Â Â - I would like to see the canvas for morphic30 too. > Â Â Â Â - refactor the system to use that. > stef > Yes. Yes. Yes :) > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

May 30, 2010

Re: [Pharo-project] Rome/Athens notes

by StÃ©phane Ducasse

On May 30, 2010, at 10:57 PM, Igor Stasenko wrote: > On 30 May 2010 23:08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> cool post >> > > Yeah, these things are quite interesting. Except that not much people > actually interested in it :) I do not think so. Good posts are read more that you believe. Now in mailing-list the numbers of mails cut the knowledge after a point. > Here's another thing, which can be done right (if we want). > > Rome/OpenVG Paths is actually nothing else than a special kind of more > general thing - shape. > > So, at very basis, we should have only two components for painting: > shape and paint. > And in fact we need to support only a single operation: fill the shape > with given paint. > (The path stroke could be seen as a special kind of fill) > > > So the question is: Really. Why we should constrain ourselves with > specific things > from a very starting, by cutting out a most basic (and abstact ideas) behind? > > There are infinite number of ways, how one could define a shape. > While paths is only a small, yet effective representation of shapes. > In same way there are infinite number of ways how one could define a paint. > > Then this looks like a strong basis for building-up a powerful & > flexible graphics engine :) I do not know. Do the other frameworks outside smalltalk use something else than paths? I think that we should start - making rome working. We are nearly there - test it - refactor it. - I would like to see the canvas for morphic30 too. - refactor the system to use that. stef

May 30, 2010