-\lstinputlisting[language=C,caption={Full device interface}]{listings/interface.h}
+\lstinputlisting[language=C,caption={Full device interface}]%
+ {listings/interface.h}
-\section{General message format}
+\section{General Message Format}
Messages are delimited by newlines to make processing by line based devices
easier. Message exchanges have a \emph{Request} and \emph{Response} header.
The \emph{Request} header means that the server is sending to the client. The
\caption{Message protocol for exchanging \glspl{Task}}
\end{table}
-\section{SDSs}
+\section{\glspl{SDS}}
\begin{table}[H]
\centering
\begin{subfigure}[b]{.2\textwidth}
details of the compilation process are given in Section~\ref{sec:compiler}.
The new \glspl{SDS} that were generated during compilation are merged with the
existing device's \glspl{SDS}. Furthermore the messages are placed in the
-channel \gls{SDS} of the device. This will result in sending the actual \gls{SDS}
-specification and \gls{Task} specifications to the device. A \gls{Task} record
-is created with the identifier $-1$ to denote a \gls{Task} not yet
-acknowledged. Finally the device itself is updated with the new state and with
-the new \gls{Task}. After waiting for the acknowledgement the device is
-updated again and the \gls{Task} returns.
+channel \gls{SDS} of the device. This will result in sending the actual
+\gls{SDS} specification and \gls{Task} specifications to the device. A
+\gls{Task} record is created with the identifier $-1$ to denote a \gls{Task}
+not yet acknowledged. Finally the device itself is updated with the new state
+and with the new \gls{Task}. After waiting for the acknowledgement the device
+is updated again and the \gls{Task} returns.
\begin{lstlisting}[label={lst:sendtask},%
caption={Sending a \gls{Task} to a device}]
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 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.
-Listing~\ref{lst:return} shows the classes and implementation for the return
-expression.
+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. Listing~\ref{lst:return} shows the classes and implementation for
+the return expression.
\begin{lstlisting}[label={lst:return},%
caption={Bytecode view for the return instruction}]
%Table of contents
\tableofcontents
-\addcontentsline{toc}{chapter}{Glossaries \& Acronyms}
-\printglossaries%
-
\mainmatter{}
\glsresetall{}
\chapter{Introduction}\label{chp:introduction}
\chapter[mTask system]{\gls{mTask} system}\label{chp:system}
\input{system}
-\chapter[Extending the mTask EDSL]{Extending the \gls{mTask} {EDSL}}\label{chp:mtaskcont}
+\chapter[Extending the mTask EDSL]%
+ {Extending the \gls{mTask} {EDSL}}\label{chp:mtaskcont}
\input{mtaskext}
\chapter{System Architecture}\label{chp:arch}
\appendix\label{chp:appendix}
-\chapter{Communication protocol}\label{app:communication-protocol}
+\chapter{Communication Protocol}\label{app:communication-protocol}
\input{appendix-protocol}
-\chapter{Device client interface}\label{app:device-interface}
+\chapter{Device Client Interface}\label{app:device-interface}
\input{appendix-device-interface}
-\cleardoublepage{}
\phantomsection{}
\addcontentsline{toc}{chapter}{Bibliography}
\bibliographystyle{ieeetr}
\bibliography{thesis}
+\addcontentsline{toc}{chapter}{Glossary}
+\printglossaries%
+
\cleardoublepage{}
\phantomsection{}
\addcontentsline{toc}{chapter}{Lists of \ldots}
\vspace{0.4cm}
\textbf{\Large\@title}\\[0.4cm]
\hrule
- \vspace{7cm}
+ \vspace{6cm}
\begin{minipage}[t]{0.45\textwidth}
\begin{flushleft}\large
\textit{Author:}\\
dr.~P.W.M.~Koopman
\end{flushright}
\end{minipage}
- \vspace{2cm}
+ \vspace{1cm}
\vfill
{\large\@date}
\end{center}
\end{lstlisting}
\paragraph{Sequence:}
-The implementation for the sequence combinator is called the
-\CI{step} (\CI{>>*}). This combinator runs the left-hand \gls{Task} and
-starts the right-hand side when a certain predicate holds. Predicates
-can be propositions about the \CI{TaskValue}, user actions from within
-the web browser or a thrown exception. The familiar
-bind-combinator is an example of a sequence combinator. This combinator
-runs the left-hand side and continues to the right-hand \gls{Task} if
-there is an \CI{UnStable} value and the user presses continue or when
-the value is \CI{Stable}. The combinator could have been implemented
-as follows:
+The implementation for the sequence combinator is called the \CI{step}
+(\CI{>>*}). This combinator runs the left-hand \gls{Task} and starts the
+right-hand side when a certain predicate holds. Predicates can be propositions
+about the \CI{TaskValue}, user actions from within the web browser or a thrown
+exception. The familiar bind-combinator is an example of a sequence combinator.
+This combinator runs the left-hand side and continues to the right-hand
+\gls{Task} if there is an \CI{UnStable} value and the user presses continue or
+when the value is \CI{Stable}. The combinator could have been implemented as
+follows:
\begin{lstlisting}[language=Clean]
(>>=) infixl 1 :: (Task a) (a -> (Task b)) -> (Task b) | iTask a & iTask b
(>>=) ta f = ta >>* [OnAction "Continue" onValue, OnValue onStable]
\end{lstlisting}
\paragraph{Parallel:}
-The parallel combinator allows for concurrent \glspl{Task}. The
-\glspl{Task} combined with these operators will appear at the same time
-in the web browser of the user and the results are combined as the type
-dictates. All parallel combinators used are derived from the basic parallel
-combinator that is very complex and only used internally.
+The parallel combinator allows for concurrent \glspl{Task}. The \glspl{Task}
+combined with these operators will appear at the same time in the web browser
+of the user and the results are combined as the type dictates. All parallel
+combinators used are derived from the basic parallel combinator that is very
+complex and only used internally.
thus are persistent between restarts of the program. Library functions for
shares residing in memory are available as well. The three main operations on
shares are atomic in the sense that during reading no other \glspl{Task} are
-executed. The system provides useful functions to transform, map and combine
+executed. The system provides useful functions to transform, map and combine
\glspl{SDS} using combinators. The system also provides functionality to
-inspect the value of an \gls{SDS} and act upon a change. \Glspl{Task} waiting on
-an \gls{SDS} to change are notified when needed. This results in low resource
-usage because \glspl{Task} are never constantly inspecting \gls{SDS} values but
-are notified.
+inspect the value of an \gls{SDS} and act upon a change. \Glspl{Task} waiting
+on an \gls{SDS} to change are notified when needed. This results in low
+resource usage because \glspl{Task} are never constantly inspecting \gls{SDS}
+values but are notified.
\begin{lstlisting}[%
label={lst:shares},caption={\Gls{SDS} functions}]
repositories / msc-thesis1617.git / commitdiff