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

Re: [Pharo-project] #sortBlock:

by Julian Fitzell

On Thu, Dec 24, 2009 at 1:26 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Dec 24, 2009, at 10:00 AM, Julian Fitzell wrote: > >> On Thu, Dec 24, 2009 at 12:19 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>>> #sortBlock: is defined by ANSI on SortedCollection as an accessor and >>>>>> an instance creation method. That's what it sounds like and shouldn't >>>>>> be implemented on non-sorted collections. >>>>> >>>>> Why? what would be the reason not to use sortBlock: for others? >>>> >>>> The intention is different. #sortBlock: tells a collection to maintain >>>> itself as sorted even after additions and deletions. This message is not >>>> appropriate for collections that do not have that ability. >>>> >>>> #sortBlock: is not the best name for this functionality, but I think >>>> it's bad to use #sortBlock: with a different meaning. >>> >>> I agree :) >>> Now SortedCollection should understand sort too which uses sortBlock: >>> My main concern is polymorphism between collection which are nearly the same! >> >> #sortBlock: is an accessor for the sortBlock instance variable on >> SortedCollection. It makes no sense for a collection that doesn't have >> that instance variable to have that accessor. > > did I say that? I do not think so. I'm not that idiot. > No I say that SortedCollection should understand sort: Ah, apologies - I misunderstood what you were saying (I was a little surprised that you would be arguing what I thought you were arguing :) ). Julian

Dec. 25, 2009

Re: [Pharo-project] Fwd: hasEqualElements:

by Eliot Miranda

On Thu, Dec 24, 2009 at 2:52 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Thu, 24 Dec 2009, Eliot Miranda wrote: > > > > This 'hack' is as old as Smalltalk-80 V2 and is AFAICT in all > Smalltalk-80 > > derived Smalltalks: > > > > !Object methodsFor: 'accessing'! > > at: index > > "Answer the value of an indexable field in the receiver. Fail if the > > argument index is not an Integer or is out of bounds. Essential. See > > documentation in Object metaclass." > > > > <primitive: 60> > > index isInteger > > ifTrue: [self errorSubscriptBounds: index]. > > (index isKindOf: Number) > > ifTrue: [^self at: index truncated] > > ifFalse: [self errorNonIntegerIndex]! > > > > It is also free in the sense that the failure code is only invoked when > the > > primitive fails and so adds nothing to the cost of successful accesses, > > which are the high dynamic frequency operation. It will also show up > under > > profiling if one is concerned about efficiency, and so isn't a hidden > cost. > > > > It is also in keeping with Smalltalk's mixed mode/arbitrary precision > > implicit coercion number system that one *can* use fractions or floats as > > indices. > > > > Stripping out coercions like this will make the system more brittle. So > > please do *not* remove this "hack". I think it's a feature and a useful > > one. > > Can you give me an example that demonstrates the usefulness of this > feature? > | a r | a := Array new: 10 withAll: 0. r := Random new. 100 timesRepeat: [| v | v := r next * 10 + 1. a at: v put: (a at: v) + 1]. a i.e. I didn't have to provide an explicit rounding step. That's useful. But in general anywhere where an index is derived by some calculation not having to provide the rounding step could be useful/helpful/more concise. e.g. (n roundTo: 0.1) * 10 vs ((n roundTo: 0.1) * 10) asInteger. Some thought went into the original choice. It is not a hack but there by intent. The integers are simply a subset of the reals and forcing the programmer to use them is favouring the machine above the programmer. But I think you should justify getting rid of it rather than my having to justify keeping it. Getting rid of it risks breaking code. If it is there but does not harm then why get rid of it? best Eliot > > > Levente > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 25, 2009

Re: [Pharo-project] about displayString

by Schwab,Wilhelm K

Stef, Dolphin has all long used #display* to represent objects for end users, and #print* for developers. Squeak grabbed #displayOn: for Morphic, and I would greatly enjoy seeing that cleared up or proved orthogonal to creating text from objects. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Thursday, December 24, 2009 5:35 PM To: Pharo-project(a)lists.gforge.inria.fr Development Subject: [Pharo-project] about displayString Hi I would really like that we introduce displayString to keep printOn: for internal purpose. Igor I remember that you got a proposal about that. Do you remember? Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 24, 2009

