<br><br><div class="gmail_quote">On Sun, Jan 3, 2010 at 7:49 AM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Mariano Martinez Peck wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br>
</blockquote>
<br></div>
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?<br>
</blockquote><div><br></div><div>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.</div>
<div><br></div><div>I know, code speaks louder than words. I'll see what I can do in my copious spare time ;)</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Cheers,<br><font color="#888888">
- Andreas<br>
<br>
</font><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div class="h5">
On Sun, Jan 3, 2010 at 3:09 PM, Andreas Raab <<a href="mailto:andreas.raab@gmx.de" target="_blank">andreas.raab@gmx.de</a> <mailto:<a href="mailto:andreas.raab@gmx.de" target="_blank">andreas.raab@gmx.de</a>>> wrote:<br>
<br>
Folks -<br>
<br>
I've been going through various packages, and we're actually capable<br>
of unloading quite a bit of them cleanly by now. I've attached my<br>
unload script which (on a most recent updated trunk image with no<br>
additional packages loaded) will be able to unload the following<br>
packages:<br>
- ReleaseBuilder, ScriptLoader<br>
- 311Deprecated, 39Deprecated<br>
- Universes, SMLoader, SMBase, Installer-Core<br>
- VersionNumberTests, VersionNumber<br>
- Services-Base, PreferenceBrowser, Nebraska<br>
- CollectionsTests, GraphicsTests, KernelTests, MorphicTests<br>
- MultilingualTests, NetworkTests, ToolsTests, TraitsTests<br>
- XML-Parser, Traits<br>
After these packages been unloaded there are no Undeclared<br>
references or obsolete behaviors or modified MC packages. There are<br>
several more candidate packages, some of which I could use some help<br>
with:<br>
<br>
* Tests: The tests package is currently not unloadable because it<br>
includes ClassTestCase which is used from several other places.<br>
There is a fundamental question here whether we should aim for<br>
making all tests as well as SUnit unloadable or not. If the former,<br>
then we need to move tests out of packages like Files, System or MC<br>
in order to make them unloadable. If we're not shooting for making<br>
SUnit unloadable it may be worthwhile to promote ClassTestCase up to<br>
SUnit so that the Tests package becomes unloadable. Comments?<br>
<br>
* Morphic-Extras: I don't understand the intent of this package. The<br>
name implies to me that it includes "extras" which I'd expect to be<br>
optional content that should be unloadable at will but the reality<br>
is that even attempting to unload it (I foolishly tried) blows up<br>
left and right. Question: Is the intention of Morphic-Extras to<br>
contain unloadable content? If so, it's not doing its job currently.<br>
If that's not the intention of Morphic-Extras, I'd appreciate a<br>
heads-up of what the rationale for the structure is.<br>
<br>
* ST80: This is still a bit off but we're getting there. It can<br>
actually be unloaded but there are still several Undeclared<br>
variables and obsolete behaviors after unloading MVC. But the good<br>
news is that the system is still functioning (!) instead of horribly<br>
dying as it used to be. We could use a bit of additional help from<br>
people with an interest in this area.<br>
<br>
Cheers,<br>
- Andreas<br>
<br>
<br>
<br>
<br>
<br></div></div>
------------------------------------------------------------------------<br>
<br>
<br>
</blockquote>
<br>
<br>
</blockquote></div><br>