August 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Why String>>adaptToNumber: rcvr andSend: selector

by Carla F. Griggio

(1 to: 10) + 5 is a shortcut for *(1 to: 10) collect:[:number | number + 5]* (1 @ 5) + 5 is a shortcut for (1 @ 5) + (5 @ 5) On Tue, Aug 24, 2010 at 6:02 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > But... What do they do? They are not clean. > > Does the collection one add the element to the collection? > > Does the point one add the number to the first, the second or both > components? I remember that a point might be added to other point, > multiplied by another point or a scalar :). > > > On Tue, Aug 24, 2010 at 5:53 PM, Carla F. Griggio <carla.griggio(a)gmail.com > > wrote: > >> I think 5 + 'hello' is plain wrong. >> >> In these cases: >> >> >> 5 + (1 to: 10) >> >> 5 + (1@5) >> >> the message shouldn't be conmutative. What I mean is that I don't want >> that to be the same as: >> >> (1 to: 10) + 5 >> >> (1 @ 5) + 5 >> >> >> On Tue, Aug 24, 2010 at 5:44 PM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> I feel these pieces of code aren't really explicit in what they do >>> >>> 5 + 'hello' >>> >>> 5 + (1 to: 10) >>> >>> 5 + (1@5) >>> >>> >>> >>> On Tue, Aug 24, 2010 at 5:42 PM, Guillermo Polito < >>> guillermopolito(a)gmail.com> wrote: >>> >>>> Well Collection and Point understand that message too. >>>> >>>> One step at a time, but an issue entry now so we don't forget about it. >>>> >>>> http://code.google.com/p/pharo/issues/detail?id=2858 >>>> >>>> >>>> On Tue, Aug 24, 2010 at 5:20 PM, Carla F. Griggio < >>>> carla.griggio(a)gmail.com> wrote: >>>> >>>>> What we've been discussing with Guille is that sometimes the 'type >>>>> checking' (or actually, the conversion) is done, and sometimes not. >>>>> >>>>> For example: >>>>> >>>>> 5 + true >>>>> >>>>> true does not understand 'adaptToNumber:andSend:', so no magic >>>>> conversion is done, but strings understand that message so we get things >>>>> like: >>>>> >>>>> 5 + 'foo' = 5 >>>>> >>>>> This should be consistent regardless the type of the parameter. >>>>> >>>>> Cheers, >>>>> Carla >>>>> >>>>> >>>>> >>>>> On Tue, Aug 24, 2010 at 5:10 PM, Guillermo Polito < >>>>> guillermopolito(a)gmail.com> wrote: >>>>> >>>>>> Do we reeeeeally want to do >>>>>> >>>>>> 5 + '4' >>>>>> >>>>>> 5 + 'hello' >>>>>> >>>>>> ? >>>>>> >>>>> >>>>> >>>> >>> >> >

Aug. 24, 2010

Re: [Pharo-project] Why String>>adaptToNumber: rcvr andSend: selector

by Guillermo Polito

But... What do they do? They are not clean. Does the collection one add the element to the collection? Does the point one add the number to the first, the second or both components? I remember that a point might be added to other point, multiplied by another point or a scalar :). On Tue, Aug 24, 2010 at 5:53 PM, Carla F. Griggio <carla.griggio(a)gmail.com>wrote: > I think 5 + 'hello' is plain wrong. > > In these cases: > > > 5 + (1 to: 10) > > 5 + (1@5) > > the message shouldn't be conmutative. What I mean is that I don't want that > to be the same as: > > (1 to: 10) + 5 > > (1 @ 5) + 5 > > > On Tue, Aug 24, 2010 at 5:44 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> I feel these pieces of code aren't really explicit in what they do >> >> 5 + 'hello' >> >> 5 + (1 to: 10) >> >> 5 + (1@5) >> >> >> >> On Tue, Aug 24, 2010 at 5:42 PM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> Well Collection and Point understand that message too. >>> >>> One step at a time, but an issue entry now so we don't forget about it. >>> >>> http://code.google.com/p/pharo/issues/detail?id=2858 >>> >>> >>> On Tue, Aug 24, 2010 at 5:20 PM, Carla F. Griggio < >>> carla.griggio(a)gmail.com> wrote: >>> >>>> What we've been discussing with Guille is that sometimes the 'type >>>> checking' (or actually, the conversion) is done, and sometimes not. >>>> >>>> For example: >>>> >>>> 5 + true >>>> >>>> true does not understand 'adaptToNumber:andSend:', so no magic >>>> conversion is done, but strings understand that message so we get things >>>> like: >>>> >>>> 5 + 'foo' = 5 >>>> >>>> This should be consistent regardless the type of the parameter. >>>> >>>> Cheers, >>>> Carla >>>> >>>> >>>> >>>> On Tue, Aug 24, 2010 at 5:10 PM, Guillermo Polito < >>>> guillermopolito(a)gmail.com> wrote: >>>> >>>>> Do we reeeeeally want to do >>>>> >>>>> 5 + '4' >>>>> >>>>> 5 + 'hello' >>>>> >>>>> ? >>>>> >>>> >>>> >>> >> >

