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
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
