I guess I was so busy preparing for my STIC talk I forgot to announce the availability of a podcast on GemTalk Systems that I did with James Robertson and David Buck. I have to say that James and David run a pretty smooth interview. It was fun and (I hope) informative.


Today GemTalk Systems announced the acquisition of the GemStone/S platform from VMware. Before anyone gets their knickers in a knot, this is a good thing:

GemTalk Systems plans to expand its 64-bit Smalltalk platform capability by designing and releasing new and innovative extensions to the core GemStone/S technology.

The entire Smalltalk team is moving intact from VMware to GemTalk Systems and I want to emphasize that both GemTalk Systems and VMware are being very generous and fair during the transition.

We are re-locating to another suite in the same office complex, up the stairs from our old location.

We are keeping all of the GemStone/S intellectual property including MagLev and all of the GemStone/S customers.

We are not keeping our old name (GemStone Systems) and we are not keeping the domain. I guess one can’t expect everything. I have also been assured that the URLs for GemSource and SS3 will continue to function for at least a year (if not longer).

From a technical perspective GemStone/S has thrived at VMware, the engineering team has been pretty much left alone and we were given all of the necessary resources to “get the job done”. From a technical and personal perspective, I have been very happy with my tenure at VMware.

On the business side, I would say that GemStone/S foundered a bit. The GemStone/S product never got fully integrated into the VMware universe (unlike GemFire), but then the GemStone/S product was not the  primary focus of the original VMware acquisition.

Now, with the GemFire team becoming part of Pivotal, you can imagine that the Smalltalk team is very happy to find a home with GemTalk Systems . 

GemTalk Systems is a privately held company led by Dan Ware.  Prior to the VMware acquisition in 2010, Dan had been an executive with GemStone Systems  for 17 years. For most of those years Dan was in charge of the Sales organization, so Dan knows the GemStone/S customer base, very well.

Dan and the investors love GemStone/S and want to see it continue to thrive.

This quote bears repeating:

GemTalk Systems plans to expand its 64-bit Smalltalk platform capability by designing and releasing new and innovative extensions to the core GemStone/S technology.

and from our transition FAQ:

Our core technology will be Smalltalk-based products, but they can provide infrastructure in other environments. We will continue to support GemBuilder for Java, and we will be revisiting MagLev for Ruby and GLASS for Seaside. New initiatives into other development areas are possible.

Frankly, I don’t think that I could have imagined a better home for GemStone/S.

Live, From New York, it's Saturday Night!On Thursday of this week (October 18, 2012), John McIntosh is giving a presentation about WorldPulse at the New York City iOS Developer Meetup.

WorldPulse is application for the iPhone and iPad, that shows live accurate cloud cover data, the day/night terminus, night lights, and in 2.0 weather data from all the weather stations in the world.

In John’s presentation:

…he will talk about the steps needed to cache, secure, and protect weather data as fetched from a data supplier for delivery to WorldPulse users.

The presentation will highlight the use of Amazon EC2 as a backend, Gemstone for the object oriented database

The meetup is hosted by Spreecast and the presentation will be live streamed as well as archived on the Spreecast site.

Photo by / CC BY-NC-ND 2.0

Turning coffee into cash[1]


GemStone/S 64 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 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

GemTools 1.0-beta.8.7

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

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


Seaside 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, use the script to download and install GemStone/S on your machine (highly recommended), or visit downloads page.

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



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

Let’s say that you’ve got Seaside 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, that means you’ll run the following topaz script BEFORE running the 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 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] / CC BY-NC-ND 2.0

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

Photo by / CC BY-NC-SA 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


GemStone 3.1.0

GemStone/S 64 3.1.0 was released July 5, 2012.GemStone/S 64 Bit 3.1.0 is a major new version, including many new features as well as enhancements to existing features and bug fixes. A quick highlight of features is as follows:

  • IPv6 support
  • multi-threaded, highly performant backup and restore
  • increased security for remote logins using SRP and SSL
  • a new hot standby interface, providing continuous automatic synchronization
  • powerful locale-specific collation using the ICU libraries
  • full support for upgrade of Seaside applications
  • API for secure SSL sockets from Smalltalk

