Bootstrapping GLASS 1.0-beta.0

[1]

Not long after shipping the SOAP update for GLASS, I started working on Metacello. With the SOAP update, it became obvious that the GLASS ‘umbrella’ package was going to have to be replaced, and soon. Well, 7 months later I am reaching the point were I am finally ready to replace the GLASS package with a Metacello configuration .

I’m going to phase in the use of Metacello with GLASS. With the initial release, we’ll use Metacello for bootstrapping GLASS into a virgin extent. This way folks starting a greenfield project can use Seaside 2.8.4 or Pier 1.2 right away. Other releases that are in the pipeline:

• GemStone/S 64 2.4.x with partial continuations for Seaside3.0.
• Metacello configuration for bootstrapping Seaside 3.0 (ConfigurationOfSeaside30). A Squeak/Pharo version of this configuration is available now.
• final release of GLASS.230 package that will boot Metacello into an existing GLASS installation and allow for upgrading to GLASS 1.0-beta.0 and beyond.

GLASS 1.0-beta.0

ConfigurationOfGLASS version 1.0-beta.0 is based upon GLASS.230-dkh.231, with the following additions:

• Seaside 2.8.4
• Pier 1.2
• Metacello support
• VB-Regex loaded as part of ‘core’
• Scriptaculous updates from Ken Treis
• GemTools updates from Gerhard Obermann
  • optional auto abort performed before commands
  • add remove method (without any checks) renamed “remove method …” to “safe remove method …”
  • add command “browse class history”
  • add class history index to class browser title
• browse changes fixed … reversed comparison direction so that ”Install” will install repository version. the strike-out text is what is in current image.
• supports bootstrapping of code into virgin extent (see Bootstrapping Instructions).

Read the following sections to gain an understanding of the 1.0-beta configuration structure. If you are impatient and just want to load and go, then you can skip to the Bootstrapping Instructions.

1.0-beta Configuration Structure

With release 1.0-beta.0 there are 9 different loadable configurations defined in ConfigurationOfGLASS. If you read the code in the method ConfigurationOfGlass>>baseline10beta00:, you can see the Metacello specification summarized in the following sections.

Primary GLASS Projects

Any one (or combination) of the following projects and groups may be used as a load configuration for bootstrapping

Each of these projects is managed by it’s own ConfigurationOfxxx class.

• Core project. ConfigurationOfGsCore manages the Core, Base-Bootstrap, Bootstrap, GemStone-Exceptions (2.x only), GemStone-Indexing-Extensions, GsRandom, Sport, Squeak and VB-Regex packages. The Core packages are fundamental to the operation of GLASS and is always loaded.
• FastCGI project. ConfigurationOfGsFastCGI manages the FastCGIPool and FastCGI packages. The FastCGI packages are optional and are used to support FastCGI packages for Seaside2.8 and Seaside3.0.
• Hyper project. ConfigurationOfGsHyper manages the OpenSkills and Hyper packages. The Hyper packages are optional and are used to support the Hyper packages for Seaside2.8 and Seaside3.0.
• Magritte project. ConfigurationOfGsMagritte manages the Magritte-Model, Magritte-Tests and Magritte-Seaside packages. The Magritte packages are optional and represent the GemStone/S port of Magritte. By default only Magritte-Model and Magritte-Tests packages are loaded. To load Magritte-Seaside, it must be explicitly referenced.
• Metacello project. ConfigurationOfMetacello manages the Metacello packages and is imported from the Metacello project. By default the Metacello-Core, Metacello-MC and Metacello-Platform packages are loaded. The Metacello packages are fundamental to the operation of GLASS.
• Misc project. ConfigurationOfGsMisc manages the MockGemStone, SMTPMail, Utf8Encoding, Announcements, XML-Parser, SIXX, SmaCC, System-Digital-Signatures, and GemStone-Release-Support packages. The Misc packages are represent useful pieces of functionality that are contained in a single package and depend only upon the Core project. The Misc project is rarely loaded in it’s entirety. Typically individual packages are loaded from the project.
• Monticello project. ConfigurationOfGsMonticello manages the Change-Notification, PackageInfo-Base, and Monticello packages. The Monticello packages are fundamental to the operation of GLASS.
• OB project. ConfigurationOfGsOB manages the OmniBrower, OB-GemStone-Platfrom, OB-Monticello, OB-SUnitIntegration, OB-SUnitGUI, OB-Stanadard, OB-Tools and JadeServer packages. The OB packages are optional and provide the implementation for the GemTools.
• Pier project. ConfigurationOfGSPier manages the Pier-Model, Pier-Blog, Pier-DesignChooser, Pier-Design, Pier-Documents, Pier-EditorEnh, Pier-Google, Pier-Links, Pier-Randomizer, Pier-Slideshow, Pier-TagCloud, and Pier-Twitter packages. The Pier packages are optional and represent the GemStone/S port of Pier.
• Scaffolding project. ConfigurationOfGsScaffolding manages the GemStone-Scaffolding package. The Scaffolding packages are optional and representing the implementation of Scaffolding for GemStone. Even though this project consists of a single primary package, the fact that it depends upon Magritte and Scriptaculous warrants the creation of separate Metacello configuration.
• Seaside2.8 project. ConfigurationOfGsSeaside28 manages the Seaside2.8, SeasideAsync, Scriptaculous, RSRSS2, CallDemo, CheckboxExample, CSSDock, ErrorHandler, HelloWorld, ImageDemo, LogoutDemo, MarqueeDemo, menuDemo, ScreenResolution, Store, GemStone-Store, GemStone-Examples, FastCGISeaside and HyperSeaside packages. The Seaside2.8 packages are optional and represent the GemStone/S port of Seaside. By default only the Seaside2.8 pacakge is loaded. All of the other packages must be explicitly referenced.
• Seaside2.8 Testing project. ConfigurationOfGsSeasideTesting28 manages the SeasideTesting and PierTesting packages.
• SOAP project. ConfigurationOfGsSoap manages the SoXML, SOAP-CORE, SOAP-Client SOAP-Server, SOAP-Example and SOAP-TestCases packages. The SOAP packages are optional and represent the GemStone/S port of SoapCore.

