Smalltalk/X port of Metacello

Hi,

I've just ported Metacello-Core to Smalltalk/X. The primary SVN
repository is at:

   https://swing.fit.cvut.cz/svn/stx/goodies/metacello/

a GIT repository with Cypress export of SVN code is at:

 
https://github.com/janvrany/metacello-work/tree/1.0-beta.31.1.5_smalltalkx

There is still one method that depends on MC: MetacelloPlatform >>
#createRepository:. Quick fix I did for St/X is attached.

However, I found out that **a lot** of tests are missing in
Dale's 1.0-beta.31.1.5 branch compared to master. What's happened?


Cheers, Jan

Jan,

Great news!

The vast majority of the tests are associated with the MC packages ... when you take the mcz packages out of the equation there isn't too much to test ... The bulk of the MC tests are doing loads of test packages to test the various features.

Last week I did some work to move some of the code that deserves to be in core from MC and I ended up pushing some more tests towards core, but that work was done on the master branch and I noticed that you based your work on the 1.0-beta.31.1.5 branch. You should probably move your port to the master branch as a start.

We should start considering a generic package test layer ... a bunch of the load tests from MC could be moved into this layer. The details of the test are not specific to Monticello, but you have to have a package loader implemented to run the tests ... I would want to do this work off of the master branch.

I will also need to get busy on the new Cypress implementation ...

I am releasing Metacello 1.0-beta31.1.5 today and I've got FileTree 1.0 (the current Cypress format) queued up for release so I might not get to the new format until next week at the earliest ...

Dale
----- Original Message -----
| From: "Jan Vrany" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, September 18, 2012 7:06:55 AM
| Subject: [Metacello] Smalltalk/X port of Metacello
|
| Hi,
|
| I've just ported Metacello-Core to Smalltalk/X. The primary SVN
| repository is at:
|
|    https://swing.fit.cvut.cz/svn/stx/goodies/metacello/
|
| a GIT repository with Cypress export of SVN code is at:
|
|  
| https://github.com/janvrany/metacello-work/tree/1.0-beta.31.1.5_smalltalkx
|
| There is still one method that depends on MC: MetacelloPlatform >>
| #createRepository:. Quick fix I did for St/X is attached.
|
| However, I found out that **a lot** of tests are missing in
| Dale's 1.0-beta.31.1.5 branch compared to master. What's happened?
|
|
| Cheers, Jan
|

On 18/09/12 16:30, Dale Henrichs wrote:
> Jan,
>
> Great news!
>
> The vast majority of the tests are associated with the MC packages ... when you take the mcz packages out of the equation there isn't too much to test ... The bulk of the MC tests are doing loads of test packages to test the various features.
>

If you say so...

I tried to create very simple config like:

version0_0_1: spec
     <version: '0.0.1'>

     spec for: #common do:[
         spec package: 'stx:goodies/metacello'.
     ]


and then tried just to inspect

ConfigurationOfMetacello project version: '0.0.1'

and ended up with DNUs. I tried to naively fix them, but more appeared.
I would say this should work without any fancy MC stuff, shouldn't it?

> Last week I did some work to move some of the code that deserves to be in core from MC and I ended up pushing some more tests towards core, but that work was done on the master branch and I noticed that you based your work on the 1.0-beta.31.1.5 branch. You should probably move your port to the master branch as a start.

OK.  I'll update and try it again.


>
> We should start considering a generic package test layer ... a bunch of the load tests from MC could be moved into this layer. The details of the test are not specific to Monticello, but you have to have a package loader implemented to run the tests ... I would want to do this work off of the master branch.
>
> I will also need to get busy on the new Cypress implementation ...

:-) Yes. We will see how it works in real



Jan

Jan,

----- Original Message -----
| From: "Jan Vrany" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, September 18, 2012 8:44:47 AM
| Subject: Re: [Metacello] Smalltalk/X port of Metacello
|
| On 18/09/12 16:30, Dale Henrichs wrote:
| > Jan,
| >
| > Great news!
| >
| > The vast majority of the tests are associated with the MC packages
| > ... when you take the mcz packages out of the equation there isn't
| > too much to test ... The bulk of the MC tests are doing loads of
| > test packages to test the various features.
| >
|
| If you say so...
|
| I tried to create very simple config like:
|
| version0_0_1: spec
|      <version: '0.0.1'>
|
|      spec for: #common do:[
|          spec package: 'stx:goodies/metacello'.
|      ]
|
|
| and then tried just to inspect
|
| ConfigurationOfMetacello project version: '0.0.1'
|
| and ended up with DNUs. I tried to naively fix them, but more
| appeared.
| I would say this should work without any fancy MC stuff, shouldn't
| it?

