Merge branch 'bjorn/system-documentation'

* bjorn/system-documentation:
  Replace "lambda head" with "fun" in compiler warning
  Remove an historical note about fun representation before R6B
  Replace mention of a tuple fun with an external fun
  Update Interoperability Tutorial
  Update System Principles
  Update Erlang Reference Manual
  Update Getting Started
  Update Programming Examples
  Update OAM Principles
  Update Installation Guide
  Update Embedded Systems User's Guide
  Update Efficiency Guide
  Update Design Principles

1 files changed, 64 insertions, 22 deletions

diff --git a/system/doc/tutorial/c_port.xmlsrc b/system/doc/tutorial/c_port.xmlsrc
index 8579da8520..0631293237 100644
--- a/system/doc/tutorial/c_port.xmlsrc
+++ b/system/doc/tutorial/c_port.xmlsrc
@@ -4,7 +4,7 @@
 <chapter>
   <header>
     <copyright>
-      <year>2000</year><year>2013</year>
+      <year>2000</year><year>2015</year>
       <holder>Ericsson AB. All Rights Reserved.</holder>
     </copyright>
     <legalnotice>
@@ -28,16 +28,34 @@
     <rev></rev>
     <file>c_port.xml</file>
   </header>
-  <p>This is an example of how to solve the <seealso marker="example">example problem</seealso> by using a port.</p>
+  <p>This section outlines an example of how to solve the example
+    problem in the <seealso marker="example">previous section</seealso>
+    by using a port.</p>
+  <p>The scenario is illustrated in the following figure:</p>
   <image file="../tutorial/port.gif">
-    <icaption>Port Communication.</icaption>
+    <icaption>Port Communication</icaption>
   </image>
 
   <section>
     <title>Erlang Program</title>
-    <p>First of all communication between Erlang and C must be established by creating the port. The Erlang process which creates a port is said to be <em>the connected process</em> of the port. All communication to and from the port should go via the connected process. If the connected process terminates, so will the port (and the external program, if it is written correctly).</p>
-    <p>The port is created using the BIF <c>open_port/2</c> with <c>{spawn,ExtPrg}</c> as the first argument. The string <c>ExtPrg</c> is the name of the external program, including any command line arguments. The second argument is a list of options, in this case only <c>{packet,2}</c>. This option says that a two byte length indicator will be used to simplify the communication between C and Erlang. Adding the length indicator will be done automatically by the Erlang port, but must be done explicitly in the external C program.</p>
-    <p>The process is also set to trap exits which makes it possible to detect if the external program fails.</p>
+    <p>All communication between Erlang and C must be established by
+      creating the port. The Erlang process that creates a port is
+      said to be <em>the connected process</em> of the port. All
+      communication to and from the port must go through the connected
+      process. If the connected process terminates, the port also
+      terminates (and the external program, if it is written
+      properly).</p>
+    <p>The port is created using the BIF <c>open_port/2</c> with
+      <c>{spawn,ExtPrg}</c> as the first argument. The string
+      <c>ExtPrg</c> is the name of the external program, including any
+      command line arguments. The second argument is a list of
+      options, in this case only <c>{packet,2}</c>. This option says
+      that a 2 byte length indicator is to be used to simplify the
+      communication between C and Erlang. The Erlang port
+      automatically adds the length indicator, but this must be done
+      explicitly in the external C program.</p>
+    <p>The process is also set to trap exits, which enables detection
+      of failure of the external program:</p>
     <pre>
 -module(complex1).
 -export([start/1, init/1]).
@@ -50,7 +68,9 @@ init(ExtPrg) ->
   process_flag(trap_exit, true),
   Port = open_port({spawn, ExtPrg}, [{packet, 2}]),
   loop(Port).</pre>
-    <p>Now it is possible to implement <c>complex1:foo/1</c> and <c>complex1:bar/1</c>. They both send a message to the <c>complex</c> process and receive the reply.</p>
+    <p>Now <c>complex1:foo/1</c> and <c>complex1:bar/1</c> can be
+      implemented. Both send a message to the <c>complex</c> process
+      and receive the following replies:</p>
     <pre>
 foo(X) ->
   call_port({foo, X}).
@@ -63,7 +83,14 @@ call_port(Msg) ->
     {complex, Result} ->
       Result
   end.</pre>
