process rinus' textual comments on chp5-7

diff --git a/results.arch.tex b/results.arch.tex
index b6b0b3d..2d6f531 100644 (file)
--- a/results.arch.tex
+++ b/results.arch.tex
@@ -14,9 +14,9 @@ The following terms will be used throughout the following chapter:
 \begin{itemize}
        \item Device, Client
 
-               These terms denotes the actual device connected to the system. This can be a
-               real device such as a microcontroller but it can also just be a program
-               on the same machine as the server functioning as a client.
+               These terms denotes the actual device connected to the system. This can
+               be a real device such as a microcontroller but it can also just be a
+               program on the same machine as the server functioning as a client.
        \item Server, \gls{iTasks}-System
 
                This is the actual executable serving the \gls{iTasks} application. The
@@ -75,13 +75,13 @@ the device software.
 \subsection{Client}
 \subsubsection{Engine}
 The client is in a constant loop listening for input and waiting to execute
-\gls{Task}. The pseudocode for this is shown in Algorithm~\ref{alg:client}. The
-\CI{input\_available} function waits for input, but has a timeout set which can
-be interrupted. The timeout of the function determines the amount of loops per
-time interval and is a parameter that can be set during compilation for a
+\glspl{Task}. The pseudocode for this is shown in Algorithm~\ref{alg:client}.
+The \CI{input\_available} function waits for input, but has a timeout set which
+can be interrupted. The timeout of the function determines the amount of loops
+per time interval and is a parameter that can be set during compilation for a
 device.
 
-\begin{algorithm}[H]
+\begin{algorithm}
        \KwData{
                \textbf{list} $tasks$,
                \textbf{time} $t$
@@ -129,7 +129,7 @@ bytecode. \Glspl{SDS} consist only of an id, value and type. The pointer to the
 bytecode of the \gls{Task} always points to the location in the memory space.
 
 \begin{lstlisting}[language=C,label={lst:structs},%
-       caption={The data type storing the \glspl{Task}}]
+       caption={The data type storing the \glspl{Task}},float]
 struct task {
        uint16_t tasklength;
        uint16_t interval;
@@ -245,15 +245,15 @@ types.
        | SerialDevice TTYSettings
        | ...
 :: MTaskDevice =
-               { deviceTask :: Maybe TaskId
-               , deviceError :: Maybe String
+               { deviceTask     :: Maybe TaskId
+               , deviceError    :: Maybe String
                , deviceChannels :: String
-               , deviceName :: String
-               , deviceState :: BCState
-               , deviceTasks :: [MTaskTask]
-               , deviceData :: MTaskResource
-               , deviceSpec :: Maybe MTaskDeviceSpec
-               , deviceShares :: [MTaskShare]
+               , deviceName     :: String
+               , deviceState    :: BCState
+               , deviceTasks    :: [MTaskTask]
+               , deviceResource :: MTaskResource
+               , deviceSpec     :: Maybe MTaskDeviceSpec
+               , deviceShares   :: [MTaskShare]
        }
 
 channels :: MTaskDevice -> Shared Channels
@@ -595,7 +595,7 @@ server application.
        {Lifting \gls{mTask}-\glspl{Task} to \gls{iTasks}-\glspl{Task}}
 If the user does not want to know where and when a \gls{mTask} is actually
 executed and is just interested in the results it can lift the \gls{mTask} to
-an \gls{iTasks}-\glspl{Task}. The function is called with a name, \gls{mTask},
+an \gls{iTasks}-\gls{Task}. The function is called with a name, \gls{mTask},
 device and interval specification and it will return a \gls{Task} that finishes
 if and only if the \gls{mTask} has returned.
 

diff --git a/results.mtask.tex b/results.mtask.tex
index acc6a69..6ec25a4 100644 (file)
--- a/results.mtask.tex
+++ b/results.mtask.tex
@@ -38,18 +38,18 @@ reflected in the \CI{MTTask} message type.
 \end{itemize}
 
 \section{\gls{SDS} semantics}
-\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
+\Gls{mTask}-\glspl{SDS} on a client are available on the server as in the form
+of regular \gls{iTasks}-\glspl{SDS}. However, the same freedom that an
+\gls{SDS} has in the \gls{iTasks}-system 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 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
-is made to notify them of the update. \glspl{SDS} can update often and the
-update might not be the final value it will get. Implementing the same
-functionality on the \gls{mTask} client would result in a lot of expensive
-unneeded bandwidth usage. Therefore a device must publish the \gls{SDS}
-explicitly to save bandwidth.
+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 is made to notify them
+of the update. \glspl{SDS} can update often and the update might not be the
+final value it will get. Implementing the same functionality on the \gls{mTask}
+client would result in a lot of expensive unneeded bandwidth usage.  Therefore
+a device must publish the \gls{SDS} explicitly to save bandwidth.
 
 To add this functionality, the \CI{sds} class could be extended. However, this
 would result in having to update all existing views that use the \CI{sds}