On 16/02/2011 11:09 PM, Max Bolingbroke wrote:
Thinking about it some more, this example is actually quite
interesting because if you *prevent* the list from being floated the
forM gets foldr/build fused into a totally listless optimal loop. It
really does seem like a shame to disable that
On Feb 15, 2011, at 6:05 PM, Daniel Fischer daniel.is.fisc...@googlemail.com
wrote:
On Tuesday 15 February 2011 23:29:39, Andrew Coppin wrote:
Ouch!
I suppose what we could really do with is a combinator that runs a
monadic action N times, without actually constructing a list N elements
On Wednesday 16 February 2011 19:31:05, James Andrew Cook wrote:
Doesn't Control.Monad.replicateM_ do exactly that?
Yes, right, forgot about that. That would've worked fine in Andrew's case.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
On 16/02/2011 06:31 PM, James Andrew Cook wrote:
Doesn't Control.Monad.replicateM_ do exactly that?
10 points to Gryffindore.
(Now, if only there was a version that feeds an integer to the monadic
action as well... Still, it's not hard to implement.)
On 16 February 2011 21:51, Andrew Coppin andrewcop...@btinternet.com wrote:
(Now, if only there was a version that feeds an integer to the monadic
action as well... Still, it's not hard to implement.)
As simple as:
forM [1..x] mk_my_action
___
On Wednesday 16 February 2011 23:13:10, Max Bolingbroke wrote:
On 16 February 2011 21:51, Andrew Coppin andrewcop...@btinternet.com
wrote:
(Now, if only there was a version that feeds an integer to the monadic
action as well... Still, it's not hard to implement.)
As simple as:
forM
On 16 February 2011 22:48, Daniel Fischer
daniel.is.fisc...@googlemail.com wrote:
The problem with that is that under certain circumstances the list is
shared in nested loops, which was what caused the thread (it was mapM_ and
not forM_, but I'd be very surprised if they behaved differently
I tried -O2 -fno-cse. No difference.
I also tried -O2 -fno-full-laziness. BIG DIFFERENCE.
See also the very old GHC ticket at
http://hackage.haskell.org/trac/ghc/ticket/917
I don't know if that's the problem or not, but it might plausibly be.
Here's the smallest version of the program that
On Tuesday 15 February 2011 20:15:54, Andrew Coppin wrote:
I tried -O2 -fno-cse. No difference.
I also tried -O2 -fno-full-laziness. BIG DIFFERENCE.
See also the very old GHC ticket at
http://hackage.haskell.org/trac/ghc/ticket/917
I don't know if that's the problem or not, but it
On 15/02/11 20:35, Daniel Fischer wrote:
Which makes me wonder: unwanted sharing of lists [1 .. n] or similar is a
frequent cause of space leaks, so would it be possible to teach GHC to not
share such lists (unless they're bound to a name to indicate sharing is
wanted)?
In particular for
On Tuesday 15 February 2011 22:20:06, Claude Heiland-Allen wrote:
Compare with the heap profile graph output from this short program which
uses a horrible data-dependency hack to force recomputation:
main = do
print $ length
[(x,y) | x - [(1 :: Int) .. 1], y - [(1 :: Int) ..
On 15/02/2011 08:35 PM, Daniel Fischer wrote:
The result is that the list
[1 .. 10*1024*1024*k]
from the penultimate line of random_file is shared between the four
iterations of the inner loop in file_batch (for k = 1 .. 4). Oops.
Ouch! That's gotta sting in the morning... o_O
I suppose
On Tuesday 15 February 2011 23:29:39, Andrew Coppin wrote:
On 15/02/2011 08:35 PM, Daniel Fischer wrote:
The result is that the list
[1 .. 10*1024*1024*k]
from the penultimate line of random_file is shared between the four
iterations of the inner loop in file_batch (for k = 1 .. 4).
Is this a known bug? (GHC 6.10.x)
It's known to happen when optimising shares what shouldn't be shared. Try
compiling with -O2 -fno-cse (if that doesn't help, it doesn't necessarily
mean it's not unwanted sharing, though).
And, please, let us see some code to identify the problem.
I tried -O2
On 14 February 2011 21:00, Andrew Coppin andrewcop...@btinternet.com wrote:
Is this a known bug? (GHC 6.10.x)
It's known to happen when optimising shares what shouldn't be shared. Try
compiling with -O2 -fno-cse (if that doesn't help, it doesn't necessarily
mean it's not unwanted sharing,
I was battling a similar (the same?) issue recently. The problem might
indeed be caused by excessive sharing. There's a good example in GHC's
trac [1]. Try compiling your code with -O2 and -fno-full-laziness.
There is also an issue with full-laziness and recursive overloaded
functions [2]. Again,
I have a small program that fills a file with random numbers. If I
compile it without optimisation, it runs in constant space. And yet, if
I supply -O2 (or even just -O1), for large output files the program
gobbles large amounts of RAM.
Is this a known bug? (GHC 6.10.x)
On Saturday 12 February 2011 11:30:26, Andrew Coppin wrote:
I have a small program that fills a file with random numbers. If I
compile it without optimisation, it runs in constant space. And yet, if
I supply -O2 (or even just -O1), for large output files the program
gobbles large amounts of
18 matches
Mail list logo
