Apparently Peter Henderson’s 1982 paper “Purely Functional Operating Systems” is hard to find
online. Some years ago, during my PhD research, I scanned the paper from a physical copy in the
university library. Here’s the scan I made.
The tool is great, but it uses perf to record and analyze profile
data, and
perf on Debian has a performance problem:
when not linked against libbfd, it shells out to addr2line for
every address it needs to look up. Thousands and thousands and
thousands of incredibly short-lived processes.
A big part of the change is to fix the confusing terminology used in
the project. From now on, I’ll try to stick to the following:
Syndicated actors, and the Syndicated Actor model: Like regular
actors, but with replicated state, i.e. assertions connecting peers
rather than just messages.
The notion of a dataspace: A particular kind of behaviour of a
syndicated actor: tracks assertions made to it, and reacts to
assertions of interest by responding with previously-learned facts.
Structuring of a syndicated actor via conversational concurrency
and facets: Programming actors, syndicated or not, gets to be a
bit of a mess if you’re restricted to using a monolithic behaviour
function. Facets let you split up an actor’s behaviour into
reusable composable pieces. Conversational concurrency guides you
in how to carve it up.
Language support for syndicated actors and conversational
concurrency: the Syndicate DSL.
Back in October 2020, I built an on-screen keyboard for Squeak
Smalltalk. It ended up being about 230 lines
of code (!) in total.
I’ve been using Smalltalk as the primary UI for my experimental
cellphone software stack, and I needed a way to type input.
Using VNC to develop on the phone works fine, but
to work on the device itself - both for day-to-day phone tasks as well
as developing the system - I need a proper on-device keyboard.
This video shows the keyboard in action. As you can see,
it’s not perfect! At one point I tapped ctrl while typing, leading
to an unexpected pop-up menu appearing.
But the basic idea is sound. (Aside: why aren’t there any Android
keyboards that are laid out like a PC keyboard, with punctuation in
the right place, etc.?)
The usual shortcuts like Alt-P for “print it”, Alt-D for “do it”
and Alt-I for “inspect it” all work for evaluating snippets of
Smalltalk interactively.
The keyboard integrates with my previously-written touchscreen support
code, with the red/blue/yellow modifier buttons affecting touches,
making them into simulated left-/middle-/right-clicks, and with
keyboard focus changes auto-popping-up and -down the keyboard.
Simulating mouse clicks is a temporary state of affairs that lets me
use the touchscreen reasonably naturally, making use of context menus
and so on, without having to make invasive changes to the input
pipeline of Squeak’s
Morphic.
How it works
Class OnScreenKeyboardMorph synthesizes keyboard events and injects
them into the Morphic world.
You can have arbitrarily many keyboards
instantiated, but there’s a global one living in a
flap at the bottom of the
screen. That’s the blue tab at the bottom left of the screen you can
see in the video.
I had already written code to read from /dev/input/eventN,
tracking each multitouch contact separately. A subclass of HandMorph
overrides newKeyboardFocus: to pop the keyboard up and down as the
keyboard focus comes and goes:
Each key is represented by an OnScreenKeyMorph. It tracks keyboard
shift state by registering as a dependent of the
OnScreenKeyboardMorph:
The important part, of course, is the mouse event handler for
OnScreenKeyMorph:
The only other interesting part is the keyboard initialization
routine, which builds the layout:
The rest is book-keeping and simple delegation methods, like this:
and so on.
I haven’t released the whole package yet, because it’s all very much
in flux, but if you’re interested, you can take a look at the
changeset for the Keyboard-related code here:
LinuxIO-Morphic-KeyboardMorph.st
UPDATE: Full code available at
this gist
(also embedded below).
Say you have the following
TypeScript interface I that you
want to invoke remotely by passing messages of type M; or that you
receive messages of type M and want to handle them using an object
of type I:
Keeping things type-safe looks really tedious! There’s obviously a
connection between I and M. Can we avoid writing them by hand?
TL;DR TypeScript lets us define generic types Messages and
Methods such that M = Messages<I> and I = Methods<M>. Read on
for the details.
Interface ⟶ Messages
Let’s start with what, for me, has been the common case: given an
interface type, automatically produce the type of messages that can be
sent to implementors of the interface.
First, how do we want to represent messages?
I’ve taken a leaf out of Smalltalk’s book, and made a message include
a selector, the name of the method the message intends to invoke,
and some args, the provided arguments to the method. The Args
extends never[] check is to help type inference deduce the empty
argument tuple: without it, the type system won’t complain about
missing arguments.
I’ve also added a callback to Message. The technique I describe
here can be further extended to “asynchronous” or callbackless
settings with minor modifications.
The next definition, of type Messages<I>, is where the magic
happens. It expands to a union of Messages representing the methods
defined in I:
And that’s it! Here’s how it works:
MessagesProduct is a mapped type that describes a modified
interface, where all (and only) the method properties of interface
I are rewritten to have a Message as their type, but keeping
the same key;
then, the ...[keyof I] part in the definition of Messages uses
index types to set up a union type built from all
the value types (“indexed access operator”) associated with all the
keys in I (“index type query operator”).
Messages ⟶ Interface
Going in the other direction is simpler:
It’s a mapped type, again, that maps union members that have
Message type to an appropriate function signature. It takes
advantage of TypeScript’s automatic distributivity: a union of
products gets rewritten to be a product of unions. Then, in the
conditional typeM extends Message<...> ? ..., it projects out
just exactly the member of interest again.2
This time we use the mapped type as-is instead of re-projecting it
into a union using indexed access like we did with MessagesProduct
above.
Type-safe interpretation of messages
Now we have types for our interfaces, and types for the messages that
match them, can we write a type-safe generic perform function? Yes,
we can!
An example
Given the above definition for I, actually using Messages<I>
produces the following type definition3 (according
to the IDE that I use):
Conversely, given the M from the top of the file, we get the
following for Methods<M>:
Roundtripping works too: both Methods<Messages<I>> and
Messages<Methods<M>> give what you expect.
TypeScript is really cool
It’s a fully-fledged, ergonomic realization of the research started by
Sam Tobin-Hochstadt, who invented
Occurrence Typing,
the technology at the heart of TypeScript.
Then, building on the language itself, emacs with
tide,
flycheck, and
company makes for a very pleasant
IDE.4
Congratulations to Sam, whose ideas really have worked out amazingly
well, and to the TypeScript team for producing such a polished and
pleasant language.
Appendix: Full code implementing this idea
This module implements the idea described in this article, extended
with the notion of EventMessages, which don’t have a callback.
Well, at least in TypeScript v4.x, anyway. I
don’t know about earlier versions. ↩
Actually I’ll admit to not being quite sure that
this is what’s really going on here. TypeScript’s unions feel a
bit murky: there’s been more than one occasion I’ve been surprised
at what a union-of-products has been automatically “simplified”
(?) into. ↩
Hey, what’s going on with those named tuple
slots? I would have expected a tuple type like [number, string]
not to be able to have names attached to the slots, but it turns
out I’m wrong and the compiler at least internally propagates
names in some circumstances! It even re-uses them if you convert a
Messages<I> back into an interface, Methods<Messages<I>>… ↩
Here’s my .emacs TypeScript setup, based on the examples in the tide manual:
Recently on HN,
rbanffy brought up a form of the old chestnut about crashing the
image by simply executing true become: false.
It turns out it’s no longer true!
In the latest Squeak,
doesn’t work – the compiler complains that you can’t assign into a
read-only variable. So let’s try this:
But now the metaprogramming system complains you’re trying to modify a
read-only binding! So we view source on ClassBinding»value:, and see
that a resumable exception is being used to guard the modification, so
let’s explicitly signal that we really want to modify that
binding:
Finally! Now, evaluating True yields False.
But the image keeps running! Use of the literal class True seems to
be rare enough that things are OK for at least several minutes after
the change.
Doing this, however, definitely should immediately torpedo things:
… huh. It didn’t work. It used to! Again, on this current Squeak
version, we see a different behaviour. This time, it says Cannot
execute #elementsExchangeIdentityWith: on read-only object #(false).
So we’ll have to try harder:
That doesn’t work either! Same error as for #become:.
Welp, I’m actually all out of ways to crash this modern image in
analogous ways to the easy pitfalls of images of yesteryear…
P.S. Running the following command,
analogous to True := False, definitely does have an analogous
effect on a similarly-“alive” Unix image :-) . I just tried it on a
scratch VM; the results are pretty intimidating!
One lovely thing about working in Smalltalk is the effortlessness of
development.
I started off developing the code on my desktop machine, and
occasionally testing it on the phone itself. I just rsync the image
and changes files back and forth. This lets me pick up exactly where I
left off on the other device each time I move over.
However, developing on the phone was challenging because of the lack
of a keyboard (though I’ll post soon about an on-screen keyboard I’ve
written). So I installed RFB (from
here) into my image on the desktop,
and tested it. Then I saved the image and rsynced it to the phone as
usual, and presto, I can develop and test interactively on the phone
itself:
Using VNC to develop on the phone itself
There were a couple of things I had to do to get this to work:
As I’ve been working on a mobile Smalltalk system, I’ve found myself needing to decode
and encode a number of complex telephony packet
formats1 such as the following, an incoming SMS
delivery message containing an SMS-DELIVER TPDU in
GSM 03.40 format,
containing seven-bit (!)
GSM 03.38-encoded text:
It turns out there are a plethora of such binary formats needed to
get a working cellphone.
I started off hand-rolling them, but it quickly became too much, so
I borrowed liberallystole from Erlang, and implemented
BitSyntax for Smalltalk. (After all, I am
already using
Erlang-influenced actors for
the Smalltalk system daemons!)
The BitSyntax package includes a BitSyntaxCompiler class which
interprets BitSyntaxSpecification objects, producing reasonably
efficient Smalltalk for decoding and encoding binary structures,
mapping from bytes to instance variables and back again.
The interface to the compiled code is simple. After compiling a
BitSyntaxSpecification for the data format above, we can analyze the
example message straightforwardly:
and, if we wish, serialize it again:
How does it work?
Syntax specifications are built using an embedded domain-specific
language (EDSL).
For example, for the above data format, we would supply the following
spec for class SmsIncoming:
along with appropriate specs for SmsAddress and SmsPdu (omitted
for space reasons here) and the following for the SmsPdu subclass
SmsPduDeliver:
These are non-trivial examples; the simple cases are simple, and the
complex cases are usually possible to express without having to write
code by hand. The EDSL is extensible, so more combinators and parser
types can be easily added as the need arises.
The package BitSyntax-Help contains an extensive manual written for
Squeak’s built-in documentation system.
Enjoy!
Telephony packet formats are particularly
squirrelly in places. Seven-bit text encoding? Really? Multiple
ways to encode phone numbers. Lengths sometimes in octets,
sometimes in half-octets, sometimes in septets (!) with padding
implicit. Occasional eight-bit data shoehorned into a septet-based
section of a message. Bit fields everywhere. Everything is an
acronym, cross-referenced to yet another document. Looking at the
3GPP and GSM specs gave me flashbacks to the last time I worked in
telephony, nearly 20 years ago… ↩
Today I noticed that the keyboard on my 2013-vintage Acer C720
chromebook was visibly curved, being pushed up from below by the
battery, which had swollen enormously.
This can be really dangerous, so I took the back off the machine and
removed the battery. Here’s what it looks like: