Moose and Metacello scripting API

I just finished doing a load of Moose into Pharo1.4-14421 using the following expression:

  Metacello new
    configuration: 'Moose';
    version: 'default';
    squeaksource: 'Moose';
    load.

I'm happy that the load completed without barfing, but when I ran the rests I got the following results:

  7075 run, 6946 passes, 26 expected failures, 90 failures, 13 errors, 0 unexpected passes

At the moment I don't whether this result is expected or not...

I'll start digging into this tomorrow, but if anyone can tell me whether or not this is a "normal" result, then you'll save me a fair amount of time.

Along these lines, I'd appreciate it if a Moose developer could volunteer to provide me with a couple of different development use cases related to loading/updating images for development... I plan to try doing upgrades from version 4.0 to version 4.1 to version 4.2, but a knowledgeable developer might be able to tell me that that kind of upgrade path isn't expected to work and point at a more reasonable upgrade path ...
there are couple of new features (`lock` and `upgrade`commands as well as `onUpgrade:` and blocks) in the scripting api that might address upgrade problems, but without intimate knowledge of what should and shouldn't work I'd just be flopping around ...

I expect to do some trial runs pushing Moose and Glamour (additonal nominations for other projects welcome) out to Github to see how the fetch times might be sped up. With git and github all of the packages in a single repository are downloaded at once (instead of one package at a time with mcz repositories) and that might have a dramatic impact on load times ... or not:)

With ESUG coming up it would be nice if I could get some groundwork laid with some Moose developers so that we could address any meaty issues face to face at ESUG ...

Thanks in advance,

Dale

Hi Dale,

Great news!

See my replies inline.

On Wed, Jul 18, 2012 at 2:39 AM, Dale Henrichs <[hidden email]> wrote:
It seems that you are running all Pharo tests. I cannot reproduce
those exact numbers right now (probably because my image also has
other artifacts in there).

But, for reference, we should only run the Moose related tests. Here
is the snippet we use at the moment on the continuous integration
server:
http://ci.moosetechnology.org/job/moose-latest-dev/

"Run the Moose Tests"
packages := Set new.
((ConfigurationOfMoose new project version: 'default')
        packagesForSpecNamed: 'Tests')
        do: [ :spec | packages add: spec name ].
(ConfigurationOfMoose new project version: 'default') projects do: [:each |
        each name = 'Filesystem' ifFalse: [
                (each version packagesForSpecNamed: 'Tests') do: [:spec |
                        packages add: spec name ]]].
HDTestReport runPackages: (packages asSortedCollection: [:a :b | a < b
]) asOrderedCollection.


> I'll start digging into this tomorrow, but if anyone can tell me whether or not this is a "normal" result, then you'll save me a fair amount of time.
>
> Along these lines, I'd appreciate it if a Moose developer could volunteer to provide me with a couple of different development use cases related to loading/updating images for development... I plan to try doing upgrades from version 4.0 to version 4.1 to version 4.2, but a knowledgeable developer might be able to tell me that that kind of upgrade path isn't expected to work and point at a more reasonable upgrade path ...
> there are couple of new features (`lock` and `upgrade`commands as well as `onUpgrade:` and blocks) in the scripting api that might address upgrade problems, but without intimate knowledge of what should and shouldn't work I'd just be flopping around ...

Essentially, for Moose, we mostly have only one development scenario:
- load the latest baseline
- develop locally
- commit the code changes for each package
- when a good enough situation is reached, create a configuration version
(ideally, this last step would also be created by the continuous
integration step)


> I expect to do some trial runs pushing Moose and Glamour (additonal nominations for other projects welcome) out to Github to see how the fetch times might be sped up. With git and github all of the packages in a single repository are downloaded at once (instead of one package at a time with mcz repositories) and that might have a dramatic impact on load times ... or not:)
>
> With ESUG coming up it would be nice if I could get some groundwork laid with some Moose developers so that we could address any meaty issues face to face at ESUG ...

I wish I could come to ESUG, but I cannot this year. Nevertheless, I
can try to support remotely.

Cheers,
Doru


> Thanks in advance,
>
> Dale



--
www.tudorgirba.com

"Every thing has its own flow"

Doru,

Excellent! You provided exactly the information I was looking for and you'll keep me from splashing around too much.

I selected all of the tests that came in during the load so no doubt I was running tests for non-Moose projects.

I'm in the final phases of getting the scripting api functional and ready for a preview release   and I want to make sure that Moose will not be negatively impacted... Once I'm comfortable I will appreciate it if you could start using the preview release for your development activities, so I can get feedback from real users ...

I'll also be interested to gauge your interest in using git/github for Moose. Your development model of working on the bleeding edge fits very well with git/github. One of the nasty little chores of constantly having to update the mcz file version in the config file (for every project) is completely eliminated when you use git/github ... you only need to supply a single commit SHA to tag a project release....As I said, I plan to set up some sample git/github projects using Moose so that I can hammer on Metacello...

If you're not coming to ESUG, then we won't have to wait til then to get busy:) We'll have to plan on skyping...

Thanks,

Dale

----- Original Message -----
| From: "Tudor Girba" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, July 18, 2012 3:11:37 AM
| Subject: Re: [Metacello] Moose and Metacello scripting API
|
| Hi Dale,
|
| Great news!
|
| See my replies inline.
|
| On Wed, Jul 18, 2012 at 2:39 AM, Dale Henrichs <[hidden email]>
| wrote:
| > I just finished doing a load of Moose into Pharo1.4-14421 using the
| > following expression:
| >
| >   Metacello new
| >     configuration: 'Moose';
| >     version: 'default';
| >     squeaksource: 'Moose';
| >     load.
| >
| > I'm happy that the load completed without barfing, but when I ran
| > the rests I got the following results:
| >
| >   7075 run, 6946 passes, 26 expected failures, 90 failures, 13
| >   errors, 0 unexpected passes
| >
| > At the moment I don't whether this result is expected or not...
|
| It seems that you are running all Pharo tests. I cannot reproduce
| those exact numbers right now (probably because my image also has
| other artifacts in there).
|
| But, for reference, we should only run the Moose related tests. Here
| is the snippet we use at the moment on the continuous integration
| server:
| http://ci.moosetechnology.org/job/moose-latest-dev/
|
| "Run the Moose Tests"
| packages := Set new.
| ((ConfigurationOfMoose new project version: 'default')
|         packagesForSpecNamed: 'Tests')
|         do: [ :spec | packages add: spec name ].
| (ConfigurationOfMoose new project version: 'default') projects do:
| [:each |
|         each name = 'Filesystem' ifFalse: [
|                 (each version packagesForSpecNamed: 'Tests') do:
|                 [:spec |
|                         packages add: spec name ]]].
| HDTestReport runPackages: (packages asSortedCollection: [:a :b | a <
| b
| ]) asOrderedCollection.
|
|
| > I'll start digging into this tomorrow, but if anyone can tell me
| > whether or not this is a "normal" result, then you'll save me a
| > fair amount of time.
| >
| > Along these lines, I'd appreciate it if a Moose developer could
| > volunteer to provide me with a couple of different development use
| > cases related to loading/updating images for development... I plan
| > to try doing upgrades from version 4.0 to version 4.1 to version
| > 4.2, but a knowledgeable developer might be able to tell me that
| > that kind of upgrade path isn't expected to work and point at a
| > more reasonable upgrade path ...
| > there are couple of new features (`lock` and `upgrade`commands as
| > well as `onUpgrade:` and blocks) in the scripting api that might
| > address upgrade problems, but without intimate knowledge of what
| > should and shouldn't work I'd just be flopping around ...
|
| Essentially, for Moose, we mostly have only one development scenario:
| - load the latest baseline
| - develop locally
| - commit the code changes for each package
| - when a good enough situation is reached, create a configuration
| version
| (ideally, this last step would also be created by the continuous
| integration step)
|
|
| > I expect to do some trial runs pushing Moose and Glamour (additonal
| > nominations for other projects welcome) out to Github to see how
| > the fetch times might be sped up. With git and github all of the
| > packages in a single repository are downloaded at once (instead of
| > one package at a time with mcz repositories) and that might have a
| > dramatic impact on load times ... or not:)
| >
| > With ESUG coming up it would be nice if I could get some groundwork
| > laid with some Moose developers so that we could address any meaty
| > issues face to face at ESUG ...
|
| I wish I could come to ESUG, but I cannot this year. Nevertheless, I
| can try to support remotely.
|
| Cheers,
| Doru
|
|
| > Thanks in advance,
| >
| > Dale
|
|
|
| --
| www.tudorgirba.com
|
| "Every thing has its own flow"
|

So, how do we proceed?

Doru


On Wed, Jul 18, 2012 at 4:09 PM, Dale Henrichs <[hidden email]> wrote:


