Hi I think the issue you're running in to with 6.4 is this one: http://hackage.haskell.org/trac/ghc/ticket/830 - known and fixed a while back.
Thanks Neil On Thu, Aug 6, 2009 at 9:59 PM, Dan Weston<weston...@imageworks.com> wrote: > I assume for the return line, you meant to return a list, not a tuple. ghc > doesn't support a 600-tuple. > In any case, returning a list, I have verified that this problem exists in > ghc 6.10.3, for -O0 and -O2. > > For -O0, it compiles and links fine, but gives this runtime message: > > z: internal error: scavenge: unimplemented/strange closure type -1 @ > 0x2a95a8e000 > (GHC version 6.10.3 for x86_64_unknown_linux) > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > Abort > > Maybe it is attempting to unroll these loops, even with -O0? > > Dan > > Henning Thielemann wrote: >> >> Today a student has shown me a program that consists of a large 'do' block >> for the list monad. The program looks like >> >> do x1 <- [0..3] >> x2 <- [0..2] >> ... >> x600 <- [0..5] >> guard (x1+x2+2*x3 >= 0) >> ... >> return (x1,x2,....,x600) >> >> It was actually generated by another program. The results were: >> >> GHC-6.4 was not able to compile that program at all, because it stopped >> because of memory exhaustion. >> GHC-6.8.2 finished compilation after two minutes but the program aborted >> quickly because of a corrupt thunk identifier. >> GHC-6.10 not yet tested. >> Hugs-2006 executed the program without complaining and showed the first >> result after a few seconds: (0,0,0,0,0,...,0). >> >> Eventually the program must run on a Linux cluster with a not up-to-date >> Linux kernel, that is, I suspect newer GHC versions cannot be used due to >> the 'timer_create' problem. (At least, the 'cabal' executable that I >> generated with a GHC-6.8.2 had this problem when running on the cluster >> which reminded me on the problems with GHC-6.8 itself running on older Linux >> kernels.) >> >> Since the list monad sorts the variable values in lexicographic order >> which is inappropriate for the considered problem, I recommended the use of >> control-monad-omega. Luke, I hope this monad can cope with 600 variables. >> :-) >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
