Fix various small typos in the OTP Design Principles

7 files changed, 35 insertions, 40 deletions

diff --git a/system/doc/design_principles/applications.xml b/system/doc/design_principles/applications.xml
index f576701051..32e4de237d 100644
--- a/system/doc/design_principles/applications.xml
+++ b/system/doc/design_principles/applications.xml
@@ -113,7 +113,7 @@ stop(_State) ->
 <list>
     <item><c>Application</c>, an atom, is the name of the application.
       The file must be named <c>Application.app</c>.</item>
-    <item>Each <c>Opt</c> is a tuple <c>{Key,Value}</c>, which define a
+    <item>Each <c>Opt</c> is a tuple <c>{Key,Value}</c>, which defines a
       certain property of the application. All keys are optional.
       Default values are used for any omitted keys.</item>
 </list>
@@ -187,7 +187,7 @@ ch_app:stop([])</code>
       <section>
           <title>Directory Structure Guidelines for a Development Environment</title>
           <p>Any directory structure for development will suffice as long as the released directory structure
-              adhere to the <seeguide marker="#app_dir_released">description below</seeguide>,
+              adheres to the <seeguide marker="#app_dir_released">description below</seeguide>,
               but it is encouraged that the same directory structure
               also be used in a development environment. The version number should be omitted from the
               application directory name since this is an artifact of the release step.
@@ -236,7 +236,7 @@ ch_app:stop([])</code>
               should target the <c>priv/lib</c> or <c>priv/bin</c> directories.</p>
           <p>The <c>priv</c> directory holds assets that the application needs during runtime. Executables should
               reside in <c>priv/bin</c> and dynamically-linked libraries should reside in <c>priv/lib</c>. Other assets
-              are free to reside within the <c>priv</c> directory but it is recommended it does so in a structured manner.</p>
+              are free to reside within the <c>priv</c> directory but it is recommended they do so in a structured manner.</p>
           <p>Source files from other languages that generate Erlang code, such as ASN.1 or Mibs, should be placed
               in directories, at the top level or in <c>src</c>, with the same name as the source language, for example
               <c>asn1</c> and <c>mibs</c>. Build artifacts should be placed in their respective language directory,
@@ -312,7 +312,7 @@ ch_app:stop([])</code>
       processes is the <em>application controller</em> process,
       registered as <c>application_controller</c>.</p>
     <p>All operations on applications are coordinated by the application
-      controller. It is interacted through the functions in
+      controller. It is interacted with through the functions in
       the module <c>application</c>, see the <c>application(3)</c>
       manual page in Kernel. In particular, applications can be
       loaded, unloaded, started, and stopped.</p>
diff --git a/system/doc/design_principles/des_princ.xml b/system/doc/design_principles/des_princ.xml
index 76ac6a0c99..f46532c3f2 100644
--- a/system/doc/design_principles/des_princ.xml
+++ b/system/doc/design_principles/des_princ.xml
@@ -11,7 +11,7 @@
       Licensed under the Apache License, Version 2.0 (the "License");
       you may not use this file except in compliance with the License.
       You may obtain a copy of the License at
- 
+
           http://www.apache.org/licenses/LICENSE-2.0
 
       Unless required by applicable law or agreed to in writing, software
@@ -19,7 +19,7 @@
       WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
       See the License for the specific language governing permissions and
       limitations under the License.
-    
+
     </legalnotice>
 
     <title>Overview</title>
@@ -193,7 +193,7 @@ handle_cast({free, Ch}, Chs) ->
     <p>In <c>ch1.erl</c> and <c>ch2.erl</c> above, the implementation
       of <c>channels/0</c>, <c>alloc/1</c>, and <c>free/2</c> has been
       intentionally left out, as it is not relevant to the example.
-      For completeness, one way to write these functions are given
+      For completeness, one way to write these functions is given
       below. This is an example only, a realistic
       implementation must be able to handle situations like running out
       of channels to allocate, and so on.</p>
@@ -288,4 +288,3 @@ free(Ch, {Alloc, Free} = Channels) ->
       <seeguide marker="release_handling">Release Handling</seeguide>.</p>
   </section>
 </chapter>
-
diff --git a/system/doc/design_principles/events.xml b/system/doc/design_principles/events.xml
index b5c7d53ef5..c2196c6758 100644
--- a/system/doc/design_principles/events.xml
+++ b/system/doc/design_principles/events.xml
@@ -11,7 +11,7 @@
       Licensed under the Apache License, Version 2.0 (the "License");
       you may not use this file except in compliance with the License.
       You may obtain a copy of the License at
- 
+
           http://www.apache.org/licenses/LICENSE-2.0
 
       Unless required by applicable law or agreed to in writing, software
@@ -19,7 +19,7 @@
       WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
       See the License for the specific language governing permissions and
       limitations under the License.
-    
+
     </legalnotice>
 
     <title>gen_event Behaviour</title>
@@ -45,7 +45,7 @@
       event handlers. For example, an event manager for handling errors
       can by default have a handler installed, which writes error
       messages to the terminal. If the error messages during a certain
-      period is to be saved to a file as well, the user adds another
+      period are to be saved to a file as well, the user adds another
       event handler that does this. When logging to the file is no
       longer necessary, this event handler is deleted.</p>
     <p>An event manager is implemented as a process and each event
@@ -239,4 +239,3 @@ code_change(OldVsn, State, Extra) ->
     {ok, NewState}</code>
   </section>
 </chapter>
-
diff --git a/system/doc/design_principles/release_handling.xml b/system/doc/design_principles/release_handling.xml
index 3f2c6872f4..d23e9732fc 100644
--- a/system/doc/design_principles/release_handling.xml
+++ b/system/doc/design_principles/release_handling.xml
@@ -11,7 +11,7 @@
       Licensed under the Apache License, Version 2.0 (the "License");
       you may not use this file except in compliance with the License.
       You may obtain a copy of the License at
- 
+
           http://www.apache.org/licenses/LICENSE-2.0
 
       Unless required by applicable law or agreed to in writing, software
@@ -19,7 +19,7 @@
       WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
       See the License for the specific language governing permissions and
       limitations under the License.
-    
+
     </legalnotice>
 
     <title>Release Handling</title>
@@ -493,13 +493,13 @@ handle_cast({free, Ch}, Chs) ->
     <p>This file does not need to be created manually, it can be
       generated by <c>systools:make_relup/3,4</c>. The relevant versions
       of the <c>.rel</c> file, <c>.app</c> files, and <c>.appup</c> files
-      are used as input. It is deducted which applications are to be
+      are used as input. It is deduced which applications are to be
       added and deleted, and which applications that must be upgraded
       and/or downgraded. The instructions for this are fetched from
       the <c>.appup</c> files and transformed into a single list of
       low-level instructions in the right order.</p>
     <p>If the <c>relup</c> file is relatively simple, it can be created
-      manually. It it only to contain low-level instructions.</p>
+      manually. It is only to contain low-level instructions.</p>
     <p>For details about the syntax and contents of the release upgrade
       file, see the <c>relup(4)</c> manual page in SASL.</p>
     <p><em>Example, continued from the previous section:</em> You have a
@@ -628,13 +628,13 @@ ok</pre>
     <p>The new release package now also contains version "2" of <c>ch_app</c>
       and the <c>relup</c> file:</p>
       <code type="none">
-% tar tf ch_rel-2.tar 
+% tar tf ch_rel-2.tar
 lib/kernel-2.9/ebin/kernel.app
 lib/kernel-2.9/ebin/application.beam
 ...
 lib/stdlib-1.12/ebin/stdlib.app
 lib/stdlib-1.12/ebin/beam_lib.beam
-...      
+...
 lib/sasl-1.10/ebin/sasl.app
 lib/sasl-1.10/ebin/sasl.beam
 ...
@@ -735,4 +735,3 @@ Module:config_change(Changed, New, Removed)</code>
       application callback module.</p>
   </section>
 </chapter>
-
diff --git a/system/doc/design_principles/release_structure.xml b/system/doc/design_principles/release_structure.xml
index 981886282a..9e2e8df9c6 100644
--- a/system/doc/design_principles/release_structure.xml
+++ b/system/doc/design_principles/release_structure.xml
@@ -11,7 +11,7 @@
       Licensed under the Apache License, Version 2.0 (the "License");
       you may not use this file except in compliance with the License.
       You may obtain a copy of the License at
- 
+
           http://www.apache.org/licenses/LICENSE-2.0
 
       Unless required by applicable law or agreed to in writing, software
@@ -19,7 +19,7 @@
       WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
       See the License for the specific language governing permissions and
       limitations under the License.
-    
+
     </legalnotice>
 
     <title>Releases</title>
@@ -105,7 +105,7 @@
     <title>Generating Boot Scripts</title>
     <p><c>systools</c> in the SASL application includes tools to
       build and check releases. The functions read the <c>rel</c> and
-      <c>.app</c> files and performs syntax and dependency checks.
+      <c>.app</c> files and perform syntax and dependency checks.
       The <c>systools:make_script/1,2</c> function is used to generate
       a boot script (see System Principles):</p>
     <pre>
@@ -130,7 +130,7 @@ ok</pre>
 Erlang (BEAM) emulator version 5.3
 
 Eshell V5.3  (abort with ^G)
