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

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

by Eliot Miranda

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 >

Dec. 19, 2009

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

by Martin McClure

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. Regards, -Martin

Dec. 19, 2009

[Pharo-project] Issue 1634: Object allSubInstances slooooow

by Stan Shepherd

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: Test also attached (it's slow without the mod) http://code.google.com/p/pharo/issues/detail?id=1634 http://code.google.com/p/pharo/issues/detail?id=1634 http://n2.nabble.com/file/n4189848/BehaviorTest-testAllObjectsPerformance.st BehaviorTest-testAllObjectsPerformance.st http://n2.nabble.com/file/n4189848/Behavior-allSubInstancesDo.st Behavior-allSubInstancesDo.st http://n2.nabble.com/file/n4189848/Behavior-allSubInstancesDo.st Behavior-allSubInstancesDo.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] Issue 1633: Object allSubInstances appears to loop forever

by Stan Shepherd

Eliot Miranda-2 wrote: > > with closures the block in allSubInstances will be a different object on > each evaluation. Pre closures this would have been a single BlockContext > used for each evaluation of the block (and hence non-reentrant). So you > need to modify, e.g. by implementing allInstancesDo: in MethodContext > class: > > 'From Croquet1.0beta of 11 April 2006 [latest update: #1] on 18 December > 2009 at 9:26:47 am'! > > !MethodContext class methodsFor: 'hacks' stamp: 'ar 9/17/2008 16:24'! > allInstancesDo: aBlock > "Only count until thisContext" > | inst next | > inst := self someInstance. > [inst == thisContext] whileFalse:[ > next := inst nextInstance. > aBlock value: inst. > inst := next]! ! > > find it attached > > On Fri, Dec 18, 2009 at 7:47 AM, Stan Shepherd > <stan.shepherd414(a)gmail.com>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 >> >> It appears to be repeatedly adding its current context. >> >> ...Stan >> >> OrderedCollection>>addLast: >> Receiver: an OrderedCollection(an Object an Object an Object an >> Object an Object an Object an Object...etc... >> Arguments and temporary variables: >> newObject: [] in Object > >> http://n2.nabble.com/Issue-1633-Object-allSubInstances-appears-to-loop-fore… > > Thanks Eliot, that does catch the looping. ...Stan -- View this message in context: http://n2.nabble.com/Issue-1633-Object-allSubInstances-appears-to-loop-fore… 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 Mariano Martinez Peck

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. > > John M McIntosh wrote: > > > Technically the behaviour between the the versions (3.x/4.x/5.x) > > should be the same, if you can show it's not, then it's a bug. > > > > In 5.0 we see the keydown and record data, but we don't actually get > > the character until text services decides what the unicode value is > > going to be based on the keyboard/language & deadkey support. > > > > Some time after the keydown (one or more) Text services calls > > insertText: on our view that then makes us generate the keydown, > > keystroke event using the same millisecond clock value. > > > > Milliseconds later the key goes up and we generate the key up event > > using the current clock time. > > Could there be an interaction between key events and clipboard access? > Or a race conditions where the Mac menu and Squeak both process the > paste event? > I can't come up with any other explanation why double key events would > only happen on CMD-v... > That is maybe they are occurring on copy and cut as well, but we just > won't notice... > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 18, 2009

Re: [Pharo-project] Pharo IDE usability (was Re: Pharo for Professional Development)

by Mariano Martinez Peck

2009/12/18 Simon Denier <Simon.Denier(a)inria.fr> > > On 18 dÃ©c. 2009, at 12:33, CÃ©drick BÃ©ler wrote: > > >> Yep, IDE tools in Pharo are at least a few years behind what you can find >> in other IDEs, at least in terms of usability. >> > > yes and this is sad because in term of real possiblities, this is far > better to me... > > > >> This is a known problem :) and there already has been a stream of >> propositions, enhancements, and talks about this (I myself did a >> presentation at ESUG 2009 about what I wanted). >> > > Yes It was interesting :) I agreed on most of them (especially the "in > context search" which is essential to me) > > > > Discussing with Lukas, it appears there is an API for the contextual > search, which the environment browsers use. It needs some documentation, > perhaps better names and UI. > > > > >> The issue was also discussed at the last Pharo sprint, and the major >> problem is simply lack of resources: nobody has the time nor the money to >> invest at least 2 or 3 months full work, in order to do a major clean >> up/rewrite of the graphical framework for dev tools (which would be a good >> first step). Now there is Morphic which is low-level, OB which is >> complicated, Glamour which needs enhancements... >> > > Yes I know all that ! > That why it probably better to discuss first. > Maybe the proposition to pay someone (the count me in stuff) could be used > for that. > Because to me this is not just a problem but the BIG problem (at least so > that newcommers don't leave with a bad feeling). Pay someone for 3 months is > easier than for 12 :). And you could count me in for that (to give a > contribution and also to participate) :) > > Every Dolphin users seems enligthened by their tools. Couldn't we mimic > them ? > > Laurent just made propositions, you too in your ESUG presentation. We > should collect, organize and provide a clear view of what we expect. Then > maybe pay someone or simply create a project but with clear goals. > > Then make this tool rock solid (even in alpha or unstable ;) ) > > > > That's already a lot of things to do actually. But I'm open to discussions. > The big problem is that we can discuss at length, but get nothing in the > end: myself I still havent found the time to do basic stuff in Morphic! > > Anyway, the more I think, the more I'm convinced we need a team of > integrators to build/test the dev image, because the core team is going on > but the dev is always lagging behind and does not give a good impression to > new programmers. > > > YES!!!! Exactlly...that's what I always said...I doesn't matter how nice and very good implemented is the Pharo core if the pharo dev is not cool, they won't use it. Of course, most of the times happens that to achieve a good pharo dev image, we need first a good core. But we are in the way. I hope Metacello can help us and also the test server and all that related stuff. Cheers, Mariano > > >> >> However, the primary annoyance right now is the dichotomy between the OB >> new framework and the O2 derived for David's work. The problem is that now, >> whenever the tools changed in OB (especially refactoring support), O2 can >> not follow and it breaks the tools in the package browser. >> >> 1) Remove O2SystemBrowser from the menu. Does anybody uses this browser? >> It's the same as OBSystemBrowser, so I guess people either use >> OBSystemBrowser or O2PackageBrowser. >> 2) How can we backport changes from O2 into OB? >> > > I use OB. I gave up on the package browser to have a snappier reaction. > But, with all due respect, these are projects. The abstraction behind OB > make some operations difficult. IMO, this could be easier to use classic > rigid tool (as we ( I ) want only one big coding tool). But I actually don't > care of what's behind as far as it works as defined in the future specs. > > >> >> About the taskbar: I'm more and more convinced that the taskbar does not >> work well for me, in particular does not scale. I would prefer something >> like the Mac Os dock. On the other hand, Algernon is a great tool to >> navigate quickly to a class (unfortunately, it does not support yet the >> queries as in a Mercury panel). >> > > Mercury seems quite broken to me. I've stopped looking at it and using it. > > > Strange. It's one of the feature I use the most. > > Mercury and Algernon by the way need also some kind of uniformisation. > > Do we start some actions in the direction of that ? What other thinks ? > > CÃ©drick > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 18, 2009

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

by Mariano Martinez Peck

On Fri, Dec 18, 2009 at 10:08 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > you are talking about a dream we made and this coming to be true :) > > >> Thanks Steph, > > > > lot of Preferences references remain, but not so much :) > > I would like to remove them then produce a Preferences package > > removable from the core an re-loadable if needed (pharo aka dev distrib > > needs it). > Excellent. If you want I can create a Metacello ConfigurationOfPreferences or something similar :) > > Then documentation ... > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 18, 2009

Re: [Pharo-project] Pharo IDE usability (was Re: Pharo for Professional Development)

by Lukas Renggli

>> This is a known problem :) and there already has been a stream of >> propositions, enhancements, and talks about this (I myself did a >> presentation at ESUG 2009 about what I wanted). > > Yes It was interesting :) I agreed on most of them (especially the "in > context search" which is essential to me) > > Discussing with Lukas, it appears there is an API for the contextual search, > which the environment browsers use. It needs some documentation, perhaps > better names and UI. The browser environments are described in (upcoming) "Pharo by Example" chapter "Reflection" in the section "Browsing environments": https://www.iam.unibe.ch/scg/svn_repos/SqueakByExample/PharoBook/Reflection… Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 18, 2009

Re: [Pharo-project] Pharo IDE usability (was Re: Pharo for Professional Development)

by Simon Denier

