Hi Tim,
I was looking for a similar function a while ago, and created the
'grangesPlain' function in 'SomaticSignatures':
grangesPlain <-
function (x)
{
mcols(x) = NULL
x = as(x, "GRanges")
return(x)
}
It removes the metadata columns, as Michael described. Further, it
performs a
Lovely. Hadn't even thought about the VRanges aspect in a while, but this is
essentially the use case I had as well. Thanks!
--t
> On May 5, 2014, at 1:25 AM, Julian Gehring wrote:
>
> Hi Tim,
>
> I was looking for a similar function a while ago, and created the
> 'grangesPlain' function in
The in-line usage makes sense. How about dropmcols() or something, at least
for removing the mcols?
On Mon, May 5, 2014 at 1:25 AM, Julian Gehring wrote:
> Hi Tim,
>
> I was looking for a similar function a while ago, and created the
> 'grangesPlain' function in 'SomaticSignatures':
>
> grangesP
If you just want all the genomes, you can do something like
library(BSgenome)
genomePkgs = available.genomes()
biocLite(genomePkgs)
Best,
Kasper
On Mon, May 5, 2014 at 2:00 AM, Dario Strbenac
wrote:
> Thanks for this code. I was interested in all of the BSgenome packages, so
> the results
On 05/05/2014 06:55 AM, Michael Lawrence wrote:
The in-line usage makes sense. How about dropmcols() or something, at least
for removing the mcols?
generalize as setMcols, like setNames? setMcols(x, NULL)
On Mon, May 5, 2014 at 1:25 AM, Julian Gehring wrote:
Hi Tim,
I was looking for a s
Hi,
On 05.05.2014 16:22, Martin Morgan wrote:
generalize as setMcols, like setNames? setMcols(x, NULL)
How about Tim's original suggestion, to add a 'granges' method that
works on a 'GRanges' input? The current definition
granges(x, use.mcols=FALSE, ...)
seem suited for this.
Best wishes
Hi Sebastian,
Hm, this looks odd indeed. I am wondering whether this is some sort of
name space problem. Does the same happen when you create your ³A² dummy
class and the ³[³ method in a little dummy package with its own name
space? Something seems to be messing up the methods table when you define
That's exactly what I was after -- the generic is already defined, so why not
use it?
--t
> On May 5, 2014, at 7:42 AM, Julian Gehring wrote:
>
> Hi,
>
>> On 05.05.2014 16:22, Martin Morgan wrote:
>> generalize as setMcols, like setNames? setMcols(x, NULL)
>
> How about Tim's original sugges
Hi Sebastian,
This could be a rounding error. I will have to take a closer look at it
and will get back to you asap.
Thanks for reporting,
Florian
PS: Pviz looks nice. Already have a couple of use cases :-)
On 02/05/14 21:52, "Sebastian Gibb" wrote:
>sTrack <- SequenceTrack(Hsapiens)
>
__
Hi Lance,
Sorry for the late reply, I was out of office for the last two weeks. Looks
like you indeed discovered a bug which I may have introduced during the last
changes to the ylim code. Thanks for the report, and even more so for the
patch! I will make the necessary code changes in both the r
In my opinion, granges() is not very clear as to the intent. The mcols are
part of the GRanges, so why would calling granges() drop them? I think we
want something similar to unclass(), unname(), etc. This why I suggested
dropmcols().
On Mon, May 5, 2014 at 8:17 AM, Tim Triche, Jr. wrote:
> Th
I agree with Michael on this.
I can see why, in some usage cases, granges() is convenient to have with
use.mcols=FALSE (which seems to have been added in the latest release).
But in my usage of granges(), where I call granges() on objects like
SummarizedExperiments and friends, I have been expect
Dear Florian,
On 2014-05-05 16:17:41, florian.ha...@novartis.com wrote:
> Hm, this looks odd indeed. I am wondering whether this is some sort of
> name space problem. Does the same happen when you create your ³A² dummy
> class and the ³[³ method in a little dummy package with its own name
> space?
Hi,
I have no problem using granges() for that. Just to clarify:
(a) it would propagate the names()
(b) it would drop the metadata()
(c) the mcols() would propagate only if 'use.mcols=TRUE' was
specified ('use.mcols' is FALSE by default)
(d) it would return a GRanges *instance* i.e.
Wondering,
Is it too off the beaten track to expect
`mcols<-`(x,NULL)
to work?
hint: it does not
>-Original Message-
>From: bioc-devel-boun...@r-project.org
>[mailto:bioc-devel-boun...@r-project.org] On Behalf Of Hervé Pagès
>Sent: Monday, May 05, 2014 1:28 PM
>To: Kasper Daniel
Hi Malcolm,
On 05/05/2014 01:00 PM, Cook, Malcolm wrote:
Wondering,
Is it too off the beaten track to expect
`mcols<-`(x,NULL)
> args(`mcols<-`)
function (x, ..., value)
Arguments after the ellipsis must be named:
`mcols<-`(x, value=NULL)
Nothing we can do about this.
Cheers,
H.
>On 05/05/2014 01:00 PM, Cook, Malcolm wrote:
>> Wondering,
>>
>> Is it too off the beaten track to expect
>>
>> `mcols<-`(x,NULL)
>
> > args(`mcols<-`)
> function (x, ..., value)
>
>Arguments after the ellipsis must be named:
>
> `mcols<-`(x, value=NULL)
Herve - Great - of cours
On 05/05/2014 02:12 PM, Cook, Malcolm wrote:
On 05/05/2014 01:00 PM, Cook, Malcolm wrote:
>> Wondering,
>>
>> Is it too off the beaten track to expect
>>
>> `mcols<-`(x,NULL)
>
> > args(`mcols<-`)
> function (x, ..., value)
>
>Arguments after the ellipsis must be named:
Hi all,
Bioconductor 2.14 (release) packages are now available for the Mavericks (Mac
OS X 10.9) build of R.
If you install this version of R, you can install Mavericks packages by typing:
source("http://bioconductor.org/biocLite.R";)
...and then using biocLite() to install the package(s) you
On 05/05/2014 10:56 AM, Sebastian Gibb wrote:
Dear Florian,
On 2014-05-05 16:17:41, florian.ha...@novartis.com wrote:
Hm, this looks odd indeed. I am wondering whether this is some sort of
name space problem. Does the same happen when you create your ³A² dummy
class and the ³[³ method in a litt
20 matches
Mail list logo
