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

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

by Mariano Martinez Peck

2010/1/4 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > We certainly don't need the web images, but I would like to see them stay > to help with testing. If we are building them with unstable versions of > Seaside, that is a problem with the process (loading the wrong stuff) not > the concept/service (providing a Seaside-ready version of Pharo for > testing). We just finished designing a beta program, at least three of > volunteers indicated a preference for the web image. > Bill: On the contrary: I don't want to have beta testers in PharoWeb and then others in Seaside one click images (which are also based in Pharo). My idea is the contrary: JOIN FORCES. If people who were now using PharoWeb image, start to use Seaside images, they will also help to test and debugs. A lot of issues reported in those images in Seaside were actually Pharo issues. In addition, is VERY uncommon that an issue of the "IDE" appears in PharoWeb but not in PharoDev. So, most of the issues in PharoWeb that are not present in PharoDev may be related to Seaside, and even probably, because we are using worng version of the packages. Cheers Mariano > Bill > > ------------------------------ > *From:* pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] *On Behalf Of *Mariano > Martinez Peck > *Sent:* Monday, January 04, 2010 3:25 AM > *To:* Pharo Development > *Subject:* [Pharo-project] What about killing PharoWeb images? > > 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 > > > _______________________________________________ > 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 moving tmp closer their use

by Igor Stasenko

My own preference is a balance between being readable and efficient. At first, i care above anything to make my code readable. And I think that, being properly formatted, declaring temps in blocks scope not makes code less readable. Also, i think that keeping variables close to desired scope, will instead could help improving code readability. But i must say, we should learn & teach developers to write code short & consise, or at least attempt to (following a well known smalltalk practice - 1/2 lines per method). Then we wouldn't need to choose, what way of declaring temps is better ;) 2010/1/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi guys > > in squeak a week ago nicolas pushed a cool (from my taste) changes that refactored the complete > system so that |temp| declaration would be at the scope where they are used. > This is not clear that this is an optimisation but I like the fact that temp > are defined at the right place. > Now it may lead to code that is a bit less readable in the sense that your temps > are not systematically listed at the beginning of the method but occasionally in the closures > that use them. > From my hackish lisping state of mind I like it now what do you prefer? > > Stef > _______________________________________________ > 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.

Jan. 4, 2010

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

by Tudor Girba

Hi Mariano, I also agree with you. Cheers, Doru On 4 Jan 2010, at 09:24, 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? > > 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 -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

Jan. 4, 2010

Re: [Pharo-project] 64 bit images (was Re: [squeak-dev] The Trunk: Collections-dtl.268.mcz)

by Laval Jannik

Yes, but the changeset build the fix in SystemDictionary, In a previous discussion, we decide to create an instance variable in SmalltalkImage and to put methods in SmalltalkImage too. Cheers, Jannik On Jan 4, 2010, at 13:35 , StÃ©phane Ducasse wrote: > Jannik > > did you check the changeset in the mantis bug report? > > Stef > On Jan 4, 2010, at 10:53 AM, Laval Jannik wrote: > >> Hi, >> >> I made a new version of the system-tracer (in attachment). >> It works fine with the latest pharo version. >> >> For wordSize, we decide to create a instance variable in SmalltalkImage, which is initialized at startup. >> The method initialPC is: >> >> --- >> initialPC >> "Answer the program counter for the receiver's first bytecode." >> >> ^ (self numLiterals + 1) * SmalltalkImage current wordSize + 1 >> --- >> >> The fix will be integrated in Pharo soon. >> It is also in attachment. >> >> <addWordSizeInSystemDictionary.1.cs><System-Tracing-forPharo.cs> >> >> Cheers >> >> On Jan 3, 2010, at 06:46 , John M McIntosh wrote: >> >>> Ok, well I was hoping that Laval Jannik would review the changes/solution in http://bugs.squeak.org/view.php?id=7430 >>> then update his original System-Tracing.2forPharo3.cs Then test to confirm we can build a 64bit image from the current Pharo image >>> >>> >>> On 2010-01-02, at 6:46 PM, David T. Lewis wrote: >>> >>>> John, one additional note. >>>> >>>> The SystemTracer changesets currently in circulation have an obsolete >>>> implementation of SystemDictionary>>wordSize.The original 64-bit >>>> Squeak used vmParameterAt: 27 for the VM to answer its word size, >>>> but this was later changed to vmParameter at: 40. This is the reason >>>> that the original "dist3" 64-bit image does not work on current VMs. >>>> >>>> You will want to revert #wordSize back to a current version >>>> so that it uses vmParameter at: 40. >>>> >>>> This issue will go away when we implement the cached #wordSize fixes >>>> discussed separately (http://bugs.squeak.org/view.php?id=7430) but >>>> I wanted to mention it because I spotted the obsolete method in the >>>> System-Tracing2forPharo.cs change set. >>>> >>> >>> -- >>> =========================================================================== >>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 >>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>> =========================================================================== >>> >>> >>> >>> >> >> --- >> Jannik Laval >> --- >> >> _______________________________________________ >> 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

