I think what people are also thinking about is that the policy for publishing a package on CRAN is that it have to pass R CMD check with no errors, warnings *or* notes. So, in that sense notes are no different from warnings.
At least that's why I go about and add some rare ad hoc code patching in my code. /Henrik On Fri, Apr 16, 2010 at 2:09 AM, <mark.braving...@csiro.au> wrote: > Speaking as a copious generator of CMD CHECK notes: I don't see that there's > a problem to be solved here-- i.e. I don't see why it's worth changing good > code or adding conventions just to circumvent CMD CHECK notes. (If the code > is bad, of course it should be changed!) As the original poster said, the CMD > CHECK note is only a note, not a warning-- it's checking for "*possible* > problems". With my packages, especially debug & mvbutils, CHECK issues 100s > of lines of "notes", which (after inspection) I don't worry about-- they > arise from RCMD CHECK not understanding my code (eg non-default scopings), > not from coding errors. I would be very unhappy at having to add enormous > amounts of "explanation" to the packages simply to alleviate a non-problem! > > Similarly, some compilers give notes about possibly non-initialized variables > etc, but these are often a result of the compiler not understanding the code. > I do look at them, and decide whether there are problems that need fixing or > not-- it's no big deal to ignore them if not useful. Presumably the RCMD > CHECK notes are useful to some coders, in which case good; but nothing > further really seems needed. > > Mark > > -- > Mark Bravington > CSIRO Mathematical & Information Sciences > Marine Laboratory > Castray Esplanade > Hobart 7001 > TAS > > ph (+61) 3 6232 5118 > fax (+61) 3 6232 5012 > mob (+61) 438 315 623 > > l...@stat.uiowa.edu wrote: >> On Mon, 12 Apr 2010, William Dunlap wrote: >> >>> >>>> -----Original Message----- >>>> From: r-devel-boun...@r-project.org >>>> [mailto:r-devel-boun...@r-project.org] On Behalf Of Henrik Bengtsson >>>> Sent: Monday, April 12, 2010 8:24 AM >>>> To: Duncan Murdoch >>>> Cc: r-devel; Michael Dewey >>>> Subject: Re: [Rd] R CMD check tells me 'no visible binding for >>>> globalvariable ', what does it mean? >>>> >>>> On Mon, Apr 12, 2010 at 5:08 PM, Duncan Murdoch >>>> <murd...@stats.uwo.ca> wrote: >>>>> On 12/04/2010 10:51 AM, Michael Dewey wrote: >>>>>> >>>>>> When I run R CMD check on a package I have recently started work >>>>>> on I get the following: >>>>>> >>>>>> * checking R code for possible problems ... NOTE >>>>>> addlinear: no visible binding for global variable 'x' >>>>>> >>>>>> I appreciate that this is only a NOTE and so I assume is R's >>>>>> equivalent of 'This is perfectly legal but I wonder whether it is >>>>>> really what you intended' but I would like to understand it. >>>>>> >>>>>> In the relevant function addlinear the following function is >>>>>> defined locally: >>>>>> >>>>>> orfun <- function(x, oddsratio) {1/(1+1/(oddsratio * >>>>>> (x/(1-x))))} >>>>>> >>>>>> and then used later in curve >>>>>> >>>>>> curve(orfun(x, exp(estimate)), from = 0.001, to = 0.999, >>>>>> add = TRUE) >>>>>> >>>>>> These are the only occurrences of 'x'. >>>>>> >>>>>> Is it just telling me that I have never assigned a value to x? Or >>>>>> is it more sinister than that? As far as I can tell the function >>>>>> does what I intended. >>>>> >>>>> The curve() function evaluates the first argument in a strange >>>>> way, and this confuses the code checking. (The variable name "x" >>>>> is special to curve().) >>>>> >>>>> I think you can avoid the warning by rewriting that call to >>>>> curve() as >>>>> >>>>> curve(function(x) orfun(x, exp(estimate)), from = 0.001, to = >>>>> 0.999, add = TRUE) >>>> >>>> ...or >>>> >>>> x <- NULL; rm(x); # Dummy to trick R CMD check curve(orfun(x, >>>> exp(estimate)), from = 0.001, to = 0.999, add = TRUE) >>> >>> Or we could come up with a scheme to telling the usage checking >>> functions in codetools that some some or all arguments of certain >>> functions are evaluated in odd ways so it should not check them. >>> E.g., irregularUsage(curve, expr) irregularUsage(lm, subset, >>> formula) # subset and formula arguments of lm >>> irregularUsage(expression, ...) # ... arguments to expression >>> Perhaps one could add such indications to the NAMESPACE file or to a >>> new file in a package. The former is kludgy but the latter requires >>> changes to the packaging system. >>> >> >> This is done at the moment in a very ad hoc way for functions in the >> core packages. I will make a note to add something for curve. This >> is an interesting case, as only the variable 'x' should be viewed as >> special for code analysis purposes if I understand the intent in >> curve properly. >> >> Providing a mechanism for user functions to be annotated for code >> analysis might be useful, and might help in making the handling of >> core package functions with special evaluation rulesa little less ad >> hloc. On the other hand I'm not sure I want to do anything that >> encourages further use of nonstantard evaluation in new code. >> >> luke >> >>> Bill Dunlap >>> Spotfire, TIBCO Software >>> wdunlap tibco.com >>> >>> >>>> >>>> /Henrik >>>> >>>>> >>>>> Duncan Murdoch >>>>> >>>>> ______________________________________________ >>>>> R-devel@r-project.org mailing list >>>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>>> >>>> >>>> ______________________________________________ >>>> R-devel@r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>> >>> >>> ______________________________________________ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
