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 https://www.kontolino.de 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 http://objektfabrik.de.

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

	^self.

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,

VAStGoodies.com 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 VASTGoodies.com. 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 libcrypto.so

[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 libcrypto.so 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/libcrypto.so -> libcrypto.so.1.1

/update]

 

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 libcrypto.so 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/libcrypto.so.1.1 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/libcrypto.so.1.1 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.id, t1.name, t1. ...
FROM MYSCHEMA.CUSTOMER t1
WHERE (
  (SELECT COUNT(*)
    FROM MYSCHEMA.ORDER s1t1
    WHERE (s1t1.cust_id = t1.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.

 

Seaside Learnings, pt. 123

Note to self: never, never ever try to use show:onAnswer: or answer: in an Ajax callback. In your delegating WATask orย  WAComponent you will see the callback code run as if all was good, just the new components won’t show up in th browser. This will take a long time to debug and you won’t feel like a rock star developer once you found the solution…