Last post for today! Now that the protocol specification, the Synit website, the Synit manual, and the Synit codebase are all published and live, the final piece of the puzzle is the SqueakPhone codebase.

Getting the code

It comes in two parts:

• a git-based piece, at https://git.syndicate-lang.org/tonyg/squeak-phone, and
• a Monticello-based piece, at https://squeaksource.com/SqueakPhone.html.

Follow the instructions in the README to give it a try.

It’s quite likely the instructions are not detailed enough, or that I’ve accidentally left the code in a “works on my machine but only on my machine” state, so if you try it out and it doesn’t work, or you have questions, please stop by on IRC or just email me directly.

I’m really pleased to announce the first public release of Synit. From the site:

Synit is an experiment in applying pervasive reactivity and object capabilities to the System Layer of an operating system for personal computers, including laptops, desktops, and mobile phones. Its architecture follows the principles of the Syndicated Actor Model.

Synit is the foundation of the squeak-on-a-cellphone system-layer experiment I’ve been working on for the past year or so.

To go along with the software, there’s a draft manual, including

• an essay giving a good overview of the Syndicated Actor Model;

• a Syndicated Actor Model glossary;

• a quick description of the architecture of the system;

• the protocol specification that I just announced;

• and more.

Come hang out on IRC! Or, just email me directly.

I’ve just published the first public draft of the Syndicate Network Protocol specification.

It has already been implemented for Rust, TypeScript, Python 3, Racket and Squeak: see the implementations page.

Feedback, comments, and criticism very welcome! Just email me.

Patrick Dubroy recently posted an interesting challenge problem:

The goal is to implement a square that you can either drag and drop, or click. The code should distinguish between the two gestures: a click shouldn’t just be treated as a drop with no drag. Finally, when you’re dragging, pressing escape should abort the drag and reset the object back to its original position.

In his post, he gives three solutions. A few days later, Francisco Sant’Anna posted an additional take on the problem using Céu. Later still, Francisco wrote another post comparing and contrasting various approaches to concurrency including Céu and Martin Sústrik’s idea of Structured Concurrency.

Since Syndicate is similar both to Structured Concurrency and to synchronous languages like Céu, Francisco’s post was enough for me to get around to trying to solve Patrick’s challenge problem using Syndicate.

Drag, Click or Cancel in Syndicate/js

I’ve put a complete project up here; you can clone it with

1
git clone https://git.syndicate-lang.org/tonyg/dubroy-user-input

You can try the program out by clicking here.

The interesting bit is the part that implements the main state machine, function awaitClick, so in the rest of this post I’ll look into that in some detail. To see how the whole program hangs together, visit the index.ts file in the git repository.

Each state is represented as a Syndicate facet. We kick things off with

1
2
3
react {
    awaitClick('Waiting');
}

which enters a fresh facet and sets up its behaviour using awaitClick:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
function awaitClick(status: string) {
    assert Status(status);
    on message Mouse('down', $dX: number, $dY: number) => {
        if (inBounds(dX - x.value, dY - y.value)) {
            stop {
                react {
                    assert Status('Intermediate');
                    const [oX, oY] = [x.value, y.value];
                    stop on message Mouse('up', _, _) => react {
                        awaitClick('Clicked!');
                    }
                    stop on message Key('Escape') => react {
                        awaitClick('Cancelled!');
                    }
                    stop on message Mouse('move', $nX: number, $nY: number) => react {
                        assert Status('Dragging');
                        stop on message Mouse('up', _, _) => react {
                            awaitClick('Dragged!');
                        }
                        stop on message Key('Escape') => react {
                            [x.value, y.value] = [oX, oY];
                            awaitClick('Cancelled!');
                        }
                        [x.value, y.value] = [oX + nX - dX, oY + nY - dY];
                        on message Mouse('move', $nX: number, $nY: number) => {
                            [x.value, y.value] = [oX + nX - dX, oY + nY - dY];
                        }
                    }
                }
            }
        }
    }
}

When the mouse button is pressed (line 3), if the press is inside the square (line 4), we transition (lines 5–6) to a new state (lines 7–28).

This “intermediate” state is responsible for disambiguating clicks and drags. If we get a mouse up event, we transition back to waiting for a click (lines 9–11). If we get an Escape keypress, we do the same (lines 12–14). If we get some mouse motion, however, we transition (line 15) to a third state (lines 16–27).

This “drag” state tracks the mouse as it moves (lines 24–27). If the mouse button is released, we go back to waiting for a click (lines 17–19). If Escape is pressed (lines 20–23), we transition back to awaitClick state after resetting the square’s position (line 21).

Syndicate dataflow variables hook up changes to x.value and y.value to the position of the square (see here in the full program), and the Status(...) assertions are reflected onto the screen by a little auxiliary actor (here in the full program).

The idiom

1
stop on <Event> => react { ... }

seen on lines 9, 12, 15, 17, and 20, acts as a state transition: the stop keyword causes the active facet to terminate when the event is received, and the react statement after => enters a new state.¹

And that’s it! Hopefully I’ve managed to convey the idea.

I considered a few variations on this implementation as I was writing it. Originally, I omitted lines 12–14 above, because I read the specification as requiring a response to Escape only within a drag, not the intermediate state before it’s known whether a press corresponds to a click or a drag. Another variation was less state-machine-like and more statechart-like, with Escape handling in an outer state and mouse handling in a pair of inner states, but it wasn’t quite as clear as the variation above.

I’ve just released SyndicatedActors, a package for Squeak Smalltalk that implements the Syndicated Actor Model.

You can get it from the project page on SqueakSource:

• https://squeaksource.com/SyndicatedActors.html

