update conclusion and add mTask stuff
authorMart Lubbers <mart@martlubbers.net>
Fri, 2 Jun 2017 12:59:52 +0000 (14:59 +0200)
committerMart Lubbers <mart@martlubbers.net>
Fri, 2 Jun 2017 12:59:52 +0000 (14:59 +0200)
conclusion.tex
methods.mtask.tex
thesis.loa [deleted file]

index 850e4b4..6ee7e67 100644 (file)
@@ -23,7 +23,6 @@ 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}
 
 \section{Future Research}
@@ -50,4 +49,6 @@ Future improvements of the system could be:
                \gls{mTask}-\glspl{Task}. This could be extended to a similar system
                as in the \gls{C}-code generation view. The \glspl{Task} can launch
                other \glspl{Task} and compose \glspl{Task} of subtasks.
+       \item Implement other classes from the \gls{mTask}-\gls{EDSL} such as the
+               \CI{mtask} class that allows tasks launching new tasks.
 \end{itemize}
index 48f8844..a0ec96b 100644 (file)
@@ -35,47 +35,6 @@ instance isExpr Upd
 instance isExpr Expr
 \end{lstlisting}
 
-\section{Semantics}
-The \gls{C}-backend of the \gls{mTask}-system has an engine that is generated
-alongside the code for the \glspl{Task}. This engine will execute the
-\glspl{mTask} according to certain rules and semantics.
-\glspl{mTask} do not behave like functions but more like
-\gls{iTasks}-\glspl{Task}. An \gls{mTask} is queued when either his timer runs
-out or when it is started by another \gls{mTask}. When an \gls{mTask} is
-queued it does not block the execution but it will return immediately while
-the actual \gls{Task} will be executed some time in the future.
-
-The \gls{iTasks}-backend simulates the \gls{C}-backend and thus uses the same
-semantics. This engine expressed in pseudocode is listed as
-Algorithm~\ref{lst:engine}. All the \glspl{Task} are inspected on their waiting
-time. When the waiting time has not passed the delta is subtracted and they are
-pushed to the end of the queue. When the waiting has has surpassed they are
-executed. When a \gls{mTask} wants to queue another \gls{mTask} it can just
-append it to the queue.
-
-\begin{algorithm}[H]
-       \KwData{\textbf{queue} queue, \textbf{time} $t, t_p$}
-
-       $t\leftarrow\text{now}()$\;
-       \Begin{
-               \While{true}{
-                       $t_p\leftarrow t$\;
-                       $t\leftarrow\text{now}()$\;
-                       \If{notEmpty$($queue$)$}{
-                               $task\leftarrow \text{queue.pop}()$\;
-                               $task$.wait $\leftarrow task$.wait $-(t-t_p)$\;
-                               \eIf{$task.wait>t_0$}{
-                                       queue.append$(task)$\;
-                               }{
-                                       run\_task$(task)$\;
-                               }
-                       }
-               }
-       }
-       \caption{Engine pseudocode for the \gls{C}- and
-               \gls{iTasks}-backend}\label{lst:engine}
-\end{algorithm}
-
 \section{Expressions}
 Expressions in the \gls{mTask}-\gls{EDSL} are divided into two types, namely
 boolean expressions and arithmetic expressions. The class of arithmetic
@@ -167,24 +126,79 @@ class sds v where
   sds :: ((v t Upd)->In t (Main (v c s))) -> (Main (v c s)) | ...
 \end{lstlisting}
 
+\section{Semantics}
+The \gls{C}-backend of the \gls{mTask}-system has an engine that is generated
+alongside the code for the \glspl{Task}. This engine will execute the
+\glspl{mTask} according to certain rules and semantics.
+\glspl{mTask} do not behave like functions but more like
+\gls{iTasks}-\glspl{Task}. An \gls{mTask} is queued when either his timer runs
+out or when it is started by another \gls{mTask}. When an \gls{mTask} is
+queued it does not block the execution but it will return immediately while
+the actual \gls{Task} will be executed some time in the future.
+
+The \gls{iTasks}-backend simulates the \gls{C}-backend and thus uses the same
+semantics. This engine expressed in pseudocode is listed as
+Algorithm~\ref{lst:engine}. All the \glspl{Task} are inspected on their waiting
+time. When the waiting time has not passed the delta is subtracted and they are
+pushed to the end of the queue. When the waiting has has surpassed they are
+executed. When a \gls{mTask} wants to queue another \gls{mTask} it can just
+append it to the queue.
+
+\begin{algorithm}[H]
+       \KwData{\textbf{queue} queue, \textbf{time} $t, t_p$}
+
+       $t\leftarrow\text{now}()$\;
+       \Begin{
+               \While{true}{
+                       $t_p\leftarrow t$\;
+                       $t\leftarrow\text{now}()$\;
+                       \If{notEmpty$($queue$)$}{
+                               $task\leftarrow \text{queue.pop}()$\;
+                               $task$.wait $\leftarrow task$.wait $-(t-t_p)$\;
+                               \eIf{$task.wait>t_0$}{
+                                       queue.append$(task)$\;
+                               }{
+                                       run\_task$(task)$\;
+                               }
+                       }
+               }
+       }
+       \caption{Engine pseudocode for the \gls{C}- and
+               \gls{iTasks}-backend}\label{lst:engine}
+\end{algorithm}
+
+To achieve this in the \gls{EDSL} a \gls{Task} clas are added that work in a
+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
+rather arcane and therefore an example is given. The aforementioned Listing
+shows a simple specification containing one task that increments a value
+indefinitely every one seconds.
+
+\begin{lstlisting}[language=Clean,label={lst:taskclass},%
+       caption={The classes for defining tasks}]
+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) | ...
+
+count = task \count = (\n.count (lit 1000) (n +. One)) In {main = count (lit 1000) Zero}
+\end{lstlisting}
+
 \section{Example mTask}
-\todo{Also explain semantics about running tasks}
 Some example \glspl{mTask} using almost all of the functionality are shown in
 Listing~\ref{lst:exmtask}. The \glspl{mTask} 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 \emph{Arduino} \emph{Hello World!}
-application that blinks a certain LED at each interval. The \CI{thermostat}
-\gls{mTask} will enable a digital pin powering a cooling fan when the analog
+\CI{blink} \gls{mTask} show the classic \gls{Arduino} \emph{Hello World!}
+application that blinks a certain 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 program but now using the assignment style \gls{GPIO}.
+same expression but now using the assignment style \gls{GPIO} technique.
 
 \begin{lstlisting}[%
        language=Clean,label={lst:exmtask},caption={Some example \glspl{mTask}}]
-blink :: Main (View Int Stmt)
-blink = sds \x=1 In sds \led=LED1 In {main =
-  IF (x ==. lit 1) (ledOn led) (ledOff led) :.
-  x =. lit 1 -. x
-  }
+blink = task \blink=(\x.
+               IF (x ==. lit True) (ledOn led) (ledOff led) :.
+               blink (lit 1000) (Not x)
+       In {main=blink (lit 1000) True}
 
 thermostat :: Main (View () Stmt)
 thermostat = {main =
diff --git a/thesis.loa b/thesis.loa
deleted file mode 100644 (file)
index 5279714..0000000
+++ /dev/null
@@ -1,10 +0,0 @@
-\addvspace {10\p@ }
-\addvspace {10\p@ }
-\addvspace {10\p@ }
-\addvspace {10\p@ }
-\contentsline {algocf}{\numberline {1}{\ignorespaces Engine pseudocode for the \gls {C}- and \gls {iTasks}-backend\relax }}{14}{algocf.1}
-\addvspace {10\p@ }
-\addvspace {10\p@ }
-\addvspace {10\p@ }
-\addvspace {10\p@ }
-\addvspace {10\p@ }