The manual that never was written (but should have been)…

Tom has only started blogging a week ago, but obviously he decided to not waste any time with long useless stuff. After all, he’s a Smalltalker 😉

His first posts so far were all very interesting, tearse, and provide a lot of useful information and ideas around build automation with VA Smalltalk. One of the big mysteries in VA Smalltalk is the role of the abt.cnf file, which was said to support the execution of Smalltalk scripts on startup of an image, but there’s never been much documentation about it. Since the execution of the Smalltalk code in abt.cnf happens very early in the startup sequence, simple attempts of doing anything useful in abt.cnf failed miserably. So I gave up on it long ago and had almost forgotten about it.

In his latest post, Tom shows how to use abt.cnf for loading code into a virgin image which really contains no pre-loaded code (meaning a copy of abt.icx from the /newimage subdirectory). So I’ve learned something new that I will definitely use to get rid of the necessity of building “basic preloaded kernel images” for our Stream-based configuration and packaging tool. We can just use abt.cnf to pre-load that base image without any prerequisites – a cool thing!

You know, in a world where you have these ever-re-occuring steps like loading the latest code into a virgin image every morning and performing all the same 43 steps for packaging again and again, every little improvement pays back after a very short time (just imagine your machine prepares a new image in the morning for you while you discuss the latest soccer results at the coffee machine or during your standup meeting…).

And I liked this one:

I have a deep and abiding hatred for the Application Organizer, so I like to ensure that it won’t offend me with its presence…

My favorites are the question whether I want to go to the Organizer or start a new project every day 😉  and the fact that StSDebugger is always deactivated bay default (luckily, I fixed that one a year or two ago).

New Blogger with Smalltalk topics

Tom Koschate has finally decided to join the Blogosphere with his Blog named “Nothing About Elks“. He also has a welcome present for all VA Smalltalk users which he just announced the other day on the VA Smalltalk Support Forum:

I’ve uploaded the code I use to support automated packaging using the Jenkins (formerly Hudson) integrated build server to There’s a lot of overlap in functionality with Melissa, but there are some important differences too, including the ability to package XD images.

As you may know, I’ve been working on very similar topics, including coupling our build process with Hudson and I really look forward to having a look into Tom’s goodie and to see how he solved things. I didn’t have look into XD packaging for our customers yet, so I hope I find the time soon.

His first blog post explains a bit of why he built the tool and what scenario he found when he started on his current project:

Generally speaking, this results in having to package four to five different Windows images and a half-dozen UNIX images for each plant. Historically, each plant has been treated as a separate system with a separate release schedule. As you can imagine, this has led to some interesting forks in development.

This not only sounds familiar but also as if he’s got a lot of experience to learn from.

So welcome, Tom! I look forward to reading more and learning from your experience!

Instantiations’ plans for VA Smalltalk

John O’Keefe gave his regular VAST Update talk at Smalltalk Solutions this year, detailing their plans for VA Smalltalk.

The main slides for me are the announcements of major features for the next release that is scheduled for Summer 2011 (which, by John’s definition can be very long this year – but I have nothing against a long warm summer 😉 ):

Major new features for VA ST 8.0.4 (??)So we’ll finally see full support for UTF-8 for e.g. Seaside and we’ll get Continuations. Even if Continuations aren’t really needed for most Web Apps today, VA ST’s port of Seaside will finally be compliant to the available Seaside documentation.

I especially look forward to the new GUI controls on Windows. VA ST has been missing many newer windows widgets for a long time now and some freshup in this area is greatly appreciated. Especially the fact that they plan to support these new Widgets in both the Composition Editor and WindowBuilder shows their commitment to both tools. An important message to all existing customers.

And I really look forward to a better merge tool and code completion. Every time I come back to VAST after working in Xcode I miss it.

A settings framework will be the foundation for a major cleanup of the menu structures in VA Smalltalk. If you load a handful of extensions into VAST, you’ll find some sort of settings, preferences and defaults in almost every menu, spread over the whole tool. Once a central settings framework is in place,  it’s relatively easy to clean this up.

So the message is that Instantiations is now taking concrete steps to go forward with VA Smalltalk. If all of these announcements come true for the next release (there are more minor changes mentioned in the talk), this will be a major step forward.

I am also glad to see that Instantiations has picked up some of these plans from discussions on the VA Smalltalk support forum and personal talks with users and partners. I’ve been blogging about some of these topics and have discussed them with other users and customers as well as with Instantiations in the past and I know the input came from several other sources as well.

Slides of StS2011 talks are online

The Smalltalk Industry Council (STIC), organizer of the Smalltals Solutions Conference has put the slides of the talks online for download:

Smalltalk Solutions 2011 has come and gone, but the effects of the conference will linger through this next year.  […]
The Smalltalk Industry Council will be releasing the videos of each of the sessions over the coming weeks.  In the meantime, they have released the presentations of each speaker, as well as posted some pictures and a brief overview video.


VA Smalltalk, GLORP, Proxies and #isNil [Update]

This is mostly a note to myself, because these little things can cost you some hours, even though you clearly know about all the pieces of the puzzle and simply forget to use the right peek statement at the right time.

