Hi dale

do you plan to write a visitor on metacello spec?

Stef

On Jul 24, 2013, at 9:38 PM, Dale K. Henrichs 
<[email protected]> 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" <[email protected]>
> | To: "Pharo Development List" <[email protected]>
> | 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 <[email protected]>
> | 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 <[email protected]> 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
> | >> <[email protected]> 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
> | >> <[email protected]> wrote:
> | >> 
> | >>> 
> | >>> On Jul 24, 2013, at 9:11 AM, Tudor Girba <[email protected]>
> | >>> wrote:
> | >>> 
> | >>>> Hi,
> | >>>> 
> | >>>> On Jul 24, 2013, at 8:48 AM, Stéphane Ducasse
> | >>>> <[email protected]> wrote:
> | >>>> 
> | >>>>> 
> | >>>>> On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs
> | >>>>> <[email protected]> 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" <[email protected]>
> | >>>>>> | To: "Moose-related development" <[email protected]>
> | >>>>>> | Cc: "Any question about pharo is welcome"
> | >>>>>> | <[email protected]>, "Pharo Development List"
> | >>>>>> | <[email protected]>
> | >>>>>> | 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
> | >>>>>> | <[email protected]>
> | >>>>>> | 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
> | >>>>>> | > [email protected]
> | >>>>>> | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> | >>>>>> |
> | >>>>>> |
> | >>>>>> | _______________________________________________
> | >>>>>> | Moose-dev mailing list
> | >>>>>> | [email protected]
> | >>>>>> | https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> | >>>>>> |
> | >>>>> 
> | >>>>> 
> | >>>>> _______________________________________________
> | >>>>> Moose-dev mailing list
> | >>>>> [email protected]
> | >>>>> 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."
> | 
> | 
> | 
> | 
> | 
> 


Reply via email to