October 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [update] #10487

by Lukas Renggli

>> Personally I would like to download an image *without* any tests, no >> matter if this is a core or a dev image. And have included a detailed >> report on the results of running all the tests in that particular >> image. > > But why, apart from the tiny image disk usage reduction. The test > sometimes show how to use the, most times underdocumented, package. IMHO, that's a myth. Did a single test case ever in your entire life help you to understand a piece of code? It never happened to me so far :-) The rational behind my opinion is that I do not care about the tests of the other packages when I develop software. Did you ever (other than by accident) run the Collection or Compiler tests when you developed some of your code? Btw, the same is true for the Monticello working copies. I frankly do not care what version of Collection or Compiler is loaded in my image. Sometimes I just drop all this information before I load my code. This greatly reduces clutter. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 19, 2009

Re: [Pharo-project] Immutable strings

by Lukas Renggli

I've added a comment to the bug tracker. I suggest to keep the bug marked as WontFix or Invalid. Lukas 2009/10/19 Gary Chambers <gazzaguru2(a)btinternet.com>: > Then there are so many string classes now! Still, a good idea, got well > bitten by the problem twenty years ago (Smalltalk V/DOS)... took a good day > to discover the problem! > > Regards, Gary > > ----- Original Message ----- > From: "Niko Schwarz" <niko.schwarz(a)googlemail.com> > To: <pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, October 19, 2009 4:48 PM > Subject: [Pharo-project] Immutable strings > > >> Hello list! >> >> I would like to propose the compiler spit out immutable strings as >> string literals. I'd like to do this by making a subclass of classical >> strings which throws error messages when it is attempted to change the >> string. >> >> The beginning of this discussion happened in the bug tracker, please >> see http://code.google.com/p/pharo/issues/detail?id=1332. >> >> I completely agree with Toon: String literals should be immutable. >> This can be done with almost no speed impact and would only break code >> that quite honestly deserves to break. >> >> My 2 cents. >> >> Regards, >> >> Niko >> >> _______________________________________________ >> 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

Oct. 19, 2009

Re: [Pharo-project] [update] #10487

by Gary Chambers

