Re: [R-pkg-devel] Use of `:::` in a package for code run in a parallel cluster

[Wang, Zhu]

Apologize if I hijack this thread, but the use of ::: is something I was 
puzzled.

I tried Duncan's solution in my R package mypkg, something like:

pkg::callInternal("foo", args)

R CMD check mypkg

* checking dependencies in R code ... WARNING
'::' or ':::' import not declared from: ‘pkg'

I probably missed something here.

Thanks,
Zhu

-Original Message-
From: R-package-devel  On Behalf Of 
Duncan Murdoch
Sent: Sunday, September 13, 2020 3:20 PM
To: David Kepplinger ; R Package Devel 

Subject: Re: [R-pkg-devel] Use of `:::` in a package for code run in a parallel 
cluster

On 13/09/2020 3:51 p.m., David Kepplinger wrote:
> Dear list members,
> 
> I submitted an update for my package and got automatically rejected by 
> the incoming checks (as expected from my own checks) for using `:::` 
> calls to access the package's namespace.
> "There are ::: calls to the package's namespace in its code. A package
> *almost* never needs to use ::: for its own objects:…" (emphasis mine)
> 
> This was a conscious decision on my part as the package runs code on a 
> user-supplied parallel cluster and I consider cluster-exporting the 
> required functions a no-go as it would potentially overwrite objects 
> in the clusters R sessions. The package code does not own the cluster 
> and hence the R sessions. Therefore overwriting objects could 
> potentially lead to unintended behaviour which is opaque to the user and 
> difficult to debug.
> 
> Another solution to circumvent the R CMD check note is to export the 
> functions to the public namespace but mark them as internal. This was 
> also suggested in another thread on this mailing list (c.f. "Etiquette 
> for package submissions that do not automatically pass checks?"). I do 
> not agree with this work-around as the methods are indeed internal and 
> should never be used by users. Exporting truly internal functions for 
> the sake of satisfying R CMD check is a bad argument, in particular if 
> there is a clean, well-documented, solution by using `:::`

Who is calling this function:  package code or user code?  I assume it's a bit 
of a mix:  your package writes a script that calls the function when it runs in 
user space.  (It would help if you gave an explicit example of when you need to 
use this technique.)

If my assumption is correct, there are other simple workarounds besides 
exporting the functions.  Instead of putting

pkg:::foo(args)

into your script, put

pkg::callInternal("foo", args)

where pkg::callInternal is an exported function that can look up unexported 
functions in the namespace.

You may argue that you prefer pkg:::foo for some reason:  to which I'd respond 
that you are being rude to the CRAN volunteers.  I've offered two options (one 
in the previous thread, a different one here), and there was a third one in 
that thread offered by Ivan Krylov.  Surely one of these is good enough for 
your needs, and you shouldn't force CRAN to handle you specially.

Duncan

> 
> I argue `:::` is the only clean solution to this problem and no dirty 
> work-arounds are necessary. This is a prime example of where `:::` is 
> actually useful and needed inside a package. If the R community 
> disagrees, I think R CMD check should at least emit a WARNING instead 
> of a NOTE and elaborate on the problem and accepted work-arounds in 
> "Writing R extensions". Or keep emitting a NOTE but listing those 
> nebulous reasons where `:::` would be tolerated inside a package. 
> Having more transparent criteria for submitting to CRAN would be 
> really helpful to the entire R community and probably also reduce the traffic 
> on this mailing list.
> 
> Best,
> David
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list 
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

__
R-package-devel@r-project.org mailing list 
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Use of `:::` in a package for code run in a parallel cluster

[David Kepplinger]

Thank you all for the discussion and suggestions.

so making a package function baz available makes all functions in the
> package available -- a function in the package already has access to other
> functions in the namespace, whether those functions are exported or not, so
> there is no need to use :::.
>

Thanks, Martin. I completely missed that the parallel package serializes
the entire environment of the function, including the package namespace and
so `:::` is indeed unnecessary in my use case. I probably experimented in
the global environment first and extrapolated the observed behaviour to the
package. Sorry for annoying everyone with this.