-    <p>The <c>complex</c> process encodes the message into a sequence of bytes, sends it to the port, waits for a reply, decodes the reply and sends it back to the caller.</p>
+    <p>The <c>complex</c> process does the following:</p>
+    <list type="bulleted">
+       <item>Encodes the message into a sequence of bytes.</item>
+       <item>Sends it to the port.</item>
+       <item>Waits for a reply.</item>
+       <item>Decodes the reply.</item>
+       <item>Sends it back to the caller:</item>
+     </list>
     <pre>
 loop(Port) ->
   receive
@@ -75,37 +102,52 @@ loop(Port) ->
       end,
       loop(Port)
  end.</pre>
-    <p>Assuming that both the arguments and the results from the C functions will be less than 256, a very simple encoding/decoding scheme is employed where <c>foo</c> is represented by the byte 1, <c>bar</c> is represented by 2, and the argument/result is represented by a single byte as well.</p>
+    <p>Assuming that both the arguments and the results from the C
+      functions are less than 256, a simple encoding/decoding scheme
+      is employed. In this scheme, <c>foo</c> is represented by byte
+      1, <c>bar</c> is represented by 2, and the argument/result is
+      represented by a single byte as well:</p>
     <pre>
 encode({foo, X}) -> [1, X];
 encode({bar, Y}) -> [2, Y].
-      
+
 decode([Int]) -> Int.</pre>
-    <p>The resulting Erlang program, including functionality for stopping the port and detecting port failures is shown below.
+    <p>The resulting Erlang program, including functionality for
+      stopping the port and detecting port failures, is as follows:
       </p>
       <codeinclude file="complex1.erl" type="erl"/>
   </section>
 
   <section>
     <title>C Program</title>
-    <p>On the C side, it is necessary to write functions for receiving and sending 
-      data with two byte length indicators from/to Erlang. By default, the C program
-      should read from standard input (file descriptor 0) and write to standard output
-      (file descriptor 1). Examples of such functions, <c>read_cmd/1</c> and
-      <c>write_cmd/2</c>, are shown below.</p>
+    <p>On the C side, it is necessary to write functions for receiving
+      and sending data with 2 byte length indicators from/to Erlang.
+      By default, the C program is to read from standard input (file
+      descriptor 0) and write to standard output (file descriptor 1).
+      Examples of such functions, <c>read_cmd/1</c> and
+      <c>write_cmd/2</c>, follows:</p>
       <codeinclude file="erl_comm.c" type="erl"/>
-    <p>Note that <c>stdin</c> and <c>stdout</c> are for buffered input/output and should not be used for the communication with Erlang!</p>
-    <p>In the <c>main</c> function, the C program should listen for a message from Erlang and, according to the selected encoding/decoding scheme, use the first byte to determine which function to call and the second byte as argument to the function. The result of calling the function should then be sent back to Erlang.</p>
+    <p>Notice that <c>stdin</c> and <c>stdout</c> are for buffered
+      input/output and must <em>not</em> be used for the communication
+      with Erlang.</p>
+    <p>In the <c>main</c> function, the C program is to listen for a
+      message from Erlang and, according to the selected
+      encoding/decoding scheme, use the first byte to determine which
+      function to call and the second byte as argument to the
+      function. The result of calling the function is then to be sent
+      back to Erlang:</p>
     <codeinclude file="port.c" tag="" type="none"></codeinclude>
-    <p>Note that the C program is in a <c>while</c>-loop checking for the return value of <c>read_cmd/1</c>. The reason for this is that the C program must detect when the port gets closed and terminate.</p>
+    <p>Notice that the C program is in a <c>while</c>-loop, checking
+      for the return value of <c>read_cmd/1</c>. This is because the C
+      program must detect when the port closes and terminates.</p>
   </section>
 
   <section>
     <title>Running the Example</title>
-    <p>1. Compile the C code.</p>
+    <p><em>Step 1.</em> Compile the C code:</p>
     <pre>
 unix> <input>gcc -o extprg complex.c erl_comm.c port.c</input></pre>
-    <p>2. Start Erlang and compile the Erlang code.</p>
+    <p><em>Step 2.</em> Start Erlang and compile the Erlang code:</p>
     <pre>
 unix> <input>erl</input>
 Erlang (BEAM) emulator version 4.9.1.2
@@ -113,7 +155,7 @@ Erlang (BEAM) emulator version 4.9.1.2
 Eshell V4.9.1.2 (abort with ^G)
 1> <input>c(complex1).</input>
 {ok,complex1}</pre>
-    <p>3. Run the example.</p>
+    <p><em>Step 3.</em> Run the example:</p>
     <pre>
 2> <input>complex1:start("extprg").</input>
 &lt;0.34.0>