So what’s cost me hours today? I had weird results in my Seaside Apps where components shouldn’t be displayed and – even more important – not ask non-existant objects for data. But my whole problem wasn’t related to Seaside or our internal web framework at all. What we have implemented is a method for certain containers to decide whether they get rendered based on the value of a Block that’s evaluated at render time. Only if the Block returns true, the component would be rendered, and only then the underlying business object would be asked for its data.

Example: Only if a Customer has an Address object, the address FieldSet would render itself and ask the address instance for its street, zip code and so on. This is not only for optical reasons but also due to the fact that a non-existent address instance (aka nil) doesn’t understand #street, #zip or city.

So what I had was a Block that said

myComponent visible: [self customer address notNil] ...

(Note that visible: is not a method of Seaside, it’s in our own Framework, and also not that Seaside is not relevant here).

I always got errors when I rendered the component for customers without addresses, even though the Block was evaluated before rendering of the component would be started.

Interestingly, when I set a Breakpoint and inspected the result of self customer address I got nil. And asking that nil object in the inspector whether it is notNil always gave the right answer. But obviously, when the code ran, it answered true, as if there were two kinds of nil.
So what was going on?

After some minutes of being a bit puzzled, I came to the conclusion this must be something related to GLORP’s Proxies, because the Customer objects were read from the database.

Some experimentation showed that replacing notNil with ~= nil worked like a charm.

Being a Smalltalker, the first idea was to see if Glorp’s Proxy did something wrong. Normally, sending a message to a GLORP Proxy works as expected: the proxy forwards a message to the result of self getValue. So I tried setting a conditional Breakpoint into Proxy>>#doesNotUnderstand: , that only fires if the Message’s selector is #notNil. Unsurprisingly, the Breakpoint never fired. Even when I had a Breakpoint immediately before #notNil is sent to the Proxy, I could see that it the block was evaluated, but it seemed the #notNil message never reached the Proxy.

This was the moment when all of a sudden I remembered that #isNil and #notNil are optimized in VA Smalltalk, meaning these message are never really sent to the receiver. The VM checks for nil in a primitive rather than calling the methods #isNil and #notNil. Even though these two methods can be found in the Image, and the implementations are correct, they are just there for documentation purposes. You can put halts and breakpoints into them as many as you want, the methods never get sent.

This also explains the differences between the behavior when inspecting  self customer address and sending notNil to the resulting nil object and having the method just run. In the inspector case, the inspect would cause the proxy to execeute getValue and I’d be sending notNil to the resulting nil object, while in the method run case the receiver of #notNil would be the Proxy, that is not nil and will always answer false to #notNil (because it never gets the chance to forward the #notNil message to the real object).

So, still being a Smalltalker, you might think that situation is easy to solve, because you can alwas implement #isNil and #notNil in Proxy. But if you’ve read the last paragrapg carefully, you’ll understand that there’s no use in doing so. Because the new implementation would never be called.

So if you (me) are (am) working with GLORP and need to check for nil or not nil, there are mainly two workarounds (none of them elegant or nice, but they work):

  • send #= nil or #~= nil
  • send #getValue to an object before sending #isNil/#notNil

You may be bored by this, because you think it is old hat. And you’re right, it is. But I hope I won’t forget it again now that I’ve written it down 😉

[Update] As Alan mentions in a comment to this post, newer versions of GLORP do not create a Proxy if it’s obvious that the related object will be nil, but set the instance variable to nil instead. So with newer version of VA Smalltalk that will ship with a port of a newer Glorp version, using #notNil / #isNil will work as expected [/Update]

Smalltalk Inspect Episode 3: VA Smalltalk Teil 2 – Envy

Ab sofort steht die dritte Folge unseres Podcast “Smalltalk Inspect” zur Verfügung. Diesmal setzen wir unseren Rundflug um VA Smalltalk von Instantiations fort und widmen uns besonders Envy, der Komponente zur Versions- und Konfigurationsverwaltung.

Smalltalk Inspect ist im iTunes-store zu finden. Und hier geht es zum RSS-Feed für andere Podcatcher.

Wir würden uns über Feedback, Anregungen, Diskussionsthemen und interessierte Interviewpartner sehr freuen. Dazu kann man hier auf diesem Blog, bei Marten oder auf unseren Podcast-Blog einen Kommentar hinterlassen, oder uns direkt kontaktieren.

Smalltalk Solutions 2011: Georg Heeg pre-announces public availability of Slides

Georg Heeg, Director of the Smalltalk Industry Council (STIC), just wrote to several mailing list (like the esug, vwnc, and gsug lists):

Smalltalk Solutions 2011 is over. It has been a great conference. The mood among Smalltalker was great. There is really interesting new stuff going on in various places.

For those who attended and want to recap what they had heard, and for those who could not make it we are currently preparing slides and videos to become available on our web site

Currently we are collecting comments about

  • What worked?
  • What did not work?
  • What do you want to see at next conference?
  • Location requests
  • Time of the year

Please send your comments to, preferably within the next two weeks.

