Smalltalk › Squeak › Squeak - Dev

Instructions for updating trunk undate config

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

cbc

Instructions for updating trunk undate config

This one I'm going to need some help on, having never done this before (obviously).

-----

When and How to change the trunk update configuration:

* When you are adding a new package to trunk, update the configuration with the new package (just because a package is in the repository does not mean it is loaded)

* When you are removing a package from trunk, update the configuration to remove the package (and follow instructions for removing the package)

* When methods are moved from one package to another - primarily when they are used in the update logic - then create an update with the package where the method is removed and where the method is added in the same update configuration

* When you need to ensure a preamble or postscript script is run for a package, include the version in a new configuration (otherwise it could be skipped - trunk only loads the latest version of a package if specific versions are not called out in the update configuration)

* If you need to do very intricate, step by step surgery on the internals of Squeak itself, such as converting how contexts work, you should use a series of update configurations to ensure step by step applications of the packages so the trunk update is successful

To perform the modify the update configuration:

1. Update squeak.

2. Open the trunk package

3. Select the 'update' package, find the last update commit, and "Browse" it (with the button)

4. In the MCConfigurationBrowser, press the "Update" button and choose "update all from image"

5. If you need to add a new package, press the "Add" button and chose the package to add (it needs to be in your image with the right version to add it)

6. If you need to remove a package, select the package and press "Remove"

7. If you packages are updating that have dependencies between each other (say, adding an abstract class to one package, and a subclass of that abstract class in another package), then you will need to make sure those packages are in the right order. In this case, find the package with the subclass, and make sure it is after the abstract classes package. Do this by selecting one package and pressing the "Up" and "Down" keys until the packages are in the right order

8. Finally, save the package back to Trunk, and test out the update stream to ensure it works.

-----

Thanks,

cbc

Eliot Miranda-2

Re: Instructions for updating trunk undate config

Hi Chris,

> On Feb 10, 2018, at 1:48 PM, Chris Cunningham <[hidden email]> wrote:
>
> This one I'm going to need some help on, having never done this before (obviously).
>
> -----
> When and How to change the trunk update configuration:
> * When you are adding a new package to trunk, update the configuration with the new package (just because a package is in the repository does not mean it is loaded)
> * When you are removing a package from trunk, update the configuration to remove the package (and follow instructions for removing the package)
> * When methods are moved from one package to another - primarily when they are used in the update logic - then create an update with the package where the method is removed and where the method is added in the same update configuration

That's not the safest. The safest is to create a configuration with the package to which the method is moved, but still containing the version of the package from which the method had moved which still had the method. This way, the package from which the method is moved will be marked dirty but there is no chance of the method being lost.

> * When you need to ensure a preamble or postscript script is run for a package, include the version in a new configuration (otherwise it could be skipped - trunk only loads the latest version of a package if specific versions are not called out in the update configuration)
> * If you need to do very intricate, step by step surgery on the internals of Squeak itself, such as converting how contexts work, you should use a series of update configurations to ensure step by step applications of the packages so the trunk update is successful
>
> To perform the modify the update configuration:
> 1. Update squeak.
> 2. Open the trunk package
> 3. Select the 'update' package, find the last update commit, and "Browse" it (with the button)
> 4. In the MCConfigurationBrowser, press the "Update" button and choose "update all from image"
> 5. If you need to add a new package, press the "Add" button and chose the package to add (it needs to be in your image with the right version to add it)
> 6. If you need to remove a package, select the package and press "Remove"
> 7. If you packages are updating that have dependencies between each other (say, adding an abstract class to one package, and a subclass of that abstract class in another package), then you will need to make sure those packages are in the right order. In this case, find the package with the subclass, and make sure it is after the abstract classes package. Do this by selecting one package and pressing the "Up" and "Down" keys until the packages are in the right order
> 8. Finally, save the package back to Trunk, and test out the update stream to ensure it works.
> -----
>
> Thanks,
> cbc
>

cbc

Re: Instructions for updating trunk undate config

Hi Eliot,

On Sun, Feb 11, 2018 at 7:56 PM, Eliot Miranda <[hidden email]> wrote:

Hi Chris,

