Hi Koustav,
My opinion on this is to split the visualisations out into a separate package
but keep the functions in the existing package. Then when the new visualisation
package is released, depend on it from the existing package.
It’s worth asking: Is the package actually worth splitting up?
Yes, gladly. Thank you for taking time to help me. Here is the exact line of R
code where we build the samtools command (the file to be tested is added later):
args <- paste("mpileup -ERI", #Redo Baq, ignore readgroups, and skip indels
"-f", refFasta(param),
can you provide an example of the samtools command line that you evaluate?
On 8/23/19, 6:11 PM, "Bioc-devel on behalf of Jonathon Hill"
wrote:
I had not until today. I spent the afternoon looking at the possibility,
and it looks like it would be beyond my lab’s skills. We do not have
I had not until today. I spent the afternoon looking at the possibility, and it
looks like it would be beyond my lab’s skills. We do not have anyone
comfortable in C, as we do everything in R. The problem is that we need to get
the results of the mpileup command with BAQ score. Although it has
Hi,
During one of my R packages bioc review, I see the following 2 errors,
one:
Error in library.dynam(dynlib, pkg, lib) :
DLL 'rgl' not found: maybe not installed for this architecture?
Error: .onLoad failed in loadNamespace() for 'rgl', details:
call: NULL
error:Loading rgl's
Hi Jonathon,
Have you considered depending on Rhtslib? See
https://bioconductor.org/packages/Rhtslib
Rsamtools itself is implemented on top of Rhtslib. Note that other
Bioconductor packages (e.g. DiffBind, deepSNV, BitSeq, qrqc, QuasR,
seqbias, TransView, etc...) use Rhtslib internally to
Hi,
I am working through the process of submitting a new package (MMAPPR2). We are
having a problem with the build failing, because our package requires Samtools
installed. We cannot use Rsamtools, as we depend on features not implemented in
the package. How do we resolve the issue? What is
Hi,
I have a curious scenario, I have a package which has some visualisation
modules. But, as package development progresses, I think that possibly the
visualisation modules themselves might deserve a package for themselves. This
would imply,
1. Removing the aforementioned modules from the