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

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

Version Mismatch (preview)

[1]

A couple of weeks ago we published a one-click GemTools 2.4 download. We named the file 2.4 to differentiate it from the 2.3.1 GemTools client download, but we inadvertently included 2.4 gci files in the download – we haven’t released 2.4 yet.

We’ve now made two one-click GemTools preview downloads available on the download page:

• GemTools 2.3.0-preview for all platforms (for use with version 2.3.0 of GemStone/S, like the 1.0beta11 appliance)
• GemTools 2.3.1-preview for all platforms (for use with version 2.3.1 of GemStone/S)

If you are using the GemTools 2.4 download and have experienced problems then you should definitely download and use the one-click file that matches your stone version.

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

GLASS Beta Update: Reducing Round Trips (Preview)

[1]

As much fun as round trips can be, when those roundtrips are over the WAN using GemTools, it can get a bit tiring.

A little over a month ago (GLASS.230-dkh.194) I added the class OBUpdateConcentrator to GLASS. The job of the concentrator is to collect OB-related #update: messages sent to Morphic widgets on the client from the server and ship them across the wire in one roundtrip instead of n roundtrips (see this section for more info). The net effect is that the number of roundtrips for browser interactions is reduced by about 50%.

I didn’t turn on the concentrator for the latest preview, because there were some apparent update problems (they may have been transient Pharo problems). After announcing the preview, I realized that folks who need to connect over the WAN probably wouldn’t mind a few update problems in return for better UI performance. So I decided to make another preview drop primarily aimed at providing relief for roundtrip sufferers.

In order to turn on the concentrator, the method ClientForwarder>>_asOop needs to be implemented. the method contains a primitive call and you need to be SystemUser to compile the method, so you need to use topaz (your input highlighted in gray):

foos:c_gss64bit_230>topaz -l
___________________________________________________________________________
|                             Configuration Files                             |
|                                                                             |
………………….
|_____________________________________________________________________________|
topaz> set user SystemUser pass swordfish
Warning: GemStone is clearing the previous GemStone password.
topaz> login
[Info]: LNK client/gem GCI levels = 830/830
[Info]: User ID: SystemUser
[Info]: Repository: c_gs64stone_230
[Info]: Session ID: 2
[Info]: GCI Client Host: <Linked>
[Info]: Page server PID: -1
[Info]: Login Time: 03/25/09 13:46:51.706 PDT
gci login: currSession 1 rpc gem processId -1
successful login
topaz 1> method: ClientForwarder
_asOop
<primitive: 86>
self _primitiveFailed: #asOop
%
topaz 1> commit
Successful commit
topaz 1> logout

After defining the method and committing, it is  worth turning off some of the optional UI features (in the Preferences Browser under the browsing category), namely: annotationPanels, mercuryPanel, optionalButtons, and syntaxHighlightingAsYouType. These OB options, while useful, consume additional roundtrips for each refresh of the browser. Yes, the preferences you set in your client (either Squeak or Pharo) will be propogated to the server…

Last night I ran some tests from home running against a stone on my office desktop machine and got a 3x performance boost (3 seconds per click versuse 10 seconds per click). I  started doing some development tasks to make sure that all of the browsers were functional when  optionalButtons is disabled (it turned out that the Test Runner wasn’t the first time around) and while I wasn’t doing intense development (I was keeping an eye on the Utah/Rockets game), the performance was good enough that I forgot that I was working on a stone in the office.

GemStone-dkh.449

There have been no major changes in the GemTools since the last preview release other than a new Find… Menu command was added called Case Sensitive String…, which searches through all method source doing a case sensitive search.

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

GLASS.230-dkh.216

In addition to the roundtrip performance improvements, a number of bugs have been fixed:

