Simon Marlow marlo...@gmail.com 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
Peter Hercek pher...@gmail.com 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
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
Malcolm Wallace wrote:
Simon Marlow marlo...@gmail.com 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
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
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 (readTVar
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
