November 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] String and Symbol comparison

by StÃ©phane Ducasse

yes! may be create a tag for m1.1 On Nov 14, 2008, at 9:13 AM, Lukas Renggli wrote: > I created: > > http://code.google.com/p/pharo/issues/detail?id=331 > http://code.google.com/p/pharo/issues/detail?id=332 > > It would be useful to be able to tag issues for specific milestones. > > Lukas > > On Fri, Nov 14, 2008 at 9:05 AM, Lukas Renggli <renggli(a)gmail.com> > wrote: >> On Fri, Nov 14, 2008 at 8:57 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> I should say that I always like the fact that >>>> >>>> 'abc' = #abc --> false >>>> #abc = 'abc' --> false >>> >>> Because a symbol and a string are different to my eyes. >>> But when there was the discussion a while back >>> I understood that a symbol is a kind of string. >>> >>> Now how can we make progress on that point >>> - evaluate the risks >>> - write some tests for strings and symbols >>> - give a try >>> - but do that for pharo 1.1 :) >> >> Ok, I will file an issue so that we don't forget. >> >> Along the same lines is that strings implement the complete >> arithmetic >> protocol. In my opinion that should go away as well: it is a source >> of >> errors and portability issues. Furthermore it looks really >> unprofessional: >> >> '1' + '2' --> '3' (in Pharo/Squeak) >> >> I guess this is some eToy remnant. >> >> Lukas >> >> >> >> >>> stef >>> >>> On Nov 14, 2008, at 7:46 AM, Lukas Renggli wrote: >>> >>>> I want to open this for discussion: >>>> >>>> In all Smalltalk dialects the following expressions evaluate to >>>> false: >>>> >>>> 'abc' = #abc --> false >>>> #abc = 'abc' --> false >>>> >>>> This means a String and a Symbol is never the same thing, even if >>>> they >>>> contain the same characters. In Squeak/Pharo this is different >>>> though >>>> (at least this is symmetrical, pre 3.9 this wasn't even >>>> symmetrical): >>>> >>>> 'abc' = #abc --> true >>>> #abc = 'abc' --> true >>>> >>>> Unfortunately this difference makes writing portable code that >>>> deals >>>> with symbols and strings a huge pain. And it is hard to test, debug >>>> and find those kind of problems. >>>> >>>> I wonder if it would be possible to change that behavior in >>>> Squeak to >>>> match the other Smalltalk implementations? I guess this would break >>>> some code, but at least this problem would then be gone forever. >>>> >>>> Lukas >>>> >>>> -- >>>> 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 >>> >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> > > > > -- > 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 >

Nov. 14, 2008

Re: [Pharo-project] String and Symbol comparison

by Lukas Renggli

I created: http://code.google.com/p/pharo/issues/detail?id=331 http://code.google.com/p/pharo/issues/detail?id=332 It would be useful to be able to tag issues for specific milestones. Lukas On Fri, Nov 14, 2008 at 9:05 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > On Fri, Nov 14, 2008 at 8:57 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> I should say that I always like the fact that >>> >>> 'abc' = #abc --> false >>> #abc = 'abc' --> false >> >> Because a symbol and a string are different to my eyes. >> But when there was the discussion a while back >> I understood that a symbol is a kind of string. >> >> Now how can we make progress on that point >> - evaluate the risks >> - write some tests for strings and symbols >> - give a try >> - but do that for pharo 1.1 :) > > Ok, I will file an issue so that we don't forget. > > Along the same lines is that strings implement the complete arithmetic > protocol. In my opinion that should go away as well: it is a source of > errors and portability issues. Furthermore it looks really > unprofessional: > > '1' + '2' --> '3' (in Pharo/Squeak) > > I guess this is some eToy remnant. > > Lukas > > > > >> stef >> >> On Nov 14, 2008, at 7:46 AM, Lukas Renggli wrote: >> >>> I want to open this for discussion: >>> >>> In all Smalltalk dialects the following expressions evaluate to false: >>> >>> 'abc' = #abc --> false >>> #abc = 'abc' --> false >>> >>> This means a String and a Symbol is never the same thing, even if they >>> contain the same characters. In Squeak/Pharo this is different though >>> (at least this is symmetrical, pre 3.9 this wasn't even symmetrical): >>> >>> 'abc' = #abc --> true >>> #abc = 'abc' --> true >>> >>> Unfortunately this difference makes writing portable code that deals >>> with symbols and strings a huge pain. And it is hard to test, debug >>> and find those kind of problems. >>> >>> I wonder if it would be possible to change that behavior in Squeak to >>> match the other Smalltalk implementations? I guess this would break >>> some code, but at least this problem would then be gone forever. >>> >>> Lukas >>> >>> -- >>> 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 >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 14, 2008

