- Glasgow-haskell-users

GHC library profiling
by Pasqualino 'Titto' Assini 25 Apr '07

25 Apr '07

Hi, I have a little library that depends on the 'ghc' api library. I would like to build my library in profiling mode but this is not possible as the 'ghc' library itself seems to be distributed only in non-profiling mode. Is there any way out? How can I get or build a profiling version of 'ghc'? An unrelated comment: I guess that the right command to update the darcs version of ghc plus all its related libraries is: sh darcs-all --extra pull Would it be useful to add this info to the ghc README file? Currently it only explains how to get ghc and libs the very first time Thanks in advance for your help, titto

2 1

Release naming - e.g. "6.8" vs. "6.8.0"
by Isaac Dupree 20 Apr '07

20 Apr '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've gotten confused before between whether GHC "6.6" referred to the whole branch or the point release between 6.4.2 and 6.6.1. It makes it hard to distinguish which is being referred to (although, it also makes it easy to be vague when referring to an upcoming major release, which might be considered an advantage I suppose). I propose we switch to that "X.Y.0"-style major release naming as of 6.8.0 (a.k.a. 6.8). Comments or opinions? Isaac (P.S. GCC's having made this naming change inspired me to suggest this, but I don't actually know what their reasons were) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGKOrZHgcxvIWYTTURAtykAJ4s/cSgmcHtGspk1LvNApq+N2SjQQCdFAqH UsNQIR2CXZ6en74MFwNi0HM= =ynkD -----END PGP SIGNATURE-----

1 0

Impressions on GHC debugger
by Alexey Rodriguez Yakushev 19 Apr '07

19 Apr '07

Dear all, Yesterday I darcs-got the GHC HEAD to play with the debugger and I have the following impressions/bug/suggestions: * I would like to know whether I am debugging mode (i.e. in a breakpoint) or not. For example > *Main> -- normal prompt and, for example, > *Main:[1] > -- in breakpoint 1 now, if I evaluate expression "e" via "seq e ()" and it happens to trigger breakpoint 2, I would like to see something like > *Main:[1]:[2] > or some better notation, but you get my point. * The notation for printing a list is non-Haskell, consider the following evaluated head but unevaluated tail: > *Main> :print xs > xs = [True | (_t2::[Bool])] I would have expected "True : (_t2::[Bool])" * Consider the following code: > mymap f [] = [] > mymap f (x:xs) = f x:mymap f xs > > main = mapM_ putStrLn $ mymap ('a':) ["hello","bye"] First, I set a breakpoint on line two. When I invoke "main", the breakpoint is triggered two times before "main" is done evaluating. Afterwards, If I type "main" at the ghci prompt again, the breakpoint is not triggered anymore! Even though ":show breaks" lists it. * Again considering the code above, if I break at line 2: > Stopped at FreeVar2.hs:2:17-19 > x :: GHC.Base.Unknown > f :: t -> a > xs :: [GHC.Base.Unknown] Now I type "f" and the following message appears: > *** Exception: No match in record selector Var.tcTyVarDetails * I was wondering whether it would be nice to have a "break" function/ primitive, so that you can write: > mymap f [] = [] > mymap f (x:xs) = (break (f x):mymap f xs) with "break" having type "a -> a" and inserting a breakpoint around the argument expression. It is handy to not have to recalculate lines. However I am not so sure anymore. Using line numbers is not as bad as I thought. The debugger is a nice addition to GHC, and I look forward to the debugger being integrated into the Emacs Haskell mode! Cheers, Alexey

3 2

RE: Login problems with trac
by C Rodrigues 18 Apr '07

18 Apr '07

The wiki has "edit" links if I login as guest, but not if I login as heatsink. Is that also because of the spam issue? _________________________________________________________________ Get a FREE Web site, company branded e-mail and more from Microsoft Office Live! http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/

4 5

Release plans
by Simon Marlow 18 Apr '07

18 Apr '07

We'd like to solicit comments from the community on our plans for future GHC releases. The current situation is this: - 6.6.1 is nearly ready to go (perhaps this week, please test the RC!) - 6.6.2 has ~35 outstanding tickets - 6.8 has ~150 outstanding tickets the default option would be to work on 6.6.2 and release it in a couple of months, while continuing to work on 6.8 for a release in ~6 months or so. However, there's another option: we could skip 6.6.2 and head straight for 6.8, the idea being to stabilise 6.8 with the existing feature set (plus a few important developments in progress), so that we can get these features out in a release sooner rather than later. The 6.6.2 tickets would be moved to 6.8, and most of the outstanding 6.8 tickets would be pushed to 6.8.1 or later, retaining only the features/bug-fixes that are essential for the 6.8 release. Here's a quick summary of the major developments that we already have in the 6.8 codebase: - Associated data types, and the new FC intermediate language - GHCi debugger (although there's an overhaul of the breakpoint support almost ready to go in) - Coverage (HPC) - GADTs + typeclasses - more packages moved from core to extralibs - GHC API changes, compile to object code inside GHCi - performance improvements: simplifier rewrite, and SpecConstr improvements - standalone deriving declarations - left-to-right impredicative instantiation: runST $ foo Here are the features in progress that we'd like to get into 6.8: - pointer-tagging (15% perf improvement for compiled code) - get external core working again - base package breakup (see discussion on libraries list) - list fusion We think the above feature set makes for a pretty strong 6.8 release. What do you think of this plan? Are there features/bug-fixes that you really want to see in 6.8? Cheers, Simon & the GHC Team

14 27

Re: Release plans
by Brandon Michael Moore 18 Apr '07

18 Apr '07

Sending to the right list this time, with some additions. > Just to show what kind of problems we are currently facing. The > following type checks in our EHC compiler and in Hugs, but not in the > GHC: > > module Test where > > data T s = forall x. T (s -> (x -> s) -> (x, s, Int)) > > run :: (forall s . T s) -> Int > run ts = case ts of > T g -> let (x,_, b) = g x id > in b Consider this additional code which also typechecks in Hugs: v :: forall s . T s v = T f f :: s -> ([s] -> s) -> ([s], s, Int) f v g = let x = [v] in (x, g x, 0) run v gives 0. Apparently id has type [s] -> s. I'm not sure if we're ending up with the infinite type s = [s], or maybe something really bad would happen in run v, if it were not for parametricity keeping us from examining the first two elements of the triple too closely (I tried adding Show constraints, but couldn't get code like that to typecheck). Now for wild speculation: Simplifing T and assuming full existentials, you might define something akin to run with a type like (forall s . exists x. (x -> s) -> (x, s)) -> (exists t . (t -> t) -> (t, t)), which suggest to me two ingredients (in a language with type operators), a functional axiom of choice plus fixpoints of type operators, ac :: (forall a . exists b. X) -> exists f::*->*. forall a . X[f(a)/b] and fixT :: (* -> *) -> * Then you might implement the type above as equalize pkg = open ac pkg as {exists F. body} in close {fixT F, body} Brandon

1 0

Happy bug
by Stefan O'Rear 17 Apr '07

17 Apr '07

stefan@stefans:~/cadt/src$ happy Parser.y happy: parE stefan@stefans:~/cadt/src$ A little code examination seems to show that this error cannot occur for correct grammars. But still - it's not helpful. I would prefer to see the actual first error rather than none of the errors. Parser.y is attached. I tried to send this to the bug report address, but SimonM's email system rejected it as spam, even with a 25-bit hashcash stamp! So now all of g-h-u is annoyed.

4 4

diagnostics' identifier quoting style
by Isaac Dupree 16 Apr '07

16 Apr '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here's a random message selected from building GHC: Warning: Defined but not used: `res_ty'' (the identifier is "res_ty{PRIME}", where {PRIME} is the ' mark) Note that quotes are left:` (grave accent) and right:' (ASCII single quote). Besides this being theoretically incorrect, identifiers can include the ' symbol (generally meaning more like "prime" than "single quote"...), making this look odd. Maybe it should show the identifier-string so that it just has ordinary double-quotes around it?, looking like: Warning: Defined but not used: "res_ty'" Isaac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGIBIQHgcxvIWYTTURAt5TAKC7Rkbgqr7RsuGEMgyXsMm7kbiIswCdHGs2 lJY8FH7CR8YXwJ47g+0gNWw= =ptnw -----END PGP SIGNATURE-----

4 3

GHC's error messages are too verbose?
by Bryan O'Sullivan 16 Apr '07

16 Apr '07

I've long wondered why GHC issues such prolix error messages when it runs into a problem. Here's a representative example from some hacking I'm currently doing: src/Network/Hackage/CabalPackage/Setup.hs:68:5: Couldn't match expected type `(RpmFlags, [String])' against inferred type `()' Expected type: IO (RpmFlags, [String]) Inferred type: IO () In the expression: (when (not (null unknown))) $ (do hPutStrLn stderr "Unrecognised options:" mapM_ (hPutStrLn stderr) unknown exitWith (ExitFailure 1)) This might not look like a terribly long error, but that's because I've snipped a bunch of context that GHC also prints: In the expression: do let (os, args', unknown, errs) = getOpt' RequireOrder options args opts = foldl (flip ($)) emptyRpmFlags os (when (rpmHelp opts)) $ (do printHelp stdout exitWith ExitSuccess) (when (not (null errs))) $ (do hPutStrLn stderr "Errors:" mapM_ (hPutStrLn stderr) errs exitWith (ExitFailure 1)) (when (not (null unknown))) $ (do hPutStrLn stderr "Unrecognised options:" mapM_ (hPutStrLn stderr) unknown exitWith (ExitFailure 1)) This length is on the modest side for a block of monadic code. With a longer chunk of code, individual error messages can easily stretch to dozens of lines long, due purely to GHC printing context information that amounts to repeating my source code back at me. I don't understand the motivation behind this verbosity. Clearly, a little bit of context is helpful, so I can see which expression GHC is objecting to, but why repeat the entire surrounding chunk of code back at me, when I already have the file name and line number, and the original code that caused the error? Compilers for other languages seem content with as little as one line of output per error (which I am not advocating), or a few lines of source with the problem highlighted, but I rarely see more. Hugs also tends towards the terse side, but I've never found this to be a problem. Cheers, <b

6 5

Guessing compiler features from a binary
by Jeffrey Yasskin 14 Apr '07

14 Apr '07

Hi all. I'm looking for the best way to derive the following attributes of a compiled ghc from just the binary: * Supports native code generation * Supports profiling * Supports -unreg * Has ghci * Has the threaded RTS * Supports SMP I can probably detect each of these by writing a small test program, but I'm hoping there's a more straightforward (and faster) way. I was hoping for a mode similar to `perl -V`, but `ghc -V -v5` doesn't seem to print anything relevant and I don't see any other flags that look hopeful. Some background: I'm trying to make it easy to run the testsuite driver from outside of the ghc Makefile system. Right now, its command line (on my system) looks something like: python ../../../testsuite/driver/runtests.py -e ghc_with_native_codegen=1 -e ghc_with_profiling=0 -e ghc_with_unreg=0 -e ghc_with_interpreter=1 -e ghc_with_threaded_rts=1 -e ghc_with_smp=1 --rootdir=. --config=../../../testsuite/config/ghc -e config.confdir=\"../../../testsuite/config\" -e config.compiler=\"/Users/jyasskin/src/ghc/HEAD/ghc/compiler/stage1/ghc-inplace\" -e config.compiler_always_flags.append"(\"-Dpowerpc_apple_darwin\")" -e config.compiler_always_flags.append"(\"\")" -e config.ghc_pkg=\"/Users/jyasskin/src/ghc/HEAD/ghc/utils/ghc-pkg/ghc-pkg-inplace\" -e config.hp2ps=\"/Users/jyasskin/src/ghc/HEAD/ghc/utils/hp2ps/hp2ps\" -e config.gs=\"gs\" -e config.platform=\"powerpc-apple-darwin\" -e config.wordsize=\"32\" -e default_testopts.cleanup=\"\" -e "if '0': config.use_threads=int(0)" -e config.timeout="int() or config.timeout" -e config.timeout_prog=\"../../../testsuite/timeout/timeout\" which is not something I'd want to have to type. I'm hoping to be able to derive all of these arguments from just the path to the compiler, which could produce a command line as short as `python ../../../testsuite/driver/runtests.py --compiler="/Users/jyasskin/src/ghc/HEAD/ghc/compiler/stage1/ghc-inplace"`. Thanks for any suggestions, Jeffrey

1 0