Re: [Rd] Rtools and MinGW
On Sun, 3 Apr 2011, Thomas Mang wrote: Hi, I have R version 2.8.1 and Rtools 28 installed (as you might guess, set up years ago). In Rtools the MinGW GCC 4.2 compiler toolset is included. For my regular C/C++ programs I have also installed, separately, the full MinGW bundle with the latest GCC 4.5 compiler tools. So I have two g++ variants on the same machine. According to the Rtools documentation, the bin directory of it shall be in the system PATH, and very early in the PATH (first elements). Presently the bin directory of the Rtools-MinGW is front. Fine but Ok for my daily C++ work I actually prefer that the regular (non-Rtools) MinGW compiler is invoked, hence I would prefer putting that in front. But then, of course, invoking g++ from R development would refer to the regular MinGW compiler toolset. When I do R development, would you expect it to cause problems if actually the regular MinGW (gcc 4.5) is invoked, and not the version that came bundled with Rtools (4.2) ? Or is this something I should better stay away from ? If not likely to work, what would you suggest to do instead ? Follow the posting guide and update your R before posting We do not support ancient versions of R, and it is very likely that R 2.8.1 does not work correctly with gcc 4.5.2: there are incompatibilities in the argument passing. thanks and best, Thomas -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rtools and MinGW
On 04.04.2011 11:04, Prof Brian Ripley wrote: On Sun, 3 Apr 2011, Thomas Mang wrote: Hi, I have R version 2.8.1 and Rtools 28 installed (as you might guess, set up years ago). In Rtools the MinGW GCC 4.2 compiler toolset is included. For my regular C/C++ programs I have also installed, separately, the full MinGW bundle with the latest GCC 4.5 compiler tools. So I have two g++ variants on the same machine. According to the Rtools documentation, the bin directory of it shall be in the system PATH, and very early in the PATH (first elements). Presently the bin directory of the Rtools-MinGW is front. Fine but Ok for my daily C++ work I actually prefer that the regular (non-Rtools) MinGW compiler is invoked, hence I would prefer putting that in front. But then, of course, invoking g++ from R development would refer to the regular MinGW compiler toolset. When I do R development, would you expect it to cause problems if actually the regular MinGW (gcc 4.5) is invoked, and not the version that came bundled with Rtools (4.2) ? Or is this something I should better stay away from ? If not likely to work, what would you suggest to do instead ? Follow the posting guide and update your R before posting We do not support ancient versions of R, and it is very likely that R 2.8.1 does not work correctly with gcc 4.5.2: there are incompatibilities in the argument passing. OK I can update but in general I think it's unlikely that the MinGW version bundled with Rtools will ever be the same as the regular MinGW version (even if just by update cycle delays). Is there any other way to tell Rtools where to search for MinGW-bin except of setting the globally applicable PATH variable ? Some configuration file or so ? thanks, Thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rtools and MinGW
On 04/04/2011 6:34 AM, Thomas Mang wrote: On 04.04.2011 11:04, Prof Brian Ripley wrote: > On Sun, 3 Apr 2011, Thomas Mang wrote: > >> Hi, >> >> I have R version 2.8.1 and Rtools 28 installed (as you might guess, >> set up years ago). In Rtools the MinGW GCC 4.2 compiler toolset is >> included. >> >> For my regular C/C++ programs I have also installed, separately, the >> full MinGW bundle with the latest GCC 4.5 compiler tools. So I have >> two g++ variants on the same machine. >> >> According to the Rtools documentation, the bin directory of it shall >> be in the system PATH, and very early in the PATH (first elements). >> Presently the bin directory of the Rtools-MinGW is front. >> Fine but Ok for my daily C++ work I actually prefer that the regular >> (non-Rtools) MinGW compiler is invoked, hence I would prefer putting >> that in front. But then, of course, invoking g++ from R development >> would refer to the regular MinGW compiler toolset. When I do R >> development, would you expect it to cause problems if actually the >> regular MinGW (gcc 4.5) is invoked, and not the version that came >> bundled with Rtools (4.2) ? Or is this something I should better stay >> away from ? >> If not likely to work, what would you suggest to do instead ? > > Follow the posting guide and update your R before posting > > We do not support ancient versions of R, and it is very likely that R > 2.8.1 does not work correctly with gcc 4.5.2: there are > incompatibilities in the argument passing. OK I can update but in general I think it's unlikely that the MinGW version bundled with Rtools will ever be the same as the regular MinGW version (even if just by update cycle delays). Is there any other way to tell Rtools where to search for MinGW-bin except of setting the globally applicable PATH variable ? Some configuration file or so ? Why not just keep two PATH variables, and put one in place before R builds, the other in place the rest of the time? Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rtools and MinGW
On Sun, Apr 3, 2011 at 3:36 PM, Thomas Mang wrote: > Hi, > > I have R version 2.8.1 and Rtools 28 installed (as you might guess, set up > years ago). In Rtools the MinGW GCC 4.2 compiler toolset is included. > > For my regular C/C++ programs I have also installed, separately, the full > MinGW bundle with the latest GCC 4.5 compiler tools. So I have two g++ > variants on the same machine. > > According to the Rtools documentation, the bin directory of it shall be in > the system PATH, and very early in the PATH (first elements). Presently the > bin directory of the Rtools-MinGW is front. > Fine but Ok for my daily C++ work I actually prefer that the regular > (non-Rtools) MinGW compiler is invoked, hence I would prefer putting that in > front. But then, of course, invoking g++ from R development would refer to > the regular MinGW compiler toolset. When I do R development, would you > expect it to cause problems if actually the regular MinGW (gcc 4.5) is > invoked, and not the version that came bundled with Rtools (4.2) ? Or is > this something I should better stay away from ? > If not likely to work, what would you suggest to do instead ? > > thanks and best, > Thomas > If you use Rcmd.bat from http://batchfiles.googlecode.com to build your packages then it will find Rtools using the registry rather than the path so if your other processing uses the path you can be using two different versions of Rtools transparently. (Alternately, in the same collection there is rtools.bat which will add the rtools bin directory to your path for the remainder of the current console session only so other console sessions can be using other versions of Rtools.) Also both of these will look for an R_TOOLS environment variable and use that instead of the registry if present so you could set that for even further customization (although from your description you won't likely need to do that). You might need to use a back version of Rcmd.bat since your version of R is pretty old but all back versions are still available. -- 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] [[.data.frame oddity
data.frame[[row,col]] unclasses its output. Is that proper?
> d <- data.frame(num=1:4,
fac=factor(letters[11:14],levels=letters[1:15]),
date=as.Date("2011-04-01") + (0:3),
lt=as.POSIXlt("2011-04-01") + (0:3)*1e5,
pv=package_version(c("1.2-3", "4.5","6.7", "8.9-10")))
> d
num fac date lt pv
1 1 k 2011-04-01 2011-04-01 00:00:00 1.2.3
2 2 l 2011-04-02 2011-04-02 03:46:404.5
3 3 m 2011-04-03 2011-04-03 07:33:206.7
4 4 n 2011-04-04 2011-04-04 11:20:00 8.9.10
> str(d)
'data.frame': 4 obs. of 5 variables:
$ num : int 1 2 3 4
$ fac : Factor w/ 15 levels "a","b","c","d",..: 11 12 13 14
$ date:Class 'Date' num [1:4] 15065 15066 15067 15068
$ lt : POSIXct, format: "2011-04-01 00:00:00" "2011-04-02 03:46:40"
...
$ pv :List of 4
..$ :Classes 'package_version', 'numeric_version' hidden list of 1
.. ..$ : int 1 2 3
..$ :Classes 'package_version', 'numeric_version' hidden list of 1
.. ..$ : int 4 5
..$ :Classes 'package_version', 'numeric_version' hidden list of 1
.. ..$ : int 6 7
..$ :Classes 'package_version', 'numeric_version' hidden list of 1
.. ..$ : int 8 9 10
..- attr(*, "class")= chr "package_version" "numeric_version"
> d[[1,1]]
[1] 1
> d[[1,2]] # d[1,2] gives factor("k",levels=letters[1:15])
[1] 11
> d[[1,3]] # d[1,3] gives as.Date("2011-04-01")
[1] 15065
> d[[1,4]] # d[1,4] gives as.POSIXct("2011-04-01")
[1] 1301641200
> d[[1,5]] # d[1,5] gives package_version("1.2.3")
[1] 1 2 3
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Use keep.source for function in package with lazy loading
I have a function in one of my packages that I would like to print using the original source rather than the deparse of the function. The package uses lazy loading and the help page for library (under keep.source) says that keep.source does not apply to packages that use lazy loading and that whether those functions keep the source depends on when they are installed. This package is on R-forge and is being built there (and will eventually be used to submit the next version of the package to CRAN). I am not sure what the help means by 'installed', I have set the options to keep the source to TRUE before calling install.package, but that does not seem to work. Is there a way to "strongly encourage" the source to be kept for this function (or the entire package)? Thanks, -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare greg.s...@imail.org 801.408.8111 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Use keep.source for function in package with lazy loading
On Mon, 4 Apr 2011, Greg Snow wrote: I have a function in one of my packages that I would like to print using the original source rather than the deparse of the function. The package uses lazy loading and the help page for library (under keep.source) says that keep.source does not apply to packages that use lazy loading and that whether those functions keep the source depends on when they are installed. Not quite: it is says it is 'determined when it is installed'. For a package that does not use lazy loading, what is installed is a file of R code. When library() loads such a package, it sources() the R code, and at that point has the option to keep the source or not (for that R session). For a package which uses lazy loading, the source()ing happens when the package is installed: the objects created are then dumped into a database. Whether the source attribute is retained at that point depends on the setting of the option "keep.source.pkgs". So if you can arrange to install the package with that option set to true, in principle (and in my experiments) the source attributes are retained. The easiest way to do this would seem to be to set the environment variable R_KEEP_PKG_SOURCE to "yes" whilst installing the package. This package is on R-forge and is being built there (and will eventually be used to submit the next version of the package to CRAN). I am not sure what the help means by 'installed', I have set the options to keep the source to TRUE before calling install.package, but that does not seem to work. I presume you mean keep.source.pkgs, not keep.source? That needs to be set in the process which is installing the package: install.packages() calls R CMD INSTALL in a separate process. Is there a way to "strongly encourage" the source to be kept for this function (or the entire package)? Thanks, -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare greg.s...@imail.org 801.408.8111 -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
