process camil's comments

diff --git a/arch.devices.tex b/arch.devices.tex
index db56b48..20d0621 100644 (file)
--- a/arch.devices.tex
+++ b/arch.devices.tex
@@ -2,19 +2,18 @@ A device is suitable for the system as a client if it can run the engine.
 The engine is compiled from one codebase and devices implement (part of) the
 device specific interface. The shared codebase only uses standard \gls{C} and
 no special libraries or tricks are used. Therefore, the code is compilable for
 The engine is compiled from one codebase and devices implement (part of) the
 device specific interface. The shared codebase only uses standard \gls{C} and
 no special libraries or tricks are used. Therefore, the code is compilable for

-almost any device or system. Note that it is not needed to implement a full
-interface. The full interface --- excluding the device specific settings --- is
-listed in Appendix~\ref{app:device-interface}. The interface works in a
-similar fashion as the \gls{EDSL}. Devices do not have to implement all
-functionality, this is analogous to the fact that views do not have to
-implement all type classes in the \gls{EDSL}. When the device connects with
-the server for the first time, the specifications of what is implemented is
-communicated. Devices must be available throughout sessions and cannot always
-be kept in scope and therefore they are stored in an \gls{SDS}.
+almost any device or system. The full interface --- excluding the device
+specific settings --- is listed in Appendix~\ref{app:device-interface}. The
+interface works in a similar fashion as the \gls{EDSL}. Devices do not have to
+implement all functionality, this is analogous to the fact that views do not
+have to implement all type classes in the \gls{EDSL}. When the device connects
+with the server for the first time, the specifications of what is implemented
+is communicated. Devices must be available throughout sessions and cannot
+always be kept in scope and therefore they are stored in an \gls{SDS}.

 
 At the time of writing the following device families are supported and can run
 the device software. Porting the client software to a new device does not
 
 At the time of writing the following device families are supported and can run
 the device software. Porting the client software to a new device does not

-require a lot of work. For example, porting to the \texttt{mbed} device family
+require a lot of work. For example, porting to the \gls{mbed} device family

 only took about an hour.
 \begin{itemize}
        \item \texttt{POSIX} compatible systems connected via the \gls{TCP}.
 only took about an hour.
 \begin{itemize}
        \item \texttt{POSIX} compatible systems connected via the \gls{TCP}.


@@ -22,7 +21,7 @@ only took about an hour.
                This port only uses functionality from the standard \gls{C} library and
                therefore runs on \emph{Linux} and \emph{MacOS}.
        \item Microcontrollers supported by the
                This port only uses functionality from the standard \gls{C} library and
                therefore runs on \emph{Linux} and \emph{MacOS}.
        \item Microcontrollers supported by the

-               \texttt{mbed}\footnote{\url{https://mbed.com}} environment.
+               \gls{mbed}\footnote{\url{https://mbed.com}} environment.

 
                This is tested in particular on the \texttt{STM32f7x} series \gls{ARM}
                development board.
 
                This is tested in particular on the \texttt{STM32f7x} series \gls{ARM}
                development board.


@@ -41,8 +40,8 @@ only took about an hour.
                client has been made for the \texttt{ESP8266} powered \emph{NodeMCU}
                that is connected via \gls{TCP} over WiFi. A port also has been made
                for the regular \gls{Arduino} \emph{Uno} board which only boasts a
                client has been made for the \texttt{ESP8266} powered \emph{NodeMCU}
                that is connected via \gls{TCP} over WiFi. A port also has been made
                for the regular \gls{Arduino} \emph{Uno} board which only boasts a

-               meager \emph{2K} \emph{RAM}. The stack size and storage available for
-               devices boasting this little \emph{RAM} has to be smaller than default
+               meager \emph{2KB} RAM. The stack size and storage available for
+               devices boasting this little RAM has to be smaller than default

                but are still suitable to hold a hand full of \glspl{Task}.
 \end{itemize}
 
                but are still suitable to hold a hand full of \glspl{Task}.
 \end{itemize}
 


@@ -114,11 +113,11 @@ memory space are reordered in such a way that there are no holes left. In
 practice this means that if the first received \gls{Task} is removed, all
 \glspl{Task} received later will have to move back. Obviously, this is quite
 time intensive but it can not be permitted to leave holes in the memory since
 practice this means that if the first received \gls{Task} is removed, all
 \glspl{Task} received later will have to move back. Obviously, this is quite
 time intensive but it can not be permitted to leave holes in the memory since

-the memory space is so limited. This techniques allows for even the smallest
-tested microcontrollers with only $2K$ \emph{RAM} to hold several \glspl{Task}
-and \glspl{SDS}. Without this technique, the memory space will decrease over
-time and the client can then not run for very long since holes are evidently
-created at some point.
+the memory space is so limited. With this technique, even the smallest
+tested microcontrollers with only $2K$ RAM can hold several \glspl{Task} and
+\glspl{SDS}. Without this technique, the memory space will decrease over time
+and the client can then not run for very long since holes are evidently created
+at some point.

 
 The structure instances and helper functions for traversing for \glspl{Task}
 and \glspl{SDS} are shown in Listing~\ref{lst:structs}.
 
 The structure instances and helper functions for traversing for \glspl{Task}
 and \glspl{SDS} are shown in Listing~\ref{lst:structs}.

diff --git a/arch.example.tex b/arch.example.tex
index 828e097..ad8c4db 100644 (file)
--- a/arch.example.tex
+++ b/arch.example.tex
@@ -1,5 +1,5 @@
 \subsection{Framework}
 \subsection{Framework}

-Systems built with support for \gls{mTask} are often following the same design
+Systems built with support for \gls{mTask} often follow the same design

 pattern. First the devices are created --- with or without the interaction of
 the user --- and they are then connected. When all devices are registered, the
 \gls{mTask}-\glspl{Task} can be sent and \gls{iTasks}-\glspl{Task} can be
 pattern. First the devices are created --- with or without the interaction of
 the user --- and they are then connected. When all devices are registered, the
 \gls{mTask}-\glspl{Task} can be sent and \gls{iTasks}-\glspl{Task} can be


@@ -25,11 +25,12 @@ The thermostat is a classic example program for showing interactions between
 peripherals. The following program shows a system containing two devices. The
 first device --- the sensor --- contains a temperature sensor that measures the
 room temperature. The second device --- the actor --- contains a heater,
 peripherals. The following program shows a system containing two devices. The
 first device --- the sensor --- contains a temperature sensor that measures the
 room temperature. The second device --- the actor --- contains a heater,

-connected to the digital pin \CI{D5}. Moreover, this device contains a led to
-indicate whether the heater is on. The following code shows an implementation
-for this. The code fully uses the framework. Note that a little bit of type
-twiddling is required to fully us the result from the \gls{SDS}. This approach
-is still type safe due to the type safety of \CI{Dynamic}s.
+connected to the digital pin \CI{D5}. Moreover, this device contains an
+\gls{LED} to indicate whether the heater is on. The following code shows an
+implementation for this. The code makes use of all the aspects of the
+framework. Note that a little bit of type twiddling is required to fully use
+the result from the \gls{SDS}. This approach is still type safe due to the type
+safety of \CI{Dynamic}s.

 
 \begin{lstlisting}[caption={Thermostat example}]
 thermos :: Task ()
 
 \begin{lstlisting}[caption={Thermostat example}]
 thermos :: Task ()


@@ -55,8 +56,8 @@ where
 
 \subsection[Lifting mTasks to iTasks-Tasks]%
        {Lifting \gls{mTask}-\glspl{Task} to \gls{iTasks}-\glspl{Task}}
 
 \subsection[Lifting mTasks to iTasks-Tasks]%
        {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
+If the user does not want to know where and when an \gls{mTask} is actually
+executed and is just interested in the results, it can lift the \gls{mTask} to

 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.
 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.


@@ -72,7 +73,7 @@ where
 \end{lstlisting}
 
 The factorial function example from Chapter~\ref{chp:mtaskcont} can then be
 \end{lstlisting}
 
 The factorial function example from Chapter~\ref{chp:mtaskcont} can then be

-lifted to a real \gls{iTasks}-\gls{mTask} with the following code:
+lifted to a real \gls{iTasks}-\gls{Task} with the following code:

 \begin{lstlisting}[caption={Lifting the factorial \gls{Task} to \gls{iTasks}}]
 factorial :: MTaskDevice -> Task BCValue
 factorial dev = enterInformation "Factorial of ?" []
 \begin{lstlisting}[caption={Lifting the factorial \gls{Task} to \gls{iTasks}}]
 factorial :: MTaskDevice -> Task BCValue
 factorial dev = enterInformation "Factorial of ?" []


@@ -92,19 +93,19 @@ As an example, the addition of a new sensor will be demonstrated. The heartbeat
 and oxygen saturation sensor add-on is a \textsc{PCB} the size of a fingernail
 with a red \gls{LED} and a light sensor on it. Moreover, it contains an
 \textsc{I2C} chip to communicate. The company producing the chip provides the
 and oxygen saturation sensor add-on is a \textsc{PCB} the size of a fingernail
 with a red \gls{LED} and a light sensor on it. Moreover, it contains an
 \textsc{I2C} chip to communicate. The company producing the chip provides the

-programmer with example code for \gls{Arduino} and \textsc{mbed}. The sensor
-emits red light and measures the returning light intensity. The microcontroller
-hosting the device has to keep track of four seconds of samples to determine
-the heartbeat. In the \gls{mTask}-system, an abstraction is made. The current
-implementation runs on \textsc{mbed} supported devices.
+programmer with example code for \gls{Arduino} and \gls{mbed}. The sensor
+emits red light and measures the intensity of the light returned. The
+microcontroller hosting the device has to keep track of four seconds of samples
+to determine the heartbeat. In the \gls{mTask}-system, an abstraction is made.
+The current implementation runs on \gls{mbed} supported devices.

 
 \subsubsection{\gls{mTask} Classes}
 First, a class has to be devised to store the functionality of the sensor. The
 heartbeat sensor updates four values continuously, namely the heartbeat, the
 
 \subsubsection{\gls{mTask} Classes}
 First, a class has to be devised to store the functionality of the sensor. The
 heartbeat sensor updates four values continuously, namely the heartbeat, the

-validity of the reading, the oxygen saturation and the validity of it. For
-every value a function is added to the new \CI{hb} class. Moreover, the
-introduced datatype housing the values should implement the \CI{mTaskType}
-classes. The definition is as follows:
+oxygen saturation and the validity of the two. For every value a function is
+added to the new \CI{hb} class. Moreover, the introduced datatype housing the
+values should implement the \CI{mTaskType} classes. The definition is as
+follows:

 
 \begin{lstlisting}[caption={The \texttt{hb} class}]
 :: Heartbeat = HB Int
 
 \begin{lstlisting}[caption={The \texttt{hb} class}]
 :: Heartbeat = HB Int

diff --git a/arch.itasks.tex b/arch.itasks.tex
index 5ef0e6d..b8f4b08 100644 (file)
--- a/arch.itasks.tex
+++ b/arch.itasks.tex
@@ -7,7 +7,7 @@ devices and view the state of the system.
 
 \subsection{Device Storage}
 Everything that a device encompasses is stored in the \CI{MTaskDevice} record
 
 \subsection{Device Storage}
 Everything that a device encompasses is stored in the \CI{MTaskDevice} record

-type which is in turn stored in a \gls{SDS}. This includes management for the
+type which is in turn stored in an \gls{SDS}. This includes management for the

 \glspl{SDS} and \glspl{Task} stored on the device. The \CI{MTaskDevice}
 definition is shown in Listing~\ref{lst:mtaskdevice} accompanied with the
 necessary classes and sub types. Devices added to the system must be reachable
 \glspl{SDS} and \glspl{Task} stored on the device. The \CI{MTaskDevice}
 definition is shown in Listing~\ref{lst:mtaskdevice} accompanied with the
 necessary classes and sub types. Devices added to the system must be reachable


@@ -80,7 +80,6 @@ This has the implication that the server and the client can get out of sync.
 However, this is by design and well documented. In the current system, an
 \gls{SDS} can only reside on a single device.
 
 However, this is by design and well documented. In the current system, an
 \gls{SDS} can only reside on a single device.
 

-% TODO

 % Single share per share
 There are several possible approaches for storing \glspl{SDS} on the server
 each with their own level of control. A possible way is to --- in the device
 % Single share per share
 There are several possible approaches for storing \glspl{SDS} on the server
 each with their own level of control. A possible way is to --- in the device


@@ -93,13 +92,13 @@ on the device. Accessing the \gls{SDS} happens by calling the \CI{get},
 \CI{set} and \CI{upd} functions directory on the actual \gls{SDS}.
 
 % Single share per device
 \CI{set} and \CI{upd} functions directory on the actual \gls{SDS}.
 
 % Single share per device

-Another approach would be to have reference to a \gls{SDS} containing a table
-of \gls{SDS} values per device. This approach poses the same orphan problem as
-before. Accessing a single \gls{SDS} on the device happens by calling the
+Another approach would be to have reference to an \gls{SDS} containing a table
+of \gls{SDS} values per device. This approach suffers the same orphan problem
+as before. Accessing a single \gls{SDS} on the device happens by calling the

 \CI{get}, \CI{set} and \CI{upd} functions on the actual table \gls{SDS} with an
 \CI{get}, \CI{set} and \CI{upd} functions on the actual table \gls{SDS} with an

-applied \CI{mapReadWrite}. Using parametric lenses can circumvent problem of
-watchers getting notified for other shares that are written. Error handling is
-better than the previously mentioned approach because a \gls{SDS} can know
+applied \CI{mapReadWrite}. Using parametric lenses can circumvent the problem
+of watchers getting notified for other shares that are written. Error handling
+is better than the previously mentioned approach because an \gls{SDS} can know

 whether the \gls{SDS} has really gone because it will not be available anymore
 in the table. It still does not know whether the device is still available.
 
 whether the \gls{SDS} has really gone because it will not be available anymore
 in the table. It still does not know whether the device is still available.
 


@@ -117,8 +116,8 @@ high frequency.
 The type for the parametric lens of the \gls{SDS} containing all devices is
 \CI{Maybe (MTaskDevice, Int)}. There are several levels of abstraction that
 have to be introduced. First, the \gls{SDS} responsible for storing the entire
 The type for the parametric lens of the \gls{SDS} containing all devices is
 \CI{Maybe (MTaskDevice, Int)}. There are several levels of abstraction that
 have to be introduced. First, the \gls{SDS} responsible for storing the entire

-list of devices is called the global \gls{SDS}. Secondly, a \gls{SDS} can focus
-on a single device, such \glspl{SDS} are called local \glspl{SDS}. Finally, a
+list of devices is called the global \gls{SDS}. Secondly, an \gls{SDS} can focus
+on a single device, such \glspl{SDS} are called local \glspl{SDS}. Finally, an

 \gls{SDS} can focus on a single \gls{SDS} on a single device. These \glspl{SDS}
 are called share \glspl{SDS}. Using parametric lenses, the notifications can be
 directed to only the watchers interested. Moreover, using parametric lenses,
 \gls{SDS} can focus on a single \gls{SDS} on a single device. These \glspl{SDS}
 are called share \glspl{SDS}. Using parametric lenses, the notifications can be
 directed to only the watchers interested. Moreover, using parametric lenses,

diff --git a/arch.tex b/arch.tex
index 1ae8e44..1fd4d4f 100644 (file)
--- a/arch.tex
+++ b/arch.tex
@@ -6,7 +6,7 @@ interpreter which executes the \gls{Task}'s bytecode following the provided
 scheduling strategy. Devices added to the system are stored and get a profile
 for identification. These profiles are persistent during reboots of the
 \gls{iTasks}-system to allow for easy reconnecting with old devices. The way of
 scheduling strategy. Devices added to the system are stored and get a profile
 for identification. These profiles are persistent during reboots of the
 \gls{iTasks}-system to allow for easy reconnecting with old devices. The way of

-interacting with \gls{mTask}-\gls{Task} is analogous to interacting with
+interacting with \gls{mTask}-\glspl{Task} is analogous to interacting with

 \gls{iTasks}-\glspl{Task}. This means that programmers can access the
 \glspl{SDS} made for a device in the same way as regular \glspl{SDS} and they
 can execute, combine and transform \gls{mTask}-\glspl{Task} as if they where
 \gls{iTasks}-\glspl{Task}. This means that programmers can access the
 \glspl{SDS} made for a device in the same way as regular \glspl{SDS} and they
 can execute, combine and transform \gls{mTask}-\glspl{Task} as if they where

diff --git a/glossaries.tex b/glossaries.tex
index 809f8e7..87d8af6 100644 (file)
--- a/glossaries.tex
+++ b/glossaries.tex
@@ -34,6 +34,8 @@
        browsers}}
 \newglossaryentry{LED}{name={LED},
        description={Lighting Emitting Diode}}
        browsers}}
 \newglossaryentry{LED}{name={LED},
        description={Lighting Emitting Diode}}

+\newglossaryentry{mbed}{name={\textsc{mbed}},
+       description={is a programming framework for microcontrollers.}}

 \newcommand{\newglossacr}[2]{\newglossaryentry{#1}{
        name={#1},
        first={#2 (#1)},%
 \newcommand{\newglossacr}[2]{\newglossaryentry{#1}{
        name={#1},
        first={#2 (#1)},%

diff --git a/mtask.examples.tex b/mtask.examples.tex
index db15f5f..c98cdd3 100644 (file)
--- a/mtask.examples.tex
+++ b/mtask.examples.tex
@@ -2,14 +2,14 @@ Some example \gls{mTask}-\glspl{Task} --- using almost all of their
 functionality --- are shown in Listing~\ref{lst:exmtask}. The
 \gls{mTask}-\glspl{Task} shown in the example do not belong to a particular
 view and therefore are of the type \CI{View t r}.  The \CI{blink} \gls{mTask}
 functionality --- are shown in Listing~\ref{lst:exmtask}. The
 \gls{mTask}-\glspl{Task} shown in the example do not belong to a particular
 view and therefore are of the type \CI{View t r}.  The \CI{blink} \gls{mTask}

-show the classic \gls{Arduino} blinking led application that blinks a certain
-\gls{LED} every second. The \CI{thermostat} expression will enable a digital
-pin powering a cooling fan when the analog pin representing a temperature
-sensor is too high.  \CI{thermostat`} shows the same expression but now using
-the assignment style \gls{GPIO} technique. The \CI{thermostat} example also
-shows that it is not necessary to run everything as a \CI{task}. The main
-program code can also just consist of the contents of the root \CI{main}
-itself.
+show the classic \gls{Arduino} blinking \gls{LED} application that blinks a
+certain \gls{LED} every second. The \CI{thermostat} expression will enable a
+digital pin powering a cooling fan when the analog pin representing a
+temperature sensor is too high.  \CI{thermostat`} shows the same expression but
+now using the assignment style \gls{GPIO} technique. The \CI{thermostat}
+example also shows that it is not necessary to run everything as a \CI{task}.
+The main program code can also just consist of the contents of the root
+\CI{main} itself.

 
 \begin{lstlisting}[%
        label={lst:exmtask},caption={Some example \gls{mTask}-\glspl{Task}}]
 
 \begin{lstlisting}[%
        label={lst:exmtask},caption={Some example \gls{mTask}-\glspl{Task}}]

diff --git a/mtaskext.sdssem.tex b/mtaskext.sdssem.tex
index b0b8fa6..c4f2c2b 100644 (file)
--- a/mtaskext.sdssem.tex
+++ b/mtaskext.sdssem.tex
@@ -27,11 +27,12 @@ class sdspub v where
 
 Moreover, \glspl{SDS} in the \gls{mTask}-\gls{EDSL} are always anonymous. There
 is no way of labeling it since it is not a real entity, it is just a function.
 
 Moreover, \glspl{SDS} in the \gls{mTask}-\gls{EDSL} are always anonymous. There
 is no way of labeling it since it is not a real entity, it is just a function.

-When a \gls{SDS} is sent to the device it must be retrievable and identifiable.
-It is not always clear which instantiated \gls{SDS} is which. Therefore, an
-added class named \CI{namedsds} is added that provides the exact same
-functionality as the \gls{SDS} class but adds a \CI{String} parameter that can
-later be used to identify a \gls{SDS}. The types for this class are as follows:
+When an \gls{SDS} is sent to the device it must be retrievable and
+identifiable.  It is not always clear which instantiated \gls{SDS} is which.
+Therefore, an added class named \CI{namedsds} is added that provides the exact
+same functionality as the \gls{SDS} class but adds a \CI{String} parameter that
+can later be used to identify an \gls{SDS}. The types for this class are as
+follows:

 
 \begin{lstlisting}[caption={The \texttt{namedsds} class}]
 class namedsds v where
 
 \begin{lstlisting}[caption={The \texttt{namedsds} class}]
 class namedsds v where