January 2004 - Glasgow-haskell-users

Compiling HOpenGL Examples with GHC 6.2 Mac OS
by HNBeck＠t-online.de 06 Jan '04

06 Jan '04

Hi, I'm a Haskell newbee and try to compile the HOpenGL Examples with GHC 6.2 Mac OS X with it's build in openGL stuff, by giving ghc --make Cube.hs the answer is :"not find module GLUT and GL", which is understandable because in the Cube.hs there is the code import GL import GLU But how to say ghc what he needs ? Is it -addpackage or -l option (in other words "import" is the same as include in C?) ? BTW: In the HOpenGL distribution, in the directory lib there is a file GL.hs and GLUT.hs which I think are the files needed for teh example above. But I don't found these files in the new GHC 6.2 distribution, is that correct ? Thanks for your help. Greetings Hans

1 0

RE: Running a "final" finaliser
by Simon Marlow 06 Jan '04

06 Jan '04

> The other thing that strikes me about this is don't we also have > the same potential problem with weak pointer finalisers? Can they > be supported in Haskell without pre-emptive concurrency? Weak pointers are a GHC-only extension too, at the moment. They require some careful GC algorithms as well as support for Haskell finalisers. GHC uses weak pointers to implement ForeignPtr internally. Cheers, Simon

1 0

threadDelay problem
by Adrian Hey 06 Jan '04

06 Jan '04

