On Mon, 2009-04-06 at 17:26 +0200, Pierre-Yves wrote:
On Mon, 2009-04-06 at 16:09 +0200, Martyn Plummer wrote:
This is using the JRI interface to call the R engine from within java. If you want to do this then you should write a wrapper script that sets all the necessary environment variables, the class path and so on.
The rJava package contains two examples "rtest" and "rtest2", both of which are installed, along with a wrapper script called "run".
Yes and their first step is:
#!/bin/sh
R_HOME=/usr/lib64/R
even before running anything
A more extensive example is the JGR package which provides a Java GUI for R. The GUI can be launched from the shell by running a wrapper script - again called "run" - which is installed with the JGR package. This script also works perfectly for me.
This is not a reason to set R_HOME globally,
I see two points, either we help the user by setting the R_HOME ourself directly within R and rjava works directly or we do not and let set R_HOME which he will do anyway to make rjava working...
How does it help the user to set R_HOME?
The rJava package does two things: 1) It allows the R user to call java functions from within R. 2) It allows applications written in java to start an instance of the R engine and pass data and commands back and forth.
It is the second use (the JRI interface) that concerns us. There are three parties in this situation: 1) R 2) The user 3) A third party java application.
The responsibility for setting R_HOME lies firmly with the third-party application, which should launch from within its own shell, within which R_HOME is set to the appropriate value. This value should be determined when the application is configured. The user should never have to set it.
Is there not a way for the testing suite of the development version to test if R_HOME is already set ?
Setting R_HOME in the environment before launching R is the wrong thing to do. That is why the R shell script prints a warning, and it is the presence of this warning that is causing the test suite to fail.
Another solution could be to add the R_HOME only on the rjava package.
If nothing is acceptable then we should roll back, I don't want to break R :)
Best regards,
Pierre
----------------------------------------------------------------------- This message and its attachments are strictly confidential. If you are not the intended recipient of this message, please immediately notify the sender and delete it. Since its integrity cannot be guaranteed, its content cannot involve the sender's responsibility. Any misuse, any disclosure or publication of its content, either whole or partial, is prohibited, exception made of formally approved use -----------------------------------------------------------------------
On Tue, 2009-04-07 at 12:09 +0200, Martyn Plummer wrote:
I see two points, either we help the user by setting the R_HOME ourself directly within R and rjava works directly or we do not and let set R_HOME which he will do anyway to make rjava working...
How does it help the user to set R_HOME?
By user I meant anyone who is willing to use rJava in any of its capacity (including the JRI interface). That mean: people that develop application using rJava or people that use that application.
The rJava package does two things:
- It allows the R user to call java functions from within R.
- It allows applications written in java to start an instance of the R
engine and pass data and commands back and forth.
It is the second use (the JRI interface) that concerns us. There are three parties in this situation:
- R
- The user
- A third party java application.
The responsibility for setting R_HOME lies firmly with the third-party application, which should launch from within its own shell, within which R_HOME is set to the appropriate value. This value should be determined when the application is configured.
Yes but since JRI does not do it automatically, the developer and thus the user have to set a R_HOME by hand. The proof is that this run scrip starts by setting R_HOME...
The user should never have to set it.
I totally agree. I would even say that the JRI interface should be able to determine what is R_HOME directly by asking R.
Is there not a way for the testing suite of the development version to test if R_HOME is already set ?
Setting R_HOME in the environment before launching R is the wrong thing to do.
Just out of curiosity, why ? R_HOME should be coherent between the environment and R itself, through a warning if they are different makes sense (IMHO), but if they are the same what is the problem ?
Regards,
Pierre
r-devel@lists.fedoraproject.org
-
Martyn Plummer -
Pierre-Yves Chibon