latest spelling sweep, now really going to send

[msc-thesis1617.git] / results.mtask.tex

diff --git a/results.mtask.tex b/results.mtask.tex
index d861ed5..acc6a69 100644 (file)
--- a/results.mtask.tex
+++ b/results.mtask.tex
@@ -41,7 +41,7 @@ reflected in the \CI{MTTask} message type.
 \Glspl{SDS} on a client are available on the server as well as regular
 \glspl{SDS}. However, the same freedom is not given for \glspl{SDS} that
 reside on the client. Not all types are suitable to be located on a client,
-simply because it needs to be serializable and representable on clients.
+simply because it needs to be representable on clients.
 Moreover, \glspl{SDS} behave a little different in an \gls{mTask} device
 compared to in the \gls{iTasks} system. In an \gls{iTasks} system, when the
 \gls{SDS} is updated, a broadcast to all watching \glspl{Task} in the system
@@ -118,7 +118,7 @@ instance serial ByteCode
 
 \subsection{Instruction Set}\label{sec:instruction}
 The instruction set is given in Listing~\ref{bc:instr}. The instruction set is
-kept large, but under $255$, to get as much expressieve power as possible while
+kept large, but under $255$, to get as much expressive power as possible while
 keeping all instruction within one byte.
 
 The interpreter running in the client is a stack machine. The virtual
@@ -235,7 +235,7 @@ instance noOp ByteCode where
 The semantics for the \gls{mTask}-\glspl{Task} bytecode view are different from
 the semantics of the \gls{C} view. \glspl{Task} in the \gls{C} view can start
 new \glspl{Task} or even start themselves to continue, while in the bytecode
-view, \glspl{Task} run indefinitly, one-shot or on interrupt. To allow interval
+view, \glspl{Task} run indefinitely, one-shot or on interrupt. To allow interval
 and interrupt \glspl{Task} to terminate, a return instruction is added. This
 class was not available in the original system and is thus added. It just
 writes a single instruction so that the interpreter knows to stop execution.