@@ -15,7 +15,7 @@ All we've written up until now are just shell commands that produce a
1515value and then disappear. To listen for and receive messages from other
1616planets, we'll need an app. Let's look at a very simple one:
1717
18− :: There is no love that is not an echo
18+ :: Accepts any noun from dojo and prints it out
1919 ::
2020 :::: /hoon/echo/examples/app
2121 ::
@@ -71,7 +71,7 @@ type `{(list) _+>.$}`. But what does this mean?
7171The phrase to remember is "a list of moves and our state". Urbit is a
7272message passing system, so whenever we want to do something that
7373interacts with the rest of the system, we send a message. Thus, a move
74−is arvo's equivalent of a syscall. The first thing that `++poke-noun`
74+is Arvo's equivalent of a syscall. The first thing that `++poke-noun`
7575produces is a list of messages, called "moves". In this case, we don't
7676actually want the system to do anything, so we produce the empty list,
7777`~` (in the `[~ +>.$]` line).
@@ -106,7 +106,7 @@ Intro to marks
106106
107107Are there other `++poke`s? Yes. In fact, `noun` and `atom` are just two
108108of arbitrarily many "marks". A mark is fundamentally a type definition,
109−but accessible at the arvo level. Each mark is defined in the `/mar`
109+but accessible at the Arvo level. Each mark is defined in the `/mar`
110110directory. Some marks have conversion routines to other marks, and some
111111have diff, patch, and merge algorithms. None of these are required for a
112112mark to exist, however.
@@ -201,7 +201,7 @@ stands for "phonetic base").
201201
202202Recall that in a `++poke` arm we produce "a list of moves and our
203203state". Until now, we've left the list of moves empty, since we haven't
204−wanted to tell arvo to do anything in particular. Now we want to send a
204+wanted to tell Arvo to do anything in particular. Now we want to send a
205205message to another urbit. Thus, we produce a list with one element:
206206
207207 [ost %poke /sending [to-urbit-address %pong] %atom 'howdy']
@@ -228,7 +228,7 @@ Thus, to truly understand bones, we must understand ducts.
228228
229229A duct is stack of causes, again, represented as paths, which are called
230230wires. At the bottom of every duct is a unix event, such as a keystroke,
231−network packet, file change, or timer event. When arvo is given this
231+network packet, file change, or timer event. When Arvo is given this
232232event, it routes the event to appropriate kernel module for handling.
233233
234234Sometimes, the module can immediately handle the event and produce any
@@ -247,9 +247,9 @@ continue indefinitely, adding more and more layers onto the duct. When
247247an entity finally produces a result, a layer is popped off the duct, and
248248the result is passed all the way back down.
249249
250−In effect, a duct is an arvo-level call stack. It's worth noting that
250+In effect, a duct is an Arvo-level call stack. It's worth noting that
251251while in traditional call stacks a function call happens synchronously
252−and returns exactly once. In arvo, multiple moves can be sent at once,
252+and returns exactly once. In Arvo, multiple moves can be sent at once,
253253are evaluated asynchronously, and each one may be responded to zero or
254254more times.
255255
@@ -286,7 +286,7 @@ app) and marked data, then pokes the arm of the corresponding mark on
286286that app on that urbit with that data. `[to-urbit-address %pong]` is the
287287target urbit and app, `%atom` is the `mark`, and`'howdy'` is the data.
288288
289−When arvo receives a `%poke` move, it calls the appropriate `++poke`.
289+When Arvo receives a `%poke` move, it calls the appropriate `++poke`.
290290The same mechanism is used for sending messages between apps on the same
291291urbit as for sending messages between apps on different urbits.
292292