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

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

by Michael Roberts

I think we should report the pharo tests the same way we report the pharo-core tests. Unless someone disagrees I will look to split out the wiki into a number of test areas. I agree we can not necessarily fix all the tests owned by the packages but we should publish a baseline. This will be important for inclusion of new packages, a prerequisite being not introducing new failures. thanks Mike On Mon, Oct 19, 2009 at 5:31 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > We have to check the packages that are part of the Pharo image before > we release 1.0. Currently we have 40 failures and 55 errors, which is > simply not good enough. There is code loaded that can not work > (considering there are 38 undeclared references...). > > Adrian > > On Oct 19, 2009, at 17:08 , Damien Cassou wrote: > >> 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 > > > _______________________________________________ > 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

[Pharo-project] HostWindowTests>>testOne is failing in Windows

by Mariano Martinez Peck

Hi adrian: I run all Pharo core tests in a Windows box and I get only one failure and 18 expected failures :) The only failure is HostWindowTests>>testOne. The assert with problem is: self shouldnt: [ hwindow open ] raise: Error. And the error raised is 'My subclass should have overridden #defaultWindowType' This is because in DisplayHostWindow>>open windowProxy is a HostWindowProxy and this class, the implementation of defaultWindowType is: defaultWindowType "set up my attributes to be a default window - a titlebar, usual decorations etc" ^self subclassResponsibility I opened a bug ticket: http://code.google.com/p/pharo/issues/detail?id=1338 Best, Mariano

Oct. 19, 2009

[Pharo-project] Fwd: [squeak-dev] The Trunk: Collections-nice.167.mcz

by StÃ©phane Ducasse

Begin forwarded message: > From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Date: October 19, 2009 3:00:19 PM GMT+02:00 > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>, stephane ducasse <stephane.ducasse(a)gmail.com > > > Subject: Fwd: [squeak-dev] The Trunk: Collections-nice.167.mcz > > Salut bis, > > Minor change to be integrated in pharo... > > Nicolas > > ---------- Forwarded message ---------- > From: <commits(a)source.squeak.org> > Date: 2009/10/19 > Subject: [squeak-dev] The Trunk: Collections-nice.167.mcz > To: squeak-dev(a)lists.squeakfoundation.org > > > Nicolas Cellier uploaded a new version of Collections to project The > Trunk: > http://source.squeak.org/trunk/Collections-nice.167.mcz > > ==================== Summary ==================== > > Name: Collections-nice.167 > Author: nice > Time: 19 October 2009, 12:32:29 pm > UUID: 95819d6c-2419-0244-bce5-75e402e44ec3 > Ancestors: Collections-ar.166 > > http://bugs.squeak.org/view.php?id=7362 > use self class instead of Text, so that we can subclass Text > > =============== Diff against Collections-ar.166 =============== > > Item was changed: > ----- Method: Text>>reversed (in category 'converting') ----- > reversed > > "Answer a copy of the receiver with element order reversed." > > ^ self class string: string reversed runs: runs reversed. > > " It is assumed that self size = runs size holds. "! > > Item was changed: > ----- Method: Text>>copyFrom:to: (in category 'copying') ----- > copyFrom: start to: stop > "Answer a copied subrange of the receiver." > > | realStart realStop | > stop > self size > ifTrue: [realStop := self size] "handle > selection at end of string" > ifFalse: [realStop := stop]. > start < 1 > ifTrue: [realStart := 1] "handle > selection before start of string" > ifFalse: [realStart := start]. > + ^self class > - ^Text > string: (string copyFrom: realStart to: realStop) > runs: (runs copyFrom: realStart to: realStop)!

Oct. 19, 2009

[Pharo-project] Fwd: [squeak-dev] The Trunk: Kernel-nice.272.mcz

by StÃ©phane Ducasse