--
www.tudorgirba.com

"Every thing has its own flow"

Doru,

I'm about a day or so away from making the Preview release available (last bit of functionality implemented earlier today)... I need to test the current version on GemStone and Pharo-2.0 and touch up the documentation and then Preview release will be ready for early adopters to work with.

For GLASS I plan to get started on a 1.0-beta.9 release that will leverage the git/github suport for ports of Zinc[1] and Zodiac[2] got GemStone.

For Moose, besides using the scripting API for development, we could use the Moosiverse project[3] for experiments in using git/github for Moose development ... Moosiverse is intended as sandbox for Moose projects where we can try different experiments in working with the Moose code base ...

So I guess things will kick off when I'm ready to release the Preview.

Dale

[1] https://github.com/glassdb/zinc
[2] https://github.com/glassdb/zodiac
[3] https://github.com/Moosiverse

----- Original Message -----
| From: "Tudor Girba" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, July 24, 2012 1:36:42 AM
| Subject: Re: [Metacello] Moose and Metacello scripting API
|
| So, how do we proceed?
|
| Doru
|
|
| On Wed, Jul 18, 2012 at 4:09 PM, Dale Henrichs <[hidden email]>
| wrote:
| > Doru,
| >
| > Excellent! You provided exactly the information I was looking for
| > and you'll keep me from splashing around too much.
| >
| > I selected all of the tests that came in during the load so no
| > doubt I was running tests for non-Moose projects.
| >
| > I'm in the final phases of getting the scripting api functional and
| > ready for a preview release   and I want to make sure that Moose
| > will not be negatively impacted... Once I'm comfortable I will
| > appreciate it if you could start using the preview release for
| > your development activities, so I can get feedback from real users
| > ...
| >
| > I'll also be interested to gauge your interest in using git/github
| > for Moose. Your development model of working on the bleeding edge
| > fits very well with git/github. One of the nasty little chores of
| > constantly having to update the mcz file version in the config
| > file (for every project) is completely eliminated when you use
| > git/github ... you only need to supply a single commit SHA to tag
| > a project release....As I said, I plan to set up some sample
| > git/github projects using Moose so that I can hammer on
| > Metacello...
| >
| > If you're not coming to ESUG, then we won't have to wait til then
| > to get busy:) We'll have to plan on skyping...
| >
| > Thanks,
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: "Tudor Girba" <[hidden email]>
| > | To: [hidden email]
| > | Sent: Wednesday, July 18, 2012 3:11:37 AM
| > | Subject: Re: [Metacello] Moose and Metacello scripting API
| > |
| > | Hi Dale,
| > |
| > | Great news!
| > |
| > | See my replies inline.
| > |
| > | On Wed, Jul 18, 2012 at 2:39 AM, Dale Henrichs
| > | <[hidden email]>
| > | wrote:
| > | > I just finished doing a load of Moose into Pharo1.4-14421 using
| > | > the
| > | > following expression:
| > | >
| > | >   Metacello new
| > | >     configuration: 'Moose';
| > | >     version: 'default';
| > | >     squeaksource: 'Moose';
| > | >     load.
| > | >
| > | > I'm happy that the load completed without barfing, but when I
| > | > ran
| > | > the rests I got the following results:
| > | >
| > | >   7075 run, 6946 passes, 26 expected failures, 90 failures, 13
| > | >   errors, 0 unexpected passes
| > | >
| > | > At the moment I don't whether this result is expected or not...
| > |
| > | It seems that you are running all Pharo tests. I cannot reproduce
| > | those exact numbers right now (probably because my image also has
| > | other artifacts in there).
| > |
| > | But, for reference, we should only run the Moose related tests.
| > | Here
| > | is the snippet we use at the moment on the continuous integration
| > | server:
| > | http://ci.moosetechnology.org/job/moose-latest-dev/
| > |
| > | "Run the Moose Tests"
| > | packages := Set new.
| > | ((ConfigurationOfMoose new project version: 'default')
| > |         packagesForSpecNamed: 'Tests')
| > |         do: [ :spec | packages add: spec name ].
| > | (ConfigurationOfMoose new project version: 'default') projects
| > | do:
| > | [:each |
| > |         each name = 'Filesystem' ifFalse: [
| > |                 (each version packagesForSpecNamed: 'Tests') do:
| > |                 [:spec |
| > |                         packages add: spec name ]]].
| > | HDTestReport runPackages: (packages asSortedCollection: [:a :b |
| > | a <
| > | b
| > | ]) asOrderedCollection.
| > |
| > |
| > | > I'll start digging into this tomorrow, but if anyone can tell
| > | > me
| > | > whether or not this is a "normal" result, then you'll save me a
| > | > fair amount of time.
| > | >
| > | > Along these lines, I'd appreciate it if a Moose developer could
| > | > volunteer to provide me with a couple of different development
| > | > use
| > | > cases related to loading/updating images for development... I
| > | > plan
| > | > to try doing upgrades from version 4.0 to version 4.1 to
| > | > version
| > | > 4.2, but a knowledgeable developer might be able to tell me
| > | > that
| > | > that kind of upgrade path isn't expected to work and point at a
| > | > more reasonable upgrade path ...
| > | > there are couple of new features (`lock` and `upgrade`commands
| > | > as
| > | > well as `onUpgrade:` and blocks) in the scripting api that
| > | > might
| > | > address upgrade problems, but without intimate knowledge of
| > | > what
| > | > should and shouldn't work I'd just be flopping around ...
| > |
| > | Essentially, for Moose, we mostly have only one development
| > | scenario:
| > | - load the latest baseline
| > | - develop locally
| > | - commit the code changes for each package
| > | - when a good enough situation is reached, create a configuration
| > | version
| > | (ideally, this last step would also be created by the continuous
| > | integration step)
| > |
| > |
| > | > I expect to do some trial runs pushing Moose and Glamour
| > | > (additonal
| > | > nominations for other projects welcome) out to Github to see
| > | > how
| > | > the fetch times might be sped up. With git and github all of
| > | > the
| > | > packages in a single repository are downloaded at once (instead
| > | > of
| > | > one package at a time with mcz repositories) and that might
| > | > have a
| > | > dramatic impact on load times ... or not:)
| > | >
| > | > With ESUG coming up it would be nice if I could get some
| > | > groundwork
| > | > laid with some Moose developers so that we could address any
| > | > meaty
| > | > issues face to face at ESUG ...
| > |
| > | I wish I could come to ESUG, but I cannot this year.
| > | Nevertheless, I
| > | can try to support remotely.
| > |
| > | Cheers,
| > | Doru
| > |
| > |
| > | > Thanks in advance,
| > | >
| > | > Dale
| > |
| > |
| > |
| > | --
| > | www.tudorgirba.com
| > |
| > | "Every thing has its own flow"
| > |
|
|
|
| --
| www.tudorgirba.com
|
| "Every thing has its own flow"
|

