Category Archive

I’ve just published GLASS-dkh.118 (2.2.5) and GLASS.230-dkh.146 (2.3.0 or 1.0beta9). These two versions should be used with GemStone-dkh.279 (Squeak). All three of the versions can be found in the GLASS project on GemSource. If you decide to upgrade to these versions, first load the version on the GemStone-side, commit and logout. Then load GemStone-dkh.279 into your Squeak image and save your Squeak image.

With this update, you will need to do a couple of things to get things to load correctly:

1. Before loading the GLASS package, turn off autoMigrate or evaluate ‘MCPlatformSupport autoMigrate: false.’ The shape and superclass of WAExternalID has been changed in Seaside2.8.2 and the automatic migrate algorithm chokes. As Seaside sessions expire, the old instances will go away.
2. After loading evaluate ‘WAAllTests initialize’ and turn autoMigrate back on.

This release contains the following features:

• Seaside 2.8.2 (Seaside2.8a1-lr.563) merged
• fix bug38366 - blank versions in history list
• fix bug38916: FSSocketServer>>addConnection: and FSSocketServer>>removeConnection: not threadsafe

See GLASS package history for more details.

Between preparations for Smalltalk Solutions and working with Seaside2.9 and 3.0, I’ve been keeping pretty busy. After Smalltalk Solutions, I hope to find time to make another pass at the tools and do a little blogging about GLASS.

It was just over a year ago that we annnounced GLASS at Smalltalk Solutions 2007 (May 2007). We were running on Seaside2.6 and at the time we figured we would be ready for a public beta in about 3 months - ho ho!

By ESUG 2007 (August 2007), we had ported Seaside2.8 to GemStone/S and we had a set of Squeak-based development tools for GLASS. By OOP 2008 (January 2008), we (nearly) had all of the tools implemented in OmniBrowser.

By the end of January we had shipped GemStone/S 64 2.2.4 and made version 1.0beta6 of the appliance available for download to those who had the appropriate hardware and were interested enough to send us an email.

In the last few months, we have addressed commit conflict handling for Seaside, debugging in a multi-vm environment, shipped GemStone/S 64 2.2.5.1 and created 1.0beta9 of the appliance (based on a 2.3 beta).

We’ve had a steady stream of requests for GLASS and now we are prepared to make the beta publicly available. So head on over to the downloads page and get busy! While you are thinking about it join our Beta mailing list, too.

If you are considering putting your GLASS application into production, then you should use version 2.2.5.1. As a released version of GemStone/S 64, 2.2.5.1 has undergone our full QA testing and when future versions of the product become available we will document the procedure for upgrading your GLASS repository to the new version of the product.

I’ve just published GLASS-dkh.117 (2.2.5) and GLASS.230-dkh.140 (2.3.0). These two versions should be used with GemStone-dkh.276GemStone-dkh.278 (Squeak). All three of the versions can be found in the GLASS project on GemSource. If you decide to upgrade to these versions, first load the version on the GemStone-side, commit and logout. Then load GemStone-dkh.276 into your Squeak image and save your Squeak image.

I know, I know, just minutes after announcing the availability of a new version of the appliance I publish a set of new packages….So shoot me! Actually, I don’t anticipate that you’ll be that interested in this particular set of versions, since you might not be able to tell that I’ve made any changes at all: I’ve simply taken the first step in heading towards getting the OB-Enhancements packages and friends loaded into GLASS.

With these versions I have started using a branch of the OB-Standard package instead of the OG-Standard package, so only folks like Liliana and Otto from Finworks will really be interested.

I haven’t had a chance to try loading OB-Enhancements, yet - I’ll save that for next week!

[Updated 5/10/2008 - use version GemStone-dkh.278 (needed for 2.3) and load OG-AllTests-dkh.14 (in the GemStone Tools project) if you want to run the OmniBrowser tests in GemStone)].

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

1. AutoCommit and AutoMigrate features added to GLASS tools. If you ever do something that is truly experimental, you can turn off AutoCommit, but in the majority of cases you should be using AutoCommit. With AutoCommit turned on, the system will perform a commit after every UI action that can change state. In the Code and Monticello browsers that means there are commits after virtually every operation. In a workspace, a commit is performed after the expression is evaluated (doIt, printIt, inspectIt, etc.).
2. Seaside2.8.1 merged in (Seaside2.8a1-lr.541).
3. Refactored the Exception hierarchy for GemStone-specific exceptions.

You can get more information by reading the comments in the package history.

GLASS-dkh.114 can be loaded into version 2.2.5 of GemStone/S 64 (including the just annouced version 2.2.5.1). It can also be loaded into version 1.0beta6 of the appliance.

The 2.2.5.1 release of GemStone/S delayed the work towards releasing a new version of the appliance based on 2.3 beta, but we should have a 2.3 beta build done later today and the new version of appliance should be available early next week.

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.