Packages are not part of the Core ... which is probably part of why you are getting the DNU's .... the implementation of  MetacelloPackageSpec is very skewed towards Monticello so it is in the MC package ...

The core includes projects and groups so if you pick up my recent work off the master branch you'll be able to create a spec that looks like the following:

baseline0_0_1: spec
     <version: '0.0.1-baseline'>

     spec for: #common do:[
         spec blessing: #baseline.
         spec project: 'Seaside' with: [
           spec
             className: 'ConfigurationOfSeaside';
             versionString: #stable ].
         spec group: 'Core' with: #('Seaside').
     ]

and this should work ... just no packages ...

At ESUG when I said that I didn't like the split that I had ... The package spec is one of the areas that may or may not have some commonality ... I found quite a bit that could be moved from MC to Core for projects, but not being familiar with your needs for packages, I wasn't able to see much commonality ... off the bat ... looking at your implementation of packages may reveal some common code ...

|
| > Last week I did some work to move some of the code that deserves to
| > be in core from MC and I ended up pushing some more tests towards
| > core, but that work was done on the master branch and I noticed
| > that you based your work on the 1.0-beta.31.1.5 branch. You should
| > probably move your port to the master branch as a start.
|
| OK.  I'll update and try it again.

I made quite a few changes moving code from MC to Core and added about 25 tests, so you should have a better experience out of the box using the master branch

|
|
| >
| > We should start considering a generic package test layer ... a
| > bunch of the load tests from MC could be moved into this layer.
| > The details of the test are not specific to Monticello, but you
| > have to have a package loader implemented to run the tests ... I
| > would want to do this work off of the master branch.
| >
| > I will also need to get busy on the new Cypress implementation ...
|
| :-) Yes. We will see how it works in real

I'm looking forward to it!...

Dale,

On 18/09/12 21:51, Dale Henrichs wrote: Ah...I see.

Ok, that means I have to bake this cake completely myself :-)

What I basically need is to "resolve" whole project spec into flat
(ideally topologically ordered) list of package thingies
(say MetacelloStXPackage) with all the properties.

While I can imagine how and where to hook in my MetacelloStXPackage
and MetacelloStXPackageSpec, I've got lost how and where to get
the list (or something from which I can easily construct such a list)

Maybe you can give me some pointers - classnames where to start
reading should be enough...

A switched to master. Much better. All 101 test pass. Thanks.

Best, Jan

----- Original Message -----
| From: "Jan Vrany" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, September 18, 2012 4:00:45 PM
| Subject: Re: [Metacello] Smalltalk/X port of Metacello
|
| Dale,
|
| On 18/09/12 21:51, Dale Henrichs wrote:
| > Jan,
| >
| > ----- Original Message -----
| > | From: "Jan Vrany" <[hidden email]>
| > | To: [hidden email]
| > | Sent: Tuesday, September 18, 2012 8:44:47 AM
| > | Subject: Re: [Metacello] Smalltalk/X port of Metacello
| > |
| > | On 18/09/12 16:30, Dale Henrichs wrote:
| > | > Jan,
| > | >
| > | > Great news!
| > | >
| > | > The vast majority of the tests are associated with the MC
| > | > packages
| > | > ... when you take the mcz packages out of the equation there
| > | > isn't
| > | > too much to test ... The bulk of the MC tests are doing loads
| > | > of
| > | > test packages to test the various features.
| > | >
| > |
| > | If you say so...
| > |
| > | I tried to create very simple config like:
| > |
| > | version0_0_1: spec
| > |      <version: '0.0.1'>
| > |
| > |      spec for: #common do:[
| > |          spec package: 'stx:goodies/metacello'.
| > |      ]
| > |
| > |
| > | and then tried just to inspect
| > |
| > | ConfigurationOfMetacello project version: '0.0.1'
| > |
| > | and ended up with DNUs. I tried to naively fix them, but more
| > | appeared.
| > | I would say this should work without any fancy MC stuff,
| > | shouldn't
| > | it?
| >
| > Packages are not part of the Core ... which is probably part of why
| > you are getting the DNU's .... the implementation of
| >  MetacelloPackageSpec is very skewed towards Monticello so it is
| > in the MC package ...
| >
| Ah...I see.
|
| > The core includes projects and groups so if you pick up my recent
| > work off the master branch you'll be able to create a spec that
| > looks like the following:
| >
| > baseline0_0_1: spec
| >       <version: '0.0.1-baseline'>
| >
| >       spec for: #common do:[
| >           spec blessing: #baseline.
| >           spec project: 'Seaside' with: [
| >             spec
| >               className: 'ConfigurationOfSeaside';
| >               versionString: #stable ].
| >           spec group: 'Core' with: #('Seaside').
| >       ]
| >
| > and this should work ... just no packages ...
| >
| > At ESUG when I said that I didn't like the split that I had ... The
| > package spec is one of the areas that may or may not have some
| > commonality ... I found quite a bit that could be moved from MC to
| > Core for projects, but not being familiar with your needs for
| > packages, I wasn't able to see much commonality ... off the bat
| > ... looking at your implementation of packages may reveal some
| > common code ...
|
| Ok, that means I have to bake this cake completely myself :-)

