- Pharo-dev - lists.pharo.org

Re: [Pharo-project] class removal problem

by Adrian Lienhard

On Jun 6, 2009, at 17:47 , Alain Plantec wrote: > Adrian Lienhard a Ã©crit : >> 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 > Thanks. > Is it an issue or is there a good reason for that ? I don't think so. However, looking at the code, it seems #unload is sent. MCClassDefinition>>#unload sends Smalltalk removeClassNamed: name which eventually calls Class>>removeFromSystem: which call #unload Strange... Adrian > > alain >> . >> >> 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 >>> >> >> >> _______________________________________________ >> 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] How to run a "cron" job?

by HernÃ¡n Morales Durand

http://squeak.saltypickle.com/Scheduler 2009/6/6 Oscar Nierstrasz <oscar(a)iam.unibe.ch> > > Hi folks, > > I need to run a periodic job in a Pier image. Â (Checking for new PDF > files and generating news items.) > > What is the recommended way to do this? > > Thanks in advance for any tips. > > - on > > > _______________________________________________ > 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] NetNameResolver - too much cleaning?

by Schwab,Wilhelm K

Adrian, Sorry, I described the wrong problem: it's the other direction (name from address) that is missing. At least on win32, I found it necessary to use both lookups to get fully qualified names, especially for the local host. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Saturday, June 06, 2009 3:47 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] NetNameResolver - too much cleaning? Hi Bill It seems to work for me (Mac 4.1.1beta2U): NetNameResolver addressForName: 'pharo-project.org' --> 212.103.66.211(one),0(0) Doesn't that work for you or are you trying something else? Adrian On Jun 6, 2009, at 01:22 , Schwab,Wilhelm K wrote: > Hello all, > > There is no good way to get an address given a name :( I tried > "borrowing" code from 3.9 and was roundly punished: it hangs > miserably. Any ideas? > > Bill > > > _______________________________________________ > 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 Alain Plantec

Adrian Lienhard a Ã©crit : > 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 Thanks. Is it an issue or is there a good reason for that ? alain > . > > 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 >> > > > _______________________________________________ > 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 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

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