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…

Why many managers failed…

So one of my posts on the Pharo Mailing list just made it into the Pharo Weekly News Blog 😉

Weekly news about Pharo

to understand the power they could have in their hand. Here is a testimony on the Pharo mailing-list. This is why we should build powerful new solutions in Pharo 🙂

Stef

Petr,

I’ve been working as a Consultant for many big corporations (mainly in VA Smalltalk) since 1996. The situation you describe is very well known to me. But in my opinion there is no technical reason for this. It’s a managerial problem. Ever since IBM went out to their customers and told them to move to Java for the better ini the mid-90ies, managers wanted the Smalltalk projects to go away as fast as possible. Nobody asked why IBM was still happily using VisualAge Smalltalk internally at that time frame….

So the Smalltalk projects were declared legacy by Management. Replacement projects were started with big efforts and optimism. Some went well, some somewhat came to fly in a bit…

View original post 486 more words