On 18 dÃ©c. 2009, at 12:33, CÃ©drick BÃ©ler wrote: > > Yep, IDE tools in Pharo are at least a few years behind what you can find in other IDEs, at least in terms of usability. > > yes and this is sad because in term of real possiblities, this is far better to me... > > > This is a known problem :) and there already has been a stream of propositions, enhancements, and talks about this (I myself did a presentation at ESUG 2009 about what I wanted). > > Yes It was interesting :) I agreed on most of them (especially the "in context search" which is essential to me) Discussing with Lukas, it appears there is an API for the contextual search, which the environment browsers use. It needs some documentation, perhaps better names and UI. > > The issue was also discussed at the last Pharo sprint, and the major problem is simply lack of resources: nobody has the time nor the money to invest at least 2 or 3 months full work, in order to do a major clean up/rewrite of the graphical framework for dev tools (which would be a good first step). Now there is Morphic which is low-level, OB which is complicated, Glamour which needs enhancements... > > Yes I know all that ! > That why it probably better to discuss first. > Maybe the proposition to pay someone (the count me in stuff) could be used for that. > Because to me this is not just a problem but the BIG problem (at least so that newcommers don't leave with a bad feeling). Pay someone for 3 months is easier than for 12 :). And you could count me in for that (to give a contribution and also to participate) :) > > Every Dolphin users seems enligthened by their tools. Couldn't we mimic them ? > > Laurent just made propositions, you too in your ESUG presentation. We should collect, organize and provide a clear view of what we expect. Then maybe pay someone or simply create a project but with clear goals. > > Then make this tool rock solid (even in alpha or unstable ;) ) That's already a lot of things to do actually. But I'm open to discussions. The big problem is that we can discuss at length, but get nothing in the end: myself I still havent found the time to do basic stuff in Morphic! Anyway, the more I think, the more I'm convinced we need a team of integrators to build/test the dev image, because the core team is going on but the dev is always lagging behind and does not give a good impression to new programmers. > > > However, the primary annoyance right now is the dichotomy between the OB new framework and the O2 derived for David's work. The problem is that now, whenever the tools changed in OB (especially refactoring support), O2 can not follow and it breaks the tools in the package browser. > > 1) Remove O2SystemBrowser from the menu. Does anybody uses this browser? It's the same as OBSystemBrowser, so I guess people either use OBSystemBrowser or O2PackageBrowser. > 2) How can we backport changes from O2 into OB? > > I use OB. I gave up on the package browser to have a snappier reaction. But, with all due respect, these are projects. The abstraction behind OB make some operations difficult. IMO, this could be easier to use classic rigid tool (as we ( I ) want only one big coding tool). But I actually don't care of what's behind as far as it works as defined in the future specs. > > > About the taskbar: I'm more and more convinced that the taskbar does not work well for me, in particular does not scale. I would prefer something like the Mac Os dock. On the other hand, Algernon is a great tool to navigate quickly to a class (unfortunately, it does not support yet the queries as in a Mercury panel). > > Mercury seems quite broken to me. I've stopped looking at it and using it. Strange. It's one of the feature I use the most. > Mercury and Algernon by the way need also some kind of uniformisation. > > Do we start some actions in the direction of that ? What other thinks ? > > CÃ©drick > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon

Dec. 18, 2009

Re: [Pharo-project] Pharo for Professional Development

by Simon Denier

On 18 dÃ©c. 2009, at 12:29, Henrik Johansen wrote: > > On Dec 18, 2009, at 12:03 09PM, Simon Denier wrote: >> >> >> >> About the taskbar: I'm more and more convinced that the taskbar does not work well for me, in particular does not scale. I would prefer something like the Mac Os dock. On the other hand, Algernon is a great tool to navigate quickly to a class (unfortunately, it does not support yet the queries as in a Mercury panel). >> >> >> Simon > > Have you tried the new taskbar in Windows 7 (with Aero on)? It's even better than the Dock, imo. Depends which Dock you are talking about :) I especially like the new with Dock/ExposÃ© in Snow Leopard. OK, I have watched a small vid about the W7 taskbar, and it's also near what I have in mind for a new taskbar in Pharo! Actually, the different between snow leopard/dock and W7/taskbar is becoming rather short. > This is just another reason why multiple native windows would be nice, though, leaves the problem for someone else :) > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon

Dec. 18, 2009