If you’ve been keeping score, you are probably wondering what happened to the new version of the appliance that I promised at the beginning of the month.

The primary rationale for releasing a new version of the appliance is to make base image code and new primitives available. I did have a hand full of interesting changes queued up awaiting the release of 2.2.5, but the release of 2.2.5 has been held open for bugfixes that might be required by a commercial customer who is taking 2.2.5 into production. While my changes are interesting, they aren’t interesting enough to warrant a release on their own.

Our current plan is to target 2.3 as a Seaside release. 2.3 will include:

  1. support for remote breakpoints
  2. a handful of base image bugfixes
  3. primitive support for UTF8 encoding
  4. any other low hanging fruit

I plan on tackling the UTF8 primitives this week, so we can get a 2.3 beta release including a new appliance drop sooner rather than later.

Based on my past prognostications you should know that for me, “Planning is a form of dreaming.”

I’ve just published GLASS-dkh.108 which should be used with GemStone-dkh.258 (both can be found in the GLASS project on GemSource). Here are some of the highlights:

  1. Arranged for GemStone-based Transcript messages to be routed to the Squeak-based Transcript.
  2. Added GemToGemAnnouncement based on Announcement package from Lukas for handling Gem to Gem signals.
  3. Parallel debugging is feature complete:
    1. Debugged continuations can be ‘resumed’.
    2. Remote breakpoints available (need 2.2.5 final and startup script changes).
    3. Profiling works in mulit-vm environment.
    4. Object log improvements (rewrite and ui adjustments).
    5. Object log integrated with Transcript. Transcript used when development vm attached, Object log used otherwise.
  4. Several bugfixes (see package history for more details).

In earlier posts, I have talked about remote debugging. I have decided (for now at least) that Parallel debugging is a better name for what we’re doing.

In a nutshell, Parallel debugging is about providing a set of tools for doing debugging that spans multiple vms that are operating in concert. The goal is to make debugging/development in a system that may be composed of hundreds of vms as easy as doing debugging/development in a single vm. Debugging continuations, remote breakpoints and the object log are all components of Parallel debugging support.

I plan on writing a post that will go into more detail about Parallel Development/Debugging with GLASS.