Thomas Hickman

I've squashed the commits into two commits and made a pull request for the in-memory I/O at #590. The original history is now at https://github.com/wtsi-hgi/htslib/tree/ref-old

I've had a look at the double buffering problem - it's hard to stop buffering happening in a hFILE, so I think it's best to have a implement a "wrapper...

I've rebased the current `develop` branch onto this, and cleaned up what's in the `Abstract ref_to_m5 from cram_io` and `Add hFile wrappers` commits, so that whitespace isn't changed and commits...

For ease of reviewing the code, this is what I've done in this pull request: 1. Moved get_cache_basedir, expand_cache_path, get_int_threadid, mkdir_prefix to ref.c, all of which were helpers functions of...

In the above commits: - I've fixed the test failures in samtools, https://github.com/wtsi-hgi/htslib/blob/51a3095d02ee1acb9c19f20314b32d863d0f75de/cram/cram_io.c#L1929 was getting executed when the M5 field wasn't present, leading to a segfault. - I've created an...

@jmarshall the intention of this PR is to replace `mFILE` in the reference fetching logic (the replacement of this will be in #589, I'll push this tomorrow). I don't think...

^ also just made an edit description that matches the purpose of this PR

Just done a little bit of an experiment with the performance of the using a mmap inside a hfile (using @jmarshall's implementation) vs using a hfile vs an operating directly...

I've now got around to doing this benchmarking now. To test the reference fetching code exclusively, I've composed a cram file which is formed from a single sample that doesn't...

It's probably a good idea to implement a `read` function which doesn't involve copying, to actually get the speed benefit of mmaping as well. I've also got replaced mFILEs in...