Re: Issue 895 in pharo: class not well unloaded with monticello

Comment #1 on issue 895 by [hidden email]: class not well unloaded  
with monticello
http://code.google.com/p/pharo/issues/detail?id=895

Issue 2740 has been merged into this issue.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Labels: Milestone-1.4

Comment #2 on issue 895 by [hidden email]: class not well unloaded with  
monticello
http://code.google.com/p/pharo/issues/detail?id=895

(No comment was entered for this change.)


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: Accepted

Comment #3 on issue 895 by [hidden email]: class not well unloaded  
with monticello
http://code.google.com/p/pharo/issues/detail?id=895

(No comment was entered for this change.)


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #4 on issue 895 by [hidden email]: class not well unloaded with  
monticello
http://code.google.com/p/pharo/issues/detail?id=895

found!
funny bug :)
before removing a class, MC remove all methods of that class. seems ok but
if #unload is removed one can't expect that it is executed when the class  
is finally removed...


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Cc: renggli

Comment #5 on issue 895 by [hidden email]: class not well unloaded with  
monticello
http://code.google.com/p/pharo/issues/detail?id=895

call for advices.
maybe we can add a collection in MCPackageLoader containing all operations  
that have to be evaluated first at the start of MCPackageLoader basicLoad.
The idea is that when a class definition is added to the removals  
collection, an operations representing the #unload sending is added into  
this new collection.
we can also use the additions collection (need to change the sorting)
of course we can also be more hacky depending on the status of all this  
stuf.
what do you think ?





_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #6 on issue 895 by renggli: class not well unloaded with monticello
http://code.google.com/p/pharo/issues/detail?id=895

Have a look at GoferUnload. It does many operations before and after  
unloading that are not currently done by the MCPackageLoader itself.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #7 on issue 895 by [hidden email]: class not well unloaded with  
monticello
http://code.google.com/p/pharo/issues/detail?id=895

I only see:
GoferUnload>>unloadClasses: aWorkingCopy
        aWorkingCopy packageInfo methods do: [ :each |
                (each classIsMeta and: [ each selector = #unload ])
                        ifTrue: [ each actualClass theNonMetaClass unload ] ]

but should'nt it be done at the PackageLoader level ?



_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #8 on issue 895 by renggli: class not well unloaded with monticello
http://code.google.com/p/pharo/issues/detail?id=895

Yes, this is the workaround for that.

There is a lot more to be done afterwards:

- getting rid of the empty categories and protocols (self gofer cleanup)
- getting rid of the package info (unregisterPackageInfo:)
- getting rid of the unused repositories (unregisterRepositories:)
- getting rid of the working copy (unregisterWorkingCopy:)

Not sure if this should be fixed in MCPackageLoader though. This is just  
the low-level interface that provides the bare load/unload functionality.  
Hardcoding the above functionality makes it difficult to reuse  
MCPackageLoader.

Probably better would be to make the tools use Gofer instead of  
MCPackageLoader.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #9 on issue 895 by [hidden email]: class not well unloaded with  
monticello
http://code.google.com/p/pharo/issues/detail?id=895

I guess yes, a Gofer UI is needed and we should use it instead of MC.
But for now, could I move the unload workaround into MCPackageLoader and  
remove it from GoferUnload ?


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #10 on issue 895 by renggli: class not well unloaded with monticello
http://code.google.com/p/pharo/issues/detail?id=895

As I said, I don't think it is a good solution to integrate that with  
MCPackageLoader. MCPackageLoader is supposed to do the low-level loading  
and unloading, not the high-level package management and cleanup. If you  
integrate it you loose this useful separation.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker