X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=methods.tex;h=473efcf090a714e2eac5fa98addf9ee3be0ca80c;hb=dc057560c806a535088e1d9ebdbdd0737467ecc3;hp=ae920752bbcc48978022018e22c1ddf59d2d5e57;hpb=57dab117db1fa358785cc3992053206584df0b53;p=msc-thesis1617.git diff --git a/methods.tex b/methods.tex index ae92075..473efcf 100644 --- a/methods.tex +++ b/methods.tex @@ -1,181 +1,155 @@ \section{\acrlong{TOP}} \gls{TOP} is a recent new programming paradigm implemented as -\gls{iTasks}~\cite{achten_introduction_2015} in -the pure lazy functional language \gls{Clean} +\gls{iTasks}\cite{achten_introduction_2015} in the pure lazy functional +language \gls{Clean}\cite{brus_cleanlanguage_1987}. \gls{iTasks} is a +\gls{EDSL} to model workflow tasks in the broadest sense. A \CI{Task} is just +a function that, given some state, returns the observable value of the +\CI{TaskValue}. A simple example is shown in Listing~\ref{lst:taskex} +accompanied with Figure~\ref{fig:taskex1},~\ref{fig:taskex2} and~% +\ref{fig:taskex3}. -\todo{Main terms} -The lazy functional programming language based on graph rewriting -\gls{Clean}~\cite{brus_cleanlanguage_1987} +\begin{lstlisting}[language=Clean,label={lst:taskex},% + caption={An example \gls{Task} for entering a name}] +:: Name = { firstname :: String + , lastname :: String + } + +derive class iTask Name + +enterInformation :: String [EnterOption m] -> (Task m) | iTask m + +enterName :: Task Name +enterName = enterInformation "Enter your name" [] +\end{lstlisting} + +\begin{figure}[H] + \begin{subfigure}{.25\textwidth} + \centering + \includegraphics[width=.9\linewidth]{taskex1} + \caption{Initial interface}\label{fig:taskex1} + \end{subfigure} + \begin{subfigure}{.25\textwidth} + \centering + \includegraphics[width=.9\linewidth]{taskex2} + \caption{Incomplete entrance}\label{fig:taskex2} + \end{subfigure} + \begin{subfigure}{.25\textwidth} + \centering + \includegraphics[width=.9\linewidth]{taskex3} + \caption{Complete entry}\label{fig:taskex3} + \end{subfigure} + \caption{Example of a generated user interface} +\end{figure} \section{\acrlong{EDSL}s} +\glspl{mTask} are expressed in a class based shallowly embedded \gls{EDSL}. +There are two main types of \glspl{EDSL}. +\todo{Small shallow embedded dsl intro} +\todo{Small deep embedded dsl} +\todo{Show that class based has the best of both worlds} +\section{Architecture} \section{Devices} +The client code for the devices is compiled from one codebase. For a device to +be eligible for \glspl{mTask} it must be able to compile the shared codebase +and 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\todo{handshake}. The full interface, +listed in Appendix~\label{app:device-interface}\todo{update interface listing}, +also includes functions for accessing the peripherals that not every device +might have. Devices can choose what to implement by setting the correct macros +in the top of the file. +\todo{Supported devices} + \subsection{Specification} +Devices are stored in a record type and all devices in the system are stored in +a \gls{SDS} containing all devices. From the macro settings in the interface +file a profile is created for the device that describes the specification. When +a connection between the server and a client is established the server will +send a request for specification. The client will serialize his specs and send +it to the server so that the server knows what the client is capable of. The +exact specification is listed in Listing~\ref{lst:devicespec} + +\begin{lstlisting}[language=Clean,label={lst:devicespec}, + caption={Device specification for \glspl{mTask}}] +:: MTaskDeviceSpec = + {haveLed :: Bool + ,haveAio :: Bool + ,haveDio :: Bool + ,taskSpace :: Int // Bytes + ,sdsSpace :: Int // Bytes + } +\end{lstlisting} +\todo{Explain specification, combine task and share space} \subsection{Communication} +\section{mTasks} +\subsection{\gls{EDSL}} +The \gls{mTask}-\gls{EDSL} contains several classes that need to be implemented +by a type for it to be an \gls{mTask}. For numeric and boolean arithmetic the +classes \texttt{arith} and \texttt{boolExpr} are available and listed in a +shortened version in Listing~\ref{lst:arithbool}. All classes are to be +implemented by types of kind \texttt{*->*->*} a type \texttt{v t p}, +respectively a view with a type and the role. + +\texttt{lit} lifts a constant to the \gls{mTask} domain. For a type to be a +valid \gls{mTask} type it needs to implement the \texttt{mTaskType} class. The +binary operators work as expected. + +\begin{lstlisting}[language=Clean,label={lst:arithbool}, + caption={Basic classes for expressions}] +class mTaskType a | toByteCode, fromByteCode, iTask, TC a + +class arith v where + lit :: t -> v t Expr | mTaskType t + (+.) infixl 6 :: (v t p) (v t q) -> v t Expr | type, +, zero t & isExpr p & isExpr q + ... +class boolExpr v where + (&.) infixr 3 :: (v Bool p) (v Bool q) -> v Bool Expr | isExpr p & isExpr q + Not :: (v Bool p) -> v Bool Expr | isExpr p + ... + (==.) infix 4 :: (v a p) (v a q) -> v Bool Expr | ==, toCode a & isExpr p & isExpr q +\end{lstlisting} + + +\subsection{Tasks} + +\subsection{Shares} +Shares can live on multiple clients at the same time. For every share created +for an \gls{mTask} a real \gls{SDS} is created that mirrors the value on the +client. All shares currently in use are stored in a system-wide \gls{SDS} in +such a way that the actual share can be retrieved at any moment. All shares +have a unique numeric identifier and an initial value. + +\begin{lstlisting}[language=Clean,label={lst:sharespec}, caption={\acrlong{SDS}}] +:: BCValue = E.e: BCValue e & mTaskType e +:: MTaskShareType = MTaskWithShare String | MTaskLens String +:: MTaskShare = + {withTask :: [String] + ,withDevice :: [String] + ,identifier :: Int + ,realShare :: MTaskShareType + ,value :: BCValue + } + +sdsStore :: Shared [MTaskShare] +\end{lstlisting} +\todo{Do something with the sharetype} + +\subsection{Communication} +%\todo{Handshake, device specification sending, spec.c} +%\todo{mTaskDevice class interface} \section{mTasks} \subsection{\gls{EDSL}} +\todo{Show the classes} \subsection{Shares} -%\subsection{Serial port communication in Clean and iTasks} -%In the first exploration stage I added duplex serial port communication to -%iTasks in the same way as TCP is added. To make it work several changes had to -%be done to the iTasks core to allow backgroundtasks to be added at runtime. The -%function shown in Listing~\ref{lst:serialtask} results into a task that -%sends the data added to the output queue through the serial port and adds data -%received to the input queue for the user to process. -% -%\begin{lstlisting}[caption={Serial port communication in iTasks}, -% language=Clean,label={lst:serialtask}] -%syncSerialChannel :: String TTYSettings (Shared ([String],[String],Bool)) -> Task () -% -%:: ByteSize = BytesizeFive | BytesizeSix | BytesizeSeven | BytesizeEight -%:: Parity = ParityNone | ...ParityOdd | ParityEven | ParitySpace | ParityMark -%:: BaudRate = ... | B9600 | B19200 | ... -%:: TTYSettings = { -% baudrate :: BaudRate, -% bytesize :: ByteSize, -% parity :: Parity, -% stop2bits :: Bool, -% xonxoff :: Bool} -%\end{lstlisting} -% -%\subsection{mTasks} -%The core of the project revolves around the embedded domain specific language -%(EDSL) called mTask designed by Pieter Koopman. mTasks is used to use the task -%oriented programming on microcontrollers in a type-safe environment. Originally -%mTasks are compiled to c code that could be compiled for arduino compatible -%devices. Such generated code will be flashed to the program memory once. In -%short, the original mTask system is comparable to an entire iTasks sytem -%including the engine. -% -%For this project the imperative language constructs of the mTask DSL are used. -%Listing~\ref{lst:mtask} shows some of these class base DSL components for -%things like arithmetics, sequencing, conditionals, shared data sources and -%interaction with the user LEDs. Together with some helper functions code -%programmed in this DSL can be compiled to bytecode and sent to a device. -% -%\begin{lstlisting}[language=Clean,label={lst:mtask}, -% caption={Parts of the mTask DSL}] -%:: Upd = Upd -%:: Expr = Expr -%:: Stmt = Stmt -%:: UserLED = LED1 | LED2 | LED3 -% -%:: Main a = {main :: a} -% -%class arith v where -% lit :: t -> v t Expr | ... -% (+.) infixl 6 :: (v t p) (v t q) -> v t Expr | ... -%class IF v where -% IF :: (v Bool p) (v t q) (v s r) -> v () Stmt | isExpr p -%class sds v where -% sds :: ((v t Upd)->In t (Main (v c s))) -> (Main (v c s)) | ... -% pub :: (v t Upd) -> v t Expr | ... -%class seq v where -% (:.) infixr 0 :: (v t p) (v u q) -> v u Stmt | ... -%class assign v where -% (=.) infixr 2 :: (v t Upd) (v t p) -> v t Expr | ... -%class noOp v where noOp :: v t p -%class userLed v where -% ledOn :: UserLED -> (v () Stmt) -% ledOff :: UserLED -> (v () Stmt) -%\end{lstlisting} -% -%\subsection{iTasks} -%In iTasks several tasks have been devised to handle the communication. Moreover -%the tasks will synchronize the shared data sources in the mTask domain with -%real SDSs in the iTasks domain allowing for communication between mTasks and -%iTasks tasks. To not clutter the communication channels the SDSs are not -%synchronized on every change on the device. When a share changes on the server -%his new value will be pushed to the device immediately. When a share is updated -%on the client it must be explicitly published using. This approach has been -%taken because some shares might be only used internally and therefore would -%clutter the communication channels that could be low-bandwidth. -% -% -%\subsection{Devices} -%For the devices an engine has been built that can receive mTasks and SDSs and -%execute them accordingly. To add a new device to the list the programmer just -%has to implement a relatively small interface. All the other functionality is -%using standard C or the interface. This interface is listed in~% -%\ref{lst:interface} and includes reading and writing data, controlling the -%peripherals and some auxiliary functions. -% -%\begin{lstlisting}[language=c,caption={Device interface},label={lst:interface}] -%uint8_t read_byte(void); -%void write_byte(uint8_t b); -% -%void write_dpin(uint8_t i, bool b); -%bool read_dpin(uint8_t i); -% -%void write_apin(uint8_t i, uint8_t a); -%uint8_t read_apin(uint8_t i); -% -%long millis(void); -%bool input_available(void); -%void delay(long ms); -% -%void setup(void); -%void debug(char *fmt, ...); -%void pdie(char *s); -%void die(char *fmt, ...); -%\end{lstlisting} -% -%mTasks run either at a fixed interval or are one-shot which is added to the -%message. The entire protocol specification can be found in the code that is -%available. When an mTask is one-shot it will only be executed once and then -%removed. This can be useful for user related tasks such as shutting down blinds -%or turning on lights for an indefinite time. mTasks that run at a fixed -%interval time can be used to monitor sensors or to periodically communicate -%with peripherals like LCD screens. -% -%There are many things to be improved upon in future research. Most likely these -%points will be touched upon in my Master's thesis research. -%\begin{itemize} -% \item Support task combinators and functions. -% -% The mTask language already supports the step combinator and it might be -% fruitful to add for more expressively. Moreover functions would also -% add a lot. They can be used to share code between tasks to reduce the -% bytecode size. -% \item Seamless integration with iTasks. -% -% At the moment everything works but is hacked together. I would like to -% extend this with a more robust system that allows adding devices on the -% fly and adds functionality to monitor the mTask devices. -% \item Dynamic mTask/SDS allocation. -% -% Currently all client data for mTask and SDS storage is statically -% allocated. This means that when only a few tasks are used the memory -% needed is too high. This can be improved upon by only allocating -% resources for tasks when they are requested and this would allow the -% system to run on low memory devices like arduino's. -% \item Extend on SDSs. -% -% In the current system the shared data sources used in mTask programs -% live in a different domain and are synchronized with an iTask -% counterpart. Programming mTasks could be made more intuitive if you -% could use standard SDSs from iTasks. Moreover, at the moment only -% integer and boolean shares are allowed. This really should be extended -% to at least strings. -% \item Slicing tasks. -% -% Every mTask runs in its entirety and to not run into race and -% scheduling problems loops are not allowed in the mTasks. An improvement -% to this could be multithreading the tasks by giving them slices of -% computation and pausing them every slice. In this way loops could be -% allowed without blocking the entire system. It does require more memory -% however. -% \item Run tasks when an interrupt fires. -% -% Tasks can be scheduled either one-shot or at an interval. It might be -% useful to tie mTasks to hardware interrupts to increase responsiveness -% and possibly battery life. These interrupts do not need to be hardware -% based. A usecase might be to run a task when some other task is -% yielding a value (see task combinators) or to run a task when a shared -% data source is received from the server. -%\end{itemize} +\todo{Show the types and why} + +Shares are used to store the values + +Shares all have