+1 Or at least have a reliable one-click (one message send) way of unloading the tests cleanly for deployment purposes. Regards, Gary ----- Original Message ----- From: "Lukas Renggli" <renggli(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, October 19, 2009 4:51 PM Subject: Re: [Pharo-project] [update] #10487 > Personally I would like to download an image *without* any tests, no > matter if this is a core or a dev image. And have included a detailed > report on the results of running all the tests in that particular > image. > > Cheers, > Lukas > > 2009/10/19 Damien Cassou <damien.cassou(a)gmail.com>: >> 2009/10/19 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>> What I propose is to identify the red tests of Pharo dev and look for >>> the >>> package and ask the maintainers (if there is anyone) to fix it. And the >>> regarding tests, we can tag them as 1.1 >> >> Ok. Can you have a look at that please? The problem is that we will >> also have to maintain these tests. >> >> >>>> > Moreover, if packages are included in Pharo dev it is because it is a >>>> > Pharo decision. So, if pharo thinks that, for example, ocompletion >>>> > must be in Pharo, so, I think that ocompletion tests must be green. >>>> >>>> But I don't think that the package lists (web and dev images) are >>>> blessed by the Pharo board. >>>> >>> And I am not agree with this also. I think Pharo board, and even the >>> community has to choose the Pharo packages. Please, take in mind that >>> the >>> final users will use and see Pharo, NOT PHARO CORE. >> >> I confirm. The Pharo user community has the last word on what gets >> integrated into images I generate, not me. The list of packages is at: >> http://code.google.com/p/pharo/wiki/Packages. >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Lambdas are relegated to relative obscurity until Java makes them >> popular by not having them." James Iry >> >> _______________________________________________ >> 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

Oct. 19, 2009

Re: [Pharo-project] Immutable strings

by Gary Chambers

Then there are so many string classes now! Still, a good idea, got well bitten by the problem twenty years ago (Smalltalk V/DOS)... took a good day to discover the problem! Regards, Gary ----- Original Message ----- From: "Niko Schwarz" <niko.schwarz(a)googlemail.com> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Monday, October 19, 2009 4:48 PM Subject: [Pharo-project] Immutable strings > Hello list! > > I would like to propose the compiler spit out immutable strings as > string literals. I'd like to do this by making a subclass of classical > strings which throws error messages when it is attempted to change the > string. > > The beginning of this discussion happened in the bug tracker, please > see http://code.google.com/p/pharo/issues/detail?id=1332. > > I completely agree with Toon: String literals should be immutable. > This can be done with almost no speed impact and would only break code > that quite honestly deserves to break. > > My 2 cents. > > Regards, > > Niko > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 19, 2009

Re: [Pharo-project] [update] #10487

by Miguel Enrique CobÃ¡ Martinez

El lun, 19-10-2009 a las 17:51 +0200, Lukas Renggli escribiÃ³: > Personally I would like to download an image *without* any tests, no > matter if this is a core or a dev image. And have included a detailed > report on the results of running all the tests in that particular > image. > But why, apart from the tiny image disk usage reduction. The test sometimes show how to use the, most times underdocumented, package. > Cheers, > Lukas > > 2009/10/19 Damien Cassou <damien.cassou(a)gmail.com>: > > 2009/10/19 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> What I propose is to identify the red tests of Pharo dev and look for the > >> package and ask the maintainers (if there is anyone) to fix it. And the > >> regarding tests, we can tag them as 1.1 > > > > Ok. Can you have a look at that please? The problem is that we will > > also have to maintain these tests. > > > > > >>> > Moreover, if packages are included in Pharo dev it is because it is a > >>> > Pharo decision. So, if pharo thinks that, for example, ocompletion > >>> > must be in Pharo, so, I think that ocompletion tests must be green. > >>> > >>> But I don't think that the package lists (web and dev images) are > >>> blessed by the Pharo board. > >>> > >> And I am not agree with this also. I think Pharo board, and even the > >> community has to choose the Pharo packages. Please, take in mind that the > >> final users will use and see Pharo, NOT PHARO CORE. > > > > I confirm. The Pharo user community has the last word on what gets > > integrated into images I generate, not me. The list of packages is at: > > http://code.google.com/p/pharo/wiki/Packages. > > > > -- > > Damien Cassou > > http://damiencassou.seasidehosting.st > > > > "Lambdas are relegated to relative obscurity until Java makes them > > popular by not having them." James Iry > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Oct. 19, 2009

Re: [Pharo-project] [update] #10487

by Lukas Renggli

Personally I would like to download an image *without* any tests, no matter if this is a core or a dev image. And have included a detailed report on the results of running all the tests in that particular image. Cheers, Lukas 2009/10/19 Damien Cassou <damien.cassou(a)gmail.com>: > 2009/10/19 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> What I propose is to identify the red tests of Pharo dev and look for the >> package and ask the maintainers (if there is anyone) to fix it. And the >> regarding tests, we can tag them as 1.1 > > Ok. Can you have a look at that please? The problem is that we will > also have to maintain these tests. > > >>> > Moreover, if packages are included in Pharo dev it is because it is a >>> > Pharo decision. So, if pharo thinks that, for example, ocompletion >>> > must be in Pharo, so, I think that ocompletion tests must be green. >>> >>> But I don't think that the package lists (web and dev images) are >>> blessed by the Pharo board. >>> >> And I am not agree with this also. I think Pharo board, and even the >> community has to choose the Pharo packages. Please, take in mind that the >> final users will use and see Pharo, NOT PHARO CORE. > > I confirm. The Pharo user community has the last word on what gets > integrated into images I generate, not me. The list of packages is at: > http://code.google.com/p/pharo/wiki/Packages. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > 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

Oct. 19, 2009

[Pharo-project] Immutable strings

by Niko Schwarz

Hello list! I would like to propose the compiler spit out immutable strings as string literals. I'd like to do this by making a subclass of classical strings which throws error messages when it is attempted to change the string. The beginning of this discussion happened in the bug tracker, please see http://code.google.com/p/pharo/issues/detail?id=1332. I completely agree with Toon: String literals should be immutable. This can be done with almost no speed impact and would only break code that quite honestly deserves to break. My 2 cents. Regards, Niko

Oct. 19, 2009

[Pharo-project] [ANN] Pharo Core 1.1 alpha

by Marcus Denker

http://gforge.inria.fr/frs/download.php/24364/PharoCore-1.1-11000-ALPHA.zip

Oct. 19, 2009

[Pharo-project] [ANN] Pharo Core 1.0rc1

by Marcus Denker

http://gforge.inria.fr/frs/download.php/24363/PharoCore-1.0-10491rc1.zip The zip contains a new sources file. Marcus

Oct. 19, 2009

Re: [Pharo-project] [update] #10488

by George Herolyants

2009/10/19 Marcus Denker <denker(a)acm.org>: > Are you trying to condese a dev image? You should not. The sources > will be build from a core image > (the alternative does not work. else the .sources would contain all > the code from the dev image) > > condensing the core image is working. :) O, thanks, now I see it's my mistake, I really try to condense a dev image. Thank you for the explanation. George

Oct. 19, 2009