> Mick Jordan
> on Tue, 28 Apr 2015 18:11:54 -0700 writes:
> I was surprised by this:
> R --interactive -e 'interactive()'
> bash-3.2$ R -q -e 'interactive()' --interactive
>> interactive()
> [1] FALSE
>>
> as the command options document says that --int
mkdir "A&"
R
# install.packages("pkgKitten")
pkgKitten::kitten("aPackage", "A&")
q()
R CMD INSTALL "A&"
gives
Warning invalid package A
(not the absence of the ampersand)
I'm reasonably certain this is a bug - I don't think ampersands should
require any additional escaping when already double qu
On Tue, Apr 28, 2015 at 3:04 PM, Gábor Csárdi wrote:
>
>
> E.g. if package 'ggplot2' uses 'stats::density()', and package 'igraph'
> also defines 'density()', and 'igraph' is on the search path, then
> 'ggplot2' will call 'igraph::density()' instead of 'stats::density()'.
Just to be clear: you m
Hi!
Some time ago, I replaced calls to library() with calls to
requireNamespace() in my package logmult, in order to follow the new
CRAN policies. But I just noticed it broke jackknife/bootstrap using
several workers via package parallel.
The reason is that I'm running model replicates on the wor
On Wed, Apr 29, 2015 at 12:53 PM, Winston Chang
wrote:
> On Tue, Apr 28, 2015 at 3:04 PM, Gábor Csárdi
> wrote:
> >
> >
> > E.g. if package 'ggplot2' uses 'stats::density()', and package 'igraph'
> > also defines 'density()', and 'igraph' is on the search path, then
> > 'ggplot2' will call 'igra
Hi Milan,
I expect I may be able to do something about the way the terms are
evaluated, to ensure the evaluation is done in the gnm namespace (while
still ensuring the variables can be found!).
In the meantime, I think the following will work:
Mult <- gnm::Mult
f <- Freq ~ Eye + Hair + Mult(Eye
Le mercredi 29 avril 2015 à 18:27 +0100, Heather Turner a écrit :
> Hi Milan,
>
> I expect I may be able to do something about the way the terms are
> evaluated, to ensure the evaluation is done in the gnm namespace (while
> still ensuring the variables can be found!).
>
> In the meantime, I thin
Gabor,
To play devil's advocate a bit, why not just have the package formally
import the functions it wants to use (or the whole package if that is
easier)? Also, if your package Depends on another package, instead of
importing it (e.g. because the end user will need functions in it in order
to m
On Wed, Apr 29, 2015 at 1:45 PM, Gabriel Becker
wrote:
> Gabor,
>
> To play devil's advocate a bit, why not just have the package formally
> import the functions it wants to use (or the whole package if that is
> easier)?
>
This is exactly my goal. And to facilitate this, R CMD check could remi
Dear all,
I noticed that the dimnames returned by apply are different in the new release.
In the following example. The returned row-names are c(“S”,”T”), but shouldn’t
they be c(“X”,”Y”) as in the old release?
Best,
Bernd
>X = array(1:8, dim=c(4,2))
>dimnames(X) = list(c("A","B","C","D"),c("
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've finally been able to piece this together, but I wonder if I've
got it right/whether there is anywhere the behaviour of `model.matrix`
with respect to `na.action` is more *explicitly* documented.
* model.matrix() respects the 'na.action' argum
On 29/04/2015 1:57 PM, Gábor Csárdi wrote:
On Wed, Apr 29, 2015 at 1:45 PM, Gabriel Becker
wrote:
> Gabor,
>
> To play devil's advocate a bit, why not just have the package formally
> import the functions it wants to use (or the whole package if that is
> easier)?
>
This is exactly my goal. A
All,
Here are two ideas on this:
1. have R CMD check show how every external function reference gets
resolved.
2. have R CMD check warn anytime there is a potential name conflict, e.g.
density( ) coming from either igraph or stats, and show how it was
resolved.
Either could be an option. I g
On Wed, Apr 29, 2015 at 3:28 PM, John Nolan wrote:
[...]
> 1. have R CMD check show how every external function reference gets
> resolved.
>
That's not possible, because it depends on the currently attached packages,
and even on the order of their attachment.
> 2. have R CMD check warn anytime
On Wed, Apr 29, 2015 at 3:24 PM, Duncan Murdoch
wrote:
[...]
> Yes, people can do this already. But why not help them with a NOTE if they
>> don't know that this is good practice, or they just simply forget?
>>
>
> I suspect the reason for this is historical: at the time that the current
> warni
On 04/28/2015 01:04 PM, Gábor Csárdi wrote:
When a symbol in a package is resolved, R looks into the package's
environment, and then into the package's imports environment. Then, if the
symbol is still not resolved, it looks into the base package. So far so
good.
If still not found, it follows t
On Wed, Apr 29, 2015 at 4:24 PM, Martin Morgan
wrote:
> On 04/28/2015 01:04 PM, Gábor Csárdi wrote:
>
[...]
> E.g. if package 'ggplot2' uses 'stats::density()', and package 'igraph'
>> also defines 'density()', and 'igraph' is on the search path, then
>> 'ggplot2' will call 'igraph::density()' i
> And in general a developer would avoid masking a function
> in a base package, so as not to require the user to distinguish
> between stats::density() and igraph::density(). Maybe the
> example is not meant literally.
The 'filter' function in the popular 'dplyr' package masks the one
that has be
On 04/29/2015 05:38 PM, William Dunlap wrote:
And in general a developer would avoid masking a function
in a base package, so as not to require the user to distinguish
between stats::density() and igraph::density(). Maybe the
example is not meant literally.
The 'filter' function in the popula
On Wed, Apr 29, 2015 at 8:12 PM, Paul Gilbert wrote:
>
> As I recall, several packages mask the simulate generic in stats, if you
> are looking for examples.
>
FWIW, here is a list of base* functions masked** by CRAN packages:
https://github.com/gaborcsardi/rfunctions/blob/master/rfunctions.md
Lo
20 matches
Mail list logo
