Hi, Stef and I developed Snapshotcello, a little utility that enables you to freeze a snapshot of a given configuration based on what is already loaded in your current image. The idea is simple. You develop against the latest versions of all packages, and commit your changes for each package. When you are ready for a release, you assemble your image, and generate a snapshot version that can be reloaded later. Here is an example of how it can work to take a snapshot of a development version: Snapshotcello new configurationClass: ConfigurationOfMoose; configurationVersion: #development; publishVersion: '4.8-snapshot' You can find more details here: http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-rea... You can get the code at: Gofer new smalltalkhubUser: 'girba' project: 'Snapshotcello'; package: 'ConfigurationOfSnapshotcello'; load. (Smalltalk globals at: #ConfigurationOfSnapshotcello) loadDevelopment Cheers, Doru -- www.tudorgirba.com "Every successful trip needs a suitable vehicle."
Nice to see SnapshotCello coming to live. May be it should be integrated to Metacello. Because everybody may need this cool feature. Stef On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Stef and I developed Snapshotcello, a little utility that enables you to freeze a snapshot of a given configuration based on what is already loaded in your current image.
The idea is simple. You develop against the latest versions of all packages, and commit your changes for each package. When you are ready for a release, you assemble your image, and generate a snapshot version that can be reloaded later.
Here is an example of how it can work to take a snapshot of a development version: Snapshotcello new configurationClass: ConfigurationOfMoose; configurationVersion: #development; publishVersion: '4.8-snapshot'
You can find more details here: http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-rea...
You can get the code at: Gofer new smalltalkhubUser: 'girba' project: 'Snapshotcello'; package: 'ConfigurationOfSnapshotcello'; load. (Smalltalk globals at: #ConfigurationOfSnapshotcello) loadDevelopment
Cheers, Doru
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Stef, I haven't completely wrapped my brain around what SnapshotCello does so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:). However, I don't like the fact that you end up sending a non-spec message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit. With that said it _is_ performing a useful function ... I have recently come up with an approach to addressing the method literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this "approved approach" when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox... Dale [1] http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html ----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: "Moose-related development" <moose-dev@iam.unibe.ch> | Cc: "Any question about pharo is welcome" <pharo-users@lists.pharo.org>, "Pharo Development List" | <pharo-dev@lists.pharo.org> | Sent: Tuesday, July 23, 2013 2:17:50 PM | Subject: [Moose-dev] Re: [ann] snapshotcello | | Nice to see SnapshotCello coming to live. May be it should be | integrated to Metacello. | Because everybody may need this cool feature. | | Stef | | On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor@tudorgirba.com> | wrote: | | > Hi, | > | > Stef and I developed Snapshotcello, a little utility that enables | > you to freeze a snapshot of a given configuration based on what is | > already loaded in your current image. | > | > The idea is simple. You develop against the latest versions of all | > packages, and commit your changes for each package. When you are | > ready for a release, you assemble your image, and generate a | > snapshot version that can be reloaded later. | > | > Here is an example of how it can work to take a snapshot of a | > development version: | > Snapshotcello new | > configurationClass: ConfigurationOfMoose; | > configurationVersion: #development; | > publishVersion: '4.8-snapshot' | > | > You can find more details here: | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-rea... | > | > You can get the code at: | > Gofer new | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; | > package: 'ConfigurationOfSnapshotcello'; | > load. | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) | > loadDevelopment | > | > Cheers, | > Doru | > | > -- | > www.tudorgirba.com | > | > "Every successful trip needs a suitable vehicle." | > | > | > | > | > | > _______________________________________________ | > Moose-dev mailing list | > Moose-dev@iam.unibe.ch | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | | _______________________________________________ | Moose-dev mailing list | Moose-dev@iam.unibe.ch | https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Stef,
I haven't completely wrapped my brain around what SnapshotCello does so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:).
However, I don't like the fact that you end up sending a non-spec message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit.
Indeed. May be in the future we could recreate a simple compliant spec driven method by interpreting the existing configuration trees but this requires some work.
With that said it _is_ performing a useful function ...
I have recently come up with an approach to addressing the method literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this "approved approach" when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox...
Dale
[1] http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html ----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: "Moose-related development" <moose-dev@iam.unibe.ch> | Cc: "Any question about pharo is welcome" <pharo-users@lists.pharo.org>, "Pharo Development List" | <pharo-dev@lists.pharo.org> | Sent: Tuesday, July 23, 2013 2:17:50 PM | Subject: [Moose-dev] Re: [ann] snapshotcello | | Nice to see SnapshotCello coming to live. May be it should be | integrated to Metacello. | Because everybody may need this cool feature. | | Stef | | On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor@tudorgirba.com> | wrote: | | > Hi, | > | > Stef and I developed Snapshotcello, a little utility that enables | > you to freeze a snapshot of a given configuration based on what is | > already loaded in your current image. | > | > The idea is simple. You develop against the latest versions of all | > packages, and commit your changes for each package. When you are | > ready for a release, you assemble your image, and generate a | > snapshot version that can be reloaded later. | > | > Here is an example of how it can work to take a snapshot of a | > development version: | > Snapshotcello new | > configurationClass: ConfigurationOfMoose; | > configurationVersion: #development; | > publishVersion: '4.8-snapshot' | > | > You can find more details here: | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-rea... | > | > You can get the code at: | > Gofer new | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; | > package: 'ConfigurationOfSnapshotcello'; | > load. | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) | > loadDevelopment | > | > Cheers, | > Doru | > | > -- | > www.tudorgirba.com | > | > "Every successful trip needs a suitable vehicle." | > | > | > | > | > | > _______________________________________________ | > Moose-dev mailing list | > Moose-dev@iam.unibe.ch | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | | _______________________________________________ | Moose-dev mailing list | Moose-dev@iam.unibe.ch | https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Hi, On Jul 24, 2013, at 8:48 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Stef,
I haven't completely wrapped my brain around what SnapshotCello does so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:).
However, I don't like the fact that you end up sending a non-spec message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit. Indeed. May be in the future we could recreate a simple compliant spec driven method by interpreting the existing configuration trees but this requires some work.
I do not understand this point. What do you mean by "interpreting the configuration trees"? Doru
With that said it _is_ performing a useful function ...
I have recently come up with an approach to addressing the method literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this "approved approach" when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox...
Dale
[1] http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html ----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: "Moose-related development" <moose-dev@iam.unibe.ch> | Cc: "Any question about pharo is welcome" <pharo-users@lists.pharo.org>, "Pharo Development List" | <pharo-dev@lists.pharo.org> | Sent: Tuesday, July 23, 2013 2:17:50 PM | Subject: [Moose-dev] Re: [ann] snapshotcello | | Nice to see SnapshotCello coming to live. May be it should be | integrated to Metacello. | Because everybody may need this cool feature. | | Stef | | On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor@tudorgirba.com> | wrote: | | > Hi, | > | > Stef and I developed Snapshotcello, a little utility that enables | > you to freeze a snapshot of a given configuration based on what is | > already loaded in your current image. | > | > The idea is simple. You develop against the latest versions of all | > packages, and commit your changes for each package. When you are | > ready for a release, you assemble your image, and generate a | > snapshot version that can be reloaded later. | > | > Here is an example of how it can work to take a snapshot of a | > development version: | > Snapshotcello new | > configurationClass: ConfigurationOfMoose; | > configurationVersion: #development; | > publishVersion: '4.8-snapshot' | > | > You can find more details here: | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-rea... | > | > You can get the code at: | > Gofer new | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; | > package: 'ConfigurationOfSnapshotcello'; | > load. | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) | > loadDevelopment | > | > Cheers, | > Doru | > | > -- | > www.tudorgirba.com | > | > "Every successful trip needs a suitable vehicle." | > | > | > | > | > | > _______________________________________________ | > Moose-dev mailing list | > Moose-dev@iam.unibe.ch | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | | _______________________________________________ | Moose-dev mailing list | Moose-dev@iam.unibe.ch | https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."
On Jul 24, 2013, at 9:11 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Jul 24, 2013, at 8:48 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Stef,
I haven't completely wrapped my brain around what SnapshotCello does so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:).
However, I don't like the fact that you end up sending a non-spec message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit. Indeed. May be in the future we could recreate a simple compliant spec driven method by interpreting the existing configuration trees but this requires some work.
I do not understand this point. What do you mean by "interpreting the configuration trees"?
I mean going over the configurations with dependencies to recreate the tree structure but with versions. May be this is not needed because for versions we do not need dependencies so just group them per configurations.
Doru
With that said it _is_ performing a useful function ...
I have recently come up with an approach to addressing the method literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this "approved approach" when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox...
Dale
[1] http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html ----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: "Moose-related development" <moose-dev@iam.unibe.ch> | Cc: "Any question about pharo is welcome" <pharo-users@lists.pharo.org>, "Pharo Development List" | <pharo-dev@lists.pharo.org> | Sent: Tuesday, July 23, 2013 2:17:50 PM | Subject: [Moose-dev] Re: [ann] snapshotcello | | Nice to see SnapshotCello coming to live. May be it should be | integrated to Metacello. | Because everybody may need this cool feature. | | Stef | | On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor@tudorgirba.com> | wrote: | | > Hi, | > | > Stef and I developed Snapshotcello, a little utility that enables | > you to freeze a snapshot of a given configuration based on what is | > already loaded in your current image. | > | > The idea is simple. You develop against the latest versions of all | > packages, and commit your changes for each package. When you are | > ready for a release, you assemble your image, and generate a | > snapshot version that can be reloaded later. | > | > Here is an example of how it can work to take a snapshot of a | > development version: | > Snapshotcello new | > configurationClass: ConfigurationOfMoose; | > configurationVersion: #development; | > publishVersion: '4.8-snapshot' | > | > You can find more details here: | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-rea... | > | > You can get the code at: | > Gofer new | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; | > package: 'ConfigurationOfSnapshotcello'; | > load. | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) | > loadDevelopment | > | > Cheers, | > Doru | > | > -- | > www.tudorgirba.com | > | > "Every successful trip needs a suitable vehicle." | > | > | > | > | > | > _______________________________________________ | > Moose-dev mailing list | > Moose-dev@iam.unibe.ch | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | | _______________________________________________ | Moose-dev mailing list | Moose-dev@iam.unibe.ch | https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
Hi Doru, Stef, May I ask what the difference is with the version generation and updating methods found in MetacelloToolbox ? I want to understand, because I am currently using these of MetacelloToolbox to do the things you describe. Cheers! Johan On 24 Jul 2013, at 09:52, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jul 24, 2013, at 9:11 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Jul 24, 2013, at 8:48 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Stef,
I haven't completely wrapped my brain around what SnapshotCello does so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:).
However, I don't like the fact that you end up sending a non-spec message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit. Indeed. May be in the future we could recreate a simple compliant spec driven method by interpreting the existing configuration trees but this requires some work.
I do not understand this point. What do you mean by "interpreting the configuration trees"?
I mean going over the configurations with dependencies to recreate the tree structure but with versions. May be this is not needed because for versions we do not need dependencies so just group them per configurations.
Doru
With that said it _is_ performing a useful function ...
I have recently come up with an approach to addressing the method literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this "approved approach" when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox...
Dale
[1] http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html ----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: "Moose-related development" <moose-dev@iam.unibe.ch> | Cc: "Any question about pharo is welcome" <pharo-users@lists.pharo.org>, "Pharo Development List" | <pharo-dev@lists.pharo.org> | Sent: Tuesday, July 23, 2013 2:17:50 PM | Subject: [Moose-dev] Re: [ann] snapshotcello | | Nice to see SnapshotCello coming to live. May be it should be | integrated to Metacello. | Because everybody may need this cool feature. | | Stef | | On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor@tudorgirba.com> | wrote: | | > Hi, | > | > Stef and I developed Snapshotcello, a little utility that enables | > you to freeze a snapshot of a given configuration based on what is | > already loaded in your current image. | > | > The idea is simple. You develop against the latest versions of all | > packages, and commit your changes for each package. When you are | > ready for a release, you assemble your image, and generate a | > snapshot version that can be reloaded later. | > | > Here is an example of how it can work to take a snapshot of a | > development version: | > Snapshotcello new | > configurationClass: ConfigurationOfMoose; | > configurationVersion: #development; | > publishVersion: '4.8-snapshot' | > | > You can find more details here: | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-rea... | > | > You can get the code at: | > Gofer new | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; | > package: 'ConfigurationOfSnapshotcello'; | > load. | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) | > loadDevelopment | > | > Cheers, | > Doru | > | > -- | > www.tudorgirba.com | > | > "Every successful trip needs a suitable vehicle." | > | > | > | > | > | > _______________________________________________ | > Moose-dev mailing list | > Moose-dev@iam.unibe.ch | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | | _______________________________________________ | Moose-dev mailing list | Moose-dev@iam.unibe.ch | https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
Perhaps I missed something in the toolbox, but as far as I know you cannot create a version of a configuration that is composed of multiple sub-projects nested multiple levels deep. Could you describe the way you are using the Metacello Toolbox? Doru On Wed, Jul 24, 2013 at 10:39 AM, Johan Brichau <johan@inceptive.be> wrote:
Hi Doru, Stef,
May I ask what the difference is with the version generation and updating methods found in MetacelloToolbox ? I want to understand, because I am currently using these of MetacelloToolbox to do the things you describe.
Cheers! Johan
On 24 Jul 2013, at 09:52, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jul 24, 2013, at 9:11 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Jul 24, 2013, at 8:48 AM, Stéphane Ducasse <
stephane.ducasse@inria.fr> wrote:
On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs <
dale.henrichs@gemtalksystems.com> wrote:
Stef,
I haven't completely wrapped my brain around what SnapshotCello does
so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:).
However, I don't like the fact that you end up sending a non-spec
message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit. Indeed. May be in the future we could recreate a simple compliant spec driven method by interpreting the existing configuration trees but this requires some work.
I do not understand this point. What do you mean by "interpreting the configuration trees"?
I mean going over the configurations with dependencies to recreate the tree structure but with versions. May be this is not needed because for versions we do not need dependencies so just group them per configurations.
Doru
With that said it _is_ performing a useful function ...
I have recently come up with an approach to addressing the method
literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this "approved approach" when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox...
Dale
[1]
http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html
----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: "Moose-related development" <moose-dev@iam.unibe.ch> | Cc: "Any question about pharo is welcome" < pharo-users@lists.pharo.org>, "Pharo Development List" | <pharo-dev@lists.pharo.org> | Sent: Tuesday, July 23, 2013 2:17:50 PM | Subject: [Moose-dev] Re: [ann] snapshotcello | | Nice to see SnapshotCello coming to live. May be it should be | integrated to Metacello. | Because everybody may need this cool feature. | | Stef | | On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor@tudorgirba.com> | wrote: | | > Hi, | > | > Stef and I developed Snapshotcello, a little utility that enables | > you to freeze a snapshot of a given configuration based on what is | > already loaded in your current image. | > | > The idea is simple. You develop against the latest versions of all | > packages, and commit your changes for each package. When you are | > ready for a release, you assemble your image, and generate a | > snapshot version that can be reloaded later. | > | > Here is an example of how it can work to take a snapshot of a | > development version: | > Snapshotcello new | > configurationClass: ConfigurationOfMoose; | > configurationVersion: #development; | > publishVersion: '4.8-snapshot' | > | > You can find more details here: | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-rea... | > | > You can get the code at: | > Gofer new | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; | > package: 'ConfigurationOfSnapshotcello'; | > load. | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) | > loadDevelopment | > | > Cheers, | > Doru | > | > -- | > www.tudorgirba.com | > | > "Every successful trip needs a suitable vehicle." | > | > | > | > | > | > _______________________________________________ | > Moose-dev mailing list | > Moose-dev@iam.unibe.ch | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | | _______________________________________________ | Moose-dev mailing list | Moose-dev@iam.unibe.ch | https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
-- www.tudorgirba.com "Every thing has its own flow"
Doru, What do you understand with 'levels'? Is it referenced projects? Perhaps this is the difference I did not immediately extract from your description. Re-reading it with this focus makes the difference clear I think. My use of the toolbox is indeed to generate or update a version for a single project where all 'nested' projects are referenced by project version. As I understand it, the snapshot version is a 'flattened' version containing all packages? I think I get it now. thanks Johan On 24 Jul 2013, at 12:45, Tudor Girba <tudor@tudorgirba.com> wrote:
Perhaps I missed something in the toolbox, but as far as I know you cannot create a version of a configuration that is composed of multiple sub-projects nested multiple levels deep.
Could you describe the way you are using the Metacello Toolbox?
Doru
On Wed, Jul 24, 2013 at 10:39 AM, Johan Brichau <johan@inceptive.be> wrote: Hi Doru, Stef,
May I ask what the difference is with the version generation and updating methods found in MetacelloToolbox ? I want to understand, because I am currently using these of MetacelloToolbox to do the things you describe.
Cheers! Johan
On 24 Jul 2013, at 09:52, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jul 24, 2013, at 9:11 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Jul 24, 2013, at 8:48 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Stef,
I haven't completely wrapped my brain around what SnapshotCello does so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:).
However, I don't like the fact that you end up sending a non-spec message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit. Indeed. May be in the future we could recreate a simple compliant spec driven method by interpreting the existing configuration trees but this requires some work.
I do not understand this point. What do you mean by "interpreting the configuration trees"?
I mean going over the configurations with dependencies to recreate the tree structure but with versions. May be this is not needed because for versions we do not need dependencies so just group them per configurations.
Doru
With that said it _is_ performing a useful function ...
I have recently come up with an approach to addressing the method literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this "approved approach" when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox...
Dale
[1] http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html ----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: "Moose-related development" <moose-dev@iam.unibe.ch> | Cc: "Any question about pharo is welcome" <pharo-users@lists.pharo.org>, "Pharo Development List" | <pharo-dev@lists.pharo.org> | Sent: Tuesday, July 23, 2013 2:17:50 PM | Subject: [Moose-dev] Re: [ann] snapshotcello | | Nice to see SnapshotCello coming to live. May be it should be | integrated to Metacello. | Because everybody may need this cool feature. | | Stef | | On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor@tudorgirba.com> | wrote: | | > Hi, | > | > Stef and I developed Snapshotcello, a little utility that enables | > you to freeze a snapshot of a given configuration based on what is | > already loaded in your current image. | > | > The idea is simple. You develop against the latest versions of all | > packages, and commit your changes for each package. When you are | > ready for a release, you assemble your image, and generate a | > snapshot version that can be reloaded later. | > | > Here is an example of how it can work to take a snapshot of a | > development version: | > Snapshotcello new | > configurationClass: ConfigurationOfMoose; | > configurationVersion: #development; | > publishVersion: '4.8-snapshot' | > | > You can find more details here: | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-rea... | > | > You can get the code at: | > Gofer new | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; | > package: 'ConfigurationOfSnapshotcello'; | > load. | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) | > loadDevelopment | > | > Cheers, | > Doru | > | > -- | > www.tudorgirba.com | > | > "Every successful trip needs a suitable vehicle." | > | > | > | > | > | > _______________________________________________ | > Moose-dev mailing list | > Moose-dev@iam.unibe.ch | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | | _______________________________________________ | Moose-dev mailing list | Moose-dev@iam.unibe.ch | https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
-- www.tudorgirba.com
"Every thing has its own flow"
Hi, On Jul 24, 2013, at 5:25 PM, Johan Brichau <johan@inceptive.be> wrote:
Doru,
What do you understand with 'levels'? Is it referenced projects?
Yes. Nested projects, each being under development :)
Perhaps this is the difference I did not immediately extract from your description. Re-reading it with this focus makes the difference clear I think.
My use of the toolbox is indeed to generate or update a version for a single project where all 'nested' projects are referenced by project version. As I understand it, the snapshot version is a 'flattened' version containing all packages?
Yes. My end goal would be to be able to create automatic transitive versioning of all nested configurations, but this requires some more work, and likely some extension at the level of Metacello. So, until this happens, we now have the option of snapshotting all packages. The cool thing is that if you have something like: ConfigurationOfMoose depends on ConfigurationOfGlamour then in the list of snapshotted packages, you will also get the version of ConfigurationOfGlamour. Thus, essentially, you obtain the same thing as if you would load nested configurations. The only problem is that because we lose configuration nesting information, Metacello is unable to resolve possible diamond conflicts. For example, suppose you have a project that depends on a certain version X of Glamour, but also would like to load the whole Moose that loads version Y of Glamour. If you use normal configurations, Metacello should be able to detect the conflict, but if you only have flattened versions, you will likely not detect the conflict so easily. In any case, I think this is acceptable at the moment. Cheers, Doru
I think I get it now. thanks
Johan
On 24 Jul 2013, at 12:45, Tudor Girba <tudor@tudorgirba.com> wrote:
Perhaps I missed something in the toolbox, but as far as I know you cannot create a version of a configuration that is composed of multiple sub-projects nested multiple levels deep.
Could you describe the way you are using the Metacello Toolbox?
Doru
On Wed, Jul 24, 2013 at 10:39 AM, Johan Brichau <johan@inceptive.be> wrote: Hi Doru, Stef,
May I ask what the difference is with the version generation and updating methods found in MetacelloToolbox ? I want to understand, because I am currently using these of MetacelloToolbox to do the things you describe.
Cheers! Johan
On 24 Jul 2013, at 09:52, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jul 24, 2013, at 9:11 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On Jul 24, 2013, at 8:48 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Stef,
I haven't completely wrapped my brain around what SnapshotCello does so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:).
However, I don't like the fact that you end up sending a non-spec message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit. Indeed. May be in the future we could recreate a simple compliant spec driven method by interpreting the existing configuration trees but this requires some work.
I do not understand this point. What do you mean by "interpreting the configuration trees"?
I mean going over the configurations with dependencies to recreate the tree structure but with versions. May be this is not needed because for versions we do not need dependencies so just group them per configurations.
Doru
With that said it _is_ performing a useful function ...
I have recently come up with an approach to addressing the method literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this "approved approach" when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox...
Dale
[1] http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html ----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: "Moose-related development" <moose-dev@iam.unibe.ch> | Cc: "Any question about pharo is welcome" <pharo-users@lists.pharo.org>, "Pharo Development List" | <pharo-dev@lists.pharo.org> | Sent: Tuesday, July 23, 2013 2:17:50 PM | Subject: [Moose-dev] Re: [ann] snapshotcello | | Nice to see SnapshotCello coming to live. May be it should be | integrated to Metacello. | Because everybody may need this cool feature. | | Stef | | On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor@tudorgirba.com> | wrote: | | > Hi, | > | > Stef and I developed Snapshotcello, a little utility that enables | > you to freeze a snapshot of a given configuration based on what is | > already loaded in your current image. | > | > The idea is simple. You develop against the latest versions of all | > packages, and commit your changes for each package. When you are | > ready for a release, you assemble your image, and generate a | > snapshot version that can be reloaded later. | > | > Here is an example of how it can work to take a snapshot of a | > development version: | > Snapshotcello new | > configurationClass: ConfigurationOfMoose; | > configurationVersion: #development; | > publishVersion: '4.8-snapshot' | > | > You can find more details here: | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-rea... | > | > You can get the code at: | > Gofer new | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; | > package: 'ConfigurationOfSnapshotcello'; | > load. | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) | > loadDevelopment | > | > Cheers, | > Doru | > | > -- | > www.tudorgirba.com | > | > "Every successful trip needs a suitable vehicle." | > | > | > | > | > | > _______________________________________________ | > Moose-dev mailing list | > Moose-dev@iam.unibe.ch | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | | _______________________________________________ | Moose-dev mailing list | Moose-dev@iam.unibe.ch | https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one."
Doru, Are you going to be at ESUG this year? I think there are some features of the Metacello Preview that can be of a great help to your Moose development and I think you and I need to spend time discussing the ins and outs in detail ... I have also done a fair amount or work writing tools for tODE that manipulate sets of configurations using the MetacelloToolBox (Metacello Preview version), so perhaps your goal of "automatic transitive versioning of all nested configurations" is not as far away as you think. And again, I think some deep discussions at a whiteboard and some pair programming is probably the most efficient... Dale ----- Original Message ----- | From: "Tudor Girba" <tudor@tudorgirba.com> | To: "Pharo Development List" <pharo-dev@lists.pharo.org> | Sent: Wednesday, July 24, 2013 11:24:20 AM | Subject: Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] snapshotcello | | Hi, | | On Jul 24, 2013, at 5:25 PM, Johan Brichau <johan@inceptive.be> | wrote: | | > Doru, | > | > What do you understand with 'levels'? Is it referenced projects? | | Yes. Nested projects, each being under development :) | | > Perhaps this is the difference I did not immediately extract from | > your description. Re-reading it with this focus makes the | > difference clear I think. | > | > My use of the toolbox is indeed to generate or update a version for | > a single project where all 'nested' projects are referenced by | > project version. As I understand it, the snapshot version is a | > 'flattened' version containing all packages? | | Yes. | | My end goal would be to be able to create automatic transitive | versioning of all nested configurations, but this requires some more | work, and likely some extension at the level of Metacello. So, until | this happens, we now have the option of snapshotting all packages. | | The cool thing is that if you have something like: | ConfigurationOfMoose depends on ConfigurationOfGlamour | | then in the list of snapshotted packages, you will also get the | version of ConfigurationOfGlamour. Thus, essentially, you obtain the | same thing as if you would load nested configurations. | | The only problem is that because we lose configuration nesting | information, Metacello is unable to resolve possible diamond | conflicts. For example, suppose you have a project that depends on a | certain version X of Glamour, but also would like to load the whole | Moose that loads version Y of Glamour. If you use normal | configurations, Metacello should be able to detect the conflict, but | if you only have flattened versions, you will likely not detect the | conflict so easily. In any case, I think this is acceptable at the | moment. | | Cheers, | Doru | | | | > I think I get it now. thanks | > | > Johan | > | > On 24 Jul 2013, at 12:45, Tudor Girba <tudor@tudorgirba.com> wrote: | > | >> Perhaps I missed something in the toolbox, but as far as I know | >> you cannot create a version of a configuration that is composed | >> of multiple sub-projects nested multiple levels deep. | >> | >> Could you describe the way you are using the Metacello Toolbox? | >> | >> Doru | >> | >> | >> On Wed, Jul 24, 2013 at 10:39 AM, Johan Brichau | >> <johan@inceptive.be> wrote: | >> Hi Doru, Stef, | >> | >> May I ask what the difference is with the version generation and | >> updating methods found in MetacelloToolbox ? I want to | >> understand, because I am currently using these of | >> MetacelloToolbox to do the things you describe. | >> | >> Cheers! | >> Johan | >> | >> On 24 Jul 2013, at 09:52, Stéphane Ducasse | >> <stephane.ducasse@inria.fr> wrote: | >> | >>> | >>> On Jul 24, 2013, at 9:11 AM, Tudor Girba <tudor@tudorgirba.com> | >>> wrote: | >>> | >>>> Hi, | >>>> | >>>> On Jul 24, 2013, at 8:48 AM, Stéphane Ducasse | >>>> <stephane.ducasse@inria.fr> wrote: | >>>> | >>>>> | >>>>> On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs | >>>>> <dale.henrichs@gemtalksystems.com> wrote: | >>>>> | >>>>>> Stef, | >>>>>> | >>>>>> I haven't completely wrapped my brain around what | >>>>>> SnapshotCello does so I don't have an informed opinion ... | >>>>>> the fact that you found a need to invent SnapshotCello does | >>>>>> speak volumes to the fact that there is a need that is going | >>>>>> unmet:). | >>>>>> | >>>>>> However, I don't like the fact that you end up sending a | >>>>>> non-spec message to make this work (#populateSpec:with:). | >>>>>> Tools like Versioner will not be able to rewrite a method | >>>>>> like this correctly so it is a less than satisfactory | >>>>>> workaround to the method literal limit. | >>>>> Indeed. May be in the future we could recreate a simple | >>>>> compliant spec driven method by interpreting the | >>>>> existing configuration trees but this requires some work. | >>>> | >>>> I do not understand this point. What do you mean by | >>>> "interpreting the configuration trees"? | >>> | >>> I mean going over the configurations with dependencies to | >>> recreate the tree structure but with versions. | >>> May be this is not needed because for versions we do not need | >>> dependencies so just group them per configurations. | >>> | >>>> | >>>> Doru | >>>> | >>>>>> | >>>>>> With that said it _is_ performing a useful function ... | >>>>>> | >>>>>> I have recently come up with an approach to addressing the | >>>>>> method literal limit from a slightly different angle and I | >>>>>> would assume that SnapshotCello could be recast to use this | >>>>>> "approved approach" when the new techinique becomes | >>>>>> available. At that time it would make sense to roll the | >>>>>> SnapshotCello funtionality into the MetacelloToolBox... | >>>>>> | >>>>>> Dale | >>>>>> | >>>>>> [1] | >>>>>> http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html | >>>>>> ----- Original Message ----- | >>>>>> | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | >>>>>> | To: "Moose-related development" <moose-dev@iam.unibe.ch> | >>>>>> | Cc: "Any question about pharo is welcome" | >>>>>> | <pharo-users@lists.pharo.org>, "Pharo Development List" | >>>>>> | <pharo-dev@lists.pharo.org> | >>>>>> | Sent: Tuesday, July 23, 2013 2:17:50 PM | >>>>>> | Subject: [Moose-dev] Re: [ann] snapshotcello | >>>>>> | | >>>>>> | Nice to see SnapshotCello coming to live. May be it should | >>>>>> | be | >>>>>> | integrated to Metacello. | >>>>>> | Because everybody may need this cool feature. | >>>>>> | | >>>>>> | Stef | >>>>>> | | >>>>>> | On Jul 23, 2013, at 10:43 PM, Tudor Girba | >>>>>> | <tudor@tudorgirba.com> | >>>>>> | wrote: | >>>>>> | | >>>>>> | > Hi, | >>>>>> | > | >>>>>> | > Stef and I developed Snapshotcello, a little utility that | >>>>>> | > enables | >>>>>> | > you to freeze a snapshot of a given configuration based on | >>>>>> | > what is | >>>>>> | > already loaded in your current image. | >>>>>> | > | >>>>>> | > The idea is simple. You develop against the latest | >>>>>> | > versions of all | >>>>>> | > packages, and commit your changes for each package. When | >>>>>> | > you are | >>>>>> | > ready for a release, you assemble your image, and generate | >>>>>> | > a | >>>>>> | > snapshot version that can be reloaded later. | >>>>>> | > | >>>>>> | > Here is an example of how it can work to take a snapshot | >>>>>> | > of a | >>>>>> | > development version: | >>>>>> | > Snapshotcello new | >>>>>> | > configurationClass: ConfigurationOfMoose; | >>>>>> | > configurationVersion: #development; | >>>>>> | > publishVersion: '4.8-snapshot' | >>>>>> | > | >>>>>> | > You can find more details here: | >>>>>> | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-rea... | >>>>>> | > | >>>>>> | > You can get the code at: | >>>>>> | > Gofer new | >>>>>> | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; | >>>>>> | > package: 'ConfigurationOfSnapshotcello'; | >>>>>> | > load. | >>>>>> | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) | >>>>>> | > loadDevelopment | >>>>>> | > | >>>>>> | > Cheers, | >>>>>> | > Doru | >>>>>> | > | >>>>>> | > -- | >>>>>> | > www.tudorgirba.com | >>>>>> | > | >>>>>> | > "Every successful trip needs a suitable vehicle." | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > _______________________________________________ | >>>>>> | > Moose-dev mailing list | >>>>>> | > Moose-dev@iam.unibe.ch | >>>>>> | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev | >>>>>> | | >>>>>> | | >>>>>> | _______________________________________________ | >>>>>> | Moose-dev mailing list | >>>>>> | Moose-dev@iam.unibe.ch | >>>>>> | https://www.iam.unibe.ch/mailman/listinfo/moose-dev | >>>>>> | | >>>>> | >>>>> | >>>>> _______________________________________________ | >>>>> Moose-dev mailing list | >>>>> Moose-dev@iam.unibe.ch | >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev | >>>> | >>>> -- | >>>> www.tudorgirba.com | >>>> | >>>> "From an abstract enough point of view, any two things are | >>>> similar." | >>> | >>> | >> | >> | >> | >> | >> -- | >> www.tudorgirba.com | >> | >> "Every thing has its own flow" | > | > | | -- | www.tudorgirba.com | | "Every now and then stop and ask yourself if the war you're fighting | is the right one." | | | | |
Hi dale do you plan to write a visitor on metacello spec? Stef On Jul 24, 2013, at 9:38 PM, Dale K. Henrichs <dale.henrichs@gemtalksystems.com> wrote:
Doru,
Are you going to be at ESUG this year?
I think there are some features of the Metacello Preview that can be of a great help to your Moose development and I think you and I need to spend time discussing the ins and outs in detail ...
I have also done a fair amount or work writing tools for tODE that manipulate sets of configurations using the MetacelloToolBox (Metacello Preview version), so perhaps your goal of "automatic transitive versioning of all nested configurations" is not as far away as you think. And again, I think some deep discussions at a whiteboard and some pair programming is probably the most efficient...
Dale
----- Original Message ----- | From: "Tudor Girba" <tudor@tudorgirba.com> | To: "Pharo Development List" <pharo-dev@lists.pharo.org> | Sent: Wednesday, July 24, 2013 11:24:20 AM | Subject: Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] snapshotcello | | Hi, | | On Jul 24, 2013, at 5:25 PM, Johan Brichau <johan@inceptive.be> | wrote: | | > Doru, | > | > What do you understand with 'levels'? Is it referenced projects? | | Yes. Nested projects, each being under development :) | | > Perhaps this is the difference I did not immediately extract from | > your description. Re-reading it with this focus makes the | > difference clear I think. | > | > My use of the toolbox is indeed to generate or update a version for | > a single project where all 'nested' projects are referenced by | > project version. As I understand it, the snapshot version is a | > 'flattened' version containing all packages? | | Yes. | | My end goal would be to be able to create automatic transitive | versioning of all nested configurations, but this requires some more | work, and likely some extension at the level of Metacello. So, until | this happens, we now have the option of snapshotting all packages. | | The cool thing is that if you have something like: | ConfigurationOfMoose depends on ConfigurationOfGlamour | | then in the list of snapshotted packages, you will also get the | version of ConfigurationOfGlamour. Thus, essentially, you obtain the | same thing as if you would load nested configurations. | | The only problem is that because we lose configuration nesting | information, Metacello is unable to resolve possible diamond | conflicts. For example, suppose you have a project that depends on a | certain version X of Glamour, but also would like to load the whole | Moose that loads version Y of Glamour. If you use normal | configurations, Metacello should be able to detect the conflict, but | if you only have flattened versions, you will likely not detect the | conflict so easily. In any case, I think this is acceptable at the | moment. | | Cheers, | Doru | | | | > I think I get it now. thanks | > | > Johan | > | > On 24 Jul 2013, at 12:45, Tudor Girba <tudor@tudorgirba.com> wrote: | > | >> Perhaps I missed something in the toolbox, but as far as I know | >> you cannot create a version of a configuration that is composed | >> of multiple sub-projects nested multiple levels deep. | >> | >> Could you describe the way you are using the Metacello Toolbox? | >> | >> Doru | >> | >> | >> On Wed, Jul 24, 2013 at 10:39 AM, Johan Brichau | >> <johan@inceptive.be> wrote: | >> Hi Doru, Stef, | >> | >> May I ask what the difference is with the version generation and | >> updating methods found in MetacelloToolbox ? I want to | >> understand, because I am currently using these of | >> MetacelloToolbox to do the things you describe. | >> | >> Cheers! | >> Johan | >> | >> On 24 Jul 2013, at 09:52, Stéphane Ducasse | >> <stephane.ducasse@inria.fr> wrote: | >> | >>> | >>> On Jul 24, 2013, at 9:11 AM, Tudor Girba <tudor@tudorgirba.com> | >>> wrote: | >>> | >>>> Hi, | >>>> | >>>> On Jul 24, 2013, at 8:48 AM, Stéphane Ducasse | >>>> <stephane.ducasse@inria.fr> wrote: | >>>> | >>>>> | >>>>> On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs | >>>>> <dale.henrichs@gemtalksystems.com> wrote: | >>>>> | >>>>>> Stef, | >>>>>> | >>>>>> I haven't completely wrapped my brain around what | >>>>>> SnapshotCello does so I don't have an informed opinion ... | >>>>>> the fact that you found a need to invent SnapshotCello does | >>>>>> speak volumes to the fact that there is a need that is going | >>>>>> unmet:). | >>>>>> | >>>>>> However, I don't like the fact that you end up sending a | >>>>>> non-spec message to make this work (#populateSpec:with:). | >>>>>> Tools like Versioner will not be able to rewrite a method | >>>>>> like this correctly so it is a less than satisfactory | >>>>>> workaround to the method literal limit. | >>>>> Indeed. May be in the future we could recreate a simple | >>>>> compliant spec driven method by interpreting the | >>>>> existing configuration trees but this requires some work. | >>>> | >>>> I do not understand this point. What do you mean by | >>>> "interpreting the configuration trees"? | >>> | >>> I mean going over the configurations with dependencies to | >>> recreate the tree structure but with versions. | >>> May be this is not needed because for versions we do not need | >>> dependencies so just group them per configurations. | >>> | >>>> | >>>> Doru | >>>> | >>>>>> | >>>>>> With that said it _is_ performing a useful function ... | >>>>>> | >>>>>> I have recently come up with an approach to addressing the | >>>>>> method literal limit from a slightly different angle and I | >>>>>> would assume that SnapshotCello could be recast to use this | >>>>>> "approved approach" when the new techinique becomes | >>>>>> available. At that time it would make sense to roll the | >>>>>> SnapshotCello funtionality into the MetacelloToolBox... | >>>>>> | >>>>>> Dale | >>>>>> | >>>>>> [1] | >>>>>> http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html | >>>>>> ----- Original Message ----- | >>>>>> | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | >>>>>> | To: "Moose-related development" <moose-dev@iam.unibe.ch> | >>>>>> | Cc: "Any question about pharo is welcome" | >>>>>> | <pharo-users@lists.pharo.org>, "Pharo Development List" | >>>>>> | <pharo-dev@lists.pharo.org> | >>>>>> | Sent: Tuesday, July 23, 2013 2:17:50 PM | >>>>>> | Subject: [Moose-dev] Re: [ann] snapshotcello | >>>>>> | | >>>>>> | Nice to see SnapshotCello coming to live. May be it should | >>>>>> | be | >>>>>> | integrated to Metacello. | >>>>>> | Because everybody may need this cool feature. | >>>>>> | | >>>>>> | Stef | >>>>>> | | >>>>>> | On Jul 23, 2013, at 10:43 PM, Tudor Girba | >>>>>> | <tudor@tudorgirba.com> | >>>>>> | wrote: | >>>>>> | | >>>>>> | > Hi, | >>>>>> | > | >>>>>> | > Stef and I developed Snapshotcello, a little utility that | >>>>>> | > enables | >>>>>> | > you to freeze a snapshot of a given configuration based on | >>>>>> | > what is | >>>>>> | > already loaded in your current image. | >>>>>> | > | >>>>>> | > The idea is simple. You develop against the latest | >>>>>> | > versions of all | >>>>>> | > packages, and commit your changes for each package. When | >>>>>> | > you are | >>>>>> | > ready for a release, you assemble your image, and generate | >>>>>> | > a | >>>>>> | > snapshot version that can be reloaded later. | >>>>>> | > | >>>>>> | > Here is an example of how it can work to take a snapshot | >>>>>> | > of a | >>>>>> | > development version: | >>>>>> | > Snapshotcello new | >>>>>> | > configurationClass: ConfigurationOfMoose; | >>>>>> | > configurationVersion: #development; | >>>>>> | > publishVersion: '4.8-snapshot' | >>>>>> | > | >>>>>> | > You can find more details here: | >>>>>> | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-rea... | >>>>>> | > | >>>>>> | > You can get the code at: | >>>>>> | > Gofer new | >>>>>> | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; | >>>>>> | > package: 'ConfigurationOfSnapshotcello'; | >>>>>> | > load. | >>>>>> | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) | >>>>>> | > loadDevelopment | >>>>>> | > | >>>>>> | > Cheers, | >>>>>> | > Doru | >>>>>> | > | >>>>>> | > -- | >>>>>> | > www.tudorgirba.com | >>>>>> | > | >>>>>> | > "Every successful trip needs a suitable vehicle." | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > _______________________________________________ | >>>>>> | > Moose-dev mailing list | >>>>>> | > Moose-dev@iam.unibe.ch | >>>>>> | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev | >>>>>> | | >>>>>> | | >>>>>> | _______________________________________________ | >>>>>> | Moose-dev mailing list | >>>>>> | Moose-dev@iam.unibe.ch | >>>>>> | https://www.iam.unibe.ch/mailman/listinfo/moose-dev | >>>>>> | | >>>>> | >>>>> | >>>>> _______________________________________________ | >>>>> Moose-dev mailing list | >>>>> Moose-dev@iam.unibe.ch | >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev | >>>> | >>>> -- | >>>> www.tudorgirba.com | >>>> | >>>> "From an abstract enough point of view, any two things are | >>>> similar." | >>> | >>> | >> | >> | >> | >> | >> -- | >> www.tudorgirba.com | >> | >> "Every thing has its own flow" | > | > | | -- | www.tudorgirba.com | | "Every now and then stop and ask yourself if the war you're fighting | is the right one." | | | | |
This would be so cool :). Doru On Thu, Jul 25, 2013 at 8:47 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Hi dale
do you plan to write a visitor on metacello spec?
Stef
On Jul 24, 2013, at 9:38 PM, Dale K. Henrichs < dale.henrichs@gemtalksystems.com> wrote:
Doru,
Are you going to be at ESUG this year?
I think there are some features of the Metacello Preview that can be of a great help to your Moose development and I think you and I need to spend time discussing the ins and outs in detail ...
I have also done a fair amount or work writing tools for tODE that manipulate sets of configurations using the MetacelloToolBox (Metacello Preview version), so perhaps your goal of "automatic transitive versioning of all nested configurations" is not as far away as you think. And again, I think some deep discussions at a whiteboard and some pair programming is probably the most efficient...
Dale
----- Original Message ----- | From: "Tudor Girba" <tudor@tudorgirba.com> | To: "Pharo Development List" <pharo-dev@lists.pharo.org> | Sent: Wednesday, July 24, 2013 11:24:20 AM | Subject: Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] snapshotcello | | Hi, | | On Jul 24, 2013, at 5:25 PM, Johan Brichau <johan@inceptive.be> | wrote: | | > Doru, | > | > What do you understand with 'levels'? Is it referenced projects? | | Yes. Nested projects, each being under development :) | | > Perhaps this is the difference I did not immediately extract from | > your description. Re-reading it with this focus makes the | > difference clear I think. | > | > My use of the toolbox is indeed to generate or update a version for | > a single project where all 'nested' projects are referenced by | > project version. As I understand it, the snapshot version is a | > 'flattened' version containing all packages? | | Yes. | | My end goal would be to be able to create automatic transitive | versioning of all nested configurations, but this requires some more | work, and likely some extension at the level of Metacello. So, until | this happens, we now have the option of snapshotting all packages. | | The cool thing is that if you have something like: | ConfigurationOfMoose depends on ConfigurationOfGlamour | | then in the list of snapshotted packages, you will also get the | version of ConfigurationOfGlamour. Thus, essentially, you obtain the | same thing as if you would load nested configurations. | | The only problem is that because we lose configuration nesting | information, Metacello is unable to resolve possible diamond | conflicts. For example, suppose you have a project that depends on a | certain version X of Glamour, but also would like to load the whole | Moose that loads version Y of Glamour. If you use normal | configurations, Metacello should be able to detect the conflict, but | if you only have flattened versions, you will likely not detect the | conflict so easily. In any case, I think this is acceptable at the | moment. | | Cheers, | Doru | | | | > I think I get it now. thanks | > | > Johan | > | > On 24 Jul 2013, at 12:45, Tudor Girba <tudor@tudorgirba.com> wrote: | > | >> Perhaps I missed something in the toolbox, but as far as I know | >> you cannot create a version of a configuration that is composed | >> of multiple sub-projects nested multiple levels deep. | >> | >> Could you describe the way you are using the Metacello Toolbox? | >> | >> Doru | >> | >> | >> On Wed, Jul 24, 2013 at 10:39 AM, Johan Brichau | >> <johan@inceptive.be> wrote: | >> Hi Doru, Stef, | >> | >> May I ask what the difference is with the version generation and | >> updating methods found in MetacelloToolbox ? I want to | >> understand, because I am currently using these of | >> MetacelloToolbox to do the things you describe. | >> | >> Cheers! | >> Johan | >> | >> On 24 Jul 2013, at 09:52, Stéphane Ducasse | >> <stephane.ducasse@inria.fr> wrote: | >> | >>> | >>> On Jul 24, 2013, at 9:11 AM, Tudor Girba <tudor@tudorgirba.com> | >>> wrote: | >>> | >>>> Hi, | >>>> | >>>> On Jul 24, 2013, at 8:48 AM, Stéphane Ducasse | >>>> <stephane.ducasse@inria.fr> wrote: | >>>> | >>>>> | >>>>> On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs | >>>>> <dale.henrichs@gemtalksystems.com> wrote: | >>>>> | >>>>>> Stef, | >>>>>> | >>>>>> I haven't completely wrapped my brain around what | >>>>>> SnapshotCello does so I don't have an informed opinion ... | >>>>>> the fact that you found a need to invent SnapshotCello does | >>>>>> speak volumes to the fact that there is a need that is going | >>>>>> unmet:). | >>>>>> | >>>>>> However, I don't like the fact that you end up sending a | >>>>>> non-spec message to make this work (#populateSpec:with:). | >>>>>> Tools like Versioner will not be able to rewrite a method | >>>>>> like this correctly so it is a less than satisfactory | >>>>>> workaround to the method literal limit. | >>>>> Indeed. May be in the future we could recreate a simple | >>>>> compliant spec driven method by interpreting the | >>>>> existing configuration trees but this requires some work. | >>>> | >>>> I do not understand this point. What do you mean by | >>>> "interpreting the configuration trees"? | >>> | >>> I mean going over the configurations with dependencies to | >>> recreate the tree structure but with versions. | >>> May be this is not needed because for versions we do not need | >>> dependencies so just group them per configurations. | >>> | >>>> | >>>> Doru | >>>> | >>>>>> | >>>>>> With that said it _is_ performing a useful function ... | >>>>>> | >>>>>> I have recently come up with an approach to addressing the | >>>>>> method literal limit from a slightly different angle and I | >>>>>> would assume that SnapshotCello could be recast to use this | >>>>>> "approved approach" when the new techinique becomes | >>>>>> available. At that time it would make sense to roll the | >>>>>> SnapshotCello funtionality into the MetacelloToolBox... | >>>>>> | >>>>>> Dale | >>>>>> | >>>>>> [1] | >>>>>> http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html | >>>>>> ----- Original Message ----- | >>>>>> | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | >>>>>> | To: "Moose-related development" <moose-dev@iam.unibe.ch> | >>>>>> | Cc: "Any question about pharo is welcome" | >>>>>> | <pharo-users@lists.pharo.org>, "Pharo Development List" | >>>>>> | <pharo-dev@lists.pharo.org> | >>>>>> | Sent: Tuesday, July 23, 2013 2:17:50 PM | >>>>>> | Subject: [Moose-dev] Re: [ann] snapshotcello | >>>>>> | | >>>>>> | Nice to see SnapshotCello coming to live. May be it should | >>>>>> | be | >>>>>> | integrated to Metacello. | >>>>>> | Because everybody may need this cool feature. | >>>>>> | | >>>>>> | Stef | >>>>>> | | >>>>>> | On Jul 23, 2013, at 10:43 PM, Tudor Girba | >>>>>> | <tudor@tudorgirba.com> | >>>>>> | wrote: | >>>>>> | | >>>>>> | > Hi, | >>>>>> | > | >>>>>> | > Stef and I developed Snapshotcello, a little utility that | >>>>>> | > enables | >>>>>> | > you to freeze a snapshot of a given configuration based on | >>>>>> | > what is | >>>>>> | > already loaded in your current image. | >>>>>> | > | >>>>>> | > The idea is simple. You develop against the latest | >>>>>> | > versions of all | >>>>>> | > packages, and commit your changes for each package. When | >>>>>> | > you are | >>>>>> | > ready for a release, you assemble your image, and generate | >>>>>> | > a | >>>>>> | > snapshot version that can be reloaded later. | >>>>>> | > | >>>>>> | > Here is an example of how it can work to take a snapshot | >>>>>> | > of a | >>>>>> | > development version: | >>>>>> | > Snapshotcello new | >>>>>> | > configurationClass: ConfigurationOfMoose; | >>>>>> | > configurationVersion: #development; | >>>>>> | > publishVersion: '4.8-snapshot' | >>>>>> | > | >>>>>> | > You can find more details here: | >>>>>> | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-rea... | >>>>>> | > | >>>>>> | > You can get the code at: | >>>>>> | > Gofer new | >>>>>> | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; | >>>>>> | > package: 'ConfigurationOfSnapshotcello'; | >>>>>> | > load. | >>>>>> | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) | >>>>>> | > loadDevelopment | >>>>>> | > | >>>>>> | > Cheers, | >>>>>> | > Doru | >>>>>> | > | >>>>>> | > -- | >>>>>> | > www.tudorgirba.com | >>>>>> | > | >>>>>> | > "Every successful trip needs a suitable vehicle." | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > _______________________________________________ | >>>>>> | > Moose-dev mailing list | >>>>>> | > Moose-dev@iam.unibe.ch | >>>>>> | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev | >>>>>> | | >>>>>> | | >>>>>> | _______________________________________________ | >>>>>> | Moose-dev mailing list | >>>>>> | Moose-dev@iam.unibe.ch | >>>>>> | https://www.iam.unibe.ch/mailman/listinfo/moose-dev | >>>>>> | | >>>>> | >>>>> | >>>>> _______________________________________________ | >>>>> Moose-dev mailing list | >>>>> Moose-dev@iam.unibe.ch | >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev | >>>> | >>>> -- | >>>> www.tudorgirba.com | >>>> | >>>> "From an abstract enough point of view, any two things are | >>>> similar." | >>> | >>> | >> | >> | >> | >> | >> -- | >> www.tudorgirba.com | >> | >> "Every thing has its own flow" | > | > | | -- | www.tudorgirba.com | | "Every now and then stop and ask yourself if the war you're fighting | is the right one." | | | | |
-- www.tudorgirba.com "Every thing has its own flow"
Stef, In Metacello there are more than one way to "visit specs": - raw specs - merged specs - specs by section - resolved specs - there are more If you are reasoning about the packages visible for a particular combination of attributes (#common, #pharo, etc.) then you are interested in the 'merged specs'. If you are interested in looking at the individual statements that are composed into the merged specs, then you need to look at the raw specs, again against a particular combination of attributes. If you are editting a spec or interested in extracting the list of all packages referenced independent of attribute, then you need to look at the specs by section ... in which case you have the choice of looking at the raw specs or merged specs for each section visited. You also probably need to control whether or not imports are followed or not. If you are interested in knowing the exact package version and repository that a spec resolves to, then you need to look at resolved specs against a particular combination of attributes. So I guess I need to know a little bit more about what you are thinking when you say "visitor on metacello spec." Dale ----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: "Pharo Development List" <pharo-dev@lists.pharo.org> | Sent: Wednesday, July 24, 2013 11:47:51 PM | Subject: Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] snapshotcello | | Hi dale | | do you plan to write a visitor on metacello spec? | | Stef | | On Jul 24, 2013, at 9:38 PM, Dale K. Henrichs | <dale.henrichs@gemtalksystems.com> wrote: | | > Doru, | > | > Are you going to be at ESUG this year? | > | > I think there are some features of the Metacello Preview that can | > be of a great help to your Moose development and I think you and I | > need to spend time discussing the ins and outs in detail ... | > | > I have also done a fair amount or work writing tools for tODE that | > manipulate sets of configurations using the MetacelloToolBox | > (Metacello Preview version), so perhaps your goal of "automatic | > transitive versioning of all nested configurations" is not as far | > away as you think. And again, I think some deep discussions at a | > whiteboard and some pair programming is probably the most | > efficient... | > | > Dale | > | > ----- Original Message ----- | > | From: "Tudor Girba" <tudor@tudorgirba.com> | > | To: "Pharo Development List" <pharo-dev@lists.pharo.org> | > | Sent: Wednesday, July 24, 2013 11:24:20 AM | > | Subject: Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] | > | snapshotcello | > | | > | Hi, | > | | > | On Jul 24, 2013, at 5:25 PM, Johan Brichau <johan@inceptive.be> | > | wrote: | > | | > | > Doru, | > | > | > | > What do you understand with 'levels'? Is it referenced | > | > projects? | > | | > | Yes. Nested projects, each being under development :) | > | | > | > Perhaps this is the difference I did not immediately extract | > | > from | > | > your description. Re-reading it with this focus makes the | > | > difference clear I think. | > | > | > | > My use of the toolbox is indeed to generate or update a version | > | > for | > | > a single project where all 'nested' projects are referenced by | > | > project version. As I understand it, the snapshot version is a | > | > 'flattened' version containing all packages? | > | | > | Yes. | > | | > | My end goal would be to be able to create automatic transitive | > | versioning of all nested configurations, but this requires some | > | more | > | work, and likely some extension at the level of Metacello. So, | > | until | > | this happens, we now have the option of snapshotting all | > | packages. | > | | > | The cool thing is that if you have something like: | > | ConfigurationOfMoose depends on ConfigurationOfGlamour | > | | > | then in the list of snapshotted packages, you will also get the | > | version of ConfigurationOfGlamour. Thus, essentially, you obtain | > | the | > | same thing as if you would load nested configurations. | > | | > | The only problem is that because we lose configuration nesting | > | information, Metacello is unable to resolve possible diamond | > | conflicts. For example, suppose you have a project that depends | > | on a | > | certain version X of Glamour, but also would like to load the | > | whole | > | Moose that loads version Y of Glamour. If you use normal | > | configurations, Metacello should be able to detect the conflict, | > | but | > | if you only have flattened versions, you will likely not detect | > | the | > | conflict so easily. In any case, I think this is acceptable at | > | the | > | moment. | > | | > | Cheers, | > | Doru | > | | > | | > | | > | > I think I get it now. thanks | > | > | > | > Johan | > | > | > | > On 24 Jul 2013, at 12:45, Tudor Girba <tudor@tudorgirba.com> | > | > wrote: | > | > | > | >> Perhaps I missed something in the toolbox, but as far as I | > | >> know | > | >> you cannot create a version of a configuration that is | > | >> composed | > | >> of multiple sub-projects nested multiple levels deep. | > | >> | > | >> Could you describe the way you are using the Metacello | > | >> Toolbox? | > | >> | > | >> Doru | > | >> | > | >> | > | >> On Wed, Jul 24, 2013 at 10:39 AM, Johan Brichau | > | >> <johan@inceptive.be> wrote: | > | >> Hi Doru, Stef, | > | >> | > | >> May I ask what the difference is with the version generation | > | >> and | > | >> updating methods found in MetacelloToolbox ? I want to | > | >> understand, because I am currently using these of | > | >> MetacelloToolbox to do the things you describe. | > | >> | > | >> Cheers! | > | >> Johan | > | >> | > | >> On 24 Jul 2013, at 09:52, Stéphane Ducasse | > | >> <stephane.ducasse@inria.fr> wrote: | > | >> | > | >>> | > | >>> On Jul 24, 2013, at 9:11 AM, Tudor Girba | > | >>> <tudor@tudorgirba.com> | > | >>> wrote: | > | >>> | > | >>>> Hi, | > | >>>> | > | >>>> On Jul 24, 2013, at 8:48 AM, Stéphane Ducasse | > | >>>> <stephane.ducasse@inria.fr> wrote: | > | >>>> | > | >>>>> | > | >>>>> On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs | > | >>>>> <dale.henrichs@gemtalksystems.com> wrote: | > | >>>>> | > | >>>>>> Stef, | > | >>>>>> | > | >>>>>> I haven't completely wrapped my brain around what | > | >>>>>> SnapshotCello does so I don't have an informed opinion ... | > | >>>>>> the fact that you found a need to invent SnapshotCello | > | >>>>>> does | > | >>>>>> speak volumes to the fact that there is a need that is | > | >>>>>> going | > | >>>>>> unmet:). | > | >>>>>> | > | >>>>>> However, I don't like the fact that you end up sending a | > | >>>>>> non-spec message to make this work (#populateSpec:with:). | > | >>>>>> Tools like Versioner will not be able to rewrite a method | > | >>>>>> like this correctly so it is a less than satisfactory | > | >>>>>> workaround to the method literal limit. | > | >>>>> Indeed. May be in the future we could recreate a simple | > | >>>>> compliant spec driven method by interpreting the | > | >>>>> existing configuration trees but this requires some work. | > | >>>> | > | >>>> I do not understand this point. What do you mean by | > | >>>> "interpreting the configuration trees"? | > | >>> | > | >>> I mean going over the configurations with dependencies to | > | >>> recreate the tree structure but with versions. | > | >>> May be this is not needed because for versions we do not need | > | >>> dependencies so just group them per configurations. | > | >>> | > | >>>> | > | >>>> Doru | > | >>>> | > | >>>>>> | > | >>>>>> With that said it _is_ performing a useful function ... | > | >>>>>> | > | >>>>>> I have recently come up with an approach to addressing the | > | >>>>>> method literal limit from a slightly different angle and I | > | >>>>>> would assume that SnapshotCello could be recast to use | > | >>>>>> this | > | >>>>>> "approved approach" when the new techinique becomes | > | >>>>>> available. At that time it would make sense to roll the | > | >>>>>> SnapshotCello funtionality into the MetacelloToolBox... | > | >>>>>> | > | >>>>>> Dale | > | >>>>>> | > | >>>>>> [1] | > | >>>>>> http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html | > | >>>>>> ----- Original Message ----- | > | >>>>>> | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | > | >>>>>> | To: "Moose-related development" <moose-dev@iam.unibe.ch> | > | >>>>>> | Cc: "Any question about pharo is welcome" | > | >>>>>> | <pharo-users@lists.pharo.org>, "Pharo Development List" | > | >>>>>> | <pharo-dev@lists.pharo.org> | > | >>>>>> | Sent: Tuesday, July 23, 2013 2:17:50 PM | > | >>>>>> | Subject: [Moose-dev] Re: [ann] snapshotcello | > | >>>>>> | | > | >>>>>> | Nice to see SnapshotCello coming to live. May be it | > | >>>>>> | should | > | >>>>>> | be | > | >>>>>> | integrated to Metacello. | > | >>>>>> | Because everybody may need this cool feature. | > | >>>>>> | | > | >>>>>> | Stef | > | >>>>>> | | > | >>>>>> | On Jul 23, 2013, at 10:43 PM, Tudor Girba | > | >>>>>> | <tudor@tudorgirba.com> | > | >>>>>> | wrote: | > | >>>>>> | | > | >>>>>> | > Hi, | > | >>>>>> | > | > | >>>>>> | > Stef and I developed Snapshotcello, a little utility | > | >>>>>> | > that | > | >>>>>> | > enables | > | >>>>>> | > you to freeze a snapshot of a given configuration | > | >>>>>> | > based on | > | >>>>>> | > what is | > | >>>>>> | > already loaded in your current image. | > | >>>>>> | > | > | >>>>>> | > The idea is simple. You develop against the latest | > | >>>>>> | > versions of all | > | >>>>>> | > packages, and commit your changes for each package. | > | >>>>>> | > When | > | >>>>>> | > you are | > | >>>>>> | > ready for a release, you assemble your image, and | > | >>>>>> | > generate | > | >>>>>> | > a | > | >>>>>> | > snapshot version that can be reloaded later. | > | >>>>>> | > | > | >>>>>> | > Here is an example of how it can work to take a | > | >>>>>> | > snapshot | > | >>>>>> | > of a | > | >>>>>> | > development version: | > | >>>>>> | > Snapshotcello new | > | >>>>>> | > configurationClass: ConfigurationOfMoose; | > | >>>>>> | > configurationVersion: #development; | > | >>>>>> | > publishVersion: '4.8-snapshot' | > | >>>>>> | > | > | >>>>>> | > You can find more details here: | > | >>>>>> | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-rea... | > | >>>>>> | > | > | >>>>>> | > You can get the code at: | > | >>>>>> | > Gofer new | > | >>>>>> | > smalltalkhubUser: 'girba' project: | > | >>>>>> | > 'Snapshotcello'; | > | >>>>>> | > package: 'ConfigurationOfSnapshotcello'; | > | >>>>>> | > load. | > | >>>>>> | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) | > | >>>>>> | > loadDevelopment | > | >>>>>> | > | > | >>>>>> | > Cheers, | > | >>>>>> | > Doru | > | >>>>>> | > | > | >>>>>> | > -- | > | >>>>>> | > www.tudorgirba.com | > | >>>>>> | > | > | >>>>>> | > "Every successful trip needs a suitable vehicle." | > | >>>>>> | > | > | >>>>>> | > | > | >>>>>> | > | > | >>>>>> | > | > | >>>>>> | > | > | >>>>>> | > _______________________________________________ | > | >>>>>> | > Moose-dev mailing list | > | >>>>>> | > Moose-dev@iam.unibe.ch | > | >>>>>> | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev | > | >>>>>> | | > | >>>>>> | | > | >>>>>> | _______________________________________________ | > | >>>>>> | Moose-dev mailing list | > | >>>>>> | Moose-dev@iam.unibe.ch | > | >>>>>> | https://www.iam.unibe.ch/mailman/listinfo/moose-dev | > | >>>>>> | | > | >>>>> | > | >>>>> | > | >>>>> _______________________________________________ | > | >>>>> Moose-dev mailing list | > | >>>>> Moose-dev@iam.unibe.ch | > | >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev | > | >>>> | > | >>>> -- | > | >>>> www.tudorgirba.com | > | >>>> | > | >>>> "From an abstract enough point of view, any two things are | > | >>>> similar." | > | >>> | > | >>> | > | >> | > | >> | > | >> | > | >> | > | >> -- | > | >> www.tudorgirba.com | > | >> | > | >> "Every thing has its own flow" | > | > | > | > | > | | > | -- | > | www.tudorgirba.com | > | | > | "Every now and then stop and ask yourself if the war you're | > | fighting | > | is the right one." | > | | > | | > | | > | | > | | > | | |
In Metacello there are more than one way to "visit specs":
- raw specs - merged specs - specs by section - resolved specs - there are more
If you are reasoning about the packages visible for a particular combination of attributes (#common, #pharo, etc.) then you are interested in the 'merged specs'.
If you are interested in looking at the individual statements that are composed into the merged specs, then you need to look at the raw specs, again against a particular combination of attributes.
If you are editting a spec or interested in extracting the list of all packages referenced independent of attribute, then you need to look at the specs by section ... in which case you have the choice of looking at the raw specs or merged specs for each section visited. You also probably need to control whether or not imports are followed or not.
If you are interested in knowing the exact package version and repository that a spec resolves to, then you need to look at resolved specs against a particular combination of attributes.
So I guess I need to know a little bit more about what you are thinking when you say "visitor on metacello spec."
Dale
I see. But when I close my eyes and think about the metacello domain. I see trees of projects baseline, versions packages required packages the fact that the information is merged, resolvedâ¦. should give back trees and I would like to be able to visit these structures so that we can build analysis such as snapcello on top. So probably that a visitor would have to be attached a strategy while navigating. Stef
Unfortunately, I will not be able to join :( Doru On Wed, Jul 24, 2013 at 9:38 PM, Dale K. Henrichs < dale.henrichs@gemtalksystems.com> wrote:
Doru,
Are you going to be at ESUG this year?
I think there are some features of the Metacello Preview that can be of a great help to your Moose development and I think you and I need to spend time discussing the ins and outs in detail ...
I have also done a fair amount or work writing tools for tODE that manipulate sets of configurations using the MetacelloToolBox (Metacello Preview version), so perhaps your goal of "automatic transitive versioning of all nested configurations" is not as far away as you think. And again, I think some deep discussions at a whiteboard and some pair programming is probably the most efficient...
Dale
----- Original Message ----- | From: "Tudor Girba" <tudor@tudorgirba.com> | To: "Pharo Development List" <pharo-dev@lists.pharo.org> | Sent: Wednesday, July 24, 2013 11:24:20 AM | Subject: Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] snapshotcello | | Hi, | | On Jul 24, 2013, at 5:25 PM, Johan Brichau <johan@inceptive.be> | wrote: | | > Doru, | > | > What do you understand with 'levels'? Is it referenced projects? | | Yes. Nested projects, each being under development :) | | > Perhaps this is the difference I did not immediately extract from | > your description. Re-reading it with this focus makes the | > difference clear I think. | > | > My use of the toolbox is indeed to generate or update a version for | > a single project where all 'nested' projects are referenced by | > project version. As I understand it, the snapshot version is a | > 'flattened' version containing all packages? | | Yes. | | My end goal would be to be able to create automatic transitive | versioning of all nested configurations, but this requires some more | work, and likely some extension at the level of Metacello. So, until | this happens, we now have the option of snapshotting all packages. | | The cool thing is that if you have something like: | ConfigurationOfMoose depends on ConfigurationOfGlamour | | then in the list of snapshotted packages, you will also get the | version of ConfigurationOfGlamour. Thus, essentially, you obtain the | same thing as if you would load nested configurations. | | The only problem is that because we lose configuration nesting | information, Metacello is unable to resolve possible diamond | conflicts. For example, suppose you have a project that depends on a | certain version X of Glamour, but also would like to load the whole | Moose that loads version Y of Glamour. If you use normal | configurations, Metacello should be able to detect the conflict, but | if you only have flattened versions, you will likely not detect the | conflict so easily. In any case, I think this is acceptable at the | moment. | | Cheers, | Doru | | | | > I think I get it now. thanks | > | > Johan | > | > On 24 Jul 2013, at 12:45, Tudor Girba <tudor@tudorgirba.com> wrote: | > | >> Perhaps I missed something in the toolbox, but as far as I know | >> you cannot create a version of a configuration that is composed | >> of multiple sub-projects nested multiple levels deep. | >> | >> Could you describe the way you are using the Metacello Toolbox? | >> | >> Doru | >> | >> | >> On Wed, Jul 24, 2013 at 10:39 AM, Johan Brichau | >> <johan@inceptive.be> wrote: | >> Hi Doru, Stef, | >> | >> May I ask what the difference is with the version generation and | >> updating methods found in MetacelloToolbox ? I want to | >> understand, because I am currently using these of | >> MetacelloToolbox to do the things you describe. | >> | >> Cheers! | >> Johan | >> | >> On 24 Jul 2013, at 09:52, Stéphane Ducasse | >> <stephane.ducasse@inria.fr> wrote: | >> | >>> | >>> On Jul 24, 2013, at 9:11 AM, Tudor Girba <tudor@tudorgirba.com> | >>> wrote: | >>> | >>>> Hi, | >>>> | >>>> On Jul 24, 2013, at 8:48 AM, Stéphane Ducasse | >>>> <stephane.ducasse@inria.fr> wrote: | >>>> | >>>>> | >>>>> On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs | >>>>> <dale.henrichs@gemtalksystems.com> wrote: | >>>>> | >>>>>> Stef, | >>>>>> | >>>>>> I haven't completely wrapped my brain around what | >>>>>> SnapshotCello does so I don't have an informed opinion ... | >>>>>> the fact that you found a need to invent SnapshotCello does | >>>>>> speak volumes to the fact that there is a need that is going | >>>>>> unmet:). | >>>>>> | >>>>>> However, I don't like the fact that you end up sending a | >>>>>> non-spec message to make this work (#populateSpec:with:). | >>>>>> Tools like Versioner will not be able to rewrite a method | >>>>>> like this correctly so it is a less than satisfactory | >>>>>> workaround to the method literal limit. | >>>>> Indeed. May be in the future we could recreate a simple | >>>>> compliant spec driven method by interpreting the | >>>>> existing configuration trees but this requires some work. | >>>> | >>>> I do not understand this point. What do you mean by | >>>> "interpreting the configuration trees"? | >>> | >>> I mean going over the configurations with dependencies to | >>> recreate the tree structure but with versions. | >>> May be this is not needed because for versions we do not need | >>> dependencies so just group them per configurations. | >>> | >>>> | >>>> Doru | >>>> | >>>>>> | >>>>>> With that said it _is_ performing a useful function ... | >>>>>> | >>>>>> I have recently come up with an approach to addressing the | >>>>>> method literal limit from a slightly different angle and I | >>>>>> would assume that SnapshotCello could be recast to use this | >>>>>> "approved approach" when the new techinique becomes | >>>>>> available. At that time it would make sense to roll the | >>>>>> SnapshotCello funtionality into the MetacelloToolBox... | >>>>>> | >>>>>> Dale | >>>>>> | >>>>>> [1] | >>>>>> http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html | >>>>>> ----- Original Message ----- | >>>>>> | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | >>>>>> | To: "Moose-related development" <moose-dev@iam.unibe.ch> | >>>>>> | Cc: "Any question about pharo is welcome" | >>>>>> | <pharo-users@lists.pharo.org>, "Pharo Development List" | >>>>>> | <pharo-dev@lists.pharo.org> | >>>>>> | Sent: Tuesday, July 23, 2013 2:17:50 PM | >>>>>> | Subject: [Moose-dev] Re: [ann] snapshotcello | >>>>>> | | >>>>>> | Nice to see SnapshotCello coming to live. May be it should | >>>>>> | be | >>>>>> | integrated to Metacello. | >>>>>> | Because everybody may need this cool feature. | >>>>>> | | >>>>>> | Stef | >>>>>> | | >>>>>> | On Jul 23, 2013, at 10:43 PM, Tudor Girba | >>>>>> | <tudor@tudorgirba.com> | >>>>>> | wrote: | >>>>>> | | >>>>>> | > Hi, | >>>>>> | > | >>>>>> | > Stef and I developed Snapshotcello, a little utility that | >>>>>> | > enables | >>>>>> | > you to freeze a snapshot of a given configuration based on | >>>>>> | > what is | >>>>>> | > already loaded in your current image. | >>>>>> | > | >>>>>> | > The idea is simple. You develop against the latest | >>>>>> | > versions of all | >>>>>> | > packages, and commit your changes for each package. When | >>>>>> | > you are | >>>>>> | > ready for a release, you assemble your image, and generate | >>>>>> | > a | >>>>>> | > snapshot version that can be reloaded later. | >>>>>> | > | >>>>>> | > Here is an example of how it can work to take a snapshot | >>>>>> | > of a | >>>>>> | > development version: | >>>>>> | > Snapshotcello new | >>>>>> | > configurationClass: ConfigurationOfMoose; | >>>>>> | > configurationVersion: #development; | >>>>>> | > publishVersion: '4.8-snapshot' | >>>>>> | > | >>>>>> | > You can find more details here: | >>>>>> | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-rea... | >>>>>> | > | >>>>>> | > You can get the code at: | >>>>>> | > Gofer new | >>>>>> | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; | >>>>>> | > package: 'ConfigurationOfSnapshotcello'; | >>>>>> | > load. | >>>>>> | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) | >>>>>> | > loadDevelopment | >>>>>> | > | >>>>>> | > Cheers, | >>>>>> | > Doru | >>>>>> | > | >>>>>> | > -- | >>>>>> | > www.tudorgirba.com | >>>>>> | > | >>>>>> | > "Every successful trip needs a suitable vehicle." | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > | >>>>>> | > _______________________________________________ | >>>>>> | > Moose-dev mailing list | >>>>>> | > Moose-dev@iam.unibe.ch | >>>>>> | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev | >>>>>> | | >>>>>> | | >>>>>> | _______________________________________________ | >>>>>> | Moose-dev mailing list | >>>>>> | Moose-dev@iam.unibe.ch | >>>>>> | https://www.iam.unibe.ch/mailman/listinfo/moose-dev | >>>>>> | | >>>>> | >>>>> | >>>>> _______________________________________________ | >>>>> Moose-dev mailing list | >>>>> Moose-dev@iam.unibe.ch | >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev | >>>> | >>>> -- | >>>> www.tudorgirba.com | >>>> | >>>> "From an abstract enough point of view, any two things are | >>>> similar." | >>> | >>> | >> | >> | >> | >> | >> -- | >> www.tudorgirba.com | >> | >> "Every thing has its own flow" | > | > | | -- | www.tudorgirba.com | | "Every now and then stop and ask yourself if the war you're fighting | is the right one." | | | | |
-- www.tudorgirba.com "Every thing has its own flow"
That's going to make working out Metacello details a bit difficult:( Dale ----- Original Message ----- | From: "Tudor Girba" <tudor@tudorgirba.com> | To: "Pharo Development List" <pharo-dev@lists.pharo.org> | Sent: Thursday, July 25, 2013 1:08:30 AM | Subject: Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] | snapshotcello | Unfortunately, I will not be able to join :( | Doru | On Wed, Jul 24, 2013 at 9:38 PM, Dale K. Henrichs < | dale.henrichs@gemtalksystems.com > wrote: | | Doru, | | | Are you going to be at ESUG this year? | | | I think there are some features of the Metacello Preview that can | | be | | of a great help to your Moose development and I think you and I | | need | | to spend time discussing the ins and outs in detail ... | | | I have also done a fair amount or work writing tools for tODE that | | manipulate sets of configurations using the MetacelloToolBox | | (Metacello Preview version), so perhaps your goal of "automatic | | transitive versioning of all nested configurations" is not as far | | away as you think. And again, I think some deep discussions at a | | whiteboard and some pair programming is probably the most | | efficient... | | | Dale | | | ----- Original Message ----- | | | | From: "Tudor Girba" < tudor@tudorgirba.com > | | | | To: "Pharo Development List" < pharo-dev@lists.pharo.org > | | | | Sent: Wednesday, July 24, 2013 11:24:20 AM | | | | Subject: Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: Re: [ann] | | | snapshotcello | | | | | | | | Hi, | | | | | | | | On Jul 24, 2013, at 5:25 PM, Johan Brichau < johan@inceptive.be > | | | | wrote: | | | | | | | | > Doru, | | | | > | | | | > What do you understand with 'levels'? Is it referenced | | | > projects? | | | | | | | | Yes. Nested projects, each being under development :) | | | | | | | | > Perhaps this is the difference I did not immediately extract | | | > from | | | | > your description. Re-reading it with this focus makes the | | | | > difference clear I think. | | | | > | | | | > My use of the toolbox is indeed to generate or update a version | | | > for | | | | > a single project where all 'nested' projects are referenced by | | | | > project version. As I understand it, the snapshot version is a | | | | > 'flattened' version containing all packages? | | | | | | | | Yes. | | | | | | | | My end goal would be to be able to create automatic transitive | | | | versioning of all nested configurations, but this requires some | | | more | | | | work, and likely some extension at the level of Metacello. So, | | | until | | | | this happens, we now have the option of snapshotting all | | | packages. | | | | | | | | The cool thing is that if you have something like: | | | | ConfigurationOfMoose depends on ConfigurationOfGlamour | | | | | | | | then in the list of snapshotted packages, you will also get the | | | | version of ConfigurationOfGlamour. Thus, essentially, you obtain | | | the | | | | same thing as if you would load nested configurations. | | | | | | | | The only problem is that because we lose configuration nesting | | | | information, Metacello is unable to resolve possible diamond | | | | conflicts. For example, suppose you have a project that depends | | | on | | | a | | | | certain version X of Glamour, but also would like to load the | | | whole | | | | Moose that loads version Y of Glamour. If you use normal | | | | configurations, Metacello should be able to detect the conflict, | | | but | | | | if you only have flattened versions, you will likely not detect | | | the | | | | conflict so easily. In any case, I think this is acceptable at | | | the | | | | moment. | | | | | | | | Cheers, | | | | Doru | | | | | | | | | | | | | | | | > I think I get it now. thanks | | | | > | | | | > Johan | | | | > | | | | > On 24 Jul 2013, at 12:45, Tudor Girba < tudor@tudorgirba.com > | | | > wrote: | | | | > | | | | >> Perhaps I missed something in the toolbox, but as far as I | | | >> know | | | | >> you cannot create a version of a configuration that is | | | >> composed | | | | >> of multiple sub-projects nested multiple levels deep. | | | | >> | | | | >> Could you describe the way you are using the Metacello | | | >> Toolbox? | | | | >> | | | | >> Doru | | | | >> | | | | >> | | | | >> On Wed, Jul 24, 2013 at 10:39 AM, Johan Brichau | | | | >> < johan@inceptive.be > wrote: | | | | >> Hi Doru, Stef, | | | | >> | | | | >> May I ask what the difference is with the version generation | | | >> and | | | | >> updating methods found in MetacelloToolbox ? I want to | | | | >> understand, because I am currently using these of | | | | >> MetacelloToolbox to do the things you describe. | | | | >> | | | | >> Cheers! | | | | >> Johan | | | | >> | | | | >> On 24 Jul 2013, at 09:52, Stéphane Ducasse | | | | >> < stephane.ducasse@inria.fr > wrote: | | | | >> | | | | >>> | | | | >>> On Jul 24, 2013, at 9:11 AM, Tudor Girba < | | | >>> tudor@tudorgirba.com | | | >>> > | | | | >>> wrote: | | | | >>> | | | | >>>> Hi, | | | | >>>> | | | | >>>> On Jul 24, 2013, at 8:48 AM, Stéphane Ducasse | | | | >>>> < stephane.ducasse@inria.fr > wrote: | | | | >>>> | | | | >>>>> | | | | >>>>> On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs | | | | >>>>> < dale.henrichs@gemtalksystems.com > wrote: | | | | >>>>> | | | | >>>>>> Stef, | | | | >>>>>> | | | | >>>>>> I haven't completely wrapped my brain around what | | | | >>>>>> SnapshotCello does so I don't have an informed opinion ... | | | | >>>>>> the fact that you found a need to invent SnapshotCello | | | >>>>>> does | | | | >>>>>> speak volumes to the fact that there is a need that is | | | >>>>>> going | | | | >>>>>> unmet:). | | | | >>>>>> | | | | >>>>>> However, I don't like the fact that you end up sending a | | | | >>>>>> non-spec message to make this work (#populateSpec:with:). | | | | >>>>>> Tools like Versioner will not be able to rewrite a method | | | | >>>>>> like this correctly so it is a less than satisfactory | | | | >>>>>> workaround to the method literal limit. | | | | >>>>> Indeed. May be in the future we could recreate a simple | | | | >>>>> compliant spec driven method by interpreting the | | | | >>>>> existing configuration trees but this requires some work. | | | | >>>> | | | | >>>> I do not understand this point. What do you mean by | | | | >>>> "interpreting the configuration trees"? | | | | >>> | | | | >>> I mean going over the configurations with dependencies to | | | | >>> recreate the tree structure but with versions. | | | | >>> May be this is not needed because for versions we do not need | | | | >>> dependencies so just group them per configurations. | | | | >>> | | | | >>>> | | | | >>>> Doru | | | | >>>> | | | | >>>>>> | | | | >>>>>> With that said it _is_ performing a useful function ... | | | | >>>>>> | | | | >>>>>> I have recently come up with an approach to addressing the | | | | >>>>>> method literal limit from a slightly different angle and I | | | | >>>>>> would assume that SnapshotCello could be recast to use | | | >>>>>> this | | | | >>>>>> "approved approach" when the new techinique becomes | | | | >>>>>> available. At that time it would make sense to roll the | | | | >>>>>> SnapshotCello funtionality into the MetacelloToolBox... | | | | >>>>>> | | | | >>>>>> Dale | | | | >>>>>> | | | | >>>>>> [1] | | | | >>>>>> http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html | | | | >>>>>> ----- Original Message ----- | | | | >>>>>> | From: "Stéphane Ducasse" < stephane.ducasse@inria.fr > | | | | >>>>>> | To: "Moose-related development" < moose-dev@iam.unibe.ch | | | >>>>>> | > | | | | >>>>>> | Cc: "Any question about pharo is welcome" | | | | >>>>>> | < pharo-users@lists.pharo.org >, "Pharo Development | | | >>>>>> | List" | | | | >>>>>> | < pharo-dev@lists.pharo.org > | | | | >>>>>> | Sent: Tuesday, July 23, 2013 2:17:50 PM | | | | >>>>>> | Subject: [Moose-dev] Re: [ann] snapshotcello | | | | >>>>>> | | | | | >>>>>> | Nice to see SnapshotCello coming to live. May be it | | | >>>>>> | should | | | | >>>>>> | be | | | | >>>>>> | integrated to Metacello. | | | | >>>>>> | Because everybody may need this cool feature. | | | | >>>>>> | | | | | >>>>>> | Stef | | | | >>>>>> | | | | | >>>>>> | On Jul 23, 2013, at 10:43 PM, Tudor Girba | | | | >>>>>> | < tudor@tudorgirba.com > | | | | >>>>>> | wrote: | | | | >>>>>> | | | | | >>>>>> | > Hi, | | | | >>>>>> | > | | | | >>>>>> | > Stef and I developed Snapshotcello, a little utility | | | >>>>>> | > that | | | | >>>>>> | > enables | | | | >>>>>> | > you to freeze a snapshot of a given configuration | | | >>>>>> | > based | | | >>>>>> | > on | | | | >>>>>> | > what is | | | | >>>>>> | > already loaded in your current image. | | | | >>>>>> | > | | | | >>>>>> | > The idea is simple. You develop against the latest | | | | >>>>>> | > versions of all | | | | >>>>>> | > packages, and commit your changes for each package. | | | >>>>>> | > When | | | | >>>>>> | > you are | | | | >>>>>> | > ready for a release, you assemble your image, and | | | >>>>>> | > generate | | | | >>>>>> | > a | | | | >>>>>> | > snapshot version that can be reloaded later. | | | | >>>>>> | > | | | | >>>>>> | > Here is an example of how it can work to take a | | | >>>>>> | > snapshot | | | | >>>>>> | > of a | | | | >>>>>> | > development version: | | | | >>>>>> | > Snapshotcello new | | | | >>>>>> | > configurationClass: ConfigurationOfMoose; | | | | >>>>>> | > configurationVersion: #development; | | | | >>>>>> | > publishVersion: '4.8-snapshot' | | | | >>>>>> | > | | | | >>>>>> | > You can find more details here: | | | | >>>>>> | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-rea... | | | | >>>>>> | > | | | | >>>>>> | > You can get the code at: | | | | >>>>>> | > Gofer new | | | | >>>>>> | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; | | | | >>>>>> | > package: 'ConfigurationOfSnapshotcello'; | | | | >>>>>> | > load. | | | | >>>>>> | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) | | | | >>>>>> | > loadDevelopment | | | | >>>>>> | > | | | | >>>>>> | > Cheers, | | | | >>>>>> | > Doru | | | | >>>>>> | > | | | | >>>>>> | > -- | | | | >>>>>> | > www.tudorgirba.com | | | | >>>>>> | > | | | | >>>>>> | > "Every successful trip needs a suitable vehicle." | | | | >>>>>> | > | | | | >>>>>> | > | | | | >>>>>> | > | | | | >>>>>> | > | | | | >>>>>> | > | | | | >>>>>> | > _______________________________________________ | | | | >>>>>> | > Moose-dev mailing list | | | | >>>>>> | > Moose-dev@iam.unibe.ch | | | | >>>>>> | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | | | >>>>>> | | | | | >>>>>> | | | | | >>>>>> | _______________________________________________ | | | | >>>>>> | Moose-dev mailing list | | | | >>>>>> | Moose-dev@iam.unibe.ch | | | | >>>>>> | https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | | | >>>>>> | | | | | >>>>> | | | | >>>>> | | | | >>>>> _______________________________________________ | | | | >>>>> Moose-dev mailing list | | | | >>>>> Moose-dev@iam.unibe.ch | | | | >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | | | >>>> | | | | >>>> -- | | | | >>>> www.tudorgirba.com | | | | >>>> | | | | >>>> "From an abstract enough point of view, any two things are | | | | >>>> similar." | | | | >>> | | | | >>> | | | | >> | | | | >> | | | | >> | | | | >> | | | | >> -- | | | | >> www.tudorgirba.com | | | | >> | | | | >> "Every thing has its own flow" | | | | > | | | | > | | | | | | | | -- | | | | www.tudorgirba.com | | | | | | | | "Every now and then stop and ask yourself if the war you're | | | fighting | | | | is the right one." | | | | | | | | | | | | | | | | | | | | | | -- | www.tudorgirba.com | "Every thing has its own flow"
----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: "Pharo Development List" <pharo-dev@lists.pharo.org> | Cc: "Moose-related development" <moose-dev@iam.unibe.ch>, "Any question about pharo is welcome" | <pharo-users@lists.pharo.org> | Sent: Tuesday, July 23, 2013 11:48:27 PM | Subject: Re: [Pharo-dev] [Moose-dev] Re: [ann] snapshotcello | | | On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs | <dale.henrichs@gemtalksystems.com> wrote: | | > Stef, | > | > I haven't completely wrapped my brain around what SnapshotCello | > does so I don't have an informed opinion ... the fact that you | > found a need to invent SnapshotCello does speak volumes to the | > fact that there is a need that is going unmet:). | > | > However, I don't like the fact that you end up sending a non-spec | > message to make this work (#populateSpec:with:). Tools like | > Versioner will not be able to rewrite a method like this correctly | > so it is a less than satisfactory workaround to the method literal | > limit. | | Indeed. May be in the future we could recreate a simple compliant | spec driven method by interpreting the | existing configuration trees but this requires some work. Absolutely and it would be work that I'd be willing to do ... From that perspective SnapshotCello is a very good spec for what you and the Moose team need. Dale
Hi, I would be happy to blend Snapshotcello into Metacello. Cheers, Doru On Jul 24, 2013, at 9:05 PM, "Dale K. Henrichs" <dale.henrichs@gemtalksystems.com> wrote:
----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: "Pharo Development List" <pharo-dev@lists.pharo.org> | Cc: "Moose-related development" <moose-dev@iam.unibe.ch>, "Any question about pharo is welcome" | <pharo-users@lists.pharo.org> | Sent: Tuesday, July 23, 2013 11:48:27 PM | Subject: Re: [Pharo-dev] [Moose-dev] Re: [ann] snapshotcello | | | On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs | <dale.henrichs@gemtalksystems.com> wrote: | | > Stef, | > | > I haven't completely wrapped my brain around what SnapshotCello | > does so I don't have an informed opinion ... the fact that you | > found a need to invent SnapshotCello does speak volumes to the | > fact that there is a need that is going unmet:). | > | > However, I don't like the fact that you end up sending a non-spec | > message to make this work (#populateSpec:with:). Tools like | > Versioner will not be able to rewrite a method like this correctly | > so it is a less than satisfactory workaround to the method literal | > limit. | | Indeed. May be in the future we could recreate a simple compliant | spec driven method by interpreting the | existing configuration trees but this requires some work.
Absolutely and it would be work that I'd be willing to do ... From that perspective SnapshotCello is a very good spec for what you and the Moose team need.
Dale
-- www.tudorgirba.com "Every thing has its own flow."
Hi, On Jul 23, 2013, at 11:51 PM, "Dale K. Henrichs" <dale.henrichs@gemtalksystems.com> wrote:
Stef,
I haven't completely wrapped my brain around what SnapshotCello does so I don't have an informed opinion ... the fact that you found a need to invent SnapshotCello does speak volumes to the fact that there is a need that is going unmet:).
What is not clear? I would be interested in describing our scenario in more details because I think this is a development pattern. But, I need some concrete questions to start from.
However, I don't like the fact that you end up sending a non-spec message to make this work (#populateSpec:with:). Tools like Versioner will not be able to rewrite a method like this correctly so it is a less than satisfactory workaround to the method literal limit.
I still do not understand why Versionner would be affected by the current versions given that we are only generating versions that should be immutable hence no need for management.
With that said it _is_ performing a useful function ...
I have recently come up with an approach to addressing the method literal limit from a slightly different angle and I would assume that SnapshotCello could be recast to use this "approved approach" when the new techinique becomes available. At that time it would make sense to roll the SnapshotCello funtionality into the MetacelloToolBox...
Having a different way to store the information should be no problem. I am curious about your ideas. Cheers, Doru
Dale
[1] http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html ----- Original Message ----- | From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> | To: "Moose-related development" <moose-dev@iam.unibe.ch> | Cc: "Any question about pharo is welcome" <pharo-users@lists.pharo.org>, "Pharo Development List" | <pharo-dev@lists.pharo.org> | Sent: Tuesday, July 23, 2013 2:17:50 PM | Subject: [Moose-dev] Re: [ann] snapshotcello | | Nice to see SnapshotCello coming to live. May be it should be | integrated to Metacello. | Because everybody may need this cool feature. | | Stef | | On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor@tudorgirba.com> | wrote: | | > Hi, | > | > Stef and I developed Snapshotcello, a little utility that enables | > you to freeze a snapshot of a given configuration based on what is | > already loaded in your current image. | > | > The idea is simple. You develop against the latest versions of all | > packages, and commit your changes for each package. When you are | > ready for a release, you assemble your image, and generate a | > snapshot version that can be reloaded later. | > | > Here is an example of how it can work to take a snapshot of a | > development version: | > Snapshotcello new | > configurationClass: ConfigurationOfMoose; | > configurationVersion: #development; | > publishVersion: '4.8-snapshot' | > | > You can find more details here: | > http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-rea... | > | > You can get the code at: | > Gofer new | > smalltalkhubUser: 'girba' project: 'Snapshotcello'; | > package: 'ConfigurationOfSnapshotcello'; | > load. | > (Smalltalk globals at: #ConfigurationOfSnapshotcello) | > loadDevelopment | > | > Cheers, | > Doru | > | > -- | > www.tudorgirba.com | > | > "Every successful trip needs a suitable vehicle." | > | > | > | > | > | > _______________________________________________ | > Moose-dev mailing list | > Moose-dev@iam.unibe.ch | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | | _______________________________________________ | Moose-dev mailing list | Moose-dev@iam.unibe.ch | https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
-- www.tudorgirba.com "Live like you mean it."
----- Original Message ----- | From: "Tudor Girba" <tudor@tudorgirba.com> | To: "Any question about pharo is welcome" <pharo-users@lists.pharo.org> | Cc: "Moose-related development" <moose-dev@iam.unibe.ch>, "Pharo Development List" <pharo-dev@lists.pharo.org> | Sent: Wednesday, July 24, 2013 12:07:48 AM | Subject: Re: [Pharo-users] [Moose-dev] Re: [ann] snapshotcello | | Hi, | | On Jul 23, 2013, at 11:51 PM, "Dale K. Henrichs" | <dale.henrichs@gemtalksystems.com> wrote: | | > Stef, | > | > I haven't completely wrapped my brain around what SnapshotCello | > does so I don't have an informed opinion ... the fact that you | > found a need to invent SnapshotCello does speak volumes to the | > fact that there is a need that is going unmet:). | | What is not clear? I would be interested in describing our scenario | in more details because I think this is a development pattern. But, | I need some concrete questions to start from. I do not completely understand what SnapshotCello is actually doing let alone why it is doing what it is doing ... So I need to spend time with it to "wrap my brain around it" then I can ask concrete questions.... | | > However, I don't like the fact that you end up sending a non-spec | > message to make this work (#populateSpec:with:). Tools like | > Versioner will not be able to rewrite a method like this correctly | > so it is a less than satisfactory workaround to the method literal | > limit. | | I still do not understand why Versionner would be affected by the | current versions given that we are only generating versions that | should be immutable hence no need for management. I made my comments without having wrapped my head around SnapshotCello and it is my standard reaction to non-spec-based message sends ... I reserve the right to someday switch to a non-class-based implementation for Metacello and problems like too many literals in a method will no longer be a problem (and the tool many literals issue is but one of the forces driving me away from class-based specs), but specs that are generated dynamically based on data gleaned from arbitrary message sends will not be mappable. So I continue to repeat the message that Metacello does not support the dynamic generation of specs. In your particular case you are probably living within acceptable bounds, but the very existence of "message sends within a spec" may encourage other folks to try their hand at dynamic generation....and we are off to the races:) So I continue to repeat the message that Metacello does not support the dynamic generation of specs. | | > With that said it _is_ performing a useful function ... | > | > I have recently come up with an approach to addressing the method | > literal limit from a slightly different angle and I would assume | > that SnapshotCello could be recast to use this "approved approach" | > when the new techinique becomes available. At that time it would | > make sense to roll the SnapshotCello funtionality into the | > MetacelloToolBox... | | Having a different way to store the information should be no problem. | I am curious about your ideas. I've tossed out some of my ideas in a post in the metacello mailing list[1]. And that would be a good place to discusss this further... Dale [1] http://forum.world.st/Loading-problem-in-Seaside-tc4699965.html
Nice :) Random Question: Do you have a way to file out a whole configuration as a fuel file? or would it be considerably easier to so with your Snappy tool? On 2013-07-23, at 23:17, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Nice to see SnapshotCello coming to live. May be it should be integrated to Metacello. Because everybody may need this cool feature.
Stef
On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Stef and I developed Snapshotcello, a little utility that enables you to freeze a snapshot of a given configuration based on what is already loaded in your current image.
The idea is simple. You develop against the latest versions of all packages, and commit your changes for each package. When you are ready for a release, you assemble your image, and generate a snapshot version that can be reloaded later.
Here is an example of how it can work to take a snapshot of a development version: Snapshotcello new configurationClass: ConfigurationOfMoose; configurationVersion: #development; publishVersion: '4.8-snapshot'
You can find more details here: http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-rea...
You can get the code at: Gofer new smalltalkhubUser: 'girba' project: 'Snapshotcello'; package: 'ConfigurationOfSnapshotcello'; load. (Smalltalk globals at: #ConfigurationOfSnapshotcello) loadDevelopment
Cheers, Doru
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Jul 24, 2013, at 12:09 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
Nice :)
Random Question: Do you have a way to file out a whole configuration as a fuel file?
Do you mean the packages? or the configuration itself? What snapshotcello does is that it walks the configurations and gather the packages and their repository and generate a list.
or would it be considerably easier to so with your Snappy tool?
probably because you get a linear list of packages. Stef
On 2013-07-23, at 23:17, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Nice to see SnapshotCello coming to live. May be it should be integrated to Metacello. Because everybody may need this cool feature.
Stef
On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Stef and I developed Snapshotcello, a little utility that enables you to freeze a snapshot of a given configuration based on what is already loaded in your current image.
The idea is simple. You develop against the latest versions of all packages, and commit your changes for each package. When you are ready for a release, you assemble your image, and generate a snapshot version that can be reloaded later.
Here is an example of how it can work to take a snapshot of a development version: Snapshotcello new configurationClass: ConfigurationOfMoose; configurationVersion: #development; publishVersion: '4.8-snapshot'
You can find more details here: http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-rea...
You can get the code at: Gofer new smalltalkhubUser: 'girba' project: 'Snapshotcello'; package: 'ConfigurationOfSnapshotcello'; load. (Smalltalk globals at: #ConfigurationOfSnapshotcello) loadDevelopment
Cheers, Doru
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi, On Jul 24, 2013, at 8:49 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jul 24, 2013, at 12:09 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
Nice :)
Random Question: Do you have a way to file out a whole configuration as a fuel file?
Do you mean the packages? or the configuration itself? What snapshotcello does is that it walks the configurations and gather the packages and their repository and generate a list.
I think he means all packages. I like the idea.
or would it be considerably easier to so with your Snappy tool?
probably because you get a linear list of packages.
It actually does not depend that much on Snapshotcello, given that Snapshotcello actually uses Metacello for anything meaningful. But, it could be cheaper to simply traverse the snapshotted list of packages and dump them in fuel. Cheers, Doru
Stef
On 2013-07-23, at 23:17, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Nice to see SnapshotCello coming to live. May be it should be integrated to Metacello. Because everybody may need this cool feature.
Stef
On Jul 23, 2013, at 10:43 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
Stef and I developed Snapshotcello, a little utility that enables you to freeze a snapshot of a given configuration based on what is already loaded in your current image.
The idea is simple. You develop against the latest versions of all packages, and commit your changes for each package. When you are ready for a release, you assemble your image, and generate a snapshot version that can be reloaded later.
Here is an example of how it can work to take a snapshot of a development version: Snapshotcello new configurationClass: ConfigurationOfMoose; configurationVersion: #development; publishVersion: '4.8-snapshot'
You can find more details here: http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-rea...
You can get the code at: Gofer new smalltalkhubUser: 'girba' project: 'Snapshotcello'; package: 'ConfigurationOfSnapshotcello'; load. (Smalltalk globals at: #ConfigurationOfSnapshotcello) loadDevelopment
Cheers, Doru
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."
participants (5)
-
Camillo Bruni -
Dale K. Henrichs -
Johan Brichau -
Stéphane Ducasse -
Tudor Girba