two minor questions on ghc
Hello, people, here are two minor questions on ghc. (1) To make ghc-2.04 putting .o files into the given subdirectory, say, `o_hi', we command ghc -c Foo.hs -odir o_hi What is the similar option for .hi ? I cannot find it in the ghc user guide. It suggests only ghc -c Foo.hs -ohi o_hi/Foo.hi But this is not so comfortable. Besides, it is said not recommended. Could anybody explain this? (2) catMaybes had escaped from the ghc-0.29 library; the doc. says: "catMaybes, which used to be here, is in the Haskell-1.3 libraries." Besides it is set under the conditional compilation in the sources. What is the idea? Is catMaybes any better than allMaybes ? In the binary snapshot I have, it is not compiled. So I simply repeate the script. But there might be some better solution - ? Thank you. - Sergey Mechveliani [EMAIL PROTECTED]
Re: Mysterious DEC utterances.
Sven Panne on: Warning: Linking some objects which contain exception information sections and some which do not. This may cause fatal runtime exception handling problems (last obj encountered without exceptions was main/LoopHack.o). I don't speak DECish too fluently, but here's my humble guess: Under arcane circumstances, linking gcc-compiled code on DEC-Unix 3.2 produces the above warning. It's annoying, but it doesn't hurt (at least apart from aesthetics :-) . I can now concur, as the rest of the build went swimmingly. Perhaps Josh's problems were 3.2 specific... I don't know if 3.2 and 4.0 are alleged to be object code compatible -- if so, and anyone's desparate enough to try, I could perhaps arrange to send them a built hsc. More utterances: I also note the following message from later in said build. I can't recall having seen any such things things before, though perhaps I either didn't do builds on other platforms with -dshow-passes set (or just didn't notice the output if I did). I assume it too is benign, just mildly Mysterious to we mere mortals. Cheers, Alex. -- rm -f src/PosixUtil.p_o ; if [ ! -d src/PosixUtil ]; then mkdir src/PosixUtil ; else exit 0; fi; find src/PosixUtil -name '*.p_o' -print | xargs rm -f __rm_food; ../../ghc/driver/ghc -H50M -K8M -split-objs -odir src/PosixUtil -hisuf p_hi -recomp -isrc -cpp -fvia-C -fglasgow-exts -dcore-lint -prof '-#include"cbits/libposix.h"' -monly-3-regs -dshow-passes -c src/PosixUtil.lhs -o src/PosixUtil.p_o -osuf p_o ghc: WARNING: splitting objects when profiling will *BREAK* if any _scc_s are present! *** Reader: *** Renamer: *** TypeCheck: *** DeSugar: *** Core2Core: *** Core2Core: Simplify *** Core2Stg: *** Stg2Stg: *** Core Lint result of TidyCorePgm *** Core Lint result of Simplify (3) *** CodeGen: ghc: module version changed to 1; reason: no old .hi file
Re: Not very Happy.
Alex | Further to my previous comments about ghc-2.04 and Happy output, I | can report that having mangled happy-0.9 output to work with 1.4ish | arrays, the situation is more dire yet. For the same happy input | program as previously reported, ghc _really_ struggles to compile | the -a output -- with a 100Mb heap under Solaris, it doesn't get past | the DeSugar phase. (I'd tell you what happens with a 120Mb heap, but | it's still trashing one of our Ultras quite senseless.) Must be a | space-leak, surely? You have a list of 60,000 Ints, on which GHC was doing its full-blown overloading thing. We used this as an excuse to modify the type checker so that the main type-checking function now has type (more or less) tcExpr :: Expr - Type - TcM Expr' instead of the old tcExpr :: Expr - TcM (Expr', Type) That is, the type checker takes the expected type of the epxression, rather than returning the type of the epxression as a result. This means that we can take advantage of information from type signatures, and from the function that's applied to this particular argument expression. Apart from reducing the constant factor on programs like yours, I fancy that error messages will become more informative. Net result: your program has a max residency of 37M instead of 120M. That's still far too much, but it's a worthwhile improvement.I don't regard this saga as over by any means. This'll be in 2.05 which we plan to toss over the fence (source only, only partly tested) tomorrow. Simon
Re: GHC status
I read a nice paper recently "The cathedral and the bazaar" by Eric Raymond, reflecting on his experience Linux, and in particular of developing "fetchmail". You can find it at http://locke.ccil.org/~esr/writings/cathedral.html It's really worth reading. One particular thing he suggests is making very frequent releases, even if they are buggy (like daily when in intense development mode). I've been brought up to think that releasing buggy software is likely to discourage one's users, but perhaps not if the non-buggy versions (ha!) are prominently so flagged, so that "users" can stick to them, while "developers" can pull in the latest one. Comments? (Read the Raymond paper first.) Very nice paper, I greatly enjoyed reading it. I think that the Linux kind of frequent releases may actually be worth a try. For the libraries it is most certainly worth it. For the compiler proper, it probably depends heavily on how many people actually install the sources or even build from them. My impression from the mailing lists is that a substantial number of users do this. Probably a version numbering scheme like that of Linux is necessary to distinguish stable from experimental versions (Linux uses X.Y.Z where Y is even for stable and odd for experimental versions). Linux ftp sites usually keep the even and odd kernel versions in two separate subdirectories to avoid confusion. Manuel
Re: Haskell 1.4 Prelude bug
There's a Haskell 1.4 report bug list at http://haskell.systemsz.cs.yale.edu/report/bugs.html John Peterson puts the entries in, but it's really up to others to write the entry. Would you like to document the bugs you've found along with the fixes and send an entry to John? It would be a great service to human kind. Simon | From: Justin Cormack [EMAIL PROTECTED] | Date: Wed, 23 Jul 97 18:59 BST | Is there an official place to send bug reports to? | | There are several bugs in the lex function specified in the PreludeText | section of the Standard Prelude for Haskell 1.4. To start with the subsidiary | function lexLitChar is not defined. Also there is a typo isAlphaNum instead | of isAlphanum (this typo also appears on page 34 of the Standard Libraries | report). There are I suspect some further bugs too. Also Hugs does not lex | the backquote character as specified in the definition. | | More generally, I wonder why this is in the Prelude rather than a library | where it would seem more appropriate? | | Justin Cormack |
