Some recent updates to the system:
1. Realtalk is networked. Statements made on one host can be observed on all other hosts.
2. The server is in Realtalk. db.local, currently in the closet, is running both the Realtalk database and a Realtalk host running real pages.
3. External programs can dial in. Via a websocket, a laptop or web browser can observe and make Realtalk statements.
4. A lot of cruft has been cleaned up. No more patching through the shared folder, post-frame functions, diagnostic functions, HTTP APIs, shell scripts....
---- ---- ---- ---- ---- ---- ---- ---- ---- ----
1. Realtalk is networked.
The Realtalk kernel used to implement a global convergence scheme, where hosts would offer and exchange statements until they all converged. That's been removed and replaced with a simple asynchronous protocol where the database just holds on to the latest statement set from each host, and will tell it to you if you ask.
- A host says "make statements" to send the database its latest set of statements.
- A host says "get statements" to receive a map from the database with the latest set of statements for each host.
This is tick:
function tick (frame_count)
-- If new statements have arrived from other hosts, fold them into the frame.
receive_remote_statements(unstable_frame)
-- Update the claims about the current time.
update_time_statements(unstable_frame, frame_count)
-- Run until nothing changes.
converge_frame(unstable_frame)
-- Send the database our current statements, and request to receive an update.
send_remote_statements()
-- The unstable frame is now stable.
update_stable_frame_to_match_unstable_frame()
-- Loop forever.
return tick(frame_count + 1)
end
Because we're still locally converging, a host's stable frame will always be consistent within its own zone, but might be inconsistent when looking across other zones.
"send_remote_statements" currently shares just a subset of statements. You can get your statements out either by object:
Wish (processor) shares statements from (you).
or by relation:
Wish (processor) shares statements with relation "_ claims _ is a good boy.".
Someday everybody will share everything, but we haven't been designing with that in mind so far, so it's currently opt-in. The goal here was just to get the technical underpinnings in place for networking, so we can start experimenting with it and figure out a good language for working with remote objects.
One useful hack is
Wish (you) is everywhere.
which makes every processor want to run programs on you, which makes you appear as a "ghost page" (formerly knows as "the boot") in every zone, which is handy for blasting Bizarre Love Triangle throughout the entire space.
2. The server is in Realtalk.
There used to be a standalone server.lua running on db.local, which implemented a REST API for patching and printing pages. That's gone.
Now, db.local is running the Realtalk database, which routes values between hosts, and also running an honest-to-goodness Realtalk host. This "server" host is running a somewhat different set of ghost pages than a normal realbox -- none of the engine or illumination stuff, but a handful of special pages:
Recognize Ghost Pages claims that all the pages on the whiteboard exist, and lets you wish that they're different. (This wish replaces "editing the boot".)
Page Text notices claims about page numbers, and claims that pages have text, patched text, and active text. You can also wish for a different active text, and it will patch the page.
Printing New Pages notices wishes to print. You can print pages or raw postscript.
Web Server hosts webpages, and also has the rtjson functionality of being able to peek at Realtalk refs. (Yes, http://db.local is being served from the wall!)
Websocket Gateway allows external clients to "dial in" to the Realtalk system. More on this below.
/rt.js and /editor.html are the Javascript websocket client library and the web editor, respectively. They are of the form:
local text = [=[
<html> etc...
</html>
]=]
Wish web server serves (text) at "/editor.html".
That is, they wish for a block of text to be served at a particular URL. This is how we host web pages from the wall.
3. External programs can dial in.
The server upshot is, there are no longer HTTP endpoints to do things like patch, print, etc. Now you just wish for stuff. And if you're outside the Realtalk network, you dial into the Realtalk network and wish for stuff. It's statements all the way down.
A client currently dials in via websocket. The client connects to the websocket and subscribes to a set of relations, and gets sent updates when statements with those relations change. The client can also make statements of their own.
The web editor thus works just like the in-world editor -- they both notice claims about pages and text, and they make exactly the same wishes to print and save.
The websocket server library seems flaky, but we can add other ways of dialing in that work in a similar way.
4. A lot of cruft has been cleaned up.
As a result, we're now 100+ FPS when not much is happening, and usually 60+ FPS even under reasonable load.
Post-frame functions are gone. We use past tense now (to refer to the stable frame).
There was a lot of diagnostic and timing stuff which seemed stale, so it was all swept away. We can add back in diagnostics as we need them (maybe just by live-editing the system).
It used to be that page text and patches were transmitted through the shared folder. Now, the Page Text page on the server is the only one that directly accesses those files, and everyone else gets their text from it over the network. Patching (in all editors) is now instantaneous. The shared folder is still there for sharing sounds and video.
There used to be a menagerie of shell scripts for running and stopping the system in various ways from the command line. That's all been subsumed into a single "run.lua" script (with a menagerie of options), which is... on the wall! This also subsumes some of the Linux configuration -- there is just a single systemd service which runs "run.lua login" at login, and that's what takes care of mounting the shared folder, starting X and jack and the Realtalk db and shared folder backups, restarting things when they crash, etc.
rtlight3, Reatalk's Linuxy life-support system, is gone. Luke and I refactored it into the "rtengine" Lua library, the "realbox-setup" directory, and the "run.lua" script. The home directory of a Realbox is now just:
~/
run.lua -- start and stop the system (autogenerated from a page)
boot.lua -- bootloader (autogenerated by a page)
config.json -- projector/camera configuration (autogenerated by engine)
realtalk/ -- Realtalk kernel library
rtlua/ -- Lua interpreter and vendor libraries
rtengine/ -- camera and projector library
rtaudio/ -- audio library
realbox-setup/ -- misc scripts for unix things
log/ -- stdout+stderr from everything
shared/ -- cat videos