This is an R-specific problem discovered in the normal course of programming.
Sometimes, when the Platform is run via its internally housed version of R, on a computer that houses a second, separate, stand-alone version of R, R gets confused as to which package library it should utilize to complete the requested program. Sometimes, it looks within the R folder of the CAMP RST folder, as it should, but sometimes, if the computer on which the Platform is running also houses a separate copy of the same version of R, it looks in that particular user's library for necessary packages. If the user has separate package versions, etc., this can cause the Platform-run analysis to abort.
Trent figured this out.
Unless R_LIBS_USER is set beforehand, at startup R looks for a folder named paste(Sys.getenv("R_USER"), "/R/win-library/<R version number>"). If R does not find this directory, it does not add it to .libPaths() and only the "home" libPath is in .libPaths().
When running off the L:\ drive, <R version number> is 3.1. Trent does not have a local directory named C:/users/tmcdonald/google drive/documents/R/win-library/3.1. Trent has a directory which ends in /R/win-library/3.2 because Trent erased his previous versions. Jason has a local directory that ends /R/win-library/3.1. This led to errors when testing programs directly via the Platform. Case solved.
For the Platform, we don't want this to happen. We want to make sure to use the packages we include in the Platform. This could really screw us up if someone happened to have a local R copy with version number 3.1 (or any version that matches the one we are using). So, to fix this, include the following line at the top of source_all.r:
.libPaths(.Library)
This will erase any local R_LIBS_USER directory and point to the library tree we send out. This will fix the problem and prevent other future problems.
This is an R-specific problem discovered in the normal course of programming.
Sometimes, when the Platform is run via its internally housed version of R, on a computer that houses a second, separate, stand-alone version of R, R gets confused as to which package library it should utilize to complete the requested program. Sometimes, it looks within the
R
folder of theCAMP RST
folder, as it should, but sometimes, if the computer on which the Platform is running also houses a separate copy of the same version of R, it looks in that particular user's library for necessary packages. If the user has separate package versions, etc., this can cause the Platform-run analysis to abort.Trent figured this out.
Unless
R_LIBS_USER
is set beforehand, at startup R looks for a folder namedpaste(Sys.getenv("R_USER"), "/R/win-library/<R version number>")
. If R does not find this directory, it does not add it to.libPaths()
and only the "home"libPath
is in.libPaths()
.When running off the
L:\
drive,<R version number>
is3.1
. Trent does not have a local directory namedC:/users/tmcdonald/google drive/documents/R/win-library/3.1
. Trent has a directory which ends in/R/win-library/3.2
because Trent erased his previous versions. Jason has a local directory that ends/R/win-library/3.1
. This led to errors when testing programs directly via the Platform. Case solved.For the Platform, we don't want this to happen. We want to make sure to use the packages we include in the Platform. This could really screw us up if someone happened to have a local R copy with version number
3.1
(or any version that matches the one we are using). So, to fix this, include the following line at the top ofsource_all.r
:This will erase any local
R_LIBS_USER
directory and point to the library tree we send out. This will fix the problem and prevent other future problems.