[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. This has a notable impact on performance when loading packages.
+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.
+}. This has a notable impact on performance when loading packages.
 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
 of the \proglang{R} application programming interface (API) (see also Figure~\ref{fig:design_sketch}). 
-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.




More information about the rkward-tracker mailing list