would be great.
I'm doing boring admin right now and I was trying to understand why I get a 
problem unload Nautilus.

Stef

On Nov 27, 2013, at 1:46 PM, Pavel Krivanek <[email protected]> wrote:

> 
> 
> 
> 2013/11/26 Stéphane Ducasse <[email protected]>
> 
> On Nov 26, 2013, at 3:27 PM, Pavel Krivanek <[email protected]> wrote:
> 
>> Hi Stef,
>> 
>> I started to play with this way of shrinking (see the attachment). At least 
>> it's really faster than to use MC :-)
> 
> Sure :)
> Do you have a ci job to produce an image systematically?
> 
> I will setup something...
> 
> -- Pavel
>  
> 
>> Where are the configurations you are creating?
> 
> I started with
>        a new configuration for RB
>       I want
>               Nautilus
>               Zinc, 
>               Keymapping
>               Gofer
>               Fuel
>               Morphic
>               …
> 
> 
>> 
>> Cheers,
>> -- Pavel
>> 
>> 
>> 2013/11/25 Stéphane Ducasse <[email protected]>
>> 
>> On Nov 25, 2013, at 7:11 AM, Pavel Krivanek <[email protected]> wrote:
>> 
>> > Hi Stef,
>> >
>> > our starting point looks like this:
>> > - we have a method how to produce small image without network etc.
>> > - we are able to load network, Monticello and Gofer in it (this job is 
>> > currently broken)
>> > - we are able to load Metacello too - this should be the basic stage for 
>> > normal users
>> 
>> I would love to be able to grab an image up to the previous stage. Like that 
>> I can continue to work on the configurations regeneration project I have
>> 
>> > - than we are a le to load rest od the system at once
>> > - we have several configurations that we are able to load and unload.
>> >
>> > Our biggest problem is the huge nonmodular step between Metacello image 
>> > and full Pharo. I think we shoud move forward using division. To define 
>> > how an image without development tools should look like and create two big 
>> > configurations for them. Then continue with the next splitting.
>> 
>> Yes
>> 
>> >
>> > From the practical point of view, it's always faster to remove. something 
>> > than to load something.
>> Fun since it was difficult for me to unload I thought that I should focus on 
>> load :)
>> 
>> 
>> 
>> > And it's much faster to unload it without Monticello. So I would use ugly 
>> > removeAllButPackages: because it's fast, then fix the problems like 
>> > obsolete classes an Undeclared, continue with the pretty unloding part of 
>> > the configuration and finally loading part will be easy.
>> >
>> > -- Pavel
>> >
>> > 24. 11. 2013 v 22:36, Stéphane Ducasse <[email protected]>:
>> >
>> >> Hi pavel
>> >>
>> >> may be I should start from your miniimage and start to making sure that 
>> >> the configurations can load then in a second step
>> >> I can make sure that they can unload.
>> >>
>> >> What do you think?
>> >>
>> >> Stef
>> >
>> 
>> 
>> 
>> <shrink.st>
> 
> 

Reply via email to