verified using vim regex search (and corresponding regexes for the 3, 2,
and 1 letter motes):
/c3__\(.\)\(.\)\(.\)\(.\) *c3_s4\(('\1','\2','\3','\4')\)\@!
* master: (33 commits)
groups: updating glob and version
interface: use single sig in NotificationText
interface: fix subscription reconnect issues
landscape: fixing bad glob
landscape: updating glob and version
interface: adds `theme-color` meta tag, removes outdated safari web app meta tag
zuse: add missing assertions
landscape: cache marks again
zuse: comment clarifying sk bounds check
bounds-check against sk=1
zuse: style cleanup, use +rep/+end
pill: solid, brass
interface: refine joining error cases
group-view: fix errored rollback
helm: cleanup +poke-rekey to match #5522
helm: fix |rekey to work with multikey files
test: schnorr bounds checking
zuse: boundary assertions for schnorr
zuse: schnorr test cases
zuse: schnorr address
...
nara: swedish for near, provides a trace from the start of the nearest virtualization
to the statement wrapped by the nara hint.
hela: swedish for whole, provides a trace from the start of the event
to the statement wrapped by the hela hint.
The eventual goal is to present these traces in a way that is most salient & useful to developers
and in a way that is aesthetically pleasing as the bout hint is useful and nice looking.
For this pull request the goal is to provide the actual functionality in code that we can feel
safe and comfortable adding to the master branch. To this end, I've added a trivial set of tests for
nara and hela in pkg/arvo/tests/run/hints.hoon - they only prove that invoking these hints will not
crash the runtime, but I'm open to ideas for how I can test these hints further.
The `ProfileOverlay` component expects a `ship` arg as a patp without the sig. This deSigs the ship value used in `NotificationText`.
This closesurbit/landscape#1376
the full type output by vars is now:
(list [cord (list [cord (list [cord @])])])
it's a mouthful, but a consistent mouthful. the first layer of the list
is the IO driver name, nam_m. the second layer is the instance name,
either %all or some driver-relevant identifier (e.g. http instance.) the
third layer is the list of labels and values.
This actually raises difficult questions about the schema for the /vars
peel. One level of nesting makes sense to aggregate per IO driver, but
multiple levels is confusing.
The current output is extremely unprincipled: you just have to know that
there are multiple http servers and handle the output accordingly.
Options would be:
1. collapse the ambiguity to the top level, i.e. 'http-0i8080',
'http-global', etc.
2. collapse the ambiguity to the inner level, i.e. '0i8080-connections'.
3. create a proper recursive data type that e.g. uses an $each.
3b. send some kind of schema.
5. recognize that we have entered a terrifying hall of mirrors and back
out the entire approach of nested metrics in favor of just a bigass
flat list of labels with values like borgmon does.
