- Glasgow-haskell-users

My program is crashing - help!
by Marcin 'Qrczak' Kowalczyk 02 Jan '01

02 Jan '01

I don't know if this is a bug in my code, in ghc, or in the python interpreter. I could not find it for a long time. Would somebody please help me? In <http://qrczak.ids.net.pl/HsPython-bug.tar.gz> there is a simplest fragment I could ake which exposes the bug. It requires ghc-4.11 and python-2.0. It should be tweakable for older versions of both: - For older ghc versions, either replace Ptr/FunPtr with Addr and ForeignPtr with ForeignObj, or use QForeign instead of Foreign. In any case you must install hsc2hs from ghc >= 4.09 or QForeign. QForeign is at <http://download.sourceforge.net/qforeign/qforeign-0.63.tar.gz>. - For older Python versions, fix paths in the Makefile. The program should do an equivalent of main = putStr (repeat '9') but in a very indirect way, calling Python which calls back Haskell for each digit. On my machine it crashes after several lines of output (inside malloc). It is very sensitive to small changes. When compiled with -O, it works fine. When the PyObject module is merged with Main, it works fine. When nullFunPtr is passed in Main.hsFunctionNew instead of freeMethodDefPtr, it still crashes, but if nullFunPtr is replaced with 0 and the corresponding type in a foreign import is changed to Int, it works fine (well, this applied to a version before removing unnecessary junk, now it may be different). When freeMethodDef is written in C and foreign imported instead of being written in Haskell and foreign exported, it works fine. Et caetera. I tried to run it under ghc-4.08.1 and python-1.5 (after necessary tweaking), but it's very different: it crashes very soon and ltrace shows that a message about passing a non-tuple as arguments is strcpy'ed just before the crash. Perhaps the crash is expected, since I don't catch Python exceptions in the simplified version, but the message is not: I am passing the result of PyTuple_New(0) (after wrapping in a ForeignPtr). Anyway, it is very sensitive to small changes of compilers or the source itself. Maybe I am using the Python interface in a wrong way, or I am doing some stupid mistake, or there is a bug in ghc - I really don't know what is going on. Help! -- Marcin 'Qrczak' Kowalczyk

3 2

RE: Realtime-GC
by Simon Peyton-Jones 02 Jan '01

02 Jan '01

Yes -- Andy Cheadle and Tony Field (whose paper is in ICFP00) are planning to bring their incremental GC fully into GHC, so it'll become part of the distribution. I think Andy will be delighted to have a Real Customer! So far, GC is sufficiently unobtrusive that no one notices, so it'll be fun to have someone who does. Are there any other GHC users who notice GC pauses? Simon | -----Original Message----- | From: Sven Panne [mailto:Sven.Panne@informatik.uni-muenchen.de] | Sent: 30 December 2000 22:09 | To: GHC Users | Cc: Armin Sander | Subject: Realtime-GC | | | IIRC there was some activity in the realtime GC area | for GHC (something like experimental support for 4.0x, | but I can't remember exactly). Any progress yet? It | would be quite cool to fly through Quake levels without | those small hiccups. And I'm quite sure there are more | serious applications which would profit from that, too... :-) | | Cheers, | Sven | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

2 1

Realtime-GC
by Sven Panne 30 Dec '00

30 Dec '00

IIRC there was some activity in the realtime GC area for GHC (something like experimental support for 4.0x, but I can't remember exactly). Any progress yet? It would be quite cool to fly through Quake levels without those small hiccups. And I'm quite sure there are more serious applications which would profit from that, too... :-) Cheers, Sven

1 0

RE: Generic Classes?
by Simon Peyton-Jones 30 Dec '00

30 Dec '00

No, not in 4.08.2. They'll be in our first release of GHCi. I'm not sure when that will be; Feb I expect. Simon | -----Original Message----- | From: George Russell [mailto:ger@tzi.de] | Sent: 21 December 2000 16:54 | To: glasgow-haskell-users(a)haskell.org | Subject: Generic Classes? | | | Are Generic classes going to be in 4.08.2, and if not when | are they likely | to be in a binary release? I have a potential application, though | I can manage without them for the time being. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

2 1

RE: Transitive inlining
by Simon Peyton-Jones 30 Dec '00

30 Dec '00