> On Feb 10, 2018, at 1:48 PM, Chris Cunningham <[hidden email]> wrote:
>
> This one I'm going to need some help on, having never done this before (obviously).
>
> -----
> When and How to change the trunk update configuration:
> * When you are adding a new package to trunk, update the configuration with the new package (just because a package is in the repository does not mean it is loaded)
> * When you are removing a package from trunk, update the configuration to remove the package (and follow instructions for removing the package)
> * When methods are moved from one package to another - primarily when they are used in the update logic - then create an update with the package where the method is removed and where the method is added in the same update configuration

That's not the safest. The safest is to create a configuration with the package to which the method is moved, but still containing the version of the package from which the method had moved which still had the method. This way, the package from which the method is moved will be marked dirty but there is no chance of the method being lost.

I wasn't sure where the conversation between you and Bert left off on this subject. I can certainly change this to be this way - especially since it is safer (leaving the Bert enhancement to cover places where we weren't aware that happened, maybe. Although we should be aware.).

Another question: should we ALWAYS create a config when a method (or class) moves from one package to another?

-cbc

Bert Freudenberg

Re: Instructions for updating trunk undate config

On Tue 13. Feb 2018 at 20:38, Chris Cunningham <[hidden email]> wrote:

Hi Eliot,

On Sun, Feb 11, 2018 at 7:56 PM, Eliot Miranda <[hidden email]> wrote:
Hi Chris,

> On Feb 10, 2018, at 1:48 PM, Chris Cunningham <[hidden email]> wrote:
>
> This one I'm going to need some help on, having never done this before (obviously).
>
> -----
> When and How to change the trunk update configuration:
> * When you are adding a new package to trunk, update the configuration with the new package (just because a package is in the repository does not mean it is loaded)
> * When you are removing a package from trunk, update the configuration to remove the package (and follow instructions for removing the package)
> * When methods are moved from one package to another - primarily when they are used in the update logic - then create an update with the package where the method is removed and where the method is added in the same update configuration

That's not the safest. The safest is to create a configuration with the package to which the method is moved, but still containing the version of the package from which the method had moved which still had the method. This way, the package from which the method is moved will be marked dirty but there is no chance of the method being lost.

I wasn't sure where the conversation between you and Bert left off on this subject. I can certainly change this to be this way - especially since it is safer (leaving the Bert enhancement to cover places where we weren't aware that happened, maybe. Although we should be aware.).

Another question: should we ALWAYS create a config when a method (or class) moves from one package to another?

-cbc

IMHO we have way too many config maps already.

We don't need any config maps even for moving methods between packages.

The only time when you actually need an explicit config map is when you are doing open-heart surgery on the kernel.

This is because besides the explicit config maps, the implicit map loaded at the end of the updater usually takes care of everything. It is created on the fly by taking the last published config map and updating it with the latest packages from trunk.

Creating unnecessary config maps just slows down the update process.

- Bert -

Nicolas Cellier

Re: Instructions for updating trunk undate config

2018-02-14 10:04 GMT+01:00 Bert Freudenberg <[hidden email]>:

On Tue 13. Feb 2018 at 20:38, Chris Cunningham <[hidden email]> wrote:
Hi Eliot,

On Sun, Feb 11, 2018 at 7:56 PM, Eliot Miranda <[hidden email]> wrote:
Hi Chris,

> On Feb 10, 2018, at 1:48 PM, Chris Cunningham <[hidden email]> wrote:
>
> This one I'm going to need some help on, having never done this before (obviously).
>
> -----
> When and How to change the trunk update configuration:
> * When you are adding a new package to trunk, update the configuration with the new package (just because a package is in the repository does not mean it is loaded)
> * When you are removing a package from trunk, update the configuration to remove the package (and follow instructions for removing the package)
> * When methods are moved from one package to another - primarily when they are used in the update logic - then create an update with the package where the method is removed and where the method is added in the same update configuration

That's not the safest. The safest is to create a configuration with the package to which the method is moved, but still containing the version of the package from which the method had moved which still had the method. This way, the package from which the method is moved will be marked dirty but there is no chance of the method being lost.

I wasn't sure where the conversation between you and Bert left off on this subject. I can certainly change this to be this way - especially since it is safer (leaving the Bert enhancement to cover places where we weren't aware that happened, maybe. Although we should be aware.).

Another question: should we ALWAYS create a config when a method (or class) moves from one package to another?

-cbc

IMHO we have way too many config maps already.

We don't need any config maps even for moving methods between packages.

The only time when you actually need an explicit config map is when you are doing open-heart surgery on the kernel.

This is because besides the explicit config maps, the implicit map loaded at the end of the updater usually takes care of everything. It is created on the fly by taking the last published config map and updating it with the latest packages from trunk.

Creating unnecessary config maps just slows down the update process.

- Bert -

Other cases: renaming a class is not traced by MC version control

This is seen as addition of a class NewName and deletion of class OldName.

If there are instances of OldName that we want to migrate, then we have to use some preamble/postscript

1) publish NewName, use NewName in client code, and becomeForward: OldName allInstances in postscript

2) Remove OldName and suppress postscript

That means at least one update map entry for 1)

Note that if ever a block refering to OldName is forked, then the process has to be restarted with some surgery...

An alternative would be to script the class rename in some preamble...

Eliot Miranda-2

Re: Instructions for updating trunk undate config

In reply to this post by Bert Freudenberg

Hi Bert,

On Wed, Feb 14, 2018 at 1:04 AM, Bert Freudenberg <[hidden email]> wrote:

On Tue 13. Feb 2018 at 20:38, Chris Cunningham <[hidden email]> wrote:
Hi Eliot,

On Sun, Feb 11, 2018 at 7:56 PM, Eliot Miranda <[hidden email]> wrote:
Hi Chris,

> On Feb 10, 2018, at 1:48 PM, Chris Cunningham <[hidden email]> wrote:
>
> This one I'm going to need some help on, having never done this before (obviously).
>
> -----
> When and How to change the trunk update configuration:
> * When you are adding a new package to trunk, update the configuration with the new package (just because a package is in the repository does not mean it is loaded)
> * When you are removing a package from trunk, update the configuration to remove the package (and follow instructions for removing the package)
> * When methods are moved from one package to another - primarily when they are used in the update logic - then create an update with the package where the method is removed and where the method is added in the same update configuration

That's not the safest. The safest is to create a configuration with the package to which the method is moved, but still containing the version of the package from which the method had moved which still had the method. This way, the package from which the method is moved will be marked dirty but there is no chance of the method being lost.

I wasn't sure where the conversation between you and Bert left off on this subject. I can certainly change this to be this way - especially since it is safer (leaving the Bert enhancement to cover places where we weren't aware that happened, maybe. Although we should be aware.).

Another question: should we ALWAYS create a config when a method (or class) moves from one package to another?

-cbc

IMHO we have way too many config maps already.

We don't need any config maps even for moving methods between packages.

The only time when you actually need an explicit config map is when you are doing open-heart surgery on the kernel.

I agree. But the question is whether we should mention this or not. For me, being able to do open heart surgery reliably is really important. And at the same time having a reliable update process is really important too. occasionally we've had broken updates, due to incorrect update maps, causing temporarily missing methods, etc, when moving code between packages. These episodes are painful; they're difficult to debug because the system is broken; they require meddling with packages and update maps on the repository. So do we err on the side of caution and document the issue, along with caveats such as "this is hyper cautious; you really shouldn't need to do this unless you're doing open heart surgery" or do we not document it and endure the occasional, rare pain of fixing things when they do break. You know me; I'm quite conservative in these things and so lean to the former. But I'm happy to be contradicted here.

This is because besides the explicit config maps, the implicit map loaded at the end of the updater usually takes care of everything. It is created on the fly by taking the last published config map and updating it with the latest packages from trunk.

I would at least like to see this detailed somewhere in Chris's documentation of the process.

Creating unnecessary config maps just slows down the update process.

Agreed. I create them only when I think, most likely mistakenly given my ignorance of Monticello update internals, that there's a chance I'm going to break the system. But unless I have a good understanding of the magic I'm going to find it hard to avoid creating config maps.

- Bert -

_,,,^..^,,,_

best, Eliot