You are currently browsing the category archive for the ‘Seaside’ category.
GemStone/S 3.1.0.1
GemStone/S 64 3.1.0.1 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 3.1.0.1 ships with GLASS 1.0-beta.8.7.2 pre-installed in $GEMSTONE/bin/extent0.seaside.dbf, but t
here 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 3.1.0.1.
GemTools 1.0-beta.8.7
A One-Click GemTools 1.0-beta.8.7 for GemStone 3.1.0.1 can be obtained from the seaside.gemstone.com downloads page or you can download GemTools 1.0-beta.8.7 for Gemstone/S 3.1.0.1 all platforms directly.
You can build a custom GemTools image by following these steps on the glass db wiki.
Seaside3.0.7.1
Seaside 3.0.7.1 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 ftp://ftp.gemstone.com/pub/GemStone64/3.1.0.1, use the installGemStone.sh script to download and install GemStone/S on your machine (highly recommended), or visit seaside.gemstone.com downloads page.
To use the installGemStone.sh script, your supply the GemStone version number as an argument to the script. The following downloads and installs the GemStone/S 3.1.0.1 release:
./installGemstone.sh 3.1.0.1
Upgrading
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 3.0.7.1
Let’s say that you’ve got Seaside 3.0.7.1 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 3.0.7.1, that means you’ll run the following topaz script BEFORE running the upgradeSeasideImage.sh 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 3.0.7.1 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] http://www.flickr.com/photos/gatesfoundation/5076533520 / CC BY-NC-ND 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:
- CofigurationOfSeaside30 3.0.6.3
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:
- Issue 636: expected exception behavior WAWalkbackErrorHandler not portable (and not ANSI compliant)
- Issue 694: Swazoo adapter does not respect Request URIs ending in slash
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
Kaliningrad oblast (sometimes called Yantarny krai which means “The amber region”) is located on the coast of the Baltic sea and is the site of the world’s largest amber deposits.
Kaliningrad Project
I created the Kaliningrad project because I want to use Monticello to manage the code that I write in Amber.
Kaliningrad automatically maps Amber package names to Monticello package names, so Kaliningrad is pretty easy to use.
Kaliningrad is based on Seaside 3.0 and uses the Seaside File Library and the Seaside-REST package to serve and store the Amber .js and .st files.
To load Kaliningrad execute the following expression:
Gofer new url: 'http://ss3.gemstone.com/ss/Kaliningrad'; package: 'ConfigurationOfKaliningrad'; load. ((Smalltalk at: #ConfigurationOfKaliningrad) project version: '0.1') load.
The Kaliningrad configuration loads only the most basic packages for Seaside 3.0, so you’ll need to load up one of the adaptors (Swazoo, Comanche, or Zinc) before you can connect.
Using Kaliningrad
Once you’ve got the Seaside server running, hit (user/password : admin/tool):
http://localhost:8080/tools/amber-browser
to bring up the Amber Browser:
If you want save your Amber code into a Monticello package follow these steps:
- Create an Amber package (‘tODE-AmberClient’) in the Amber Browser.
- Create a Monticello package with the same name (‘tODE-AmberClient’) using the Monticello Browser in your image.
- Register the Monticello package with the KOAmberBrowser class:
KOAmberBrowser addMonticelloPackage: 'tODE-AmberClient'
Thereafter, when you hit the Commit package button for ‘tODE-AmberClient’ in the Amber Browser, the .js and .st source will be saved in the ‘tODE-AmberClient’ Monticello package.
Thats it!
The class KOAmberBrowser is also a good example for how to integrate Amber code into a Seaside component.
Importing classes into Amber
If you want to import a class from your Smalltalk image into Amber, you can evaluate an expression like the following in an Amber workspace:
KOImporter importClass: 'TOSession' intoModule: 'tODE-Amber'
Be aware that there are differences between Amber Smalltalk and other Smalltalk implementations (see the section entitled Differences with other Smalltalk implementations on the Amber documentation page). KOImporter does not check for correctness.
Summary
Kaliningrad 0.1 is based on Amber 0.9.
I’ve been using Kaliningrad with Pharo for a couple of weeks now, but the code should run in GemStone and Squeak.
If you run into problems, let me know.
—–
[1] Photo by http://www.flickr.com/photos/paul_garland/5133520694 / CC BY-SA 2.0
The SS3 Alpha was announced at the end of May, but with SmalltalkHub scheduled to come on-line soon work on the alpha was suspended.
On the Sunday before ESUG (August 21), the Pharo folks started using ss3 for storing their Pharo 1.4 work – SqueakSource had crashed one too many times.
Consequently we are resuming work on SS3 and are committed to taking SS3.gemstone.com into production.
The warning that packages stored in SS3 will not be preserved beyond the Alpha period has been withdrawn and we have instituted daily backups for the site. We are still in the alpha period, but the basic operation of the site is sound. Tobias Pape has bugfixes queued up for most, if not all of the outstanding bugs and we will be working towards pushing the fixes into production over the coming weeks.
It should be noted that some mcz files cannot be stored in SS3. We plan to characterize and fix the known problems with loading mcz files.
Please report issues you run into with the SqueakSource3 issue tracker.
When we’ve addressed the initial crop of critical bug reports we will move into a short Beta period and then transition to full production. In the interim, if you are willing to put up with the current set of bugs in exchange for stability, then you should consider hosting your project on SS3.
With that said, keep in mind that work on SmalltalkHub is continuing and I understand that there is an active project to improve the reliability of www.squeaksource.com, so carefully consider the impact on your users before moving to SS3. SS3 is intended to be a stable alternative until SmalltalkHub is brought online and www.squeaksource.com is stabilized.
—–
[1] Photo by http://www.flickr.com/photos/marcus_hansson/87885327 / CC BY 2.0
Nick Ager just published the instructions (and a screencast) for creating a free Micro EC2 instance for Seaside, Pier, and GLASS:
Amazon’s offer of a free micro instance for a year grabbed my attention:
[Updated: 1/4/2010] If you are interested, you should also check out the discussion on the Seaside list.
Photo by http://www.flickr.com/photos/chechipe/3821497127/ / CC BY NC ND 2.0