Convenience GLASS Projects

• FastCGISeaside is a project based on a specialization of ConfigurationOfGsSeaside28 and references the FastCGISeaside package.
• HyperSeaside is a project based on a specialization of ConfigurationOfGsSeaside28 and references the HyperSeaside package.
• Metacello Tools is a project based on a specialization of ConfigurationOfMetacello and references the OB-Metacello package.
• Release Support is a project based on a specialization of ConfigurationOfGsMisc and references the GemStone-Release-Support package.
• Pier Testing is a project based on a specialization of ConfigurationOfGsPier and references the PierTesting package.

Groups

The following groups have been defined for the common load configurations.

• Dev group is made up of the Core, Monticello, Metacello, Release Support, OB and Metacello Tools projects.
• Magritte Dev group is made up of the Dev and Magritte projects.
• SOAP Dev group is made up of the Dev and SOAP projects.
• Seaside Dev group is made up of the Dev, Seaside2.8, FastCGISeaside and HyperSeaside projects.
• Seaside Testing Dev group is made up of the Seaside Dev, Seaside2.8 Testing projects.
• Scaffolding Dev group is made up of the Dev, Scaffolding, FastCGISeaside and HyperSeaside projects.
• Pier Dev group is made up of the Dev, Pier,  FastCGISeaside and HyperSeaside projects.
• Pier Testing Dev group is made up of the Pier Dev and Pier Testing projects.
• ALL group is made up of all of the projects defined in ConfigurationOfGLASS.

As you become familiar with Metacello and the GLASS configurations, you can define your load configuration. although you probably want to become more familiar with Metacello first.

Bootstrapping Instructions

Please comment to this post or send mail to the GLASS Beta Mailing List if you have trouble or the instrcutions are not clear. The bootstrap should work for the appliance or any version of GemStone/S 2.3 or greater.

1. Start a stone using a virgin extent copied from $GEMSTONE/bin/extent0.dbf into $GEMSTONE/seaside/data. Don’t forget to shut the stone down before copying extents around and don’t forget to make the extent writable using ‘chmod +w extent0.dbf’.
2. Download and unzip bootstrap_1.0-beta.0.zip.
3. cd to the bootstrap_1.0-beta.0 directory
4. Edit the .topazini file to match your stone.
5. Launch topaz: ‘topaz -l -T50000′
6. ‘login’ and ‘input installMaster.topaz’
7. Exit topaz. The ‘installMaster.topaz’ script installs the Dev Group which includes the GemTools.
8. Launch a GemTools Client 1.0-beta.1 image and login.
9. [Updated: later that day] Due to some bugs discovered in 1.0-beta.0, it is recommended that you update to 1.0-beta.1 by executing the following expression:

   ConfigurationOfGLASS project updateProject.
   (ConfigurationOfGLASS project version: '1.0-beta.1')
       load: 'Dev'.
   System commitTransaction.

10. Choose a configuration to load by executing one of the following expressions:

    (ConfigurationOfGLASS project version: '1.0-beta.1')
        load: 'Magritte Dev'.
    (ConfigurationOfGLASS project version: '1.0-beta.1')
        load: 'SOAP Dev'.
    (ConfigurationOfGLASS project version: '1.0-beta.1')
        load: 'Seaside Dev'.
    (ConfigurationOfGLASS project version: '1.0-beta.1')
        load: 'Seaside Testing Dev'.
    (ConfigurationOfGLASS project version: '1.0-beta.1')
        load: 'Scaffolding Dev'.
    (ConfigurationOfGLASS project version: '1.0-beta.1')
        load: 'Pier Dev'.
    (ConfigurationOfGLASS project version: '1.0-beta.1')
        load: 'Pier Testing Dev'.
    (ConfigurationOfGLASS project version: '1.0-beta.1')
        load: 'ALL'.

11. Make a backup and have fun!

—–
[1]http://www.flickr.com/photos/dawilson/ / CC BY-NC-ND 2.0

Lighttpd Load Balancer Love

Ken Treis gives some love to lighttpd in his post: My Favorite GLASS Front-End Server: lighttpd:

lighttpd maintains a running “load” for each FastCGI backend server. When an incoming request hits, lighttpd chooses from among the servers with the lightest load. This is exactly what I was looking for.

Photo by TW Collins (Creative Commons).

Fruit de ESUG 2009

[1]

That’s a huge platter of fruit de mer sitting in front of me (at the end of the table) and no it wasn’t all mine – there were 5 of us sharing that mound of seafood. The photo nearly says it all about ESUG 2009: a group of Smalltalkers eating seafood and talking shop.

Overall an excellent conference. Good presentations, good food, and good conversations. Congratulations to ESUG and the conference organizers for a job well done.

Follow these links for slides, pictures and videos. Here are some of my highlights

Glamour

Where did all the code go?

If you’ve ever tried to write a browser in Smalltalk you are aware of the amount of code that you must write. OmniBrowser cuts down on the amount of code involved, but you must still wrap your mind around the OB meta model, which is not always easy.

Enter Glamour. The following code produces an Object Explorer (multi-paned object explorer):

| browser |
browser := GLMFinder new.
browser list
	title: 'Collection';
	when: [:each | each isCollection].
browser list
	title: 'Object';
	display:  [ :anObject | 
        anObject class allInstVarNames collect: [:iv | 
            iv -> (anObject instVarNamed: iv) ] ];
	format: [:assoc |
        assoc key asString, ' : ', assoc value printString];
	send: #value.
browser text
	display: [:entity | 'self' ];
	title: 'Evaluator';
	update: #selection 
    on: $o 
    entitled: 'Open (o)' 
    with: [ :text :entity |
	    Compiler 
         evaluate: text selectedText 
         for: entity 
         logged: false ].
^ browser

Philipp Bunge and Tudor Girba have been able to distill window building down to the bare minimum. Very neat work. Oh, did I mention that besides a Morphic mapping, there is a Seaside3.0 mapping too?

Metacello

While I feel comfortable with the core engine of Metacello, I arrived in Brest, keen to get feedback on the spec creation API. Fortunately, I was able to spend the better part of 4 days working closely with Tudor Girba to refine the functionality and spec creation API. Following Doru’s suggestions, I have made some fairly significant changes to improve the overall usability of Metacello. Doru and I will continue working together on refining the things for the beta release of Metacello.

In addition to Doru’s feedback, I was able to talk to a number of different people about Metacello and the problems it is trying to address. All in all very positive feedback.

Seaside 3.0

Julian, Lukas and Philippe announced Seaside 3.0 at the conference and the Seaside Sprint brought Seaside3.0 tantalizingly close to beta.

GemStone will be releasing version 2.4 very soon now. Shortly after the 2.4 release is officially announced, we will make the Seasde3.0 beta available on GLASS.

The online book Dynamic Web Development with Seaside (sponsored by ESUG) was also announced at the conference.

CouchDB for GemStone/S

In the days leading up to ESUG Randall Schwarz visited our offices and piqued my interest in NOSQL databases:

Have you run into limitations with traditional relational databases? Don’t mind trading a query language for scalability?

Sounds like an ad for GemStone/S doesn’t it?

I chatted up the idea that it would a be a no-brainer for GemStone to provide a NOSQL database mapping for GLASS with a number of folks at the conference.

Philippe Marschall thought it was more than a good idea. In a matter of days (or was it hours) he had implemented a CouchDB mapping for GLASS using Seaside3.0. The code is up on GemSource in the CouchDB project.

Summary

There were lots of other conversations and many more interesting projects to discuss like Pharo and a port of Moose to GemStone. Needless to say, I came away from the conference with a todo list as long as your arm (to add to my already long todo list:).

The next few months should be a very interesting time as the seeds sown at this year’s ESUG come to fruition!

—–
[1]Photo by Damien Pollet (Creative Commons).

GemTools Client for Pharo 1.0 beta

This morning, Adrian Leinhard announced the first Pharo 1.0 beta release.

As most of you are aware, I’ve been heads down on Metacello going on several months now. I’m making very good progress.

In the last couple of weeks, I’ve been reworking the internal GLASS build procedures to use Metacello. I’ve also had a couple of GLASS users using Metacello for creating their own custom extents (i.e., loading only the projects that they are interested in, rather than the whole enchilada you get with the GLASS package).

When I read Adrian’s announcement, I thought this was a perfect time to kill two birds with one stone: release a version of GemTools that runs on the latest Pharo image and get a little more real world exposure for Metacello by using Metacello in the install/update procedure for the GemTools Client.

If you haven’t already been using the GemTools 2.3.1 Preview for all platforms (which is based on Pharo), then you should download the preview GemTools client and follow the instructions for setting up your session and verify that you can connect to your stone. You’ll need the session information and the gci files from the Preview to get things running with the Pharo 1.0 beta.

Installing GemTools Client in Pharo 1.0 beta

[Updated: 10/17/2009] Updated instructions for installing the GemTools Client in Pharo and Squeak can be found here.

If you’ve already been using Pharo as a GemTools client, then follow these instructions to get cooking:

1. Download and install the Pharo 1.0 beta. Don’t forget to get the latest Pharo vm for your platform (also available on the downloads page).
2. Load Metacello-All-dkh.6 from http://seaside.gemstone.com/ss/metacello (loads Metacello-Core, Metacello-MC, MetacelloProject and OB-Metacello).
3. Delete the Metacello-All working copy. Once you’ve got Metacello loaded, you don’t need Metacello-All anymore.
4. Execute the following expression to load the GemTools Client Metacello project (project meta-information):

   (MetacelloMCProject instance packageSpec
     file: 'GemStone-MetacelloProject-dkh.116';
     repositoryName:
       'http://seaside.gemstone.com/ss/GLASSproject';
     yourself) load

5. Execute the following expression to load the GemTools Client code:

   (GemToolsClientMetacelloProject version: '0.9') load

6. Execute the following expression to open the GemTools launcher:

   OGLauncher open

7. Copy the session information from your old GemTools Client to the new GemTools Client in your Pharo 1.0 beta image. Use the Edit session menu item on the Session Menu in the launchers.
8. Save the image.
9. Copy the gci files (gciForWindows.dll, gciForLinux.so, and gciForMacintosh.so) from GemTools-2.3.1-preview.app/Contents/Resources in the one-click into the directory containing your Pharo 1.0 beta image and changes files.
10. Press the Login button on the GemTools Launcher and you should be in business.

[Update 8/1/2009: Use the Update Client and load version 0.9.1, to get a bugfix for interrupt handling].

Moving forward, you’ll use the Update Client button or Update… menu item to get newer versions of the GemTools client.

The ink is barely dry on version 0.9 of the GemTools Client, so if you run into issues, send mail to the GLASS Beta Mailing List (subscription required).

Next GLASS Beta Update

If things go smoothly, I expect to have a new GLASS version (using Metacello of course) available in a couple of weeks. The new update will include Seaside 2.8.4,  Pier 1.2 and a handful of bugfixes.

Metacello

My priorities at the moment are to:

1. Use Metacello to replace the old GLASS package system for communicating software updates and package dependencies.
2. Finish implementing the features that are planned for 1.0 so that I can go into beta with Metacello. I hope to have gone beta with Metacello prior to ESUG.
3. Finish up the Metacello tutorials so that other folks can start using Metacello for their own projects.
4. Define a Metacello project for Swazoo 2 and Aida to make it possible for folks to track the ongoing development of GLASS while using Aida.

Seaside 2.9

We plan to release GemStone/S Version 2.4 within the next couple of months. 2.4 includes VM support for partial continuations, so it will be feasible to run Seaside 2.9 on top of GLASS.

