From Simon.Urbanek at math.uni-augsburg.de  Fri Aug 29 11:09:52 2003
From: Simon.Urbanek at math.uni-augsburg.de (Simon Urbanek)
Date: Fri Aug 29 10:09:21 2003
Subject: [Rd] about REPL and loops in general ...
Message-ID: <2ACD19C7-D9F8-11D7-84CE-000A957CEFBA@math.uni-augsburg.de>

I need to implement some external callbacks to R and I'm not happy with 
the current REPL, since it prevents any general solution.

Are there plans to improve the current REPL anytime soon? The current 
approach has some deficiencies you are surely aware of (only one input 
(=external event loop), the loop is blocked while waiting for input in 
R_ReadConsole, ...). But the major problem is that several 
packages/modules simply replace the standard REPL with their own 
implementations by not returning control to the loop. This virtually 
prevents any cooperation - it is impossible to load two such modules at 
a time without breaking something.

I think that something along the lines of a "light" REventLoop (i.e. 
just the loop management where modules can register their handlers, w/o 
the "demo" loops) would be very helpful. What makes me wonder is that 
even quite recent code again just replaces the REPL (simply never 
returns back while duplicating the functionality) or uses other tricks. 
So, are there plans to replace the current REPL soon? (preferably in 
1.8 ;)). If not, what are the reasons?

Another related question is why shouldn't we use threads for external 
event loops? Most current GUIs are multi-threaded anyway. This wouldn't 
affect R directly. I have something like this in mind:
- external hander registers and gets an ID
R main loop:
{
- wait for mutex A to be signaled (with an ID)
- call signaler's handler function and perform REP if required
- release the mutex A
}

each external loop runs in a separate thread thus not affecting R (R 
can be computing anything in the meantime). once it needs to do 
something in R (e.g. user typed a line), it locks the mutex and signals 
a condition on the mutex which results in action taken in the main R 
REPL.

the above approach makes sure that R (and anything jumping into R) 
still remains single-threaded, but allows arbitrary event loops  to run 
as multiple threads in parallel. afaik all current OSes have threads 
support (we could provide single-threaded REPL as fallback for those 
who don't) and the above is fairly easy to implement in pthreads (and 
compatible) as well as Windows.

I'm willing to provide code for the latter approach or to help with the 
first one if necessary.

Cheers,
Simon

---
Simon Urbanek
Department of computer oriented statistics and data analysis
University of Augsburg
Universit?tsstr. 14
86135 Augsburg
Germany

Tel: +49-821-598-2236
Fax: +49-821-598-2200

Simon.Urbanek@Math.Uni-Augsburg.de
http://simon.urbanek.info


[Rd] about REPL and loops in general ...
Simon Urbanek