The dogs didn’t let us sleep in this morning, so I’m getting an early start on the day. I’ve been very busy the last two weeks intending to write but getting roped into one thing after another.

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

1. GemStone examples included in the GLASS package. I plan to write descriptions of the examples today!
2. Highlighting added to MCRepositoryBrowser.
3. Started work on MCConfiguration support. I’ve got an OmniBrowser-based tool written and MCConfigurations themselves are mostly working.
4. Improved OmniBrowser tools performance. I did some work to reduce roundtrips and speed up icon calculations.
5. Added MCServerDirectoryRepository. Now you can have directory-based repositories on your client machine (where the Squeak client is running) or on the server machine (where your gems are running).
6. Fixed some bugs, etc. You can look at the history for GLASS-dkh.101 if you want the gory details.

Next week we are planning on releasing a new version of the appliance. Keep an eye on this space for an announcement. If you haven’t played with the appliance yet and have 64bit hardware, drop us an email to get download instructions.

It’s an absolutely beautiful day today. Every February we get a week of sunny, fifty degree weather and it looks like this is the week. It is so nice to see the sun! Over the holiday weekend we were able to take our dogs for a run in a nearby dog park. It’s a real treat to see a Saluki in full flight.

Besides playing with dogs, I’ve spent some time playing with and cleaning up some things in GLASS. I’ve published a new version of the GLASS package (GLASS-dkh.88) and here are some of the hightlights:

1. I’m getting happier with the remote debugging factility - the steps for debugging are greatly simplified and I’ve even replaced the Hyper button on the GemStone Transcript with a Debug button that will open a debugger on the first continuation in the RcQueue (you’ll need to load GemStone-dkh.240 into your Squeak image for this feature). When you’re in production (#deploymentMode == true), the debug continuations are unconditionally added to the queue.
2. In the same vein as remote debugging, I’ve added a consolidated object log where you can dump a LogEntry into an RcQueue from any one of the gems serving Seaside requests and view the logged objects in the comfort of your own development image. No need to muck around in N different logs to look for stack traces or important error messages.
3. You may have noticed that in the past I have been somewhat vague whenever the subject of commit failures was brought up. Now, when you hit a commit failure, we drop a transactionConflicts Dictionary into the object log (see the comment in System class transactionConflicts for a description of its contents), and simply retry the HTTP request. If retry fails 10 times in a row, we throw in internal error.

I’ll be writing a couple of posts in the next week or so to provide more details.

Version 1.0beta6 of the appliance is rolling off the assembly line and that new software smell is once again wafting through the hallways of our Beaverton office. If you are using an appliance that is older than 1.0beta5, then you should contact us to get download instructions for 1.0beta6.

If you haven’t played with the appliance yet and have 64bit hardware, drop us an email to get download instructions, you should also read the Terse Guide to GLASS Tools.

On the development front, I am busy getting a port of SourceSource 2 running on GemStone. SourceSource 2 is Philippe Marschall’s port of SqueakSource to Seaside2.8 and Magritte. When I’m done I think that this will be a good example of what types of things need to be done to port a Squeak Seaside app to GemStone.

Oh, and don’t forget to sign up for our GLASS Beta mailing list.

To the extent that any tool set is ever actually done, I’m glad to say that the GemStone tools for GLASS are done. It has been a long haul, but I’m feeling real good about the state of the tools. I will write up a Terse Guide to the GLASS Tools in the next day or so to give you an idea of what to expect.

In order for you to actually get a look at the new tools you’ll have to wait for Version 2.2.4 of GemStone/S 64 or download a new version of the Seaside Appliance.

Version 2.2.4 is due to be released this Friday. We’re in the final stages of QA for this release and so far we are on track to make the date.

Once 2.2.4 goes out the door, we will build the new version of the appliance. It should be available next week. If you have been using an older version of the appliance, it is highly recommended that you download the new version. If you haven’t played with the appliance yet and have 64bit hardware drop us an email to get download instructions.

Between the holidays and time off to wrestle with a stubborn cold, December was a short, but busy month.

Version 2.2.4 of GemStone/S 64 is due to be released around the middle of January, so I’ve been scrambling to make changes to the base classes that are needed for OmniBrowser and Seaside.

We will also be cranking out a new rev of the GLASS appliance around the same time, so I’ve been working to get all of the image-based tests to pass and to clean up some of the Undeclared Symbols that have been floating around. Infrastructure improvements for the most part. With this rev of the GLASS appliance, we’ll still be in limited beta (i.e., if you have 64 bit hardware and want to take GLASS for a spin, drop us an email), but we are getting very close to making the beta available for download.

The big news is that we’ve finally got OmniBrowser-based Monticello tools, what a nice Xmas gift that was! We brought Avi down to Portland for a week and he nailed the Monticello tools. He did his development in Squeak, so we have made the results available to Damien Cassou (via the Package Universe) and he should be including the new tools in the beta Squeak development image. The OB-Monticello package is available in Colin’s OmniBrowser repository. I will be making a handful of changes in the next week or so as I get the new Monticello tools working in GemStone/S, but the plan is to have them ready for the next rev of the appliance. When that work is done, I’ll refresh the information in the Package Universe.

Finally, don’t forget that OOP 2008 in Munich (January 21-25, 2008) is coming up.

Back in October, I said that I was going heads down on the tools and I really wasn’t kidding. During November I didn’t blog very much, but I did make some major progress.

First, I finished off the port of Magritte that was started by Lukas and Isaiah Perumalla.

I dipped my toe into the OmniBrowser-based Monticello tools, but before long it was obvious that I needed to migrate to the latest version of OmniBrowser. Firstly, we’d be able to make some of the very nice features, that have been recently added to OmniBrowser, available to GemStone developers. Secondly, we’d be able to use the current development image available from Damien Cassou as the basis for the GemStone/S tools. eliminating the need to build a specific Squeak image for GemStone.

While merging the latest OmniBrowser changes into the GemStone code-base, I got fed up with the inspector for stack contexts in the debugger. I’m pretty happy with the resulting context inspector, but then I’m probably a little biased. The new context inspector gives you an overview of the arguments, temps and receiver state that includes names and values, something like what you can get with Dolphin (but not quite that nice). The inspector is slaved to the debugger, so the contents are updated on each step or whenever you select a new context.

During Thanksgiving week I took some vacation and spent quality down time with my wife, family and doggies.

Based on feedback from a beta user, we finally decided to bite the bullet. With the next release of the GemStone (version 2.2.4), the GemStone/S compiler will support Squeak-style curly brace Array constructors, as well as method pragmas. At ESUG, Damien Cassou questioned why we didn’t just add the curly brace Array constructor to our compiler - he was right, it just took us a while to get around to it.

Well November began with OmniBrowser-based Monticello tools at the top of my list and it ended with them still at the top, but a fair amount of necessary work was done along the way.

We’re having an Indian Summer in Oregon this year. The trees are alive with vibrant reds and bright yellows against a backdrop of Douglas Fir green and a bright blue sky. Balmy, clear weather in Oregon, in October - Fantastic! As the sun climbs up over the Cascades and lights up the maples in the parking lot, I’m thinking back on the fact that I spent the entire summer working on the tools for GLASS and it looks like I’ll be spending my Indian Summer doing the same thing.

While I was playing with GemStone/S and Seaside, Isaiah Perumalla spent some time porting Magritte to GemStone/S. Isaiah (with some help from Lukas Renggli) got to the point where all but a few of the tests were passing. Some GemStone-specific work was needed and I’ve stepped in to finish off the port, but the bulk of the work was done by Isaiah and Lukas.

In the midst of working through the remaining Magritte tests, I decided that I would get breakpoints working in the OmniBrowser tools. I’ve got them working now, but I now have to add a Breakpoint Browser to the list of tools that need to be implemented.

Also, Otto Behrens and Liliana Ivan from Finworks found time to extend Shout to do syntax highlighting for GemStone/S Smalltalk, which is very nice.

If you have 64 bit hardware and the time to explore GLASS right now, visit our website and drop us an email to let us know that you’re ready to rumba.

Meanwhile, I’m going heads down on the tools.

I’ve pretty much spent the last couple of weeks catching up on some of the things that had fallen by the wayside on the way to ESUG.

While I was away, Otto Behrens and Liliana Ivan from Finworks, made a number of contributions to the tools, including a port of TestRunner to the GemStone tools - very cool.

Once I’d cleared the decks a bit, I started to build the OmniBrowser-based Monticello tools, but before going very far, it turned out that we needed to update our Seaside code base to the latest Squeak version of Seaside2.8 (Seaside2.8a1-pmm.481). I ended up spending a couple of days doing the merge, as I fixed a handful of bugs in the tools along the way.

Janko Mivšek of EraNova was able to port the Squeak version of AIDA/Web to G.L.A.S.S. in just a couple of days. He used an Alpha version of the Seaside appliance and was fairly happy with the results. AIDA/Web is a Smalltalk-based web framework that has been available on the VW platform for a decade or so and has recently been ported to Squeak.

Before getting back to the tools for a final push (which should take a couple of weeks), I’ll be spending a little bit of time looking at performance and scaling. Based on very limited testing, Seaside2.8 appears to be about twice as fast as Seaside2.6 in GemStone. I’ve also been really pleased with the early results of muli-gem/multi-core testing - rates beyond 100 requests/second appear to be very realistic. Once the tools are in the bag, I’ll get real serious about characterizing GemStone/Seaside performance.

We’ve had a handful of folks use the Alpha version of G.L.A.S.S. and they’ve given us very useful feedback, but we’re really waiting for the OmniBrowser-based Monticello tools to be finished, before opening up the Beta of G.L.A.S.S. As I mentioned earlier, I’m expecting it to take a couple more weeks to finish off the Monticello tools, followed by a couple more weeks of Alpha, then we will be ready to Rumba.