I'm really happy about this. Some things were broken in the unloaded image (world menu items that depended on missing pieces) but other things were more exigent at the time, and the long time to unload discouraged me from testing much in the unloaded image. 

Speaking of which, does it make sense to break the tests up into a group that's still relevant to the unloaded image? If it does, and we do that, I wouldn't mind  running the unload and then running the tests the next time I put up an updated image; I can put up one full image as well as its unloaded counterpart. Perhaps that would stir more interest in hacking on the core image. 

I suppose that might not work, though: seems like committing from an unloaded image would probably cause methods to be removed. Drat.  

On Aug 24, 2010, at 9:06 PM, Andreas Raab <andreas.raab at gmx.de> wrote:

> On 8/24/2010 9:03 PM, Eliot Miranda wrote:
>> Excellent; works perfectly!  The preference must be updated manually
>> because there's no preferences browser (for others evaluate
>> (MCMcmUpdater classPool at: #UpdateMissingPackages put: false)) but with
>> that done update went without a hitch. Thank you!
> 
> No, no, no. This is why we have those tagged preferences. All you need to do is to evaluate:
> 
>    MCMcmUpdater updateMissingPackages: false.
> 
> No need to poke in the classPool or anything :-)
> 
> Cheers,
>  - Andreas
>