hi dirk, i'm having an issue with grDevices, but the issue only seems to appear when i using my library with RInside on windows. one of the packages we use (ggjoy) calls the grDevices::pdf() function, which tries to load the enc/WinAnsi.enc file from grDevices package. however, as can be seen here https://jona.thon.love/rinside.png it doesn't look relative to the R_HOME, but to `C:\`. fossicking through the grDevices source code, i find this: https://github.com/wch/r-source/blob/b7e8221be0266371b5b12e3549cf052c1eed10bc/src/library/grDevices/src/devPS.c#L507 suggesting that the value of this R_Home variable is an empty string however, the R_HOME environmental variable is set appropriately, and calling any number of the `R.home()`, `Sys.getenv('R_HOME')` return the expected value. further, this particular installation is used by tens of thousand of users, and produces plots fine ... this is the only exception we've found so far. you don't have any intuitions as to what may be the problem here, and how we could work around it? with thanks jonathon
[Rcpp-devel] grDevices issue with RInside
5 messages · Dirk Eddelbuettel, Jonathon Love
Hi Jonathon,
On 15 August 2017 at 19:46, Jonathon Love wrote:
| i'm having an issue with grDevices, but the issue only seems to appear | when i using my library with RInside on windows. | | one of the packages we use (ggjoy) calls the grDevices::pdf() function, | which tries to load the enc/WinAnsi.enc file from grDevices package. | however, as can be seen here | | https://jona.thon.love/rinside.png | | it doesn't look relative to the R_HOME, but to `C:\`. | | fossicking through the grDevices source code, i find this: | | https://github.com/wch/r-source/blob/b7e8221be0266371b5b12e3549cf052c1eed10bc/src/library/grDevices/src/devPS.c#L507 | | suggesting that the value of this R_Home variable is an empty string | | however, the R_HOME environmental variable is set appropriately, and | calling any number of the `R.home()`, `Sys.getenv('R_HOME')` return the | expected value. further, this particular installation is used by tens of | thousand of users, and produces plots fine ... this is the only | exception we've found so far. | | you don't have any intuitions as to what may be the problem here, and | how we could work around it? Might it be that you are shooting the messenger? You see the issue via RInside as you implemented it via RInside. But we "merely" give you access to the embedded R instance, and methinks that the issue may be with ggjoy and/or the pdf() device. Are you really sure RInside plays any part here? Dirk
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
hi dirk,
Might it be that you are shooting the messenger? You see the issue via RInside as you implemented it via RInside. But we "merely" give you access to the embedded R instance, and methinks that the issue may be with ggjoy and/or the pdf() device. Are you really sure RInside plays any part here?
yeah, i totally recognise RInside may only be related in an incredibly tangential way. all this code works fine when run interactively (and on macOS and linux), and i haven't been able to reproduce the issue outside of rinside ... i expect it's some subtle interaction, but i thought i'd check in with you that you'd not encountered something like this before. to me it looks like an R issue, but it's almost impossible to get anyone to take you seriously when your minimal example is an executable embedding RInside :P with thanks jonathon
hi dirk, i've got it! Rst.rhome is assigned here from getenv() (and no copy is made): https://github.com/eddelbuettel/rinside/blob/d94b999b1f9a5b9a7c1eaefc89abe40ea0d2d4d2/src/RInside.cpp#L164 It makes it's way down inside of R, and is assigned to R_Home: https://github.com/wch/r-source/blob/3234382b4b4632b114fc8400885300b04e4934a0/src/gnuwin32/system.c#L724 strings returned by getenv() are invalidated by subsequent calls to getenv(). the offending code exists in a #ifdef _WIN32 which is why it's windows only. i'll have a PR for you shortly. this has been a bit of an epic. jonathon
hi dirk,
Might it be that you are shooting the messenger? You see the issue via RInside as you implemented it via RInside. But we "merely" give you access to the embedded R instance, and methinks that the issue may be with ggjoy and/or the pdf() device. Are you really sure RInside plays any part here?
yeah, i totally recognise RInside may only be related in an incredibly tangential way. all this code works fine when run interactively (and on macOS and linux), and i haven't been able to reproduce the issue outside of rinside ... i expect it's some subtle interaction, but i thought i'd check in with you that you'd not encountered something like this before. to me it looks like an R issue, but it's almost impossible to get anyone to take you seriously when your minimal example is an executable embedding RInside :P with thanks jonathon
On 16 August 2017 at 19:50, Jonathon Love wrote:
| hi dirk, | | i've got it! | | Rst.rhome is assigned here from getenv() (and no copy is made): | | https://github.com/eddelbuettel/rinside/blob/d94b999b1f9a5b9a7c1eaefc89abe40ea0d2d4d2/src/RInside.cpp#L164 | | It makes it's way down inside of R, and is assigned to R_Home: | | https://github.com/wch/r-source/blob/3234382b4b4632b114fc8400885300b04e4934a0/src/gnuwin32/system.c#L724 | | strings returned by getenv() are invalidated by subsequent calls to | getenv(). | | the offending code exists in a #ifdef _WIN32 which is why it's windows only. | | i'll have a PR for you shortly. Seeing it now, thanks! | this has been a bit of an epic. I can imagine. Windows embedding is simply less well used which is probably why you were the first to find this particular banane peel ... Dirk
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org