Sean DeNigris has a cool post on using the Metacello ToolBox:
Photo by http://www.flickr.com/photos/tkellyphoto/4507543643/a> / CC BY-NC-ND 2.0
tips and techniques for using GemStone/S and Seaside
One of the harder problems that developers have to deal with is characterizing issues that show up only in production, especially if exceptions aren’t being thrown.
In development, you’d just toss a `self halt` or two into the code and you’d be off to the races, but in production where multiple servers are involved, things can get a little more complicated. Often developers must resort to print statement debugging and sophisticated server log mining tools to characterize production issues.
Breakpoints have been available in GLASS, for a long time now. In 2008 I added remote breakpoints for Seaside2.8 and finally with the release of Seaside 3.0.6.3, remote breakpoints are available for Seaside 3.0.
With remote breakpoints, you can easily set/clear breakpoints in all of the gems that are serving Seaside and when a breakpoint is encountered a continuation is snapped off and added to the ObjectLog. At your leisure, you can debug the continuation from GemTools or inspect the continuation via the ObjectLog.
Before using remote breakpoints, you need to do a little prep depending upon which version of GemStone/S you are using.
If you want to use remote breakpoints with GemStone/S 2.x, you need only install a new StartSeaside30 Adaptor script or add the following section to your own script:
true "enable for remote breakpoints and profiling"
ifTrue: [
GemToGemAnnouncement installStaticHandler.
Exception
installStaticException: [:ex :cat :num :args |
BreakpointNotification signal.
"needed to avoid infinite loop when resuming
from a breakpoint"
ex _incrementBreakpointsToIgnore. ]
category: GemStoneError
number: 6005
subtype: nil.
System commitTransaction
ifFalse: [
nil error: 'Could not commit for GemToGemSignaling' ]].
The script support for remote breakpoints is preinstalled in GemStone/S 3.0.1, however you must disable native code by setting GEM_NATIVE_CODE_ENABLED to FALSE in your gem conf files:
GEM_NATIVE_CODE_ENABLED = FALSE;
In 3.x there are actually three conf files to think about:
By default, GEM_NATIVE_CODE_ENABLED is set to FALSE, but in a production installation you should set GEM_NATIVE_CODE_ENABLED to TRUE to get the best performance and only set it to FALSE if you want to enable remote breakpoints.
Lets run through the process of using remote breakpoints:
For this example we’ll set a breakpoint in the WAExceptionFunctionalTest>>raiseWarning method.










You can inspect continuations in the ObjectLog from your web browser by using the WAObjectLog component.