Deep SIXX with XMLPullParser

Ken Treis has post up called Deep SIXX with XMLPullParser about how he and the folks at his company use SIXX to transfer objects between GemStone and Pharo.

Ken ported Antony Blakey’s XMLPullParser from VisualWorks to Squeak in a (successful) attempt to reduce the amount of memory consumed while copying large object graphs using SIXX.

If you are developing in Squeak/Pharo and deploying in GemStone, then you should check out Ken’s work.

Photo by jayhem (Creative Commons).

GLASS Beta Update: Fixin’ Some Bugs (Preview)

[1]

In the month since the last beta update, I’ve been mostly heads down working on Metacello a version control/configuration managements framework. Metacello isn’t ready for public consumption yet, when it is, you will hear about it here. [Update later that day] Metacello is not a Monticello replacement, it is a Monticello enhancement.

Besides Metacello there have been a handful of bugfixes that are worth packaging up. The most important of which gets rid of potential infinite recursion in ExceptionA>>description.

GemStone-dkh.467

No GemTools changes. Added GLASS.230-dkh.231 to update list as an alpha release.

GLASS.230-dkh.231

GLASS bugfixes and additions:

• fix for ExceptionA>>description infinite recursion problem reported by Dario
• non-recursive MCAncestry>>ancestorsDoWhileTrue:
• added methods to be able to cleanUp MethodVersionHistory instances (thanks Gerhard)
• fix problem with recompile:, where method hasn’t been loaded because of other issues
• bugfix 39932 – Url decoding not decoding ‘+’ in url
• fix a problem reading an MCZ reported by Dario … turns out we needed a ‘null’ Error handler:)
• incorporate Squeak protocol additions from Ramon Leon.

Update Process

To update an existing installation to GemStone-dkh.467 and GLASS.230-dkh.231, follow these instructions. If you have recently downloaded an appliance or installed GemStone/S 64 2.3.1, then follow these instructions telling you how to get a recent GemTools client vm.

If you update to GLASS.230-dkh.231 from a version prior to GLASS.230-dkh.231, a Warning dialog will pop up – proceed through the warning.

—–
[1] Photo by dashananda (Creative Commons).

Easy Remote GemStone

Norbert Hartl just published Easy remote gemstone, an article outlining the steps for setting up a linux host for remote access by the GemTools. Norbert details the steps for either poking holes in your firewall or using an ssh tunnel.

Photo by extratony (Creative Commons).

Seaside/GLASS Success Story

Andreas Brodbeck published Seaside project is live! a report on his successful use of GLASS and Seaside for a course management tool application.

Andreas shares some of his tips for doing development in Squeak/Pharo and deploying in GemStone/S.

Photo by gorgeoux (Creative Commons).

GLASS Beta Update: Working with SOAP (Preview)

[1]

If you find yourself wishing that you could work with SOAP and GLASS, you don’t need to head out to the shed and drag out the old bucket and squeegee. All you need to do is load up the latest preview GLASS version and you’ll be ready to go!

HTTP Server and Client

Before getting started with SOAP, we need to talk a little bit about Hyper. SOAP needs an HTTP client to access services and an HTTP server to provide services. While there are a number of good Smalltalk-based HTTP server implementations floating around out there, there aren’t very many good HTTP Clients!

Fortunately,  Bruce Badger has been continuously updating his Hyper HTTP server and last fall he released a version of Hyper with a very nice HTTP Client implementation. In November, I used the Hyper HTTP Client in a port of Masashi Umezawa’s SoapCore and created a GLASS.231 branch. I needed to create a branch, because the new Hyper was incompatible with the version of Swazoo that I was using for Seaside.

Recently I’ve received a number of requests for SOAP support in GLASS, so I bit the bullet last week and tackled the Seaside/Swazoo/Hyper issue. After a couple of days working through various solutions, I decided to ditch Swazoo and write a simple service class for gluing together Hyper and Seaside. See the section on Using Hyper for details.

AIDA

To be fair, the Swazoo code used in GLASS was several years old (at least). Janko Mivšek has a newer version of Swazoo (Swazoo 2) ported to GLASS, but for SOAP support I need an HTTP Client and the latest Hyper is the ticket. To use Aida with GLASS going forward, you should probably unload the Hyper package, before following Janko’s instructions for running Aida/Web on GLASS.

SOAP