Doru,

With the release of the Preview we can start looking at Moose ...

I guess there are two parts:

  - use of scripting api
  - use of git guthub

If you load up the Metacello Preview release you can start using the scripting api in your day to day development. As an example, here's your run test scripts recast to use the scripting api and use the currently loaded version instead of a fixed (assumed) version:

"Run the Moose Tests"
packages := Set new.
"use the version that is currently loaded in image)
version := (Metacello image
    configuration: 'Moose';
    list) version.
(version
        packagesForSpecNamed: 'Tests')
        do: [ :spec | packages add: spec name ].
version projects do: [:each |
        each name = 'Filesystem' ifFalse: [
                (each version packagesForSpecNamed: 'Tests') do: [:spec |
                        packages add: spec name ]]].
HDTestReport runPackages: (packages asSortedCollection: [:a :b | a < b
]) asOrderedCollection.

Running tests is a common operation and it might make sense to to do something along the lines of:

  Metacello image
    configuration: 'Moose';
    test.

but it's obvious from your example that some filtering is called for so something like the following might be better and more general:

  packages := Metacello image
    configuration: 'Moose';
    projects: [:proj | proj name ~= 'Filesystem'];
    packages: [:pkg | true];
    groups: [:group | group name = 'Tests'];
    list.
  HDTestReport runPackages:
    (packages asSortedCollection: [:a :b | a < b]) asOrderedCollection.

What I'm getting at here is that there are probably some very common patterns that folks use in scripts that could be encoded in a much cleaner fashion ...

Regarding git, I really think that Moose development would be enhanced by going to git. The notion of doing development on the bleedingEdge is right up git's alley. With git the Metacello configuration management is greatly simplified as you no longer have to mess updating mcz file versions. Use a BaselineOf for development and use the ConfigurationOf to publish new versions of the project which involves wrapping a git commit (SHA or tag) in Metacello "clothing". The github collaboration features could be real useful as well.