Aug. 24, 2010

Re: [Pharo-project] PackageInfo >> printOn:

by Lukas Renggli

I would change it to PackageInfo>>printOn: aStream aStream print: self class; nextPutAll: ' named: '; print: self packageName That's basically the only solution that really makes sense. Lukas On 24 August 2010 22:50, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > may be { Collections-Weak } to make a displayed sign to denote packages. > > Stef > >> Or maybe we can add >> >> PackageInfo >> name >> ^ self packageName >> >> >> >> >> On Tue, Aug 24, 2010 at 4:54 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> Hi. The current implementation of PackageInfo >> printOn: Â is this: >> >> printOn: aStream >> >> Â Â super printOn: aStream. >> Â Â aStream nextPutAll: '(',self packageName,')'. >> >> So...it prints something like this: 'aPackageInfo(Collections-Weak)' >> >> most of the times I prefer to print 'Collections-Weak' >> >> in my image I change it to >> >> printOn: aStream >> >> Â Â aStream nextPutAll: self packageName. >> >> Do you think this can be useful for the rest or I just keep it in my image? >> >> Cheers >> >> Mariano >> >> _______________________________________________ >> 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 www.lukas-renggli.ch

Aug. 24, 2010

Re: [Pharo-project] String to Number conversion

by Guillermo Polito

Searching in the mails: <quote> self assert: '123blabla' squeezeOutNumber equals: 123. self assert: 'blabla123' squeezeOutNumber equals: 123. self assert: 'blabla12blabla' squeezeOutNumber equals: 12. self assert: ('12.3bla' squeezeOutNumber -12.3 ) abs < 0.0001. self assert: '.1' squeezeOutNumber > 0. </quote> I tried it in my image and 'bla' squeezeOutNumber. fails because of a primitive error... Anyway, the behavior is a little different from the existent in #readFrom: Did you mean to let the dirty stuff to #squeezeOutNumber and throw the error in the #readFrom:? On Tue, Aug 24, 2010 at 5:49 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > >> http://code.google.com/p/pharo/issues/detail?id=2857 > >> > >> Which will be the impact in the system and other tools to throw an error > >> when the conversion cannot take place? > >> I think an error must be thrown, but should it be in Pharo 1.2 or in > next > >> version? > >> > > > > My opinion: the system will be more predictible and cleaner ;) > > Me too. > Still this is strange because I'm sure we did that with niko and introduce > squeeze..... > So may be we integrated some older code on top. > I remember that even our changes broke scriptloader itself and the update > stream :) > > > Nicolas > > > >> On Tue, Aug 24, 2010 at 11:45 AM, Nicolas Cellier > >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >>> > >>> In squeak, (Integer readFromString: 'foo') ->Error > >>> > >>> Use: > >>> - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, > >>> - (Integer readFrom: 'foo' ifFail: []), to get nil > >>> > >>> Though it is possible, I dislike anwsering nil, because it would mean > >>> a bunch of #readFrom: send should be protected by #ifNil: Blocks... > >>> 1) That's nonsense, readFrom:ifFail: already does the work. > >>> 2) you cripple the code with Error conditions and end up with > >>> unreadable C-looking like code > >>> (3 lines of Error condition crap for 1 line of underlying algorithm > >>> at every function call) > >>> 3) Exception handling can avoid long chains of ifFail: / ifNil: tests > >>> > >>> But that conversation already took place many times... > >>> > >>> I'd like the readFrom:ifFail: form to be generalized to other objects, > >>> with default behaviour raising an Error. What do you think ? > >>> > >>> Nicolas > >>> > >>> 2010/8/24 Johan Brichau <johan(a)inceptive.be>: > >>>> > >>>> On 24 Aug 2010, at 15:19, StÃ©phane Ducasse wrote: > >>>> > >>>>> I thought that readFromString: was raising an error and that > >>>>> guessNumber* was returning zero > >>>> > >>>> I thought that too. I even have application code that shows that this > >>>> used to return nil in some version of Pharo... > >>>> But: > >>>> > >>>> 'foo' asInteger = nil > >>>> Integer readFromString: 'foo' = 0 > >>>> 'foo' asNumber -> Error > >>>> > >>>> aargh :-( > >>>> > >>>> disclaimer: currently testing this in pharo1.1 > >>>> > >>>> Johan > >>>> _______________________________________________ > >>>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 24, 2010

