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

Re: [Pharo-project] Fwd: Issue 584 in pharo: SqueakPageCache generateURL -> DNU because pathForFile is not defined on ServerFile

by Michael Rueger

Adrian Lienhard wrote: > When removing SqueakPageCache, shouldn't one remove the whole morph > saving logic (i.e., SqueakPage, ObjectOut, MorphObjectOut and maybe +1 Michael

June 6, 2009

Re: [Pharo-project] Fwd: Issue 584 in pharo: SqueakPageCache generateURL -> DNU because pathForFile is not defined on ServerFile

by Alain Plantec

Adrian Lienhard a Ã©crit : > When removing SqueakPageCache, shouldn't one remove the whole morph > saving logic (i.e., SqueakPage, ObjectOut, MorphObjectOut and maybe > more)? certainely, I've investigated that. Removing SqueakPage etc also leads to ... TabbePalettte removal :) alain > I have never used this, so I cannot say whether it may be worth > keeping (in which case, we should make it work again). > > Adrian > > On Jun 6, 2009, at 15:05 , StÃ©phane Ducasse wrote: > > >> I would be inclined to say that we should remove SqueakPageCache but >> what the other think? >> SqueakPageCache is a cache for Morph sved on disc and that can be >> reloaded >> Begin forwarded message: >> >> >>> From: codesite-noreply(a)google.com >>> Date: June 5, 2009 10:53:23 PM CEDT >>> To: stephane.ducasse(a)gmail.com >>> Subject: Issue 584 in pharo: SqueakPageCache generateURL -> DNU >>> because pathForFile is not defined on ServerFile >>> >>> >>> Comment #2 on issue 584 by alain.pl...(a)free.fr: SqueakPageCache >>> generateURL -> DNU because pathForFile is not defined on ServerFile >>> http://code.google.com/p/pharo/issues/detail?id=584 >>> >>> so do we remove SqueakPage (#issue 477) or not ? >>> >>> >>> -- >>> You received this message because you are listed in the owner >>> or CC fields of this issue, or because you starred this issue. >>> You may adjust your issue notification preferences at: >>> http://code.google.com/hosting/settings >>> >> >> >> >> >> _______________________________________________ >> 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 > > >

June 6, 2009

Re: [Pharo-project] class removal problem

by Adrian Lienhard

Hi Alain, Just this morning when removing SqueakMap I noticed the same problem. What I did to solve it is to explicitly execute "ClassToBeRemoved unload" as part of the ScriptLoader update before loading the new package versions. Cheers, Adrian On Jun 6, 2009, at 15:47 , Alain Plantec wrote: > Hi all, > > It is about the class load/unload logic. > > I'm trying to remove BooleanPreferenceView. > But this class is registered as a preference view : > --------------- > BooleanPreferenceView class>>initialize > PreferenceViewRegistry ofBooleanPreferences register: self. > --------------- > > BooleanPreferenceView also implements #unload which unregisters itself > from the registry: > --------------- > BooleanPreferenceView class>>unload > PreferenceViewRegistry ofBooleanPreferences unregister: self > --------------- > > So ok, if I remove the class from the browser, #unload is sent and the > PreferenceViewRegistry registry is kept clean. > The same if I load a change set. > But if I make a SLICE and load it from a fresh image, then, it seems > that #unload is not sent because > AnObsoleteBooleanPreferenceView is still referenced by the > PreferenceViewRegistry registry. > > Have I missed something ? > Thanks > Alain > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 6, 2009

Re: [Pharo-project] Fwd: Issue 584 in pharo: SqueakPageCache generateURL -> DNU because pathForFile is not defined on ServerFile

by Adrian Lienhard

When removing SqueakPageCache, shouldn't one remove the whole morph saving logic (i.e., SqueakPage, ObjectOut, MorphObjectOut and maybe more)? I have never used this, so I cannot say whether it may be worth keeping (in which case, we should make it work again). Adrian On Jun 6, 2009, at 15:05 , StÃ©phane Ducasse wrote: > > > I would be inclined to say that we should remove SqueakPageCache but > what the other think? > SqueakPageCache is a cache for Morph sved on disc and that can be > reloaded > Begin forwarded message: > >> From: codesite-noreply(a)google.com >> Date: June 5, 2009 10:53:23 PM CEDT >> To: stephane.ducasse(a)gmail.com >> Subject: Issue 584 in pharo: SqueakPageCache generateURL -> DNU >> because pathForFile is not defined on ServerFile >> >> >> Comment #2 on issue 584 by alain.pl...(a)free.fr: SqueakPageCache >> generateURL -> DNU because pathForFile is not defined on ServerFile >> http://code.google.com/p/pharo/issues/detail?id=584 >> >> so do we remove SqueakPage (#issue 477) or not ? >> >> >> -- >> You received this message because you are listed in the owner >> or CC fields of this issue, or because you starred this issue. >> You may adjust your issue notification preferences at: >> http://code.google.com/hosting/settings > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 6, 2009

[Pharo-project] Graphs Javascript

by Francois Stephany

Ce truc pourrait t'intÃ©resser pour tracer tes arbres de gÃ©nÃ©alogie: http://thejit.org/

June 6, 2009

[Pharo-project] class removal problem

by Alain Plantec

Hi all, It is about the class load/unload logic. I'm trying to remove BooleanPreferenceView. But this class is registered as a preference view : --------------- BooleanPreferenceView class>>initialize PreferenceViewRegistry ofBooleanPreferences register: self. --------------- BooleanPreferenceView also implements #unload which unregisters itself from the registry: --------------- BooleanPreferenceView class>>unload PreferenceViewRegistry ofBooleanPreferences unregister: self --------------- So ok, if I remove the class from the browser, #unload is sent and the PreferenceViewRegistry registry is kept clean. The same if I load a change set. But if I make a SLICE and load it from a fresh image, then, it seems that #unload is not sent because AnObsoleteBooleanPreferenceView is still referenced by the PreferenceViewRegistry registry. Have I missed something ? Thanks Alain

June 6, 2009

Re: [Pharo-project] ObjectFinder

by Simon Denier

On 5 juin 09, at 20:22, Frederic Pluquet wrote: > Hello, > > Here a list of interesting features of ObjectFinder: > > - interesting columns are always entirely displayed: if you have the > last column partially hidden (because you scrolled on the left for > some reason), when this column is updated for showing new items, it > is completely shown. In the traditional OB, the update is performed > and the last column stills partially hidden. > > - The fact to select an item of a previous column does not imply the > deletion of the empty columns at its right (causing move of the > current selected column, to fit the last column for the right side). > In Object Finder, the right empty columns are removed only when a > new right column is created AND a left scroll is need. The user is > so not perturbed by the move of the current selected column. > > - the calculus of the senders of a compiled method are collected in > a forked process when the compiled method is inspected (and not when > the user asks the senders). The senders are so ready to be > displaying when the user asks him (Inspect Object>>#= for example). > > - when you inspect implementors of a compiled method, you see the > classes displayed according the hierarchy (with indentation for > subclasses) (Inspect Object>>#= for example). > > - for a compiled method, the button "M" is show the selectors used > in the compiled method. When you select one, the selection of the > selector in the code of method is shown in the description while the > right panel shows the classes implementing this selector (with > hierarchy feature obviously :)). A button "S" permits to show the > methods sending this selector. > > I don't know if my explanations are clear... Give me feedback if > necessary :) > Not at first look but when you play with the finder, it becomes clear :) Great work, very neat tool. One minor improvment: Let's say I have two panes A and B. In pane A, I have a list of CompiledMethod and I select Object#= Then the code for Object#= is displayed in the bottom pane, and pane B is filled with field values of the CompiledMethod instance. Then if I play with the buttons in pane B to get the senders/ implementors/messages for Object#=, the bottom pane is cleared. I feel like it should still displayed the current selection (in pane A) until I make another selection. > FrÃ©d > ---- > FrÃ©dÃ©ric Pluquet > UniversitÃ© Libre de Bruxelles (ULB) > Assistant > http://www.ulb.ac.be/di/fpluquet > > > On Fri, Jun 5, 2009 at 7:50 PM, Frederic Pluquet > <fpluquet(a)ulb.ac.be> wrote: > Hello, > > ObjectFinder needs some refactoring and the web site is not up to > date. I hope update everything this evening. > > For the slow move is the shift key :) (like on mac :-D) > > FrÃ©d > ---- > FrÃ©dÃ©ric Pluquet > UniversitÃ© Libre de Bruxelles (ULB) > Assistant > http://www.ulb.ac.be/di/fpluquet > > > > On Fri, Jun 5, 2009 at 7:38 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > I guess that frederic will reply since he is reading the list and > using pharo. > But indeed this smooth movement would be really nice to have. > He even has a slow move pressing alt like on the mac :))) > Stef > > > > > > > Ducasse<stephane.ducasse(a)inria.fr> wrote: > >> Smooth animation (this is really important for not been lost) so > you > >> always understand the flow since as in the > >> mac finder there is a smooth scrolling but fast of the new pane. > >> > >> - pluggable mechanism to put extra buttons and displaying info. > >> For example for dictionary, compiledmethods.... > >> Frederic showed me how to integrate the result of roel typer in > >> addition to fields and methods browsing and this is cool > >> So my gut feeling is that you should sit with frederic at esug and > >> see > >> and may be use its code in place > >> of the chasing browsing (which I cannot use at all). Since the > >> objectFinder is 5 classes and using OB all the way > >> down it would be pity not to have a look at it. > > > > Sounds interesting. I just wonder how this smooth scrolling is > > implemented, if it uses OB all the way down. Couldn't this be > > integrated with OB-Tools, that also come with various inspectors. > > > > Cheers, > > Lukas > > > > -- > > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon

June 6, 2009

[Pharo-project] Fwd: Issue 584 in pharo: SqueakPageCache generateURL -> DNU because pathForFile is not defined on ServerFile

by StÃ©phane Ducasse

I would be inclined to say that we should remove SqueakPageCache but what the other think? SqueakPageCache is a cache for Morph sved on disc and that can be reloaded Begin forwarded message: > From: codesite-noreply(a)google.com > Date: June 5, 2009 10:53:23 PM CEDT > To: stephane.ducasse(a)gmail.com > Subject: Issue 584 in pharo: SqueakPageCache generateURL -> DNU > because pathForFile is not defined on ServerFile > > > Comment #2 on issue 584 by alain.pl...(a)free.fr: SqueakPageCache > generateURL -> DNU because pathForFile is not defined on ServerFile > http://code.google.com/p/pharo/issues/detail?id=584 > > so do we remove SqueakPage (#issue 477) or not ? > > > -- > You received this message because you are listed in the owner > or CC fields of this issue, or because you starred this issue. > You may adjust your issue notification preferences at: > http://code.google.com/hosting/settings

June 6, 2009

Re: [Pharo-project] Streams - #nextLine

by StÃ©phane Ducasse

Hi bill do you have a couple of unit tests so that we can really give you an answer? Stef On Jun 6, 2009, at 1:19 AM, Schwab,Wilhelm K wrote: > Hello all, > > You might recall my advocating breaking changes to #next, #next: and > company: these methods do not behave as advertised, answering nil > vs. raising an exception when reading off the back of a stream. It > was fairly clear that the will did not exist to make he required > changes, so I have put myself on a strict diet of #nextOne, > #nextMany:, #nextAvailable: that *do* work as expected. I plan to > make code for these methods available to all, and strongly recommend > using them. > > My initial efforts with Citezen have convinced me that I am correct > to demand that code function as advertised/expected. I lost a > couple of hours trying to sort out whether I was faced with a > debugger defect, but ended up finding a source of inconsistency > among like-named methods. Look at implementors of #nextLine. > First, this is perhaps ambiguous given Pharo's cross-platform nature > - it might be wise to always specify CrLf or simply Lf??? Beyond > that, some implementations answer nil (why is beyond me, as it > leaves callers with two things to check when #notEmpty would > otherwise almost always suffice). > > Any thoughts? If nothing else, I think the various #nextLine > methods should behave alike, and as you can tell, I strongly favor > answering empty vs. nil. > > Bill > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 6, 2009

Re: [Pharo-project] ObjectFinder

by StÃ©phane Ducasse

Great that you like it. Probably should be included in OB who is in charge of that? Stef On Jun 5, 2009, at 11:26 PM, Mariano Martinez Peck wrote: > Wow!! I just downloaded and play with it for a while and seems very > very useful. And fast enough too. > > I hope this to be in pharo core :) > > Nice work! > > Mariano > > 2009/6/5 Frederic Pluquet <fpluquet(a)ulb.ac.be> > No one click image but it works (normally :)) in any Pharo/Squeak > image. It is available on SqueakSource: http://www.squeaksource.com/ObjectFinder > > FrÃ©d > > ---- > FrÃ©dÃ©ric Pluquet > UniversitÃ© Libre de Bruxelles (ULB) > Assistant > http://www.ulb.ac.be/di/fpluquet > > > On Fri, Jun 5, 2009 at 8:27 PM, Lukas Renggli <renggli(a)gmail.com> > wrote: > Do you have a one-click image to try it out? ;-) > > 2009/6/5 Frederic Pluquet <fpluquet(a)ulb.ac.be>: > > Hello, > > Here a list of interesting features of ObjectFinder: > > - interesting columns are always entirely displayed: if you have > the last > > column partially hidden (because you scrolled on the left for some > reason), > > when this column is updated for showing new items, it is > completely shown. > > In the traditional OB, the update is performed and the last column > stills > > partially hidden. > > - The fact to select an item of a previous column does not imply the > > deletion of the empty columns at its right (causing move of the > current > > selected column, to fit the last column for the right side). In > Object > > Finder, the right empty columns are removed only when a new right > column is > > created AND a left scroll is need. The user is so not perturbed by > the move > > of the current selected column. > > > > - the calculus of the senders of a compiled method are collected > in a forked > > process when the compiled method is inspected (and not when the > user asks > > the senders). The senders are so ready to be displaying when the > user asks > > him (Inspect Object>>#= for example). > > - when you inspect implementors of a compiled method, you see the > classes > > displayed according the hierarchy (with indentation for > subclasses) (Inspect > > Object>>#= for example). > > - for a compiled method, the button "M" is show the selectors used > in the > > compiled method. When you select one, the selection of the > selector in the > > code of method is shown in the description while the right panel > shows the > > classes implementing this selector (with hierarchy feature > obviously :)). A > > button "S" permits to show the methods sending this selector. > > I don't know if my explanations are clear... Give me feedback if > necessary > > :) > > FrÃ©d > > ---- > > FrÃ©dÃ©ric Pluquet > > UniversitÃ© Libre de Bruxelles (ULB) > > Assistant > > http://www.ulb.ac.be/di/fpluquet > > > > > > On Fri, Jun 5, 2009 at 7:50 PM, Frederic Pluquet > <fpluquet(a)ulb.ac.be> wrote: > >> > >> Hello, > >> ObjectFinder needs some refactoring and the web site is not up to > date. I > >> hope update everything this evening. > >> For the slow move is the shift key :) (like on mac :-D) > >> FrÃ©d > >> ---- > >> FrÃ©dÃ©ric Pluquet > >> UniversitÃ© Libre de Bruxelles (ULB) > >> Assistant > >> http://www.ulb.ac.be/di/fpluquet > >> > >> > >> On Fri, Jun 5, 2009 at 7:38 PM, StÃ©phane Ducasse > >> <stephane.ducasse(a)inria.fr> wrote: > >>> > >>> I guess that frederic will reply since he is reading the list and > >>> using pharo. > >>> But indeed this smooth movement would be really nice to have. > >>> He even has a slow move pressing alt like on the mac :))) > >>> Stef > >>> > >>> > > >>> > > >>> > Ducasse<stephane.ducasse(a)inria.fr> wrote: > >>> >> Smooth animation (this is really important for not been lost) > so you > >>> >> always understand the flow since as in the > >>> >> mac finder there is a smooth scrolling but fast of the new > pane. > >>> >> > >>> >> - pluggable mechanism to put extra buttons and displaying info. > >>> >> For example for dictionary, compiledmethods.... > >>> >> Frederic showed me how to integrate the result of roel typer in > >>> >> addition to fields and methods browsing and this is cool > >>> >> So my gut feeling is that you should sit with frederic at > esug and > >>> >> see > >>> >> and may be use its code in place > >>> >> of the chasing browsing (which I cannot use at all). Since the > >>> >> objectFinder is 5 classes and using OB all the way > >>> >> down it would be pity not to have a look at it. > >>> > > >>> > Sounds interesting. I just wonder how this smooth scrolling is > >>> > implemented, if it uses OB all the way down. Couldn't this be > >>> > integrated with OB-Tools, that also come with various > inspectors. > >>> > > >>> > Cheers, > >>> > Lukas > >>> > > >>> > -- > >>> > 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 > >> > > > > > > _______________________________________________ > > 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 > > > _______________________________________________ > 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

June 6, 2009