Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
Being generally uninformed about Windows, I have to admit to almost total confusion trying to follow this thread. However, since I have recently been trying to do something in Windows, I would appreciate a newbie friendly explanation of a few points: -Rtools is used to build R and to build (some?) R packages. If you make Rtools an R package, how do you bootstrap the R build process? -in unix-like OSes, configure is used before make to set things similar to the question of where to find Rtools, and what version of various tools are available, and give warnings and errors if these are not adequate. Is there a reason configure cannot be used in Windows, or is there not something similar? -or am I really confused and should not consider the possibility that people actually build R, so the discussion is just about packages? Thanks, Paul On 13-04-22 11:16 AM, Gabor Grothendieck wrote: On Mon, Apr 22, 2013 at 10:27 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 21/04/2013 6:57 PM, Hadley Wickham wrote: PS. Hadley, is this what you meant when you wrote Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *., or those approaches are only when you call 'R CMD' from the R prompt? I believe the latter, but I just want to make sure I didn't miss something. Well both devtools and RStudio allow you to do package development without leaving R, so neither do anything to your path when you're not using them. In teaching windows users to develop R packages, I found the use of the command line to be a substantial road-block, and if you can develop packages without leaving R, why not? The idea of temporary additions to the path during the INSTALL/build/check code sounds reasonable. R could probably do it more accurately than devtools or RStudio can (since we know the requirements, and you have to guess at them), but could hopefully do it in a way that isn't incompatible with those. The code called by install.packages() and related functions within R is essentially the same code as called by R CMD INSTALL etc from the command line, so this would help both cases. I would like to comment on this as I have had to implement similar facilities myself as part R.bat in the batchfiles. There is an issue of keeping R and Rtools in sync. Currently different Rtools versions will work with the same R version. For example, I have used both Rtools 1927 and 1930 with the current version of R. Its necessary to determine the relative paths that the version of Rtools in use requires since in principle the relative Rtools paths can vary from one version of Rtools to the next if the gcc version changes, say. Ideally the system would be able to figure this out even if registry entries and environment variables are not set by looking in standard locations for the Rtools root and finding the relative paths by querying some file in the Rtools installation itself. devtools does this by querying the Rtools version and uss an internal database of relative paths keyed by version. R.bat in batchfiles does it by scanning the Rtools unins000.dat file and extracting the relative paths directly from it. This has the advantage that no database need be maintained and it also automatically adapts to new versions of Rtools without any foreknowledge of them. Of course since you have control of both ends you alternately could add the relative paths to an expanded version of the VERSION file or add some additional text file into Rtools for the purpose of identifying he relative paths.. Another possibility if significant changes were to be considered would be to make Rtools into an R package thereby leveraging existing facilities and much simplifying any synchronization. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On 29/04/2013 7:43 AM, Paul Gilbert wrote: Being generally uninformed about Windows, I have to admit to almost total confusion trying to follow this thread. However, since I have recently been trying to do something in Windows, I would appreciate a newbie friendly explanation of a few points: -Rtools is used to build R and to build (some?) R packages. If you make Rtools an R package, how do you bootstrap the R build process? Rtools used to be needed for all packages. Nowadays packages that consist only of R code typically wouldn't need it. It might be possible to make Rtools into an R package, but it would require quite a bit of work, because generally speaking packages don't provide command line executables, and we strongly prefer packages to contain their own source. The Rtools source is really quite huge (since it contains compilers for C/C++, Fortran, and Objective C/C++, as well as a small collection of Unix-like tools). -in unix-like OSes, configure is used before make to set things similar to the question of where to find Rtools, and what version of various tools are available, and give warnings and errors if these are not adequate. Is there a reason configure cannot be used in Windows, or is there not something similar? Most bare-bones Windows systems can't run configure scripts and could not possibly provide the minimal tools necessary to build R, so we decided long ago to manually configure R for one particular toolset, which we maintain and distribute. People who have Cygwin installed can use the usual Unix-style tools to configure R for Cygwin, but as far as I know no Cygwin maintainer has managed to build R so that it passes its tests. We (in R-core) do not support Cygwin, putting our efforts towards the current strategy instead. -or am I really confused and should not consider the possibility that people actually build R, so the discussion is just about packages? Not very many people build R on Windows, but a few do, and we support them by making Rtools available. Duncan Murdoch Thanks, Paul On 13-04-22 11:16 AM, Gabor Grothendieck wrote: On Mon, Apr 22, 2013 at 10:27 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 21/04/2013 6:57 PM, Hadley Wickham wrote: PS. Hadley, is this what you meant when you wrote Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *., or those approaches are only when you call 'R CMD' from the R prompt? I believe the latter, but I just want to make sure I didn't miss something. Well both devtools and RStudio allow you to do package development without leaving R, so neither do anything to your path when you're not using them. In teaching windows users to develop R packages, I found the use of the command line to be a substantial road-block, and if you can develop packages without leaving R, why not? The idea of temporary additions to the path during the INSTALL/build/check code sounds reasonable. R could probably do it more accurately than devtools or RStudio can (since we know the requirements, and you have to guess at them), but could hopefully do it in a way that isn't incompatible with those. The code called by install.packages() and related functions within R is essentially the same code as called by R CMD INSTALL etc from the command line, so this would help both cases. I would like to comment on this as I have had to implement similar facilities myself as part R.bat in the batchfiles. There is an issue of keeping R and Rtools in sync. Currently different Rtools versions will work with the same R version. For example, I have used both Rtools 1927 and 1930 with the current version of R. Its necessary to determine the relative paths that the version of Rtools in use requires since in principle the relative Rtools paths can vary from one version of Rtools to the next if the gcc version changes, say. Ideally the system would be able to figure this out even if registry entries and environment variables are not set by looking in standard locations for the Rtools root and finding the relative paths by querying some file in the Rtools installation itself. devtools does this by querying the Rtools version and uss an internal database of relative paths keyed by version. R.bat in batchfiles does it by scanning the Rtools unins000.dat file and extracting the relative paths directly from it. This has the advantage that no database need be maintained and it also automatically adapts to new versions of Rtools without any foreknowledge of them. Of course since you have control of both ends you alternately could add the relative paths to an expanded version of the VERSION file or add some additional text file into Rtools for the purpose of identifying he relative paths.. Another possibility if significant changes were to be considered would be to make Rtools into an R package thereby leveraging existing facilities
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On 13-04-21 9:22 PM, steven mosher wrote:
Well, color me confused as heck. I've upgraded to R 3.0 so that I can bring
my packages up to date, but the instructions surrounding Rtools30 are not a
model of clarity.
First thing is, you should not pay attention to Gabor's complaints.
They are valid, but they only matter to a tiny minority of R users,
those who use software that requires the ancient sort and find
utilities from MSDOS. Rtools installs a minimal Unix emulator, and
sort and find act differently there.
You should also ignore many of the instructions that you find on the
web, because people write them then don't update them when things
change. Pay attention to the R Installation and Administration manual
(which is kept up to date), and the instructions that are installed
along with the tools (and readable on the web site).
If you can't follow those instructions, point out which ones you don't
understand. If you can follow them but things don't work, then describe
what problems you are having.
Duncan Murdoch
On Sun, Apr 21, 2013 at 4:04 PM, Gabor Grothendieck ggrothendi...@gmail.com
wrote:
On Sun, Apr 21, 2013 at 6:17 PM, Henrik Bengtsson h...@biostat.ucsf.edu
wrote:
I (as well) keep a specific Rsetup.bat file for launching Windows
cmd.exe with the proper PATH etc setup for build R packages etc. It's
only after this thread I gave it a second thought; you can indeed
temporarily set the PATH via ~/.Rprofile or ~/.Renviron, which *are*
processed at the very beginning when calling 'R CMD ...'.
EXAMPLE WITH .Rprofile:
## ~/.Rprofile (e.g. C:/User/foo/.Rprofile):
path - unlist(strsplit(Sys.getenv(PATH), ;));
path - c(C:\\Rtools\\bin, C:\\Rtools\\gcc-4.6.3\\bin, path);
Sys.setenv(PATH=paste(unique(path), collapse=;));
## DISABLED:
x:\ R --no-init-file CMD INSTALL matrixStats_0.6.2.tar.gz
* installing to library 'C:/Users/hb/R/win-library/3.0'
* installing *source* package 'matrixStats' ...
** libs
*** arch - i386
ERROR: compilation failed for package 'matrixStats'
* removing 'C:/Users/hb/R/win-library/3.0/matrixStats'
## ENABLED:
x:\ R CMD INSTALL matrixStats_0.6.2.tar.gz
* installing to library 'C:/Users/hb/R/win-library/3.0'
* installing *source* package 'matrixStats' ...
** libs
*** arch - i386
gcc -m32 -IC:/PROGRA~1/R/R-3.0.0patched/include -DNDEBUG [...]
[...]
* DONE (matrixStats)
EXAMPLE WITH .Renviron:
## ~/.Renviron (e.g. C:/User/foo/.Renviron):
# Backslashes are preserved iff put within quotes
PATH=C:\Rtools\bin;C:\Rtools\gcc-4.6.3\bin;${PATH}
x:\ R --no-environ CMD INSTALL matrixStats_0.6.2.tar.gz
= fails
x:\ R CMD INSTALL matrixStats_0.6.2.tar.gz
= works
As long as R is on the PATH, the above either of the approaches
removes the need to add Rtools to the PATH via a BAT file and it won't
clutter up your PATH. This begs the question (as somewhat already
proposed), instead of users/developers doing this manually, would it
be possible to have 'R CMD ...' to locate add Rtools to the PATH
internally. That would certainly lower the barriers for newcomers to
install packages from source that need compilation. Obviously, this
doesn't make the tools (e.g. make) in Rtools available outside of R,
it does not allow you to build R itself from source, but it does cover
the very common use cases of calling 'R CMD build/INSTALL/check/...'.
/Henrik
PS. Hadley, is this what you meant when you wrote Better solutions
(e.g. Rstudio and devtools) temporarily set the path on when you're
calling R CMD *., or those approaches are only when you call 'R CMD'
from the R prompt? I believe the latter, but I just want to make sure
I didn't miss something.
That seems like a reasonable approach although the code shown does
entail more setup and ongoing maintenance by the user than R.bat which
does not require that the user edit any files and additionally locates
R itself and has many other features. Also, because R.bat locates R
itself it can be useful even if you are not doing development. On the
other hand if you are looking to do development strictly from within R
then devtools is already developed.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On 21/04/2013 6:57 PM, Hadley Wickham wrote: PS. Hadley, is this what you meant when you wrote Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *., or those approaches are only when you call 'R CMD' from the R prompt? I believe the latter, but I just want to make sure I didn't miss something. Well both devtools and RStudio allow you to do package development without leaving R, so neither do anything to your path when you're not using them. In teaching windows users to develop R packages, I found the use of the command line to be a substantial road-block, and if you can develop packages without leaving R, why not? The idea of temporary additions to the path during the INSTALL/build/check code sounds reasonable. R could probably do it more accurately than devtools or RStudio can (since we know the requirements, and you have to guess at them), but could hopefully do it in a way that isn't incompatible with those. The code called by install.packages() and related functions within R is essentially the same code as called by R CMD INSTALL etc from the command line, so this would help both cases. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
The idea of temporary additions to the path during the INSTALL/build/check code sounds reasonable. R could probably do it more accurately than devtools or RStudio can (since we know the requirements, and you have to guess at them), but could hopefully do it in a way that isn't incompatible with those. Both devtools and Rstudio check if gcc and ls are on the path already, and if they are, do nothing, so anything you did should be compatible. JJ and I would of course be happy to make any changes if necessary, and share our code for Rtools detection (along with useful error messages in all the edge cases). Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On Mon, Apr 22, 2013 at 10:27 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 21/04/2013 6:57 PM, Hadley Wickham wrote: PS. Hadley, is this what you meant when you wrote Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *., or those approaches are only when you call 'R CMD' from the R prompt? I believe the latter, but I just want to make sure I didn't miss something. Well both devtools and RStudio allow you to do package development without leaving R, so neither do anything to your path when you're not using them. In teaching windows users to develop R packages, I found the use of the command line to be a substantial road-block, and if you can develop packages without leaving R, why not? The idea of temporary additions to the path during the INSTALL/build/check code sounds reasonable. R could probably do it more accurately than devtools or RStudio can (since we know the requirements, and you have to guess at them), but could hopefully do it in a way that isn't incompatible with those. The code called by install.packages() and related functions within R is essentially the same code as called by R CMD INSTALL etc from the command line, so this would help both cases. I would like to comment on this as I have had to implement similar facilities myself as part R.bat in the batchfiles. There is an issue of keeping R and Rtools in sync. Currently different Rtools versions will work with the same R version. For example, I have used both Rtools 1927 and 1930 with the current version of R. Its necessary to determine the relative paths that the version of Rtools in use requires since in principle the relative Rtools paths can vary from one version of Rtools to the next if the gcc version changes, say. Ideally the system would be able to figure this out even if registry entries and environment variables are not set by looking in standard locations for the Rtools root and finding the relative paths by querying some file in the Rtools installation itself. devtools does this by querying the Rtools version and uss an internal database of relative paths keyed by version. R.bat in batchfiles does it by scanning the Rtools unins000.dat file and extracting the relative paths directly from it. This has the advantage that no database need be maintained and it also automatically adapts to new versions of Rtools without any foreknowledge of them. Of course since you have control of both ends you alternately could add the relative paths to an expanded version of the VERSION file or add some additional text file into Rtools for the purpose of identifying he relative paths.. Another possibility if significant changes were to be considered would be to make Rtools into an R package thereby leveraging existing facilities and much simplifying any synchronization. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
The problem is that if you don't just use the PC for running R but use it to run other programs too then any program and that utilizes Windows batch scripts making use of find.exe or sort.exe likely won't work if Rtools is on your path. The fact that devtools, batchfiles and Rcpp have workarounds mitigates it somewhat but the problem should be fixed so it works out-of-the-box once and for all. I guess I don't see the advantage of that approach (except perhaps for simplicity), compared to using the registry to store path information and then using environmental variables to set it when needed. It would be nice if Rtools didn't override existing windows executables, in the same way it would be nice if windows worked like linux out of the box. But since it doesn't, and since in general adding more and more directories to the path makes it more and more likely for some conflict to arise, I think Rtools current approach is very reasonable. Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On Sun, Apr 21, 2013 at 8:18 AM, Hadley Wickham h.wick...@gmail.com wrote: The problem is that if you don't just use the PC for running R but use it to run other programs too then any program and that utilizes Windows batch scripts making use of find.exe or sort.exe likely won't work if Rtools is on your path. The fact that devtools, batchfiles and Rcpp have workarounds mitigates it somewhat but the problem should be fixed so it works out-of-the-box once and for all. I guess I don't see the advantage of that approach (except perhaps for simplicity), compared to using the registry to store path information and then using environmental variables to set it when needed. It would be nice if Rtools didn't override existing windows executables, in the same way it would be nice if windows worked like linux out of the box. But since it doesn't, and since in general adding more and more directories to the path makes it more and more likely for some conflict to arise, I think Rtools current approach is very reasonable. Because it can conflict with other Windows software unless you add a layer over it. What other popular software that runs on Windows has these problems? I can't think of any. The closest I can come up with was that for a short time after git was ported to Windows it would change the font of the Windows console but there was an immediate hue and cry about it having no business messing with the rest of Windows and it was quickly rectified. Accepting these infelicities just gets one onto a slippery slope. For example, as far as I know devtools and Rcpp don't have any current problems but that could easily change in the future since they keep databases of Rtools configurations which must be manually updated by their developers as Rtools evolves -- if Rtools changes they could stop working for periods of time until new versions are produced. R.bat in batchfiles was just re-written this year so it is a bit more robust to such changes but even it would have to be modified if the changes in Rtools were of sufficient magnitude. I don't blame these tools for this but surely this is a symptom that something is fundamentally wrong with the entire approach since the tight coupling of what should be independent modules results in the need for ongoing maintenance. Some good work was done to rid R and Rtools of dependence on perl but this effort should not stop there and needs to continue in order to reduce and eliminate the dependence on third party tools that cause problems. (By the way, regarding registry values and environment variables, R.bat in batchfiles will look at the registry and at environment variables but it will work even if no registry values or environment variables have been set by the user provided one uses standard locations for R and Rtools. That is, in fact, how I run my own configuration on Windows.) -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
Because it can conflict with other Windows software unless you add a layer over it. What other popular software that runs on Windows has these problems? I can't think of any. The closest I can come up with was that for a short time after git was ported to Windows it would change the font of the Windows console but there was an immediate hue and cry about it having no business messing with the rest of Windows and it was quickly rectified. I don't understand: unless you modify settings in the default install, Rtools *does not* affect other windows software in any way. Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On Sun, Apr 21, 2013 at 9:49 AM, Hadley Wickham h.wick...@gmail.com wrote: Because it can conflict with other Windows software unless you add a layer over it. What other popular software that runs on Windows has these problems? I can't think of any. The closest I can come up with was that for a short time after git was ported to Windows it would change the font of the Windows console but there was an immediate hue and cry about it having no business messing with the rest of Windows and it was quickly rectified. I don't understand: unless you modify settings in the default install, Rtools *does not* affect other windows software in any way. If its the case that it now works from the cmd line without setting the Rtools path before issuing R CMD ... that would be great. If so it must have occurred silently at some point since I have spent hours in past years trying to track down why another program I was using did not work only to discover that it was Rtools. Surely this was also your own understanding since devtools, maintains an Rtools path database which ought to be unnecessary if R is able to find Rtools itself. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
Because it can conflict with other Windows software unless you add a layer over it. What other popular software that runs on Windows has these problems? I can't think of any. The closest I can come up with was that for a short time after git was ported to Windows it would change the font of the Windows console but there was an immediate hue and cry about it having no business messing with the rest of Windows and it was quickly rectified. I don't understand: unless you modify settings in the default install, Rtools *does not* affect other windows software in any way. If its the case that it now works from the cmd line without setting the Rtools path before issuing R CMD ... that would be great. If so it must have occurred silently at some point since I have spent hours in past years trying to track down why another program I was using did not work only to discover that it was Rtools. Surely this was also your own understanding since devtools, maintains an Rtools path database which ought to be unnecessary if R is able to find Rtools itself. I think we are having a failure of communication: Rtools does not set the path, so that you must do so, every time you use it. There is no other way to prevent it from interfering from some other windows software, except by tightly confining the scope in which it enters the path. When I first starting working with Rtools, I thought this was a terribly frustrating decision - why didn't the default installer always put rtools on the path? But now I see it's the only way - it avoids conflicts with other software, and without that default there'd be no way to have multiple versions of rtools installed. That said, I think the logic that Rstudio and devtools uses to find rtools would have been helpful to include in base R, but that's not so important now that it's available in a package. (And if any big change was made, I'd probably argue it'd be better just to always bundle rtools with R on windows - I think it's a key part of the philosophy of R that users can easily become developers. But there are obviously other considerations.) To clarify, the rtools database in devtools does not contain a list of locations of rtools, but the directories inside of an rtools installation that need to be available on the path. This list has changed over time as the tools needed by R have changed. I don't see any way of avoiding that (except perhaps by storing those in the registry, but regardless there's no way to go back in time and fix old decisions). Devtools (following the logic of rstudio) looks in a number of places to find rtools, first looking in the path and then in the registry, and takes considerable care to ensure that the versions of R and rtools match (another reason why the database is necessary). Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
While as a Linux user who has not so far been banished to Winland I have not experienced this problem, it seems to be the type of issue where a how to, for example, on the R Wiki, would be helpful. Moreover, surely this is a name conflict on different platforms, so possibly a list of these in a related location would also be useful. I have been struggling unsuccessfully to remember one that bit me recently when I did have to help a Windows user. It was not a major disaster, but more of a large sucking sound of time being wasted figuring out something that was just a shade more than trivial. If there are folk who can get this started, do include me in an off-list copy and I'll be willing to test/edit wiki material. JN __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On Sun, Apr 21, 2013 at 12:57 PM, Hadley Wickham h.wick...@gmail.com wrote: Because it can conflict with other Windows software unless you add a layer over it. What other popular software that runs on Windows has these problems? I can't think of any. The closest I can come up with was that for a short time after git was ported to Windows it would change the font of the Windows console but there was an immediate hue and cry about it having no business messing with the rest of Windows and it was quickly rectified. I don't understand: unless you modify settings in the default install, Rtools *does not* affect other windows software in any way. If its the case that it now works from the cmd line without setting the Rtools path before issuing R CMD ... that would be great. If so it must have occurred silently at some point since I have spent hours in past years trying to track down why another program I was using did not work only to discover that it was Rtools. Surely this was also your own understanding since devtools, maintains an Rtools path database which ought to be unnecessary if R is able to find Rtools itself. I think we are having a failure of communication: Rtools does not set the path, so that you must do so, every time you use it. There is no other way to prevent it from interfering from some other windows software, except by tightly confining the scope in which it enters the path. When I first starting working with Rtools, I thought this was a terribly frustrating decision - why didn't the default installer always put rtools on the path? But now I see it's the only way - it avoids conflicts with other software, and without that default there'd be no way to have multiple versions of rtools installed. That said, I think the logic that Rstudio and devtools uses to find rtools would have been helpful to include in base R, but that's not so important now that it's available in a package. (And if any big change was made, I'd probably argue it'd be better just to always bundle rtools with R on windows - I think it's a key part of the philosophy of R that users can easily become developers. But there are obviously other considerations.) To clarify, the rtools database in devtools does not contain a list of locations of rtools, but the directories inside of an rtools installation that need to be available on the path. This list has changed over time as the tools needed by R have changed. I don't see any way of avoiding that (except perhaps by storing those in the registry, but regardless there's no way to go back in time and fix old decisions). Devtools (following the logic of rstudio) looks in a number of places to find rtools, first looking in the path and then in the registry, and takes considerable care to ensure that the versions of R and rtools match (another reason why the database is necessary). Yes, that is what I thought until you seemed to be saying otherwise but it seems we just misunderstood each other and, in fact, no one disputes the need to put Rtools on the path nor that it conflicts with other Windows programs and potentially causes other programs on your PC not to work. In fact that was one of the motivations I had for developing the batchfiles as I once spent hours tracking down a problem due to Rtools. Also I understand that the devtools database uses relative paths and wasn't faulting devtools for this but only pointing out that the database's existence was a consequence of the need to set up the paths in the first place which is what we were discussing - not devtools. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
I (as well) keep a specific Rsetup.bat file for launching Windows
cmd.exe with the proper PATH etc setup for build R packages etc. It's
only after this thread I gave it a second thought; you can indeed
temporarily set the PATH via ~/.Rprofile or ~/.Renviron, which *are*
processed at the very beginning when calling 'R CMD ...'.
EXAMPLE WITH .Rprofile:
## ~/.Rprofile (e.g. C:/User/foo/.Rprofile):
path - unlist(strsplit(Sys.getenv(PATH), ;));
path - c(C:\\Rtools\\bin, C:\\Rtools\\gcc-4.6.3\\bin, path);
Sys.setenv(PATH=paste(unique(path), collapse=;));
## DISABLED:
x:\ R --no-init-file CMD INSTALL matrixStats_0.6.2.tar.gz
* installing to library 'C:/Users/hb/R/win-library/3.0'
* installing *source* package 'matrixStats' ...
** libs
*** arch - i386
ERROR: compilation failed for package 'matrixStats'
* removing 'C:/Users/hb/R/win-library/3.0/matrixStats'
## ENABLED:
x:\ R CMD INSTALL matrixStats_0.6.2.tar.gz
* installing to library 'C:/Users/hb/R/win-library/3.0'
* installing *source* package 'matrixStats' ...
** libs
*** arch - i386
gcc -m32 -IC:/PROGRA~1/R/R-3.0.0patched/include -DNDEBUG [...]
[...]
* DONE (matrixStats)
EXAMPLE WITH .Renviron:
## ~/.Renviron (e.g. C:/User/foo/.Renviron):
# Backslashes are preserved iff put within quotes
PATH=C:\Rtools\bin;C:\Rtools\gcc-4.6.3\bin;${PATH}
x:\ R --no-environ CMD INSTALL matrixStats_0.6.2.tar.gz
= fails
x:\ R CMD INSTALL matrixStats_0.6.2.tar.gz
= works
As long as R is on the PATH, the above either of the approaches
removes the need to add Rtools to the PATH via a BAT file and it won't
clutter up your PATH. This begs the question (as somewhat already
proposed), instead of users/developers doing this manually, would it
be possible to have 'R CMD ...' to locate add Rtools to the PATH
internally. That would certainly lower the barriers for newcomers to
install packages from source that need compilation. Obviously, this
doesn't make the tools (e.g. make) in Rtools available outside of R,
it does not allow you to build R itself from source, but it does cover
the very common use cases of calling 'R CMD build/INSTALL/check/...'.
/Henrik
PS. Hadley, is this what you meant when you wrote Better solutions
(e.g. Rstudio and devtools) temporarily set the path on when you're
calling R CMD *., or those approaches are only when you call 'R CMD'
from the R prompt? I believe the latter, but I just want to make sure
I didn't miss something.
On Sun, Apr 21, 2013 at 11:02 AM, Gabor Grothendieck
ggrothendi...@gmail.com wrote:
On Sun, Apr 21, 2013 at 12:57 PM, Hadley Wickham h.wick...@gmail.com wrote:
Because it can conflict with other Windows software unless you add a
layer over it. What other popular software that runs on Windows has
these problems? I can't think of any. The closest I can come up with
was that for a short time after git was ported to Windows it would
change the font of the Windows console but there was an immediate hue
and cry about it having no business messing with the rest of Windows
and it was quickly rectified.
I don't understand: unless you modify settings in the default install,
Rtools *does not* affect other windows software in any way.
If its the case that it now works from the cmd line without setting
the Rtools path before issuing R CMD ... that would be great. If so it
must have occurred silently at some point since I have spent hours in
past years trying to track down why another program I was using did
not work only to discover that it was Rtools. Surely this was also
your own understanding since devtools, maintains an Rtools path
database which ought to be unnecessary if R is able to find Rtools
itself.
I think we are having a failure of communication: Rtools does not set
the path, so that you must do so, every time you use it. There is no
other way to prevent it from interfering from some other windows
software, except by tightly confining the scope in which it enters the
path. When I first starting working with Rtools, I thought this was a
terribly frustrating decision - why didn't the default installer
always put rtools on the path? But now I see it's the only way - it
avoids conflicts with other software, and without that default there'd
be no way to have multiple versions of rtools installed. That said, I
think the logic that Rstudio and devtools uses to find rtools would
have been helpful to include in base R, but that's not so important
now that it's available in a package. (And if any big change was made,
I'd probably argue it'd be better just to always bundle rtools with R
on windows - I think it's a key part of the philosophy of R that users
can easily become developers. But there are obviously other
considerations.)
To clarify, the rtools database in devtools does not contain a list of
locations of rtools, but the directories inside of an rtools
installation that need to be available on the path. This list has
changed over time as the tools needed by R have changed. I don't
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
PS. Hadley, is this what you meant when you wrote Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *., or those approaches are only when you call 'R CMD' from the R prompt? I believe the latter, but I just want to make sure I didn't miss something. Well both devtools and RStudio allow you to do package development without leaving R, so neither do anything to your path when you're not using them. In teaching windows users to develop R packages, I found the use of the command line to be a substantial road-block, and if you can develop packages without leaving R, why not? Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On Sun, Apr 21, 2013 at 6:17 PM, Henrik Bengtsson h...@biostat.ucsf.edu wrote:
I (as well) keep a specific Rsetup.bat file for launching Windows
cmd.exe with the proper PATH etc setup for build R packages etc. It's
only after this thread I gave it a second thought; you can indeed
temporarily set the PATH via ~/.Rprofile or ~/.Renviron, which *are*
processed at the very beginning when calling 'R CMD ...'.
EXAMPLE WITH .Rprofile:
## ~/.Rprofile (e.g. C:/User/foo/.Rprofile):
path - unlist(strsplit(Sys.getenv(PATH), ;));
path - c(C:\\Rtools\\bin, C:\\Rtools\\gcc-4.6.3\\bin, path);
Sys.setenv(PATH=paste(unique(path), collapse=;));
## DISABLED:
x:\ R --no-init-file CMD INSTALL matrixStats_0.6.2.tar.gz
* installing to library 'C:/Users/hb/R/win-library/3.0'
* installing *source* package 'matrixStats' ...
** libs
*** arch - i386
ERROR: compilation failed for package 'matrixStats'
* removing 'C:/Users/hb/R/win-library/3.0/matrixStats'
## ENABLED:
x:\ R CMD INSTALL matrixStats_0.6.2.tar.gz
* installing to library 'C:/Users/hb/R/win-library/3.0'
* installing *source* package 'matrixStats' ...
** libs
*** arch - i386
gcc -m32 -IC:/PROGRA~1/R/R-3.0.0patched/include -DNDEBUG [...]
[...]
* DONE (matrixStats)
EXAMPLE WITH .Renviron:
## ~/.Renviron (e.g. C:/User/foo/.Renviron):
# Backslashes are preserved iff put within quotes
PATH=C:\Rtools\bin;C:\Rtools\gcc-4.6.3\bin;${PATH}
x:\ R --no-environ CMD INSTALL matrixStats_0.6.2.tar.gz
= fails
x:\ R CMD INSTALL matrixStats_0.6.2.tar.gz
= works
As long as R is on the PATH, the above either of the approaches
removes the need to add Rtools to the PATH via a BAT file and it won't
clutter up your PATH. This begs the question (as somewhat already
proposed), instead of users/developers doing this manually, would it
be possible to have 'R CMD ...' to locate add Rtools to the PATH
internally. That would certainly lower the barriers for newcomers to
install packages from source that need compilation. Obviously, this
doesn't make the tools (e.g. make) in Rtools available outside of R,
it does not allow you to build R itself from source, but it does cover
the very common use cases of calling 'R CMD build/INSTALL/check/...'.
/Henrik
PS. Hadley, is this what you meant when you wrote Better solutions
(e.g. Rstudio and devtools) temporarily set the path on when you're
calling R CMD *., or those approaches are only when you call 'R CMD'
from the R prompt? I believe the latter, but I just want to make sure
I didn't miss something.
That seems like a reasonable approach although the code shown does
entail more setup and ongoing maintenance by the user than R.bat which
does not require that the user edit any files and additionally locates
R itself and has many other features. Also, because R.bat locates R
itself it can be useful even if you are not doing development. On the
other hand if you are looking to do development strictly from within R
then devtools is already developed.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
Well, color me confused as heck. I've upgraded to R 3.0 so that I can bring
my packages up to date, but the instructions surrounding Rtools30 are not a
model of clarity.
On Sun, Apr 21, 2013 at 4:04 PM, Gabor Grothendieck ggrothendi...@gmail.com
wrote:
On Sun, Apr 21, 2013 at 6:17 PM, Henrik Bengtsson h...@biostat.ucsf.edu
wrote:
I (as well) keep a specific Rsetup.bat file for launching Windows
cmd.exe with the proper PATH etc setup for build R packages etc. It's
only after this thread I gave it a second thought; you can indeed
temporarily set the PATH via ~/.Rprofile or ~/.Renviron, which *are*
processed at the very beginning when calling 'R CMD ...'.
EXAMPLE WITH .Rprofile:
## ~/.Rprofile (e.g. C:/User/foo/.Rprofile):
path - unlist(strsplit(Sys.getenv(PATH), ;));
path - c(C:\\Rtools\\bin, C:\\Rtools\\gcc-4.6.3\\bin, path);
Sys.setenv(PATH=paste(unique(path), collapse=;));
## DISABLED:
x:\ R --no-init-file CMD INSTALL matrixStats_0.6.2.tar.gz
* installing to library 'C:/Users/hb/R/win-library/3.0'
* installing *source* package 'matrixStats' ...
** libs
*** arch - i386
ERROR: compilation failed for package 'matrixStats'
* removing 'C:/Users/hb/R/win-library/3.0/matrixStats'
## ENABLED:
x:\ R CMD INSTALL matrixStats_0.6.2.tar.gz
* installing to library 'C:/Users/hb/R/win-library/3.0'
* installing *source* package 'matrixStats' ...
** libs
*** arch - i386
gcc -m32 -IC:/PROGRA~1/R/R-3.0.0patched/include -DNDEBUG [...]
[...]
* DONE (matrixStats)
EXAMPLE WITH .Renviron:
## ~/.Renviron (e.g. C:/User/foo/.Renviron):
# Backslashes are preserved iff put within quotes
PATH=C:\Rtools\bin;C:\Rtools\gcc-4.6.3\bin;${PATH}
x:\ R --no-environ CMD INSTALL matrixStats_0.6.2.tar.gz
= fails
x:\ R CMD INSTALL matrixStats_0.6.2.tar.gz
= works
As long as R is on the PATH, the above either of the approaches
removes the need to add Rtools to the PATH via a BAT file and it won't
clutter up your PATH. This begs the question (as somewhat already
proposed), instead of users/developers doing this manually, would it
be possible to have 'R CMD ...' to locate add Rtools to the PATH
internally. That would certainly lower the barriers for newcomers to
install packages from source that need compilation. Obviously, this
doesn't make the tools (e.g. make) in Rtools available outside of R,
it does not allow you to build R itself from source, but it does cover
the very common use cases of calling 'R CMD build/INSTALL/check/...'.
/Henrik
PS. Hadley, is this what you meant when you wrote Better solutions
(e.g. Rstudio and devtools) temporarily set the path on when you're
calling R CMD *., or those approaches are only when you call 'R CMD'
from the R prompt? I believe the latter, but I just want to make sure
I didn't miss something.
That seems like a reasonable approach although the code shown does
entail more setup and ongoing maintenance by the user than R.bat which
does not require that the user edit any files and additionally locates
R itself and has many other features. Also, because R.bat locates R
itself it can be useful even if you are not doing development. On the
other hand if you are looking to do development strictly from within R
then devtools is already developed.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
Here's the short answer: Whatever you used to do should still work.
I started this thread, not knowing that it was going to get sucked into
a whirlpool on the fringes of an operating system religious war. My
sincerest apologies to everyone who has gotten confused as a consequence.
I only ran into problem because I installed R 3.0 and Rtools 3.0 on a
new machine, and accidentally put Rtools in a different location from
where it used to reside on the machines I used for R 2.whatever. And so
the scripts I used to build packages no longer worked because the path
was wrong. If you can avoid doing something silly like that, then your
old methods for building and maintaining packages should work the same
way they always did.
On 4/21/2013 8:22 PM, steven mosher wrote:
Well, color me confused as heck. I've upgraded to R 3.0 so that I can bring
my packages up to date, but the instructions surrounding Rtools30 are not a
model of clarity.
On Sun, Apr 21, 2013 at 4:04 PM, Gabor Grothendieck ggrothendi...@gmail.com
wrote:
On Sun, Apr 21, 2013 at 6:17 PM, Henrik Bengtsson h...@biostat.ucsf.edu
wrote:
I (as well) keep a specific Rsetup.bat file for launching Windows
cmd.exe with the proper PATH etc setup for build R packages etc. It's
only after this thread I gave it a second thought; you can indeed
temporarily set the PATH via ~/.Rprofile or ~/.Renviron, which *are*
processed at the very beginning when calling 'R CMD ...'.
EXAMPLE WITH .Rprofile:
## ~/.Rprofile (e.g. C:/User/foo/.Rprofile):
path - unlist(strsplit(Sys.getenv(PATH), ;));
path - c(C:\\Rtools\\bin, C:\\Rtools\\gcc-4.6.3\\bin, path);
Sys.setenv(PATH=paste(unique(path), collapse=;));
## DISABLED:
x:\ R --no-init-file CMD INSTALL matrixStats_0.6.2.tar.gz
* installing to library 'C:/Users/hb/R/win-library/3.0'
* installing *source* package 'matrixStats' ...
** libs
*** arch - i386
ERROR: compilation failed for package 'matrixStats'
* removing 'C:/Users/hb/R/win-library/3.0/matrixStats'
## ENABLED:
x:\ R CMD INSTALL matrixStats_0.6.2.tar.gz
* installing to library 'C:/Users/hb/R/win-library/3.0'
* installing *source* package 'matrixStats' ...
** libs
*** arch - i386
gcc -m32 -IC:/PROGRA~1/R/R-3.0.0patched/include -DNDEBUG [...]
[...]
* DONE (matrixStats)
EXAMPLE WITH .Renviron:
## ~/.Renviron (e.g. C:/User/foo/.Renviron):
# Backslashes are preserved iff put within quotes
PATH=C:\Rtools\bin;C:\Rtools\gcc-4.6.3\bin;${PATH}
x:\ R --no-environ CMD INSTALL matrixStats_0.6.2.tar.gz
= fails
x:\ R CMD INSTALL matrixStats_0.6.2.tar.gz
= works
As long as R is on the PATH, the above either of the approaches
removes the need to add Rtools to the PATH via a BAT file and it won't
clutter up your PATH. This begs the question (as somewhat already
proposed), instead of users/developers doing this manually, would it
be possible to have 'R CMD ...' to locate add Rtools to the PATH
internally. That would certainly lower the barriers for newcomers to
install packages from source that need compilation. Obviously, this
doesn't make the tools (e.g. make) in Rtools available outside of R,
it does not allow you to build R itself from source, but it does cover
the very common use cases of calling 'R CMD build/INSTALL/check/...'.
/Henrik
PS. Hadley, is this what you meant when you wrote Better solutions
(e.g. Rstudio and devtools) temporarily set the path on when you're
calling R CMD *., or those approaches are only when you call 'R CMD'
from the R prompt? I believe the latter, but I just want to make sure
I didn't miss something.
That seems like a reasonable approach although the code shown does
entail more setup and ongoing maintenance by the user than R.bat which
does not require that the user edit any files and additionally locates
R itself and has many other features. Also, because R.bat locates R
itself it can be useful even if you are not doing development. On the
other hand if you are looking to do development strictly from within R
then devtools is already developed.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On 13-04-19 10:03 PM, Gabor Grothendieck wrote: On Fri, Apr 19, 2013 at 8:47 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote: 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. Its not just find - its also sort. And really R has no business clobbering built in Windows commands. This is just wrong and really causes anyone who does any significant amount of Windows batch programming (or uses batch programs of any complexity) endless problems. Only those people who choose not to solve them in the recommended way. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
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. Its not just find - its also sort. And really R has no business clobbering built in Windows commands. This is just wrong and really causes anyone who does any significant amount of Windows batch programming (or uses batch programs of any complexity) endless problems. Which is presumably why Rtools doesn't modify the path by default. Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *. Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On Sat, Apr 20, 2013 at 10:45 AM, Hadley Wickham h.wick...@gmail.com wrote: 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. Its not just find - its also sort. And really R has no business clobbering built in Windows commands. This is just wrong and really causes anyone who does any significant amount of Windows batch programming (or uses batch programs of any complexity) endless problems. Which is presumably why Rtools doesn't modify the path by default. Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *. I am well aware of the various kludges to address this including my own batchfiles ( http://batchfiles.googlecode.com ) which handles this by temporarily changing the path as well; however, the real problem is that Rtools does not play nice with Windows and that needs to be addressed directly. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On 13-04-20 11:09 AM, Gabor Grothendieck wrote: On Sat, Apr 20, 2013 at 10:45 AM, Hadley Wickham h.wick...@gmail.com wrote: 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. Its not just find - its also sort. And really R has no business clobbering built in Windows commands. This is just wrong and really causes anyone who does any significant amount of Windows batch programming (or uses batch programs of any complexity) endless problems. Which is presumably why Rtools doesn't modify the path by default. Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *. I am well aware of the various kludges to address this including my own batchfiles ( http://batchfiles.googlecode.com ) which handles this by temporarily changing the path as well; however, the real problem is that Rtools does not play nice with Windows and that needs to be addressed directly. It has been. You ignored it. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On Sat, Apr 20, 2013 at 11:49 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 13-04-20 11:09 AM, Gabor Grothendieck wrote: On Sat, Apr 20, 2013 at 10:45 AM, Hadley Wickham h.wick...@gmail.com wrote: 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. Its not just find - its also sort. And really R has no business clobbering built in Windows commands. This is just wrong and really causes anyone who does any significant amount of Windows batch programming (or uses batch programs of any complexity) endless problems. Which is presumably why Rtools doesn't modify the path by default. Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *. I am well aware of the various kludges to address this including my own batchfiles ( http://batchfiles.googlecode.com ) which handles this by temporarily changing the path as well; however, the real problem is that Rtools does not play nice with Windows and that needs to be addressed directly. It has been. You ignored it. Duncan Murdoch If some change to address this has been made that would be great but there is no mention of it on the Rtools page in the change history section (the only documented change relates to the png/tiff/jpeg libraries), there was no announcement that I saw and Rtools\bin still contains find and sort so what specifically is the change? -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On 13-04-20 12:30 PM, Gabor Grothendieck wrote: On Sat, Apr 20, 2013 at 11:49 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 13-04-20 11:09 AM, Gabor Grothendieck wrote: On Sat, Apr 20, 2013 at 10:45 AM, Hadley Wickham h.wick...@gmail.com wrote: 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. Its not just find - its also sort. And really R has no business clobbering built in Windows commands. This is just wrong and really causes anyone who does any significant amount of Windows batch programming (or uses batch programs of any complexity) endless problems. Which is presumably why Rtools doesn't modify the path by default. Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *. I am well aware of the various kludges to address this including my own batchfiles ( http://batchfiles.googlecode.com ) which handles this by temporarily changing the path as well; however, the real problem is that Rtools does not play nice with Windows and that needs to be addressed directly. It has been. You ignored it. Duncan Murdoch If some change to address this has been made that would be great but there is no mention of it on the Rtools page in the change history section (the only documented change relates to the png/tiff/jpeg libraries), there was no announcement that I saw and Rtools\bin still contains find and sort so what specifically is the change? It's not a change to Rtools, it's a change is to the build system in R: it allows you to rename sort or find in your own copy of Rtools, and R will use whatever you specify. You were informed of this when I did it in 2007, and I've mentioned it when the topic comes up here, most recently in the message quoted above. That's a long time ago, so I don't remember if you tried it then, but I've never heard a complaint from anyone else that it doesn't work. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On 4/20/2013 12:54 PM, Duncan Murdoch wrote: On 13-04-20 12:30 PM, Gabor Grothendieck wrote: On Sat, Apr 20, 2013 at 11:49 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 13-04-20 11:09 AM, Gabor Grothendieck wrote: On Sat, Apr 20, 2013 at 10:45 AM, Hadley Wickham h.wick...@gmail.com wrote: 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. Its not just find - its also sort. And really R has no business clobbering built in Windows commands. This is just wrong and really causes anyone who does any significant amount of Windows batch programming (or uses batch programs of any complexity) endless problems. Which is presumably why Rtools doesn't modify the path by default. Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *. I am well aware of the various kludges to address this including my own batchfiles ( http://batchfiles.googlecode.com ) which handles this by temporarily changing the path as well; however, the real problem is that Rtools does not play nice with Windows and that needs to be addressed directly. It has been. You ignored it. Duncan Murdoch If some change to address this has been made that would be great but there is no mention of it on the Rtools page in the change history section (the only documented change relates to the png/tiff/jpeg libraries), there was no announcement that I saw and Rtools\bin still contains find and sort so what specifically is the change? It's not a change to Rtools, it's a change is to the build system in R: it allows you to rename sort or find in your own copy of Rtools, and R will use whatever you specify. You were informed of this when I did it in 2007, and I've mentioned it when the topic comes up here, most recently in the message quoted above. That's a long time ago, so I don't remember if you tried it then, but I've never heard a complaint from anyone else that it doesn't work. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel How do you do that? (More explicitly, what steps would I have to take to redefine things like find.exe and sort.exe in Rtools so that R would know how to find them and use them? I can't figure that out from the earlier parts of these messages.) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On Sat, Apr 20, 2013 at 1:54 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 13-04-20 12:30 PM, Gabor Grothendieck wrote: On Sat, Apr 20, 2013 at 11:49 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 13-04-20 11:09 AM, Gabor Grothendieck wrote: On Sat, Apr 20, 2013 at 10:45 AM, Hadley Wickham h.wick...@gmail.com wrote: 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. Its not just find - its also sort. And really R has no business clobbering built in Windows commands. This is just wrong and really causes anyone who does any significant amount of Windows batch programming (or uses batch programs of any complexity) endless problems. Which is presumably why Rtools doesn't modify the path by default. Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *. I am well aware of the various kludges to address this including my own batchfiles ( http://batchfiles.googlecode.com ) which handles this by temporarily changing the path as well; however, the real problem is that Rtools does not play nice with Windows and that needs to be addressed directly. It has been. You ignored it. Duncan Murdoch If some change to address this has been made that would be great but there is no mention of it on the Rtools page in the change history section (the only documented change relates to the png/tiff/jpeg libraries), there was no announcement that I saw and Rtools\bin still contains find and sort so what specifically is the change? It's not a change to Rtools, it's a change is to the build system in R: it allows you to rename sort or find in your own copy of Rtools, and R will use whatever you specify. You were informed of this when I did it in 2007, and I've mentioned it when the topic comes up here, most recently in the message quoted above. That's a long time ago, so I don't remember if you tried it then, but I've never heard a complaint from anyone else that it doesn't work. I certainly was not aware of this and posts in this thread suggest that others were not aware of it either. Perhaps you could provide some details and links. I am sure many people would be interested. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On 13-04-20 2:02 PM, Kevin Coombes wrote: On 4/20/2013 12:54 PM, Duncan Murdoch wrote: On 13-04-20 12:30 PM, Gabor Grothendieck wrote: On Sat, Apr 20, 2013 at 11:49 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 13-04-20 11:09 AM, Gabor Grothendieck wrote: On Sat, Apr 20, 2013 at 10:45 AM, Hadley Wickham h.wick...@gmail.com wrote: 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. Its not just find - its also sort. And really R has no business clobbering built in Windows commands. This is just wrong and really causes anyone who does any significant amount of Windows batch programming (or uses batch programs of any complexity) endless problems. Which is presumably why Rtools doesn't modify the path by default. Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *. I am well aware of the various kludges to address this including my own batchfiles ( http://batchfiles.googlecode.com ) which handles this by temporarily changing the path as well; however, the real problem is that Rtools does not play nice with Windows and that needs to be addressed directly. It has been. You ignored it. Duncan Murdoch If some change to address this has been made that would be great but there is no mention of it on the Rtools page in the change history section (the only documented change relates to the png/tiff/jpeg libraries), there was no announcement that I saw and Rtools\bin still contains find and sort so what specifically is the change? It's not a change to Rtools, it's a change is to the build system in R: it allows you to rename sort or find in your own copy of Rtools, and R will use whatever you specify. You were informed of this when I did it in 2007, and I've mentioned it when the topic comes up here, most recently in the message quoted above. That's a long time ago, so I don't remember if you tried it then, but I've never heard a complaint from anyone else that it doesn't work. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel How do you do that? (More explicitly, what steps would I have to take to redefine things like find.exe and sort.exe in Rtools so that R would know how to find them and use them? I can't figure that out from the earlier parts of these messages.) Rename them to whatever you want in the Rtools install, then edit the definitions. I think currently they are in src/gnuwin32/Makefile and src/gnuwin32/MkRules (one in each), but I'd suggest you just search files named M* for the strings sort and find, in case I've got it wrong, or it has changed since the last time I looked. If you try to build R itself rather than just packages, you may need to do more edits, because some of the makefiles for things like the jpeg libraries weren't written by us, and may have these commands hard-coded. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On Sat, Apr 20, 2013 at 2:21 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 13-04-20 2:02 PM, Kevin Coombes wrote: On 4/20/2013 12:54 PM, Duncan Murdoch wrote: On 13-04-20 12:30 PM, Gabor Grothendieck wrote: On Sat, Apr 20, 2013 at 11:49 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 13-04-20 11:09 AM, Gabor Grothendieck wrote: On Sat, Apr 20, 2013 at 10:45 AM, Hadley Wickham h.wick...@gmail.com wrote: 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. Its not just find - its also sort. And really R has no business clobbering built in Windows commands. This is just wrong and really causes anyone who does any significant amount of Windows batch programming (or uses batch programs of any complexity) endless problems. Which is presumably why Rtools doesn't modify the path by default. Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *. I am well aware of the various kludges to address this including my own batchfiles ( http://batchfiles.googlecode.com ) which handles this by temporarily changing the path as well; however, the real problem is that Rtools does not play nice with Windows and that needs to be addressed directly. It has been. You ignored it. Duncan Murdoch If some change to address this has been made that would be great but there is no mention of it on the Rtools page in the change history section (the only documented change relates to the png/tiff/jpeg libraries), there was no announcement that I saw and Rtools\bin still contains find and sort so what specifically is the change? It's not a change to Rtools, it's a change is to the build system in R: it allows you to rename sort or find in your own copy of Rtools, and R will use whatever you specify. You were informed of this when I did it in 2007, and I've mentioned it when the topic comes up here, most recently in the message quoted above. That's a long time ago, so I don't remember if you tried it then, but I've never heard a complaint from anyone else that it doesn't work. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel How do you do that? (More explicitly, what steps would I have to take to redefine things like find.exe and sort.exe in Rtools so that R would know how to find them and use them? I can't figure that out from the earlier parts of these messages.) Rename them to whatever you want in the Rtools install, then edit the definitions. I think currently they are in src/gnuwin32/Makefile and src/gnuwin32/MkRules (one in each), but I'd suggest you just search files named M* for the strings sort and find, in case I've got it wrong, or it has changed since the last time I looked. If you try to build R itself rather than just packages, you may need to do more edits, because some of the makefiles for things like the jpeg libraries weren't written by us, and may have these commands hard-coded. Are you suggesting that R itself be rebuild? Rtools be rebuilt? Some clarity on this and the process to do it would be helpful. I was really looking for a way to do this with an out of the box R installation since from a practical viewpoint few are going to want to build their own software. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On 13-04-20 2:39 PM, Gabor Grothendieck wrote: On Sat, Apr 20, 2013 at 2:21 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 13-04-20 2:02 PM, Kevin Coombes wrote: On 4/20/2013 12:54 PM, Duncan Murdoch wrote: On 13-04-20 12:30 PM, Gabor Grothendieck wrote: On Sat, Apr 20, 2013 at 11:49 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 13-04-20 11:09 AM, Gabor Grothendieck wrote: On Sat, Apr 20, 2013 at 10:45 AM, Hadley Wickham h.wick...@gmail.com wrote: 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. Its not just find - its also sort. And really R has no business clobbering built in Windows commands. This is just wrong and really causes anyone who does any significant amount of Windows batch programming (or uses batch programs of any complexity) endless problems. Which is presumably why Rtools doesn't modify the path by default. Better solutions (e.g. Rstudio and devtools) temporarily set the path on when you're calling R CMD *. I am well aware of the various kludges to address this including my own batchfiles ( http://batchfiles.googlecode.com ) which handles this by temporarily changing the path as well; however, the real problem is that Rtools does not play nice with Windows and that needs to be addressed directly. It has been. You ignored it. Duncan Murdoch If some change to address this has been made that would be great but there is no mention of it on the Rtools page in the change history section (the only documented change relates to the png/tiff/jpeg libraries), there was no announcement that I saw and Rtools\bin still contains find and sort so what specifically is the change? It's not a change to Rtools, it's a change is to the build system in R: it allows you to rename sort or find in your own copy of Rtools, and R will use whatever you specify. You were informed of this when I did it in 2007, and I've mentioned it when the topic comes up here, most recently in the message quoted above. That's a long time ago, so I don't remember if you tried it then, but I've never heard a complaint from anyone else that it doesn't work. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel How do you do that? (More explicitly, what steps would I have to take to redefine things like find.exe and sort.exe in Rtools so that R would know how to find them and use them? I can't figure that out from the earlier parts of these messages.) Rename them to whatever you want in the Rtools install, then edit the definitions. I think currently they are in src/gnuwin32/Makefile and src/gnuwin32/MkRules (one in each), but I'd suggest you just search files named M* for the strings sort and find, in case I've got it wrong, or it has changed since the last time I looked. If you try to build R itself rather than just packages, you may need to do more edits, because some of the makefiles for things like the jpeg libraries weren't written by us, and may have these commands hard-coded. Are you suggesting that R itself be rebuild? Rtools be rebuilt? Some clarity on this and the process to do it would be helpful. I was really looking for a way to do this with an out of the box R installation since from a practical viewpoint few are going to want to build their own software. No. No. Can't help you. So? Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On 4/20/2013 1:21 PM, Duncan Murdoch wrote: On 13-04-20 2:02 PM, Kevin Coombes wrote: On 4/20/2013 12:54 PM, Duncan Murdoch wrote: It's not a change to Rtools, it's a change is to the build system in R: it allows you to rename sort or find in your own copy of Rtools, and R will use whatever you specify. You were informed of this when I did it in 2007, and I've mentioned it when the topic comes up here, most recently in the message quoted above. That's a long time ago, so I don't remember if you tried it then, but I've never heard a complaint from anyone else that it doesn't work. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel How do you do that? (More explicitly, what steps would I have to take to redefine things like find.exe and sort.exe in Rtools so that R would know how to find them and use them? I can't figure that out from the earlier parts of these messages.) Rename them to whatever you want in the Rtools install, then edit the definitions. I think currently they are in src/gnuwin32/Makefile and src/gnuwin32/MkRules (one in each), but I'd suggest you just search files named M* for the strings sort and find, in case I've got it wrong, or it has changed since the last time I looked. If you try to build R itself rather than just packages, you may need to do more edits, because some of the makefiles for things like the jpeg libraries weren't written by us, and may have these commands hard-coded. Duncan Murdoch To most Windows users, the Rtools install would seem to refer to getting the bundled Rtools30.exe from the CRAN web site, double-clicking on it, selecting the options form the GUI windows that appear, and clicking install. There is no option in this procedure to change the names of find or sort. As far as I can tell, the steps you are recommending take place in an earlier build step. This would require the user who wants to do this to rebuild Rtools in its entirety, which is more trouble than it is likely to be worth. Especially when you can avoid the problem by using your own batch script or perl script to reset the path on those relatively rare occasions when you need to use Rtools. Since buiilding Rtools for a Windows machine is something than CRAN does on a regular basis, why can't they just change the names there (and not bother the UNIX users, and probably not even bother the UNIX users who find themselves banished to the Windows wilderness). Just call them unixfind and unixsort and everyone will be able to figure it out __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
As far as I can tell, the steps you are recommending take place in an earlier build step. This would require the user who wants to do this to rebuild Rtools in its entirety, which is more trouble than it is likely to be worth. Especially when you can avoid the problem by using your own batch script or perl script to reset the path on those relatively rare occasions when you need to use Rtools. Since buiilding Rtools for a Windows machine is something than CRAN does on a regular basis, why can't they just change the names there (and not bother the UNIX users, and probably not even bother the UNIX users who find themselves banished to the Windows wilderness). Just call them unixfind and unixsort and everyone will be able to figure it out Because the point of Rtools is to make windows more like linux, rather than less? I really don't understand the complaints in this thread - I have regularly had classes of 10-20 windows users build a package with no prior experience, and simply downloading and installing Rtools. In my opinion Rtools uses the right defaults, and with a bit of extra scripting work (painful at first, but only needs to be done once, e.g. https://github.com/hadley/devtools/blob/master/R/rtools.r) it's painless to use from R. Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On Sat, Apr 20, 2013 at 9:13 PM, Hadley Wickham h.wick...@gmail.com wrote: As far as I can tell, the steps you are recommending take place in an earlier build step. This would require the user who wants to do this to rebuild Rtools in its entirety, which is more trouble than it is likely to be worth. Especially when you can avoid the problem by using your own batch script or perl script to reset the path on those relatively rare occasions when you need to use Rtools. Since buiilding Rtools for a Windows machine is something than CRAN does on a regular basis, why can't they just change the names there (and not bother the UNIX users, and probably not even bother the UNIX users who find themselves banished to the Windows wilderness). Just call them unixfind and unixsort and everyone will be able to figure it out Because the point of Rtools is to make windows more like linux, rather than less? I really don't understand the complaints in this thread - I have regularly had classes of 10-20 windows users build a package with no prior experience, and simply downloading and installing Rtools. In my opinion Rtools uses the right defaults, and with a bit of extra scripting work (painful at first, but only needs to be done once, e.g. https://github.com/hadley/devtools/blob/master/R/rtools.r) it's painless to use from R. The problem is that if you don't just use the PC for running R but use it to run other programs too then any program and that utilizes Windows batch scripts making use of find.exe or sort.exe likely won't work if Rtools is on your path. The fact that devtools, batchfiles and Rcpp have workarounds mitigates it somewhat but the problem should be fixed so it works out-of-the-box once and for all. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
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. 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: 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). 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.) 2. Build a source tarball via R CMD build $package 3. Build a Windows binary version (as a zip file) via R CMD INSTALL --build $tarball 4. Check the package via R CMD check --as-cran $tarball 5. Install the package via R CMD INSTALL $tarball Problem 3: Step 3 fails, withe the error message Running 'zip' failed. Dumb Fix to Problem 3: Install the GnbuWin32 version of zip, and make sure that its location is earlier in ter path than the version that comes with Rtools. Problem 4: Step 4 fails when running the test scripts that accompany the package. The error message is the semicryptic cannot open file 'c:\Users\krc\AppData\Local\Temp\Rtmp' Permission denied Dumb Fix to Problem 4: Write this email message and hope someone with even more patience than I have has already found a better way to get all this stuff to work. Tired of spinning my wheels, Kevin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
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. 2. Build a source tarball via R CMD build $package 3. Build a Windows binary version (as a zip file) via R CMD INSTALL --build $tarball 4. Check the package via R CMD check --as-cran $tarball 5. Install the package via R CMD INSTALL $tarball Problem 3: Step 3 fails, withe the error message Running 'zip' failed. Dumb Fix to Problem 3: Install the GnbuWin32 version of zip, and make sure that its location is earlier in ter path than the version that comes with Rtools. I have no idea about this one. Problem 4: Step 4 fails when running the test scripts that accompany the package. The error message is the semicryptic cannot open file 'c:\Users\krc\AppData\Local\Temp\Rtmp' Permission denied That's Windows permissions biting you again. Run as administrator. Duncan Murdoch Dumb Fix to Problem 4: Write this email message and hope someone with even more patience than I have has already found a better way to get all this stuff to work. Tired of spinning my wheels, Kevin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.0, Rtools3.0,l Windows7 64-bit, and permission agony
On Fri, Apr 19, 2013 at 8:47 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote: 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. Its not just find - its also sort. And really R has no business clobbering built in Windows commands. This is just wrong and really causes anyone who does any significant amount of Windows batch programming (or uses batch programs of any complexity) endless problems. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