Hello, Whilst experimenting with concurrency and a library which expects me to use the usual event loop I wrote some test code like this.. main :: IO () main = do forkIO forked loop -- Main Loop loop :: IO () loop = do maybeEvent <- pollEvent -- non-blocking case maybeEvent of Just event -> do dispatch event loop Nothing -> do threadDelay 10000 -- 10000 uS = 10 mS loop -- Concurrent thread for test purposes forked :: IO () forked = do threadDelay 1000000 -- 1000000 uS (= 1 S) putStrLn "Hello" forked The idea is to stop a Haskell prog with no runable threads or events to process hogging CPU time. I was a bit dissapointed to find that despite this on my (otherwise idle) machine the above code was still using 96% of cpu time. But fiddling about a bit I found that by changing the thread delay in the main loop to 20 mS the CPU usage dropped to 1% or so, which is much more acceptable (well it did say 1/50 th second accuracy in the docs :-). So this all seems OK, but I wonder if this is a reliable solution on all platforms ghc is ported to (given the the consequence of getting this wrong can be a very greedy program). Is the 20 mS resolution figure a function of ghc only? Or might it depend on other factors too (like OS). Or might it change with ghc version? I think it would nice to have some reliable way to ensure that in reality the thread delay will be as small as possible, but always greater than zero. Maybe a threadDelayResolution constant could be provided? Also, assuming that currently the (hypothetical) threadDelayResolution is 20000 and that in reality the actual threadDelay is N*20000 where N is an integer, I think the docs for threadDelay should specify how N is calculated from the argument of threadDelay. At the moment chosing a thread delay of 19999 sends my CPU usage right back up to 96%, though whether that's as specified or merely a property of ghc 6.2 under Redhat 9 seems a little ambiguous :-) BTW, the docs for Control.Concurrent mention something about an -i<n> RTS option, but I can't find any info on this in the user guide. When I try it I get an error, listing all RTS options. There's no -i listed but there is something that looks related, a -C option, but this doesn't appear in the ghc user guide either :-( Regards -- Adrian Hey

1 0

RE: Running a "final" finaliser
by Simon Marlow 06 Jan '04

06 Jan '04

> The other complication I can see is that ForeignPtr finalisers can't > be Haskell. So I have to call the Haskell finalisation from C. > Is that safe? I'm afraid I still don't fully understand why Haskell > finalisers are unsafe or why (if) calling Haskell from a C finaliser > (which then called C land again) would be any safer. If you don't mind your code being non-portable, then Foreign.Concurrent provides Haskell finalisers. This support will be available only on Haskell implementations which implement pre-emptive concurrency (i.e. just GHC for now). Cheers, Simon

3 3

-xc giving very little information
by Stefan Reich 05 Jan '04

05 Jan '04

A complex program of mine fails with this message: Fail: Maybe.fromJust: Nothing I tried to extract more information about the error by compiling with -prof -auto-all and running the program with +RTS -xc, as advised on http://www.haskell.org/hawiki/TipsAndTricks . This yielded exactly one additional line: <Data.Maybe.CAF>. Fail: Maybe.fromJust: Nothing (Same result for GHC 6.0.1 and 6.2.) Is there another option I have to use to get a full stack trace? Or is my longing for stack traces a side-effect of writing too much Java code that I have to overcome? :) -Stefan

3 2

RE: GHC 6.2 breaks multiline string literals
by Simon Marlow 05 Jan '04

05 Jan '04

> This worked in GHC 6.0.1: > > multilineLiteral = " > line1 > line2" > > But doesn't work in GHC 6.2. Is this a bug or rather a bugfix? > > Anyway, I found it very convenient to embed verbatim string > blocks this > way. Is there maybe another way to achieve the same thing? Just to clarify, this is actually illegal syntax according to Haskell 98, so it is now disallowed. Use string gaps and explicit \n characters in string literals. Cheers, Simon

1 0

RE: -keep-hc-files with --make?
by Simon Marlow 05 Jan '04

05 Jan '04

> It seems that with GHC 6.2, -keep-hc-files and --make conflict: GHC > deletes the HC files it makes. I found an old bug report about this, > with a note from one of the developers claiming to have fixed > this, but > at least here the bug is reproduceable (a regression, perhaps?). > > This is on up-to-date Debian unstable. Looks like a bug; thanks for the report. It'll be fixed in the next release. Cheers, Simon

1 0

RE: -xc giving very little information
by Simon Marlow 05 Jan '04

05 Jan '04

> A complex program of mine fails with this message: > > Fail: Maybe.fromJust: Nothing > > I tried to extract more information about the error by compiling with > -prof -auto-all and running the program with +RTS -xc, as advised on > http://www.haskell.org/hawiki/TipsAndTricks . This yielded > exactly one > additional line: > > <Data.Maybe.CAF>. > Fail: Maybe.fromJust: Nothing > > (Same result for GHC 6.0.1 and 6.2.) That is rather unfortunate, but it's the "correct" behaviour. fromJust is defined like this: fromJust Nothing = error "Maybe.fromJust: Nothing" fromJust (Just a) = a and GHC has compiled it like this: _lift = error "Maybe.fromJust: Nothing" fromJust Nothing = _lift fromJust (Just a) = a so that it can inline fromJust without creating too much code explosion. Unfortunately, this means that _lift is a CAF, and all CAF evaluation appears at the top level in the cost-centre-stack semantics (see the section on profiling in the User's Guide for details). There's no obvious way to work around this, I'm afraid. Cheers, Simon

1 0

RE: classes and template haskell (bug?)
by Simon Peyton-Jones 05 Jan '04

05 Jan '04

Indeed, this is a bug. Well, two bugs actually. I've just fixed them. Thanks for the report. (You probably want to send TH-related mail to template-haskell(a)haskell.org, and other GHC bugs to Glasgow-haskell-bugs(a)haskell.org.) Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Jeremy Shaw | Sent: 02 January 2004 04:35 | To: glasgow-haskell-users(a)haskell.org | Subject: Re: classes and template haskell (bug?) | | Hello, | | No dice. Using cvs head from 12/31, I get the same behavior, (plus a | new bug). Using the same test as before (after updating the import | line): | | *Main> runQ [d| instance Test (a,b) |] >>= putStrLn . show | ghc-6.3: panic! (the `impossible' happened, GHC version 6.3): | Failed binder lookup: a{tv} {- tv a2jx -} | | Please report it as a compiler bug to glasgow-haskell-bugs(a)haskell.org, | or http://sourceforge.net/projects/ghc/. | | Also, a new bug has appeared (then again, it is cvs head) -- If I | start ghci, and then do this: | | Prelude> let n = 1 | Prelude> n | *** Exception: basicTypes/Var.lhs:226:32-58: Non-exhaustive patterns in record update | | Prelude> b | *** Exception: basicTypes/Var.lhs:226:32-58: Non-exhaustive patterns in record update | | Prelude> a | *** Exception: basicTypes/Var.lhs:226:32-58: Non-exhaustive patterns in record update | | Prelude> 3 + 4 | *** Exception: basicTypes/Var.lhs:226:32-58: Non-exhaustive patterns in record update | | | Or similarily: | | *Main> runQ [d| instance Test (Int,Int) |] >>= putStrLn . show | Loading package haskell98 ... linking ... done. | Loading package haskell-src ... linking ... done. | [InstanceD [] (AppT (ConT Main.Test) (AppT (AppT (TupleT 2) (ConT GHC.Base.Int)) (ConT | GHC.Base.Int))) []] | *Main> runQ [d| instance Test (a,b) |] >>= putStrLn . show | *** Exception: basicTypes/Var.lhs:226:32-58: Non-exhaustive patterns in record update | | Jeremy Shaw. | | | At Wed, 31 Dec 2003 08:11:47 -0000, | Simon Peyton-Jones wrote: | > | > In GHC 6.2, Template Haskell has various bugs. I think they are all | > fixed in the HEAD, so you can either build from source or grab a | > development snapshot from the GHC site. | > | > The HEAD version of TH has a slightly different programming interface | > too -- see | > http://research.microsoft.com/~simonpj/tmp/notes2.ps | > | > Simon | > | > | -----Original Message----- | > | From: glasgow-haskell-users-bounces(a)haskell.org | > [mailto:glasgow-haskell-users- | > | bounces(a)haskell.org] On Behalf Of Jeremy Shaw | > | Sent: 31 December 2003 02:19 | > | To: glasgow-haskell-users(a)haskell.org | > | Subject: classes and template haskell (bug?) | > | | > | Hello, | > | | > | I have loaded the following from a file into ghci 6.2: | > | | > | module Main where | > | | > | import Language.Haskell.THSyntax | > | | > | class Test a where | > | test :: a -> a | > | | > | instance Test (a,b,c) where | > | test x = x | > | | > | main = putStrLn "Hello, World!" | > | | > | This works for me: | > | | > | *Main> runQ [d| instance Test (Int,Int) |] >>= putStrLn . show | > | [InstanceD [] (AppT (ConT "Main:Test") (AppT (AppT (TupleT 2) (ConT | > "GHC.Base:Int")) (ConT | > | "GHC.Base:Int"))) []] | > | | > | But this doesn't: | > | | > | *Main> runQ [d| instance Test (a,b) |] >>= putStrLn . show | > | ghc-6.2: panic! (the `impossible' happened, GHC version 6.2): | > | Failed binder lookup: a {- tv a20x -} | > | | > | Please report it as a compiler bug to | > glasgow-haskell-bugs(a)haskell.org, | > | or http://sourceforge.net/projects/ghc/. | > | | > | | > | Am I doing something wrong, or is this a bug? | > | | > | Thanks! | > | Jeremy Shaw. | > | _______________________________________________ | > | Glasgow-haskell-users mailing list | > | Glasgow-haskell-users(a)haskell.org | > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: classes and template haskell (bug?)
by Simon Peyton-Jones 02 Jan '04

