on master help sign in
Merge pull request #1312 from urbit/update-remaining-home-references

change home->base throughout docs

commitd166c650ead6ac1fac7218f6e1fbb798cc4add15 authortinnus-napbus <77721746+tinnus-napbus@users.noreply.github.com> dateWed 19 Jan 2022, 15:36 (5 years ago) parent57fafc61602aa9
21 files changed+118−92
content/docs/arvo/clay/architecture.md+1−1 content/docs/arvo/clay/marks/using-marks.md+3−3 content/docs/arvo/clay/marks/writing-marks.md+8−8 content/docs/arvo/gall/gall.md+3−3 content/docs/azimuth/advanced-azimuth-tools.md+3−4 content/docs/glossary/arvo.md+5−1 content/docs/glossary/behn.md+1−1 content/docs/glossary/clay.md+1−1 content/docs/glossary/dill.md+1−1 content/docs/glossary/eyre.md+1−1 content/docs/glossary/ford.md+1−1 content/docs/glossary/gall.md+1−1 content/docs/glossary/hoon.md+1−1 content/docs/glossary/iris.md+1−1 content/docs/hoon/guides/cli-tutorial.md+44−21 content/docs/hoon/reference/hoon-errors.md+6−8 content/docs/hoon/reference/rune/dot.md+16−15 content/docs/hoon/reference/rune/zap.md+16−15 content/docs/hoon/reference/stdlib/3g.md+2−2 content/using/os/filesystem.md+2−2 content/using/os/ship-troubleshooting.md+1−1
content/docs/arvo/clay/architecture.md+1−1
@@ -90,7 +90,7 @@ blob store for performance reasons.
9090Recall that a desk is a series of numbered commits. Not every
9191commit in a desk must be numbered. For example, if the `%base` desk
9292has had 50 commits since `%foo` was forked from it, then a merge
93−from `%base` to `%foo` will only add a single revision number to home,
93+from `%base` to `%foo` will only add a single revision number,
9494although the full commit history will be accessible by traversing
9595the parentage of the individual commits.
9696
content/docs/arvo/clay/marks/using-marks.md+3−3
@@ -159,21 +159,21 @@ If we try merging diffs `a` and `c` however, we get `~` because of a conflict:
159159If we run `+mash` on `a` and `b` we get the same diff as with `+join` (sans the `unit`):
160160
161161```
162−> (mash:txt-nave [our %home diff-a] [our %blah diff-b])
162+> (mash:txt-nave [our %base diff-a] [our %blah diff-b])
163163[~ ~[[%.n p=<|foo|> q=<|zap|>] [%.n p=<|bar|> q=<|zoo|>] [%.y p=1]]]
164164```
165165
166166If we `+mash` `a` and `c`, however, we get a diff with the conflict annotated rather than just `~`:
167167
168168```
169−> (mash:txt-nave [our %home diff-a] [our %blah diff-c])
169+> (mash:txt-nave [our %base diff-a] [our %blah diff-c])
170170[ ~
171171 ~[
172172 [%.y p=1]
173173 [ %.n
174174 p=<|bar|>
175175 q
176− <|>>>>>>>>>>>> ~zod/home zoo ++++++++++++ bar ------------ bla <<<<<<<<<<<< ~zod/blah|>
176+ <|>>>>>>>>>>>> ~zod/base zoo ++++++++++++ bar ------------ bla <<<<<<<<<<<< ~zod/blah|>
177177 ]
178178 [%.y p=1]
179179 ]
content/docs/arvo/clay/marks/writing-marks.md+8−8
@@ -135,7 +135,7 @@ We've also added a `+mime` arm to `+grow` for converting _from_ our `%csv` `mark
135135
136136Additionally, we've used the `+validate` function in a few places to make sure our CSV data has consistent row lengths.
137137
138−If we save the above mark file as `csv.hoon` in `/mar` and `|commit %home`, we should now be able to import CSV files into Urbit. Let's give it a go. In the root of our `%home` `desk`, let's add a file named `foo.csv` with the following contents:
138+If we save the above mark file as `csv.hoon` in `/mar` and `|commit %base`, we should now be able to import CSV files into Urbit. Let's give it a go. In the root of our `%base` `desk`, let's add a file named `foo.csv` with the following contents:
139139
140140```
141141foo,bar,baz
@@ -143,34 +143,34 @@ blah,blah,blah
1431431,2,3
144144```
145145
146−If we now `|commit %home`, we should see it's been successfully added:
146+If we now `|commit %base`, we should see it's been successfully added:
147147
148148```
149−> |commit %home
149+> |commit %base
150150>=
151−+ /~zod/home/4/foo/csv
151++ /~zod/base/4/foo/csv
152152```
153153
154154And if we try reading the file with the `-read` thread:
155155
156156```
157−> -read [%x our %home da+now /foo/csv]
157+> -read [%x our %base da+now /foo/csv]
158158~[<|foo bar baz|> <|blah blah blah|> <|1 2 3|>]
159159```
160160
161161We can see our `%csv` `mark` has successfully converted our `foo.csv` file to a `(list (list @t))` when it was imported.
162162
163−Let's try the other direction now. We can create a new `bar.csv` files in the root of `%home` from the dojo like so:
163+Let's try the other direction now. We can create a new `bar.csv` files in the root of `%base` from the dojo like so:
164164
165165```
166166> */bar/csv ~[['abc' 'def' ~] ['ghi' 'jkl' ~]]
167−+ /~zod/home/5/bar/csv
167++ /~zod/base/5/bar/csv
168168```
169169
170170And if we check it in the terminal on the Unix side we can see it's been correctly encoded:
171171
172172```
173−> cat zod/home/bar.csv
173+> cat zod/base/bar.csv
174174abc,def
175175ghi,jkl
176176```
content/docs/arvo/gall/gall.md+3−3
@@ -302,19 +302,19 @@ a `%wake` card, which you will recieve in `+on-arvo`. It will come back
302302on `/my/wire`.
303303
304304```hoon
305−=/ =path /(scot %p our.hid)/home/(scot %da now.hid)/my-file/txt
305+=/ =path /(scot %p our.hid)/base/(scot %da now.hid)/my-file/txt
306306=/ contents=cage [%txt !>(~['text file line 1' 'line 2'])]
307307[%pass /my/wire %arvo %c %info (foal:space:userlib path contents)]
308308```
309309
310310This is a request to the `%c` vane (Clay, the filesystem vane) to write
311−a file to `/my-file/txt` in the home desk. You will not receive a
311+a file to `/my-file/txt` in the base desk. You will not receive a
312312response to this `note`.
313313
314314```hoon
315315=/ =path /my-file/txt
316316=/ =moat [da+now.hid da+(add now.hid ~h1) path]
317−[%pass /my/wire %arvo %c %warp our.hid %home ~ %many & moat]
317+[%pass /my/wire %arvo %c %warp our.hid %base ~ %many & moat]
318318```
319319
320320This is a request to the `%c` vane to send us a `%writ` `card` whenever
content/docs/azimuth/advanced-azimuth-tools.md+3−4
@@ -20,7 +20,7 @@ fakezod](https://urbit.org/using/develop/#creating-a-development-ship). You can
2020do this with your live running ship but at this time this will need you to
2121modify the code so it's best to do this on a ship you can make mistakes on.
2222
23−Be sure to have mounted your home desk so you can easily edit files on it. The
23+Be sure to have mounted your base desk so you can easily edit files on it. The
2424first edit that will probably need to be made is in
2525[`app/claz.hoon`](https://github.com/urbit/urbit/blob/85435e9a81e105809d5d381b5d34fae1d4daa3b8/pkg/arvo/app/claz.hoon#L14).
2626The listed url will need to be changed to a valid Ethereum endpoint. infura.io
@@ -36,7 +36,7 @@ as a guide based on what action you are going to be performing. The maximum cost
3636of your transaction will be the maximum gas units multiplied by the gwei you're
3737going to set later. You'll need at least this much in your account.
3838
39−Once you have made these changes be sure to run `|commit %home` to get them into
39+Once you have made these changes be sure to run `|commit %base` to get them into
4040your ship.
4141
4242Next run `|start %claz` after which you'll be able to generate transactions.
@@ -49,7 +49,6 @@ Here we have an example of generating a transaction to spawn a ship. Something
4949to note is that for this to be successful you'll need to actually have the right
5050to spawn the ship in question. Let's break down the command.
5151
52−
5352`%generate` is how all commands to `claz` are going to start.
5453
5554`%/spawn/eth-txs` is simply the path for the output file
@@ -102,7 +101,7 @@ details on that are outside of the scope of this guide.
102101`%/spawn-signed/txt` is the path to the output file.
103102
104103`%/spawn/eth-txs` is the path to the transaction file we generated earlier. It
105−will need to be accessible so don't forget to `|commit %home` if you moved it to
104+will need to be accessible so don't forget to `|commit %base` if you moved it to
106105a different pier.
107106
108107`%/mykey/txt` is the path to your private key file. It should contain your
content/docs/glossary/arvo.md+5−1
@@ -9,18 +9,22 @@ manager. It contains [vanes](/docs/glossary/vane), which are kernel modules that
99essential system operations.
1010
1111Arvo being purely functional means that the state of the operating system at a given moment is completely determined by the sequence of events in the event log. In other words, the state of an Arvo instance is given by a lifecycle function
12+
1213```
1314L: History ➜ State
1415```
16+
1517where `History` consists of the set of all possible sequences of events in an Arvo event log.
1618
1719Arvo coordinates and reloads vanes. It can be thought of as a traffic-director. Any vane needs to go through Arvo before reaching another vane. Events and their effects happen like so:
20+
1821```
1922Unix event -> Vere -> Arvo -> vane -> Arvo
2023```
24+
2125Here, [Vere](/docs/glossary/vere) is the virtual machine running Urbit.
2226
23−Arvo is located in `/home/sys/arvo.hoon` within your urbit.
27+Arvo is located in `/base/sys/arvo.hoon` within your urbit.
2428
2529Arvo vanes include [Ames](/docs/glossary/ames) for networking, [Behn](/docs/glossary/behn) for timing,
2630[Clay](/docs/glossary/clay) for filesystem and typed revision control, [Dill](/docs/glossary/dill) for
content/docs/glossary/behn.md+1−1
@@ -7,7 +7,7 @@ category = "arvo"
77
88**Behn** is the timing [vane](/docs/glossary/filesystem). It allows for applications to schedule events, which are managed in a simple priority queue. For example, [Clay](/docs/glossary/clay), the Urbit filesystem, uses Behn to keep track of time-specific file requests. [Eyre](/docs/glossary/eyre), the Urbit web vane, uses Behn for timing-out HTTP sessions.
99
10−Behn is located in `/home/sys/vane/behn.hoon` within [Arvo](/docs/glossary/arvo).
10+Behn is located in `/base/sys/vane/behn.hoon` within [Arvo](/docs/glossary/arvo).
1111
1212### Further Reading
1313
content/docs/glossary/clay.md+1−1
@@ -10,7 +10,7 @@ category = "arvo"
1010
1111A common way to use Clay is to create a pier, a directory that exists in and is visible in Unix. Changes are automatically recorded from Urbit to the Unix directory and vice versa. Just set it and forget it!
1212
13−Clay is located at `/home/sys/vane/clay.hoon` within Arvo.
13+Clay is located at `/base/sys/vane/clay.hoon` within Arvo.
1414
1515### Further Reading
1616
content/docs/glossary/dill.md+1−1
@@ -15,7 +15,7 @@ A keyboard event's journey from Unix to Dojo, the Urbit shell, can be imagined a
1515Keystroke in Unix -> Vere (virtual machine) -> Arvo -> Dill -> the Dojo
1616```
1717
18−Dill is located at `/home/sys/vane/dill.hoon` within [Arvo](/docs/glossary/arvo).
18+Dill is located at `/base/sys/vane/dill.hoon` within [Arvo](/docs/glossary/arvo).
1919
2020### Further Reading
2121
content/docs/glossary/eyre.md+1−1
@@ -10,7 +10,7 @@ category = "arvo"
1010
1111In general, apps and vanes do not call Eyre; rather, Eyre calls apps and vanes. Eyre uses [Ford](/docs/glossary/ford) and [Gall](/docs/glossary/gall) to functionally publish pages and facilitate communication with apps.
1212
13−Eyre is located at `/home/sys/vane/eyre.hoon` within [Arvo](/docs/glossary/arvo).
13+Eyre is located at `/base/sys/vane/eyre.hoon` within [Arvo](/docs/glossary/arvo).
1414
1515### Further Reading
1616
content/docs/glossary/ford.md+1−1
@@ -10,7 +10,7 @@ category = "arvo"
1010
1111Ford neither accepts Unix events nor produces Unix effects. It exists entirely for the benefit of [Arvo](/docs/glossary/arvo) applications and other vanes, specifically [Clay](/docs/glossary/clay) and [Gall](/docs/glossary/gall).
1212
13−Ford is located at `/home/sys/vane/ford.hoon` within [Arvo](/docs/glossary/arvo).
13+Ford is located at `/base/sys/vane/ford.hoon` within [Arvo](/docs/glossary/arvo).
1414
1515### Further Reading
1616
content/docs/glossary/gall.md+1−1
@@ -8,7 +8,7 @@ category = "arvo"
88
99**Gall** is the application-management [vane](/docs/glossary/vane). Userspace apps –⁠ daemons, really –⁠ are started, stopped, and sandboxed by Gall. Gall provides developers with a consistent interface for connecting their app to [Arvo](/docs/glossary/arvo). It allows applications and other vanes to send messages to applications and subscribe to data streams. Messages coming into Gall are routed to the intended application, and the response comes back along the same route. If the intended target is on another [ship](/docs/glossary/ship), Gall will route it behind the scenes through [Ames](/docs/glossary/ames) to the other ship.
1010
11−Gall is located at `/home/sys/vane/gall.hoon` within Arvo.
11+Gall is located at `/base/sys/vane/gall.hoon` within Arvo.
1212
1313### Further Reading
1414
content/docs/glossary/hoon.md+1−1
@@ -6,7 +6,7 @@ template = "doc.html"
66
77Hoon is a strict, higher-order typed functional programming language that compiles itself to [Nock](/docs/glossary/nock). As a result Hoon code is effectively implemented by the interpreter [Vere](/docs/glossary/vere). Programs for the Urbit operating system and kernel, [Arvo](/docs/glossary/arvo), are written in Hoon.
88
9−The Hoon source file is located in `/home/sys/hoon.hoon` within your Urbit.
9+The Hoon source file is located in `/base/sys/hoon.hoon` within your Urbit.
1010
1111### Further Reading
1212
content/docs/glossary/iris.md+1−1
@@ -8,4 +8,4 @@ category = "arvo"
88
99**Iris** is the web-server [vane](/docs/glossary/vane) that handles everything HTTP-related on the server side. It is the counterpart to [Eyre](/docs/glossary/eyre), which is the client-facing HTTP vane.
1010
11−Iris is located at `/home/sys/vane/iris.hoon` within [Arvo](/docs/glossary/arvo).
11+Iris is located at `/base/sys/vane/iris.hoon` within [Arvo](/docs/glossary/arvo).
content/docs/hoon/guides/cli-tutorial.md+44−21
@@ -10,9 +10,10 @@ In this walkthrough we will go in-depth on how to build command line interface (
1010applications in Urbit using the `shoe` library.
1111
1212There are three CLI apps that currently ship with urbit - `%dojo`, `%chat-cli`,
13−and `%shoe`. You should be familiar with the former two, the latter is an example
14−app that shows off how the `shoe` library works that we will be looking at
15−closely. These are all Gall apps, and as such their source can be found in the `app/` folder of your `%home` desk.
13+and `%shoe`. You should be familiar with the former two, the latter is an
14+example app that shows off how the `shoe` library works that we will be looking
15+at closely. These are all Gall apps, and their source can be found in the `app/`
16+folder of your `%base` desk.
1617
1718In [the `shoe` library](#the-shoe-library) we take a closer look at the `shoe` library and its
1819cores and how they are utilized in CLI apps. Then in [the `sole`
@@ -26,7 +27,6 @@ lesson](/docs/hoon/hoon-school/generators#ask) on `sole` and `%ask`
2627generators, which only covers the bare minimum necessary to write generators
2728that take user input.
2829
29−
3030## The `shoe` library {#the-shoe-library}
3131
3232Here we describe how sessions are identified, the specialized `card`s that Gall agents
@@ -44,9 +44,11 @@ ship and which session on that ship if there are multiple.
4444
4545Gall agents with the `shoe` library are able to utilize `%shoe` `card`s. These
4646additions to the standard set of `cards` have the following shape:
47+
4748```hoon
4849[%shoe sole-ids=(list @ta) effect=shoe-effect]`
4950```
51+
5052`sole-ids` is the `list` of session ids that the following `effect` is
5153emitted to. An empty `sole-ids` sends the effect to all connected sessions.
5254`shoe-effect`s, for now, are always of the shape `[%sole effect=sole-effect]`, where
@@ -144,14 +146,13 @@ This is a function for wrapping a `shoe` core, which has too many
144146arms to be a valid Gall agent core. This turns it into a standard Gall agent core by
145147integrating the additional arms into the standard ones.
146148
147−
148149## The `sole` library {#the-sole-library}
149150
150−`shoe` apps may create specialized `card`s of the `[%shoe
151−(list @ta) shoe-effect]` shape, where `shoe-effect` currently just wrap `sole-effect`s, i.e. instructions for displaying text and producing other effects in the console.
151+`shoe` apps may create specialized `card`s of the `[%shoe (list @ta) shoe-effect]` shape, where `shoe-effect` currently just wrap `sole-effect`s, i.e. instructions for displaying text and producing other effects in the console.
152152
153153The list of possible `sole-effects` can be found in `/sur/sole.hoon`. A few
154154commonly used ones are as follows.
155+
155156- `[%txt tape]` is used to display a line of text.
156157- `[%bel ~]` is used to emit a beep.
157158- `[%pro sole-prompt]` is used to set the prompt.
@@ -159,6 +160,7 @@ commonly used ones are as follows.
159160
160161For example, a `sole-effect` that beeps and displays `This is some text.` would
161162be structured as
163+
162164```hoon
163165[%mor [%txt "This is some text."] [%bel ~] ~]
164166```
@@ -180,20 +182,23 @@ intention is to connect their `%shoe` apps.
180182On each fake ship start `%shoe` by entering `|start %shoe` into dojo. This will
181183automatically
182184change the prompt to `~zod:shoe>` and `~nus:shoe>`. Type `demo` and watch the following appear:
185+
183186```
184187~zod ran the command
185188~zod:shoe>
186189```
190+
187191`~zod ran the command` should be displayed in bold green text, signifying that
188192the command originated locally.
189193
190−Now we will connect the sessions. Switch `~zod` back to dojo with `Ctrl-X` and enter `|link
191−~nus %shoe`. If this succeeds you will see the following.
194+Now we will connect the sessions. Switch `~zod` back to dojo with `Ctrl-X` and enter `|link ~nus %shoe`. If this succeeds you will see the following.
195+
192196```
193197>=
194198; ~nus is your neighbor
195199[linked to [p=~nus q=%shoe]]
196200```
201+
197202Now `~zod` will have two `%shoe` sessions running - one local one on `~zod` and
198203one remote one on `~nus`, which you can access by pressing `Ctrl-X` until you see
199204`~nus:shoe>` from `~zod`'s console. On the other hand, you should not see
@@ -207,10 +212,12 @@ bold green text.
207212
208213Now try to link to `~zod`'s `%shoe` session from `~nus` by switching to the dojo
209214on `~nus` and entering `|link ~zod %shoe`. You should see
215+
210216```
211217>=
212218[unlinked from [p=~zod q=%shoe]]
213219```
220+
214221and if you press `Ctrl-X` you will not get a `~zod:shoe>` prompt. This is
215222because the example app is set up to always allow `~zod` to connect (as well as
216223subject moons if the ship happens to be a planet) but not `~nus`, so this
@@ -229,11 +236,12 @@ message means that `~nus` failed to connect to `~zod`'s `%shoe` session.
229236
230237`/+` is the Ford rune which imports libraries from the `/lib` directory into
231238the subject.
232− * `shoe` is the `shoe` library.
233− * `verb` is a library used to print what a Gall agent is doing.
234− * `dbug` is a library of debugging tools.
235− * `default-agent` contains a Gall agent core with minimal implementations of
236− required Gall arms.
239+
240+- `shoe` is the `shoe` library.
241+- `verb` is a library used to print what a Gall agent is doing.
242+- `dbug` is a library of debugging tools.
243+- `default-agent` contains a Gall agent core with minimal implementations of
244+ required Gall arms.
237245
238246```hoon
239247|%
@@ -243,6 +251,7 @@ the subject.
243251+$ card card:shoe
244252--
245253```
254+
246255The types used by the app.
247256
248257`state-0` stores the state of the app, which is null as there is no state to
@@ -254,8 +263,7 @@ commands that can be entered by the user. Since this app only supports one
254263command, it is unnecessary for it to have any associated data, thus the command
255264is represented by `~`.
256265
257−In a non-trivial context, a `command` is commonly given by `[%name
258−data]`, where `%name` is the identifier for the type of command and `data` is
266+In a non-trivial context, a `command` is commonly given by `[%name data]`, where `%name` is the identifier for the type of command and `data` is
259267a type or list of types that contain data needed to execute the command. See
260268`app/chat-cli.hoon` for examples of commands, such as `[%say letter:store]` and
261269`[%delete path]`. This is not required though, and you could use something like
@@ -264,7 +272,7 @@ a type or list of types that contain data needed to execute the command. See
264272`card` is either an ordinary Gall agent `card` or a `%shoe` `card`, which takes
265273the shape `[%shoe sole-ids=(list @ta) effect=shoe-effect]`. A `%shoe` `card` is
266274sent to all `sole`s listed in `sole-ids`, imaking them run the `sole-effect`
267−specified by `effect` (i.e. printing some text). Here we can
275+specified by `effect` (i.e. printing some text). Here we can
268276reference `card:shoe` because of `/+ shoe` at the beginning of the app.
269277
270278```hoon
@@ -272,6 +280,7 @@ reference `card:shoe` because of `/+ shoe` at the beginning of the app.
272280=* state -
273281::
274282```
283+
275284Add the bunt value of `state-0` to the head of the subject, then give it the
276285macro `state`. The `-` here is a lark expression referring to the head of the
277286subject. This allows us to use `state` to refer to the state elsewhere in the
@@ -293,13 +302,13 @@ producing a standard Gall agent core. Then we call wrap the Gall agent core with
293302`agent:dbug`, endowing it with additional arms useful for debugging, and then
294303wrap again with `verb`.
295304
296−
297305```hoon
298306|_ =bowl:gall
299307+* this .
300308 def ~(. (default-agent this %|) bowl)
301309 des ~(. (default:shoe this command) bowl)
302310```
311+
303312This is boilerplate Gall agent core code. We set `this` to be a macro for the
304313subject, which is the Gall agent core itself. We set `def` and `des` to be
305314macros for initialized `default-agent` and `default:shoe` doors respectively.
@@ -323,23 +332,25 @@ the standard Gall arms:
323332++ on-arvo on-arvo:def
324333++ on-fail on-fail:def
325334```
335+
326336These are minimalist Gall app arm implementations using the default behavior found in `def`.
327337
328338Here begins the implementation of the additional arms required by the
329339`(shoe:shoe command)` interface.
340+
330341```hoon
331342++ command-parser
332343 |= sole-id=@ta
333344 ^+ |~(nail *(like [? command]))
334345 (cold [& ~] (jest 'demo'))
335346```
347+
336348`+command-parser` is of central importance - it is what is used to parse user
337349input and transform it into `command`s for the app to execute. Writing a proper
338350command parser requires understanding of the Hoon parsing functions found in the
339351standard library. How to do so may be found in the [parsing tutorial](/docs/hoon/guides/parsing). For now, it is sufficient to know that this arm matches the text "demo" and
340352produces a `[? command]`-shaped noun in response. Note how the `&` signifies that the command will be run as soon as it has been entered, without waiting for the user to press return.
341353
342−
343354```hoon
344355++ tab-list
345356 |= sole-id=@ta
@@ -347,47 +358,57 @@ produces a `[? command]`-shaped noun in response. Note how the `&` signifies tha
347358 :~ ['demo' leaf+"run example command"]
348359 ==
349360```
361+
350362`+tab-list` is pretty much plug-n-play. For each command you want to be tab
351−completed, add an entry to the `list` begun by `:~` of the form `[%command
352−leaf+"description"]`. Now whenever the user types a partial command and presses
363+completed, add an entry to the `list` begun by `:~` of the form `[%command leaf+"description"]`. Now whenever the user types a partial command and presses
353364tab, the console will display the list of commmands that match the partial
354365command as well as the descriptions given here.
355366
356367Thus here we have that starting to type `demo` and pressing tab will result in
357368the following output in the console:
369+
358370```
359371demo run example command
360372~zod:shoe> demo
361373```
374+
362375with the remainder of `demo` now added to the input line.
363376
364377Next we have `+on-command`, which is called whenever `+command-parser`
365378recognizes that `demo` has been entered by a user.
379+
366380```hoon
367381++ on-command
368382 |= [sole-id=@ta =command]
369383 ^- (quip card _this)
370384```
385+
371386This is a gate that takes in the `sole-id` corresponding to the session and the
372387`command` noun parsed by `+command-parser` and returns a `list` of `card`s and
373388`_this`, which is our shoe agent core including its state.
389+
374390```hoon
375391 =- [[%shoe ~ %sole -]~ this]
376392```
393+
377394This creates a cell of a `%shoe` card that triggers a `sole-effect` given by the head of
378395the subject `-`, then the Gall agent core `this` - i.e. the return result of
379396this gate. The use of the `=-` rune means that what follows this
380397expression is actually run first, which puts the desired `sole-effect` into the
381398head of the subject.
399+
382400```hoon
383401 =/ =tape "{(scow %p src.bowl)} ran the command"
384402```
403+
385404We define the `tape` that we want to be printed.
405+
386406```hoon
387407 ?. =(src our):bowl
388408 [%txt tape]
389409 [%klr [[`%br ~ `%g] [(crip tape)]~]~]
390410```
411+
391412We cannot just produce the `tape` we want printed, - it needs to fit the
392413`sole-effect` type. This tells us that if the
393414origin of the command is not our ship to just print it normally with the `%txt`
@@ -396,6 +417,7 @@ makes the text green and bold).
396417
397418The following allows either `~zod`, or the host ship and its moons, to connect to
398419this app's command line interface using `|link`.
420+
399421```hoon
400422++ can-connect
401423 |= sole-id=@ta
@@ -407,6 +429,7 @@ this app's command line interface using `|link`.
407429
408430We use the minimal implementations for the final two `shoe` arms, since we don't
409431want to do anything special when users connect or disconnect.
432+
410433```hoon
411434++ on-connect on-connect:des
412435++ on-disconnect on-disconnect:des
content/docs/hoon/reference/hoon-errors.md+6−8
@@ -72,12 +72,12 @@ stack trace. An extensive stack trace tutorial is [below](#stack-trace-tutorial)
7272If you have `!:` on, you'll see an error trace, like:
7373
7474```
75−/~zod/home/0/gen/hello:<[7 3].[11 21]>
76−/~zod/home/0/gen/hello:<[8 1].[11 21]>
77−/~zod/home/0/gen/hello:<[9 1].[11 21]>
78−/~zod/home/0/gen/hello:<[10 1].[11 21]>
79−/~zod/home/0/gen/hello:<[11 1].[11 21]>
80−/~zod/home/0/gen/hello:<[11 7].[11 21]>
75+/~zod/base/0/gen/hello:<[7 3].[11 21]>
76+/~zod/base/0/gen/hello:<[8 1].[11 21]>
77+/~zod/base/0/gen/hello:<[9 1].[11 21]>
78+/~zod/base/0/gen/hello:<[10 1].[11 21]>
79+/~zod/base/0/gen/hello:<[11 1].[11 21]>
80+/~zod/base/0/gen/hello:<[11 7].[11 21]>
8181nest-fail
8282```
8383
@@ -185,5 +185,3 @@ true:
185185For now, you need to be on the local console to see these debug
186186printfs (which are implemented by interpreter hints). This is a
187187bug and, like all bugs, will be fixed at some point.
188−
189−
content/docs/hoon/reference/rune/dot.md+16−15
@@ -4,7 +4,8 @@ weight = 3
44template = "doc.html"
55aliases = ["docs/reference/hoon-expressions/rune/dot/"]
66+++
7−Anything Nock can do, Hoon can do also. These runes are used for carrying out Nock operations in Hoon.
7+
8+Anything Nock can do, Hoon can do also. These runes are used for carrying out Nock operations in Hoon.
89
910## Runes
1011
@@ -18,15 +19,15 @@ The noun `q`, cast to the type `p`.
1819
1920##### Discussion
2021
21−Nock has no `12` instruction! But the virtual Nock
22−used to run userspace code does. Nock `12` loads from a
22+Nock has no `12` instruction! But the virtual Nock
23+used to run userspace code does. Nock `12` loads from a
2324typed immutable namespace defined by its virtual context.
2425
25−Ordinarily a Hoon expression has access to no information but whatever can be found in the subject. The one exception is with the `.^` rune. It essentially allows you to request information from one of the Arvo vanes (modules).
26+Ordinarily a Hoon expression has access to no information but whatever can be found in the subject. The one exception is with the `.^` rune. It essentially allows you to request information from one of the Arvo vanes (modules).
2627
27−`.^` checks that the type of the value retrieved from Arvo nests under `p`. `q` is a `path` which includes information about which vane is being queried, and what sort of information is requested.
28+`.^` checks that the type of the value retrieved from Arvo nests under `p`. `q` is a `path` which includes information about which vane is being queried, and what sort of information is requested.
2829
29−In principle `.^` takes two subexpressions, but in practice `q` is often given in two parts: the first part includes the vane to be queried (e.g., `%a` for Ames, `%b` for Behn, `%c` for Clay, etc.) and the kind of request. The second part is a path that corresponds to the kind of request.
30+In principle `.^` takes two subexpressions, but in practice `q` is often given in two parts: the first part includes the vane to be queried (e.g., `%a` for Ames, `%b` for Behn, `%c` for Clay, etc.) and the kind of request. The second part is a path that corresponds to the kind of request.
3031
3132##### Examples
3233
@@ -51,19 +52,19 @@ In the dojo we can ask Clay -- the Arvo filesystem -- for a listing of the files
5152]
5253```
5354
54−The `%c` is for Clay, and the `y` is for the request type. `arch` is the type of the listing. See `gen/cat.hoon` to see how this information is printed more prettily.
55+The `%c` is for Clay, and the `y` is for the request type. `arch` is the type of the listing. See `gen/cat.hoon` to see how this information is printed more prettily.
5556
5657The `%` is for the current path in the dojo:
5758
5859```
5960> `path`%
60−/~zod/home/~2018.9.20..23.05.35..0231
61+/~zod/base/~2018.9.20..23.05.35..0231
6162```
6263
63−You can modify the time of the file listing quite simply and ask for a listing from 5 hours ago. (Remember that Clay is a revision-controlled file system.)
64+You can modify the time of the file listing quite simply and ask for a listing from 5 hours ago. (Remember that Clay is a revision-controlled file system.)
6465
6566```
66−> .^(arch %cy /(scot %p our)/home/(scot %da (sub now ~h5)))
67+> .^(arch %cy /(scot %p our)/base/(scot %da (sub now ~h5)))
6768[ fil=~
6869 dir
6970 { [p=~.web q=~]
@@ -89,7 +90,7 @@ You can modify the time of the file listing quite simply and ask for a listing f
8990
9091##### Produces
9192
92−`p` plus `1` if `p` is an atom; otherwise, crashes. The product atom has no aura.
93+`p` plus `1` if `p` is an atom; otherwise, crashes. The product atom has no aura.
9394
9495##### Syntax
9596
@@ -131,7 +132,7 @@ Regular: **2-fixed**.
131132
132133Keep in mind that `p` and `q` can be arbitrary Hoon expressions, as long as they evaluate to the appropriate nouns for Nock evaluation.
133134
134−Note also that `.*` ("dottar") can be used to bypass the type system. It's
135+Note also that `.*` ("dottar") can be used to bypass the type system. It's
135136therefore possible to use Hoon as a typeless language.
136137
137138##### Examples
@@ -172,13 +173,13 @@ Irregular: `=(a b)` is `.=(a b)`.
172173
173174##### Discussion
174175
175−The test for equality includes a type check. Either the type of `p` must nest under the type of `q`, or _vice versa_. Otherwise the result is a crash.
176+The test for equality includes a type check. Either the type of `p` must nest under the type of `q`, or _vice versa_. Otherwise the result is a crash.
176177
177178Like Nock equality, `.=` ("dottis") tests whether two nouns are the same,
178−ignoring invisible pointer structure. Because in a conventional
179+ignoring invisible pointer structure. Because in a conventional
179180noun implementation each noun has a lazy short hash, comparisons
180181are fast unless the hash needs to be computed, or we are comparing
181−separate copies of identical nouns. (Comparing large duplicates
182+separate copies of identical nouns. (Comparing large duplicates
182183is a common cause of performance bugs.)
183184
184185##### Examples
content/docs/hoon/reference/rune/zap.md+16−15
@@ -4,6 +4,7 @@ weight = 4
44template = "doc.html"
55aliases = ["docs/reference/hoon-expressions/rune/zap/"]
66+++
7+
78## Runes
89
910### `!>` "zapgar"
@@ -20,7 +21,7 @@ Regular: **1-fixed**.
2021
2122##### Discussion
2223
23−In Hoon, a dynamic type is a static type compiled at runtime. This type-noun cell is generally called a `vase`.
24+In Hoon, a dynamic type is a static type compiled at runtime. This type-noun cell is generally called a `vase`.
2425
2526##### Examples
2627
@@ -29,7 +30,7 @@ In Hoon, a dynamic type is a static type compiled at runtime. This type-noun ce
2930[#t/@ud q=1]
3031```
3132
32−If you want just the type value, use a 'type spear'. This is `-:!>`, i.e., the head of the cell produced by `!>`:
33+If you want just the type value, use a 'type spear'. This is `-:!>`, i.e., the head of the cell produced by `!>`:
3334
3435```
3536> -:!>(1)
@@ -50,7 +51,7 @@ The value of `vase` typed with the type of the mold if possible, else a
5051
5152##### Syntax
5253
53−Regular: **2-fixed**
54+Regular: **2-fixed**
5455
5556##### Discussion
5657
@@ -99,8 +100,8 @@ Regular: **1-fixed**.
99100ford: %ride failed to execute:
100101
101102> !: ?:(=(0 1) 123 !!)
102−/~zod/home/~2018.10.15..19.50.06..74af:<[1 5].[1 22]>
103−/~zod/home/~2018.10.15..19.50.06..74af:<[1 19].[1 21]>
103+/~zod/base/~2018.10.15..19.50.06..74af:<[1 5].[1 22]>
104+/~zod/base/~2018.10.15..19.50.06..74af:<[1 19].[1 21]>
104105ford: %ride failed to execute:
105106```
106107
@@ -124,7 +125,7 @@ Regular: **1-fixed**.
124125
125126##### Discussion
126127
127−`!.` is used to turn off a debugging stack trace option for any code you have in `p`. This rune can be embedded under a `!:` rune for inner loops of your code that you don't want or need to trace. This is especially useful if a trace overflows the stack.
128+`!.` is used to turn off a debugging stack trace option for any code you have in `p`. This rune can be embedded under a `!:` rune for inner loops of your code that you don't want or need to trace. This is especially useful if a trace overflows the stack.
128129
129130##### Examples
130131
@@ -133,18 +134,18 @@ Regular: **1-fixed**.
133134ford: %ride failed to execute:
134135
135136> !: %.(1 |=(a=@ ^-(@ ?:(=(a 10) !! $(a +(a))))))
136−/~zod/home/~2018.10.15..20.01.21..6b0c:<[1 5].[1 49]>
137−/~zod/home/~2018.10.15..20.01.21..6b0c:<[1 17].[1 47]>
138−/~zod/home/~2018.10.15..20.01.21..6b0c:<[1 22].[1 46]>
139−/~zod/home/~2018.10.15..20.01.21..6b0c:<[1 36].[1 45]>
137+/~zod/base/~2018.10.15..20.01.21..6b0c:<[1 5].[1 49]>
138+/~zod/base/~2018.10.15..20.01.21..6b0c:<[1 17].[1 47]>
139+/~zod/base/~2018.10.15..20.01.21..6b0c:<[1 22].[1 46]>
140+/~zod/base/~2018.10.15..20.01.21..6b0c:<[1 36].[1 45]>
140141...skipping some lines...
141−/~zod/home/~2018.10.15..20.01.21..6b0c:<[1 17].[1 47]>
142−/~zod/home/~2018.10.15..20.01.21..6b0c:<[1 22].[1 46]>
143−/~zod/home/~2018.10.15..20.01.21..6b0c:<[1 33].[1 35]>
142+/~zod/base/~2018.10.15..20.01.21..6b0c:<[1 17].[1 47]>
143+/~zod/base/~2018.10.15..20.01.21..6b0c:<[1 22].[1 46]>
144+/~zod/base/~2018.10.15..20.01.21..6b0c:<[1 33].[1 35]>
144145ford: %ride failed to execute:
145146
146147> !: %.(1 !.(|=(a=@ ^-(@ ?:(=(a 10) !! $(a +(a)))))))
147−/~zod/home/~2018.10.15..20.01.35..0529:<[1 5].[1 53]>
148+/~zod/base/~2018.10.15..20.01.35..0529:<[1 5].[1 53]>
148149ford: %ride failed to execute:
149150```
150151
@@ -221,7 +222,7 @@ Regular: **2-fixed**.
221222
222223##### Produces
223224
224−Nothing. Always crashes, with type `%void`.
225+Nothing. Always crashes, with type `%void`.
225226
226227##### Syntax
227228
content/docs/hoon/reference/stdlib/3g.md+2−2
@@ -203,7 +203,7 @@ stack traces.
203203
204204```
205205> !:(!!) :: !! always produces a crash
206−/~zod/home/~2014.9.20..01.22.04..52e3/:<[1 4].[1 6]>
206+/~zod/base/~2014.9.20..01.22.04..52e3/:<[1 4].[1 6]>
207207
208208> `pint`[[1 4] [1 6]]
209209[p=[p=1 q=4] q=[p=1 q=6]]
@@ -248,7 +248,7 @@ The stack trace that is printed after crashing.
248248
249249```
250250> !: !! :: !! always produces a crash
251−/~zod/home/~2018.8.8..21.42.40..7852:<[1 5].[1 7]>
251+/~zod/base/~2018.8.8..21.42.40..7852:<[1 5].[1 7]>
252252! exit
253253```
254254
content/using/os/filesystem.md+2−2
@@ -300,10 +300,10 @@ optional strategy.
300300Merge the `%examples` `desk` from `~waxbex-ribmex`
301301
302302```
303−|merge %home-work /=home=, =gem %fine
303+|merge %work /=base=, =gem %fine
304304```
305305
306−Merge `/=home=` into `%home-work` using merge strategy `%fine`.
306+Merge `/=base=` into `%work` using merge strategy `%fine`.
307307
308308#### Sync
309309
content/using/os/ship-troubleshooting.md+1−1
@@ -122,7 +122,7 @@ own with patience. Otherwise, try the procedure outlined [here](https://github.c
122122
123123### I keep getting an `ames` error stack-trace
124124
125−You may see a message like this one: `/~zod/home/~2019.7.22..18.55.46..83a3/sys/vane/ames:<[line column].[line column]>`. This is a clay path to a Hoon file, pointing to the line and column where an expression crashed. This kind of error might be accompanied by a `crud` message.
125+You may see a message like this one: `/~zod/base/~2019.7.22..18.55.46..83a3/sys/vane/ames:<[line column].[line column]>`. This is a clay path to a Hoon file, pointing to the line and column where an expression crashed. This kind of error might be accompanied by a `crud` message.
126126
127127This means that another ship is sending invalid packets to you. This could be
128128because one of the ships has not updated the other ship's "rift number", which