Re: [R-pkg-devel] Registered S3 methods from standard package

[Colin Gillespie]

Hi All,

Just to close the thread for future readers.

CRAN forbid both plot.numeric() and plot.default(). Instead, I should
go down the route of pretty_plot and plot.prettyB

This means that plot(lm(1:10 ~ rnorm(10)) doesn't work and the plot()
function doesn't magically become nicer.

__But__ I do appreciate that overwriting plot.default() may cause
chaos for other package authors, so overall it's probably the correct
choice.

Thanks


colin

On Mon, 13 May 2019 at 12:26, Colin Gillespie  wrote:
>
> Dr Colin Gillespie
>
> >
> > Or more simply:  call the method prettyBplot.
>
> Rightly (but perhaps wrongly) I was trying for a simple method where
> the plots just change. If prettyB loaded, the plots just look a little
> nicer. If prettyB isn't available, then the plot function works as normal.
>
> So two possible options are:
>
>   * registerS3method - I suspect this isn't permitted.
>   * Don't override plot.default(), but override other methods. E.g.
> boxplot.list() and plot.numeric(). But is this going against the
> spirit of the law?
>
> Thanks
>
> Colin
>
> >
> > Duncan Murdoch
> >
> > >
> > > Resetting to graphics::plot.default should be made possible as well.
> > >
> > > The question remains whether registerS3method() can be used at all,
> > > since the help says:
> > >
> > >> Internal namespace support functions.  Not intended to be called
> > >>   directly, and only visible because of the special nature of the
> > >>   ‘base’ namespace.
> > >
> > > Cheers,
> > >
> > >   Sebastian
> > >
> > >
> > > Am 13.05.19 um 09:22 schrieb Colin Gillespie:
> > >> Dear All,
> > >>
> > >> I'm developing a small package to make plotting methods a little bit
> > >> nicer looking:
> > >>
> > >> https://github.com/jumpingrivers/prettyB/
> > >>
> > >> The general idea is to replace plot.default() with an alternative
> > >> (matching all arguments) and export. This would allow users to simply
> > >> load the package and use base graphics functions as normal, but get a
> > >> pretty graph.
> > >>
> > >> The general pattern I follow is:
> > >>
> > >> https://github.com/jumpingrivers/prettyB/blob/master/R/plot.R#L23
> > >>
> > >> which then includes S3method(plot,default) in my NAMESPACE file. When
> > >> building and checking the package I get
> > >>
> > >> Registered S3 methods from standard package(s) overwritten by 'prettyB':
> > >>  method  from
> > >>  plot.defaultgraphics
> > >>
> > >> which CRAN does not permit.
> > >>
> > >> Question: Is it possible to achieve the functionality I'm after
> > >> (replacing the default plot.default() functions) while following the
> > >> CRAN rules?
> > >>
> > >> Thanks
> > >>
> > >> Colin
> > >>
> > >> __
> > >> 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

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

Re: [R-pkg-devel] R CMD check works but with devtools::check() examples fail

[Jack O. Wasey]

Barbara,

On 5/15/19 5:09 PM, Barbara Lerner wrote:

I have just upgraded to R 3.6.0 and when building and checking my
package, R CMD check passes all the checks, including running the
examples, but devtools::check reports a failure when running the
examples.  I have also run the example successfully manually in RStudio.
I would appreciate help in understanding what devtools::check is doing
that R CMD check is not doing, or help in understanding the failure
report that devtools::check provides.

Here are somewhat abbreviated outputs from each:


~/git/rdtLite.check/rdtLite.Rcheck/00_pkg_src/rdtLite -> R CMD check .


Agree with Dirk, and also you are running R CMD check on the current 
directory, whereas Writing R Extensions recommends/insists on checking a 
tarball created using R CMD build:


"It is strongly recommended that the final checks are run on a tar 
archive prepared by R CMD build."


I've no idea how this might change checks (does it still look at 
.Rbuildignore?) but this might introduce additional problems.


Jack



* using log directory
‘/Users/blerner/git/rdtLite.check/rdtLite.Rcheck/00_pkg_src/rdtLite/..Rcheck’
* using R version 3.6.0 (2019-04-26)
* using platform: x86_64-apple-darwin15.6.0 (64-bit)
* using session charset: UTF-8
* checking for file ‘./DESCRIPTION’ ... OK
* this is package ‘rdtLite’ version ‘1.0.3’
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... NOTE
Found the following hidden files and directories:
    .commit
    ..Rcheck
These were most likely included in error. See section ‘Package
structure’ in the ‘Writing R Extensions’ manual.
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... OK
* checking whether package ‘rdtLite’ can be installed ... OK
* checking installed package size ... OK
* checking package directory ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking for left-over files ... OK
* checking index information ... OK
* checking package subdirectories ... WARNING
Found the following directory with the name of a check directory:
    ./..Rcheck
Most likely, these were included erroneously.
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the package can be unloaded cleanly ... OK
* checking whether the namespace can be loaded with stated dependencies
... OK
* checking whether the namespace can be unloaded cleanly ... OK
* checking dependencies in R code ... NOTE
Namespace in Imports field not imported from: ‘gtools’
    All declared Imports should be used.
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... OK
* checking Rd files ... OK
* checking Rd metadata ... OK
* checking Rd cross-references ... OK
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... OK
* checking Rd \usage sections ... OK
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... OK
* checking examples ... OK
* checking for unstated dependencies in ‘tests’ ... OK
* checking tests ...
    Running ‘test-all.R’
   OK
* checking PDF version of manual ... OK
* DONE

Status: 1 WARNING, 2 NOTEs



~/git/rdtLite.check/rdtLite.Rcheck/00_pkg_src/rdtLite -> Rscript -e
"devtools::check()"
Updating rdtLite documentation
Warning: roxygen2 requires Encoding: UTF-8
Writing NAMESPACE
Loading rdtLite
Registered S3 methods overwritten by 'ggplot2':
    method from
    [.quosures rlang
    c.quosures rlang
    print.quosures rlang
Writing NAMESPACE
── Building ─
rdtLite ──
Setting env vars:
● CFLAGS    : -Wall -pedantic -fdiagnostics-color=always
● CXXFLAGS  : -Wall -pedantic -fdiagnostics-color=always
● CXX11FLAGS: -Wall -pedantic -fdiagnostics-color=always

     checking for file
‘/Users/blerner/git/rdtLite.check/rdtLite.Rcheck/00_pkg_src✔  checking
for file
‘/Users/blerner/git/rdtLite.check/rdtLite.Rcheck/00_pkg_src/rdtLite/DESCRIPTION’
─  preparing ‘rdtLite’:
✔  checking DESCRIPTION meta-information ...
─  checking for LF line-endings in source and make files and shell scripts
─  checking for empty or unneeded directories
─  building ‘rdtLite_1.0.3.tar.gz’

── Checking ─
rdtLite ──
Setting env vars:
● _R_CHECK_CRAN_INCOMING_REMOTE_: FALSE
● _R_CHECK_CRAN_INCOMING_   : FALSE
● _R_CHECK_FORCE_SUGGESTS_  : FALSE
── 

Re: [R-pkg-devel] R CMD check works but with devtools::check() examples fail

[Gábor Csárdi]

On Thu, May 16, 2019 at 10:56 AM Jack O. Wasey  wrote:
> Agree with Dirk, and also you are running R CMD check on the current
> directory,

Why do you think so? Don't the lines below the "-- Building" header
mean that devtools/rcmdcheck is building the package?

G.

[...]
> > ── Building ─
> > rdtLite ──
> > Setting env vars:
> > ● CFLAGS: -Wall -pedantic -fdiagnostics-color=always
> > ● CXXFLAGS  : -Wall -pedantic -fdiagnostics-color=always
> > ● CXX11FLAGS: -Wall -pedantic -fdiagnostics-color=always
> > 
> >  checking for file
> > ‘/Users/blerner/git/rdtLite.check/rdtLite.Rcheck/00_pkg_src✔  checking
> > for file
> > ‘/Users/blerner/git/rdtLite.check/rdtLite.Rcheck/00_pkg_src/rdtLite/DESCRIPTION’
> > ─  preparing ‘rdtLite’:
> > ✔  checking DESCRIPTION meta-information ...
> > ─  checking for LF line-endings in source and make files and shell scripts
> > ─  checking for empty or unneeded directories
> > ─  building ‘rdtLite_1.0.3.tar.gz’
> >
> > ── Checking ─
[...]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] R CMD check works but with devtools::check() examples fail

