Smalltalk / Web Camp Lake Constance test run

We just had a great weekend at Tägerwilen (Switzerland, close to Konstanz/Kreuzlingen) for a test run of a Smalltalk / Web Camp.

Sabine from Spesenfuchs, Thomas from PORaBo and myself had this idea shortly after ESUG 2019, when it became obvious that a visit to the Smalltalk / Web Camp at Yesplan in Ghent / Belgium wouldn’t work for at least Thomas and me. We thought it would be a great idea and we’d greatly profit from each other if we met, showed us our code and problems, maybe coded together on some things or at least discuss ideas for solutions. So we decided we’d want to do our own and Thomas soon suggested to meet at his company in Tägerwilen which is very good to reach for all of us.

For a first run, we’d do it in private in order to see how this works out. And it worked out very well:

We spent most of Friday and Saturday talking about all things Smalltalk and Web. A lot of discussion, show us your code and how did you do that’s. I am packed with ideas and learnings from this camp.

Thanks to the fine folks at PORaBo, we had a great location with a big screen for presentations and screen sharing, a warm place with a beautiful view of Lake Constance and, last but not least, great catering.

As every programmer knows, A day is not enough to learn from colleagues and discuss ideas and concepts as well as all things real life 😉 So we went for an exquisite and cpomfortable dinner at a lebanese restaurant in Konstanz ( on Friday night. As you can see on the photos, we all were exhausted and hungry after a full day of knowledge sharing. In the course of the evening, we could at least work on the hungry part.

We did this more or less private test run of a Smalltalk / Web Camp in order to see if it works out, if the format will help people learn and get ideas. As far as I can tell, everybody was happy with the outcome. For myself I can say I had a boost. I learned a lot about how people solved certain problems, what nice options I never found in Seaside, or what I might have done wrong with Glorp session handling in a web context. I learned about UX concepts and other peoples’ ideas how to improve my application. I saw how nicely Spesenfuchs evolves and how their beautifull UIs work. I could look behind the scenes of porabo’s complex monitor applications for nursery stations and see what kinds of problems you might get when you need to be responsive in presenting statistics on large datasets.

To put it short: I found this a great success and I hope we can establish something like this on a regular basis.

Calling all Smalltalk / Web developers in the area

So we tried this for you and I’d like to invite everybody in Southern Germany, North/East Switzerland, Eastern France, West Austria or anybody willing to travel to this area for a weekend to join us for a weekend of Smalltalk and Web development exchange.

Let’s meet some place between Zürich, Würzburg, Besançon, Innsbruck for another Camp like this. All we need is a room, a Beamer and your input. A sponsor would be great, but we can also see if we share the cost for a room and beamer and such.

Our plan would be to meet about twice a year at some place where most of us can travel to, so somewhere on Lake Constance, Freiburg, Zürich, Winterthur, Strassbourg, Freiburg, Bregenz might be good starting points…

Get in touch if you’d be interested and maybe even have an idea for a place/venue to meet at.

Final thanks for this one!

A Huge Thank You goes out to all participants (Sabine, Vreni, Manuel, Peter, Jannik, Pascal, Thomas) for their input. And a special thanks goes out to PORaBO for hosting and treating us. The exchange of ideas would not have worked out this well without the nice conference room with this big screen.

We had a good time!
And I hope we can do this again soon…

VA Smalltalk 9.2 released

Instantiations just released Version 9.2 of VA Smalltalk. It is now available for download for all registered users with a valid support contract and there is also a free evaluation version for anybody interested in trying it.

Over the last few releases, it seems the folk over at instantiations decided to make each new version a bit more exciting than the last one. The biggest and most revolutionary change in 9.0 surely was the introduction of a new VM, which is much faster than the old one. It’s hard to believe, but the mere speed of the VM wasn’t the main reason to build a completely new VM. The more interesting fact about this new VM was that it is now based on widely-used standard infrastructure and therefor allows for easier maintenance and development for new platforms.

The first, long awaited step here was support for 64 bits on both Linux and Windows.

With the new version 9.2 we see a completely new architecture being supported by VAST: ARM processors. Yes, there is now a VA Smalltalk version you can run on ARM machines, like the tiny Raspberry PI computers. We are likely to see more and more Smalltalk on IoT devices, new ARM-based Servers, and who knows, maybe one day on mobile devices…

But Instantiations didn’t stop there- VAST 9.2 now introduces a new JIT compiler, which again increases execution speed on the basis of the new virtual machine.

The Instantiations we see these days is not the same company that it was, say, 10 years ago. Back then, new releases were more or less maintenance updates, bundled a few more tools that had existed before, but were not previously shipped with VAST.

That has changed dramatically. Instantiations has shifted gears and ships lots of new code and features with each new version these days. Areas of special interest have been encryption technologies, better development tools and some love for long-standing features of VAST.

VAST 9.2 continues on this path.

My favourite new features of VA Smalltalk 9.2 are:

  • Native Database Driver for Postgres
    For years, VA Smalltalk has only been supporting commercial databases like DB2, Oracle or SQL Server, and ODBC. Open Source has made its way into even big corporations and so I felt the need for DB drivers for at least Postgres and MySQL/MariaDB. Instantiations also has NoSQL databases on their roadmap, so expect to see more in upcoming releases
  • SMTP / IMAP support
    VAST has supported these standards for almost two decades now. However, the level of support was more like providing the most important building blocks for these technologies. Without anything related to cryptography. The code hasn’t been touched in many many, years, I’d suspect almost never since Instantiations took over VAST maintenance from IBM. This time around, Seth and his team decided to change this and redo the full stack of SMTP and IMAP from the ground up. So this can be considered completely new and – according to my first tests – very well crafted!
  • Full support for HiDPI monitors on Windows
  • Usability improvements for the Linux version of VA Smalltalk
    We’re deploying most of our web based products like on Linux servers. So final testing and maintenance and bug hunting need to be done on Linux. VA Smalltalk has been available on Linux for many years, but its look & feel on Linux is not as nice as one windows. Many of the nice improvements for the IDE itself are not available on Linux yet, because VAST uses the tried and tested MOTIF GUI toolset. Unfortunately, Tried and Tested not only means rock solid, but also not really as modern as other GUI toolsets on Linux (Gnome/GTK, for example). VAST 9.2 makes things a little nicer, but we will only see Scintilla support on Linux when MOTIF is replaced by GTK, which is already on the roadmap for VAST.
  • ARM support
    Servers with ARM processors are getting more and more popular, because they offer more computing power per watt (very generally speaking) than X86 processors.
    For the very same reason, most mobile and IoT devices these days are powered by an ARM processor.
    So Instantiations is pushing open a door into these worlds with this new VM technology

There are a lot more new features and improvements, but these are the ones I personally am loking forward most. You can find a list of all new features on Instantiations’ web site.

Of course the development will not stop there: a new version is already in the works for 2020 and here is the company’s roadmap for the upcoming release(s).

How to get VAST 9.2?

If you are a customer with a current maintenance contract, you can download VA Smalltalk 9.2 from Instantiations using your credentials.

If you are interested in trying VA Smalltalk before you buy, there is an evaluation license available that is fully functional, but doesn’t work well for deployment.

If you are in the Germany, Switzerland, Austria region and would like to buy VA Smalltalk licenses or need support on your VA Smalltalk project, you should get in touch with me at

Little VAST hacks: Keep Track of (and re-find) needed Changes

Sometimes you just need some easy hacks to make your life much easier.

One of them is to keep track of things you have to do later. Be it cleanups, some other thing to take care of once “this is done”.

We as Smalltalk developers live, drink and breathe source code and objects and are most comfortable within our beloved Smalltalk environment. So how do you mark a method as something to be taken care of later? And how do you make sure you can keep track of these places?

The answer is so blindingly easy that I wasn’t sure if I should take the time to write it down and steal your time to read it. Yet, it is one of those life hacks that open new possibilities if you didn’t know it yet.. So here it is:

Implement a method like toDo: (or use one that’s available)

We’ll use the Smalltalk tools for our purpose. So the easiest thing we can do is use the mechanism to find senders.

First we need a method named #toDo: or similar on Oject. If you have Glorp loaded in your image, you already have such a method, it is called #needsWork: and takes a parameter. The parameter is what makes things interesting, because you can now hand a String (or whatever you want) as a parameter to the method.

What does this method do? Well, it doesn’t really matter, as long as it doesn’t break your program 😉 So the implementation of needsWork in Glorp is beautiful and maintainable:

needsWork: aString


Since the return of #self ist standard behaviour in Smalltalk anyways, you could as well keep the method empty. You can add some comments, add some logging or whatever, just make sure the method has no side effects.

How to find these places?

Well, you can now search for senders of #toDo: or #needsWork: and read the comments to work on your to do – list.

So this is all I have to tell you about this. You’re welcome. This trick works on all Smalltalk dialects and has been used for decades.

Just one bonus for you: If you like to collect important snippets for your daily work in a Workspace or even are a fan of adding your own Menu items to the System Transcript or like to automate stuff, here is a little snippet to open a Browser on all Senders of a Method in VA Smalltalk:

System image allMethodsSending: #needsWork:

Just evaluate this whenever you need to know what’s on your list for today.

That’s all folks, have fun Smalltalking

Pharo is moving to GtK3 (finally)

Today seems to be my Smalltalk-news-blogging-day 😉 It started off with an announcement from Instantiations about plans for the next release.

Just a few minutes ago Esteban Lorenzano announced on the Pharo Mailing List that Pharo 8 will be based on Spec 2.0, a new version of the still quite young GUI framework in Pharo. This would not be a sensation by itself, people are releasing 2.0’s of something all the time. The real announcement in this announcement is that Spec 2.0 will be suitable of running on top  of GtK 3 and therefor Pharo will soon be able to support native widgets on virtually all supported platforms (Windows, Linux, Mac). So native look&feel is coming to Pharo! How’s that?

I’m a bit sceptical all of this will be “finished” in Pharo 8 (if Pharo 8 is scheduled for the next 12-18 months), but the move is the right one in my opinion.

Yes, we do use the Cloud. And yes, RESTful services and web applications seem to be everywhere. But still we do use lots of locally installed tools every day. And there, look & feel is important. Most Smalltalk IDEs feel a bit foreign on their host operating systems. Historically, this is for a good reason: The IDE’s GUI was cross-platform from the very beginning. The GUI was emulated and/or completely home made and just used a few graphics directives of the hosting operating system. And this has been a problem for many Smalltalk dialects for decades: they looked and felt strange.

That’s why Smalltalk IDEs like Dolphin and Ambrai (long forgotten) were so nice in my opinion: they behaved like a native application.

These days can soon be over, and I hope Pharo will spear head a movement here and show how well things work.

News from Instantiations: VAST 9.2, IoT, new JITter

Last night Instantiations sent out a newsletter informing users and fans of VA Smalltalk about the latest developments around VA Smalltalk.

It’s not too much of a surprise that Instantiations is working on a new release 9.2 of VA Smalltalk which is scheduled to arrive later this year (let’s speculate a little and spread rumors about the timeframe of the ESUG 2019 conference in Cologne, Germany, starting August 26th…).

The more surprising things in their newsletter is that there will be a JIT-Compiler that makes the new VM even faster than before. So not only do we have pure 64 bit VM’s since release 9.0 (9.1 for Linux), which already beats the old VM in many fields, we’ll soon have an even faster one. I really look forward to enabling or Kontolino! users to work even faster.

VisualAge (which was VA Smalltalk’s name back in the IBM days) has always been designed to be cross-platform. Back when it came out in the early 90ies, it targeted OS/2, AIX and Windows, soon to be followed by Solaris and HP-UX. You write Smalltalk code, VA ST does the rest for you. That has always been the idea and the base design principle for most if not all class libraries in VA ST. A decade and a half or so ago, IBM came out with a version for Linux, which powers our web applications and many services at other customers. My guess is that this platform has yet to see its peak in usage in VA Smalltalk, as more and more systems move from fat clients to either REST or web servers.

The next big step will be IoT platforms, most of which are based on ARM processors. Started as a hobby project, it turned out that a port of VAST to ARM was not only feasible but also easy and the resulting programs turned out to be performant enough to run on small devices like the Raspberry PI. So it’s only logical that there will be a VA Smalltalk port to ARM devices.

My personal dream based on this is that Instantiations will one day find out it is even feasible to support not only IoT machines, but also ARM-based tablets and Smartphones (I know, Android is not Linux and running headless Smalltalk code on an ARM processor is not even half the rent to running a GUI application in a new operating system, but, otoh, Linux enthusiasts all around the planet are working on end-user targeted Linux-Distros for tablets and Smartphones based on X Windows, so never say never!).

So I think it is fair to say that Instantiations is working on a few very interesting and promising things at the moment – as they’ve been over the last few years. It seems Smalltalk is going to be around for another decade or two (and beyond), and may even become stronger. Instantiations has obvious plans to be among the leading commercial vendors in that field.

If you want to read the full newsletter from Instantiations, you can do so here. And if you are interested in Instantiations’ product roadmap, please follw me here.

If you’re interested in VA Smalltalk licences in Germany, Austria or Switzerland or need consulting services around VA Smalltalk here in this area, please contact us for more details.

VASTGoodies just turned 10

As Adriaan just announced on his blog, was launched the 27th of January, 10 years ago now. But not only that, just a few days before that milestone, another milestone was reached: the 1000th upload!

The introduction of VASTGoodies was a much-needed and welcomed addition to the Smalltalk universe. Back in the 2000’s the open source idea was getting more and more prominent in the Smalltalk world. Squeak and Pharo were around, yielding lots of great open source code. Seaside once was the landmark project for open source in the Smalltalk world and had the potential to make Smalltalk vendors agree on standards, while before Seaside, every single one of the concentrated on keeping their customers and getting people on board of their Smalltalk dialect. (Well, that’s not entirely true, IBM gave sh*t about their VisualAge Smalltalk customers back then, only cared if they were willing to port their code to Websphere).

So, where was I? Ah, yes, open source. There had been quite a few places to find and download open source code for VA Smalltalk before 2009. Some of them still exist. But you had to know them. If you wanted to share code with others, you had to find options for hosting the code and documentation.

VASTGoodies changed the game. You could find open source code, download and load it right into your library with the help of Adriaans VASTGoodies tools, which Instantiations ships with the product. And, what’s more: you can easily upload code to VASTGoodies and make it available to all other VAST users out there with just a few clicks right in your Configuration Maps Browser.

So, let’s celebrate this birthday and thank Adriaan and his employer for writing, maintaining and hosting It has been a place to easily find and get open source code.

A birthday is always a good opportunity to look back (checked) and also look ahead. So what’s to come?

It may sound brutal but I hope we won’t need VASTGoodies for another 10 years.

The current Smalltalk world is finally making a move towards “standard” code management systems and platforms. This is important for several reasons:

  • Smalltalk code should be retrievable by search engines and thus make Smalltalk more visible for people looking for solutions and examples
  • It should be easier to exchange code between Smalltalk dialects.There are ideas and concepts to make code exchangeable between Smalltalks, like the Tonel source format.
  • Right now, it is hard to contribute to a Pharo or Squeak code base if you are on another dialect. I still hope the VA Smalltalk world will be a little more open to the open source idea
  • Pharo and – to some extent – Squeak are moving away from proprietary souce management systems to current standard ones, like git and platforms like github. Instantiations has a prototype of a bridge to external source management systems and is working on this area.

So let me finish by thanking Adriaan for VASTGoodies and the accompanying tools and for his energy to maintain this for 10 years now. I also want to thank the contributors who uploaded code to VASTGoodies. There are quite a few very nice contributions there, like helpers for accessing the pins on a Raspberry Pi, complete code generation tools, helpers for several file formats and much, much more.


What to do when VAST x64 (and Seaside) on Linux need a little help finding

[update: I just updated the title of the post, because on other Linux machines,  like our test and production servers, there is a link named in the 64 bits libraries path, so the change to the ini file is not necessary there…

20591215 0 lrwxrwxrwx 1 root root 16 Jun 20 13:29 /usr/lib/x86_64-linux-gnu/ ->



My dilemma these days is that I have very little time besides my work on Kontolino. At the sime time, I’d like to re-start blogging and hopefully provide some helpful information to the Smalltalk world. So all I can do at this moment is use my blog as a little notebook of findings that I feel will either be helpful to myself in the future or – even better – to others as well.

We’re currently attempting to port or Application from 32 to 64 bits. so far, the process was quite smooth on our development environment (Windows), but needs a little tweaking on Linux.

First, let me say something so surprisingly positive that I could hardly believe it: we are using an external library on Linux which is available in a 32 bit as well as a 64 bit variant. And what can I say: our code needed absolutely no change! It just ran on 64 bits in both Windows and Linux. Fantastic!

Some other things I found so far:

  • With Environments, you can easily have 32 bits and 64 bit versions of VAST coexist on one machine, both on Windows and Linux. I don’t know if I ever mentioned it, but Environments is an excellent addition to VA Smalltalk!!!
  • You must not mix .ini files between 32 and 64 bit images. This can lead to strange effects. As a long time VA Smalltalker, I should of course know that. I just keep forgetting it.
  • On my play/test machine for dirty experiments, a used Dell Laptop with Xubuntu 18.04 on it, I had a strange effect with Seaside: The session object would be nil and never be initialized, even though all seemed well. The error messages were somewhat useless for finding the problem. It turned out that trying to visit http://localhost:800 shows a much more helpful error message: WANoSecureKeyGeneratorAvailable.
    The strange thing here is that the 32 bit version of the same app is running on that machine quite nicely. So I was sure this must be a library problem.
    And it is: there is a in /usr/lib/i386-linux-gnu/, but obviously there is no 64 bit version of it on my machine. I checked that openssl (without :i386) is installed.
    But there is /usr/lib/x86_64-linux-gnu/ on the machine. So at least on this machine I have to change the CRYPTO_LIB parameter to point to /usr/lib/x86_64-linux-gnu/ or set a link to it. Now the session runs perfectly.

The process is not finished yet, so there may be new findings over the next few days. For now, I’ll stop here…

Seaside, File Libraries and UTF-8

In my seemingly endless hunt for potential problems with Umlauts travelling between our users’ web browsers and our Seaside images, I find new areas of “interest” almost daily. As a little background information, it might be useful to mention that at least the Smalltalk diealect we are using (VA Smalltalk) is not speaking UTF-8 natively, so a German Ü in our images is encoded in ISO-8859-1 (or Windows 1252 or such), while the rest of the web uses utf-8 these days. Since Version 9.1 of VA smalltalk, we have at least a reliably working Seaside Adapter which converts between the web client (utf-8) and server (iso-8859-15 in our case).

This time, the problem was with special characters that had been entered into Smalltalk browsers in FileLibrary methods. In our case, we’re talking about Javascript code that is stored in WAFileLibraries and being edited inside the Smalltalk IDE (if you have no idea why anyone would want to do that, this article is probably not suitable for you 😉 ).

Since we deploy or file library contents to the file system on the web server (Apache will servve these from the file system instead of the Smalltalk image) for performance reasons, the above-mentioned adapter is not in the game any more when a user accesses our site. So our wait dialogs and stuff that had been implemented in these javascript methods would always display wrong characters.

Once you remember that the reason why things work on your development machine and doesn’t in production is due to this deployment, it is clear that the deployment process is not converting the files on output. So they end up on the file system in the wrong encoding.

There are at least two ways you could fix that:

  1. fix deployFiles in WAFileLibrary to add teh step of converting to utf-8 before saving to disk
  2. use the power of bash and iconv to convert the files on the file system on the deployment machine(s)

There are lots of good reasons for 1. However, apart from the fact that I don’t have access to Seaside’s base code and am not even using Pharo, and because I’d have to test what happens to binary files (like .png and such), I decided to use approach 2.

The script for doing this is easily stippled together with the help of StackOverflow

find . -name '*.js' -exec iconv -f iso-8859-1 -t utf-8 "{}" -o "{}" \;

As I said, integrating this into WAFileLibrary in Seaside would be much better. There are a few caveats when using this script:

  • you must run it exactly once, otherwise it will completely break Umlauts on second conversion
  • you need to remember to run it every time you update the files on the server
  • there are more, I am sure. I just can’t think of them right now

So this is not perfect. I will try to integrate it into teh two relevant implementations of #deployFiles and see if I can contribute that code back to the Seaside maintainers…


Glorp findings – using count:

Conntinuing on the Customer/Order example from my last post, we might want to only send some ads to customers who have ordered at least twice in the past. For this we’d first have to cunt all orders of our customers who haven’t ordered for at least 100 days.

So the first step is to create an SQL Statement that counts a customers’ orders and then select only those with more than one order. As usual in Glorp, it is extremely easy to do so – once you know how 😉

So this is how to create such a subquery in Glorp:

myDbSession read: Customer where: [:c| 
  (c count: [:cust| cust invoices]) > 1 ].

This will result in:

SELECT,, t1. ...
    WHERE (s1t1.cust_id = 
  > 1)

And return all customers that have ordered at least twice.

The next step is to combine this with our notExists: clause from the last post:

myDbSession read: Customer 
where: [:c|
  (c count: [:x| x orders]) >1 
  AND: (c notExists: (Query read: Order 
       where: [:p| p customer = c 
               AND: [p date < (Date today subtractDays: 100)]])) ].

It’s really that easy. You just need to remember who is the receiver for count: and notExists: etc. And that’s exactly why I find this hard sometimes.


Glorp Subqueries – notExists:

I decided to get back to blogging after a very long break. Since I am quite busy with our Kontolino! project, I also decided that I need to get back to blogging with small articles that require little time – but might still be useful. So here is the idea: I am struggling with Glorp and O/R mapping much more often than I’d like to and since Glorp is not documented well enough when it comes to “more advanced” techniques, I thought I should probably just write a blog post whenever I solve a more or less difficult problem that required some searching and trying. This is in the hopes that my blog will be a source of information for myself and maybe other readers.

So here is my first (well, actually I have written a little bit about my Glorp “discoveries” in the past, like here, here or here) installment of this new series:

If you need to query objects using a NOT EXISTS in the resulting SQL, Glorp can of course help you. Let’s say you need to find all Customer s in your DB that haven’t ordered anything in the last 100 days and you’d like to send a nice Coupon code to them. So you need to find all Customers who do not have an order that is younger than 100 days. This is of course easy in SQL, but the Glorp syntax for such queries is a bit “different”:

myDbSession read: Customer 
     where: [:cust| 
       cust notExists: 
         (Query read: Order 
           where: [:ord|
             ord customer = cust 
             AND: (ord date >= (Date today subtractDays: 100))])].

Let’s start a little competition / blog parade:

Do you know of nicer ways to do this? Any hints/tipps about this query you’d like to share. Just write a blog post and trackback to this post to see if we can improve on this.

What Glorp related tips like this one can you think of that are worth mentioning? Respond in a comment or write it to your blog and let’s help each others and new users learn as much as possible about Glorp.