@@ -54,14 +54,14 @@ use `u3m_soft_sure()`, `u3m_soft_slam()`, or `u3m_soft_nock()`
54for C functions, Hoon function calls, and Nock invocations.
54for C functions, Hoon function calls, and Nock invocations.
55Caution - this returns just the result, and asserts globally.
55Caution - this returns just the result, and asserts globally.
57−All the `u3m_soft` functions above work *only on the surface*.
57+All the `u3m_soft` functions above work **only on the surface**.
58Within the surface, virtualize with `u3m_soft_run()`. Note that
58Within the surface, virtualize with `u3m_soft_run()`. Note that
59this takes a `fly` (a namespace gate), thus activating the `11`
59this takes a `fly` (a namespace gate), thus activating the `11`
60super-operator in the nock virtualizer, `++mock`. When actually
60super-operator in the nock virtualizer, `++mock`. When actually
61using the `fly`, call `u3m_soft_esc()`. Don't do either unless
61using the `fly`, call `u3m_soft_esc()`. Don't do either unless
62you know what you're doing!
62you know what you're doing!
64−For descending into a subroad *without* Nock virtualization,
64+For descending into a subroad **without** Nock virtualization,
65use `u3m_hate()` and `u3m_love` respectively. Hating enters
65use `u3m_hate()` and `u3m_love` respectively. Hating enters
66a subroad; loving leaves it, copying out a product noun.
66a subroad; loving leaves it, copying out a product noun.
@@ -87,7 +87,7 @@ dumber than most) - `u3j` is the most interesting code in `u3`.
88Let's consider the minor miracle of driver-to-battery binding
88Let's consider the minor miracle of driver-to-battery binding
89which lets `u3j` work - and decrement not be `O(n)` - without
89which lets `u3j` work - and decrement not be `O(n)` - without
90−violating the precisely defined semantics of pure Nock, *ever*.
90+violating the precisely defined semantics of pure Nock, **ever**.
92It's easy to assume that jets represent an architectural coupling
92It's easy to assume that jets represent an architectural coupling
93between Hoon language semantics and Nock interpreter internals.
93between Hoon language semantics and Nock interpreter internals.
@@ -108,7 +108,7 @@ code]`, any high-level language transforming itself to Nock would
108use this design.
108use this design.
110So jets are in fact fully general. Broadly speaking, the jet
110So jets are in fact fully general. Broadly speaking, the jet
111−system works by matching a C *driver* to a battery. When the
111+system works by matching a C **driver** to a battery. When the
112battery is invoked with Nock operator `9`, it must be found in
112battery is invoked with Nock operator `9`, it must be found in
113associative memory and linked to its driver. Then we link the
113associative memory and linked to its driver. Then we link the
114formula axis of the operation (`a` in `[9 a b]`) to a specific
114formula axis of the operation (`a` in `[9 a b]`) to a specific
@@ -141,7 +141,7 @@ nock(+.a -.a)
141Then, naturally, when we go from Hoon or a high-level language
141Then, naturally, when we go from Hoon or a high-level language
142containing functions down to Nock, `[function arguments]` turns
142containing functions down to Nock, `[function arguments]` turns
143into `[formula subject]`. This seems like an obvious design, and
143into `[formula subject]`. This seems like an obvious design, and
144−we mention it only because it is *completely wrong*.
144+we mention it only because it is **completely wrong**.
146Rather, to execute a one-armed core like the above, we run
146Rather, to execute a one-armed core like the above, we run
@@ -250,7 +250,7 @@ in `j/tree.c`. The data structures:
250 } u3j_dash;
250 } u3j_dash;
253−Warm and cold state is *per road*. In other words, as we nest
253+Warm and cold state is **per road**. In other words, as we nest
254roads, we also nest jet state. The jet state in the road is:
254roads, we also nest jet state. The jet state in the road is:
@@ -330,7 +330,7 @@ we don't need (cleaning these things up is tricky), but just gets
330flattened into a term.
330flattened into a term.
332The parent axis is a nock formula, but always reduces to a simple
332The parent axis is a nock formula, but always reduces to a simple
333−axis, which is the address of this core's *parent*. Consider
333+axis, which is the address of this core's **parent**. Consider
334again an ordinary gate
334again an ordinary gate
@@ -340,13 +340,13 @@ again an ordinary gate
340Typically the `context` is itself a library core, which itself
340Typically the `context` is itself a library core, which itself
341has a jet binding. If so, the parent axis of this gate is `7`.
341has a jet binding. If so, the parent axis of this gate is `7`.
343−If the parent is already bound - and the parent *must* be already
343+If the parent is already bound - and the parent **must** be already
344bound, in this road or a road containing it - we can hook this core
344bound, in this road or a road containing it - we can hook this core
345bottom-up into a tree hierarchy. Normally the child core is
345bottom-up into a tree hierarchy. Normally the child core is
346produced by an arm of the parent core, so this is not a problem -
346produced by an arm of the parent core, so this is not a problem -
347we wouldn't have the child if we hadn't already made the parent.
347we wouldn't have the child if we hadn't already made the parent.
349−The clue also contains a list of *hooks*, named nock formulas on
349+The clue also contains a list of **hooks**, named nock formulas on
350the core. Usually these are arms, but they need not be. The
350the core. Usually these are arms, but they need not be. The
351point is that we often want to call a core from C, in a situation
351point is that we often want to call a core from C, in a situation
352where we have no type or other source information. A common case
352where we have no type or other source information. A common case
@@ -365,14 +365,14 @@ instance, if the core is a Hoon gate - a function - we will call
365### u3j: the cold jet dashboard
365### u3j: the cold jet dashboard
367For even more fun, the jet tree is not actually a tree of
367For even more fun, the jet tree is not actually a tree of
368−batteries. It's a tree of battery *labels*, where a label is
368+batteries. It's a tree of battery **labels**, where a label is
369an [axis term] path from the root of the tree. (At the root,
369an [axis term] path from the root of the tree. (At the root,
370if the core pattern is always followed properly, is a core whose
370if the core pattern is always followed properly, is a core whose
371payload is an atomic constant, conventionally the Hoon version.)
371payload is an atomic constant, conventionally the Hoon version.)
373Under each of these labels, it's normal to have an arbitrary
373Under each of these labels, it's normal to have an arbitrary
374number of different Nock batteries (not just multiple copies
374number of different Nock batteries (not just multiple copies
375−of the same noun, a situation we *do* strive to avoid). For
375+of the same noun, a situation we **do** strive to avoid). For
376instance, one might be compiled with debugging hints, one not.
376instance, one might be compiled with debugging hints, one not.
378We might even have changed the semantics of the battery without
378We might even have changed the semantics of the battery without
@@ -420,7 +420,7 @@ of information: the `++cope`, or per-location noun; and a map of
420batteries to a per-battery `++club`.
420batteries to a per-battery `++club`.
422The `cope` is a triple of `++bane` (battery name, right now just
422The `cope` is a triple of `++bane` (battery name, right now just
423−a `term`); `++axis`, the axis, within *this* core, of the parent;
423+a `term`); `++axis`, the axis, within **this** core, of the parent;
424and `(each bash noun)`, which is either `[0 bash]` if the parent
424and `(each bash noun)`, which is either `[0 bash]` if the parent
425is another core, or `[1 noun]`, for the constant noun (like
425is another core, or `[1 noun]`, for the constant noun (like
426`164`) if there is no parent core.
426`164`) if there is no parent core.
@@ -453,7 +453,7 @@ validate with a single comparison. Otherwise, we have to recurse
453upward by checking the parent.
453upward by checking the parent.
455Note that there is at present no way to force a jet to depend on
455Note that there is at present no way to force a jet to depend on
456−static *data*.
456+static **data**.
458### u3j: the warm jet dashboard
458### u3j: the warm jet dashboard
@@ -519,7 +519,7 @@ in the `u3j_harm` which tell us how to call the arm function.
520If `ice` is yes (`&`, `0`), the jet is known to be perfect and we
520If `ice` is yes (`&`, `0`), the jet is known to be perfect and we
521can just trust the product of `fun_f`. Otherwise, we need to run
521can just trust the product of `fun_f`. Otherwise, we need to run
522−*both* the Nock arm and `fun_f`, and compare their results.
522+**both** the Nock arm and `fun_f`, and compare their results.
524(Note that while executing the C side of this test, we have to
524(Note that while executing the C side of this test, we have to
525set `ice` to yes; on the Nock side, we have to set `liv` to no.
525set `ice` to yes; on the Nock side, we have to set `liv` to no.
@@ -531,9 +531,9 @@ test is on the outermost layer of recursion.)
531environment has a slight locking problem with these flags if arm
531environment has a slight locking problem with these flags if arm
532testing is multi-threaded.)
532testing is multi-threaded.)
534−If `tot` is yes, (`&`, `0`), the arm function is *total* and has
534+If `tot` is yes, (`&`, `0`), the arm function is **total** and has
535−to return properly (though it can still return *u3_none*).
535+to return properly (though it can still return **u3_none**).
536−Otherwise, it is *partial* and can `u3_cm_bail()` out with
536+Otherwise, it is **partial** and can `u3_cm_bail()` out with
537c3__punt. This feature has a cost: the jet runs in a subroad.
537c3__punt. This feature has a cost: the jet runs in a subroad.
539Finally, if `liv` is no (`|`, 1), the jet is off and doesn't run.
539Finally, if `liv` is no (`|`, 1), the jet is off and doesn't run.
@@ -570,10 +570,10 @@ caller passes the entire core, which is retained if the function
570returns `u3_none`, transferred otherwise. Why? Again, use
570returns `u3_none`, transferred otherwise. Why? Again, use
571counts of 1 are special and precious for performance hackers.
571counts of 1 are special and precious for performance hackers.
573−`u3q` interfaces break the core into C arguments, *retain* noun
573+`u3q` interfaces break the core into C arguments, **retain** noun
574−arguments, and *transfer* noun returns. `u3k` interfaces are the
574+arguments, and **transfer** noun returns. `u3k` interfaces are the
575same, except with more use of `u3_none` and other simple C
575same, except with more use of `u3_none` and other simple C
576−variations on the Hoon original, but *transfer* both arguments
576+variations on the Hoon original, but **transfer** both arguments
577and returns. Generally, `u3k` are most convenient for new code.
577and returns. Generally, `u3k` are most convenient for new code.
579Following `u3k/q/w` is `[a-f]`, corresponding to the 6 logical
579Following `u3k/q/w` is `[a-f]`, corresponding to the 6 logical
@@ -586,7 +586,7 @@ For instance, `++add` is `u3wa_add(cor)`, `u3qa_add(a, b)`, or
586`u3wdb_get(cor)`, `u3kdb_get(a, b)`, etc, in `j/d/by_get.c`.
586`u3wdb_get(cor)`, `u3kdb_get(a, b)`, etc, in `j/d/by_get.c`.
588For historical reasons, all internal jet code in `j/[a-f]`
588For historical reasons, all internal jet code in `j/[a-f]`
589−*retains* noun arguments, and *transfers* noun results. Please
589+**retains** noun arguments, and **transfers** noun results. Please
590do not do this in new `g` jets! The new standard protocol is to
590do not do this in new `g` jets! The new standard protocol is to
591transfer both arguments and results.
591transfer both arguments and results.
@@ -604,13 +604,13 @@ the macros `u3k()` and `u3z()` respectively.
604Normally we create nouns through `u3i` functions, and don't call
604Normally we create nouns through `u3i` functions, and don't call
605the `u3a` allocators directly. But if you do:
605the `u3a` allocators directly. But if you do:
607−One, there are *two* sets of allocators: the word-aligned
607+One, there are **two** sets of allocators: the word-aligned
608allocators and the fully-aligned (ie, malloc compatible)
608allocators and the fully-aligned (ie, malloc compatible)
609allocators. For instance, on a typical OS X setup, malloc
609allocators. For instance, on a typical OS X setup, malloc
610produces 16-byte aligned results - needed for some SSE
610produces 16-byte aligned results - needed for some SSE
611instructions.
611instructions.
613−These allocators are *not compatible*. For 32-bit alignment
613+These allocators are **not compatible**. For 32-bit alignment
614as used in nouns, call
614as used in nouns, call
@@ -670,7 +670,7 @@ allocate a block of raw space with `u3a_slab()`, then chop off
670the end with `u3a_malt()` (which does the measuring itself)
670the end with `u3a_malt()` (which does the measuring itself)
671or `u3a_mint()` in case you've measured it yourself.
671or `u3a_mint()` in case you've measured it yourself.
673−Once again, *do not call `malloc()`* (or C++ `new`) within any
673+Once again, **do not call `malloc()`** (or C++ `new`) within any
674code that may be run within a jet. This will cause rare sporadic
674code that may be run within a jet. This will cause rare sporadic
675corruption when we interrupt execution within a `malloc()`. We'd
675corruption when we interrupt execution within a `malloc()`. We'd
676just override the symbol, but `libuv` uses `malloc()` across
676just override the symbol, but `libuv` uses `malloc()` across
@@ -687,7 +687,7 @@ would expect, quite slow. (There is no such thing as a fast tree
687interpreter.)
687interpreter.)
689There is only one Nock, but there are lots of ways to call it.
689There is only one Nock, but there are lots of ways to call it.
690−(Remember that all `u3n` functions *transfer* C arguments and
690+(Remember that all `u3n` functions **transfer** C arguments and
693The simplest interpreter, `u3n_nock_on(u3_noun bus, u3_noun fol)`
693The simplest interpreter, `u3n_nock_on(u3_noun bus, u3_noun fol)`
@@ -696,7 +696,7 @@ invokes Nock on `bus` (the subject) and `fol` (the formula).
696reason `0` is true and `1` is false.)
696reason `0` is true and `1` is false.)
698A close relative is `u3n_slam_on(u3_noun gat, u3_noun sam)`,
698A close relative is `u3n_slam_on(u3_noun gat, u3_noun sam)`,
699−which slams a *gate* (`gat`) on a sample (`sam`). (In a normal
699+which slams a **gate** (`gat`) on a sample (`sam`). (In a normal
700programming language which didn't talk funny and was retarded,
700programming language which didn't talk funny and was retarded,
701`u3n_slam_on()` would call a function on an argument.) We could
701`u3n_slam_on()` would call a function on an argument.) We could
702write it most simply as:
702write it most simply as:
@@ -715,7 +715,7 @@ write it most simply as:
717Simpler is `u3n_kick_on(u3_noun gat)`, which slams a gate (or,
717Simpler is `u3n_kick_on(u3_noun gat)`, which slams a gate (or,
718−more generally, a *trap* - because sample structure is not even
718+more generally, a **trap** - because sample structure is not even
719needed here) without changing its sample:
719needed here) without changing its sample:
@@ -850,7 +850,7 @@ of `axis`, `u3_noun *`. For cells, triples, etc, decompose with
850`u3r_pq()` and friends.
850`u3r_pq()` and friends.
852`u3r_sing(u3_noun a, u3_noun b)` (true if `a` and `b` are a
852`u3r_sing(u3_noun a, u3_noun b)` (true if `a` and `b` are a
853−*single* noun) are interesting because it uses mugs to help it
853+**single** noun) are interesting because it uses mugs to help it
854out. Clearly, different nouns may have the same mug, but the
854out. Clearly, different nouns may have the same mug, but the
855same nouns cannot have a different mug. It's important to
855same nouns cannot have a different mug. It's important to
856understand the performance characteristics of `u3r_sing()`:
856understand the performance characteristics of `u3r_sing()`:
@@ -907,7 +907,7 @@ the memoization facility is a general-purpose cache.
907(It's also used for partial memoization - a feature that'll
907(It's also used for partial memoization - a feature that'll
908probably be removed, in which conservative worklist algorithms
908probably be removed, in which conservative worklist algorithms
909(which would otherwise be exponential) memoize everything in the
909(which would otherwise be exponential) memoize everything in the
910−subject *except* the worklist. This is used heavily in the Hoon
910+subject **except** the worklist. This is used heavily in the Hoon
911compiler jets (j/f/*.c). Unfortunately, it's probably not
911compiler jets (j/f/*.c). Unfortunately, it's probably not
912possible to make this work perfectly in that it can't be abused
912possible to make this work perfectly in that it can't be abused
913to violate Nock, so we'll probably remove it at a later date,
913to violate Nock, so we'll probably remove it at a later date,