Unfortunately, I will not be able to join :( Doru
On Wed, Jul 24, 2013 at 9:38 PM, Dale K. Henrichs < dale.henri...@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" <tu...@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 <jo...@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 <tu...@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 > | >> <jo...@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.duca...@inria.fr> wrote: > | >> > | >>> > | >>> On Jul 24, 2013, at 9:11 AM, Tudor Girba <tu...@tudorgirba.com> > | >>> wrote: > | >>> > | >>>> Hi, > | >>>> > | >>>> On Jul 24, 2013, at 8:48 AM, Stéphane Ducasse > | >>>> <stephane.duca...@inria.fr> wrote: > | >>>> > | >>>>> > | >>>>> On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs > | >>>>> <dale.henri...@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.duca...@inria.fr> > | >>>>>> | To: "Moose-related development" <moose-...@iam.unibe.ch> > | >>>>>> | Cc: "Any question about pharo is welcome" > | >>>>>> | <pharo-us...@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 > | >>>>>> | <tu...@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-ready > | >>>>>> | > > | >>>>>> | > 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-...@iam.unibe.ch > | >>>>>> | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > | >>>>>> | > | >>>>>> | > | >>>>>> | _______________________________________________ > | >>>>>> | Moose-dev mailing list > | >>>>>> | moose-...@iam.unibe.ch > | >>>>>> | https://www.iam.unibe.ch/mailman/listinfo/moose-dev > | >>>>>> | > | >>>>> > | >>>>> > | >>>>> _______________________________________________ > | >>>>> Moose-dev mailing list > | >>>>> moose-...@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"
