I discussed with marcus and the problem is that yes of course he can 
load MC, then save the pacakge on SqueakSource, but
then he has to produce a changeset containing only the right changes.

By the way, I really do not see why having MC in the developer image is 
a problem, especially
if we think that we want to have other packages to arrive to mini and 
that we could at the end
have a system which only load bytecode to bootstrap so I think that we 
are a bit focusing on the wrong path.

Stef



>
>> For issues with "image size" or "code quantity" in including MC - why 
>> not
>> just load MC into an image, install/uninstall desired/undesired 
>> packages,
>> then unload it when finished? A->B->C...
>
> yes this is what I was thinking :)
> But I have to check with marcus because he is smart and I trust him 
> when he tells
> that something is getting in his way. So once I will have clarified 
> that point with him
> I will make that clear to the rest :)
>
> STfe
>
>>
>> -lyndon
>>
>> ----- Original Message -----
>> From: "stéphane ducasse" <ducasse at iam.unibe.ch>
>> To: "The general-purpose Squeak developers list"
>> <squeak-dev at lists.squeakfoundation.org>; <avi at beta4.com>
>> Sent: Monday, December 13, 2004 1:40 PM
>> Subject: Re: MC in basic
>>
>>
>>>> Yes, that's exactly right.  And by the same logic, I would now have 
>>>> no
>>>> problem having VMMaker etc in basic either, since they are now (post
>>>> 3.5) well packaged too - as I said, I don't *care* what's in basic 
>>>> and
>>>> what isn't as long as I can trivially unload some of it.  Or what's
>>>> not in it, since I can trivially load what I need.
>>>
>>> For traits we would like to use OB because the old browser is hell.
>>> And managing the new compiler as a package would be much easier for
>>> marcus.
>>> This has also the nice effect that we could even produce an image
>>> without the compiler.
>>> Cool ;) but this is for mini-image people.
>>> So we would like to have MC to be able for us to go fast.
>>>
>>> Stef
>>>
>>>
>>
>>
>
>
>