1. Release Notes for GemBuilder for Smalltalk 8.3

GemBuilderfor Smalltalk (GBS) version 8.3 is a new version of the GemBuilder for Smalltalk product, adding support for GemStone/S 64 Bit version 3.4 and VW 8.2.1, making many improvements to the tools, and fixing a number of bugs. Please take time to read through these release notes before installing or upgrading, to acquaint yourself with the changes.

These release notes provide changes between the previous version of GBS, version 8.2, and version 8.3.

If you are upgrading from a version prior to 8.2, please also review the release notes for each intermediate release between your version and 8.3, to see the full set of changes.

This release supports both GemStone/S 64 Bit, the 64-bit GemStone/S-based object server, and with GemStone/S, the original 32-bit GemStone object server.

GBS v8.3 is supported with VisualWorks 7.10.1 and 8.x, and cannot be used with VisualWorks versions earlier than 7.9, nor with VA Smalltalk.

To install GemBuilder for Smalltalk 8.3, follow the instructions in the GemBuilder for Smalltalk Installation Guide for version 8.3.

Supported Platforms and Versions

The following tables describe the client Smalltalk versions and platforms supported by GBS 8.3, and the GemStone server product shared library versions that can be used with each.

For more details, including the specific required client libraries for each server product and versions, refer to the GemBuilder for Smalltalk Installation Guide for version 8.3.

Table 1 Supported GemStone/S 64 Bit Server versions


VW 8.2.1


64 bit

VW 8.1.1


VW 7.10.1


VW 7.10.1

Windows 10

3.4, 3.3.6


3.4, 3.3.6


Windows 8

3.4, 3.3.6


3.4, 3.3.6


Windows 2008 R2

3.4, 3.3.6


3.4, 3.3.6


Windows 7

3.4, 3.3.6

3.3.6, 3.2.17

3.4, 3.3.6, 3.2.17


Ubuntu Linux 16.04

3.4, 3.3.6


3.4, 3.3.6


Ubuntu Linux 14.04

3.4, 3.3.6

3.3.6, 3.2.17

3.4, 3.3.6, 3.2.17


Red Hat Linux ES 7.1

3.4, 3.3.6


3.4, 3.3.6


Red Hat Linux ES 6.7

3.4, 3.3.6

3.3.6, 3.2.17

3.4, 3.3.6, 3.2.17


Table 2 Supported 32-bit GemStone/S Server versions


VW 7.10.1


Windows 2008 R2


Windows 7


Red Hat Linux ES 6.5


Changes and New Features

The following changes are in version 8.3:

Support for GemStone/S 64 Bit version 3.4

Support for the latest version of the GemStone/S 64 Bit server, v3.4, has been added. If you are upgrading to v3.4 as well, please read through the Release Notes for v3.4 for changes that impact your GBS application.

library change on UNIX

Previously, the required client libraries included, in addition to libgcirpc* or libgcilnk*, the shared library libssl*. With the addition of new open source products, this has been changed, and the new library name is libfloss (floss stands for Free/Libre Open Source Software). libfloss include the openSSL shared library, as well as LDAP and Kerberos.

This does not apply to clients on Windows, which continue to require the same set of libraries.


A UserProfile’s groups are now collections of UserProfileGroup, rather than strings. The API for managing users has been updated to handle these objects.

Single sign on authentication

Note that v3.4 supports Single-sign on, using Kerberos. Users can authenticate using this mechanism. However, the User Tools in GBS do not support configuring this authentication or creating KerberosPrincipals. To configure single sign on, you must execute the server code following the instructions in the GemStone/S 64 Bit System Administration Guide or the 3.4 Release Notes.

Handling of server version mismatch

When the v3.4 libraries contact the NetLDI, they now make a secure connection. This creates a protocol error if an image using the 3.4 libraries are incorrectly configured to connect to a NetLDI running an earlier version of GemStone. Likewise, an error is encountered when earlier libraries from earlier versions are used to connect to a 3.4 NetLDI.

Note that if logins encounter error with messages such as: ’SSL configuration mismatch’ or ’Invalid flags value from peer’, it is likely to indicates a version mismatch.

Support for VW 8.2.1

Support for VisualWorks version 8.2.1 has been added. The GBS 8.3 distribution includes an additional parcel, GbsToolsVw821, that is automatically loaded when loading detects a VW 8.2.1 image.

Autocommit did not handle commit failures