Nope, I think that we can extract out big hunks of code that you can leverage.

|
| What I basically need is to "resolve" whole project spec into flat
| (ideally topologically ordered) list of package thingies
| (say MetacelloStXPackage) with all the properties.

Yes, this bit can be extracted out ... I can take a stab at extracting out the code that you need ... it will be a combination of package code and some loader code ... you will be rolling your own loader, but I can certainly tease out the important bits ... I'm kinda busy this week tho.

|
| While I can imagine how and where to hook in my MetacelloStXPackage
| and MetacelloStXPackageSpec, I've got lost how and where to get
| the list (or something from which I can easily construct such a list)
|
| Maybe you can give me some pointers - classnames where to start
| reading should be enough...

Okay...I can do that ... I'll put together a method/class reading list with the important bits about producing the ordered list of packages ... should be able to have it for you tomorrow morning.


|
| >
| > |
| > | > Last week I did some work to move some of the code that
| > | > deserves to
| > | > be in core from MC and I ended up pushing some more tests
| > | > towards
| > | > core, but that work was done on the master branch and I noticed
| > | > that you based your work on the 1.0-beta.31.1.5 branch. You
| > | > should
| > | > probably move your port to the master branch as a start.
| > |
| > | OK.  I'll update and try it again.
| >
| > I made quite a few changes moving code from MC to Core and added
| > about 25 tests, so you should have a better experience out of the
| > box using the master branch
| >
|
| A switched to master. Much better. All 101 test pass. Thanks.

Oh good!

Dale

Dale,

That would be great. Once I get the list, my "loader" will do the rest.

No rush! I'll hardly have a time for Metacello next week, so no need for
that tomorrow! I guess you have better things to do...

Jan

Jan,

I decided to take a quick look and then put together a little guide for you[1]. I thought I'd end up with more method links than I did ... it actually looks like getting the load order for your packages will be pretty straight forward ... When I moved the methods up from the MC packages to Core I pushed most of the stuff that you need except a couple of methods that you need for your own package spec and a couple of methods for your version spec ... the rest of the stuff will be occupied by your customizations for your loader ...

Dale

[1] https://gist.github.com/3746823

----- Original Message -----
| From: "Jan Vrany" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, September 18, 2012 4:47:46 PM
| Subject: Re: [Metacello] Smalltalk/X port of Metacello
|
| Dale,
|
| > | >
| > | > At ESUG when I said that I didn't like the split that I had ...
| > | > The
| > | > package spec is one of the areas that may or may not have some
| > | > commonality ... I found quite a bit that could be moved from MC
| > | > to
| > | > Core for projects, but not being familiar with your needs for
| > | > packages, I wasn't able to see much commonality ... off the bat
| > | > ... looking at your implementation of packages may reveal some
| > | > common code ...
| > |
| > | Ok, that means I have to bake this cake completely myself :-)
| >
| > Nope, I think that we can extract out big hunks of code that you
| > can leverage.
| >
| > |
| > | What I basically need is to "resolve" whole project spec into
| > | flat
| > | (ideally topologically ordered) list of package thingies
| > | (say MetacelloStXPackage) with all the properties.
| >
| > Yes, this bit can be extracted out ... I can take a stab at
| > extracting out the code that you need ... it will be a combination
| > of package code and some loader code ... you will be rolling your
| > own loader, but I can certainly tease out the important bits ...
| > I'm kinda busy this week tho.
|
| That would be great. Once I get the list, my "loader" will do the
| rest.
|
| >
| > |
| > | While I can imagine how and where to hook in my
| > | MetacelloStXPackage
| > | and MetacelloStXPackageSpec, I've got lost how and where to get
| > | the list (or something from which I can easily construct such a
| > | list)
| > |
| > | Maybe you can give me some pointers - classnames where to start
| > | reading should be enough...
| >
| > Okay...I can do that ... I'll put together a method/class reading
| > list with the important bits about producing the ordered list of
| > packages ... should be able to have it for you tomorrow morning.
|
| No rush! I'll hardly have a time for Metacello next week, so no need
| for
| that tomorrow! I guess you have better things to do...
|
| Jan
|

