R devel - Apr 2010 - R CMD check tells me 'no visible binding for globalvariable'

Henrik wrote: 

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.
---------------------------------

Getting rid of these notes would be very hard in the survival package.
The population survival routines (survexp, pyears) that have to deal
with dates try to be very accommodating wrt the date format the user
chose, so have constructions like
   if (user date looks like a chron object) {
         calculation using chron functions
         }
   else if (is from the date package) {
        use mdy.date }
   else if (Date object)

etc

   Most of the functions inside the {} cause a warning note because of
course the necessary packages for each case are not present when
survival is built.  Since we deal with medical studies that span
multiple years or even decades, I and others in my group benefit
directly from this date handling: it was not added solely from a
humanitarian impulse.
   
  It's a minor nuisance, since I have to read through the messages after
each build to see if something I actually do need to worry about turns
up.  It has happened, in which case I'm thankful for the message.
(Although it would be nice if there were a way to generate more context.
Once one was for an undefined variable 'n', which was not easy to find
using a text editor.)

Terry Therneau

On Fri, 16 Apr 2010, Therneau, Terry M., Ph.D. wrote:
> 'Henrik' wrote:
>
> 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.
I think that policy is a figment of his imagination.  'NOTE' was 
introduced to allow tentative warnings: we for example note .Rd errors 
that we can correct and warn (so far) on those we cannot.
> ---------------------------------
>
> Getting rid of these notes would be very hard in the survival package.
> The population survival routines (survexp, pyears) that have to deal
> with dates try to be very accommodating wrt the date format the user
> chose, so have constructions like
>   if (user date looks like a chron object) {
>         calculation using chron functions
>         }
>   else if (is from the date package) {
>        use mdy.date }
>   else if (Date object)
>
> etc
>
>   Most of the functions inside the {} cause a warning note because of
> course the necessary packages for each case are not present when
> survival is built.  Since we deal with medical studies that span
> multiple years or even decades, I and others in my group benefit
> directly from this date handling: it was not added solely from a
> humanitarian impulse.
>
>  It's a minor nuisance, since I have to read through the messages after
> each build to see if something I actually do need to worry about turns
> up.  It has happened, in which case I'm thankful for the message.
> (Although it would be nice if there were a way to generate more context.
> Once one was for an undefined variable 'n', which was not easy to
find
> using a text editor.)
We do load all the Depends and Suggests packages when doing the 
codetools checks, so I think that

Suggests: date, chron, timeDate

would solve this. It leaves

predict.coxph: no visible global function definition for ?labels.lm?
predict.coxph: no visible global function definition for ?Build.terms?
predict.survreg: no visible global function definition for ?labels.lm?
predict.survreg: no visible global function definition for  ?Build.terms?
survpenal.fit: no visible global function definition for ?new.frame?
survpenal.fit: possible error in get("coxlist1", frame = rho): unused
   argument(s) (frame = rho)
survpenal.fit: possible error in get("coxlist2", frame = rho): unused
   argument(s) (frame = rho)
survreg.fit: no visible global function definition for ?new.frame?

which are I think all from S-Plus specific code.

Brian Ripley

>
> Terry Therneau
>
>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595