Hi,
thanks for your comments.
Am Montag, den 30.06.2008, 16:54 -0700 schrieb Ryan Ingram:
1) unsafeInterleaveIO seems like a big hammer to use for this problem,
and there are a lot of gotchas involved that you may not have fully
thought out. But you do meet the main criteria (file being read
Joachim Breitner [EMAIL PROTECTED] writes:
1) unsafeInterleaveIO seems like a big hammer to use for this problem,
and there are a lot of gotchas involved that you may not have fully
thought out. But you do meet the main criteria (file being read is
assumed to be constant for a single run of
Hi,
Am Dienstag, den 01.07.2008, 11:53 +0200 schrieb Ketil Malde:
Joachim Breitner [EMAIL PROTECTED] writes:
1) unsafeInterleaveIO seems like a big hammer to use for this problem,
and there are a lot of gotchas involved that you may not have fully
thought out. But you do meet the main
On Tue, Jul 01, 2008 at 10:22:35AM +, Joachim Breitner wrote:
Hi,
Am Dienstag, den 01.07.2008, 11:53 +0200 schrieb Ketil Malde:
Joachim Breitner [EMAIL PROTECTED] writes:
1) unsafeInterleaveIO seems like a big hammer to use for this problem,
and there are a lot of gotchas
On Tue, 1 Jul 2008, David Roundy wrote:
Indeed, the best option (in my opinion) would be
unsafeInterleaveIO readFileStrict
How about ByteString.readFile ? This is strict and efficient.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
On 7/1/08, Joachim Breitner [EMAIL PROTECTED] wrote:
Hi,
thanks for your comments.
Am Montag, den 30.06.2008, 16:54 -0700 schrieb Ryan Ingram:
1) unsafeInterleaveIO seems like a big hammer to use for this problem,
and there are a lot of gotchas involved that you may not have fully
Hi,
thanks again for you input. Just one small remark:
Am Dienstag, den 01.07.2008, 14:52 -0700 schrieb Ryan Ingram:
On 7/1/08, Joachim Breitner [EMAIL PROTECTED] wrote:
Am Montag, den 30.06.2008, 16:54 -0700 schrieb Ryan Ingram:
1) unsafeInterleaveIO seems like a big hammer to use for
On 2008 Jul 1, at 17:52, Ryan Ingram wrote:
Well, you're also (from your description) probably writing some
tracking information to an IORef of some sort. That can happen in the
middle of an otherwise pure computation, and it's difficult to know
exactly when it'll get triggered, due to
Hi,
for an application such as a image gallery generator, that works on a
bunch of input files (that are assumed to be constant during one run of
the program) and generates or updates a bunch of output files, I often
had the problem of manually tracking what input files a certain output
file
2008/6/30 Joachim Breitner [EMAIL PROTECTED]:
The problem I stumbled over was that considering the type of =
(=): Monad m = m a - (a - m b) - m b
means that I can not „look ahead what files would be written without
actually reading the requested file. Of course this is not always
possible,
On Mon, 2008-06-30 at 12:04 +0200, Joachim Breitner wrote:
Hi,
for an application such as a image gallery generator, that works on a
bunch of input files (that are assumed to be constant during one run of
the program) and generates or updates a bunch of output files, I often
had the problem
Hi,
Am Montag, den 30.06.2008, 07:08 -0500 schrieb Derek Elkins:
You may want to look at Magnus Carlsson's Monads for Incremental
Computing http://citeseer.comp.nus.edu.sg/619122.html
not exactly what I need, but very interesting read. Maybe I can use some
of the ideas.
Thanks,
Joachim
--
Some comments:
1) unsafeInterleaveIO seems like a big hammer to use for this problem,
and there are a lot of gotchas involved that you may not have fully
thought out. But you do meet the main criteria (file being read is
assumed to be constant for a single run of the program).
If you have the
13 matches
Mail list logo
