On 13-04-19 5:37 PM, Kevin Coombes wrote:
Having finally found some free time, I was going to use it to update a
bunch of R packages from 2.15 to 3.0.
I am running Windows 7, 64-bit professional. This is on a brand-new
laptop using vanilla settings when installing the operating system.
Problem 1: I installed R3.0 to the default location (C:\Program
FIles\R\R-3.0.0). The first thing I tried to do was install
BioConductor. This failed (permission denied). Thinking that this might
be a BioConductor problem, I then tried to install a (semirandom)
package from CRAN. This also failed.
In both cases, when using the GUI, the error message is almost
incomprehensible. You get a pop-up window that *only* says "Do you want
to use a private library instead?" Since this wasn't what I wanted to
do I said "no". Only after the pop-up closes does the command window
print the error message telling me that permission was denied for R to
write to its own library location.
This is a standard Windows problem, to stop viruses from modifying installed
programs. The standard Windows solution to it is to run the installer as an
administrator, taking personal responsibility for installing the
package/virus.
Since this is a laptop, you could probably do this, but it's possible that
you are not the administrator on your system. If that's the case, you
should ask your administrator to do the install.
Dumb Fix to Problem 1: So, I uninstalled R and then reinstalled to a
nonstandard location (C:\R\R-3.0.0). Now I can successfully install
packages from CRAN and BioConductor (hooray!). But I run directly into:
That's another solution, and a third solution is to accept the offer R made,
to install your packages somewhere where you as a user have write
permission.
Problem 2: Emacs Speaks Statistics (ESS) can no longer find the R
binary. When R was installed in the default location, ESS worked. When R
2.15 (or earlier) was installed in the same nonstandard location, I
could get ESS to find the R binaries by including (setq
ess-directory-containing-r "C:") in my .emacs file, but that no longer
works.
Dumb Fix to Problem 2: Hack into ess-site.el and put the complete,
explicit path to the correct binary into
(setq-default inferior-R-program-name 'FULLPATHHERE")
which will break as soon as I upgrade R (assuming I am foolish enough to
ever do that again).
I can't help you with ESS.
Now I am ready to rebuild my R packages. I have this nice perl script
that goes through the following procedure:
1. Set the path to include the correct Rtools directory. (For reasons
that Gabor Grothendieck has pointed out previously, this is not a
permanent part of the path since doing so would override some built-in
Windows commands.)
Just curious: how often do you use the Windows find command? We have put
instructions in place for people to run the install process with a renamed
Rtools find command (which I think is the only conflict). The issue is that
more users who want to use the command line commands are familiar with the
Unix variant (which came first, by the way) than the Windows one, so
renaming the Rtools one would cause trouble for more people.