----- Original Message -----
| From: "Jan Vrany" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, September 18, 2012 4:47:46 PM
| Subject: Re: [Metacello] Smalltalk/X port of Metacello
|
| Dale,
|
| > | >
| > | > At ESUG when I said that I didn't like the split that I had ...
| > | > The
| > | > package spec is one of the areas that may or may not have some
| > | > commonality ... I found quite a bit that could be moved from MC
| > | > to
| > | > Core for projects, but not being familiar with your needs for
| > | > packages, I wasn't able to see much commonality ... off the bat
| > | > ... looking at your implementation of packages may reveal some
| > | > common code ...
| > |
| > | Ok, that means I have to bake this cake completely myself :-)
| >
| > Nope, I think that we can extract out big hunks of code that you
| > can leverage.
| >
| > |
| > | What I basically need is to "resolve" whole project spec into
| > | flat
| > | (ideally topologically ordered) list of package thingies
| > | (say MetacelloStXPackage) with all the properties.
| >
| > Yes, this bit can be extracted out ... I can take a stab at
| > extracting out the code that you need ... it will be a combination
| > of package code and some loader code ... you will be rolling your
| > own loader, but I can certainly tease out the important bits ...
| > I'm kinda busy this week tho.
|
| That would be great. Once I get the list, my "loader" will do the
| rest.
|
| >
| > |
| > | While I can imagine how and where to hook in my
| > | MetacelloStXPackage
| > | and MetacelloStXPackageSpec, I've got lost how and where to get
| > | the list (or something from which I can easily construct such a
| > | list)
| > |
| > | Maybe you can give me some pointers - classnames where to start
| > | reading should be enough...
| >
| > Okay...I can do that ... I'll put together a method/class reading
| > list with the important bits about producing the ordered list of
| > packages ... should be able to have it for you tomorrow morning.
|
| No rush! I'll hardly have a time for Metacello next week, so no need
| for
| that tomorrow! I guess you have better things to do...

I have too many things that should have been done 2 weeks ago:)

Dale

Dale,

thanks a lot, that was exactly what I needed. I've fixed so
basic spec with list of packages works. Now I can focus on loader...

Thanks a lot!

Best, Jan

On 19/09/12 01:05, Dale Henrichs wrote:
> Jan,
>
> I decided to take a quick look and then put together a little guide for you[1]. I thought I'd end up with more method links than I did ... it actually looks like getting the load order for your packages will be pretty straight forward ... When I moved the methods up from the MC packages to Core I pushed most of the stuff that you need except a couple of methods that you need for your own package spec and a couple of methods for your version spec ... the rest of the stuff will be occupied by your customizations for your loader ...
>

Cool!

----- Original Message -----
| From: "Jan Vrany" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, September 18, 2012 6:44:17 PM
| Subject: Re: [Metacello] Smalltalk/X port of Metacello
|
| Dale,
|
| thanks a lot, that was exactly what I needed. I've fixed so
| basic spec with list of packages works. Now I can focus on loader...
|
| Thanks a lot!
|
| Best, Jan
|
| On 19/09/12 01:05, Dale Henrichs wrote:
| > Jan,
| >
| > I decided to take a quick look and then put together a little guide
| > for you[1]. I thought I'd end up with more method links than I did
| > ... it actually looks like getting the load order for your
| > packages will be pretty straight forward ... When I moved the
| > methods up from the MC packages to Core I pushed most of the stuff
| > that you need except a couple of methods that you need for your
| > own package spec and a couple of methods for your version spec ...
| > the rest of the stuff will be occupied by your customizations for
| > your loader ...
| >
|
|
|