Fixed typos in docs, based on Haim and Gidi's corrections

docs/source/BPjsTutorial/bp-object.rst

@@ -26,7 +26,7 @@ Creates an event with name and possible data object.
 ``bp.EventSet(name, predicate)``
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Creates and event set: basically a named predicate that accepts events and returns ``true`` for set members.
+Creates an event set: basically a named predicate that accepts events and returns ``true`` for set members.
 
 * ``name``: Name of the event set. String.
 * ``predicate``: The set membership predicate. Function that takes one parameter (event) and returns boolean.
@@ -57,7 +57,7 @@ Provides access to the logger. See :doc:`logging`.
 ``bp.random``
 ~~~~~~~~~~~~~
 
-provides an access to a random number generator, sporting the following methods:
+provides an access to a random number generator, supporting the following methods:
 
 * ``bp.random.nextFloat()``: Generate a random number between 0 and 1.
 * ``bp.random.nextInt(bound)``: Generate a random number between 0 (inclusive) and ``bound`` (non-inclusive).

docs/source/BPjsTutorial/dynamic-bthread-addition.rst

@@ -2,7 +2,7 @@
 Adding B-Threads Dynamically
 ==============================
 
-Let's count to 4 in an arbitrary order! That is, let's have 4 events, labeled ``e0`` to ``e3``, and not care about the order in which the occur. For this, we need four b-threads, each requesting a numbered event. But since they all do the same, we might want to create them from a loop, like so:
+Let's count to 4 in an arbitrary order! That is, let's have 4 events, labeled ``e0`` to ``e3``, and not care about the order in which they occur. For this, we need four b-threads, each requesting a numbered event. But since they all do the same, we might want to create them from a loop, like so:
 
 .. literalinclude:: code/dynamic-bthread-bad.js
   :linenos:

docs/source/BPjsTutorial/hello-world.rst

@@ -25,7 +25,7 @@ The "Hello, World" version below (:download:`source <code/hello-world-seq.js>`)
 
 This is not a very complicated example, but it does show a few basics worth mentioning. First, b-threads are normal javascript functions that take no parameters. They are added to the b-program using ``bp.registerBThread``. Note that the b-program is never explicitly started by the client code. Starting the b-program is done by BPjs for you.
 
-Lines 2 and 3 contains a very simple ``bp.sync`` statement, requesting an event. The events are created using the event factory ``bp.Event(...)``. This code uses the simple version of ``bp.Event``, passing the event name onely.
+Lines 2 and 3 contains a very simple ``bp.sync`` statement, requesting an event. The events are created using the event factory ``bp.Event(...)``. This code uses the simple version of ``bp.Event``, passing the event name only.
 We'll see more of ``bp.XXX`` and ``bp.sync`` soon, but first let's run this program and see what happens.
 
 

docs/source/BPjsTutorial/interrupts.rst

@@ -43,7 +43,7 @@ The "Oven" b-thread waits for a ``"Bake Start"`` event. When this event is selec
 
 The "baker" b-thread is a classic scenario, listing the stages of making a cake, once it's requested. Classic, except for the ``bp.sync`` at line 6, where the ``Cake Burnt`` event is declared to be interrupting. If, while waiting for the baking to complete, the cake burns, the baker terminates. Which is preferable to decorating and serving a burnt cake.
 
-.. note:: Interrupting events do not add new capabilities to BP. The can be modeled by adding them as a ``waitFor`` parameter to ``bp.sync``, and then examining whether it is a member of the interrupting event set. Still, declaring event as *interrupting* adds declarative expressiveness (which, in turn, aids program analysis), and is more convenient.
+.. note:: Interrupting events do not add new capabilities to BP. This can be modeled by adding them as a ``waitFor`` parameter to ``bp.sync``, and then examining whether it is a member of the interrupting event set. Still, declaring event as *interrupting* adds declarative expressiveness (which, in turn, aids program analysis), and is more convenient.
 
 Here's the output of an unsuccessful baking attempt:
 
@@ -71,9 +71,9 @@ Here's the output of an unsuccessful baking attempt:
 Final Acts of an Interrupted B-Thread
 --------------------------------------
 
-A b-thread can specify a handler function for interrupting events. This functions gets the interrupting event as a parameter.
+A b-thread can specify a handler function for interrupting events. If the b-thread is interrupted, that function is invoked, with the interrupting event as a parameter.
 
-The function can be used for clean up and logging, but as it is *not executed as a b-thread*, it **cannot call ``bp.sync``**. It can, however, enqueue events externally. Let's revisit the last example, and add enqueue a "sorry, no cake" event to inform the customer (:download:`source <code/interrupts-handler.js>`).
+The function can be used for clean up and logging, but as it is *not executed as a b-thread*, it **cannot call ``bp.sync``**. It can, however, enqueue events externally. Let's revisit the last example, and enqueue a "sorry, no cake" event to inform the customer (:download:`source <code/interrupts-handler.js>`). The enqueued event is presented to the b-program as an external event; this is because the interrupt handler is external to the b-program (as it is not a b-thread).
 
 .. literalinclude:: code/interrupts-handler.js
   :linenos: