GemStone/S 3.1.0.1 is shipping

[1]

GemStone/S 3.1.0.1

GemStone/S 64 3.1.0.1 was released August 28, 2012. This release fixes a number of bugs and we recommend all 3.x customers use this release. Be sure to review the release notes and install guides for this release.

GLASS 1.0-beta.8.7.3

GemStone 3.1.0.1 ships with GLASS 1.0-beta.8.7.2 pre-installed in $GEMSTONE/bin/extent0.seaside.dbf, but there are a few minor issues that show up as test failures. GLASS 1.0-beta.8.7.3 has been released to address those issues.

You should update to GLASS 1.0-.8.7.3 when you start using GemStone 3.1.0.1.

GemTools 1.0-beta.8.7

A One-Click GemTools 1.0-beta.8.7 for GemStone 3.1.0.1 can be obtained from the seaside.gemstone.com downloads page or you can download GemTools 1.0-beta.8.7 for Gemstone/S 3.1.0.1 all platforms directly.

You can build a custom GemTools image by following these steps on the glass db wiki.

Seaside3.0.7.1

Seaside 3.0.7.1 should be used with GemStone/S 3.1.x. There are a few critical bug fixes included in that version.

Download and Installation

You can download the binaries from ftp://ftp.gemstone.com/pub/GemStone64/3.1.0.1, use the installGemStone.sh script to download and install GemStone/S on your machine (highly recommended), or visit seaside.gemstone.com downloads page.

To use the installGemStone.sh script, your supply the GemStone version number as an argument to the script. The following downloads and installs the GemStone/S 3.1.0.1 release:

  ./installGemstone.sh 3.1.0.1

Upgrading

If you are upgrading from GemStone/S 2.x, then be sure to read my post on GemStone/S 3.1.0 first.

If you are upgrading from GemStone/S 2.x or GemStone/S 3.1.0, you still need to run through the upgrade process described in the Install Guide for (Linux or Max).

Helper Scripts for Upgrade of Seaside 3.0.7.1

Let’s say that you’ve got Seaside 3.0.7.1 installed in your GemStone/S 3.1.0 repository. According to the upgrade instructions you will need to define the BootstrapApplicationLoadSpecs for your application. For Seaside 3.0.7.1, that means you’ll run the following topaz script BEFORE running the upgradeSeasideImage.sh script:

The important bits are that you are specifying GLASS 1.0-beta.8.7.3 and specifying the <path to seaside cache repository>. The seaside cache repository is a directory on your machine where you’ve stashed all of the mcz files needed to reload Seaside 3.0.7.1 into your upgraded repository. You can use the following script to create the seaside cache repository:

Finally, as noted in Issue 354, you need to reload the ConfigurationOfGLASS and ConfgurationOfSeaside30:

—–

[1] http://www.flickr.com/photos/gatesfoundation/5076533520 / CC BY-NC-ND 2.0

Practical Git for Smalltalk: STIC 2012

The video of my STIC 2012 talk “Practical Git for Smalltalk” is available. You can view the slides on SlideRocket or as pdf.

Photo by http://www.flickr.com/photos/unavoidablegrain/3277754772 / CC BY-NC-SA 2.0

Metacello 1.0-beta.31.1.5 brewed

[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 http://www.flickr.com/photos/avcellshots/4299303654 / CC BY-NC 2.0