From eb79b5ec5410cf3e7fb8dd3b4f68517dcfb4fec6 Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Mon, 26 Jun 2017 14:39:35 +0200 Subject: [PATCH] latest spelling sweep, now really going to send --- appendix-protocol.tex | 10 +++++----- conclusion.tex | 2 +- glossaries.tex | 3 ++- introduction.tex | 2 +- methods.mtask.tex | 6 +++--- results.arch.tex | 2 +- results.mtask.tex | 6 +++--- 7 files changed, 16 insertions(+), 15 deletions(-) diff --git a/appendix-protocol.tex b/appendix-protocol.tex index 20e7fa3..c0d5a2a 100644 --- a/appendix-protocol.tex +++ b/appendix-protocol.tex @@ -100,7 +100,7 @@ interpreted as \gls{MSB} first integers. 2,3 & id\\ \bottomrule \end{tabular} - \caption{Send an SDS specification} + \caption{Send an \gls{SDS} specification} \end{subfigure} \quad% \begin{subfigure}[b]{.2\textwidth} @@ -120,7 +120,7 @@ interpreted as \gls{MSB} first integers. 2,3 & SDS id\\ \bottomrule \end{tabular} - \caption{Delete an SDS\\~} + \caption{Delete an \gls{SDS}\\~} \end{subfigure} \quad% \begin{subfigure}[b]{.2\textwidth} @@ -137,7 +137,7 @@ interpreted as \gls{MSB} first integers. \multicolumn{2}{c}{Response}\\ \bottomrule \end{tabular} - \caption{SDS update\\~} + \caption{\gls{SDS} update\\~} \end{subfigure} \quad% \begin{subfigure}[b]{.2\textwidth} @@ -154,7 +154,7 @@ interpreted as \gls{MSB} first integers. 4,5 & value\\ \bottomrule \end{tabular} - \caption{SDS publish\\~} + \caption{\gls{SDS} publish\\~} \end{subfigure} - \caption{Message protocol for exchanging SDSs} + \caption{Message protocol for exchanging \glspl{SDS}} \end{table} diff --git a/conclusion.tex b/conclusion.tex index aa79d52..0cc405e 100644 --- a/conclusion.tex +++ b/conclusion.tex @@ -24,7 +24,7 @@ finishes. This does require separate stacks for each \gls{Task} and therefore increases the system requirements of the client software. However, it could be implemented as a compile-time option and exchanged during the handshake so that the server knows the multithreading capabilities of the client. Multithreading -allows \glspl{Task} to be truly interruptable by other \glspl{Task}. +allows \glspl{Task} to be truly interruptible by other \glspl{Task}. Furthermore, this allows for more fine-grained timing control of \glspl{Task}. \paragraph{Optimizing the interpreter:} diff --git a/glossaries.tex b/glossaries.tex index 6c3d258..809f8e7 100644 --- a/glossaries.tex +++ b/glossaries.tex @@ -5,7 +5,8 @@ description={is a statically typed pure lazy functional programming language based on graph rewriting}} \newglossaryentry{Haskell}{name={\emph{Haskell}}, - description={is a staticly typed pure lazy functional programming language}} + description={is a statically typed pure lazy functional programming + language}} \newglossaryentry{iTasks}{name=\emph{iTasks}, description={is a \gls{TOP} implementation written as an \gls{EDSL} in the \gls{Clean} programming language}} diff --git a/introduction.tex b/introduction.tex index f2dae81..0237c79 100644 --- a/introduction.tex +++ b/introduction.tex @@ -39,7 +39,7 @@ such as time are available in the current \gls{iTasks} implementation.}. However, this requires a very specific adapter to be written for every device and function. This forces a fixed logic in the device that is set at compile time. Many small \gls{IoT} devices have limited processing power but are still -powerfull enough for decision making. Recompiling the code for a small +powerful enough for decision making. Recompiling the code for a small \gls{IoT} device is expensive and therefore it is difficult to use a device dynamically for multiple purposes. Oortgiese et al.\ lifted \gls{iTasks} from a single server model to a distributed server architecture that is also runnable diff --git a/methods.mtask.tex b/methods.mtask.tex index 38930c5..6d12848 100644 --- a/methods.mtask.tex +++ b/methods.mtask.tex @@ -14,9 +14,9 @@ literature. A view for the \gls{mTask}-\gls{EDSL} is a type with two free type variables\footnote{kind \CI{*->*->*}.} that implements some of the classes -given. The types do not have to be present as fields in the higher kinded view -and can, and will most often, be exclusively phantom types. Thus, views are of -the form:\\\CI{:: v t r = ...}. The first type variable will be the type of the +given. The types do not have to be present as fields in the view and can, and +will most often, be exclusively phantom types. Thus, views are of the +form:\\\CI{:: v t r = ...}. The first type variable will be the type of the view. The second type variable will be the type of the \gls{EDSL}-expression and the third type variable represents the role of the expression. Currently the role of the expressions form a hierarchy. The three roles and their diff --git a/results.arch.tex b/results.arch.tex index 5e846c9..b6b0b3d 100644 --- a/results.arch.tex +++ b/results.arch.tex @@ -60,7 +60,7 @@ the device software. development board. \item Microcontrollers which are programmable in the \gls{Arduino} \gls{IDE} connected via serial communication or via \gls{TCP} over WiFi or - ethernet. + Ethernet. This does not only include \gls{Arduino} compatible boards but also other boards capable of running \gls{Arduino} code. A port of the diff --git a/results.mtask.tex b/results.mtask.tex index d861ed5..acc6a69 100644 --- 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. -- 2.20.1