A screencast of these instructions is available on Vimeo (compressed) or full-size (11.8 MB).
In a recent post I described how to set up Apache and GemStone/S on Slicehost and we ended with running Seaside. This post will describe how to connect to your GLASS system from GemTools and update Seaside (and related packages) to the latest release.
In a local shell, we log in to the Slicehost server using SSH (earlier I described an alias ‘slice’ that I have for this command):
ssh -p 30000 glass@slice
Once connected we run a script to set some environment variables and verify that the system is running:
source /opt/gemstone/product/seaside/defSeaside
gslist
If gslist
does not show the appropriate processes, start them:
startGemstone
runSeasideGems start
The next step is to start the NetLDI service. This service listens on a port (during our initial setup the script defined 50377 as the port for NetLDI), starts gems in guest mode with the glass account, and uses a special port range (in our case one port, 50378, use more if there will be many concurrent connections) to communicate with the newly-started gem.
startnetldi -g -a glass -p 50378:50378
Now we can return to our client environment and start GemTools. GemTools is a Squeak application available from the downloads page at seaside.gemstone.com. In GemTools we need to identify the GLASS host by IP address or host name. In my case I’ve added ‘slice’ to my hosts file so I can give the host name. Click the “Login” button to connect to GemStone.
On the Transcript window there are a row of buttons. Click “Monticello” to open a Monticello browser. In this browser we have a list of the packages currently installed in our system. Select the GLASS package on the left pane and note the list of servers for that package in the right pane. Select the http server and click the “Open” button. This will open a new window with the packages available on that server in the left pane and a list of versions in the right pane. Select the latest one (at the top), and click the “Load” button. Each of these steps is somewhat slow, so be patient. Once the package is loaded, you can close the Monticello browsers.
From the Transcript, you can click “Browse” to browse code and you can execute Smalltalk code in the text entry widget.
This use of GemTools will form the basis of much of what we do later in developing a Seaside application in GLASS.
9 comments
Comments feed for this article
November 13, 2008 at 12:36 pm
Paul
In what order should things be updated? Just the GLASS version or also the monticello.g and some other things? Thanks
November 14, 2008 at 4:34 am
James Foster
Paul: GLASS is a package that does not have any code itself but instead has all the other packages listed as prerequisites. Whenever there is a new version of something like monticello.g, Dale will create a new version of GLASS to manage it. Thus, you only need to load GLASS and the others come along for the ride with no additional effort.
If you are updating both the server and the GemTools client (in Squeak), update the server with GLASS before you update the client with GemStone. Otherwise you might create a situation in which the client is incompatible with the server and can no longer log in!
November 21, 2008 at 5:16 pm
isaiahperumalla
hey james
i trying to run the GemTools natively on my client machine (mac osx).
i downloaded the squeak images and GemStone/S 2.3 library for Mac OS X v10.5 Leopard.
however when i start up my squeak client image i get “Library not found error”,
i stepped into the debugger and it seems like it looking for gciForMacintosh.so or something like that. where can i get this, or have i completely missed something
November 22, 2008 at 10:30 pm
James Foster
Hi Isaiah,
You should rename the library you downloaded to ‘gciForMacintosh.so’ to match what the image expects. The image is from the GemTools “One-Click” package that includes Squeak, the image/changes and libraries for Windows, Linux, and Macintosh (which might be a better bet for your use). Because the library names are by default the same for Linux and Macintosh, we renamed them to something that is more descriptive. I suppose we should rename them in the download as well!
November 28, 2008 at 1:01 pm
Miguel Cobá
I find a kind of bug in the GemTool.sh script.
If you run it from inside the unzipped directory as:
./GemTools.sh
the directory is not resolved well and the softlink to the gci gets a bad path.
miguel@vm1:~/GemTools-2.3.app$ ./GemTools.sh
miguel@vm1:~/GemTools-2.3.app$ ls -alh Contents/Linux686/gciForLinux.so
lrwxrwxrwx 1 miguel miguel 35 2008-11-28 13:58 Contents/Linux686/gciForLinux.so -> ./Contents/Resources/gciForLinux.so
where the softlink it is resolved relative to Contents/Linux686/ as:
Contents/Linux686/./Contents/Resources/gciForLinux.so
that isn’t correct. Changing
#!/bin/sh
in the script to
#!/bin/sh -x
you can see the expansion of the variables:
miguel@vm1:~/GemTools-2.3.app$ ./GemTools.sh
++ dirname ./GemTools.sh
+ APP=.
+ EXE=./Contents/Linux686
+ RES=./Contents/Resources
+ rm ./Contents/Linux686/gciForLinux.so
+ ln -s ./Contents/Resources/gciForLinux.so ./Contents/Linux686/gciForLinux.so
+ exec ./Contents/Linux686/squeak -plugins ./Contents/Linux686 -encoding latin1 -vm-display-X11 -swapbtn ./Contents/Resources/GemTools.image
But if you run the script using the full path, it is expanded correctly:
miguel@vm1:~/GemTools-2.3.app$ cd
miguel@vm1:~$ /home/miguel/GemTools-2.3.app/GemTools.sh
++ dirname /home/miguel/GemTools-2.3.app/GemTools.sh
+ APP=/home/miguel/GemTools-2.3.app
+ EXE=/home/miguel/GemTools-2.3.app/Contents/Linux686
+ RES=/home/miguel/GemTools-2.3.app/Contents/Resources
+ rm /home/miguel/GemTools-2.3.app/Contents/Linux686/gciForLinux.so
+ ln -s /home/miguel/GemTools-2.3.app/Contents/Resources/gciForLinux.so /home/miguel/GemTools-2.3.app/Contents/Linux686/gciForLinux.so
+ exec /home/miguel/GemTools-2.3.app/Contents/Linux686/squeak -plugins /home/miguel/GemTools-2.3.app/Contents/Linux686 -encoding latin1 -vm-display-X11 -swapbtn /home/miguel/GemTools-2.3.app/Contents/Resources/GemTools.image
This permits the GemTools Squeak Image to correctly locate the gci and to connect to a remote GemStone.
Summary, you must use the full path to start the GemTools.sh script to avoid errors in connecting with remote Gemstone/S
Cheers,
Miguel Cobá
November 29, 2008 at 9:44 am
James Foster
Hi Miguel,
I’m having trouble reproducing your problem. I’m using the VMware virtual appliance, and when I try the steps you describe it works fine. One difference, is that when I do a listing of the softlink, I get something slightly different:
glass@glass:~/Desktop/GemTools-2.3.app$ ls -alF Contents/Linux686/gciForLinux.so
lrwxrwxrwx 1 glass glass 27 2008-11-29 08:35 Contents/Linux686/gciForLinux.so -> ../Resources/gciForLinux.so*
Here the link is resolved to the following:
Contents/Linux686/../Resources/gciForLinux.so
This is different from what you report (you have only one period and the Contents directory is included again). Based on this, I suspect that there is something different in your Linux distro and/or how the unzip process restored the symbolic link. When I do the unzip, it finishes with the following:
inflating: GemTools-2.3.app/GemTools.sh
inflating: GemTools-2.3.app/GemTools.exe
finishing deferred symbolic links:
GemTools-2.3.app/Contents/Linux686/gciForLinux.so -> ../Resources/gciForLinux.so
I’m not sure what I could do differently to address your problem.
James
November 29, 2008 at 12:46 pm
Miguel Cobá
yes, that is very strange.
I have Debian GNU/Linux 4.0 i386 running on a KVM virtual machine, and the problem remains:
miguel@vm1:~$ ls
GemTools-2.3.zip Seaside-2.8.3.app.zip Seaside-2.8-578.app
miguel@vm1:~$ uname -a
Linux vm1 2.6.18-5-486 #1 Mon Dec 24 16:04:42 UTC 2007 i686 GNU/Linux
miguel@vm1:~$ md5sum GemTools-2.3.zip
f66746c002b3388e8f7b4cec96a38f75 GemTools-2.3.zip
miguel@vm1:~$ unzip -v
UnZip 5.52 of 28 February 2005, by Debian. Original by Info-ZIP.
Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.
Compiled with gcc 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) for Unix (Linux ELF) on Mar 16 2008.
UnZip special compilation options:
ACORN_FTYPE_NFS
COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
SET_DIR_ATTRIB
TIMESTAMP
USE_EF_UT_TIME
USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
VMS_TEXT_CONV
WILD_STOP_AT_DIR
[decryption, version 2.9 of 05 May 2000]
UnZip and ZipInfo environment options:
UNZIP: [none]
UNZIPOPT: [none]
ZIPINFO: [none]
ZIPINFOOPT: [none]
miguel@vm1:~$ unzip GemTools-2.3.zip
Archive: GemTools-2.3.zip
creating: GemTools-2.3.app/
[many lines removed by James]
linking: GemTools-2.3.app/Contents/Linux686/gciForLinux.so -> /home/glass/Desktop/GemTools-2.3.app/Contents/Resources/gciForLinux.so
[many lines removed by James]
inflating: GemTools-2.3.app/GemTools.exe
finishing deferred symbolic links:
GemTools-2.3.app/Contents/Linux686/gciForLinux.so -> /home/glass/Desktop/GemTools-2.3.app/Contents/Resources/gciForLinux.so
miguel@vm1:~$ cd GemTools-2.3.app/
miguel@vm1:~/GemTools-2.3.app$ ./GemTools.sh
miguel@vm1:~/GemTools-2.3.app$ ls -alh Contents/Linux686/gciForLinux.so
lrwxrwxrwx 1 miguel miguel 35 2008-11-29 13:26 Contents/Linux686/gciForLinux.so -> ./Contents/Resources/gciForLinux.so
miguel@vm1:~/GemTools-2.3.app$ ls -alF Contents/Linux686/gciForLinux.so
lrwxrwxrwx 1 miguel miguel 35 2008-11-29 13:26 Contents/Linux686/gciForLinux.so -> ./Contents/Resources/gciForLinux.so
Trying with the full path to the script:
miguel@vm1:~/GemTools-2.3.app$ /home/miguel/GemTools-2.3.app/GemTools.sh
miguel@vm1:~/GemTools-2.3.app$ ls -alh Contents/Linux686/gciForLinux.so
lrwxrwxrwx 1 miguel miguel 63 2008-11-29 13:29 Contents/Linux686/gciForLinux.so -> /home/miguel/GemTools-2.3.app/Contents/Resources/gciForLinux.so
miguel@vm1:~/GemTools-2.3.app$ ls -alF Contents/Linux686/gciForLinux.so
lrwxrwxrwx 1 miguel miguel 63 2008-11-29 13:29 Contents/Linux686/gciForLinux.so -> /home/miguel/GemTools-2.3.app/Contents/Resources/gciForLinux.so
Also, the script, when runs, deletes the softlink and recreates it with the output of:
dirname $0
that when is ran with
./GemTools.sh
returns:
./
Check http://unix.derkeiler.com/Newsgroups/comp.unix.shell/2008-10/msg00629.html
Maybe the fix would be (taken from: http://www.atm.ch.cam.ac.uk/casnet/unix/weblog/43.html)
currentdir=`pwd` # preserve where we are
cd `dirname $file`
fullpath_file = `pwd && echo “/” && basename $file`
cd $currentdir
APP=$fullpath_file
… rest of script:..
What is strange is that you don’t have any problem.
Well, maybe just happens to me.
Thank you anyway.
November 29, 2008 at 2:01 pm
James Foster
Migual,
It might be that you are working with an older copy of GemTools. The one I downloaded today does not delete the softlink and recreate it:
glass@glass:~/Desktop$ md5sum GemTools-2.3.zip
82032bf149c4479e152af6585faccf3e GemTools-2.3.zip
#!/bin/sh
APP=`dirname $0`
EXE=”$APP/Contents/Linux686″
RES=”$APP/Contents/Resources”
exec “$EXE/squeak” -plugins “$EXE” \
-encoding latin1 \
-vm-display-X11 -swapbtn \
“$RES/GemTools.image”
There is a bit of confusion because GemTools is named based on the server version it runs with. There was a brief time when we had a problem with the symlink due to a packing problem that did not create the symlink. The packing problem was fixed so the script was simplified but not renamed. Could you try the download again?
James
November 30, 2008 at 8:31 pm
Miguel Cobá
Yeah, indeed the problem doesn’t exist with the current versión of GemTools.
I just checked the link name and as it had the same name as the one of my already downloaded zip, I didn’t try to downloaded again.
Next time, I will check the source first before reporting a problem.
Thank you very much for your time
Miguel Cobá