Re: [Pharo-project] Why String>>adaptToNumber: rcvr andSend: selector

by Carla F. Griggio

I think 5 + 'hello' is plain wrong. In these cases: 5 + (1 to: 10) 5 + (1@5) the message shouldn't be conmutative. What I mean is that I don't want that to be the same as: (1 to: 10) + 5 (1 @ 5) + 5 On Tue, Aug 24, 2010 at 5:44 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > I feel these pieces of code aren't really explicit in what they do > > 5 + 'hello' > > 5 + (1 to: 10) > > 5 + (1@5) > > > > On Tue, Aug 24, 2010 at 5:42 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Well Collection and Point understand that message too. >> >> One step at a time, but an issue entry now so we don't forget about it. >> >> http://code.google.com/p/pharo/issues/detail?id=2858 >> >> >> On Tue, Aug 24, 2010 at 5:20 PM, Carla F. Griggio < >> carla.griggio(a)gmail.com> wrote: >> >>> What we've been discussing with Guille is that sometimes the 'type >>> checking' (or actually, the conversion) is done, and sometimes not. >>> >>> For example: >>> >>> 5 + true >>> >>> true does not understand 'adaptToNumber:andSend:', so no magic conversion >>> is done, but strings understand that message so we get things like: >>> >>> 5 + 'foo' = 5 >>> >>> This should be consistent regardless the type of the parameter. >>> >>> Cheers, >>> Carla >>> >>> >>> >>> On Tue, Aug 24, 2010 at 5:10 PM, Guillermo Polito < >>> guillermopolito(a)gmail.com> wrote: >>> >>>> Do we reeeeeally want to do >>>> >>>> 5 + '4' >>>> >>>> 5 + 'hello' >>>> >>>> ? >>>> >>> >>> >> >

Aug. 24, 2010

Re: [Pharo-project] Poll: missing libraries to support busines

by StÃ©phane Ducasse

we had fun with bruce in this antiecological icebar at london so there is certainly a hope. Stef

Aug. 24, 2010

Re: [Pharo-project] PackageInfo >> printOn:

by StÃ©phane Ducasse

may be { Collections-Weak } to make a displayed sign to denote packages. Stef > Or maybe we can add > > PackageInfo >> name > ^ self packageName > > > > > On Tue, Aug 24, 2010 at 4:54 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi. The current implementation of PackageInfo >> printOn: is this: > > printOn: aStream > > super printOn: aStream. > aStream nextPutAll: '(',self packageName,')'. > > So...it prints something like this: 'aPackageInfo(Collections-Weak)' > > most of the times I prefer to print 'Collections-Weak' > > in my image I change it to > > printOn: aStream > > aStream nextPutAll: self packageName. > > Do you think this can be useful for the rest or I just keep it in my image? > > Cheers > > Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 24, 2010

