Hi Leonardo --
On 07/07/2014 03:27 PM, Leonardo Collado Torres wrote:
Hello BioC-devel list,
I am currently confused on a namespace issue which I haven't been able
to solve. To reproduce this, I made the simplest example I thought of.
Step 1: make some toy data and save it on your desktop
li
This is why I tell people not to use require(). But what's with needing to
load IRanges to subset an Rle? Is that temporary?
Limiting imports is unlikely to reduce loading time. It may actually
increase it. There are good reasons for it though.
On Tue, Jul 8, 2014 at 5:21 AM, Martin Morgan wro
Hi guys,
On 07/08/2014 05:29 AM, Michael Lawrence wrote:
This is why I tell people not to use require(). But what's with needing to
load IRanges to subset an Rle? Is that temporary?
Very temporary. The source code of the "extractROWS" and "replaceROWS"
methods for Rle objects actually contains
Hi,
On 05/13/2014 01:15 AM, Julian Gehring wrote:
Hi,
In summary, would it be feasible to add to 'GenomicRanges'?
1) A 'granges(x, use.mcols=FALSE, ...)' method with signature 'GRanges'
that converts to a 'GRanges' object and optionally drops the mcols (if
'use.mcols' is TRUE)
Will do.
2)
On Tue, Jul 8, 2014 at 10:36 AM, Julian Gehring
wrote:
> Hi Herve,
>
>
> 2) A 'dropMcols' or 'dropmcols' method with signature 'GRanges' that is
>>> a wrapper for
>>>mcols(x) <- NULL
>>>
>>
>> How about setMcols(), which is more general than dropmcols()?
>>
>>
> Do you mean a function like:
On 07/08/2014 11:29 AM, Michael Lawrence wrote:
On Tue, Jul 8, 2014 at 10:36 AM, Julian Gehring
wrote:
Hi Herve,
2) A 'dropMcols' or 'dropmcols' method with signature 'GRanges' that is
a wrapper for
mcols(x) <- NULL
How about setMcols(), which is more general than dropmcols()?
D
Hello,
Thank you everyone for the replies and help!
I did not know that it was due to S4Vectors::extractROWS nor what
Hervé exposed about the upcoming changes to them.
Regarding "probably it is not desirable to move packages from loaded
to attached, but I don't think this influences performance
The recent TranscriptDb thread reminded me of a question: are there
plans (or am I missing the function) to easily get a TranscriptDb out
of the AnnotationHub objects? It would be great to have a preprocessed
Ensembl txdb like we have for UCSC.
> ah <- AnnotationHub()
> gr <-
> ah$ensembl.release
On 07/08/2014 11:58 AM, Leonardo Collado Torres wrote:
Hello,
Thank you everyone for the replies and help!
I did not know that it was due to S4Vectors::extractROWS nor what
Hervé exposed about the upcoming changes to them.
Regarding "probably it is not desirable to move packages from loaded
to
Hi Michael,
On 07/08/2014 12:11 PM, Michael Love wrote:
The recent TranscriptDb thread reminded me of a question: are there
plans (or am I missing the function) to easily get a TranscriptDb out
of the AnnotationHub objects? It would be great to have a preprocessed
Ensembl txdb like we have for U
10 matches
Mail list logo