I also have another use of `:::` for which I am not sure if it's considered
disallowed use of `:::`, so I'm throwing it out there for feedback.
I have one internal function which checks a long list of common arguments
to several other functions, similar to
internal_check_args <- function (sd = 2, type = c("bootstrap",
"theoretical"), ...) {
  # check arguments for valid ranges, etc.
  return(list(sd = sd, type = match.arg(type))
}

And several functions which use the internal function for argument checking
and such, similar to
exported_foo <- function (x, sd = 2, type = c("bootstrap", "theoretical")) {
  args_call <- match.call()
  args_call[[1]] <- quote(mypackage:::internal_check_args)
  args <- eval.parent(args_call)
}

exported_foo_cv <- function (x, cv_folds = 3, ...) {
  args_call <- match.call(expand.dots = TRUE)
  args_call[[1]] <- quote(mypackage:::internal_check_args)
  args <- eval.parent(args_call)
}

This is modelled after what, e.g., `lm()` does with `model.frame()`, only
that `internal_check_args()` is not exported, hence I use `:::`. There are
other solutions for this type of use of `:::` (probably some considered
cleaner) but again without guidelines on when `:::` is acceptable it's
difficult for package maintainers to know when to use/not use it. From all
the discussions it seems that there is absolutely no acceptable use of
`:::` and work-arounds are always the better alternative.

In light of the other interesting points brought up by discussants, I also
want to honor their time and reply here.

You may argue that you prefer pkg:::foo for some reason:  to which I'd
> respond that you are being rude to the CRAN volunteers.  I've offered
> two options (one in the previous thread, a different one here), and
> there was a third one in that thread offered by Ivan Krylov.  Surely one
> of these is good enough for your needs, and you shouldn't force CRAN to
> handle you specially.
>

I am sorry it came across rude when I tried to solicit arguments for why
the use of `:::` is considered "bad practice", while work-arounds are
considered to be okay. I wouldn't force CRAN to handle my case specially; I
rather wanted to challenge the general "attitude" towards the use of `:::`.
I am sure there is a need to discourage the use of `:::` in packages as
CRAN volunteers probably have seen hundreds of cases where `:::` was abused
(such as mine, as Martin Morgan pointed out).

you can use
>
> get("internal_function", asNamespace("mypackage"))(arg1, arg2)
>
> In fact, if you look at the source code of `:::`, that's exactly how
> it is implemented:
>

That would be a work-around I would have used if necessary. But my general
question remains: why should I reinvent the wheel when R already comes with
`:::`? The only advantage of all the work-arounds I've seen would be to
trick R CMD check that the code is okay, when in fact the same "bad
practice" is practiced.

Best,
David

On Sun, Sep 13, 2020 at 3:04 PM Martin Morgan 
wrote:

> At least in the 'parallel' package
>
> library(parallel)
> cl = makePSOCKcluster(2)
>
> and because of the nature of the R language, the entire namespace is
> exported, analogous to
>
> baz <- local({
> foo <- function() 2
> function(...) foo()
> })
>
> so making a package function baz available makes all functions in the
> package available -- a function in the package already has access to other
> functions in the namespace, whether those functions are exported or not, so
> there is no need to use :::.
>
> > parSapply(1:2, baz)
> [1] 2 2
>
> This is in contrast to what one might expect from exploring things on the
> command line, where foo is defined in the global environment and, by
> convention, the global environment is not serialized to the workers
>
> > foo <- function() 1
> > bar <- function(...) foo()
> > parLapply(cl, 1:2, bar)
> Error in checkForRemoteErrors(val) :
>   2 nodes produced errors; first error: could not find function "foo"
>
> Do you really need to use `:::`?
>
> Martin Morgan
>
>
>
> On 9/13/20, 3:52 PM, "R-package-devel on behalf of David Kepplinger" <
> r-package-devel-boun...@r-project.org on behalf of
> david.kepplin...@gmail.com> wrote:
>
> Dear list members,
>
> I submitted an update for my package and got automatically rejected by
> the
> incoming checks (as expected from my own checks

Re: [R-pkg-devel] Use of `:::` in a package for code run in a parallel cluster

[Joshua Ulrich]

On Sun, Sep 13, 2020 at 3:19 PM Duncan Murdoch  wrote:
>
> On 13/09/2020 3:51 p.m., David Kepplinger wrote:
> > Dear list members,
> >
> > I submitted an update for my package and got automatically rejected by the
> > incoming checks (as expected from my own checks) for using `:::` calls to
> > access the package's namespace.
> > "There are ::: calls to the package's namespace in its code. A package
> > *almost* never needs to use ::: for its own objects:…" (emphasis mine)
> >
> > This was a conscious decision on my part as the package runs code on a
> > user-supplied parallel cluster and I consider cluster-exporting the
> > required functions a no-go as it would potentially overwrite objects in the
> > clusters R sessions. The package code does not own the cluster and hence
> > the R sessions. Therefore overwriting objects could potentially lead to
> > unintended behaviour which is opaque to the user and difficult to debug.
> >
> > Another solution to circumvent the R CMD check note is to export the
> > functions to the public namespace but mark them as internal. This was also
> > suggested in another thread on this mailing list (c.f. "Etiquette for
> > package submissions that do not automatically pass checks?"). I do not
> > agree with this work-around as the methods are indeed internal and should
> > never be used by users. Exporting truly internal functions for the sake of
> > satisfying R CMD check is a bad argument, in particular if there is a
> > clean, well-documented, solution by using `:::`
>
> Who is calling this function:  package code or user code?  I assume it's
> a bit of a mix:  your package writes a script that calls the function
> when it runs in user space.  (It would help if you gave an explicit
> example of when you need to use this technique.)
>
> If my assumption is correct, there are other simple workarounds besides
> exporting the functions.  Instead of putting
>
> pkg:::foo(args)
>
> into your script, put
>
> pkg::callInternal("foo", args)
>
> where pkg::callInternal is an exported function that can look up
> unexported functions in the namespace.
>
Another possibility is what quantmod::newTA() does.
https://github.com/joshuaulrich/quantmod/blob/a8e9cb87825c0997a8468f5105db6c507b26ac5d/R/newTA.

It's a function that creates a user-facing function.  The created
function needs to access unexported objects from the quantmod
namespace.  newTA() accomplishes that by setting the environment of
the function it returns to the quantmod namespace.

https://github.com/joshuaulrich/quantmod/blob/a8e9cb87825c0997a8468f5105db6c507b26ac5d/R/newTA.R#L98

That gives the user's new function access to the unexported charting
objects it needs to work.

Hope that helps.

Best,
Josh


> You may argue that you prefer pkg:::foo for some reason:  to which I'd
> respond that you are being rude to the CRAN volunteers.  I've offered
> two options (one in the previous thread, a different one here), and
> there was a third one in that thread offered by Ivan Krylov.  Surely one
> of these is good enough for your needs, and you shouldn't force CRAN to
> handle you specially.
>
> Duncan
>
> >
> > I argue `:::` is the only clean solution to this problem and no dirty
> > work-arounds are necessary. This is a prime example of where `:::` is
> > actually useful and needed inside a package. If the R community disagrees,
> > I think R CMD check should at least emit a WARNING instead of a NOTE and
> > elaborate on the problem and accepted work-arounds in "Writing R
> > extensions". Or keep emitting a NOTE but listing those nebulous reasons
> > where `:::` would be tolerated inside a package. Having more transparent
> > criteria for submitting to CRAN would be really helpful to the entire R
> > community and probably also reduce the traffic on this mailing list.
> >
> > Best,
> > David
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



--
Joshua Ulrich  |  about.me/joshuaulrich
FOSS Trading  |  www.fosstrading.com

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] CRAN incoming checks email

[Uwe Ligges]

On 13.09.2020 21:22, David Kepplinger wrote:

Dear List-Members:

The email from the automatic incoming checks says to "reply-all" in case
one suspects a false-positive, yet the reply-to header is set only to "
cran-submissi...@r-project.org". My email program (just as myself)
interprets this as "reply-all means replying only to
cran-submissi...@r-project.org". The wording in the email, on the other
hand, suggests I also should reply to Uwe Ligges. I find the current
disagreement of wording and email headers more than confusing.

Can someone clarify the correct protocol of replying to the email? I
wouldn't want to unnecessarily bother Uwe Ligges with even more emails.


Thanks: Uwe has configured mails in a way he always receives one mail in 
a CRAN-submissions folder for both cases.


Best,
Uwe




Thanks,
David

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Use of `:::` in a package for code run in a parallel cluster

[Martin Morgan]

At least in the 'parallel' package

library(parallel)
cl = makePSOCKcluster(2)

and because of the nature of the R language, the entire namespace is exported, 
analogous to

baz <- local({
foo <- function() 2
function(...) foo()
})

so making a package function baz available makes all functions in the package 
available -- a function in the package already has access to other functions in 
the namespace, whether those functions are exported or not, so there is no need 
to use :::.

> parSapply(1:2, baz)
[1] 2 2

This is in contrast to what one might expect from exploring things on the 
command line, where foo is defined in the global environment and, by 
convention, the global environment is not serialized to the workers

> foo <- function() 1
> bar <- function(...) foo()
> parLapply(cl, 1:2, bar)
Error in checkForRemoteErrors(val) : 
  2 nodes produced errors; first error: could not find function "foo"

Do you really need to use `:::`?

Martin Morgan



On 9/13/20, 3:52 PM, "R-package-devel on behalf of David Kepplinger" 
 
wrote:

Dear list members,

I submitted an update for my package and got automatically rejected by the
incoming checks (as expected from my own checks) for using `:::` calls to
access the package's namespace.
"There are ::: calls to the package's namespace in its code. A package
*almost* never needs to use ::: for its own objects:…" (emphasis mine)

This was a conscious decision on my part as the package runs code on a
user-supplied parallel cluster and I consider cluster-exporting the
required functions a no-go as it would potentially overwrite objects in the
clusters R sessions. The package code does not own the cluster and hence
the R sessions. Therefore overwriting objects could potentially lead to
unintended behaviour which is opaque to the user and difficult to debug.

Another solution to circumvent the R CMD check note is to export the
functions to the public namespace but mark them as internal. This was also
suggested in another thread on this mailing list (c.f. "Etiquette for
package submissions that do not automatically pass checks?"). I do not
agree with this work-around as the methods are indeed internal and should
never be used by users. Exporting truly internal functions for the sake of
satisfying R CMD check is a bad argument, in particular if there is a
clean, well-documented, solution by using `:::`.

I argue `:::` is the only clean solution to this problem and no dirty
work-arounds are necessary. This is a prime example of where `:::` is
actually useful and needed inside a package. If the R community disagrees,
I think R CMD check should at least emit a WARNING instead of a NOTE and
elaborate on the problem and accepted work-arounds in "Writing R
extensions". Or keep emitting a NOTE but listing those nebulous reasons
where `:::` would be tolerated inside a package. Having more transparent
criteria for submitting to CRAN would be really helpful to the entire R
community and probably also reduce the traffic on this mailing list.

Best,
David

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Use of `:::` in a package for code run in a parallel cluster

[Duncan Murdoch]

On 13/09/2020 3:51 p.m., David Kepplinger wrote:

Dear list members,

I submitted an update for my package and got automatically rejected by the
incoming checks (as expected from my own checks) for using `:::` calls to
access the package's namespace.
"There are ::: calls to the package's namespace in its code. A package
*almost* never needs to use ::: for its own objects:…" (emphasis mine)

This was a conscious decision on my part as the package runs code on a
user-supplied parallel cluster and I consider cluster-exporting the
required functions a no-go as it would potentially overwrite objects in the
clusters R sessions. The package code does not own the cluster and hence
the R sessions. Therefore overwriting objects could potentially lead to
unintended behaviour which is opaque to the user and difficult to debug.

Another solution to circumvent the R CMD check note is to export the
functions to the public namespace but mark them as internal. This was also
suggested in another thread on this mailing list (c.f. "Etiquette for
package submissions that do not automatically pass checks?"). I do not
agree with this work-around as the methods are indeed internal and should
never be used by users. Exporting truly internal functions for the sake of
satisfying R CMD check is a bad argument, in particular if there is a
clean, well-documented, solution by using `:::`


Who is calling this function:  package code or user code?  I assume it's 
a bit of a mix:  your package writes a script that calls the function 
when it runs in user space.  (It would help if you gave an explicit 
example of when you need to use this technique.)


If my assumption is correct, there are other simple workarounds besides 
exporting the functions.  Instead of putting


   pkg:::foo(args)

into your script, put

   pkg::callInternal("foo", args)

where pkg::callInternal is an exported function that can look up 
unexported functions in the namespace.


You may argue that you prefer pkg:::foo for some reason:  to which I'd 
respond that you are being rude to the CRAN volunteers.  I've offered 
two options (one in the previous thread, a different one here), and 
there was a third one in that thread offered by Ivan Krylov.  Surely one 
of these is good enough for your needs, and you shouldn't force CRAN to 
handle you specially.


Duncan



I argue `:::` is the only clean solution to this problem and no dirty
work-arounds are necessary. This is a prime example of where `:::` is
actually useful and needed inside a package. If the R community disagrees,
I think R CMD check should at least emit a WARNING instead of a NOTE and
elaborate on the problem and accepted work-arounds in "Writing R
extensions". Or keep emitting a NOTE but listing those nebulous reasons
where `:::` would be tolerated inside a package. Having more transparent
criteria for submitting to CRAN would be really helpful to the entire R
community and probably also reduce the traffic on this mailing list.

Best,
David

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Use of `:::` in a package for code run in a parallel cluster

[David Kepplinger]

Dear list members,

I submitted an update for my package and got automatically rejected by the
incoming checks (as expected from my own checks) for using `:::` calls to
access the package's namespace.
"There are ::: calls to the package's namespace in its code. A package
*almost* never needs to use ::: for its own objects:…" (emphasis mine)

This was a conscious decision on my part as the package runs code on a
user-supplied parallel cluster and I consider cluster-exporting the
required functions a no-go as it would potentially overwrite objects in the
clusters R sessions. The package code does not own the cluster and hence
the R sessions. Therefore overwriting objects could potentially lead to
unintended behaviour which is opaque to the user and difficult to debug.

Another solution to circumvent the R CMD check note is to export the
functions to the public namespace but mark them as internal. This was also
suggested in another thread on this mailing list (c.f. "Etiquette for
package submissions that do not automatically pass checks?"). I do not
agree with this work-around as the methods are indeed internal and should
never be used by users. Exporting truly internal functions for the sake of
satisfying R CMD check is a bad argument, in particular if there is a
clean, well-documented, solution by using `:::`.

I argue `:::` is the only clean solution to this problem and no dirty
work-arounds are necessary. This is a prime example of where `:::` is
actually useful and needed inside a package. If the R community disagrees,
I think R CMD check should at least emit a WARNING instead of a NOTE and
elaborate on the problem and accepted work-arounds in "Writing R
extensions". Or keep emitting a NOTE but listing those nebulous reasons
where `:::` would be tolerated inside a package. Having more transparent
criteria for submitting to CRAN would be really helpful to the entire R
community and probably also reduce the traffic on this mailing list.

Best,
David

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] CRAN incoming checks email

[David Kepplinger]

Dear List-Members:

The email from the automatic incoming checks says to "reply-all" in case
one suspects a false-positive, yet the reply-to header is set only to "
cran-submissi...@r-project.org". My email program (just as myself)
interprets this as "reply-all means replying only to
cran-submissi...@r-project.org". The wording in the email, on the other
hand, suggests I also should reply to Uwe Ligges. I find the current
disagreement of wording and email headers more than confusing.

Can someone clarify the correct protocol of replying to the email? I
wouldn't want to unnecessarily bother Uwe Ligges with even more emails.

Thanks,
David

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Rcpp with clang++ -stdlib=libc++ ?

[Dr . Jens Oehlschlägel]

Thank you Dirk and Kevin,

that was very helpful and

 >  sudo apt install libc++-dev libc++abi-dev

did the job!

Great, this was very important to me.
Thanks again

Jens



On 13.09.20 02:55, Kevin Ushey wrote:
> My understanding is that many Linux OSes package the clang compiler, the 
> libc++ standard library, and the headers used by the libc++ standard 
> library separately. To install those headers, you likely need (e.g. on 
> Ubuntu):
> 
>      sudo apt install libc++-dev libc++abi-dev
> 
> to be able to build and compile programs against libc++.
> 
> This also comes with the caveat that mixing programs built against 
> different standard library implementations is in general a bad idea, so 
> you may see issues if you mix libraries compiled with libstdc++ and 
> libc++ in the same R session. (This can come up with R packages that 
> link to other libraries installed on the system, which will typically be 
> built with and linked against the "default" system compiler + standard 
> library implementations.) I'm not sure if this will be an issue in 
> practice with what you're doing, but it's worth being aware of.
> 
> Best,
> Kevin
> 
> On Sat, Sep 12, 2020 at 5:50 AM Dirk Eddelbuettel  > wrote:
> 
> 
> Hi Jens,
> 
> On 11 September 2020 at 21:00, Dr. Jens Oehlschlägel wrote:
> | I can compile a package under clang++ with -stdlib=libstdc++, but
> with -stdlib=libc++ I get
> |
> | "
> | In file included from
> 
> /home/jo/R/x86_64-pc-linux-gnu-library/4.0/Rcpp/include/Rcpp/r/headers.h:67:
> |
> 
> /home/jo/R/x86_64-pc-linux-gnu-library/4.0/Rcpp/include/Rcpp/platform/compiler.h:100:10:
> fatal error: 'cmath' file not found
> | #include 
> |  ^~~
> | 1 error generated.
> | "
> |
> | Is there any howto for using Rcpp with -stdlib=libc++ ?
> 
> That has zero to do with Rcpp.  You are lacking a C++ library header
> when
> switching the C++ standard library along with clang. Nothing that
> Rcpp ships,
> or governs, or selects.
> 
> I am forgetting the fine details here (and someone may hopefully fill in
> fuller details) but in short, "that is just the way it is".  I think we
> simply pivot back to the g++ standard C++ library even when using
> clang++.
> 
> Cheers from Chicago,  Dirk
> 
> | Greetings from Munich
> |
> | Jens Oehlschlägel
> |
> |
> | P.S.
> |
> | Package Makevars
> | CXX_STD = CXX17
> | PKG_CXXFLAGS=-O3 -march=native -pthread
> | PKG_LIBS=-latomic -pthread
> |
> | ~.R/Makevars
> | CXX17 = clang++ -stdlib=libc++
> | CXX17FLAGS = -fstack-protector-strong -D_FORTIFY_SOURCE=2 -g $(LTO)
> | CXX17STD = -std=c++17
> |
> | > packageVersion("Rcpp")
> | [1] ‘1.0.5’
> |
> | > version
> |    _
> | platform   x86_64-pc-linux-gnu
> | arch   x86_64
> | os linux-gnu
> | system x86_64, linux-gnu
> | status
> | major  4
> | minor  0.2
> | year   2020
> | month  06
> | day    22
> | svn rev    78730
> | language   R
> | version.string R version 4.0.2 (2020-06-22)
> | nickname   Taking Off Again
> |
> | __
> | R-package-devel@r-project.org
>  mailing list
> | https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 
> -- 
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> 
> 
> __
> R-package-devel@r-project.org 
> mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> 

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel