From 78d08778c999d9bb644b76e4c8dd1a248917429f Mon Sep 17 00:00:00 2001
From: Mart Lubbers <mart@martlubbers.net>
Date: Thu, 29 Jun 2017 13:22:08 +0200
Subject: [PATCH] process rinus' textual comments on chp5-7
---
results.arch.tex | 36 ++++++++++++++++++------------------
results.mtask.tex | 22 +++++++++++-----------
2 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/results.arch.tex b/results.arch.tex
index b6b0b3d..2d6f531 100644
--- 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
--- 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}
--
2.20.1