Re: [Pharo-project] String and Symbol comparison

by StÃ©phane Ducasse

Yeap! Stef On Nov 14, 2008, at 9:10 AM, Michael Roberts wrote: > +1 on removing arithmetic protocol > > cheers, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 14, 2008

Re: [Pharo-project] String and Symbol comparison

by Michael Roberts

+1 on removing arithmetic protocol cheers, Mike

Nov. 14, 2008

Re: [Pharo-project] String and Symbol comparison

by Lukas Renggli

On Fri, Nov 14, 2008 at 8:57 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I should say that I always like the fact that >> >> 'abc' = #abc --> false >> #abc = 'abc' --> false > > Because a symbol and a string are different to my eyes. > But when there was the discussion a while back > I understood that a symbol is a kind of string. > > Now how can we make progress on that point > - evaluate the risks > - write some tests for strings and symbols > - give a try > - but do that for pharo 1.1 :) Ok, I will file an issue so that we don't forget. Along the same lines is that strings implement the complete arithmetic protocol. In my opinion that should go away as well: it is a source of errors and portability issues. Furthermore it looks really unprofessional: '1' + '2' --> '3' (in Pharo/Squeak) I guess this is some eToy remnant. Lukas > stef > > On Nov 14, 2008, at 7:46 AM, Lukas Renggli wrote: > >> I want to open this for discussion: >> >> In all Smalltalk dialects the following expressions evaluate to false: >> >> 'abc' = #abc --> false >> #abc = 'abc' --> false >> >> This means a String and a Symbol is never the same thing, even if they >> contain the same characters. In Squeak/Pharo this is different though >> (at least this is symmetrical, pre 3.9 this wasn't even symmetrical): >> >> 'abc' = #abc --> true >> #abc = 'abc' --> true >> >> Unfortunately this difference makes writing portable code that deals >> with symbols and strings a huge pain. And it is hard to test, debug >> and find those kind of problems. >> >> I wonder if it would be possible to change that behavior in Squeak to >> match the other Smalltalk implementations? I guess this would break >> some code, but at least this problem would then be gone forever. >> >> Lukas >> >> -- >> 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 > -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 14, 2008

Re: [Pharo-project] String and Symbol comparison

by StÃ©phane Ducasse

I should say that I always like the fact that > 'abc' = #abc --> false > #abc = 'abc' --> false Because a symbol and a string are different to my eyes. But when there was the discussion a while back I understood that a symbol is a kind of string. Now how can we make progress on that point - evaluate the risks - write some tests for strings and symbols - give a try - but do that for pharo 1.1 :) stef On Nov 14, 2008, at 7:46 AM, Lukas Renggli wrote: > I want to open this for discussion: > > In all Smalltalk dialects the following expressions evaluate to false: > > 'abc' = #abc --> false > #abc = 'abc' --> false > > This means a String and a Symbol is never the same thing, even if they > contain the same characters. In Squeak/Pharo this is different though > (at least this is symmetrical, pre 3.9 this wasn't even symmetrical): > > 'abc' = #abc --> true > #abc = 'abc' --> true > > Unfortunately this difference makes writing portable code that deals > with symbols and strings a huge pain. And it is hard to test, debug > and find those kind of problems. > > I wonder if it would be possible to change that behavior in Squeak to > match the other Smalltalk implementations? I guess this would break > some code, but at least this problem would then be gone forever. > > Lukas > > -- > 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 >

