Nythrun Posted May 7, 2008 Share Posted May 7, 2008 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 ) Link to comment
DavidW Posted May 7, 2008 Author Share Posted May 7, 2008 Can you explain that to me in simple terms? - it looks great but it's over my head right now... Link to comment
Nythrun Posted May 7, 2008 Share Posted May 7, 2008 Nah, it's really not 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 Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.