• fix Bug39828 – fastcgi and uploadfile problems
• fix Bug39766 – WAGsWalkbackErrorHandler is not subclassable
• fix Bug39778 – Collection should include #ifNotEmpty:ifEmpty:
• fix Bug39810 – Can’t use DateTimes in SIXX
• fix Bug39869 – Unicode and debugging
• fix Bug38428 – a collection of glass shards in the browser
• fix Bug38458 – Monticello Browser – Viewing history has impact on repository pane
• fix Bug39369 – MCReader(C)>>readerClassForFileNamed: needs more error checks
• fix Bug39552 – case-sensitive methods containing search
• fix Bug38320 – SystemBrowser update problem
• fix Bug38389 – WB, trying to load a package that had it’s working copy deleted
• fix Bug38436 – Nothing happens on Repository Browser:”refresh”
• fix Bug38438 – Browse Monticello package needed
• fix Bug39756 – need to implment String>>restoreFromSnapshot:
• fix Bug39763 – Date>>+ has bugs
• fix Bug39579 – confusing warning from Monticello save after a merge
• fix Bug38424 – Need way to propogate compiler warnings to tools
• fix Bug39755 – MC1 should raise errors when there are unloaded classes methods
• fix Bug39767 – possible stack overflow during FileDirectory>>forceNewDirectoryNamed:
• fix Bug38550 – Confirmation for Monticello unl;oad package

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

Updating

If you are already using a preview GemTools client, you only need to follow these instructions. If you are using a version of the GemTools Client earlier than GemStone-dkh.441, then you should follow these instructions.

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

GLASS Beta Update: Cooking with GLASS (Preview)

[1]

In the last month, Gerhard Obermann and I have been pretty busy. Between us we’ve made over 80 updates to the GemTools package and over 20 updates to the GLASS package.

At this point in time, I think that the GemTools Launcher (GemStone-dkh.441) and the OmniBrowser tools are stable enough that you no longer need to be Brave and/or Curious to take the new tools and GLASS.230-dkh.209 for a spin. In fact the tools are probably in better shape now than they’ve ever been (I haven’t seen the MNU storms that would periodically appear in the old client for quite awhile). If you’re reluctant to upgrade, check out the new Backup/Restore commands. Being able to backup/restore your repository from the GemTools Client should ease your mind.

I still have between 50 and 100 issues that I want to address (mainly on the server-side) before the next beta release. In the mean time, I am all but done with the UI changes and I would like feedback from folks on the new commands. If you haven’t already, join the beta mailing list and send mail with your comments and suggestions.

If you run into (gasp!) a bug, use the new Bug Report commands to report the bug. Honestly, I would rather have people report 100 duplicate bugs than miss 1 valid bug report – don’t assume that I know about the problem!

GemStone-dkh.441

There have been a significant number of changes to the GemTools Client since the last preview release, so many that I decided to update the old Terse Guide to the GLASS Tools with a new post: Terse Guide to the (new) GLASS Tools. All of the menu items for the GemTools Launcher are documented.

If you haven’t already created a new GemTools client smalltalk image, then follow these instructions.

If you’ve already updated to a preview release, then you’ve already got a new Squeak/Pharo image and all you need to do is to update to the latest version of the GemTools Client, using these instructions.

Take a look at the GemTools change log for a complete history of the changes made between GemStone-dkh.355 and GemStone-dkh.441.

GLASS.230-dkh.209

In addition to the support needed for the GemTools Launcher a number of bugs were fixed:

• Bug39820 – packages dirtied unnecessarily when recompiling subclasses
• Bug38105 – HTTPSocketError not correctly loaded
• Bug38794 – Subclass creation method leaves instance creation disabled
• Bug39838 – ExceptionA class>>hasFixFor39741 breaks some things
• Bug38146 – unload class and remove method should clean up undeclared sybmols
• Bug39798 – UndefinedSymbols is not maintained correctly
• Bug39850 – MCPackageBrowser doesn’t update when package dirtied
• Bug39345 – ‘Squeak browser tools need move-to-category button’
• Bug39578 – ‘”revert to version” in “Versions of” method browser does not autocommit’
• Bug39303 – sorting of change list in Monticello brower is strange
• Bug39823 – missing OSkSocketReadStream>>upToEnd
• Bug39800 – SeasideTesting has probably decayed…
• Bug39777 – Cannot ‘browse’ ProtoObject without a walkbalk
• Bug39772 – Class>>allSubInstancesDo: always fails
• Bug39582 – lots of key-not-found errors using Vocabulary browser
• Bug38140 – ‘highlight inspect’ feature for debugger
• Bug38274 – need visual separation between ancestors in MCWorkingCopy>>summary
• Bug38304 – CTL-i on a String or Smallinteger ends up with Squeak inspector
• Bug39662 – Inspecting a float in GLASS results in a ‘Float out of Range’ error in Squeak
• Bug39827 – missing base method for GLASS
• Bug39795 – MAPriorityContainer>>remove: fails unexpectedly

Other highlights include:

• A belated update to Seaside2.8.3.
• Update to Pier 1.1.1.
• Improved Debugger, Inspector, and Chasing Inspector.

The following packages have bee removed from the GLASS package:

• MonticelloConfigurations
• Pier-LightBox
• Pier-Twitter
• SqueakSource
• TinyWiki

These packages are not automatically removed by the update process. If you aren’t using them, then you should manually unload them using the Monitcello Browser. If you don’t remove them you may see test failures for the UndefinedSymbolsTest and SentButNotImplementedTest. After removing the above packages the tests should run clean (4182 run, 4182 passed, 0 failed, 0 errors).

Once you’ve updated to the latest version of the GemTools Client, follow these instructions to update the GLASS server software to GLASS.230-dkh.209.

Take a look at the  GLASS change log for a complete history of the changes made between GLASS.230-dkh.187 and GLASS.230-dkh.209.

—–

[1] Photo by placbo (Creative Commons).

GLASS Beta Update: Preview and Pharo

[1]

[Update 3/16/2009: see the post GLASS Beta Update: Cooking with GLASS (Preview) for the latest preview information].

With the latest dev release of Pharo (pharo0.1-10243dev09.02.3), the new GemTools Client has stopped working correctly. From what I can see, a number of updates were made to OmniBrowser which causes the buttons to disappear from the OGLauncher….I stopped looking for additional problems at that point:). I’m not going to complain, though, the Pharo image is pretty cool already and it is still pre-Beta.

As of pharo0.1-10213dev09.01.3 (and probably pharo0.1-10236dev09.02.2.zip) the GemTools Client was working correctly. Until further notice don’t use the latest versions of Pharo.

I have been pretty busy fixing bugs recently and anticipate a refresh of the GemTools Client and the GLASS package in a week or so.

—–
[1] Photo by milomingo via Flickr (Creative Commons).

GLASS Beta Update: Simplified Updating (Preview continued)

[1]

[Update 3/16/2009: see the post GLASS Beta Update: Cooking with GLASS (Preview) for the latest preview information].

As a few brave souls discovered, the process for updating to the new crop of tools is a little more complicated than it needs to be. A couple of them even got their fingers pinched during the update:).I was looking for feedback, so I appreciate the effort. Hopefully their sacrifices will be worthwhile.

There weren’t that many changes made to the OmniBrowser code in GLASS post GLASS.230-dkh.177, however, the changes that were made created havoc for any windows opened prior to the update. I had originally hoped that a couple of errors between friends would be okay, but enough people ran into odd problems during the updates to GLASS.230-dkh.182 and GLASS.230-dkh.183, that it became clear that the update process needed to be improved.

I tried a number of things including an attempt to work around the problems with the new GemTools Client code. I was successful in getting the new GemTools Client to run against the older versions of GLASS (which is a step in the right direction), but I wasn’t able to get around the crashes and walkbacks. With a nudge from Igor Stasenko, I finally settled on using an update script.

In the end I made two significant changes to the update process:

1. Update the GemTools client before updating the server. In the past we’ve updated the server-side code first and then updated the client-side code. However, since we’re recommending that users move to a completely different client image, I think it is easier to get the client update out of the way before doing the server update, especialy now that the latest GemTools Client code will run against older versions of GLASS. Any problems in getting the GemTools Client built and connected to the server can be worked out before making changes on the server side.
2. Update the Server using a script instead of the Monticello Browser. With this particular update, using a script is necessary since the windowing mechanism for the current session becomes broken during the update. In the long run, it is useful to have a script-based update mechanism that can be used to update production repositories that aren’t easily accessed through the GemTools Client.

Preview GLASS.230-dkh.187

Since GLASS.230-dkh.183 I’ve made a handful of improvements that are worth trying out:

• merge Pier-Model-lr.245, load Pier-Blog-lr.103.
• OSTestRunner bugfixes.
• debugIt implemented. debugIt opens a Debugger on the selected code, setting a breakpoint on the first statement.
• exploreIt implemented. exploreIt opens a Chasing Inspector on the result of evaluating the selected code.
• Remove MonticelloConfigurations as a required package.

If you’ve been following the mailing list, you will have noted that we’ve received a flurry of bug reports in the last week or so. I appreciate the bug reports, but because I intend to address a good number of them before the next beta update, the next update will be deferred for at least 2 more weeks.

1. Update GemTools Client: GemStone-dkh.355

If you choose to use Pharo as the basis of your GemTools Client, be sure to download the latest dev image as a starting point. As of today, pharo0.1-10211dev09.01.2.zip is the latest dev image. If you choose to use Squeak as your GemTools Client, start with a basic 3.10 image like Squeak3.10-7159-basic.zip.

Use the Universe Browser, select the GemTools-Client version 0.355 package (in Network category) and install it. Note that during the install using 3.10, you will be warned about an extension to OTToolset – is is safe to proceed.

Open a Workspace and evaluate the expression ‘OGLauncher open‘ and then edit the Glass session, inserting the login information that is relevant to your system – stoneHost, gemHost, stoneName and netLDI.

Login using the GemToolsLauncher and get ready to update the GLASS repository to GLASS.230-dkh.187. Note that during the login using Pharo, you will get a warning about using a deprecated #authorInitials: api – it is safe to proceed.

Even though the Class Browser and Monticello Browser are functional, I wouldn’t try to do too much work using the new GemTools Client and an old version of GLASS. For best results you should immediately update your GLASS repository.

I’ve used the new GemTools Client to upgrade GLASS.230-dkh.164 (corresponding to 2.3 release and the 1.0beta11 appliance) and GLASS.230-dkh.177 (corresonding to the 2.3.1 release) with good results.

Since I’m still actively working on the new tools, I don’t plan to publish a ‘one-click’ GemTools Client, until the rate of change has settled down.

2. Update GemStone Repository: GLASS.230-dkh.187

The following update script:

1. Adds a method to SystemChangeAnnouncement.
2. Turns off autoMigrate.
3. Loads GLASS.230-dkh.187 from the GemSource repository.
4. Sets autoMigrate back on.
5. Performs a commit.

The code should be pasted into the workspace pane of a Gemstone-dkh.355 GemTools Launcher or run from a topaz session.

| httpRepository version rg |
SystemChangeAnnouncement 
    compileMethod: 'item: ignored' 
    category: 'accessing'.
MCPlatformSupport autoMigrate: false.
httpRepository := MCHttpRepository
    location: 'http://seaside.gemstone.com/ss/GLASS'
    user: ''
    password: ''.
"pick up the GLASS repository if it's already
 in default repository group"
MCRepositoryGroup default repositoriesDo: [:rep |
    rep = httpRepository ifTrue: [ httpRepository := rep ]].
version := httpRepository
    loadVersionFromFileNamed: 'GLASS.230-dkh.187.mcz'.
version load.
rg := version workingCopy repositoryGroup.
rg addRepository: httpRepository.
MCPlatformSupport autoMigrate: true.
System commitTransaction.

If you’ve used the GemTools Launcher to run the update script you should logout and then log back in before continuing with your work. If you use topaz to update the repository, you need to remember to use a GemStone-dkh.355 GemTools Client to connect to your repository.

The GemTools Client is still in preview, so unless you are brave and/or curious, I’d recommend that you stick with a more stable version of GLASS.

———-

[1] Photo by EricGjerde via Flickr (Creative Commons).

GLASS Beta Update: Holiday Tools (Preview continued)

[Update 3/16/2009: see the post GLASS Beta Update: Cooking with GLASS (Preview) for the latest preview information].

Over the Christmas holidays my grandson Oscar and I got serious about tools.

Oscar learned how to use a drill and I built an OmniBrowser-based version of TestRunner to go along with the new GemTools Launcher.

GemTools Launcher updates

Gerhard Obermann has been busy working on the tools, too. He’s made a number of improvements to the Launcher:

• Empty and Show Object log menu items added to the Doit button.
• Added a Transaction button as a home for Commit and Abort.
• Tweaked appearance in a number of places.

To pick up Gerhard’s changes use the Package Universe browser to load GemTools-Client version 0.335. If you haven’t already loaded the tools preview, follow these instructions.