The code depends on the Preserves and BTree-Collections support packages. Preserves is available from its SqueakSource project page, and BTree-Collections is included in the SyndicatedActors project.

To do all these installation steps from within a running Squeak image:

1
2
3
4
5
Installer ss project: 'Preserves';
    install: 'Preserves'.
Installer ss project: 'SyndicatedActors';
    install: 'BTree-Collections';
    install: 'SyndicatedActors'.

Happy New Year!

I’ve been using the PinePhone 1.2 to develop synit recently. I haven’t done anything about power management or sleeping yet, and I wondered how bad the battery life might be, so last night I ran the following script from a full battery until the phone shut down from lack of power:

1
2
3
4
5
6
7
while true
do
    date
    cat /sys/class/power_supply/axp20x-battery/capacity
    sleep 60
    sync
done | tee -a battery-rundown-log

Here is the resulting discharge curve (data):

Before running the script, I turned off the display and backlight,

1
2
3
4
5
6
# Puts the framebuffer in "graphics" mode, disabling touchscreen 
# sensitivity and "screen saver" mode
echo 1 | sudo tee /sys/class/graphics/fb0/state

# Actually blanks the screen, shutting down the graphics pipeline
echo 3 | sudo tee /sys/class/graphics/fb0/blank

and almost nothing was running on the phone: normal system daemons (udevd, syslogd, dbus-daemon, haveged, chronyd), wifi support (wpa_supplicant and NetworkManager), modem support (eg25-manager and gpsd), sshd, and a lone getty.

This, then, is about as good as we might reasonably expect from an idle system, with its display blanked, that never goes into sleep mode: around ten or eleven hours of battery life.

Putting the phone into sleep mode should significantly extend the battery life.

I plan on running Squeak Smalltalk for the user interface, and I suspect that there’ll be a fair amount of power draw as a result of that, so it seems likely I’ll have to investigate putting the phone into sleep mode.

Lots and lots has happened since the last update!

The big-ticket items each get a blog post of their own:

• Preserves Path, a new query language for Preserves data
• Rust Preserves v1.0.0 released
• Internal flow control within message brokers
• Common Syndicate protocols in a separate repository
• Syndicated Actors for Rust, including a new implementation of the Syndicate dataspace server daemon
• Syndicated Actors for Python 3
• Syndicated Actors for Bash (Yes, really! 🙂)
• Progress on Syndicate-at-the-System-Layer

I’ve been making good progress on my current overarching project, Structuring the System Layer with Dataspaces.

I’ve written a few scripts to create an initrd from Alpine Linux packages (based on my experience working for the FRμIT testbed project), with a custom init script that installs the system onto a (virtual) hard disk and configures it for booting.

The second-stage init is just syndicate-server, configured to start system services that self-assemble into the correct startup ordering as a result of monitoring their dependencies using assertions in the dataspace.

I’ve also been studying the various pieces of existing system layers (like s6, systemd, SysV init, inetd and so on) to try to map the design landscape a bit.

In addition, I’ve explored use of PF_NETLINK sockets to subscribe to kernel-originated device plug-and-play events (like udev does). It seems straightforward.

The things I’ve written as a result of all this aren’t quite ready for public viewing yet. I’ll post again when the repository is available.

Implementing a quality message broker involves quite a bit of subtlety. Dealing with high-speed message publication, where either the server, downstream consumers, or both can become overloaded can be especially challenging.

These were problems that faced me when I was putting together the first versions of the RabbitMQ server, and the same issues crop up in servers that speak the Syndicate network protocol, too.

I recently came up with a really interesting and apparently effective approach to internal flow control while working on syndicate-server.

The idea is to associate all activity with an account that records how much outstanding work the server has left to do to fully complete processing of that activity.

• Actors reading from e.g. network sockets call an ensure_clear_funds function on their associated Accounts. This will suspend the reader until enough of the account’s “debt” has been “cleared”. This will in turn cause the TCP socket’s read buffers to fill up and the TCP window to close, which will throttle upstream senders.

• Every time an actor (in particular, actors triggered by data from sockets) sends an event to some other actor, a LoanedItem is constructed which “borrows” some credit from the sending actor’s nominated account.

• Every time a LoanedItem is completely processed (in the Rust implementation, when it is dropped), its cost is “repaid” to its associated account.

• But crucially, when an actor is responding to an event by sending more events, it charges the sent events to the account associated with the triggering event. This lets the server automatically account for fan-out of events.¹

Example. Imagine an actor A receiving publications from a TCP/IP socket. If it ever “owes” more than, say, 5 units of cost on its account, it stops reading from its socket until its debt decreases. Each message it forwards on to another actor costs it 1 unit. Say a given incoming message M is routed to a dataspace actor D (thereby charging A’s account 1 unit), where it results in nine outbound events M′ to peer actors O1···O9.

Then, when D receives M, 1 unit is repaid to A’s account. When D sends M′ on to each of O1···O9, 1 unit is charged to A’s account, resulting in a total of 9 units charged. At this point in time, A’s account has had net +1−1+9 = 9 units withdrawn from it as a result of M’s processing.

Imagine now that all of O1···O9 are busy with other work. Then, next time around A’s main loop, A notices that its outstanding debt is higher than its configured threshold, and stops reading from its socket. As each of O1···O9 eventually gets around to processing its copy of M′, it repays the associated 1 unit to A’s account.² Eventually, A’s account drops below the threshold, A is woken up, and it resumes reading from its socket.  □

Anecdotally, this appears to work well. Experimenting with producers sending as quickly as they can, producers are throttled by the server, and the server seems stable even though its consumers are not able to keep up with the unthrottled send rate of each producer.

It’ll be interesting to see how it does with other workloads!