From 76254fbf2941fa0b5a02ab3a98104cad56959218 Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Sun, 18 Jun 2017 09:59:55 +0200 Subject: [PATCH] process the rest of george's comments --- abstract.tex | 7 ++-- appendix-protocol.tex | 12 +++---- conclusion.tex | 82 +++++++++++++++++++++---------------------- introduction.tex | 32 +++++++++-------- methods.dsl.tex | 4 +-- methods.mtask.tex | 22 ++++++------ methods.top.tex | 33 ++++++++--------- results.arch.tex | 49 +++++++++++++------------- results.itasks.tex | 21 +++++------ results.mtask.tex | 60 +++++++++++++++---------------- 10 files changed, 164 insertions(+), 158 deletions(-) diff --git a/abstract.tex b/abstract.tex index dbd59b7..3e40f04 100644 --- a/abstract.tex +++ b/abstract.tex @@ -1,6 +1,7 @@ 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. diff --git a/appendix-protocol.tex b/appendix-protocol.tex index 08cb71b..3936588 100644 --- a/appendix-protocol.tex +++ b/appendix-protocol.tex @@ -28,10 +28,10 @@ the message is not acknowledged or responded upon. 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} @@ -41,18 +41,18 @@ the message is not acknowledged or responded upon. 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} diff --git a/conclusion.tex b/conclusion.tex index 729f479..406c744 100644 --- a/conclusion.tex +++ b/conclusion.tex @@ -1,34 +1,8 @@ -\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. @@ -37,13 +11,13 @@ 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} @@ -51,10 +25,10 @@ True multitasking could be added to the client software. This allows \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 @@ -70,28 +44,52 @@ given. 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. diff --git a/introduction.tex b/introduction.tex index 775a7b5..62bbb9f 100644 --- a/introduction.tex +++ b/introduction.tex @@ -7,24 +7,24 @@ communication between them. However, currently the term \gls{IoT} encompasses 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 @@ -42,7 +42,7 @@ This forces a fixed logic in the device that is set at compile time. Many 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 @@ -50,10 +50,10 @@ and a very limited amount of processing power and are therefore not suitable to 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} @@ -84,6 +84,10 @@ communicating between the server and client. 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 @@ -100,9 +104,9 @@ https://leventerkok.github.io/hArduino}). [Accessed: 23-May-2017].}. \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 @@ -113,16 +117,16 @@ is sent to the device. \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 diff --git a/methods.dsl.tex b/methods.dsl.tex index 3b4181e..be8bf74 100644 --- a/methods.dsl.tex +++ b/methods.dsl.tex @@ -32,11 +32,11 @@ Evermore so, extending the \gls{ADT} is easy and convenient but extending the 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. diff --git a/methods.mtask.tex b/methods.mtask.tex index 4e61d97..d6fcbb3 100644 --- a/methods.mtask.tex +++ b/methods.mtask.tex @@ -2,7 +2,7 @@ The \gls{mTask}-\gls{EDSL} is the basis on which the system is built. The \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 @@ -62,15 +62,15 @@ class boolExpr v where \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. @@ -182,11 +182,11 @@ similar fashion as the \texttt{sds} class. This class is listed in 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) | ... diff --git a/methods.top.tex b/methods.top.tex index e6b7580..e83b6b7 100644 --- a/methods.top.tex +++ b/methods.top.tex @@ -1,7 +1,7 @@ \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 @@ -71,8 +71,8 @@ Generated interfaces can be modified with decoration operators. 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} @@ -126,19 +126,20 @@ system time, a random integer or just some data stored in memory. The actual 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}] @@ -163,14 +164,14 @@ of the resource. When this happens, all waiting \glspl{Task} looking at the 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 diff --git a/results.arch.tex b/results.arch.tex index f9b6725..e276010 100644 --- a/results.arch.tex +++ b/results.arch.tex @@ -65,7 +65,7 @@ the device software. \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 @@ -90,17 +90,17 @@ a list of \CI{MTaskDevice}s. The exact specification is defined as in 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 @@ -207,8 +207,8 @@ function and the record is updated accordingly. \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 @@ -223,17 +223,18 @@ is shown in Figure~\ref{fig:tasksend}. \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}] diff --git a/results.itasks.tex b/results.itasks.tex index a2200c7..3c25317 100644 --- a/results.itasks.tex +++ b/results.itasks.tex @@ -1,13 +1,13 @@ 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},% @@ -21,10 +21,11 @@ An image of the management interface is shown in Figure~\ref{lst:manage}. 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 @@ -71,8 +72,8 @@ functions. \CI{sdsFocus} allows the programmer to fix the parameter. 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},% diff --git a/results.mtask.tex b/results.mtask.tex index 1b46df1..edb3d66 100644 --- a/results.mtask.tex +++ b/results.mtask.tex @@ -9,10 +9,10 @@ without interfering with the existing views. \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}. @@ -21,21 +21,21 @@ 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}} @@ -66,16 +66,16 @@ added to the \gls{mTask}-system encapsulated in the type \CI{ByteCode}. As 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 @@ -118,7 +118,7 @@ kept large, but under $255$, to get the highest expressivity for the lowest 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 @@ -150,17 +150,17 @@ instructions. | 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 @@ -201,11 +201,11 @@ instance userLed ByteCode where \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}}] @@ -230,9 +230,9 @@ instance noOp ByteCode where \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}. @@ -277,10 +277,10 @@ This function compiles the bytecode and transforms the \gls{Task} in a message. 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.}] -- 2.20.1