Yes, all the inlining you expect should indeed happen. If it doesn't can you show us an example? Simon | -----Original Message----- | From: Manuel M. T. Chakravarty [mailto:chak@cse.unsw.edu.au] | Sent: 11 December 2000 13:41 | To: glasgow-haskell-users(a)haskell.org | Cc: keller(a)it.uts.edu.au | Subject: Transitive inlining | | | In the context of the array library, we stumbled over | another problem. Does GHC transitive inlining across | modules? Let's say, we have the following scenario: | | module B (foo) where | | {-# INLINE foo #-} | foo .. = ...bar... | | {-# INLINE bar #-} | bar .. = ... | | | module L (baz) where | | import B | | {#- INLINE baz #-} | baz .. = ...B.foo... | | | module Main where | | import L | | main .. = ...L.baz... | | GHC in this case inlines the whole expression "...B.foo..." | in `Main', but will it inline the right hand side of `B.bar' | in `Main' (or even of `B.foo')? If the INLINE pragma is | transitive across modules boundaries, one would hope so. | | It seems that GHC is not (always?) doing this inlining, | which already for a very simple benchmark costs us a factor | of 5 runtime! (With inlining - enforced by copying | definitions manually into `Main' - the code produced by GHC | is actually a little bit faster than the code for the | corresponding C program). | | Cheers, | Manuel | | PS: I had problems building GHCi and it seems as if my | message to cvs-ghc(a)haskell.org doesn't get through | somehow... | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

2 3

RULES and unfolding
by Manuel M. T. Chakravarty 30 Dec '00

30 Dec '00

Is there any heuristic in GHC that discourages putting unfoldings of functions into .hi files if the function occurs on the right handside of a RULES rule? I have code, where this seems to be the case. When I remove the rewrite rule, the function is placed into the .hi file, but with the rewrite rule, it isn't - despite an INLINE pragma for that function! Unfortunately, the example is rather big and I didn't manage to find a small piece of code showing the same behaviour yet. This currently bites me in a rule of the form {-# "" forall ... foo .. bar .. = foobar .. #-} {-# INLINE foobar #-} foobar .. = ... where I want foobar inlined. Cheers, Manuel PS: I do this only because GHC crashes when I place the rhs of the foobar definition directly into the rhs of the rule, but again I don't have a small example producing the bug *sigh*

1 0

Lambda dropping in loops
by Manuel M. T. Chakravarty 30 Dec '00

30 Dec '00

Given a function like fill 0# mpa = return () fill i# mpa = do let i'# = i# -# 1# writeMP mpa (I# i'#) e fill i'# mpa it would be nice if GHC were to lambda drop it (on the core level) into fill i# mpa = fill' i# where fill' 0# = return () fill' i# = do let i'# = i# -# 1# writeMP mpa (I# i'#) e fill' i'# as this allows it to subsequently apply the new case liberation optimisation. By performing the lambda dropping manually, I have gotten much better code in some performance sensitive definitions. Cheers, Manuel

1 0

RE: Fun with GHC's optimiser
by Simon Peyton-Jones 22 Dec '00

22 Dec '00

Manuel | I have found a way of rephrasing the definition so that it | is properly optimised by GHC. However, I think, it should | be possible to do this automatically and it is maybe not | unlike the optimisation done by simplCore/LiberateCase. I agree with your example. But I think the way to handle it is this. Suppose we have f x y = ....(f ex (C a b))... where C is a constructor, and where y is scrutinised by a case expression somewhere in f's body. Then, in this recursive call to f, we know what y will be, and we could save the case in the recursive call. So make a specialised version of f, thus: fs x a b = let y = C a b in (...original body of f...) Now add a RULE to f, saying f x (C a b) ===> fs x a b This is very much the way type specialisation works. Now every call to f that has a (C a b) argument will benefit. Including the recursive call to f in fs's RHS, so fs will become the self-recursive tight loop you want, leaving f as a sort of 'impedence matcher' for callers elsewhere. I'll try to find time to implement this. Simon

2 1

Generic Classes?
by George Russell 21 Dec '00

21 Dec '00

Are Generic classes going to be in 4.08.2, and if not when are they likely to be in a binary release? I have a potential application, though I can manage without them for the time being.

1 0

Re: GHC Command Line Help
by George Russell 21 Dec '00

21 Dec '00

"Steinitz, Dominic J" wrote: > > I was experimenting with using FiniteMap. The program compiled ok but the linker gave me the following error. What do I need to include on the command line or have I not installed ghc correctly? > > [dom@lhrtba8fd85 FiniteMap]$ /usr/bin/ghc -o main test.o -L/usr/lib/ghc-4.08.1 - > lHSlang -lHSdata > /usr/lib/ghc-4.08.1/libHSdata.a(FiniteMap__1.o): In function `__init_FiniteMap': > FiniteMap__1.o(.text+0x16): undefined reference to `__init_GlaExts' > collect2: ld returned 1 exit status I suggest using /usr/bin/ghc -o main test.o -package data -package lang -fglasgow-exts or something similar (rather than trying to name the libraries directly).

1 0