dcafdd5 · urbit.org · git.iko.soy

git.iko.soy/urbit.org

on master help sign in

kiss -> task

dcafdd5ryjm7 years ago

learn/arvo/_index.md+5−5

compare with master

unifiedsplit

@@ -101,12 +101,12 @@ As of this writing, we have seven vanes, which each provide the following servic

101

102### Cards

103

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.

105

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`.

107

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`.

109

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.

111

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

681time and space into the great unknown. Hurtling through fiber-optic

682cables at hundreds of thousands of kilometers per second, it finally

683arrives 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.

685And now we reenter the kernel.

686

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

688earlier.

689

690```

@@ -693,12 +693,12 @@ earlier.

693```

694

695Here, 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

697the packet was received and the packet itself. The other argument is

698just `%good`, which is a `++cape:ames` saying that we expect the packet to

699succeed. If a formal error occurs, then since we have a transactional

700event 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

702a negative acknowledgment.

703

704```

@@ -929,7 +929,7 @@ Forwarding is the simplest case, since we've seen all the arms before,

929except perhaps `++emit` and `++emir`, which simply take a boon or list

930of boons respectively and queue them up to be handled when the core

931resolves. 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

933the data. Otherwise, we try to find a route to the recipient, as before.

934

935```

@@ -1278,9 +1278,9 @@ The weary traveler is seeking out its familial roots, finding the app

1278from whom sprung forth the original message way back in paragraph three.

1279When it arrives at the network adapter of its ancestors, the adapter

1280tells 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.

1282

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`,

1284going over to `++chew`, `++apse`, `++chow`, and eventualy to `++dine`.

1285We've seen most of the cases in `++dine`, but we haven't yet looked at

1286the handling of this `%buck` meal.

learn/arvo/eyre.md+3−3

@@ -50,10 +50,10 @@ browser to server to browser and back.

50### Initial request

52An 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.

55From 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

57parsed(see `++zest:epur`, `++eat-headers`) and handed off to `++handle`, wrapped

58in `++emule` to produce a `++fail` page in case of error. `++apex:handle` will

59`++process` the request to a `pest` or a `++done` core, and in the former case

@@ -295,7 +295,7 @@ This document outlines the following:

295

2962. [the values stored on the client](#client), both statically in cookies and dynamically as the `window.urb` object, which facilitate this transaction.

297

298−3. [`kiss`](#kiss), the requests `%eyre` will accept.

298+3. [`task`](#task), the requests `%eyre` will accept.

299

3004. [`gift`](#gift), the responses it will give to those requests.

301

learn/arvo/gall.md+1−1

@@ -755,7 +755,7 @@ code quoted above includes a bunch of otherwise unnecessary faces for

755the purpose of illustration. Compare: `[%hiss p=(unit user) q=mark

756r=cage]` from `zuse`.

757

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`.

759

760> 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`.

761