enenbaum
wrote:
Michael, do you know if this change will be (or has already
been)
backported into R-3.3.0?
Thanks.
Dan
- Original Message -
From: "Lihua Zhu"
To: "Dan Tenenbaum" , "Michael
Lawrence"
Cc: "bioc-devel"
Sent: Tuesday, April 5, 20
gt;> >> > Which package Can I update to get the new import argument.
> >> >> > Thanks
> >> >> > Karim
> >> >> >
> >> >> >
> >> >> > On Tue, Apr 5, 2016 at 6:50 PM, Michael Lawrence
> >> >> >
> >> >&
devel on behalf of Dan Tenenbaum"
>> >> >> >> > >> >> >> dtene...@fredhutch.org>
>> >> >> >> wrote:
>> >> >> >>
>> >> >> >>>BTW, looks like the change has been made to
>> I will try to sneak that in since it seems to work and it would be
> >> >> nice to use it before this Fall.
> >> >>
> >> >> On Tue, Apr 5, 2016 at 10:32 AM, Dan Tenenbaum <
> dtene...@fredhutch.org>
> >> >> wrote:
> >&
it before this Fall.
>> >>
>> >> On Tue, Apr 5, 2016 at 10:32 AM, Dan Tenenbaum
>> >> wrote:
>> >> > Michael, do you know if this change will be (or has already been)
>> >> > backported into R-3.3.0?
>> >> >
>> &g
orted into R-3.3.0?
> >> >
> >> > Thanks.
> >> > Dan
> >> >
> >> >
> >> > - Original Message -
> >> >> From: "Lihua Zhu"
> >> >> To: "Dan Tenenbaum" , "Michael Law
ge -
>> >> From: "Lihua Zhu"
>> >> To: "Dan Tenenbaum" , "Michael Lawrence"
>> >>
>> >> Cc: "bioc-devel"
>> >> Sent: Tuesday, April 5, 2016 9:49:26 AM
>> >> Subject: Re: [Bio
.3.0?
> >
> > Thanks.
> > Dan
> >
> >
> > - Original Message -
> >> From: "Lihua Zhu"
> >> To: "Dan Tenenbaum" , "Michael Lawrence" <
> lawrence.mich...@gene.com>
> >> Cc: "bioc-devel"
; - Original Message -
>> From: "Lihua Zhu"
>> To: "Dan Tenenbaum" , "Michael Lawrence"
>>
>> Cc: "bioc-devel"
>> Sent: Tuesday, April 5, 2016 9:49:26 AM
>> Subject: Re: [Bioc-devel] namespace question
>
ject.
>>org_blosxom.cgi_R-2Ddevel_NEWS_2016_04_02-23n2016-2D04-2D02&d=BQIGaQ&c=WJB
>>j9sUF1mbpVIAf3biu3CPHX4MeRjY_w4DerPlOmhQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5g
>>JMlij5cC5bLU&m=HCJuUKMo50mOyjfD0AtQzV69c0SnACXTGdX_iHcWRfo&s=MbBj5lNGwkIfP
>>hrHI2clfQd1aq1yPyROa3utKrCP4ug&e=
>>
LU&m=HCJuUKMo50mOyjfD0AtQzV69c0SnACXTGdX_iHcWRfo&s=MbBj5lNGwkIfP
>hrHI2clfQd1aq1yPyROa3utKrCP4ug&e=
>
>
>
>- Original Message -
>> From: "Michael Lawrence"
>> To: "Hervé Pagès"
>> Cc: "Michael Lawrence" , "bioc-devel"
>>
>>
quot;
>
> Sent: Saturday, April 2, 2016 4:10:10 AM
> Subject: Re: [Bioc-devel] namespace question
> Also, just btw, there are two other places where arbitrary R code can
> be evaluated in the NAMESPACE, but no one has abused them yet. as far
> as I know. The first argument to
Also, just btw, there are two other places where arbitrary R code can
be evaluated in the NAMESPACE, but no one has abused them yet. as far
as I know. The first argument to if() and the .fixes argument to
useDynLib(). The latter sets the precedent for the except= behavior.
Although someone forgot t
At the same time, it would empower developers, who should be free to
assume their own risks. There are already many ways an R user can
break things.
But I agree with the simplicity argument. NAMESPACE, while conforming
to R syntax, does not have "standard" R semantics. Mixing semantics,
especially
On 04/01/2016 01:39 PM, Michael Lawrence wrote:
Yes, it's arbitrary R code that is evaluated, so paste0() would work.
You're right that it's a big door and could let people do weird
things. Do you foresee a problem with that?
Opening such a big door raises many questions. In addition to allowin
Yes, it's arbitrary R code that is evaluated, so paste0() would work.
You're right that it's a big door and could let people do weird
things. Do you foresee a problem with that?
I guess one could have implemented NAMESPACE parsing by evaluating the
code in an environment (inheriting from the base
On 03/31/2016 04:07 PM, Michael Lawrence wrote:
I agree. The importExcept idea also works that way: importExcept(foo, bar, baz)
But import(foo, except=c(bar, baz)) reads better.
mmh... so R expressions with calls to base functions like base::c() are
making their way in the NAMESPACE file. That
I agree. The importExcept idea also works that way: importExcept(foo, bar, baz)
But import(foo, except=c(bar, baz)) reads better.
On Thu, Mar 31, 2016 at 4:00 PM, wrote:
> I don't think you want to separate it from the import. Better to allow
> something like
>
> import(foo, exclude=bar)
>
> o
I don't think you want to separate it from the import. Better to allow
something like
import(foo, exclude=bar)
or
import(foo, exclude=c("bar", "baz"))
This seems reasonably natural and shouldn't be too hard to
implement. (But is has been a while since I've worked on this code).
Best,
luke
O
I think "From" is needed to specify which package we want to exlude
functions.
I think excludeFrom (package, function) seems to be intuitive.
thanks,
Karim
On Thu, Mar 31, 2016 at 9:54 PM, Hervé Pagès wrote:
> On 03/31/2016 12:55 PM, Michael Lawrence wrote:
>
>> Probably should just stick
On 03/31/2016 12:55 PM, Michael Lawrence wrote:
Probably should just stick to exact symbols for now. If there is a
case where a pattern is actually useful, rather than just an
obfuscation, we can extend the feature set.
Fair enough. Not really intuitive that excludeImport uses the same
syntax a
Probably should just stick to exact symbols for now. If there is a
case where a pattern is actually useful, rather than just an
obfuscation, we can extend the feature set.
On Thu, Mar 31, 2016 at 12:11 PM, Zhu, Lihua (Julie)
wrote:
> Herve,
>
> That is a very interesting idea and works for me! Th
Herve,
That is a very interesting idea and works for me! Thanks!
importPatternFrom(IRanges, "^values$")
Best,
Julie
On 3/31/16 2:51 PM, "Bioc-devel on behalf of Hervé Pagès"
wrote:
>On 03/30/2016 08:35 PM, Michael Lawrence wrote:
>> That would work, but R is not going to be happy about redu
On 03/30/2016 08:35 PM, Michael Lawrence wrote:
That would work, but R is not going to be happy about redundant
imports. Interactively, users would balk at symbol qualification.
There are two classes of conflict:
1) Same semantics, where a common generic would arbitrate, or one
package could dep
ael Lawrence
> Cc: Lihua Julie Zhu , "bioc-devel@r-project.org"
>
> Subject: Re: [Bioc-devel] namespace question
>
> Of course, that depends on whether Julie actually uses hash::values or this
> is just trying to avoid a conflict. Importing IRanges piecewise is ...
> pr
On 03/31/2016 07:05 AM, Michael Lawrence wrote:
We should probably deprecate values(). It has long been superseded by
mcols().
FWIW this is on my long-term list but it can't be done now. values()
was originally (and is still) a RangedData accessor. At some point it
was also made a synonym of el
But using hash::values() is not so bad.
On Thu, Mar 31, 2016 at 7:09 AM, Kasper Daniel Hansen
wrote:
> Of course, that depends on whether Julie actually uses hash::values or this
> is just trying to avoid a conflict. Importing IRanges piecewise is ...
> probably difficult.
>
> Best,
> Kasper
>
>
...@gmail.com>>
Date: Thursday, March 31, 2016 9:09 AM
To: Michael Lawrence
mailto:lawrence.mich...@gene.com>>
Cc: Lihua Julie Zhu mailto:julie@umassmed.edu>>,
"bioc-devel@r-project.org<mailto:bioc-devel@r-project.org>"
mailto:bioc-devel@r-project.org>
Of course, that depends on whether Julie actually uses hash::values or this
is just trying to avoid a conflict. Importing IRanges piecewise is ...
probably difficult.
Best,
Kasper
On Thu, Mar 31, 2016 at 10:05 AM, Michael Lawrence <
lawrence.mich...@gene.com> wrote:
> We should probably depreca
We should probably deprecate values(). It has long been superseded by
mcols(). But for now, it would seem pragmatic to importFrom(hash, ...)
since it has so few functions.
On Thu, Mar 31, 2016 at 6:54 AM, Zhu, Lihua (Julie)
wrote:
> Sorry. I meant values.
>
> replacing previous import ŒIRanges::v
Sorry. I meant values.
replacing previous import ŒIRanges::values¹ by Œhash::values¹ when loading
ŒCRISPRseek¹
Best,
Julie
On 3/30/16 11:13 PM, "Michael Lawrence" wrote:
>I can't find the hash function in IRanges. Are you sure it has one?
>
>On Wed, Mar 30, 2016 at 8:07 PM, Zhu, Lihua (Juli
That would work, but R is not going to be happy about redundant
imports. Interactively, users would balk at symbol qualification.
There are two classes of conflict:
1) Same semantics, where a common generic would arbitrate, or one
package could depend on the other, and
2) Different semantics, in w
In the cases of having conflicting names, is it not appropriate then to use
the "package::function" form for calling a particular function?
On Wed, Mar 30, 2016 at 11:14 PM Michael Lawrence
wrote:
> I can't find the hash function in IRanges. Are you sure it has one?
>
> On Wed, Mar 30, 2016 at 8
I can't find the hash function in IRanges. Are you sure it has one?
On Wed, Mar 30, 2016 at 8:07 PM, Zhu, Lihua (Julie)
wrote:
> Michael,
>
> I have the same user case as Kasper. Another example is that both IRanges
> and hash packages have hash. I need to use the hash from the hash package
> ins
Michael,
I have the same user case as Kasper. Another example is that both IRanges and
hash packages have hash. I need to use the hash from the hash package instead
of the one from IRanges.
Best,
Julie
On Mar 30, 2016, at 7:57 PM, Kasper Daniel Hansen
mailto:kasperdanielhan...@gmail.com>> wr
For this particular use case I think we might just make Biobase depend on
matrixStats and then go forward.
On Wed, Mar 30, 2016 at 8:22 PM, Michael Lawrence wrote:
> Thanks. If we can identify specific conflicts between popular
> packages, we might be able to work around them. I think S4Vectors
Thanks. If we can identify specific conflicts between popular
packages, we might be able to work around them. I think S4Vectors is
coming to depend on matrixStats, so those conflicts will start
happening a lot more often now.
Michael
On Wed, Mar 30, 2016 at 4:56 PM, Kasper Daniel Hansen
wrote:
>
My usecase is when I import() two packages who has a conflict in a name.
For example, both Biobase and matrixStats has both anyMissing and
rowMedians. I am happy to get all of these two packages, but I need to
resolve the conflict. Since I want to keep the ones from matrixStats I
know need to figu
I'm curious about which symbols you wouldn't want to import, and why.
On Wed, Mar 30, 2016 at 12:19 PM, Zhu, Lihua (Julie)
wrote:
> Hi,
>
> Is there a function to import all the exported objects from a package except
> a few named ones in NAMESPACE file?
>
> For example, I would like to import a
Lihua Julie Zhu mailto:julie@umassmed.edu>>
Cc: "bioc-devel@r-project.org<mailto:bioc-devel@r-project.org>"
mailto:bioc-devel@r-project.org>>
Subject: Re: [Bioc-devel] namespace question
No, as far as I know. I asked about this on R-devel a long time ago; would
No, as far as I know. I asked about this on R-devel a long time ago; would
be nice to have importFromExcept()
Best,
Kasper
On Wed, Mar 30, 2016 at 3:19 PM, Zhu, Lihua (Julie)
wrote:
> Hi,
>
> Is there a function to import all the exported objects from a package
> except a few named ones in NAME
Hi,
Is there a function to import all the exported objects from a package except a
few named ones in NAMESPACE file?
For example, I would like to import all the functions in S4Vectors except fold.
Is there a way to specify this without listing all other functions using
importFrom?
Many thank
Martin, Hervé,
this is great! thanks for nailing this one down. it wasn't anything
critical to my package but it was making me feel unsure about how
namespaces work, and moreover, i've learned the use of
'requireNamespace()' !!
cheers,
robert.
On 10/09/2014 09:40 PM, Hervé Pagès wrote:
Hi
Hi Robert, Martin,
Yes using requireNamespace() internally is much cleaner than using
require(). Sorry for that. Just made the change in S4Vectors 0.2.6.
FYI the need to load IRanges namespace in a couple of places
inside S4Vectors is temporary and will go away soon.
Cheers,
H.
On 10/09/2014 09
On 10/09/2014 08:00 AM, Robert Castelo wrote:
hi Martin,
thanks for your recommendations regarding the conditional loading of packages. I
think however, that they are not related to the problem I'm referring. Let me
put here a reproducible example which works with qpgraph version 0.99.7 that I
h
hi Martin,
thanks for your recommendations regarding the conditional loading of
packages. I think however, that they are not related to the problem I'm
referring. Let me put here a reproducible example which works with
qpgraph version 0.99.7 that I have just pushed to svn:
library(qtl)
libra
On 10/07/2014 07:05 PM, Michael Lawrence wrote:
I think the intent there is that if you virtually always need a package to
generate the input or analyze the output of a documented function, it
should be in Depends. If it's a package that is only useful for
demonstration, it should be in Suggests,
I think the intent there is that if you virtually always need a package to
generate the input or analyze the output of a documented function, it
should be in Depends. If it's a package that is only useful for
demonstration, it should be in Suggests, and one should abide by the same
guidelines (requ
The guidelines state :
Depends: is appropriate when a package is used in the example section of a man
page.
I think such packages should be in Suggests. In the example, the package should
be loaded by :
if(require(examplePackage))
{
exampleFunction(data)
}
--
On 10/07/2014 09:15 AM, Michael Lawrence wrote:
Probably in your code you do not actually want to require() ad hoc packages
and influence the user search path (and implicitly rely on search path order
for correct functionality), but rather to requireNamespace("foo");
foo::fun(...
On Tue, Oct 7, 2014 at 8:54 AM, Martin Morgan wrote:
> On 10/07/2014 08:15 AM, Robert Castelo wrote:
>
>> hi, it happens only with "[", that's why i'm puzzled.
>>
>> it behaves as if you load a GRanges object 'x' and try to subset it
>>
>> x[1]
>>
>> without loading 'GenomicRanges' first.
>>
>
>
On 10/07/2014 08:15 AM, Robert Castelo wrote:
hi, it happens only with "[", that's why i'm puzzled.
it behaves as if you load a GRanges object 'x' and try to subset it
x[1]
without loading 'GenomicRanges' first.
Is there a reproducible example? I see in your code there are several places
wh
hi, it happens only with "[", that's why i'm puzzled.
it behaves as if you load a GRanges object 'x' and try to subset it
x[1]
without loading 'GenomicRanges' first.
robert.
On 10/07/2014 05:05 PM, Michael Lawrence wrote:
Does that happen with the other methods or just "["? As a last resort,
Does that happen with the other methods or just "["? As a last resort, you
could just drop the import (because "[" is a primitive, it should just
work).
On Tue, Oct 7, 2014 at 3:08 AM, Robert Castelo
wrote:
> hi Martin,
>
> On 10/06/2014 07:24 PM, Martin Morgan wrote:
> [...]
>
> There are two
hi Martin,
On 10/06/2014 07:24 PM, Martin Morgan wrote:
[...]
There are two 'as.vector' generics, one defined in Matrix and one in
BiocGenerics (and made available via IRanges). These generics have
different methods
> showMethods(Matrix::as.vector)
Function: as.vector (package base)
x="abIndex
On 10/05/2014 01:39 PM, Robert Castelo wrote:
hi,
i have the following warning message when installing the devel version
(0.99.5) of my package 'qpgraph':
** testing if installed package can be loaded
Warning: replacing previous import by 'IRanges::as.vector' when loading
'qpgraph'
* DONE (qpgr
hi,
i have the following warning message when installing the devel version
(0.99.5) of my package 'qpgraph':
** testing if installed package can be loaded
Warning: replacing previous import by 'IRanges::as.vector' when loading
'qpgraph'
* DONE (qpgraph)
after investigating the issue i think it
57 matches
Mail list logo
