- Pharo-dev - lists.pharo.org

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

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

by Damien Cassou

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

Oct. 19, 2009

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

by Mariano Martinez Peck

2009/10/19 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > El lun, 19-10-2009 a las 12:47 -0200, Mariano Martinez Peck escribiÃ³: > > > > > > 2009/10/19 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > > El lun, 19-10-2009 a las 11:58 -0200, Mariano Martinez Peck > > escribiÃ³: > > > > > > > > > On Mon, Oct 19, 2009 at 10:59 AM, Adrian Lienhard > > <adi(a)netstyle.ch> > > > wrote: > > > 10483 - 10487 > > > ----- > > > - Issue 1310: Make all tests green > > > > > > This is grate news. Sorry for my ignorance, but when you > > refer to "all > > > tests" are you talking about Pharo core or just Pharo? In > > addition, is > > > a Pharo goal to have also all test green in the dev image ? > > > > > > I don't think so. > > The packages added by the dev images are independent and their > > tests are > > their own responsibility. > > > > > > > > I am sorry but I am not totally agree. Pharo core is something > > internal. Imagine a final user who just go to > > www.pharo-project.com/download and he downloads the "Pharo image". He > > will expect to have all green tests. He won't be aware of pharo core > > at all. > > I agree from a user perspective. But the dev images are, I think, a > community bonus resulting from the effort of Damien. He isn't and musn't > be responsible for checking if the packages included have green tests or > not. Even more, the fact that a package hasn't green test doesn't > necessarily means that the package is broken. It could mean that the > tests aren't updated to the current package code. The package could very > well work correctly although some tests fail. > > So, yes it *would* be great to have the dev packages all with green > tests but this is almost impossible to get with the current workforce > and free time. > > Great but almost impossible. > > I am agree. But, tests have several purposes. One of them is to try to build robust software. So, the final users will use Pharo, not Pharo core. So, if Pharo has a lot of red tests and it is buggy, it won't be usable from a user perspective, no matter how core is. It's like, who cares if Ubuntu kernel works well if what I use is Ubuntu? I need ubuntu to be robust, which includes ubuntu packages and core. 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 > Cheers > > > > 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 don't say it is Pharo responsability to have those tests in green. > > > > Again, I am not saying it is Pharo responability to do this. This was > > a BIG step in Pharo. > > > > > > > > > > - Issue 1330: Better performance for tests > > > > > > Test result: 7168 run, 7150 passes, 18 expected > > failures, 0 > > > failures, > > > 0 errors, 0 unexpected passes > > > > > > ___________________ > > > http://www.adrian-lienhard.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 > > > > -- > > 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 > > > > _______________________________________________ > > 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 > > > _______________________________________________ > 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