Re: [R-pkg-devel] [External] Re: Interpret feedback: not write testthat-tests in examples

[Jeff Newmiller]

Looks like 187 opportunities to improve clarity.

On July 16, 2020 11:30:37 AM PDT, Ben Bolker  wrote:
>FWIW/in defense of the OP, this is a *very* common idiom in the base R 
>code base.  There may be some false positives, but
>
> find . -name "*.Rd" -exec grep -Fl "stopifnot(" {} \; | grep -v doc |
>wc
>
>lists 187 files, e.g. from src/library/utils/man/object.size.Rd
>
>stopifnot(identical( ## assert that all three are the same :
>  unique(substr(as.vector(fsl), 1,5)),
>  format(round(as.vector(sl)/1024, 1
>
>
>On 7/16/20 2:02 PM, luke-tier...@uiowa.edu wrote:
>> On Thu, 16 Jul 2020, Henrik Bengtsson wrote:
>>
>>> If the point of having, say,
>>>
>>> stopifnot(add(1, 2) == sum(c(1, 2))
>>>
>>> is to make it explicit to the reader that your add() function gives
>>> the same results as sum(), then I argue that is valid to use in an
>>> example.  I'm pretty sure I've used that in some of my examples. 
>For
>>> the purpose, there should be no reason why you can't use other
>>> "assert" functions for this purpose, e.g.
>>>
>>> testthat::expect_equal(add(1, 2), sum(c(1, 2))
>>
>> If the point is to communicate this to users I would write something
>like
>>
>> ## The following evaluates to TRUE:
>> add(1, 2) == sum(c(1, 2)
>>
>> Using stopifnot just adds clutter that obscures the message for a
>> human reader; testthat::expect_equal even more so.
>>
>> Best,
>>
>> luke
>>
>>>
>>> Now, if the point of your "assert" statement is only to validate
>your
>>> package/code, then I agree it should not be in the example code
>>> because it adds clutter.  Such validation should be in a package
>test.
>>>
>>> So, if the former, I suggest you reply to the CRAN Team and explain 
>>> this.
>>>
>>> /Henrik
>>>
>>> On Thu, Jul 16, 2020 at 6:28 AM Richel Bilderbeek
>>>  wrote:

 Dear R package developers,

 I would enjoy some help regarding some feedback I got on my package
>
 from a CRAN volunteer, as I am unsure how to interpret this
>correctly.

 This is the feedback I got (I added '[do]'):

> Please [do] not write testthat-tests in your examples.

 I wonder if this is about using `testthat` or using tests in
>general.

 To simplify the context, say I wrote a package with a function 
 called `add`, that adds two numbers. My example code would then be 
 something like this:

 ```
 library(testthat)

 expect_equal(add(1, 2), 3)
 ```

 The first interpretation is about using `testthat`: maybe I should 
 use base R (`stopifnot`) or another testing library (`testit`) or 
 hand-craft it myself?

 The second interpretation is about using tests in example code. I 
 like to actively demonstrate that my code works as expected. I 
 checked the policies regarding examples, and I could not find a
>rule 
 that I should refrain from doing so.

 What is the correct response to this feedback?

 Thanks for your guidance, Richel Bilderbeek

 __
 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

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] [External] Re: Interpret feedback: not write testthat-tests in examples

[Steven Scott]

I agree with the consensus that documentation is for humans, while tests
are for computers.

On Thu, Jul 16, 2020, 8:41 PM  wrote:

> On Thu, 16 Jul 2020, Ben Bolker wrote:
>
> > FWIW/in defense of the OP, this is a *very* common idiom in the base R
> code
> > base.  There may be some false positives, but
> >
> >  find . -name "*.Rd" -exec grep -Fl "stopifnot(" {} \; | grep -v doc | wc
> >
> > lists 187 files, e.g. from src/library/utils/man/object.size.Rd
>
> And I probably wrote some of them, but I don't think I would now.
> As a rule, I think the documentation is clearer without the tests.
>
> On the other hand, we don't all agree on these things.
>
> >
> > stopifnot(identical( ## assert that all three are the same :
> >  unique(substr(as.vector(fsl), 1,5)),
> >  format(round(as.vector(sl)/1024, 1
> >
> >
> > On 7/16/20 2:02 PM, luke-tier...@uiowa.edu wrote:
> >> On Thu, 16 Jul 2020, Henrik Bengtsson wrote:
> >>
> >>> If the point of having, say,
> >>>
> >>> stopifnot(add(1, 2) == sum(c(1, 2))
> >>>
> >>> is to make it explicit to the reader that your add() function gives
> >>> the same results as sum(), then I argue that is valid to use in an
> >>> example.  I'm pretty sure I've used that in some of my examples.  For
> >>> the purpose, there should be no reason why you can't use other
> >>> "assert" functions for this purpose, e.g.
> >>>
> >>> testthat::expect_equal(add(1, 2), sum(c(1, 2))
> >>
> >> If the point is to communicate this to users I would write something
> like
> >>
> >> ## The following evaluates to TRUE:
> >> add(1, 2) == sum(c(1, 2)
> >>
> >> Using stopifnot just adds clutter that obscures the message for a
> >> human reader; testthat::expect_equal even more so.
> >>
> >> Best,
> >>
> >> luke
> >>
> >>>
> >>> Now, if the point of your "assert" statement is only to validate your
> >>> package/code, then I agree it should not be in the example code
> >>> because it adds clutter.  Such validation should be in a package test.
> >>>
> >>> So, if the former, I suggest you reply to the CRAN Team and explain
> this.
> >>>
> >>> /Henrik
> >>>
> >>> On Thu, Jul 16, 2020 at 6:28 AM Richel Bilderbeek
> >>>  wrote:
> 
>  Dear R package developers,
> 
>  I would enjoy some help regarding some feedback I got on my package
> from
>  a CRAN volunteer, as I am unsure how to interpret this correctly.
> 
>  This is the feedback I got (I added '[do]'):
> 
> > Please [do] not write testthat-tests in your examples.
> 
>  I wonder if this is about using `testthat` or using tests in general.
> 
>  To simplify the context, say I wrote a package with a function called
>  `add`, that adds two numbers. My example code would then be something
>  like this:
> 
>  ```
>  library(testthat)
> 
>  expect_equal(add(1, 2), 3)
>  ```
> 
>  The first interpretation is about using `testthat`: maybe I should
> use
>  base R (`stopifnot`) or another testing library (`testit`) or
> hand-craft
>  it myself?
> 
>  The second interpretation is about using tests in example code. I
> like
>  to actively demonstrate that my code works as expected. I checked the
>  policies regarding examples, and I could not find a rule that I
> should
>  refrain from doing so.
> 
>  What is the correct response to this feedback?
> 
>  Thanks for your guidance, Richel Bilderbeek
> 
>  __
>  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
> >
>
> --
> Luke Tierney
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa  Phone: 319-335-3386
> Department of Statistics andFax:   319-335-3017
> Actuarial Science
> 241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
> Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu
> __
> R-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] [External] Re: Interpret feedback: not write testthat-tests in examples

[luke-tierney]

On Thu, 16 Jul 2020, Ben Bolker wrote:

FWIW/in defense of the OP, this is a *very* common idiom in the base R code 
base.  There may be some false positives, but


 find . -name "*.Rd" -exec grep -Fl "stopifnot(" {} \; | grep -v doc | wc

lists 187 files, e.g. from src/library/utils/man/object.size.Rd


And I probably wrote some of them, but I don't think I would now.
As a rule, I think the documentation is clearer without the tests.

On the other hand, we don't all agree on these things.



stopifnot(identical( ## assert that all three are the same :
 unique(substr(as.vector(fsl), 1,5)),
 format(round(as.vector(sl)/1024, 1


On 7/16/20 2:02 PM, luke-tier...@uiowa.edu wrote:

On Thu, 16 Jul 2020, Henrik Bengtsson wrote:


If the point of having, say,

stopifnot(add(1, 2) == sum(c(1, 2))

is to make it explicit to the reader that your add() function gives
the same results as sum(), then I argue that is valid to use in an
example.  I'm pretty sure I've used that in some of my examples.  For
the purpose, there should be no reason why you can't use other
"assert" functions for this purpose, e.g.

testthat::expect_equal(add(1, 2), sum(c(1, 2))


If the point is to communicate this to users I would write something like

## The following evaluates to TRUE:
add(1, 2) == sum(c(1, 2)

Using stopifnot just adds clutter that obscures the message for a
human reader; testthat::expect_equal even more so.

Best,

luke



Now, if the point of your "assert" statement is only to validate your
package/code, then I agree it should not be in the example code
because it adds clutter.  Such validation should be in a package test.

So, if the former, I suggest you reply to the CRAN Team and explain this.

/Henrik

On Thu, Jul 16, 2020 at 6:28 AM Richel Bilderbeek
 wrote:


Dear R package developers,

I would enjoy some help regarding some feedback I got on my package from 
a CRAN volunteer, as I am unsure how to interpret this correctly.


This is the feedback I got (I added '[do]'):


Please [do] not write testthat-tests in your examples.


I wonder if this is about using `testthat` or using tests in general.

To simplify the context, say I wrote a package with a function called 
`add`, that adds two numbers. My example code would then be something 
like this:


```
library(testthat)

expect_equal(add(1, 2), 3)
```

The first interpretation is about using `testthat`: maybe I should use 
base R (`stopifnot`) or another testing library (`testit`) or hand-craft 
it myself?


The second interpretation is about using tests in example code. I like 
to actively demonstrate that my code works as expected. I checked the 
policies regarding examples, and I could not find a rule that I should 
refrain from doing so.


What is the correct response to this feedback?

Thanks for your guidance, Richel Bilderbeek

__
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



--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
   Actuarial Science
241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Failing rhub::check_for_cran() because of data.table

[Gábor Csárdi]

Hi, this is because data.table is not available as a binary package
for R-devel, on CRAN. You can tell R to build it from source like
this:

rhub::check(
  platform="windows-x86_64-devel",
  env_vars=c(R_COMPILE_AND_INSTALL_PACKAGES = "always")
)

Btw. please report R-ghub errors in the issue tracker, e.g.
https://github.com/r-hub/rhub/issues/367#issuecomment-621757715

Thanks,
Gabor

On Mon, Jul 13, 2020 at 8:22 PM Chuck Powell  wrote:
>
> Hi,
>
> My first posting.  Apologies in advance if I misspeak or am asking a dumb
> question.
>
> I maintain a small package on CRAN
> https://cran.r-project.org/web/packages/CGPfunctions/index.html
>
> Source is on Github here https://github.com/ibecav/CGPfunctions/
>
> Recently received note I needed to fix my package because of changes to
> broom.  Corrections made and everything passes locally.
>
> When I submit to rhub::check_for_cran() however it creates an error in the
> development branch
> *Build ID:* CGPfunctions_0.6.2.tar.gz-3e48a7f97fa04b64924552dc50b43fd2
>
>
> with:
>
> #> Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()),
> versionCheck = vI[[j]]) :
>
> 1181
> #>
> Calls: ... loadNamespace -> withRestarts -> withOneRestart ->
> doWithOneRestart
>
> 1182
> #>
> Execution halted
>
> 1183
> #>
> there is no package called 'data.table'
>
> 1184
> #>
> ERROR: lazy loading failed for package 'CGPfunctions'
>
> 1185
> #>
> * removing 'C:/Users/USERDFJOuzrklm/R/CGPfunctions'
>
>
>
> Looking at data.table on CRAN I see there is no windows binary
> Windows binaries: r-devel: not available
> ,
>
>
> I don't use any data.table functions, I don't import it, or suggest it or
> enhance it it's being pulled in through some dependency in car and/or broom.
>
> Am I okay to submit to CRAN?  Is there a setting I can change?
> Obviously data.table exists despite what Rhub is reporting.
>
> Thank you hopefully that is a clear enough description.
>
> Chuck
>
> [[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] Interpret feedback: not write testthat-tests in examples

[Mark van der Loo]

Dear Richel,

The comment itself is pretty clear I think: to be accepted on CRAN you
should not use testthat tests in your examples.

I can't speak for CRAN but I'm pretty convinced this is for testing in
general.

Tests are for testing, not for demonstration. Most users of your package
will probably have never heard of testthat because they are not package
authors. They also probably don't need testthat to use your package, so it
distracts them from learning how your package works. Packages like testthat
(and RUnit, unity and tinytest) are in the first place aimed at package
authors to make sure that their package works as it should and to avoid
re-introducing bugs (regressions).



Best,
Mark




On Thu, Jul 16, 2020 at 3:28 PM Richel Bilderbeek <
ric...@richelbilderbeek.nl> wrote:

> Dear R package developers,
>
> I would enjoy some help regarding some feedback I got on my package from a
> CRAN volunteer, as I am unsure how to interpret this correctly.
>
> This is the feedback I got (I added '[do]'):
>
> > Please [do] not write testthat-tests in your examples.
>
> I wonder if this is about using `testthat` or using tests in general.
>
> To simplify the context, say I wrote a package with a function called
> `add`, that adds two numbers. My example code would then be something like
> this:
>
> ```
> library(testthat)
>
> expect_equal(add(1, 2), 3)
> ```
>
> The first interpretation is about using `testthat`: maybe I should use
> base R (`stopifnot`) or another testing library (`testit`) or hand-craft it
> myself?
>
> The second interpretation is about using tests in example code. I like to
> actively demonstrate that my code works as expected. I checked the policies
> regarding examples, and I could not find a rule that I should refrain from
> doing so.
>
> What is the correct response to this feedback?
>
> Thanks for your guidance, Richel Bilderbeek
>
> __
> 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

[R-pkg-devel] Interpret feedback: not write testthat-tests in examples

[Richel Bilderbeek]

Dear R package developers,

I would enjoy some help regarding some feedback I got on my package from a CRAN 
volunteer, as I am unsure how to interpret this correctly.

This is the feedback I got (I added '[do]'):

> Please [do] not write testthat-tests in your examples.

I wonder if this is about using `testthat` or using tests in general.

To simplify the context, say I wrote a package with a function called `add`, 
that adds two numbers. My example code would then be something like this:

```
library(testthat)

expect_equal(add(1, 2), 3)
```

The first interpretation is about using `testthat`: maybe I should use base R 
(`stopifnot`) or another testing library (`testit`) or hand-craft it myself?

The second interpretation is about using tests in example code. I like to 
actively demonstrate that my code works as expected. I checked the policies 
regarding examples, and I could not find a rule that I should refrain from 
doing so.

What is the correct response to this feedback?

Thanks for your guidance, Richel Bilderbeek

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

Re: [R-pkg-devel] Interpret feedback: not write testthat-tests in examples

[Robert M. Flight]

Richel,

I think that feedback is important. Examples are examples first, and tests
second, as in if your examples no longer work, then maybe you need to check
your underlying code.

{testthat} tests belong in their own `tests` directory, and are used to
directly test your code and provide feedback about whether your code is
working.

The pattern I normally see if you want to directly check the output of an
example is a `stopifnot(x == y)`, but I've never observed having
`expect_equal` in example code.

There might not be a policy against it, but I think the general expectation
is that {testthat} code stays in `tests`, not in examples in the
documentation.

-Robert

On Thu, Jul 16, 2020 at 9:28 AM Richel Bilderbeek <
ric...@richelbilderbeek.nl> wrote:

> Dear R package developers,
>
> I would enjoy some help regarding some feedback I got on my package from a
> CRAN volunteer, as I am unsure how to interpret this correctly.
>
> This is the feedback I got (I added '[do]'):
>
> > Please [do] not write testthat-tests in your examples.
>
> I wonder if this is about using `testthat` or using tests in general.
>
> To simplify the context, say I wrote a package with a function called
> `add`, that adds two numbers. My example code would then be something like
> this:
>
> ```
> library(testthat)
>
> expect_equal(add(1, 2), 3)
> ```
>
> The first interpretation is about using `testthat`: maybe I should use
> base R (`stopifnot`) or another testing library (`testit`) or hand-craft it
> myself?
>
> The second interpretation is about using tests in example code. I like to
> actively demonstrate that my code works as expected. I checked the policies
> regarding examples, and I could not find a rule that I should refrain from
> doing so.
>
> What is the correct response to this feedback?
>
> Thanks for your guidance, Richel Bilderbeek
>
> __
> 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

[R-pkg-devel] [SOLVED] Interpret feedback: not write testthat-tests in examples

[Richel Bilderbeek]

Dear R package developers,

Thanks so much for the generous responses!

In summary:

- one should usually not write tests in examples, that's what the 'tests' 
folder is for
- if there is a demonstration, use a simple stopifnot, as one cannot assume a 
regular reader knows about the testthat package

Thanks again and the best, Richel Bilderbeek


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

Re: [R-pkg-devel] [External] Re: Interpret feedback: not write testthat-tests in examples

[Ben Bolker]

FWIW/in defense of the OP, this is a *very* common idiom in the base R 
code base.  There may be some false positives, but


 find . -name "*.Rd" -exec grep -Fl "stopifnot(" {} \; | grep -v doc | wc

lists 187 files, e.g. from src/library/utils/man/object.size.Rd

stopifnot(identical( ## assert that all three are the same :
 unique(substr(as.vector(fsl), 1,5)),
 format(round(as.vector(sl)/1024, 1


On 7/16/20 2:02 PM, luke-tier...@uiowa.edu wrote:

On Thu, 16 Jul 2020, Henrik Bengtsson wrote:


If the point of having, say,

stopifnot(add(1, 2) == sum(c(1, 2))

is to make it explicit to the reader that your add() function gives
the same results as sum(), then I argue that is valid to use in an
example.  I'm pretty sure I've used that in some of my examples.  For
the purpose, there should be no reason why you can't use other
"assert" functions for this purpose, e.g.

testthat::expect_equal(add(1, 2), sum(c(1, 2))


If the point is to communicate this to users I would write something like

## The following evaluates to TRUE:
add(1, 2) == sum(c(1, 2)

Using stopifnot just adds clutter that obscures the message for a
human reader; testthat::expect_equal even more so.

Best,

luke



Now, if the point of your "assert" statement is only to validate your
package/code, then I agree it should not be in the example code
because it adds clutter.  Such validation should be in a package test.

So, if the former, I suggest you reply to the CRAN Team and explain 
this.


/Henrik

On Thu, Jul 16, 2020 at 6:28 AM Richel Bilderbeek
 wrote:


Dear R package developers,

I would enjoy some help regarding some feedback I got on my package 
from a CRAN volunteer, as I am unsure how to interpret this correctly.


This is the feedback I got (I added '[do]'):


Please [do] not write testthat-tests in your examples.


I wonder if this is about using `testthat` or using tests in general.

To simplify the context, say I wrote a package with a function 
called `add`, that adds two numbers. My example code would then be 
something like this:


```
library(testthat)

expect_equal(add(1, 2), 3)
```

The first interpretation is about using `testthat`: maybe I should 
use base R (`stopifnot`) or another testing library (`testit`) or 
hand-craft it myself?


The second interpretation is about using tests in example code. I 
like to actively demonstrate that my code works as expected. I 
checked the policies regarding examples, and I could not find a rule 
that I should refrain from doing so.


What is the correct response to this feedback?

Thanks for your guidance, Richel Bilderbeek

__
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] Anyone Know How To Setup Wine for Windows Testing?

[Steve Bronder]

On Wed, Jul 15, 2020 at 2:22 PM Neal Fultz  wrote:

> If you don't mind multi-gig docker containers, this can be helpful:
>
> https://github.com/scottyhardy/docker-wine
>
> It doesn't work with 64 bit versions of R as far as I could tell, but 32
> bit did install and start correctly in a few clicks when I tried last year.
>

Thanks! I'm hoping if I can get this all working locally I can put
everything into a docker container for other folks. At this point I have R
up and running and it can install binary packages, but there are some
terrible terrible Cygwin/Rtools errors I can't figure out. In particular
this warning / message seems worrisome

Cygwin WARNING:
  Couldn't compute FAST_CWD pointer.  This typically occurs if you're using
  an older Cygwin version on a newer Windows.  Please update to the latest
  available Cygwin version from https://cygwin.com/.  If the problem
persists,
  please see https://cygwin.com/problems.html

If anyone has interest I can post a script for setting up the wine instance
as far as I can get atm.


>
>
>
>
> On Wed, Jul 15, 2020 at 10:56 AM J C Nash  wrote:
>
>> Are you sure you want to try to run R etc. under Wine?
>>
>
Do I want to? No :-). But we (Stan) want to use flto and are seeing errors
on windows I want to be able to debug locally.


>
>> - If you have Windows running, either directly or in a VM, you can run R
>> there.
>>
>
Sadly I don't have access to a windows machine. If I can't figure this out
then I'll probably just get a windows aws instance. But it would be nice
for people to have a wine setup they could test locally on.


> - If you have Windows and want to run R under some other OS, then set up a
>> VM
>> e.g., Linux Mint, for that. I sometimes test R for Windows in a
>> VirtualBox VM
>> for Win10, but generally run in Linux Mint. I've also run R in some Linux
>> VMs
>> to test for specific dependencies in some distros.
>>
>> I rather doubt R will run very well in Linux under Wine. My experience
>> with Wine
>> is that a few apps (e.g. Irfanview) run well, but many give lots of
>> trouble.
>>
>
Yes I'm 80/20 on whether compilation with Rtools will totally work on wine.
But if I can get this all setup and put it into a docker file I think it
will be useful for other people as well so it's worth spending a bit of
time on.


>
>> JN
>>
>>
>> On 2020-07-15 1:17 p.m., Steve Bronder wrote:
>> > Does anyone know of a setup guide for getting R and Rtools 4.0 up and
>> > running on Wine with the Windows Server 2008 R2 VM? Do other maintainers
>> > with more knowhow think that would be useful for debugging purposes?
>> >
>> > I've been trying to test out some flto gcc things for windows by
>> setting up
>> > a local wine VM on my ubuntu box. Wine has an option for Windows Server
>> > 2008 R2 (which I believe is the windows session CRAN uses?) If anyone
>> has
>> > done this before and knows of a guide somewhere that would be very
>> helpful!
>> >
>> > Regards,
>> >
>> > Steve Bronder
>> >
>> >   [[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
>
>
- Steve Bronder

[[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] Interpret feedback: not write testthat-tests in examples

[Henrik Bengtsson]

If the point of having, say,

stopifnot(add(1, 2) == sum(c(1, 2))

is to make it explicit to the reader that your add() function gives
the same results as sum(), then I argue that is valid to use in an
example.  I'm pretty sure I've used that in some of my examples.  For
the purpose, there should be no reason why you can't use other
"assert" functions for this purpose, e.g.

testthat::expect_equal(add(1, 2), sum(c(1, 2))

Now, if the point of your "assert" statement is only to validate your
package/code, then I agree it should not be in the example code
because it adds clutter.  Such validation should be in a package test.

So, if the former, I suggest you reply to the CRAN Team and explain this.

/Henrik

On Thu, Jul 16, 2020 at 6:28 AM Richel Bilderbeek
 wrote:
>
> Dear R package developers,
>
> I would enjoy some help regarding some feedback I got on my package from a 
> CRAN volunteer, as I am unsure how to interpret this correctly.
>
> This is the feedback I got (I added '[do]'):
>
> > Please [do] not write testthat-tests in your examples.
>
> I wonder if this is about using `testthat` or using tests in general.
>
> To simplify the context, say I wrote a package with a function called `add`, 
> that adds two numbers. My example code would then be something like this:
>
> ```
> library(testthat)
>
> expect_equal(add(1, 2), 3)
> ```
>
> The first interpretation is about using `testthat`: maybe I should use base R 
> (`stopifnot`) or another testing library (`testit`) or hand-craft it myself?
>
> The second interpretation is about using tests in example code. I like to 
> actively demonstrate that my code works as expected. I checked the policies 
> regarding examples, and I could not find a rule that I should refrain from 
> doing so.
>
> What is the correct response to this feedback?
>
> Thanks for your guidance, Richel Bilderbeek
>
> __
> 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] Interpret feedback: not write testthat-tests in examples

[Jeff Newmiller]

The point of an example is to provide an illustration of how the function 
should be used for people who are not software developers. IMO any use of any 
other functions should be absolutely minimized to reduce the cognitive overload 
("you need to understand 13 other concepts before you can understand what this 
function does"). Even stopifnot is in my view best avoided, and if you choose 
to use it then the use of that function should come _after_ the use of the 
function so it can be ignored by the reader without disrupting their reading of 
the example.

Complex interactions between functions should be described in vignettes, and 
tests should be stored in test code. R package help already has a reputation 
for being obtuse to beginners and mixing tests into examples exacerbates that 
perception.

On July 16, 2020 10:39:45 AM PDT, Henrik Bengtsson  
wrote:
>If the point of having, say,
>
>stopifnot(add(1, 2) == sum(c(1, 2))
>
>is to make it explicit to the reader that your add() function gives
>the same results as sum(), then I argue that is valid to use in an
>example.  I'm pretty sure I've used that in some of my examples.  For
>the purpose, there should be no reason why you can't use other
>"assert" functions for this purpose, e.g.
>
>testthat::expect_equal(add(1, 2), sum(c(1, 2))
>
>Now, if the point of your "assert" statement is only to validate your
>package/code, then I agree it should not be in the example code
>because it adds clutter.  Such validation should be in a package test.
>
>So, if the former, I suggest you reply to the CRAN Team and explain
>this.
>
>/Henrik
>
>On Thu, Jul 16, 2020 at 6:28 AM Richel Bilderbeek
> wrote:
>>
>> Dear R package developers,
>>
>> I would enjoy some help regarding some feedback I got on my package
>from a CRAN volunteer, as I am unsure how to interpret this correctly.
>>
>> This is the feedback I got (I added '[do]'):
>>
>> > Please [do] not write testthat-tests in your examples.
>>
>> I wonder if this is about using `testthat` or using tests in general.
>>
>> To simplify the context, say I wrote a package with a function called
>`add`, that adds two numbers. My example code would then be something
>like this:
>>
>> ```
>> library(testthat)
>>
>> expect_equal(add(1, 2), 3)
>> ```
>>
>> The first interpretation is about using `testthat`: maybe I should
>use base R (`stopifnot`) or another testing library (`testit`) or
>hand-craft it myself?
>>
>> The second interpretation is about using tests in example code. I
>like to actively demonstrate that my code works as expected. I checked
>the policies regarding examples, and I could not find a rule that I
>should refrain from doing so.
>>
>> What is the correct response to this feedback?
>>
>> Thanks for your guidance, Richel Bilderbeek
>>
>> __
>> 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

-- 
Sent from my phone. Please excuse my brevity.

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

Re: [R-pkg-devel] [External] Re: Interpret feedback: not write testthat-tests in examples

[luke-tierney]

On Thu, 16 Jul 2020, Henrik Bengtsson wrote:


If the point of having, say,

stopifnot(add(1, 2) == sum(c(1, 2))

is to make it explicit to the reader that your add() function gives
the same results as sum(), then I argue that is valid to use in an
example.  I'm pretty sure I've used that in some of my examples.  For
the purpose, there should be no reason why you can't use other
"assert" functions for this purpose, e.g.

testthat::expect_equal(add(1, 2), sum(c(1, 2))


If the point is to communicate this to users I would write something like

## The following evaluates to TRUE:
add(1, 2) == sum(c(1, 2)

Using stopifnot just adds clutter that obscures the message for a
human reader; testthat::expect_equal even more so.

Best,

luke



Now, if the point of your "assert" statement is only to validate your
package/code, then I agree it should not be in the example code
because it adds clutter.  Such validation should be in a package test.

So, if the former, I suggest you reply to the CRAN Team and explain this.

/Henrik

On Thu, Jul 16, 2020 at 6:28 AM Richel Bilderbeek
 wrote:


Dear R package developers,

I would enjoy some help regarding some feedback I got on my package from a CRAN 
volunteer, as I am unsure how to interpret this correctly.

This is the feedback I got (I added '[do]'):


Please [do] not write testthat-tests in your examples.


I wonder if this is about using `testthat` or using tests in general.

To simplify the context, say I wrote a package with a function called `add`, 
that adds two numbers. My example code would then be something like this:

```
library(testthat)

expect_equal(add(1, 2), 3)
```

The first interpretation is about using `testthat`: maybe I should use base R 
(`stopifnot`) or another testing library (`testit`) or hand-craft it myself?

The second interpretation is about using tests in example code. I like to 
actively demonstrate that my code works as expected. I checked the policies 
regarding examples, and I could not find a rule that I should refrain from 
doing so.

What is the correct response to this feedback?

Thanks for your guidance, Richel Bilderbeek

__
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



--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
   Actuarial Science
241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu

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