Release notes, Install Guide and manuals are available here. Be sure to carefully read the GemStone 3.1.0 release notes, if this is the first time you have used GemStone/S 3.x as there are significant differences between GemStone3.x and GemStone 2.x.

Before attempting an upgrade  you will want to make sure that your application loads into a virgin 3.1 repository (extent0.seaside.dbf) and passes unit tests before attempting the upgrade.

GLASS 1.0-beta.8.7.2

GemStone 3.1.0 ships with GLASS 1.0-beta.8.7.2 pre-installed in $GEMSTONE/bin/extent0.seaside.dbf.

With the GemStone 3.1.0 release, there is an upgrade path from Gemstone 2.x and GemStone 3.0.1. See the Linux or Mac Install  Guide for detailed upgrade instructions.

Download and Installation

You can download the binaries from, use the script to download and install GemStone 3.1.0 on your machine(highly recommended), or visit downloads page.

Starting a 3.1.0 stone

Once you’ve installed Gemstone in /opt/gemstone/product, follow these steps to start and stop the stone:

  1. Define GEMSTONE environment variables  ($GEMSTONE/bin and $GEMSTONE/seaside/bin added to your $PATH environment variable):
    source /opt/gemstone/product/seaside/defSeaside

    It is recommended that you add this step to your .bashrc.

  2. Copy the system.conf and GLASS extent0.dbf files to data directory:
    cp $GEMSTONE/seaside/system.conf \
    chmod +w $GEMSTONE/seaside/data/system.conf
    cp $GEMSTONE/bin/extent0.seaside.dbf \
    chmod +w $GEMSTONE/seaside/data/extent0.dbf

    This step is performed as part of the script.

  3. Start netldi and stone processes:
  4. Ensure stone process is running:
    gslist -lcv
  5. Stop stone process:

Check the Starting a stone page on the glass db wiki for updates to the above procedure.

GemTools 1.0-beta.8.7

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

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


[1] / CC BY 2.0

Mosquit-glowFor those of you who are using or interested in Kaliningrad, you might want to take a look at Amber Skeleton, a project I just announced.

Where Kaliningrad is based on Seaside and Monticello, Amber Skeleton is based on Zinc and Cypress.

The Cypress project defines a format for disk-based packages. There are Cypress implementations available (or in the works) for GemStone, Pharo, Squeak, VAST, and VisualWorks.

The original motivation for Kaliningrad was:

I created the Kaliningrad project because I want to use Monticello to manage the code that I write in Amber.

With Amber Skeleton, the server-side Smalltalk source is stored on GitHub (using FileTree) along with the client-side Amber source, which is already managed on GitHub.

The FileTree project implements a Monticello repository type that is compatible with Cypress, it is easy to save Squeak/Pharo/GemStone Monticello packages on disk and use Git for version control.

Everything isn’t quite hunky dory:

  • Metacello does not have Git/GitHub support, but there is a project underway to address that.
  • Amber Skeleton is currently only implemented on Pharo, but Squeak and GemStone versions shouldn’t be too difficult to implement
  • Currently there is no image-based tool support for Git/GitHub, but there is a project underway to address that.

Despite the limitations, I still think that you might find Amber Skeleton interesting.

Photo by / CC BY-NC-SA 2.0

five dollarsDuring STIC 2012, we announced VMware’s new list prices for 4 & 8 core perpetual GLASS licenses. You can also purchase Tech Support from VMware for your GLASS deployments.

No Changes to the free version terms!

Photo by / CC BY-SA 2.0

The Persistence of LightBob Nemec responds to Dave Thomas‘ statement that object abstraction is too complex for the majority of programmers.

From Bob’s post:

There are two types of programmers: the toolsmiths (abstractionists) and the tool users (constructionists). Smalltalk developers seem to all be abstractionists.

Most programmers are constructionists. They have a job building and maintaining business applications. As Smalltalkers we ask ourselves: how can we get these programmers to use Smalltalk, to see how much more productive and enjoyable our environment is? The answer, I believe, is to reduce barriers to entry.

Photo by / CC BY-NC-ND 2.0

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

Join 446 other subscribers


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.
March 2023