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:
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.
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