fix listings, process comments

[msc-thesis1617.git] / arch.itasks.tex

diff --git a/arch.itasks.tex b/arch.itasks.tex
index 1b3384f..5168510 100644 (file)
--- a/arch.itasks.tex
+++ b/arch.itasks.tex
@@ -1,9 +1,13 @@
 The server part of the system is written in \gls{iTasks}. Functions for
-managing devices, \glspl{Task} and \glspl{SDS} are available. Furthermore, an
+managing are added. This includes functionality for adding, removing and
+updating devices. Functions for sending \glspl{Task} and \glspl{SDS} to devices
+and functionality to remove them.
+Furthermore, an
 interactive web application has been created that provides an interactive
-management console for the \gls{mTask} system. This interface provides
-functionality to list \glspl{SDS}, add and remove \glspl{Task}, administrate
-devices and view the state of the system.
+management console for these manageming tasks. This interface provides
+functionality to show \glspl{Task} and \glspl{SDS} and their according status.
+It also provides the user with a library of example \gls{mTask}-\glspl{Task}
+that can be sent interactively to the device.
 
 \subsection{Device Storage}
 Everything that a device encompasses is stored in the \CI{MTaskDevice} record
@@ -14,11 +18,11 @@ necessary classes and sub types. Devices added to the system must be reachable
 asynchronously. This implies that the programmer only needs to keep hold of
 the reference to the device and not the actual device record.
 
-\begin{lstlisting}[caption={Device type},label={lst:mtaskdevice}]
+\begin{lstlisting}[language=Clean,caption={Device type},label={lst:mtaskdevice}]
 :: Channels :== ([MTaskMSGRecv], [MTaskMSGSend], Bool)
-:: MTaskDeviceSpec = ... // Also explained in later sections
-:: MTaskMSGRecv = ...    // Message format, explained in later sections
-:: MTaskMSGSend = ...    // Also explained in later sections
+:: MTaskDeviceSpec = ... // Explained in a later section
+:: MTaskMSGRecv = ...    // Message format, explained in a later section
+:: MTaskMSGSend = ...    // Also explained in a later section
 :: MTaskResource
        = TCPDevice TCPSettings
        | SerialDevice TTYSettings
@@ -153,7 +157,7 @@ can determine whether the second argument --- the reader --- needs to be
 notified. In practice, the reader only needs to be notified when the parameters
 are exactly the same.
 
-\begin{lstlisting}[label={lst:actualdev},%
+\begin{lstlisting}[language=Clean,label={lst:actualdev},%
        caption={Device \gls{SDS}}]
 ($<) :: a (f a) -> (f b)
 ($<) a fb = fmap (const a) fb
@@ -188,7 +192,7 @@ Accessing the global \gls{SDS} is just a matter of focussing the
 \gls{SDS} will only be notified if a device is added or removed. The actual
 code is as follows:
 
-\begin{lstlisting}[caption={Global \gls{SDS}}]
+\begin{lstlisting}[language=Clean,caption={Global \gls{SDS}}]
 deviceStoreNP :: Shared [MTaskDevice]
 deviceStoreNP = sdsFocus Nothing deviceStore
 \end{lstlisting}
@@ -201,7 +205,7 @@ channels and is unique throughout the system. This type of \gls{SDS} will only
 be notified if the device itself changed. It will not be notified when only a
 single \gls{SDS} on the device changes. The implementation is as follows:
 
-\begin{lstlisting}[caption={Local \gls{SDS}}]
+\begin{lstlisting}[language=Clean,caption={Local \gls{SDS}}]
 deviceShare :: MTaskDevice -> Shared MTaskDevice
 deviceShare d = mapReadWriteError
        ( \ds->case find ((==)d) ds of
@@ -222,7 +226,7 @@ the local \gls{SDS} only treating it as references. It uses the
 a \gls{Task} writes to this \gls{SDS}, the global \gls{SDS} will know this
 through the parameter and propagate the value to the device.
 
-\begin{lstlisting}[caption={Local \gls{SDS}}]
+\begin{lstlisting}[language=Clean,caption={Local \gls{SDS}}]
 shareShare :: MTaskDevice MTaskShare -> Shared BCValue
 shareShare dev share = sdsFocus ()
        $ mapReadWriteError (read, write)