[Pharo-project] About moving tmp closer their use

by StÃ©phane Ducasse

Hi guys in squeak a week ago nicolas pushed a cool (from my taste) changes that refactored the complete system so that |temp| declaration would be at the scope where they are used. This is not clear that this is an optimisation but I like the fact that temp are defined at the right place. Now it may lead to code that is a bit less readable in the sense that your temps are not systematically listed at the beginning of the method but occasionally in the closures that use them. >From my hackish lisping state of mind I like it now what do you prefer? Stef

Jan. 4, 2010

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

by StÃ©phane Ducasse

You did that manually :) Ok so may be since there are only few senders I can do it too :) Stef > If this preserves formatting, proceed, else, beware. > Given there were few senders in trunk, my change was manual, not > automatic (Steph didn't you mean systematic ?). > > Nicolas > > 2010/1/4 Lukas Renggli <renggli(a)gmail.com>: >> From Slime: >> >> RBParseTreeRewriter new >> replace: '``@expr1 and: [ | `@temp2 | ``@expr2 ] and: [ | `@temp3 | ``@expr3 ]' >> with: '``@expr1 and: [ | `@temp2 | ``@expr2 and: [ | `@temp3 | ``@expr3 ] ]'; >> replace: '``@expr1 and: [ | `@temp2 | ``@expr2 ] and: [ | `@temp3 | >> ``@expr3 ] and: [ | `@temp4 | ``@expr4 ]' >> with: '``@expr1 and: [ | `@temp2 | ``@expr2 and: [ | `@temp3 | >> ``@expr3 and: [ | `@temp4 | ``@expr4 ] ] ]'; >> replace: '``@expr1 and: [ | `@temp2 | ``@expr2 ] and: [ | `@temp3 | >> ``@expr3 ] and: [ | `@temp4 | ``@expr4 ] and: [ | `@temp5 | ``@expr5 >> ]' >> with: '``@expr1 and: [ | `@temp2 | ``@expr2 and: [ | `@temp3 | >> ``@expr3 and: [ | `@temp4 | ``@expr4 and: [ | `@temp5 | ``@expr5 ] ] ] >> ]'; >> replace: '``@expr1 or: [ | `@temp2 | ``@expr2 ] or: [ | `@temp3 | ``@expr3 ]' >> with: '``@expr1 or: [ | `@temp2 | ``@expr2 or: [ | `@temp3 | ``@expr3 ] ]'; >> replace: '``@expr1 or: [ | `@temp2 | ``@expr2 ] or: [ | `@temp3 | >> ``@expr3 ] or: [ | `@temp4 | ``@expr4 ]' >> with: '``@expr1 or: [ | `@temp2 | ``@expr2 or: [ | `@temp3 | >> ``@expr3 or: [ | `@temp4 | ``@expr4 ] ] ]'; >> replace: '``@expr1 or: [ | `@temp2 | ``@expr2 ] or: [ | `@temp3 | >> ``@expr3 ] or: [ | `@temp4 | ``@expr4 ] or: [ | `@temp5 | ``@expr5 ]' >> with: '``@expr1 or: [ | `@temp2 | ``@expr2 or: [ | `@temp3 | >> ``@expr3 or: [ | `@temp4 | ``@expr4 or: [ | `@temp5 | ``@expr5 ] ] ] >> ]'; >> replace: '``@expr1 or: [ | `@temp2 | ``@expr2 ] or: [ | `@temp3 | >> ``@expr3 ] or: [ | `@temp4 | ``@expr4 ] or: [ | `@temp5 | ``@expr5 ] >> or: [ | `@temp6 | ``@expr6 ]' >> with: '``@expr1 or: [ | `@temp2 | ``@expr2 or: [ | `@temp3 | >> ``@expr3 or: [ | `@temp4 | ``@expr4 or: [ | `@temp5 | ``@expr5 or: [ | >> `@temp6 | ``@expr6 ] ] ] ] ]'; >> yourself >> >> 2010/1/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> 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 >>> >>> >>> _______________________________________________ >>> 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] 64 bit images (was Re: [squeak-dev] The Trunk: Collections-dtl.268.mcz)

by StÃ©phane Ducasse

Jannik did you check the changeset in the mantis bug report? Stef On Jan 4, 2010, at 10:53 AM, Laval Jannik wrote: > Hi, > > I made a new version of the system-tracer (in attachment). > It works fine with the latest pharo version. > > For wordSize, we decide to create a instance variable in SmalltalkImage, which is initialized at startup. > The method initialPC is: > > --- > initialPC > "Answer the program counter for the receiver's first bytecode." > > ^ (self numLiterals + 1) * SmalltalkImage current wordSize + 1 > --- > > The fix will be integrated in Pharo soon. > It is also in attachment. > > <addWordSizeInSystemDictionary.1.cs><System-Tracing-forPharo.cs> > > Cheers > > On Jan 3, 2010, at 06:46 , John M McIntosh wrote: > >> Ok, well I was hoping that Laval Jannik would review the changes/solution in http://bugs.squeak.org/view.php?id=7430 >> then update his original System-Tracing.2forPharo3.cs Then test to confirm we can build a 64bit image from the current Pharo image >> >> >> On 2010-01-02, at 6:46 PM, David T. Lewis wrote: >> >>> John, one additional note. >>> >>> The SystemTracer changesets currently in circulation have an obsolete >>> implementation of SystemDictionary>>wordSize.The original 64-bit >>> Squeak used vmParameterAt: 27 for the VM to answer its word size, >>> but this was later changed to vmParameter at: 40. This is the reason >>> that the original "dist3" 64-bit image does not work on current VMs. >>> >>> You will want to revert #wordSize back to a current version >>> so that it uses vmParameter at: 40. >>> >>> This issue will go away when we implement the cached #wordSize fixes >>> discussed separately (http://bugs.squeak.org/view.php?id=7430) but >>> I wanted to mention it because I spotted the obsolete method in the >>> System-Tracing2forPharo.cs change set. >>> >> >> -- >> =========================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> =========================================================================== >> >> >> >> > > --- > Jannik Laval > --- > > _______________________________________________ > 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 Schwab,Wilhelm K

We certainly don't need the web images, but I would like to see them stay to help with testing. If we are building them with unstable versions of Seaside, that is a problem with the process (loading the wrong stuff) not the concept/service (providing a Seaside-ready version of Pharo for testing). We just finished designing a beta program, at least three of volunteers indicated a preference for the web image. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Monday, January 04, 2010 3:25 AM To: Pharo Development Subject: [Pharo-project] What about killing PharoWeb images? 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] Code Critics pragmas for classes - do they need to be on instance *and* class side?

by Stan Shepherd

Lukas Renggli wrote: > >> I was specifically thinking of "class not referenced", which seems >> strange >> to have to put on both sides. But I suppose there could be other class >> checks for which there could be utility in treating Â class and instance >> separately; I haven't come across a case so far. > > Ok, you convinced me. I've fixed this (but not tested it) in > Refactoring-Core-lr.93. Let me know if this is better. > > Name: Refactoring-Core-lr.93 > Author: lr > Time: 3 January 2010, 3:25:42 pm > UUID: c8f01646-b4cc-420a-a05e-dd8a0a81a305 > Ancestors: Refactoring-Core-TestRunner.92 > > - for lint issues in class environments filter the instance and class > side > > Lukas > >> >> ...Stan > >> > -- > 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 > > That's a lot tidier, thanks. ...Stan -- View this message in context: http://n2.nabble.com/Code-Critics-pragmas-for-classes-do-they-need-to-be-on… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 4, 2010

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

by Stan Shepherd

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? > > 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 > +1 I would definitely support concentrating on the Seaside one click images. As Mariano says, they're pretty stable, so you can get on with developing in them. >From a marketing point of view, the one click images are much easier for someone who is evaluating Pharo for the first time. Also, the existing web dev is not the advertisement for Pharo that we want. There is a (very) slight complication. Lukas's recommendation for people starting a new project with JavaScript is to use JQueryUI, hence this implies Seaside 3.0. The Seaside 3.0 image on the Seaside site is not an official release: http://n4.nabble.com/2-1Using-the-One-Click-Image-tt975474.html#a975784 http://n4.nabble.com/2-1Using-the-One-Click-Image-tt975474.html#a975784 So the ideal solution is that that version become an official 3.0 one-click, although this was not in the Seaside plan. And maybe at the same time the Seaside team could apply (or allow to be applied) the few changes that Mariano mentioned to make that image seem more familiar. This would also make this image have the same 'look and feel' as the Seaside book. On the negative side of the ledger, there would be less testers/debuggers of the Pharo side; the problem areas of the OB/O2/Refactoring combination would not be exercised by many end users, until a stable combination could be put in the one click. Mariano, do you use the 2.8.4 or the 3.0 image? ...Stan -- View this message in context: http://n2.nabble.com/What-about-killing-PharoWeb-images-tp4249050p4249415.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 4, 2010