Update read.bismark documentation

[PeteHaitch]

The docs have fallen behind updates made to the bismark_methylation_extractor. I think the underlying code is fine, but the docs refer to the wrong input file (should be the .cov file rather than the .bedGraph file). It'd be good to update the example data correspondingly in inst/extdata.

Ideally, I'll include some unit tests that keep pace with latest version of Bismark to automatically generate the input file, but I'd have to have a think about how to implement that.

[kasperdanielhansen]

Was this ever fixed? Bismark now (?) has several types of output files. We should update docs to include a discussion of this and also add unit testing for parsing by just reading in say 10 lines or so.

[PeteHaitch]

Yes, I think these were covered in #4. So I think this can be closed.

Incidentally, that link includes my benchmarking of data.table::fread() and readr::read_tsv() on gzipped data that we discussed yesterday. I think the data still stand, but I'm more open to the interpretation that readr::read_tsv() is better for bsseq because it natively handles gzipped files (they are uncompressed in memory rather than to disk; http://blog.rstudio.org/2015/04/09/readr-0-1-0/).

[kasperdanielhansen]

One issue with our compute cluster is that disk access is slow. If
benchmarking was done on laptop, highly likely that we may see different
results on JHPCE, because readr avoids writing a file.

On Fri, Mar 11, 2016 at 3:21 PM, Peter Hickey notifications@github.com
wrote:

Yes, I think these were covered in #4
#4. So I think this can
be closed.

Incidentally, that link includes my benchmarking of data.table::fread()
and readr::read_tsv() on gzipped data that we discussed yesterday. I
think the data still stand, but I'm more open to the interpretation that
readr::read_tsv() is better for bsseq because it natively handles gzipped
files (they are uncompressed in memory rather than to disk;
http://blog.rstudio.org/2015/04/09/readr-0-1-0/).

—
Reply to this email directly or view it on GitHub
#1 (comment)
.