[Pharo-project] class removal problem
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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
so this is an issue :) Stef On Jun 6, 2009, at 6:49 PM, Adrian Lienhard wrote:
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse a écrit :
so this is an issue :)
http://code.google.com/p/pharo/issues/detail?id=895 alain
Stef
On Jun 6, 2009, at 6:49 PM, Adrian Lienhard wrote:
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
Adrian Lienhard -
Alain Plantec -
Stéphane Ducasse