From spencer.graves at prodsyse.com  Thu Mar 29 16:43:02 2012
From: spencer.graves at prodsyse.com (Spencer Graves)
Date: Thu, 29 Mar 2012 07:43:02 -0700
Subject: [Rd] CRAN policies
In-Reply-To: <20340.27787.279109.551834@max.nulle.part>
References: <CB9770B4.36D98%jeff.a.ryan@gmail.com>
	<4F731B09.5000203@statistik.tu-dortmund.de>
	<CAP01uRmob_VSmgVc80yek3g4D3K0tedmmU1EbmHJ3CCpgRQDgw@mail.gmail.com>
	<CAJ55+d+cTBjmhWt86W=fQMJq2_Zxib-4ufTobbF7z7W1LYfDyg@mail.gmail.com>
	<1333025892.27217.141.camel@brian-rcg>
	<20340.27787.279109.551834@max.nulle.part>
Message-ID: <4F7474F6.6040300@prodsyse.com>

On 3/29/2012 7:07 AM, Dirk Eddelbuettel wrote:
> On 29 March 2012 at 07:58, Brian G. Peterson wrote:
> | On Thu, 2012-03-29 at 16:52 +1300, Thomas Lumley wrote:
> |>  The 'No visible binding for global variable" is a good example.  This
> |>  found some bugs in my 'survey' package, which I removed. There is
> |>  still one note of this type, which arises when I have to handle two
> |>  different versions of the hexbin package with different internal
> |>  structures.  The note is a false positive because the use is guarded
> |>  by an if(), but  CMD check can't tell this.   So, it's a good idea to
> |>  remove all Notes that can be removed without introducing other code
> |>  problems, which is nearly all of them, but occasionally there may be a
> |>  good reason for code that produces a Note.
> |>
> | 'occasionally' seems like an understatement.
> |
> | Here's an example:
> |
> | data(cars)
> | lm(speed ~ dist,cars) #would produce global variables NOTE
> | lm("speed ~ dist",cars) # would not produce the NOTE


Another example using library(ggplot2):


=qplot(time., value, data=X, geom='line',
                     facets=facets, color=variable, xlim=xlim, ylim=ylim,
                     xlab='days', ylab='displacement (inches)', ...),


       "value" and "variable" are columns of "X".  If I knew how to list 
this in an "overrides" file, I would do so.  My experience is similar to 
what others mentioned:  99 percent of the "No visible bindings" messages 
I've seen are my coding errors.  This one is not.  I don't recall for 
sure, but I think I checked trying putting "value" and "variable" in 
quotes, and it didn't work.


       The function that includes this call to "qplot" actually includes 
the definition of a global variable "time.", which is NOT used, because 
"X" has a column named "time.".  The global variable "time." is a 
character string, while "X$time." is class POSIXct.


       I mention this, because this discussion suddenly told me how to 
get rid of this NOTE:  Precede this call to qplot with something like 
the following:


       value <- variable <- "NOTE:  Define these variables to override 
the NOTE impulse in R CMD check'


       I haven't tried this with "qplot", but it ignores the global 
variable "Time." and uses the "Time." column of "X", so it should work.  
I just tried something similar with "lm", and it ignored a global 
variable in favor of a column of "X".  This is a silly kludge, but it's 
simple and does not require a modification to "R CMD check".


       Spencer


> |
> | While the change required to avoid the CRAN NOTE is small, I can't think
> | of a single example or text on using formulas that recommends quoting
> | the formula as a best practice.  I'm not sure how users or package
> | authors are supposed to know that they should use a (non standard) way
> | of specifying the formula to avoid wasting their time, and the CRAN
> | volunteers time.  I'm certain that there are many other examples, but
> | this one was easy to demonstrate.
>
> And it's close to my personal favourite of
>
>      with( cars,  ... some expression involving dist and / or speed ... )
>
> which gives the same warning about dist and speed being unknown globals.
> Punishment for good coding style -- gotta love it.
>
>
> Now, we all want high-quality packages.
>
> We all strive to have as few false positives.
>
> And we all understand that writing a parser if freaking hard.
>
> One fudge-y way of helping with this may be via an overrides file.
>
> This is what Debian does to suppress known / tolerated violations of what the
> 'lintian' package checker picks up on.  For the R package, I have a fair
> number of these: the file for the r-base-core binary is currently 83 lines
> long and this ends on
>
>    r-base-core: executable-not-elf-or-script usr/lib/R/bin/Rdiff
>    r-base-core: image-file-in-usr-lib usr/lib/R/library/graphics/help/figures/mai.png
>    r-base-core: image-file-in-usr-lib usr/lib/R/library/graphics/help/figures/oma.png
>    r-base-core: image-file-in-usr-lib usr/lib/R/library/graphics/help/figures/pch.png
>    r-base-core: executable-not-elf-or-script usr/lib/R/bin/Rd2pdf
>
> two warnings on files with 755 modes in a non-PATH location (fine, that's how
> R works) and idem with image files below /usr/lib (when the FHS probably
> prefers them below /usr/share/).
>
> You pipe the output of a lintian run into 'lintian-info' and you get longer
> one or two paragraph descriptions with further pointers on the violations.
>
> Does this sounds like something worthwhile to add to the R CMD check system ?
>
> Should we consider to allow overrides to make known good exceptions good away?
>
> Dirk
>



[Rd] CRAN policies
Spencer Graves