-
Notifications
You must be signed in to change notification settings - Fork 2
/
TODO-DTL.html
217 lines (186 loc) · 7.44 KB
/
TODO-DTL.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html> <head>
<title>Todo List for R for Duncan Temple Lang</title>
<link rel="stylesheet" href="Rtech.css">
</head>
<body>
<h1>Todo List for R for Duncan Temple Lang</h1>
The following is an unordered list of items that I intend to work on
that relate to R. (There are others, but I am not admitting to the
them.) The time frame for these is completely uncertain. I am very
keen to hear peoples' suggestion of which should be done first, etc.
<hr width="75%">
<dl>
<dt>
<li> Structuring the Event Loop.
<dd> We want to be able to host other systems
such as Tcl/Tk, Gtk applications, etc.
and allow them to integrate their event sources into
our event loop.
Similarly, we need to be able to do the reverse when
R is embedded in other applications.
<p>
The immediate things to do are
<ul>
<li> Replace the current <code>PolledEvents</code> setup
with a linked-list approach managed centrally
in the same way that <code>addInputHander</code> works.
<li> Provide routines in the Tcl/Tk library to implement
the Tcl Notifier mechanism so that Tcl event sources
are handled by the R event loop.
Also, we can do a similar thing for Gtk facilities.
<li> Provide implementations of R's <code>addInputHandler()</code>,
<code>addPolledEventHandler()</code>, etc. that pass the information
to Tcl/Tk, Gtk, etc. when R is embedded in those applications.
<li> Add new event sources
<ul>
<li> <code>setReader()</code> for connections,
<li> timer events,
<li> signals,
<li> potentially, assignments, idle tasks,
etc.
</ul>
</ul>
<dt>
<li> Extending the "database" concept to provide
support for S4-style user defined elements
of the search path.
<dd>
This is needed generally by many of the
inter-system interface packages.
These include the Perl, Java, Python, JavaScript
interfaces, and also packages such as
CORBA, RPgSQL, RMySQL, etc. which can richly
exploit the concept of a proxy object
or a foreign reference. Much of this has been
done in the Omegahat language and the
setup there can be implemented here.
<dt>
<li> C-level API for embedding R.
<dd> Including exceptions which Robert is implementing
for R.
<dt>
<li> Integrating Tom Vogel's mechanism for
<a
href="http://www.ece.cmu.edu/~tov/public/R/X11andTk.html">using a Tk
widget as an X11 device canvas</a>.
<dd> This should be relatively easy given the changes motivated
by the SNetscape package for using an arbitrary X <code>Window</code>
structure.
<dt>
<li> Packages
<dd> I continuing to develop several packages.
<dl>
<dt>
<a href="http://www.omegahat.org/RGnumeric">RGnumeric</a>
<dd> A plugin for Gnumeric that allows R functions
to be called from Gnumeric and for these functions
to access Gnumeric workbooks, sheets and cells.
<dt> <a href="http://www.omegahat.org/SNetscape">SNetscape</a>
<dd>
Fixing the event queue problem associated with
the embedded graphics devices is urgent here.
Also, using S foreign references needs to be added.
<dt> SXalan (and using libxslt).
<dd>
<dt> <a href="http://www.omegahat.org/RSPostgres">REmbeddedPostgres</a>
<dd> using R functions within SQL queries
that are executed in the server via an embedded R.
<dt> RSHelp
<dd>documentation mechanism using XML
<dt> SXMLObjects
<dd> Serializing S (R and S-Plus) objects
in XML format so that they can be read and written
by other systems (e.g. each other, Matlab, SAS, etc.)
<dt> <a href="http://www.ggobi.org/RSggobi.html">Rggobi</a>
<dd> An interface for embedding ggobi in R.
</dl>
Work on others such as
<a href="http://www.omegahat.org/RSPerl">RSPerl</a>,
<a href="http://www.omegahat.org/Java">SJava</a>,
<a href="http://www.omegahat.org/RSPython">Python</a>,
<a href="http://www.omegahat.org/XML">XML</a>
<dt>
<li> R as a shared library & shared libraries.
<dd> It is useful for both technical and non-technical
reasons to always use the R engine as a shared library.
<ul>
<li> This simplifies providing different front ends
such as GUIs, command lines, embedding,
and makes these uniform;
<li> simplifies some dynamic loading issues;
<li> licensing uncertainties may become clearer.
</ul>
We can pursue this further, making more than
just the Rmath library
available as separately usable components of the
R engine. For example, we might be able to
allow certain parts of the graphics engine and devices
be used in other applications, separately from the rest of R.
<dt>
<li> Integrating an XSLT translator into R
<dd> As opposed to the SXalan package which embeds R in
an XSL translator, this would allow us to "out-source"
sub-computations for XML operations, such as when
processing help files that contain style rather than
top-level structural information.
<dt>
<li> Interactive graphics.
<dd> It may be interesting to allow users events on graphics devices
to be programmable at the user-level.
And then take this to a level of abstraction that makes
it platform neutral.
<dt>
<li> An interface generator like <a href="http://www.swig.org">SWIG</a>
<dd> Using Lcc, we can parse C code and extract
the structure and routine definitions.
Using this information, we can
automatically generate S and C code
that interfaces to these and provide quick and easy access to
"arbitrary" C code.
<dt>
<li> Internal and User-level threads in the S language.
<dd> Luke and I are working on getting concurrency
and potentially parallelism in R
so that one can (at least appear to) be
executing different commands simultaneously.
Ideally we will be able to exploit multiple
processors in a machine and run certain
computations in parallel.
<p>
To do this, we need to
<ul>
<li> provide support multiple interpreters
and this involves removing all the global variables.
This is underway.
<li> Luke is investigating the extent to which
the <code>eval()</code> can be made non-recursive.
This has the potential to make it possible for us
to schedule different interpreters ourselves
without the need for operating system threads.
</ul>
<p>
Hopefully we will also be able to
provide an interface which supports
both process-level threads and distributed
computing across machines.
<dt>
<li> Safe Interpreter
<dd> When R is embedded in applications such as
a Database server, Netscape, security issues
arise as one can evaluate arbitrary S code
including system calls,
and also load and invoke arbitrary C code.
We need to provide a minimal interpreter
that prohibits execution of these and potentially
other functions.
This needs to be configurable for different
installation sites, user groups, etc.
</dl>
<hr>
<address><a href="http://cm.bell-labs.com/stat/duncan">Duncan Temple Lang</a>
<a href=mailto:[email protected]><[email protected]></a></address>
<!-- hhmts start -->
Last modified: Sat Apr 28 09:49:28 EDT 2001
<!-- hhmts end -->
</body> </html>