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

[Pharo-project] {Spam?} Re: "Real" packages.

by Bill Schwab

Stef, Re Dolphin, class categories have long been of marginal use; I'll speak for myself on that but suspect others would agree. Packages are of course extremely useful. Method categories are also quite useful, and Dolphin allows multiple categories to be assigned to a given method. Dolphin mixes virtual categories (computed by rules) with static ones maintained by the user (and serialized as part of packages). I can easily see where OB would get quite a speed boost out of it. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> stephane.ducasse(a)inria.fr 2/10/2009 4:41:10 PM >>> Alexandre implemented long time ago an hybrid model where both kind of packages could coexist and we should probably revive it for 1.1 Stef On Feb 10, 2009, at 10:28 PM, Michael van der Gulik wrote: > > > On Wed, Feb 11, 2009 at 9:21 AM, David RÃ¶thlisberger <squeak(a)webcitas.ch > > wrote: > > > So if we had real packages in Pharo as first class entities, OB > would be much faster > and simpler to maintain. Right now, OB models packages and class > cats itself, has to > take the information from both the Monticello's working copy > managers and the > SystemOrganizer. This is a mess and a huge pain, but what can we do. > We should really invest in bringing real packages to Pharo. > > > If you want "real" packages, I've implemented them in Squeak: > > http://gulik.pbwiki.com/Namespaces > http://gulik.pbwiki.com/Packages > > The places the code is held, including a video and a Squeak image is > linked from here: > http://gulik.pbwiki.com/SecureSqueak > > I'm not interested in Pharo, but the code is there and is released > under the MIT license if anybody else wants it. > > Gulik. > > -- > http://people.squeakfoundation.org/person/mikevdg > http://gulik.pbwiki.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

Feb. 10, 2009

Re: [Pharo-project] "Real" packages.

by StÃ©phane Ducasse

Alexandre implemented long time ago an hybrid model where both kind of packages could coexist and we should probably revive it for 1.1 Stef On Feb 10, 2009, at 10:28 PM, Michael van der Gulik wrote: > > > On Wed, Feb 11, 2009 at 9:21 AM, David RÃ¶thlisberger <squeak(a)webcitas.ch > > wrote: > > > So if we had real packages in Pharo as first class entities, OB > would be much faster > and simpler to maintain. Right now, OB models packages and class > cats itself, has to > take the information from both the Monticello's working copy > managers and the > SystemOrganizer. This is a mess and a huge pain, but what can we do. > We should really invest in bringing real packages to Pharo. > > > If you want "real" packages, I've implemented them in Squeak: > > http://gulik.pbwiki.com/Namespaces > http://gulik.pbwiki.com/Packages > > The places the code is held, including a video and a Squeak image is > linked from here: > http://gulik.pbwiki.com/SecureSqueak > > I'm not interested in Pharo, but the code is there and is released > under the MIT license if anybody else wants it. > > Gulik. > > -- > http://people.squeakfoundation.org/person/mikevdg > http://gulik.pbwiki.com/ > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by David RÃ¶thlisberger

Igor Stasenko schrieb: > 2009/2/10 David RÃ¶thlisberger <squeak(a)webcitas.ch>: >> >>> But again, there is no excuse in doing this each time you need a tree. >>> Thanks to system notifier we have a ways to determine when category >>> tree needs to be rebuilt, so it can be built once and stay cached >>> until user add/remove/rename category. >> yes, right. Packages are cached for a long time and also their classes and extended >> classes. And now also the class cats per package, which is a small share though. >> But it's good to cache iy anyway. >> > > Also, note, that you need only one instance of such tree in image . > You don't have to build this tree over and over again for each browser > window on screen :) In a way, yes. But then OB would basically do what the system itself should do, namely modeling packages. I would rather invest in a genuine package model in the system itself than let OB build its own persistent package model. A browser should by definition browse an existing model and not primarily create, maintain, and make persistently accessible a system's model. This would be like a shadow model to what the system otherwise uses, Sounds odd to me, although from a performance point of view it would make sense. David

