# [rkward-cvs] SF.net SVN: rkward:[3595] branches/jss_dec_10/FINAL_JSS_TEX/FINAL_splitted

tfry at users.sourceforge.net tfry at users.sourceforge.net
Mon May 23 14:09:46 UTC 2011

Revision: 3595
http://rkward.svn.sourceforge.net/rkward/?rev=3595&view=rev
Author:   tfry
Date:     2011-05-23 14:09:45 +0000 (Mon, 23 May 2011)

Log Message:
-----------
Update technical supplement for changes in 0.5.5/0.5.6

Modified Paths:
--------------
branches/jss_dec_10/FINAL_JSS_TEX/FINAL_splitted/TODO
branches/jss_dec_10/FINAL_JSS_TEX/FINAL_splitted/figures/design_sketch.odg
branches/jss_dec_10/FINAL_JSS_TEX/FINAL_splitted/figures/design_sketch.pdf
branches/jss_dec_10/FINAL_JSS_TEX/FINAL_splitted/technical.tex

Modified: branches/jss_dec_10/FINAL_JSS_TEX/FINAL_splitted/TODO
===================================================================
--- branches/jss_dec_10/FINAL_JSS_TEX/FINAL_splitted/TODO	2011-05-23 08:55:12 UTC (rev 3594)
+++ branches/jss_dec_10/FINAL_JSS_TEX/FINAL_splitted/TODO	2011-05-23 14:09:45 UTC (rev 3595)
@@ -1,6 +1,6 @@
TODO list for the revision (Incomplete!)

-Updated screenshots:
+- Update screenshots:
Figure number   |   Importance   |   Comments
2                   high             no more Pending Jobs tool view, toolbar changed, status bar changed, could show an S4 object in workspace browser
3                   very low         could hide ".GlobalEnv", here
@@ -9,6 +9,7 @@
10                  high             no longer shows ".GlobalEnv" (addresses reviewer comment)
11                  high             see Figure 8. At least this one is very easy to re-create

+- Re-do figure placement, after everything else is done!

#----------------------------------------------------------

@@ -31,4 +32,4 @@
TODO

* MDI, TDI, SDI mixture needs some details (Stefan)
-* Section 3.7 Results output ~/.rkward needs update
\ No newline at end of file
+* Section 3.7 Results output ~/.rkward needs update

Modified: branches/jss_dec_10/FINAL_JSS_TEX/FINAL_splitted/figures/design_sketch.odg
===================================================================
(Binary files differ)

Modified: branches/jss_dec_10/FINAL_JSS_TEX/FINAL_splitted/figures/design_sketch.pdf
===================================================================
(Binary files differ)

Modified: branches/jss_dec_10/FINAL_JSS_TEX/FINAL_splitted/technical.tex
===================================================================
--- branches/jss_dec_10/FINAL_JSS_TEX/FINAL_splitted/technical.tex	2011-05-23 08:55:12 UTC (rev 3594)
+++ branches/jss_dec_10/FINAL_JSS_TEX/FINAL_splitted/technical.tex	2011-05-23 14:09:45 UTC (rev 3595)
@@ -15,14 +15,18 @@
complex model to complete, the user should be able to continue to use the GUI to
prepare the next analysis. Asynchronous command execution is also a prerequisite
for an implementation of the plot-preview feature (see the section no graphics windows
-in the main article). Commands
-generated from plugins or user actions are placed in queue and are evaluated in
-a separate thread in the order they were submitted\footnote{
+in the main article). Internally, the GUI frontend and the \proglang{R} engine run in two separate processes\footnote{
+    Up to \pkg{RKWard} version 0.5.4, two separate threads inside a single process were used. This alternate design is still
+    available as a compile time option.
+}. Commands generated from plugins or user actions are placed in queue in the frontend and are evaluated in
+the backend process in the order they were submitted\footnote{
It is possible, and in some cases necessary, to enforce a different order of command execution in
internal code. For instance, \pkg{RKWard} makes sure that no user command can
potentially interfere while \pkg{RKWard} is loading the data of a \code{data.frame} for
editing.
-}. The asynchronous design implies that \pkg{RKWard} avoids relying on the
+}.
+
+The asynchronous design implies that \pkg{RKWard} avoids relying on the
\proglang{R} engine during interactive use. This is one of several reasons for
the use of \proglang{ECMAScript} in plugins, instead of scripting using
\proglang{R} itself (see Sections~\ref{sec:technical_toolkit} and \ref{sec:technical_plugins}).
@@ -34,9 +38,14 @@
other places. The object representation includes objects in all environments
in the search path, and any objects contained within these environments in a
hierarchical tree\footnote{
-    Currently, environments of functions or formulas are not taken into account.
+    Currently, environments of functions or formulas are not taken into account, but slots of S4 objects,
+    and package namespace environments are represented in the object tree.
}. The representation of \proglang{R} objects is gathered
+pro-actively\footnote{
+    To limit the amount of processing, and to avoid recursion, \pkg{RKWard} currently stops
+    gathering object information at a depth of three levels. Information on deeper levels is gathered
+    on an as-needed basis, when the user accesses information on the respective parent objects.
Specifically, objects which would usually be lazy loaded'' only when needed \citep[see][]{Ripley2004} are
accessed in order to fetch information on their properties. This means the data
has to be loaded from disk; however, the memory is freed immediately after fetching
@@ -46,17 +55,15 @@
A further side-effect of the asynchronous threaded design is that there is
inherently a rather clear separation between the GUI code and the code making direct use
-In the current development version, the evaluation
-of \proglang{R} commands has even been moved into a separate process. Therefore in future releases it could
-be made possible to run GUI and \proglang{R} engine on different computers.
+In future releases it could be made possible to run GUI and \proglang{R} engine on different computers.

\begin{figure}[t!]
\centering
\includegraphics[clip=true,trim=0cm 2cm 0cm 0cm]{./figures/design_sketch.pdf}
\caption{Technical design of \pkg{RKWard}. Only a few central components are visualized.
- All communication with the \proglang{R} engine is passed through a single interface living in the main application thread. The \proglang{R} engine itself
- runs in a separate thread (or in a separate process).
- Separate threads are also used to generate \proglang{R} code from plugins.
+ All communication with the \proglang{R} engine is passed through a single interface living in the frontend process. The \proglang{R} engine itself
+ runs in a separate process.
+ Separate threads within the frontend process are used to generate \proglang{R} code from plugins.
}
\label{fig:design_sketch}
\end{figure}
@@ -127,8 +134,8 @@
still known to have portability issues especially on Mac OS X, and to some degree
also on the Microsoft Windows platform \citep{Jarvis2010}.

-The major reason for choosing the \pkg{KDE} and \pkg{Qt} libraries was their
-many high level features which have allowed \pkg{RKWard} development to make quick
+The major reason for choosing the \pkg{KDE} and \pkg{Qt} libraries has been the
+many high level features, they provide. This has allowed \pkg{RKWard} development to make quick
progress despite limited resources. Most importantly, the \pkg{KDE} libraries provide a
full featured text editor \citep{CullmannND} as a component which can be
seamlessly integrated into a host application using the KParts technology
@@ -152,8 +159,8 @@
well, this would make it impossible to use plugins in an asynchronous way.
Further, the main functional requirement in this place is the manipulation and
concatenation of text strings. While \proglang{R} provides support for this, concatenating
-strings with the \code{+}-operator, as available in \proglang{ECMAScript}, allows for a much
-more readable way to perform such basic text manipulation.
+strings with the \code{+}-operator, as available in \proglang{ECMAScript}, allows for a
+very readable way to perform such basic text manipulation.

\section{On-screen graphics windows}
\label{sec:technical_graphics}
@@ -161,7 +168,7 @@
not technically provide a custom on-screen graphics device. \pkg{RKWard} detects when
new graphics windows are created via calls to \code{X11()} or \code{windows()}. These windows
are then captured'' in a platform dependent way (based on the XEmbed \citep{Ettrich2002} protocol
-for \pkg{X11}, or reparenting for the Microsoft Windows platform). An \pkg{RKWard} menu bar and a
+for \pkg{X11}, or on reparenting for the Microsoft Windows platform). An \pkg{RKWard} menu bar and a
toolbar is then added to these windows to provide added functionality. While
this approach requires some platform dependent code, any corrections or
improvements made to the underlying \proglang{R} native devices will automatically be
@@ -182,7 +189,7 @@
one.

Plot history support for the
-\pkg{lattice} system \citep[see also][]{Sarkar2008} is implemented by inserting a hook in the \code{print.lattice()}
+\pkg{lattice} system \citep{Sarkar2008} is implemented by inserting a hook in the \code{print.lattice()}
function. This hook retrieves and stores the \code{lattice.status} object from the
\code{lattice:::.LatticeEnv} environment, thereby making \code{update()} calls on trellis
objects transparent to the user. Any recorded trellis object is then replayed

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.