[Bioc-devel] ShortRead::countLines integer overflow with large fastq files

Dear Martin, countLines in ShrotRead returns the line counts as integers which appears to create problems with large FASTQ files (>536.8 Mio lines) due to R's integer limit (2^31-1). When the integer limit is reached/exceeded it seems that countLines returns negative values not reflecting the

Re: [Bioc-devel] as.list fails on IRanges inside of lapply(, blah)

On 02/20/2018 01:25 PM, Gabe Becker wrote: Herve, Thanks for the response. The looping across a ranges that's still in tehre is: dss = switch(seqtype,                      bp = DNAStringSet(*lapply(ranges(srcs)*, function(x) origin[x])),                      aa =

Re: [Bioc-devel] as.list fails on IRanges inside of lapply(, blah)

Herve, Thanks for the response. The looping across a ranges that's still in tehre is: dss = switch(seqtype, bp = DNAStringSet(*lapply(ranges(srcs)*, function(x) origin[x])), aa = AAStringSet(*lapply(ranges(srcs),* function(x) origin[x])),

Re: [Bioc-devel] as.list fails on IRanges inside of lapply(, blah)

Hi Gabe, I made a couple of changes to genbankr (1.7.2) to avoid those looping e.g. I replaced things like sapply(gr, width) with width(gr) I can't run a full 'R CMD build' + 'R CMD check' on the package though because the code in the vignette seems to fail for reasons unrelated to

[Bioc-devel] as.list fails on IRanges inside of lapply(, blah)

All, I'm trying to track down the new failure in my genbankr package and it appears to come down to the fact that i'm trying to lapply over an IRanges, which fails in the IRanges to list (or List?) conversion. The particular case that fails in my example is an IRanges of length 1 but that does

Re: [Bioc-devel] gwaswloc class broken

I think this is settled by running updateObject(ebicat37) with a current GenomicRanges etc. I will do this and reserialize. On Tue, Feb 20, 2018 at 8:01 AM, Robert Castelo wrote: > thanks Vince for your quick response, indeed your intuition is right, > coercing to

Re: [Bioc-devel] R version check in BiocChech

Depending on your reviewer, they MAY let you slide with a different version dependency despite the BiocCheck WARNING... maybe... However ... It is strongly, strongly recommended that all new package depend on the version of R that it will be released under. New packages currently being

Re: [Bioc-devel] gwaswloc class broken

thanks Vince for your quick response, indeed your intuition is right, coercing to 'GRanges' avoids the problem, i'm cc'ing bioc-devel so that people involved in 'GRanges' know about this: library(gwascat) data(ebicat37) ebicat37[1] Error in updateObject(x, check = FALSE) : no slot of name

[Bioc-devel] gwaswloc class broken

hi, the 'gwasloc' class from the gwascat package seems to be broken in devel, i suspect due to recent changes in the 'GRanges' class or some other class upstream, because the definition of the 'gwasloc' class in gwascat/R/classes.R is: setClass("gwaswloc",

Re: [Bioc-devel] R version check in BiocChech

> It _is_ the developer's choice. But a developer of packages for the Bioconductor > project commits to using R-devel during certain pre-release phases, depending > on proximity in time to a point release of R. (See http://bioconductor.org/developers/how-to/useDevel/) > for full details.)