headers
Adrian Hey | 1 Jan 2004 12:39

Re: Running a "final" finaliser

On Wednesday 31 Dec 2003 10:05 am, Adrian Hey wrote:
> On Wednesday 31 Dec 2003 8:56 am, Adrian Hey wrote:
> > Intended use is something like this...
> >
> > {-# notInline libXYZRef #-}
> > libXYZRef :: LibRef
> > libXYZRef = unsafePerformIO newLibRef
> >
> > main :: IO ()
> > main = finally (initLibXYZ >> userMain) (killLibRef libXYZRef
> >  shutDownLibXYZ)
> > -- initLibXYZ and shutDownLibXYZ are Haskell bindings to functions
> > supplied -- by libXYZ
>
> Actually, using..
>  main = finally (initLibXYZ >> userMain)
>                 (performGC >> killLibRef libXYZRef shutDownLibXYZ)
>
> seems to fix the problem, which isn't too surprising I guess.
> But then again, if this is a reliable solution there's no need
> for LibRef after all :-)

Hmm, further experiments with creating zillions of garbage
ForeignPtrs (not just 1) reveals that the problem only occurs
if *no* garbage collection has occured before the program shuts
down. In other words, as long as at least one garbage collection
has occured, it doesn't matter if library shutdown occurs immediately
in response to killLibRef or if it's deferred until the reference
count hits zero as a result of finalisers being called. (This test
is without the explicit performGC of course.)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeremy Shaw | 2 Jan 2004 05:35

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 <at> 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:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sven Panne | 2 Jan 2004 12:20
Picon

Re: classes and template haskell (bug?)

Jeremy Shaw wrote:
> I attempted to build cvs head but it died with the following error:
> 
> /usr/bin/ghc6 -H16m -O  -istage1/utils  -istage1/basicTypes  -istage1/types  -istage1/hsSyn 
-istage1/prelude  -istage1/rename  -istage1/typecheck  -istage1/deSugar  -istage1/coreSyn 
-istage1/specialise  -istage1/simplCore  -istage1/stranal  -istage1/stgSyn  -istage1/simplStg 
-istage1/codeGen  -istage1/absCSyn  -istage1/main  -istage1/profiling  -istage1/parser 
-istage1/cprAnalysis  -istage1/compMan  -istage1/ndpFlatten  -istage1/cbits  -istage1/iface 
-istage1/nativeGen -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package
concurrent -package posix -package util -recomp -Rghc-timing  -H16M '-#include "hschooks.h"' 
-fno-warn-incomplete-patterns -fvia-C -Onot -fno-ignore-interface-pragmas  -c parser/Parser.hs
-o stage1/parser/Parser.o  -ohi stage1/parser/Parser.hi
> 
> parser/Parser.hs:1878: Variable not in scope: `$>'
> [...]

You need a rather recent version of Happy from CVS to compile the HEAD.

Cheers,
    S.
Permalink | Reply | 0 comments |
headers
Simon Peyton-Jones | 5 Jan 2004 11:41
Picon
Favicon
Gravatar

RE: classes and template haskell (bug?)

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 <at> haskell.org, and other GHC bugs to
Glasgow-haskell-bugs <at> haskell.org.)

Simon

| -----Original Message-----
| From: glasgow-haskell-users-bounces <at> haskell.org
[mailto:glasgow-haskell-users-
| bounces <at> haskell.org] On Behalf Of Jeremy Shaw
| Sent: 02 January 2004 04:35
| To: glasgow-haskell-users <at> 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 <at> haskell.org,
| or http://sourceforge.net/projects/ghc/.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Malcolm Wallace | 5 Jan 2004 12:35
Picon

Re: -xc giving very little information

Stefan Reich <doc <at> drjava.de> writes:

> 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:

This looks like the perfect situation in which to use program tracing
through Hat.  It will give you stack back-traces and much much more.

    http://haskell.org/hat/

Unfortunately, Hat is currently limited to ghc version 5.04.3 (i.e. not
yet updated to cope with the 6.x series), but perhaps your program
is written in sufficiently standard Haskell for this to be no problem?
(Hat also works with nhc98.)

Regards,
    Malcolm
Permalink | Reply | 2 comments |
headers
Simon Marlow | 5 Jan 2004 14:28
Picon
Favicon

RE: -xc giving very little information


> 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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Marlow | 5 Jan 2004 14:46
Picon
Favicon

RE: -keep-hc-files with --make?


> 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
Permalink | Reply | 0 comments |
headers
Simon Marlow | 5 Jan 2004 14:48
Picon
Favicon

RE: GHC 6.2 breaks multiline string literals


> 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
Permalink | Reply | 0 comments |
headers
Simon Marlow | 5 Jan 2004 16:14
Picon
Favicon

RE: Running a "final" finaliser

> 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
Permalink | Reply | 3 comments |
headers
Ian Lynagh | 5 Jan 2004 16:33
Picon
Gravatar

Re: -xc giving very little information

On Mon, Jan 05, 2004 at 11:35:37AM +0000, Malcolm Wallace wrote:
> 
> Unfortunately, Hat is currently limited to ghc version 5.04.3 (i.e. not
> yet updated to cope with the 6.x series),

The Debian package works with ghc6.2 (at least the Insort example works
for me - I haven't done more with it than that), although some things
probably haven't been fixed up in the nicest possible way. You can get
the diff at:

http://ftp.debian.org/debian/pool/main/h/hat/hat_2.02-6.diff.gz

Thanks
Ian
Permalink | Reply | 1 comment |

Gmane