Smalltalk › Squeak › Squeak - Dev

Iterative development with MCConfigurations

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Chris Muller

Iterative development with MCConfigurations

What is a best practice for doing iterative development with
MCConfigurations?

I want to be able to make plenty of short, incremental improvements,
with a map defining the stable combination of packages each time.

I found Cees' great "MCConfigurations quick how-to"

http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-November/098181.html

He seems to say this sort of development is overrated (I'm interpreting
his words with my own word).

But even if I didn't want to be conservative and have lots of
small-step maps I can easily roll-back to, I still want to at least be
able to post the continuously improving software to SqueakSource. When
posting though, it doesn't overlay the existing configuration with that
name, instead gives you an error "Found". SqueakSource doesn't seem to
be aware of configurations so you can select and delete them.

So that leaves versioning. I have not seen a way for configurations to
be "versioned," but since ancestry isn't really necessary for
configurations maybe this really just amounts to me using my own naming
scheme that includes an incrementing number..?

What are some good practices?

Ron Teitelbaum

RE: Iterative development with MCConfigurations

Hi Chris,

I've been doing lots of saves but no versioning of the configuration file.
I miss that from envy, but I figured that as I go if I need a persistent
checkpoint I would just add a version number and change the name. For the
most part since you are working with packages that are versioned it's easy
to rollback when you need too manually.

The other thing to keep in mind is that you don't have to save the
configuration file. When I get to a point that everything is working the
way I want it to I save the file. From then on I only version the packages.
When I start up each day I open the configuration file and update from
repositories. (This can be dangerous when squeakSource is down. You end up
loading from package-cache instead). This way I get all the updates from
everyone including all my new code (I'm running my own squeakSource for my
code). I keep an image with no objects created (I don't run any apps) and
load code. If the code loading time gets to long I'll save an image with
just the code loaded.

So I have basically three things to help manage code.

1. Check point on saved configuration file
2. The current working point. Loading versioned packages accessed by using
update from repositories.
3. Current working checkpoint on saved code-load-only image.

Hope that helps,

Ron Teitelbaum

> -----Original Message-----
> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Chris Muller
> Sent: Wednesday, December 13, 2006 9:35 PM
> To: squeak dev
> Subject: Iterative development with MCConfigurations
>
> What is a best practice for doing iterative development with
> MCConfigurations?
>
> I want to be able to make plenty of short, incremental improvements,
> with a map defining the stable combination of packages each time.
>
> I found Cees' great "MCConfigurations quick how-to"
>
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-
> November/098181.html
>
> He seems to say this sort of development is overrated (I'm interpreting
> his words with my own word).
>
> But even if I didn't want to be conservative and have lots of
> small-step maps I can easily roll-back to, I still want to at least be
> able to post the continuously improving software to SqueakSource. When
> posting though, it doesn't overlay the existing configuration with that
> name, instead gives you an error "Found". SqueakSource doesn't seem to
> be aware of configurations so you can select and delete them.
>
> So that leaves versioning. I have not seen a way for configurations to
> be "versioned," but since ancestry isn't really necessary for
> configurations maybe this really just amounts to me using my own naming
> scheme that includes an incrementing number..?
>
> What are some good practices?
>
>

Michael Rueger-6

Re: Iterative development with MCConfigurations

In reply to this post by Chris Muller

Chris Muller wrote:

> So that leaves versioning. I have not seen a way for configurations to
> be "versioned," but since ancestry isn't really necessary for
> configurations maybe this really just amounts to me using my own naming
> scheme that includes an incrementing number..?

That's what we have been doing e.g. in the Sophie project.
Would be nice if MC configurations were a little smarter, but we are
glad that we have them at all :-)

Michael

stephane ducasse

Re: Iterative development with MCConfigurations

But why we can't you save your MCConfig in a method of a class that
you version.?

We have been doing that for 3.9 all the time (not using MCConfig
because it was not working for 3.9 management
but if you look at ScriptLoader this is a container of loading-
configuration scripts and they are all versioned on squeaksource).

Stef

On 14 déc. 06, at 08:51, Michael Rueger wrote:

> Chris Muller wrote:
>
>> So that leaves versioning. I have not seen a way for
>> configurations to
>> be "versioned," but since ancestry isn't really necessary for
>> configurations maybe this really just amounts to me using my own
>> naming
>> scheme that includes an incrementing number..?
>
> That's what we have been doing e.g. in the Sophie project.
> Would be nice if MC configurations were a little smarter, but we
> are glad that we have them at all :-)
>
> Michael
>
>

Michael Rueger-6

Re: Iterative development with MCConfigurations

stephane ducasse wrote:
> But why we can't you save your MCConfig in a method of a class that you
> version.?

That's what we also do, but that is a little more complicated. For most
people just saving a properly named MC config is just what they need :-)

Michael

Bert Freudenberg

Re: Iterative development with MCConfigurations

On Dec 14, 2006, at 0:39 , Michael Rueger wrote:

> stephane ducasse wrote:
>> But why we can't you save your MCConfig in a method of a class
>> that you version.?
>
> That's what we also do, but that is a little more complicated. For
> most people just saving a properly named MC config is just what
> they need :-)

That actually works quite well. impara developed it for Plopp. In
principle, you just have a MC package with one class having a number
of configuration methods. This package is updated, and the latest
config in it is then loaded. You can see a public version of that in
Sophie:

http://source.sophieproject.org/Sophie.html

Look at class SophieReleaseBuilderDeveloper (in package Sophie-
Releases). On the class side you can see all the configuration
methods. This is a subclass of

ConfigMapReleaseBuilder (in package Deployment-Configs)

which contains the configuration-to-method conversion routines.

- Bert -

stephane ducasse

Re: Iterative development with MCConfigurations

Yes! This is the kind of mechanisms I was thinking about. I did
something similar because
we could not use MCConfig for 3.9. It would be good to put this
behavior with MCConfig.

>> stephane ducasse wrote:
>>> But why we can't you save your MCConfig in a method of a class
>>> that you version.?
>>
>> That's what we also do, but that is a little more complicated. For
>> most people just saving a properly named MC config is just what
>> they need :-)
>
> That actually works quite well. impara developed it for Plopp. In
> principle, you just have a MC package with one class having a
> number of configuration methods. This package is updated, and the
> latest config in it is then loaded. You can see a public version of
> that in Sophie:
>
> http://source.sophieproject.org/Sophie.html
>
> Look at class SophieReleaseBuilderDeveloper (in package Sophie-
> Releases). On the class side you can see all the configuration
> methods. This is a subclass of
>
> ConfigMapReleaseBuilder (in package Deployment-Configs)
>
> which contains the configuration-to-method conversion routines.
>
> - Bert -
>
>
>
>