- Nhc-bugs - Haskell.org

Axis of Evil
by Wanted! 21 Mar '02

21 Mar '02

1 0

Re: [nhc-bugs] problems with 1.12
by Malcolm Wallace 20 Mar '02

20 Mar '02

> The whole thing failed at the end because we don't have Java, but I > guess this is not really needed for anything? ;-) You are right, it is not needed. I will disable the java build in the standard setup, since we supply a pre-built .jar file anyway. > P.S. Since I've also had transmission problems, I attach yesterday's > mail about the Solaris build. Thanks for the copy, but I received it yesterday. My reply (again) went to you alone, so I guess you are not receiving direct emails, only the ones on the nhc-bugs list. I'll copy that message to the list as well, to ensure you receive it. Regards, Malcolm

1 0

Fw: Re: [nhc-bugs] problems with 1.12
by Malcolm Wallace 20 Mar '02

20 Mar '02

Hi Feliks, > > (Forwarded message, original mistakenly sent only to Feliks.) > Never got the first one. [ I got a "not-delivered after 24 hours" warning on the original, which alerted me to the fact it was addressed only to you. ] > It's just that I was so impressed with the ease of porting the previous > two versions that I wondered whether there was anything in your > "process" that gave this effect and that you might be able to restore. Well it is true that at one time we built the compiler regularly on three different machine architectures (ix86-Linux, mips-IRIX, sparc-solaris). We no longer have any mips-IRIX machines, and the nightly sparc-solaris build is currently on hold due to an annoying feature of SSH, so there is only one machine/OS combination being tested daily at the moment. You are absolutely right that we should try to restore this part of our "process", since I am sure that its lack is the cause of many of the small errors you and others have been seeing. > Since hbc more or less expired, and ghc is excellent, but devilishly > difficult to port, I would imagine that portability could be _the_ > "selling" point for nhc, now that memory has become so cheap. We have always sold nhc98 on portability, and would like to continue to do so. > The file is there, and the symbols are there, too. > > I have a vague recollection that half a year ago (in another context, > nothing to do with nhc) I encountered a similar problem and that it had > something to do with assumptions about whether a library file is in > shareable format... I have a suggestion - try running `ranlib' on the archive file. I think the GNU ar does this automatically at creation time, but the BSD ar probably does not. If this fixes the problem, then I will add it to the Makefile. > I don't even know what "observe" does, so this might be irrelevant. It implements fast file-access primitives for the hat-observe program, which is (obviously) one of the Hat trace-browsing tools. If you aren't intending to use tracing (why not?! :-) then this part of the build doesn't matter to you anyway. Regards, Malcolm

1 0

Re: [nhc-bugs] problems with 1.12
by Malcolm Wallace 20 Mar '02

20 Mar '02

(Forwarded message, original mistakenly sent only to Feliks.) Feliks Kluzniak <feliks(a)crt.se> writes: > I find this a little worrying. The previous two versions of nhc were > quite painless to build on all sorts of systems, including Solaris and > OpenBSD: this is not an advantage that should be given up easily! I am sorry that you are having these problems, but it is inevitable that different operating systems have slightly different properties, and we cannot possibly test on all of them. Nevertheless, we do aim for nhc98 to be as painless as possible to build on any Unix-like machine. Your bug reports are very valuable in helping us to achieve that aim. > cd /q/pd/nhc/nhc98-1.12/targets/ix86-OpenBSD/obj/hattools && > /q/pd/nhc/nhc98-1.12/script/nhc98 +RTS -K10M -RTS +CTS -H20M -CTS > -o HatObserve Run.o PrettyLibHighlight.o HighlightStyle.o PrettyExp.o > HatExpressionTree.o HatTrie.o HatTrace.o HatObserve.o > /q/pd/nhc/nhc98-1.12/targets/ix86-OpenBSD/obj/hattools/hatlib.a > > observe.c:604: Undefined symbol `_newFunTable' referenced from text > segment observe.c:616: Undefined symbol `_addToFunTable' referenced > from text segment observe.c:624: Undefined symbol > `_FunTableCheckArities' referenced from text segment collect2: ld > returned 1 exit status It looks like your machine's version of 'ar' might differ from GNU ar. Those symbols are defined in the source file src/hat/tools/FunTable.c, which is compiled by $(CC) and added to the hatlib.a archive by the command ar -rc $(OBJDIR)/hatlib.a $(THOROBJS) The error messages refer to `observe.c', which is also a member of the archive. Perhaps you can use nm .../targets/ix86-OpenBSD/obj/hattools/hatlib.a to determine whether the file Funtable.o exists in the archive, and whether it does indeed define the symbols which are claimed to be missing. Send me any interesting information you find. Regards, Malcolm