Re: [Pharo-project] String to Number conversion

by StÃ©phane Ducasse

>> http://code.google.com/p/pharo/issues/detail?id=2857 >> >> Which will be the impact in the system and other tools to throw an error >> when the conversion cannot take place? >> I think an error must be thrown, but should it be in Pharo 1.2 or in next >> version? >> > > My opinion: the system will be more predictible and cleaner ;) Me too. Still this is strange because I'm sure we did that with niko and introduce squeeze..... So may be we integrated some older code on top. I remember that even our changes broke scriptloader itself and the update stream :) > Nicolas > >> On Tue, Aug 24, 2010 at 11:45 AM, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>> In squeak, (Integer readFromString: 'foo') ->Error >>> >>> Use: >>> - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, >>> - (Integer readFrom: 'foo' ifFail: []), to get nil >>> >>> Though it is possible, I dislike anwsering nil, because it would mean >>> a bunch of #readFrom: send should be protected by #ifNil: Blocks... >>> 1) That's nonsense, readFrom:ifFail: already does the work. >>> 2) you cripple the code with Error conditions and end up with >>> unreadable C-looking like code >>> (3 lines of Error condition crap for 1 line of underlying algorithm >>> at every function call) >>> 3) Exception handling can avoid long chains of ifFail: / ifNil: tests >>> >>> But that conversation already took place many times... >>> >>> I'd like the readFrom:ifFail: form to be generalized to other objects, >>> with default behaviour raising an Error. What do you think ? >>> >>> Nicolas >>> >>> 2010/8/24 Johan Brichau <johan(a)inceptive.be>: >>>> >>>> On 24 Aug 2010, at 15:19, StÃ©phane Ducasse wrote: >>>> >>>>> I thought that readFromString: was raising an error and that >>>>> guessNumber* was returning zero >>>> >>>> I thought that too. I even have application code that shows that this >>>> used to return nil in some version of Pharo... >>>> But: >>>> >>>> 'foo' asInteger = nil >>>> Integer readFromString: 'foo' = 0 >>>> 'foo' asNumber -> Error >>>> >>>> aargh :-( >>>> >>>> disclaimer: currently testing this in pharo1.1 >>>> >>>> Johan >>>> _______________________________________________ >>>> 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

Aug. 24, 2010

Re: [Pharo-project] [Fixed]: Issue 2856: Use unique URL to core from [Dev image]->World Menu->System>Software update

by StÃ©phane Ducasse

Exact! I like when people get the message :) Stef >> Absolutely, and no thanks necessary - it's my Pharo, too! > > Sean > -- > View this message in context: http://forum.world.st/Fixed-Issue-2856-Use-unique-URL-to-core-from-Dev-imag… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 24, 2010

Re: [Pharo-project] Why String>>adaptToNumber: rcvr andSend: selector

by Guillermo Polito

I feel these pieces of code aren't really explicit in what they do 5 + 'hello' 5 + (1 to: 10) 5 + (1@5) On Tue, Aug 24, 2010 at 5:42 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Well Collection and Point understand that message too. > > One step at a time, but an issue entry now so we don't forget about it. > > http://code.google.com/p/pharo/issues/detail?id=2858 > > > On Tue, Aug 24, 2010 at 5:20 PM, Carla F. Griggio <carla.griggio(a)gmail.com > > wrote: > >> What we've been discussing with Guille is that sometimes the 'type >> checking' (or actually, the conversion) is done, and sometimes not. >> >> For example: >> >> 5 + true >> >> true does not understand 'adaptToNumber:andSend:', so no magic conversion >> is done, but strings understand that message so we get things like: >> >> 5 + 'foo' = 5 >> >> This should be consistent regardless the type of the parameter. >> >> Cheers, >> Carla >> >> >> >> On Tue, Aug 24, 2010 at 5:10 PM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> Do we reeeeeally want to do >>> >>> 5 + '4' >>> >>> 5 + 'hello' >>> >>> ? >>> >> >> >

Aug. 24, 2010