--- a/doc_recap_some_important_thoughts_about_the_current_compiler.patch	Sat Feb 08 18:28:44 2014 -0800
+++ b/doc_recap_some_important_thoughts_about_the_current_compiler.patch	Sun Feb 09 15:48:57 2014 -0800
@@ -1,5 +1,5 @@
 # HG changeset patch
-# Parent 01873f017f54a0c625261b8a1f27052219a00141
+# Parent 3bae25c81f3e5b3be3a6609c932997d9a8fc3b59
 Recap important notes about the current compiler in a small document
 
 This should be used as a work document for the next compiler version.
@@ -17,10 +17,10 @@
 new file mode 100644
 --- /dev/null
 +++ b/doc/rathaxes/technical/rtx_2k12_wrap_up.tex
-@@ -0,0 +1,113 @@
+@@ -0,0 +1,121 @@
 +\documentclass[american]{rtxarticle}
 +
-+\title{Rathaxes 2012 wrap-up} 
++\title{\rtx\ 2012 wrap-up}
 +
 +\author{Louis Opter}
 +
@@ -29,13 +29,15 @@
 +\maketitle 
 +
 +\begin{abstract}
-+The second version of the Rathaxes compiler, \emph{Rathaxes 2012}, started in
-+2010 has been sunset in 2013. This document aims to highlight the issues and
-+the lessons learned while trying to recode an e1000 driver with this compiler
++The second iteration of the \rtx\ compiler, \emph{\rtx\ 2012}, started in 2010
++has been sunset in 2013. This document aims to highlight the issues and the
++lessons learned while trying to recode an e1000 driver with this compiler
 +version.
 +
-+This document should serve as a reference for the next version of the Rathaxes
-+compiler implemented in Python 3 with Pyrser.
++This document should serve as a reference for the next version of the \rtx\
++compiler implemented in Python 3 with Pyrser. Design shortcomings led to the
++biggest issues and are covered first, some implementation issues are covered in
++a second part.
 +\end{abstract}
 +
 +\section{Design issues}
@@ -49,7 +51,7 @@
 +\item Register declarations.
 +\end{itemize}
 +
-+Turned out to unecessary because:
++Turned out to unnecessary because:
 +
 +\begin{itemize}
 +\item We decided to scope the first driver to a single kernel (Linux 2.6.32 and
@@ -59,9 +61,12 @@
 +\item Challenges appeared at other places.
 +\end{itemize}
 +
++The \texttt{with} statement stays a core feature of the language, it just
++turned out to an advanced feature that we didn't need at first.
++
 +It's also interesting to note that sequences weren't used to define algorithms
 +as planned but were re-fitted as ``functions'' as we started to write object
-+oriented code around Rathaxes types. Some sequences are also used to logically
++oriented code around \rtx\ types. Some sequences are also used to logically
 +regroup chunks and pointcut but those chunks could be moved to types or could
 +directly be top-level declarations within their interface.
 +
@@ -71,31 +76,34 @@
 +
 +\begin{itemize}
 +\item ``Object model'';
-+\item Ref/Scalar;
++\item ref/scalar (let you express whether a variable or attribute is a pointer
++      or not);
 +\item Error handling;
 +\item Variadic sequences;
-+\item Arrays support;
-+\item Comments passthrough;
++\item Arrays support (maybe we could have ref, scalar and array?);
++\item Comments pass-through;
 +\item Type coercion to \texttt{Builtin::symbol}.
 +\end{itemize}
 +
-+Are really needed.
++Are really needed; the ref/scalar distinction has been implemented in 2013 and
++works ok.
 +
 +\subsubsection{``Object model''}
 +
-+The driver code started to organically organize itself into types with methods
-+and attributes that loosely correspond to classes. We ran different into
-+issues:
++The driver code started to organically organize itself into types, with methods
++(chunks attached to a type which take an explicit \texttt{self} argument of
++that type) and attributes, that loosely correspond to classes. We ran different
++into issues:
 +
 +\begin{itemize}
 +\item Methods call aren't working;
 +\item Type dependencies aren't resolved correctly, so they aren't generated in
 +      the right order;
 +\item \texttt{\$\{self\}} is ambiguous, how do you know when it's a scalar or a
-+      method? (this is important to define the init method);
++      method? (this is important to define the \texttt{init} method);
 +\item Abstract data types should probably be framed/defined in the language;
 +\item Mappings aren't resolved recursively;
-+\item Mappings can't use Rathaxes code in them (e.g: you can't use
++\item Mappings can't use \rtx\ code in them (e.g: you can't use
 +      \texttt{\$\{Rathaxes::Type.ref\}} in a mapping definition);
 +\item Circular dependencies aren't supported (in e1000 the rings and the
 +      hardware context are inter-dependant, you can't avoid that);
@@ -107,24 +115,24 @@
 +
 +\subsubsection{Error handling}
 +
-+This has been deliberately left out in Rathaxes 2012 but it seems that the
++This has been deliberately left out in \rtx\ 2012 but it seems that the
 +biggest difficulty is going to define and then inject the error handling code
 +into the parent chunk/context appropriately.
 +
 +\section{Implementation issues}
 +
-+Some bugs are imparing development:
++Bugs are impairing development:
 +
 +\begin{itemize}
 +\item Expansion bugs:
 +\begin{itemize}
-+\item Obscure expansion issues solved by scoping thigns;
++\item Obscure expansion issues solved by scoping things;
 +\item Variable declarations leaking across different chunks;
 +\item Chunk/Pointcut parameters not bound to the C variables (the parameters
 +      must be named like the C variables are).
 +\end{itemize}
 +\item CNorm issues: it's impossible to use annotation (e.g: \texttt{\_\_init},
-+      \texttt{\_\_exit}, \texttt{\_\_iomem}, \ldots) or arbitrary typedef'd
++      \texttt{\_\_exit}, \texttt{\_\_iomem}\ldots) or arbitrary typedef'd
 +      types;
 +\item Some sequences call aren't working for obscure reasons (e.g:
 +      \texttt{DMA::unmap}).