[Pharo-dev] about miniimage

Stéphane Ducasse stephane.ducasse at inria.fr
Wed Nov 27 14:39:15 EST 2013


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 <pavel.krivanek at gmail.com> wrote:

> 
> 
> 
> 2013/11/26 Stéphane Ducasse <stephane.ducasse at inria.fr>
> 
> On Nov 26, 2013, at 3:27 PM, Pavel Krivanek <pavel.krivanek at gmail.com> 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 <stephane.ducasse at inria.fr>
>> 
>> On Nov 25, 2013, at 7:11 AM, Pavel Krivanek <pavel.krivanek at gmail.com> 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 <stephane.ducasse at inria.fr>:
>> >
>> >> 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>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131127/8a48501c/attachment-0002.html>


More information about the Pharo-dev mailing list