02 Jan '04

In GHC 6.2, Template Haskell has various bugs. I think they are all fixed in the HEAD, so you can either build from source or grab a development snapshot from the GHC site. The HEAD version of TH has a slightly different programming interface too -- see http://research.microsoft.com/~simonpj/tmp/notes2.ps Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Jeremy Shaw | Sent: 31 December 2003 02:19 | To: glasgow-haskell-users(a)haskell.org | Subject: classes and template haskell (bug?) | | Hello, | | I have loaded the following from a file into ghci 6.2: | | module Main where | | import Language.Haskell.THSyntax | | class Test a where | test :: a -> a | | instance Test (a,b,c) where | test x = x | | main = putStrLn "Hello, World!" | | This works for me: | | *Main> runQ [d| instance Test (Int,Int) |] >>= putStrLn . show | [InstanceD [] (AppT (ConT "Main:Test") (AppT (AppT (TupleT 2) (ConT "GHC.Base:Int")) (ConT | "GHC.Base:Int"))) []] | | But this doesn't: | | *Main> runQ [d| instance Test (a,b) |] >>= putStrLn . show | ghc-6.2: panic! (the `impossible' happened, GHC version 6.2): | Failed binder lookup: a {- tv a20x -} | | Please report it as a compiler bug to glasgow-haskell-bugs(a)haskell.org, | or http://sourceforge.net/projects/ghc/. | | | Am I doing something wrong, or is this a bug? | | Thanks! | Jeremy Shaw. | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

3 3