On Aug 27, 2014 5:24 PM, "Hadley Wickham"
> I'd say: Depends is a historical artefact from ye old days before
> package namespaces. Apart from depending on a specific version of R,
> you should basically never use depends. (The one exception is, as
> mentioned in R-exts, if you're writing somethi
On Wed, Aug 27, 2014 at 5:01 PM, Gavin Simpson wrote:
>
> On 27 August 2014 15:24, Hadley Wickham wrote:
>>
>> > Is that the cause of these NOTEs? Is the expectation that if I am using
>> > a
>> > function from a package, even a package that I have in Depends:, that I
>> > have to explicitly decl
On 27 August 2014 16:25, Uwe Ligges wrote:
> Again, I am happy to be re-educated on this though :-)
>>
>
> If you like, you can fill the search path with lots of packages (and make
> masking of functions more likely), but you shoudl really import into your
> namesoace so that unanticipated order
On 28.08.2014 00:19, Gavin Simpson wrote:
On 27 August 2014 16:09, Dan Tenenbaum wrote:
- Original Message -
From: "Gavin Simpson"
To: "Hadley Wickham"
Cc: r-devel@r-project.org
Sent: Wednesday, August 27, 2014 3:01:53 PM
Subject: Re: [Rd] Re R CMD check checking in development ve
On 27 August 2014 16:09, Dan Tenenbaum wrote:
> - Original Message -
> > From: "Gavin Simpson"
> > To: "Hadley Wickham"
> > Cc: r-devel@r-project.org
> > Sent: Wednesday, August 27, 2014 3:01:53 PM
> > Subject: Re: [Rd] Re R CMD check checking in development version of R
> >
> > On 27 A
- Original Message -
> From: "Gavin Simpson"
> To: "Hadley Wickham"
> Cc: r-devel@r-project.org
> Sent: Wednesday, August 27, 2014 3:01:53 PM
> Subject: Re: [Rd] Re R CMD check checking in development version of R
>
> On 27 August 2014 15:24, Hadley Wickham wrote:
>
> > > Is that the
On 27 August 2014 15:24, Hadley Wickham wrote:
> > Is that the cause of these NOTEs? Is the expectation that if I am using a
> > function from a package, even a package that I have in Depends:, that I
> > have to explicitly declare these imports in NAMESPACE?
>
> Yes.
>
> (Otherwise your package
> Is that the cause of these NOTEs? Is the expectation that if I am using a
> function from a package, even a package that I have in Depends:, that I
> have to explicitly declare these imports in NAMESPACE?
Yes.
(Otherwise your package won't work if it's only attached and not
loaded. i.e. if some
Dear list,
This is related to the change discussed in the thread "no visible binding
for global variables for data sets in a package".
I went to look at the Check results for one of my packages (analogue) on
CRAN: http://cran.r-project.org/web/checks/check_results_analogue.html
Under the r-devel
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 27/08/2014 14:43, Simon Urbanek wrote:
Mario,
On Aug 27, 2014, at 4:03 AM, Mario Emmenlauer wrote:
Hello,
I'm very new to R and don't know much about it yet. I would like
to develop R-programs that work with data of sizes of 10^10 - 10^11
data points. We have very-high-memory machines wi
On Aug 27, 2014, at 5:45 AM, Jonathon Love wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> hi,
>
> on OS X, when you try and use something which depends on X11, and you
> don't have XQuartz installed, you receive an error message, it directs
> you to download XQuartz, and then it
Mario,
On Aug 27, 2014, at 4:03 AM, Mario Emmenlauer wrote:
>
> Hello,
>
> I'm very new to R and don't know much about it yet. I would like
> to develop R-programs that work with data of sizes of 10^10 - 10^11
> data points. We have very-high-memory machines with ~256 GB, but it
> would signif
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
>
Re solution 2, the following is in the function tabFarsDead()
the latest (0.55) version of gamclass:
data('FARS', package='gamclass', envir=environment())
FARS <- get("FARS", envir=environment())
The second statement is, strictly, redundant, but it
makes the syntax checker happy. Another pos
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
hi,
on OS X, when you try and use something which depends on X11, and you
don't have XQuartz installed, you receive an error message, it directs
you to download XQuartz, and then it euthanizes your process.
(my guess is that there is a skeleton X11
Hello,
I'm very new to R and don't know much about it yet. I would like
to develop R-programs that work with data of sizes of 10^10 - 10^11
data points. We have very-high-memory machines with ~256 GB, but it
would significantly help if I could store the data points in single
precision in RAM inst
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
27 matches
Mail list logo
