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

Re: [Pharo-project] Big problem with the implementation of traits

by Adrian Lienhard

On Jan 20, 2009, at 09:49 , StÃ©phane Ducasse wrote: > > Now I was wondering why you did not change > newClass := self recompile: false from: oldClass to: newClass > mutate: false. too Not sure if I understand what you mean. The message #recompile:from:to:mutate: is sent from the two methods I changed. The important change is that the transfer of the trait composition has to be done into the class returned by this method, not into the previous value of newClass (that is, before and and after the call, the variable newClass points to different instances). Adrian

Jan. 21, 2009

Re: [Pharo-project] Workspace Enhancement

by Damien Cassou

On Wed, Jan 21, 2009 at 1:58 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > Have a look at earlier versions of OB-Tools. They implement that, I > replaced it with the behavior of the original inspectors after people > complained about it. I think the chasing-style inspector is much > better than the "dive" thing in VisualWorks, because you don't loose > your navigation context with every click. I don't know who complained but I would have loved to have this feature :-). -- Damien Cassou http://damiencassou.seasidehosting.st

Jan. 21, 2009

[Pharo-project] Plugin organization

by Michael Rueger

Hi all, while working on a new (Open)Sophie release I ran into the problem of where to put some plugin code. In this case it is for the Curl Plugin, which Steven Riggins ported into Sophie, but the problem is pretty common I would guess. So the problem is this (as illustrated using our Curl package): - we have a package Sophie-Curl, which includes the Squeak Curl client and the CurlPlugin class. - loaded into a "normal" image, the CurlPlugin ends up being a subclass of ProtObject as the superclass is missing. - now we separate it into Sophie-Curl and Sophie-Curl-Plugin, but that won't fly with the MC name matching - so we name it Sophie-Curl and Sophie-Plugin-Curl I think that is ugly. What I would like to propose is that we organize all plugins in Pharo in to a Plugin category. So we would then have "Plugin-Curl", "Plugin-Locale" etc. Or alternatively "Plugin-Network-Curl", "Plugin-System-Locale" etc. That would also allow to simply load all plugins into a VMMaker image by using a package "Plugin". What do you guys think? Michael

Jan. 21, 2009

Re: [Pharo-project] Workspace Enhancement

by Lukas Renggli

> Is it anything like the "dive" feature in VW? I really liked that. It > doesn't have to load the whole object tree, which is much faster when you > have a really big root object! Have a look at earlier versions of OB-Tools. They implement that, I replaced it with the behavior of the original inspectors after people complained about it. I think the chasing-style inspector is much better than the "dive" thing in VisualWorks, because you don't loose your navigation context with every click. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 21, 2009

[Pharo-project] New pharo dev

by Damien Cassou

New pharo dev based on latest 10211 and containing the very latest fixes from David and Dale on OB and OB-Tools: http://code.google.com/p/pharo/wiki/Downloads?tm=2 -- Damien Cassou http://damiencassou.seasidehosting.st

Jan. 21, 2009

Re: [Pharo-project] Workspace Enhancement

by Rob Rothwell

On Wed, Jan 21, 2009 at 4:13 AM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > On Tue, Jan 20, 2009 at 6:49 PM, Dale Henrichs > <dale.henrichs(a)gemstone.com> wrote: > > At one time, the OB-Tools had a chasing inspector which provided > exloreIt-like feature in an OB window. The most recent versions of the > OB-Tools has seen the return of the 'classic' inspector, which is nice, > but... > > > > I liked the chasing inspector feature enough to bring it back as the > 'exploreIt' implementation in GLASS. It is a quick and dirty implementation > that can be improved, but when 'exploring' an object graph I've been happy > with the chasing-style inspector. > > > > It's OB-based, so if there is interest I could make it available in > OB-Tools. > > I would like it. Is it anything like the "dive" feature in VW? I really liked that. It doesn't have to load the whole object tree, which is much faster when you have a really big root object! Anyway, that would be nice... Rob

Jan. 21, 2009

Re: [Pharo-project] Workspace Enhancement

by Damien Cassou

On Tue, Jan 20, 2009 at 6:49 PM, Dale Henrichs <dale.henrichs(a)gemstone.com> wrote: > At one time, the OB-Tools had a chasing inspector which provided exloreIt-like feature in an OB window. The most recent versions of the OB-Tools has seen the return of the 'classic' inspector, which is nice, but... > > I liked the chasing inspector feature enough to bring it back as the 'exploreIt' implementation in GLASS. It is a quick and dirty implementation that can be improved, but when 'exploring' an object graph I've been happy with the chasing-style inspector. > > It's OB-based, so if there is interest I could make it available in OB-Tools. I would like it. -- Damien Cassou http://damiencassou.seasidehosting.st

Jan. 21, 2009

[Pharo-project] Fwd: about license clear problematic methods

by StÃ©phane Ducasse

> > At Mon, 19 Jan 2009 21:08:31 +0100, > stephane ducasse wrote: >> >> Hi yoshiki >> >> we would like to have pharo license cleaned. >> Do you have a list (or a way) to get the methods you cleaned in Etoy? > > For that matter, you should run an analysis in the Pharo image. The > Authorship2 code has some methods for it, including generating HTML, > etc. > > What we actually did is available in etoys3.2 stream at: > http://tinlizzie.org/updates/etoys/updates/ > > Feel free to ask any questions! > > -- Yoshiki >

Jan. 21, 2009

Re: [Pharo-project] Workspace Enhancement

by Chris Cunningham

On Tue, Jan 20, 2009 at 12:03 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > It happened to me more than once, that I accidently had some huge > objects hanging in a workspace leading to a memory leak. So > remembering the variables can be a dangerous thing. > Mainly I was checking to see if there would be issues like this. I often do researchy things in workspaces which grab only large amounts of memory (100's of MB), and forget to nil them out afterwards. Then, weeks (or months) later I need to shrink the image, and eventually find my way back to the workspace where a simple nil clears them out. I was worried that if they were held onto in history, this would be a problem. Keeping the strings around would be useful for me - my current image has about 20 workspaces open (and in 3.10 dev, this results in lots of minimized window title bars). Being able to store them off in history would be nice. -Chris

Jan. 21, 2009

Re: [Pharo-project] Workspace Enhancement

by Dale Henrichs

----- "Damien Cassou" <damien.cassou(a)gmail.com> wrote: | On Tue, Jan 20, 2009 at 10:15 AM, StÃ©phane Ducasse | <stephane.ducasse(a)inria.fr> wrote: | > I would prefer to have a better inspector/explorer | | Lukas reimplemented most Squeak tools using OB (inspector, explorer, | debugger, workspace, transcript...). Dale fixed a lot of things in the | debugger and things are going very well now. At one time, the OB-Tools had a chasing inspector which provided exloreIt-like feature in an OB window. The most recent versions of the OB-Tools has seen the return of the 'classic' inspector, which is nice, but... I liked the chasing inspector feature enough to bring it back as the 'exploreIt' implementation in GLASS. It is a quick and dirty implementation that can be improved, but when 'exploring' an object graph I've been happy with the chasing-style inspector. It's OB-based, so if there is interest I could make it available in OB-Tools. Dale

Jan. 20, 2009