7

I have my R installed in C:\R\R-3.3.0. But:

> R.home()
[1] "C:/R/R-33~1.0"
> Sys.getenv("R_HOME")
[1] "C:/R/R-33~1.0"

I think both should be "C:/R/R-3.3.0" as I have quite a lot of trouble when using the debugger: It just does not find the libraries!

As I am on Windows, I read this in the documentation, but it did not help:

On Windows the values of R.home() and R_HOME are switched to the 8.3 short form of path elements if required and if the Windows service to do that is enabled. The value of R_HOME is set to use forward slashes (since many package maintainers pass it unquoted to shells, for example in ‘Makefile’s).

Help is higly appreciated, because my knowledge about environment variables is tiny.

Christoph
  • 6,841
  • 4
  • 37
  • 89
  • Maybe `Sys.setenv()` ? – symbolrush Jul 07 '16 at 10:00
  • I also thought about that - but I don't want to mess things further up... – Christoph Jul 07 '16 at 10:04
  • I guess `dir c:/R /x` shows the short name of the R-3.3.0 directory, and that it is R-33~1.0 ? Maybe it would help to illustrate the trouble you are having using 'the debugger'? – Martin Morgan Jul 07 '16 at 10:43
  • @MartinMorgan: You are right: `dir("C:/R/R-33~1.0")` shows the content of "C:/R/R-3.3.0"! So that is ok and not an error? The problem with my debugger is described [here](http://stackoverflow.com/questions/38197844/strange-error-debugger-does-not-find-source). Do you think I should delete that question? – Christoph Jul 07 '16 at 11:05
  • @Christoph you say that 'debugging is not working' but it's not clear what that means? You mean you invoke the function but do not enter the debugger? Maybe another function masks the one you expect, at the R prompt `function` is not the same as `package::function`. – Martin Morgan Jul 07 '16 at 11:12
  • @MartinMorgan: Sorry, the answer was hidden in the link given above... The message is "debug location is approximate because the source is not available". Surprisingly, it is only a problem on my laptop and only with one function of my package. I checked with a collegue, that the problem is reproducible - at least on my laptop. Unfortunately, it is NOT reproducable on another laptop. – Christoph Jul 07 '16 at 11:20
  • @MartinMorgan: Do you have any idea / hypthesis which I could test? I run out of ideas. How can just ONE function not be found? – Christoph Jul 07 '16 at 12:07
  • Your posts do not show the problem (e.g., no text 'debug location is not ...' in either question) so it's pointless to speculate on the problem; better to make the package available, e.g., in github, even better to trim the package to contain a minimal reproducible example -- just the function that you can't debug. I'd guess the function is in its own file and the file is different from others, e.g., DOS encoding. Maybe you install the package in a non-standard way, so show that step; it's not good enough to say 'I re-installed the package'. Take extra stuff out of the picture, like packrat. – Martin Morgan Jul 07 '16 at 13:11
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/116695/discussion-between-christoph-and-martin-morgan). – Christoph Jul 07 '16 at 13:29

1 Answers1

3

Thanks to @Morgan I found the answer here:

The "short name" is really the old DOS 8.3 naming convention, so all the directories will be the first 6 letters followed by ~1 assuming there is only one name that matches

Community
  • 1
  • 1
Christoph
  • 6,841
  • 4
  • 37
  • 89