[Glass] [ANN] GsUpgrader

Hi Dale,

I’m currently applying the upgradeGLASS1 on a 3.1 stone running Seaside30 where I am upgrading to Zinc 2.4.3, which relies on GLASS.

I’m getting a load conflict for Grease because I have the one loaded from Smalltalkhub.

ERROR 2710 , a MetacelloConflictingProjectError occurred (error 2710), Load Conflict between existing ConfigurationOfGrease 1.0.9 from http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main and BaselineOfGrease [baseline] from github://GsDevKit/Grease:master/repository (MetacelloConflictingProjectError)

Is this not something we can safely allow? Grease is going to be loaded from smalltalkhub or gemsource in many cases.

Johan

On 16 Sep 2014, at 19:17, Dale Henrichs via Glass <[hidden email]> wrote:

With the move of more and more GsDevKit projects to github, the process of upgrading to the proper version of GLASS and Metacello has gotten fairly complicated: 

  - Upgrade to GLASS1.0-beta.9.3 (unless you have already upgrading to GLASS1)

  - Upgrade to the latest version of Metacello (load preview unless you have already loaded a baseline)

  - Upgrade to the latest version of GLASS1

I am also still adding features and bugfixes to Metacello to improve the support of git/github projects, and unfortunately it is not always possible to use Metacello to install an upgrade of Metacello itself.

I created the gsUpgrader[1] project to simplify the upgrade process for the github-based projects. GsUpgrader is a single class with four entry points:

  - upgradeGLASS[3]

  - upgradeGLASS1[4]

  - upgradeGrease[5] 

  - upgradeMetacello[6] 

A fifth entry point: #metacelloReport produces a project/package version report that is useful to help debug upgrade issues ... I've tested GsUpgrader in a number of scenarios[7], but there always seem to be special cases that sneak through the cracks.

The class is loaded from a package using the following expression:

  Gofer new

    package: 'GsUpgrader-Core';

    url: 'http://ss3.gemtalksystems.com/ss/gsUpgrader';

    load.

A simple package is used so that the GsUpgrader class can be used to upgrade GemStone installations as old as GemStone 2.4.4.1[2] (the first GemStone version that officially supported GLASS).

I will start updating the installation instructions for the various github-based projects to use GsUpgrader.

I would recommend that all of you use GsUpgrader to upgrade to the latest version of Metacello using the following expression:

  Gofer new

    package: 'GsUpgrader-Core';

    url: 'http://ss3.gemtalksystems.com/ss/gsUpgrader';

    load.

  (Smalltalk at: #GsUpgrader) upgradeMetacello.

Having an up-to-date version of Metacello is probably the most important thing at this juncture and it is always a good idea to upgrade Metacello before upgading any other github-based projects.

Dale

[1] https://github.com/GsDevKit/gsUpgrader#gsupgrader-

[2] http://gemstonesoup.wordpress.com/2010/07/15/gemstones-64-version-2-4-4-1-is-shipping/

[3] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgradeglass

[4] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgradeglass1

[5] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgradegrease

[6] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgrademetacello

[7] https://travis-ci.org/GsDevKit/gsUpgrader/builds/35386940

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

That’s pretty much what I was thinking :)

Loading a newer version of Grease should not be a problem. I’m going to check the delta from 1.0.x to 1.1.x to make sure.

In the meantime, I removed the Grease project registration from the registry before doing the upgradeGLASS1 to make Metacello pass through with the load.

Johan

On 19 Sep 2014, at 21:34, Dale Henrichs <[hidden email]> wrote:

Good catch ... I think:)

You are right, GsUpgrader shouldn't be hitting conflicts for Grease...

My inclination is to fix this and "force" the github-base Grease to be loaded (unless the Grease project is locked, in which case the lock wins), since the bugfixes there will always be more current ... 

What do you think?

Dale

On Fri, Sep 19, 2014 at 12:12 PM, Johan Brichau <[hidden email]> wrote:

Hi Dale,

I’m currently applying the upgradeGLASS1 on a 3.1 stone running Seaside30 where I am upgrading to Zinc 2.4.3, which relies on GLASS.

I’m getting a load conflict for Grease because I have the one loaded from Smalltalkhub.

ERROR 2710 , a MetacelloConflictingProjectError occurred (error 2710), Load Conflict between existing ConfigurationOfGrease 1.0.9 from http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main and BaselineOfGrease [baseline] from github://GsDevKit/Grease:master/repository (MetacelloConflictingProjectError)

Is this not something we can safely allow? Grease is going to be loaded from smalltalkhub or gemsource in many cases.

Johan

On 16 Sep 2014, at 19:17, Dale Henrichs via Glass <[hidden email]> wrote:

With the move of more and more GsDevKit projects to github, the process of upgrading to the proper version of GLASS and Metacello has gotten fairly complicated: 

  - Upgrade to GLASS1.0-beta.9.3 (unless you have already upgrading to GLASS1)

  - Upgrade to the latest version of Metacello (load preview unless you have already loaded a baseline)

  - Upgrade to the latest version of GLASS1

I am also still adding features and bugfixes to Metacello to improve the support of git/github projects, and unfortunately it is not always possible to use Metacello to install an upgrade of Metacello itself.

I created the gsUpgrader[1] project to simplify the upgrade process for the github-based projects. GsUpgrader is a single class with four entry points:

  - upgradeGLASS[3]

  - upgradeGLASS1[4]

  - upgradeGrease[5] 

  - upgradeMetacello[6] 

A fifth entry point: #metacelloReport produces a project/package version report that is useful to help debug upgrade issues ... I've tested GsUpgrader in a number of scenarios[7], but there always seem to be special cases that sneak through the cracks.

The class is loaded from a package using the following expression:

  Gofer new

    package: 'GsUpgrader-Core';

    url: 'http://ss3.gemtalksystems.com/ss/gsUpgrader';

    load.

A simple package is used so that the GsUpgrader class can be used to upgrade GemStone installations as old as GemStone 2.4.4.1[2] (the first GemStone version that officially supported GLASS).

I will start updating the installation instructions for the various github-based projects to use GsUpgrader.

I would recommend that all of you use GsUpgrader to upgrade to the latest version of Metacello using the following expression:

  Gofer new

    package: 'GsUpgrader-Core';

    url: 'http://ss3.gemtalksystems.com/ss/gsUpgrader';

    load.

  (Smalltalk at: #GsUpgrader) upgradeMetacello.

Having an up-to-date version of Metacello is probably the most important thing at this juncture and it is always a good idea to upgrade Metacello before upgading any other github-based projects.

Dale

[1] https://github.com/GsDevKit/gsUpgrader#gsupgrader-

[2] http://gemstonesoup.wordpress.com/2010/07/15/gemstones-64-version-2-4-4-1-is-shipping/

[3] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgradeglass

[4] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgradeglass1

[5] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgradegrease

[6] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgrademetacello

[7] https://travis-ci.org/GsDevKit/gsUpgrader/builds/35386940

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Okay ... submitted GsUpgrader issue[1] for tracking ... I should take care of this puppy shortly ...

Dale

[1] https://github.com/GsDevKit/gsUpgrader/issues/3

On Fri, Sep 19, 2014 at 1:33 PM, Johan Brichau <[hidden email]> wrote:

That’s pretty much what I was thinking :)

Loading a newer version of Grease should not be a problem. I’m going to check the delta from 1.0.x to 1.1.x to make sure.

In the meantime, I removed the Grease project registration from the registry before doing the upgradeGLASS1 to make Metacello pass through with the load.

Johan

On 19 Sep 2014, at 21:34, Dale Henrichs <[hidden email]> wrote:

Good catch ... I think:)

You are right, GsUpgrader shouldn't be hitting conflicts for Grease...

My inclination is to fix this and "force" the github-base Grease to be loaded (unless the Grease project is locked, in which case the lock wins), since the bugfixes there will always be more current ... 

What do you think?

Dale

On Fri, Sep 19, 2014 at 12:12 PM, Johan Brichau <[hidden email]> wrote:

Hi Dale,

I’m currently applying the upgradeGLASS1 on a 3.1 stone running Seaside30 where I am upgrading to Zinc 2.4.3, which relies on GLASS.

I’m getting a load conflict for Grease because I have the one loaded from Smalltalkhub.

ERROR 2710 , a MetacelloConflictingProjectError occurred (error 2710), Load Conflict between existing ConfigurationOfGrease 1.0.9 from http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main and BaselineOfGrease [baseline] from github://GsDevKit/Grease:master/repository (MetacelloConflictingProjectError)

Is this not something we can safely allow? Grease is going to be loaded from smalltalkhub or gemsource in many cases.

Johan

On 16 Sep 2014, at 19:17, Dale Henrichs via Glass <[hidden email]> wrote:

With the move of more and more GsDevKit projects to github, the process of upgrading to the proper version of GLASS and Metacello has gotten fairly complicated: 

  - Upgrade to GLASS1.0-beta.9.3 (unless you have already upgrading to GLASS1)

  - Upgrade to the latest version of Metacello (load preview unless you have already loaded a baseline)

  - Upgrade to the latest version of GLASS1

I am also still adding features and bugfixes to Metacello to improve the support of git/github projects, and unfortunately it is not always possible to use Metacello to install an upgrade of Metacello itself.

I created the gsUpgrader[1] project to simplify the upgrade process for the github-based projects. GsUpgrader is a single class with four entry points:

  - upgradeGLASS[3]

  - upgradeGLASS1[4]

  - upgradeGrease[5] 

  - upgradeMetacello[6] 

A fifth entry point: #metacelloReport produces a project/package version report that is useful to help debug upgrade issues ... I've tested GsUpgrader in a number of scenarios[7], but there always seem to be special cases that sneak through the cracks.

