You are currently browsing the category archive for the ‘Metacello’ category.

Rocco plays light celloJust released Metacello Preview 1.0.0-beta.32.8 with a handful of bug fixes.

The primary bugfix addresses a Metacello locking issue brought up by Guido Chari.

For more info on Metacello locking:

Metacello new
  configuration: 'MyProject';
  version: #'bleedingEdge';

See the Metacello Preview docs up on GitHub.

Photo by / CC BY 2.0

Brewing with JP and Stanley[1]

After a visit to Belgium, I suppose it is appropriate to try to do a little brewing of your own. Metacello 1.0-beta.31.1.5 is a balanced release with tangy Seaside overtones, a hint of Chile and a nutty Belgian finish.

The Seaside3.1 notes were supplied by Philippe Marschall who was brewing the Seaside 3.1 configuration during ESUG. Philippe ran into a nasty bug (Issue #111) involving nested version imports. He also pointed out that it would be very nice if the for:do: method would take an attribute list as an argument (Issue #110).

The nutty Belgian is of course Johan Brichau who pointed out that versions generated by the toolbox from a baseline can have empty package versions that require manual intervention (Issue #115).  The Chilean hint came from Alexandre Bergel who had reported this particular bug earlier.

Complete ingredient list:

  • Issue 69 – MetacelloConfigurationTutorial undefined reference to ToolSet
  • Issue 73 – update Metacello-MC to a version which adds custom project attribute support to MetacelloConfigTemplate
  • Issue 110 – allow attribute lists in #for:do: statementes
  • Issue 111 – nested `version:imports:` cause trouble (1.0-beta.31.1.5)
  • Issue 114 – get all of the unit tests passing
  • Issue 115 – Version generated from a baseline can have empty package versions in a platform-specific section
  • Issue 129 – deployment scripts

Metacello Preview 1.0.0-beta.32.3

Version 1.0.0-beta.32.3 keeps the Metacello Preview  in sync with 1.0-beta.31.1.5. I’m looking for feedback from some real users before releasing the Metacello Scripting API.  If you are interested in taking the Metacello Scripting API for a spin, follow the installation instructions and provide feedback on the Metacello issues list.

If you’re already using the Preview, then the following expression will upgrade your image to the new version:

Nested Version Imports

It turns out that using nested `version:imports:` is a pretty cool technique for partitioning large projects into smaller, more manageable pieces without having to resort to separate configurations for each sub-project.

The technique involves creating a common baseline that specifies the common packages used by all of the sub-projects. For each sub-project a baseline that imports the common baseline and a literal version that imports the sub-project baseline is defined. Finally a common literal version is defined and it imports all of the sub-project versions.

For Seaside3.1 `3.1.0-common-baseline` is the common baseline:

`3.1.0-filesystem-baseline` is the sub-project baseline for the FileSystem sub-project:

`3.1.0-filesystem` is the sub-project version for the FileSystem sub-project:

`3.1.0` is the common version with an import for each of the Seaside3.1 sub-projects:

Attribute list for #for:do: method

If you create enough configurations, especially if you are doing cross-platform work, you are bound to come across the situation where you have two identical #for:do: that cannot be combined. In this example the #squeak and #pharo1.x blocks are identical, but because there is no single attribute that includes both #squeak and #pharo1.x while excluding #pharo2.x you are forced to duplicate the blocks in the spec:

With 1.0-beta.31.1.5, you can use a list of attributes to consolidate duplicate #fordo: blocks:

Empty package versions after version generation from baseline

If you use the MetacelloToolBox to create versions from baselines, you may have noticed that occasionally you’ll get some illegal versions created where the mcz version is a blank string or the version is completely missing. Up until now the only solution was to hand edit the newly created version … Jeez! Why use a tool to generate the version if you have to edit by hand!

If you have a baseline that looks like the following:

where the GoferFoo package is specified in the #common section and the #nested section, and you used the following to generate a version method:

you could end up with the following:

with the GoferFoo package correctly specified in the #common section and an empty mcz version for the GoferFoo package in the #nested section.

With the bugfix, instead of leaving the mcz file for the packages empty, the MetacelloToolBox deletes the unnecessary package expression which results in the following:


[1] Photo by / CC BY-NC 2.0

Icy InstrumentsSean DeNigris has a cool post on using the Metacello ToolBox:

Writing configurations by hand can be a drag. But fear not! Dale and Co. have created an API to facilitate your workflow.

Photo by> / CC BY-NC-ND 2.0

City of London: 122 Leadenhall Street, 'The Cheesegrater'Mariano Martinez Peck writes about how he uses Metacello to create his own development images:

I spend a lot of time building my own images.

If I am downloading hundred of images every day, an image can last me a maximum of a couple of days, and I spend a lot of time building my own images, then there is something that it is not working.

Moreover, I am lazy, I don’t like loosing time with it, and my memory is bad. Hence, I have come to the solution that I will show you in this post.

Photo by / CC BY 2.0

Ready to surface![1]

Metacello 1.0-beta.31 has been released. The primary motivation for the release is support for GLASS 1.0-beta.8.7:

  • Use Gofer which addresses some GemStone problems.
  • GemStone  variant of the fix for Pharo Issue 4613: programmatic calculation of platform attributes.

and change that affects the sort order for branched Monticello packages:

In previous versions, the branch name took precedence over the version number when sorting Monticello packages. This had the effect of preventing branched Monticello packages from being loaded on top of a non-branched Monticello package which is not correct. Moving forward the version number takes precedence over the branch name and the branch name is only used to break a version number tie.


[1] Photo by / CC BY-NC-ND 2.0

On The Beach c1900I just finished updating the Metacello configurations for Seaside 2.8, Magritte 1.0 and Pier 1.0. I’ve tested the configurations in Pharo 1.0 and GLASS 1.0-beta.87 running against GemStone 2.3 (i.e., the appliance).

The change log for the most recent Seaside2.8 checkins indicates that Seaside2.8 should run in Pharo 1.3, but I haven’t tested in that environment. In a comment, Lukas confirms that Seaside2.8 runs in Pharo 1.3. You can download images from the Lukas’ continuation integration server.

If you want to run the latest configurations of Seaside2.8 and friends in the appliance, then follow the update instructions on Getting Started with GLASS.

Photo by / CC BY-NC-SA 2.0

Containers on deck[1]

When you have a bunch of packages that you need to transfer between repositories, you can use Metacello and Gofer to simplify the task.

With the SS3 repository coming on-line, I decided to move tODE development to it’s own repository on SS3. The scripts that I wrote turned out to be pretty simple, but not necessarily obvious, so I thought that they’d be worth sharing.

The basic idea is to use Metacello to identify the packages that you want to transfer and use Gofer fetch to download the selected packages from the source repository into the local cache. Then use Gofer push to upload the packages from the local cache to the target repository.

In my case I want to transfer all versions of the packages used in tODE 0.1:

| gofer |
"Identify the source repository"
gofer := Gofer new gemsource: 'Naviode';
	package: 'ConfigurationOftODE' yourself.
"Traverse all packages defined in version '0.1' of the tODE configuration"
(ConfigurationOftODE project version: '0.1') packages do:[:spec |
	"Use the #name and #package: messages and Gofer will fetch 
	all versions of the Monticello package"
	gofer package: spec name ].
"Initiate the download with the #fetch command"
gofer fetch.

After the above expression completes, I can then initiate the upload:

| gofer |
"Identify the target repository"
gofer := Gofer new url: '';
	package: 'ConfigurationOftODE' yourself.
"Use the same algorithm for identifying the packages to be pushed"
(ConfigurationOftODE project version: '0.1') packages do:[:spec |
	gofer package: spec name ].
"Initiate the upload with the #push command"
gofer push.

If you want to transfer only the latest versions of the packages, substitute the following expression in the above scripts:

"Traverse all packages defined in version '0.1' of the tODE configuration"
(ConfigurationOftODE project version: '0.1') packages do:[:spec |
	"Use the #file and the #version: messages and Gofer will fetch
	only the specified version of the Monticello package"
	gofer version: spec file ].


[1] Photo by / CC BY-NC-SA 2.0

running with the seagulls[1]

Metacello 1.0-beta.30 was released this afternoon. This release has a couple of bugfixes and some more significant performance improvements.


  • Pharo1.4 support (build 14124 or later). tests pass, but ProfStef apparently has not been ported. Based on fix for Pharo Issue 4613
  • another round of performance improvements with significant speedups for #currentVersion, #project, #versionStatus and friends
  • tweak MetacelloToolBox class>>saveModifiedPackagesAndConfigurationIn:description: so that description is updated when your package updates are needed.
  • persistent author initials can be set by defining #’GS_tODE_AuthorInitials’ in UserGlobals with desired author initials string (in support of tODE). GemStone only
  • allow configuration branches to be used in a project reference (className: is name sans branch, file: is name with branch)


  • fix  Issue 136 : load of referenced project can fail with missing version error
  • fix  Issue 146 : unrecognized SystemVersion results in assuming system is on #gemstone…

If you already have an earlier version of Metacello loaded, evaluate the following expression to upgrade to 1.0-beta.30:

ConfigurationOfMetacello project updateProject.
(ConfigurationOfMetacello project version: '1.0-beta.30') load.

Metacello 1.0-beta.30 was tested against:

  • PharoCore-1.0
  • PharoCore-1.1.2
  • PharoCore-1.2
  • PharoCore-1.3-13299
  • PharoCore-1.4-14126
  • Squeak4.2
  • GLASS 1.0beta.8.6


[1] Photo by / CC BY-SA 2.0

OfflineJoachim Tuchel has a nice writeup on how to use Metacello when you have limited access to the internet:

I needed to get Seaside and some other stuff into a Pharo image on a machine at a place where there is very limited offline access….

Photo by / CC BY-SA 2.0


Metacello 1.0-beta.29 was released earlier today. This release includes a number of bugfixes and performance improvements.


  • SIGNIFICANT speedup for load/fetch/currentVersion operations. More caching and better algorithms.
  • Warn about newer versions in repository. MetacelloToolBox class>>saveModifiedDevelopmentPackages:for:description:.
  • MetacelloBrowser support.
  • experimental support for branching configurations (mcz level branch)

Bugs fixed:

  • fix Issue 108: Need to update Metacello (tests and Gofer config) to integrate changes from Pharo Issue 3660
  • fix Issue 112: direct version load (upgrade) of config doesn”t update already loaded mcz files
  • fix Issue 115: Invalid method construction by toolbox
  • fix Issue 118: dirty package after merge skews currentVersion calculation
  • fix Issue 120: lessons methods disapppeared in Metacello-Tutorial-DaleHenrichs.24
  • fix Issue 122: misleading error message regarding stable versions
  • fix Issue 123: broken development scenario

If you already have an earlier version of Metacello loaded, evaluate the following expression to upgrade to 1.0-beta.29:

ConfigurationOfMetacello project updateProject.
(ConfigurationOfMetacello project version: '1.0-beta.29') load.

Metacello 1.0-beta.29 was tested against:

  • PharoCore-1.0
  • PharoCore-1.1.2
  • PharoCore-1.2.2-12353
  • PharoCore-1.3a
  • Squeak4.2
  • GLASS 1.0beta.8.6


[1] Photo by / CC BY 2.0

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 445 other followers


RSS GLASS updates

  • An error has occurred; the feed is probably down. Try again later.

RSS Metacello Updates

  • An error has occurred; the feed is probably down. Try again later.

RSS Twitterings

  • An error has occurred; the feed is probably down. Try again later.
February 2017
« May