October 2002 - Glasgow-haskell-users

RE: crash in profiling mode
by Simon Marlow 30 Oct '02

30 Oct '02

> I have a problem with profiling using a freshly installed GHC > 5.04 under Solaris. With the following program crash.lhs: Please install 5.04.1 instead, I believe this bug was fixed. Cheers, Simon

2 1

FFI & C++
by Niklas Sörensson 29 Oct '02

29 Oct '02

Hi, I am currently trying to create a Haskell interface to a C++ library and cannot get it to work completely. The problem seems to be that the linker must be able to find the code for basic C++ constructs like new and throw. Apparently it is able to do so when compiling an executable, but when I try to do the same with ghci it fails. Anybody have an idea why this happens and what to do about it? A second question, The feature to install local packages is currently a bit awkward. I would like to be able to simply use a local package the same way I use a normal package, and my first try was to set the package-conf file in my .ghci file. But this doesn't work very well for two reasons: (1) it only works for the interpreter, but not for the compiler (2) it isn't read until *after* the command line is read, so any packages given there is not recognized. Is it possible to have a common (.ghc) file that is used for both the compiler and the interpreter, and that is read *before* the command line is interpreted? /Niklas

2 1

problem generating Core with no-implicit-prelude
by Hal Daume III 29 Oct '02

29 Oct '02

Hi all, I think there's a problem with the external core generation. Suppose we have the following module: ----- module Test where data Bool = True | False data Maybe a = Just a | Nothing class Eq a where (==) :: a -> a -> Bool instance Eq Bool where (==) True True = True (==) False False = True (==) _ _ = False instance Eq a => Eq (Maybe a) where (==) Nothing Nothing = True (==) (Just a) (Just b) = (==) a b (==) _ _ = False ----- We compile this using: ghc -fext-core -fno-code test.hs -fno-implicit-prelude Now, if we look at the core, inside the definition of Test.zdfEqMaybe (the eq function for Maybe a), it essentially looks like (glossing over some of the extraneous stuff): Test.zdfEqMaybe = \ zddEq -> Test.ZCDEq \ ds ds1 -> case ds of Nothing -> case ds1 of Test.Just a1 -> Test.zdwFalse Test.Nothing -> Test.zdwTrue Just a1 -> case ds1 of Test.Nothing -> Test.zdwFalse Test.Just b -> Test.zeze zddEq a1 b Now, the problem is that "Test.ZCDEq" isn't defined anywhere in the core file produced and neither is Test.zeze. If this is indeed a bug, could someone fix it? If not, could someone tell me what I'm doing wrong (I could be misreading the Core, but I don't think so). - Hal p.s., the full core output reads: %module Test %data Test.Bool = {Test.True; Test.False}; %data Test.Maybe a = {Test.Just a; Test.Nothing}; %newtype Test.ZCTEq a = GHCziPrim.ZLzmzgZR a (GHCziPrim.ZLzmzgZR a Test.Bool); Test.zdfEqBool :: GHCziPrim.ZLzmzgZR Test.Bool (GHCziPrim.ZLzmzgZR Test.Bool Test.Bool) = \ (ds::Test.Bool) (ds1::Test.Bool) -> %case ds %of (wild::Test.Bool) {Test.False -> %case ds1 %of (wild1::Test.Bool) {Test.True -> Test.zdwFalse; Test.False -> Test.zdwTrue}; Test.True -> ds1}; Test.zdfEqMaybe :: %forall a . GHCziPrim.ZLzmzgZR (GHCziPrim.ZLzmzgZR a (GHCziPrim.ZLzmzgZR a Test.Bool)) (GHCziPrim.ZLzmzgZR (Test.Maybe a) (GHCziPrim.ZLzmzgZR (Test.Maybe a) Test.Bool)) = %note "InlineMe" \ @ a (zddEq::GHCziPrim.ZLzmzgZR a (GHCziPrim.ZLzmzgZR a Test.Bool)) -> Test.ZCDEq @ (Test.Maybe a) (\ (ds::Test.Maybe a) (ds1::Test.Maybe a) -> %case ds %of (wild::Test.Maybe a) {Test.Nothing -> %case ds1 %of (wild1::Test.Maybe a) {Test.Just (a1::a) -> Test.zdwFalse; Test.Nothing -> Test.zdwTrue}; Test.Just (a1::a) -> %case ds1 %of (wild1::Test.Maybe a) {Test.Nothing -> Test.zdwFalse; Test.Just (b::a) -> Test.zeze @ a zddEq a1 b}}); -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

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