[Rd] R CMD check tells me 'no visible binding for globalvariable ', what does it mean?
John Fox
jfox at mcmaster.ca
Fri Apr 16 14:40:34 CEST 2010
Dear all,
I think that "notes" were introduced precisely to differentiate between
situations that may be innocuous and those that are more serious, the latter
producing "warnings" and "errors." The Rcmdr package, for example, generates
a whack of notes for code that works correctly and that I don't know how to
rewrite to get rid of the notes -- not to say that it would necessarily be
impossible to do so. Eliminating all packages that produce R CMD check notes
from CRAN is not a good idea, in my opinion.
Best,
John
--------------------------------
John Fox
Senator William McMaster
Professor of Social Statistics
Department of Sociology
McMaster University
Hamilton, Ontario, Canada
web: socserv.mcmaster.ca/jfox
> -----Original Message-----
> From: r-devel-bounces at r-project.org [mailto:r-devel-bounces at r-project.org]
On
> Behalf Of Henrik Bengtsson
> Sent: April-16-10 4:39 AM
> To: Mark.Bravington
> Cc: murdoch; luke; r-devel; info
> Subject: Re: [Rd] R CMD check tells me 'no visible binding for
globalvariable
> ', what does it mean?
>
> 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.Bravington at 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
> >
> > luke at stat.uiowa.edu wrote:
> >> On Mon, 12 Apr 2010, William Dunlap wrote:
> >>
> >>>
> >>>> -----Original Message-----
> >>>> From: r-devel-bounces at r-project.org
> >>>> [mailto:r-devel-bounces at 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
> >>>> <murdoch at 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 at r-project.org mailing list
> >>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>>>>
> >>>>
> >>>> ______________________________________________
> >>>> R-devel at r-project.org mailing list
> >>>> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>>>
> >>>
> >>> ______________________________________________
> >>> R-devel at r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-devel
> > ______________________________________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
More information about the R-devel
mailing list