git.iko.soy/urbit.org
on master help sign in
Merge pull request #626 from ryjm/kiss-to-task

kiss -> task

commit20217ebbe15be790ef338b6e928583d4c46eeece authorrmariani <robert@tlon.io> dateFri 30 Aug 2019, 11:21 (7 years ago) parente55a597dcafdd5
4 files changed+16−16
compare with master
unifiedsplit
learn/arvo/_index.md+5−5 learn/arvo/ames.md+7−7 learn/arvo/eyre.md+3−3 learn/arvo/gall.md+1−1
learn/arvo/_index.md+5−5
@@ -101,12 +101,12 @@ As of this writing, we have seven vanes, which each provide the following servic
101101
102102### Cards
103103
104−Cards are the vane-specific portion of a move. Each vane defines a protocol for interacting with other vanes (via Arvo) by defining four types of cards: kisses, gifts, notes, and signs.
104+Cards are the vane-specific portion of a move. Each vane defines a protocol for interacting with other vanes (via Arvo) by defining four types of cards: tasks, gifts, notes, and signs.
105105
106−When one vane is `%pass`ed a card in its `++kiss`, Arvo activates the `++call` gate with the card as its argument. To produce a result, the vane `%give`s one of the cards defined in its `++gift`. If the vane needs to request something of another vane, it `%pass`es it a `++note` card. When that other vane returns a result, Arvo activates the `++take` gate of the initial vane with one of the cards defined in its `++sign`.
106+When one vane is `%pass`ed a card in its `++task` (defined in zuse), Arvo activates the `++call` gate with the card as its argument. To produce a result, the vane `%give`s one of the cards defined in its `++gift`. If the vane needs to request something of another vane, it `%pass`es it a `++note` card. When that other vane returns a result, Arvo activates the `++take` gate of the initial vane with one of the cards defined in its `++sign`.
107107
108−In other words, there are only four ways of seeing a move: (1) as a request seen by the caller, which is a ++note. (2) that same request as seen by the callee, a `++kiss`. (3) the response to that first request as seen by the callee, a `++gift`. (4) the response to the first request as seen by the caller, a `++sign`.
108+In other words, there are only four ways of seeing a move: (1) as a request seen by the caller, which is a ++note. (2) that same request as seen by the callee, a `++task`. (3) the response to that first request as seen by the callee, a `++gift`. (4) the response to the first request as seen by the caller, a `++sign`.
109109
110−When a `++kiss` card is passed to a vane, Arvo calls its `++call` gate, passing it both the card and its duct. This gate must be defined in every vane. It produces two things in the following order: a list of moves and a possibly modified copy of its context. The moves are used to interact with other vanes, while the new context allows the vane to save its state. The next time Arvo activates the vane it will have this context as its subject.
110+When a `++task` card is passed to a vane, Arvo calls its `++call` gate, passing it both the card and its duct. This gate must be defined in every vane. It produces two things in the following order: a list of moves and a possibly modified copy of its context. The moves are used to interact with other vanes, while the new context allows the vane to save its state. The next time Arvo activates the vane it will have this context as its subject.
111111
112−This overview has detailed how to pass a card to a particular vane. To see the cards each vane can be `%pass`ed as a `++kiss` or return as a `++gift` (as well as the semantics tied to them), each vane's public interface is explained in detail in its respective overview.
112+This overview has detailed how to pass a card to a particular vane. To see the cards each vane can be `%pass`ed as a `++task` or return as a `++gift` (as well as the semantics tied to them), each vane's public interface is explained in detail in its respective overview.
learn/arvo/ames.md+7−7
@@ -681,10 +681,10 @@ The packet, after its creation, embarks on a journey across physical
681681time and space into the great unknown. Hurtling through fiber-optic
682682cables at hundreds of thousands of kilometers per second, it finally
683683arrives at our neighbor's network adapter. The adapter tells unix, unix
684−tells libuv, libuv tells vere, and vere sends a `%hear` kiss to ames.
684+tells libuv, libuv tells vere, and vere sends a `%hear` task to ames.
685685And now we reenter the kernel.
686686
687−The `%hear` kiss goes straight to `++knob`, just as did the `%wont` kiss
687+The `%hear` task goes straight to `++knob`, just as did the `%wont` task
688688earlier.
689689
690690```
@@ -693,12 +693,12 @@ earlier.
693693```
694694
695695Here, though, we call `++gnaw:am` to process the packet. The arguments
696−to `++gnaw` are the same as those to the `%hear` kiss: the lane on which
696+to `++gnaw` are the same as those to the `%hear` task: the lane on which
697697the packet was received and the packet itself. The other argument is
698698just `%good`, which is a `++cape:ames` saying that we expect the packet to
699699succeed. If a formal error occurs, then since we have a transactional
700700event system, the `%hear` event will never be considered to have
701−actually happened, and unix will send a `%hole` kiss so that we may send
701+actually happened, and unix will send a `%hole` task so that we may send
702702a negative acknowledgment.
703703
704704```
@@ -929,7 +929,7 @@ Forwarding is the simplest case, since we've seen all the arms before,
929929except perhaps `++emit` and `++emir`, which simply take a boon or list
930930of boons respectively and queue them up to be handled when the core
931931resolves. If we're told to forward a packet to ourselves, then we emit a
932−`%mead` boon which simply sends another `%hear` kiss to ourselves with
932+`%mead` boon which simply sends another `%hear` task to ourselves with
933933the data. Otherwise, we try to find a route to the recipient, as before.
934934
935935```
@@ -1278,9 +1278,9 @@ The weary traveler is seeking out its familial roots, finding the app
12781278from whom sprung forth the original message way back in paragraph three.
12791279When it arrives at the network adapter of its ancestors, the adapter
12801280tells unix, unix tells libuv, libuv tells vere, and vere sends a `%hear`
1281−kiss to ames. Once more into the kernel.
1281+task to ames. Once more into the kernel.
12821282
1283−The `%hear` kiss is handled in `++knob` as before, leading to `++gnaw`,
1283+The `%hear` task is handled in `++knob` as before, leading to `++gnaw`,
12841284going over to `++chew`, `++apse`, `++chow`, and eventualy to `++dine`.
12851285We've seen most of the cases in `++dine`, but we haven't yet looked at
12861286the handling of this `%buck` meal.
learn/arvo/eyre.md+3−3
@@ -50,10 +50,10 @@ browser to server to browser and back.
5050### Initial request
5151
5252An http request for `http://sampel-sipnym.urbit.org/cli` will be [redirected](dns)
53−to the `%eyre` on ~sampel-sipnym, and come in as a `%this` kiss.
53+to the `%eyre` on ~sampel-sipnym, and come in as a `%this` task.
5454
5555From arvo, requests enter `++call`, which after some type reification are passed
56−along to `++apex:ye`. In the case of a `%this` kiss, its components are
56+along to `++apex:ye`. In the case of a `%this` task, its components are
5757parsed(see `++zest:epur`, `++eat-headers`) and handed off to `++handle`, wrapped
5858in `++emule` to produce a `++fail` page in case of error. `++apex:handle` will
5959`++process` the request to a `pest` or a `++done` core, and in the former case
@@ -295,7 +295,7 @@ This document outlines the following:
295295
2962962. [the values stored on the client](#client), both statically in cookies and dynamically as the `window.urb` object, which facilitate this transaction.
297297
298−3. [`kiss`](#kiss), the requests `%eyre` will accept.
298+3. [`task`](#task), the requests `%eyre` will accept.
299299
3003004. [`gift`](#gift), the responses it will give to those requests.
301301
learn/arvo/gall.md+1−1
@@ -755,7 +755,7 @@ code quoted above includes a bunch of otherwise unnecessary faces for
755755the purpose of illustration. Compare: `[%hiss p=(unit user) q=mark
756756r=cage]` from `zuse`.
757757
758−> You can grep zuse.hoon and arvo.hoon for most of these definitions. However, beware the ambiguity surrounding "hiss": there's ++hiss in section 3bI of `zuse` ("Arvo structures"), and there's `%hiss` the move that is sent to %eyre to make our HTTP request happen. Here we're talking about the latter. See `++kiss-eyre` in `zuse`.
758+> You can grep zuse.hoon and arvo.hoon for most of these definitions. However, beware the ambiguity surrounding "hiss": there's ++hiss in section 3bI of `zuse` ("Arvo structures"), and there's `%hiss` the move that is sent to %eyre to make our HTTP request happen. Here we're talking about the latter. See `++task:able:eyre` in `zuse`.
759759
760760> Recall that `++unit` means "maybe". Formally, "`(unit a)` is either null or a pair of null and a value in `a`". Also recall that to pull a value out of a unit (`u.unit`), you must first verify that the unit is not null (for example with `?~`). See `++need`.
761761