Fix mistakes

doc/asymmetric.qbk

@@ -16,7 +16,7 @@ unidirectional transfer of data.
 __pull_coro__ transfers data from another execution context (== pulled-from).
 The template parameter defines the transferred parameter type.
 The constructor of __pull_coro__ takes a function (__coro_fn__) accepting a
-reference to an __push_coro__ as argument. Instantiating an __pull_coro__ passes
+reference to a __push_coro__ as argument. Instantiating a __pull_coro__ passes
 the control of execution to __coro_fn__ and a complementary __push_coro__ is
 synthesized by the library and passed as reference to __coro_fn__.
 
@@ -47,12 +47,12 @@ are overloaded. The increment-operation switches the context and transfers data.
         output:
         1 1 2 3 5 8 13 21 34 55
 
-In this example an __pull_coro__ is created in the main execution context taking
+In this example a __pull_coro__ is created in the main execution context taking
 a lambda function (== __coro_fn__) which calculates Fibonacci numbers in a
 simple ['for]-loop.
 The __coro_fn__ is executed in a newly created execution context which is
 managed by the instance of __pull_coro__.
-An __push_coro__ is automatically generated by the library and passed as
+A __push_coro__ is automatically generated by the library and passed as
 reference to the lambda function. Each time the lambda function calls
 __push_coro_op__ with another Fibonacci number, __push_coro__ transfers it back
 to the main execution context. The local state of __coro_fn__ is preserved and
@@ -67,8 +67,8 @@ Fibonacci numbers.
 __push_coro__ transfers data to the other execution context (== pushed-to).
 The template parameter defines the transferred parameter type.
 The constructor of __push_coro__ takes a function (__coro_fn__) accepting a
-reference to an __pull_coro__ as argument. In contrast to __pull_coro__,
-instantiating an __push_coro__ does not pass the control of execution to
+reference to a __pull_coro__ as argument. In contrast to __pull_coro__,
+instantiating a __push_coro__ does not pass the control of execution to
 __coro_fn__ - instead the first call of __push_coro_op__ synthesizes a
 complementary __pull_coro__ and passes it as reference to __coro_fn__.
 
@@ -119,7 +119,7 @@ and transfers data.
                    cold           peas       porridge             in            the
                     pot           nine           days            old
 
-In this example an __push_coro__ is created in the main execution context
+In this example a __push_coro__ is created in the main execution context
 accepting a lambda function (== __coro_fn__) which requests strings and lays out
 'num' of them on each line.
 This demonstrates the inversion of control permitted by coroutines. Without
@@ -132,7 +132,7 @@ The __coro_fn__ is executed in a newly created execution context which is
 managed by the instance of __push_coro__.
 The main execution context passes the strings to the __coro_fn__ by calling
 __push_coro_op__.
-An __pull_coro__ instance is automatically generated by the library and passed as
+A __pull_coro__ instance is automatically generated by the library and passed as
 reference to the lambda function. The __coro_fn__ accesses the strings passed
 from the main execution context by calling __pull_coro_get__ and lays those
 strings out on ['std::cout] according the parameters 'num' and 'width'.
@@ -159,8 +159,8 @@ available.
 
 
 [heading passing data from a pull-coroutine to main-context]
-In order to transfer data from an __pull_coro__ to the main-context the framework
-synthesizes an __push_coro__ associated with the __pull_coro__ instance in the
+In order to transfer data from a __pull_coro__ to the main-context the framework
+synthesizes a __push_coro__ associated with the __pull_coro__ instance in the
 main-context. The synthesized __push_coro__ is passed as argument to __coro_fn__.
 The __coro_fn__ must call this __push_coro_op__ in order to transfer each
 data value back to the main-context.
@@ -188,8 +188,8 @@ data value is given by __pull_coro_get__.
 
 
 [heading passing data from main-context to a push-coroutine]
-In order to transfer data to an __push_coro__ from the main-context the framework
-synthesizes an __pull_coro__ associated with the __push_coro__ instance in the
+In order to transfer data to a __push_coro__ from the main-context the framework
+synthesizes a __pull_coro__ associated with the __push_coro__ instance in the
 main-context. The synthesized __pull_coro__ is passed as argument to __coro_fn__.
 The main-context must call this __push_coro_op__ in order to transfer each data
 value into the __coro_fn__.
@@ -231,13 +231,13 @@ __pull_coro__ has values and __coro_fn__ has not terminated.
 
 
 [heading exceptions]
-An exception thrown inside an __pull_coro__'s __coro_fn__ before its first call
-to __push_coro_op__ will be re-thrown by the __pull_coro__ constructor. After an
+An exception thrown inside a __pull_coro__'s __coro_fn__ before its first call
+to __push_coro_op__ will be re-thrown by the __pull_coro__ constructor. After a
 __pull_coro__'s __coro_fn__'s first call to __push_coro_op__, any subsequent
 exception inside that __coro_fn__ will be re-thrown by __pull_coro_op__.
 __pull_coro_get__ does not throw.
 
-An exception thrown inside an __push_coro__'s __coro_fn__ will be re-thrown by
+An exception thrown inside a __push_coro__'s __coro_fn__ will be re-thrown by
 __push_coro_op__.
 
 [important Code executed by __coro_fn__ must not prevent the propagation of the
@@ -253,7 +253,7 @@ pending __forced_unwind__ exception.]
             // possibly not re-throw pending exception
         }
 
-[important Do not jump from inside a catch block and than re-throw the
+[important Do not jump from inside a catch block and then re-throw the
 exception in another execution context.]
 
 
@@ -341,9 +341,9 @@ __pull_coro__ can be used via input-iterators using __begin__ and __end__.
 ['coroutine<>::pull_type::iterator::operator++()] corresponds to
 __pull_coro_op__; ['coroutine<>::pull_type::iterator::operator*()]
 roughly corresponds to __pull_coro_get__. An iterator originally obtained from
-__begin__ of an __pull_coro__ compares equal to an iterator obtained from
+__begin__ of a __pull_coro__ compares equal to an iterator obtained from
 __end__ of that same __pull_coro__ instance when its __pull_coro_bool__ would
-return `false`].
+return `false`.
 
 [note If `T` is a move-only type, then
 ['coroutine<T>::pull_type::iterator] may only be dereferenced once
@@ -366,7 +366,7 @@ Output-iterators can be created from __push_coro__.
 
 ['coroutine<>::push_type::iterator::operator*()] roughly
 corresponds to __push_coro_op__. An iterator originally obtained from
-__begin__ of an __push_coro__ compares equal to an iterator obtained from
+__begin__ of a __push_coro__ compares equal to an iterator obtained from
 __end__ of that same __push_coro__ instance when its __push_coro_bool__ would
 return `false`.
 
@@ -377,7 +377,7 @@ routine. The __pull_coro__, __push_coro__ becomes complete, e.g. __pull_coro_boo
 __push_coro_bool__ will return `false`.
 
 [important After returning from __coro_fn__ the __coro__ is complete (can not
-resumed with __push_coro_op__, __pull_coro_op__).]
+be resumed with __push_coro_op__, __pull_coro_op__).]
 
 
 
@@ -623,7 +623,7 @@ has returned (completed), the function returns `true`. Otherwise `false`.]]
     range_iterator< push_type< Arg > >::type end( push_type< Arg > &);
 
 [variablelist
-[[Returns:] [Returns a end range-iterator (output-iterator).]]
+[[Returns:] [Returns an end range-iterator (output-iterator).]]
 [[Note:] [When first obtained from `begin( push_type< R > &)`, or after some
 number of increment operations, an iterator will compare equal to the iterator
 returned by `end( push_type< R > &)` when the corresponding __push_coro_bool__

doc/intro.qbk

@@ -13,7 +13,7 @@ In computer science routines are defined as a sequence of operations. The
 execution of routines forms a parent-child relationship and the child terminates
 always before the parent. Coroutines (the term was introduced by Melvin
 Conway [footnote Conway, Melvin E.. "Design of a Separable Transition-Diagram Compiler".
-Commun. ACM, Volume 6 Issue 7, July 1963, Article No. 7]),
+Commun. ACM, Volume 6 Issue 7, July 1963, Article No. 7])
 are a generalization of routines (Donald Knuth [footnote Knuth, Donald Ervin (1997).
 "Fundamental Algorithms. The Art of Computer Programming 1", (3rd ed.)]).
 The principal difference between coroutines and routines

doc/stack.qbk

@@ -117,13 +117,13 @@ end of each stack. The memory is managed internally by
 [variablelist
 [[Preconditions:] [`! traits_type::is_unbounded() && ( traits_type::maximum:size() >= stack_size)`
 and `0 < nest_size`.]]
-[[Effects:] [Allocates memory of at least `stack_size` Bytes and stores a pointer to
+[[Effects:] [Allocates memory of at least `stack_size` bytes and stores a pointer to
 the stack and its actual size in `sctx`. Depending on the architecture (the
 stack grows downwards/upwards) the stored address is the highest/lowest
 address of the stack. Argument `next_size` determines the number of stacks to
 request from the system the first time that `*this` needs to allocate system
-memory. The third argument `max_size` controls how many memory might be
-allocated for stacks - a value of zero means no uper limit.]]
+memory. The third argument `max_size` controls how much memory might be
+allocated for stacks - a value of zero means no upper limit.]]
 ]
 
 [heading `stack_context allocate()`]
@@ -167,7 +167,7 @@ end of each stack. The memory is simply managed by `std::malloc()` and
 [variablelist
 [[Preconditions:] [`traits_type::minimum:size() <= size` and
 `! traits_type::is_unbounded() && ( traits_type::maximum:size() >= size)`.]]
-[[Effects:] [Allocates memory of at least `size` Bytes and stores a pointer to
+[[Effects:] [Allocates memory of at least `size` bytes and stores a pointer to
 the stack and its actual size in `sctx`. Depending on the architecture (the
 stack grows downwards/upwards) the stored address is the highest/lowest
 address of the stack.]]
@@ -237,7 +237,7 @@ available stack allocator.]
 [section:stack_traits Class ['stack_traits]]
 
 ['stack_traits] models a __stack_traits__ providing a way to access certain
-properites defined by the enironment. Stack allocators use __stack_traits__ to
+properties defined by the environment. Stack allocators use __stack_traits__ to
 allocate stacks.
 
         struct stack_traits
@@ -326,7 +326,7 @@ structures.
 [section:valgrind Support for valgrind]
 
 Running programs that switch stacks under valgrind causes problems.
-Property (b2 command-line) `valgrind=on` let valgrind treat the memory regions
+Property (b2 command-line) `valgrind=on` lets valgrind treat the memory regions
 as stack space which suppresses the errors.
 
 [endsect]
@@ -336,7 +336,7 @@ as stack space which suppresses the errors.
 
 Sanitizers (GCC/Clang) are confused by the stack switches.
 The library (and Boost.Context too) is required to be compiled with property (b2 command-line)
-`context-impl=ucontext` and compilers santizer options.
+`context-impl=ucontext` and compilers sanitizer options.
 Users must define `BOOST_USE_ASAN` before including any Boost.Context headers
 when linking against Boost binaries.