OSTestRunner

OSTestRunner is a clone of the Squeak TestRunner with the functionality molded to fit within OmniBrowser. OSTestRunner can be run in Squeak, Pharo or GLASS. Click on the image below for a full-sized view of the Pharo version.

To use with Squeak or Pharo, check out the instructions in the announcement message.

To load into GLASS:

1. Follow the instructions for bringing up the tools preview (make sure you load GemTools-Client version 0.335 on the Squeak side).
2. Log into GemStone (using the new launcher) and load GLASS.230-dkh.183 from the GLASS project on GemSource, using the GLASS Monticello browser.
3. Logout and log back in to make sure that the client is updated with the new server classes and enjoy.

I’m still tweaking OSTestRunner for GLASS roundtrip performance and I want to have better user feedback while the tests are running, but other than that I’m happy with the new OSTestRunner – hey all of the menus and buttons work on the new version!

Monday, I’ll dive back into MC2 and will beat on the new tools (tweaking here and there), so you can look forward to a general release of the GemTools towards the end of the month.

GLASS Beta Update: Tools Tuneup (Preview)

[1]

[Update 3/16/2009: see the post GLASS Beta Update: Cooking with GLASS (Preview) for the latest preview information].

It’s been awhile since I’ve done a major overhaul of the GLASS tools, so it’s about time to get a new update of the tools into circulation. Even if it is a preview.

As reported a couple of weeks ago, I updated to the latest OmniBrowser package in order to get the MC2 UI to work. Technically, I’ve been on vacation the last two weeks, but a major snowpocalypse in Oregon put the kabosh on plans to head to Cannon Beach with the doggies, so I’ve found myself working on the tools.

OB-Standard

The first task was to update to the latest OB-Standard tools. In the last year a lot of work has been put into the OB-Standard tools. David Röthlisberger and Damien Cassou have been busy producing some pretty nice OmniBrowser-based tools. Besides merging the code, I fixed some long standing GemTools problems:

• window updating – now when you save a method in one window, the code will be updated in another window.
• window colors enabled.
• Version browser buttons.
• Monticello Patch browser menu includes browse, implementors, and senders.
• eliminate use of FileList for defining directory-based monticello repositories (too slow over GCI!) – now you just supply a path string.
• Gerhard Obermann enabled drag drop for method recategorization.

OB-Tools

Next on the agenda was to update to the latest OB-Tools. Lukas Renggli has implemented a full range of tools using OmniBrowser, including a Debugger, Inspector, FileBrowser, ProcessBrowser, Workspace and Transcript . So far I’ve integrated all of these tools except the Transcript – right now I use the client Transcript. Notable fixes and improvements include:

• inspectors embedded in debugger window – the new debugger almost looks like the debugger that your Grandpa used:).
• automatic context selection after a step in the debugger.
• eliminate the chasing inspector – replaced with a standard inspector. I think I’ll miss the chasing inspector though.
• out, through, and step to selection in debugger
  • out steps until execution leaves the current context, either via return or by entering a block.
  • through steps until execution returns to the home context (useful for stepping through block execution).
  • step to selection steps until the selected step point is on the stack.

BTW, if you have free time and the inclination, Lukas is looking for someone to take over development of the OB-Tools. We are using and maintaining OB-Tools for GLASS, so I will be chipping in with fixes on an occasional basis, but I can’t commit to the task of Squeak-specific updates – at least right now.

Package Universe, Pharo and Mars

For this round of development, I started out using a Squeak 3.10 basic image (Squeak3.10-7159-basic). As a consequence, the formula for creating the GemTools client image was fresh in my mind so I decided to create a package in the Package Universe for the GemTools-Client. With the Pharo beta coming up and the recent announcement of Mars 0.1, it will be useful to allow folks to build their own GemTools-Client without needing to rely on us to supply the client image.

My first test of the GemTools Client package was to load it into Pharo and I’ve been doing my development in Pharo since then.

New GemTools Launcher

With the addition of the new OB-Tools, I needed to figure out a way to provide easy access to all of the new tools, since button real estate is in short supply in the existing Transcript window. I briefly considered replacing the World menu with a GemTools-specific world menu, but finally faced the fact that I’d need to rework the Transcript window from scratch.

