File 2188-Correct-spelling-of-behaviour-and-time-out.patch of Package erlang

From 2316d3b1e8970572f9349c424825db152044d3e0 Mon Sep 17 00:00:00 2001
From: Raimo Niskanen <raimo@erlang.org>
Date: Tue, 10 Mar 2020 16:38:37 +0100
Subject: [PATCH 2/2] Correct spelling of 'behaviour' and 'time-out'

---
 system/doc/design_principles/statem.xml | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/system/doc/design_principles/statem.xml b/system/doc/design_principles/statem.xml
index 07030ed46d..06bffc72ee 100644
--- a/system/doc/design_principles/statem.xml
+++ b/system/doc/design_principles/statem.xml
@@ -22,7 +22,7 @@
 
     </legalnotice>
 
-    <title>gen_statem Behavior</title>
+    <title>gen_statem Behaviour</title>
     <prepared></prepared>
     <docno></docno>
     <date></date>
@@ -84,12 +84,12 @@ State(S) x Event(E) -> Actions(A), State(S')</pre>
       (see, for example, the Wikipedia article "Mealy machine").
     </p>
     <p>
-      Like most <c>gen_</c> behaviors, <c>gen_statem</c> keeps
+      Like most <c>gen_</c> behaviours, <c>gen_statem</c> keeps
       a server <c>Data</c> besides the state. Because of this, and as
       there is no restriction on the number of states
       (assuming that there is enough virtual machine memory)
       or on the number of distinct input events,
-      a state machine implemented with this behavior
+      a state machine implemented with this behaviour
       is in fact Turing complete.
       But it feels mostly like an Event-Driven Mealy machine.
     </p>
@@ -191,7 +191,7 @@ State(S) x Event(E) -> Actions(A), State(S')</pre>
     <marker id="Callback Modes" />
     <title>Callback Modes</title>
     <p>
-      The <c>gen_statem</c> behavior supports two <em>callback modes</em>:
+      The <c>gen_statem</c> behaviour supports two <em>callback modes</em>:
     </p>
     <taglist>
       <tag>
@@ -788,7 +788,7 @@ State(S) x Event(E) -> Actions(A), State(S')</pre>
     <marker id="State Enter Calls" />
     <title>State Enter Calls</title>
     <p>
-      The <c>gen_statem</c> behavior can if this is enabled,
+      The <c>gen_statem</c> behaviour can if this is enabled,
       regardless of <em>callback mode</em>,
       automatically
       <seealso marker="stdlib:gen_statem#type-state_enter">
@@ -890,7 +890,7 @@ StateName(EventType, EventContent, Data) ->
 	<seealso marker="#Postponing Events">postponed </seealso>
 	and
 	<seealso marker="#Inserted Events">inserted</seealso>
-	events cancel this timeout just as external events.
+	events cancel this time-out just as external events.
       </item>
     </taglist>
     <p>
@@ -966,7 +966,7 @@ StateName(EventType, EventContent, Data) ->
 	<seealso marker="#Postponing Events">postponing</seealso>
 	an event in a <em>state change</em> with starting an
 	<seealso marker="#Event Time-Outs">event time-out</seealso>
-	with time <c>0</c> there will be no timeout event inserted
+	with time <c>0</c> there will be no time-out event inserted
 	since the event time-out is cancelled by the postponed
 	event that is delivered due to the state change.
       </p>
@@ -1848,7 +1848,7 @@ do_unlock() ->
       as the receive statement is within the <c>gen_*</c> engine itself.
       It must be there because all
       <seealso marker="stdlib:sys"><c>sys</c></seealso>
-      compatible behaviors must respond to system messages and therefore
+      compatible behaviours must respond to system messages and therefore
       do that in their engine receive loop,
       passing non-system messages to the <em>callback module</em>.
     </p>
-- 
2.16.4

openSUSE Build Service is sponsored by