Because GemStone Smalltalk does not have a native GUI, most developers use a “client” Smalltalk with some tools that give access to the “server” Smalltalk. Traditionally, this has been GemBuilder for Smalltalk (GBS) installed into a VA Smalltalk or VisualWorks client. With the advent of GLASS (and a no-cost license for GemStone/S 64 Bit), tools are also available for Squeak/Pharo (named GemTools).
Because it is non-trivial to set up a local Squeak/Pharo system, we have provided a pre-build “one-click” download that works on Linux, Macintosh, and Microsoft Windows. Of course, once something like this is made, it is immediately out-of-date and it becomes a challenge to provide updates. Updates to GemTools itself, while significant, are at least confined to executing Smalltalk code in the client. Updates to the client environment are, however, more complex. Also, there are those who want to build things from scratch so as to better understand what is going on.
A further complication is that once you a working environment, you are less likely to rebuild it from scratch. This leaves the frustrating experience that “it works for me” and “when I followed the instructions I get a different result.” In our case, the instructions refer to third-parties (the Squeak/Pharo web sites) and simply direct you to follow their download and install instructions. When those instructions change—or the things being installed change—the results are likely to change (and not for the better!). It was into this pit that Friedrich fell a few days ago. He faithfully followed the instructions, but got a different result from those of us who followed the instructions sometime earlier.
Given that Squeak/Pharo is an open-source project and is rapidly developing (and diverging?), keeping GemTools up-to-date is a major challenge. One of the biggest challenges is related to the external library that is used on the client to interact with the server. The name and location of the library seems to be different for each platform and VM. Debugging these problems is particularly challenging, since one gets little more than the error “Unable to find function address.”
As of the date of this blog post, the Pharo download page provides two sources for a client virtual machine. One takes you to a place to get builds of Squeak-18.104.22.1685 for various operating systems, including Linux; the other immediately downloads pharo-vm-0.15.2f-linux.zip. If you take the “Pharo” VM, things work; if you take Squeak-22.214.171.1245, then things don’t work. It turns out that the latest Squeak VM has a change in how external libraries are referenced.
When the new VM was released, Ian Piumarta included a release note:
Plugin search stretegy rationalised and simplified. Default location is now the executable directory (where ‘squeakvm’ is installed). The -plugins argument can be a colon-separated list of locations to search, just like PATH. Plugins are named ‘so.plugin’ to make interference with FFI libraries less likely.
Thus, we need to change not just the location of the library, but also its name. Instead of putting ‘gciForLinux.so’ next to the image, you now need to put ‘so.gciForLinux’ next to the virtual machine. Furthermore, when opening the library you need to leave off the ‘so.’ prefix.
So, if you are using Squeak-126.96.36.1995, put ‘so.gciForLinux’ next to the VM, and edit GciLibrary>>#’moduleName’ as follows:
| path |
self isOnWindows ifTrue: [^'gciForWindows.dll'].
self isOnMacintosh ifTrue: [^'gciForMacintosh.so'].
self isOnLinux ifFalse: [self error: 'Unknown platform!'].
path := SmalltalkImage current vmPath , 'so.gciForLinux'.
(FileDirectory new fileExists: path) ifTrue: [^'gciForLinux'].
Once this is done, the client should be able to interact with the GCI library. We should be able to update GemTools with this method soon.