It would be relatively easy to run a little pilot project using git/github for Moose and if the pilot doesn't pan out, the development can easily be moved back to mcz land ...

In the end it's up to you.

Dale


----- Original Message -----
| From: "Tudor Girba" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, July 24, 2012 1:36:42 AM
| Subject: Re: [Metacello] Moose and Metacello scripting API
|
| So, how do we proceed?
|
| Doru
|
|
| On Wed, Jul 18, 2012 at 4:09 PM, Dale Henrichs <[hidden email]>
| wrote:
| > Doru,
| >
| > Excellent! You provided exactly the information I was looking for
| > and you'll keep me from splashing around too much.
| >
| > I selected all of the tests that came in during the load so no
| > doubt I was running tests for non-Moose projects.
| >
| > I'm in the final phases of getting the scripting api functional and
| > ready for a preview release   and I want to make sure that Moose
| > will not be negatively impacted... Once I'm comfortable I will
| > appreciate it if you could start using the preview release for
| > your development activities, so I can get feedback from real users
| > ...
| >
| > I'll also be interested to gauge your interest in using git/github
| > for Moose. Your development model of working on the bleeding edge
| > fits very well with git/github. One of the nasty little chores of
| > constantly having to update the mcz file version in the config
| > file (for every project) is completely eliminated when you use
| > git/github ... you only need to supply a single commit SHA to tag
| > a project release....As I said, I plan to set up some sample
| > git/github projects using Moose so that I can hammer on
| > Metacello...
| >
| > If you're not coming to ESUG, then we won't have to wait til then
| > to get busy:) We'll have to plan on skyping...
| >
| > Thanks,
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: "Tudor Girba" <[hidden email]>
| > | To: [hidden email]
| > | Sent: Wednesday, July 18, 2012 3:11:37 AM
| > | Subject: Re: [Metacello] Moose and Metacello scripting API
| > |
| > | Hi Dale,
| > |
| > | Great news!
| > |
| > | See my replies inline.
| > |
| > | On Wed, Jul 18, 2012 at 2:39 AM, Dale Henrichs
| > | <[hidden email]>
| > | wrote:
| > | > I just finished doing a load of Moose into Pharo1.4-14421 using
| > | > the
| > | > following expression:
| > | >
| > | >   Metacello new
| > | >     configuration: 'Moose';
| > | >     version: 'default';
| > | >     squeaksource: 'Moose';
| > | >     load.
| > | >
| > | > I'm happy that the load completed without barfing, but when I
| > | > ran
| > | > the rests I got the following results:
| > | >
| > | >   7075 run, 6946 passes, 26 expected failures, 90 failures, 13
| > | >   errors, 0 unexpected passes
| > | >
| > | > At the moment I don't whether this result is expected or not...
| > |
| > | It seems that you are running all Pharo tests. I cannot reproduce
| > | those exact numbers right now (probably because my image also has
| > | other artifacts in there).
| > |
| > | But, for reference, we should only run the Moose related tests.
| > | Here
| > | is the snippet we use at the moment on the continuous integration
| > | server:
| > | http://ci.moosetechnology.org/job/moose-latest-dev/
| > |
| > | "Run the Moose Tests"
| > | packages := Set new.
| > | ((ConfigurationOfMoose new project version: 'default')
| > |         packagesForSpecNamed: 'Tests')
| > |         do: [ :spec | packages add: spec name ].
| > | (ConfigurationOfMoose new project version: 'default') projects
| > | do:
| > | [:each |
| > |         each name = 'Filesystem' ifFalse: [
| > |                 (each version packagesForSpecNamed: 'Tests') do:
| > |                 [:spec |
| > |                         packages add: spec name ]]].
| > | HDTestReport runPackages: (packages asSortedCollection: [:a :b |
| > | a <
| > | b
| > | ]) asOrderedCollection.
| > |
| > |
| > | > I'll start digging into this tomorrow, but if anyone can tell
| > | > me
| > | > whether or not this is a "normal" result, then you'll save me a
| > | > fair amount of time.
| > | >
| > | > Along these lines, I'd appreciate it if a Moose developer could
| > | > volunteer to provide me with a couple of different development
| > | > use
| > | > cases related to loading/updating images for development... I
| > | > plan
| > | > to try doing upgrades from version 4.0 to version 4.1 to
| > | > version
| > | > 4.2, but a knowledgeable developer might be able to tell me
| > | > that
| > | > that kind of upgrade path isn't expected to work and point at a
| > | > more reasonable upgrade path ...
| > | > there are couple of new features (`lock` and `upgrade`commands
| > | > as
| > | > well as `onUpgrade:` and blocks) in the scripting api that
| > | > might
| > | > address upgrade problems, but without intimate knowledge of
| > | > what
| > | > should and shouldn't work I'd just be flopping around ...
| > |
| > | Essentially, for Moose, we mostly have only one development
| > | scenario:
| > | - load the latest baseline
| > | - develop locally
| > | - commit the code changes for each package
| > | - when a good enough situation is reached, create a configuration
| > | version
| > | (ideally, this last step would also be created by the continuous
| > | integration step)
| > |
| > |
| > | > I expect to do some trial runs pushing Moose and Glamour
| > | > (additonal
| > | > nominations for other projects welcome) out to Github to see
| > | > how
| > | > the fetch times might be sped up. With git and github all of
| > | > the
| > | > packages in a single repository are downloaded at once (instead
| > | > of
| > | > one package at a time with mcz repositories) and that might
| > | > have a
| > | > dramatic impact on load times ... or not:)
| > | >
| > | > With ESUG coming up it would be nice if I could get some
| > | > groundwork
| > | > laid with some Moose developers so that we could address any
| > | > meaty
| > | > issues face to face at ESUG ...
| > |
| > | I wish I could come to ESUG, but I cannot this year.
| > | Nevertheless, I
| > | can try to support remotely.
| > |
| > | Cheers,
| > | Doru
| > |
| > |
| > | > Thanks in advance,
| > | >
| > | > Dale
| > |
| > |
| > |
| > | --
| > | www.tudorgirba.com
| > |
| > | "Every thing has its own flow"
| > |
|
|
|
| --
| www.tudorgirba.com
|
| "Every thing has its own flow"
|

