Yes, this is a bit of a stumbling block. This was the first solution I thought of. Come to think of it, this may be the space leak in my library. I think I'm using the naive solution, "length [SoundData]", to get the length while writing the header. If I understand the language properly (still in doubt), that would force every item in the list, chewing up memory for a large file.
I just thought of another option, though. If you know the original length of the data (probably from reading the header), and the extra length added by your processing function is independent of the data (this is true for everything I am currently interested in, but unfortunately not in general), you could simply sum the changes to the length before you do the processing. Of course this wouldn't work for a data stream. On Dec 14, 2007 3:37 AM, Henning Thielemann <[EMAIL PROTECTED]> wrote: > > On Fri, 14 Dec 2007, Soenke Hahn wrote: > > > Indeed, the iffparse.library on AmigaOS did it this way. This is obviously > only possible on devices that allow for 'seek'. _______________________________________________ haskell-art mailing list haskell-art@lists.lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
