- Glasgow-haskell-users

RE: problem generating Core with no-implicit-prelude
by Simon Peyton-Jones 31 Oct '02

31 Oct '02

It is a bug... we weren't printing enough in -fext-core. I think it's fixed now. (I'm away till Monday.) Simon | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: 29 October 2002 17:57 | To: GHC Users Mailing List | Subject: problem generating Core with no-implicit-prelude | | 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 | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Concurrency and interactive input
by Walker Duhon 31 Oct '02

31 Oct '02

Hello, I am playing around with concurrency using ghc 5.02.2. What I'd like to do is have a bunch of threads do something indefinitely, while one thread monitors stdin for user input (the user input affects the behavior of the other threads in some way). From the documentation I had assumed that standard Haskell I/O functions (like getline) would not block other running threads, but this doesn't seem to be the case as illustrated here: conTry3 = forkIO (loop 'a') >> quitYet where loop ch = hPutChar stdout ch >> loop ch quitYet = do x <- getLine if x == "quit" then return () else quitYet Output: (stuff in between {} is a comment, and not part of the output) rere ttt fff dfsd fgfg fgfg aaaaaaaaaaaaaaaaaa { and on and on } dfdf dfd fdfd fgfg fgf aaaaaaaaaaaaaaaa { and on and on } quit aaaaaaa { and on and on } {program ends} The behavior I wanted was for 'a' to be printed (almost) continuously, echo the relatively infrequent input, and quit upon receiving "quit". I am aware (through a web search) that there was a mail thread addressing a similar issue a while back (1999) entitled: I thought concurrent haskell was _preemptive_! That thread made it seem like the issue would be cleared up soon. In any case, I would still like to be able to have an interactive input thread that doesn't block everything in my program. Is there any way to do this? Thanks in advance, Walker

2 1

RE: FFI & C++
by Seth Kurtzberg 30 Oct '02

30 Oct '02

What is the O/S and compiler? That the C++ new operator is not found is very strange. Throw is another story, as throw doesn't appear in the compiled code with some compilers. On Wed, 2002-10-30 at 04:18, Simon Marlow wrote: > > 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? > > I don't know the gory details, but it might be that we would have to link GHCi with the C++ linker for this to work. Would anyone with a clue about C++ linking like to comment? > > > 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? > > Hmm, I must admit I'm a bit averse to adding features like this unless they are really necessary. One problem is that when someone submits a bug report, we'll have to start asking "do you have a .ghc file? what does it contain?". The current situation has the advantage of being simple. > > Can't you just alias ghc to 'ghc -package-conf ...'? > > Cheers, > Simon > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Seth Kurtzberg M. I. S. Corp 480-661-1849 Pager 888-605-9296, or 6059296(a)skytel.com

3 3

RE: compiling big files?
by Simon Marlow 30 Oct '02

30 Oct '02

> I have occasional problems getting ghc-5.04.1 to compile a very large > source file with -O switched on. The source file is generated by > another tool, and is rather large at 25762 lines (2776340 bytes). > > Without -O, the compilation goes normally, taking about 10 > minutes or so. > > With -O, the compiler uses >280Mb of memory, which causes my machine > with only 256Mb to swap like crazy, but that is OK, because > after about > half an hour, ghc produces its output in a .hc file. The C compiler > (gcc-2.95.3) then produces a .raw_s file: > > $ wc /tmp/ghc* > 759338 837040 18321347 /tmp/ghc3992.hc > 1711905 3174489 32014101 /tmp/ghc3992.raw_s eek! :-S > It's the next stage, when (I presume) the ghc-mangler converts the > .raw_s file to a simpler .s file, that doesn't run to completion. > It simply reports > > Killed > make: *** [targets/ix86-Linux/hat-lib-ghc] Error 2 > > It seems that if I re-run ghc on the intermediate .hc file that > was left behind in the /tmp directory, then the mangler is ok, > and assembly proceeds right up to the .o file. > > So is there any (fixable) reason why the one-step invocation fails, > but the two-step invocation succeeds? I have no idea what might cause this. If you put the .hc up for download somewhere, I'll take a look. In the meantime, you might want to try using the native code generator instead. Just add -fasm to the command line. Cheers, Simon

1 0

compiling big files?
by Malcolm Wallace 30 Oct '02

30 Oct '02

I have occasional problems getting ghc-5.04.1 to compile a very large source file with -O switched on. The source file is generated by another tool, and is rather large at 25762 lines (2776340 bytes). Without -O, the compilation goes normally, taking about 10 minutes or so. With -O, the compiler uses >280Mb of memory, which causes my machine with only 256Mb to swap like crazy, but that is OK, because after about half an hour, ghc produces its output in a .hc file. The C compiler (gcc-2.95.3) then produces a .raw_s file: $ wc /tmp/ghc* 759338 837040 18321347 /tmp/ghc3992.hc 1711905 3174489 32014101 /tmp/ghc3992.raw_s It's the next stage, when (I presume) the ghc-mangler converts the .raw_s file to a simpler .s file, that doesn't run to completion. It simply reports Killed make: *** [targets/ix86-Linux/hat-lib-ghc] Error 2 It seems that if I re-run ghc on the intermediate .hc file that was left behind in the /tmp directory, then the mangler is ok, and assembly proceeds right up to the .o file. So is there any (fixable) reason why the one-step invocation fails, but the two-step invocation succeeds? Regards, Malcolm

1 0

RE: FFI & C++
by Simon Marlow 30 Oct '02

30 Oct '02

> 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? I don't know the gory details, but it might be that we would have to link GHCi with the C++ linker for this to work. Would anyone with a clue about C++ linking like to comment? > 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? Hmm, I must admit I'm a bit averse to adding features like this unless they are really necessary. One problem is that when someone submits a bug report, we'll have to start asking "do you have a .ghc file? what does it contain?". The current situation has the advantage of being simple. Can't you just alias ghc to 'ghc -package-conf ...'? Cheers, Simon

1 0

Re: Optimisation and unsafePerformIO
by Albert Lai 30 Oct '02

30 Oct '02

"David Sabel" <dsabel(a)stud.uni-frankfurt.de> writes: > {-# NOINLINE b #-} > > b x = if even x then unsafePerformIO getChar else bot > > bot = bot > > main = do > putChar (b 4) > putChar (b 6) I am not a compiler implementer (or lawyer, for that matter :) But I propose this guess. First, both even 4 and even 6 get constant-folded to True; so b 4 and b 6 both become unsafePerformIO getChar. Then there is a common subexpression elimination.

2 1

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