Back in November, I was able to find 3 SOAP servers in the wild that were still up and running (4s4c, Microsoft Soap Interop Server and EasySoap++ – as of this writing 4s4c appears to be MIA). The servers were built based on the ROUND 2 SOAP Interoperability Tests Specification a (proposed) SOAP service interface that can be implemented by SOAP implementations as part of an interoperability testing process. This page is the best resource for information about the Interoperability Tests and this page has the results of the Interoperability Tests as of November 2001. The tests were arranged by the SOAP Builders Yahoo group and this looks like the message that kicked things off.

I was happy to find a set of servers out there that were still alive, since the servers for the original interop tests built into SoapCore were no longer available! I then built a client and server on top of SoapCore (SoapInteropClient and SoapInteropServiceImpl) and a set of TestCases (SoapInteropTestCase) so that I could test the GLASS SoapCore implementation against the 3 external services and an internal service. By default the test cases for the external services are disabled (see SoapInteropTestCase class>>skipInteropTesting: for information about enabling the tests against the external services).

If you find that you need to use SOAP with a project start by looking at the interop examples. Also read the sections GemStone Processes and GCI and SOAP/HTTP Server Development Tips for information on doing SOAP development in GLASS.

SOAP Server Transactions

I have not done any work to add transparent persistence to the SOAP server, but I would imagine that the approach used by FastCGISeaside>>answerResponderRoleCheckingLock: and SeasideHTTPService>>answerToCheckingLock: will work for SOAP. The same rules apply:

• Perform an abort before handling the SOAP request and perform a commit before returning the SOAP response. If no persistent objects were modified while serving the request (a read only request for example), the final commit is no more expensive than an abort.
• One concurrent transaction per gem. Add more gems for handling concurrent requests (presumably Apache or lighttpd can be used to round robin the SOAP requests).
• On a denied lock or transaction conflicts abort and retry the request a short while later.

If anyone is interested in adding transactions to a SOAP server let me know and I’ll whip out a prototype. Right now I assume that the primary interest in SOAP is as a client.

WSDL

Paul DeBruicker attended the GLASS Workshop in Santa Fe earlier this month and recently Paul announced (beta mailing list subscription required) his desire to port the Spray client from Dolphin to GemStone/S. Spray is a Dolphin-based package written by Steve Waring that adds WSDL support to SoapCore.

Nice timing.

Hernan Wilkinson has offered to work on the project along with Paul and I’m sure if anyone else interested in SOAP/WSDL support for GLASS, that your help would be appreciated. When it comes to web servers, I’m sure that the more players involved in interoperability testing the better the final product. Join and send mail to the beta mailing list if you would like to participate.

Using Hyper: SeasideSite replaced by SeasideHTTPService

“Ditching Swazoo” is not quite as bad as it sounds. Anyone using FastCGI will not be affected and the new version of Hyper looks to be an improved version.

If you use Hyper in production, then I would recommend that you move forward cautiously. I haven’t put the new Hyper under stress for this preview release. I intend to do so before making a beta release. Hopefully the next beta release (non-preview) will be the last beta release, so I plan to subject the system to some heavy load for both FastCGI and Hyper. As it currently stands, Hyper passes the unit tests and I’ve done limited manual testing.

If you are using $GEMSTONE/seaside/bin/startSeaside_Hyper, then you need to edit the file and replace the chunk of code that looks like this:

server := SwazooServer singleton.
server initialize.

site := (SeasideSite new)
    name: 'Seaside';
    initialize;
    host: GsSocket getLocalHostName
        ip: (GsSocket getHostAddressByName: GsSocket getLocalHostName)
        port: $1;
    initializeResourceFromUriPattern: '/', 'seaside'.

server addSite: site.

GsFile gciLogServer: 'Hyper Server started on port ', $1 printString.
SwazooServer startSite: 'Seaside'.
"does not return, unless there's an error"

with a chunk of code that looks like this:

server := SeasideHTTPService onPort: $1 acceptInForeground: true multiThreading: true.
GsFile gciLogServer: 'Hyper Server started on port ', $1 printString.
server start.
"does not return, unless there's an error"

If you have been using SeasideSite launchSeaside: 9765 to run Hyper using a GemTools Client, then you should use SeasideHTTPService startServiceOnPort: 9765 instead.

Finally don’t skip the sections GemStone Processes and GCI and SOAP/HTTP Server Development Tips, since they contain valuable information on doing Hyper development in a GemTools Client.

GemStone Processes and GCI

When you do a login from a GemTools Client, a separate Gem process is started on the stone’s machine. The client Smalltalk image and the Gem process communicate via GCI using a relatively simple protocol:

• Commands are initiated by the client (most often sending a message to to an object or executing code in a string). When a GCI command is executed in the Gem a new GsProcess is created and the command is run within the context of that new process.
• While the command is executing in the Gem, the client is blocked waiting for a response (there is a non-blocking mode for GCI which we use for in the GemTools Client, however, the operation is still blocking as far as the end user is concerned, because the GCI API is not thread safe).
• If you hit ALT-. in your Squeak/Pharo image, we catch the client-side interrupt and use the GCI to send a Hard Break to the GsProcess running in the Gem. This results in a GemStone debugger being opened. If you close the debugger the GsProcess is terminated. If you Proceed, the GCI API is used to resume execution of the interrupted GsProcess.
• Unhandled Errors that occur during execution on the Gem are passed over the GCI to the client where we arrange to bring up a GemStone debugger. Note: if you use the [unset|set] UsePopUpOnDebug command on the Admin… menu you can arrange to open a Squeak/Pharo debugger on the client-side Process.
• A command finishes when the GsProcess created to run the command ‘falls off the end’ (like a doIt) or there is an explicit return in the executed code. In either case the result of the command is returned across the wire to the client.
• Execution of code in the Gem blocks until another GCI command is received.

The Gem blocks when a command finishes execution. If you execute a command like:

[[ true ] whileTrue: [ (Delay forSeconds: 10) wait ]] fork.

The command will return immediately and the Gem blocks until you execute another GCI command.

For normal development activities, this doesn’t make too much difference, but if you are trying to debug a web server or a SOAP server, then you need be aware that unless you have explicitly given the Gem control (via a GCI call), your Gem threads will be blocked.

SOAP/HTTP Server Development Tips

A lot of issues can be fleshed out using unit tests, but occasionally you hit an issue that only appears when the system is running as a server. For Seaside applications we’ve arranged for continuations to be used for the remote debugging of application errors.

I have not added continuation-based debugging to the SOAP server (could be done if there is interest), so in order to debug a SOAP server, you’ll need to run your development vm as a server. You need to do the same thing if you want to debug internal server errors for Hyper or FastCGI.

Given that you understand that your Gem threads are blocked:) while your GemTools Client is active and given that you’ve opened a Process Browser you are ready to do server-side development. At the end of this section, I provide instructions for running SOAP/Hyper/FastCGI servers within your development vm.

For the purposes of discussion, I’ll assume that you’ve started a Hyper server and that you’ve navigated to the WAErrorTest page (click on the image for full size view):

Click on the Raise error link and click on the Debug link and the debugger will pop up in the GemTools Client:

The third process involved is the main hyper thread that is listening on port 9765:

So we’ve got three processes of interest: the main accept connection loop for Hyper, a thread forked off by Hyper to service the browser connection, and the a thread forked off by Seaside to service the Seaside request. We’ve got a debugger open on the the third thread and since we signaled an Error, the exception isn’t resumable. If we close the debugger control will be maintained by the client and the Gem execution is blocked.

Once the debugger is closed you can do a couple of things:

• Select each of the other two process and use the terminate menu item to terminate the process. If you go this route, you’ll (obviously) need to restart the Hyper server to serve HTTP requests.
• Select the process that is waiting on a Semaphore and terminate it. If you go this route, you simply need to the use the yield forever menu item on the Process Browser to return contol to the Gem and allow the processes to run freely.
• You should also be able to simply use yield forever without terminating any process – if you look closely you’ll see that the process in the debugger has an #ensure: block that should #signal the semapore that the other process is waiting on. Unfortunately, that doesn’t correctly at the moment. The fact that we’re bringing up a debugger with a hard break, is a special case and I’ll be looking at this bug more closely.

If you hit Alt-. while the server has control, control will be returned to the client, however, you can’t determine which process will be interrupted – the process that is running when the vm detects the interrupt will have the debugger brought up on it.

For 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 object log after running the Soap unit tests, for examples.

The following three sections provide specific information for debugging server code.

Soap Server

The following expression starts an HTTPServer listening on port 8823 that is ready to serve SOAP requests from the ROUND 2 SOAP Interoperability Tests Specification:

SoapInteropServiceImpl registerAllServices.
(Delay forMilliseconds: 100) wait.

The Soap service is started in the background. so the Delay is necessary to allow the server thread to make enough progress to be ready to service client requests. This setup is aimed at convenience for running tests. For a production server, you should arrange for the HTTPServer to be started running in the foreground (see SoapHTTPService class>>named:onPort:).

