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

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

by Lukas Renggli

> Even with these numbers I cannot evaluate what could be a slowdown/pseed up > impact on the complete system. I imgain that the ietration slow down should be minimal > and compensated by the creation speed up. Yeah, the iteration slowdown should be minimal of using Set vs. Array. What I think is more critical that you change the semantics of the returned data-structure. That could not only break clients, but also their expectations towards performance. I find interesting that most sets are almost empty. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 4, 2009

[Pharo-project] christmas coding parties?

by StÃ©phane Ducasse

Hi all I would like to organize a couple of coding parties around christmas. The 18 of december? is one possibility (even if I can only start at 11h). So if some of you are close to lille during holidays we could have fun coding together. I would like to organize a moose day too. I want to code what I have in mind with CAnalyzer and mondrian. Stef

Dec. 4, 2009

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

by StÃ©phane Ducasse

this is interesting to see that this is still a guess game. Even with these numbers I cannot evaluate what could be a slowdown/pseed up impact on the complete system. I imgain that the ietration slow down should be minimal and compensated by the creation speed up. May be in the future when system will have a better knowledge of themselves we may end up having better tools... > I posted these numbers a while ago. > > In my image the average length of a Dictionary is 10, the average > length of a Set is 1.2. > > Lukas > > > 2009/12/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> I would be curious to see the average length of dictionary keys (except Smalltalk) >> and see the performance penalty between set and array for the do: >> >> Stef >> >>> 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 >>>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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] getting rid of Symbol >> new: ?

by Adrian Lienhard

Hi Sheri, Sounds ok to make new: raise an exception if you adjust the tests (and any code that exists in the image using new: (but I assume there is none)). However, the actual reason why you get multiple same symbols after loading a segment likely is unrelated to ByteSymbol class>>new:. I guess it is because when creating the segment you do not hold onto these symbols. Like this they do not get into the outPointers ref stream but in the bytearray. When installing the segment again, with same symbols existing in the image already, then you get duplicates. The "right way" to do this is to strongly hold onto all symbols when creating a segment. See #createSegmentFrom:. You can reproduce this problem by commenting out the first line of #createSegmentFrom: and running #testSymbols. Let us know how it goes... BTW, Mariano is also writing ImageSegment tests, so maybe you want to join forces (or maybe he already is the colleague you mentioned?). Cheers, Adrian On Dec 3, 2009, at 23:10 , StÃ©phane Ducasse wrote: >> From: Sheridan Mahoney <sheridan(a)sheridan-mahoney.com> >> Date: December 3, 2009 11:04:19 PM GMT+01:00 >> To: pharo-project-bounces(a)lists.gforge.inria.fr >> Subject: Re: getting rid of Symbol >> new: ? >> Reply-To: sheridan(a)sheridan-mahoney.com >> >> >> A colleague and I are investigating the ImageSegment class and its >> methods, we came across an issue I would like to get external >> opinions on. Newbie alert, BTW (at least one of us, no names >> mentioned...). Also, this is not a problem that will affect many >> users, but it is familiarizing us with the check-in process, >> slices, etc. While working on ImageSegment tests, we discovered a >> problem on trying to load segments that had Symbols in the root >> array. It is possible to create 2 ByteSymbols with the same >> sequence of characters. :( In trying to track down how this is >> possible, we came across a side issue, that ByteSymbol new: had >> the capacity to create multiple new ByteSymbols with the same >> number of nil characters (as in, initialized with nil). We want to >> dissallow Symbol new: , which would cause people to use one of >> the nicer methods for Symbol/ByteSymbol creation (namely, one which >> checks that the sequence of characters doesn't already exist, as >> part of the creation process). We have a fix we want to check in, >> but currently it breaks a test case in the SymbolTest class, which >> is checking that new: works. We also changed the intern: >> method on the class side of Symbol to use basicNew: instead >> of new: . Are there reasons to keep 'Symbol new:' , that >> outweigh the reasons to get rid of it? >> Many thanks, >> and Cheers, >> Sheri Mahoney > > _______________________________________________ > 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] allowUnderscoreAssignment is not functional

by StÃ©phane Ducasse

what are the pros and cons? I would like to avoid to have _ in the code but this is good to let people load their code. So I would keep it and make it work. Stef On Dec 4, 2009, at 9:40 AM, Alain Plantec wrote: > 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 > > _______________________________________________ > 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 Tudor Girba

Using this script: (Dictionary allInstances inject: 0 into: [ :r :e | r + e size ]) / Dictionary allInstances size asFloat I get 14.23 in my image. Using this script: (Set allInstances inject: 0 into: [ :r :e | r + e size ]) / Set allInstances size asFloat I get 0.49 Cheers, Doru On 4 Dec 2009, at 11:49, Lukas Renggli wrote: > I posted these numbers a while ago. > > In my image the average length of a Dictionary is 10, the average > length of a Set is 1.2. > > Lukas > > > 2009/12/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> I would be curious to see the average length of dictionary keys >> (except Smalltalk) >> and see the performance penalty between set and array for the do: >> >> Stef >> >>> 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 >>>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

Dec. 4, 2009

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

by Lukas Renggli

I posted these numbers a while ago. In my image the average length of a Dictionary is 10, the average length of a Set is 1.2. Lukas 2009/12/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I would be curious to see the average length of dictionary keys Â (except Smalltalk) > and see the performance penalty between set and array for the do: > > Stef > >> 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 >>> >> >> _______________________________________________ >> 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

Dec. 4, 2009

Re: [Pharo-project] allowUnderscoreAssignment is not functional

by Lukas Renggli

Yes, that we noticed too. This method is never called. Lukas 2009/12/4 Alain Plantec <alain.plantec(a)free.fr>: > 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 > > _______________________________________________ > 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

Dec. 4, 2009

Re: [Pharo-project] cmdDotEnabled

by Alain Plantec

Mariano Martinez Peck a Ã©crit : > I think you didn't understand Alain (or maybe I didn't understand) . > The preference exist but no matter if it is enable or not, the > behaviour is the same. If this is true, I see two options: > > 1) Fix it > 2) remove the preference yes, this what the questions. but finally, the answers are given, we keep the preference and I open an issue. Alain > > Cheers > > Mariano > > On Fri, Dec 4, 2009 at 11:12 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: > > Yes let us keep it for now. > Even if I would love to ressurect a good keybinbing package in the > future. > > Stef > On Dec 4, 2009, at 10:55 AM, Marcus Denker wrote: > > > > > 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 > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@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 > <mailto:Pharo-project@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. 4, 2009

Re: [Pharo-project] [update 1.1] #11070

by StÃ©phane Ducasse

thanks marcus. Stef On Dec 4, 2009, at 11:18 AM, Marcus Denker wrote: > 11070 > ----- > > Issue 1539: remove class ProjectLoading > Issue 1540: remove more unsent messages... > Issue 1537: vmSatisticsReportString averages always show 0 at first decimal place > Issue 1529: Date and time classes should not rely on collections arithmetic > > > _______________________________________________ > 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