Re: [Rd] URL checks

2021-01-12 Thread J C Nash


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

2021-01-12 Thread luke-tierney

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

2021-01-12 Thread Iñaki Ucar
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

2021-01-12 Thread Dirk Eddelbuettel


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

2021-01-12 Thread Bill Dunlap
'=>' 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

2021-01-12 Thread Duncan Murdoch

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