Re: [Rd] R CMD check --force-multiarch does not install all the archs for testing
On 28.06.2011 01:31, Hervé Pagès wrote:
Hi,
Why isn't 'R CMD check --force-multiarch' installing the package
for all the architectures that are going to be checked?
Hervé,
no, since it cannot know that that you need
--merge-multiarch
as an additional install flag for this particular package.
You will have to check it in repository maintainer's mode (as the CRAN
maintainers do everywhere). Essentially this is for me (when also
producing WIndows binaries):
Step 1: Installation
R CMD INSTALL --pkglock --compact-docs --build --merge-multiarch
--library="D:/path/to/library" fabia_1.5.0.tar.gz > fabia-install.out 2>&1
(where the merge-multiarch part applies only to this package, of course)
Step 2: Check (without installation, since that happened before already,
using the install log from step 1)
R CMD check --library="D:/path/to/library" --force-multiarch
--install="check:fabia-install.out" fabia
Best wishes,
Uwe
For some packages, it only installs for the default arch ('i386').
Then testing the package for 'x64' fails.
For example,
Output of R CMD check --force-multiarch fabia_1.5.0.tar.gz:
---
* using log directory 'D:/biocbld/bbs-2.9-bioc/meat/fabia.Rcheck'
* using R version 2.14.0 Under development (unstable) (2011-05-30 r56020)
* using platform: i386-pc-mingw32 (32-bit)
* using session charset: ISO8859-1
* using option '--no-vignettes'
* checking for file 'fabia/DESCRIPTION' ... OK
* this is package 'fabia' version '1.5.0'
* checking package name space information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking whether package 'fabia' can be installed ... OK
* checking installed package size ... OK
* checking package directory ... OK
* checking for portable file names ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* loading checks for arch 'i386'
** checking whether the package can be loaded ... OK
** checking whether the package can be loaded with stated dependencies
... OK
** checking whether the package can be unloaded cleanly ... OK
** checking whether the name space can be loaded with stated
dependencies ... OK
** checking whether the name space can be unloaded cleanly ... OK
* loading checks for arch 'x64'
** checking whether the package can be loaded ...Warning: running
command '"D:/biocbld/bbs-2.9-bioc/R/bin/x64/Rterm.exe"
R_ENVIRON_USER='no_such_file' --no-site-file --no-init-file --no-save
--no-restore --slave -f
D:\biocbld\bbs-2.9-bioc\tmpdir\RtmpO65p5H\Rin57456988' had status 1
ERROR
Error: package 'fabia' is not installed for 'arch=x64'
Execution halted
It looks like this package has a loading problem: see the messages for
details.
Content of fabia.Rcheck\00install.out:
--
* installing *source* package 'fabia' ...
Building libRcpp.a in RcppSrc...
rm -f Rcpp.o libRcpp.a
g++ -c Rcpp.cpp -o Rcpp.o -I"D:/biocbld/BBS-2˜1.9-B/R/include"
-I"D:/biocbld/BBS-2˜1.9-B/R/src/include" -Wall -O2
ar r libRcpp.a Rcpp.o
C:\Rtools213\MinGW\bin\ar.exe: creating libRcpp.a
ranlib libRcpp.a
rm -f Rcpp.o
rm -f Rcpp.o
** libs
running src/Makefile.win ...
rm -f fabia.o fabia.dll *.a *.o *.so *.dll
g++ -c fabiac.cpp -o fabia.o -I../RcppSrc
-I"D:/biocbld/BBS-2˜1.9-B/R/include" -Wall -O2
g++ -shared -s -static-libgcc fabia.o -L../RcppSrc -lRcpp
-L"D:/biocbld/BBS-2˜1.9-B/R/bin/i386" -lR -o fabia.dll
rm -f fabia.o *.a *.o *.so
installing to D:/biocbld/bbs-2.9-bioc/meat/fabia.Rcheck/fabia/libs/i386
** R
** demo
** inst
** preparing package for lazy loading
Creating a generic function for "plot" from package "graphics" in
package "fabia"
** help
*** installing help indices
** building package indices ...
*** tangling vignette sources ...
'fabia.Rnw'
** testing if installed package can be loaded
* DONE (fabia)
The source tarball for this package is available here:
http://bioconductor.org/packages/2.9/bioc/html/fabia.html
What command should be used to perform a multiarch check of this
package?
This is on a 64-bit Windows Server 2008 R2 Enterprise machine using a
recent combined Windows 32/64 bit binary of R-devel from CRAN.
Thanks!
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD check --configure-args?
R CMD INSTALL takes a --configure-args argument, but I cannot see how to pass the same values in R CMD check, which returns a: Warning: unknown option ‘--configure-args=... (R 2.13.0). What am I missing? Roger -- Roger Bivand Department of Economics, NHH Norwegian School of Economics, Helleveien 30, N-5045 Bergen, Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43 e-mail: roger.biv...@nhh.no __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] doMC - compiler - concatenate an expression vector into a single expression?
Hi,
this post is about foreach operators, the compiler package and the last
update of doMC that includes support for the compiler functionality.
I am using a home-made %dopar%-like operator that adds some custom
expression to be executed before the foreach loop expression itself (see
sample code below).
It used to work perfectly with doMC 1.2.1, but with the introduction of
the compiler functionality, things do not work properly.
The change in the doMC package consists in evaluating a compiled
expression instead of the original R expression:
# from doMC:::doMC ...
c.expr <- comp(expr, env = envir, options = list(suppressUndefined = TRUE))
and for R >= 2.13.0 comp is defined as compiler::compile:
function (e, env = .GlobalEnv, options = NULL)
{
cenv <- makeCenv(env)
cntxt <- make.toplevelContext(cenv, options)
cntxt$env <- addCenvVars(cenv, findLocals(e, cntxt))
genCode(e, cntxt)
}
My guess is that the function findLocals or genCode can not handle a
2-length expression vector.
Maybe somebody who knows the internals of these functions could explain
better this behaviour?
How can I concatenate two expressions into a single one?
Thank you,
Renaud
##
# Sample code
##
`%dopar2%` <- function(obj, ex){
# append custom code to the expression
ex <- c(expression({ a <- i; message("Custom ", a);}), substitute(ex))
# call the standard %dopar% operator
do.call(`%dopar%`, list(obj, ex), envir=parent.frame() )
}
res <- foreach(i=1:3) %dopar2% { print(i); i*2; }
res
#
# Output with doSEQ or doMC 1.2.1
#
Custom 1
[1] 1
Custom 2
[1] 2
Custom 3
[1] 3
> res
[[1]]
[1] 2
[[2]]
[1] 4
[[3]]
[1] 6
#
# Output with doMC 1.2.2
#
[[1]]
expression({
a <- i
message("Custom ", a)
}, {
print(i)
i * 2
})
[[2]]
expression({
a <- i
message("Custom ", a)
}, {
print(i)
i * 2
})
[[3]]
expression({
a <- i
message("Custom ", a)
}, {
print(i)
i * 2
})
--
Renaud Gaujoux
Computational Biology - University of Cape Town
South Africa
###
UNIVERSITY OF CAPE TOWN
This e-mail is subject to the UCT ICT policies and e-mai...{{dropped:5}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check --configure-args?
On 28.06.2011 11:35, Roger Bivand wrote: R CMD INSTALL takes a --configure-args argument, but I cannot see how to pass the same values in R CMD check, which returns a: Warning: unknown option ‘--configure-args=... (R 2.13.0). What am I missing? Untested: Can't you pass it via --install-args= ? Uwe Roger __ 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 CMD check --configure-args?
On Tue, 28 Jun 2011, Uwe Ligges wrote: On 28.06.2011 11:35, Roger Bivand wrote: R CMD INSTALL takes a --configure-args argument, but I cannot see how to pass the same values in R CMD check, which returns a: Warning: unknown option ‘--configure-args=... (R 2.13.0). What am I missing? Untested: Can't you pass it via --install-args= ? Yes, I see it now, thanks very much! Roger Uwe Roger __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Roger Bivand Department of Economics, NHH Norwegian School of Economics, Helleveien 30, N-5045 Bergen, Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43 e-mail: roger.biv...@nhh.no __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Download R package on HP-UX ia64 Server
Hi, I am new to R, is there R package for HP-UX ia64 server? In another word, is it possible to compile R from source on HP-UX ia64 system? Any advice would be greatly appreciated! Thanks, Hong Hong Zhou, MS, MIS Senior Systems Analyst Center for Outcomes Research The Children's Hospital of Philadelphia 3535 Market St. Suite 1029 Philadelphia, PA 10104 Tel: (215) 590 5444 Fax: (215) 590 2378 Email: z...@email.chop.edu [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] (no subject)
Hi, I am trying to write code in C for an R package. I need high precision in the form of the mpfr and gmp packages. I have installed mpfr and gmp under the instructions of the following website http://pauillac.inria.fr/cdrom_a_graver/prog/pc/mpfr/eng.htm and I get no errors. I have put the header files (mpfr.h and gmp.h) in the folder C:\Program Files\R\R-2.13.0\include; allowing my c code to identify the header files by incorporating include and include. Unfortunately when I try to include any of the functions listed in the header file I get compile error stating that these functions are undeclared, even though the source code is in the same directory as my c code that I am trying to compile. Any help on this matter would be greatly appreciated. Kind Regards, Michelle Carey [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] doMC - compiler - concatenate an expression vector into a single expression?
Dear Renaud,
Thank you for the report. I see that Steve Weston has responded to your
cross-posting on r-sig-hpc; I hope this helps with your immediate problem.
We will investigate whether changes to doMC are warranted.
Regards,
Rich Calaway
On Tue, Jun 28, 2011 at 2:58 AM, Renaud Gaujoux wrote:
> Hi,
>
> this post is about foreach operators, the compiler package and the last
> update of doMC that includes support for the compiler functionality.
>
> I am using a home-made %dopar%-like operator that adds some custom
> expression to be executed before the foreach loop expression itself (see
> sample code below).
> It used to work perfectly with doMC 1.2.1, but with the introduction of the
> compiler functionality, things do not work properly.
> The change in the doMC package consists in evaluating a compiled expression
> instead of the original R expression:
>
> # from doMC:::doMC ...
> c.expr <- comp(expr, env = envir, options = list(suppressUndefined = TRUE))
>
> and for R >= 2.13.0 comp is defined as compiler::compile:
> function (e, env = .GlobalEnv, options = NULL)
> {
>cenv <- makeCenv(env)
>cntxt <- make.toplevelContext(cenv, options)
>cntxt$env <- addCenvVars(cenv, findLocals(e, cntxt))
>genCode(e, cntxt)
> }
>
>
> My guess is that the function findLocals or genCode can not handle a
> 2-length expression vector.
>
> Maybe somebody who knows the internals of these functions could explain
> better this behaviour?
> How can I concatenate two expressions into a single one?
>
> Thank you,
> Renaud
>
>
> ##**
> # Sample code
> ##**
>
> `%dopar2%` <- function(obj, ex){
>
># append custom code to the expression
>ex <- c(expression({ a <- i; message("Custom ", a);}), substitute(ex))
>
># call the standard %dopar% operator
>do.call(`%dopar%`, list(obj, ex), envir=parent.frame() )
> }
> res <- foreach(i=1:3) %dopar2% { print(i); i*2; }
> res
>
>
> #
> # Output with doSEQ or doMC 1.2.1
> #
> Custom 1
> [1] 1
> Custom 2
> [1] 2
> Custom 3
> [1] 3
> > res
> [[1]]
> [1] 2
>
> [[2]]
> [1] 4
>
> [[3]]
> [1] 6
>
>
> #
> # Output with doMC 1.2.2
> #
>
> [[1]]
> expression({
>a <- i
>message("Custom ", a)
> }, {
>print(i)
>i * 2
> })
>
> [[2]]
> expression({
>a <- i
>message("Custom ", a)
> }, {
>print(i)
>i * 2
> })
>
> [[3]]
> expression({
>a <- i
>message("Custom ", a)
> }, {
>print(i)
>i * 2
> })
>
>
>
> --
> Renaud Gaujoux
> Computational Biology - University of Cape Town
> South Africa
>
>
>
>
> ###
> UNIVERSITY OF CAPE TOWN
> This e-mail is subject to the UCT ICT policies and e-mail disclaimer
> published on our website at http://www.uct.ac.za/about/**
> policies/emaildisclaimer/
Re: [Rd] (no subject)
On Jun 28, 2011, at 9:58 AM, Michelle.Carey wrote: > Hi, > > > > I am trying to write code in C for an R package. I need high precision > in the form of the mpfr and gmp packages. gmp is available as R package http://cran.r-project.org/web/packages/gmp/index.html do you really need it at a lower level than that? > I have installed mpfr and gmp > under the instructions of the following website > http://pauillac.inria.fr/cdrom_a_graver/prog/pc/mpfr/eng.htm and I get > no errors. I have put the header files (mpfr.h and gmp.h) in the folder > C:\Program Files\R\R-2.13.0\include; That doesn't sound right - the instructions you quote install in the default location which is presumably /usr/local so you should simply set your flags to use that location. > allowing my c code to identify the > header files by incorporating include and include. > Unfortunately when I try to include any of the functions listed in the > header file I get compile error stating that these functions are > undeclared, That doesn't sound plausible, either - undeclared function don't cause errors (not in C). Undefined functions do and you have to make sure you link the libraries installed above. > even though the source code is in the same directory as my c > code that I am trying to compile. That bears no meaning - as you said you installed the libraries, so you have to use those. Source code of gmp/mpfr has no effect on your code and should not be anywhere near it. Cheers, Simon > Any help on this matter would be > greatly appreciated. > > > > Kind Regards, > > Michelle Carey > > > > > [[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 CMD check --force-multiarch does not install all the archs for testing
Hi Uwe,
On 11-06-28 01:44 AM, Uwe Ligges wrote:
On 28.06.2011 01:31, Hervé Pagès wrote:
Hi,
Why isn't 'R CMD check --force-multiarch' installing the package
for all the architectures that are going to be checked?
Hervé,
no, since it cannot know that that you need
--merge-multiarch
as an additional install flag for this particular package.
Why not just use this flag anyway? Does it hurt to use it on packages
that don't strictly need it?
You will have to check it in repository maintainer's mode (as the CRAN
maintainers do everywhere). Essentially this is for me (when also
producing WIndows binaries):
Step 1: Installation
R CMD INSTALL --pkglock --compact-docs --build --merge-multiarch
--library="D:/path/to/library" fabia_1.5.0.tar.gz > fabia-install.out 2>&1
(where the merge-multiarch part applies only to this package, of course)
Step 2: Check (without installation, since that happened before already,
using the install log from step 1)
R CMD check --library="D:/path/to/library" --force-multiarch
--install="check:fabia-install.out" fabia
Wha! Would be nice if there was a plan to make 'R CMD check' also
usable by normal people (including the package developer), not just
by a few privileged people that know about those undocumented tricks.
Thanks,
H.
Best wishes,
Uwe
For some packages, it only installs for the default arch ('i386').
Then testing the package for 'x64' fails.
For example,
Output of R CMD check --force-multiarch fabia_1.5.0.tar.gz:
---
* using log directory 'D:/biocbld/bbs-2.9-bioc/meat/fabia.Rcheck'
* using R version 2.14.0 Under development (unstable) (2011-05-30 r56020)
* using platform: i386-pc-mingw32 (32-bit)
* using session charset: ISO8859-1
* using option '--no-vignettes'
* checking for file 'fabia/DESCRIPTION' ... OK
* this is package 'fabia' version '1.5.0'
* checking package name space information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking whether package 'fabia' can be installed ... OK
* checking installed package size ... OK
* checking package directory ... OK
* checking for portable file names ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* loading checks for arch 'i386'
** checking whether the package can be loaded ... OK
** checking whether the package can be loaded with stated dependencies
... OK
** checking whether the package can be unloaded cleanly ... OK
** checking whether the name space can be loaded with stated
dependencies ... OK
** checking whether the name space can be unloaded cleanly ... OK
* loading checks for arch 'x64'
** checking whether the package can be loaded ...Warning: running
command '"D:/biocbld/bbs-2.9-bioc/R/bin/x64/Rterm.exe"
R_ENVIRON_USER='no_such_file' --no-site-file --no-init-file --no-save
--no-restore --slave -f
D:\biocbld\bbs-2.9-bioc\tmpdir\RtmpO65p5H\Rin57456988' had status 1
ERROR
Error: package 'fabia' is not installed for 'arch=x64'
Execution halted
It looks like this package has a loading problem: see the messages for
details.
Content of fabia.Rcheck\00install.out:
--
* installing *source* package 'fabia' ...
Building libRcpp.a in RcppSrc...
rm -f Rcpp.o libRcpp.a
g++ -c Rcpp.cpp -o Rcpp.o -I"D:/biocbld/BBS-2˜1.9-B/R/include"
-I"D:/biocbld/BBS-2˜1.9-B/R/src/include" -Wall -O2
ar r libRcpp.a Rcpp.o
C:\Rtools213\MinGW\bin\ar.exe: creating libRcpp.a
ranlib libRcpp.a
rm -f Rcpp.o
rm -f Rcpp.o
** libs
running src/Makefile.win ...
rm -f fabia.o fabia.dll *.a *.o *.so *.dll
g++ -c fabiac.cpp -o fabia.o -I../RcppSrc
-I"D:/biocbld/BBS-2˜1.9-B/R/include" -Wall -O2
g++ -shared -s -static-libgcc fabia.o -L../RcppSrc -lRcpp
-L"D:/biocbld/BBS-2˜1.9-B/R/bin/i386" -lR -o fabia.dll
rm -f fabia.o *.a *.o *.so
installing to D:/biocbld/bbs-2.9-bioc/meat/fabia.Rcheck/fabia/libs/i386
** R
** demo
** inst
** preparing package for lazy loading
Creating a generic function for "plot" from package "graphics" in
package "fabia"
** help
*** installing help indices
** building package indices ...
*** tangling vignette sources ...
'fabia.Rnw'
** testing if installed package can be loaded
* DONE (fabia)
The source tarball for this package is available here:
http://bioconductor.org/packages/2.9/bioc/html/fabia.html
What command should be used to perform a multiarch check of this
package?
This is on a 64-bit Windows Server 2008 R2 Enterprise machine using a
recent combined Windows 32/64 bit binary of R-devel from CRAN.
Thanks!
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 6
[Rd] Small bug in install.packages?
When capturing the path to the current R binary, install.packages does:
cmd0 <- paste(file.path(R.home("bin"), "R"), "CMD INSTALL")
shouldn't that be
cmd0 <- shQuote(paste(file.path(R.home("bin"), "R"), "CMD INSTALL"))
to allow paths with spaces in them (which would be very common on windows)?
Hadley
--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check --force-multiarch does not install all the archs for testing
On Jun 28, 2011, at 3:01 PM, Hervé Pagès wrote:
> Hi Uwe,
>
> On 11-06-28 01:44 AM, Uwe Ligges wrote:
>>
>>
>> On 28.06.2011 01:31, Hervé Pagès wrote:
>>> Hi,
>>>
>>> Why isn't 'R CMD check --force-multiarch' installing the package
>>> for all the architectures that are going to be checked?
>>
>> Hervé,
>>
>> no, since it cannot know that that you need
>>
>> --merge-multiarch
>>
>> as an additional install flag for this particular package.
>
> Why not just use this flag anyway? Does it hurt to use it on packages that
> don't strictly need it?
>
It does for two reasons: a) everything is built twice and b) package authors
don't expect the necessity to support --libs-only if the package doesn't
require separate build runs.
The cross-platform way is to not use --merge-multiarch but use --libs-only
instead as needed (easy to check after the first arch run which will tell you
whether it's needed or not). I suspect that --merge-multiarch is just a
convenience shortcut (and it's unclear to me why it's Windows-only...).
Cheers,
Simon
>> You will have to check it in repository maintainer's mode (as the CRAN
>> maintainers do everywhere). Essentially this is for me (when also
>> producing WIndows binaries):
>>
>>
>> Step 1: Installation
>>
>> R CMD INSTALL --pkglock --compact-docs --build --merge-multiarch
>> --library="D:/path/to/library" fabia_1.5.0.tar.gz > fabia-install.out 2>&1
>>
>> (where the merge-multiarch part applies only to this package, of course)
>>
>>
>>
>> Step 2: Check (without installation, since that happened before already,
>> using the install log from step 1)
>>
>> R CMD check --library="D:/path/to/library" --force-multiarch
>> --install="check:fabia-install.out" fabia
>
> Wha! Would be nice if there was a plan to make 'R CMD check' also
> usable by normal people (including the package developer), not just
> by a few privileged people that know about those undocumented tricks.
>
> Thanks,
> H.
>
>>
>> Best wishes,
>> Uwe
>>
>>
>>
>>
>>
>>
>>
>>
>>> For some packages, it only installs for the default arch ('i386').
>>> Then testing the package for 'x64' fails.
>>>
>>> For example,
>>>
>>> Output of R CMD check --force-multiarch fabia_1.5.0.tar.gz:
>>> ---
>>> * using log directory 'D:/biocbld/bbs-2.9-bioc/meat/fabia.Rcheck'
>>> * using R version 2.14.0 Under development (unstable) (2011-05-30 r56020)
>>> * using platform: i386-pc-mingw32 (32-bit)
>>> * using session charset: ISO8859-1
>>> * using option '--no-vignettes'
>>> * checking for file 'fabia/DESCRIPTION' ... OK
>>> * this is package 'fabia' version '1.5.0'
>>> * checking package name space information ... OK
>>> * checking package dependencies ... OK
>>> * checking if this is a source package ... OK
>>> * checking whether package 'fabia' can be installed ... OK
>>> * checking installed package size ... OK
>>> * checking package directory ... OK
>>> * checking for portable file names ... OK
>>> * checking DESCRIPTION meta-information ... OK
>>> * checking top-level files ... OK
>>> * checking index information ... OK
>>> * checking package subdirectories ... OK
>>> * checking R files for non-ASCII characters ... OK
>>> * checking R files for syntax errors ... OK
>>> * loading checks for arch 'i386'
>>> ** checking whether the package can be loaded ... OK
>>> ** checking whether the package can be loaded with stated dependencies
>>> ... OK
>>> ** checking whether the package can be unloaded cleanly ... OK
>>> ** checking whether the name space can be loaded with stated
>>> dependencies ... OK
>>> ** checking whether the name space can be unloaded cleanly ... OK
>>> * loading checks for arch 'x64'
>>> ** checking whether the package can be loaded ...Warning: running
>>> command '"D:/biocbld/bbs-2.9-bioc/R/bin/x64/Rterm.exe"
>>> R_ENVIRON_USER='no_such_file' --no-site-file --no-init-file --no-save
>>> --no-restore --slave -f
>>> D:\biocbld\bbs-2.9-bioc\tmpdir\RtmpO65p5H\Rin57456988' had status 1
>>> ERROR
>>> Error: package 'fabia' is not installed for 'arch=x64'
>>> Execution halted
>>>
>>> It looks like this package has a loading problem: see the messages for
>>> details.
>>>
>>> Content of fabia.Rcheck\00install.out:
>>> --
>>>
>>> * installing *source* package 'fabia' ...
>>> Building libRcpp.a in RcppSrc...
>>> rm -f Rcpp.o libRcpp.a
>>> g++ -c Rcpp.cpp -o Rcpp.o -I"D:/biocbld/BBS-2˜1.9-B/R/include"
>>> -I"D:/biocbld/BBS-2˜1.9-B/R/src/include" -Wall -O2
>>> ar r libRcpp.a Rcpp.o
>>> C:\Rtools213\MinGW\bin\ar.exe: creating libRcpp.a
>>> ranlib libRcpp.a
>>> rm -f Rcpp.o
>>> rm -f Rcpp.o
>>> ** libs
>>> running src/Makefile.win ...
>>> rm -f fabia.o fabia.dll *.a *.o *.so *.dll
>>> g++ -c fabiac.cpp -o fabia.o -I../RcppSrc
>>> -I"D:/biocbld/BBS-2˜1.9-B/R/include" -Wall -O2
>>> g++ -shared -s -static-libgcc fabia.o -L../RcppSrc -lRcpp
>>> -L"D:/biocbld/BBS-2˜1.9-B/R/bin/i386" -lR -o fabia.dll
>>> r
Re: [Rd] Small bug in install.packages?
On Jun 28, 2011, at 3:03 PM, Hadley Wickham wrote:
> When capturing the path to the current R binary, install.packages does:
>
> cmd0 <- paste(file.path(R.home("bin"), "R"), "CMD INSTALL")
>
> shouldn't that be
>
> cmd0 <- shQuote(paste(file.path(R.home("bin"), "R"), "CMD INSTALL"))
>
> to allow paths with spaces in them (which would be very common on windows)?
>
Isn't R.home() 8.3 path anyway?
BTW: I think you probably meant more something like
paste(shQuote(file.path(R.home("bin"), "R")), "CMD INSTALL") since the above
won't work ..
Cheers,
S
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check --force-multiarch does not install all the archs for testing
Hi Simon,
On 11-06-28 12:19 PM, Simon Urbanek wrote:
On Jun 28, 2011, at 3:01 PM, Hervé Pagès wrote:
Hi Uwe,
On 11-06-28 01:44 AM, Uwe Ligges wrote:
On 28.06.2011 01:31, Hervé Pagès wrote:
Hi,
Why isn't 'R CMD check --force-multiarch' installing the package
for all the architectures that are going to be checked?
Hervé,
no, since it cannot know that that you need
--merge-multiarch
as an additional install flag for this particular package.
Why not just use this flag anyway? Does it hurt to use it on packages that
don't strictly need it?
It does for two reasons: a) everything is built twice
That's exactly what I want when I do 'R CMD check --force-multiarch'
and b) package authors don't expect the necessity to support --libs-only if the
package doesn't require separate build runs.
When specifying --force-multiarch, the user really expects the package
to be installed for all sub-archs.
The cross-platform way is to not use --merge-multiarch but use --libs-only
instead as needed (easy to check after the first arch run which will tell you
whether it's needed or not). I suspect that --merge-multiarch is just a
convenience shortcut (and it's unclear to me why it's Windows-only...).
A great convenience indeed as it allows to do the multiarch install in
a single step. And it's unclear to me too why it's Windows-only but I
would have hoped you would know...
Thanks,
H.
Cheers,
Simon
You will have to check it in repository maintainer's mode (as the CRAN
maintainers do everywhere). Essentially this is for me (when also
producing WIndows binaries):
Step 1: Installation
R CMD INSTALL --pkglock --compact-docs --build --merge-multiarch
--library="D:/path/to/library" fabia_1.5.0.tar.gz> fabia-install.out 2>&1
(where the merge-multiarch part applies only to this package, of course)
Step 2: Check (without installation, since that happened before already,
using the install log from step 1)
R CMD check --library="D:/path/to/library" --force-multiarch
--install="check:fabia-install.out" fabia
Wha! Would be nice if there was a plan to make 'R CMD check' also
usable by normal people (including the package developer), not just
by a few privileged people that know about those undocumented tricks.
Thanks,
H.
Best wishes,
Uwe
For some packages, it only installs for the default arch ('i386').
Then testing the package for 'x64' fails.
For example,
Output of R CMD check --force-multiarch fabia_1.5.0.tar.gz:
---
* using log directory 'D:/biocbld/bbs-2.9-bioc/meat/fabia.Rcheck'
* using R version 2.14.0 Under development (unstable) (2011-05-30 r56020)
* using platform: i386-pc-mingw32 (32-bit)
* using session charset: ISO8859-1
* using option '--no-vignettes'
* checking for file 'fabia/DESCRIPTION' ... OK
* this is package 'fabia' version '1.5.0'
* checking package name space information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking whether package 'fabia' can be installed ... OK
* checking installed package size ... OK
* checking package directory ... OK
* checking for portable file names ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* loading checks for arch 'i386'
** checking whether the package can be loaded ... OK
** checking whether the package can be loaded with stated dependencies
... OK
** checking whether the package can be unloaded cleanly ... OK
** checking whether the name space can be loaded with stated
dependencies ... OK
** checking whether the name space can be unloaded cleanly ... OK
* loading checks for arch 'x64'
** checking whether the package can be loaded ...Warning: running
command '"D:/biocbld/bbs-2.9-bioc/R/bin/x64/Rterm.exe"
R_ENVIRON_USER='no_such_file' --no-site-file --no-init-file --no-save
--no-restore --slave -f
D:\biocbld\bbs-2.9-bioc\tmpdir\RtmpO65p5H\Rin57456988' had status 1
ERROR
Error: package 'fabia' is not installed for 'arch=x64'
Execution halted
It looks like this package has a loading problem: see the messages for
details.
Content of fabia.Rcheck\00install.out:
--
* installing *source* package 'fabia' ...
Building libRcpp.a in RcppSrc...
rm -f Rcpp.o libRcpp.a
g++ -c Rcpp.cpp -o Rcpp.o -I"D:/biocbld/BBS-2˜1.9-B/R/include"
-I"D:/biocbld/BBS-2˜1.9-B/R/src/include" -Wall -O2
ar r libRcpp.a Rcpp.o
C:\Rtools213\MinGW\bin\ar.exe: creating libRcpp.a
ranlib libRcpp.a
rm -f Rcpp.o
rm -f Rcpp.o
** libs
running src/Makefile.win ...
rm -f fabia.o fabia.dll *.a *.o *.so *.dll
g++ -c fabiac.cpp -o fabia.o -I../RcppSrc
-I"D:/biocbld/BBS-2˜1.9-B/R/include" -Wall -O2
g++ -shared -s -static-libgcc fabia.o -L../RcppSrc -lRcpp
-L"D:/biocbld/BBS-2˜1.9-B/R/bin/i386" -lR -o fabia.dll
rm -f
Re: [Rd] R CMD check --force-multiarch does not install all the archs for testing
On Jun 28, 2011, at 3:45 PM, Hervé Pagès wrote:
> Hi Simon,
>
> On 11-06-28 12:19 PM, Simon Urbanek wrote:
>>
>> On Jun 28, 2011, at 3:01 PM, Hervé Pagès wrote:
>>
>>> Hi Uwe,
>>>
>>> On 11-06-28 01:44 AM, Uwe Ligges wrote:
On 28.06.2011 01:31, Hervé Pagès wrote:
> Hi,
>
> Why isn't 'R CMD check --force-multiarch' installing the package
> for all the architectures that are going to be checked?
Hervé,
no, since it cannot know that that you need
--merge-multiarch
as an additional install flag for this particular package.
>>>
>>> Why not just use this flag anyway? Does it hurt to use it on packages that
>>> don't strictly need it?
>>>
>>
>> It does for two reasons: a) everything is built twice
>
> That's exactly what I want when I do 'R CMD check --force-multiarch'
>
No, that's not what it does (and I assume you mean --force-biarch). It builds
the package just once, you're simply overriding the default behavior of
checking for configure.win, that's all. The two flags are orthogonal,
--force-biarch makes no sense with --merge-multiarch, they are for all
practical purposes mutually exclusive by definition of what they do.
>> and b) package authors don't expect the necessity to support --libs-only if
>> the package doesn't require separate build runs.
>
> When specifying --force-multiarch, the user really expects the package to be
> installed for all sub-archs.
>
... with the assumption that the package supports it even though it has a
configure script which may to may not work unlike --merge-multiarch which will
always work. --force-biarch is just a way to flag packages that have
configure.win that has no effect on the binary settings (flags etc.). It forces
R to try multi-arch build in one flight, but it may or may not work depending
on the package. It is a way to save time by not running --merge-multiarch (and
thus building the package twice).
Cheers,
Simon
>>
>> The cross-platform way is to not use --merge-multiarch but use --libs-only
>> instead as needed (easy to check after the first arch run which will tell
>> you whether it's needed or not). I suspect that --merge-multiarch is just a
>> convenience shortcut (and it's unclear to me why it's Windows-only...).
>
> A great convenience indeed as it allows to do the multiarch install in
> a single step. And it's unclear to me too why it's Windows-only but I
> would have hoped you would know...
>
> Thanks,
> H.
>
>
>>
>> Cheers,
>> Simon
>>
>>
You will have to check it in repository maintainer's mode (as the CRAN
maintainers do everywhere). Essentially this is for me (when also
producing WIndows binaries):
Step 1: Installation
R CMD INSTALL --pkglock --compact-docs --build --merge-multiarch
--library="D:/path/to/library" fabia_1.5.0.tar.gz> fabia-install.out 2>&1
(where the merge-multiarch part applies only to this package, of course)
Step 2: Check (without installation, since that happened before already,
using the install log from step 1)
R CMD check --library="D:/path/to/library" --force-multiarch
--install="check:fabia-install.out" fabia
>>>
>>> Wha! Would be nice if there was a plan to make 'R CMD check' also
>>> usable by normal people (including the package developer), not just
>>> by a few privileged people that know about those undocumented tricks.
>>>
>>> Thanks,
>>> H.
>>>
Best wishes,
Uwe
> For some packages, it only installs for the default arch ('i386').
> Then testing the package for 'x64' fails.
>
> For example,
>
> Output of R CMD check --force-multiarch fabia_1.5.0.tar.gz:
> ---
> * using log directory 'D:/biocbld/bbs-2.9-bioc/meat/fabia.Rcheck'
> * using R version 2.14.0 Under development (unstable) (2011-05-30 r56020)
> * using platform: i386-pc-mingw32 (32-bit)
> * using session charset: ISO8859-1
> * using option '--no-vignettes'
> * checking for file 'fabia/DESCRIPTION' ... OK
> * this is package 'fabia' version '1.5.0'
> * checking package name space information ... OK
> * checking package dependencies ... OK
> * checking if this is a source package ... OK
> * checking whether package 'fabia' can be installed ... OK
> * checking installed package size ... OK
> * checking package directory ... OK
> * checking for portable file names ... OK
> * checking DESCRIPTION meta-information ... OK
> * checking top-level files ... OK
> * checking index information ... OK
> * checking package subdirectories ... OK
> * checking R files for non-ASCII characters ... OK
> * checking R files for syntax errors ... OK
> * loading checks for arch 'i386'
> ** checking whether the package can be l
Re: [Rd] R CMD check --force-multiarch does not install all the archs for testing
Simon,
On 11-06-28 01:44 PM, Simon Urbanek wrote:
On Jun 28, 2011, at 3:45 PM, Hervé Pagès wrote:
Hi Simon,
On 11-06-28 12:19 PM, Simon Urbanek wrote:
On Jun 28, 2011, at 3:01 PM, Hervé Pagès wrote:
Hi Uwe,
On 11-06-28 01:44 AM, Uwe Ligges wrote:
On 28.06.2011 01:31, Hervé Pagès wrote:
Hi,
Why isn't 'R CMD check --force-multiarch' installing the package
for all the architectures that are going to be checked?
Hervé,
no, since it cannot know that that you need
--merge-multiarch
as an additional install flag for this particular package.
Why not just use this flag anyway? Does it hurt to use it on packages that
don't strictly need it?
It does for two reasons: a) everything is built twice
That's exactly what I want when I do 'R CMD check --force-multiarch'
No, that's not what it does (and I assume you mean --force-biarch). It builds
the package just once, you're simply overriding the default behavior of
checking for configure.win, that's all. The two flags are orthogonal,
--force-biarch makes no sense with --merge-multiarch, they are for all
practical purposes mutually exclusive by definition of what they do.
I really mean --force-multiarch, not --force-biarch. AFAIK 'R CMD check'
has no --force-biarch option.
and b) package authors don't expect the necessity to support --libs-only if the
package doesn't require separate build runs.
When specifying --force-multiarch, the user really expects the package to be
installed for all sub-archs.
... with the assumption that the package supports it even though it has a
configure script which may to may not work unlike --merge-multiarch which will
always work.
Just to clarify:
--force-multiarch is an 'R CMD check' option, not an 'R CMD INSTALL'
option
--merge-multiarch is an 'R CMD INSTALL' option, not an 'R CMD check'
option
Now you are saying that --merge-multiarch will always work (on Windows
of course, all this discussion is about how to achieve multiarch check
on Windows). Great, this is what I've been observing too so far!
On packages with or without native codes, with or without configure.win
scripts, etc... It always seems to work. So, again, why isn't
'R CMD check --force-multiarch' installing with --merge-multiarch?
Note that I'm not attached to that solution in particular, just trying
to suggest an easy fix for 'R CMD check --force-multiarch' (which right
now is broken on some packages).
--force-biarch is just a way to flag packages that have configure.win that has
no effect on the binary settings (flags etc.). It forces R to try multi-arch
build in one flight, but it may or may not work depending on the package. It is
a way to save time by not running --merge-multiarch (and thus building the
package twice).
--force-biarch is an 'R CMD INSTALL' option that I don't use. Why would
I use something that might fail when I can use --merge-multiarch which
always works.
Thanks,
H.
Cheers,
Simon
The cross-platform way is to not use --merge-multiarch but use --libs-only
instead as needed (easy to check after the first arch run which will tell you
whether it's needed or not). I suspect that --merge-multiarch is just a
convenience shortcut (and it's unclear to me why it's Windows-only...).
A great convenience indeed as it allows to do the multiarch install in
a single step. And it's unclear to me too why it's Windows-only but I
would have hoped you would know...
Thanks,
H.
Cheers,
Simon
You will have to check it in repository maintainer's mode (as the CRAN
maintainers do everywhere). Essentially this is for me (when also
producing WIndows binaries):
Step 1: Installation
R CMD INSTALL --pkglock --compact-docs --build --merge-multiarch
--library="D:/path/to/library" fabia_1.5.0.tar.gz> fabia-install.out 2>&1
(where the merge-multiarch part applies only to this package, of course)
Step 2: Check (without installation, since that happened before already,
using the install log from step 1)
R CMD check --library="D:/path/to/library" --force-multiarch
--install="check:fabia-install.out" fabia
Wha! Would be nice if there was a plan to make 'R CMD check' also
usable by normal people (including the package developer), not just
by a few privileged people that know about those undocumented tricks.
Thanks,
H.
Best wishes,
Uwe
For some packages, it only installs for the default arch ('i386').
Then testing the package for 'x64' fails.
For example,
Output of R CMD check --force-multiarch fabia_1.5.0.tar.gz:
---
* using log directory 'D:/biocbld/bbs-2.9-bioc/meat/fabia.Rcheck'
* using R version 2.14.0 Under development (unstable) (2011-05-30 r56020)
* using platform: i386-pc-mingw32 (32-bit)
* using session charset: ISO8859-1
* using option '--no-vignettes'
* checking for file 'fabia/DESCRIPTION' ... OK
* this is package 'fabia' version '1.5.0'
* checking package name space information ... OK
* checking package dependen
Re: [Rd] R CMD check --force-multiarch does not install all the archs for testing
On Jun 28, 2011, at 5:11 PM, Hervé Pagès wrote: > Simon, > > On 11-06-28 01:44 PM, Simon Urbanek wrote: >> >> On Jun 28, 2011, at 3:45 PM, Hervé Pagès wrote: >> >>> Hi Simon, >>> >>> On 11-06-28 12:19 PM, Simon Urbanek wrote: On Jun 28, 2011, at 3:01 PM, Hervé Pagès wrote: > Hi Uwe, > > On 11-06-28 01:44 AM, Uwe Ligges wrote: >> >> >> On 28.06.2011 01:31, Hervé Pagès wrote: >>> Hi, >>> >>> Why isn't 'R CMD check --force-multiarch' installing the package >>> for all the architectures that are going to be checked? >> >> Hervé, >> >> no, since it cannot know that that you need >> >> --merge-multiarch >> >> as an additional install flag for this particular package. > > Why not just use this flag anyway? Does it hurt to use it on packages > that don't strictly need it? > It does for two reasons: a) everything is built twice >>> >>> That's exactly what I want when I do 'R CMD check --force-multiarch' >>> >> >> No, that's not what it does (and I assume you mean --force-biarch). It >> builds the package just once, you're simply overriding the default behavior >> of checking for configure.win, that's all. The two flags are orthogonal, >> --force-biarch makes no sense with --merge-multiarch, they are for all >> practical purposes mutually exclusive by definition of what they do. > > I really mean --force-multiarch, not --force-biarch. AFAIK 'R CMD check' > has no --force-biarch option. > >> >> and b) package authors don't expect the necessity to support --libs-only if the package doesn't require separate build runs. >>> >>> When specifying --force-multiarch, the user really expects the package to >>> be installed for all sub-archs. >>> >> >> ... with the assumption that the package supports it even though it has a >> configure script which may to may not work unlike --merge-multiarch which >> will always work. > > Just to clarify: > > --force-multiarch is an 'R CMD check' option, not an 'R CMD INSTALL' > option > > --merge-multiarch is an 'R CMD INSTALL' option, not an 'R CMD check' > option > > Now you are saying that --merge-multiarch will always work (on Windows > of course, all this discussion is about how to achieve multiarch check > on Windows). Great, this is what I've been observing too so far! > On packages with or without native codes, with or without configure.win > scripts, etc... It always seems to work. So, again, why isn't > 'R CMD check --force-multiarch' installing with --merge-multiarch? > Note that I'm not attached to that solution in particular, just trying > to suggest an easy fix for 'R CMD check --force-multiarch' (which right > now is broken on some packages). > >> --force-biarch is just a way to flag packages that have configure.win that >> has no effect on the binary settings (flags etc.). It forces R to try >> multi-arch build in one flight, but it may or may not work depending on the >> package. It is a way to save time by not running --merge-multiarch (and thus >> building the package twice). > > --force-biarch is an 'R CMD INSTALL' option that I don't use. Why would > I use something that might fail when I can use --merge-multiarch which > always works. > Ok, never mind then, I was talking exclusively about R CMD INSTALL. Cheers, Simon > Thanks, > H. > >> >> Cheers, >> Simon >> >> The cross-platform way is to not use --merge-multiarch but use --libs-only instead as needed (easy to check after the first arch run which will tell you whether it's needed or not). I suspect that --merge-multiarch is just a convenience shortcut (and it's unclear to me why it's Windows-only...). >>> >>> A great convenience indeed as it allows to do the multiarch install in >>> a single step. And it's unclear to me too why it's Windows-only but I >>> would have hoped you would know... >>> >>> Thanks, >>> H. >>> >>> Cheers, Simon >> You will have to check it in repository maintainer's mode (as the CRAN >> maintainers do everywhere). Essentially this is for me (when also >> producing WIndows binaries): >> >> >> Step 1: Installation >> >> R CMD INSTALL --pkglock --compact-docs --build --merge-multiarch >> --library="D:/path/to/library" fabia_1.5.0.tar.gz> fabia-install.out >> 2>&1 >> >> (where the merge-multiarch part applies only to this package, of course) >> >> >> >> Step 2: Check (without installation, since that happened before already, >> using the install log from step 1) >> >> R CMD check --library="D:/path/to/library" --force-multiarch >> --install="check:fabia-install.out" fabia > > Wha! Would be nice if there was a plan to make 'R CMD check' also > usable by normal people (including the package developer), not just > by a few privileged people that know abo
Re: [Rd] Small bug in install.packages?
> Isn't R.home() 8.3 path anyway?
I don't think so:
> R.home("bin")
[1] "C:/Program Files/R/R-2.13.0/bin/i386"
> sessionInfo()
R version 2.13.0 Patched (2011-06-09 r56106)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] grDevices datasets utils stats graphics methods base
other attached packages:
[1] RMark_2.0.5 rj_0.5.0-5 devtools_0.2codetools_0.2-8
[5] plotrix_3.2-2 nlme_3.1-101msm_1.0.1
loaded via a namespace (and not attached):
[1] grid_2.13.0 lattice_0.19-26 mvtnorm_0.9-9991 rJava_0.8-8
[5] splines_2.13.0 survival_2.36-9 tools_2.13.0
> BTW: I think you probably meant more something like
> paste(shQuote(file.path(R.home("bin"), "R")), "CMD INSTALL") since the above
> won't work ..
Ooops, yes.
Hadley
--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Small bug in install.packages?
It is 8.3 on my install of 2.13.0 (release) and I get the same results
with the current R-patched.
> R.home("bin")
[1] "C:/PROGRA~1/R/R-213~1.0PA/bin/i386"
> sessionInfo()
R version 2.13.0 Patched (2011-06-20 r56188)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
--
Joshua Ulrich | FOSS Trading: www.fosstrading.com
On Tue, Jun 28, 2011 at 4:42 PM, Hadley Wickham wrote:
>> Isn't R.home() 8.3 path anyway?
>
> I don't think so:
>
>> R.home("bin")
> [1] "C:/Program Files/R/R-2.13.0/bin/i386"
>> sessionInfo()
> R version 2.13.0 Patched (2011-06-09 r56106)
> Platform: i386-pc-mingw32/i386 (32-bit)
>
> locale:
> [1] LC_COLLATE=English_United States.1252
> [2] LC_CTYPE=English_United States.1252
> [3] LC_MONETARY=English_United States.1252
> [4] LC_NUMERIC=C
> [5] LC_TIME=English_United States.1252
>
> attached base packages:
> [1] grDevices datasets utils stats graphics methods base
>
> other attached packages:
> [1] RMark_2.0.5 rj_0.5.0-5 devtools_0.2 codetools_0.2-8
> [5] plotrix_3.2-2 nlme_3.1-101 msm_1.0.1
>
> loaded via a namespace (and not attached):
> [1] grid_2.13.0 lattice_0.19-26 mvtnorm_0.9-9991 rJava_0.8-8
> [5] splines_2.13.0 survival_2.36-9 tools_2.13.0
>
>> BTW: I think you probably meant more something like
>> paste(shQuote(file.path(R.home("bin"), "R")), "CMD INSTALL") since the above
>> won't work ..
>
> Ooops, yes.
>
> Hadley
>
>
> --
> Assistant Professor / Dobelman Family Junior Chair
> Department of Statistics / Rice University
> http://had.co.nz/
>
> __
> 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] Small bug in install.packages?
On 28/06/2011 5:42 PM, Hadley Wickham wrote:
Isn't R.home() 8.3 path anyway?
I don't think so:
R.home("bin")
[1] "C:/Program Files/R/R-2.13.0/bin/i386"
Weird. Like others, I see 8.3 pathnames. R gets those from a Windows
call; what version of Windows are you using?
Duncan Murdoch
sessionInfo()
R version 2.13.0 Patched (2011-06-09 r56106)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] grDevices datasets utils stats graphics methods base
other attached packages:
[1] RMark_2.0.5 rj_0.5.0-5 devtools_0.2codetools_0.2-8
[5] plotrix_3.2-2 nlme_3.1-101msm_1.0.1
loaded via a namespace (and not attached):
[1] grid_2.13.0 lattice_0.19-26 mvtnorm_0.9-9991 rJava_0.8-8
[5] splines_2.13.0 survival_2.36-9 tools_2.13.0
BTW: I think you probably meant more something like paste(shQuote(file.path(R.home("bin"),
"R")), "CMD INSTALL") since the above won't work ..
Ooops, yes.
Hadley
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Small bug in install.packages?
On 28/06/2011 8:17 PM, Duncan Murdoch wrote:
On 28/06/2011 5:42 PM, Hadley Wickham wrote:
Isn't R.home() 8.3 path anyway?
I don't think so:
R.home("bin")
[1] "C:/Program Files/R/R-2.13.0/bin/i386"
Weird. Like others, I see 8.3 pathnames. R gets those from a Windows
call; what version of Windows are you using?
... and how are you starting R? Startup goes through some contortions
to handle all the different possibilities; maybe one of them is missing
the path-shortening step.
Duncan Murdoch
Duncan Murdoch
sessionInfo()
R version 2.13.0 Patched (2011-06-09 r56106)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] grDevices datasets utils stats graphics methods base
other attached packages:
[1] RMark_2.0.5 rj_0.5.0-5 devtools_0.2codetools_0.2-8
[5] plotrix_3.2-2 nlme_3.1-101msm_1.0.1
loaded via a namespace (and not attached):
[1] grid_2.13.0 lattice_0.19-26 mvtnorm_0.9-9991 rJava_0.8-8
[5] splines_2.13.0 survival_2.36-9 tools_2.13.0
BTW: I think you probably meant more something like paste(shQuote(file.path(R.home("bin"),
"R")), "CMD INSTALL") since the above won't work ..
Ooops, yes.
Hadley
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