With autocommit on, a commit failure, such as a commit conflict between multiple sessions, resulted in a walkback, MNU on #description. (#46747)

Accessing the server map with unmapped, out of range OOPs

Attempting to remove the mapping of an object that was not previously mapped and was larger than the current map size resulted in a subscript out of bounds error. Now, this will do nothing. (#46791)

Image saved with server browser open not cleaned up on VW restart

When the image was saved when there were logged in sessions with open browsers, on VW, these sessions are normally cleaned up. It was possible for the cleanup on restart to be bypassed, and the event detectors for the open browsers to run, which resulted in a walkback. (#46572)

Primitive failure when unstubbing for mapped classes of different sizes

If an application uses automatic name-matching class mapping for a subclass of OrderedCollection, and theses OrderedCollection subclasses have unmatched named instance variables, unstubbing of instance with fewer unnamed instance variables can fail.

The problem is when the class on the client more named instance variables than the class with the same name on the server, and a stub is created for an instance with fewer elements than number of instance variables, before the classes are mapped. The attempt to change the class of the stub fails since the stub is too small to accommodate the named instance variables. (#46781)

Error when unstubbing an unmapped subclass of Dictionary

When an instance of a subclass of Dictionary that is not mapped is unstubbed, it reported an unstub error. (#46785)

Fatal error that is not a subclass of GbsFatalError was not handled correctly.

The error detector should be shut down if a fatal error occurs. If the fatal error was not a subclass of GbsFatalError, this code raised an error. (#46971)

SymbolDictionary issues

Removing SymbolDictionary did not remove from transient symbol list

When a SymbolDictionary was removed from the SymbolList, it was removed from the persistent but not the transient SymbolLists. This resulted in incorrect behaviors in resolution of symbols associated with that SymbolDictionary for the remainder of the session. (#46859)

SymbolDictionary names that are not proper identifiers

Identifiers in the Smalltalk sense contain only alphanumeric characters and underscore, and start with a letter. While usually SymbolDictionary names are identifiers, it is legal to use any Symbol. Non-identifier Symbols require quoting and resolution as an expression within the class definition expression, and make some tools usage within GemStone more awkward; using non-identifier Symbols as SymbolDictionary names is discouraged.

GBS continues to allow such non-identifier symbol names for SymbolDictionaries. Now, when you attempt to create a new Symbol dictionary with a name that is not an identifier, you get a dialog confirming that this is not an identifier.

The GBS tools fully support using non-identifier SymbolDictionary names; a few issues have been fixed in v8.3. (#44924, #47105)

Inspector changes and bug fixes

Inspector toolbar includes new button for Refresh From GS Server

The toolbar pane on Inspectors now includes a new button to perform the operation Refresh From GS Server. This function is also on the Object menu.

Note that the position of this item on the menu has changed.

Possible walkback when inspecting server object

There were cases where the inspector computations could validly attempt to set the tab more than once, which was handled as if it was a recursive call. (#46907)

Accept in Inspector could perform replication and error

When inspecting an Array and accepting changes in an element, it was possible to attempt to create a client class and encounter a block replication error. (#47034)

Spawn Class Hierarchy menu item actually spawned Class Browser

With VW 8.x, the Inspector GsElements tab has a pop-up menu item Spawn Class Hierarchy. This spawned a Class Browser (#47143)

Inspectors on Server strings not closed on logout

On logout, open inspectors on server strings remained open, but became inspectors on the client immutable ByteString 'Not cached', which had to be manually closed. (#46480)

Improved printing of sourceCode of GS Basic tab of method inspector

Server method inspectors sometimes included the GS Basic tab field sourceCode. When present, this included associated delegate information, which was unnecessary. Now the sourceCode field is always provided and the delegate information is not included. (#46810)

Dictionary inspector GS Basic tab did not show indexed instance variables for empty dictionary

The GS Basic tab of an inspector should display the named and indexed instance variables. For inspectors on empty instance of kinds of Dictionary that were created with empty slots and have no contents, the indexed instance variable slots were not displayed. (#46783)

Debugger changes and bug fixes

Gbs stack dumps now indicate objects that are immutable

If a client object is immutable, the GBS stack dump output will include ’(immutable)' (#46777)

Debugger > Browse opened Hierarchy Browser rather than Method Browser

The debugger menu item Method > Browse opened a Class Hierarchy Browser rather than a Method Browser. (#46435)

Debugger receiver pane display changes for stubs

When debugging a stub, previously the receiver pane included entries for .proxy (the stub itself), .delegate (the delegate for the server object), and self (the server object that is stubbed).

The names and ordering for self and .proxy have changed to be more intuitively correct. Now, the top entry is labeled self (since it represents the receiver), and the server object is now labeled .server.

Debugger single stepping into blocks

When single stepping to a block and through the code in a block, the values on the stack were incorrectly listed in the temporaries inspector panes. ((#46692)

With some server versions, when single stepping through the code within the block, the highlight of the currently selected step point failed, so selection remained at the start of the method. (#47088)

On debugger open, top context is not selected

VW 8.x only

When a debugger is open, normally the first context is selected and the current codepoint highlighted. With VW 8.x, the first contact was displayed grayed out, and no context was selected. (#46543)

In the debugger, executing GS-Debug leaves debugger in stuck state

VW 8.x only

In a debugger, attempting to execute code using GS-Debug it resulted in a walkback, Message not understood: #gbxIsServerContext. This error leaves the debugger state such that the debugger does not respond to close. (#46610)

Code Browser Issues

Browser auto-commit icon did not indicate state

Under VisualWorks 8.x, there was no visual difference indicating the state of autocommit. (#46434)

Button to indicate modifications made

VW 8.x only

In code browsers, the Source, Definition, Hierarchy and Comment tabs now have indicators that turn red when there are unsaved edits in the text. These indicators were present under VW 7.10.1, but missing with VW 8.x. (#46544)

Finding references to class variables found too many references

The Code browser’s Class menu item Browse References > To A Class Variable found all references to class variables with the given name, not just the references from the selected class. (#46563)

Code Browser Instance Variable tab selection and method visibility

In a System, Class, or Hierarchy Browser, the Instance Variable tab can be used to select methods that reference a particular instance variable. Now, when no instance variable is selected, all methods are displayed. Also, when a method is edited, the instance variable remains selected unless the new method no longer references the instance variable. (#46789)

Error on moving a class to a new undisplayed SymbolDictionary

If a SymbolDictionary was created but a browser was not updated to make this visible, moving a class to this SymbolDictionary reported an Element not found error in attempting to set the selection. (#46843)

Class creation dialog detects invalid arguments

If you use the class creation dialog and the classname is empty, or the superclass is not a Behavior, it now inlines appropriate error messages into the incorrect entry. (#45667)

Server refresh caused reset of selected class in Hierarchy Browser

When you commit, abort, or refresh from server, the selected class in the Hierarchy Browser was changed to the class that the browser was originally opened on, regardless of the currently selected class. (#46579)

Browser Control-F dialog could not easily be closed

The find class dialog created using control-F did not respond to cancel. (#46361)

Class Versioning in Class Hierarchy and Class Browsers

The Class Hierarchy and Class Browsers can be used to modify a class definition, by changing superclass or by adding and removing instance variables. These changes create a new version of the class and recompile subclasses. The display of the class definition was not always updated, leaving the older version of the class visible, and in some cases a new browser opened on the modified class version. (#46724, #43046. #46724 )

When you file in code that defines a class that already exists, such that a new version of the class is created, it does not automatically recompile the subclasses of this class, so the superclass remains the older version. The Hierarchy Browser, however, reported that the superclass of the class is the new version, and displays the new version of the superclass. If the protocol This can be confusing if the protocol in the superclass is different, since methods in the new superclass version will not be understood. (#45694)

Issues related to managing methods

Autocommit did not commit generated accessor methods

When accessor methods were created using the menu item Create Accessors..., the generated accessor methods were not committed automatically. (#46540)

Browser selection behavior after dragging method between categories

When dragging and dropped a method from one method category to another, previously selection moved to the new category. Now, the currently selected category remains selected; no method is selected, since the moved method is no longer in this category.

New methods in category "unknown"

When a new method is created by editing an existing method when a category is not selected, it would put this method into a category "unknown", rather than the category of the existing method. Now, if a method is selected, it will use this method’s category for the new method’s category. (#46746)

Dragging a method to a new protocol makes hierarchy browser unusable

If the hierarchy browser is opened on a class, and a subclass of that class is selected and a method dragging between categories, and the superclass has fewer protocols than the class in which the method was moved, it results in a subscript out of bounds error. The browser is no longer usable and must be closed. (#46580)

Browser override/overridden arrows do not distinguish between class and instance methods

Browsers use up and down arrows to distinguish methods that override one inherited from a superclass, or that are implemented by a subclass. This did not distinguish between class and instance methods, so the arrows could be incorrect. (#46617)

Drag and drop a method between browsers

Attempting to select and drag a method from one browser to a different class in a separate browser resulted in an error, MNU on #proxy. This is now supported functionality. (#46556 )

Deleting method without selected protocol put text pane in incorrect state

If no protocol is selected and a method is deleted, the text pane displayed the class definition but the selected tab was Source, not Definition. Attempting to edit the definition and accept encountered unexpected token errors. (#46586)

MNU on commit if a browser referenced a deleted method

Deleting a method that was selected in another browser created a number of issues.

Subsequent commits or aborts would throw an exception while updating the open browsers, after they completed successfully. (#44374, 46587).

Now, deleted methods are no longer red italic; the text <<removed>> is appended to the selected item in the browser.

Formatting issues

Formatting a method that made no changes dirtied source

If you format a method but the formatting made no changes, the method was marked dirty. (#46571)

Format class definition failed

The control-O option to format a method was not disabled for class definitions, and inserted errors in the definition text. Control-O can now only be used when the source tab is selected. (#46568)

Formatting a method with syntax errors did not report errors correctly

When a method containing syntax errors was formatted, the syntax error message was inserted in the wrong place and the entire method, not just the error, was selected. (#46633)

User Editor issues

Unable to create or edit a user with a nil Default Security Policy

GS64 allows nil object security policies, meaning that objects do not have object-level access control, and users may have their default object security policy nil to indicate this.

The user tool did not support this; nil was treated as the string ’nil’, and a user security policy created with the name nil. This was made the default security policy for the user, which could have left this user unable to login.

This occurred when attempting to create a new user with a nil security policy, or on making any edit, not just to the security policy, to an existing user. (#47069, #45207, #45199)

Creating a user changed ownership of the selected security policy

When a user is created using the user dialog, a default object security policy must be selected. The ownership of that security policy was set to the new user. (#45392)

Privilege denied changing default security policy

Only members of the DataCuratorGroup could change a user’s default object security policy; the privilege was not sufficient. (#45392)

Deleting a user with insufficient privileges caused infinite recursion

Using the User Browser to delete a user by a user that had the incorrect privileges was not detected, so encountered infinite recursion. (#46595)

Privileges browser broken under VW 8.x

Attempting to open the privileges browser in VisualWorks 8.1.1 encountered an MNU. (#46483)

Deleting a group

The User Editor browser has the ability to create groups, but previously did not support removing a group. The feature is now available by right-click in either groups list. (#47097)

With multiple sessions, User Browser could get delegate error

The User Browser did not respect the distinction between the selected session and the current session, and could get error "Attempt to use a delegate from another session". (#46832)

Workspace opened from the GemStone launcher could block the launcher

A workspace opened from the GemStone Launcher shared the same WindowManager as the launcher. Performing long operations in the workspace blocked activity on the Launcher. (#46865)

GBS client methods using segment

In GemStone/S 64 Bit, ’segments’ were renamed to ’objectSecurityPolicies’ to reflect their actual function. Methods that reference ’segment’ are supported but deprecated. #(46466)

In GBS v8.3, Object extension methods have been updated:

  • Object >> changeToSegment: and Object >> assignToSegment: are deprecated when running with GS64 3.x
  • Object >> gbsObjectSecurityPolicy: added, only for use with GS64 3.x

Per-thread replication spec issues

replication spec set could be used in wrong session

There were code paths in which the per-thread replication specs intended for one session were used in a different session, or in a later session with a matching session number as the original session. (#47055)

replicationSpecSet confusion within usingReplicationSpecSet:do: block

While in a usingReplicationSpecSet:do: block, GbsSession>>replicationSpecSet answered the thread-specific spec set for the block, rather than the global spec set for the session. (#47065)

Per thread replication spec blocks did not nest

Per-thread replication specs, configured with usingReplicationSpecSet:do: encountered errors if you attempted to nest the blocks. (#46763)

Replication spec failure without object method

If a thread-safe replication spec is defined, but there is no method defined on Object class for that symbol, or if the method was removed, it results in a walkback and possible errors that are difficult to diagnose, and the image did not reliably cleanup the environment afterwards. (#46754, #46758, #46765, #47115)

Now, if a method in Object class is deleted whose selector corresponds to a replication spec set that has been used in any currently-logged-in session, a Warning will be signaled. A Warning will, unless caught, open a dialog.