Quodss

Mass update report

Introduction

A few months ago I started working on mass modernization project to learn about Arvo and Vere and to contribute to the core development. Since then I had some success working on WebAssembly interpreter, and I decided that it would be wise to focus my attention on that project instead.

I managed to achieve the first milestone outlined in the grant proposal. To ensure my efforts don't go in vain I will describe what I achieved and learned while working on that milestone.

Target audience

tiller-tolbus

%fleet specification

%fleet is an Urbit application for monitoring a set of sponsored ships. It is intended to be run on a ship that is providing value-added sponsor services to other running ships. The primary target audience is stars performing planet services, although it should in principle be useful for galaxies performing star services, as well as planets performing moon services.

%fleet initializes by collecting a set of residents on the host ship from Ethereum and Jael. Periodically, it checks to ensure that the set is up to date. Upon each refresh, new residents are added, and former residents are removed from this set. This “refresh” should occur at least once per hour, and even more frequently if performance allows.

%fleet will automatically monitor the uptime of each ship in its set. Similar to ~midden-fabler/ahoy, it will track the amount of time since the last heartbeat from each ship. If the time since last heartbeat exceeds a specified “heartbeat threshold”, %fleet will comman

belisarius222

• yes to epoch system
• each epoch has a version file, an initial snapshot, and an event log database file
• we will need to add code to vere to find the latest epoch folder before loading snapshot and event log
• there are two separable operations involved in truncation:

1. create new epoch, by copying snapshot into a new epoch folder, creating a new version file in that folder, and creating a new event log database file in that folder whose events db is empty and whose metadata db contains entries copied from the previous epoch's metadata db
2. a "keep only N recent epochs" command, which removes all epoch folders older than that

belisarius222

The best idea we have so far for parallel processing comes from ~master-morzod, and it's this:

You want to kick a long-running Nock computation (e.g. a call to the hoon compiler) out of the main event loop and run it in another thread so it doesn't block normal Arvo event processing while it's running. To do this, have Arvo store a $trap (a thunk, or unevaluated Nock expression), representing this computation, give it a number, and emit an effect to the runtime asking the runtime "please wake me up to run trap 37".

A naive runtime, upon seeing this effect, will just immediately enqueue an Arvo event asking Arvo "please run trap 37". This will defer execution of the trap until later, but it will still block the main loop.

A smart runtime doesn't immediately enqueue an Arvo event. Instead, it scrys into Arvo asking it for trap 37, and obtains the trap. It runs the trap in another thread (note that this requires adding basic multithreading support to the Nock interpreter). Once the computation completes,

belisarius222

Remote Scry Protocol Proposal

Overview

Despite Urbit's "scry" namespace being global (every request path contains the host ship), there is no way to query other ships. This proposal adds a second Urbit-to-Urbit network protocol that implements remote scrying. This will allow for ships to field read requests without incurring disk writes, and since the namespace is immutable, caching responses will be simple and worthwhile.

To "scry" in Urbit means to query the Urbit namespace. Conceptually, if a query resolves, it can produce either a piece of marked data (meaning tagged with a system-recognized type) or an empty result indicating that this path will never contain data. Not all requests resolve; some "block", which represents a refusal or inability to answer the question (such as a local query for a file at a future date). The namespace is immutable in the sense that all nonblocking results to the same query must be identical. Whether a query resolves is not specified; a query could succeed, the