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

Re: [Pharo-project] Issue 1634: Object allSubInstances slooooow

by Eliot Miranda

On Sat, Dec 19, 2009 at 9:11 AM, Stan Shepherd <stan.shepherd414(a)gmail.com>wrote: > > > Eliot Miranda-2 wrote: > > > > On Fri, Dec 18, 2009 at 6:04 PM, Martin McClure > > <martin(a)hand2mouse.com>wrote: > > > >> Stan Shepherd wrote: > >> > Pharo image: Pharo | Pharo-core > >> > PharoCore1.0rc1 Latest update: #10502 > >> > VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: > >> > #10074] > >> > > >> > Steps to reproduce: > >> > 1.[Object allSubInstances size inspect] timeToRun 375479 (6 minutes) > >> > > >> > with fix > >> > [Object allSubInstances size inspect] timeToRun 22335 (22 seconds) > >> > > >> > Attached treats Object as a special case, and takes advantage of > >> primitive > >> > in SystemNavigation>>allObjectsDo: > >> > >> It looks like with this change, Object allSubInstances would return > >> instances of classes that do not inherit from Object, for instance > >> objects that inherit from ProtoObject. > >> > >> Perhaps the special case should go on ProtoObject? Or a test could be > >> made of how many subclasses a class has, and if it's over some arbitrary > >> number just iterate through all objects and test each one for isKindOf:? > >> Don't know how fast that would be, maybe it's not faster. But probably > >> slow is preferable to incorrect. If you just want "all objects" and > >> don't care about their class then you can always use > >> SystemNavigation>>allObjectsDo: rather than allSubInstances. > >> > > > > +1. > > > > I don't think there's any justification for this hack. It's possible to > > have another root to the hierarchy apart from ProtoObject. Further, a > bit > > weak, but allSubInstancesDo: has ordering properties; it will evaluate > the > > block with all instances of a class followed by all instances of another > > and > > so on; it will visit all instances of any superclass before it visits any > > instances of subclasses, and that could be useful. If you want to use > > allObjectsDo: use it. Of course allSubInstancesDo: is slow; it makes as > > many scans of the system as there are classes (Metaclass avoids the scan > > by > > evaluating with soleInstance). But that's not a justification for > > special-casing one use of it to a freely accessible but different > > alternative. > > > > > >> Regards, > >> > >> -Martin > >> > >> _______________________________________________ > >> 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 > > > > > Eliot Miranda-2 wrote: > > > > I don't think there's any justification for this hack. > > > > Quite so. It was late, and I'd thought better of it by morning. However, > don't feel you need to spare my feelings ;) > Sorry Sam :) I had to be blunt. I knew you'd understand :) Forgive me. > > Taking a step back, Object allSubinstances size seems to be a common proxy > measure for the size/bloat/complexity of an image. > (E.g. http://www.object-arts.com/docs/index.html?how_many_objects.htm ). > Running it on a large production system would potentially be very slow. > It could also be something a current Smalltaker would run to check out > Pharo, > in which case a coffee break would be warranted. So from a marketing of > Pharo > perspective, 6 minutes seems too long to me. Yes, an experienced user will > avoid it. > I have no proposal as to how to catch that case while avoiding a hack. > Adding a specific > allSubinstances to Object class would break inheritance chain to Behavior. > > > In the meantime, perhaps there should be an alternative simple measure > available: > > SystemNavigation>>allObjects > "A fast way to list all current objects in the image. > n.b. this will include the classes ImageSegmentRootStub > MessageCatcher > TestCoverage DynamicBindingsInfo, and possibly others, that do not > inherit from Object. These classes probably have no instances, but > it is not safe to assume this" > | aCollection | > aCollection := OrderedCollection new. > self allObjectsDo: > [:x | x == aCollection ifFalse: [aCollection add: x]]. > ^ aCollection > > with a comment in allSubInstances > "for Prototype>>allSubInstances, Object>>allSubInstances,consider > using > SystemNavigation>>allObjects. This is much faster. see comment > there" > > > Martin McClure wrote: > > > > It looks like with this change, Object allSubInstances would return > > instances of classes that do not inherit from Object, for instance > > objects that inherit from ProtoObject. > > > Yes. It doesn't currently, but it could. See comment above. > > > Martin McClure wrote: > > > > Or a test could be made of how many subclasses a class has, and if it's > > over some arbitrarynumber just iterate through all objects and test each > > one for isKindOf:? > > Don't know how fast that would be, maybe it's not faster. > > > Yes, I looked at that: > multi single > pass pass > Collection 18650 29448 82 subclasses, multipass 50% faster > > BorderedMorph 26301 7464 206 subclasses, singlepass 3x faster > > GRObject 113717 6969 742 subclasses, singlepass 14x faster. > > Breakeven point is around 100 subclasses. > > Mostly allSubInstances is used in housekeeping tasks, so it's not a big > issue. > As it's mostly used in housekeeping, a lot of the applications would > probably be > fine with the unordered, one pass version. > > I'll do a bit of digging into whether there are any meaningful performance > implications. > > ...Stan > > Behavior>>allSubInstancesDoInOnePass: attached if anyone wants to > benchmark > http://n2.nabble.com/file/n4192013/Behavior-allSubInstancesDoInOnePass.st > Behavior-allSubInstancesDoInOnePass.st > -- > View this message in context: > http://n2.nabble.com/Issue-1634-Object-allSubInstances-slooooow-tp4189848p4… > 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 >

