An 3.9 image for developers

Hi Damien,

on Fri, 15 Sep 2006 09:53:33 +0200, you wrote:
> Klaus D. Witzel a écrit :
>> Hi Cédrick,
>> This one is productivity gain par excellence. But as soon as the  
>> repositories go away and/or the dev.image gets older and/or  
>> incompatible, what will happen then? DNU's? frustration? confusion?
>
> It would be cool to keep squeak-dev.image up to date. That is why I'm  
> creating a script to do all the job. We should be able to create new  
> images automatically with new packages.

Kewl, really kewl 8-)

/Klaus

Hi ;)
>>
>>
>> For the packages...
>> maybe we could add FFI ? needed for external browser and OSProcess
>> ...  (not sure)
but only FFI maybe ? so it's a bit shorter to add platform dependant
packages...

RFB if added should be added before Seaside...
>
> Whatever DB it will be, it will also be always the wrong one. Who's
> using PostgreSQL anyways, I have not seen anybody using it, during the
> last 30 years (see: experience related).
well, I'm using it ;) but I was obliged to... I think, at least in the
MC repositories, we should find some databse support ?

What about XML support ? (I also was obliged too :) )

Cédrick

> RFB if added should be added before Seaside...
> >
> > Whatever DB it will be, it will also be always the wrong one. Who's
> > using PostgreSQL anyways, I have not seen anybody using it, during the
> > last 30 years (see: experience related).
> well, I'm using it ;) but I was obliged to... I think, at least in the
> MC repositories, we should find some databse support ?
>
> What about XML support ? (I also was obliged too :) )

I doubt I will use an image with all those 200 cool preloaded packages ;-)

It would be preferable to have a developer image that lets the
developer select a bunch of packages the first time it is opened. It
then quickly installs the selected mc snapshots in the right order and
throws away the ones that are not needed for the particular image.

Just an idea ;-)

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Lukas Renggli a écrit :

I agree, it would be better to have a simple image with the tools used
by almost every developers.


> It would be preferable to have a developer image that lets the
> developer select a bunch of packages the first time it is opened. It
> then quickly installs the selected mc snapshots in the right order and
> throws away the ones that are not needed for the particular image.

An image for developers is useful only if it is ready to use. If the
developer should download it and install everything he needs, it is not
very useful.

We need a mix: Pre-install most used packages and ease installation of
others.


--
Damien Cassou

> > It would be preferable to have a developer image that lets the
> > developer select a bunch of packages the first time it is opened. It
> > then quickly installs the selected mc snapshots in the right order and
> > throws away the ones that are not needed for the particular image.
>
> An image for developers is useful only if it is ready to use. If the
> developer should download it and install everything he needs, it is not
> very useful.

What I imagine is that you have all the necessary snapshots (instances
of MCSnapshot) in the development image already, you then only load
the necessary ones in the right order (that should be quite fast) and
then you throw away all those instances as they are not needed any
longer.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Lukas Renggli a écrit :
This is a good idea. But it only works for monticello packages, not for
squeakmap.


--
Damien Cassou

> This is a good idea. But it only works for monticello packages, not for
> squeakmap.

Yes, but are there any packages remaining that are relevant and that
are not packaged with Monticello?

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

>>
>> What I imagine is that you have all the necessary snapshots (instances
>> of MCSnapshot) in the development image already, you then only load
>> the necessary ones in the right order (that should be quite fast) and
>> then you throw away all those instances as they are not needed any
>> longer.
me too :)
>
> This is a good idea. But it only works for monticello packages, not
> for squeakmap.
>
Yes but most packages have a Monticello repository...

I added the creation of a new category in the preference browser. And at
the end of the installation, a preference browser open on that category
so that we can choose.

some other ideas:

- if we say no to seaside, maybe we should dismiss magritte and pier
(even they can work with morpf - I think there will be problems ;) ) ?
so maybe we need a kind of dependency var in Themes ?

- what if we do install twice or if we want to add seaside refusing it
the first time? we can also have a problem during the install. Can we
have a recover fonction in a certain way - like if already installed,
skip it (this could be useful in cas a problem occur for a package, like
I add with Magritte) ?


Cédrick

ps: ImageConfigurator>>allThmes  should have #squeaDevImage instead of
squeakDevImageConfigurator...  didn't commit it as I wasn't sure

I chose
ImageConfigurator new install
>
> ps: ImageConfigurator>>allThmes  should have #squeaDevImage instead of
> squeakDevImageConfigurator...  didn't commit it as I wasn't sure
>
other small bugs...

- ImageConfigurator>>usabilityEnhancements is not defined

- if on a browser, we choose a new default one with the upper left icon,
RB is twice and once written RefractoringBrowser. In ImageConfigurator
squeakDevImageConfiguration   there is
    ...      
    addSqueakMapPackage: 'Tric-RefractoringBrowser';
    ...
RefractoringBrowser open an empty RB. Is it something normal ?


Cédrick

>
> Yes, it's a browser which shows only some packages, and not the entire
> image.
> You can select which packages you want to display.
>
really cool ;)
I wanted such a browser

Tahnks

Cédrick

Romain Robbes wrote: This is cool. Very handy.

It just looks like a typo, though, in the open... menu:
Refactoring Browser
Refractoring Browser

It'd be nice to better differentiate it. Like maybe
Refactoring Browser
Refactoring Browser - empty

Brad Fuller wrote: Ah... this is one instance and if you select another "Refractoring
Browser" from the open... menu you get the same object, not another
instantiation.

BTW, I get a
MessageNotUnderstood: OrderedCollection>>removeAll

when selecting "hide all" from the menu
===============================

hideAll
    self current categories removeAll

Is it planned that the VMs get corrected? ;-)

Note the "perhaps".
Also, in #setPlatformPreferences it will change the actual preference so
that when loaded on a different Vm it will be unable to determine what the
user's preference was in the first place!

LOL!

Damien Cassou wrote: How about if you rename the image/changes to something different than
the release image name?
Little thing, I know. But, that way no one will mistake the "developer"
version for the release image.

--
brad fuller
sonaural: www.sonaural.com
personal: www.bradfuller.com
          www.oreillynet.com/pub/au/2184

Brad Fuller a écrit :
> Damien Cassou wrote:
> How about if you rename the image/changes to something different than
> the release image name?
> Little thing, I know. But, that way no one will mistake the "developer"
> version for the release image.

Sure sure. Is there a way to do it programatically, from the image ?


--
Damien Cassou

> BTW, I get a
> MessageNotUnderstood: OrderedCollection>>removeAll
>
> when selecting "hide all" from the menu
> ===============================
>
> hideAll
>     self current categories removeAll

I ran into that as well, I just add this...

Collection>>removeAll
     self removeAll: self copy

Hi Ramon,

on Sat, 16 Sep 2006 17:10:25 +0200, you wrote:
You won't like it globally. Just do, when you need it,

  aCollection removeAll: aCollection copy

and let #removeAll as is.

/Klaus