[Jack O. Wasey]

Why do you think so? Don't the lines below the "-- Building" header
mean that devtools/rcmdcheck is building the package?


I saw (the last part of) this:

> ~/git/rdtLite.check/rdtLite.Rcheck/00_pkg_src/rdtLite -> R CMD check .

Sorry if I added some confusion: on closer inspection, it does look like 
this is R CMD check doing its normal thing.




G.

[...]

── Building ─
rdtLite ──
Setting env vars:
● CFLAGS: -Wall -pedantic -fdiagnostics-color=always
● CXXFLAGS  : -Wall -pedantic -fdiagnostics-color=always
● CXX11FLAGS: -Wall -pedantic -fdiagnostics-color=always

  checking for file
‘/Users/blerner/git/rdtLite.check/rdtLite.Rcheck/00_pkg_src✔  checking
for file
‘/Users/blerner/git/rdtLite.check/rdtLite.Rcheck/00_pkg_src/rdtLite/DESCRIPTION’
─  preparing ‘rdtLite’:
✔  checking DESCRIPTION meta-information ...
─  checking for LF line-endings in source and make files and shell scripts
─  checking for empty or unneeded directories
─  building ‘rdtLite_1.0.3.tar.gz’

── Checking ─

[...]



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

Re: [R-pkg-devel] R CMD check works but with devtools::check() examples fail

[Jari Oksanen]

I think this is because the check systems set different environmental 
variables. I had the same problem in February, and found out that R 3.6.0 (then 
still to come) adds new environmental variable _R_CHECK_LENGTH_1_LOGIC2_. This 
*is* documented, but the documentation is well hidden in R-internals manual. It 
says (or said when I looked at this in early February):

_R_CHECK_LENGTH_1_LOGIC2_
Optionally check if either argument of the binary operators && and || has 
length greater than one. The format is the same as for 
_R_CHECK_LENGTH_1_CONDITION_. Default: unset (nothing is reported)

R has for ages wanted that condition if(A && B) should have length 1, but with 
this variable set, it also wants both A and B have length one (which is not the 
same thing). You need to find the place where this does not happen and fix 
that. If you look at the end of the error message, it even says in which case 
you have a length>1 component in your condition (it is given as length 3 in the 
diagnostic output).

I found this then because win-builder set this environmental variable, and 
there may be other build systems that do the same. You should fix the cases to 
avoid trouble.

Cheers, Jari Oksanen

On 16 May 2019, at 13:08, Gábor Csárdi 
mailto:csardi.ga...@gmail.com>> wrote:

On Thu, May 16, 2019 at 10:56 AM Jack O. Wasey 
mailto:j...@jackwasey.com>> wrote:
Agree with Dirk, and also you are running R CMD check on the current
directory,

Why do you think so? Don't the lines below the "-- Building" header
mean that devtools/rcmdcheck is building the package?

G.

[...]
── Building ─
rdtLite ──
Setting env vars:
● CFLAGS: -Wall -pedantic -fdiagnostics-color=always
● CXXFLAGS  : -Wall -pedantic -fdiagnostics-color=always
● CXX11FLAGS: -Wall -pedantic -fdiagnostics-color=always

checking for file
‘/Users/blerner/git/rdtLite.check/rdtLite.Rcheck/00_pkg_src✔  checking
for file
‘/Users/blerner/git/rdtLite.check/rdtLite.Rcheck/00_pkg_src/rdtLite/DESCRIPTION’
─  preparing ‘rdtLite’:
✔  checking DESCRIPTION meta-information ...
─  checking for LF line-endings in source and make files and shell scripts
─  checking for empty or unneeded directories
─  building ‘rdtLite_1.0.3.tar.gz’

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


[[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] R CMD check works but with devtools::check() examples fail

[Duncan Murdoch]

On 16/05/2019 5:56 a.m., Jack O. Wasey wrote:

Barbara,

On 5/15/19 5:09 PM, Barbara Lerner wrote:

I have just upgraded to R 3.6.0 and when building and checking my
package, R CMD check passes all the checks, including running the
examples, but devtools::check reports a failure when running the
examples.  I have also run the example successfully manually in RStudio.
I would appreciate help in understanding what devtools::check is doing
that R CMD check is not doing, or help in understanding the failure
report that devtools::check provides.

Here are somewhat abbreviated outputs from each:


~/git/rdtLite.check/rdtLite.Rcheck/00_pkg_src/rdtLite -> R CMD check .


Agree with Dirk, and also you are running R CMD check on the current
directory, whereas Writing R Extensions recommends/insists on checking a
tarball created using R CMD build:

"It is strongly recommended that the final checks are run on a tar
archive prepared by R CMD build."

I've no idea how this might change checks (does it still look at
.Rbuildignore?) but this might introduce additional problems.


Running check on a directory instead of a tarball usually leads to some 
extra warnings, it typically doesn't suppress them.  (The extra warnings 
I've seen most recently are about files that would be excluded from the 
tarball.)


Duncan urdoch



Jack



* using log directory
‘/Users/blerner/git/rdtLite.check/rdtLite.Rcheck/00_pkg_src/rdtLite/..Rcheck’
* using R version 3.6.0 (2019-04-26)
* using platform: x86_64-apple-darwin15.6.0 (64-bit)
* using session charset: UTF-8
* checking for file ‘./DESCRIPTION’ ... OK
* this is package ‘rdtLite’ version ‘1.0.3’
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... NOTE
Found the following hidden files and directories:
     .commit
     ..Rcheck
These were most likely included in error. See section ‘Package
structure’ in the ‘Writing R Extensions’ manual.
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... OK
* checking whether package ‘rdtLite’ can be installed ... OK
* checking installed package size ... OK
* checking package directory ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking for left-over files ... OK
* checking index information ... OK
* checking package subdirectories ... WARNING
Found the following directory with the name of a check directory:
     ./..Rcheck
Most likely, these were included erroneously.
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the package can be unloaded cleanly ... OK
* checking whether the namespace can be loaded with stated dependencies
... OK
* checking whether the namespace can be unloaded cleanly ... OK
* checking dependencies in R code ... NOTE
Namespace in Imports field not imported from: ‘gtools’
     All declared Imports should be used.
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... OK
* checking Rd files ... OK
* checking Rd metadata ... OK
* checking Rd cross-references ... OK
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... OK
* checking Rd \usage sections ... OK
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... OK
* checking examples ... OK
* checking for unstated dependencies in ‘tests’ ... OK
* checking tests ...
     Running ‘test-all.R’
    OK
* checking PDF version of manual ... OK
* DONE

Status: 1 WARNING, 2 NOTEs