The class is loaded from a package using the following expression:

  Gofer new

    package: 'GsUpgrader-Core';

    url: 'http://ss3.gemtalksystems.com/ss/gsUpgrader';

    load.

A simple package is used so that the GsUpgrader class can be used to upgrade GemStone installations as old as GemStone 2.4.4.1[2] (the first GemStone version that officially supported GLASS).

I will start updating the installation instructions for the various github-based projects to use GsUpgrader.

I would recommend that all of you use GsUpgrader to upgrade to the latest version of Metacello using the following expression:

  Gofer new

    package: 'GsUpgrader-Core';

    url: 'http://ss3.gemtalksystems.com/ss/gsUpgrader';

    load.

  (Smalltalk at: #GsUpgrader) upgradeMetacello.

Having an up-to-date version of Metacello is probably the most important thing at this juncture and it is always a good idea to upgrade Metacello before upgading any other github-based projects.

Dale

[1] https://github.com/GsDevKit/gsUpgrader#gsupgrader-

[2] http://gemstonesoup.wordpress.com/2010/07/15/gemstones-64-version-2-4-4-1-is-shipping/

[3] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgradeglass

[4] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgradeglass1

[5] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgradegrease

[6] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgrademetacello

[7] https://travis-ci.org/GsDevKit/gsUpgrader/builds/35386940

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Hi Dale,

I’m currently applying the upgradeGLASS1 on a 3.1 stone running Seaside30 where I am upgrading to Zinc 2.4.3, which relies on GLASS.

I’m getting a load conflict for Grease because I have the one loaded from Smalltalkhub.

ERROR 2710 , a MetacelloConflictingProjectError occurred (error 2710), Load Conflict between existing ConfigurationOfGrease 1.0.9 from http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main and BaselineOfGrease [baseline] from github://GsDevKit/Grease:master/repository (MetacelloConflictingProjectError)

Is this not something we can safely allow? Grease is going to be loaded from smalltalkhub or gemsource in many cases.

Johan

On 16 Sep 2014, at 19:17, Dale Henrichs via Glass <[hidden email]> wrote:

With the move of more and more GsDevKit projects to github, the process of upgrading to the proper version of GLASS and Metacello has gotten fairly complicated: 

  - Upgrade to GLASS1.0-beta.9.3 (unless you have already upgrading to GLASS1)

  - Upgrade to the latest version of Metacello (load preview unless you have already loaded a baseline)

  - Upgrade to the latest version of GLASS1

I am also still adding features and bugfixes to Metacello to improve the support of git/github projects, and unfortunately it is not always possible to use Metacello to install an upgrade of Metacello itself.

I created the gsUpgrader[1] project to simplify the upgrade process for the github-based projects. GsUpgrader is a single class with four entry points:

  - upgradeGLASS[3]

  - upgradeGLASS1[4]

  - upgradeGrease[5] 

  - upgradeMetacello[6] 

A fifth entry point: #metacelloReport produces a project/package version report that is useful to help debug upgrade issues ... I've tested GsUpgrader in a number of scenarios[7], but there always seem to be special cases that sneak through the cracks.

The class is loaded from a package using the following expression:

  Gofer new

    package: 'GsUpgrader-Core';

    url: 'http://ss3.gemtalksystems.com/ss/gsUpgrader';

    load.

A simple package is used so that the GsUpgrader class can be used to upgrade GemStone installations as old as GemStone 2.4.4.1[2] (the first GemStone version that officially supported GLASS).

I will start updating the installation instructions for the various github-based projects to use GsUpgrader.

I would recommend that all of you use GsUpgrader to upgrade to the latest version of Metacello using the following expression:

  Gofer new

    package: 'GsUpgrader-Core';

    url: 'http://ss3.gemtalksystems.com/ss/gsUpgrader';

    load.

  (Smalltalk at: #GsUpgrader) upgradeMetacello.

Having an up-to-date version of Metacello is probably the most important thing at this juncture and it is always a good idea to upgrade Metacello before upgading any other github-based projects.

Dale

[1] https://github.com/GsDevKit/gsUpgrader#gsupgrader-

[2] http://gemstonesoup.wordpress.com/2010/07/15/gemstones-64-version-2-4-4-1-is-shipping/

[3] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgradeglass

[4] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgradeglass1

[5] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgradegrease

[6] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgrademetacello

[7] https://travis-ci.org/GsDevKit/gsUpgrader/builds/35386940

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Johan,

I have been trying a whole bunch of combinations to try to reproduce the conflict that you are seeing and I've been unsuccessful ... so I guess I need additional information. 

The log or transcript of the upgrade would be very useful along with the result of:

  GsUpgrader metacelloReport

from before the load ...

In the latest version of Metacello loading a baseline over a configuration should never produce a conflict ... so you've probably got a specific version of Metacello loaded along with GLASS that slips through the GsUpgrader net ...

There is a path in GsUpgrader that looks suspicious, but I prefer to have a specific test case before making changes ...

Dale

On Fri, Sep 19, 2014 at 12:12 PM, Johan Brichau <[hidden email]> wrote:

Hi Dale,

I’m currently applying the upgradeGLASS1 on a 3.1 stone running Seaside30 where I am upgrading to Zinc 2.4.3, which relies on GLASS.

I’m getting a load conflict for Grease because I have the one loaded from Smalltalkhub.

ERROR 2710 , a MetacelloConflictingProjectError occurred (error 2710), Load Conflict between existing ConfigurationOfGrease 1.0.9 from http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main and BaselineOfGrease [baseline] from github://GsDevKit/Grease:master/repository (MetacelloConflictingProjectError)

Is this not something we can safely allow? Grease is going to be loaded from smalltalkhub or gemsource in many cases.

Johan

On 16 Sep 2014, at 19:17, Dale Henrichs via Glass <[hidden email]> wrote:

With the move of more and more GsDevKit projects to github, the process of upgrading to the proper version of GLASS and Metacello has gotten fairly complicated: 

  - Upgrade to GLASS1.0-beta.9.3 (unless you have already upgrading to GLASS1)

  - Upgrade to the latest version of Metacello (load preview unless you have already loaded a baseline)

  - Upgrade to the latest version of GLASS1

I am also still adding features and bugfixes to Metacello to improve the support of git/github projects, and unfortunately it is not always possible to use Metacello to install an upgrade of Metacello itself.

I created the gsUpgrader[1] project to simplify the upgrade process for the github-based projects. GsUpgrader is a single class with four entry points:

  - upgradeGLASS[3]

  - upgradeGLASS1[4]

  - upgradeGrease[5] 

  - upgradeMetacello[6] 

A fifth entry point: #metacelloReport produces a project/package version report that is useful to help debug upgrade issues ... I've tested GsUpgrader in a number of scenarios[7], but there always seem to be special cases that sneak through the cracks.

The class is loaded from a package using the following expression:

  Gofer new

    package: 'GsUpgrader-Core';

    url: 'http://ss3.gemtalksystems.com/ss/gsUpgrader';

    load.

A simple package is used so that the GsUpgrader class can be used to upgrade GemStone installations as old as GemStone 2.4.4.1[2] (the first GemStone version that officially supported GLASS).

I will start updating the installation instructions for the various github-based projects to use GsUpgrader.

I would recommend that all of you use GsUpgrader to upgrade to the latest version of Metacello using the following expression:

  Gofer new

    package: 'GsUpgrader-Core';

    url: 'http://ss3.gemtalksystems.com/ss/gsUpgrader';

    load.

  (Smalltalk at: #GsUpgrader) upgradeMetacello.

Having an up-to-date version of Metacello is probably the most important thing at this juncture and it is always a good idea to upgrade Metacello before upgading any other github-based projects.

Dale

[1] https://github.com/GsDevKit/gsUpgrader#gsupgrader-

[2] http://gemstonesoup.wordpress.com/2010/07/15/gemstones-64-version-2-4-4-1-is-shipping/

[3] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgradeglass

[4] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgradeglass1

[5] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgradegrease

[6] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgrademetacello

[7] https://travis-ci.org/GsDevKit/gsUpgrader/builds/35386940

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Question -- is the GsUpgrader intended to be used for the initial install of glass?

If not, i'll start another thread.

if so.. I got new errors when trying.

On Sat, Sep 20, 2014 at 6:22 PM, Dale Henrichs via Glass <[hidden email]> wrote:

Johan,

I have been trying a whole bunch of combinations to try to reproduce the conflict that you are seeing and I've been unsuccessful ... so I guess I need additional information. 

The log or transcript of the upgrade would be very useful along with the result of:

  GsUpgrader metacelloReport

from before the load ...

In the latest version of Metacello loading a baseline over a configuration should never produce a conflict ... so you've probably got a specific version of Metacello loaded along with GLASS that slips through the GsUpgrader net ...

There is a path in GsUpgrader that looks suspicious, but I prefer to have a specific test case before making changes ...

Dale

On Fri, Sep 19, 2014 at 12:12 PM, Johan Brichau <[hidden email]> wrote:

Hi Dale,

I’m currently applying the upgradeGLASS1 on a 3.1 stone running Seaside30 where I am upgrading to Zinc 2.4.3, which relies on GLASS.

I’m getting a load conflict for Grease because I have the one loaded from Smalltalkhub.

ERROR 2710 , a MetacelloConflictingProjectError occurred (error 2710), Load Conflict between existing ConfigurationOfGrease 1.0.9 from http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main and BaselineOfGrease [baseline] from github://GsDevKit/Grease:master/repository (MetacelloConflictingProjectError)

Is this not something we can safely allow? Grease is going to be loaded from smalltalkhub or gemsource in many cases.

Johan

On 16 Sep 2014, at 19:17, Dale Henrichs via Glass <[hidden email]> wrote:

With the move of more and more GsDevKit projects to github, the process of upgrading to the proper version of GLASS and Metacello has gotten fairly complicated: 

  - Upgrade to GLASS1.0-beta.9.3 (unless you have already upgrading to GLASS1)

  - Upgrade to the latest version of Metacello (load preview unless you have already loaded a baseline)

  - Upgrade to the latest version of GLASS1

I am also still adding features and bugfixes to Metacello to improve the support of git/github projects, and unfortunately it is not always possible to use Metacello to install an upgrade of Metacello itself.

I created the gsUpgrader[1] project to simplify the upgrade process for the github-based projects. GsUpgrader is a single class with four entry points:

  - upgradeGLASS[3]

  - upgradeGLASS1[4]

  - upgradeGrease[5] 

  - upgradeMetacello[6] 

A fifth entry point: #metacelloReport produces a project/package version report that is useful to help debug upgrade issues ... I've tested GsUpgrader in a number of scenarios[7], but there always seem to be special cases that sneak through the cracks.

The class is loaded from a package using the following expression:

  Gofer new

    package: 'GsUpgrader-Core';

    url: 'http://ss3.gemtalksystems.com/ss/gsUpgrader';

    load.

A simple package is used so that the GsUpgrader class can be used to upgrade GemStone installations as old as GemStone 2.4.4.1[2] (the first GemStone version that officially supported GLASS).

I will start updating the installation instructions for the various github-based projects to use GsUpgrader.

I would recommend that all of you use GsUpgrader to upgrade to the latest version of Metacello using the following expression:

  Gofer new

    package: 'GsUpgrader-Core';

    url: 'http://ss3.gemtalksystems.com/ss/gsUpgrader';

    load.

  (Smalltalk at: #GsUpgrader) upgradeMetacello.

Having an up-to-date version of Metacello is probably the most important thing at this juncture and it is always a good idea to upgrade Metacello before upgading any other github-based projects.

Dale

[1] https://github.com/GsDevKit/gsUpgrader#gsupgrader-

[2] http://gemstonesoup.wordpress.com/2010/07/15/gemstones-64-version-2-4-4-1-is-shipping/

[3] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgradeglass

[4] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgradeglass1

[5] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgradegrease

[6] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgrademetacello

[7] https://travis-ci.org/GsDevKit/gsUpgrader/builds/35386940

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

The GsUpgrader is intended to work with any $GEMSTONE/bin/extent0.seaside.dbf .... it will not work work with a $GEMSTONE/bin/extent0.dbf...

Dale

On Sat, Sep 20, 2014 at 6:34 PM, Jon Paynter via Glass <[hidden email]> wrote:

Question -- is the GsUpgrader intended to be used for the initial install of glass?

If not, i'll start another thread.

if so.. I got new errors when trying.

On Sat, Sep 20, 2014 at 6:22 PM, Dale Henrichs via Glass <[hidden email]> wrote:

Johan,

I have been trying a whole bunch of combinations to try to reproduce the conflict that you are seeing and I've been unsuccessful ... so I guess I need additional information. 

The log or transcript of the upgrade would be very useful along with the result of:

  GsUpgrader metacelloReport

from before the load ...

In the latest version of Metacello loading a baseline over a configuration should never produce a conflict ... so you've probably got a specific version of Metacello loaded along with GLASS that slips through the GsUpgrader net ...

There is a path in GsUpgrader that looks suspicious, but I prefer to have a specific test case before making changes ...

Dale

On Fri, Sep 19, 2014 at 12:12 PM, Johan Brichau <[hidden email]> wrote:

Hi Dale,

I’m currently applying the upgradeGLASS1 on a 3.1 stone running Seaside30 where I am upgrading to Zinc 2.4.3, which relies on GLASS.

I’m getting a load conflict for Grease because I have the one loaded from Smalltalkhub.

ERROR 2710 , a MetacelloConflictingProjectError occurred (error 2710), Load Conflict between existing ConfigurationOfGrease 1.0.9 from http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main and BaselineOfGrease [baseline] from github://GsDevKit/Grease:master/repository (MetacelloConflictingProjectError)

Is this not something we can safely allow? Grease is going to be loaded from smalltalkhub or gemsource in many cases.

Johan

On 16 Sep 2014, at 19:17, Dale Henrichs via Glass <[hidden email]> wrote:

With the move of more and more GsDevKit projects to github, the process of upgrading to the proper version of GLASS and Metacello has gotten fairly complicated: 

  - Upgrade to GLASS1.0-beta.9.3 (unless you have already upgrading to GLASS1)

  - Upgrade to the latest version of Metacello (load preview unless you have already loaded a baseline)

  - Upgrade to the latest version of GLASS1

I am also still adding features and bugfixes to Metacello to improve the support of git/github projects, and unfortunately it is not always possible to use Metacello to install an upgrade of Metacello itself.

I created the gsUpgrader[1] project to simplify the upgrade process for the github-based projects. GsUpgrader is a single class with four entry points:

  - upgradeGLASS[3]

  - upgradeGLASS1[4]

  - upgradeGrease[5] 

  - upgradeMetacello[6] 

A fifth entry point: #metacelloReport produces a project/package version report that is useful to help debug upgrade issues ... I've tested GsUpgrader in a number of scenarios[7], but there always seem to be special cases that sneak through the cracks.

The class is loaded from a package using the following expression:

  Gofer new

    package: 'GsUpgrader-Core';

    url: 'http://ss3.gemtalksystems.com/ss/gsUpgrader';

    load.

A simple package is used so that the GsUpgrader class can be used to upgrade GemStone installations as old as GemStone 2.4.4.1[2] (the first GemStone version that officially supported GLASS).

I will start updating the installation instructions for the various github-based projects to use GsUpgrader.

I would recommend that all of you use GsUpgrader to upgrade to the latest version of Metacello using the following expression:

  Gofer new

    package: 'GsUpgrader-Core';

    url: 'http://ss3.gemtalksystems.com/ss/gsUpgrader';

    load.

  (Smalltalk at: #GsUpgrader) upgradeMetacello.

Having an up-to-date version of Metacello is probably the most important thing at this juncture and it is always a good idea to upgrade Metacello before upgading any other github-based projects.

Dale

[1] https://github.com/GsDevKit/gsUpgrader#gsupgrader-

[2] http://gemstonesoup.wordpress.com/2010/07/15/gemstones-64-version-2-4-4-1-is-shipping/

[3] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgradeglass

[4] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgradeglass1

[5] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgradegrease

[6] https://github.com/GsDevKit/gsUpgrader#gsupgrader-classupgrademetacello

[7] https://travis-ci.org/GsDevKit/gsUpgrader/builds/35386940

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Johan,

@Dale: this time, it wasn’t me, it was Jon :)

I have been trying a whole bunch of combinations to try to reproduce the conflict that you are seeing and I've been unsuccessful ... so I guess I need additional information. 

Jon, I just ran into an issue which I suspect you are seeing as well [1].

For me to confirm, could you repeat these steps and see if it works:

- when the error happens, exit from topaz

- login to topaz again and launch the same upgrade expression

-> does it work?

If yes, then it is the same issue as the one in [1]. Otherwise, can you keep an eye on the memory consumption of your box (using top/htop) while running the upgrade script? And what amount of memory is available on your box?

Johan

[1] https://github.com/GsDevKit/gsUpgrader/issues/5

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Johan,

The bug that you reported does indeed produce the error signature that you reported earlier and is likely to be the root cause of Jon's problems as well ...

I have a couple of open bugs against Metacello about the poor error messages for retry[1] and poor error reporting during github downloads[2] that I was about to address today:) so the timing is good.

Right now I still am a bit mystified about why I am not seeing the errors caused by "Cannot allocate memory", but now that I know what to look for, I should be able to figure it out ...

So thanky Jon and Johan for your patience and help ferreting this puppy out!

Dale

[1] https://github.com/dalehenrich/metacello-work/issues/227

[2] https://github.com/dalehenrich/metacello-work/issues/226

On Mon, Sep 22, 2014 at 7:39 AM, Johan Brichau via Glass <[hidden email]> wrote:

Johan,

@Dale: this time, it wasn’t me, it was Jon :)

I have been trying a whole bunch of combinations to try to reproduce the conflict that you are seeing and I've been unsuccessful ... so I guess I need additional information. 

Jon, I just ran into an issue which I suspect you are seeing as well [1].

For me to confirm, could you repeat these steps and see if it works:

- when the error happens, exit from topaz

- login to topaz again and launch the same upgrade expression

-> does it work?

If yes, then it is the same issue as the one in [1]. Otherwise, can you keep an eye on the memory consumption of your box (using top/htop) while running the upgrade script? And what amount of memory is available on your box?

Johan

[1] https://github.com/GsDevKit/gsUpgrader/issues/5

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

On Mon, Sep 22, 2014 at 10:50 AM, Jon Paynter <[hidden email]> wrote:

Dale,

Glad to hear you found the problem.

i suspect what im seeing is different.  initially I was getting an error when running #upgradeGLASS1, so based on Johan's report of out of memory, I ran the various parts individually, with a commit and logout in between.

#upgradeGrease --> no problems

  it also ran #upgradeMetacello with no problems.

But when I run #upgradeGLASS1, I get this:
--transcript--'Loading baseline of BaselineOfGrease...'
--transcript--'Project: System-Digital-Signatures stable'
--transcript--' [0.243]'
--transcript--'Project: SMTPMail stable'
--transcript--'Project: UTF8 stable'
--transcript--'...finished baseline'
--transcript--'No instance migrations performed.'
ERROR 2003 , a OffsetError occurred (error 2003), reason:objErrBadOffsetIncomplete, max:0 actual:1 (OffsetError)
topaz 1>

I would like to see the stack from the offset error use the `stack` command to generate the stack so I can see frame contexts...

Thanks,

Dale

@Johan - I did quit topaz between sessions.  sorry for not making that clear

@Dale - here is the stack:
topaz 1> stack
==> 1 OffsetError (AbstractException) >> _signalWith: @5 line 25
    receiver a OffsetError occurred (error 2003), reason:objErrBadOffsetIncomplete, max:0 actual:1
    inCextensionArg nil
    res nil
2 OffsetError (AbstractException) >> signal     @2 line 47
    receiver a OffsetError occurred (error 2003), reason:objErrBadOffsetIncomplete, max:0 actual:1
(skipped 1 evaluationTemps)
3 OrderedCollection (Object) >> _error:args:    @15 line 11
    receiver anOrderedCollection
    errorSymbol objErrBadOffsetIncomplete
    argList anArray
    cls OffsetError
    mv anArray
    errNum 2003
    newArgList anArray
(skipped 1 evaluationTemps)
4 OrderedCollection (Object) >> _errorIndexOutOfRange: @2 line 6
    receiver anOrderedCollection
    anIndex 1
(skipped 2 evaluationTemps)
5 OrderedCollection (Object) >> at:             @9 line 15
    receiver anOrderedCollection
    anIndex 1
(skipped 1 evaluationTemps)
6 OrderedCollection (SequenceableCollection) >> first @2 line 5
    receiver anOrderedCollection
(skipped 1 evaluationTemps)
7 GsUpgrader >> standardUpgrade:repository:     @6 line 5
    receiver aGsUpgrader
    projectName Grease
    repositoryDescription github://GsDevKit/Grease:master/repository
    repositoryDescription github://GsDevKit/Grease:master/repository
    metacello nil
    projectName Grease
    projectSpec nil
    self aGsUpgrader
8 GsUpgrader >> upgradeGrease                   @6 line 6
    receiver aGsUpgrader
(skipped 3 evaluationTemps)
9 GsUpgrader >> upgradeGLASS1                   @11 line 13
    receiver aGsUpgrader
(skipped 1 evaluationTemps)
10 GsUpgrader class >> upgradeGLASS1             @3 line 4
    receiver GsUpgrader
11 Executed Code                                 @3 line 1
    receiver nil
12 UndefinedObject (GsNMethod class) >> _gsReturnToC @1 line 1
    receiver nil
topaz 1>

On Mon, Sep 22, 2014 at 11:00 AM, Dale Henrichs <[hidden email]> wrote:

On Mon, Sep 22, 2014 at 10:50 AM, Jon Paynter <[hidden email]> wrote:

Dale,

Glad to hear you found the problem.

i suspect what im seeing is different.  initially I was getting an error when running #upgradeGLASS1, so based on Johan's report of out of memory, I ran the various parts individually, with a commit and logout in between.

#upgradeGrease --> no problems

  it also ran #upgradeMetacello with no problems.

But when I run #upgradeGLASS1, I get this:
--transcript--'Loading baseline of BaselineOfGrease...'
--transcript--'Project: System-Digital-Signatures stable'
--transcript--' [0.243]'
--transcript--'Project: SMTPMail stable'
--transcript--'Project: UTF8 stable'
--transcript--'...finished baseline'
--transcript--'No instance migrations performed.'
ERROR 2003 , a OffsetError occurred (error 2003), reason:objErrBadOffsetIncomplete, max:0 actual:1 (OffsetError)
topaz 1>

I would like to see the stack from the offset error use the `stack` command to generate the stack so I can see frame contexts...

Thanks,

Dale

Jon,

Thanks for the stack ... the offset error is happening because the Grease project has not been registered and I have been having a devil of a time finding the right combination that ends up with the you getting to this point without getting the Grease project registered (which is the root cause of this particular bug)....

It's a shame that you don't have the log files from each of your experiments, since that would be extremely helpful... Do you start with a fresh extent every time or are you starting from a previously failed extent?

If you are starting with a fresh extent, I would ask that if you are willing to try again that you record each shell command that you launch and when you are in topaz use `output push append bug.out` to record all of the output from the topaz commands into a single file that I can look at ..

As it stands I can patch this particular problem, but I am unable to test the validity of my patch and AFAICT this is the first time you've hit this particular problem so there are other problems (likely to be the one that Johan found) that are leading to this situation, but I really don't know for sure and I have been unable to figure it out by randomly trying different combinations...

Dale

On Mon, Sep 22, 2014 at 11:04 AM, Jon Paynter <[hidden email]> wrote:

@Johan - I did quit topaz between sessions.  sorry for not making that clear

@Dale - here is the stack:
topaz 1> stack
==> 1 OffsetError (AbstractException) >> _signalWith: @5 line 25
    receiver a OffsetError occurred (error 2003), reason:objErrBadOffsetIncomplete, max:0 actual:1
    inCextensionArg nil
    res nil
2 OffsetError (AbstractException) >> signal     @2 line 47
    receiver a OffsetError occurred (error 2003), reason:objErrBadOffsetIncomplete, max:0 actual:1
(skipped 1 evaluationTemps)
3 OrderedCollection (Object) >> _error:args:    @15 line 11
    receiver anOrderedCollection
    errorSymbol objErrBadOffsetIncomplete
    argList anArray
    cls OffsetError
    mv anArray
    errNum 2003
    newArgList anArray
(skipped 1 evaluationTemps)
4 OrderedCollection (Object) >> _errorIndexOutOfRange: @2 line 6
    receiver anOrderedCollection
    anIndex 1
(skipped 2 evaluationTemps)
5 OrderedCollection (Object) >> at:             @9 line 15
    receiver anOrderedCollection
    anIndex 1
(skipped 1 evaluationTemps)
6 OrderedCollection (SequenceableCollection) >> first @2 line 5
    receiver anOrderedCollection
(skipped 1 evaluationTemps)
7 GsUpgrader >> standardUpgrade:repository:     @6 line 5
    receiver aGsUpgrader
    projectName Grease
    repositoryDescription github://GsDevKit/Grease:master/repository
    repositoryDescription github://GsDevKit/Grease:master/repository
    metacello nil
    projectName Grease
    projectSpec nil
    self aGsUpgrader
8 GsUpgrader >> upgradeGrease                   @6 line 6
    receiver aGsUpgrader
(skipped 3 evaluationTemps)
9 GsUpgrader >> upgradeGLASS1                   @11 line 13
    receiver aGsUpgrader
(skipped 1 evaluationTemps)
10 GsUpgrader class >> upgradeGLASS1             @3 line 4
    receiver GsUpgrader
11 Executed Code                                 @3 line 1
    receiver nil
12 UndefinedObject (GsNMethod class) >> _gsReturnToC @1 line 1
    receiver nil
topaz 1>

On Mon, Sep 22, 2014 at 11:00 AM, Dale Henrichs <[hidden email]> wrote:

On Mon, Sep 22, 2014 at 10:50 AM, Jon Paynter <[hidden email]> wrote:

Dale,

Glad to hear you found the problem.

i suspect what im seeing is different.  initially I was getting an error when running #upgradeGLASS1, so based on Johan's report of out of memory, I ran the various parts individually, with a commit and logout in between.

#upgradeGrease --> no problems

  it also ran #upgradeMetacello with no problems.

But when I run #upgradeGLASS1, I get this:
--transcript--'Loading baseline of BaselineOfGrease...'
--transcript--'Project: System-Digital-Signatures stable'
--transcript--' [0.243]'
--transcript--'Project: SMTPMail stable'
--transcript--'Project: UTF8 stable'
--transcript--'...finished baseline'
--transcript--'No instance migrations performed.'
ERROR 2003 , a OffsetError occurred (error 2003), reason:objErrBadOffsetIncomplete, max:0 actual:1 (OffsetError)
topaz 1>

I would like to see the stack from the offset error use the `stack` command to generate the stack so I can see frame contexts...

Thanks,

Dale

On Mon, Sep 22, 2014 at 12:01 PM, Jon Paynter <[hidden email]> wrote:

Hi Dale,
Im at the office right now with a fresh VM.  No dev work was done, so I removed /opt/gemstone to start over.

Here are the steps I took

1)  ./installGemstone.sh 3.1.0.6

   note - since outbound FTP is blocked, I manually transferred the zip file to my VM.

2) startnet / startGemstone