—–
[1]http://www.flickr.com/photos/mwichary/2356597072 / CC BY 2.0
I’ve just released a new configuration version for Seaside30 as a complement to the recently released GLASS 1.0-beta.8.7.1:
This release is primarily aimed at supporting GemStone/S 3.0.1 with several GemStone-specific bugfixes and a couple of GemStone-specific Seaside bugfixes:
With this release I have finally implemented remote breakpoints for Seaside 3.0 which will be covered in a separate blog post.
Photo by http://www.flickr.com/people/halfanacre / CC BY-NC-ND 2.0
GLASS 1.0-beta.8.7.1 has been released. There are only a couple of bugfixes in this release as this release was targeted at the upcoming GemStone/S 2.4.5 release. The bulk of the changes were related to porting GLASS 1.0-beta.8.7 to GemStone/S 2.4.5.
GLASS 1.0-beta.8.7.1 has been tested against GemStone/S 2.3.1, GemStone/S 2.4.4.1, GemStone/S 3.0.1 and the forthcoming GemStone/S 2.4.5 release.
To upgrade to GLASS 1.0-beta.8.7.1:
—–
[1]http://www.flickr.com/photos/delgrossodotcom/3698511651 / CC BY-NC-SA 2.0
GemTools 1.0-beta.8.6 has been released. With this release the GLASS upgrade process has been improved, yet again.
One-Click GemTools images are available on the GLASS downloads page. GemTools images are available for use with GemStone/S 2.3.x, GemStone/S 2.4.4.x, and GemStone/S 3.0.1.x,
I suppose it is a little known fact that the GemTools code base includes code that is used to drive the GLASS upgrade process, although my constant entreaties to “upgrade GemTools to the latest version before upgrading GLASS” may have given you a clue or two.
I thought I’d take this opportunity to describe what goes on behind the scenes when you select the Update > Update GLASS menu item in GemTools. This section should be especially useful if you prefer to upgrade your system without running GemTools.
For a complete upgrade script, take a look at the GLASS upgrade script page on the glass db wiki. The GLASS upgrade script page will always have the latest and greatest upgrade script.
The upgrade process has been greatly simplified since I first started using Metacello for bootstrapping GLASS 1.0-beta.0, back in November of 2009, but the basic steps have remained the same:
Currently Metacello 1.0-beta.31.1 is the version that is needed for a smooth upgrade process:
ConfigurationOfMetacello project currentVersion versionNumber < '1.0-beta.31.1' asMetacelloVersionNumber ifTrue: [ (Gofer new) gemsource: 'metacello'; version: 'Gofer-Core.gemstone-dkh.135'; version: 'Metacello-Base-DaleHenrichs.19'; version: 'Metacello-Core-dkh.468'; version: 'Metacello-MC-dkh.531'; version: 'Metacello-Platform.gemstone-dkh.23'; load ].
It turns out that the best formula for bootstrapping Metacello is to directly load the key packages. I would have liked to use Metacello to bootstrap itself, but for GLASS we need to upgrade a wide range of Metacello releases dating back to over a year ago and there are several bugs that make it impractical to do anything but load the packages directly.
To bootstrap Monticello, we use the GLASS configuration and load the ‘Core’ and ‘Monticello’ projects:
MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [[[ (ConfigurationOfGLASS project version: '1.0-beta.8.7.1') load: #( 'Core' 'Monticello' ) ] on: MetacelloSkipDirtyPackageLoad do: [:ex | ex resume: false ]] on: Warning do: [:ex | Transcript cr; show: ex description. ex resume ]].
We wrap the load with an out-of-memory handler.
The MetacelloSkipDirtyPackageLoad handler is there to compensate for a bug in the Monticello package loader that occasionally resulted in a package being marked dirty after a successful load.
The Warning handler is also there to ensure that packages needed for the upgrade are loaded whether or not they are marked dirty.
The GLASS upgrade is completed by doing a simple load:
MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [[[ (ConfigurationOfGLASS project version: '1.0-beta.8.7.1') load ] on: MetacelloSkipDirtyPackageLoad do: [:ex | ex resume: false ]] on: Warning do: [:ex | Transcript cr; show: ex description. ex resume ]].
—–
[1]http://www.flickr.com/photos/archer10/5228946002 / CC BY-SA 2.0
GemStone/S 64 3.0.1 was released on Monday of this week.GemStone/S 64 Bit 3.0.1 is a new version of the GemStone/S 64 Bit object server. This release provides feature enhancements and fixes a number of serious 3.0 bugs.
Release notes, Install Guide and manuals are available here. Be sure to carefully read the GemStone 3.0.0 release notes, if this is the first time you have used GemStone/S 3.0 as there are significant differences between GemStone3.x and GemStone 2.x
GemStone 3.0.1 ships with GLASS 1.0-beta.8.7 pre-installed in $GEMSTONE/bin/extent0.seaside.dbf.
Currently there is no path for upgrading a GemStone 2.x GLASS application to GemStone 3.0.1. The upgrade path will be defined in a future release.
If you are running a production application in GemStone 2.x, it is recommended that you continue to use GemStone 2.x for production. You should port your application to GemStone 3.0.1 in preparation for the time when the upgrade procedure is defined.
If you are starting a new application then you should use GemStone 3.0.1 as a starting point.
You can download the binaries from ftp://ftp.gemstone.com/pub/GemStone64/3.0.1/ or visit seaside.gemstone.com downloads page and use the installGemStone3.0.1.sh script to download and install GemStone 3.0.1 on your machine (highly recommended).
Once you’ve installed Gemstone in /opt/gemstone/product, follow these steps to start and stop the stone:
source /opt/gemstone/product/seaside/defSeaside
It is recommended that you add this step to your .bashrc.
system.conf and GLASS extent0.dbf files to data directory:
cp $GEMSTONE/seaside/system.conf \
$GEMSTONE/seaside/data
chmod +w $GEMSTONE/seaside/data/system.conf
cp $GEMSTONE/bin/extent0.seaside.dbf \
$GEMSTONE/seaside/data/extent0.dbf
chmod +w $GEMSTONE/seaside/data/extent0.dbf
This step is performed as part of the installGemStone3.0.1.sh script.
netldi and stone processes:
startnet startGemstone
stone process is running:
gslist -lcv
stone process:
stopGemstone
Check the Starting a stone page on the glass db wiki for updates to the above procedure.
A One-Click GemTools 1.0-beta.8.5 for GemStone 3.0.1 can be obtained from the seaside.gemstone.com downloads page or you can download GemTools 1.0-beta.8.5 for Gemstone/S 3.0.1 all platforms directly.
You can build a custom GemTools image by following these steps on the glass db wiki.
I have new releases of Seaside, Magritte and Pier that have been ported to GemStone 3.0.1 queued up and they should be made available shortly.
—–
[1] “Mike” Michael L. Baird, flickr.bairdphotos.com / CC BY 2.0
GLASS 1.0-beta.8.7 has been released. I’ve been pretty busy since the last GLASS release in March: there are almost 50 bugfixes included in this release.
GLASS 1.0-beta.8.7 has been tested against GemStone/S 2.3.1, GemStone/S 2.4.4.1 and the forthcoming GemStone/S 3.0.1 release.
I plan a series of blog posts over the next few weeks to cover some of the more interesting changes and new features included in and enabled by GLASS 1.0-beta.8.7.
If you’ve downloaded the GLASS appliance, you will be running on GemStone/S 64 Version 2.3 and GLASS.230-dkh.164. The good news is that you can upgrade from GLASS.230-dkh.164 to GLASS 1.0-beta.8.7:
As always don’t forget to make a backup before and after the upgrade.
GemStone/S 2.4.4.1 and the subsequent 2.4.x releases have all shipped with GLASS 1.0-beta.8.1 pre-installed in the seaside extent ($GEMSTONE/bin/extent0.seaside.dbf). The upcoming GemStone/S 2.4.5 release will be shipped with GLASS 1.0-beta.8.7 pre-installed.
To upgrade to GLASS 1.0-beta.8.7:
—–
http://www.flickr.com/photos/mcbridejc/6165651180 / CC BY-NC-SA 2.0
GemTools 1.0-beta.8.5 has been released. With this release there have been several bugfixes:
as well as some tweaks to the GLASS upgrade process.
I always recommend that you update GemTools before upgrading GLASS, because the GLASS upgrade process is driven by code included in GemTools. When you select the Update GLASS menu item, the class OGUpgradeJadeServer (included in the GemTools distribution) is compiled on the server and is then used to control the upgrade process.
Speaking of upgrading GLASS… If you are interested in doing a GLASS upgrade from a topaz script take a look at this page on the glassdb wiki has the most up-to-date instructions.
Don’t forget that when you load GemTools into Pharo and Squeak, a set of Help Browser pages are created to provide the most up-to-date information on getting started with GemStone and the GemTools image.
Before releasing 1.0-beta.8.5, I tried loading GemTools into some of the more recent Pharo releases, like Pharo 1.3 and Pharo 1.2, but unfortunately the OmniBrowser implementation in those images is incompatible with the OmniBrowser required for GemTools. The latest version of Pharo that I found that works with GemTools is Pharo1.1.2-11422.
While we’re on the subject, you should also be aware that in order to connect to GemStone, you must use an older version of the Squeak vms (4.2.2 or older) to avoid an FFI bug. For more details, see Issue 258.
—–
http://www.flickr.com/photos/nhankamer/5616046050 / CC BY-NC 2.0