Dec. 19, 2009

Re: [Pharo-project] Default code browser

by Schwab,Wilhelm K

I tried whisker on Squeak years ago and hated it. A clean CHB that offers easy ways to spawn new browsers, can be filtered to subsets of the class hierarchy, and has a history for easy forward-back/recent navigation is the way to go IMHO. 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: Saturday, December 19, 2009 3:44 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Default code browser On of the idea is to use glamour to experiment new browsers and probably to write it from scratch when we know what is really good. Ideally I like the multiple method showing of whisker but not the rest david implemented that in OB. I like the fact that O2 supports the view of class extension view per packages Now I avoid to talk about browsers because we do not have somebody in the community working heavily on that beside david and david may leave once he will finish his PhD. Now OB metamodel does not support tree and make it difficult to have something like the class comment visible close to the class definition. On Dec 18, 2009, at 3:47 PM, GeertClaes wrote: > > > George Herolyants-3 wrote: >> >> Though I think WhiskerBrowser still covers the above use case better. >> Unfortunately it doesn't run on Pharo. >> > > Maybe WhiskerBrowser can be created using Glamour? > -- > View this message in context: > http://n2.nabble.com/Default-code-browser-tp4183317p4186933.html > 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 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 19, 2009

[Pharo-project] OCompletion and the O2PackageBrowser search panel problem

by Adrian Lienhard

There is an issue with OCompletion and the O2PackageBrowser in the latest 1.0 dev image. I created issue 1635: OCompletion +O2PackageBrowser: mercury search bar backspace delete error. http://code.google.com/p/pharo/issues/detail?id=1635 Adrian

Dec. 19, 2009

[Pharo-project] Seaside2.8 and Seaside3.0 configs online in MetacelloRepository

by Dale Henrichs

Just published ConfigurationOfSeaside28 to http://www.squeaksource.com/MetacelloRepository. In a pharo dev image: Gofer new squeaksource: 'MetacelloRepository'; addPackage: 'ConfigurationOfSeaside28'; load. (Smalltalk at: #ConfigurationOfSeaside28) perform: #load. ConfigurationOfSeaside28 was published a while ago, but I'll mention the Seaside3.0 config for completeness: Gofer new squeaksource: 'MetacelloRepository'; addPackage: 'ConfigurationOfSeaside30'; load. (Smalltalk at: #ConfigurationOfSeaside30) perform: #load. Note that Seaside2.8 and Seaside3.0 cannot be loaded into the same image as there are class name conflicts. Both of these configurations have been successfully loaded into 'Pharo1.0rc1 #10493' and 'Squeak3.10.2-trunk' (Squeak requires manual load of configuration package:). I will be integrating ConfigurationOfSeaside28 for use with GLASS. ConfigurationOfSeaside30 is already integrated into GLASS (for GemStone/S 2.4). Dale

Dec. 19, 2009

[Pharo-project] About projects with Metacello

by Mariano Martinez Peck

