doc: Reordering some paragraphs in the tutorial.

[8sync.git] / doc / 8sync-new-manual.org

diff --git a/doc/8sync-new-manual.org b/doc/8sync-new-manual.org
index 955e50ec28adf863dae86ed9f9f628c866d6f5bd..3c81bc8499d9bb665d73ba2db8276a28866a77c2 100644 (file)
--- a/doc/8sync-new-manual.org
+++ b/doc/8sync-new-manual.org
@@ -159,7 +159,7 @@ nothing is going to happen.
 We can run it like:
 
 #+BEGIN_SRC scheme
-(run-bot #:username "some-bot-username") ; be creative!
+(run-bot #:username "some-bot-name") ; be creative!
 #+END_SRC
 
 Assuming all the tubes on the internet are properly connected, you
@@ -253,24 +253,6 @@ so that /other/ actors may participate in communicating with IRC
 through our IRC bot.
 
 Anyway, our current message handler is simply too annoying.
-What would be much more interesting is if we could recognize
-when an actor could repeat messages /only/ when someone is speaking
-to it directly.
-Luckily this is an easy adjustment to make.
-
-#+BEGIN_SRC scheme
-  (define-method (handle-line (irc-bot <my-irc-bot>) speaker channel
-                              line emote?)
-    (define my-name (irc-bot-username irc-bot))
-    (define (looks-like-me? str)
-      (or (equal? str my-name)
-          (equal? str (string-concatenate (list my-name ":")))))
-    (when (looks-like-me?)
-      (<- (actor-id irc-bot) 'send-line channel
-          (format #f "Bawwwwk! ~a says: ~a" speaker line))))
-#+END_SRC
-
-This is relatively straightforward, but it isn't very interesting.
 What we would really like to do is have our bot respond to individual
 "commands" like this:
 
@@ -376,7 +358,7 @@ What cool commands can you add?
   At the time of writing, venture capital awash startups are trying to
   turn chatbots into "big business"... a strange (and perhaps absurd)
   thing given chat bots being a fairly mundane novelty amongst hackers
-  and teenagers everywhere in the 1990s.
+  and teenagers everywhere a few decades ago.
 
 ** Writing our own actors
 
@@ -544,7 +526,6 @@ which does not block the rest of the program from running.
 Let's try applying that to our own code by turning our manager
 into a micromanager.
 
-#+END_SRC
 #+BEGIN_SRC scheme
   ;;; Update this method
   (define (manager-assign-task manager message difficulty)
@@ -614,6 +595,20 @@ Of course, we need to update our worker accordingly as well.
 everywhere as we are in this program... that's just to make the
 examples more illustrative.)
 
+"<-reply" is what actually returns the information to the actor
+waiting on the reply.
+It takes as an argument the actor sending the message, the message
+it is in reply to, and the rest of the arguments are the "body" of
+the message.
+(If an actor handles a message that is being "waited on" but does not
+explicitly reply to it, an auto-reply with an empty body will be
+triggered so that the waiting actor is not left waiting around.)
+
+The last thing to note is the call to "self-destruct".
+This does what you might expect: it removes the actor from the hive.
+No new messages will be sent to it.
+Ka-poof!
+
 Running it is the same as before:
 
 #+BEGIN_SRC scheme
@@ -646,20 +641,6 @@ manager> Oh!  I guess you can go home then.
 worker> Whew!  Free at last.
 #+END_SRC
 
-"<-reply" is what actually returns the information to the actor
-waiting on the reply.
-It takes as an argument the actor sending the message, the message
-it is in reply to, and the rest of the arguments are the "body" of
-the message.
-(If an actor handles a message that is being "waited on" but does not
-explicitly reply to it, an auto-reply with an empty body will be
-triggered so that the waiting actor is not left waiting around.)
-
-The last thing to note is the call to "self-destruct".
-This does what you might expect: it removes the actor from the hive.
-No new messages will be sent to it.
-Ka-poof!
-
 ** Writing our own network-enabled actor
 
 So, you want to write a networked actor!