RInside can fail to run if the user has a non-trivial .Rprofile

[kevinushey]

I've seen this error in a few of the old mailing list and bumped into it while testing RInside. The error message I get on running any of the examples is:

Error: cons memory exhausted (limit reached?)
Execution halted

The Rf_initEmbeddedR(R_argc, (char**)R_argv) call seems to complete successfully, but R dies on the first Rf_eval call:

Rf_eval(Rf_lang2(suppressMessagesSymbol, Rf_lang2(requireSymbol, Rf_mkString("Rcpp"))), R_GlobalEnv);

The error goes away if I

1. Explicitly set --vanilla in the run arguments,
2. Empty out my .Rprofile.

Is there any explicit documentation on how RInside might play nicely (or not nicely) if the user has a .Rprofile? Does an embedded R session come started with less available nodes / memory and hence become more likely to fail in such a situation (if the .Rprofile tries to load up that R session with stuff)?

> sessionInfo()
R Under development (unstable) (2014-02-01 r64910)
Platform: x86_64-apple-darwin13.0.0 (64-bit)

locale:
[1] en_CA.UTF-8/en_CA.UTF-8/en_CA.UTF-8/C/en_CA.UTF-8/en_CA.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

> clang -v
kevinushey@Kevin-MBP:~$ clang -v
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

[eddelbuettel]

Yes. That is kinda known.

I do think we have at least an option for --vanilla you can set for the ctor. Can you try setting that and see what happens? I'd rather not force vanilla, but maybe we need to make it respect an env var or something.

BTW just committed to littler a few things I did on the plane, including automated creation of gitversion.h header

[eddelbuettel]

Oh, another thing I do is to .... protect some parts of my ~/.Rprofile by if (interactive()). Maybe a documentation issue (and/or code issue) ?

[kevinushey]

The user can supply their own argv to the constructor, but AFAICS this is ignored / not used. The arguments passed to Rf_initEmbeddedR are constructed independent of what the user passes:

void RInside::initialize(const int argc, const char* const argv[], const bool loadRcpp, 
                         const bool verbose, const bool interactive) {
...
const char *R_argv[] = {(char*)programName, "--gui=none", "--no-save", "--no-readline", "--silent", "", ""};
    const char *R_argv_opt[] = {"--vanilla", "--slave"};
    int R_argc = (sizeof(R_argv) - sizeof(R_argv_opt) ) / sizeof(R_argv[0]);
    Rf_initEmbeddedR(R_argc, (char**)R_argv);
...
}

That said, I definitely should be protecting my ~/.Rprofile with if (interactive()), but I do think we should strive to protect users from themselves ;) I think it would be better that, so users can avoid these problems, the default is set to --vanilla and users have to 'opt-in' to use their own ~/.Rprofile (and be prepared for errors due to a complicated ~/.Rprofile, a big workspace getting restored, etc...)

Also, re litter -- very awesome :) I'll be checking that out later today.

[eddelbuettel]

Correct. My memory failed me -- I confused this with the boolean switch for verbose and interactive. The use of R_argv_opt() is a carry-over from littler, but while littler deals with this, RInside does not. We could add a new switch, or we could just keep telling people to clean up their ~/.Rprofile :-)

[eddelbuettel]

This is now taken care of in 4282cb3