1 0

a problem with 1.12
by Feliks Kluzniak 19 Mar '02

19 Mar '02

Hello, When I tried to build 1.12 (from the sources, on Solaris, with GHC, worked perfectly with 1.10), I got gcc -c -I../Kernel -I/q/pd/nhc/nhc98-1.12/include -D__EXTENSIONS__ -O3 -DHIGH_BYTE_FIRST -o /q/pd/nhc/nhc98-1.12/targets/sparc-solaris2/obj/runtime/Builtin/cFFI.o cFFI.c In file included from cFFI.c:3: HsFFI.h:5: stdint.h: No such file or directory Regards, -- Feliks

3 3

problems with 1.12
by Feliks Kluzniak 18 Mar '02

18 Mar '02

Hello, In OpenBSD (built just with gcc) the "stdint.h" -> "inttypes.h" patch was also required (see Oliver Braun's earlier advice for compiling on Solaris). The whole thing stopped with: nhc/nhc98-1.12/targets/ix86-OpenBSD/obj/hattools/HatObserve.o HatObserve.hs cd /q/pd/nhc/nhc98-1.12/targets/ix86-OpenBSD/obj/hattools && /q/pd/nhc/nhc98-1.12/script/nhc98 +RTS -K10M -RTS +CTS -H20M -CTS -o HatObserve Run.o PrettyLibHighlight.o HighlightStyle.o PrettyExp.o HatExpressionTree.o HatTrie.o HatTrace.o HatObserve.o /q/pd/nhc/nhc98-1.12/targets/ix86-OpenBSD/obj/hattools/hatlib.a observe.c:604: Undefined symbol `_newFunTable' referenced from text segment observe.c:616: Undefined symbol `_addToFunTable' referenced from text segment observe.c:624: Undefined symbol `_FunTableCheckArities' referenced from text segment collect2: ld returned 1 exit status I find this a little worrying. The previous two versions of nhc were quite painless to build on all sorts of systems, including Solaris and OpenBSD: this is not an advantage that should be given up easily! Regards, -- Feliks

1 0

hat and ghc and literate scripts
by Amanda Clare 18 Mar '02

18 Mar '02

I just installed the binary for nhc98-1.12. The hat package files for ghc ended up in my .../lib/ghc-5.02.1/imports directory rather than .../lib/ghc-5.02.1/imports/hat. Creating a hat directory and moving the files into it fixed this. Can hat handle .lhs files yet? I get the following for a literate file with RCS annotations at the top (the first character is a $) hat-trans DeepSeq.lhs ====== In file: DeepSeq.lhs: 1:1 Found ($) but expected a {-end-of-definition-or-EOF-} Amanda -- Amanda Clare http://users.aber.ac.uk/ajc99/ Tel: +44 (0)1970 621787 Fax: +44 (0)1970 622455 Dept. of Computer Science, University of Wales, Aberystwyth, SY23 3DB

1 0

two problems exportation/importation of field labels.
by Feliks Kluzniak 08 Mar '02

08 Mar '02

Hello! I think NHC does not properly handle exports and imports of field labels. Problem 1 -------- The following two modules seem to be legal according to the Haskell 98 report (Sec.5.2, p. 66): ================================================================== module See1 ( D( Undef, Def, value ) ) where data D = Undef | Def{ value :: Int } ------------------------------------------------------------------ module See2 ( foo ) where import See1 ( D( Undef, Def, value ) ) foo :: D -> Int foo d = case d of Undef -> error "no value" Def{} -> value d ================================================================== Both GHC and Hugs accept this, but NHC reports an error: hmake -d../nhc See2.hs nhc98 -c -d ../nhc See1.hs ==================================== In file: ./See1.hs: 1:16 Found ( but expected one of ) , If one changes the heading of See1 to module See1 ( D( Undef, Def ), value ) where then one gets hmake -d../nhc See2.hs nhc98 -c -d ../nhc See2.hs ==================================== In file: ./See2.hs: 3:13 Found ( but expected a {-end-of-definition-or-EOF-} Problem 2 --------- There are no syntactic problems when one uses another, equally legal form: ================================================================== module See1 ( D( Undef, Def ), value ) where data D = Undef | Def{ value :: Int } ------------------------------------------------------------------ module See2 ( foo ) where import See1 ( D( Undef, Def ), value ) foo :: D -> Int foo d = case d of Undef -> error "no value" Def{} -> value d ================================================================== Again, this is accepted both by GHC and Hugs. But now NHC has another bone to pick: hmake -d../nhc See2.hs nhc98 -c -d ../nhc See2.hs ==================================== Error when renaming:: Identifier value defined 2 times. To make this go away, one has to change the importation clause to import See1 ( D( Undef, Def ) ) Now everything is OK, and NHC does not complain about the occurrence of "value" in "foo"! Regards, -- Feliks

2 1

Type checker bug
by Simon Marlow 18 Feb '02

18 Feb '02

The following module should elicit a type error: type T a = Int class C a where f :: a -> T a g :: T a -> a instance C Char main = print (g (f 'a')) but nhc98 compiles it without complaint. GHC & Hugs both emit an unresolved overloading error: test187.hs:9: Ambiguous type variable(s) `a' in the constraint `C a' arising from use of `g' at test187.hs:9 In the first argument of `print', namely `(g (f 'a'))' In the definition of `main': print (g (f 'a')) test187.hs:9: Ambiguous type variable(s) `a' in the constraint `Show a' arising from use of `print' at test187.hs:9 In the definition of `main': print (g (f 'a')) I believe nhc98's Binary library makes use of the same trick in its definition of the Bin type. The type synonym in the example should really be a newtype. Cheers, Simon

1 0

trouble building trace
by Stoney Jackson 14 Feb '02

14 Feb '02

Hello, I'm getting a lexer error from the greencard-nhc98 script when trying to make trace. I've been able to build basic, heapprofile, timeprofile, compiler, hmake, runtime, prelude, greencard, hp2graph. $ uname -a CYGWIN_NT-5.0 SALSERO 1.3.9(0.51/3/2) 2002-01-21 12:48 i686 unknown --------- make excerpt ------------- /home/jacksoni/dl/nhc98-1.10/script/hmake -nhc98 -K10M +CTS -H20M -CTS Hatobserve /home/jacksoni/dl/nhc98-1.10/targets/ix86-CYGWIN_NT-5.0/obj/hat/hatlib.a -d/ home/jacksoni/dl/nhc98-1.10/targets/ix86-CYGWIN_NT-5.0/obj/hat nhc98 +RTS -K10M -RTS +CTS -H20M -CTS -c -d /home/jacksoni/dl/nhc98-1.10/targets/ix86-CYGWIN_NT-5.0/obj/hat HatTrace.gc Lexical error: unrecognised input at line 183 col 45 greencard-nhc98 failed on ./HatTrace.gc make[1]: *** [/home/jacksoni/dl/nhc98-1.10/lib/ix86-CYGWIN_NT-5.0/hat-observe] E rror 1 make[1]: Leaving directory `/home/jacksoni/dl/nhc98-1.10/src/tracer/hat' make: *** [lib/ix86-CYGWIN_NT-5.0/hat-check] Error 2 --------- line 183 from ./src/tracer/hat/HatTrace.gc ----- %dis addr x = declare "void*" x in (%%Addr x) Column 45 of this line is the closing paren ')'. Any ideas? -- Stoney

2 1