` 100 -- `div` cpuTimePrecision
-- putStrLn $ Timing: ++ str ++ ++ show time
return time
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Tobias Olausson
tob...@gmail.com
prop_schedule
*** Failed! Falsifiable (after 5 tests and 1 shrink):
[((),0,0),((),-1,0)]
--
Tobias Olausson
tob...@gmail.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
It seems this was the case, thank you!
/Tobias
2009/7/24 Felipe Lessa felipe.le...@gmail.com:
On Fri, Jul 24, 2009 at 08:11:12PM +0200, Tobias Olausson wrote:
prop_schedule :: Ord t = [Interval a t] - Bool
prop_schedule [] = True
prop_schedule [a] = True
prop_schedule (x:y:ys
.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Tobias Olausson
tob...@gmail.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo
This simple implementation of CPU does not behave as expected in the
latest version of ghc using ST.Lazy since it updates the `pc` in the
wrong order.
When we use ghc-6.8 the code works as expected both with lazy and strict ST.
How is that? How do we fix this so we can use ghc-6.10.
--
(loopSys 0)
which in turn is being runST'd and then printed
Does anyone know why the program just outputs loop
when compiled under ghc 6.10.2, and runs perfectly fine
under ghc 6.8.2? The program is compiled with --make and -O2
Tobias Olausson
tob...@gmail.com
guess is that you want one of
(1) mdo, when the effects in 'something' only matter once, or
(2) unsafeInterleaveST, if you just want to be able to traverse the
(x:xs) list lazily and the references it uses are dead after calling
foo.
-- ryan
On Sun, May 3, 2009 at 10:27 AM, Tobias Olausson
the program spend 96.1% of its total running time collecting garbage?
Any tips to make this program perform better are appreciated.
Please do tell if anything is unclear.
--
Tobias Olausson
tob...@gmail.com
___
Haskell-Cafe mailing list
Haskell-Cafe
://hackage.haskell.org/trac/ghc/ticket/2727 . It doesn't analyze
the cause of the slowness, so it's quite possible that it may be
related to GC as in your case.
Cheers,
Dan
On Tue, Mar 3, 2009 at 7:44 PM, Tobias Olausson tob...@gmail.com wrote:
Hello all.
I am currently implementing