Language Dynamics

Apple drops Java
Microsoft drops Python and Ruby

Smalltalk portability: Sport and Grease

There are many dialects of Smalltalk. The implementation of the language is very similar in them all (partly thanks to the ANSI standard), but it's not exactly the same. The differences mean that a library or application written using one Smalltalk dialect can not simply be loaded/compiled and run in another.

Let's say you developed an application using Visual Smalltalk and you now want to deploy it using Pharo. Most of the code will work fine in both Visual Smalltalk and Pharo, for example "OrderedCollection new" will do the same thing in both, but things like sockets, files, times and string parsing classes and methods are different in the two dialects. To get the application working in Pharo you'll need to go through all the code in the system checking for things which don't work the same way and fixing them. Changing code to run on another platform is called porting, and the result of a porting exercise is a second implementation of the subject system. A second body of code which will need to be maintained separately, so if you extend or fix a bug in the Pharo version you'll need to remember to make the same effective change (perhaps implemented a bit differently) in the Visual Smalltalk version. It is quite likely that such code bases will diverge over time. The cost of porting a system and then maintaing multiple versions of a system and them keeping then in step can be high; you may end up having to support them as distinct systems with separate lives.

Fear not. There is a better way.

Portability libraries are used to minimise the cost of porting an application. Portability libraries place the platform specific things behind a defined API. If a Smalltalk application is written to use only portability API(s) and 'standard' features it can be moved unaltered between Smalltalk dialects. Some applications have to use features which are peculiar to a platform, such as a GUI library, and such portions of a system must be ported and maintained the hard way, but many systems today can be, and are, written in such a way that they are completely portable between dialects using portability libraries.

Two such libraries are Sport and Grease. Both of these libraries emerged from the process of porting code between Smalltalk dialects, but each addresses a different segment of the differences between dialects, with surprisingly little overlap between them.

Sport was created during the development of OpenSkills applications such as the SkillsBase and Membership Management System. These applications are developed exclusively in VisualWorks and are deployed to run exclusively in GemStone. The work to get the applications to run in GemStone resulted in the creation of the OpenSkills portability library in early 2004, renamed to Sport (for Smalltalk Portability) in 2006.

Similarly, the Grease library came out of the desire to run the Seaside web application library on a variety of dialects. Initially the portability code was called simply Platform and was a part of the Seaside library from about 2005 triggered by the desire to run Seaside in VisualWorks. The Grease name was applied to the portability library in the latter part of 2009 when it became a shared library used by packages related to Seaside, such as Pier and Magritte.

Sport and Grease cover different areas with their portability APIs. Sport covers Sockets, Files, Time, Exception handling and utilities such as being able to explicitly test in which Smalltalk dialect code is being run in. Grease covers utilities for parsing, printing, encoding & decoding strings, delayed sends, common exceptions, utilities such as secure hash. There is some overlap, but not much. For example, Seaside expects the underlying HTTP server to deal with socket issues so Grease does not deal with sockets. Sport in turn does not have the extensive parsing and printing facilities found in Grease.

The longer term goals for both Sport and Grease are that they should go away to be replaced with standardised implementations of the various areas, e.g. sockets. But Julian Fitzell (the Grease maintainer) and I both expect that to take quite some time. Today, Sport and Grease together provide a mechanism where Smalltalk applications can be developed in a truly portable way.

To emphasise this, because it's quite a big deal, the exact same Smalltalk code for applications may run in many different Smalltalk dialects completely unaltered with the help of Sport and Grease.

For home DNS & DHCP, use dnsmasq

I find that I have many devices in my home requiring IP addresses and names; laptops, netbooks, phones, nas, music player ... the list goes on.

While my current DSL modem/router will run DHCP and give each device on the LAN an IP address, if I want to refer to a device by name (e.g. 192.168.0.24 aka "nero") I have to add names and IP addresses to the hosts file on my workstation ... and (yawn) on every other computer I also want to see that device by name.

Adding to my woes, the DHCP server in the router is a bit free and easy with IP addresses, so if I restart a device it can get a different IP address which means that IP addresses move from device to device over time, which in turn means the names in my hosts files are all messed up. Darn ... and potentially harmful.

Of course all I really want to do it to write down once that *this* box should be given *this* IP address and made available with *this* name

... and the small utility dnsmasq lets me do just that. The following line says that the device with the MAC address 00:1b:62:01:e4:d5 is always to be given the IP address 192.168.0.24 and is always to be known as nero:

dhcp-host=00:1b:62:01:e4:d5,192.168.0.24,nero

This one line configures both a DHCP server and a DNS server (light-weight implementations internal to dnsmasq), so any machine on the LAN can now use the name "nero" in place of the IP address even if the IP address did change, which would only happen if the configuration line above were changed.

For the low-down on dnsmask see the project home page and the articles here and here.

A very brief how-to (assuming a Debian-like server) would go something like ...

1. Identify a machine on your LAN which runs 24/7 (I use a FitPC running Ubuntu) and install dnsmasq on it

2. Decide on a domain for your LAN, e.g. home.localdomain

3. Identify the devices on your network which will have static IP addresses. I have two, the DSL modem/router and the FitPC running dnsmasq. For these devices make entries in the /etc/hosts file of the machine running dnsmasq, e.g.:

192.168.0.1 gateway gateway.home.localdomain
192.168.0.100 server server.home.localdomain

4. Now work on the dnsmasq config file (/etc/dnsmasq.conf). First take a copy of the default file because it has lots of useful information in there. Then edit the file with details of your network and devices. You can see an example based on what I did for my home network below, but do refer to the docs and the original config file to understand the detail.

5. Stop any other DHCP server you may have running (e.g. the one in the DSL modem/router)

6. On the machine running dnsmasq: sudo /etc/init.d/dnsmasq restart

7. Restart the network interfaces on your devices (or just reboot the computer, phone or whatever)

8. Test that everything is as you expect. e.g. does ping nero work? Does ping nero.home.localdomain work?

9. Done

The example file:

domain-needed
bogus-priv
expand-hosts
domain=home.localdomain
dhcp-range=192.168.1.100,192.168.1.150,1h

dhcp-host=00:1b:62:01:e4:d5,192.168.0.24,nero
dhcp-host=00:1c:f0:06:25:ca,192.168.0.25,see
dhcp-host=00:23:76:cd:a7:9a,192.168.0.26,rome
dhcp-host=00:14:a6:2d:a7:9a,192.168.0.27,burn

dhcp-option=option:router,192.168.0.1
dhcp-option=option:domain-name,home.localdomain

Microsoft wants to "help" with SVG

So, Microsoft suddenly takes an interest in the SVG standard:

Slashdot Technology Story | Microsoft Wants To Participate In SVG Development

This feels horribly familiar.

Microsoft 'helped' the Oasis group with the ODF standard by submitting proposals (which mysteriously were never put forward by Microsoft to be actually voted upon) and delaying the completion of the ODF specification. Once it was obvious ODF would be an ISO standard Microsoft abandoned the Oasis ODF project and, surprise, out of the blue submitted their very own MOO-XML proposal on an express track to being a ISO standard which they pursued by corrupting the standards process itself. So we now have two ISO document format standards, the open ODF and the Microsoft MOO-XML and a discredited ISO. Brilliant.

Is this recent SVG move by Microsoft the first part of a similar campaign? Up until now Microsoft have ignored or tried to talk down SVG. Having failed to kill it with marketing muscle, are Microsoft moving into a more active SVG killing mode? I would not be at all surprised.

Of course, Microsoft could just start using and supporting valid SVG without trying to meddle with the specification. That would be a positive thing.