Re: [Pharo-project] Fwd: hasEqualElements:

by Levente Uzonyi

On Thu, 24 Dec 2009, Eliot Miranda wrote: > > This 'hack' is as old as Smalltalk-80 V2 and is AFAICT in all Smalltalk-80 > derived Smalltalks: > > !Object methodsFor: 'accessing'! > at: index > "Answer the value of an indexable field in the receiver. Fail if the > argument index is not an Integer or is out of bounds. Essential. See > documentation in Object metaclass." > > <primitive: 60> > index isInteger > ifTrue: [self errorSubscriptBounds: index]. > (index isKindOf: Number) > ifTrue: [^self at: index truncated] > ifFalse: [self errorNonIntegerIndex]! > > It is also free in the sense that the failure code is only invoked when the > primitive fails and so adds nothing to the cost of successful accesses, > which are the high dynamic frequency operation. It will also show up under > profiling if one is concerned about efficiency, and so isn't a hidden cost. > > It is also in keeping with Smalltalk's mixed mode/arbitrary precision > implicit coercion number system that one *can* use fractions or floats as > indices. > > Stripping out coercions like this will make the system more brittle. So > please do *not* remove this "hack". I think it's a feature and a useful > one. Can you give me an example that demonstrates the usefulness of this feature? Levente

Dec. 24, 2009

Re: [Pharo-project] Fonts

by Schwab,Wilhelm K

By 12.2, I was referring to the image 09.12.2 -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Thursday, December 24, 2009 5:26 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Fonts I don't know what the "12.2 web image" is and how this is related to my load scripts? > Lukas, are your build scripts on the Wiki updated for the changes? My load scripts are for PharoCore 1.0rc1 and set the bitmap fonts. 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

Dec. 24, 2009

Re: [Pharo-project] Fonts

by Schwab,Wilhelm K

Lukas, Are the bitmap fonts by choice or compromise (perhaps OS specific)? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Thursday, December 24, 2009 5:26 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Fonts I don't know what the "12.2 web image" is and how this is related to my load scripts? > Lukas, are your build scripts on the Wiki updated for the changes? My load scripts are for PharoCore 1.0rc1 and set the bitmap fonts. 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

Dec. 24, 2009

[Pharo-project] about displayString

by StÃ©phane Ducasse

Hi I would really like that we introduce displayString to keep printOn: for internal purpose. Igor I remember that you got a proposal about that. Do you remember? Stef

Dec. 24, 2009

Re: [Pharo-project] Fonts

by Lukas Renggli

I don't know what the "12.2 web image" is and how this is related to my load scripts? > Lukas, are your build scripts on the Wiki updated for the changes? My load scripts are for PharoCore 1.0rc1 and set the bitmap fonts. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 24, 2009

Re: [Pharo-project] Fwd: hasEqualElements:

by Eliot Miranda

On Thu, Dec 24, 2009 at 12:21 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Thu, 24 Dec 2009, csrabak(a)bol.com.br wrote: > > > Em 24/12/2009 01:21, Levente Uzonyi < leves(a)elte.hu > escreveu: > > > >> On Thu, 24 Dec 2009, csrabak(a)bol.com.br wrote: > >> > >>> Em 23/12/2009 22:51, Nicolas Cellier escreveu: > >>> > >>>> 2009/12/24 : > >>>>> Igor, Sometimes a fallacy can be written by clever people, by > >>>>> accident. If you pay attention to the line: (size := self size) > >>>>> = otherCollection size ifFalse: [^false]. I all Smalltalks > >>>>> [Except Pharo to what I wrote a comment in issue 1637 > >>>>> http://code.google.com/p/pharo/issues/detail?id=1637] this would > >>>>> return false if self be not Collection or otheCollection > >>>>> isKindOf: Collection not. This happens because in these > >>>>> Smalltalks Object>>size returns zero. > >>>>> Not so sure. Try 1.0 size, then 1.0 at: 1.0 size in you > >>>> favourite > >>>> dialect. > >>> Nicolas, > >>> In Squeak 3.10.2-7179: > >>> 1.0 size -> 2 "OK I'm surprised here" > >> It's not surprising since Float is a variable word subclass of > >> Number. :) > >> > >>> 1.0 at: 1.0 size -> 0 "this will not work anymore in Pharo because > >>> indices have to be Integer in Pharo right now" > >> The index is 2, so it will work. Btw, I wonder how pharo can force > >> Integer indices if the vm accepts Floats too. > >> > > Levente, > > > > In fact VM _does_ _not_ accept Floats as indices. There is a hack in > > Squeak code (which in fact contradicts the comment in the method) in > > the #at: methods that make a conversion from Number to Integer. > > > > If you comment that code out you'll see the VM #at: (via the primitive) > > will fail with Floats. > > True, and cool, since this hack can be removed. Now I wonder why did I > assume that the vm has this hack. :) > This 'hack' is as old as Smalltalk-80 V2 and is AFAICT in all Smalltalk-80 derived Smalltalks: !Object methodsFor: 'accessing'! at: index "Answer the value of an indexable field in the receiver. Fail if the argument index is not an Integer or is out of bounds. Essential. See documentation in Object metaclass." <primitive: 60> index isInteger ifTrue: [self errorSubscriptBounds: index]. (index isKindOf: Number) ifTrue: [^self at: index truncated] ifFalse: [self errorNonIntegerIndex]! It is also free in the sense that the failure code is only invoked when the primitive fails and so adds nothing to the cost of successful accesses, which are the high dynamic frequency operation. It will also show up under profiling if one is concerned about efficiency, and so isn't a hidden cost. It is also in keeping with Smalltalk's mixed mode/arbitrary precision implicit coercion number system that one *can* use fractions or floats as indices. Stripping out coercions like this will make the system more brittle. So please do *not* remove this "hack". I think it's a feature and a useful one. > > Levente > > > > > -- > > Cesar Rabak > > > > _______________________________________________ > > 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 >

Dec. 24, 2009

Re: [Pharo-project] Fwd: hasEqualElements:

by Levente Uzonyi

On Thu, 24 Dec 2009, csrabak(a)bol.com.br wrote: > Em 24/12/2009 01:21, Levente Uzonyi < leves(a)elte.hu > escreveu: > >> On Thu, 24 Dec 2009, csrabak(a)bol.com.br wrote: >> >>> Em 23/12/2009 22:51, Nicolas Cellier escreveu: >>> >>>> 2009/12/24 : >>>>> Igor, Sometimes a fallacy can be written by clever people, by >>>>> accident. If you pay attention to the line: (size := self size) >>>>> = otherCollection size ifFalse: [^false]. I all Smalltalks >>>>> [Except Pharo to what I wrote a comment in issue 1637 >>>>> http://code.google.com/p/pharo/issues/detail?id=1637] this would >>>>> return false if self be not Collection or otheCollection >>>>> isKindOf: Collection not. This happens because in these >>>>> Smalltalks Object>>size returns zero. >>>>> Not so sure. Try 1.0 size, then 1.0 at: 1.0 size in you >>>> favourite >>>> dialect. >>> Nicolas, >>> In Squeak 3.10.2-7179: >>> 1.0 size -> 2 "OK I'm surprised here" >> It's not surprising since Float is a variable word subclass of >> Number. :) >> >>> 1.0 at: 1.0 size -> 0 "this will not work anymore in Pharo because >>> indices have to be Integer in Pharo right now" >> The index is 2, so it will work. Btw, I wonder how pharo can force >> Integer indices if the vm accepts Floats too. >> > Levente, > > In fact VM _does_ _not_ accept Floats as indices. There is a hack in > Squeak code (which in fact contradicts the comment in the method) in > the #at: methods that make a conversion from Number to Integer. > > If you comment that code out you'll see the VM #at: (via the primitive) > will fail with Floats. True, and cool, since this hack can be removed. Now I wonder why did I assume that the vm has this hack. :) Levente > > -- > Cesar Rabak > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 24, 2009