Cincom VisualWorks Smalltalk: doing something useful

The Return of the Living Dead

(I'm going to ignore the sequels to the original classic film. I like to pretend they were never made).

In the last post, I had resolved myself to making something useful. One of the good things about Visual Studio is the AWS explorer, it enables you to nose around in your AWS setup, look at output logs of lambda functions, look at your ECS containers and whatnot. When I switched to Visual Studio Code, I see there is an AWS explorer but it's a bit pathetic. Building an AWS explorer is a bit of an undertaking (there are a lot of things in AWS) but I have a few rules for this undertaking. The first is that the tool is for me, personally. It's not necessarily going to become an essential part of my build process and I won't foist it on other developers that work on my code base. The second is that it will have a proper UI. You can simply use the AWS command line tools to do pretty much everything, so I can always fall back to that.

In this case, I also want it to be completely cross platform, i.e. it needs to run on Debian, Windows and my ancient Mac (for giggles), because what I want to see is whether VisualWorks can build something quickly that is personalised, won't take up too much of my time, yet be useful

Brains! Brains! Brains! Brains!

Note, I'm super lazy. What I want this unnamed tool to do is run the AWS command line interface for me, parse the JSON output and display it in a nice tree view (or whatever), then on the nodes of the tree, offer something useful. I'm going to start with DynamoDB as it's the most obvious thing missing from the VSCode version of the AWS explorer.

I'm also targeting the AWS CLI because that removes one of the compatibility issues I might come across - AWS already did the hard work, I just want to fancy format the output without spending a ton of time.

So there are two things I need to start with: the first is a way to execute the aws command, the second is a way to interpret the JSON that comes out. Unlike tools used by millions, we are going to struggle to use something like StackOverflow to help working out how to find that functionality in VisualWorks. From this perspective, I've regressed to being somewhat of a beginner again because the classes have changed a bit since 1995 and I have forgotten pretty much everything anyway.

I can finally see the one thing the one thing that can relieve this horrible suffering.

I don't know how to execute an external process in VisualWorks any more and using the Browser is the way you search for stuff like that. Except I don't know what I'm searching for. The Browser looks like this:

I want to search for...something. After some thought I figure the word "fork" might be useful. If you're not familiar with Unix systems, you will likely never had to build a C program that did the classic fork/exec pair but those system calls (or modern variants) are what you use to kick off another program. I'm going to search for "fork" by typing it into the completely unlabelled search box on the Browser and hit Enter, because there is no button to kick off the search. Note you can also use "Find method:" or "Find class" from the "Find" menu.

Righto, that looks promising. Note that the method "fork:arguments:" is a Class method, which in C# or C would be "static". That means I invoke the class and I run the method directly. Let's go back to our workspace and try it out. Here is where Smalltalk is so absolutely killer: I don't need to make an entire command line app just to run an experiment, I just type my code snippet into the workspace and "Do It" or "Inspect it"

I want to list the tables in my dynamodb setup, so the command I want to run is "aws dynamodb list-tables". If I run that in a CMD window on this machine, it outputs some json:

In my workspace, I put the following code:

ExternalProcess fork: 'aws' arguments: #('dynamodb' 'list-tables')

Quick breakdown: I am sending the message "fork: arguments:" to the class ExternalProcess. The first argument is the name of the command, the second argument is a simple array declaration with two ByteArrays as the elements of the array. I can "Inspect it" on just the second argument to see my array:

I can "Inspect it" on the whole statement and get back a ByteString that contains some Json:

Very cool and very legal. Now, how do I parse the Json? I don't know! This is where VisualWorks is a bit of a bummer in the modern world, usually I just poke some questions into Google and somebody, somewhere has an answer on "How to do X in language Y on platform Z". But I'm going to try anyway

Rigor mortis. What do you mean, rigor mortis?

Learning new platforms is tough, and re-learing older ones is nearly as tough. Googling for "VisualWorks json parser" brings up a link to Cincom, which brings up a Youtube video, which mentions something called Xtreams. I do a search for that in the Browser and it doesn't come up. Might need to look in the external packages "Parcel Browser". The Parcel Browser is where you can find a bunch of optional things to add to your image. If I'm going to bring in a parcel, I will want to save my image afterwards so I can return to this image state next time I fire up VisualWorks. Annoyingly, there is nothing as simple as a "Search" box on the parcel browser. This really sucks. By accident I click on the "Directories" tab and under "Contributed" I find it. This is a lot harder than it should be

Right click on "Load" and it is now part of the system. Time to save the image with Xtreams included.

With that out of the way, there is a new class in my system called JSON that has a method "decode:", so I can do this:

JSON decode: (ExternalProcess fork: 'aws' arguments: #('dynamodb' 'list-tables'))

Which produces a Dictionary if I "Inspect it". Note: I have wrapped the call to ExternalProcess in some brackets so that the ByteArray it produces can then be passed to JSON decode:

Come in, Dispatch...send more paramedics.

So all the underlying stuff is available to do what I want (run the AWS cli, grab the output and parse it to something useful). Next, I need to build a user interface which will mean making classes and generally re-learning how to set up my own namespace, source code control and all the usual stuff you need to make a program.