HAND-IN STATE

Thamsen_2014_Thesis-names.tex

@@ -1,12 +1,5 @@
-%
-% Automatically included file.
-%
-% Should contain: 
-% * hyphenation; 
-% * macros for, eg, product names;
-% * acronyms
-%
 \hyphenation{Small-talk}
+\hyphenation{Java-Script}
 
 \newacronym{cop}{Context-oriented Programming}
 \newacronym{dom}{Document Object Model}
@@ -16,10 +9,3 @@
 \newacronym{api}{application programming interface}
 \newacronym{http}{Hypertext Transfer Protocol}
 \newacronym{uml}{Unified Modeling Language}
-
-% \newacronym{vm}{Virtual Machine}
-% \newacronym{ast}{abstract syntax tree}
-
-%%% Local Variables: 
-%%% mode: latex
-%%% End: 

Thamsen_2014_Thesis.tex

@@ -5,14 +5,17 @@
 %
 \PassOptionsToPackage{final}{graphics}
 
-\documentclass[draft,master]{swathesis}
+\documentclass[final,master]{swathesis}
 
 \def\fromname{by}
 
 \KOMAoptions{parskip=true}
 
 \lstset{language=JavaScript,extendedchars=true}
 
+\usepackage{geometry}
+\special{papersize=210mm,297mm}
+
 \usepackage{pifont}
 \newcounter{dingdistance}
 \setcounter{dingdistance}{191}
@@ -33,9 +36,8 @@
 Bastian Steinert
 }
 
-% ABGABEDATUM
-% \setdate{2012}{04}{05}
-% \date{\datedate}
+\setdate{2014}{05}{13}
+\date{\datedate}
 
 \author{Lauritz Thamsen}
 \location{Potsdam}
@@ -44,13 +46,13 @@
 
 \begin{document}
 \frontmatter
+\newpage
+\newpage
 \maketitle
 \input{content/0_1_abstract}
 \input{content/0_2_acknowledgment}
 \tableofcontents
 \listoffigures
-% \listoftables
-% \lstlistoflistings
 \mainmatter
 
 \input{content/1_introduction}
@@ -63,8 +65,6 @@
 \input{content/8_future_work}
 \input{content/9_summary}
 
-% \listofacronyms
-
 \printbibliography
 
 \clearpage

content/0_1_abstract.tex

@@ -1,7 +1,7 @@
 \begin{abstract}
 
 % Background
-In programming systems such as the Lively Kernel programmers construct applications from objects.
+In programming systems such as the Lively Kernel, programmers construct applications from objects.
 Dedicated tools allow them to manipulate the state and behavior of objects at runtime.
 Programmers are encouraged to make changes directly and receive immediate feedback on their actions.
 
@@ -43,13 +43,9 @@
 Der Ansatz basiert auf \emph{versionsbewusste Referenzen}.
 Diese können zu mehreren Versionen von Objekten aufgelöst werden und erlauben so vorherige Systemzustände wiederherzustellen.
 
-Die Arbeit beschreibt eine auf Proxys basierende Implementierung in JavaScript.
+Die Arbeit beschreibt einen auf Proxys basierenden Entwurf und eine Implementierung in JavaScript.
 Die Evaluierung der Implementierung zeigt, dass Systemzustände des Lively Kernels damit erhalten und wiederhergestellt werden können.
 Der zusätzlich nötige Arbeitsspeicher für die versionsbewussten Referenzen ist dabei vertretbar, während die Programmausführung erheblich verlangsamt wird.
 Mit Verbesserungen könnte die vorgestellte Lösung allerdings benutzt werden, um Entwickler mit praktikablen Wiederherstellungs-Werkzeugen zu unterstützen.
 
 \end{zusammenfassung}
-
-%%% Local Variables:
-%%% mode: latex
-%%% End:

content/0_2_acknowledgment.tex

@@ -14,8 +14,4 @@ \chapter*{Acknowledgments} \label{cha:acknowledgments}
 
 \begin{quotation}
   \noindent I thank Oliver Buck for his comments on drafts of this thesis.
-\end{quotation}
-
-%%% Local Variables:
-%%% mode: latex
-%%% End:
+\end{quotation}

content/2_background.tex

@@ -50,7 +50,7 @@ \section{The Lively Kernel}
 Thus, programmers can create versions of the Lively Kernel with the Lively Kernel.
 
 The Lively Kernel is a browser-based system.
-It is implemented in JavaScript and renders to \ac{HTML}.
+It is implemented in JavaScript and renders to \ac{html}.
 
 \subsubsection{Programming with Prototypes and Classes}
 
@@ -74,32 +74,31 @@ \subsubsection{Direct Manipulation of Morphs}
 When a morph is grabbed, it can be added to another morph and becomes that morph's submorph.
 This way, a morph does not have to be a basic shapes or simple widgets, but can be the interface of any application.
 