-1> 
+1>
 =PROGRESS REPORT==== 13-Jun-2003::12:01:15 ===
           supervisor: {local,sasl_safe_sup}
              started: [{pid,&lt;0.33.0>},
@@ -320,4 +320,3 @@ $ROOT/...
     </section>
   </section>
 </chapter>
-
diff --git a/system/doc/design_principles/statem.xml b/system/doc/design_principles/statem.xml
index 8158416fb1..2d6ea27635 100644
--- a/system/doc/design_principles/statem.xml
+++ b/system/doc/design_principles/statem.xml
@@ -72,7 +72,7 @@ State(S) x Event(E) -> Actions(A), State(S')</pre>
       in which the new state <c>S'</c> is different from
       the current state <c>S</c>, where "different" means
       Erlang's strict inequality: <c>=/=</c>
-      also know as "does not match".
+      also known as "does not match".
       <c>gen_statem</c> does more things during <em>state changes</em>
       than during other <em>state transitions</em>.
     </p>
@@ -122,7 +122,7 @@ State(S) x Event(E) -> Actions(A), State(S')</pre>
 	<seeguide marker="#Inserted Events">
 	  Inserted Events
 	</seeguide>
-	(that is, events from the state machine to itself; 
+	(that is, events from the state machine to itself;
 	 for purely internal events in particular)
       </item>
       <item>
@@ -177,7 +177,7 @@ State(S) x Event(E) -> Actions(A), State(S')</pre>
     </p>
     <p>
       The behaviour engine holds the state machine state,
-      server data, timer references, a queue of posponed messages
+      server data, timer references, a queue of postponed messages
       and other metadata.  It receives all process messages,
       handles the system messages, and calls the <em>callback module</em>
       with machine specific events.
@@ -189,14 +189,14 @@ State(S) x Event(E) -> Actions(A), State(S')</pre>
       <seetype marker="stdlib:gen_statem#action"><c>{change_callback_module, NewModule}</c></seetype>,
       <seetype marker="stdlib:gen_statem#action"><c>{push_callback_module, NewModule}</c></seetype> or
       <seetype marker="stdlib:gen_statem#action"><c>pop_callback_module</c></seetype>.
-      Note that this is a pretty esotheric thing to do...
+      Note that this is a pretty esoteric thing to do...
       The origin for this feature is a protocol that after
       version negotiation branches off into quite different
       state machines depending on the protocol version.
       There <i>might</i> be other use cases.
       <i>Beware</i> that the new callback module
       completely replaces the previous behaviour module,
-      so all relevant callback functions has to handle
+      so all relevant callback functions have to handle
       the state and data from the previous callback module.
     </p>
   </section>
@@ -505,8 +505,8 @@ State(S) x Event(E) -> Actions(A), State(S')</pre>
 	</seemfa>
 	callback function is called before any
 	<seeguide marker="#State Callback"><em>state callback</em></seeguide>
-	is called.  This function behaves like an <em>state callback</em>
-	function, but gets its only argument <c>Args</c> from 
+	is called.  This function behaves like a <em>state callback</em>
+	function, but gets its only argument <c>Args</c> from
 	the <c>gen_statem</c>
 	<seemfa marker="stdlib:gen_statem#start/3">
 	  <c>start/3,4</c>
@@ -644,7 +644,7 @@ State(S) x Event(E) -> Actions(A), State(S')</pre>
 	</seetype>
       </tag>
       <item>
-	Generate the next event to handle, see section 
+	Generate the next event to handle, see section
 	<seeguide marker="#Inserted Events">Inserted Events</seeguide>.
       </item>
       <tag>
@@ -892,7 +892,7 @@ StateName(EventType, EventContent, Data) ->
     <p>
       You may repeat the <em>state enter call</em>
       using the <c>{repeat_state,...}</c>
-      return value from the 
+      return value from the
       <seeguide marker="#State Callback">state callback</seeguide>.
       In this case <c>OldState</c> will also be equal to the current state.
     </p>
@@ -1765,10 +1765,10 @@ open(cast, {button,_}, Data) ->
       Note that no time-out message will arrive after this (because the timer has been explicitly canceled),
       unless you have already postponed one earlier (see the next section),
       so ensure that you do not accidentally postpone such messages.
-      Also note that a time-out message may arrive during a **state callback** 
+      Also note that a time-out message may arrive during a <em>state callback</em>
       that is cancelling the timer, so you may have to read out
       such a message from the process mailbox, depending on
-      the return value from 
+      the return value from
       <seemfa marker="erts:erlang#cancel_timer/2"><c>erlang:cancel_timer(Tref)</c></seemfa>.
     </p>
     <p>
@@ -1829,7 +1829,7 @@ open(cast, {button,_}, Data) ->
       This is not important if you do not postpone events.
       But if you later decide to start postponing some events,
       then the design flaw of not having separate states
-      when they should be, might become a hard to find bug.
+      when they should be, might become a hard-to-find bug.
     </p>
 
     <section>
diff --git a/system/doc/design_principles/sup_princ.xml b/system/doc/design_principles/sup_princ.xml
index 7fb8ba39ea..60ec23466f 100644
--- a/system/doc/design_principles/sup_princ.xml
+++ b/system/doc/design_principles/sup_princ.xml
@@ -11,7 +11,7 @@
       Licensed under the Apache License, Version 2.0 (the "License");
       you may not use this file except in compliance with the License.
       You may obtain a copy of the License at
- 
+
           http://www.apache.org/licenses/LICENSE-2.0
 
       Unless required by applicable law or agreed to in writing, software
@@ -19,7 +19,7 @@
       WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
       See the License for the specific language governing permissions and
       limitations under the License.
-    
+
     </legalnotice>
 
     <title>Supervisor Behaviour</title>
@@ -466,7 +466,7 @@ supervisor:delete_child(Sup, Id)</code>
       <c>Id</c> is the value associated with the <c>id</c> key in
       the <seeguide marker="#spec">child specification</seeguide>.</p>
     <p>As with dynamically added child processes, the effects of
-      deleting a static child process is lost if the supervisor itself
+      deleting a static child process are lost if the supervisor itself
       restarts.</p>
   </section>
 
@@ -534,4 +534,3 @@ supervisor:terminate_child(Sup, Pid)</code>
       then terminates itself.</p>
   </section>
 </chapter>
-