[ANN] Metacello - 0.8 alpha

0 views
Skip to first unread message

Dale Henrichs

unread,
Jul 24, 2009, 6:53:31 PM7/24/09
to montice...@googlegroups.com
To get version 0.8:

1. Load Metacello-All-dkh.5 from http://seaside.gemstone.com/ss/metacello (loads
Metacello-Core, Metacello-MC, MetacelloProject and OB-Metacello - note that
Metacello-All needs to have OB loaded.

2. Execute the following expression in a workspace:

(MetacelloMetacelloProject version: '0.8') load

OR find the class MetacelloMetacelloProject in an OB class/project browser and
click on the '2. Load Project' menu item for the class and select 0.8 from the
list. the '1. Update Project' menu item can be used to load the latest version
of the Metacello-MetacalloProject package.

3. Delete the Metacello-All package.

Highlights of version 0.8:

- removed baseline feature (too complicated)
- the order of specs in the packages method is the default load order
- atomic load spans all projects being loaded (that specify atomic loading)
- savePackages and updatePackageMethods recurse through project references';
- assorted sundry UI adjustments
- tutorials updated but not as much as I want

I'm snapping off version 0.8 because Metacello is stable enough to use for our internal GLASS build process (the Finworks folks have also used Metacello for building a custom GLASS repository). As I add additional features I don't want to perturb existing users.

I was close to calling 0.8 a beta, but I decided that there were a handful of features that I still wanted to add to add for 1.0, so I'm holding off the beta designation until it's at least feature complete.

The missing features are:

- platform-specific Metacello code (in addition to #gemstone attribute, I am
using a gemstone version attribute for code that is version sensitive).
- pre/post load doits
- load latest command

That's not much, so I don't think I'm that far away from a beta...If you play with the latest 0.8, you'll notice that there is a version 0.9-dev which is of course blessed as #development which means it is unstable.

Dale

stephane ducasse

unread,
Jul 29, 2009, 10:50:41 AM7/29/09
to montice...@googlegroups.com
Dale

I do not have internet connection until next week (this email will be
sent when I will catch a free spot).
So I can only comment on what I read.
Now I have a question about postload and preload. how do we define
preload with MC packages.
I have the impression that with MC1.5 there is support for that but
each time I jump in the code
I got rejected by the code and this does not push me to naively
integrate MC extra features.

BTW do you support blessing?

Stef

Dale Henrichs

unread,
Jul 30, 2009, 3:28:44 PM7/30/09
to montice...@googlegroups.com
Stef,

I haven't looked at what is done for MC1.5. Metacello is being created because there are some features that shouldn't be integrated into Monticello. Pre/post load doits are on the borderline of whether they should be in Monticello or not. I am adding them to Metacello, because the version of Monticello that is implemented in GemStone doesn't have pre/post doits:)

Here is an example of pre/post doits. First the package definitions for 2.3:

packages23
<packages: '2.3' attribute: #'common' >

^self packagesSpec
add: 'Package1-anon.1' requires: { 'Package2'. };
add: 'Package2-anon.2' requires: { 'Package3'. };
yourself

and doits for Package1:

doits23
<doits: '2.3' attribute: #'common' >

^self doitsSpec
add: 'Package1' postLoadDoIt: ["do post load stuff"];
add: 'Package1' preLoadDoIt: ["do pre load stuff"];
yourself

The block can be a 0, 1 or 2 arg block. The first optional arg is the Metacello loader and the second optional arg is the packageSpec.

The doits are related to the package by the package name.

I separated the doits from the package definitions, because I wanted to be able to programmatically generate packages methods (having tools update the package versions is just too convenient) and trying to preserve/generate the source code for blocks was a problem I didn't want to solve.

Blessings are supported. Here's a series of version definitions for the class MetacelloExampleProject (BTW, blessings can be defined using a pragma method, so that blessings can be conditional, if needed):

version01
<version: '0.1' attribute: #'common' >

^self versionSpec
blessing: #alpha;
yourself

version02
<version: '0.2' attribute: #'common' >

^self versionSpec
blessing: #beta;
yourself

version10
<version: '1.0' attribute: #'common' >

^self versionSpec
blessing: #release;
yourself

version11
<version: '1.1-dev' attribute: #'common' >

^self versionSpec
blessing: #development;
yourself

Then to use blessings, you use the following expressions:

(MetacelloExampleProject latestVersion: #alpha) gives you version 0.1
(MetacelloExampleProject latestVersion: #release) gives you version 1.0
(MetacelloExampleProject latestVersion) gives you version 1.1-dev

There is no fixed list of blessings (yet), but I'm definitely using a convention that a blessing of #development means that the version is unstable and I've also add '-dev' in the version string to reinforce that the version is unstable. I've toyed with the idea that the blessing could be encoded/displayed in the version string, but for now, I think that a convention is good enough. I like the idea of being able to change the blessing of a version without affecting the version string....

BTW, a version of '1.1' will sort after a version of '1.1-dev'. In a version string, '.' separates numeric components and '-' denotes a string component so that a version string of '1.11' will sort after '1.9' (numeric 11 is greater than numeric 9) while '1-11' will sort before '1-9' (string '9' collates after string '11').

I _will_ be at ESUG, so I assume that we should have a Metacello meeting with all interested parties. I'll arrive in Brest on Friday before Camp Smalltalk and will leave on Sunday after the Seaside sprint, so we should be able to find time to meet.

Dale

Julian Fitzell

unread,
Jul 30, 2009, 5:53:27 PM7/30/09
to montice...@googlegroups.com
On Thu, Jul 30, 2009 at 12:28 PM, Dale
Henrichs<dale.h...@gemstone.com> wrote:
> I _will_ be at ESUG, so I assume that we should have a Metacello meeting with all interested parties. I'll arrive in Brest on Friday before Camp Smalltalk and will leave on Sunday after the Seaside sprint, so we should be able to find time to meet.

I was vaguely thinking of trying to do some MC2 at camp smalltalk.
maybe we should share a table... if we could get MC2 and metacello
loading a version of seaside while we're there, that would be work
well done. Probably optimistic though. :) I won't arrive until sat
afternoon though probably.

Julian

Dale Henrichs

unread,
Jul 31, 2009, 11:48:38 AM7/31/09
to montice...@googlegroups.com
Julian,

It's worth a shot ... ESUG would be a good time see how well MC2 fits into Metacello, since I should be in beta by then...

Dale
Reply all
Reply to author
Forward
0 new messages