Didn't get to this last night but I've just now confirmed this. With a normal
build (defaulting to -O) the test code below generates only 3 failures (MacOS
Leopard w/GHC 6.12.3 and HUnit 1.2.2.3). When using -O0 or by changing
assertFailure in Test.HUnit.Lang (line 81) to use E.throwIO
On 6 June 2011 02:34, KQ qu...@sparq.org wrote:
The shock here is that there was only one failure, whereas the False ~=?
True should have failed.
I'm not sure, but at a glance it looks you might have the usual
problem where compiling your test with optimisations means that GHC
optimises away
On 06/06/2011 10:23, Max Bolingbroke wrote:
On 6 June 2011 02:34, KQ qu...@sparq.org wrote:
The shock here is that there was only one failure, whereas the False ~=?
True should have failed.
I'm not sure, but at a glance it looks you might have the usual
problem where compiling your test
On 6 June 2011 16:18, Jimbo Massive jimbo.massive-hask...@xyxyx.org wrote:
Or is this bad behaviour due to HUnit doing something unsafe?
I think it may be related to this bug:
http://hackage.haskell.org/trac/ghc/ticket/5129
The suggested fix is to change HUnit to define assertFailure with
On 6 June 2011 16:43, Max Bolingbroke batterseapo...@hotmail.com wrote:
The suggested fix is to change HUnit to define assertFailure with
throwIO, but the latest source code still uses throw:
Err, I mean
http://hackage.haskell.org/packages/archive/HUnit/latest/doc/html/src/Test-HUnit-Lang.html
That sounds very applicable to my issue (and unfortunately my googling missed
this, ergo my consult of haskell-cafe uberwissenmensch). When I again have
access to the aforementioned Mac this evening I'll try both disabling
optimizations and a tweaked HUnit to see if that resolves the problem
While working on a project of mine recently I realized that a particular HUnit
test should have been failing. After paring things down, I came up with this
shocker:
test_perhaps.hs:
module Main where
import Test.HUnit
main = runTestTT $ TestList [ True ~=? True
