[R-gui] Re: R-SIG-GUI digest, Vol 1 #3 - 9 msgs

[Duncan Temple Lang]

Duncan Murdoch wrote:
> On Thu, 17 Oct 2002 21:32:32 -0400, you wrote:
> 
> >I think it is hard to get it configured on other people's machines.
> >But I don't think it is technically too hard to get it to work as a
> >regular server. What are the problems you have encountered.  (I agree
> >things could be better and have some plans to make it easier and more
> >platform independent, but they do involve significant reorganization
> >of code.)

Thanks for the feedback.

> 
> The biggest problem is that R thinks that it's in charge. There
> shouldn't be an event loop in R, or a console, or any other
> user-interface element.  R should provide the back end services that
> let a front end user interface function, but it should make the least
> possible assumptions about what that interface looks like.

That is quite easy to do.  That's how we write most of the
inter-system interfaces that embed R, e.g. Gnumeric, Netscape, Python,
Perl, Java, and so on.  I have heard some people mention this problem
before, and when I discussed it with them we determined that they were
running the R_mainloop() routine (or its equivalent). That's why R
thought it was in charge.  The proper thing to do is just call R's
initialization routine which sets up the engine for computation, but
stop there and your application assumes control.  Then in any callback
(or whatever is approriate for your application), you can use
R_tryEval() to evaluate any S expression.  When you initialize the R
engine, you can tell it that it is not interactive (although it knows
that itself) and can give it command line arguments.  (This does work
best on Unix as the Windows initialization is not similar and done in
a separate piece of code. But it does work.)


> 
> I'd like to have an R object (and my program might instantiate a dozen
> of them), which would provide services like parsing strings to turn
> them into expressions, evaluating expressions, converting expressions
> into printable strings,  telling me details about what's in the symbol
> table (and details about any object in the symbol table), etc.

No problem. Just arrange for that object to either call the relevant
internal C routine in the R C code, or have it create an expression
(in C) and evaluate that using R_tryEval(). Then extract the information
as appropriate from the resulting SEXP. If the expression becomes
anything more complex than  calling a function with a few arguments,
write a function in S that takes care of doing the computations and call it.


> 
> This object should be set up so that I can give it a long calculation
> and it'll go away and do it, but with a way for me to say I changed my
> mind and want to do something else instead.

Good luck. That's a tricky thing to do, in general, without threads.
So on Windows, you can do it using threads.  But you can send an
signal to the process on Unix. But of course you'll have to do it from
another process or thread since there is no way to get access to the
prompt. We may be able to do things in the near future using readers
and idle tasks. 

 
> It needs to be able to say it wants to output a string, but let me
> decide what to do with it.

If you really want to do that (I don't think it works in general
except when relaying the output, e.g., directly to another display),
just call a myEval() function which sinks the output to a
textConnection() and return the result.  One can also use the
taskCallback mechanism to have the result handled in a particular
way. I am a big fan of event-driven programming and using callbacks
to modularize behaviour that can be dynamically specified.

> 
> It needs to be able to say it wants to draw some graphics, and give me
> a way to say where it should do that.  (This means that I'll need to
> provide all the services needed to be a graphics driver.)

I would think it is best to write a graphics device and when you start
R load the code that implements that into R. I don't think there is a
need for the application to be told by R that it wants to draw
graphics.  An event driven model handles this better.

> 
> I'd like it to be able to report errors, and what its state was like
> when they occurred.

Exceptions will do this. We have discussed putting them in for I
believe 3 1/2 years now and I brought it up again recently.  Hopefully
those that have designed the mechanism will get a chance to put them
in. 


So all these are great to know about. More documentation is needed for
how to run R as an embedded engine. I'll do this as time permits.
Exceptions will be a very useful addition.

Thanks.

 (a different) Duncan

> 
> >Can you point me to GUIs that are developed as clients to a server
> >running in a different process. 
> 
> I don't know about Zed, but I wasn't thinking of it being in a
> different process.  It might be implemented that way, but I want it to
> look as though it's in the same process.  
> 
> Duncan