Begin forwarded message: > From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Date: October 19, 2009 2:58:30 PM GMT+02:00 > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>, stephane ducasse <stephane.ducasse(a)gmail.com > > > Subject: Fwd: [squeak-dev] The Trunk: Kernel-nice.272.mcz > > Salut, > > Minor change to be integrated in pharo... > > J'ai une insulte de mail delivery quand j'essaie de transfÃ©rer Ã > Pharo-project(a)lists.gforge.inria.fr ... > > Nicolas > > > ---------- Forwarded message ---------- > From: <commits(a)source.squeak.org> > Date: 2009/10/19 > Subject: [squeak-dev] The Trunk: Kernel-nice.272.mcz > To: squeak-dev(a)lists.squeakfoundation.org > > > Nicolas Cellier uploaded a new version of Kernel to project The Trunk: > http://source.squeak.org/trunk/Kernel-nice.272.mcz > > ==================== Summary ==================== > > Name: Kernel-nice.272 > Author: nice > Time: 19 October 2009, 2:39:18 am > UUID: 6ad59bb1-c97b-ad4f-aa05-ae19f0921ca5 > Ancestors: Kernel-ar.271 > > How to gain a factor x2 on speed of > String streamContents: [:strm | Float pi absPrintExactlyOn: strm > base: 10] > > 1) do not use d := r // s. r := r \\ s. This will evaluate the > quotient twice. > 2) s generally has a lot of trailing bits = 0, so it is faster to > evaluate: > d := (r >> (s lowBit - 1)) // (s >> (s lowBit - 1)). > especially s lowBit - 1 and (s >> (s lowBit - 1)) can go outside the > while loop > 3) revert the tests in tc1 and tc2: these tests are false but for the > last digit. > Since Float usually have more than 2 digits, it is statistically > faster to test for the false condition first. > 4) use and: or: when due instead of & | > > > =============== Diff against Kernel-ar.271 =============== > > Item was changed: > ----- Method: Float>>absPrintExactlyOn:base: (in category > 'printing') ----- > absPrintExactlyOn: aStream base: base > "Print my value on a stream in the given base. Assumes that my > value is strictly > positive; negative numbers, zero, and NaNs have already been > handled elsewhere. > Based upon the algorithm outlined in: > Robert G. Burger and R. Kent Dybvig > Printing Floating Point Numbers Quickly and Accurately > ACM SIGPLAN 1996 Conference on Programming Language Design and > Implementation > June 1996. > This version guarantees that the printed representation exactly > represents my value > by using exact integer arithmetic." > > + | fBase significand exp baseExpEstimate be be1 r s mPlus > mMinus scale roundingIncludesLimits d tc1 tc2 fixedFormat > decPointCount slowbit shead | > - | fBase significand exp baseExpEstimate be be1 r s mPlus > mMinus scale roundingIncludesLimits d tc1 tc2 fixedFormat > decPointCount | > self isInfinite ifTrue: [aStream nextPutAll: 'Infinity'. ^ > self]. > fBase := base asFloat. > significand := self significandAsInteger. > roundingIncludesLimits := significand even. > exp := (self exponent - 52) max: MinValLogBase2. > baseExpEstimate := (self exponent * fBase reciprocalLogBase2 - > 1.0e-10) ceiling. > exp >= 0 > ifTrue: > [be := 1 << exp. > significand ~= 16r10000000000000 > ifTrue: > [r := significand * be * 2. > s := 2. > mPlus := be. > mMinus := be] > ifFalse: > [be1 := be * 2. > r := significand * be1 * 2. > s := 4. > mPlus := be1. > mMinus := be]] > ifFalse: > + [(exp = MinValLogBase2 or: [significand ~= > 16r10000000000000]) > - [(exp = MinValLogBase2) | (significand ~= > 16r10000000000000) > ifTrue: > [r := significand * 2. > s := (1 << (exp negated)) * 2. > mPlus := 1. > mMinus := 1] > ifFalse: > [r := significand * 4. > s := (1 << (exp negated + 1)) > * 2. > mPlus := 2. > mMinus := 1]]. > baseExpEstimate >= 0 > ifTrue: [s := s * (base raisedToInteger: > baseExpEstimate)] > ifFalse: > [scale := base raisedToInteger: > baseExpEstimate negated. > r := r * scale. > mPlus := mPlus * scale. > mMinus := mMinus * scale]. > + ((r + mPlus < s) not and: [roundingIncludesLimits or: [r + > mPlus > s]]) > - (r + mPlus > s) | (roundingIncludesLimits & (r + mPlus = s)) > ifTrue: [baseExpEstimate := baseExpEstimate + 1] > ifFalse: > [r := r * base. > mPlus := mPlus * base. > mMinus := mMinus * base]. > (fixedFormat := baseExpEstimate between: -3 and: 6) > ifTrue: > [decPointCount := baseExpEstimate. > baseExpEstimate <= 0 > ifTrue: [aStream nextPutAll: > ('0.000000' truncateTo: 2 - baseExpEstimate)]] > ifFalse: > + [decPointCount := 1]. > + slowbit := s lowBit - 1. > + shead := s >> slowbit. > + [d := (r >> slowbit) // shead. > + r := r - (d*s). > + (tc1 := (r > mMinus) not and: [roundingIncludesLimits or: [r < > mMinus]]) | > + (tc2 := (r + mPlus < s) not and: [roundingIncludesLimits or: > [r + mPlus > s]])] whileFalse: > - [decPointCount := 1]. > - [d := r // s. > - r := r \\ s. > - (tc1 := (r < mMinus) | (roundingIncludesLimits & (r = > mMinus))) | > - (tc2 := (r + mPlus > s) | (roundingIncludesLimits & (r + mPlus > = s)))] whileFalse: > [aStream nextPut: (Character digitValue: d). > r := r * base. > mPlus := mPlus * base. > mMinus := mMinus * base. > decPointCount := decPointCount - 1. > decPointCount = 0 ifTrue: [aStream nextPut: $.]]. > tc2 ifTrue: > + [(tc1 not or: [r*2 >= s]) ifTrue: [d := d + 1]]. > - [tc1 not | (tc1 & (r*2 >= s)) ifTrue: [d := d + 1]]. > aStream nextPut: (Character digitValue: d). > decPointCount > 0 > ifTrue: > [decPointCount - 1 to: 1 by: -1 do: [:i | aStream > nextPut: $0]. > aStream nextPutAll: '.0']. > fixedFormat ifFalse: > [aStream nextPut: $e. > aStream nextPutAll: (baseExpEstimate - 1) printString]!

