[R-SIG-Mac] Interacting with R GUI app from another Cocoa app

[Neil Tiffin]

On Nov 29, 2009, at 3:40 PM, Guillaume Chapron wrote:

>> You might try to write the results into a file and read it back in  
>> R.  This is probably safer anyway.
>
> This was my initial approach, but I expect a lot of overheads  
> reading an array that can be as large as 100,000,000*10,000*100.

Coding it should take at most, an hour, I would try it, you might be  
surprised.  Usually, I always code a working version then optimize  
it.  More than once, I have been surprised when the problem areas  
turned out to be completely different than I originally thought and I  
avoided a lot of additional complexity trying to solve a problem that  
did not exist.  If the simulation runs a few hours, spending a few  
more minutes reading and writing the results might be inconsequential.

>
> But did you mean that the Cocoa app should save its output as an R  
> workspace? Is it possible to convert and save a C array into its  
> equivalent in an R workspace?

You might follow this, http://developer.r-project.org/embedded.html to  
embed R into the Cocoa app.  I have no experience with this but it may  
lead you to something else.  You might also look at https://stat.ethz.ch/pipermail/r-sig-mac/2005-March/001706.html

Its possible to use interprocess communications to have R request the  
data from the Cocoa App.  However, there are a number of problems with  
this.  For example, the cocoa app has to be running.  When R is  
requesting the data it will be locked up waiting for the data.  You  
need to read state back and forth to know when to do what.  You will  
need to write an R extension in C, much the like the database  
extensions.  This seems like a lot of complexity to me.  In essence,  
your Cocoa GUI app would act like a database provider.

If R processing is segmenting the array at all, then you might be able  
to use a common database from both the Cocoa app and R.  A database  
just writes to a file with a lot more overhead, so if its not  
segmenting the array then you are probably better off reading a flat  
file as it all needs to be in memory at one time.

>
> While searching more on the web, I came across a post of someone  
> wanting to export a C++ array to R, and Simon Urbanek replied "the  
> short answer is no, you can't, because the memory has to be  
> allocated by R". But R.app is Applescript enabled, so I should be  
> able to tell R to create an array, and maybe later assign this  
> object to the simulation output.

I would guess that writing to a file and importing into R would be  
much faster than using Applescript.

>
>> Why not run the original dyn library simulation as another user,  
>> then the current user can do whatever they want with R?  To do this  
>> enable "fast user switching" in the "Accounts" preference.  Now you  
>> can leave a program running as one user and log in as another user  
>> to do something else.  Of course, you will need to create a 2nd  
>> user account.
>
> That would work, but that would not be very practicable, for  
> example, I would need as many accounts as simulations I want to run  
> at the same time.
>

Then why not run R from the command line, you can have as many R  
instances running as you have machine (memory and CPUs), then use your  
original library version.