* cram_codec structures are specialised for decoding or encoding. * Unfortunately this makes turning a decoder into an encoder (such as * when trans

* Applies various compression methods to specific blocks, depending on * known observations of how data series compress. * * Returns 0 on success

Returns the landmarks[] array and the number of elements * in num_landmarks. */

*----------------------------------------------------------------------------- * cram_container */

MAXIMUM storage size needed for the container. */

* Copies the blocks representing the next num_slice slices from a * container from 'in' to 'out'. It is expected that the file pointer * is just af

* Decodes the Tag Dictionary record in the preservation map * Updates the cram compression header. * * Returns number of bytes decoded on success

* Attempts to estimate the size of some blocks so we can preallocate them * before decoding. Although decoding will automatically grow the blocks,

* Internal part of cram_decode_slice(). * Generates the sequence, quality and cigar components. */

* Spawn a multi-threaded version of cram_decode_slice(). */

Resolve mate pair cross-references between recs within this slice */

* Note we also need to scan through the record encoding map to * see which data series share the same block, either external or * CORE. For example

* Encodes auxiliary data. Largely duplicated from above, but done so to * keep it simple and avoid a myriad of version ifs. * * Returns the read-gr

* Encodes auxiliary data, CRAM 1.0 format. * Returns the read-group parsed out of the BAM aux fields on success * NULL on failure or no rg p

* Encodes a single slice from a container * * Returns 0 on success * -1 on failure */

* Encodes a slice compression header. * * Returns cram_block on success * NULL on failure */

* Encodes a single read. * * Returns 0 on success * -1 on failure */

* Load first container. * Called when fd->ctr is NULL> * * Returns container on success * NULL on failure. */

! * Returns the refs_t structure used by a cram file handle. * * This may be used in conjunction with option CRAM_OPT_SHARED_REF to * share refere

* Read the next cram record and return it. * Note that to decode cram_record the caller will need to look up some data * in the current slice, point

! * Returns the hFILE connected to a cram_fd. */

* Builds an index file. * * fd is a newly opened cram file that we wish to index. * fn_base is the filename of the associated CRAM file. * fn_idx

* A specialised form of cram_index_build (below) that deals with slices * having multiple references in this (ref_id -2). In this scenario we * deco

Return the index entry for last slice on a specific reference.

* Loads a CRAM .crai index into memory. * * Returns 0 for success * -1 for failure */

* Initialises the lookup tables. These could be global statics, but they're * clumsy to setup in a multi-threaded environment unless we generate * v

* Creates a new blank container compression header * * Returns header ptr on success * NULL on failure */

* Creates a new empty slice in memory, for subsequent writing to * disk. * * Returns cram_slice ptr on success * NULL on failure */

* Handles creation of a new container or new slice, flushing any * existing containers when appropriate. * * Really this is next slice, which may o

* Queries the M5 string from the header and attempts to populate the * reference from this using the REF_PATH environment. * * Returns 0 on sucess

* Write iterator: put BAM format sequences into a CRAM file. * We buffer up a containers worth of data at a time. * * Returns 0 on success *

* Reads the SAM header from the first CRAM data block. * Also performs minimal parsing to extract read-group * and sample information. * Returns S

* Reads a CRAM file definition structure. * Returns file_def ptr on success * NULL on failure */

* Load the entire reference 'id'. * This also increments the reference count by 1. * * Returns ref_entry on success; * NULL on failure */

* Skips to a container overlapping the start coordinate listed in * cram_range. * * In theory we call cram_index_query multiple times, once per sli

* Attaches a header to a cram_fd. * * This should be used when creating a new cram_fd for writing where * we have an SAM_hdr already constructed (e

*----------------------------------------------------------------------------- * cram_slice */

* Converts a cram in-memory record into a bam in-memory record. We * pass a pointer to a bam_seq_t pointer along with the a pointer to * the allocat

* Writes a CRAM SAM header. * Returns 0 on success * -1 on failure */

* Writes a cram_file_def structure to cram_fd. * Returns 0 on success * -1 on failure */

Decompress up to ten or so bytes by peeking at the file, which must be positioned at the start of a GZIP block.

Store a double value in little-endian byte order @param val The value to store * @param buf Where to store it (may be unaligned) */

* Returns the number of expected read names for this record. */

* As per open_path_mfile, but searching only for local filenames. * This is useful as we may avoid doing a full mfopen and loading * the entire file

* Converts 'in' to a full pathname to store in out. * Out must be at least PATH_MAX bytes long. */

return the maximum absolute value of the vector

return the minimum absolute value of the vector

void getSavedData(string &str) const { str = _saveDataStr; }