Action doc commit

Author: clojure-build

docs/flow-guide.html

@@ -18,11 +18,11 @@ <h3><a href="#describe-step-fn-descriptor" id="describe-step-fn-descriptor"></a>
 <h3><a href="#init-step-fn-arg-map-init-state" id="init-step-fn-arg-map-init-state"></a>init: <code>(step-fn arg-map) -&gt; init-state</code></h3>
 <p>The init arity is called once by the process to takes a set of args from the flow def (corresponding to the params returned from the describe arity) and returns the init state of the process.</p>
 <h3><a href="#transition-step-fn-state-transition-state" id="transition-step-fn-state-transition-state"></a>transition: <code>(step-fn state transition) -&gt; state'</code></h3>
-<p>The transition arity is called any time the flow or process undergoes a lifecycle transition (::flow/start, ::flow/stop, ::flow/pause, ::flow/resume). The description arity takes the current state and returns an updated state to be used for subsequent calls.</p>
+<p>The transition arity is called any time the flow or process undergoes a lifecycle transition (::flow/start, ::flow/stop, ::flow/pause, ::flow/resume). The transition arity takes the current state and returns an updated state to be used for subsequent calls.</p>
 <p>The step-fn should use the transition arity to coordinate the creation, pausing, and shutdown of external resources in a process.</p>
 <h3><a href="#transform-step-fn-state-input-msg-state-out-id-msgs" id="transform-step-fn-state-input-msg-state-out-id-msgs"></a>transform: <code>(step-fn state input msg) -&gt; [state' {out-id [msgs]}]</code></h3>
 <p>The transform arity is called in a loop by the process for every message received on an input channel and returns a new state and a map of output cids to messages to return. The process will take care of sending these messages to the output channels. Output can be sent to none, any or all of the :outsenumerated, and/or an input named by a <a href="pid inid">pid inid</a> tuple (e.g. for reply-to), and/or to the ::flow/report output. A step need not output at all (output or msgs can be empyt/nil), however an output <em>message</em> may never be nil (per core.async channels).</p>
-<p>The step-fn may throw excepitons from any arity and they will be handled by flow. Exceptions thrown from the transition or transform arities, the exception will be logged on the flow’s :error-chan.</p>
+<p>The step-fn may throw exceptions from any arity and they will be handled by flow. If exceptions are thrown from the transition or transform arities, the exception will be logged on the flow’s :error-chan.</p>
 <h3><a href="#process-state" id="process-state"></a>Process state</h3>
 <p>The process state is a map. It can contain any keys needed by the step-fn transition and transform arities. In addition, there are some flow-specific keys, described here.</p>
 <p><code>::flow/pid</code> is added to the state by the process based on the name supplied in the flow def.</p>
@@ -41,7 +41,7 @@ <h3><a href="#creating-a-process-launcher" id="creating-a-process-launcher"></a>
 <li><code>::workload</code> - one of <code>:mixed</code>, <code>:io</code> or <code>:compute</code></li>
 <li><code>:compute-timeout-ms</code> - if :workload is :compute, this timeout (default 5000 msec) will be used when getting the return from the future - see below</li>
 </ul>
-<p>A :workload supplied as an option to <code>process</code> will override any :workload returned by the :describe fn of the process launcher. If neither are provded the default is :mixed.</p>
+<p>A :workload supplied as an option to <code>process</code> will override any :workload returned by the :describe fn of the process launcher. If neither are provided the default is :mixed.</p>
 <p>In the :workload context of :mixed or :io, this dictates the type of thread in which the process loop will run, <em>including its calls to transform</em>.</p>
 <p>When :io is specified, transform should not do extensive computation.</p>
 <p>When :compute is specified, each call to transform will be run in a separate thread. The process loop will run in an :io context (since it no longer directly calls transform, all it does is I/O) and it will submit transform to the :compute executor then await (blocking, for compute-timeout-ms) the completion of the future returned by the executor. If the future times out it will be reported on ::flow/error.</p>