Ted Blackman 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

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

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:

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
a "keep only N recent epochs" command, which removes all epoch folders older than that

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

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,

	\|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

	=>
	\|%
	+$ 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
	::

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