I’ve been planning on reimplementing the Morphic windows in OmniBrowser for a long time, so I decided to rewrite the new window using OmniBrowser and do something with the Login window while I was at it. I combined the Login window and Transcript window functions into a single Launcher window. The screenshot below is from a Pharo dev image (click on the image for full size view):

There’s also a new OmniBrowser-based workspace window with a tabbed interface contrbuted by Gerhard Obermann.

The only remaining non-OmniBrowser window in GemTools is the Test Runner window and I’ll be taking a run that pretty soon.

Having all windows implemented with OmniBrowser is important so that native window UIs like Mars, which is implemented in Cocoa runs on top of OmniBrowser,can be used for GemTools.

Preview for the Brave and/or Curious

I am still working the new GemTools with about 10 items left in my ToDo list, but if you’re brave and/or curious and willing to provide feedback, then I encourage you to take the new GemTools for a spin. Once you have updated your GemStone repository to GLASS.230-dkh.182 or later, you will have to use the new tools – the old client tools will no longer be functional.

First you’ll need to update to the latest GLASS package on the GemStone side (GLASS.230-dkh.182 found on GemSource):

1. Before loading GLASS.230-dkh.182 you need to
   1. evaluate the following expression in a GemStone workspace:
      • SystemChangeAnnouncement compileMethod: ‘item: ignored’ category: ‘accessing’.
   2. turn off auto migration.
2. After the package has loaded (if you are using the Monticello Package browesr), you’ll get a walkback complaining about #refresh. Close the walkback, press the commit button [updated 1/4/2009], and shut down your old GemTools image.

Remember once you have updated your GemStone repository to GLASS.230-dkh.182 or later, you will have to use the new tools – the old client tools will no longer be functional. This is where the brave part comes in.

Now you need to prepare a new GemTools client image. I’ve used Squeak 3.10 vm with the Squeak3.10-7159-basic image and the Pharo vm with the Pharo-Dev 10185 image (at this writing Pharo-Dev10196 is the latest dev image). I haven’t tried 3.9 yet, but I have no reason to believe that there will problems loading the code. Once you’ve downloaded and launched the base image of your choice:

1. Open the Package Universe browser (Universe browser a couple of menus deep in Pharo).
2. Click on update list from network.
3. Open the Network category.
4. select GemTools-Client version 0.324 or later (ignore the GLASS Client packages – I was having trouble with getting the packages defined).
5. Click on select package.
6. Click on Install Selections.
7. When the load is done, evaluate ‘OGLauncher open’ in Squeak workspace.
8. Click on the Edit Session menu item with the Glass session selected and fill in the login information.
9. Alternatively, use the New Session menu item if you need to add more login information than provided by the Basic template.
10. click on the Login button and have fun.

I’ve only been using these tools for several days, so I am very interested in feedback. If you run into walkbacks or are simply confused by the new interface submit a comment to this post, or send mail to the Beta mailing list (you have to join first). If you have no problems, that would also be useful to know.

I will be continuing to work on the new tools for the next couple of weeks so its worth checking the Package Universe every once in a while to see if I’ve published a new version. Also be prepared for changes to the way some of the tools work.

I expect to make a general announcement of the new tools in 3-4 weeks – I’m hoping to get the Test Runner into OmniBrowser and take a run at the OB-Enhancements and OB-Refactory before all is said and done. I’ll have to update the Terse Guide to the GLASS Tools.

Don’t forget to send feedback!

and… Merry Xmas!

——

[1] Photo by jsalvino via Flickr (Creative Commons).

GemStone/S 64 Version 2.3.1 is Shipping

[1]

On Tuesday we announced the release of GemStone/S 64 version 2.3.1. This release is primarily a bugfix release for our commercial customers. The critical bugifixes are not likely to affect anyone using Seaside. For complete details please refer to the Release Notes.

The release can be obtained from the GLASS downloads page.

New installations should always use the latest available product release, but for this particular release unless you are suffering from one of the bugs that has been fixed you can safely defer the upgrade.

2.3.1 ships with GLASS.230-dkh.176 so you should update to GLASS.230-dkh.177.

We have no plans to release a new version of the appliance. 1.0beta11 is still the most recent version.

——
[1] Photo by jasonpearce via Flickr (Creative Commons).