Hi folks. Now that I am starting to write some configurations, I realized that we have a "change of concept" with Metacello. With Gofer or Installer (someone tell me if I am wrong) we are use to manage projects that are a certain repository of squeaksource or similar. And then we have the packages. So, for example we are talking about the RefactoringBrowser, you have: www.squeaksource.com/rb and the packages AST-Core, Refactoring-Core and Refactoring-Spelling. Then there is the project OB where you have also OB-Refactory and OB-Regex for example. At first, of course, I thought to have one ConfigurationOf per project. I mean, map one to one. But now...I was wondering that I can have a ConfigurationOfRefactoring for example, that can deals with ALL the things related to RB. In this case AST-Core, Refactoring-Core and Refactoring-Spelling from rb repo and OB-Refactory and OB-Regex from OB repo....and see all of them like a project. What do you think ? Do you have any thoughts with this? pors and cons? I would like to listen opinions. Cheers, Mariano

Dec. 19, 2009

Re: [Pharo-project] Issue 1634: Object allSubInstances slooooow

by StÃ©phane Ducasse

Stan did you compare/have a look at spaceTally because it is also reporting memory consumption and may be we could make everything better. (I just read my mails between two houses fixes). I will take more time this evening if I can. Anyway thanks. I like these kinds of discussions. Because I learn stuff or they make me think and rethink what I think I know Stef On Dec 19, 2009, at 6:11 PM, Stan Shepherd wrote: > > > Eliot Miranda-2 wrote: >> >> On Fri, Dec 18, 2009 at 6:04 PM, Martin McClure >> <martin(a)hand2mouse.com>wrote: >> >>> Stan Shepherd wrote: >>>> Pharo image: Pharo | Pharo-core >>>> PharoCore1.0rc1 Latest update: #10502 >>>> VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: >>>> #10074] >>>> >>>> Steps to reproduce: >>>> 1.[Object allSubInstances size inspect] timeToRun 375479 (6 minutes) >>>> >>>> with fix >>>> [Object allSubInstances size inspect] timeToRun 22335 (22 seconds) >>>> >>>> Attached treats Object as a special case, and takes advantage of >>> primitive >>>> in SystemNavigation>>allObjectsDo: >>> >>> It looks like with this change, Object allSubInstances would return >>> instances of classes that do not inherit from Object, for instance >>> objects that inherit from ProtoObject. >>> >>> Perhaps the special case should go on ProtoObject? Or a test could be >>> made of how many subclasses a class has, and if it's over some arbitrary >>> number just iterate through all objects and test each one for isKindOf:? >>> Don't know how fast that would be, maybe it's not faster. But probably >>> slow is preferable to incorrect. If you just want "all objects" and >>> don't care about their class then you can always use >>> SystemNavigation>>allObjectsDo: rather than allSubInstances. >>> >> >> +1. >> >> I don't think there's any justification for this hack. It's possible to >> have another root to the hierarchy apart from ProtoObject. Further, a bit >> weak, but allSubInstancesDo: has ordering properties; it will evaluate the >> block with all instances of a class followed by all instances of another >> and >> so on; it will visit all instances of any superclass before it visits any >> instances of subclasses, and that could be useful. If you want to use >> allObjectsDo: use it. Of course allSubInstancesDo: is slow; it makes as >> many scans of the system as there are classes (Metaclass avoids the scan >> by >> evaluating with soleInstance). But that's not a justification for >> special-casing one use of it to a freely accessible but different >> alternative. >> >> >>> Regards, >>> >>> -Martin >>> >>> _______________________________________________ >>> 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 >> > > > Eliot Miranda-2 wrote: >> >> I don't think there's any justification for this hack. >> > > Quite so. It was late, and I'd thought better of it by morning. However, > don't feel you need to spare my feelings ;) > > > Taking a step back, Object allSubinstances size seems to be a common proxy > measure for the size/bloat/complexity of an image. > (E.g. http://www.object-arts.com/docs/index.html?how_many_objects.htm ). > Running it on a large production system would potentially be very slow. > It could also be something a current Smalltaker would run to check out > Pharo, > in which case a coffee break would be warranted. So from a marketing of > Pharo > perspective, 6 minutes seems too long to me. Yes, an experienced user will > avoid it. > I have no proposal as to how to catch that case while avoiding a hack. > Adding a specific > allSubinstances to Object class would break inheritance chain to Behavior. > > > In the meantime, perhaps there should be an alternative simple measure > available: > > SystemNavigation>>allObjects > "A fast way to list all current objects in the image. > n.b. this will include the classes ImageSegmentRootStub MessageCatcher > TestCoverage DynamicBindingsInfo, and possibly others, that do not > inherit from Object. These classes probably have no instances, but > it is not safe to assume this" > | aCollection | > aCollection := OrderedCollection new. > self allObjectsDo: > [:x | x == aCollection ifFalse: [aCollection add: x]]. > ^ aCollection > > with a comment in allSubInstances > "for Prototype>>allSubInstances, Object>>allSubInstances,consider using > SystemNavigation>>allObjects. This is much faster. see comment there" > > > Martin McClure wrote: >> >> It looks like with this change, Object allSubInstances would return >> instances of classes that do not inherit from Object, for instance >> objects that inherit from ProtoObject. >> > Yes. It doesn't currently, but it could. See comment above. > > > Martin McClure wrote: >> >> Or a test could be made of how many subclasses a class has, and if it's >> over some arbitrarynumber just iterate through all objects and test each >> one for isKindOf:? >> Don't know how fast that would be, maybe it's not faster. >> > Yes, I looked at that: > multi single > pass pass > Collection 18650 29448 82 subclasses, multipass 50% faster > > BorderedMorph 26301 7464 206 subclasses, singlepass 3x faster > > GRObject 113717 6969 742 subclasses, singlepass 14x faster. > > Breakeven point is around 100 subclasses. > > Mostly allSubInstances is used in housekeeping tasks, so it's not a big > issue. > As it's mostly used in housekeeping, a lot of the applications would > probably be > fine with the unordered, one pass version. > > I'll do a bit of digging into whether there are any meaningful performance > implications. > > ...Stan > > Behavior>>allSubInstancesDoInOnePass: attached if anyone wants to benchmark > http://n2.nabble.com/file/n4192013/Behavior-allSubInstancesDoInOnePass.st > Behavior-allSubInstancesDoInOnePass.st > -- > View this message in context: http://n2.nabble.com/Issue-1634-Object-allSubInstances-slooooow-tp4189848p4… > 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

