Re: [Rd] URL checks
Sorry, Martin, but I've NOT commented on this matter, unless someone has been impersonating me. Someone else? JN On 2021-01-11 4:51 a.m., Martin Maechler wrote: >> Viechtbauer, Wolfgang (SP) >> on Fri, 8 Jan 2021 13:50:14 + writes: > > > Instead of a separate file to store such a list, would it be an idea to > add versions of the \href{}{} and \url{} markup commands that are skipped by > the URL checks? > > Best, > > Wolfgang > > I think John Nash and you misunderstood -- or then I > misunderstood -- the original proposal: > > I've been understanding that there should be a "central repository" of URL > exceptions that is maintained by volunteers. > > And rather *not* that package authors should get ways to skip > URL checking.. > > Martin > > > >> -Original Message- > >> From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of > Spencer > >> Graves > >> Sent: Friday, 08 January, 2021 13:04 > >> To: r-devel@r-project.org > >> Subject: Re: [Rd] URL checks > >> > >> I also would be pleased to be allowed to provide "a list of known > >> false-positive/exceptions" to the URL tests. I've been challenged > >> multiple times regarding URLs that worked fine when I checked them. We > >> should not be required to do a partial lobotomy to pass R CMD check ;-) > >> > >> Spencer Graves > >> > >> On 2021-01-07 09:53, Hugo Gruson wrote: > >>> > >>> I encountered the same issue today with > https://astrostatistics.psu.edu/. > >>> > >>> This is a trust chain issue, as explained here: > >>> https://whatsmychaincert.com/?astrostatistics.psu.edu. > >>> > >>> I've worked for a couple of years on a project to increase HTTPS > >>> adoption on the web and we noticed that this type of error is very > >>> common, and that website maintainers are often unresponsive to > requests > >>> to fix this issue. > >>> > >>> Therefore, I totally agree with Kirill that a list of known > >>> false-positive/exceptions would be a great addition to save time to > both > >>> the CRAN team and package developers. > >>> > >>> Hugo > >>> > >>> On 07/01/2021 15:45, Kirill Müller via R-devel wrote: > One other failure mode: SSL certificates trusted by browsers that are > not installed on the check machine, e.g. the "GEANT Vereniging" > certificate from https://relational.fit.cvut.cz/ . > > K > > On 07.01.21 12:14, Kirill Müller via R-devel wrote: > > Hi > > > > The URL checks in R CMD check test all links in the README and > > vignettes for broken or redirected links. In many cases this > improves > > documentation, I see problems with this approach which I have > > detailed below. > > > > I'm writing to this mailing list because I think the change needs to > > happen in R's check routines. I propose to introduce an "allow-list" > > for URLs, to reduce the burden on both CRAN and package maintainers. > > > > Comments are greatly appreciated. > > > > Best regards > > > > Kirill > > > > # Problems with the detection of broken/redirected URLs > > > > ## 301 should often be 307, how to change? > > > > Many web sites use a 301 redirection code that probably should be a > > 307. For example, https://www.oracle.com and https://www.oracle.com/ > > both redirect to https://www.oracle.com/index.html with a 301. I > > suspect the company still wants oracle.com to be recognized as the > > primary entry point of their web presence (to reserve the right to > > move the redirection to a different location later), I haven't > > checked with their PR department though. If that's true, the > redirect > > probably should be a 307, which should be fixed by their IT > > department which I haven't contacted yet either. > > > > $ curl -i https://www.oracle.com > > HTTP/2 301 > > server: AkamaiGHost > > content-length: 0 > > location: https://www.oracle.com/index.html > > ... > > > > ## User agent detection > > > > twitter.com responds with a 400 error for requests without a user > > agent string hinting at an accepted browser. > > > > $ curl -i https://twitter.com/ > > HTTP/2 400 > > ... > > ...Please switch to a supported browser.. > > > > $ curl -s -i https://twitter.com/ -A "Mozilla/5.0 (X11; Ubuntu; > Linux > > x86_64; rv:84.0) Gecko/20100101 Firefox/84.0" | head -n 1 > > HTTP/2 200 > > > > # Impact > > > > While the latter problem *could* be fixed by
Re: [Rd] [External] brief update on the pipe operator in R-devel
After some discussions we've settled on a syntax of the form mtcars |> subset(cyl == 4) |> d => lm(mpg ~ disp, data = d) to handle cases where the pipe lhs needs to be passed to an argument other than the first of the function called on the rhs. This seems a to be a reasonable balance between making these non-standard cases easy to see but still easy to write. This is now committed to R-devel. Best, luke On Tue, 22 Dec 2020, luke-tier...@uiowa.edu wrote: It turns out that allowing a bare function expression on the right-hand side (RHS) of a pipe creates opportunities for confusion and mistakes that are too risky. So we will be dropping support for this from the pipe operator. The case of a RHS call that wants to receive the LHS result in an argument other than the first can be handled with just implicit first argument passing along the lines of mtcars |> subset(cyl == 4) |> (\(d) lm(mpg ~ disp, data = d))() It was hoped that allowing a bare function expression would make this more convenient, but it has issues as outlined below. We are exploring some alternatives, and will hopefully settle on one soon after the holidays. The basic problem, pointed out in a comment on Twitter, is that in expressions of the form 1 |> \(x) x + 1 -> y 1 |> \(x) x + 1 |> \(y) x + y everything after the \(x) is parsed as part of the body of the function. So these are parsed along the lines of 1 |> \(x) { x + 1 -> y } 1 |> \(x) { x + 1 |> \(y) x + y } In the first case the result is assigned to a (useless) local variable. Someone writing this is more likely to have intended to assign the result to a global variable, as this would: (1 |> \(x) x + 1) -> y In the second case the 'x' in 'x + y' refers to the local variable 'x' in the first RHS function. Someone writing this is more likely to have meant (1 |> \(x) x + 1) |> \(y) x + y with 'x' in 'x + y' now referring to a global variable: > x <- 2 > 1 |> \(x) x + 1 |> \(y) x + y [1] 3 > (1 |> \(x) x + 1) |> \(y) x + y [1] 4 These issues arise with any approach in R that allows a bare function expression on the RHS of a pipe operation. It also arises in other languages with pipe operators. For example, here is the last example in Julia: julia> x = 2 2 julia> 1 |> x -> x + 1 |> y -> x + y 3 julia> ( 1 |> x -> x + 1 ) |> y -> x + y 4 Even though proper use of parentheses can work around these issues, the likelihood of making mistakes that are hard to track down is too high. So we will disallow the use of bare function expressions on the right hand side of a pipe. Best, luke -- 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
Re: [Rd] [External] brief update on the pipe operator in R-devel
On Tue, 12 Jan 2021 at 20:23, wrote: > > After some discussions we've settled on a syntax of the form > > mtcars |> subset(cyl == 4) |> d => lm(mpg ~ disp, data = d) > > to handle cases where the pipe lhs needs to be passed to an argument > other than the first of the function called on the rhs. This seems a > to be a reasonable balance between making these non-standard cases > easy to see but still easy to write. This is now committed to R-devel. Interesting. Is the use of "d =>" restricted to pipelines? In other words, I think that it shouldn't be equivalent to "function(d)", i.e., that this: x <- d => lm(mpg ~ disp, data = d) shouldn't work. -- Iñaki Úcar __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] brief update on the pipe operator in R-devel
On 12 January 2021 at 20:38, Iñaki Ucar wrote: | On Tue, 12 Jan 2021 at 20:23, wrote: | > | > After some discussions we've settled on a syntax of the form | > | > mtcars |> subset(cyl == 4) |> d => lm(mpg ~ disp, data = d) | > | > to handle cases where the pipe lhs needs to be passed to an argument | > other than the first of the function called on the rhs. This seems a | > to be a reasonable balance between making these non-standard cases | > easy to see but still easy to write. This is now committed to R-devel. | | Interesting. Is the use of "d =>" restricted to pipelines? In other | words, I think that it shouldn't be equivalent to "function(d)", i.e., | that this: | | x <- d => lm(mpg ~ disp, data = d) | | shouldn't work. Looks like your wish was already granted: > mtcars |> subset(cyl == 4) |> d => lm(mpg ~ disp, data = d) Call: lm(formula = mpg ~ disp, data = subset(mtcars, cyl == 4)) Coefficients: (Intercept) disp 40.872 -0.135 > d => lm(mpg ~ disp, data = d) Error in `=>`(d, lm(mpg ~ disp, data = d)) : could not find function "=>" > x <- d => lm(mpg ~ disp, data = d) Error in `=>`(d, lm(mpg ~ disp, data = d)) : could not find function "=>" > Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] brief update on the pipe operator in R-devel
'=>' can be defined as a function. E.g., it could be the logical "implies" function: > `=>` <- function(x, y) !x | y > TRUE => FALSE [1] FALSE > FALSE => TRUE [1] TRUE It might be nice then to have deparse() display it as an infix operator instead of the current prefix: > deparse(quote(p => q)) [1] "`=>`(p, q)" There was a user who recently wrote asking for an infix operator like -> or => that would deparse nicely for use in some sort of model specification. When used with |>, the parser will turn the |> and => into an ordinary looking function call so deparsing is irrelevant. > deparse(quote(x |> tmp => f(7,arg2=tmp))) [1] "f(7, arg2 = x)" -Bill On Tue, Jan 12, 2021 at 12:01 PM Dirk Eddelbuettel wrote: > > On 12 January 2021 at 20:38, Iñaki Ucar wrote: > | On Tue, 12 Jan 2021 at 20:23, wrote: > | > > | > After some discussions we've settled on a syntax of the form > | > > | > mtcars |> subset(cyl == 4) |> d => lm(mpg ~ disp, data = d) > | > > | > to handle cases where the pipe lhs needs to be passed to an argument > | > other than the first of the function called on the rhs. This seems a > | > to be a reasonable balance between making these non-standard cases > | > easy to see but still easy to write. This is now committed to R-devel. > | > | Interesting. Is the use of "d =>" restricted to pipelines? In other > | words, I think that it shouldn't be equivalent to "function(d)", i.e., > | that this: > | > | x <- d => lm(mpg ~ disp, data = d) > | > | shouldn't work. > > Looks like your wish was already granted: > > > mtcars |> subset(cyl == 4) |> d => lm(mpg ~ disp, data = d) > > Call: > lm(formula = mpg ~ disp, data = subset(mtcars, cyl == 4)) > > Coefficients: > (Intercept) disp >40.872 -0.135 > > > d => lm(mpg ~ disp, data = d) > Error in `=>`(d, lm(mpg ~ disp, data = d)) : could not find function "=>" > > x <- d => lm(mpg ~ disp, data = d) > Error in `=>`(d, lm(mpg ~ disp, data = d)) : could not find function "=>" > > > > Dirk > > -- > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] brief update on the pipe operator in R-devel
On 12/01/2021 3:52 p.m., Bill Dunlap wrote: '=>' can be defined as a function. E.g., it could be the logical "implies" function: > `=>` <- function(x, y) !x | y > TRUE => FALSE [1] FALSE > FALSE => TRUE [1] TRUE It might be nice then to have deparse() display it as an infix operator instead of the current prefix: > deparse(quote(p => q)) [1] "`=>`(p, q)" There was a user who recently wrote asking for an infix operator like -> or => that would deparse nicely for use in some sort of model specification. The precedence of it as an operator is determined by what makes sense in the pipe construction. Currently precedence appears to be :: ::: access variables in a namespace $ @ component / slot extraction [ [[indexing ^ exponentiation (right to left) - + unary minus and plus : sequence operator %any% special operators (including %% and %/%) * / multiply, divide + - (binary) add, subtract < > <= >= == != ordering and comparison ! negation & &&and | ||or => PIPE BIND |> PIPE ~ as in formulae -> ->> rightwards assignment <- <<- assignment (right to left) = assignment (right to left) ? help (unary and binary) (Most of this is taken from ?Syntax, but I added the new operators in based on the gram.y file). So A & B => C & D would appear to be parsed as (A & B) => (C & D) I think this also makes sense; do you? Duncan Murdoch When used with |>, the parser will turn the |> and => into an ordinary looking function call so deparsing is irrelevant. > deparse(quote(x |> tmp => f(7,arg2=tmp))) [1] "f(7, arg2 = x)" -Bill On Tue, Jan 12, 2021 at 12:01 PM Dirk Eddelbuettel wrote: On 12 January 2021 at 20:38, Iñaki Ucar wrote: | On Tue, 12 Jan 2021 at 20:23, wrote: | > | > After some discussions we've settled on a syntax of the form | > | > mtcars |> subset(cyl == 4) |> d => lm(mpg ~ disp, data = d) | > | > to handle cases where the pipe lhs needs to be passed to an argument | > other than the first of the function called on the rhs. This seems a | > to be a reasonable balance between making these non-standard cases | > easy to see but still easy to write. This is now committed to R-devel. | | Interesting. Is the use of "d =>" restricted to pipelines? In other | words, I think that it shouldn't be equivalent to "function(d)", i.e., | that this: | | x <- d => lm(mpg ~ disp, data = d) | | shouldn't work. Looks like your wish was already granted: > mtcars |> subset(cyl == 4) |> d => lm(mpg ~ disp, data = d) Call: lm(formula = mpg ~ disp, data = subset(mtcars, cyl == 4)) Coefficients: (Intercept) disp 40.872 -0.135 > d => lm(mpg ~ disp, data = d) Error in `=>`(d, lm(mpg ~ disp, data = d)) : could not find function "=>" > x <- d => lm(mpg ~ disp, data = d) Error in `=>`(d, lm(mpg ~ disp, data = d)) : could not find function "=>" > Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel [[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