If you are trying to debug a Soap server error, here are a couple of useful methods to set breakpoints in:

• SoapHttpConnector>>send:to:with: in the SoapHttpGenericError handler.
• SoapEnvelopeBuilder>>buildSoapEnvelopeFromXmlString: in the Error handler.
• SoapServiceHandler>>dispatch:with: in the Error handler.
• HTTPConnection>>internalErrorHandler.

Hyper Server

The following expression starts an HTTPServer listening for HTTP requests on port 9765:

SeasideHTTPService startServiceOnPort: 9765

If you are trying to debug a Hyper server error, here are a couple of useful methods to set breakpoints in:

• SeasideHTTPService>>internalServerMalfunction:
• HTTPConnection>>internalErrorHandler.

FastCGI Server

For FastCGI you need to edit your Apache (or lighttpd) config to route all requests to a single server. You also need to stop any FastCGI gems that may be running (you can use the Stop Seaside gems command on the Admin… menu). Then run the following expression to start a FastCGI server listening on port 9001 in your development vm:

FSSeasideHandler startUp: 9001.

If you are trying to debug a FastCGI server error, here are a couple of useful methods to set breakpoints in:

• FsSeasideHandler>>internalServerMalfunction:
• FSConnection>>handleError:
• FSConnection>>handleFSError:
  

GemStone-dkh.466

A number of commands were added to the GemTools Launcher.

• [unset|set] UsePopUpOnDebug command added to Admin… menu. If you consistently get an out-of-memory error it may be caused by a recursive error. Setting UsePopUpOnDebug causes a pre-debugger window popup to appear. If the pop-up appears instread of an out-of-memory notifier, select the Debug Squeak stack option and send the Squeak stack as a Bug Report to the beta mailing list for analysis. If you choose Debug GemStone stack the normal GemStone debugger will be opened (although in an out-of-memory situation, it is likely that there is an error opening the GemStone debugger).
• System Browser command added to Tools… menu.
• Mark For Collection command added to Admin… menu.
• Browser Preferences submenu to Admin… menu which allows you to set preferences directly on server instead of inheriting from client (which might require an logout/login sequence).
• Override FFI>>finalize with a bugfix that eliminates that annoying finalize error that occasionally pops up.
• JadeServer class moved to server-side for faster logins. A version of JadServer still exists on the GemTools Client for backwards compatibility with older server versions.

Take a look at the GemTools change log for a complete history of changes since GemStone-dkh.449.

GLASS.230-dkh.229

In addition to the Hyper overhaul and addition of SOAP support:

• finish fixing Bug39828 – fastcgi and uploadfile problems (thanks Dario)
• suspend, terminate, yield 5, and yield forever commands were added to the Process Browser.
• Several packages have been  removed from the GLASS package during the preview process. Normally these orphaned packages remain in your repository unless you explicitly unload them. However, with GLASS.230-dkh.220 I decided that the following 5 packages needed to be explicitly removed (via preDoIt): SwazooSeaside, Swazoo, SqueakSource, MonticelloConfigurations, TinyWiki. If these packages are not explicitly unloaded, the unit tests will not pass.
• JadeServer class moved to server-side for faster logins.
• The package GemStone-Scaffolding was added to GLASS. See James Foster’s Scaffolding for GemStone screencast for more information.
• The #defaultAction for Warning has been changed to bring up a confirmation window which will permit you to continue or bring up a debugger. This means that you’ll start seeing warning messages during Monticello operations that were silent before.

Take a look at the GLASS change log for a complete history of changes since GLASS.230-dkh.216.

Update Process

To update an existing installation to GemStone-dkh.466 and GLASS.230-dkh.229, follow these instructions. While it is possible to use the Monticello Browser for upating, I am now recommending that you use the Update Client and Update GLASS menu items on the Update… menu to avoid issues that may be introduced by UI changes.

When you update to GLASS.230-dkh.229 a Warning dialog will pop up (due to the changes in the #defaultAction for Warning) – proceed through warning.

—–

[1] Photo by sea turtle (Creative Commons).

Learning Web Development with Seaside

James Foster has just announced the availability of the Seaside tutorial Learning Web Development with Seaside, that he has been developing for several months. The tutorial is the basis of his popular Weaving a GLASS Web workshop and his SoCal tour.

The tutorial is being made available under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 License.

If you are interested in having a Seaside tutorial/workshop in your area, please contact James at James dot Foster at GemStone dot com.

Photo by Rob Shenk (Creative Commons).