[Rd] lubridate does not install on FreeBSD any more
With newest R devel #sessionInfo() R Under development (unstable) (2012-01-10 r58085) Platform: amd64-portbld-freebsd10.0 (64-bit) locale: [1] de_DE.ISO8859-15/de_DE.ISO8859-15/de_DE.ISO8859-15/C/de_DE.ISO8859-15/de_DE.ISO8859-15 attached base packages: [1] stats graphics grDevices utils datasets methods base I get the following error when I try to build and install lubridate from sources on FreeBSD 10.0-CURRENT (amd64): #R CMD INSTALL lubridate_0.2.6.tar.gz * installing to library '/usr/local/lib/R/library' * installing *source* package 'lubridate' ... ** package 'lubridate' successfully unpacked and MD5 sums checked ** R ** data ** moving datasets to lazyload DB ** inst ** preparing package for lazy loading ** help *** installing help indices ** building package indices ** testing if installed package can be loaded During startup - Warning messages: 1: Setting LC_CTYPE failed, using C 2: Setting LC_TIME failed, using C 3: Setting LC_MESSAGES failed, using C 4: Setting LC_PAPER failed, using C Error : .onLoad failed in loadNamespace() for 'lubridate', details: call: utils::assignInNamespace(+.Date, add_dates, base) error: locked binding of '+.Date' cannot be changed Error: loading failed Execution halted ERROR: loading failed * removing '/usr/local/lib/R/library/lubridate' * restoring previous '/usr/local/lib/R/library/lubridate' Do you have any idea what is going on here? Thanks in advance, Rainer Hurling __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] lubridate does not install on FreeBSD any more
On 11.01.2012 11:13, Rainer Hurling wrote: With newest R devel #sessionInfo() R Under development (unstable) (2012-01-10 r58085) Platform: amd64-portbld-freebsd10.0 (64-bit) locale: [1] de_DE.ISO8859-15/de_DE.ISO8859-15/de_DE.ISO8859-15/C/de_DE.ISO8859-15/de_DE.ISO8859-15 attached base packages: [1] stats graphics grDevices utils datasets methods base I get the following error when I try to build and install lubridate from sources on FreeBSD 10.0-CURRENT (amd64): #R CMD INSTALL lubridate_0.2.6.tar.gz * installing to library '/usr/local/lib/R/library' * installing *source* package 'lubridate' ... ** package 'lubridate' successfully unpacked and MD5 sums checked ** R ** data ** moving datasets to lazyload DB ** inst ** preparing package for lazy loading ** help *** installing help indices ** building package indices ** testing if installed package can be loaded During startup - Warning messages: 1: Setting LC_CTYPE failed, using C 2: Setting LC_TIME failed, using C 3: Setting LC_MESSAGES failed, using C 4: Setting LC_PAPER failed, using C Error : .onLoad failed in loadNamespace() for 'lubridate', details: call: utils::assignInNamespace(+.Date, add_dates, base) error: locked binding of '+.Date' cannot be changed Error: loading failed Execution halted ERROR: loading failed * removing '/usr/local/lib/R/library/lubridate' * restoring previous '/usr/local/lib/R/library/lubridate' Do you have any idea what is going on here? Yes: locked bindings cannot be changed in R-devel any more, and lubridate does that. The maintainer has been asked for an update already. Uwe Ligges Thanks in advance, Rainer Hurling __ 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] lubridate does not install on FreeBSD any more
On Jan 11, 2012, at 11:13 , Rainer Hurling wrote: With newest R devel #sessionInfo() R Under development (unstable) (2012-01-10 r58085) Platform: amd64-portbld-freebsd10.0 (64-bit) locale: [1] de_DE.ISO8859-15/de_DE.ISO8859-15/de_DE.ISO8859-15/C/de_DE.ISO8859-15/de_DE.ISO8859-15 attached base packages: [1] stats graphics grDevices utils datasets methods base I get the following error when I try to build and install lubridate from sources on FreeBSD 10.0-CURRENT (amd64): #R CMD INSTALL lubridate_0.2.6.tar.gz * installing to library '/usr/local/lib/R/library' * installing *source* package 'lubridate' ... ** package 'lubridate' successfully unpacked and MD5 sums checked ** R ** data ** moving datasets to lazyload DB ** inst ** preparing package for lazy loading ** help *** installing help indices ** building package indices ** testing if installed package can be loaded During startup - Warning messages: 1: Setting LC_CTYPE failed, using C 2: Setting LC_TIME failed, using C 3: Setting LC_MESSAGES failed, using C 4: Setting LC_PAPER failed, using C Error : .onLoad failed in loadNamespace() for 'lubridate', details: call: utils::assignInNamespace(+.Date, add_dates, base) error: locked binding of '+.Date' cannot be changed Error: loading failed Execution halted ERROR: loading failed * removing '/usr/local/lib/R/library/lubridate' * restoring previous '/usr/local/lib/R/library/lubridate' Do you have any idea what is going on here? I think that should be rather obvious. It tries to modify/define a base function and no longer gets away with that bit of bad programming citizenship. -- Peter Dalgaard, Professor Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Command completion of the R binary / Ubuntu
Dear Deepayan and dear list, I notice a small inconsistency with the command completion of the R CMD check. --no-latex is deprecated sincs R 2.12.0 and defunct since 2.13.0 but the command line completion still suggests it: cb@cbdesktop:~/r-devel$ bin/R CMD check --no-here I hit tab --no-clean --no-examples --no-latex --no-vignettes --no-codoc --no-install--no-tests cb@cbdesktop:~/r-devel$ bin/R CMD check --no-latex Fehler: '--no-latex' is defunct: use '--no-manual' instead I gather the command line options could be updated to current R CMD check in file /etc/bash_completion.d/R: cb@cbdesktop:~/tmp$ diff R /etc/bash_completion.d/R 244,247c244,245 --no-install --no-tests --no-vignettes --no-manual \ --no-rebuild-vignettes --install-args --check-subdirs \ --extra-arch --multiarch --no-multiarch --force-multiarch \ --timings --use-gct --use-valgrind --rcfile --- --no-install --no-tests --no-vignettes --no-latex \ --use-gct --use-valgrind --rcfile I gather from the mailing list archives, that the original is available at http://code.google.com/p/rcompletion/source/browse/trunk/bash_completion/R Should I suggest the patch there? Will changes propagate to the packaged linux distributions from there or should the updated file be brought to the attention somewhere else? Best regards, Claudia sessionInfo () R version 2.14.1 (2011-12-22) Platform: x86_64-pc-linux-gnu (64-bit) locale: [1] LC_CTYPE=de_DE.UTF-8 LC_NUMERIC=C [3] LC_TIME=de_DE.UTF-8LC_COLLATE=de_DE.UTF-8 [5] LC_MONETARY=de_DE.UTF-8LC_MESSAGES=de_DE.UTF-8 [7] LC_PAPER=C LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=de_DE.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base -- Claudia Beleites Spectroscopy/Imaging Institute of Photonic Technology Albert-Einstein-Str. 9 07745 Jena Germany email: claudia.belei...@ipht-jena.de phone: +49 3641 206-133 fax: +49 2641 206-399 244,247c244,245 --no-install --no-tests --no-vignettes --no-manual \ --no-rebuild-vignettes --install-args --check-subdirs \ --extra-arch --multiarch --no-multiarch --force-multiarch \ --timings --use-gct --use-valgrind --rcfile --- --no-install --no-tests --no-vignettes --no-latex \ --use-gct --use-valgrind --rcfile __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] lubridate does not install on FreeBSD any more
On 11.01.2012 11:32 (UTC+1), Uwe Ligges wrote: On 11.01.2012 11:13, Rainer Hurling wrote: With newest R devel #sessionInfo() R Under development (unstable) (2012-01-10 r58085) Platform: amd64-portbld-freebsd10.0 (64-bit) locale: [1] de_DE.ISO8859-15/de_DE.ISO8859-15/de_DE.ISO8859-15/C/de_DE.ISO8859-15/de_DE.ISO8859-15 attached base packages: [1] stats graphics grDevices utils datasets methods base I get the following error when I try to build and install lubridate from sources on FreeBSD 10.0-CURRENT (amd64): #R CMD INSTALL lubridate_0.2.6.tar.gz * installing to library '/usr/local/lib/R/library' * installing *source* package 'lubridate' ... ** package 'lubridate' successfully unpacked and MD5 sums checked ** R ** data ** moving datasets to lazyload DB ** inst ** preparing package for lazy loading ** help *** installing help indices ** building package indices ** testing if installed package can be loaded During startup - Warning messages: 1: Setting LC_CTYPE failed, using C 2: Setting LC_TIME failed, using C 3: Setting LC_MESSAGES failed, using C 4: Setting LC_PAPER failed, using C Error : .onLoad failed in loadNamespace() for 'lubridate', details: call: utils::assignInNamespace(+.Date, add_dates, base) error: locked binding of '+.Date' cannot be changed Error: loading failed Execution halted ERROR: loading failed * removing '/usr/local/lib/R/library/lubridate' * restoring previous '/usr/local/lib/R/library/lubridate' Do you have any idea what is going on here? Yes: locked bindings cannot be changed in R-devel any more, and lubridate does that. The maintainer has been asked for an update already. Uwe Ligges Thanks in advance, Rainer Hurling Thanks, Uwe Ligges and Peter Dalgaard, for clarifying this. So we have to wait for an update ... __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Command completion of the R binary / Ubuntu
On Wed, Jan 11, 2012 at 4:16 PM, Claudia Beleites claudia.belei...@ipht-jena.de wrote: Dear Deepayan and dear list, I notice a small inconsistency with the command completion of the R CMD check. --no-latex is deprecated sincs R 2.12.0 and defunct since 2.13.0 but the command line completion still suggests it: cb@cbdesktop:~/r-devel$ bin/R CMD check --no-here I hit tab --no-clean --no-examples --no-latex --no-vignettes --no-codoc --no-install --no-tests cb@cbdesktop:~/r-devel$ bin/R CMD check --no-latex Fehler: '--no-latex' is defunct: use '--no-manual' instead I gather the command line options could be updated to current R CMD check in file /etc/bash_completion.d/R: cb@cbdesktop:~/tmp$ diff R /etc/bash_completion.d/R 244,247c244,245 --no-install --no-tests --no-vignettes --no-manual \ --no-rebuild-vignettes --install-args --check-subdirs \ --extra-arch --multiarch --no-multiarch --force-multiarch \ --timings --use-gct --use-valgrind --rcfile --- --no-install --no-tests --no-vignettes --no-latex \ --use-gct --use-valgrind --rcfile I gather from the mailing list archives, that the original is available at http://code.google.com/p/rcompletion/source/browse/trunk/bash_completion/R Should I suggest the patch there? Will changes propagate to the packaged linux distributions from there or should the updated file be brought to the attention somewhere else? Thanks for the patch. I believe only Debian/Ubuntu package it (and this would have been more appropriate for r-sig-debian). I'll coordinate with Dirk et al to update the relevant files. -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Command completion of the R binary / Ubuntu: result
On Jan 11, 2012, at 10:02 AM, Claudia Beleites wrote: Dear list, for the benefit of people searching for this in the future (and as r-devel archives are searched by RSiteSearch, The Baron search page claims to search r-devel, but most of my attempts to follow the links it offers have failed. They end up at links like: http://finzi.psych.upenn.edu/R/R-devel/2010-December/059322.html (which 404s.) I instead search the r-devel Archive with Google Advanced Search with a domain of site:https://stat.ethz.ch/pipermail/r-devel/ I just edited the URL to see if the directory and naming conventions would agree and they do seem to, https://stat.ethz.ch/pipermail/r-devel/2010-December/059322.html so I will copy this to John Baron to see if he wants to address it. -- David. but r-sig-debian isn't): - command line completion of the R command doesn't have anything to do with R - Deepayan told me that as far as he knows, only Debian (and Ubuntu) have it, so R-sig-debian is the appropriate mailing list. Deepayan moved the discussion there. Thanks. Have a nice day, Claudia David Winsemius, MD West Hartford, CT __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Copying objects prior to .Call
R-devel,
I have noticed that making a copy of an object in R prior to using
.Call on the original object can
cause the C code to alter not only the object passed to it but also
the copy in R. A simple example
is:
x - 2
y - x
.Call(addOne, x, DUP=TRUE) # Changing DUP does not alter output
NULL
x
[1] 3
y
[1] 3
And corresponding simple C code:
test.c:
#include R.h
#include Rinternals.h
#include Rmath.h
SEXP addOne(SEXP input) {
REAL(input)[0] = REAL(input)[0] + 1;
return R_NilValue;
}
I assume that this is simply a result of lazy loading in R, and well
documented. My question is, do
there exist functions to (1) force R to make a copy of an object
(force() does not work), and (2) to check
whether two objects are actually pointing to the same memory address.
For question 1, I have
found specific operations which force a copy of a given datatype, but
would prefer a more general
solution.
Thank you,
Taylor
sessionInfo()
R version 2.14.1 (2011-12-22)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
locale:
[1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.14.1
--
Taylor B. Arnold
Department of Statistics
Yale University
24 Hillhouse Avenue
New Haven, CT 06520
e-mail: taylor.arn...@yale.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Copying objects prior to .Call
On Jan 11, 2012, at 12:08 PM, Taylor Arnold wrote:
R-devel,
I have noticed that making a copy of an object in R prior to using
.Call on the original object can
cause the C code to alter not only the object passed to it but also
the copy in R.
Please see the docs - .Call does *NOT* have a DUP argument - you are
responsible for duplication at all times if you make modifications (e.g. using
duplicate()).
Cheers,
Simon
A simple example
is:
x - 2
y - x
.Call(addOne, x, DUP=TRUE) # Changing DUP does not alter output
NULL
x
[1] 3
y
[1] 3
And corresponding simple C code:
test.c:
#include R.h
#include Rinternals.h
#include Rmath.h
SEXP addOne(SEXP input) {
REAL(input)[0] = REAL(input)[0] + 1;
return R_NilValue;
}
I assume that this is simply a result of lazy loading in R, and well
documented. My question is, do
there exist functions to (1) force R to make a copy of an object
(force() does not work), and (2) to check
whether two objects are actually pointing to the same memory address.
For question 1, I have
found specific operations which force a copy of a given datatype, but
would prefer a more general
solution.
Thank you,
Taylor
sessionInfo()
R version 2.14.1 (2011-12-22)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
locale:
[1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.14.1
--
Taylor B. Arnold
Department of Statistics
Yale University
24 Hillhouse Avenue
New Haven, CT 06520
e-mail: taylor.arn...@yale.edu
__
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] Copying objects prior to .Call
On Wed, Jan 11, 2012 at 11:49 AM, Simon Urbanek
simon.urba...@r-project.org wrote:
On Jan 11, 2012, at 12:08 PM, Taylor Arnold wrote:
R-devel,
I have noticed that making a copy of an object in R prior to using
.Call on the original object can
cause the C code to alter not only the object passed to it but also
the copy in R.
Please see the docs - .Call does *NOT* have a DUP argument - you are
responsible for duplication at all times if you make modifications (e.g.
using duplicate()).
Except that duplicate will create a new SEXPREC and the original
poster wanted to modify the SEXPREC passed through a pointer in .Call.
Purposely changing the value of arguments to .Call is a bad design,
Taylor. R is a functional language and this breaks the functional
semantics. It is the sort of thing that you do only when you can't
think of a better approach. It may, perhaps, be justified if the R
objects you are passing happen to be fields in a reference class (see
?setRefClass) but otherwise it is just opening yourself up to errors.
At the level of C/C++ all R objects passed as arguments to .Call
should be regarded as
const SEXP
A simple example
is:
x - 2
y - x
.Call(addOne, x, DUP=TRUE) # Changing DUP does not alter output
NULL
x
[1] 3
y
[1] 3
And corresponding simple C code:
test.c:
#include R.h
#include Rinternals.h
#include Rmath.h
SEXP addOne(SEXP input) {
REAL(input)[0] = REAL(input)[0] + 1;
return R_NilValue;
}
I assume that this is simply a result of lazy loading in R, and well
documented. My question is, do
there exist functions to (1) force R to make a copy of an object
(force() does not work), and (2) to check
whether two objects are actually pointing to the same memory address.
For question 1, I have
found specific operations which force a copy of a given datatype, but
would prefer a more general
solution.
Thank you,
Taylor
sessionInfo()
R version 2.14.1 (2011-12-22)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
locale:
[1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.14.1
--
Taylor B. Arnold
Department of Statistics
Yale University
24 Hillhouse Avenue
New Haven, CT 06520
e-mail: taylor.arn...@yale.edu
__
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Copying objects prior to .Call
On 11.01.2012 18:49, Simon Urbanek wrote:
On Jan 11, 2012, at 12:08 PM, Taylor Arnold wrote:
R-devel,
I have noticed that making a copy of an object in R prior to using
.Call on the original object can
cause the C code to alter not only the object passed to it but also
the copy in R.
Please see the docs - .Call does *NOT* have a DUP argument - you are
responsible for duplication at all times if you make modifications (e.g. using
duplicate()).
Cheers,
Simon
A simple example
is:
x- 2
y- x
.Call(addOne, x, DUP=TRUE) # Changing DUP does not alter output
NULL
x
[1] 3
y
[1] 3
And corresponding simple C code:
test.c:
#includeR.h
#includeRinternals.h
#includeRmath.h
SEXP addOne(SEXP input) {
REAL(input)[0] = REAL(input)[0] + 1;
return R_NilValue;
}
I assume that this is simply a result of lazy loading
In addition to Simon: it is lazy evalution rather than lazy loading in
this case.
Uwe
in R, and well
documented. My question is, do
there exist functions to (1) force R to make a copy of an object
(force() does not work), and (2) to check
whether two objects are actually pointing to the same memory address.
For question 1, I have
found specific operations which force a copy of a given datatype, but
would prefer a more general
solution.
Thank you,
Taylor
sessionInfo()
R version 2.14.1 (2011-12-22)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
locale:
[1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.14.1
--
Taylor B. Arnold
Department of Statistics
Yale University
24 Hillhouse Avenue
New Haven, CT 06520
e-mail: taylor.arn...@yale.edu
__
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Inconsistencies in device_Raster when axes are reflected
I noticed some undocumented and inconsistent behavior in device_Raster when a plot is produced with reflected axes such as: image(volcano, xlim = c(1,0), useRaster = TRUE) image(volcano, ylim = c(1,0), useRaster = TRUE) The `pdf` device will perform horizontal and vertical reflections, while `quartz` will ignore the transformations when plotting to the screen, but when plotting to a file, `quartz(file = 'test.pdf', type = 'pdf')`, it will produce horizontal reflections and ignore vertical ones. When the `xlim` or `ylim` is reversed, negative widths and heights are passed to the C function `device_Raster`, which is not a behavior documented in `R_ext/GraphicsDevice.h`. Also, the values of `x` and `y` passed to `device_Raster` will be shifted by the width or height of the image such that the coordinates no longer reference the bottom-left corner of the image as `R_ext/GraphicsDevice.h` says they should. Given the inconsistencies in documentation and behavior, I am wondering what the intended behavior of `device_Raster` is in this situation. Thanks! -Charlie - Charlie Sharpsteen Undergraduate-- Environmental Resources Engineering Humboldt State University -- View this message in context: http://r.789695.n4.nabble.com/Inconsistencies-in-device-Raster-when-axes-are-reflected-tp4286320p4286320.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Copying objects prior to .Call
On Jan 11, 2012, at 1:04 PM, Uwe Ligges wrote:
On 11.01.2012 18:49, Simon Urbanek wrote:
On Jan 11, 2012, at 12:08 PM, Taylor Arnold wrote:
R-devel,
I have noticed that making a copy of an object in R prior to using
.Call on the original object can
cause the C code to alter not only the object passed to it but also
the copy in R.
Please see the docs - .Call does *NOT* have a DUP argument - you are
responsible for duplication at all times if you make modifications (e.g.
using duplicate()).
Cheers,
Simon
A simple example
is:
x- 2
y- x
.Call(addOne, x, DUP=TRUE) # Changing DUP does not alter output
NULL
x
[1] 3
y
[1] 3
And corresponding simple C code:
test.c:
#includeR.h
#includeRinternals.h
#includeRmath.h
SEXP addOne(SEXP input) {
REAL(input)[0] = REAL(input)[0] + 1;
return R_NilValue;
}
I assume that this is simply a result of lazy loading
In addition to Simon: it is lazy evalution rather than lazy loading in this
case.
It is actually neither. `x` gets evaluated, but the value is shared with `y`
because R has no reason to create a copy of identical information until
modified. That's why the .Call() code must create a copy if it wants to touch
the value that it received. Note that .Call does *not* get `x` itself - it gets
a value obtained from the binding of `x` so the only legal way to modify `x` is
to assign a value to it. You can try to be more efficieint and check if a value
has references to it and prevent copying if it doesn't (see NAMED), but if it
does, you have to copy it.
Cheers,
Simon
Uwe
in R, and well
documented. My question is, do
there exist functions to (1) force R to make a copy of an object
(force() does not work), and (2) to check
whether two objects are actually pointing to the same memory address.
For question 1, I have
found specific operations which force a copy of a given datatype, but
would prefer a more general
solution.
Thank you,
Taylor
sessionInfo()
R version 2.14.1 (2011-12-22)
Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit)
locale:
[1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.14.1
--
Taylor B. Arnold
Department of Statistics
Yale University
24 Hillhouse Avenue
New Haven, CT 06520
e-mail: taylor.arn...@yale.edu
__
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Command completion of the R binary / Ubuntu
On 11 January 2012 at 17:33, Deepayan Sarkar wrote: | On Wed, Jan 11, 2012 at 4:16 PM, Claudia Beleites | claudia.belei...@ipht-jena.de wrote: | Dear Deepayan and dear list, | | I notice a small inconsistency with the command completion of the R CMD | check. --no-latex is deprecated sincs R 2.12.0 and defunct since 2.13.0 | but the command line completion still suggests it: | | cb@cbdesktop:~/r-devel$ bin/R CMD check --no-here I hit tab | --no-clean --no-examples --no-latex --no-vignettes | --no-codoc --no-install --no-tests | cb@cbdesktop:~/r-devel$ bin/R CMD check --no-latex | Fehler: '--no-latex' is defunct: use '--no-manual' instead | | I gather the command line options could be updated to current R CMD | check in file /etc/bash_completion.d/R: | | cb@cbdesktop:~/tmp$ diff R /etc/bash_completion.d/R | 244,247c244,245 | --no-install --no-tests --no-vignettes --no-manual \ | --no-rebuild-vignettes --install-args --check-subdirs \ | --extra-arch --multiarch --no-multiarch --force-multiarch \ | --timings --use-gct --use-valgrind --rcfile | --- | --no-install --no-tests --no-vignettes --no-latex \ | --use-gct --use-valgrind --rcfile | | I gather from the mailing list archives, that the original is available at | http://code.google.com/p/rcompletion/source/browse/trunk/bash_completion/R | | Should I suggest the patch there? Will changes propagate to the packaged | linux distributions from there or should the updated file be brought to | the attention somewhere else? | | Thanks for the patch. | | I believe only Debian/Ubuntu package it (and this would have been more | appropriate for r-sig-debian). I'll coordinate with Dirk et al to | update the relevant files. That is indeed almost entirely a Deepayan (juicy code) and Dirk (mere packaging) issue as the rest (Ubuntun etc) just follows from there. And r-sig-debian would indeed have been a good venue too. But posting here makes it a nice reminder to everybody not using the .deb package about what they are missing :) Dirk | -Deepayan | | __ | R-devel@r-project.org mailing list | https://stat.ethz.ch/mailman/listinfo/r-devel -- Outside of a dog, a book is a man's best friend. Inside of a dog, it is too dark to read. -- Groucho Marx __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Command completion of the R binary / Ubuntu
Deepayan Sarkar-3 wrote I believe only Debian/Ubuntu package it (and this would have been more appropriate for r-sig-debian). I'll coordinate with Dirk et al to update the relevant files. -Deepayan The bash completion script is also used by the Homebrew package manager on OS X. -Charlie - Charlie Sharpsteen Undergraduate-- Environmental Resources Engineering Humboldt State University -- View this message in context: http://r.789695.n4.nabble.com/Command-completion-of-the-R-binary-Ubuntu-tp4285040p4286476.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Silently loading and Depends: versus NAMESPACE imports
R CMD check really hates it when my .onLoad() function contains suppressMessages(library(foo)) However, _and for non-public packages not going to CRAN_ I prefer doing this over using explicit Depends or import statements in the NAMESPACE file as the latter do not give me an ability to make the loading less verbose. With the R universe of packages being as vast as at is, a simple (non-public) package I have loads about five or six other packages explicitly, each of which loads even more. The net result is totally intimidating _sixty lines full_ of verbose noise that is meaningful to me as an R programmer, but not for the colleagues expected to use the packages. It looks rather uninviting, frankly. How do I use imports via NAMESPACE, and yet keep the noise level down to zero? Dirk -- Outside of a dog, a book is a man's best friend. Inside of a dog, it is too dark to read. -- Groucho Marx __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] parse( connection) and source-keeping
In R = 2.13.x, calling 'parse( con)' where 'con' is a connection, 'options(
keep.source)' is TRUE, and default 'srcfile' would preserve the source. In R
= 2.14.1, it doesn't.
tf - tempfile()
options( keep.source=TRUE)
texto - c( 'function() { # comment', '}')
parse( text=texto)
expression(function() { # comment
})
cat( texto, file=tf, sep='\n')
parse( file=tf)
expression(function() { # comment
})
parse( file( tf))
expression(function() {
})
parse( textConnection( texto))
expression(function() {
})
and yes I didn't bother closing any connections.
My suspicion is that this change is unintentional, and it seems to me that the
best option would be for 'connection' to work like 'text' does here, ie to
attach a 'srcfilecopy' containing the contents.
I didn't submit a bug report because the documentation (which hasn't changed in
this respect) actually doesn't say what 'parse' should do with 'connection' (as
opposed to 'text' or 'file') argument when 'getOption( keep.source)' is TRUE
and 'srcfile' is NULL. [BTW it's also unstated which argument takes precedence
if a non-default 'srcfile' argument is specified.] So some additional
explanation is needed there at a minimum, but also a decision as to what the
best behaviour would be.
bye
Mark
Mark Bravington
CSIRO CMIS
Marine Lab
Hobart
Australia
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] package DESCRIPTION file and CRAN Task View entries?
I'm in the middle of a long overdue package update, and after seeing the CRAN Task Views I thought there would be an entry, in the DESCRIPTIONS file, for that entry that appears on the package webpage. For example, http://cran.case.edu/web/packages/vegan/index.html Since it's been some time since I've updated the package, I did a little reading (R-exts.pdf) and web searching and recently read on http://www.r-bloggers.com/another-look-at-cran-task-views/ These are web pages that are maintained by volunteers with expertise in a specified area. The maintainers provide annotated guidance to routines and packages. I'm not sure I'm correct about this, but I'm beginning to think there is no connection between the DESCRIPTIONS file and the CRAN Task View entry on the web page. Is that correct? I'd like to add the updated rconifers package to the Environmetrics View. Package rconifers provides a set of forest growth simulators and miscellaneous functions for data analysis in forestry. Since the CRAN Task View is used to help organize the r packages better, help novice users find appropriate packages, and provide information on new packages, is there any talk of adding this feature? Respectfully, Jeff. Jeff Hamann, PhD PO Box 1421 Corvallis, Oregon 97339-1421 541-754-2457 jeff.hamann[at]forestinformatics[dot]com jeff.d.hamann[at]gmail[dot]com http://www.forestinformatics.com http://en.wikipedia.org/wiki/Forest_informatics To ensure that your email is processed, include a subject entry in your email. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD check pkg and 32/64 bit.
R gurus: I'm trying to get another round of rconifers out and I need some advice/help crushing differences in the examples test. I'm trying to make sure the max sdi values are being respected. I've added a tests/rconifers-Ex.Rout.save (from windows i386-pc-mingw32) and when I ran R CMD check (both R-2.13.0), I got the following results: * using log directory 'c:/conifers/trunk/rconifers.Rcheck' * using R version 2.13.0 (2011-04-13) * using platform: i386-pc-mingw32 (32-bit) * using session charset: ISO8859-1 * checking for file 'rconifers/DESCRIPTION' ... OK * this is package 'rconifers' version '1.0.7' * checking package dependencies ... OK * checking if this is a source package ... OK * checking for executable files ... OK * checking whether package 'rconifers' 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 * 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 for unstated dependencies in R code ... OK * checking S3 generic/method consistency ... OK * checking replacement functions ... OK * checking foreign function calls ... OK * checking R code for possible problems ... OK * checking Rd files ... OK * checking Rd metadata ... OK * checking Rd cross-references ... OK * checking for missing documentation entries ... OK * checking for code/documentation mismatches ... OK * checking Rd \usage sections ... OK * checking Rd contents ... OK * checking for unstated dependencies in examples ... OK * checking contents of 'data' directory ... OK * checking data for non-ASCII characters ... OK * checking data for ASCII and uncompressed saves ... OK * checking line endings in C/C++/Fortran sources/headers ... WARNING Found the following sources/headers with CR or CRLF line endings: src/coeffs_cips.c src/coeffs_mgt.c src/coeffs_smc.c src/coeffs_swo.c src/coeffs_swohybrid.c src/conifers.h src/file_io.c src/grow.c src/model_cips.c src/model_smc.c src/model_swo.c src/model_swohybrid.c src/mortality.c src/plot.c src/rconifers.c src/stats.c src/thin.c Some Unix compilers require LF line endings. * checking line endings in Makefiles ... OK * checking for portable use of $(BLAS_LIBS) and $(LAPACK_LIBS) ... OK * checking examples ... OK * checking differences from 'rconifers-Ex.Rout' to 'rconifers-Ex.Rout.save' ... OK * checking PDF version of manual ... OK WARNING: There was 1 warning, see 'c:/conifers/trunk/rconifers.Rcheck/00check.log' for details The magic line is: * checking differences from 'rconifers-Ex.Rout' to 'rconifers-Ex.Rout.save' ... OK which tells me that the check file matched the expected file. When I ran the check under OSX and got the following results: macbook:Desktop hamannjd$ R CMD check rconifers * using log directory /Users/hamannjd/Desktop/rconifers.Rcheck * using R version 2.13.0 (2011-04-13) * using platform: x86_64-apple-darwin10.7.0 (64-bit) * using session charset: UTF-8 * checking for file rconifers/DESCRIPTION ... OK * this is package rconifers version 1.0.7 * checking package dependencies ... OK * checking if this is a source package ... OK * checking for executable files ... OK * checking whether package rconifers can be installed ... OK * checking installed package size ... OK * checking package directory ... OK * checking for portable file names ... OK * checking for sufficient/correct file permissions ... 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 * 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 for unstated dependencies in R code ... OK * checking S3 generic/method consistency ... OK * checking replacement functions ... OK * checking foreign function calls ... OK * checking R code for possible problems ... OK * checking Rd files ... OK * checking Rd metadata ... OK * checking Rd cross-references ... OK * checking for missing documentation entries ... OK * checking for code/documentation mismatches ... OK * checking Rd \usage sections ... OK * checking Rd contents ... OK * checking for unstated dependencies in examples ... OK * checking contents of 'data' directory ... OK * checking data for non-ASCII characters ... OK * checking data for ASCII and uncompressed saves ... OK *
Re: [Rd] package DESCRIPTION file and CRAN Task View entries?
On 11 January 2012 at 14:11, Jeff Hamann wrote: | I'd like to add the updated rconifers package to the Environmetrics View. In my case, other maintainers typically just email me suggestions for inclusion in the two Task Views I look after. And after all, there is always a one-to-one match between a Task View and its (human, not robot) editor with an email address. Dirk -- Outside of a dog, a book is a man's best friend. Inside of a dog, it is too dark to read. -- Groucho Marx __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] parse( connection) and source-keeping
On 12-01-11 3:54 PM, mark.braving...@csiro.au wrote:
In R= 2.13.x, calling 'parse( con)' where 'con' is a connection, 'options(
keep.source)' is TRUE, and default 'srcfile' would preserve the source. In R=
2.14.1, it doesn't.
Actually, it preserved the source attribute of the function if it
could, but didn't add a srcref. Sometimes it would fail, giving a
message like
Error in parse(textConnection(texto)) :
function is too long to keep source (at line 8812)
tf- tempfile()
options( keep.source=TRUE)
texto- c( 'function() { # comment', '}')
parse( text=texto)
expression(function() { # comment
})
cat( texto, file=tf, sep='\n')
parse( file=tf)
expression(function() { # comment
})
parse( file( tf))
expression(function() {
})
parse( textConnection( texto))
expression(function() {
})
and yes I didn't bother closing any connections.
My suspicion is that this change is unintentional, and it seems to me that the
best option would be for 'connection' to work like 'text' does here, ie to
attach a 'srcfilecopy' containing the contents.
Yes, that does sound like a good idea.
Duncan Murdoch
I didn't submit a bug report because the documentation (which hasn't changed in
this respect) actually doesn't say what 'parse' should do with 'connection' (as
opposed to 'text' or 'file') argument when 'getOption( keep.source)' is TRUE
and 'srcfile' is NULL. [BTW it's also unstated which argument takes precedence
if a non-default 'srcfile' argument is specified.] So some additional
explanation is needed there at a minimum, but also a decision as to what the
best behaviour would be.
bye
Mark
Mark Bravington
CSIRO CMIS
Marine Lab
Hobart
Australia
__
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] Inconsistencies in device_Raster when axes are reflected
Hi On 12/01/2012 7:11 a.m., Sharpie wrote: I noticed some undocumented and inconsistent behavior in device_Raster when a plot is produced with reflected axes such as: image(volcano, xlim = c(1,0), useRaster = TRUE) image(volcano, ylim = c(1,0), useRaster = TRUE) The `pdf` device will perform horizontal and vertical reflections, while `quartz` will ignore the transformations when plotting to the screen, but when plotting to a file, `quartz(file = 'test.pdf', type = 'pdf')`, it will produce horizontal reflections and ignore vertical ones. When the `xlim` or `ylim` is reversed, negative widths and heights are passed to the C function `device_Raster`, which is not a behavior documented in `R_ext/GraphicsDevice.h`. Also, the values of `x` and `y` passed to `device_Raster` will be shifted by the width or height of the image such that the coordinates no longer reference the bottom-left corner of the image as `R_ext/GraphicsDevice.h` says they should. Given the inconsistencies in documentation and behavior, I am wondering what the intended behavior of `device_Raster` is in this situation. I think the problem is that I just failed to anticipate this situation (i.e., the current documentation and behaviour both assume xlim[1] xlim[2] and ylim[1] ylim[2]). Will take a look at where to apply a fix (EITHER allow the API to be more flexible [allow negative 'width' and 'height' and 'x' and 'y' to be other than left-bottom], which will require complicating the code in some devices OR keep the API fixed and complicate the graphics engine code instead). The rotation argument adds an interesting twist ... Thanks for the report! Paul Thanks! -Charlie - Charlie Sharpsteen Undergraduate-- Environmental Resources Engineering Humboldt State University -- View this message in context: http://r.789695.n4.nabble.com/Inconsistencies-in-device-Raster-when-axes-are-reflected-tp4286320p4286320.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check pkg and 32/64 bit.
Take a closer look: the differences in output are not just in trailing
digits.
We solve the latter in R itself mainly by use of e.g. options(digits=5)
in the relevant \examples{} sections.
However, we also try to remove the numerical instability in the
algorithms that leads to this. Perhaps some convergence criterion is
too loose?
Also, you can find out if this really is a 32/64-bit issue by running
both architectures on the Mac (although 32/64 tends to be closer on that
platform than on Linux or Windows).
On 11/01/2012 22:33, Jeff Hamann wrote:
R gurus:
I'm trying to get another round of rconifers out and I need some advice/help
crushing differences in the examples test.
I'm trying to make sure the max sdi values are being respected.
I've added a tests/rconifers-Ex.Rout.save (from windows i386-pc-mingw32) and
when I ran R CMD check (both R-2.13.0), I got the following results:
* using log directory 'c:/conifers/trunk/rconifers.Rcheck'
* using R version 2.13.0 (2011-04-13)
* using platform: i386-pc-mingw32 (32-bit)
* using session charset: ISO8859-1
* checking for file 'rconifers/DESCRIPTION' ... OK
* this is package 'rconifers' version '1.0.7'
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking for executable files ... OK
* checking whether package 'rconifers' 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
* 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 for unstated dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... OK
* checking Rd files ... OK
* checking Rd metadata ... OK
* checking Rd cross-references ... OK
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... OK
* checking Rd \usage sections ... OK
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... OK
* checking contents of 'data' directory ... OK
* checking data for non-ASCII characters ... OK
* checking data for ASCII and uncompressed saves ... OK
* checking line endings in C/C++/Fortran sources/headers ... WARNING
Found the following sources/headers with CR or CRLF line endings:
src/coeffs_cips.c
src/coeffs_mgt.c
src/coeffs_smc.c
src/coeffs_swo.c
src/coeffs_swohybrid.c
src/conifers.h
src/file_io.c
src/grow.c
src/model_cips.c
src/model_smc.c
src/model_swo.c
src/model_swohybrid.c
src/mortality.c
src/plot.c
src/rconifers.c
src/stats.c
src/thin.c
Some Unix compilers require LF line endings.
* checking line endings in Makefiles ... OK
* checking for portable use of $(BLAS_LIBS) and $(LAPACK_LIBS) ... OK
* checking examples ... OK
* checking differences from 'rconifers-Ex.Rout' to 'rconifers-Ex.Rout.save' ...
OK
* checking PDF version of manual ... OK
WARNING: There was 1 warning, see
'c:/conifers/trunk/rconifers.Rcheck/00check.log'
for details
The magic line is:
* checking differences from 'rconifers-Ex.Rout' to 'rconifers-Ex.Rout.save' ...
OK
which tells me that the check file matched the expected file.
When I ran the check under OSX and got the following results:
macbook:Desktop hamannjd$ R CMD check rconifers
* using log directory ‘/Users/hamannjd/Desktop/rconifers.Rcheck’
* using R version 2.13.0 (2011-04-13)
* using platform: x86_64-apple-darwin10.7.0 (64-bit)
* using session charset: UTF-8
* checking for file ‘rconifers/DESCRIPTION’ ... OK
* this is package ‘rconifers’ version ‘1.0.7’
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking for executable files ... OK
* checking whether package ‘rconifers’ can be installed ... OK
* checking installed package size ... OK
* checking package directory ... OK
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... 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
* 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 for unstated dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking
