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}
2,3 & SDS id\\
\bottomrule
\end{tabular}
- \caption{Delete an SDS\\~}
+ \caption{Delete an \gls{SDS}\\~}
\end{subfigure}
\quad%
\begin{subfigure}[b]{.2\textwidth}
\multicolumn{2}{c}{Response}\\
\bottomrule
\end{tabular}
- \caption{SDS update\\~}
+ \caption{\gls{SDS} update\\~}
\end{subfigure}
\quad%
\begin{subfigure}[b]{.2\textwidth}
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}
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:}
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}}
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
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
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
\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
\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
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.
repositories / msc-thesis1617.git / commitdiff