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

Re: [Pharo-project] What about killing PharoWeb images?

by Lukas Renggli

> 1) First of all, I don't like the PharoWeb name. Because it is not Web in > general, it is seaside. So, in my opinion, a better name would be > PharoSeaside. Maybe even new comers may think that the only alternative is > seaside. You know I have nothing against Seaside and that I even use it > several times. I would like to see AidaWeb images based in Pharo too. I think at some point the images also contained AIDA. > 4) Now I created all the Metacello configurations for the PharoDev image and > I took me a lot of time. Because I am not the developer of any of those > projects. So, I need to understand the dependencies, the order, the > versions, etc. But why ??? If Seaside people have already done that, don't > duplicate efforts. There is a configuration for Seaside 3.0 (and probably also Seaside 2.8). This was probably the first configuration every written. Ask Dale. > 4) You may notice that Seaside images are a bit "different" than our Dev > images. This is mostly due to the preferences, the theme and maybe some > tools (ECompeltion instead of OCompletion, etc..). So, what I suggest is to > prepare a little script that can be downloadable and those people who want a > Seaside image but more "similar" to our Dev images, just run that script. They are different because they reflect my preferences. I basically build the Seaside images for me. If other people like and use these images, that's great of course. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 4, 2010

Re: [Pharo-project] about and:and: and and:

by StÃ©phane Ducasse

Nicolas I would love to get the latest version cleanup automatically If by accident a huge slice would be committed into the pharoInbox. what the others think? Stef On Jan 4, 2010, at 9:26 AM, Nicolas Cellier wrote: > My point was: > - these messages are Squeak specific > - they are slow (didn't knew about NewCompiler...) > - do they really add some value over nested and: ? > > Nicolas > > 2010/1/4 Lukas Renggli <renggli(a)gmail.com>: >> The NewCompiler optimizes #and:and:and: to an optimized and nested >> #and:. The standard compiler does a normal message send with block >> activations for each condition and thus is dead slow. >> >> Lukas >> >> 2010/1/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> hi nicolas >>> >>> I saw that you apply some automatic refactoring in squeak about and:and: -> and: >>> and I wanted to know. Is and: more optimized than and:and: (I imagine that) but I would like >>> to know for sure. >>> >>> Stef >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> 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

Jan. 4, 2010

Re: [Pharo-project] about and:and: and and:

by StÃ©phane Ducasse

Thanks lukas so we could get rid of them :) Stef On Jan 4, 2010, at 9:12 AM, Lukas Renggli wrote: > The NewCompiler optimizes #and:and:and: to an optimized and nested > #and:. The standard compiler does a normal message send with block > activations for each condition and thus is dead slow. > > Lukas > > 2010/1/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> hi nicolas >> >> I saw that you apply some automatic refactoring in squeak about and:and: -> and: >> and I wanted to know. Is and: more optimized than and:and: (I imagine that) but I would like >> to know for sure. >> >> Stef >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 4, 2010

Re: [Pharo-project] What about killing PharoWeb images?

by StÃ©phane Ducasse

On Jan 4, 2010, at 9:24 AM, Mariano Martinez Peck wrote: > Please, don't say "NOOOOO!" immediately. Read the mail carefully, take a deep breath and think cold. > > After working a couple of weeks in the Metacello configurations and now with Damien's scripts to build Dev and Web images, I came to the question: Do we really need a PharoWeb image? we dont :) I agree with you. > I will give just my opinions of why having PharoWeb images is not a good idea anymore > > 1) First of all, I don't like the PharoWeb name. Because it is not Web in general, it is seaside. So, in my opinion, a better name would be PharoSeaside. Maybe even new comers may think that the only alternative is seaside. You know I have nothing against Seaside and that I even use it several times. I would like to see AidaWeb images based in Pharo too. > > 2) Why to still have PharoWeb images if now Seaside images (at least the one click) are based in seaside ? In addition, when I develop in Seaside, I use Seaside images, not PharoWeb, and I think most people do the same. > > 3) Seaside images (or Lukas images for seaside) are MUCH more stable than the PharoWeb images. Why? Several reasons: > 3.a) THEY know the dependencies of the packages, the versions, how to set up, the order of load, etc, NOT us. THEY are the experts in seaside, not us. > 3.b) THEY really test their images before make then public. > 3.c) We are "force" to release one release per month which has no sense. How says that Seaside is released once a month? That's bad because it means we are usually taking unstable versions. THEY know when a release should be done and when a release is stable or not. > > 4) Now I created all the Metacello configurations for the PharoDev image and I took me a lot of time. Because I am not the developer of any of those projects. So, I need to understand the dependencies, the order, the versions, etc. But why ??? If Seaside people have already done that, don't duplicate efforts. > > 5) The instability of PharoWeb images give to our public a bad impression. We waste all of out efforts of Pharo in that image. > > 6) The idea of Pharo is to be the vehicle. And that's exactly the Pharo role in the Seaside images. We don't need to build PharoWeb images. > Even more, do we build PharoGlass images ? NOOOO. Why not ? Because Dale already prepare them and as HE knows much more about Glass than us, his images are better for Glass. > > 7) Tracking and managing issues always take time. Even analyzing a bug, say "we won't fix" and close it. With PharoWeb images we are having those kind of issues. > > 8) Our resources are limited. Why not to use them in more important stuff ? For example, building a better and more robust Dev image? > > > > Here is my proposal: > > 1) Completely remove the idea of PharoWeb image. Remove the links from the website and do not create Web images any more. > 2) In http://www.pharo-project.org/pharo-download add a description explaining that now Seaside images are based in Pharo, so you can directly download that image. We can even explain a bit about seaside, and even if you want you can put a href called "PharoWeb" which links to the seaside image. However, I would rather call it "PharoSeaside". > 3) Tomorrow we can have AidaWeb images based in pharo (please Janko!!) so we can just do the same and put the link to those images. > 4) You may notice that Seaside images are a bit "different" than our Dev images. This is mostly due to the preferences, the theme and maybe some tools (ECompeltion instead of OCompletion, etc..). So, what I suggest is to prepare a little script that can be downloadable and those people who want a Seaside image but more "similar" to our Dev images, just run that script. > > > So...what do you think? I would really like to hear your opinion about this. > > Cheers > > Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 4, 2010

Re: [Pharo-project] about and:and: and and:

by Nicolas Cellier

My point was: - these messages are Squeak specific - they are slow (didn't knew about NewCompiler...) - do they really add some value over nested and: ? Nicolas 2010/1/4 Lukas Renggli <renggli(a)gmail.com>: > The NewCompiler optimizes #and:and:and: to an optimized and nested > #and:. The standard compiler does a normal message send with block > activations for each condition and thus is dead slow. > > Lukas > > 2010/1/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> hi nicolas >> >> I saw that you apply some automatic refactoring in squeak about and:and: -> and: >> and I wanted to know. Is and: more optimized than and:and: (I imagine that) but I would like >> to know for sure. >> >> Stef >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 4, 2010

[Pharo-project] What about killing PharoWeb images?

by Mariano Martinez Peck

Please, don't say "NOOOOO!" immediately. Read the mail carefully, take a deep breath and think cold. After working a couple of weeks in the Metacello configurations and now with Damien's scripts to build Dev and Web images, I came to the question: Do we really need a PharoWeb image? I will give just my opinions of why having PharoWeb images is not a good idea anymore 1) First of all, I don't like the PharoWeb name. Because it is not Web in general, it is seaside. So, in my opinion, a better name would be PharoSeaside. Maybe even new comers may think that the only alternative is seaside. You know I have nothing against Seaside and that I even use it several times. I would like to see AidaWeb images based in Pharo too. 2) Why to still have PharoWeb images if now Seaside images (at least the one click) are based in seaside ? In addition, when I develop in Seaside, I use Seaside images, not PharoWeb, and I think most people do the same. 3) Seaside images (or Lukas images for seaside) are MUCH more stable than the PharoWeb images. Why? Several reasons: 3.a) THEY know the dependencies of the packages, the versions, how to set up, the order of load, etc, NOT us. THEY are the experts in seaside, not us. 3.b) THEY really test their images before make then public. 3.c) We are "force" to release one release per month which has no sense. How says that Seaside is released once a month? That's bad because it means we are usually taking unstable versions. THEY know when a release should be done and when a release is stable or not. 4) Now I created all the Metacello configurations for the PharoDev image and I took me a lot of time. Because I am not the developer of any of those projects. So, I need to understand the dependencies, the order, the versions, etc. But why ??? If Seaside people have already done that, don't duplicate efforts. 5) The instability of PharoWeb images give to our public a bad impression. We waste all of out efforts of Pharo in that image. 6) The idea of Pharo is to be the vehicle. And that's exactly the Pharo role in the Seaside images. We don't need to build PharoWeb images. Even more, do we build PharoGlass images ? NOOOO. Why not ? Because Dale already prepare them and as HE knows much more about Glass than us, his images are better for Glass. 7) Tracking and managing issues always take time. Even analyzing a bug, say "we won't fix" and close it. With PharoWeb images we are having those kind of issues. 8) Our resources are limited. Why not to use them in more important stuff ? For example, building a better and more robust Dev image? Here is my proposal: 1) Completely remove the idea of PharoWeb image. Remove the links from the website and do not create Web images any more. 2) In http://www.pharo-project.org/pharo-download add a description explaining that now Seaside images are based in Pharo, so you can directly download that image. We can even explain a bit about seaside, and even if you want you can put a href called "PharoWeb" which links to the seaside image. However, I would rather call it "PharoSeaside". 3) Tomorrow we can have AidaWeb images based in pharo (please Janko!!) so we can just do the same and put the link to those images. 4) You may notice that Seaside images are a bit "different" than our Dev images. This is mostly due to the preferences, the theme and maybe some tools (ECompeltion instead of OCompletion, etc..). So, what I suggest is to prepare a little script that can be downloadable and those people who want a Seaside image but more "similar" to our Dev images, just run that script. So...what do you think? I would really like to hear your opinion about this. Cheers Mariano

