Ubuntu 64-bit and Cincom Smalltalk 32-bit

You’ll need to issue these commands:

sudo apt-get install libc6:i386
sudo apt-get install libx11-6:i386
sudo apt-get install zlib1g:i386

The Magic is Back

In the interest of getting on with life, I succumbed and created a magic build image (actually there are four, but they’re the same).  So the build is now happening with Jenkins and I’ve moved to other matters for now.

You can’t go back

One of the things I’ve always liked about computers is that doing x to y always gives you z.  That is, until I started using Cincom’s Smalltalk.  Now, doing x to y gives me z, a, b, c… but never in a predictable fashion, and I always get a new answer.  This has added a challenge to problem-solving.  Yes, I’m in contact with Support.

Almost there

I found that using a combination of James’ tutorial, and Cincom’s documentation got me to within a stone’s throw of where I wanted to be.  What I want now is a StORE reference for ENVY users.

Bring Back the Magic

Actually, it doesn’t seem to have left. Even Cincom is asking us to create a “magic” build image. After all these years, why is this still the case? Or is it us? Am I the only one that likes to start a day of development on a fresh image, knowing for sure that there’s no cruft from previous work? It seems to be the case. There’s a tutorial, but it goes back to 2009, and invokes the dulcet tones of the late James Robertson. I liked and respected James, but I was hoping for something a little more recent.

Cincom has many of the parts, but there’s problems. In 8.1 at least, the settings import is broken. That’s right, you can export the prerequisites page all you want, but importing doesn’t work. Nor does resetting to default. I would guess that if any testing were done, it was only to ensure that things didn’t blow up. Even once you’ve figured out the settings aren’t exporting properly, though, figuring out the prerequisites is a guessing game.

What I want to do seems simple enough. I just want to start with a virgin image, load a bunch of stuff, make sure there’s no current owner, save the image and get out. Why am I spending days on this?  Surely this deserves a paragraph or two in the documentation!

It Must Be Later

Because I’m writing again.  The company was founded by a former colleague of mine from my first tour at TAF.  He took some ideas of mine and ran with them, creating a niche for himself.  The new position has me looking at a number of things based on my experiences at TAF. 

The first thing I’ll need to do is automate the build process. They’ve been without since upgrading to VW 8.1, and it shows. Creating a working image is a real pain!

Try the Veal

Yes, folks, I’m back in the Smalltalk saddle again, and I’m here all week. In Ottawa, that is. I’m playing for Team Cincom now, but it’s not a great hardship. I will say that Envy has StORE beaten by a long shot. I’m working for one of the few Smalltalk shops left in Ontario, although they, like others, don’t advertise Smalltalk. More later…

Caught in a (vm)Trap

I was reminded by a recent posting by Joachim Tuchel (VMTRAP with VA Smalltalk due to strange bytecode differences (or whatever)), that I needed to document my own recent experience with vmtraps.

I was working with another developer at TAF debugging a VA Smalltalk 8.5.2 image in AIX when his development image died, and couldn’t be re-opened. Moments later, other developers using the same AIX machine reported that they couldn’t open development images either. Packaged images were fine, as were VAST 8.0 images. Lacking a better solution at the time, I had our system administrator bounce the box, and all was well.

I was later reminded by the fine folks at Instantiations support that I should have checked for rogue es processes, and made sure that the /tmp/es directory was clear of all files once every possible Smalltalk process was gone. The same reminder would hold true for Linux and Solaris users as well.

Just something to keep in mind when working with Smalltalk in a UNIX environment…

Where Was I?

After many months, once more in a position to think about VA Smalltalk upgrades and the automation of packaging again. When 8.5 came out, it broke the tools I developed during the upgrade process from 7.5 to 8.0.2. Fortunately, subsequent releases have fixed things, so I’m at a point where I can complete the upgrade to 8.5.2. I wrote about many of these issues in an earlier blog entry.

As is my usual custom, I’ve started by modifying my config maps to specify either 8.0.2 or 8.5.2 maps as prerequisites. The development environments had few problems, but packaging was a challenge. Instantiations has added some interesting new time zone support to the base image, but it requires one to include an additional application, EsTimeZone, as part of the runtime package. If one is creating a new package from scratch, the default rules will apparently pick up this application automatically. The rest of us are not so lucky – we have to modify our packaging instructions to include this new package. This new requirement isn’t currently mentioned in the upgrade notes.

In my case, because I’m building 8.0.2 and 8.5.2 images from the same code base, I’ve been forced to move the packaging rules class to a subapplication. A configuration expression based on the system version loads the appropriate subapplication. This is where I found one more little “gotcha”.

In 8.0.2 and earlier versions, the preferred mechanism for determining the Smalltalk version was to send #vaVersion to System. This has been deprecated in favour of #imageVersion, which answers the same thing. If you’re like me, and trying to maintain a couple of versions of Smalltalk, you’ll probably find it easier to continue to use #vaVersion for now, and switch to #imageVersion once you’ve retired anything prior to 8.5.

Other than these few minor annoyances, it looks like there haven’t been any significant changes introduced, unless you were an early adopter of the log4s framework. If you were, you’ll want to look things over a little more closely.

Fit-ting In

Here at TAF, we currently run a mix of generic Linux PCs and thin client netstations as X terminals for our AIX production box. The netstations have long been unsupported, but we’re also interested in something more robust and less power-hungry than the PCs we’re currently running. One of my tasks recently was evaluating a Fit-PC2 for use as a replacement.

Out of the box, the Fit comes with Linux Mint installed. For those not familiar with it, Linux Mint is based on Ubuntu. In this case, we’re talking Linux Mint 9, “Isadora”, which corresponds to Ubuntu’s 10.04, or “Lucid Lynx” release. This isn’t a bad thing as it’s a long-term support release, but Ubuntu and friends are problematic for the use we have intended for these machines.

In order to connect to AIX, we rely on XDMCP. We also rely on xfs to provide certain fonts for use by the programs running in AIX. The Ubuntu distributions have removed this support by default, and made it an extreme challenge to put it back in. I spent a day or two fighting the Fit to re-enable this support before giving up.

My next step was to take the brain-dead approach of installing Red Hat Linux using the same install CD and kickstart script we’ve used for our other Linux installations. This actually worked, although disk and video performance weren’t outstanding.

The Fit is based on Intel’s Poulsbo chipset, which isn’t natively supported in our version of Red Hat. Some research in the Fit-PC2 forums yielded a kernel module that provided a working driver, but given the somewhat informal source and the fact that it was for a different distribution, I was reluctant to recommend it for production. However, I did try it on our little box, and was pleasantly surprised. Everything seems to be working as expected, and we will be throwing the box into a production test sometime in the near future.

As a longer term solution, we need to upgrade to a more modern version of Linux along with a configuration tool such as Puppet. RHEL 6 seems to be headed in the same direction as Ubuntu in terms of XDMCP support, so we have some work in store for us.