Hi Dale,

Thanks a lot for the persistence :). I am definitely interested in exploring this route. I am a bit tight up with work and with traveling for the next 2 weeks, but afterwards I will try to allocate some time and get back to you.

Cheers,
Doru


On 1 Aug 2012, at 16:36, Dale Henrichs wrote:

--
www.tudorgirba.com

"Live like you mean it."

Excellent ... sounds like a plan ... although I think 2 weeks will put me up against ESUG ... but let's plan to get started then anyway...

Dale

----- Original Message -----
| From: "Tudor Girba" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, August 1, 2012 12:47:23 PM
| Subject: Re: [Metacello] Moose and Metacello scripting API
|
| Hi Dale,
|
| Thanks a lot for the persistence :). I am definitely interested in
| exploring this route. I am a bit tight up with work and with
| traveling for the next 2 weeks, but afterwards I will try to
| allocate some time and get back to you.
|
| Cheers,
| Doru
|
|
| On 1 Aug 2012, at 16:36, Dale Henrichs wrote:
|
| > Doru,
| >
| > With the release of the Preview we can start looking at Moose ...
| >
| > I guess there are two parts:
| >
| >  - use of scripting api
| >  - use of git guthub
| >
| > If you load up the Metacello Preview release you can start using
| > the scripting api in your day to day development. As an example,
| > here's your run test scripts recast to use the scripting api and
| > use the currently loaded version instead of a fixed (assumed)
| > version:
| >
| > "Run the Moose Tests"
| > packages := Set new.
| > "use the version that is currently loaded in image)
| > version := (Metacello image
| >    configuration: 'Moose';
| >    list) version.
| > (version
| >        packagesForSpecNamed: 'Tests')
| >        do: [ :spec | packages add: spec name ].
| > version projects do: [:each |
| >        each name = 'Filesystem' ifFalse: [
| >                (each version packagesForSpecNamed: 'Tests') do:
| >                [:spec |
| >                        packages add: spec name ]]].
| > HDTestReport runPackages: (packages asSortedCollection: [:a :b | a
| > < b
| > ]) asOrderedCollection.
| >
| > Running tests is a common operation and it might make sense to to
| > do something along the lines of:
| >
| >  Metacello image
| >    configuration: 'Moose';
| >    test.
| >
| > but it's obvious from your example that some filtering is called
| > for so something like the following might be better and more
| > general:
| >
| >  packages := Metacello image
| >    configuration: 'Moose';
| >    projects: [:proj | proj name ~= 'Filesystem'];
| >    packages: [:pkg | true];
| >    groups: [:group | group name = 'Tests'];
| >    list.
| >  HDTestReport runPackages:
| >    (packages asSortedCollection: [:a :b | a < b])
| >    asOrderedCollection.
| >
| > What I'm getting at here is that there are probably some very
| > common patterns that folks use in scripts that could be encoded in
| > a much cleaner fashion ...
| >
| > Regarding git, I really think that Moose development would be
| > enhanced by going to git. The notion of doing development on the
| > bleedingEdge is right up git's alley. With git the Metacello
| > configuration management is greatly simplified as you no longer
| > have to mess updating mcz file versions. Use a BaselineOf for
| > development and use the ConfigurationOf to publish new versions of
| > the project which involves wrapping a git commit (SHA or tag) in
| > Metacello "clothing". The github collaboration features could be
| > real useful as well.
| >
| > It would be relatively easy to run a little pilot project using
| > git/github for Moose and if the pilot doesn't pan out, the
| > development can easily be moved back to mcz land ...
| >
| > In the end it's up to you.
| >
| > Dale
| >
| >
| > ----- Original Message -----
| > | From: "Tudor Girba" <[hidden email]>
| > | To: [hidden email]
| > | Sent: Tuesday, July 24, 2012 1:36:42 AM
| > | Subject: Re: [Metacello] Moose and Metacello scripting API
| > |
| > | So, how do we proceed?
| > |
| > | Doru
| > |
| > |
| > | On Wed, Jul 18, 2012 at 4:09 PM, Dale Henrichs
| > | <[hidden email]>
| > | wrote:
| > | > Doru,
| > | >
| > | > Excellent! You provided exactly the information I was looking
| > | > for
| > | > and you'll keep me from splashing around too much.
| > | >
| > | > I selected all of the tests that came in during the load so no
| > | > doubt I was running tests for non-Moose projects.
| > | >
| > | > I'm in the final phases of getting the scripting api functional
| > | > and
| > | > ready for a preview release   and I want to make sure that
| > | > Moose
| > | > will not be negatively impacted... Once I'm comfortable I will
| > | > appreciate it if you could start using the preview release for
| > | > your development activities, so I can get feedback from real
| > | > users
| > | > ...
| > | >
| > | > I'll also be interested to gauge your interest in using
| > | > git/github
| > | > for Moose. Your development model of working on the bleeding
| > | > edge
| > | > fits very well with git/github. One of the nasty little chores
| > | > of
| > | > constantly having to update the mcz file version in the config
| > | > file (for every project) is completely eliminated when you use
| > | > git/github ... you only need to supply a single commit SHA to
| > | > tag
| > | > a project release....As I said, I plan to set up some sample
| > | > git/github projects using Moose so that I can hammer on
| > | > Metacello...
| > | >
| > | > If you're not coming to ESUG, then we won't have to wait til
| > | > then
| > | > to get busy:) We'll have to plan on skyping...
| > | >
| > | > Thanks,
| > | >
| > | > Dale
| > | >
| > | > ----- Original Message -----
| > | > | From: "Tudor Girba" <[hidden email]>
| > | > | To: [hidden email]
| > | > | Sent: Wednesday, July 18, 2012 3:11:37 AM
| > | > | Subject: Re: [Metacello] Moose and Metacello scripting API
| > | > |
| > | > | Hi Dale,
| > | > |
| > | > | Great news!
| > | > |
| > | > | See my replies inline.
| > | > |
| > | > | On Wed, Jul 18, 2012 at 2:39 AM, Dale Henrichs
| > | > | <[hidden email]>
| > | > | wrote:
| > | > | > I just finished doing a load of Moose into Pharo1.4-14421
| > | > | > using
| > | > | > the
| > | > | > following expression:
| > | > | >
| > | > | >   Metacello new
| > | > | >     configuration: 'Moose';
| > | > | >     version: 'default';
| > | > | >     squeaksource: 'Moose';
| > | > | >     load.
| > | > | >
| > | > | > I'm happy that the load completed without barfing, but when
| > | > | > I
| > | > | > ran
| > | > | > the rests I got the following results:
| > | > | >
| > | > | >   7075 run, 6946 passes, 26 expected failures, 90 failures,
| > | > | >   13
| > | > | >   errors, 0 unexpected passes
| > | > | >
| > | > | > At the moment I don't whether this result is expected or
| > | > | > not...
| > | > |
| > | > | It seems that you are running all Pharo tests. I cannot
| > | > | reproduce
| > | > | those exact numbers right now (probably because my image also
| > | > | has
| > | > | other artifacts in there).
| > | > |
| > | > | But, for reference, we should only run the Moose related
| > | > | tests.
| > | > | Here
| > | > | is the snippet we use at the moment on the continuous
| > | > | integration
| > | > | server:
| > | > | http://ci.moosetechnology.org/job/moose-latest-dev/
| > | > |
| > | > | "Run the Moose Tests"
| > | > | packages := Set new.
| > | > | ((ConfigurationOfMoose new project version: 'default')
| > | > |         packagesForSpecNamed: 'Tests')
| > | > |         do: [ :spec | packages add: spec name ].
| > | > | (ConfigurationOfMoose new project version: 'default')
| > | > | projects
| > | > | do:
| > | > | [:each |
| > | > |         each name = 'Filesystem' ifFalse: [
| > | > |                 (each version packagesForSpecNamed: 'Tests')
| > | > |                 do:
| > | > |                 [:spec |
| > | > |                         packages add: spec name ]]].
| > | > | HDTestReport runPackages: (packages asSortedCollection: [:a
| > | > | :b |
| > | > | a <
| > | > | b
| > | > | ]) asOrderedCollection.
| > | > |
| > | > |
| > | > | > I'll start digging into this tomorrow, but if anyone can
| > | > | > tell
| > | > | > me
| > | > | > whether or not this is a "normal" result, then you'll save
| > | > | > me a
| > | > | > fair amount of time.
| > | > | >
| > | > | > Along these lines, I'd appreciate it if a Moose developer
| > | > | > could
| > | > | > volunteer to provide me with a couple of different
| > | > | > development
| > | > | > use
| > | > | > cases related to loading/updating images for development...
| > | > | > I
| > | > | > plan
| > | > | > to try doing upgrades from version 4.0 to version 4.1 to
| > | > | > version
| > | > | > 4.2, but a knowledgeable developer might be able to tell me
| > | > | > that
| > | > | > that kind of upgrade path isn't expected to work and point
| > | > | > at a
| > | > | > more reasonable upgrade path ...
| > | > | > there are couple of new features (`lock` and
| > | > | > `upgrade`commands
| > | > | > as
| > | > | > well as `onUpgrade:` and blocks) in the scripting api that
| > | > | > might
| > | > | > address upgrade problems, but without intimate knowledge of
| > | > | > what
| > | > | > should and shouldn't work I'd just be flopping around ...
| > | > |
| > | > | Essentially, for Moose, we mostly have only one development
| > | > | scenario:
| > | > | - load the latest baseline
| > | > | - develop locally
| > | > | - commit the code changes for each package
| > | > | - when a good enough situation is reached, create a
| > | > | configuration
| > | > | version
| > | > | (ideally, this last step would also be created by the
| > | > | continuous
| > | > | integration step)
| > | > |
| > | > |
| > | > | > I expect to do some trial runs pushing Moose and Glamour
| > | > | > (additonal
| > | > | > nominations for other projects welcome) out to Github to
| > | > | > see
| > | > | > how
| > | > | > the fetch times might be sped up. With git and github all
| > | > | > of
| > | > | > the
| > | > | > packages in a single repository are downloaded at once
| > | > | > (instead
| > | > | > of
| > | > | > one package at a time with mcz repositories) and that might
| > | > | > have a
| > | > | > dramatic impact on load times ... or not:)
| > | > | >
| > | > | > With ESUG coming up it would be nice if I could get some
| > | > | > groundwork
| > | > | > laid with some Moose developers so that we could address
| > | > | > any
| > | > | > meaty
| > | > | > issues face to face at ESUG ...
| > | > |
| > | > | I wish I could come to ESUG, but I cannot this year.
| > | > | Nevertheless, I
| > | > | can try to support remotely.
| > | > |
| > | > | Cheers,
| > | > | Doru
| > | > |
| > | > |
| > | > | > Thanks in advance,
| > | > | >
| > | > | > Dale
| > | > |
| > | > |
| > | > |
| > | > | --
| > | > | www.tudorgirba.com
| > | > |
| > | > | "Every thing has its own flow"
| > | > |
| > |
| > |
| > |
| > | --
| > | www.tudorgirba.com
| > |
| > | "Every thing has its own flow"
| > |
|
| --
| www.tudorgirba.com
|
| "Live like you mean it."
|
|