Hey,
Happy new year. I hope all is well with you and yours :-)



Sent from my iPhone
Sean Glazier
Live with Passion


On Jan 3, 2010, at 7:58 PM, Eliot Miranda <eliot.miranda at gmail.com>  
wrote:

>
>
> On Sun, Jan 3, 2010 at 7:49 AM, Andreas Raab <andreas.raab at gmx.de>  
> wrote:
> Mariano Martinez Peck wrote:
> As a "repeater offender" you will probably don't answer be. But  
> anyway... we were discussing a couple of days ago with the Pharo  
> guys about unloading and the biggest problem we found were the  
> overrides of the packages. Do you handle this situation?
>
> Sure: Don't use overrides. Overrides are a necessary evil when you  
> can't change the underlying system to use proper means of composing  
> the desired behavior. However, if you are in control it's plain  
> insanity to use overrides. Why in the lord's name would you use  
> overrides unless you absolutely, positively had to?
>
> Because one is experimenting.  I agree with you Andreas that  
> overrides are evil and that in a well-designed system they can be  
> eliminated by well-designed extensibility conventions.  However, in  
> experimentation phases before such extensibility schemes have been  
> engineered or been justified economically, good support for  
> overrides are a reasonable substitute, and as you admit, necessary.   
> The problem with Monticello's overrides is simply with their  
> implementation above method versions.  As we've discussed recently  
> an alternative implementation of a dictionary from overridden item  
> (method reference or class definition reference) to a dictionary  
> from package name to version in that package, along with a global  
> package load order, would allow the system to compute all the  
> overridden items reliably at any time, and compute the most recent  
> previous version when unloading a package that overrides.  The  
> modifications to Monticello would be minimal - maintain a global  
> load order, enter overridden definitions into the override map on  
> load, and remove entries from the override map on unload.
>
> I know, code speaks louder than words.  I'll see what I can do in my  
> copious spare time ;)
>
>
> Cheers,
>  - Andreas
>
> On Sun, Jan 3, 2010 at 3:09 PM, Andreas Raab <andreas.raab at gmx.de <mailto:andreas.raab at gmx.de 
> >> wrote:
>
>    Folks -
>
>    I've been going through various packages, and we're actually  
> capable
>    of unloading quite a bit of them cleanly by now. I've attached my
>    unload script which (on a most recent updated trunk image with no
>    additional packages loaded) will be able to unload the following
>    packages:
>    - ReleaseBuilder, ScriptLoader
>    - 311Deprecated, 39Deprecated
>    - Universes, SMLoader, SMBase, Installer-Core
>    - VersionNumberTests, VersionNumber
>    - Services-Base, PreferenceBrowser, Nebraska
>    - CollectionsTests, GraphicsTests, KernelTests, MorphicTests
>    - MultilingualTests, NetworkTests, ToolsTests, TraitsTests
>    - XML-Parser, Traits
>    After these packages been unloaded there are no Undeclared
>    references or obsolete behaviors or modified MC packages. There are
>    several more candidate packages, some of which I could use some  
> help
>    with:
>
>    * Tests: The tests package is currently not unloadable because it
>    includes ClassTestCase which is used from several other places.
>    There is a fundamental question here whether we should aim for
>    making all tests as well as SUnit unloadable or not. If the former,
>    then we need to move tests out of packages like Files, System or MC
>    in order to make them unloadable. If we're not shooting for making
>    SUnit unloadable it may be worthwhile to promote ClassTestCase up  
> to
>    SUnit so that the Tests package becomes unloadable. Comments?
>
>    * Morphic-Extras: I don't understand the intent of this package.  
> The
>    name implies to me that it includes "extras" which I'd expect to be
>    optional content that should be unloadable at will but the reality
>    is that even attempting to unload it (I foolishly tried) blows up
>    left and right. Question: Is the intention of Morphic-Extras to
>    contain unloadable content? If so, it's not doing its job  
> currently.
>    If that's not the intention of Morphic-Extras, I'd appreciate a
>    heads-up of what the rationale for the structure is.
>
>    * ST80: This is still a bit off but we're getting there. It can
>    actually be unloaded but there are still several Undeclared
>    variables and obsolete behaviors after unloading MVC. But the good
>    news is that the system is still functioning (!) instead of  
> horribly
>    dying as it used to be. We could use a bit of additional help from
>    people with an interest in this area.
>
>    Cheers,
>     - Andreas
>
>
>
>
>
> --- 
> ---------------------------------------------------------------------
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100104/25668c7d/attachment.htm