Feb. 10, 2009

[Pharo-project] "Real" packages.

by Michael van der Gulik

On Wed, Feb 11, 2009 at 9:21 AM, David RÃ¶thlisberger <squeak(a)webcitas.ch>wrote: > > > So if we had real packages in Pharo as first class entities, OB would be > much faster > and simpler to maintain. Right now, OB models packages and class cats > itself, has to > take the information from both the Monticello's working copy managers and > the > SystemOrganizer. This is a mess and a huge pain, but what can we do. > We should really invest in bringing real packages to Pharo. > If you want "real" packages, I've implemented them in Squeak: http://gulik.pbwiki.com/Namespaces http://gulik.pbwiki.com/Packages The places the code is held, including a video and a Squeak image is linked from here: http://gulik.pbwiki.com/SecureSqueak I'm not interested in Pharo, but the code is there and is released under the MIT license if anybody else wants it. Gulik. -- http://people.squeakfoundation.org/person/mikevdg http://gulik.pbwiki.com/

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by Igor Stasenko

2009/2/10 David RÃ¶thlisberger <squeak(a)webcitas.ch>: > > >> But again, there is no excuse in doing this each time you need a tree. >> Thanks to system notifier we have a ways to determine when category >> tree needs to be rebuilt, so it can be built once and stay cached >> until user add/remove/rename category. > > yes, right. Packages are cached for a long time and also their classes and extended > classes. And now also the class cats per package, which is a small share though. > But it's good to cache iy anyway. > Also, note, that you need only one instance of such tree in image . You don't have to build this tree over and over again for each browser window on screen :) > David > > _______________________________________________ > 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.

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by David RÃ¶thlisberger

> But again, there is no excuse in doing this each time you need a tree. > Thanks to system notifier we have a ways to determine when category > tree needs to be rebuilt, so it can be built once and stay cached > until user add/remove/rename category. yes, right. Packages are cached for a long time and also their classes and extended classes. And now also the class cats per package, which is a small share though. But it's good to cache iy anyway. David

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by Igor Stasenko

2009/2/10 David RÃ¶thlisberger <squeak(a)webcitas.ch>: > >>> As for, >>> 3.3% {2ms} ByteString class(String class)>>new: >>> >>> Total count of ByteString>>new: calls during >>> GlobalCounter reset. >>> self fullDrawOn: World assuredCanvas. >>> GlobalCounter counters copy inspect >>> >>> is 7146, >>> which again makes me look suspicious at OB here.. Hey! Are we drawing, >>> or processing a text?!?! > > hehe, good point. > The reason why OB does heavy string processing is, simply said, that packages and > class categories are not first class, but stupid strings... To for instance find out > to which Monticello package a class cat belongs (or vice-versa) we have to do string > processing, to not show the package name of a class cat (eg. 'Kernel-Classes' are > displayed as 'Classes' in the tree below package 'Kernel') we have to do string > processing, and so on, and so on. As there are many packages with many class cats, > this sums up. > > So if we had real packages in Pharo as first class entities, OB would be much faster > and simpler to maintain. Right now, OB models packages and class cats itself, has to > take the information from both the Monticello's working copy managers and the > SystemOrganizer. This is a mess and a huge pain, but what can we do. > We should really invest in bringing real packages to Pharo. > Right, i had an impression, that so much string processing going from the need to build a tree from class category names. But again, there is no excuse in doing this each time you need a tree. Thanks to system notifier we have a ways to determine when category tree needs to be rebuilt, so it can be built once and stay cached until user add/remove/rename category. > David > > _______________________________________________ > 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.

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by David RÃ¶thlisberger

