Here is one rationale for the change, which was useful for my understanding
This arises in the survival package in the survexp function:
survexp <- function(formula, data, weights, subset, na.action,
ratetable=survexp.us)
The argument has been changed to survival::survexp.us, soon to be
> peter dalgaard
> on Wed, 27 Aug 2014 21:09:47 +0200 writes:
> On 27 Aug 2014, at 16:48 , Hadley Wickham wrote:
>>> I think the right answer _is_ to export the lazy data; the question is
how to do it. There's nothing particularly strange about exporting
non-functions ("le
On 27 Aug 2014, at 16:48 , Hadley Wickham wrote:
>> I think the right answer _is_ to export the lazy data; the question is how
>> to do it. There's nothing particularly strange about exporting non-functions
>> ("letters" would be an example, save for the special status of
>> package:base). If
On 27 Aug 2014, at 19:51 , Michael Friendly wrote:
> - Peter Dalgaard noted the change in R-devel, and nobody so far has suggested
> a working remedy, so a clean solution
> seems warranted.
Actually, both Peter Dalgaard and Brian Ripley suggested Lahman:battingLabels,
and, with the current s
On Wed, Aug 27, 2014 at 12:51 PM, Michael Friendly wrote:
> On 8/27/2014 10:41 AM, peter dalgaard wrote:
>>
>> Using data() in a package with lazyloaded data seems like asking for
>> trouble to me. But you're making me curious (and I'm too lazy[*] to set up
>> for rebuilding the package myself):
>
On 8/27/2014 10:41 AM, peter dalgaard wrote:
Using data() in a package with lazyloaded data seems like asking for trouble to
me. But you're making me curious (and I'm too lazy[*] to set up for rebuilding
the package myself):
Did you actually try putting battingLabels & friends in the namespace
http://cran.r-project.org/doc/manuals/r-patched/R-exts.html#Suggested-packages
suggests e.g. Lahman::battingLabels, and that does work for lazy-loaded
datasets (which is what these appear to be).
We have seen a couple of other instances in which this was needed for
code within the package. Ho
> I think the right answer _is_ to export the lazy data; the question is how to
> do it. There's nothing particularly strange about exporting non-functions
> ("letters" would be an example, save for the special status of package:base).
> If you attach the package, the lazyloaded data appear in t
Using data() in a package with lazyloaded data seems like asking for trouble to
me. But you're making me curious (and I'm too lazy[*] to set up for rebuilding
the package myself):
Did you actually try putting battingLabels & friends in the namespace? What
happened?
A workaround could be to use
On 8/27/2014 9:29 AM, Michael Friendly wrote:
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".
So, this would be v
On 8/27/2014 5:24 AM, Martin Maechler wrote:
Michael Friendly
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
>
ty, Canberra ACT 0200.
On 27 Aug 2014, at 20:00,
mailto:r-devel-requ...@r-project.org>>
mailto:r-devel-requ...@r-project.org>> wrote:
From: Martin Maechler
mailto:maech...@stat.math.ethz.ch>>
Subject: Re: [Rd] no visible binding for global variable for data sets in a
package
D
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
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 objec
> Michael Friendly
> 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
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
Everyone,
I know that this has been discussed a few times on the list, but I
think that there is a high false positive rate of messages from
findGlobals during R CMD check (I know the help page has that "The
result is an approximation").
Here are two examples of from the caret package:
This func
Just to pick on this: 'how to react?'.
Codetools does have false positives, and non-standard evaluation often
triggers them. I've seen this one several times and pretty clearly a
chararcter string is better style.
But some are just false positives, including those in MASS.
On Fri, 12 Oct 200
Roger Bivand wrote:
> On Fri, 12 Oct 2007, roger koenker wrote:
>
>> Could someone advise me about how to react to the message:
>>
>> * checking R code for possible problems ... NOTE
>> slm: no visible binding for global variable 'response'
>>
>> from R CMD check SparseMwith
>> * using R ver
roger koenker wrote:
> Could someone advise me about how to react to the message:
>
I'd try putting quotes in
model.extract(m, "response")
(and also in
model.extract(m, "weights")
even though you're not seeing the complaint on that one).
> * checking R code for possible problems ... NOTE
>
On Fri, 12 Oct 2007, roger koenker wrote:
> Could someone advise me about how to react to the message:
>
> * checking R code for possible problems ... NOTE
> slm: no visible binding for global variable 'response'
>
> from R CMD check SparseMwith
> * using R version 2.6.0 Under development (uns
Dear Roger,
simply use quotes as in:
model.extract(m, "response")
Best,
Uwe
roger koenker wrote:
> Could someone advise me about how to react to the message:
>
> * checking R code for possible problems ... NOTE
> slm: no visible binding for global variable 'response'
>
> from R CMD check Sp
Could someone advise me about how to react to the message:
* checking R code for possible problems ... NOTE
slm: no visible binding for global variable 'response'
from R CMD check SparseMwith
* using R version 2.6.0 Under development (unstable) (2007-09-03 r42749)
The offending code looks li
On Tue, 17 Apr 2007, Robin Hankin wrote:
> Hello everyone
>
> I am trying to get one of my packages through R's QC.
>
> The package is clean for me under R-2.4.1, R-2.5.0, and
> R-devel, but Kurt gets
Do you have _R_CHECK_USE_CODETOOLS_ set to something true (and for 2.4.1,
codetools installed
Hello everyone
I am trying to get one of my packages through R's QC.
The package is clean for me under R-2.4.1, R-2.5.0, and
R-devel, but Kurt gets
>
> * checking R code for possible problems ... WARNING
> hypercube: no visible binding for global variable âfâ
Function hypercube() [cut-&-p
25 matches
Mail list logo
