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

Re: [Pharo-project] getting rid of Symbol >> new: ?

by StÃ©phane Ducasse

thanks. I know these book Now the question is: are they any senders... > I'm not sure that forbidding new: is a good idea. In Smalltalk it is rare to forbid such methods. > > "If an instance created by sending the #new method ... would cause an error, a common practice is to override the behavior of #new so that it fails." Skublics, Klimas, & Thomas, Smalltalk with Style, p. 14 (Prentice Hall, 1996). > > James Foster > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 4, 2009

Re: [Pharo-project] cmdDotEnabled

by Marcus Denker

On Dec 4, 2009, at 10:01 AM, Alain Plantec wrote: > the same as for allowUnderscoreAssignment, > cmd-dot is always functional whatever allowUnderscoreAssignment > preference value. > do we keep the preference ? Disabeling cmd-dot seems useful for end-user apps (e.g. Kiosk apps). So maybe we want to keep it. Marcus

Dec. 4, 2009

Re: [Pharo-project] about keys returning a set

by Henrik Johansen

On Dec 4, 2009, at 9:12 30AM, Igor Stasenko wrote: > 2009/12/4 Lukas Renggli <renggli(a)gmail.com>: >> Actually the code can be further optimized: >> >> Dictionary>>keys >> "Answer a Set containing the receiver's keys." >> >> | result container | >> result := Set basicNew setTally: tally array: array copy. >> container := result array. >> 1 to: container size do: [ :index | >> (container at: index) >> ifNotNil: [ :assoc | container at: index put: assoc key ] ]. >> ^ result >> >> This is roughly 22 times faster than the current implementation, and 5 >> times faster than the squeak implementation. >> >> The system doesn't seem to break with this change :-) >> > except that it breaking encapsulation. > Thus i vote -1 for this kind of optimization :) You could also achieve the same performance by writing the method (returning an array) | result currentIX | result := Array new: tally. currentIX := 1. 1 to: array size do: [:ix | (array at: ix) ifNotNil: [:assoc | result at: currentIX put: assoc key. currentIX := currentIX +1]]. ^result Which is, unless you consider using at:put: and expecting an Array of size n to hold n elements, not breaking encapsulation. Though, the block creation overhead of using keysDo (which is the main reason for the performance difference seen between the two) should, if I've understood Eliot correctly, go away with a stack-based vm. While on the topic of the Set hierarchy, is it just me, or is the Keyed* versions a mistake? Giving a block that computes a key means the collection either needs to: - Know about what type of objects is put into it, in which case you break encapsulation. and it would likely be better to just implement hash/= for those types of objects. - Only use info available of Object, in which case you're not very likely to end up with much better hash functions than scaledIdentityHash anyways. Cheers, Henry

Dec. 4, 2009

Re: [Pharo-project] about keys returning a set

by Henrik Johansen

Never mind, didn't notice IdentityDictionary reimplements keys... :/ On Dec 4, 2009, at 10:10 46AM, Henrik Johansen wrote: > This merely shows there are no tests testing the keys method of an IdentityDictionary which contains objects for which hash != identityHash... > > Cheers, > Henry > > On Dec 4, 2009, at 9:06 25AM, Lukas Renggli wrote: > >> keys >> "Answer a Set containing the receiver's keys." >> >> | result container | >> result := Set basicNew setTally: tally array: array copy. >> container := result array. >> 1 to: container size do: [ :index | >> (container at: index) >> ifNotNil: [ :assoc | container at: index put: assoc key ] ]. >> ^ result > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 4, 2009

Re: [Pharo-project] about keys returning a set

by Henrik Johansen

This merely shows there are no tests testing the keys method of an IdentityDictionary which contains objects for which hash != identityHash... Cheers, Henry On Dec 4, 2009, at 9:06 25AM, Lukas Renggli wrote: > keys > "Answer a Set containing the receiver's keys." > > | result container | > result := Set basicNew setTally: tally array: array copy. > container := result array. > 1 to: container size do: [ :index | > (container at: index) > ifNotNil: [ :assoc | container at: index put: assoc key ] ]. > ^ result

Dec. 4, 2009

[Pharo-project] cmdDotEnabled

by Alain Plantec

the same as for allowUnderscoreAssignment, cmd-dot is always functional whatever allowUnderscoreAssignment preference value. do we keep the preference ? Alain

Dec. 4, 2009

Re: [Pharo-project] about keys returning a set

by Nicolas Cellier

2009/12/4 Lukas Renggli <renggli(a)gmail.com>: > Actually the code can be further optimized: > > Dictionary>>keys > Â Â Â Â "Answer a Set containing the receiver's keys." > > Â Â Â Â | result container | > Â Â Â Â result := Set basicNew setTally: tally array: array copy. > Â Â Â Â container := result array. > Â Â Â Â 1 to: container size do: [ :index | > Â Â Â Â Â Â Â Â (container at: index) > Â Â Â Â Â Â Â Â Â Â Â Â ifNotNil: [ :assoc | container at: index put: assoc key ] ]. > Â Â Â Â ^ result > > This is roughly 22 times faster than the current implementation, and 5 > times faster than the squeak implementation. > > The system doesn't seem to break with this change :-) > > Lukas > Yes Levente considered this implementation as keysAsSet, but did not pushed it in trunk so far. You must also consider that each further usage of a Set will add a performance penalty vs an Array, especially do: Nicolas > 2009/12/4 Lukas Renggli <renggli(a)gmail.com>: >> I wonder if ever something along the following lines was considered? >> >> Dictionary>>keys >> Â Â Â Â "Answer a Set containing the receiver's keys." >> >> Â Â Â Â | result | >> Â Â Â Â result := Set basicNew. >> Â Â Â Â result setTally: tally array: (array collect: [ :each | >> Â Â Â Â Â Â Â Â each isNil ifFalse: [ each key ] ]). >> Â Â Â Â ^ result >> >> This returns a Set, so it wouldn't break any semantics. In my >> benchmark this is roughly 8x faster than the current implementation, >> and 2x faster than the optimized Squeak implementation. >> >> The drawback is that it makes some heavy assumptions on the internal >> structure of Dictionary, Association and Set. >> >> Lukas >> >> 2009/12/4 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: >>> A small addendum ;) >>> On 03.12.2009 22:13, Nicolas Cellier wrote: >>>> 3) identify thise sending a potential inefficient message (includes:) >>>> insert keys asSet in this case (only if includes: is in a loop!) >>>> >>>> >>> 3b. If the keys collection isn't used for anything else, change to use >>> includesKey: instead. >>> >>> Cheers, >>> Henry >>> >>> _______________________________________________ >>> 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 >

Dec. 4, 2009

[Pharo-project] allowUnderscoreAssignment is not functional

by Alain Plantec

Hi all, maybe I've missed something but whatever value is set to this preference, the result is that underscore is always allowed. Note that it is used by the scanner: Scanner>>xUnderscore Preferences allowUnderscoreAssignment ifFalse:[^self xIllegal]. self step. tokenType := #leftArrow. ^token := #':=' The question behind is do we keep this preference ? Cheers Alain

Dec. 4, 2009

Re: [Pharo-project] about keys returning a set

by Igor Stasenko

2009/12/4 Lukas Renggli <renggli(a)gmail.com>: > Actually the code can be further optimized: > > Dictionary>>keys > Â Â Â Â "Answer a Set containing the receiver's keys." > > Â Â Â Â | result container | > Â Â Â Â result := Set basicNew setTally: tally array: array copy. > Â Â Â Â container := result array. > Â Â Â Â 1 to: container size do: [ :index | > Â Â Â Â Â Â Â Â (container at: index) > Â Â Â Â Â Â Â Â Â Â Â Â ifNotNil: [ :assoc | container at: index put: assoc key ] ]. > Â Â Â Â ^ result > > This is roughly 22 times faster than the current implementation, and 5 > times faster than the squeak implementation. > > The system doesn't seem to break with this change :-) > except that it breaking encapsulation. Thus i vote -1 for this kind of optimization :) > Lukas > > 2009/12/4 Lukas Renggli <renggli(a)gmail.com>: >> I wonder if ever something along the following lines was considered? >> >> Dictionary>>keys >> Â Â Â Â "Answer a Set containing the receiver's keys." >> >> Â Â Â Â | result | >> Â Â Â Â result := Set basicNew. >> Â Â Â Â result setTally: tally array: (array collect: [ :each | >> Â Â Â Â Â Â Â Â each isNil ifFalse: [ each key ] ]). >> Â Â Â Â ^ result >> >> This returns a Set, so it wouldn't break any semantics. In my >> benchmark this is roughly 8x faster than the current implementation, >> and 2x faster than the optimized Squeak implementation. >> >> The drawback is that it makes some heavy assumptions on the internal >> structure of Dictionary, Association and Set. >> >> Lukas >> >> 2009/12/4 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: >>> A small addendum ;) >>> On 03.12.2009 22:13, Nicolas Cellier wrote: >>>> 3) identify thise sending a potential inefficient message (includes:) >>>> insert keys asSet in this case (only if includes: is in a loop!) >>>> >>>> >>> 3b. If the keys collection isn't used for anything else, change to use >>> includesKey: instead. >>> >>> Cheers, >>> Henry >>> >>> _______________________________________________ >>> 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 > -- Best regards, Igor Stasenko AKA sig.

Dec. 4, 2009

Re: [Pharo-project] about keys returning a set

by Lukas Renggli

Actually the code can be further optimized: Dictionary>>keys "Answer a Set containing the receiver's keys." | result container | result := Set basicNew setTally: tally array: array copy. container := result array. 1 to: container size do: [ :index | (container at: index) ifNotNil: [ :assoc | container at: index put: assoc key ] ]. ^ result This is roughly 22 times faster than the current implementation, and 5 times faster than the squeak implementation. The system doesn't seem to break with this change :-) Lukas 2009/12/4 Lukas Renggli <renggli(a)gmail.com>: > I wonder if ever something along the following lines was considered? > > Dictionary>>keys > Â Â Â Â "Answer a Set containing the receiver's keys." > > Â Â Â Â | result | > Â Â Â Â result := Set basicNew. > Â Â Â Â result setTally: tally array: (array collect: [ :each | > Â Â Â Â Â Â Â Â each isNil ifFalse: [ each key ] ]). > Â Â Â Â ^ result > > This returns a Set, so it wouldn't break any semantics. In my > benchmark this is roughly 8x faster than the current implementation, > and 2x faster than the optimized Squeak implementation. > > The drawback is that it makes some heavy assumptions on the internal > structure of Dictionary, Association and Set. > > Lukas > > 2009/12/4 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: >> A small addendum ;) >> On 03.12.2009 22:13, Nicolas Cellier wrote: >>> 3) identify thise sending a potential inefficient message (includes:) >>> insert keys asSet in this case (only if includes: is in a loop!) >>> >>> >> 3b. If the keys collection isn't used for anything else, change to use >> includesKey: instead. >> >> Cheers, >> Henry >> >> _______________________________________________ >> 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

Dec. 4, 2009