Nov. 14, 2008

[Pharo-project] String and Symbol comparison

by Lukas Renggli

I want to open this for discussion: In all Smalltalk dialects the following expressions evaluate to false: 'abc' = #abc --> false #abc = 'abc' --> false This means a String and a Symbol is never the same thing, even if they contain the same characters. In Squeak/Pharo this is different though (at least this is symmetrical, pre 3.9 this wasn't even symmetrical): 'abc' = #abc --> true #abc = 'abc' --> true Unfortunately this difference makes writing portable code that deals with symbols and strings a huge pain. And it is hard to test, debug and find those kind of problems. I wonder if it would be possible to change that behavior in Squeak to match the other Smalltalk implementations? I guess this would break some code, but at least this problem would then be gone forever. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 14, 2008

Re: [Pharo-project] OldSocket removal

by John M McIntosh

I should comment that the original method initializeNetworkIfError (whatever): was there because at the time (long ago) tcp/ip network support was an optional feature on macintosh and windows machines so there was fall back to support no network. That's unlikely today, and changing to just use the initializeNetwork is fine, where a thrown NetworkError would result in a valid sunit error. On Nov 13, 2008, at 7:26 AM, Dan Corneanu wrote: > I think it was not me. I have removed nothing from Network-Kernel. > We should use NetNameResolver class>>initializeNetwork. The method > throws a NetworkError if it can not initialize the network. > I think the method was never present in the pharo image. > -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 13, 2008

Re: [Pharo-project] OldSocket removal

by Dan Corneanu

I think it was not me. I have removed nothing from Network-Kernel. We should use NetNameResolver class>>initializeNetwork. The method throws a NetworkError if it can not initialize the network. I think the method was never present in the pharo image. How can I trace back changes made to the NetNameResolver class, without selecting each monticello version of Network and browsing the code inside it? On Wed, Nov 12, 2008 at 10:32 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Hi Dan, > > On Sat, Oct 25, 2008 at 8:36 PM, Dan Corneanu <dan.corneanu(a)gmail.com> wrote: >> I've played with the change sets from >> http://www.smalltalkconsulting.com/html/OTNotes4.html. >> I've made some changes to the tests, to fit the current Socket and >> NetNameResolver implementations. If it is of any help, I can put up a >> mcz so others can have a look to the code. > > John released a new changeset: > http://code.google.com/p/pharo/issues/detail?id=275. However, unit > tests does not run due to missing NetNameResolver > class>>initializeNetworkIfFail:. I think you removed that method. > Could you please check the changeset, make the necessary changes, > verify that all unit tests run and commit to PharoInbox? > > Also, please update the issue on google code according to what you do. > > Bye > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 13, 2008

Re: [Pharo-project] OldSocket removal

by Dan Corneanu

I'll have a look. On Wed, Nov 12, 2008 at 10:32 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Hi Dan, > > On Sat, Oct 25, 2008 at 8:36 PM, Dan Corneanu <dan.corneanu(a)gmail.com> wrote: >> I've played with the change sets from >> http://www.smalltalkconsulting.com/html/OTNotes4.html. >> I've made some changes to the tests, to fit the current Socket and >> NetNameResolver implementations. If it is of any help, I can put up a >> mcz so others can have a look to the code. > > John released a new changeset: > http://code.google.com/p/pharo/issues/detail?id=275. However, unit > tests does not run due to missing NetNameResolver > class>>initializeNetworkIfFail:. I think you removed that method. > Could you please check the changeset, make the necessary changes, > verify that all unit tests run and commit to PharoInbox? > > Also, please update the issue on google code according to what you do. > > Bye > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 13, 2008