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.