[Rd] capabilities(), was [R-pkg-devel] ... No protocol specified (OS X only)
Diverting (from R-package-devel) to R-devel, as it is now about
extending R :
> Jeroen Ooms on Thu, 20 Feb 2020 20:34:14 +0100 writes:
> On Tue, Feb 18, 2020 at 1:29 AM Dominic Comtois
> wrote:
>>
>> Hello,
>>
>> On my package's check results (
>> https://cran.r-project.org/web/checks/check_results_summarytools.html), I
>> see a bunch of warnings with "No protocol specified" messages. This
happens
>> only with OS X, and I can't reproduce them when actually building on a
Mac,
>> nor with rhub::check_on_macos(). I can't really make sense out of them,
and
>> they are all over the place. Can they simply be ignored?
> This happens when your package calls capabilities(), which as a side
> effect initiates xquartz. It seems the MacOS server has certain
> permission restrictions that cause X11 to print this warning.
> I think you can safely ignore it.
Thank you, Jeroen.
The function is currently defined (in base/R/New-Internal.R ) as
capabilities <- function(what = NULL)
{
z <- .Internal(capabilities())
if(!is.null(what))
z <- z[match(what, names(z), 0L)]
if(.Platform$OS.type == "windows") return(z)
## Now we need to deal with any NA entries if X11 is unknown.
nas <- names(z[is.na(z)])
if(any(nas %in% c("X11", "jpeg", "png", "tiff"))) {
## This might throw an X11 error
z[nas] <- tryCatch(.Internal(capabilitiesX11()),
error = function(e) FALSE)
}
z
}
and we could easily add a 2nd argument, say 'Xchk = TRUE' like
this
capabilities <- function(what = NULL, Xchk = TRUE)
{
z <- .Internal(capabilities())
if(!is.null(what))
z <- z[match(what, names(z), 0L)]
if(.Platform$OS.type == "windows") return(z)
if(Xchk) {
## Now we need to deal with any NA entries if X11 is unknown.
nas <- names(z[is.na(z)])
if(any(nas %in% c("X11", "jpeg", "png", "tiff"))) {
## This might throw an X11 error
z[nas] <- tryCatch(.Internal(capabilitiesX11()),
error = function(e) FALSE)
}
}
z
}
and as an afterthought rather improve the argument's default, from
Xchk = TRUE
to
Xchk = is.null(what) ||
any(c("X11", "jpeg", "png", "tiff") %in% what)
(or similar smart defaults).
Then, e.g., capabilities("long.double") or
capabilities("profmem")
would never trigger that X11-lookup and neither would
cap <- capabilities(X = FALSE)
where you'd typically get an NA for cap[["X11"]]
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] Support for Dashes in the Raw String Delimiter
r"{single quote ' and double quote " and one at the end "}"
[1] "single quote ' and double quote \" and one at the end \""
See ?Quotes for details.
The C++ syntax, on which the R syntax is based, is strictly more
powerful than the Python approach: it allows a raw string to contain
_any_ sequence of characters by adjusting the delimiter. To simplify
the implementation R only allows dashes for adjustment, but that is
sufficient:
r"{'`"}"
[1] "'`\""
r"-{r"{'`"}"}-"
[1] "r\"{'`\"}\""
Best,
luke
On Fri, 21 Feb 2020, Juan Telleria Ruiz de Aguirre wrote:
Dear R Developers,
As regards "Support for Dashes in the Raw String Delimiter" from commit:
https://github.com/wch/r-source/commit/4d4781ad19890193d5eb458d71f18d7e53ee73c5
Would it be possible to support in addition to r"" Syntax, for not escaping
backlash character in strings, also support """ """ (Python Like Syntax),
for also allowing to have within the character string the closing sequence
" symbol?
See Python's article on string literals for further information:
https://docs.python.org/2.0/ref/strings.html
Thanks!
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] trivial typo in man page Quote.Rd
Attn: someone on R-core:
"ran" should be "can".
Also, thanks for this feature!
Index: Quotes.Rd
===
--- Quotes.Rd (revision 77845)
+++ Quotes.Rd (working copy)
@@ -74,7 +74,7 @@
Raw character constants are also available using a syntax similar to
the one used in C++: \code{r"(...)"} with \code{...} any character
sequence, except that it must not contain the closing sequence
- \samp{)"}. The delimiter pairs \code{[]} and \code{\{\}} ran also be
+ \samp{)"}. The delimiter pairs \code{[]} and \code{\{\}} can also be
used. For additional flexibility, a number of dashes can be placed
between the opening quote and the opening delimiter, as long as the same
number of dashes appear between the closing delimiter and the closing
quote.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] trivial typo in man page Quote.Rd
> Ben Bolker
> on Fri, 21 Feb 2020 10:53:32 -0500 writes:
> Attn: someone on R-core:
> "ran" should be "can".
> Also, thanks for this feature!
> Index: Quotes.Rd
> ===
> --- Quotes.Rd (revision 77845)
> +++ Quotes.Rd (working copy)
> @@ -74,7 +74,7 @@
> Raw character constants are also available using a syntax similar to
> the one used in C++: \code{r"(...)"} with \code{...} any character
> sequence, except that it must not contain the closing sequence
> - \samp{)"}. The delimiter pairs \code{[]} and \code{\{\}} ran also be
> + \samp{)"}. The delimiter pairs \code{[]} and \code{\{\}} can also be
>
Thank you, Ben. Commited now.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dimnames incoherence?
If we change the behavior NULL--[[--assignment from
`[[<-`(NULL, 1, "a" ) # gives "a" (*not* a list)
to
`[[<-`(NULL, 1, "a" ) # gives list("a")
then we have more consistency there *and* your bug is fixed too.
Of course, in other situations back-compatibility would be
broken as well.
Would that change the result of
L <- list(One=1) ; L$Two[[1]] <- 2
from the current list(One=1,Two=2) to list(One=1, Two=list(2))
and the result of
F <- 1L ; levels(F)[[1]] <- "one"
from structure(1L, levels="one") to structure(1L, levels=list("one"))?
This change would make L$Name[[1]] <- value act like L$Name$one <- value
in cases when L did not have a component named "Name" and value
had length 1.
I have seen users use [[<- where [<- is more appropriate in cases like
this. Should there be a way to generate warnings about the change in
behavior as you've done with other syntax changes?
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Wed, Feb 19, 2020 at 12:59 PM Martin Maechler
wrote:
> > Martin Maechler
> > on Wed, 19 Feb 2020 18:06:57 +0100 writes:
>
> > Serguei Sokol
> > on Wed, 19 Feb 2020 15:21:21 +0100 writes:
>
> >> Hi,
> >> I was bitten by a little incoherence in dimnames assignment or may
> be I
> >> missed some point.
> >> Here is the case. If I assign row names via dimnames(a)[[1]], when
> >> nrow(a)=1 then an error is thrown. But if I do the same when
> nrow(a) > 1
> >> it's OK. Is one of this case works unexpectedly? Both? Neither?
>
> >> a=as.matrix(1)
> >> dimnames(a)[[1]]="a" # error: 'dimnames' must be a list
>
> >> aa=as.matrix(1:2)
> >> dimnames(aa)[[1]]=c("a", "b") # OK
>
> >> In the second case, dimnames(aa) is not a list (like in the first
> case)
> >> but it works.
> >> I would expect that the both work or neither.
>
> > I agree (even though I'm strongly advising people to use '<-'
> > instead of '=');
> > which in this case helps you get the name of the function really
> > involved: It is `dimnames<-` (which is implemented in C
> > entirely, for matrices and other arrays).
>
> As a matter of fact, I wrote too quickly, the culprit here is
> the `[[<-` function (rather than `dimnames<-`),
> which has a special "inconsistency" feature when used to "add to NULL";
> almost surely inherited from S, but I now think we should
> consider dropping on the occasion of aiming for R 4.0.0 :
>
> It's documented in ?Extract that length 1 `[[.]]`-assignment works
> specially for NULL (and dimnames(.) are NULL here).
>
> Note you need to read and understand one of the tougher sections
> in the official 'R Language Definition' Manual,
> section -- 3.4.4 Subset assignment ---
> i.e.,
>
> https://cran.r-project.org/doc/manuals/r-release/R-lang.html#Subset-assignment
>
> notably this part:
>
> Nesting of complex assignments is evaluated recursively
>
> names(x)[3] <- "Three"
>
> is equivalent to
>
> `*tmp*` <- x
> x <- "names<-"(`*tmp*`, value="[<-"(names(`*tmp*`), 3, value="Three"))
> rm(`*tmp*`)
>
> and then, apply this to ourdimnames(a)[[1]] <- "a"
> and so replace
>
> - 'names<-' by 'dimnames<-'
> - '[<-' by '[[<-'
>
> --
>
> Here is the rest of my analysis as valid R code
> {this is not new, Peter Dalgaard had explained this 10 or 20
> years ago to a mailing list audience IIRC} :
>
> ## MM: The problematic behavior (bug ?) is in `[[<-`, not in `dimnames<-` :
>
> `[[<-`(NULL, 1, "a" ) # gives "a" (*not* a list)
> `[[<-`(NULL, 1, c("a","b")) # gives list(c("a","b")) !!
>
> ##==> in C code: in subassign.c [ ~/R/D/r-devel/R/src/main/subassign.c ]
> ##==> function (~ 340 lines)
> ##do_subassign2_dflt(SEXP call, SEXP op, SEXP args, SEXP rho)
> ## has
> "
> line svn r. svn auth. c.o.d.e...
> -- - --
> 1741 4166 ihaka if (isNull(x)) {
> 1742 45446 ripley if (isNull(y)) {
> 1743 76166 luke UNPROTECT(2); /* args, y */
> 1744 4166 ihaka return x;
> 1745 45446 ripley }
> 1746 35680murdoch if (length(y) == 1)
> 1747 68094 luke x = allocVector(TYPEOF(y), 0);
> 1748 24954 ripley else
> 1749 68094 luke x = allocVector(VECSXP, 0);
> 1750 1820 ihaka }
> -- - --
> "
> ## so clearly, in case the value is of length 1, no list is created .
>
> ## For dimnames<- Replacing NULL by list() should be done in both cases
> , and then things work :
> `[[<-`(list(), 1, "a" ) # gives list( "a" )
> `[[<-`(list(), 1, c("a","b")) # gives list(c("a","b")) !!
>
> ## but the problem here is that `[[<-` at this time in the game
> ## does *not* know that it comes from dimnames<-
>
> ---
>
> If we change the behavior NULL--[[--assignment from
>
> `[[<