-The Lively Kernel provides a set of manipulation tools, called \emph{Halos}, as shown in Figure~\ref{fig:Halos}.
-Developers can bring up these tools for each morph.
-The different buttons of a morph's halo allow, for example, to resize, rotate, and copy morphs.
-
 \begin{figure}[h]
     \centering
     \includegraphics[width=0.3\textwidth]{figures/2_background/1_halos.pdf}
     \caption{The halo buttons of a basic morph.}
     \label{fig:Halos}
 \end{figure}
 
-Other halo buttons open specific tools, which are shown in Figure~\ref{fig:LivelyTools}:
+The Lively Kernel provides a set of manipulation tools, called \emph{Halos}, as shown in Figure~\ref{fig:Halos}.
+Developers can bring up these tools for each morph.
+The different buttons of a morph's halo allow, for example, to resize, rotate, and copy morphs.
 
-\begin{figure}[h]
-    \centering
-    \includegraphics[width=\textwidth]{figures/2_background/2_LivelyTools.pdf}
-    \caption{Three Lively Kernel's tools to manipulate morphs: the Inspector, the Style Editor, and the Object Editor.}
-    \label{fig:LivelyTools}
-\end{figure}
+Other halo buttons open specific tools, which are shown in Figure~\ref{fig:LivelyTools}:
 
 \begin{enumerate}
     \item The \emph{Inspector}~\circnum{1} presents all the values that make up a morph's current state. It also has a small code pane at the bottom that can be used to manipulate the morph's properties programmatically.
     \item The \emph{Style Editor}~\circnum{2} allows to manipulate certain aspects of a morph's visual appearance. Programmers can use it to change, for example, a morph's color, border width, or the layout of its submorphs.
     \item The \emph{Object Editor}~\circnum{3} is a tool to edit the object-specific behavior of morphs. It shows all scripts of a particular morph and allows programmers to add, remove, and edit scripts.
 \end{enumerate}
 
+\begin{figure}[h]
+    \centering
+    \includegraphics[width=\textwidth]{figures/2_background/2_LivelyTools.pdf}
+    \caption{Three Lively Kernel's tools to manipulate morphs: the Inspector, the Style Editor, and the Object Editor.}
+    \label{fig:LivelyTools}
+\end{figure}
 
 \subsubsection{Saving Morphs to the Shared Parts Bin Repository}
 
@@ -131,14 +130,7 @@ \section{CoExist}
 
 \subsubsection{Tools to Recover Previous Development States}
 
-CoExist provides two tools to help programmers benefit from the preserved histories, shown in Figure~\ref{fig:CoExist}:
-
-\begin{figure}[h]
-    \centering
-    \includegraphics[width=\textwidth]{figures/2_background/4_coexistTools.pdf}
-    \caption{CoExist's tools to manage the preserved development states: the \emph{Timeline} and the \emph{Version Browser}.}
-    \label{fig:CoExist}
-\end{figure}
+CoExist provides two tools to help programmers benefit from the preserved histories, shown in Figure~\ref{fig:CoExist}.
 
 \paragraph{Timeline}
 CoExist's \emph{Timeline} tool is located at the bottom of the development environment.
@@ -156,6 +148,12 @@ \subsubsection{Tools to Recover Previous Development States}
 The tools support programmers in re-tracing their steps, understanding the impact of their actions, and in recovering previous development states.
 They can withdraw changes permanently or recover only specific information from previous versions.
 
+\begin{figure}[h]
+    \centering
+    \includegraphics[width=\textwidth]{figures/2_background/4_coexistTools.pdf}
+    \caption{CoExist's tools to manage the preserved development states: the \emph{Timeline} and the \emph{Version Browser}.}
+    \label{fig:CoExist}
+\end{figure}
 
 \subsubsection{Benefits of Continuous Versioning}
 

content/3_motivation.tex

@@ -8,20 +8,20 @@ \section{Part Development By Example}
 
 To exemplify how developers work directly on objects in the Lively Kernel, we will outline how a Lively Kernel user adds a new feature to the Object Editor.
 
-\begin{figure}[h]
-    \centering
-    \includegraphics[width=0.7\textwidth]{figures/3_motivation/1_magnifierButton.png}
-    \caption{The Object Editor with its magnifier button highlighted with a red outline.}
-    \label{fig:MagnifierButton}
-\end{figure}
-
 The editor has been developed by composing and editing graphical objects.
 Thus, the user does not adapt any source code modules to change the editor, but rather manipulates objects directly.
 
 In this example, the user adds a magnifier tool to the Object Editor.
 The magnifier tool helps finding the editor's target, which is the object the editor currently presents scripts for.
 Implementing the new feature requires to create a new button morph and to add it to the editor, as shown in Figure~\ref{fig:MagnifierButton}.
 
+\begin{figure}[h]
+    \centering
+    \includegraphics[width=0.7\textwidth]{figures/3_motivation/1_magnifierButton.png}
+    \caption{The Object Editor's magnifier button highlighted with a red outline.}
+    \label{fig:MagnifierButton}
+\end{figure}
+
 The magnifier button has two features:
 \begin{enumerate}
     \item When a programmer hovers over the button, the Object Editor's current target is highlighted with a rectangular overlay.
@@ -33,7 +33,7 @@ \section{Part Development By Example}
 \begin{figure}[h]
     \centering
     \includegraphics[width=0.8\textwidth]{figures/3_motivation/2_magnifierBehavior.png}
-    \caption{Hovering the Object Editor's magnifier button highlights the current target object.}
+    \caption{The Object Editor's magnifier button as it highlights the editor's target.}
     \label{fig:MagnifierBehavior}
 \end{figure}
 
@@ -48,18 +48,18 @@ \section{Part Development By Example}
 Moving the button around will then move the image accordingly.
 Finally, the users adds the result of these manipulations, visible in \circnum{4}, to the Object Editor.
 
+All these changes are made directly to the state of objects: the button morph, the magnifier image morph, and the editor morph.\\
+When programmers edit parts in this way, they often see the effects of their actions immediately.
+For example, when adding the new button to the Object Editor, the button is visible at all times.
+Programmers do not need to run any code to see and test the button.
+
 \begin{figure}[h]
     \centering
     \includegraphics[width=0.8\textwidth]{figures/3_motivation/3_buildingTheButton.pdf}
     \caption{Directly manipulating a button morph.}
     \label{fig:ButtonBuilding}
 \end{figure}
 
-All these changes are made directly to the state of objects: the button morph, the magnifier image morph, and the editor morph.\\
-When programmers edit parts in this way, they often see the effects of their actions immediately.
-For example, when adding the new button to the Object Editor, the button is visible at all times.
-Programmers do not need to run any code to see and test the button.
-
 \paragraph{Scripting the Button Morph}
 Now the user implements the button's behavior.
 The user adds scripts to the button that lay a translucent rectangle over the current target.
@@ -93,13 +93,6 @@ \section{Recovery Needs When Developing Parts}
     \item \textbf{Inappropriate changes through scripts}: The user could make a mistake in a workspace snippet that is intended to manipulate morph properties programmatically. Such a snippet can change many properties of many objects.
 \end{itemize}
 
-\begin{figure}[h]
-    \centering
-    \includegraphics[width=0.7\textwidth]{figures/3_motivation/4_workspaceDoIt.png}
-    \caption{The button's \lstinline{onMouseMove} script with a text selection.}
-    \label{fig:onMouseOverScript}
-\end{figure}
-
 \paragraph{Explorative Script Evaluation}
 Undesirable changes can also be introduced when a programmer explores the behavior of objects by evaluating scripts.
 The Object Editor allows evaluating code directly for its target object.
@@ -109,22 +102,29 @@ \section{Recovery Needs When Developing Parts}
 Only evaluating the selected lines would, however, neither check the conditions usually checked above nor set the state usually set below the selected lines.
 Therefore, evaluating this selection allows to test the highlighting behavior but leaves the system in a state it normally would not be in.
 
+\begin{figure}[h]
+    \centering
+    \includegraphics[width=0.7\textwidth]{figures/3_motivation/4_workspaceDoIt.png}
+    \caption{The button's \lstinline{onMouseMove} script with a text selection.}
+    \label{fig:onMouseOverScript}
+\end{figure}
+
 The examples show that there are many situations in which the user might want to undo previous actions.
 In programming systems like the Lively Kernel, where programmers work on objects, changes are always made to the state of objects.
 Functions are properties of objects.
 Even classes and modules are objects.
 
-\begin{figure}[h]
-    \centering
-    \includegraphics[width=0.6\textwidth]{figures/3_motivation/5_stateChanges.pdf}
-    \caption{Adding a submorph changes the state of a morph.}
-    \label{fig:changedCharacter}
-\end{figure}
-
 For example, evaluating the text selection in Figure~\ref{fig:onMouseOverScript} changes the \lstinline{world} object's state.
 The \lstinline{world} object has now one more submorph, as shown in Figure~\ref{fig:changedCharacter}.
 Thus, the \lstinline{world}'s collection of submorphs is changed.
 
 To undo the side-effect of the script and re-establish the previous situation, the change to the \lstinline{world} object needs to be undone.
 The \lstinline{submorphs} property of \lstinline{world} has to be as it previously was.\\
 When the state of all objects is preserved and can be re-established, previous system states can be recovered when necessary.
+
+\begin{figure}[h]
+    \centering
+    \includegraphics[width=0.6\textwidth]{figures/3_motivation/5_stateChanges.pdf}
+    \caption{Adding a submorph changes the state of a morph.}
+    \label{fig:changedCharacter}
+\end{figure}