[Rd] R CMD check for the R code from vignettes

[Kevin Coombes]

"Doc, it hurts when I do this."
"So, don't do that."

If no one in R Core does anything about this issue (in terms of changing 
Sweave or Stangle), then the solution still remains very simple.  
Authors of vignettes should avoid using anything in \Sexpr{} that has a 
side effect. As long as they do that, the code will tangle correctly and 
produce the same result as Sweave.

R CMD check already detects other things which may or may not be 
outright errors but are viewed as bad practice. I think it is bad 
practice to put code with side effects into an Sexpr. So, I don't do 
that. If I did do that accidentally, I really wouldn't mind if R CMD 
check warned me abut it.

   -- Kevin

On 6/2/2014 6:28 PM, Gavin Simpson wrote:
> On 2 June 2014 15:59, Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
>
>> On 03/06/2014, 4:12 AM, Gavin Simpson wrote:
>>
>>> On 2 June 2014 11:44, Duncan Murdoch <murdoch.duncan at gmail.com
>>> <mailto:murdoch.duncan at gmail.com>> wrote:
>>>
>>> ....
>>      Several of us have told you the real harm:  it means that users
>>>      can't easily extract a script that replicates the computations done
>>>      in the vignette.  That's a useful thing to be able to do.
>>>
>>>
>>> Isn't the issue here that `tangle()` doesn't, currently, "extract a
>>> script that replicates the computations done in the vignette", but
>>> rather does so only partially?
>>>
>> No, I think the issue is that some people don't want to have to guarantee
>> that the tangled source produces the same results.  R doesn't guarantee it,
>> it is up to the author to do so.
>
> I think those issues have become conflated on this thread; R CMD check
> issues raised the problem that side effects in \Sexpr may lead to tangle()
> generating an R script that may not work or do so only incorrectly.
>
> Whatever the ensuing discussion; the above issue is not ideal and as you
> mention below it could be solved by not allowing side effects in \Sexpr,
> fixing tangle so that \Sexpr is recorded, or some other workaround.
>
>
>>> People seem to be arguing across one another throughout this thread.
>>> Yihui has identified an infelicity in the tangle implementation. Turning
>>> off tangling + sourcing in R CMD check may not be a desirable solution,
>>> so if the aim is to extract R code to replicate the computations in the
>>> vignette, tangle() needs to be modified to allow for inclusion
>>> (optional) of \Sexpr "chunks".
>>>
>> That's one solution, and the other is to limit \Sexpr code to things with
>> no side effects, as Sweave was originally designed.
>
> That would be perfectly fine also; clarifying usage etc helps and whilst it
> may inconvenience those authors that exploited the ambiguity, there is a
> solution now that anyone can write their own vignette drivers.
>
>
>>
>>> To move this thread forwards, would contributions that added this
>>> optional feature to tangle() be considered by R Core? If so, perhaps
>>> those affected by the current infelicity might wish to propose patches
>>> to the R sources which implement a solution?
>>>
>> As I said before, I'm more sympathetic to that solution than to dropping
>> the requirement that tangled code should work.  I think the changes to base
>> R need only be minimal:  only an extra argument to the driver code for the
>> tangling.  Users who want to use this feature should write their own (or
>> use someone else's if they don't' mind an extra dependency) as a
>> "non-Sweave vignette driver", whose implementation is to call Stangle with
>> the non-default parameter setting.
>>
>> Duncan Murdoch
>>
> I agree, and given that the changes to base R would be minimal and yet
> solve the problem for those wanting to allow & tangle side effects in
> \Sexpr (or allow them to solve it with a driver) it is disappointing to
> note i) the length of this thread (!) and ii) the often irrelevant
> arguments that some contributors have offered. (Do note this is not
> directed specifically at you Duncan.)
>
> It has not gone without notice of late the increasing regularity with which
> threads here descend into irrelevant or antagonistic directions.
>
> G
>