Hi all,
I was wondering whether some of the rather arbitrary restrictions on input
files for the process of forging as new Bsgenome package could be liftet. In
particular:
Why do we need all chromosomes in individual files? Couldn�t the function be
smart enough to just extract the relevant
Thanks for checking it out and benchmarking. We should be more clear
in the docs that the use case for reducing by range is when the entire
dataset won't fit into memory. Also, we had some discussion and
Valerie had written up methods for packing up the ranges supplied by
the user into a better
I don't fully understand the use case for reducing by range is when the
entire dataset won't fit into memory. The basic assumption of these
functions (as far as I can see) is that the output data fits in memory.
What may not fit in memory is various earlier iterations of the data.
For example, in
On Mon, Sep 29, 2014 at 9:09 AM, Kasper Daniel Hansen
kasperdanielhan...@gmail.com wrote:
I don't fully understand the use case for reducing by range is when the
entire dataset won't fit into memory. The basic assumption of these
functions (as far as I can see) is that the output data fits in
Reminder, this is tomorrow.
Dan
- Forwarded Message -
From: Dan Tenenbaum dtene...@fhcrc.org
To: bioc-devel bioc-devel@r-project.org
Sent: Wednesday, September 17, 2014 1:35:39 PM
Subject: [Bioc-devel] hedgehog Subversion server upgrade Tuesday 9/30
Hello Bioconductor developers,
On
Sorry if I have overlooked something… referring to
http://www.bioconductor.org/developers/how-to/workflows Is there a standardized
way to manage
- dependencies
- versions
In principle, these could be automagically computed (?), but would still have
to be exposed to workflow users using an
Hi Florian,
True. These restrictions don't make much sense these days anymore!
Some of them are gone in the devel version of BSgenome. The
BSgenomeForge vignette in devel now says:
The sequence data must be in a single twoBit file (e.g. musFur1.2bit)
or in a collection of FASTA files
- Original Message -
From: Wolfgang Huber whu...@embl.de
To: bioc-devel@r-project.org
Sent: Monday, September 29, 2014 12:24:54 PM
Subject: [Bioc-devel] Workflows
Sorry if I have overlooked something… referring to
http://www.bioconductor.org/developers/how-to/workflows Is there
Dear Dan
Thanks. What is the recommended procedure for people wanting to run the
workflow on their own computer? (E.g. for teaching).
Or even to prevent them from doing odd things like using the wrong versions of
R and packages?
Best wishes
Wolfgang
Il giorno Sep 29, 2014, alle ore 21:32
- Original Message -
From: Wolfgang Huber whu...@embl.de
To: Dan Tenenbaum dtene...@fhcrc.org
Cc: bioc-devel@r-project.org
Sent: Monday, September 29, 2014 12:35:18 PM
Subject: Re: [Bioc-devel] Workflows
Dear Dan
Thanks. What is the recommended procedure for people wanting to
Hi All
I’m in the process of getting package submitted to Bioconductor. The package is
a pure shiny package and this has led to some - especially one question. For
those not familiar with shiny apps, the code that makes these work resides in
their own .R files outside of the R directory in a
- Original Message -
From: Thomas Dybdal Pedersen thomas...@gmail.com
To: bioc-devel@r-project.org
Sent: Monday, September 29, 2014 12:49:16 PM
Subject: [Bioc-devel] Guidelines for shiny packages
Hi All
I’m in the process of getting package submitted to Bioconductor. The
On 09/28/2014 07:49 PM, Kasper Daniel Hansen wrote:
3. (well, this is GenomicRanges) It seems like GenomicFiles has a lot of
similarities with SummarizedExperiment. I have a lot of use cases for a
simple class which has a single GRanges slot, and then support stuff like
granges(), start(),
Unfortunately this approach is limited to apps where the UI of the app is
defined in R code. For more involved GUI development it is much preferred to
write the HTML yourself and for this to work, there need to be a server.R file.
I don’t think we should have recommendations that limits the
Just to support Kasper's proposal, I see this as being broadly useful.
It's really common to be dealing with an object (say, a
SummarizedExperiment-derived doohickey, or a transcriptDb-looking whatzit,
or bumps, or dmrcoutput) that has metadata which looks like a
GRanges. More often than not, a
This comes down to an inheritance vs. composition decision, but I hope
everyone is aware of the extraColumnSlots mechanism in GRanges that makes
it easy to add additional column-shaped slots to a subclass of GRanges.
It may be that hasGRanges could take a similar approach, except support
Hi Michel,
In BiocParallel 0.99.24 .convertToSimpleError() now checks for NULL and
converts to NA_character_.
I'm testing with BatchJobs 1.4, BiocParallel 0.99.24 and SLURM. I'm
still not getting an informative error message:
xx - bplapply(1:2, FUN)
SubmitJobs
I wrote it, because it might be clearer to see it as code:
###
=
### DelegatingGenomicRanges objects
###
-
###
### Virtual class that delegates
Hi Kasper,
The reduceBy* functions were intended to combine data across ranges or
files. If we have 10 ranges and 3 files you can think of it as a 10 x 3
grid where we'll have 30 queries and therefore 30 pieces of information
that can be combined across different dimensions.
The request to
Martin, I think Time explained it pretty well. All I am saying is that it
would be convenient to have a class which represents that another class can
be treated as a GRanges.
In bsseq I have one such class: BSseqTstat. I used to also construct the
BSseq class like this, but since it is
I'm trying to put together a new package submission, rgsepd, and I've ran
into an error I can't figure out. Hoping to talk with someone with more
experience on the bioconductor build system.
The build report is here
21 matches
Mail list logo
