February 2004 - Glasgow-haskell-users

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 16 Feb '04

16 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 16 Feb '04

16 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 09 Feb '04

09 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

GHCi and Unboxed tuples
by Mike Gunter 09 Feb '04

09 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.) The best fix, of course, would be to make the bytecode generator handle unboxed tuples. thanks, mike

1 0

Subject: RE: Generics...
by MR K P SCHUPKE 09 Feb '04

09 Feb '04

> the identity function will convert one to the other Okay. This I understand. I understand why the type of a generic transform has to be: gtrans :: Data a => a -> a and thinking about this has given me the solution. Obviously my data types are wrong... If a loose one type and create an angebraic type instead along the lines of: data SqlType a = TypedExpr String | SqlColumn String Then I can express the function I want generically. Where this leads to messy nested constructors, I can use constructor functions to neaten things up again. So... I need to think about the generic transforms I wish to implement before specifying the data types. This will probably lead to a better use of the types anyway. Regards, Keean Schupke.

1 0

vim syntax files for GHC-style .lhs, .hs + cpp
by dons＠cse.unsw.edu.au 08 Feb '04

08 Feb '04

Hey all, ------------------------------------------------------------- Vim syntax highlighting for GHC-style .lhs and .hs + cpp ------------------------------------------------------------- Rather than let this just sit on my hd, I'm making them available. ftp://ftp.cse.unsw.edu.au/pub/users/dons/vim/ These are vim syntax files for the tex-style (not the bird-feet style) literate Haskell used in much of GHC, and for normal Haskell with -cpp preprocessor sprinkles. The directories should go in your ~/.vim/ folder. There is also a preliminary outline of a vim indent file for .hs code. If you'd like to finish this off, then send me diff's please! The .lhs file still has a few minor buglets, so by making this stuff available I'm hoping someone has time to fix them. Cheers, Don

1 0