From: Mart Lubbers Date: Tue, 7 Mar 2023 10:56:02 +0000 (+0100) Subject: process many comments X-Git-Url: https://git.martlubbers.net/?a=commitdiff_plain;h=20d972f3af3f073519e6e3e23edf4eb725f8f52d;p=phd-thesis.git process many comments --- diff --git a/bib/tiot.bib b/bib/tiot.bib index ba70002..c0d034c 100644 --- a/bib/tiot.bib +++ b/bib/tiot.bib @@ -1207,7 +1207,7 @@ @online{ diffmicro, title = "MicroPython Differences from CPython", - author = {{Micropython Team}}, + author = {{Micropython\kern-1.43065pt Team}}, date = "2022", url = {https://docs.micropython.org/en/latest/genrst/index.html} } diff --git a/coda/coda.tex b/coda/coda.tex index c05becb..4edce6b 100644 --- a/coda/coda.tex +++ b/coda/coda.tex @@ -20,7 +20,7 @@ The edge, or perception, layer of an \gls{IOT} system is often powered by microc These small and cheap computers do not have powerful hardware but are energy efficient and support many sensors and actuators. While the term \gls{IOT} has already been known for almost thirty years, only recently, the exponential growth of the number of \gls{IOT} edge devices is really ramping up. Programming \gls{IOT} systems is very complex because each layer of the system is built with different computers, hardware architectures, programming languages, programming paradigms, and abstraction levels. -This generates a lot of semantic friction.\todo[inline]{benoem ook de andere problemen. Geen over all type check om correcte samenwerking te garanderen.} +This generates a lot of semantic friction and interoperation issues. Furthermore, \gls{IOT} systems become convoluted because they are dynamic, multi-tiered, multi-user, multitasking, interactive, distributed, and collaborative in nature. \Gls{TOP} proves a suitable programming paradigm that allows the declarative specification of exactly such systems. However, edge devices are often too computationally restricted to be able to run a full-fledged \gls{TOP} system such as \gls{ITASK}. @@ -34,6 +34,7 @@ Finally, in \cref{prt:tvt} it compares how this approach compares to existing ap \subsection{\nameref{prt:dsl}} \Cref{prt:dsl} presents some tool crafting techniques that are useful for creating \gls{TOP} languages for \gls{IOT} edge devices. It presents two novel techniques for embedding \glspl{DSL} in \gls{FP} languages. +Both technique make it easier for \gls{DSL} developers to create rich and extensible \glspl{DSL}. Classy deep embedding is a novel \gls{EDSL} embedding technique. When embedding \glspl{DSL}, one always has to make concessions. @@ -49,8 +50,6 @@ They are not automatically useable in the \gls{DSL} because the interfaces such I show how to automatically generate the required boilerplate for shallowly embedded \glspl{DSL} in order to make data types from the host language first-class citizens in the \gls{DSL}. The scaffolding is generated using template metaprogramming and quasiquotation is used to alleviate the programmer from the syntax burden and support pattern matching. -\todo[inline]{Paar zinnen over het nut van deze tool crafts: het maakt het voor DSL-developpers in het algemeen makkelijker om uitbreidbare DSLs te maken.} - \subsection{\nameref{prt:top}} General-purpose \gls{TOP} systems cannot run on edge devices due to their significant hardware requirements. However, with the right techniques, \glspl{DSL} can be created that can be executed on edge devices while maintaining the high abstraction level. @@ -62,11 +61,9 @@ The \gls{MTASK} system is fully integrated with the \gls{ITASK} system, a \gls{T In the \gls{ITASK} system, there are abstractions for details such as user interfaces, data storage, client-side platforms, and persistent workflows. The \gls{MTASK} language abstracts away from edge device specific details such as sensor and actuator access, heterogeneity in hardware, and multitasking and scheduling. Tasks in the \gls{MTASK} system are compiled at run time and sent to the device dynamically in order to support create dynamic systems where tasks are tailor-made for the current work requirements. -This tight integration makes programming full \gls{IOT} systems using \gls{TOP} possible without major compromises. Using only three simple functions, devices are connected to \gls{ITASK} servers, \gls{MTASK} tasks are integrated in \gls{ITASK}, and \gls{ITASK} \glspl{SDS} accessed from within \gls{MTASK} tasks. Its design, integration with \gls{ITASK}, implementation, and green computing facilities are shown. - -\todo[inline]{Paar zinnen over het nut} +This tight integration makes programming full \gls{IOT} systems using \gls{TOP} possible without major compromises. \subsection{\nameref{prt:tvt}} Using tierless programming, many issues that arise with tiered programming are mitigated. diff --git a/intro/intro.tex b/intro/intro.tex index 08597fe..39c8bff 100644 --- a/intro/intro.tex +++ b/intro/intro.tex @@ -17,9 +17,7 @@ \end{itemize} \end{chapterabstract} -\todo[inline]{Brackets upright in listings?} -This dissertation is about orchestrating \gls{IOT} systems harmlessly and efficiently. -\todo{beter?} +This dissertation is about orchestrating \gls{IOT} systems safely and efficiently. There are at least 13.4 billion devices connected to the internet at the time of writing \citep{transforma_insights_current_2023}. Each of these devices sense, act, or otherwise, interact with people, computers, and the environment. Despite their immense diversity, they are all computers and they all require software to operate. @@ -121,8 +119,8 @@ However, network technology that is tailored to the needs of the specific interc Examples of this are BLE, LoRa, ZigBee, and LTE-M as a communication protocol for connecting the perception layer to the application layer using \gls{IOT} transport protocols such as \gls{MQTT}. Protocols such as HTTP, AJAX, and WebSocket connecting the presentation layer to the application layer that are designed for the use in web applications. -\todo[inline]{Hier enkele zinnen over maintainability} -Across the layers, the devices are a large heterogeneous collection of different platforms, protocols, paradigms, and programming languages often resulting in impedance problems or semantic friction between layers when programming \citep{ireland_classification_2009}. +Across the layers, the devices are a large heterogeneous collection of different platforms, protocols, paradigms, and programming languages. +As a result, impedance problems or semantic friction occurs between layers and the maintainability is severely hampered \citep{ireland_classification_2009}. Even more so, the perception layer itself is often a heterogeneous collection of microcontrollers in itself, each having their own peculiarities, programming language of choice, and hardware interfaces. As edge hardware needs to be cheap, small scale, and energy efficient, the microcontrollers used to power them do not have a lot of computational power, only a smidge of memory, and little communication bandwidth. Typically, these devices are unable to run a full-fledged general-purpose \gls{OS}. @@ -248,7 +246,6 @@ Some concepts from the \gls{TOSD} model can be mapped upon the \gls{IOT} archite Firstly, edge devices can be seen as simple resources, thus accessed through \glspl{SDS}. The second view is that edge devices contain miniature \gls{TOP} systems in itself. The individual components in the miniature systems, the tasks, the \glspl{SDS}, are, in the eventual execution, connected to the main system. -\todo{hier plaatje uit 6?: nee} \subsection{The iTask system} The concept of \gls{TOP} originated from the \gls{ITASK} framework, a declarative language and \gls{TOP} engine for defining interactive multi-user distributed web applications. @@ -277,6 +274,7 @@ As an example, \cref{lst:todo,fig:todo} show the code and \gls{UI} for an intera The user modifies a shared to-do list through an editor directly or using some predefined actions. Furthermore, in parallel, the length of the list is shown to demonstrate \glspl{SDS}. Using \gls{ITASK}, complex collaborations of users and tasks can be described on a high level. +%In this way, the \gls{ITASK} system is a tierless system taking care of both the presentation and application layer (see \cref{fig:iot}) by running the same code in the browser as on the server and generating all interoperation. From the data type definitions (\cref{lst:todo_dt}), using generic programming (\cref{lst:todo_derive}), the \glspl{UI} for the data types are automatically generated. Then, using the parallel task combinator (\cleaninline{-\|\|}) the task for updating the to-dos (\cref{lst:todo_update}) and the task for viewing the length are combined (\cref{lst:todo_length}, shown as \emph{Length: 2} in the bottom of the image). @@ -285,13 +283,12 @@ Both tasks operate on the to-do \gls{SDS} (\cref{lst:todo_sds}). The task for updating the to-do list is an editor (\cref{lst:todo_editor}) combined using a step combinator (\crefrange{lst:todo_contfro}{lst:todo_contto}). The actions either change the value, sorting or clearing it, or terminate the task by returning the current value of the \gls{SDS}, visualised as three buttons on the bottom right of the \gls{UI}. Special combinators (e.g.\ \cleaninline{@>>} at \cref{lst:todo_ui}) are used to tweak the \gls{UI} to display informative labels. -\todo[inline]{Zou je hier niet zeggen dat dit iTask programma de Presentation en Application layer uit Figure 1.1 maakt door dezelfde code in de browser en op de server te runnen en alle netwerkdingen te genereren? Dat is hier wel niet erg nodig. Maar geeft je wel het opstapje om in 1.4.2.\ te zeggen dat de edge devices die wij willen gebruiken dat niet kunnen. Deze paragraaf kan ook in 1.4.2.} \cleaninputlisting[float=,firstline=6,lastline=22,tabsize=3,numbers=left,caption={The code for a shared to-do list in \gls{ITASK}.},label={lst:todo}]{lst/sharedlist.icl} \begin{figure} \centering - \includegraphics[width=\linewidth]{todo0g} + \includegraphics[width=.8\linewidth]{todo0g} \caption{The \gls{UI} for the shared to-do list in \gls{ITASK}.}% \label{fig:todo} \end{figure} @@ -300,9 +297,7 @@ Special combinators (e.g.\ \cleaninline{@>>} at \cref{lst:todo_ui}) are used to The work for \gls{IOT} edge devices can often be succinctly described by \gls{TOP} programs. Software on microcontrollers is usually composed of smaller basic tasks, are interactive, and share data with other components or the server. The \gls{ITASK} system seems an obvious candidate for bringing \gls{TOP} to \gls{IOT} edge devices. -However, an \gls{ITASK} application contains many features that are not needed on \emph{edge devices} such as higher-order tasks, support for a distributed architecture, or a multi-user web server. -\todo[inline]{Dat is op zich toch niet zo'n probleem. Een iTAsk server heeft ook geen GUI, maar wel alle iTask code om die te maken. -Het feit dat dit niet hoeft op een edge device geeft je wel een van de handvatten om mTask in minder memory te runnen} +However, an \gls{ITASK} application contains many features that are not needed on \emph{edge devices} such as higher-order tasks, support for a distributed architecture, a multi-user web server, and facilities to generate \glspl{GUI} for any user-defined type. Furthermore, \gls{IOT} edge devices are in general not powerful enough to run or interpret \gls{CLEAN}\slash\gls{ABC} code, they just lack the processor speed and memory. To bridge this gap, \gls{MTASK} is developed, a domain-specific \gls{TOP} system for \gls{IOT} edge devices that is integrated in \gls{ITASK} \citep{koopman_task-based_2018}. The \gls{ITASK} language abstracts away from details such as user interfaces, data storage, client-side platforms, and persistent workflows. @@ -327,10 +322,8 @@ Using \cleaninline{enterInformation}, the connection specification of the \gls{T The \gls{MTASK} device is connected using \cleaninline{withDevice} at \cref{lst:intro_withdevice}. Once connected, the \cleaninline{intBlink} task is sent to the device (\cref{lst:intro_liftmtask}) and, in parallel, a web editor is shown that updates the value of the interval \gls{SDS} (\cref{lst:intro_editor,fig:intro_blink_int}). To allow terminating of the task, the \gls{ITASK} task ends with a sequential operation that returns a constant value when the button is pressed, making the task stable. -\todo[inline]{foto device+led?} -\todo[inline]{enterDevice nieuwe regel, globale func?} -\cleaninputlisting[float={!ht},firstline=10,lastline=18,numbers=left,caption={The \gls{ITASK} code for the interactive blinking application.},label={lst:intro_blink}]{lst/blink.icl} +\cleaninputlisting[float={!ht},firstline=10,lastline=19,numbers=left,caption={The \gls{ITASK} code for the interactive blinking application.},label={lst:intro_blink}]{lst/blink.icl} \begin{figure} \centering @@ -357,8 +350,7 @@ The main expression of the program calls the \cleaninline{blink} function with a This function on \crefrange{lst:intro:blink_fro}{lst:intro:blink_to} first reads the interval \gls{SDS}, waits the specified delay, writes the state to the \gls{GPIO} pin, and calls itself recursively using the inverse of the state in order to run continuously. The \cleaninline{>>\|.} operator denotes the sequencing of tasks in \gls{MTASK}. -\cleaninputlisting[float={!ht},linerange={23-,25-33},numbers=left,caption={The \gls{MTASK} code for the interactive blinking application.},label={lst:intro_blink_mtask}]{lst/blink.icl} %chktex 8 -\todo[inline]{Meer wit rondom =jes, doornummeren?} +\cleaninputlisting[float={!ht},linerange={24-,26-34},firstnumber=11,numbers=left,caption={The \gls{MTASK} code for the interactive blinking application.},label={lst:intro_blink_mtask}]{lst/blink.icl} %chktex 8 \subsection{Other TOP languages} While \gls{ITASK} conceived \gls{TOP}, it is no longer the only \gls{TOP} system. @@ -370,10 +362,10 @@ For example, \textmu{}Task \citep{piers_task-oriented_2016}, a \gls{TOP} languag Finally, there are \gls{TOP} languages with strong academic foundations. \Gls{TOPHAT} is a fully formally specified \gls{TOP} language designed to capture the essence of \gls{TOP} \citep{steenvoorden_tophat_2019}. Such a formal specification allows for symbolic execution, hint generation, but also the translation to \gls{ITASK} for actually performing the work \citep{steenvoorden_tophat_2022}. -\Citeauthor{steenvoorden_tophat_2022} distinguishes two instruments for \gls{TOP}: \gls{TOP} languages and \gls{TOP} engines. -The language is the \emph{formal} language for specifying interactive systems. -The engine is the software or hardware that executes these specifications as a ready-for-work application. -\todo[inline]{Noemen dat een vergelijkbare semantics voor mTask under construction is met een verwijzing naar de thesis van Elina?} +%\Citeauthor{steenvoorden_tophat_2022} distinguishes two instruments for \gls{TOP}: \gls{TOP} languages and \gls{TOP} engines. +%The language is the \emph{formal} language for specifying interactive systems. +%The engine is the software or hardware that executes these specifications as a ready-for-work application. +%Defining comparable semantics for the \gls{MTASK} language is in progress \citep{antonova_mtask_2022}. \section{Contributions}% \label{sec:contributions} @@ -382,15 +374,16 @@ This section provides a thorough overview of the relation between the scientific \subsection{\Fullref{prt:dsl}} The \gls{MTASK} system is an \gls{EDSL} and during the development of it, several novel basal techniques for embedding \glspl{DSL} in \gls{FP} languages have been found. This paper-based episode contains the following papers: -\todo{papers met bibitem doen? of conferentie noemen.} \begin{enumerate} \item \emph{Deep Embedding with Class} \citep*{lubbers_deep_2022} is the basis for \cref{chp:classy_deep_embedding}. It shows a novel deep embedding technique for \glspl{DSL} where the resulting language is extendible both in constructs and in interpretation just using type classes and existential data types. The related work section is updated with the research found after publication. \Cref{sec:classy_reprise} was added after publication and contains a (yet) unpublished extension of the embedding technique for reducing the required boilerplate at the cost of requiring some advanced type system extensions. + The paper was published at the \tfp{} 2022 in Krakow, Poland (moved to online). \item \emph{First-\kern-1ptClass Data Types in Shallow Embedded Domain-Specific Languages} \citep*{lubbers_first-class_2022}\label{enum:first-class} is the basis for \cref{chp:first-class_datatypes}. It shows how to inherit data types from the host language in \glspl{EDSL} using metaprogramming by providing a proof-of-concept implementation using \gls{HASKELL}'s metaprogramming system: \glsxtrlong{TH}. The chapter also serves as a gentle introduction to, and contains a thorough literature study on \glsxtrlong{TH}. + The paper was published at the \ifl{} 2022 in Kopenhagen, Denmark. \end{enumerate} %\paragraph{In preparation} @@ -421,13 +414,17 @@ It is compiled from the following publications: \item \emph{A Task-\kern-1.25ptBased \glsxtrshort{DSL} for Microcomputers} \citep*{koopman_task-based_2018} is the initial \gls{TOP}\slash{}\gls{MTASK} paper. It provides an overview of the initial \gls{TOP} \gls{MTASK} language and shows first versions of some interpretations. + The paper was published at the \rwdsl{} 2018 in Vienna, Austria. \item \emph{Task Oriented Programming for the Internet of Things} \citep*{lubbers_task_2018}\footnote{This work is an extension of my Master's thesis \citep{lubbers_task_2017}.} shows how a simple imperative variant of \gls{MTASK} was integrated with \gls{ITASK}. While the language differs a lot from the current version, the integration mechanism is still used. + The paper was published at the \ifl{} 2018 in Lowell, MA, {USA}. % \paragraph{Contribution} % The research in this paper and writing the paper was performed by me, though there were weekly meetings with Pieter Koopman and Rinus Plasmeijer in which we discussed and refined the ideas. \item \emph{Multitasking on Microcontrollers using Task Oriented Programming} \citep*{lubbers_multitasking_2019}\footnote{This work acknowledges the support of the \erasmusplus{} project ``Focusing Education on Composability, Comprehensibility and Correctness of Working Software'', no.\ 2017--1--SK01--KA203--035402.} is a short paper on the multitasking capabilities of \gls{MTASK} comparing it to traditional multitasking methods for \gls{ARDUINO}. + + The paper was published at the \fcows{} 2019 in Opatija, Croatia. % \paragraph{Contribution} % The research in this paper and writing the paper was performed by me, though there were weekly meetings with Pieter Koopman and Rinus Plasmeijer. \item \emph{Simulation of a Task-\kern-1.25ptBased Embedded Domain Specific Language for the Internet of Things} \citep*{koopman_simulation_2023}\footnotemark[\value{footnote}] @@ -441,10 +438,12 @@ It is compiled from the following publications: % I taught the other half of the lecture, wrote the lecture notes, made the assignments and supervised the practical session. \item \emph{Interpreting Task Oriented Programs on Tiny Computers} \citep*{lubbers_interpreting_2019} shows an implementation of the byte code compiler and \gls{RTS} of \gls{MTASK}. + The paper was published at the \ifl{} 2019 in Singapore. % \paragraph{Contribution} % The research in this paper and writing the paper was performed by me, though there were weekly meetings with Pieter Koopman and Rinus Plasmeijer. \item \emph{Reducing the Power Consumption of IoT with Task-Oriented Programming} \citep*{crooijmans_reducing_2022} shows how to create a scheduler so that devices running \gls{MTASK} tasks can go to sleep more automatically and how interrupts are incorporated in the language. + The paper was published at the \tfp{} 2022 in Krakow, Poland (moved to online). % \paragraph{Contribution} % The research was carried out by \citet{crooijmans_reducing_2021} during his Master's thesis. % I did the daily supervision and helped with the research, Pieter Koopman was the formal supervisor and wrote most of the paper. @@ -468,7 +467,9 @@ The papers of which I am first author are solely written by me, there were weekl \item \emph{Could Tierless Programming Reduce IoT Development Grief?} \citep*{lubbers_could_2023} is an extended version of paper~\ref{enum:iot20}. It compares programming traditional tiered architectures to tierless architectures by illustrating a qualitative and a quantitative four-way comparison of a smart-campus application. + The paper was published in the \tiot{} journal. \item \emph{Tiered versus Tierless \glsxtrshort{IOT} Stacks: Comparing Smart Campus Software Architectures} \citep*{lubbers_tiered_2020}\footnote{This work was partly funded by the 2019 Radboud-Glasgow Collaboration Fund.}\label{enum:iot20} compares traditional tiered programming to tierless architectures by comparing two implementations of a smart-campus application. + The paper was published in the \iotconf{} 2020 in Malm\"o, Sweden (moved to online). \end{enumerate} \paragraph{Contribution:} diff --git a/intro/lst/blink.icl b/intro/lst/blink.icl index aedf0b2..10b1142 100644 --- a/intro/lst/blink.icl +++ b/intro/lst/blink.icl @@ -14,8 +14,9 @@ interactiveBlink = enterDevice/*\label{lst:intro_enterDevice}*/ liftmTask (intBlink iInterval) dev/*\label{lst:intro_liftmtask}*/ -|| (Hint "Interval (ms)" @>> updateSharedInformation [] iInterval)/*\label{lst:intro_editor}*/ >>* [OnAction (Action "Stop") (always (return ()))] -where enterDevice :: Task TCPSettings - enterDevice = enterInformation [] <<@ Hint "Enter connection info" + +enterDevice :: Task TCPSettings +enterDevice = enterInformation [] <<@ Hint "Enter connection info" intBlink :: (Shared sds Int) -> Main (MTask v Int) | mtask, lowerSds v & RWShared sds & TC sds () Int Int @@ -24,8 +25,8 @@ intBlink :: (Shared sds Int) -> Main (MTask v Int) | mtask v & ... */ intBlink iInterval = declarePin D2 PMOutput \ledPin-> /*\label{lst:intro:declarePin}*/ - lowerSds \mInterval=iInterval/*\label{lst:intro:liftsds}*/ - In fun \blink=(\st-> /*\label{lst:intro:blink_fro}*/ + lowerSds \mInterval = iInterval/*\label{lst:intro:liftsds}*/ + In fun \blink = (\st-> /*\label{lst:intro:blink_fro}*/ getSds mInterval >>=. \i->delay i >>|. writeD ledPin st diff --git a/preamble/bibliography.tex b/preamble/bibliography.tex index 370dabb..e1f3f7f 100644 --- a/preamble/bibliography.tex +++ b/preamble/bibliography.tex @@ -12,19 +12,12 @@ maxcitenames=2, maxbibnames=99, minnames=1]{biblatex} +% fix sorting for tussenvoegsels \DeclareSortingNamekeyTemplate{ - \keypart{ - \namepart{family} - } - \keypart{ - \namepart{prefix} - } - \keypart{ - \namepart{given} - } - \keypart{ - \namepart{suffix} - } + \keypart{\namepart{family}} + \keypart{\namepart{prefix}} + \keypart{\namepart{given}} + \keypart{\namepart{suffix}} } \addbibresource[glob]{bib/*.bib} diff --git a/preamble/commands.tex b/preamble/commands.tex index cf303ab..0d31e63 100644 --- a/preamble/commands.tex +++ b/preamble/commands.tex @@ -30,3 +30,10 @@ \newcommand{\IOT}{\texorpdfstring{Io\kern-1ptT}{IoT}} \newcommand{\IIC}{I\textsuperscript{2}C} +\newcommand{\conference}[1]{\emph{#1}} +\newcommand{\tfp}{\conference{International Symposium on Trends in Functional Programming (TFP)}} +\newcommand{\ifl}{\conference{Symposium on Implementation and Application of Functional Languages (IFL)}} +\newcommand{\rwdsl}{\conference{International Workshop on Real World Domain Specific Languages (RWDSL)}} +\newcommand{\fcows}{\conference{COnference on COmposability, COmprehensibility and COrrectness of Working Software (4COWS)}} +\newcommand{\tiot}{\conference{ACM Transactions on Internet of Things (T\IOT{})}} +\newcommand{\iotconf}{\conference{International Conference on the Internet of Things (\IOT{})}} diff --git a/preamble/listings.tex b/preamble/listings.tex index dd77b3e..006b342 100644 --- a/preamble/listings.tex +++ b/preamble/listings.tex @@ -20,7 +20,6 @@ backgroundcolor=\color{lstbg}, keepspaces=true, keywordstyle=\bf, - postbreak=\mbox{\textcolor{gray}{$\hookrightarrow$}\space}, showspaces=false, showstringspaces=false, showtabs=false, diff --git a/preamble/lstlangclean.sty b/preamble/lstlangclean.sty index c11f68e..f0a4b4d 100644 --- a/preamble/lstlangclean.sty +++ b/preamble/lstlangclean.sty @@ -16,4 +16,6 @@ {...}{{$\cdots$}}3 {->}{{$\shortrightarrow$}}2 {=>}{{$\Rightarrow$}}2 + {\(}{{{\rm\tt(}}}1 + {\)}{{{\rm\tt)}}}1 } diff --git a/preamble/lstlanghaskell.sty b/preamble/lstlanghaskell.sty index 88d13a3..3ecd117 100644 --- a/preamble/lstlanghaskell.sty +++ b/preamble/lstlanghaskell.sty @@ -19,6 +19,8 @@ {\[bin|}{{$\llbracket_{bin}$}}4 {\[|}{{$\llbracket$}}1 {|\]}{{$\rrbracket$}}1 + {\(}{{{\rm\tt(}}}1 + {\)}{{{\rm\tt)}}}1 } \lstdefinelanguage[Lhs2Tex]{Haskell}[Regular]{Haskell}{% moreliterate=% diff --git a/thesis.tex b/thesis.tex index 579073b..4712e6c 100644 --- a/thesis.tex +++ b/thesis.tex @@ -38,19 +38,20 @@ \hypertarget{titlepage}{} \bookmark[level=section,dest=titlepage]{Titlepage} \subfile{front/titlepage} -\newpage% +\cleardoublepage% % Epigraph/motto \hypertarget{motto}{} \bookmark[level=section,dest=motto]{Motto} \subfile{front/motto} +\cleardoublepage% % Table of contents \setcounter{tocdepth}{1} \hypertarget{contents}{} \bookmark[level=section,dest=contents]{Contents} \tableofcontents -\newpage% +\cleardoublepage% % Dedication \hypertarget{dedication}{} diff --git a/top/imp.tex b/top/imp.tex index f38dc4a..5fc3c22 100644 --- a/top/imp.tex +++ b/top/imp.tex @@ -94,7 +94,7 @@ After compilation, several post-processing steps are applied to make the code su First, in all tail call \cleaninline{BCReturn} instructions are replaced by \cleaninline{BCTailCall} instructions to optimise the tail calls. Furthermore, all byte code is concatenated, resulting in one big program. Many instructions have commonly used arguments, so shorthands are introduced to reduce the program size. -For example, the \cleaninline{BCArg} instruction is often called with argument \numrange{0}{2} and can be replaced by the \numrange[parse-numbers=false]{\cleaninline{BCArg0}}{\cleaninline{BCArg2}} shorthands. +For example, the \cleaninline{BCArg} instruction is often called with argument \numrange{0}{2} and can be replaced by the \cleaninline{BCArg0} to \cleaninline{BCArg2} shorthands. Furthermore, redundant instructions such as pop directly after push are removed as well in order not to burden the code generation with these intricacies. Finally, the labels are resolved to represent actual program addresses instead of the freshly generated identifiers. After the byte code is ready, the lowered \glspl{SDS} are resolved to provide an initial value for them. diff --git a/top/top.tex b/top/top.tex index de58f8e..1881d62 100644 --- a/top/top.tex +++ b/top/top.tex @@ -8,7 +8,7 @@ %}{} \begin{document} \input{subfileprefix} -\part[Orchestrating the Internet of Things using Task-O\-rien\-ted Programming]{\\[2ex]\smaller{}Orchestrating the Internet of Things using Task-O\-rien\-ted Programming}% +\part[Orchestrating the Internet of Things using Task-Orien\-ted Programming]{\\[2ex]\smaller{}Orchestrating the Internet of Things using Task-Orien\-ted Programming}% \label{prt:top} \subfile{4iot} % TOP for the IoT diff --git a/tvt/img/bar_chart.pdf b/tvt/img/bar_chart.pdf index a4a9885..cb2f848 100644 Binary files a/tvt/img/bar_chart.pdf and b/tvt/img/bar_chart.pdf differ diff --git a/tvt/img/gen_stacked_barchart.py b/tvt/img/gen_stacked_barchart.py index ec73abb..3378edc 100644 --- a/tvt/img/gen_stacked_barchart.py +++ b/tvt/img/gen_stacked_barchart.py @@ -16,9 +16,9 @@ plt.rcParams['mathtext.rm'] = 'Libertine' plt.rcParams['mathtext.it'] = 'Libertine:italic' plt.rcParams['mathtext.bf'] = 'Libertine:bold' -CB_color_cycle = ['#377eb8', '#ff7f00', '#4daf4a', - '#f781bf', '#a65628', '#984ea3', - '#999999', '#e41a1c', '#dede00'] +CB_color_cycle = ['#EEEEEE', '#CCCCCC', '#999999', '#666666', + '#EEEEEE', '#CCCCCC', '#999999', '#666666', + '#EEEEEE', '#CCCCCC', '#999999', '#666666'] #data = '''PWS,PRS,CWS,CRS #9,10,7,7 diff --git a/tvt/tvt.tex b/tvt/tvt.tex index 524de9a..2b5ac47 100644 --- a/tvt/tvt.tex +++ b/tvt/tvt.tex @@ -40,7 +40,7 @@ A radical alternative development paradigm uses a single \emph{tierless} languag In a tierless language the developer writes the application as a single program. The code for different tiers is simultaneously checked by the compiler, and compiled to the required component languages. For example, Links compiles to HTML and JavaScript for the web client and to SQL on the server to interact with the database system. Tierless languages for \gls{IOT} stacks are more recent and less common, examples include Potato \citep{troyer_building_2018} and \gls{CLEAN} with \imtask{} \citep{lubbers_interpreting_2019}. -\Gls{IOT} sensor nodes may be microcontrollers with very limited compute resources, or supersensors: resource-rich single board computers like a Raspberry Pi. A tierless language may target either class of sensor node, and microcontrollers are the more demanding target due to the limited resources, e.g.\ small memory, executing on bare metal \etc. +\Gls{IOT} sensor nodes may be microcontrollers with very limited compute resources, or supersensors: resource-rich single board computers like a Raspberry Pi. A tierless language may target either class of sensor node, and microcontrollers are the more demanding target due to the limited resources, e.g.\ small memory, executing on bare metal, \etc. Potentially a tierless language both reduces the development effort and improves correctness as correct interoperation and communication is automatically generated by the compiler. A tierless language may, however, introduce other problems. How expressive is the language? That is, can it readily express the required functionality? How maintainable is the software? Is the generated code efficient in terms of time, space, and power? @@ -795,7 +795,7 @@ The two tierless implementations are also similar in size: \gls{CWS} requiring 1 There are several main reasons for the similarity. One is that the server-side code, i.e.\ for the presentation and application layers, is identical for both resource rich\slash{}constrained implementations. -The identical server code accounts for approximately 40\% of the \gls{PWS} and \gls{PRS} codebases, and approximately 85\% of the \gls{CWS} and \gls{CRS} codebases (\cref{fig_t4t:multipercentage}\todo{make gray\-sca\-le}). +The identical server code accounts for approximately 40\% of the \gls{PWS} and \gls{PRS} codebases, and approximately 85\% of the \gls{CWS} and \gls{CRS} codebases (\cref{fig_t4t:multipercentage}). For the perception and network layers on the sensor nodes, the \gls{PYTHON} and \gls{MICROPYTHON} implementations have the same structure, e.g.\ a class for each type of sensor, and use analogous libraries. Indeed, approaches like CircuitPython \citep{circuitpython} allow the same code to execute on both resource-rich and resource-constrained sensor nodes.