Yea, I can see the argument for consistency. Not sure I'll get around to it though. How about we see if they take this patch first.
Michael
On Sat, Feb 22, 2014 at 12:26 PM, Hervé Pagès <hpa...@fhcrc.org> wrote:
> Thanks Michael.
>
> Do you think it would be sensible to offer a similar fix for
> selectMethod?
>
> > setGeneric("f", function(x, y) standardGeneric("f"))
> > setMethod("f", c("numeric", "missing"), function(x, y) x)
> > selectMethod("f", "numeric")
> Error in selectMethod("f", "numeric") :
> no method found for signature numeric, ANY
>
> In a perfect world,
>
> generic(arg)
> selectMethod(generic, class(arg))
> ?generic(arg)
>
> should behave consistently.
>
> The ?import(path_to_gff) error I reported earlier was actually
> inspired by a sad experience I had in the past where I was trying
> to use selectMethod("import", ...) to find out what particular
> method was being called (I needed to see the code).
>
> Thanks,
> H.
>
>
> On 02/22/2014 05:59 AM, Michael Lawrence wrote:
>
>> Translated it into a patch against R, submitted here:
>> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15680
>>
>>
>> On Fri, Feb 21, 2014 at 2:53 PM, Hervé Pagès <hpa...@fhcrc.org
>> <mailto:hpa...@fhcrc.org>> wrote:
>>
>>
>>
>> On 02/21/2014 02:01 PM, Michael Lawrence wrote:
>>
>> This function seems to solve the problem:
>>
>> helpwith <- function(expr) {
>> env <- IRanges:::top_prenv(expr)
>> expr <- substitute(expr)
>> fun <- eval(expr[[1L]], env)
>> fun.name <http://fun.name> <http://fun.name> <-
>> deparse(expr[[1L]])
>> if (!isGeneric(fun.name <http://fun.name> <http://fun.name>,
>> env)) {
>>
>> stop("'expr' must be a call to a generic")
>> }
>> args <- formals(fun)
>> mc <- match.call(fun, expr, expand.dots=FALSE)
>> args[names(mc[-1L])] <- mc[-1L]
>> args <- args[fun@signature]
>> args$... <- args$...[[1L]]
>> target.sig <- vapply(args, function(arg) {
>> .arg <- arg # nice trick
>> if (missing(.arg)) {
>> "missing"
>> } else {
>> class(eval(arg, env))[1L]
>> }
>> }, character(1))
>> defined.sig <- selectMethod(fun, target.sig)@defined
>> help(paste0(fun.name <http://fun.name> <http://fun.name>,
>> ",", paste(defined.sig,
>>
>> collapse=","), "-method"))
>> }
>>
>> path_to_gff <- "my.gff"
>> helpwith(import(path_to_gff))
>>
>> helpwith(rbind(DataFrame(__mtcars), DataFrame(mtcars)))
>>
>> But where should it go?
>>
>>
>> Nice fix. It's a bug in ? so it would need to go into ? itself.
>>
>> The man page for ? (accessible with ?`?`) says:
>>
>> S4 Method Documentation:
>>
>> [...]
>>
>> There are two different ways to look for documentation on a
>> particular method. The first is to supply the 'topic' argument
>> in
>> the form of a function call, omitting the 'type' argument. The
>> effect is to look for documentation on the method that would be
>> used if this function call were actually evaluated. See the
>> examples below. If the function is not a generic (no S4 methods
>> are defined for it), the help reverts to documentation on the
>> function name.
>>
>> Thanks,
>> H.
>>
>>
>>
>>
>>
>> On Fri, Feb 21, 2014 at 11:17 AM, Hervé Pagès <hpa...@fhcrc.org
>> <mailto:hpa...@fhcrc.org>
>> <mailto:hpa...@fhcrc.org <mailto:hpa...@fhcrc.org>>> wrote:
>>
>> Hi Gabriel,
>>
>>
>> On 02/20/2014 05:03 PM, Gabriel Becker wrote:
>>
>> Herve,
>>
>> The help is correct (though possibly a bit pedantic),
>> there is no
>> method for that signature.
>>
>>
>> But the dispatch mechanism is able to find one because
>> 'import(path_to_gff)' *does* work. So the help maybe is
>> correct
>> but that doesn't really help the naive user.
>>
>> H.
>>
>>
>> ?import("", "")
>>
>> works for me though
>>
>> ~G
>>
>>
>> On Thu, Feb 20, 2014 at 4:51 PM, Hervé Pagès
>> <hpa...@fhcrc.org <mailto:hpa...@fhcrc.org>
>> <mailto:hpa...@fhcrc.org <mailto:hpa...@fhcrc.org>>
>> <mailto:hpa...@fhcrc.org <mailto:hpa...@fhcrc.org>
>> <mailto:hpa...@fhcrc.org <mailto:hpa...@fhcrc.org>>>> wrote:
>>
>> On 02/20/2014 04:16 PM, Michael Lawrence wrote:
>>
>> There's also "?coverage(ga)", so the user can
>> see what
>> happens
>> specifically for their object, without
>> worrying about
>> typing out
>> the class.
>>
>>
>> I was never lucky with this:
>>
>> > library(rtracklayer)
>> > path_to_gff <- system.file("tests", "v1.gff",
>> package =
>> "rtracklayer")
>> > ?import(path_to_gff)
>> Error in .helpForCall(topicExpr, parent.frame())
>> :
>> no documentation for function 'import' and
>> signature
>> 'con =
>> "character", format = "ANY", text = "ANY"'
>> In addition: Warning message:
>> In .helpForCall(topicExpr, parent.frame()) :
>> no method defined for function 'import' and
>> signature
>> 'con =
>> "character", format = "ANY", text = "ANY"'
>>
>> H.
>>
>>
>> At some point it would be neat to generate S4
>> documentation at
>> run-time.
>> Just popup a browser and see every method that
>> might be
>> dispatched with
>> a given object. In theory, the R help server
>> would
>> support this.
>>
>>
>> On Thu, Feb 20, 2014 at 3:13 PM, Hervé Pagès
>> <hpa...@fhcrc.org <mailto:hpa...@fhcrc.org>
>> <mailto:hpa...@fhcrc.org <mailto:hpa...@fhcrc.org>>
>> <mailto:hpa...@fhcrc.org
>> <mailto:hpa...@fhcrc.org> <mailto:hpa...@fhcrc.org
>> <mailto:hpa...@fhcrc.org>>>
>> <mailto:hpa...@fhcrc.org
>> <mailto:hpa...@fhcrc.org> <mailto:hpa...@fhcrc.org
>> <mailto:hpa...@fhcrc.org>>
>> <mailto:hpa...@fhcrc.org <mailto:hpa...@fhcrc.org>
>> <mailto:hpa...@fhcrc.org <mailto:hpa...@fhcrc.org>>>>> wrote:
>>
>>
>>
>> On 02/20/2014 02:55 PM, Martin Morgan
>> wrote:
>>
>> On 02/20/2014 02:32 PM, Hervé Pagès
>> wrote:
>>
>> Hi Jesper,
>>
>> On 02/20/2014 02:13 PM, Jesper
>> Gådin wrote:
>>
>> Very true that it is quite
>> difficult
>> to find the
>> documentation when one
>> is not aware of its existence
>> :P
>>
>>
>> Yeah, this has been a source of
>> frustration for
>> many people. And
>> always a source of embarrassment
>> (for us) when
>> teaching our
>> software
>> to beginners.
>>
>> I've started to change this. In
>> the upcoming
>> version of BioC
>> (2.14,
>> scheduled for mid-April), when
>> you'll do
>> ?coverage,
>> you'll
>> get to
>> choose between the 3 man pages that
>> document coverage
>> methods (there
>> is one in IRanges, one in
>> GenomicRanges,
>> and one in
>> GenomicAlignments).
>>
>> I want to generalize this to other
>> generics that have
>> methods spread
>> across several packages (e.g.
>> findOverlaps, the
>> intra- and
>> inter-range
>> methods, etc...).
>>
>> Having to choose between several
>> man pages
>> every
>> time you do
>> e.g.
>> ?findOverlaps is a minor annoyance
>> compared to not
>> being able to
>> find the man page at all. (Note
>> that if
>> you already
>> know
>> where is
>> your favorite man page, you'll be
>> able to
>> direct
>> access it with
>> e.g.
>> ?GenomicRanges::findOverlaps). Nobody
>> will
>> ever need to use
>> the insane
>>
>>
>> ?`findOverlaps,GenomicRanges,________GenomicRanges-method` to
>>
>>
>>
>>
>>
>> tab completion helps, so that you
>> don't need
>> to be totally
>> insane, just
>> insane enough to know to start with
>>
>> ?"cover<tab>
>>
>>
>> and also insane enough to know which
>> method you
>> need to
>> pick up amongst
>> the 30+ methods listed by
>> ?"findOverlaps<tab>
>> Overwhelming!
>>
>> H.
>>
>>
>>
>> Martin
>>
>> open that man page again. Ever!
>> (it will
>> still work
>> though...)
>>
>> Cheers,
>> H.
>>
>>
>> coverage() is fast and
>> beautiful. Thanks!
>>
>> /Jesper
>>
>>
>> On Wed, Feb 19, 2014 at 9:21
>> PM, Hervé
>> Pagès
>> <hpa...@fhcrc.org
>> <mailto:hpa...@fhcrc.org>
>> <mailto:hpa...@fhcrc.org <mailto:hpa...@fhcrc.org>>
>> <mailto:hpa...@fhcrc.org <mailto:hpa...@fhcrc.org>
>> <mailto:hpa...@fhcrc.org <mailto:hpa...@fhcrc.org>>>
>> <mailto:hpa...@fhcrc.org
>> <mailto:hpa...@fhcrc.org> <mailto:hpa...@fhcrc.org
>> <mailto:hpa...@fhcrc.org>>
>> <mailto:hpa...@fhcrc.org <mailto:hpa...@fhcrc.org>
>> <mailto:hpa...@fhcrc.org <mailto:hpa...@fhcrc.org>>>>
>> <mailto:hpa...@fhcrc.org
>> <mailto:hpa...@fhcrc.org>
>> <mailto:hpa...@fhcrc.org <mailto:hpa...@fhcrc.org>>
>> <mailto:hpa...@fhcrc.org
>> <mailto:hpa...@fhcrc.org> <mailto:hpa...@fhcrc.org
>> <mailto:hpa...@fhcrc.org>>>
>> <mailto:hpa...@fhcrc.org <mailto:hpa...@fhcrc.org>
>> <mailto:hpa...@fhcrc.org <mailto:hpa...@fhcrc.org>>
>> <mailto:hpa...@fhcrc.org
>> <mailto:hpa...@fhcrc.org> <mailto:hpa...@fhcrc.org
>> <mailto:hpa...@fhcrc.org>>>>>>
>>
>> wrote:
>>
>> Hi Jesper,
>>
>>
>> On 02/19/2014 08:44 AM,
>> Michael
>> Lawrence
>> wrote:
>>
>> On Wed, Feb 19, 2014
>> at 8:39 AM,
>> Jesper Gådin
>>
>> <jesper.ga...@gmail.com <mailto:jesper.ga...@gmail.com>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>__>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>__>__>
>>
>> <mailto:jesper.ga...@gmail.com <mailto:jesper.ga...@gmail.com>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>__>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>__>__>__>
>>
>> <mailto:jesper.ga...@gmail.com <mailto:jesper.ga...@gmail.com>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>__>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>__>__>
>>
>> <mailto:jesper.ga...@gmail.com <mailto:jesper.ga...@gmail.com>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>__>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>__>__>__>__>>wrote:
>>
>>
>>
>>
>> Hi Michael,
>>
>> Herves
>> suggestion will
>> probably
>> work for my
>> use case, but if
>> there are any
>> smoother ways it
>> would be
>> preferable.
>>
>> The use case is
>> as follows:
>>
>> 1) calculate
>> strand specific
>> coverage over
>> a region from
>> GAlignments
>> object (or file)
>>
>> At the moment I
>> read a
>> file using
>> readGAlignmentsFromBam()
>> with tag="XS",
>> then filter it
>> on "flag" and
>> "mapq". Then I
>> subset the
>> resulting
>> GAlignments in
>> a minus
>> and a plus
>> -strand object.
>> Then I calculate
>> coverage
>> by my own
>> coverage function which
>> uses the cigar
>> information in the
>> GAlignments
>> object. This
>> function is the
>> one using
>> cigarToRleList()
>> at the
>> moment. As I
>> understand the
>> coverage()
>> function
>> from the
>> GenomicAlignments/IRanges
>> package
>> does not take
>> into account
>> cigars, or does
>> it?
>>
>>
>> It does take the
>> coverage
>> into account;
>> specifically to exclude
>> the introns
>> from coverage. I think
>> there's also an
>> option
>> to exclude
>> deletions.
>>
>>
>> Unfortunately the man
>> page is not
>> easy to
>> access
>> (you need to do
>>
>> ?`coverage,GAlignments-method`__________), but
>>
>>
>> it says:
>>
>> The methods for
>> GAlignments and
>> GAlignmentPairs
>> objects do:
>>
>>
>> coverage(grglist(x), ...)
>>
>> And if you do grglist()
>> on a
>> GAlignments or
>> GAlignmentPairs
>> objects, the
>> ranges you get in the
>> returned
>> GRangesList
>> object
>> are calculated
>> based
>> on the CIGAR.
>>
>> Trust but verify. Here
>> is how you
>> can actually
>> verify that
>> coverage()
>> does take the CIGAR into
>> account:
>>
>>
>> library(RNAseqData.HNRNPC.bam.__________chr14)
>> gal <-
>>
>>
>>
>> readGAlignments(RNAseqData.__________HNRNPC.bam.chr14___
>> BAMFILES[__1])
>>
>>
>>
>> cig_op_table <-
>> cigarOpTable(cigar(gal))
>>
>> First we pick up an
>> alignment
>> with an N in its
>> CIGAR and do
>> coverage()
>> on it:
>>
>> > gal_with_N <-
>> gal[which(cig_op_table[
>> , "N"]
>> != 0)[1]]
>>
>> > gal_with_N
>> GAlignments with 1
>> alignment and 0
>> metadata columns:
>> seqnames strand
>> cigar qwidth
>> start end
>> width
>> <Rle> <Rle>
>> <character> <integer>
>> <integer> <integer>
>> <integer>
>> [1] chr14 +
>> 55M2117N17M 72
>> 19650072 19652260
>> 2189
>> ngap
>> <integer>
>> [1] 1
>> ---
>> seqlengths:
>> chr1
>> chr10 ...
>> chrY
>> 249250621
>> 135534747 ...
>> 59373566
>>
>> >
>> coverage(gal_with_N)$chr14
>> integer-Rle of length
>> 107349540 with 5 runs
>> Lengths: 19650071
>> 55
>> 2117
>> 17
>> 87697280
>> Values : 0
>> 1
>> 0
>> 1
>> 0
>>
>> Same thing with an
>> alignment with
>> an I in
>> its CIGAR:
>>
>> > gal_with_I <-
>> gal[which(cig_op_table[
>> , "I"]
>> != 0)[1]]
>>
>> > gal_with_I
>> GAlignments with 1
>> alignment and 0
>> metadata columns:
>> seqnames strand
>> cigar qwidth
>> start end
>> width
>> <Rle> <Rle>
>> <character> <integer>
>> <integer> <integer>
>> <integer>
>> [1] chr14 -
>> 64M1I7M 72
>> 19411677 19411747
>> 71
>> ngap
>> <integer>
>> [1] 0
>> ---
>> seqlengths:
>> chr1
>> chr10 ...
>> chrY
>> 249250621
>> 135534747 ...
>> 59373566
>>
>> >
>> coverage(gal_with_I)$chr14
>> integer-Rle of length
>> 107349540 with 3 runs
>> Lengths: 19411676
>> 71 87937793
>> <tel:71%2087937793>
>> Values : 0
>> 1
>> 0
>>
>> Same thing with an
>> alignment with
>> a D in
>> its CIGAR:
>>
>> > gal_with_D <-
>> gal[which(cig_op_table[
>> , "D"]
>> != 0)[1]]
>>
>> > gal_with_D
>> GAlignments with 1
>> alignment and 0
>> metadata columns:
>> seqnames strand
>> cigar qwidth
>> start end
>> width
>> <Rle> <Rle>
>> <character> <integer>
>> <integer> <integer>
>> <integer>
>> [1] chr14 +
>> 38M1D34M 72
>> 19659063 19659135
>> 73
>> ngap
>> <integer>
>> [1] 0
>> ---
>> seqlengths:
>> chr1
>> chr10 ...
>> chrY
>> 249250621
>> 135534747 ...
>> 59373566
>>
>> >
>> coverage(gal_with_D)$chr14
>> integer-Rle of length
>> 107349540 with 3 runs
>> Lengths: 19659062
>> 73
>> 87690405
>> Values : 0
>> 1
>> 0
>>
>> Seeing is believing,
>>
>> Cheers,
>> H.
>>
>>
>>
>> I started to
>> look at the
>> applyPileups() in
>> Rsamtools which I
>> can get to
>> calculate
>> coverage using
>> cigars,
>> but not
>> using the strand or
>> flag
>> information for
>> filtering. That
>> solution
>> would start from a
>> bam-file
>> instead of a
>> GAlignments
>> object,
>> and sure I
>> can do the
>> filtering outside
>> R.
>> But it would be
>> very
>> convenient to
>> do it
>> all from within R.
>>
>> If there are
>> nice solutions
>> starting from
>> both a GAlignments
>> and a
>> bam-file it would
>> be
>> great! =)
>>
>> /Jesper
>>
>>
>>
>> On Tue, Feb 18,
>> 2014 at
>> 10:52 PM,
>> Michael
>> Lawrence <
>> lawrence.mich...@gene.com <mailto:lawrence.mich...@gene.com>
>> <mailto:lawrence.michael@gene.__com
>> <mailto:lawrence.mich...@gene.com>>
>> <mailto:lawrence.michael@gene.
>> <mailto:lawrence.michael@gene.>____com
>> <mailto:lawrence.michael@gene.__com
>> <mailto:lawrence.mich...@gene.com>>>
>> <mailto:lawrence.michael@gene
>> <mailto:lawrence.michael@gene>.
>> <mailto:lawrence.michael@gene
>> <mailto:lawrence.michael@gene>.__>____com
>> <mailto:lawrence.michael@gene.
>> <mailto:lawrence.michael@gene.>____com
>> <mailto:lawrence.michael@gene.__com
>> <mailto:lawrence.mich...@gene.com>>>>
>>
>> <mailto:lawrence.michael@gene
>> <mailto:lawrence.michael@gene> <mailto:lawrence.michael@gene
>> <mailto:lawrence.michael@gene>>__.
>> <mailto:lawrence.michael@gene
>> <mailto:lawrence.michael@gene>
>> <mailto:lawrence.michael@gene
>> <mailto:lawrence.michael@gene>>__.__>____com
>>
>>
>>
>> <mailto:lawrence.michael@gene
>> <mailto:lawrence.michael@gene>.
>> <mailto:lawrence.michael@gene
>> <mailto:lawrence.michael@gene>.__>____com
>> <mailto:lawrence.michael@gene.
>> <mailto:lawrence.michael@gene.>____com
>> <mailto:lawrence.michael@gene.__com
>> <mailto:lawrence.mich...@gene.com>>>>>> wrote:
>>
>> Hi Jesper,
>>
>> Would you be
>> willing to
>> volunteer your
>> use case? As
>> Herve hinted,
>>
>> cigarToRleList and
>> friends are
>> low-level helpers. There
>> may be an
>> easier
>> way to
>> achieve what
>> you want,
>> or an
>> opportunity to
>> improve
>> things.
>>
>> Michael
>>
>>
>> On Mon, Feb
>> 17, 2014
>> at 1:10
>> AM, Jesper
>> Gådin
>>
>> <jesper.ga...@gmail.com <mailto:jesper.ga...@gmail.com>
>> <mailto:jesper.ga...@gmail.com <mailto:jesper.ga...@gmail.com>__>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>__>__>
>>
>> <mailto:jesper.ga...@gmail.com <mailto:jesper.ga...@gmail.com>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>__>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>__>__>__>
>>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>__>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>__>__>
>>
>> <mailto:jesper.ga...@gmail.com <mailto:jesper.ga...@gmail.com>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>__>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>
>> <mailto:jesper.ga...@gmail.com
>> <mailto:jesper.ga...@gmail.com>__>__>__>__>>wrote:
>>
>>
>>
>>
>> Hi,
>>
>> Have
>> come across a
>> cigar-vector
>> that is problematic
>> to
>> process.
>>
>> #load
>> package
>>
>>
>> library(GenomicAlignments)
>>
>>
>> #load
>> data (see
>> attached file)
>>
>>
>>
>> load("2014-02-17-cigarExample.__________rdata")
>>
>>
>>
>>
>>
>> #run
>> function
>> cigarToRleList
>>
>>
>> cigarRle <-
>> cigarToRleList(cigarExample)
>>
>> Error in
>> .Call2("Rle_constructor",
>> values, lengths,
>> check,
>> 0L, PACKAGE =
>>
>> "IRanges") :
>>
>> integer
>> overflow while
>> summing
>> elements in
>> 'lengths'
>>
>>
>> sessionInfo()
>>
>> R Under
>> development (unstable)
>> (2013-11-13 r64209)
>> Platform:
>> x86_64-unknown-linux-gnu
>> (64-bit)
>>
>> locale:
>> [1]
>> LC_CTYPE=en_US.UTF-8
>> LC_NUMERIC=C
>> [3]
>> LC_TIME=en_US.UTF-8
>> LC_COLLATE=en_US.UTF-8
>> [5]
>> LC_MONETARY=en_US.UTF-8
>>
>> LC_MESSAGES=en_US.UTF-8
>> [7]
>> LC_PAPER=en_US.UTF-8
>> LC_NAME=C
>> [9]
>> LC_ADDRESS=C
>> LC_TELEPHONE=C
>> [11]
>> LC_MEASUREMENT=en_US.UTF-8
>> LC_IDENTIFICATION=C
>>
>> attached
>> base
>> packages:
>> [1]
>> parallel stats
>> graphics
>> grDevices utils
>>
>> datasets methods
>> [8] base
>>
>> other
>> attached
>> packages:
>> [1]
>> GenomicAlignments_0.99.18
>> Rsamtools_1.15.26
>> [3]
>> Biostrings_2.31.12
>> XVector_0.3.6
>> [5]
>> GenomicRanges_1.15.26
>> IRanges_1.21.23
>> [7]
>> BiocGenerics_0.9.3
>>
>> loaded
>> via a
>> namespace
>> (and not
>> attached):
>> [1]
>> BatchJobs_1.1-1135
>> BBmisc_1.5
>>
>> BiocParallel_0.5.8
>>
>> bitops_1.0-6
>>
>> [5]
>> brew_1.0-6
>> codetools_0.2-8
>> DBI_0.2-7
>>
>> digest_0.6.4
>>
>> [9]
>> fail_1.2
>> foreach_1.4.1
>>
>> iterators_1.0.6
>> plyr_1.8
>
>
[[alternative HTML version deleted]]
_______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