~/git/rdtLite.check/rdtLite.Rcheck/00_pkg_src/rdtLite -> Rscript -e
"devtools::check()"
Updating rdtLite documentation
Warning: roxygen2 requires Encoding: UTF-8
Writing NAMESPACE
Loading rdtLite
Registered S3 methods overwritten by 'ggplot2':
     method from
     [.quosures rlang
     c.quosures rlang
     print.quosures rlang
Writing NAMESPACE
── Building ─
rdtLite ──
Setting env vars:
● CFLAGS    : -Wall -pedantic -fdiagnostics-color=always
● CXXFLAGS  : -Wall -pedantic -fdiagnostics-color=always
● CXX11FLAGS: -Wall -pedantic -fdiagnostics-color=always

      checking for file
‘/Users/blerner/git/rdtLite.check/rdtLite.Rcheck/00_pkg_src✔  checking
for file
‘/Users/blerner/git/rdtLite.check/rdtLite.Rcheck/00_pkg_src/rdtLite/DESCRIPTION’
─  preparing ‘rdtLite’:
✔  checking DESCRIPTION meta-information ...
─  checking for LF line-endings in source and make files and shell scripts
─  

[R-pkg-devel] noL

[Goldfeld, Keith]

Good morning -

I have one final issue that is preventing me from a successful
submission of my package simstudy to CRAN. In one of my examples, I sum
a vector of probabilities and check to make sure they sum to one.

I am getting an "noLD" error - so there is some issue with a long double. I
am a at a bit of a loss on how to go about fixing this (would rounding help),
but more importantly, how can I check this to make sure I have fixed it -
since I do not get an error on my local system (and it passes all other
checks.)

I've included the log from the noLD
(https://www.stats.ox.ac.uk/pub/bdr/noLD/simstudy.out) below.

- Keith


* checking examples ... ERROR
Running examples in �simstudy-Ex.R� failed
The error most likely occurred in:

> ### Name: genCorOrdCat
> ### Title: Generate correlated ordinal categorical data
> ### Aliases: genCorOrdCat
>
> ### ** Examples
>
>  Set definitions
>
> baseprobs <- matrix(c(0.2, 0.1, 0.1, 0.6,
+   0.7, 0.2, 0.1, 0,
+   0.5, 0.2, 0.3, 0,
+   0.4, 0.2, 0.4, 0,
+   0.6, 0.2, 0.2, 0),
+ nrow = 5, byrow = TRUE)
>
> set.seed(333)
> dT <- genData(1000)
>
> dX <- genCorOrdCat(dT, adjVar = NULL, baseprobs = baseprobs,
+prefix = "q", rho = .125, corstr = "cs")
Error in genCorOrdCat(dT, adjVar = NULL, baseprobs = baseprobs, prefix = "q",  :
  Probabilities are not properly specified
Execution halted
* checking for unstated dependencies in vignettes ... OK
* checking package vignettes in �inst/doc� ... OK
* checking re-building of vignette outputs ... OK
* checking PDF version of manual ... OK
* DONE

Status: 1 ERROR
See
  �/data/gannet/ripley/R/packages/tests-noLD/simstudy.Rcheck/00check.log�
for details.



This email message, including any attachments, is for th...{{dropped:14}}

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

Re: [R-pkg-devel] noL

[Jeff Newmiller]

It pays to read the archives before posting 
https://stat.ethz.ch/pipermail/r-package-devel/2019q2/003941.html

On May 16, 2019 6:31:19 AM PDT, "Goldfeld, Keith" 
 wrote:
>Good morning -
>
>I have one final issue that is preventing me from a successful
>submission of my package simstudy to CRAN. In one of my examples, I sum
>a vector of probabilities and check to make sure they sum to one.
>
>I am getting an "noLD" error - so there is some issue with a long
>double. I
>am a at a bit of a loss on how to go about fixing this (would rounding
>help),
>but more importantly, how can I check this to make sure I have fixed it
>-
>since I do not get an error on my local system (and it passes all other
>checks.)
>
>I've included the log from the noLD
>(https://www.stats.ox.ac.uk/pub/bdr/noLD/simstudy.out) below.
>
>- Keith
>
>
>* checking examples ... ERROR
>Running examples in �simstudy-Ex.R� failed
>The error most likely occurred in:
>
>> ### Name: genCorOrdCat
>> ### Title: Generate correlated ordinal categorical data
>> ### Aliases: genCorOrdCat
>>
>> ### ** Examples
>>
>>  Set definitions
>>
>> baseprobs <- matrix(c(0.2, 0.1, 0.1, 0.6,
>+   0.7, 0.2, 0.1, 0,
>+   0.5, 0.2, 0.3, 0,
>+   0.4, 0.2, 0.4, 0,
>+   0.6, 0.2, 0.2, 0),
>+ nrow = 5, byrow = TRUE)
>>
>> set.seed(333)
>> dT <- genData(1000)
>>
>> dX <- genCorOrdCat(dT, adjVar = NULL, baseprobs = baseprobs,
>+prefix = "q", rho = .125, corstr = "cs")
>Error in genCorOrdCat(dT, adjVar = NULL, baseprobs = baseprobs, prefix
>= "q",  :
>  Probabilities are not properly specified
>Execution halted
>* checking for unstated dependencies in vignettes ... OK
>* checking package vignettes in �inst/doc� ... OK
>* checking re-building of vignette outputs ... OK
>* checking PDF version of manual ... OK
>* DONE
>
>Status: 1 ERROR
>See
>�/data/gannet/ripley/R/packages/tests-noLD/simstudy.Rcheck/00check.log�
>for details.
>
>
>
>This email message, including any attachments, is for\ ...{{dropped:6}}

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

Re: [R-pkg-devel] CRAN student assistants

[Hadley Wickham]

Hi all,

The thread seems to have drifted off topic. I really didn't want this
to devolve into a discussion about when cat() or message() is more
appropriate — I have complete faith in Jenny Bryan's ability to
understand technical tradeoffs and pick the most appropriate given the
constraints. I am most interested in understanding what level of
discretion CRAN's "Studentischer administrativer Mitarbeiter" have to
critique the implementation of R packages, particularly for packages
that do not yield R CMD check problems or otherwise violate CRAN
policies.

I mean no disrespect towards the CRAN maintainers (whose tireless
efforts are a crucial part of making R the success that it is), but I
don't think it's unreasonable to enquire as to who is involved in a
crucial piece of open source community infrastructure, and, if
students are involved, what their scope of work is and how they are
trained and supervised.

I do recognise that my question "Who are they?" may have been
perceived as overly intrusive. To clarify: I don't want to know names
or other personally identifying information, but I would like to know
in general terms how many there are, and what backgrounds they have.
Similarly, I don't want to know how much they are paid, just whether
or not they are volunteers or employees.

Hadley

On Tue, May 14, 2019 at 10:23 AM Hadley Wickham  wrote:
>
> Hi all,
>
> Several people on my team have received responses to their CRAN
> submissions from new members of the CRAN team who appear to be student
> assistants (judging from their job titles: "Studentischer
> administrativer Mitarbeiter"). From the outside, they appear to be
> exercising editorial control[^1] and conducting design reviews[^2].
>
> CRAN is a critical piece of R community infrastructure, and I am sure
> these students have been surrounded by the proper checks and balances,
> but it's not obvious what their role is from the outside. I'd really
> appreciate knowing a little more about them:
>
> * Who are they?
>
> * Are they paid employees or volunteers?
>
> * What is their scope of work?
>
> * How are they trained?
>
> * If we believe that they have made a mistake, how do we request
>   review from a senior CRAN member?
>
> * They appear to be able to apply additional discretionary criteria
>   that are not included in R CMD check or documented in the CRAN policies.
>   Is this true? If so, what is the scope of these additional checks?
>
> Hadley
>
> [^1]: The devoid package was rejected because the student assistant
> did not understand the purpose of the package.
>
> [^2]: The gargle package was rejected because the student assistant
> believed that the use of cat() was incorrect. It was not.
>
> --
> http://hadley.nz



-- 
http://hadley.nz

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

Re: [R-pkg-devel] noL

[Gábor Csárdi]

To make sure that you have fixed it, you need an R build without long
double support. If you don't want to do this yourself, R-hub now has a
platform without long doubles, so you can do:

rhub::check(platform = "debian-gcc-devel-nold")

You can also do it locally with rhub::local_check_linux() or grab the
Docker image from
https://cloud.docker.com/u/rhub/repository/docker/rhub/debian-gcc-devel-nold

Cheers,
Gabor

On Thu, May 16, 2019 at 2:31 PM Goldfeld, Keith
 wrote:
>
> Good morning -
>
> I have one final issue that is preventing me from a successful
> submission of my package simstudy to CRAN. In one of my examples, I sum
> a vector of probabilities and check to make sure they sum to one.
>
> I am getting an "noLD" error - so there is some issue with a long double. I
> am a at a bit of a loss on how to go about fixing this (would rounding help),
> but more importantly, how can I check this to make sure I have fixed it -
> since I do not get an error on my local system (and it passes all other
> checks.)
>
> I've included the log from the noLD
> (https://www.stats.ox.ac.uk/pub/bdr/noLD/simstudy.out) below.
>
> - Keith
>
>
> * checking examples ... ERROR
> Running examples in ‘simstudy-Ex.R’ failed
> The error most likely occurred in:
>
> > ### Name: genCorOrdCat
> > ### Title: Generate correlated ordinal categorical data
> > ### Aliases: genCorOrdCat
> >
> > ### ** Examples
> >
> >  Set definitions
> >
> > baseprobs <- matrix(c(0.2, 0.1, 0.1, 0.6,
> +   0.7, 0.2, 0.1, 0,
> +   0.5, 0.2, 0.3, 0,
> +   0.4, 0.2, 0.4, 0,
> +   0.6, 0.2, 0.2, 0),
> + nrow = 5, byrow = TRUE)
> >
> > set.seed(333)
> > dT <- genData(1000)
> >
> > dX <- genCorOrdCat(dT, adjVar = NULL, baseprobs = baseprobs,
> +prefix = "q", rho = .125, corstr = "cs")
> Error in genCorOrdCat(dT, adjVar = NULL, baseprobs = baseprobs, prefix = "q", 
>  :
>   Probabilities are not properly specified
> Execution halted
> * checking for unstated dependencies in vignettes ... OK
> * checking package vignettes in ‘inst/doc’ ... OK
> * checking re-building of vignette outputs ... OK
> * checking PDF version of manual ... OK
> * DONE
>
> Status: 1 ERROR
> See
>   ‘/data/gannet/ripley/R/packages/tests-noLD/simstudy.Rcheck/00check.log’
> for details.
>
>
> 
> This email message, including any attachments, is for ...{{dropped:6}}

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

Re: [R-pkg-devel] noL

[Uwe Ligges]

From https://www.stats.ox.ac.uk/pub/bdr/noLD/README.txt :
"tests on x86_64 Linux with R-devel configured --disable-long-double"
in order to mimick platforms without support for long doubles.


Best,
Uwe Ligges





On 16.05.2019 15:31, Goldfeld, Keith wrote:

Good morning -

I have one final issue that is preventing me from a successful
submission of my package simstudy to CRAN. In one of my examples, I sum
a vector of probabilities and check to make sure they sum to one.

I am getting an "noLD" error - so there is some issue with a long double. I
am a at a bit of a loss on how to go about fixing this (would rounding help),
but more importantly, how can I check this to make sure I have fixed it -
since I do not get an error on my local system (and it passes all other
checks.)

I've included the log from the noLD
(https://www.stats.ox.ac.uk/pub/bdr/noLD/simstudy.out) below.

- Keith


* checking examples ... ERROR
Running examples in �simstudy-Ex.R� failed
The error most likely occurred in:


### Name: genCorOrdCat
### Title: Generate correlated ordinal categorical data
### Aliases: genCorOrdCat

### ** Examples

 Set definitions

baseprobs <- matrix(c(0.2, 0.1, 0.1, 0.6,

+   0.7, 0.2, 0.1, 0,
+   0.5, 0.2, 0.3, 0,
+   0.4, 0.2, 0.4, 0,
+   0.6, 0.2, 0.2, 0),
+ nrow = 5, byrow = TRUE)


set.seed(333)
dT <- genData(1000)

dX <- genCorOrdCat(dT, adjVar = NULL, baseprobs = baseprobs,

+prefix = "q", rho = .125, corstr = "cs")
Error in genCorOrdCat(dT, adjVar = NULL, baseprobs = baseprobs, prefix = "q",  :
   Probabilities are not properly specified
Execution halted
* checking for unstated dependencies in vignettes ... OK
* checking package vignettes in �inst/doc� ... OK
* checking re-building of vignette outputs ... OK
* checking PDF version of manual ... OK
* DONE

Status: 1 ERROR
See
   �/data/gannet/ripley/R/packages/tests-noLD/simstudy.Rcheck/00check.log�
for details.



This email message, including any attachments, is for ...{{dropped:8}}


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

Re: [R-pkg-devel] CRAN student assistants

[alejandro baranek]

Hi!

Mi humble opinion:

I cannot evaluate the workload for CRAN maintainer, but it don't seem to be
reasonable that students can make objections with packages that "do not
yield R CMD check problems or otherwise violate CRAN policies."

Maybe CRAN maintainer team are giving review tasks for those students, for
increasing package evaluation skills. But a new protocol should be
implemented with this seamly new position, where students learning errors
doesn't obstruct the workflow of senior package developers with own QA
methods implemented, as a result of years efforts.

Is not bad new workforce helps with heavy duties: it's an excelent news.
But It cannot cause problems with tunned workflow/pipelines. Is the
internal CRAN process for package approval described somewhere?

Best, Ale.

On Thu, May 16, 2019 at 11:55 AM Hadley Wickham  wrote:

> Hi all,
>
> The thread seems to have drifted off topic. I really didn't want this
> to devolve into a discussion about when cat() or message() is more
> appropriate — I have complete faith in Jenny Bryan's ability to
> understand technical tradeoffs and pick the most appropriate given the
> constraints. I am most interested in understanding what level of
> discretion CRAN's "Studentischer administrativer Mitarbeiter" have to
> critique the implementation of R packages, particularly for packages
> that do not yield R CMD check problems or otherwise violate CRAN
> policies.
>
> I mean no disrespect towards the CRAN maintainers (whose tireless
> efforts are a crucial part of making R the success that it is), but I
> don't think it's unreasonable to enquire as to who is involved in a
> crucial piece of open source community infrastructure, and, if
> students are involved, what their scope of work is and how they are
> trained and supervised.
>
> I do recognise that my question "Who are they?" may have been
> perceived as overly intrusive. To clarify: I don't want to know names
> or other personally identifying information, but I would like to know
> in general terms how many there are, and what backgrounds they have.
> Similarly, I don't want to know how much they are paid, just whether
> or not they are volunteers or employees.
>
> Hadley
>
> On Tue, May 14, 2019 at 10:23 AM Hadley Wickham 
> wrote:
> >
> > Hi all,
> >
> > Several people on my team have received responses to their CRAN
> > submissions from new members of the CRAN team who appear to be student
> > assistants (judging from their job titles: "Studentischer
> > administrativer Mitarbeiter"). From the outside, they appear to be
> > exercising editorial control[^1] and conducting design reviews[^2].
> >
> > CRAN is a critical piece of R community infrastructure, and I am sure
> > these students have been surrounded by the proper checks and balances,
> > but it's not obvious what their role is from the outside. I'd really
> > appreciate knowing a little more about them:
> >
> > * Who are they?
> >
> > * Are they paid employees or volunteers?
> >
> > * What is their scope of work?
> >
> > * How are they trained?
> >
> > * If we believe that they have made a mistake, how do we request
> >   review from a senior CRAN member?
> >
> > * They appear to be able to apply additional discretionary criteria
> >   that are not included in R CMD check or documented in the CRAN
> policies.
> >   Is this true? If so, what is the scope of these additional checks?
> >
> > Hadley
> >
> > [^1]: The devoid package was rejected because the student assistant
> > did not understand the purpose of the package.
> >
> > [^2]: The gargle package was rejected because the student assistant
> > believed that the use of cat() was incorrect. It was not.
> >
> > --
> > http://hadley.nz
>
>
>
> --
> http://hadley.nz
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
 alejandro baranek
@ken4rab 
qbotics  | rpolyhedra

| surferinvaders  | algebraic-soundscapes
 | surfer-shuffle


[[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 submission and the staged installation false positive check

[Gábor Csárdi]

Anyone had success releasing a package that is affected by the
"Non-staged installation was used" false positive bug?

This one:
https://cran.rstudio.com/web/checks/check_results_igraph.html
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17545

If yes, how did you do it? Thanks!
Gabor

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

Re: [R-pkg-devel] CRAN student assistants

[Jennifer Bryan]

Thanks for the excellent comparable package, Hong.

Today's rejection of gargle instructs me to use \donttest{} instead of
\dontrun{}. Most of the affected functions create, load, and/or refresh
service account tokens and OAuth2 credentials. I see that \dontrun{} is
used in AzureAuth, which does seem more appropriate and is what I did. My
impression is that \donttest{} code is still run under some circumstances.
Perhaps this is another good topic for discussion, now that we've worked
through cat() vs message().

It seems like you've also got a few functions without examples at all
(e.g., format_auth_header(), AzureR_dir()). How does this get through CRAN
review? When is that OK and when is it not?

I would simply like to understand the standards, so that I can impose them
on myself and go through fewer submissions. Maybe we could even automate
some of those checks. That would reduce workload all around.

I've taken your advice to reply via email with full explanation and cc
others at CRAN. Maybe this will also lead to speedy resolution with no fuss.

-- Jenny

On Wed, May 15, 2019 at 2:18 PM Hong Ooi  wrote:

> I had a similar experience with a couple of my package updates needing
> changes. The background is that I have a family of packages for talking to
> Microsoft's Azure cloud service from R, and my examples are all marked
> \dontrun because they need an Azure subscription to work. This had
> previously been cleared with Uwe Ligges, but I guess the other CRAN
> reviewers weren't aware of this.
>
> In both cases, replying to the CRAN email and cc'ing Uwe resolved the
> issue quickly and without fuss.
>
>
> -Original Message-
> From: R-package-devel  On Behalf
> Of Mark van der Loo
> Sent: Thursday, 16 May 2019 1:50 AM
> To: Jennifer Bryan 
> Cc: R Package Development 
> Subject: Re: [R-pkg-devel] CRAN student assistants
>
> For what it's worth,
>
> I recently submitted a new package that was initially refused (with
> comments) by CRAN. I updated number of them accordingly, but there were a
> few that with good reasons I could not change. I explained this in the
> comments when uploading a new version and it got accepted. So I don't see
> the problem.
>
> (The case here was a use of \dontrun{}. I had to switch an example off
> because a warning was thrown which would upset R CMD check. But
> demonstrating the warning was exactly the point of the example.)
>
> All this aside. I think it is extremely unethical to publish privately
> sent CRAN emails on GH, including personal details such as name and e-mail
> address of the sender without their explicit consent.
>
>
> Best,
> Mark
>
>
>
>
>
> On Wed, May 15, 2019 at 4:44 PM Jennifer Bryan 
> wrote:
>
> > Hello,
> >
> > Since this has turned into a worldwide code review, I will briefly
> > address that, then reiterate the point of the original message.
> >
> > I am working on an initial release of a package. It reveals
> > information to a user, sometimes in a print method-y way, sometimes in
> > more of a verbose / debugging way that is under control of a
> > documented option, which defaults to "off" or "quiet". For now, I have
> > chosen to send all of this output through a single functions that,
> > yes, uses cat(). I went this direction for an initial release to keep
> > the package simple and accumulate some user experience. If the
> > "debugging mode" proves to be useful, I will rework it, possibly using
> > UI functionality that I believe our group might release in the future.
> > Rest assured, I understand cat() vs message() and the various
> > tradeoffs. I made mine and it is my impression that package maintainers
> have this level of freedom.
> >
> > The real point is: the currenrt CRAN submission process is designed
> > for one-way communication and there's no guarantee of continuity of
> reviewer.
> > If this type of implementation review is going to happen, it seems
> > that many aspects of the process would need to change, to make sure
> > these new standards are applied consistently to every submission and
> > that existing package are brought up to current standards.
> >
> > To clarify something for Joris, I am not aware of any special channel
> > of communication or influence between CRAN and the R Foundation (of
> > which I am also a member). I think this is an aspect of CRAN vs R
> > Foundation (vs R Core even) that is unclear to many. These entities
> > operate quite independently, except for the fact that specific people
> > belong to more than one. So RF members interact with CRAN the same way
> > as any other of member of the community.
> >
> > -- Jenny
> >
> > On Wed, May 15, 2019 at 6:43 AM Jim Hester 
> > wrote:
> >
> > > Sorry first sentence should read
> > >
> > > I agree that `message()` is ideally preferred, precisely because of
> > > the reasons Martin stated, it is easily controlled by the user.
> > >
> > > On Wed, May 15, 2019 at 9:41 AM Jim Hester
> > > 
> > > wrote:
> > > >
> > > > I agree that `message()` is in a

Re: [R-pkg-devel] CRAN student assistants

[Joris Meys]

On Thu, May 16, 2019 at 4:59 PM Hadley Wickham  wrote:

> Hi all,
>
> I am most interested in understanding what level of
> discretion CRAN's "Studentischer administrativer Mitarbeiter" have to
> critique the implementation of R packages


Ing. is the german title for "Engineer". You made her name public in the
repositories of your own organisation. So at least have the decency to
google her before you question her competence in public. Your obvious lack
of understanding about the Austrian education system is no excuse for
questioning her competence.


> I mean no disrespect towards the CRAN maintainers
>

The respectful thing to do, is to discuss this IN PRIVATE with Dr. Ligges
at the next R foundation in case you really need to know. The unrespectful
thing to do, is to gaslight on a public mailing list to the point you make
others, like Alejandro, question the competence of CRAN maintainers.


>
> I do recognise that my question "Who are they?" may have been
> perceived as overly intrusive.


The word is "bewildering", as you know their names, and your organisation
shared personally identifying information (i.e. her email address which
includes the institute she WORKS for) on their github repo.


> To clarify: I don't want to know names
> or other personally identifying information, but I would like to know
> in general terms how many there are, and what backgrounds they have.
>

That's again something you can ask Dr. Ligges IN PRIVATE at the next R
foundation meeting, and not a subject for an open mailing list. And after
this exchange, I would totally understand if he refuses to answer that.


> Similarly, I don't want to know how much they are paid, just whether
> or not they are volunteers or employees.
>

The budgetary arrangements between a university and their _employee_ are of
no concern to the mailing list. Asking about such arrangements for an
employee that's not yours, is considered highly impolite in Europe.

RStudio has been very vocal on numerous occasions about standards they
hold. I would appreciate if the chief scientist of RStudio abides by those
standards.

Thank you.

-- 
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)


tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

[[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] CRAN student assistants

[Hong Ooi via R-package-devel]

--- Begin Message ---
I don’t think they check _every_ help page for examples. My assumption would be 
that if the main functionality of the package is covered, then functions that 
are clearly ancillary, or whose usage is obvious, get a pass.

Another reason for cloud-related packages to mark things as \dontrun (as 
opposed to \donttest) would be if they deploy resources that have an associated 
cost. You probably don’t want to be charged 50 bucks, or whatever, for 
deploying a compute cluster just by running example().

From: Jennifer Bryan 
Sent: Friday, 17 May 2019 3:10 AM
To: Hong Ooi 
Cc: R Package Development 
Subject: Re: [R-pkg-devel] CRAN student assistants

Thanks for the excellent comparable package, Hong.

Today's rejection of gargle instructs me to use \donttest{} instead of 
\dontrun{}. Most of the affected functions create, load, and/or refresh service 
account tokens and OAuth2 credentials. I see that \dontrun{} is used in 
AzureAuth, which does seem more appropriate and is what I did. My impression is 
that \donttest{} code is still run under some circumstances. Perhaps this is 
another good topic for discussion, now that we've worked through cat() vs 
message().

It seems like you've also got a few functions without examples at all (e.g., 
format_auth_header(), AzureR_dir()). How does this get through CRAN review? 
When is that OK and when is it not?

I would simply like to understand the standards, so that I can impose them on 
myself and go through fewer submissions. Maybe we could even automate some of 
those checks. That would reduce workload all around.

I've taken your advice to reply via email with full explanation and cc others 
at CRAN. Maybe this will also lead to speedy resolution with no fuss.

-- Jenny

On Wed, May 15, 2019 at 2:18 PM Hong Ooi 
mailto:hong...@microsoft.com>> wrote:
I had a similar experience with a couple of my package updates needing changes. 
The background is that I have a family of packages for talking to Microsoft's 
Azure cloud service from R, and my examples are all marked \dontrun because 
they need an Azure subscription to work. This had previously been cleared with 
Uwe Ligges, but I guess the other CRAN reviewers weren't aware of this.

In both cases, replying to the CRAN email and cc'ing Uwe resolved the issue 
quickly and without fuss.


-Original Message-
From: R-package-devel 
mailto:r-package-devel-boun...@r-project.org>>
 On Behalf Of Mark van der Loo
Sent: Thursday, 16 May 2019 1:50 AM
To: Jennifer Bryan mailto:jenny.f.br...@gmail.com>>
Cc: R Package Development 
mailto:r-package-devel@r-project.org>>
Subject: Re: [R-pkg-devel] CRAN student assistants

For what it's worth,

I recently submitted a new package that was initially refused (with
comments) by CRAN. I updated number of them accordingly, but there were a few 
that with good reasons I could not change. I explained this in the comments 
when uploading a new version and it got accepted. So I don't see the problem.

(The case here was a use of \dontrun{}. I had to switch an example off because 
a warning was thrown which would upset R CMD check. But demonstrating the 
warning was exactly the point of the example.)

All this aside. I think it is extremely unethical to publish privately sent 
CRAN emails on GH, including personal details such as name and e-mail address 
of the sender without their explicit consent.


Best,
Mark





On Wed, May 15, 2019 at 4:44 PM Jennifer Bryan 
mailto:jenny.f.br...@gmail.com>>
wrote:

> Hello,
>
> Since this has turned into a worldwide code review, I will briefly
> address that, then reiterate the point of the original message.
>
> I am working on an initial release of a package. It reveals
> information to a user, sometimes in a print method-y way, sometimes in
> more of a verbose / debugging way that is under control of a
> documented option, which defaults to "off" or "quiet". For now, I have
> chosen to send all of this output through a single functions that,
> yes, uses cat(). I went this direction for an initial release to keep
> the package simple and accumulate some user experience. If the
> "debugging mode" proves to be useful, I will rework it, possibly using
> UI functionality that I believe our group might release in the future.
> Rest assured, I understand cat() vs message() and the various
> tradeoffs. I made mine and it is my impression that package maintainers have 
> this level of freedom.
>
> The real point is: the currenrt CRAN submission process is designed
> for one-way communication and there's no guarantee of continuity of reviewer.
> If this type of implementation review is going to happen, it seems
> that many aspects of the process would need to change, to make sure
> these new standards are applied consistently to every submission and
> that existing package are brought up to current standards.
>
> To clarify something for Joris, I am not aware of any special channel
> of communication or influence between CRAN and th

Re: [R-pkg-devel] CRAN student assistants

[Duncan Murdoch]

On 16/05/2019 1:10 p.m., Jennifer Bryan wrote:

Thanks for the excellent comparable package, Hong.

Today's rejection of gargle instructs me to use \donttest{} instead of
\dontrun{}. Most of the affected functions create, load, and/or refresh
service account tokens and OAuth2 credentials. I see that \dontrun{} is
used in AzureAuth, which does seem more appropriate and is what I did. My
impression is that \donttest{} code is still run under some circumstances.
Perhaps this is another good topic for discussion, now that we've worked
through cat() vs message().

It seems like you've also got a few functions without examples at all
(e.g., format_auth_header(), AzureR_dir()). How does this get through CRAN
review? When is that OK and when is it not?


I haven't been involved with CRAN for a couple of years, but for the 
year when I was, one thing that really, really pissed us off was a 
question like this.  Obviously it is better if all functions have 
examples.  When package authors tried to determine the absolute least 
work they could get away with it really wasted our time trying to decide 
which side of the line a particular package fell on.  We tried to be 
consistent, but clearly that would be impossible.


So the answer to your question is:  put excellent examples in all of 
your help pages, and don't try to find the minimally publishable package.




I would simply like to understand the standards, so that I can impose them
on myself and go through fewer submissions. Maybe we could even automate
some of those checks. That would reduce workload all around.


Impose higher standards on yourself than you think are necessary, and 
your packages will be better and will be published faster.


Duncan Murdoch


I've taken your advice to reply via email with full explanation and cc
others at CRAN. Maybe this will also lead to speedy resolution with no fuss.

-- Jenny

On Wed, May 15, 2019 at 2:18 PM Hong Ooi  wrote:


I had a similar experience with a couple of my package updates needing
changes. The background is that I have a family of packages for talking to
Microsoft's Azure cloud service from R, and my examples are all marked
\dontrun because they need an Azure subscription to work. This had
previously been cleared with Uwe Ligges, but I guess the other CRAN
reviewers weren't aware of this.

In both cases, replying to the CRAN email and cc'ing Uwe resolved the
issue quickly and without fuss.


-Original Message-
From: R-package-devel  On Behalf
Of Mark van der Loo
Sent: Thursday, 16 May 2019 1:50 AM
To: Jennifer Bryan 
Cc: R Package Development 
Subject: Re: [R-pkg-devel] CRAN student assistants

For what it's worth,

I recently submitted a new package that was initially refused (with
comments) by CRAN. I updated number of them accordingly, but there were a
few that with good reasons I could not change. I explained this in the
comments when uploading a new version and it got accepted. So I don't see
the problem.

(The case here was a use of \dontrun{}. I had to switch an example off
because a warning was thrown which would upset R CMD check. But
demonstrating the warning was exactly the point of the example.)

All this aside. I think it is extremely unethical to publish privately
sent CRAN emails on GH, including personal details such as name and e-mail
address of the sender without their explicit consent.


Best,
Mark





On Wed, May 15, 2019 at 4:44 PM Jennifer Bryan 
wrote:


Hello,

Since this has turned into a worldwide code review, I will briefly
address that, then reiterate the point of the original message.

I am working on an initial release of a package. It reveals
information to a user, sometimes in a print method-y way, sometimes in
more of a verbose / debugging way that is under control of a
documented option, which defaults to "off" or "quiet". For now, I have
chosen to send all of this output through a single functions that,
yes, uses cat(). I went this direction for an initial release to keep
the package simple and accumulate some user experience. If the
"debugging mode" proves to be useful, I will rework it, possibly using
UI functionality that I believe our group might release in the future.
Rest assured, I understand cat() vs message() and the various
tradeoffs. I made mine and it is my impression that package maintainers

have this level of freedom.


The real point is: the currenrt CRAN submission process is designed
for one-way communication and there's no guarantee of continuity of

reviewer.

If this type of implementation review is going to happen, it seems
that many aspects of the process would need to change, to make sure
these new standards are applied consistently to every submission and
that existing package are brought up to current standards.

To clarify something for Joris, I am not aware of any special channel
of communication or influence between CRAN and the R Foundation (of
which I am also a member). I think this is an aspect of CRAN vs R
Foundation (vs R Core

Re: [R-pkg-devel] CRAN student assistants

[David Hugh-Jones]

Joris,

I have no dog in this fight, but I think you should cool down a bit. Hadley
explained why he thought these people were students: it’s the adjective
studentische in the job description. I don’t think he meant, or implied,
any disrespect to the individuals concerned. He is entitled to ask in
public about CRAN’s process, which is of concern to everybody who deals
with CRAN. Lastly, accusations of “gaslighting” are over the top, and
adding heat to this debate.

If you think it’s wrong to record  correspondence with CRAN in public, you
may have a point – that is a separate topic. I would lean that CRAN
responses ought not to be considered confidential, but perhaps identifying
information should be shared with care. These are quite subtle issues, so
again, thoughtful discussion would be great.

David


On Thu, 16 May 2019 at 18:41, Joris Meys  wrote:

> On Thu, May 16, 2019 at 4:59 PM Hadley Wickham 
> wrote:
>
> > Hi all,
> >
> > I am most interested in understanding what level of
> > discretion CRAN's "Studentischer administrativer Mitarbeiter" have to
> > critique the implementation of R packages
>
>
> Ing. is the german title for "Engineer". You made her name public in the
> repositories of your own organisation. So at least have the decency to
> google her before you question her competence in public. Your obvious lack
> of understanding about the Austrian education system is no excuse for
> questioning her competence.
>
>
> > I mean no disrespect towards the CRAN maintainers
> >
>
> The respectful thing to do, is to discuss this IN PRIVATE with Dr. Ligges
> at the next R foundation in case you really need to know. The unrespectful
> thing to do, is to gaslight on a public mailing list to the point you make
> others, like Alejandro, question the competence of CRAN maintainers.
>
>
> >
> > I do recognise that my question "Who are they?" may have been
> > perceived as overly intrusive.
>
>
> The word is "bewildering", as you know their names, and your organisation
> shared personally identifying information (i.e. her email address which
> includes the institute she WORKS for) on their github repo.
>
>
> > To clarify: I don't want to know names
> > or other personally identifying information, but I would like to know
> > in general terms how many there are, and what backgrounds they have.
> >
>
> That's again something you can ask Dr. Ligges IN PRIVATE at the next R
> foundation meeting, and not a subject for an open mailing list. And after
> this exchange, I would totally understand if he refuses to answer that.
>
>
> > Similarly, I don't want to know how much they are paid, just whether
> > or not they are volunteers or employees.
> >
>
> The budgetary arrangements between a university and their _employee_ are of
> no concern to the mailing list. Asking about such arrangements for an
> employee that's not yours, is considered highly impolite in Europe.
>
> RStudio has been very vocal on numerous occasions about standards they
> hold. I would appreciate if the chief scientist of RStudio abides by those
> standards.
>
> Thank you.
>
> --
> Joris Meys
> Statistical consultant
>
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
> <
> https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g
> >
>
> tel: +32 (0)9 264 61 79
> ---
> Biowiskundedagen 2017-2018
> http://www.biowiskundedagen.ugent.be/
>
> ---
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[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] CRAN student assistants

[Pedro J. Aphalo]

 From the other side of the fence, as an author and maintainer, I regret 
much more when both my own tests and CRAN's have failed to detect a 
problem than when I need to spend some effort to explain that something 
is a false positive. Considering the number of downloads from CRAN, a 
false negative test can cause grief and lost time to many users. A false 
positive causes some extra work only to the developer and CRAN 
maintainers, and I really appreciate the big effort that strict checks 
represents for them.

The other question that was implicit in the justification for the use of 
cat() is that the submission was "design in progress". I think the 
larger and more diverse the community of CRAN users becomes, the less 
justification there is for releasing packages at early stage of 
development through CRAN. Packages will evolve, but once they are in 
CRAN mostly by expanding functionality, rather than changes in design. 
Error handling and documentation should be good enough to ensure the 
package will not be wrongly used by accident. R and CRAN are no longer 
used mainly by statisticians and experts.

Best,

Pedro.

On 2019-05-16 22:42, Duncan Murdoch wrote:
> On 16/05/2019 1:10 p.m., Jennifer Bryan wrote:
>> Thanks for the excellent comparable package, Hong.
>>
>> Today's rejection of gargle instructs me to use \donttest{} instead of
>> \dontrun{}. Most of the affected functions create, load, and/or refresh
>> service account tokens and OAuth2 credentials. I see that \dontrun{} is
>> used in AzureAuth, which does seem more appropriate and is what I 
>> did. My
>> impression is that \donttest{} code is still run under some 
>> circumstances.
>> Perhaps this is another good topic for discussion, now that we've worked
>> through cat() vs message().
>>
>> It seems like you've also got a few functions without examples at all
>> (e.g., format_auth_header(), AzureR_dir()). How does this get through 
>> CRAN
>> review? When is that OK and when is it not?
>
> I haven't been involved with CRAN for a couple of years, but for the 
> year when I was, one thing that really, really pissed us off was a 
> question like this.  Obviously it is better if all functions have 
> examples.  When package authors tried to determine the absolute least 
> work they could get away with it really wasted our time trying to 
> decide which side of the line a particular package fell on.  We tried 
> to be consistent, but clearly that would be impossible.
>
> So the answer to your question is:  put excellent examples in all of 
> your help pages, and don't try to find the minimally publishable package.
>
>
>> I would simply like to understand the standards, so that I can impose 
>> them
>> on myself and go through fewer submissions. Maybe we could even automate
>> some of those checks. That would reduce workload all around.
>
> Impose higher standards on yourself than you think are necessary, and 
> your packages will be better and will be published faster.
>
> Duncan Murdoch
>
>> I've taken your advice to reply via email with full explanation and cc
>> others at CRAN. Maybe this will also lead to speedy resolution with 
>> no fuss.
>>
>> -- Jenny
>>
>> On Wed, May 15, 2019 at 2:18 PM Hong Ooi  wrote:
>>
>>> I had a similar experience with a couple of my package updates needing
>>> changes. The background is that I have a family of packages for 
>>> talking to
>>> Microsoft's Azure cloud service from R, and my examples are all marked
>>> \dontrun because they need an Azure subscription to work. This had
>>> previously been cleared with Uwe Ligges, but I guess the other CRAN
>>> reviewers weren't aware of this.
>>>
>>> In both cases, replying to the CRAN email and cc'ing Uwe resolved the
>>> issue quickly and without fuss.
>>>
>>>
>>> -Original Message-
>>> From: R-package-devel  On Behalf
>>> Of Mark van der Loo
>>> Sent: Thursday, 16 May 2019 1:50 AM
>>> To: Jennifer Bryan 
>>> Cc: R Package Development 
>>> Subject: Re: [R-pkg-devel] CRAN student assistants
>>>
>>> For what it's worth,
>>>
>>> I recently submitted a new package that was initially refused (with
>>> comments) by CRAN. I updated number of them accordingly, but there 
>>> were a
>>> few that with good reasons I could not change. I explained this in the
>>> comments when uploading a new version and it got accepted. So I 
>>> don't see
>>> the problem.
>>>
>>> (The case here was a use of \dontrun{}. I had to switch an example off
>>> because a warning was thrown which would upset R CMD check. But
>>> demonstrating the warning was exactly the point of the example.)
>>>
>>> All this aside. I think it is extremely unethical to publish privately
>>> sent CRAN emails on GH, including personal details such as name and 
>>> e-mail
>>> address of the sender without their explicit consent.
>>>
>>>
>>> Best,
>>> Mark
>>>
>>>
>>>
>>>
>>>
>>> On Wed, May 15, 2019 at 4:44 PM Jennifer Bryan 
>>> 
>>> wrote:
>>>
 Hello,

 Since this has turned into a worldwide code

Re: [R-pkg-devel] CRAN student assistants

[alejandro baranek]

Joris:
I'm sorry about your feelings about my thoughts based on Hadley's related
experience.
I feel lucky to be learning from this community. I'm an R user for many
years, but only became a package developer recently and don't have the
background neither the history in the community for putting in doubt the
efforts the CRAN team make. I red some statistics, but don't have a clear
idea of the amount of work involved in CRAN maintenance. Don't even know
where to look for documentation about it.

If you tell me how can I do, I gladly can give feedback with some
observations IN PRIVATE about  experiences we had publishing in CRAN, for
improving the experience both for the developers and for the maintainers.
I'm sure the problem I want to describe is now solved, because the alarm
was set by CRAN maintainers. It is a very small issue,  by the way.

If there is a way for helping, I'm here.

I repeat, I feel lucky for finding a project (R) where I feel contained in
many of my *strange* curiosity inquires.

All the best, Ale.



On Thu, May 16, 2019 at 2:41 PM Joris Meys  wrote:

> On Thu, May 16, 2019 at 4:59 PM Hadley Wickham 
> wrote:
>
> > Hi all,
> >
> > I am most interested in understanding what level of
> > discretion CRAN's "Studentischer administrativer Mitarbeiter" have to
> > critique the implementation of R packages
>
>
> Ing. is the german title for "Engineer". You made her name public in the
> repositories of your own organisation. So at least have the decency to
> google her before you question her competence in public. Your obvious lack
> of understanding about the Austrian education system is no excuse for
> questioning her competence.
>
>
> > I mean no disrespect towards the CRAN maintainers
> >
>
> The respectful thing to do, is to discuss this IN PRIVATE with Dr. Ligges
> at the next R foundation in case you really need to know. The unrespectful
> thing to do, is to gaslight on a public mailing list to the point you make
> others, like Alejandro, question the competence of CRAN maintainers.
>
>
> >
> > I do recognise that my question "Who are they?" may have been
> > perceived as overly intrusive.
>
>
> The word is "bewildering", as you know their names, and your organisation
> shared personally identifying information (i.e. her email address which
> includes the institute she WORKS for) on their github repo.
>
>
> > To clarify: I don't want to know names
> > or other personally identifying information, but I would like to know
> > in general terms how many there are, and what backgrounds they have.
> >
>
> That's again something you can ask Dr. Ligges IN PRIVATE at the next R
> foundation meeting, and not a subject for an open mailing list. And after
> this exchange, I would totally understand if he refuses to answer that.
>
>
> > Similarly, I don't want to know how much they are paid, just whether
> > or not they are volunteers or employees.
> >
>
> The budgetary arrangements between a university and their _employee_ are of
> no concern to the mailing list. Asking about such arrangements for an
> employee that's not yours, is considered highly impolite in Europe.
>
> RStudio has been very vocal on numerous occasions about standards they
> hold. I would appreciate if the chief scientist of RStudio abides by those
> standards.
>
> Thank you.
>
> --
> Joris Meys
> Statistical consultant
>
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
> <
> https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g
> >
>
> tel: +32 (0)9 264 61 79
> ---
> Biowiskundedagen 2017-2018
> http://www.biowiskundedagen.ugent.be/
>
> ---
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
 alejandro baranek
@ken4rab 
qbotics  | rpolyhedra

| surferinvaders  | algebraic-soundscapes
 | surfer-shuffle


[[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] R CMD check works but with devtools::check() examples fail

[Barbara Lerner]

Hi Dirk,

This is very helpful, thank you!  The R Internals document gave me the 
clues that I need.

I am pretty certain that more things are being checked than before as 
problems are being reported with code that has not changed.  In 
particular, it is checking if logical expressions are returning a vector 
of length > 1.  I had is.null tests where I wanted to check if a 
variable was null.  Unfortunately, when the variable contained a vector, 
it was checking whether the members were null, which is not what I 
intended.  I understand the error reports now and can fix these.

Barbara

Dirk Eddelbuettel wrote on 5/16/19 11:36 AM:
> Hi Barbara
>
> Feel free to CC back to the list which dropped off.
>
> On 16 May 2019 at 10:56, Barbara Lerner wrote:
> | You are right --as-cran gives the same errors as devtools::check.  When
> | it comes to running the examples, what is done differently with the
> | as-cran flag?
>
> Coarse level answer: we are asked to --as-cran per CRAN Repo Policy
>
> Finer level answer: it sets a few more tests, does remote check etc pp which
> is why it is not default. The fuller details are in the R manuals 'Writing R
> Extensions' and (oddly) in Section 8 of 'R Internals' (bad title, makes it as
> if we mortals were not supposed to look there) which details _all_ of the
> _many_ environment variables that can be turned on and off.
>
>  From the top of my head, I am not sure why example would run/not run. That
> has not happened to me in 20+ years of writing / using / binary building
> packages.  But I did not have time to dig -- could use/don't use suggested
> packages, could be honor/disregards \dontrun{} or \donttest{} flags. You will
> know your package better -- with some some digging I am sure you will get to
> it.
>
> Best,  Dirk
>

-- 
Barbara Lerner
Professor
Computer Science Department
Mount Holyoke College



[[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] R CMD check works but with devtools::check() examples fail

[Dirk Eddelbuettel]

Hi Barbara,

On 16 May 2019 at 16:48, Barbara Lerner wrote:
| This is very helpful, thank you!  The R Internals document gave me the 
| clues that I need.

Great!
 
| I am pretty certain that more things are being checked than before as 
| problems are being reported with code that has not changed.  In 
| particular, it is checking if logical expressions are returning a vector 
| of length > 1.  I had is.null tests where I wanted to check if a 

Ah, yes, that is a new check which IIRC only became active with R 3.6.0.

| variable was null.  Unfortunately, when the variable contained a vector, 
| it was checking whether the members were null, which is not what I 
| intended.  I understand the error reports now and can fix these.

Nice.  Glad I could help.

Cheers, Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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