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:
- 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.
- 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.
- 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.


7 comments
Comments feed for this article
March 17, 2008 at 2:16 pm
Transparent Persistence for Seaside « (gem)Stone Soup
[...] recent modifications to the GemStone port of Seaside, it isn’t absolutely neccessary to avoid transaction [...]
March 17, 2008 at 2:25 pm
GLASS 101: Ready… « (gem)Stone Soup
[...] added an object log to GLASS a couple of weeks ago and over the last couple of days, I’ve added a Seaside application for viewing and [...]
October 30, 2008 at 4:07 pm
GLASS 101: …Fire « (gem)Stone Soup
[...] GLASS, Seaside, Smalltalk In my post on Simple Persistence for Seaside, I claimed that with the recent enhancements to the Seaside framework in GLASS, it is perfectly okay to use an unprotected class variable to [...]
October 30, 2008 at 4:58 pm
GemStone 101: #allInstances, #become: and friends « (gem)Stone Soup
[...] error doesn’t have the most intuitive explanantion and the stack dumped into the object log was rooted in the standard commit that occurs right before the HTTP response is returned to the [...]
November 1, 2008 at 10:26 pm
Pier Programming « (gem)Stone Soup
[...] Remove all of the default Seaside apps, except the object log. [...]
March 16, 2009 at 2:26 pm
Terse Guide to the (new) GLASS Tools « (gem)Stone Soup
[...] Empty Object Log command empties the entire Object Log (also see the Remove Continuations from Object Log command in the Debug… [...]
April 15, 2009 at 3:23 pm
GLASS Beta Update: Working with SOAP (Preview) « (gem)Stone Soup
[...] all of the server variants, internal server errors are logged in the Object Log – commits are needed in the Soap server to make the log entries persistent. Take a look at the [...]