Fix doc typos.

peterhinch · peterhinch · commit 117188f78192 · 2019-02-24T12:01:03.000Z
diff --git a/FASTPOLL.md b/FASTPOLL.md
@@ -40,7 +40,7 @@ changes should be minimal.
 #### Changes incompatible with prior versions
 
 V0.24  
-The `version` bound variable now retuens a 2-tuple.
+The `version` bound variable now returns a 2-tuple.
 
 Prior versions.  
 The high priority mechanism formerly provided in `asyncio_priority.py` was a
diff --git a/README.md b/README.md
@@ -120,10 +120,10 @@ employ stream I/O. To operate at low latency they are simply run under the
 has details of how to write streaming drivers.
 
 The current `fast_io` version 0.24 fixes an issue with task cancellation and
-timeouts. In version 2.0, where a coroutine is waiting on a `sleep()` or on
-I/O, a timeout or cancellation are deferred until the coroutine is next
-scheduled. This introduces uncertainty into when the coroutine is stopped. This
-issue is also addressed in Paul Sokolovsky's fork.
+timeouts. In `uasyncio` version 2.0, where a coroutine is waiting on a
+`sleep()` or on I/O, a timeout or cancellation is deferred until the coroutine
+is next scheduled. This introduces uncertainty into when the coroutine is
+stopped. This issue is also addressed in Paul Sokolovsky's fork.
 
 ## 4.1 A Pyboard-only low power module
 
diff --git a/TUTORIAL.md b/TUTORIAL.md
@@ -32,7 +32,7 @@ asyncio and includes a section for complete beginners.
    4.1.2 [Awaiting a coro](./TUTORIAL.md#412-awaiting-a-coro)  
   4.2 [Asynchronous iterators](./TUTORIAL.md#42-asynchronous-iterators)  
   4.3 [Asynchronous context managers](./TUTORIAL.md#43-asynchronous-context-managers)  
- 5 [Exceptions timeouts and cancellation](./TUTORIAL.md#45-exceptions-timeouts-and-cancellation)  
+ 5. [Exceptions timeouts and cancellation](./TUTORIAL.md#5-exceptions-timeouts-and-cancellation)  
   5.1 [Exceptions](./TUTORIAL.md#51-exceptions)  
   5.2 [Cancellation and Timeouts](./TUTORIAL.md#52-cancellation-and-timeouts)  
    5.2.1 [Task cancellation](./TUTORIAL.md#521-task-cancellation)  
@@ -892,10 +892,11 @@ is complete.
 There is currently a wokround and two solutions.
  * Workround: the `asyn` library provides means of waiting on cancellation of
  tasks or groups of tasks. See [Task Cancellation](./PRIMITIVES.md#4-task-cancellation).
- * Paul Sokolovsky's library fork provides `uasyncio` V2.4, but this requires
- his [Pycopy](https://github.com/pfalcon/micropython) firmware.
- * The `fast_io` fork also solves this (in a less elegant manner) and runs
- under official firmware.
+ * [Paul Sokolovsky's library fork](https://github.com/pfalcon/micropython-lib)
+ provides `uasyncio` V2.4, but this requires his
+ [Pycopy](https://github.com/pfalcon/micropython) firmware.
+ * The [fast_io](./FASTPOLL.md) fork of `uasyncio` solves this in Python (in a
+ less elegant manner) and runs under official firmware.
 
 The exception hierarchy used here is `Exception-CancelledError-TimeoutError`.
 
diff --git a/UNDER_THE_HOOD.md b/UNDER_THE_HOOD.md
@@ -102,7 +102,8 @@ b = my_coro.pend_throw(None)  # Coro can now safely be executed
 ```
 In the above instance `a` will be `None` if it was the first call to
 `pend_throw` and `b` will be 42. This is used to determine if a paused task is
-on a `timeq` or waiting on I/O.
+on a `timeq` or waiting on I/O. A task on a `timeq` will have an integer value,
+being the `ID` of the task; one pending I/O will have `False`.
 
 If a coro is actually run, the only acceptable stored values are `None` or an
 exception. The error "exception must be derived from base exception" indicates
@@ -241,9 +242,9 @@ time the coro is scheduled.
 In the `fast_io` version the `cancel` function puts the task onto `.runq` or
 `.ioq` for "immediate" excecution. In the case where the task is on `.waitq` or
 `.lpq` the task ID is added to a `set` `.canned`. When the task reaches the top
-of the timeq it is discarded. This pure Python approach is less efficient than
-that in the Paul Sokolovsky fork, but his approach uses a special version of
-the C `utimeq` object and so requires his firmware.
+of the timeq it is ignored and removed from `.canned`. This Python approach is
+less efficient than that in the Paul Sokolovsky fork, but his approach uses a
+special version of the C `utimeq` object and so requires his firmware.
 
 Timeouts use a similar mechanism.
 