Thanks to all who made this conference a great success: the sponsors Cincom, Instantiations, GemStone, and Precision, the speakers, and all the attendees!

I really look forward to watch the vidoes soon…

Esteban’s Mars Project is alive

At last year’s ESUG conference, Esteban Lorenzano showed his progress on Mars, a framwork to implement native Cocoa interfaces in Pharo Smalltalk. His goal was and is to provide a way to build native Cocoa Apps without the need to build parts in Interface Builder and load NIBs etc. And I was very impressed by what he showed.

After ESUG, you couldn’t read or hear much about Mars and Deimos (a sub-project for iOS GUIs based on MARS). In his latest Blog post Esteban explains a bit of why that is: He faced a few technical problems that were hard nuts to crack, but it seems he’s back on Track and Mars is going to get real. And what’s even better: he found people to help on the project.

Cheers and Good luck to the team! We hope to code native Mac Apps in Pharo soon!

Smalltalk Inspect Episode 2: VA Smalltalk Teil 1 – GUI

Ab sofort ist Folge 2 unseres Podcast “Smalltalk Inspect” zum Download verfügbar. Diese Episode ist die erste von vermutlich 3 Folgen über VA Smalltalk von Instantiations. Wir werden uns in Zukunft auch mit anderen Plattformen beschäftigen, aber VA Smalltalk ist unsere “Heimatplattform”, auf der wir uns alle drei recht gut auskennen.

Wir haben recht viel Material zum Thema aufgenommen, und Marten arbeitet noch daran, das ganze in geniessbare Stücke zu tranchieren. Nach aktueller Planung werden die drei Folgen nun im Wochenrhythmus erscheinen. Wie wir dann die Folge zu Sebastian’s Besuch auf der Smalltalk Solutions unterbringen, müssen wir mal noch sehen.

In dieser ersten Folge geht es vor allem um ein paar Aspekte der Geschichte von VisualAge Smalltalk bei IBM und das Parts-Konzept, mit dem IBM einst ein “Visual Age of Programming” einläuten wollte. Was davon übrig ist, und wie man das heute noch nutzen kann, ist Thema dieser Folge. Den Übergang von IBM zu Instantiations werden wir später noch diskutieren.

Folge zwei wird sich in erster Linie um Envy drehen, aber dazu mehr beim nächsten Mal.

Und hier geht’s zu unserem neuesten Baby:

#002 – VA Smalltalk – Teil 01 – GUI

Bei iTunes findet sich Smalltalk Inspect inzwischen auch. Und hier geht es zum RSS-Feed für andere Podcatcher.

Wir würden uns über Feedback, Anregungen, Diskussionsthemen und interessierte Interviewpartner sehr freuen. Dazu kann man hier auf diesem Blog, bei Marten oder auf unseren Podcast-Blog einen Kommentar hinterlassen, oder uns direkt kontaktieren.

Objective-C 2, Xcode 4, LLVM, what’s next?

Objective-C and Cocoa are a nice environment to work in. The nicety of Cocoa comes from the fact that it is an object runtime system rather than a bunch of objects compiled into a running program. A Nib file (or xib file as they are called now) is nothing else than a saved snapshot of instantiated and configured GUI objects. So loading a nib is like loading a Smalltalk image: living objects are woken up and continue running at just the place they were when they were saved.

So Objective-C and Cocoa are very similar to a Smalltalk system. But still lightyears away from the real thing. Apple is doing their best to make it better and better and make it feel like a live object system. The just-released Xcode 4 IDE is a big step forward into this direction. (Side note: The eclipse community is also constantly moving into the object system direction by building something very similar to a Smalltalk image).

The next logical step after the achievements with using LLVM as an intermediate layer below Objective-C would be to get rid of the C heritage of Objective-C. Not only is the fact that you have to put Objective-C expressions into square brackets annoying, but also the fact that you need to convert from base types and structs into Objective-C objects and back a lot more often than a programmer would like.

Rumors of Apple working on a new fully dynamic programming language that runs on top of LLVM and reuses the Cocoa object model aren’t really new, but I think they make sense. And having used both Objective-C and Smalltalk, I sometimes think that Objective-C is quite good, if only their creators had gone one or two steps further and made it not only a poor man’s Smalltalk, but rather a real alternative to it. But back in the 90ies when CPU cycles were expensive, NeXT probably had not many alternatives to preprocess down to C and compile classic C code. Today, the C fundament is the weakest spot of the language, not only in my opinion.

So I hope there’s some truth behind the speculations about a new language. Apple has owned a Smalltalk implementation in the past (it’s now open-sourced and called Squeak), so the new language is probably not going to be Smalltalk, but I am sure it will be very much like it (because Cocoa and Objective-C are very similar to Smalltalk and have proven to be powerful): dynamically typed, a live object system (maybe even image based) and with a pure and easy syntax. Swimming on Apple’s wave of success, this could get very popular, and it will surely feel a lot like Smalltalk.

With LLVM and far over a decade of experience with NeXT Step, Cocoa and Xcode, Apple has all that’s needed to build a great programming language, IDE and object runtime system that’s far superior to what most people out there are using today.