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

Re: [Pharo-project] [Moose-dev] Re: for mondrian designers

by StÃ©phane Ducasse

On Dec 4, 2009, at 11:18 AM, Tudor Girba wrote: > Hi, > >>>> So consider to have a look at the cairo package in PharoTaskForces because it will not come to you alone :) > > What exactly should I load from PharoTaskForces to get Cairo? I do not really know: Rome-Core Rome-Canvas and Rome-Cairo. > > I see several Rome related packages, but which ones are needed? Is there a load script? No for now I just save the packages that were in Sophie-dev I know that alain loaded some of the Cairo packages for his experimentations. Now a script is the first step than after identifying what is working not working. You can have a look also at Sophie-dev image. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "There are no old things, there are only old ways of looking at them." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Dec. 4, 2009

[Pharo-project] Fwd: what is the status of this one? _ in selector

by StÃ©phane Ducasse

Begin forwarded message: > From: Lukas Renggli <renggli(a)me.com> > Date: December 4, 2009 8:18:48 AM GMT+01:00 > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: what is the status of this one? _ in selector > > Thanks for letting me know about the bugs that I can fix, because I don't really follow the incoming bugs. > > I fixed the one with the small input box: > > http://code.google.com/p/pharo/issues/detail?id=1375 > > That one I marked as invalid: > > http://code.google.com/p/pharo/issues/detail?id=1355 > >> What is the status of this one? _ in selector > > > I can provide an easy fix of the Pharo compiler. Another possibility would be to provide a fix with a preference to toggle between the two modes, with the new preference system this is now much simpler. > > The problem of the preference is that the system could be in an inconsistent state and not allow a recompilation anymore. > > So what kind of change do you want? > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch >

Dec. 4, 2009

Re: [Pharo-project] cmdDotEnabled

by StÃ©phane Ducasse

Fix it and keep it was the message Stef On Dec 4, 2009, at 11:16 AM, Mariano Martinez Peck wrote: > 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 > > Cheers > > Mariano > > On Fri, Dec 4, 2009 at 11:12 AM, StÃ©phane Ducasse <stephane.ducasse(a)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 > > 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

Dec. 4, 2009

[Pharo-project] [update 1.1] #11070

by Marcus Denker

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

Dec. 4, 2009

Re: [Pharo-project] [Moose-dev] Re: for mondrian designers

by Tudor Girba

Hi, >>> So consider to have a look at the cairo package in PharoTaskForces >>> because it will not come to you alone :) What exactly should I load from PharoTaskForces to get Cairo? I see several Rome related packages, but which ones are needed? Is there a load script? Cheers, Doru -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them."

Dec. 4, 2009

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

by StÃ©phane Ducasse

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

Dec. 4, 2009

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

by StÃ©phane Ducasse

I would really like to get the changes suggested by nicolas so if one of you want to support by sending code it would be cool. We are trying to close some fixed issues (besides working on our little research activities). Stef On Dec 4, 2009, at 8:29 AM, Henrik Sperre Johansen wrote: > 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

Dec. 4, 2009

Re: [Pharo-project] cmdDotEnabled

by Mariano Martinez Peck

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 Cheers Mariano On Fri, Dec 4, 2009 at 11:12 AM, StÃ©phane Ducasse <stephane.ducasse(a)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 > > 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] about keys returning a set

by StÃ©phane Ducasse

do you have an idea why people did not use it? Stef On Dec 4, 2009, at 8:58 AM, Lukas Renggli wrote: > 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 > > _______________________________________________ > 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 StÃ©phane Ducasse

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 > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 4, 2009