Index: doc/theses/colby_parsons_MMAth/data/nasusSendDynamic
===================================================================
--- doc/theses/colby_parsons_MMAth/data/nasusSendDynamic	(revision 04c31f4c9533583c26f64923016af702d88ebf40)
+++ doc/theses/colby_parsons_MMAth/data/nasusSendDynamic	(revision 0aa77e6ab48fb3e593de734c3b00e37bf7ece4d1)
@@ -1,1 +1,1 @@
-46ns & 9501ns & 7483ns & 72ns & 5547ns
+46ns & 74ns & 9519ns & 8409ns & 5513ns
Index: doc/theses/colby_parsons_MMAth/data/nasusSendStatic
===================================================================
--- doc/theses/colby_parsons_MMAth/data/nasusSendStatic	(revision 04c31f4c9533583c26f64923016af702d88ebf40)
+++ doc/theses/colby_parsons_MMAth/data/nasusSendStatic	(revision 0aa77e6ab48fb3e593de734c3b00e37bf7ece4d1)
@@ -1,1 +1,1 @@
-23ns & 2779ns & 59ns & 40ns & 68ns
+23ns & 42ns & 2780ns & 67ns & 68ns
Index: doc/theses/colby_parsons_MMAth/data/pykeSendDynamic
===================================================================
--- doc/theses/colby_parsons_MMAth/data/pykeSendDynamic	(revision 04c31f4c9533583c26f64923016af702d88ebf40)
+++ doc/theses/colby_parsons_MMAth/data/pykeSendDynamic	(revision 0aa77e6ab48fb3e593de734c3b00e37bf7ece4d1)
@@ -1,1 +1,1 @@
-58ns & 8476ns & 5972ns & 81ns & 4179ns
+59ns & 79ns & 8491ns & 5451ns & 4167ns
Index: doc/theses/colby_parsons_MMAth/data/pykeSendStatic
===================================================================
--- doc/theses/colby_parsons_MMAth/data/pykeSendStatic	(revision 04c31f4c9533583c26f64923016af702d88ebf40)
+++ doc/theses/colby_parsons_MMAth/data/pykeSendStatic	(revision 0aa77e6ab48fb3e593de734c3b00e37bf7ece4d1)
@@ -1,1 +1,1 @@
-24ns & 1712ns & 74ns & 40ns & 90ns
+25ns & 40ns & 1699ns & 67ns  & 90ns
Index: doc/theses/colby_parsons_MMAth/text/actors.tex
===================================================================
--- doc/theses/colby_parsons_MMAth/text/actors.tex	(revision 04c31f4c9533583c26f64923016af702d88ebf40)
+++ doc/theses/colby_parsons_MMAth/text/actors.tex	(revision 0aa77e6ab48fb3e593de734c3b00e37bf7ece4d1)
@@ -253,6 +253,4 @@
 Managing the envelop is straightforward because it is created at the send and deleted after the receive, \ie there is 1:1 relationship for an envelop and a many to one relationship for a message.
 
-\PAB{Do you need to say more here?}
-
 % In actor systems, messages are sent and received by actors.
 % When a actor receives a message it executes its behaviour that is associated with that message type.
@@ -1003,5 +1001,5 @@
 This heuristic does not boast better performance than randomized victim selection, but it is comparable.
 However, it constitutes an interesting contribution as it shows that adding some complexity to the heuristic of the stealing fast path does not impact mainline performance, paving the way for more involved victim selection heuristics.
-% \PAB{Both of these theorems are commented out.}
+
 % Furthermore, in the case they attempt to steal the same queue, at least one of them is guaranteed to successfully steal the queue as shown in Theorem~\ref{t:one_vic}.
 % Additionally, the longest victim heuristic makes it very improbable that the no swap scenario presented in Theorem~\ref{t:vic_cycle} manifests.
@@ -1080,7 +1078,5 @@
 The messages that \CFA provides are @DeleteMsg@, @DestroyMsg@, and @FinishedMsg@.
 These messages are supported on all actor types via inheritance.
-When sent to an actor, the actor takes the corresponding allocation action after receiving the message, regardless of what the actor returns to the executor.
-\PAB{What does this mean? Note that any pending messages to the actor will still be sent.
-It is still the user's responsibility to ensure that an actor does not receive any messages after termination.}
+These were shown earlier in Figure~\ref{f:ConvenienceMessages}, and can be overloaded by users to have specific behaviour for derived actor types.
 
 \section{Performance}\label{s:actor_perf}
@@ -1131,11 +1127,10 @@
 \caption{Static Actor/Message Performance: message send, program memory (lower is better)}
 \label{t:StaticActorMessagePerformance}
-\PAB{Put uC++ beside \CFA.}
 \begin{tabular}{*{5}{r|}r}
-	& \multicolumn{1}{c|}{\CFA (100M)} & \multicolumn{1}{c|}{CAF (10M)} & \multicolumn{1}{c|}{Akka (100M)} & \multicolumn{1}{c|}{\uC (100M)} & \multicolumn{1}{c@{}}{ProtoActor (100M)} \\
+	& \multicolumn{1}{c|}{\CFA (100M)} & \multicolumn{1}{c|}{\uC (100M)} & \multicolumn{1}{c|}{CAF (10M)} & \multicolumn{1}{c|}{Akka (100M)} & \multicolumn{1}{c@{}}{ProtoActor (100M)} \\
 	\hline
-	AMD		& \input{data/pykeSendStatic} \\
+	AMD		& \input{data/nasusSendStatic} \\
 	\hline
-	Intel	& \input{data/nasusSendStatic}
+	Intel	& \input{data/pykeSendStatic}
 \end{tabular}
 
@@ -1144,12 +1139,11 @@
 \caption{Dynamic Actor/Message Performance: message send, program memory (lower is better)}
 \label{t:DynamicActorMessagePerformance}
-\PAB{The uC++ AMD looks high. It is 65ns in the Actor paper.}
 
 \begin{tabular}{*{5}{r|}r}
-	& \multicolumn{1}{c|}{\CFA (20M)} & \multicolumn{1}{c|}{CAF (2M)} & \multicolumn{1}{c|}{Akka (2M)} & \multicolumn{1}{c|}{\uC (20M)} & \multicolumn{1}{c@{}}{ProtoActor (2M)} \\
+	& \multicolumn{1}{c|}{\CFA (20M)} & \multicolumn{1}{c|}{\uC (20M)} & \multicolumn{1}{c|}{CAF (2M)} & \multicolumn{1}{c|}{Akka (2M)} & \multicolumn{1}{c@{}}{ProtoActor (2M)} \\
 	\hline
-	AMD		& \input{data/pykeSendDynamic} \\
+	AMD		& \input{data/nasusSendDynamic} \\
 	\hline
-	Intel	& \input{data/nasusSendDynamic}
+	Intel	& \input{data/pykeSendDynamic}
 \end{tabular}
 \end{table}