3) load GsUpgrader

4) run #upgradeGLASS1

.... which worked.

Except when I connect with my pharo dev image, there are no Seaside classes loaded -- WAComponent does not exist.

So im puzzled as to what actually got "upgraded"

GsUpgrader does not install or upgrade Seaside ... GsUpgrade upgrades GLASS/GLASS1, Grease and Metacello ...

A virgin 3.1.0.6 (extent0.seaside.dbf) does not have the latest Grease, Metacello or GLASS1 installed so GsUpgrade, upgrades those packages ... Once you've done the upgrade, the install of Seaside should run smoothly ...

Note - the previous version was using gemstone 3.2.2...which may be where my previous problems were coming from.

I am running tests of GsUpgrader against virgin installs from 2.4.4.1, to 3.2.2 and many of the version in between[1] and they are all passing ...

I believe that one set of problems come from attempting to use GsUpgrader in images that have already had some combination of Metacello/GLASS1/Grease installed ... I would like to be able to characterize those types of problems so that I can bullet-proof the GsUpgrader script ... the offset error that you reported this morning helps me to bullet-proof GsUpgrader[2]

Another set of problems is very likely due to the out-of-memory problem reported by Johan ... in fact once I reproduce Johan's problem in my lab, I might start to see the other problems as well ...

Dale

[1] https://travis-ci.org/GsDevKit/gsUpgrader/builds/35778252
[2] https://github.com/GsDevKit/gsUpgrader/issues/6