RE: cvs commit: hugs98/tools hugs-hc

On 12 November 2004 15:17, Malcolm Wallace wrote:
"Simon Marlow"
writes: Added files: tools hugs-hc Log: Wrapper for Hugs to make it look enough like GHC to run the testsuite. It's an ugly kludge, and doesn't handle FFI.
Neat!
Yeah, I agree! Now I'm wondering if I can use the same trick to give nhc98 a ghc-like personality, and hence to be able to run your test-suite too.
That wasn't how I initially envisioned running the testsuite using different compilers, but I guess various ghc-specific bits have crept into the allegedly portable parts of the framework :-( Cheers, Simon

On Fri, Nov 12, 2004 at 03:24:52PM -0000, Simon Marlow wrote:
That wasn't how I initially envisioned running the testsuite using different compilers, but I guess various ghc-specific bits have crept into the allegedly portable parts of the framework :-(
Just a little. The following options are used: +RTS --make -C -Di386_unknown_linux -O -W -Wall -c -cpp -fglasgow-exts -fno-warn-incomplete-patterns -funbox-strict-fields -fwarn-unused-binds -fwarn-unused-matches -no-hs-main -o -package -v0 most of which are ignorable. A wrapper for Hugs has to pretend to generate .o files and executables, which won't be a problem for nhc98. You'll have to skip a lot more tests, though. The timeout patch also makes several tests GHC-only; perhaps it could be wrapped up somehow. (Not that Hugs doesn't need a timeout sometimes.)

On Fri, Nov 12, 2004 at 04:39:20PM +0000, Ross Paterson wrote:
The timeout patch also makes several tests GHC-only; perhaps it could be wrapped up somehow. (Not that Hugs doesn't need a timeout sometimes.)
Do you mean http://www.haskell.org//pipermail/cvs-ghc/2004-October/022166.html ? The only ghc-specific bit is working out what the value of TIMEOUT should be, but that's not part of the patch. It's done by whoever runs the testsuite. If you leave it blank then it will not use a timeout, or you could find a more suitable heuristic for hugs. Timing hugs evaluating something like "let f 0 = (); f x = f (x-1) in f 1000000" and multiplying it by a suitable conservative constant should do. And while I'm here, this work is really cool! What would be even better from my PoV is if we made sure the testsuite had no unexpected failures or passes for the last 2 or 3 releases of the implementations. This might need a slightly more flexible extension of the per-implementation stuff you've added. We might then be able to have the Debian packages run the latest version (if it doesn't take /too/ long proportionate to the build time; I guess skipping the real programs section if necessary should give a significant speed boost, though) when they build and fail if anything unexpected happens. Currently only ghc-cvs runs the testsuite, and it suceeds regardless of the outcome (on the grounds that unexpected stuff is, err, expected, and should anything actually unexpected happen we don't want the compiler thrown away as then we can't investigate them). Thanks Ian

On Fri, Nov 12, 2004 at 05:41:47PM +0000, Ian Lynagh wrote:
On Fri, Nov 12, 2004 at 04:39:20PM +0000, Ross Paterson wrote:
The timeout patch also makes several tests GHC-only; perhaps it could be wrapped up somehow. (Not that Hugs doesn't need a timeout sometimes.)
Do you mean http://www.haskell.org//pipermail/cvs-ghc/2004-October/022166.html ?
Sorry, I was talking about watchdog snippets like this in various tests: main_t <- myThreadId forkIO $ do threadDelay 2000000 throwTo main_t (ErrorCall "killed") which I confused with the title of your patch, when actually your patch is exactly the replacement for these that I was asking for.
And while I'm here, this work is really cool! What would be even better from my PoV is if we made sure the testsuite had no unexpected failures or passes for the last 2 or 3 releases of the implementations. This might need a slightly more flexible extension of the per-implementation stuff you've added.
It would be nice, but just getting the latest version to pass is more than we can manage at present. (I currently have 124 unexpected failures, though lots of these are due to not handling the FFI.)
participants (3)
-
Ian Lynagh
-
Ross Paterson
-
Simon Marlow