Is the choice of whether or not to open/close with each chunk
read something that we can reasonably hide from the I/O API's
user? There is at least one way in which is semantically
distinct -- that old trick of opening a tempfile and then
unlinking it to hide it.
It may be the sort of
2008/09/18 o...@okmij.org:
Operationally, the code does not open more than one file at a
time. More importantly, the code *never* reads more than 4096
characters at a time. A block of the file is read, split into
words, counted, and only then another chunk is read. After one
file is done, it
I hate to say it; but you know you can tweak the OS to allow
excessive file handle usage.
I once wrote a Haskell script to empty a very, vary large S3
bucket. On Linux, I had to put it in a shell while loop to
keep it going, due to file handle exhaustion. On my Mac it ran
without
Oh, curses. I didn't run it with the right option.
:; ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) 6144
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open
It depends on the underlying file control used by ghc. if it's the FILE
stream pointer, some implementations suffer from a 255 file limit. If it's a
standard file descriptor (open instead of fopen), then it's limited by
ulimit.
On Sun, Apr 5, 2009 at 10:35 AM, Jason Dusek jason.du...@gmail.com
It opens and closes each file in turn; but it would it be
unwise to open and close each file as we'd read a chunk from
it? This would allow arbitrary interleaving.
If I understand you correctly, you are proposing processing several
files in parallel, so to interleave IO. If the `files'
Lennart Augustsson wrote
main = do
name:_ - getArgs
file - readFile name
print $ length $ lines file
Given the stance against top-level mutable variables, I have not
expected to see this Lazy IO code. After all, what could be more against
the spirit of Haskell than a `pure'
oleg:
Given the stance against top-level mutable variables, I have not
expected to see this Lazy IO code. After all, what could be more against
the spirit of Haskell than a `pure' function with observable side
effects. With Lazy IO, one indeed has to choose between correctness
and
oleg-30 wrote:
I have not expected to see this Lazy IO code. After all, what could be
more against
the spirit of Haskell than a `pure' function with observable side effects.
What could even be more against the spirit of Haskell than
the original theme of this thread, i.e. code that
I agree that lazy IO is a can with some worms in it. But it's not that strange.
The readFile operation is in the IO monad, so it has an effect on the world.
This effect is not finished when readFile returns, and from the world
point of view
it's not entirely deterministic.
On Fri, Sep 19, 2008
On Fri, 2008-09-19 at 16:30 +0100, Lennart Augustsson wrote:
I agree that lazy IO is a can with some worms in it. But it's not that
strange.
The readFile operation is in the IO monad, so it has an effect on the world.
This effect is not finished when readFile returns, and from the world
On Fri, Sep 19, 2008 at 2:51 AM, [EMAIL PROTECTED] wrote:
Lennart Augustsson wrote
main = do
name:_ - getArgs
file - readFile name
print $ length $ lines file
Given the stance against top-level mutable variables, I have not
expected to see this Lazy IO code. After all, what
12 matches
Mail list logo
