On Fri, Nov 19, 2004 at 11:10:20AM +0000, Malcolm Wallace wrote:
I happened to notice a new release of hmake was out - thanks for doing this!
Well, it is packaged, and so is cpphs-0.8, but they are not yet announced properly. I was hoping to announce refreshed releases of hmake, cpphs, and nhc98 all at the same time,
Ah, better still! :-)
but unfortunately the Cygwin build of nhc98 is currently seg-faulting about 50% of the time,
:-(
hence only the other two tools have managed to make it out so far.
Speaking of nhc98 problems, when building hat on sparc I'm getting $ nhc98 +RTS -H32M -K2M -RTS +CTS -H32M -CTS -I. -I../compiler98 -c -o /scratch/igloo/hat/hat-2.02/debian/build-nhc98/targets/sparc-Linux/obj/hattrans/HbcOnly.o ../compiler98/HbcOnly.hs Ratio.%: zero denominator $ and the same with 16M instead of 32M, but with 20M it (this file - haven't tried further) compiles fine. Does this sound like a heap corruption bug, or have you got any other idea of what might cause it? Has anything changed in CVS that might have fixed it?
However, unfortunately it seems that the patch I sent here: http://www.haskell.org//pipermail/nhc-users/2003-September/000099.html didn't make it into CVS :-( I've attached the patch for 3.09 (it has a few other small tweaks I made too).
I must apologise. I do have a stack of suggestions for improvements to hmake in my inbox, but have not really had the time to review or implement them properly.
No problem, understood - I could do with some more hours in the day myself :-)
In src/hmake/Imports.hs does "stringgap (c:cs) = stringgap cs" deliberately not check isSpace c? Hmm, there's no [] case either.
Is it unreasonable to assume that the Haskell file is syntactically correct?
If you are hacking on something whose Makefile uses hmake then I don't think you can be confident the source is always syntactically correct. Well, maybe yours is, but mine isn't :-)
I suppose for robustness of hmake, we should at least have the [] case, but I don't know what the right thing to do is if the gap contains non-white characters - currently it ignores them, but it could throw an error.
Ah, I guess the compiler will give a suitable error anyway if the gap contains illegal characters, so not checking seems reasonable. Handling the [] case would definitely be good, though. Thanks Ian