[Rd] Minor typo in R-exts
Section 1.1.3 of the "R-exts" manual currently refers to "imports or
importFrom directives" where it means to say "import or importFrom
directives". Results of a diff between R-exts.texi at SVN revision
76864 and a corrected version are copied below.
*** R-exts.texi Mon Jul 22 14:41:19 2019
--- R-exts.texi.modified Mon Jul 22 14:45:32 2019
***
*** 902,904
@code{library(@var{pkgname})} should be listed in the @samp{Imports} field
! and not in the @samp{Depends} field. Packages listed in @code{imports}
or @code{importFrom} directives in the @file{NAMESPACE} file should
--- 902,904
@code{library(@var{pkgname})} should be listed in the @samp{Imports} field
! and not in the @samp{Depends} field. Packages listed in @code{import}
or @code{importFrom} directives in the @file{NAMESPACE} file should
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] In R for Windows RGui, plain text help files open up at bottom of help file
Hello, When using the R for Windows installer, I typically choose a customized startup and specify "Plain text" (rather than "HTML help") as my preferred help style. In R-3.3.0, R-3.2.5, and (IIRC) R-3.2.4 (but not R-3.2.3), the plain text help files that open up when using `help()` or `?` do so with the text 'scrolled' down all the way to the bottom. It's a minor inconvenience, but probably worth mentioning. In case it helps, here's my sessionInfo: R version 3.3.0 (2016-05-03) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 7 x64 (build 7601) Service Pack 1 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 loaded via a namespace (and not attached): [1] tools_3.3.0 Cheers, Josh O'Brien __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] For integer vectors, `as(x, "numeric")` has no effect.
On Tue, Jan 5, 2016 at 1:31 AM, Martin Maechler
wrote:
>>>>>> Josh O'Brien
>>>>>> on Mon, 4 Jan 2016 16:16:51 -0800 writes:
>
> > On Dec 19, 2015, at 3:32 AM, Martin Maechler stat.math.ethz.ch> wrote:
>
> >>>>>>> Martin Maechler on
> >>>>>>> Sat, 12 Dec 2015 10:32:51 +0100 writes:
> >>
> >>>>>>> John Chambers on Fri, 11 Dec
> >>>>>>> 2015 10:11:05 -0800 writes:
> >>
> >>>> Somehow, the most obvious fixes are always
> >>>> back-incompatible these days. The example intrigued
> >>>> me, so I looked into it a bit (should have been doing
> >>>> something else, but )
> >>
> >>>> You're right that this is the proverbial
> >>>> thin-edge-of-the-wedge.
> >>
> >>>> The problem is in setDataPart(), which will be called
> >>>> whenever a class extends one of the vector types.
> >>
> >>>> It does as(value, dataClass) The key point is that the
> >>>> third argument to as(), strict=TRUE by default. So,
> >>>> yes, the change will cause all integer vectors to
> >>>> become double when the class extends "numeric".
> >>>> Generally, strict=TRUE makes sense here and of course
> >>>> changing THAT would open up yet more incompatibilities.
> >>
> >>>> For back compatibility, one would have to have some
> >>>> special code in setDataPart() for the case of
> >>>> integer/numeric.
> >>
> >>>> John
> >>
> >>>> (Historically, the original sin was probably not making
> >>>> a distinction between "numeric" as a virtual class and
> >>>> "double" as a type/class.)
> >>
> >>> Yes, indeed. In the mean time, I've seen more cases
> >>> where "the change will cause all integer vectors to
> >>> become double when the class extends "numeric". seems
> >>> detrimental.
> >>
> >>> OTOH, I still think we could go in the right direction
> >>> --- hopefully along the wishes of bioconductor S4
> >>> development, see Martin Morgan's e-mail:
> >>
> >>> [This is all S4 - only; should not much affect base R /
> >>> S3] Currently, "integer" is a subclass of "numeric" and
> >>> so the "integer become double" part seems unwanted to
> >>> me. OTOH, it would really make sense to more formally
> >>> have the basic subclasses of "numeric" to be "integer"
> >>> and "double", and to let as(*, "double") to become
> >>> different to as(*, "numeric") [Again, this is just for
> >>> the S4 classes and as() coercions, *not* e.g. for
> >>> as.numeric() / as.double() !]
> >>
> >>> In the DEPRECATED part of the NEWS for R 2.7.0 (April
> >>> 2008) we have had
> >>
> >>> o The S4 pseudo-classes "single" and double have been
> >>> removed. (The S4 class for a REALSXP is "numeric": for
> >>> back-compatibility as(x, "double") coerces to
> >>> "numeric".)
> >>
> >>> I think the removal of "single" was fine, but in
> >>> hindsight, maybe the removal of "double" -- which was
> >>> partly broken then -- possibly could rather have been a
> >>> fixup of "double" along the following
> >>
> >>> Current "thought experiment proposal" :
> >>
> >>> 1) "numeric" := {"integer", "double"} { class -
> >>> subclasses } 2) as(1L, "numeric") continues to return 1L
> >>> .. since integer is one case of "numeric" 3) as(1L,
> >>> "double") newly returns 1.0 {and in fact would be
> >>> "equivalent" to as.double(1L)}
> >>
> >>> After the above change, S4 as(*, "double") would
> >>> correspond to S3 as.double but as(*, "numeric") would
> >>>
Re: [Rd] For integer vectors, `as(x, "numeric")` has no effect.
On Dec 19, 2015, at 3:32 AM, Martin Maechler wrote:
>> Martin Maechler
>>on Sat, 12 Dec 2015 10:32:51 +0100 writes:
>
>> John Chambers
>>on Fri, 11 Dec 2015 10:11:05 -0800 writes:
>
>>> Somehow, the most obvious fixes are always back-incompatible these days.
>>> The example intrigued me, so I looked into it a bit (should have been doing
>>> something else, but )
>
>>> You're right that this is the proverbial thin-edge-of-the-wedge.
>
>>> The problem is in setDataPart(), which will be called whenever a class
>>> extends one of the vector types.
>
>>> It does
>>> as(value, dataClass)
>>> The key point is that the third argument to as(), strict=TRUE by default.
>>> So, yes, the change will cause all integer vectors to become double when
>>> the class extends "numeric". Generally, strict=TRUE makes sense here and
>>> of course changing THAT would open up yet more incompatibilities.
>
>>> For back compatibility, one would have to have some special code in
>>> setDataPart() for the case of integer/numeric.
>
>>> John
>
>>> (Historically, the original sin was probably not making a distinction
>>> between "numeric" as a virtual class and "double" as a type/class.)
>
>> Yes, indeed. In the mean time, I've seen more cases where
>> "the change will cause all integer vectors to become double when the class
>> extends "numeric".
>> seems detrimental.
>
>> OTOH, I still think we could go in the right direction ---
>> hopefully along the wishes of bioconductor S4 development, see
>> Martin Morgan's e-mail:
>
>> [This is all S4 - only; should not much affect base R / S3]
>> Currently, "integer" is a subclass of "numeric" and so the
>> "integer become double" part seems unwanted to me.
>> OTOH, it would really make sense to more formally
>> have the basic subclasses of "numeric" to be "integer" and "double",
>> and to let as(*, "double") to become different to as(*, "numeric")
>> [Again, this is just for the S4 classes and as() coercions, *not* e.g.
>> for as.numeric() / as.double() !]
>
>> In the DEPRECATED part of the NEWS for R 2.7.0 (April 2008) we
>> have had
>
>> oThe S4 pseudo-classes "single" and double have been removed.
>> (The S4 class for a REALSXP is "numeric": for back-compatibility
>> as(x, "double") coerces to "numeric".)
>
>> I think the removal of "single" was fine, but in hindsight,
>> maybe the removal of "double" -- which was partly broken then --
>> possibly could rather have been a fixup of "double" along the
>> following
>
>> Current "thought experiment proposal" :
>
>> 1) "numeric" := {"integer", "double"} { class - subclasses }
>> 2) as(1L, "numeric") continues to return 1L .. since integer is
>> one case of "numeric"
>> 3) as(1L, "double") newly returns 1.0 {and in fact would be
>> "equivalent" to as.double(1L)}
>
>> After the above change, S4 as(*, "double") would correspond to S3 as.double
>> but as(*, "numeric") would continue to differ from
>> as.numeric(*), the former *not* changing integers to double.
>
>> Martin
>
> Also note that e.g.
>
>class(pi)would return "double" instead of "numeric"
>
> and this will break all the bad programming style usages of
>
> if(class(x) == "numeric")
>
> which I tend to see in gazillions of user and even package codes
> This bad (aka error prone !) because "correct" usage would be
>
> if(inherits(x, "numeric"))
>
> and that of course would *not* break after the change above.
>
> - - - -
>
> A week later, I'm still pretty convinced it would be worth going
> in the direction proposed above.
>
> But I was actually hoping for some encouragement or "mental support"...
> or then to hear why you think the proposition is not good or not
> viable ...
>
>
I really like Martin Maechler's "thought experiment proposal", but (based
partly on the reception its gotten) figure I mustn't be appreciating
the complications
it would introduce..
That said, if it's decided to just make a smaller fix of as(x, "numeric"),
might it be better to make the change at the C level, to R_set_class
in $RHOME/src/main/coerce.c?
Here's the 'offending' bit of R_set_class (the C-code implementing the
R function `class<-`), which treats an INTSXP in the same way as a
REALSXP, breaking before it get coerced to REALSXP:
else if(!strcmp("numeric", valueString)) {
setAttrib(obj, R_ClassSymbol, R_NilValue);
if(IS_S4_OBJECT(obj)) /* NULL class is only valid for S3 objects */
do_unsetS4(obj, value);
switch(TYPEOF(obj)) {
case INTSXP: case REALSXP: break;
default: PROTECT(obj = coerceVector(obj, REALSXP));
nProtect++;
}
}
Simply deleting "case INTSXP: " will let integer vectors pass
through and get converted to REALSXP by coerceVector().
This approach has a couple of advantages that (unless I'm missing
something) make it seem relatively clean:
- It requires no additional explicit S4 "coerce" method for
signature c("integer", "numeric").
- It simultaneously fi
[Rd] For integer vectors, `as(x, "numeric")` has no effect.
Here's the surprising behavior:
x <- 1L
xx <- as(x, "numeric")
class(xx)
## [1] "integer"
It occurs because the call to `as(x, "numeric")` dispatches the coerce
S4 method for the signature `c("integer", "numeric")`, whose body is
copied in below.
function (from, to = "numeric", strict = TRUE)
if (strict) {
class(from) <- "numeric"
from
} else from
This in turn does nothing, even when strict=TRUE, because that
assignment to class "numeric" has no effect:
x <- 10L
class(x) <- "numeric"
class(x)
[1] "integer"
Is this the desired behavior for `as(x, "numeric")`?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How best to get around shadowing of executables by system()'s prepending of directories to Windows' PATH?
On Mon, May 18, 2015 at 10:29 AM, Josh O'Brien wrote:
> My question:
>
> On Windows, R's system() command prepends several directories to those
> in the Windows Path variable.
>
> From ?system
>
> The search path for 'command' may be system-dependent: it will
> include the R 'bin' directory, the working directory and the
> Windows system directories before 'PATH'.
>
> This shadows any executables on the Path that share a name with, for
> example, one of the Windows commands.
>
> What should I do when I'd really like (the equivalent of) a call
> passed to system() that would be executed using the same Path that
> you'd get if working directly at the Windows command line? Is there a
It appears that "use shell() instead of system()" is a reasonable, if
narrow, answer to this question.
Doing:
shell("convert -density 100x100 a.pdf b.png")
constructs (and then uses system() to call) the following command:
"C:\\Windows\\system32\\cmd.exe /c convert -density 100x100 a.pdf b.png"
which gives you just what you'd get if typing directly at the command line.
> recommended workaround for situtations like this? (It _seems_ like it
> would be handy if system() et al. included an additional argument that
> optionally disabled the prepending of those extra directories, to give
> Windows users full control of the path seen by system(). Would adding
> such an argument have undesirable ramifications?)
>
>
> Motivation and reproducible example:
>
> I'm motivated here by a desire to use the function plotdiff() from
> Paul Murrell's gridGraphics package on my Windows laptop. Getting
> that to work will require a few code fixes, of which the masking of
> ImageMagick's convert.exe by that in the C:/Windows/System32 seems to
> be the most challenging. plotdiff() relies on system2() calls to
> ImageMagick's 'convert' function, as well as a call to
> Sys.which(c("convert", "compare")) that tests for the presence of
> ImageMagick on the Path. Even if ImageMagick is placed early on the
> Path, though, both calls to Sys.which() and system2() find Windows'
> convert command (which "Converts FAT volumes to NTFS") rather than
> ImageMagick's convert.
>
>
> Here's a reproducible example that shows what I'm seeing:
>
> ## In R, make a pdf
> pdf("a.pdf")
> plot(rnorm(99), col="red")
> dev.off()
>
> ## At Windows cmd command line
> where convert
> ## C:\Program Files\ImageMagick-6.8.8-Q16\convert.exe
> ## C:\Windows\System32\convert.exe
> convert -density 100x100 a.pdf a.png
>
> ## From R
>
> ## Unqualified references to convert find the 'wrong' one
> Sys.which("convert")
> ## convert
> ## "C:\\Windows\\system32\\convert.exe"
> system2("convert", "-density 100x100 a.pdf b.png")
> ## Invalid Parameter - 100x100
> ## Warning message:
> ## running command '"convert" -density 100x100 a.pdf b.png' had status 4
>
> ## A fully qualified reference does work
> system2("C:/Program Files/ImageMagick-6.8.8-Q16/convert",
> "-density 100x100 a.pdf b.png")
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How best to get around shadowing of executables by system()'s prepending of directories to Windows' PATH?
My question:
On Windows, R's system() command prepends several directories to those
in the Windows Path variable.
>From ?system
The search path for 'command' may be system-dependent: it will
include the R 'bin' directory, the working directory and the
Windows system directories before 'PATH'.
This shadows any executables on the Path that share a name with, for
example, one of the Windows commands.
What should I do when I'd really like (the equivalent of) a call
passed to system() that would be executed using the same Path that
you'd get if working directly at the Windows command line? Is there a
recommended workaround for situtations like this? (It _seems_ like it
would be handy if system() et al. included an additional argument that
optionally disabled the prepending of those extra directories, to give
Windows users full control of the path seen by system(). Would adding
such an argument have undesirable ramifications?)
Motivation and reproducible example:
I'm motivated here by a desire to use the function plotdiff() from
Paul Murrell's gridGraphics package on my Windows laptop. Getting
that to work will require a few code fixes, of which the masking of
ImageMagick's convert.exe by that in the C:/Windows/System32 seems to
be the most challenging. plotdiff() relies on system2() calls to
ImageMagick's 'convert' function, as well as a call to
Sys.which(c("convert", "compare")) that tests for the presence of
ImageMagick on the Path. Even if ImageMagick is placed early on the
Path, though, both calls to Sys.which() and system2() find Windows'
convert command (which "Converts FAT volumes to NTFS") rather than
ImageMagick's convert.
Here's a reproducible example that shows what I'm seeing:
## In R, make a pdf
pdf("a.pdf")
plot(rnorm(99), col="red")
dev.off()
## At Windows cmd command line
where convert
## C:\Program Files\ImageMagick-6.8.8-Q16\convert.exe
## C:\Windows\System32\convert.exe
convert -density 100x100 a.pdf a.png
## From R
## Unqualified references to convert find the 'wrong' one
Sys.which("convert")
## convert
## "C:\\Windows\\system32\\convert.exe"
system2("convert", "-density 100x100 a.pdf b.png")
## Invalid Parameter - 100x100
## Warning message:
## running command '"convert" -density 100x100 a.pdf b.png' had status 4
## A fully qualified reference does work
system2("C:/Program Files/ImageMagick-6.8.8-Q16/convert",
"-density 100x100 a.pdf b.png")
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Can R for Windows be built outside of the top-level source directory?
The "R-admin" manual describes how to build R from outside of the top-level source directory on a *NIX machine (http://cran.r-project.org/doc/manuals/r-release/R-admin.html#Simple-compilation), but it makes no analagous mention of a way to do so under Windows. Since the build process in Windows is so different (not using configure, for instance, and typically being performed from within $R_SOURCES/src/gnuwin32/), *and* since the "R-admin" guide makes no mention of it, my guess is that it's not easily possible. But I'd love to learn otherwise, or even just get a definitive "no". Thanks, Josh __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Avoid entering {} evaluation in debugger
Vitalie Spinu wrote
> Hi,
>
>f1 <- function(){
>browser()
>print("aaa")
>}
>
>f2 <- function(){
>a <- 12
>eval(envir = parent.frame(),
> bquote({
>b <- .(a)
>}))
>}
>
>
> Now do,
>
> f1()
>
> and enter n RET and then {1+2}:
>
> Browse[2]> {1 + 2}
> debug at #1: 1 + 2
> Browse[3]>
>
>
> {} is now being debugged. This was never bothering me till I got into
> unexpected behavior with functions that evaluate in the current
> environment.
>
> For example calling f2() starts debugging b <- 12:
>
> Browse[2]> f2()
> debug: b <- 12
> Browse[4]>
>
> Is there some sort of dont-debug-me flag that I can set in f2 to avoid
> this behavior?
>
> Thanks,
> Vitalie
>f1 <- function(){
>browser()
>print("aaa")
>}
>
>f2 <- function(){
>a <- 12
>eval(envir = parent.frame(),
> bquote({
>b <- .(a)
>}))
>}
>
>
> R Under development (unstable) (2013-04-19 r62622)
> Platform: i686-pc-linux-gnu (32-bit)
>
> locale:
> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
> [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> [7] LC_PAPER=C LC_NAME=C
> [9] LC_ADDRESS=C LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> __
> R-devel@
> mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
I believe that your sessionInfo() results leave out the most important
detail, which is that you're running R from Emacs/ESS. Is that right?
I get this same, occasionally annoying, behavior when using ESS 13.03 and
Emacs 23.3.1, but not from Rgui, Rterm, etc.
Haven't brought it up there, but this would obviously be a good topic for
ESS-help.
Cheers,
Josh
--
View this message in context:
http://r.789695.n4.nabble.com/Avoid-entering-evaluation-in-debugger-tp4666350p4666437.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] Why does typeof() modify an object's "named" field?
Hello, Doing typeof() on an object appears to reset the "named" field in its sxpinfo header to 2, which can change the way that subsequent subassignment operations are carried out: X <- 1:5e7 .Internal(inspect(X)) # @4eeb0008 13 INTSXP g0c7 [NAM(1)] (len=5000, tl=0) 1,2,3,4,5,... system.time(X[1] <- 9L) #user system elapsed # 0 0 0 typeof(X) .Internal(inspect(X)) # @4eeb0008 13 INTSXP g1c7 [MARK,NAM(2)] (len=5000, tl=0) 9,2,3,4,5,... system.time(X[2] <- 9L) #user system elapsed #0.160.080.23 Some other functions that query the nature of an object (e.g. class(), length(), attributes()) do not modify the object's "named" field. Is there a reason that typeof() should? (Possibly of interest is this somewhat related thread on Stack Overflow: http://stackoverflow.com/questions/15559387/operator-in-rstudio-and-r/15559956#15559956 ). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-lang edit: deparse(1:2) is no longer a good example of the R parser's non-invertibility
Hello, Apparently thanks to improvements to the R parser, this example from section 6.1 of the R Language Definition no longer holds. > deparse(quote(c(1, 2))) [1] "c(1, 2)" > deparse(1:2) [1] "c(1, 2)" Even running R-2.14.2, I get instead > deparse(1:2) [1] "1:2" __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to build a list with missing values? What is missing, anyway?
>Say I have argnames <- c("a", "b", "c").
>From that I want to construct the equivalent of alist(a=, b=, c=).
Here's a one liner that'll do that for you:
argnames <- letters[1:3]
setNames(rep(list(bquote()), length(argnames)), argnames)
- Josh
--
View this message in context:
http://r.789695.n4.nabble.com/How-to-build-a-list-with-missing-values-What-is-missing-anyway-tp4644957p4644965.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] Minor edit to R-ints doc will be needed for R-2.15.2: axis() no longer uses .Internal()
Hello, The second paragraph of Chapter 2: .Internal vs .Primitive of R-ints uses axis() as an example of a function that uses .Internal(). Here's the quote: > Functions using .Internal() wrapped in a closure are in general preferred as > this ensures > standard handling of named and default arguments. For example, axis is > defined as > > axis <- function(side, at = NULL, labels = NULL, ...) > .Internal(axis(side, at, labels, ...)) As of R-2.15.2, though, this will no longer be true; as noted in the Code Migration section of R-devel NEWS file: > The C code underlying base graphics has been migrated to the graphics package > (and hence no longer uses .Internal() calls). So, a different example may be needed. (Please let me know if a message of this type is better directed somewhere else, or if it should wait until after some milestone in the development cycle.) Thanks, Josh __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
