Fergus Henderson
The main problem here seems to be that Hat doesn't support the "Data.Word" module. Is there any simple work-around? I'm not particularly interested in tracing that module.
The range of hierarchical libraries supported by Hat is still rather limited at the moment I'm afraid. There is a full list of supported and unsupported modules from -package base in docs/libraries.html. Apart from Data.Word, I notice your command-line also mentions the concurrent, net, and posix packages, none of which are yet supported either. In principle, it shouldn't be too difficult to plug some of these things in. There are two issues: * Translate the library sources with hat-trans. Provided you want to 'trust' the library module, and it deals only in standard datatypes, this is just a question of copying the sources into the hatlib build tree and updating the Makefile. * Dealing with primitive types, e.g. Int8, Word16, Socket, etc. Each primitive type needs a wrapper type and a couple of wrapper functions to be written by hand, to<Type> and from<Type>. You will see examples of these in, for instance, Hat/PreludeBuiltinTypes.hs and Hat/Foreign/BuiltinTypes.hs. All primitive functions that manipulate primitive types then also need to be wrapped by hand. The mechanism is illustrated by this: import qualified TraceOrigChar foreign import haskell "Char.isAscii" isAscii :: Char -> Bool import qualified TraceOrigForeign.ForeignPtr foreign import haskell "Prelude.==" eqForeignPtr :: ForeignPtr a -> ForeignPtr a -> Bool and you can see numerous more examples in PreludeBuiltin.hs, Directory.hs, IO.hs, Foreign/ForeignPtr.hs and so on I'm sure a lot of this boilerplate could be automated, given a fairly simple specification of the complete module signature, and it is on our to-do list for when we manage to persuade a funding agency to support the next stage of research on Hat. But in the meantime, it is just another tedious job to be done by hand. A word of warning about concurrency. We don't yet know in detail what it would mean to trace a concurrent program. There are probably locking issues when writing to the (shared) trace file. There may be graph-connectedness issues for the separate threads. And we have no support for examining faults related to concurrency itself, such as the successive values acquired by an MVar. (But see [1].)
I'm not quite sure why it goes on and invokes /usr/bin/haskell-compiler after the openFile failure. But that's a side issue.
Yes, this is a bug in hmake. Regards, Malcolm [1] Concurrent Haskell Debugger, Frank Huch, http://www.informatik.uni-kiel.de/~fhu/chd/