- Pharo-dev - lists.pharo.org

[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

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