Revisited 3.4 and 3.5.1

report.lyx

@@ -5195,7 +5195,7 @@ name "sec:Communication-with-the-GDL-VM"
 A game launched on the GGS is run within a virtual machine.
  For each programming language supported, there is a virtual machine which
  interprets the game.
- Furthermore an interface for communication between the GGS, the game and
+ Furthermore an interface for communication among the GGS, the game and
  the players playing the game is present.
 \end_layout
 
@@ -5223,7 +5223,7 @@ localStorage
 .
  The game state is safely stored in a database and retrieved for manipulation
  by a call for the world object.
- Interaction with the players is done by using the 
+ Interaction with the players are done by using the 
 \emph on
 
 \begin_inset ERT
@@ -5320,7 +5320,7 @@ reference "alg:exposing-erlang"
 \end_layout
 
 \begin_layout Standard
-In JavaScript is is common to use a top level object, called a global object,
+In JavaScript it is common to use a top level object, called a global object,
  to establish a global scope.
  This allows the declaration of global variables and functions.
  To gain access to the global object in the GGS, the 
@@ -5395,7 +5395,7 @@ localStorage
 \noun default
  objects are dummy objects, which provide no functionality, these two objects
  are simply placed in the GDL for the purpose clearing up the code.
- In order to perform an action using the GGS and 
+ To perform an action using the GGS and 
 \noun on
 localStorage
 \noun default
@@ -5845,7 +5845,7 @@ Techniques for ensuring reliability
 \end_layout
 
 \begin_layout Standard
-One of the main goals of the project is to achieve high reliability.
+One main goal of the project is to achieve high reliability.
  The term 'reliable system' is defined by the IEEE as 
 \end_layout
 
@@ -6045,7 +6045,7 @@ key "Savor:1997:HSA:851010.856089"
 There are several approaches to supervisor design in general (when not just
  considering how they work in Erlang).
  One common approach is to have the supervisor look in to the state of the
- process(es) it supervises, and let the supervisor make decisions based
+ process(es) it supervises, and let the supervisor makes decisions based
  on this state.
  The supervisor has a specification of how the process it supervises should
  function, and this is how it makes decisions.
@@ -6053,27 +6053,27 @@ There are several approaches to supervisor design in general (when not just
 \end_layout
 
 \begin_layout Standard
-In Erlang, we have a simple version of supervisors.
+In Erlang, there is a simple version of supervisors.
- We do not inspect the state of the processes being supervised.
+ It does not inspect the state of the processes being supervised.
  We do have a specification of how the supervised processes should behave,
  but on a higher level.
- The specification describes things such as how many times in a given time
+ The specification describes things such as how many times in a given interval
- interval a child process may crash, which processes need restarting when
+ a child process may crash, which processes need restarting when crashes
- crashes occur, and so forth.
+ occur, and so forth.
  
 \end_layout
 
 \begin_layout Standard
-When the linking of processes in order to monitor exit behavior is coupled
+When the linking of processes to monitor exit behavior is coupled with the
- with the transparent distribution of Erlang, a very powerful supervision
+ transparent distribution of Erlang, a very powerful supervision system
- system is created.
+ is created.
- For instance, we can restart a failing process on a different, new node,
+ For instance, it is possible to restart a failing process on a different,
- with minimal impact on the system as a whole.
+ new node, with minimal impact on the system as a whole.
  
 \end_layout
 
 \begin_layout Standard
-In the GGS, we have separated the system in to two large supervised parts.
+In the GGS, the system is separated into two large supervised parts.
  We try to restart a crashing child separately, if this fails too many
 \begin_inset Foot
 status collapsed
@@ -6103,28 +6103,28 @@ The graphic above shows our two subsystems, the coordinator subsystem and
  the dispatcher subsystem.
  Since these two systems perform very different tasks they have been separated.
  Each subsystem has one worker process, the coordinator or the dispatcher.
- The worker process keeps a state which should not be lost upon a crash.
+ The worker process keeps a state which should not be lost on a crash.
 \end_layout
 
 \begin_layout Standard
-We have chosen to let faulty processes crash very easily when they receive
+We have chosen to let faulty processes crash easily when they receive bad
- bad data, or something unexpected happens.
+ data, or if something unexpected happens.
- The alternative to crashing would have been to try and fix this faulty
+ The alternative to crashing would have been to try to fix this faulty data,
- data, or to foresee the unexpected events.
+ or to foresee the unexpected events.
  We chose not to do this because it is so simple to monitor and restart
- processes, and so difficult to try and mend broken states.
+ processes, and so difficult to try to mend broken states.
  This approach is something widely deployed in the Erlang world, and developers
  are often encouraged to “Let it crash”.
 \end_layout
 
 \begin_layout Standard
-To prevent any data loss, the good state of the worker processes is stored
+To prevent any data loss, the good state of the worker processes are stored
  in their respective backup processes.
  When a worker process (re)starts, it asks the backup process for any previous
  state, if there is any that state is loaded in to the worker and it proceeds
  where it left off.
  If on the other hand no state is available, a special message is delivered
- instead, making the worker create a new state, this is what happens when
+ instead, making the worker creates a new state, this is what happens when
  the workers are first created.
 \end_layout