Dec. 19, 2009

Re: [Pharo-project] Need someone to commit on RoelTyper

by Mariano Martinez Peck

In addition, it would be cool if someone can move the tests of RoleTyper to a separate package special for tests. Can someone do this and commit my .mcz ? Please... On Fri, Dec 18, 2009 at 3:00 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi FrÃ©d! > > I fixed the _ in assignment problem in RoelTyper. I don't have access to > commit as I am not as developer and the global setting in ss is read. I > attach the .mcz. Can you commit it please or give me access? > > Thanks > > Mariano >

Dec. 19, 2009

Re: [Pharo-project] Issue 1634: Object allSubInstances slooooow

by Stan Shepherd

Eliot Miranda-2 wrote: > > On Fri, Dec 18, 2009 at 6:04 PM, Martin McClure > <martin(a)hand2mouse.com>wrote: > >> Stan Shepherd wrote: >> > Pharo image: Pharo | Pharo-core >> > PharoCore1.0rc1 Latest update: #10502 >> > VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: >> > #10074] >> > >> > Steps to reproduce: >> > 1.[Object allSubInstances size inspect] timeToRun 375479 (6 minutes) >> > >> > with fix >> > [Object allSubInstances size inspect] timeToRun 22335 (22 seconds) >> > >> > Attached treats Object as a special case, and takes advantage of >> primitive >> > in SystemNavigation>>allObjectsDo: >> >> It looks like with this change, Object allSubInstances would return >> instances of classes that do not inherit from Object, for instance >> objects that inherit from ProtoObject. >> >> Perhaps the special case should go on ProtoObject? Or a test could be >> made of how many subclasses a class has, and if it's over some arbitrary >> number just iterate through all objects and test each one for isKindOf:? >> Don't know how fast that would be, maybe it's not faster. But probably >> slow is preferable to incorrect. If you just want "all objects" and >> don't care about their class then you can always use >> SystemNavigation>>allObjectsDo: rather than allSubInstances. >> > > +1. > > I don't think there's any justification for this hack. It's possible to > have another root to the hierarchy apart from ProtoObject. Further, a bit > weak, but allSubInstancesDo: has ordering properties; it will evaluate the > block with all instances of a class followed by all instances of another > and > so on; it will visit all instances of any superclass before it visits any > instances of subclasses, and that could be useful. If you want to use > allObjectsDo: use it. Of course allSubInstancesDo: is slow; it makes as > many scans of the system as there are classes (Metaclass avoids the scan > by > evaluating with soleInstance). But that's not a justification for > special-casing one use of it to a freely accessible but different > alternative. > > >> Regards, >> >> -Martin >> >> _______________________________________________ >> 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 > Eliot Miranda-2 wrote: > > I don't think there's any justification for this hack. > Quite so. It was late, and I'd thought better of it by morning. However, don't feel you need to spare my feelings ;) Taking a step back, Object allSubinstances size seems to be a common proxy measure for the size/bloat/complexity of an image. (E.g. http://www.object-arts.com/docs/index.html?how_many_objects.htm ). Running it on a large production system would potentially be very slow. It could also be something a current Smalltaker would run to check out Pharo, in which case a coffee break would be warranted. So from a marketing of Pharo perspective, 6 minutes seems too long to me. Yes, an experienced user will avoid it. I have no proposal as to how to catch that case while avoiding a hack. Adding a specific allSubinstances to Object class would break inheritance chain to Behavior. In the meantime, perhaps there should be an alternative simple measure available: SystemNavigation>>allObjects "A fast way to list all current objects in the image. n.b. this will include the classes ImageSegmentRootStub MessageCatcher TestCoverage DynamicBindingsInfo, and possibly others, that do not inherit from Object. These classes probably have no instances, but it is not safe to assume this" | aCollection | aCollection := OrderedCollection new. self allObjectsDo: [:x | x == aCollection ifFalse: [aCollection add: x]]. ^ aCollection with a comment in allSubInstances "for Prototype>>allSubInstances, Object>>allSubInstances,consider using SystemNavigation>>allObjects. This is much faster. see comment there" Martin McClure wrote: > > It looks like with this change, Object allSubInstances would return > instances of classes that do not inherit from Object, for instance > objects that inherit from ProtoObject. > Yes. It doesn't currently, but it could. See comment above. Martin McClure wrote: > > Or a test could be made of how many subclasses a class has, and if it's > over some arbitrarynumber just iterate through all objects and test each > one for isKindOf:? > Don't know how fast that would be, maybe it's not faster. > Yes, I looked at that: multi single pass pass Collection 18650 29448 82 subclasses, multipass 50% faster BorderedMorph 26301 7464 206 subclasses, singlepass 3x faster GRObject 113717 6969 742 subclasses, singlepass 14x faster. Breakeven point is around 100 subclasses. Mostly allSubInstances is used in housekeeping tasks, so it's not a big issue. As it's mostly used in housekeeping, a lot of the applications would probably be fine with the unordered, one pass version. I'll do a bit of digging into whether there are any meaningful performance implications. ...Stan Behavior>>allSubInstancesDoInOnePass: attached if anyone wants to benchmark http://n2.nabble.com/file/n4192013/Behavior-allSubInstancesDoInOnePass.st Behavior-allSubInstancesDoInOnePass.st -- View this message in context: http://n2.nabble.com/Issue-1634-Object-allSubInstances-slooooow-tp4189848p4… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 19, 2009

