belisarius222

 |pass &noun
 :-  %k  %lard  %base  !<  shed:khan
 %+  slap  (slop .^(vase %ca %/lib/strandio/hoon) !>(..zuse))
 !,  *hoon
 =*  strandio  -
 =,  strand=strand:rand
^-  shed:khan
=/  m  (strand ,vase)
|-  ^-  form:m
;<  =bowl:rand  bind:m  get-bowl:strandio

belisarius222

=>
|%
+$  ulam
  $~  [%coin *coin]
  ::  leaves
  ::
  $%  [%coin =coin]                            ::  atom, noun, or compound coin
      [%path =pith]                            ::  hoon path syntax
      [%page =mark noun=*]                     ::  %foo|bar, bar is coin blob
  ::

belisarius222

• Apps that use JSON will need to drop compatibility for 414 and older Kelvins by default. The old %json mark from 414 will not compile on 413, and this will not be caught at build time.
  • Make sure the %json mark file in your app desk compiles on 413, and test your %json mark conversions to make sure they don't crash at runtime due to this change.
  • The json (de)serialization interface changed and is only backwards-compatible at the outermost layer (+en-json, +de-json). apex:de-json:html, part of the JSON parser internals, isn't there any more.
• A number of arms and new tasks and gifts were added to Lull and Zuse.
  • These should not cause any issues unless your app code was expecting something very specific, such as if you were doing metaprogramming on Lull or Zuse (e.g. Pyro).
• The %gall scry namespace has been changed:
  • %gu, to check if an app is an running, has a new path format:
    • old: .^(? %gu /=dojo=)
    • new: .^(? %gu /=dojo=/$)
• Similar changes were made

belisarius222

/+  default-agent, verb, dbug
::
|%
+$  poke
  $%  [%grow =case =spur =noun]
      [%tomb =case =spur]
      [%cull =case =spur]
  ==
--
::

belisarius222

How to Upgrade your App to Zuse 414k

This Kelvin requires more work to update than some previous Kelvins because the $foam type was deleted from Lull. This means if your app imports the full base-dev folder as a dependency the way most apps do and your app imports /sur/hood/hoon (as a lot of apps do), you will need to update that dependency for 414 by copying in the most recent files, and also drop support for older Kelvins by deleting their entries from /sys/kelvin and replacing them all with just [%zuse 414]. If your app does not have any files that import /sur/hood/hoon with Ford runes, you might be able to support 414 and 415 without modifying code -- if so, please test your app to be sure.

Note that Clay can still handle later commits targeted at 415, so as an app dev, you can maintain both 414 and 415 -- the constraint is that each commit to your app desk can only support one or the other if you are using the standard /sur/hood/hoon. Supporting both in the same stream of commits to

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

There was some productive discussion this week about the remote scry protocol. Ideally, we wouldn't need any session-based protocol to ensure low latency on responses to scry requests whose paths haven't been bound yet when the publisher receives the request, and the basic protocol would handle this. The following is a sketch of a way to do this, by making scry requests for paths that are known to be part of publications "sticky" on the publisher, so they persist long enough that when the path does get grown, the response can be sent down to requesters immediately.

Subscriber sends scry request to publisher ship asking for wave n+1 of some subscription. Only waves up through n have been published, and n+1 doesn't exist yet. The publisher's Arvo had told its Vere that it will notify Vere whenever new paths are grown under a certain set of path prefixes. Since the publisher Gall is managing the publication in question (along with all other publications), it included the publication path in this list

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

I just realized we should be able to delete gall's outstanding request queue entirely -- but we probably don't want to do that now, since the migration might be hairy
we could do this now because pokes and watches can never share the same flow
so there's no need for gall to maintain state to disambiguate them
we would need to collapse the foreign sending down to a single-step move, instead of a stack of two wires
so instead of gall passing a move to itself, then passing a move to ames,
gall would need to see the %watch, %leave, or %poke come out of the agent, then fire it off to ames with a wire that says whether it was a subscription or poke
a subscription wire would also need to say which foreign ship, agent, and path we're subscribing to (or unsubscribing from), and contain the subscription nonce
a poke wire would just need the foreign ship and wire the agent set, I believe
I'm not sure how we would migrate to this, especially for the poke case -- for subscriptions, we could potentially kill all existing s

belisarius222

libames

It should be possible to build apps outside Urbit that communicate with Urbits using the Ames protocol. For this to work, we need an implementation of Ames written in an Earth language that other Earth programs can easily embed. Languages that might be embeddable enough include Lua, Zig, Rust, Chez Scheme, Guile, and of course C itself.

This project will be broken into four major milestones:

• moon-specific: can only talk to sponsoring planet, no persistence
• persistent: writes packets to disk to work across moon restarts
• universal: can pretend to be any ship and talk to any ship, tracks azimuth
• portable: can run on Windows and MacOS, not just Linux