Jan. 4, 2010

Re: [Pharo-project] about and:and: and and:

by Lukas Renggli

The NewCompiler optimizes #and:and:and: to an optimized and nested #and:. The standard compiler does a normal message send with block activations for each condition and thus is dead slow. Lukas 2010/1/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > hi nicolas > > I saw that you apply some automatic refactoring in squeak about and:and: -> and: > and I wanted to know. Is and: more optimized than and:and: (I imagine that) but I would like > to know for sure. > > Stef > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 4, 2010

Re: [Pharo-project] Issue 1692: MNU when tried to navigate pop up menus with the keyboard

by Alain Plantec

Mariano Martinez Peck a Ã©crit : > > > On Mon, Jan 4, 2010 at 7:58 AM, Alain Plantec <alain.plantec(a)free.fr > <mailto:alain.plantec@free.fr>> wrote: > > Mariano Martinez Peck a Ã©crit : > > Hi Alain: This bug seems related with the new preference > architecture. > indeed, I will check that very soon. > > > Cool. Take it easy. No one is rushing :) SLICE-Issue1692-KeyboardFocusColor is in inbox. Thanks for reporting Alain > > > Alain > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

Jan. 4, 2010

Re: [Pharo-project] Issues in 1.1 (was: Re: [update 1.1] #11126 - 27 (final ...))

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=1738 >> > There are still some issues. Some methods (for example TPureBehavior >> #addTraitSelector:withMethod:) still use the old trailer bytes #(0 0 0 0). These should be removed asap (I had to make some surgery with #become: to compile the new version.) >

Jan. 4, 2010

Re: [Pharo-project] Issues in 1.1 (was: Re: [update 1.1] #11126 - 27 (final ...))

by StÃ©phane Ducasse

Thanks I will do that as soon as I can. Stef On Jan 4, 2010, at 2:45 AM, Levente Uzonyi wrote: > On Wed, 30 Dec 2009, StÃ©phane Ducasse wrote: > >> BIG THANKS igor!!! >> >> 11127 >> ----- >> >> - Issue 1690: New Method Trailer part 7 (cs 9) > > There are still some issues. Some methods (for example TPureBehavior >> #addTraitSelector:withMethod:) still use the old trailer bytes #(0 0 0 0). These should be removed asap (I had to make some surgery with #become: to compile the new version.) > > > Levente > >> >> _______________________________________________ >> 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

Jan. 4, 2010