- Glasgow-haskell-users

problems building GHC from source in Windows
by Andre W B Furtado 22 Feb '04

22 Feb '04

I was trying to build GHC in my Windows XP, using Cygwin, following the steps in the building guide. I'm stuck in the following error when executing "make" in fptools: creating libgmp.la (cd .libs && rm -f libgmp.la && ln -s ../libgmp.la libgmp.la) make[6]: Leaving directory `/cygdrive/c/haskell/cvs/fptools/ghc/ghc/rts/gmp' make[5]: Leaving directory `/cygdrive/c/haskell/cvs/fptools/ghc/ghc/rts/gmp' ../../ghc/compiler/ghc-inplace -H16m -O -O2 -static -c Apply.hc -o Apply.o make[3]: *** [Apply.o] Error 1 make[2]: *** [all] Error 1 make[2]: Leaving directory `/cygdrive/c/haskell/cvs/fptools/ghc/ghc' make[1]: *** [build] Error 1 make[1]: Leaving directory `/cygdrive/c/haskell/cvs/fptools/ghc' make: *** [build] Error 1 Any suggestions? Thanks, -- Andre

2 1

inconsistent GHC building documentaion
by Andre W B Furtado 21 Feb '04

21 Feb '04

Hi, In the "Building the Glasgow Functional Programming Tools Suite", chapter 12, Notes for building under Windows (http://www.haskell.org/ghc/docs/6.2/html/building/winbuild.html) it is said: "Install an executable Happy, from http://www.haskell.org/happy". The latest version of happy in its website is 1.13. When running configure in fptools, however, I get the error: configure: error: Happy version 1.14 or later is required to compile GHC. Suggestions: 1) Make happy 1.14 available in its website 2) Change GHC building instructions in chapter 12 (saying that version 1.14 of Happy must be used and it can be built from the CVS sources). BTW, is there any problem using happy 1.14 compiled from source? Cheers, -- Andre

1 0

Subject: Generic compilation warnings...
by MR K P SCHUPKE 18 Feb '04

18 Feb '04

When deriving Data with all warnings enabled, for example compiling the following line: data TestType = TestType Int deriving (Typeable,Data) ghc 6.2 gives the following warnings: Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: GHC.Base.I# #x with #x `notElem` [1#] Is there a problem with the 'derived' code, or should this warning be ignored? regards, Keean Schupke.

1 0

RE: Problem with using BNF converter tool
by Simon Marlow 17 Feb '04

17 Feb '04

> I am sending this here and not to the bugs list under the > assumption that I am > doing something wrong... > > I am trying to use the BNF converter tool. When I try it on > simple examples, the > first step (generation of the .y and .x files) goes through. > When I run happy on > the generated .y file, I get the following error: > > happy.bin: internal error: stg_ap_pp_ret > Please report this as a bug to glasgow-haskell-bugs(a)haskell.org, > or http://www.sourceforge.net/projects/ghc/ > > Any help/guidance would be very appreciated. This should never happen. Details please: what version of GHC, did you compile Happy from source or download binaries, if source: which version, can you send us the complete .y input to Happy, and anything else that might be relevant. Basically anything we need to reproduce the bug here. Cheers, Simon

1 0

Problem with using BNF converter tool
by robin abraham 17 Feb '04

17 Feb '04

Hi all, I am sending this here and not to the bugs list under the assumption that I am doing something wrong... I am trying to use the BNF converter tool. When I try it on simple examples, the first step (generation of the .y and .x files) goes through. When I run happy on the generated .y file, I get the following error: happy.bin: internal error: stg_ap_pp_ret Please report this as a bug to glasgow-haskell-bugs(a)haskell.org, or http://www.sourceforge.net/projects/ghc/ Any help/guidance would be very appreciated. Thanks Robin.

2 1

Re: ghc-pkg 6.2 incorrectly parses commas within quotes
by Sven Panne 17 Feb '04

17 Feb '04

Ashley Yakeley wrote: > Any word on whether this has been/will be fixed? [...] Well, it's fixed in CVS for quite a while, but it's up to Simon^2 when a new GHC release comes out. > Personally I'd favour tossing this "feature" altogether, [...] Me too... :-P * * * Cheers, S.

1 0

RE: overlapping instances and modules
by Simon Peyton-Jones 12 Feb '04

12 Feb '04

I believe this is a buglet in the error message itself. If you compile one file at a time, you instead get: Overlapping instance declarations: In module Test: C (T m) In module Test: C (t m) The complaint here is reasonable: you need -fallow-overlapping-instances when compiling Test. (One could argue about whether -fallow-overlapping-instances should apply to the instance declarations themselves, or to the situation when GHC tries to decide which instance to use, but GHC currently takes the latter approach.) It's undoubtedly wrong for GHC to complain about *no* instances when there are actually *too many*. It turns out that I fixed this some time ago, as part of an overhaul of the overlap resolution machinery in the HEAD. (The above error message is improved too.) But since it's rather a corner case I doubt I'll fix 6.2. Meanwhile give the flag when compiling Test. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Iavor S. Diatchki | Sent: 13 January 2004 16:49 | To: Haskell Mailing List; glasgow-haskell-users(a)haskell.org | Subject: overlapping instances and modules | | hello, | i am a bit stuck on the following problem, | which seems to be GHC related. | consider the following two modules: | | > {-# OPTIONS -fglasgow-exts -fallow-overlapping-instances #-} | > module Test where | > | > data T m a = T (m a) | > | > class C m where get :: m a | > | > instance C (T m) | > instance C m => C (t m) | > | > obs :: T [] Int | > obs = get | | > module Test1 where | > | > import Test | > | > obs' :: T [] Int | > obs' = get | | i can load the first one (Test) without problems, | but when i load the second one (Test1) a get the error: | Test1.hs:6: | No instance for (C []) | arising from use of `get' at Test1.hs:6 | In the definition of `obs'': obs' = get | | this seems to indicate that the second instance is being used, | but i cannot figure out why. am i doing something silly here? | | -iavor | ps: i am not on the GHC users list so please cc me if you replay there | | | | | -- | ================================================== | | Iavor S. Diatchki, Ph.D. student | | | Department of Computer Science and Engineering | | | School of OGI at OHSU | | | http://www.cse.ogi.edu/~diatchki | | ================================================== | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: PreTraceHook, PostTraceHook and ErrorHdrHook hooks in RTS
by Simon Marlow 10 Feb '04

10 Feb '04

> My proposal is to replace the hooks: > > void PreTraceHook(long fd); > void PostTraceHook(long fd); > void ErrorHdrHook(long fd); > > with the general hooks: > > void TraceHook(char *msg) > { > fputs(msg, stderr); > } > > void ErrorHook(char *msg) > { > fprintf(stderr, "Fail: %s", msg); > } > > I am waiting forward to your comments and proposals. > If you accept the idea, I will be happy to implement > it. Let's take these seperately: (1) ErrorHdrHook: yes. Most of the contents of writeErrString__ (in libraries/base/cbits/writeError.c) can be replaced by a hook, which looks like a good idea. This affects the top-level exception handler for a program and the top-level exception handler for concurrent threads. Perhaps on Windows, for a program that is compiled with -mwindows(?) we should link in a version of ErrorHook that pops up a MessageBox instead of using stderr (and fix all the other places that the RTS relies on having stdout/stderr...). (2) TraceHook: I'm not so sure about this. In my opinion, it's fine for trace to be defined as outputing to stderr: trace s e = unsafePerformIO (hPutStr stderr s >> return e) but an application should use its own version of trace if needs be. (eg. in GHC we should use our own version of trace which might use the debug console on Windows). IMO we should get rid of PreTraceHook and PostTraceHook. The difference between this and the ErrorHook is that the programmer has the option to call a different trace, but the programmer has no control over what's used for the top-level exception handler in the program, so it makes sense to allow the use of a hook there. trace shouldn't be used by library code. Cheers, Simon

1 0

RE: GHCi and Unboxed tuples
by Simon Marlow 10 Feb '04

10 Feb '04

> I just finished tracking down the source of the following error from > GHCi: > > ghc-6.2: panic! (the `impossible' happened, GHC version 6.2): > Bytecode generator can't handle unboxed tuples. > Possibly due > to foreign import/export decls in source. Workaround: > compile this module to a .o file, then restart session. > > Some clue to the source of the problem would be quite helpful. (I > expect just about anything to at least be sometime useful -- even if > it's the low-level input to bytecode generator.) > > It turns out the source of the problem is a definition in an imported > .hi file. Would it be possible for GHCi to prune the inlined > definitions containing unboxed tuples and use the non-inlined ones? > (Are the non-inline definitions are in the object file? "nm" suggests > they are.) GHC shouldn't be using any unfoldings in bytecode mode, because optimisation should be off (this is one reason that optimisation is forced off for GHCi). So I'm a bit confused as to why this might be happening: of course, there are *lots* of unfoldings in .hi that use unboxed tuples, and mostly they don't cause any problem for GHCi. > The best fix, of course, would be to make the bytecode generator > handle unboxed tuples. Unfortunately we can't do this, due to the way that the bytecode evaluator works. We can handle specific instances of unboxed tuples, but handling them in general isn't possible because the return convention depends on the number and types of the components of the unboxed tuple, which would require us to generate some non-trivial machine code in the bytecode generator. Cheers, Simon

1 0

Fwd: PreTraceHook, PostTraceHook and ErrorHdrHook hooks in RTS
by Krasimir Angelov 10 Feb '04

10 Feb '04

Note: forwarded message attached. __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

1 0