Merge pull request #68 from dwrensha/typo

fix typos and inconsistencies

c++/src/capnp/capability.h

@@ -347,7 +347,7 @@ public:
   virtual VoidPromiseAndPipeline call(uint64_t interfaceId, uint16_t methodId,
                                       kj::Own<CallContextHook>&& context) = 0;
   // Call the object, but the caller controls allocation of the request/response objects.  If the
-  // callee insists on allocating this objects itself, it must make a copy.  This version is used
+  // callee insists on allocating these objects itself, it must make a copy.  This version is used
   // when calls come in over the network via an RPC system.  During the call, the context object
   // may be used from any thread so long as it is only used from one thread at a time.  Note that
   // even if the returned `Promise<void>` is discarded, the call may continue executing if any

c++/src/capnp/rpc.capnp

@@ -425,7 +425,7 @@ struct Finish {
   # 3) If the call has not returned yet, the caller no longer cares about the result.  If nothing
   #    else cares about the result either (e.g. there are to other outstanding calls pipelined on
   #    the result of this one) then the callee may wish to immediately cancel the operation and
-  #    send back a Return message with "canceled" set.  However, implementations are not requried
+  #    send back a Return message with "canceled" set.  However, implementations are not required
   #    to support premature cancellation -- instead, the implementation may wait until the call
   #    actually completes and send a normal `Return` message.
   #
@@ -935,9 +935,9 @@ struct PromisedAnswer {
       #   a SQL table join (not to be confused with the `Join` message type).
       # - Maybe some ability to test a union.
       # - Probably not a good idea:  the ability to specify an arbitrary script to run on the
-      #   result.  We could define a little stack-based language where `PathPart` specifies one
+      #   result.  We could define a little stack-based language where `Op` specifies one
       #   "instruction" or transformation to apply.  Although this is not a good idea
-      #   (over-engineered), any narrower additions to `PathPart` should be designed as if this
+      #   (over-engineered), any narrower additions to `Op` should be designed as if this
       #   were the eventual goal.
     }
   }

c++/src/kj/async-inl.h

@@ -98,7 +98,7 @@ public:
   // `armBreadthFirst()`.  (Promise::then() uses depth-first whereas evalLater() uses
   // breadth-first.)
   //
-  // To use breadth-first scheduling instead, use `armLater()`.
+  // To use breadth-first scheduling instead, use `armBreadthFirst()`.
 
   void armBreadthFirst();
   // Like `armDepthFirst()` except that the event is placed at the end of the queue.

doc/roadmap.md

@@ -39,7 +39,7 @@ Provisionally, these are probably the things that will be worked on after 0.5.
 ## Before version 1.0
 
 These things absolutely must happen before any 1.0 release.  Note that it's not yet decided when
-a 1.0 release would happen nor how many 0.x release might precede it.
+a 1.0 release would happen nor how many 0.x releases might precede it.
 
 * **Expand test coverage:**  There are lots of tests now, but some important scenarios, such as
   handling invalid of invalid input, need better testing.