This thesis introduces a way to connect small \gls{IoT} devices with high level
\gls{TOP} implementations languages. It demonstrates how a new frontend for the
class-based shallowly \gls{EDSL} called \gls{mTask} written in \gls{Clean} can
-be employed to compile \gls{IoT}-tasks on the fly and send them to devices as
-interpretable bytecode. All of which adheres to the \gls{TOP} philosophy where
-common concepts such as \glspl{SDS} and task-combinators are available at ease.
+be employed to compile \gls{IoT}-\glspl{Task} on the fly and send them to
+devices as interpretable bytecode. All of which adheres to the \gls{TOP}
+philosophy where common concepts such as \glspl{SDS} and \gls{Task}-combinators
+are available at ease.
byte & value\\
\midrule
1 & \texttt{'t'}\\
- 2,3 & task id\\
+ 2,3 & \gls{Task} id\\
\bottomrule
\end{tabular}
- \caption{Send a task}
+ \caption{Send a \gls{Task}}
\end{subfigure}
\quad%
\begin{subfigure}[t]{.48\textwidth}
byte & meaning\\
\midrule
1 & \texttt{'d'}\\
- 2,3 & task id\\
+ 2,3 & \gls{Task} id\\
\midrule\midrule
\multicolumn{2}{c}{Response}\\
byte & value\\
\midrule
1 & \texttt{'d'}\\
- 2,3 & task id\\
+ 2,3 & \gls{Task} id\\
\bottomrule
\end{tabular}
- \caption{Delete a task}
+ \caption{Delete a \gls{Task}}
\end{subfigure}
- \caption{Message protocol for exchanging tasks}
+ \caption{Message protocol for exchanging \glspl{Task}}
\end{table}
\section{SDSs}
-\section{Conclusion}
-This thesis introduces a new view for the existing \gls{mTask}-\gls{EDSL}.
-The new view for the \gls{EDSL} compiles the language in to bytecode that can
-be interpreted by an \gls{mTask}-client. Clients have been written for several
-microcontrollers and consumer architectures that can be connected through
-various means of communication such as serial, bluetooth, wifi and wired
-network communication. The bytecode on the devices is interpreted using a
-simple stack machine and provides the programmer interfaces to the peripherals.
-The semantics of the \glspl{mTask} tries to resemble the \gls{iTasks} semantics
-as close as possible.
-
-The host language has a very efficient compiler and code generator. Therefore,
-the \gls{mTask}-system is also relatively fast because the compilation of
-\glspl{mTask} is nothing more than running some functions in the host language.
-
-The dynamic nature allows the microcontroller to be programmed once and used
-many times. The program memory of microcontrollers often guarantees around
-$10.000$ write or upload cycles and therefore existing techniques such as
-generating \gls{C} code are not usable for dynamic \gls{Task} environments.
-The dynamic nature also allows the programmer to design fail-over mechanisms.
-When a device is assigned a \gls{Task} but another device suddenly becomes
-unusable, the \gls{iTasks} system can reassign a new \gls{mTask}-\gls{Task} to
-the first device that possibly takes over some of the functionality of the
-broken device without needing to recompile the code.
-
\section{Discussion}
\todo{class based shallow doesn't have multiple backend support}
\todo{slow client software because of interpretation}
\todo{What happens if a device dies? Task resending, add to handshake}
-
\section{Future Research}
The system is still crude and a proof of concept. Improvements and extension
for the system are amply available in several fields of study.
An additional simulation view to the \gls{mTask}-\gls{EDSL} could be added that
works in the same way as the existing \gls{C}-backed simulation. It simulates
the bytecode interpretation. Moreover would be possible to let the simulator
-function as real device. Thus handling all communication through the
+function as a real device, thus handling all communication through the
existing \gls{SDS}-based systems and behave like a real device. At the moment
the \emph{POSIX}-client is the reference client and contains debugging code.
Adding a simulation view to the system allows for easy interactive debugging.
However, it might not be easy to devise a simulation tool that accurately
simulates the \gls{mTask} system accurately on some levels. The semantics can
-be simulated but for example timing and peripheral input/output are more
+be simulated but timing and peripheral input/output are more
difficult to simulate properly.
\subsection{Optimization}
\gls{mTask}-\glspl{Task} to run truly parallel. All \glspl{mTask} get slices
of execution time and will each have their own interpreter state instead of one
system-wide one that is reset after am \gls{mTask} finishes. This does require
-separate stacks for each 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.
+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.
Hardly any work has been done in the interpreter. The current interpreter is a
no nonsense stack machine. A lot of improvements can be done in this part. For
This idea could be extended to the analysis of stack size and possibly
communication bandwidth. With this functionality ever more reliable fail-over
-systems can be designed. When the system knows preciser bounds it can
+systems can be designed. When the system knows precise bounds it can
allocate more \glspl{Task} on a device whilst staying within safe memory
bounds. The resource allocation can be done at runtime within the backend
itself or a general backend can be devices that can calculate the resources
-needed for a given \gls{mTask}. A specific \gls{mTask} can not have multiple
+needed for a given \gls{mTask}. A specific \gls{mTask} cannot have multiple
views at the same time due to the restrictions of class based shallow
embedding. It might even be possible to encode the resource allocation in the
type system itself using forms of dependant types.
\subsection{Functionality}
-More task-combinators already existing in the \gls{iTasks}-system could be added
-to the \gls{mTask}-system to allow for more fine-grained control flow between
-\gls{mTask}-\glspl{Task}. In this way the new system follows the \gls{TOP}
-paradigm even more and makes programming \glspl{mTask} for
+More \gls{Task}-combinators already existing in the \gls{iTasks}-system could
+be added to the \gls{mTask}-system to allow for more fine-grained control flow
+between \gls{mTask}-\glspl{Task}. In this way the new system follows the
+\gls{TOP} paradigm even more and makes programming \glspl{mTask} for
\gls{TOP}-programmers more seamless. Some of the combinators require previously
mentioned extension such as the parallel combinator. Others might be achieved
using simple syntactic transformations.
-Currently the \gls{C}-view allows tasks to launch other tasks. In the current
-system this type of logic has to take place server side. Adding this
-functionality to the bytecode-view allows greater flexibility, easier
+Currently the \gls{C}-view allows \glspl{Task} to launch other \glspl{Task}. In
+the current system this type of logic has to take place server side. Adding
+this functionality to the bytecode-view allows greater flexibility, easier
programming and less communication resources. Adding these semantics requires
modifications to the client software and extensions to the communication
-protocol since relations between tasks also need to be encoded and
+protocol since relations between \glspl{Task} also need to be encoded and
communicated.
+\section{Conclusion}
+This thesis introduces a new view for the existing \gls{mTask}-\gls{EDSL}.
+The new view for the \gls{EDSL} compiles the language in to bytecode that can
+be interpreted by an \gls{mTask}-client. Clients have been written for several
+microcontrollers and consumer architectures that can be connected through
+various means of communication such as serial, bluetooth, wifi and wired
+network communication. The bytecode on the devices is interpreted using a
+simple stack machine and provides the programmer interfaces to the peripherals.
+The semantics of the \glspl{mTask} tries to resemble the \gls{iTasks} semantics
+as close as possible.
+
+The host language has a very efficient compiler and code generator. Therefore,
+the \gls{mTask}-system is also relatively fast because the compilation of
+\glspl{mTask} is nothing more than running some functions in the host language.
+
+The dynamic nature allows the microcontroller to be programmed once and used
+many times. The program memory of microcontrollers often guarantees around
+$10.000$ write or upload cycles and therefore existing techniques such as
+generating \gls{C} code are not usable for dynamic \gls{Task} environments.
+The dynamic nature also allows the programmer to design fail-over mechanisms.
+When a device is assigned a \gls{Task} but another device suddenly becomes
+unusable, the \gls{iTasks} system can reassign a new \gls{mTask}-\gls{Task} to
+the first device that possibly takes over some of the functionality of the
+broken device without needing to recompile the code.
all small devices that communicate with each other and the world. These devices
are often equipped with sensors, \gls{GNSS}\footnote{e.g.\ the American
\gls{GPS} or the Russian \gls{GLONASS}} and actuators%
-\cite{da_xu_internet_2014}. With these new technologies information
+~\cite{da_xu_internet_2014}. With these new technologies information
can be tracked very accurately using very little power and bandwidth. Moreover,
\gls{IoT} technology is coming into people's homes, clothes and
-healthcare\cite{riazul_islam_internet_2015}. For example, for a few euros a
+healthcare~\cite{riazul_islam_internet_2015}. For example, for a few euros a
consumer ready fitness tracker watch can be bought that tracks heartbeat and
respiration levels.
The \gls{TOP} paradigm and the corresponding \gls{iTasks} implementation offer
a high abstraction level for real life workflow tasks%
-\cite{plasmeijer_itasks:_2007}. These workflow tasks can be described through
+~\cite{plasmeijer_itasks:_2007}. These workflow tasks can be described through
an \gls{EDSL} and modeled as \glspl{Task}. The system will generate multi-user
web app from the specification. This web service can be accessed through a
browser and is used to complete these \glspl{Task}. Familiar workflow patterns
-like sequence, parallel and conditional tasks can be modelled using
+like sequence, parallel and conditional \glspl{Task} can be modelled using
combinators.
\gls{iTasks} has been proven to be useful in many fields of operation such as
-incident management~\cite{lijnse_top_2013}. Interfaces are automatically
+incident management~~\cite{lijnse_top_2013}. Interfaces are automatically
generated for the types of data which makes rapid development possible.
\Glspl{Task} in the \gls{iTasks} system are modelled after real life workflow
tasks but the modelling is applied on a very high level. Therefore it is
small \gls{IoT} devices have limited processing power but can still contain
decision making. Oortgiese et al.\ lifted \gls{iTasks} from a single server
model to a distributed server architecture that is also runnable on small
-devices such as those powered by \acrshort{ARM}~\cite{%
+devices such as those powered by \acrshort{ARM}~~\cite{%
oortgiese_distributed_2017}. However, this is limited to fairly high
performance devices that are equipped with high speed communication channels.
Devices in \gls{IoT} often have only \gls{LTN} communication with low bandwidth
run an entire \gls{iTasks} core.
\section{Problem statement}
-The updates to the \gls{mTask}-system\cite{koopman_type-safe_nodate} will
+The updates to the \gls{mTask}-system~\cite{koopman_type-safe_nodate} will
bridge this gap by introducing a new communication protocol, device application
and \glspl{Task} synchronizing the formers. The system can run on devices as
-small as \gls{Arduino} microcontrollers\cite{noauthor_arduino_nodate} and
+small as \gls{Arduino} microcontrollers~\cite{noauthor_arduino_nodate} and
operates via the same paradigms and patterns as regular \glspl{Task} in the
\gls{TOP} paradigm. Devices in the \gls{mTask}-system can run small imperative
programs written in an \gls{EDSL} and have access to \glspl{SDS}. \Glspl{Task}
Appendix~\ref{app:device-interface} shows the concrete interface for the
devices.
+Text written using the \CI{Teletype} font indicates code and is often
+referring to a listing. \emph{Emphasized} text is used for proper nouns and
+words that have a unexpected meaning.
+
\section{Related work}
Several types of similar research have been conducted concerning these matters.
Microcontrollers such as the \gls{Arduino} can be remotely controlled by the
\Gls{Clean} has a history of interpretation and there is a lot of research
happening on the intermediate language \gls{SAPL}. \Gls{SAPL} is a purely
functional intermediate language that has interpreters written in
-\gls{C++}\cite{jansen_efficient_2007} and \gls{Javascript}%
-\cite{domoszlai_implementing_2011} and \gls{Clean} and \gls{Haskell} compiler
-backends\cite{domoszlai_compiling_2012}. However, interpreting the resulting
+\gls{C++}~\cite{jansen_efficient_2007} and \gls{Javascript}%
+~\cite{domoszlai_implementing_2011} and \gls{Clean} and \gls{Haskell} compiler
+backends~\cite{domoszlai_compiling_2012}. However, interpreting the resulting
code is still heap-heavy and therefore not directly suitable for devices with as
little as $2K$ of RAM such as the \gls{Arduino} \emph{UNO}. It might be
possible to compile the \gls{SAPL} code into efficient machine language or
\Glspl{EDSL} have often been used to generate \gls{C} code for microcontroller
environments. For starters, this work is built upon the \gls{mTask}-\gls{EDSL}
that generates \gls{C} code to run a \gls{TOP}-like system on microcontrollers%
-\cite{plasmeijer_shallow_2016}\cite{koopman_type-safe_nodate}.
+~\cite{plasmeijer_shallow_2016}~\cite{koopman_type-safe_nodate}.
Again, this requires a reprogramming cycle every time the
\gls{Task}-specification is changed.
Another \gls{EDSL} designed to generate low-level high-assurance programs is
called \gls{Ivory} and uses \gls{Haskell} as a host language%
-\cite{elliott_guilt_2015}. The language uses the \gls{Haskell} type-system to
+~\cite{elliott_guilt_2015}. The language uses the \gls{Haskell} type-system to
make unsafe languages type safe. For example, \gls{Ivory} has been used in the
automotive industry to program parts of an autopilot%
-\cite{pike_programming_2014}\cite{hickey_building_2014}. \Gls{Ivory}'s syntax
+~\cite{pike_programming_2014}~\cite{hickey_building_2014}. \Gls{Ivory}'s syntax
is deeply embedded but the type system is shallowly embedded. This requires
several \gls{Haskell} extensions that offer dependent type constructions. The
process of compiling an \gls{Ivory} program happens in stages. The embedded
views accordingly is tedious and has to be done individually for all views.
The first downside of this type of \gls{EDSL} can be overcome by using
-\glspl{GADT}\cite{cheney_first-class_2003}. Listing~\ref{lst:exdeepgadt} shows
+\glspl{GADT}~\cite{cheney_first-class_2003}. Listing~\ref{lst:exdeepgadt} shows
the same language, but type-safe with a \gls{GADT}. \glspl{GADT} are not
supported in the current version of \gls{Clean} and therefore the syntax is
hypothetical. However, it has been shown that \glspl{GADT} can be simulated
-using bimaps or projection pairs\cite{cheney_lightweight_2002}. Unfortunately
+using bimaps or projection pairs~\cite{cheney_lightweight_2002}. Unfortunately
the lack of extendability remains a problem. If a language construct is added,
no compile time guarantee is given that all views support it.
\gls{mTask}-\gls{EDSL} was created by Koopman et al.\ to support several views
such as an \gls{iTasks} simulation and a \gls{C}-code generator. The \gls{EDSL}
was designed to generate a ready-to-compile \gls{TOP}-like system for
-microcontrollers such as the \gls{Arduino}\cite{koopman_type-safe_nodate}%
+microcontrollers such as the \gls{Arduino}~\cite{koopman_type-safe_nodate}%
\cite{plasmeijer_shallow_2016}.
The \gls{mTask}-\gls{EDSL} is a shallowly embedded class based \gls{EDSL} and
\section{Control flow}
Looping of \glspl{Task} happens because \glspl{Task} are executed after waiting
-a specified amount of time or when they are launched by another task or even
-themselves. Therefore there is no need for loop control flow functionality such
-as \emph{while} or \emph{for} constructions. The main control flow operators
-are the sequence operator and the \emph{if} statement. Both are shown in
-Listing~\ref{lst:control}. The first class of \emph{If} statements describes
+a specified amount of time or when they are launched by another \gls{Task} or
+even themselves. Therefore there is no need for loop control flow functionality
+such as \emph{while} or \emph{for} constructions. The main control flow
+operators are the sequence operator and the \emph{if} statement. Both are shown
+in Listing~\ref{lst:control}. The first class of \emph{If} statements describes
the regular \emph{if} statement. The expressions given can have any role. The
-functional dependency on \CI{s} determines the return type of the
-statement. The listing includes examples of implementations that illustrate
-this dependency.
+functional dependency on \CI{s} determines the return type of the statement.
+The listing includes examples of implementations that illustrate this
+dependency.
The sequence operator is very straightforward and its only function is to tie
the together in sequence.
Listing~\ref{lst:taskclass}. \glspl{Task} can have an argument and always have
to specify a delay or waiting time. The type signature of the \CI{mtask} is
complex and therefore an example is given. The aforementioned Listing
-shows a simple specification containing one task that increments a value
+shows a simple specification containing one \gls{Task} that increments a value
indefinitely every one seconds.
\begin{lstlisting}[label={lst:taskclass},%
- caption={The classes for defining tasks}]
+ caption={The classes for defining \glspl{Task}}]
class mtask v a where
task :: (((v delay r) a->v MTask Expr)->In (a->v u p) (Main (v t q))) -> Main (v t q) | ...
\section{iTasks}
\gls{TOP} is a modern recent programming paradigm implemented as
-\gls{iTasks}\cite{achten_introduction_2015} in the pure lazy functional
-language \gls{Clean}\cite{brus_cleanlanguage_1987}. \gls{iTasks} is a
+\gls{iTasks}~\cite{achten_introduction_2015} in the pure lazy functional
+language \gls{Clean}~\cite{brus_cleanlanguage_1987}. \gls{iTasks} is a
\gls{EDSL} to model workflow tasks in the broadest sense. A \gls{Task} is just
a function that --- given some state --- returns the observable \CI{TaskValue}. The
\CI{TaskValue} of a \CI{Task} can have different states. Not all state
Combinators describe relations between \glspl{Task}. \Glspl{Task} can be
combined in parallel, sequenced and their result values can be converted to
\glspl{SDS}. Moreover, a very important combinator is the step combinator which
-starts a new task according to specified predicates on the \CI{TaskValue}.
-Type signatures of the basic combinators are shown in
+starts a new \gls{Task} according to specified predicates on the
+\CI{TaskValue}. Type signatures of the basic combinators are shown in
Listing~\ref{lst:combinators}.
\begin{itemize}
source. In these functions the \CI{*IWorld} --- which in turn contains the real
program \CI{*World} --- is available. Accessing the outside world is required
for interacting with it and thus the functions can access files on disk, raw
-memory, other shares and hardware.
+memory, other \glspl{SDS} and hardware.
The basic operations for \glspl{SDS} are get, set and update. The signatures
for these functions are shown in Listing~\ref{lst:shares}. By default, all
-shares are files containing a \gls{JSON} encoded version of the object and 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 tasks are 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 a \gls{SDS} and act upon a change. \Glspl{Task} waiting on a \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.
+\glspl{SDS} are files containing a \gls{JSON} encoded version of the object and
+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
+\glspl{SDS} using combinators. The system also provides functionality to
+inspect the value of a \gls{SDS} and act upon a change. \Glspl{Task} waiting on
+a \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}]
resource are notified of the update. However, it may be the case that
\glspl{Task} were only looking at parts of the structure that was not updated.
To solve this problem, parametric lenses were
-introduced~\cite{domoszlai_parametric_2014}.
+introduced~~\cite{domoszlai_parametric_2014}.
Parametric lenses add a type variable to the \gls{SDS} that is in the current
library functions fixed to the void type (i.e. \CI{()}). When a \gls{SDS}
executes a write operation, it also provides the system with a notification
predicate. This notification predicate is a function \CI{p -> Bool} where
\CI{p} is the parametric lens type. This allows programmers to create a big
-share, and have \glspl{Task} only look at parts of the big share. This
+\gls{SDS}, and have \glspl{Task} only look at parts of the big \gls{SDS}. This
technique is used in the current system in memory shares. The \CI{IWorld}
contains a map that is accessible through an \gls{SDS}. While all data is
stored in the map, only \glspl{Task} looking at a specific entry are notified
\end{itemize}
\section{Specification}
-The servers stores a description for every device available in a record type
+The server stores a description for every device available in a record type
which are stored in a \gls{SDS}. From the macro settings in
the interface file, a profile is created for the device that describes the
specification. When a connection between the server and a client is established
Listing~\ref{lst:mtaskdevice} with the accompanying classes and types.
The \CI{deviceResource} component of the record must implement the
-\CI{MTaskDuplex} interface that provides a function that launches a task used
-for synchronizing the channels. The \CI{deviceTask} stores the \gls{Task}-id
-for this \gls{Task} when active so that it can be checked upon. This top-level
-task has the duty to report thrown exceptions and occuring errors by setting
-the \CI{deviceError} field. All communication goes via these channels. If the
-system wants to send a message to the device it just puts it in the channels.
-Messages sent from the client to the server are also placed in there. In the
-case of the \gls{TCP} device type the \gls{Task} is just a simple wrapper
-around the existing \CI{tcpconnect} function in \gls{iTasks}. In case of a
-device connected by a serial connection it uses the newly developed serial port
-library of \gls{Clean}\footnote{\url{%
+\CI{MTaskDuplex} interface that provides a function that launches a \gls{Task}
+used for synchronizing the channels. The \CI{deviceTask} stores the
+\gls{Task}-id for this \gls{Task} when active so that it can be checked upon.
+This top-level task has the duty to report exceptions and errors as they are
+thrown by setting the \CI{deviceError} field. All communication goes via these
+channels. If the system wants to send a message to the device, it just puts it
+in the channels. Messages sent from the client to the server are also placed
+in there. In the case of the \gls{TCP} device type, the \gls{Task} is just a
+simple wrapper around the existing \CI{tcpconnect} function in \gls{iTasks}. In
+case of a device connected by a serial connection, it uses the newly developed
+serial port library of \gls{Clean}\footnote{\url{%
https://gitlab.science.ru.nl/mlubbers/CleanSerial}}.
Besides all the communication information, the record also keeps track of the
\subsection{\glspl{Task} \& \glspl{SDS}}
When a \gls{Task} is sent to the device it is added to the device record
without an identifier. The actual identifier is added to the record when the
-acknowledgement of the task by the device is received. The connection diagram
-is shown in Figure~\ref{fig:tasksend}.
+acknowledgement of the \gls{Task} by the device is received. The connection
+diagram is shown in Figure~\ref{fig:tasksend}.
\begin{figure}[H]
\centering
\caption{Sending a \gls{Task} to a device}\label{fig:tasksend}
\end{figure}
-The function for sending a task to the device is shown in
-Listing~\ref{lst:sendtask}. First the task is compiled into messages. The
+The function for sending a \gls{Task} to the device is shown in
+Listing~\ref{lst:sendtask}. First the \gls{Task} is compiled into messages. The
details of the compilation process are given in Section~\ref{sec:compiler}.
-The new shares that were made during compilation are added to the deviceshares
-that were made during the compilation are merged with the existing shares on
-the device. Furthermore the messages are placed in the channel share 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}. When
-the device returns an acknowledgement the \gls{Task} is updated accordingly.
+The new \glspl{SDS} that were made during compilation are added to the
+deviceshares that were made during the compilation are merged with the existing
+shares on the device. Furthermore the messages are placed in the channel share
+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}.
+When the device returns an acknowledgement the \gls{Task} is updated
+accordingly.
\begin{lstlisting}[label={lst:sendtask},%
caption={Sending a \gls{Task} to a device}]
The glue in the system is written in \gls{iTasks}. Functions for managing
devices, \glspl{Task} and \glspl{SDS} are created. An interface is made that
allows an interactive management console for the \gls{mTask} system. This
-interface provides functionality to list shares, add tasks, remove tasks,
-administrate devices and view the state of the system.
+interface provides functionality to list \glspl{SDS}, add \glspl{Task}, remove
+\glspl{Task}, administrate devices and view the state of the system.
\section{Integration}
When the system starts up the devices residing in the \gls{SDS} must be cleaned
-up. It might be the case that they contain tasks, shares or errors. A user or
-programmer can then choose to reconnect some devices using the
+up. It might be the case that they contain \glspl{Task}, \glspl{SDS} or errors.
+A user or programmer can then choose to reconnect some devices using the
\CI{connectDevice} function.
\begin{lstlisting}[caption={Starting up the devices},%
The system management is done by a single \gls{Task} called \CI{mTaskManager}.
To manage the system, a couple of different functionalities are needed and
are launched. The left sidebar of the interface shows the list of example
-\glspl{Task} that are present in the system. When clicking a task, a dialog
-opens in which you can select the device to send the task to. The dialog might
-contain user specified variables. All example \glspl{mTask} are of the type
-\CI{Task (Main (ByteCode () Stmt))} and can thus ask for user input first.
+\glspl{Task} that are present in the system. When clicking a \gls{Task}, a
+dialog opens in which you can select the device to send the \gls{Task} to. The
+dialog might contain user specified variables. All example \glspl{mTask} are of
+the type \CI{Task (Main (ByteCode () Stmt))} and can thus ask for user input
+first.
The bottom panel shows the device information. In this panel, the devices can
be created and modified. Moreover, this panel allows the user to reconnect with
This allows the programmer to create filters and lenses. Both of the methods
are not good enough for the device \gls{SDS} because they do not achieve the
writing to the actual device. Writing to a device requires being able to write
-to shares. To solve this problem, a real base \gls{SDS} is created. All the
-details are visible in Listing~\ref{shareimpl}.
+to \glspl{SDS}. To solve this problem, a real base \gls{SDS} is created. All
+the details are visible in Listing~\ref{shareimpl}.
\todo{elaborate}
\begin{lstlisting}[label={lst:shareimpl},%
\section{Semantics}
The current \gls{mTask} engine for devices does not support \glspl{Task} in the
-sense that the \gls{C}-view it does. \Glspl{Task} used with the \gls{C}-view
-are a main program that runs some \gls{Task}. \glspl{Task} in the new system
-are \CI{Main} objects with a program inside that does not contain \glspl{Task}
-but are a \gls{Task} as a whole. Sending a \gls{Task} always goes together with
+sense that the \gls{C}-view does. \Glspl{Task} used with the \gls{C}-view are a
+main program that runs some \glspl{Task}. \glspl{Task} in the new system are
+\CI{Main} objects with a program inside that does not contain \glspl{Task} but
+are a \gls{Task} as a whole. Sending a \gls{Task} always goes together with
choosing a scheduling strategy. This strategy can be one of the following three
strategies as reflected in the \CI{MTTask}.
\CI{OneShot} takes no parameters and means that the \gls{Task} will run
once and will then be removed automatically. This type of scheduling
- could be usefull to for example retrieving sensor information on
+ could be useful, for example, in retrieving sensor information on
request of a user.
\item\CI{OnInterval}
\CI{OnInterval} has as a parameter the number of milliseconds to wait
in between executions. \Glspl{Task} running with this scheduling method
- are executed every fixed interval.
+ are executed at predetermined intervals.
\item\CI{OnInterrupt}
The last scheduling method is running \glspl{Task} on a specific
- interrupt. None of the current implementation implement this. However,
- registering interrupts on for example the \gls{Arduino} is very
- straightforward. Interrupt scheduling is usefull for \glspl{Task} that
- have to react on a certain type of hardware event such as the press of
- a button.
+ interrupt. None of the current client implementations support this.
+ However, registering interrupts on, for example the \gls{Arduino} is
+ very straightforward. Interrupt scheduling is useful for \glspl{Task}
+ that have to react on a certain type of hardware event such as the
+ press of a button.
\end{itemize}
\subsection{\glspl{SDS}}
shown in Listing~\ref{lst:bcview}, the \CI{ByteCode} view is a boxed \gls{RWST}
that writes bytecode instructions (\CI{BC}) while carrying around a
\CI{BCState}. The state is kept between compilations and is unique to a device.
-The state contains fresh variable names and a register of shares used.
+The state contains fresh variable names and a register of \glspl{SDS} used.
Types implementing the \gls{mTask} classes must have two free type variables.
Therefore the \gls{RWST} is wrapped with a constructor and two phantom type
variables are added. This means that the programmer has to unbox the
\CI{ByteCode} object to be able to use return values for the monad. Tailor made
access functions are used to achieve this with ease. The fresh variable stream
-in a compiler using an \gls{RWST} is often put in to the \emph{Reader} part of
+in a compiler using an \gls{RWST} is often put into the \emph{Reader} part of
the monad. However, not all code is compiled immediately and later on the fresh
-variable stream can not contain variables that were used before. Therefore this
+variable stream cannot contain variables that were used before. Therefore this
information is put in the state which is kept between compilations.
Not all types are suitable for usage in bytecode compiled programs. Every value
program size.
The interpreter is a
-stack machine. Therefore the it needs instructions like \emph{Push} and
+stack machine. Therefore it needs instructions like \emph{Push} and
\emph{Pop}. The virtual instruction \CI{BCLab} is added to allow for an easy
implementation. However, this is not a real instruction and the labels are
resolved to actual addresses in the final step of compilation to save
| BCReturn
\end{lstlisting}
-All instructions are can be converted semi-automatically using the generic
-function \CI{consIndex\{*\}} that gives the index of the constructor. This
-constructor index is the actual byte value for the instruction. The
-\CI{BCValue} type contains existentially quantified types and therefore must
-have a given implementation for all generic functions.
+All instructions can be converted semi-automatically using the generic function
+\CI{consIndex\{*\}} that gives the index of the constructor. This constructor
+index is the actual byte value for the instruction. The \CI{BCValue} type
+contains existentially quantified types and therefore must have a given
+implementation for all generic functions.
\subsection{Helper functions}
The \CI{ByteCode} type is just a boxed \gls{RWST} and that gives us access to
the whole range of \gls{RWST} functions. However, to apply a function the type
must be unboxed. After application the type must be boxed again. To achieve
-this some helper functions have been created. They are listed in
+this, several helper functions have been created. They are listed in
Listing~\ref{lst:helpers}. The \CI{op} and \CI{op2} function is crafted to make
operators that pop one or two values off the stack respectively. The \CI{tell`}
is a wrapper around the \gls{RWST} function \CI{tell} that appends the argument
\subsection{Control Flow}
Sequence is very straightforward in the bytecode view. The function just
sequences the two \glspl{RWST}. The \emph{If} statement requires some detailed
-explanation since labels come in to play. The implementation speaks for itself
-in Listing~\ref{lst:controlflow}. First all the labels are gathered and then
+explanation since labels come into play. The implementation speaks for itself
+in Listing~\ref{lst:controlflow}. First, all the labels are gathered and then
they are placed in the correct order in the bytecode sequence. It can happen
that multiple labels appear consecutively in the code. This is not a problem
-since the labels are resolved to real addresses later on anyways.
+since the labels are resolved to real addresses later on anyway.
\begin{lstlisting}[label={lst:controlflow},%
caption={Bytecode view for \texttt{arith}}]
\subsection{Shared Data Sources \& Assignment}
Shared data sources must be acquired from the state and constructing one
-happens via multiple steps. First a fresh identifier is grabbed from the state.
+involves multiple steps. First, a fresh identifier is grabbed from the state.
Then a \CI{BCShare} record is created with that identifier. A \CI{BCSdsFetch}
-instruction is written and the body is generated to finally add the share to
+instruction is written and the body is generated to finally add the \gls{SDS} to
the actual state with the value obtained from the function. The exact
implementation is shown in Listing~\ref{lst:shareview}.
The \glspl{SDS} that were not already sent to the device are also placed in
messages to be sent to the device. This functionality is listed in
Listing~\ref{lst:compilation}. The compilation process consists of two steps.
-First the \gls{RWST} is executed, secondly the \emph{Jump} statements that jump
-to labels are transformed to jump to addresses. The translation of labels is
-possible in one sweep because no labels are reused. Reusing labels would not
-give a speed improvement since the labels are removed anyways in the end.
+First, the \gls{RWST} is executed. Then the \emph{Jump} statements that
+jump to labels are transformed to jump to addresses. The translation of labels
+is possible in one sweep because no labels are reused. Reusing labels would not
+give a speed improvement since the labels are removed anyway in the end.
\begin{lstlisting}[label={lst:compilation},%
caption={Actual compilation.}]
repositories / msc-thesis1617.git / commitdiff