In the recently burried haskell-cafe thread "speed: ghc vs gcc",
Bulat pointed out some of the optimizations that GHC doesn't
do, such as loop unrolling. I suggested a way of experimenting
with loop unrolling, using template haskell to bypass GHC's
blindspot (it usually doesn't unfold recursive
My ghc(i) crashes when using STM data invariants. This little piece of code
demonstrates the problem:
module Bug where
import Control.Concurrent.STM
test = do
x <- atomically $ do
v <- newTVar 0
always $ return True -- remove this line and all is fine
return v
atomically (readTVa
i'm implementing a benchmark which includes a detailed specification for a
random number generator. for any of the kernels outlined in the benchmark,
i might have to generate a set of random numbers R, which has a length n,
using the following formulas:
R[k] = ((2^-46)(X[k])) mod 2^46, where
X[k
Malcolm Wallace wrote:
Simon Marlow wrote:
stdout should be flushed when the program exits, regardless of whether
it exits as a result of a clean exit or an exception. I've just
checked the code, and that's certainly what is supposed to happen.
If anyone has evidence to the contrary, plea
Peter Hercek wrote:
Simon Marlow wrote:
You seem to have a plan for maintaining a dynamic stack for debugging,
perhaps you could flesh out the details in a wiki page, mainly to
ensure that we're discussing the same thing?
Sure, but the plan to maintain an approximate debugging dynamic stack
Peter Hercek wrote:
> > http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack
>
> I was writing about a way how to maintain the stack as described in
> point 6 of the page (provided that point is about dynamic stack).
The whole page (including point 6) is about explicitly maintaining a
(s
Simon Marlow wrote:
> stdout should be flushed when the program exits, regardless of whether
> it exits as a result of a clean exit or an exception. I've just
> checked the code, and that's certainly what is supposed to happen.
> If anyone has evidence to the contrary, please submit a bug re
