Jump to content

BAM conversion


Recommended Posts

Does CLEAR_MEMORY wipe out the zlib library too, or no?

 

If it did

OUTER_PATCH list BEGIN
 WRITE_BYTE 0 0
 READ_ASCII 0 0t_0 (1)
END
OUTER_SPRINT list ~~
<<<<<<<<unprocessed_list.txt
%list%>>>>>>>>
COPY_EXISTING_REGEXP ~^.+\.bam$~ nowhere
 TO_LOWER SOURCE_RES
 SNPRINT 8 item ~%SOURCE_RES%%0t_0%%0t_0%%0t_0%%0t_0%%0t_0%%0t_0%%0t_0%%0t_0%~
 SPRINT  list ~%list%%item%~
BUT_ONLY
COPY +  unprocessed_list.txt processed_list.txt
 EVALUATE_BUFFER
OUTER_WHILE NOT FILE_SIZE unprocessed_list.txt 0 BEGIN
 COPY + unprocessed_list.txt unprocessed_list.txt
READ_ASCII   0 bam
DELETE_BYTES 0 8
 COPY_EXISTING ~%bam%.bam~ workspace
DO_DECOMPRESSION_AND_OTHER_VOODUN
 CLEAR_MEMORY
END

 

in some form would spare the AT_NOW calls (hopefully with a better winnowed .bam list too :crazyeyes: )

Link to comment

Nah, it's really not :groucho:

 

I hate using temp files, but it may be a viable way out of CANNOT_GROW_BUFFER - which files have yet to be patched are stored in the unprocessed_list.txt file (which is just .bam resrefs null-padded to eight characters).

 

While unprocessed_list.txt has a file size not equal to zero, read a resref out of it, delete the eight bytes containing that resref, then do conversion routines on the resref.bam you've just pulled. CLEAR_MEMORY after each set of actions may (or may not) keep the zlib library from choking.

 

I'll give it a shot later, I'm just buried in work and flailing around uselessly for ideas :crazyeyes:

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...