Re: [web-devel] problem with yesod, persist and enumerations

I think you've got very little to fear about here. The GHC team is amazingly responsive, and addresses issues quickly. For the three that you're bringing up: 1. It's debatable whether GHC is doing the wrong thing here, and I *think* there's work going on now to "fix" this problem. (I would also like to see the current behavior changed.) 2. Well, I just wrote the bug report, so we can't expect much from them here. But if you think there are no other compilers in wide usage today that suffer from bugs, you're in for a rude awakening. 3. I'm bad at analogies, so I'll just put it this way: have you seen the Perl/Python/Ruby multi-threading model? We've got nothing to complain about here. Plus, there's active work to make it even better. <prediction>Basically, if you write code today in Haskell versus Perl/Python/Ruby for multithreading, you'll scale to four cores much better than they will. And six months from now, you'll scale to eight cores as well, without changing a line of code.</prediction> That's not to say you shouldn't bring up your concerns, but I think that from this perspective Haskell and GHC are in good shape. Michael On Sat, Apr 16, 2011 at 8:35 PM, Anton Cheshkov wrote:

I worry about the future of haskell (ghc). I know at least three problems

- not memory releasing - optimization issues - multi-core execution issue (works bad with more than 4 core)

sadly ... (

2011/4/16 Michael Snoyman

...

On Sat, Apr 16, 2011 at 5:54 PM, Chris Casinghino < chris.casinghino@gmail.com> wrote:

...

On Sat, Apr 16, 2011 at 10:45 AM, Greg Weber wrote:

...

Are you compiling with the development server or doing a cabal build/

I'm doing a cabal build. To reproduce this, I run (cabal configure && cabal build) from the command line in the project directory.

I can confirm that this happens. However, it *only* happens when building with cabal. When building with "ghc --make", using runghc or wai-handler-devel, everything works fine. So I tried compiling with "ghc --make -O", and sure enough the same bug appeared.

I don't think there's anything we can do in the libraries to avoid this, it looks like a bug in GHC. You can modify your ghc-options line in the cabal file to pass in "-O0" to disable optimizations, though this is obviously not optimal (bad pun intended). I think we need to report this to the GHC team.

I know virtually nothing about GHC internals, but in case this means something to someone else, here's some of the output from "ghc --make -O -v test.hs":

*** Simplify: *** CorePrep: *** ByteCodeGen: *** Desugar: Result size = 8699 *** Simplifier SimplMode {Phase = InitialPhase [Gentle], no inline, rules, eta-expand, no case-of-case} max-iterations=4: Result size = 9841 Result size = 9797 Result size = 9797 *** Specialise: Result size = 9797 *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): Result size = 13259 *** Float inwards: Result size = 13259 *** Simplifier SimplMode {Phase = 2 [main], inline, rules, eta-expand, case-of-case} max-iterations=4: Result size = 677741 Result size = 850762 Result size = 1028928 Result size = 1028928 *** Simplifier SimplMode {Phase = 1 [main], inline, rules, eta-expand, case-of-case} max-iterations=4: Result size = 1026905 Result size = 1026876 Result size = 1026876 *** Simplifier SimplMode {Phase = 0 [main], inline, rules, eta-expand, case-of-case} max-iterations=4:

Michael

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

-- Best regards, Cheshkov Anton Phone: +7 909 005 18 82 Skype: cheshkov_anton