17 replies to this topic

[Nythrun]

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 )

Edited by Nythrun, 06 May 2008 - 05:17 PM.

[DavidW]

Can you explain that to me in simple terms? - it looks great but it's over my head right now...

[Nythrun]

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