>> As for, >> 3.3% {2ms} ByteString class(String class)>>new: >> >> Total count of ByteString>>new: calls during >> GlobalCounter reset. >> self fullDrawOn: World assuredCanvas. >> GlobalCounter counters copy inspect >> >> is 7146, >> which again makes me look suspicious at OB here.. Hey! Are we drawing, >> or processing a text?!?! hehe, good point. The reason why OB does heavy string processing is, simply said, that packages and class categories are not first class, but stupid strings... To for instance find out to which Monticello package a class cat belongs (or vice-versa) we have to do string processing, to not show the package name of a class cat (eg. 'Kernel-Classes' are displayed as 'Classes' in the tree below package 'Kernel') we have to do string processing, and so on, and so on. As there are many packages with many class cats, this sums up. So if we had real packages in Pharo as first class entities, OB would be much faster and simpler to maintain. Right now, OB models packages and class cats itself, has to take the information from both the Monticello's working copy managers and the SystemOrganizer. This is a mess and a huge pain, but what can we do. We should really invest in bringing real packages to Pharo. David

Feb. 10, 2009

Re: [Pharo-project] Loading Polymorph

by StÃ©phane Ducasse

Ok I will have to check how we can integrate that. stef On Feb 10, 2009, at 5:54 PM, Gary Chambers wrote: > Latest Polymorph-Widgets versions (from 41 to 42) require the MC > workaround to load/merge, unfortunately. > Anything down to drawing... in this case the change to dropShadows. > > Regards, Gary > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by Gary Chambers

I've put that change into the lastest Polymorph-Widgets. In absence of negative feedback that seems appropriate. Regards, Gary ----- Original Message ----- From: "Bill Schwab" <BSchwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, February 10, 2009 3:12 PM Subject: Re: [Pharo-project] Call for UI gripes Gary, I need to play more later, but that appears to make a significant difference. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> gazzaguru2(a)btinternet.com 02/10/09 9:34 AM >>> While we are at it I have noticed that SystemWindow>>passivate deliberately draw the World (old behaviour). Having done a few simple benchmarks it seems that better performance is achieved when it is not drawn then, in contradiction to the implication of "clean damage now, so dont merge this rect with new top window". That's on my machine. Can some of you give it a go with the "self world displayWorld" removed and we'll see if it a worthwhile thing to change? Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, February 10, 2009 12:11 PM Subject: Re: [Pharo-project] Call for UI gripes > 2009/2/10 David RÃ¶thlisberger <squeak(a)webcitas.ch>: >> Hi Igor, >> >>> OB is quite complex thing, and its hard to understand what it does for >>> outsider :) >>> >>> I just identified a few points, which can improve rendering speed by a >>> certain amount: >> [...] >>> - default. >>> 60 ms >>> >>> - with override in SystemWindow>>drawDropShadowOn: aCanvas to do >>> nothing: >>> 51 ms >>> >>> - with override in OBMonticelloPackageNode>>classCategories to return >>> cached collection >>> 45 ms >>> >> >> I incorporated into OB a patch that is following your idea concerning >> caching of >> class cats in package nodes. I did it differently than you but the >> results are even >> better now. >> > > Great! In my patch i didn't care about correctness or whatever, it was > simply to outline what possible can be done to improve rendering > speed. > >> Can you take care of integrating the SystemWindow patch into Pharo? >> > > you mean override of SystemWindow>>drawDropShadowOn: ? > Its not really correct override. Shadow should be drawn, if it there. > And by default , to draw shadow, it using Morph>>drawOn: method with > special shadow canvas. For system window it means that a rectangular > area with dimensions of morph is filled with shadow color, shifted by > shadowOffset. > To improve its speed, we could clip a shadow rectangle to not visit > pixels which is covered my system window contents, only pixels which > are outside of it and 'dropping' shadow. > > I can implement such method, but concerning integration - i'm not in > charge here :) > > What is interesting about shadows, that by default a shadow offset is > 1 pixel wide: > shadowOffset: 1@1 > > this means that unless you using magnifying glass on you display, you > can't really tell if there shadow drawn or not. > Since visual difference is minimal, do anyone can tell, why wasting so > much CPU cycles on it? :) > > >> Thanks, >> David >> >> _______________________________________________ >> 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. > > _______________________________________________ > 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

Feb. 10, 2009