From jwiley.psych at gmail.com  Wed Aug 27 12:47:28 2014
From: jwiley.psych at gmail.com (Joshua Wiley)
Date: Wed, 27 Aug 2014 20:47:28 +1000
Subject: [Rd] no visible binding for global variable for data sets in a
	package
In-Reply-To: <38F4FA18-F930-4B08-A87E-36583576AB38@gmail.com>
References: <53FD030A.1020709@yorku.ca>
	<21501.41940.216907.982935@stat.math.ethz.ch>
	<38F4FA18-F930-4B08-A87E-36583576AB38@gmail.com>
Message-ID: <CANz9Z_+Bwz7avU55Yh9UV-V4fOZYrdWkkziBeMhQYw3PLuXSWg@mail.gmail.com>

I have had similar notes, but in cases where the dataset was created
internally by a function:

* checking R code for possible problems ... NOTE
vm_diagnostics: no visible binding for global variable 'Median'
vm_diagnostics: no visible binding for global variable 'Index'
vm_diagnostics: no visible binding for global variable 'LL'
vm_diagnostics: no visible binding for global variable 'UL'

and the relevant code is here (the function creates a dataset called
'sigma' and always names the variables Index, Median, LL, UL):

  p.sigma <- ggplot(sigma, aes(Index, Median, ymin = LL, ymax = UL)) +
    geom_pointrange() +
    labs(y = "Median + 95% CI for Sigma") +
    theme_classic()

is the appropriate way to remove warnings in this case also to have the
function attach the data it internally created?




On Wed, Aug 27, 2014 at 8:09 PM, peter dalgaard <pdalgd at gmail.com> wrote:

> The change would seem to be this
>
>       \item \command{R CMD check} now by default checks code usage
>       directly on the package namespace without loading and attaching
>       the package and its suggests and enhances.
>
> and perhaps the remedies could be stated more clearly?
>
> Putting the data objects in the namespace would seem the obvious thing to
> do.
>
> One oddity is that they are sort of in there already:
>
> > Lahman::battingLabels
>     variable                             label
> 1   playerID                    Player ID code
> 2     yearID                              Year
> 3      stint                    Player's stint
> 4     teamID                              Team
> 5       lgID                            League
> 6          G                             Games
> 7  G_batting                   Games as batter
> 8         AB                           At Bats
> 9          R                              Runs
> 10         H                              Hits
> 11       X2B                           Doubles
> 12       X3B                           Triples
> 13        HR                          Homeruns
> 14       RBI                    Runs Batted In
> 15        SB                      Stolen Bases
> 16        CS                   Caught Stealing
> 17        BB                     Base on Balls
> 18        SO                        Strikeouts
> 19       IBB                 Intentional walks
> 20       HBP                      Hit by pitch
> 21        SH                    Sacrifice hits
> 22        SF                   Sacrifice flies
> 23      GIDP        Grounded into double plays
> 24     G_Old Old version of games (deprecated)
>
> But then again, actually not:
>
> > Lahman::Label()
> Error in rbind(battingLabels, pitchingLabels, fieldingLabels) :
>   object 'battingLabels' not found
>
> This is documented (:: can access datasets made available by
> lazy-loading), but it sort of suggests that we might want to improve
> consistency in this area.
>
> -pd
>
>
> On 27 Aug 2014, at 11:24 , Martin Maechler <maechler at stat.math.ethz.ch>
> wrote:
>
> >>>>>> Michael Friendly <friendly at yorku.ca>
> >>>>>>    on Tue, 26 Aug 2014 17:58:34 -0400 writes:
> >
> >> I'm updating the Lahman package of baseball statistics to the 2013
> >> release. In addition to
> >> the main data sets, the package also contains several convenience
> >> functions that make use
> >> of these data sets.  These now trigger the notes below from R CMD check
> >> run with
> >> Win builder, R-devel.  How can I avoid these?
> >
> >> * using R Under development (unstable) (2014-08-25 r66471)
> >> * using platform: x86_64-w64-mingw32 (64-bit)
> >> ...
> >> * checking R code for possible problems ... NOTE
> >> Label: no visible binding for global variable 'battingLabels'
> >> Label: no visible binding for global variable 'pitchingLabels'
> >> Label: no visible binding for global variable 'fieldingLabels'
> >> battingStats: no visible binding for global variable 'Batting'
> >> battingStats: no visible global function definition for 'mutate'
> >> playerInfo: no visible binding for global variable 'Master'
> >> teamInfo: no visible binding for global variable 'Teams'
> >
> >> One such function:
> >
> >> ## function for accessing variable labels
> >
> >> Label <- function(var, labels=rbind(battingLabels, pitchingLabels,
> >> fieldingLabels)) {
> >> wanted <- which(labels[,1]==var)
> >> if (length(wanted)) labels[wanted[1],2] else var
> >> }
> >
> > and you are using the data sets you mentioned before,
> > (and the checking has been changed recently here).
> >
> > This is a bit subtle:
> > Your data sets are part of your package (thanks to the default
> > lazyData), but *not* part of the namespace of your package.
> > Now, the reasoning goes as following: if someone uses a function
> > from your package, say Label() above,
> > by
> >       Lahman::Label(..)
> > and your package has not been attached to the search path,
> > your user will get an error, as the datasets are not found by
> > Label().
> >
> > If you consider something like   Lahman::Label(..)
> > for a bit and the emphasis we put on R functions being the
> > primary entities, you can understand the current, i.e. new,
> > R CMD check warnings.
> >
> > I see the following two options for you:
> >
> > 1) export all these data sets from your NAMESPACE
> >   For this (I thinK), you must define them in  Lahman/R/ possibly via a
> >   Lahman/R/sysdata.rda
> >
> > 2) rewrite your functions such that ensure the data sets are
> >   loaded when they are used.
> >
> >
> > "2)" actually works by adding
> >       stopifnot(require(Lahman, quietly=TRUE))
> >  as first line in Label() and other such functions.
> >
> > It works in the sense that  Lahman::Label("yearID")  will
> > work even when Lahman is not in the search path,
> > but   R-devel CMD check   will still give the same NOTE,
> > though you can argue that that note is actally a "false positive".
> >
> > Not sure about another elegant way to make "2)" work, apart from
> > using  data() on each of the datasets inside the
> > function.  As I haven't tried it, that may *still* give a
> > (false) NOTE..
> >
> > This is a somewhat interesting problem, and I wonder if everyone
> > else has solved it with '1)' rather than a version of '2)'.
> >
> > Martin
> >
> > ______________________________________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Joshua F. Wiley
Ph.D. Student, UCLA Department of Psychology
http://joshuawiley.com/
Senior Analyst, Elkhart Group Ltd.
http://elkhartgroup.com
Office: 260.673.5518

	[[alternative HTML version deleted]]



[Rd] no visible binding for global variable for data sets in a package
Joshua Wiley