[Pharo-project] why (MCPackage named: 'NonExistenPackage') unload. doesnt fail ?
Do we want that? I am finding a lot of outdated code that uses code like that and it doesnt fail, but still doesnt unload the package. For example, cleanUpForRelease does a (MCPackage named: 'HelpSystem') unload. and that package doesnt exist anymore since it was split.... so...do we want that silent behaviour ? cheers mariano
Joining the canvassing campaign done by Bill: *by all means, please, NO!* -- Cesar Rabak Em 05/01/2011 19:53, Mariano Martinez Peck < marianopeck@gmail.com > escreveu: Do we want that? I am finding a lot of outdated code that uses code like that and it doesnt fail, but still doesnt unload the package. For example, cleanUpForRelease does a (MCPackage named: 'HelpSystem') unload. and that package doesnt exist anymore since it was split.... so...do we want that silent behaviour ? cheers mariano
Do we want that? I am finding a lot of outdated code that uses code like that and it doesnt fail, but still doesnt unload the package.
For example, cleanUpForRelease does a (MCPackage named: 'HelpSystem') unload.
and that package doesnt exist anymore since it was split....
so...do we want that silent behaviour ?
probably not. Better fix the scripts as early as possible
cheers
mariano
+1. Someone wanting something that "just runs" can/should do something like (MCPackage named: 'HelpSystem' ifNone:'[ DeafObject current ]) unload Another approach is to trap and log errors so that a lengthy build process completes and then clearly shows where it encountered problems. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Thursday, January 06, 2011 6:11 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] why (MCPackage named: 'NonExistenPackage') unload. doesnt fail ?
Do we want that? I am finding a lot of outdated code that uses code like that and it doesnt fail, but still doesnt unload the package.
For example, cleanUpForRelease does a (MCPackage named: 'HelpSystem') unload.
and that package doesnt exist anymore since it was split....
so...do we want that silent behaviour ?
probably not. Better fix the scripts as early as possible
cheers
mariano
On Thu, Jan 6, 2011 at 3:32 PM, Schwab,Wilhelm K <bschwab@anest.ufl.edu>wrote:
+1. Someone wanting something that "just runs" can/should do something like
(MCPackage named: 'HelpSystem' ifNone:'[ DeafObject current ]) unload
Exactly. Now...I don't know the impact of doing this change. Maybe we screw up monticello hehehe cheer mariano
Another approach is to trap and log errors so that a lengthy build process completes and then clearly shows where it encountered problems.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Thursday, January 06, 2011 6:11 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] why (MCPackage named: 'NonExistenPackage') unload. doesnt fail ?
Do we want that? I am finding a lot of outdated code that uses code like that and it doesnt fail, but still doesnt unload the package.
For example, cleanUpForRelease does a (MCPackage named: 'HelpSystem') unload.
and that package doesnt exist anymore since it was split....
so...do we want that silent behaviour ?
probably not. Better fix the scripts as early as possible
cheers
mariano
On Thu, Jan 6, 2011 at 3:46 PM, Mariano Martinez Peck <marianopeck@gmail.com
wrote:
On Thu, Jan 6, 2011 at 3:32 PM, Schwab,Wilhelm K <bschwab@anest.ufl.edu>wrote:
+1. Someone wanting something that "just runs" can/should do something like
(MCPackage named: 'HelpSystem' ifNone:'[ DeafObject current ]) unload
Exactly. Now...I don't know the impact of doing this change. Maybe we screw up monticello hehehe
Even more.... If you have the packages: 'HelpSystem-Core' and 'HelpSystem-Tests', what do you think that happens if I do: (MCPackage named: 'HelpSystem') unload. All classes and categories are removed and the two packages 'HelpSystem-Core' and 'HelpSystem-Tests' are kept and marked as dirty.... grrrrrr
cheer
mariano
Another approach is to trap and log errors so that a lengthy build process completes and then clearly shows where it encountered problems.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Thursday, January 06, 2011 6:11 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] why (MCPackage named: 'NonExistenPackage') unload. doesnt fail ?
Do we want that? I am finding a lot of outdated code that uses code like that and it doesnt fail, but still doesnt unload the package.
For example, cleanUpForRelease does a (MCPackage named: 'HelpSystem') unload.
and that package doesnt exist anymore since it was split....
so...do we want that silent behaviour ?
probably not. Better fix the scripts as early as possible
cheers
mariano
participants (4)
-
csrabak＠bol.com.br -
Mariano Martinez Peck -
Schwab,Wilhelm K -
Stéphane Ducasse