On Fri, Jun 3, 2011 at 03:53, Ketil Malde wrote:
> dm-list-haskell-c...@scs.stanford.edu writes:
>
>> leaking file descriptors
>
> ...until they are garbage collected. I tend to consider the OS fd
> limitation an OS design error - I've no idea why there should be some
> arbitrary limit on open fi
dm-list-haskell-c...@scs.stanford.edu writes:
> leaking file descriptors
...until they are garbage collected. I tend to consider the OS fd
limitation an OS design error - I've no idea why there should be some
arbitrary limit on open files, as long as there is plenty of memory
around to store the
On 6/2/11 8:59 AM, Aleksandar Dimitrov wrote:
Hi Ketil,
By the way, what is the advantage of using iteratees here? For my
testing, I just used:
My initial move to iteratees was more a clutch call I made when I was still
using bytestring-trie, and was having immense memory consumption problem
At Thu, 02 Jun 2011 13:52:52 +0200,
Ketil Malde wrote:
>
> I have a bunch of old code, parsers etc, which are based on the
> 'readFile' paradigm:
>
> type Str = Data.ByteString.Lazy.Char8.ByteString -- usually
>
> decodeFoo :: Str -> Foo
> encodeFoo :: Foo -> Str
>
> readFoo = decodeFoo
Hi Ketil,
> By the way, what is the advantage of using iteratees here? For my
> testing, I just used:
My initial move to iteratees was more a clutch call I made when I was still
using bytestring-trie, and was having immense memory consumption problems.
bytestring-trie uses strict byte strings a
By the way, what is the advantage of using iteratees here? For my
testing, I just used:
main = printit . freqs . B.words =<< B.readFile "words"
(where 'printit' writes some data to stdout just to make sure stuff is
evaluated, and you've already seen some 'freqs' examples)
I have a bunch of o
