- Glasgow-haskell-users

crash in profiling mode
by Janis Voigtlaender 29 Oct '02

29 Oct '02

Hello, I have a problem with profiling using a freshly installed GHC 5.04 under Solaris. With the following program crash.lhs: > module Main where > test1 = print "test1" > test2 = {-# SCC "test2" #-} print "test2" > main = do c <- readLn > if c==1 then test1 else test2 I get the following runs: ~> ghc-5.04 -prof crash.lhs ~> ./a.out 1 "test1" ~> ./a.out 2 Bus error Exit 138 So, code compiled with a cost-center annotation crashes (note that I didn't even run the compiled program in profiling mode). The same happens, when compiler flags -auto or -auto-all are used. Hence, the profiling facilities are useless on my installation. Has anyone experienced such problem before? What could be broken with my installation? Some library problems? Any hint appreciated. Regards, Janis. -- Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de

1 0

RE: Optimisation and unsafePerformIO
by Simon Marlow 28 Oct '02

28 Oct '02

> Consider the following program: > > --------------------------------- > {-# NOINLINE b #-} > > b x = if even x then unsafePerformIO getChar else bot > > bot = bot > > main = do > putChar (b 4) > putChar (b 6) > > ----------------------------- > > when you compile the programm with the options: -O0 > and execute the program you get: > > test > ab (That's the input) > ab (That's the ouput) > > when you compile the programm with the options: -O1 -fno-cse > you get: > > test > ab > aa You are using unsafePerformIO in an unsafe way. The meaning of your program depends on whether the compiler implements full laziness or not, which is a decision left entirely up to the compiler implementor. If you want to write portable code, don't use unsafePerformIO in this way. What exactly is it you're trying to achieve? Perhaps we can suggest a better solution. Cheers, Simon

2 1

Optimisation and unsafePerformIO
by David Sabel 27 Oct '02

27 Oct '02

Consider the following program: --------------------------------- {-# NOINLINE b #-} b x = if even x then unsafePerformIO getChar else bot bot = bot main = do putChar (b 4) putChar (b 6) ----------------------------- when you compile the programm with the options: -O0 and execute the program you get: > test ab (That's the input) ab (That's the ouput) when you compile the programm with the options: -O1 -fno-cse you get: > test ab aa my question is now: which transformation/optimisation is responsible for that, and is it possible to switch off this transformation? David Sabel

1 0

Re: standalone core parser
by Kirsten Chevalier 25 Oct '02

25 Oct '02

> What about the Core interpreter in fptools/ghc/utils/ext-core ? > > There's a Happy parser source file there, Parser.y, as well as > all sorts of other Core-related goodies. FYI, one can use the parser and printer in fptools/ghc/utils/ext-core as is, but the typechecker and interpreter need updating in order to work with Core emitted by the latest version of GHC (the changes should be pretty minor, but I haven't tried to make them). -- Kirsten Chevalier * krc(a)uclink.berkeley.edu * Often in error, never in doubt

1 0

RE: dreaded non-modular instances; ghci bug, Either, and haddock
by Simon Peyton-Jones 25 Oct '02

25 Oct '02

| Duplicate instance declarations: | ../tools/base/lib/Monads/ExceptM.hs:26: Functor (Either x) | <No locn>: Functor (Either e) Yes, this is bad. The HEAD reports the module which defined the instance: Inst.hs:3: Duplicate instance declarations: Inst.hs:3: Eq [a] In module GHC.Base: Eq [a] I don't think this has made it into the 5.04 branch, though. | ghci doesn't seem to clean up instances when switching between modules? Yes, I think that is right too. It should. Simon

1 0

dreaded non-modular instances; ghci bug, Either, and haddock
by Claus Reinke 25 Oct '02

25 Oct '02

instances are the pride and joy of Haskell's module system.. 1) instance documentation Once introduced, instances propagate more or less everywhere, but I'm having trouble identifying the source modules for surprising instances with ghc, where I don't have the sources of the libraries, only .hi files and haddock-generated documentation.. Here's an example error message from trying to link together two pieces of Haskell software, both working fine on their own (using ghc-5.04 on cygwin): Duplicate instance declarations: ../tools/base/lib/Monads/ExceptM.hs:26: Functor (Either x) <No locn>: Functor (Either e) Duplicate instance declarations: ../tools/base/lib/Monads/ExceptM.hs:29: Monad (Either x) <No locn>: Monad (Either e) Now, how am I supposed to find out where those other instances come from? Obviously, the error message could be better, but let's just assume I'd be interested in the question independent of any error messages: where do instances come from? The way haddock groups that information in the ghc docs is not very helpful in this case: looking at the Prelude doc, I see that, yes, Either is an instance of Functor and Monad (huh, in the Haskell Prelude? I don't think so..), but not where those unexpected instances are defined.. Fortunately, ghc-5.02.3 on sunos is more informative in its error message (is that a sunos/windows difference, or did the info get lost between ghc-5.02.3 and ghc-5.04?) and suggests that the other instance might come from MonadError (btw, why?). Even armed with that suggestion, I don't know an easy way to verify this, though: the docs don't mention a Functor instance for Either in Control.Monad.Error, they do in Control.Monad.. The .hi files don't seem to give me a hint, either.. Am I missing a trick? Or is the documentation of instances incomplete? 2) ghci instance handling One way (the good old primitive way) is to test. ghci seems to confirm that the Functor instance comes from MonadError, not from Monad, not from Prelude, but.. ghci doesn't seem to clean up instances when switching between modules? $ ghci -package lang ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.04, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Loading package lang ... linking ... done. Prelude> Prelude> fmap not (Right True::Either Bool Bool) <interactive>:1: No instance for (Functor (Either Bool)) arising from use of `fmap' at <interactive>:1 In the definition of `it': fmap not (Right True :: Either Bool Bool) Prelude> :m Control.Monad Prelude Control.Monad> fmap not (Right True::Either Bool Bool) <interactive>:1: No instance for (Functor (Either Bool)) arising from use of `fmap' at <interactive>:1 In the definition of `it': fmap not (Right True :: Either Bool Bool) Prelude> :m MonadError Prelude MonadError> fmap not (Right True::Either Bool Bool) Right False Prelude MonadError> :m Prelude Prelude> fmap not (Right True::Either Bool Bool) Right False Prelude> fmap not (Left True::Either Bool Bool) Left True Prelude> Cheers, Claus PS. user's guide, ghci section, has %lt; instead of < (<)

1 0

RE: Debugging Haskell: the stack
by Simon Marlow 25 Oct '02

25 Oct '02

> when I call from Haskell into C, stop it there, and use a > debugger (e.g > gdb) to look at the stack, it looks all broken. Here is an example: > > #0 c_init () at c.c:5 > #1 0x08048f14 in ssM_fast1 () > #2 0x0804a248 in sakt_ret () > #3 0x04c58308 in ?? () > > (c_init is a C function on which I've set a breakpoint). Now, I don't > expect to see meaningful stack frames from Haskell, but I am calling > into Haskell from C, and I would expect the C functions calling into > Haskell to appear on the stack frame. What is happening? How does > Haskell manage to still return to C when the stack looks like that? GHC's runtime system leaves a hole on the C stack to use for temporary storage while running Haskell code, and then it doesn't move the C stack pointer at all until calling out to C or returning to the runtime. Gdb won't be able to traverse the hole to find the enclosing stack frames. Cheers, Simon

1 0

Debugging Haskell: the stack
by Christoph Lueth 25 Oct '02

25 Oct '02

Dear Haskell people, when I call from Haskell into C, stop it there, and use a debugger (e.g gdb) to look at the stack, it looks all broken. Here is an example: #0 c_init () at c.c:5 #1 0x08048f14 in ssM_fast1 () #2 0x0804a248 in sakt_ret () #3 0x04c58308 in ?? () (c_init is a C function on which I've set a breakpoint). Now, I don't expect to see meaningful stack frames from Haskell, but I am calling into Haskell from C, and I would expect the C functions calling into Haskell to appear on the stack frame. What is happening? How does Haskell manage to still return to C when the stack looks like that? Best regards, --C.

1 0

RE: 5.04.2 schedule?
by Simon Marlow 25 Oct '02

25 Oct '02

> > We're wondering here whether we should push out 5.04.2 > soon, or wait a > > while and see what other bugs turn up. > > > > Opinions, anyone? > > Release often, release soon! Why not put out a source distribution > on a regular basis, say, every month or so (I realize that binary > distributions are a lot of work). I'm a big fan of "release early, release often" too, but we have to balance that against stability and putting out releases that people can actually use. In the past we used to have a distinction between source and binary releases, but it didn't work too well: people used to make packages of the source releases, blurring the distinction, and in any case binary packages always pop out of the end of the nightly build, so building them isn't any extra hassle. Other packages, RPMs and so on are built by others. What really takes time is all the things that have to be done for a release: testing, updating bits with the new version number, updating web pages, uploading documentation, and so on. It takes about a day of my time to do a release, more if it's a major release (because then we have to do release notes). So I think the current situation is a good compromise: those who want the bleeding edge can get CVS and watch cvs-ghc(a)haskell.org so they can see when the compiler is stable, and we put out stable releases every couple of months or so. Cheers, Simon

3 2

RE: EVACUATED object entered! (when doing FFI)
by Simon Marlow 25 Oct '02

25 Oct '02

> Good morning again, > > Thank you for answering. > > I am using ghc 5.04.1 I compiled myself on a linux box > (Mandrake 8.2) . > > I'm sending you the source code. Compiled it with the > following commands : > > ghc -ffi -c GetFNamesBckp.hs -o GetFNamesBckp.o > > gcc -I/opt/installed/ghc-5.04.1/lib/ghc-5.04.1/include -c > cGetFNamesBckp.c -o > cGetFNamesBckp.o > > ghc -no-hs-main GetFNamesBckp_stub.o GetFNamesBckp.o cGetFNamesBckp.o Good bug! In fact, it has nothing to do with the FFI, but it is a bug in the garbage collector introduced in 5.04.1. The fix will be in 5.04.2. BTW, an easier way to compile your program is ghc -ffi -no-hs-main cGetFNamesBckp.c GetFNamesBckp.hs Cheers, Simon

1 0