Oct. 19, 2009

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

by StÃ©phane Ducasse

ideally we should have a miniimage and a metacello configuration files and people can pick what they want. + an universe based on metacello. Stef On Oct 19, 2009, at 6:37 PM, Gary Chambers wrote: > Handy, will try to remember and add to our stripping scripts... > > Regards, Gary > > ----- Original Message ----- > From: "Adrian Lienhard" <adi(a)netstyle.ch> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, October 19, 2009 5:16 PM > Subject: Re: [Pharo-project] [update] #10487 > > >> >> On Oct 19, 2009, at 18:05 , Gary Chambers wrote: >> >>> +1 Or at least have a reliable one-click (one message send) way of >>> unloading >>> the tests cleanly for deployment purposes. >> >> Check out "ScriptLoader new cleanUpForProduction" >> >> This is why I detangled the tests and moved them in a modular package >> that can be unloaded. With this script, which also clears the MC >> ancestory metadata, you get an image with only 6.7MB size on disk. >> >> Cheers, >> Adrian >> >>> >>> 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 >>> >>> >>> _______________________________________________ >>> 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

Oct. 19, 2009

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

by Gary Chambers

Handy, will try to remember and add to our stripping scripts... Regards, Gary ----- Original Message ----- From: "Adrian Lienhard" <adi(a)netstyle.ch> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, October 19, 2009 5:16 PM Subject: Re: [Pharo-project] [update] #10487 > > On Oct 19, 2009, at 18:05 , Gary Chambers wrote: > >> +1 Or at least have a reliable one-click (one message send) way of >> unloading >> the tests cleanly for deployment purposes. > > Check out "ScriptLoader new cleanUpForProduction" > > This is why I detangled the tests and moved them in a modular package > that can be unloaded. With this script, which also clears the MC > ancestory metadata, you get an image with only 6.7MB size on disk. > > Cheers, > Adrian > >> >> 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 >> >> >> _______________________________________________ >> 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

Oct. 19, 2009

[Pharo-project] [update 1.1 ] #11001

by StÃ©phane Ducasse

11001 ----- - Issue 1322: Flap should be removed Stef

Oct. 19, 2009

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

by Adrian Lienhard

We have to check the packages that are part of the Pharo image before we release 1.0. Currently we have 40 failures and 55 errors, which is simply not good enough. There is code loaded that can not work (considering there are 38 undeclared references...). Adrian On Oct 19, 2009, at 17:08 , Damien Cassou wrote: > 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

Oct. 19, 2009

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

by Miguel Enrique CobÃ¡ Martinez

El lun, 19-10-2009 a las 18:14 +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. > > 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. I agree. But then maybe is better to use the other alternative proposed of putting a visible one-liner or one-click to unload the tests after downloading and let the user unload them on demand in images used for deployment and not in images used for everyday work. Respect to the Monticello working copies I fully agree. > > Lukas > -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Oct. 19, 2009

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

by Adrian Lienhard

On Oct 19, 2009, at 18:05 , Gary Chambers wrote: > +1 Or at least have a reliable one-click (one message send) way of > unloading > the tests cleanly for deployment purposes. Check out "ScriptLoader new cleanUpForProduction" This is why I detangled the tests and moved them in a modular package that can be unloaded. With this script, which also clears the MC ancestory metadata, you get an image with only 6.7MB size on disk. Cheers, Adrian > > 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 > > > _______________________________________________ > 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