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!
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!
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…
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…
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.
After a bit of poking around, I’ve started the job of ramping up the code base at TAF to the new release of VA Smalltalk, recently announced at ESUG 2011. While there’s lots to admire about this release, a couple of things have almost stopped my upgrade efforts in their tracks.
I was actually looking forward to the deprecation support, until it bit me in the posterior. In their “wisdom”, Instantiations decided to deprecate EmSystemConfiguration>>#vaVersion, which has long been the preferred way of identifying the version of VA Smalltalk, in favour of EmSystemConfiguration>>#imageVersion. This, in itself, would have been all right, except that the deprecation implementation is broken, such that an exception is raised regardless of any tolerance settings. At the very least, this makes the config map browser impossible to use.
The other problem I’ve encountered is more subtle. You might recall from an earlier series of posts that I’ve automated the building of images based on a virgin distribution image, some code, command line parameters and Jenkins. Sadly, there’s been some change in 8.5 that breaks this. Something goes seriously wrong during processing of the abt.cnf file, leaving one with a walkback. The workaround is to start a virgin image, let it cache to the correct repository, reset the image owner, and then save and exit the image. This new image should be used as the basis of future automated builds. It also allows for the opportunity to load a fix for the broken deprecation implementation.
I dislike having to take this approach – it leads back to the “magic build image” situation that I’ve been trying to avoid all the way along, but, so far, I’m defeated…
Over the past several weeks, I’ve been picking up the pieces of a project that I thought I’d finished when I left the TAF back in 2005. However, it seems that my past has returned to haunt me, and I’m once again digging into a server that I’d implemented using VA Smalltalk’s Web Connect and Web Services frameworks.
It’s an eerie feeling returning to a project like this after six years, sort of like returning years later to the house you grew up in. A few changes may have been made here and there, but you can find your way around in the dark. In the case of my project, a couple of people have hacked on it during the intervening years, but the code was largely intact.
One of the biggest initial hurdles I had to overcome was the fact that someone had decided that a slightly different version of the code was needed for use in one of the plants at TAF. The server had been running happily unchanged for over a year. Normally, I would have continued to ignore for a while longer, but it was the last part of my Smalltalk upgrade project, so I had to be able to rebuild the server. This proved to be a challenge.
One of my hard and fast rules is that one should be able to load one single config map into a virgin image to create a specific version of a packaged image.In the case of this server, the specialized code was gathered into its own config map, but the config map itself had no required maps defined. As a guide for building the runtime, the map was completely useless. The map contained applications that were in more general config maps that built other images, but different versions with changes for which there was no documentation. Some of the code changes appeared to be gratuitous, and in other cases, there were methods that referred to methods that couldn’t be found anywhere in the code repository.
I eventually managed to shoe-horn the contents of this map into one of the existing complete maps to complete my migration, but we’ll never know what code was actually running prior to the migration. All we know is that things were working before the migration, and they continued to work after the migration. With the migration complete, I was free to concentrate on the more interesting problem of figuring out why some things that should have been working weren’t anymore, and adding some interesting new functionality.