Re: [Pharo-project] need hunter to kill the double paste bug.

by Lukas Renggli

Another thing, this is not something that is only related to the clipboard. I've seen a similar thing happen when I use a keyboard shortcut that opens a dialog. In some cases the initial selection of a text-field is replaced by the keyboard shortcuts character, e.g. pressing Ctrl+x to delete a method inserts sometimes the x into the confirmation dialog. Lukas 2009/12/19 George Herolyants <george.herolyants(a)gmail.com>: > 2009/12/19 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> On Thu, Dec 17, 2009 at 4:20 PM, Michael Rueger <m.rueger(a)acm.org> wrote: >>> >>> Do people actually experience the double paste problem on non-Mac >>> platforms? >> >> No. Only mac. I have been using Pharo in Linux and Windows, and happpens >> only on Mac I think. > > I've never expirienced this problem on Windows, too. > > _______________________________________________ > 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. 19, 2009

Re: [Pharo-project] need hunter to kill the double paste bug.

by George Herolyants

2009/12/19 Mariano Martinez Peck <marianopeck(a)gmail.com>: > On Thu, Dec 17, 2009 at 4:20 PM, Michael Rueger <m.rueger(a)acm.org> wrote: >> >> Do people actually experience the double paste problem on non-Mac >> platforms? > > No. Only mac. I have been using Pharo in Linux and Windows, and happpens > only on Mac I think. I've never expirienced this problem on Windows, too.

Dec. 19, 2009