October 2002 - Glasgow-haskell-users

RE: comparison of execution speed of array types
by Zdenek Dvorak 20 Jan '03

20 Jan '03

Hello, >DiffArray seems to be broken :). Either that or I'm using it >incorrectly. I've attached the relevant code, but when I don't reverse >the array everything works fine; when I reverse it the program doesn't >(seem to) halt. I've tried to use DiffArray recently and it is terribly slow. I was forced to write my own version (it is a bit faster, but still nothing great). My suspicion about the result of your measuring is that it does the updates in reversing the array one by one, thus leading to quadratic behavior. Zdenek Dvorak _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

2 1

RE: crash in profiling mode
by Simon Marlow 08 Nov '02

08 Nov '02

> Another question: The profiling mode of GHC-4.08.2 did also output (in > mode +RTS -p) the time spent on garbage collection (as an additional > percentage of overall running time). > With the programs I tested so far under GHC-5.04.1, I never > saw such an > indication in a.out.prof, although for the same programs under > GHC-4.08.2 considerable garbage collection times were measured. > > Does this mean that: > > a) the indication of garbage collection times has been dropped from > profiling reports (can I obtain them in another way?), > > or > > b) the newer GHC is so smart that it optimised away the need for > garbage collection in the particular (few) programs I tested, but > otherwise the GC times will show up in profiling reports, > > or > > c) something else? The inclusion of GC time in the report was wrong, since GC time wasn't included in the figure for total time, so you could get GC times of > 100%. You can get a measure of GC time vs. mutator time by adding '+RTS -sstderr' to the command line. Cheers, Simon

2 1

IOError vs. Exception vs. IOException
by Ross Paterson 31 Oct '02

31 Oct '02

Shouldn't IOError be identified with IOException rather than Exception?

2 1

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 30 Oct '02

30 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