January 2014 - ghc-devs

Validating with Haddock
by Mateusz Kowalczyk 12 Jan '14

12 Jan '14

Greetings, I'm trying to validate HEAD and I care that Haddock is built alongside it (so --no-haddock is not an option). I get the following errors listed at the bottom of this e-mail. How can I validate so that it all builds? >From what I understand, to validate I should: * Have a stable compiler in my PATH (7.6.3) * go to top level directory * run ‘sh validate’ Am I missing steps? == Start post-build package check Timestamp 2013-12-28 05:00:55 UTC for /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d/package.cache Timestamp 2013-12-28 05:00:55 UTC for /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d (same as cache) using cache: /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d/package.cache Timestamp 2013-12-28 05:22:27 UTC for /home/shana/programming/ghc/inplace/lib/package.conf.d/package.cache Timestamp 2013-12-28 05:22:27 UTC for /home/shana/programming/ghc/inplace/lib/package.conf.d (same as cache) using cache: /home/shana/programming/ghc/inplace/lib/package.conf.d/package.cache There are problems in package xhtml-3000.2.1: dependency "base-4.7.0.0-578628bf142f9304d05ce5581b5f8d76" doesn't exist There are problems in package ghc-paths-0.1.0.9: dependency "base-4.7.0.0-578628bf142f9304d05ce5581b5f8d76" doesn't exist The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. xhtml-3000.2.1 ghc-paths-0.1.0.9 -- Mateusz K.

5 23

HEADS-UP: testsuite has been folded into ghc; back up your old testsuite/ folder!
by Herbert Valerio Riedel 12 Jan '14

12 Jan '14

Hello *, It's finally done; effective immediately, the testsuite/ folder is now tracked as part of ghc.git (for the master branch) *IMPORTANT* If there's any chance you have something importing lying around in your testsuite/ please move it out of the way preemptively (e.g. with 'mv testsuite/ testsuite-old/') *before* you perform a 'git pull' or 'sync-all pull' on ghc.git. Even though there are some safe-guards in place, those might not be 100% effective, so better safe than sorry. As only the `master` branch of testsuite.git has been merged, those of you who had wip/ branches or similar in testsuite.git need to handle those yourselves. Should you need assistance with bringing over those commits from testsuite.git into ghc.git (or if there's anything else that's now broken because of this change), please let me and/or Austin a line, so we can assist you. See also previous post "Folding ghc/testsuite repos *now*, 2nd attempt"[1] announcing this step. [1] http://www.haskell.org/pipermail/ghc-devs/2014-January/003730.html Greetings, hvr

1 0

Repository Reorganization Question
by Austin Seipp 10 Jan '14

10 Jan '14

Hi all, While discussing something with Herbert this week in preparation of making a new stable branch, he brought a good point to my attention, which is that if we go ahead and reorganize the repository situation post 7.8, merging things to the stable branch from HEAD will become a bit harder. Notably, we had planned to fold testsuite (and perhaps some other repositories) into the GHC tree. Once we do this, the two branches will have diverged quite a bit, so merging from HEAD to STABLE will become harder* (because HEAD would have rolled in testsuite changes for example, but the STABLE branch would not have this history.) Thinking about it, the best time to do such a move is, basically, when there is no active stable branch. Unfortunately this time is right now, but I'm not sure how everyone feels about this. So, the question is: should we go ahead and pull the trigger on some of these perhaps? Herbert collected some numbers on the git repositories and outlined all the basic details here: https://ghc.haskell.org/trac/ghc/wiki/GitRepoReorganization The only thing I'd honestly propose right now is folding 'testsuite' into the main repository, but of course we should see what people think - perhaps we should keep base/etc off the table for now, since they seem more controversial. * I'll point out they will only become *slightly* harder in most cases, because I can always instead apply unified diffs, rather than cherry pick or something. But it does lose the original metadata from commits too. But I won't cry if people vote against this. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

13 43

Fwd: Changing GHC Error Message Wrapping
by Andrew Gibiansky 10 Jan '14

10 Jan '14

Hello, I'd like to change how the error messages from GHC get wrapped. I am using the following code: flip gcatch handler $ do runStmt "let f (x, y, z, w, e, r, d , ax, b ,c,ex ,g ,h) = (x :: Int) + y + z" RunToCompletion runStmt "f (1, 2, 3)" RunToCompletion return () where handler :: SomeException -> Ghc () handler e = liftIO $ putStrLn $ "Exception:\n" ++ show e The output I am getting looks like this: [image: Inline image 1] I would like the types to not wrap at all, or wrap at some very long length along the lines of 200-300 characters. I have seen the `pprUserLength` and `pprCols` fields in DynFlags, but they don't seem to do anything. What should I do? Thanks! Andrew

5 12

Optimisation flags at -O0
by Chris Heller 09 Jan '14

09 Jan '14

I wanted to understand better what `-fspec-constr` does. So I compiled the User Guide example with `-O0 -fspec-constr` to isolate the effects of call-pattern specialization, and nothing else (I used ghc-core to pretty-print the resulting Core syntax). It appears I get the same output wether I use `-fspec-constr` or not. Does this mean that compiling with `-O0` even explicitly enabled optimizations are turned off? If that is the case, how does one test an isolated optimization? -Chris

3 2

Cannot find normal object file when compiling TH code
by Yorick Laupa 09 Jan '14

09 Jan '14

Hi, Oddly I can't compile code using TH with GHC HEAD. Here's what I get: cannot find normal object file './Tuple.dyn_o' while linking an interpreted expression I'm currently working on a issue so I compile the code with ghc-stage2 for convenience. I found an old ticket related to my problem ( https://ghc.haskell.org/trac/ghc/ticket/8443) but adding -XTemplateHaskell didn't work out. The code compiles with ghc 7.6.3. Here's my setup: Archlinux (3.12.6-1) Any suggestions ? --Yorick

3 6

Tuple predicates in Template Haskell
by Yorick Laupa 08 Jan '14

08 Jan '14

Hi, I try to make my way through #7021 [1]. Unfortunately, there is nothing in the ticket about what should be expected from the code given as example. I came with an implementation and I would like feedback from you guys. So, considering this snippet: -- {-# LANGUAGE ConstraintKinds #-} type IOable a = (Show a, Read a) foo :: IOable a => a foo = undefined -- This is what I got now when pretty-printing TH.Info after reify "foo" call: VarI Tuple.foo (ForallT [PlainTV a_1627398594] [TupleP 2 [AppT (ConT GHC.Show.Show) (VarT a_1627398594),AppT (ConT GHC.Read.Read) (VarT a_1627398594)]] (VarT a_1627398594)) Nothing (Fixity 9 InfixL) Does that sound right to you ? Thanks for your time -- Yorick [1] https://ghc.haskell.org/trac/ghc/ticket/7021

2 2

LLVM and dynamic linking
by Ben Gamari 08 Jan '14

08 Jan '14

# The Problem Dynamic linking is currently broken with the LLVM code generator. This can be easily seen by attempting to compile GHC with, GhcDynamic = YES DYNAMIC_BY_DEFAULT = YES DYNAMIC_GHC_PROGRAMS = YES BuildFlavour = quick-llvm This build will fail with a error along the lines of, dll-split: internal error: invalid closure, info=0x402ec0 (GHC version 7.7.20131212 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug After some poking around with the help of Peter Wortmann, it seems clear that this is due to a subtle difference in how LLVM emits function symbols. While the NCG emits these symbols with `.type @object`, LLVM emits `.type @function`. It appears that the `.type` annotation guides the linker in choosing the relocation mechanism to use for the symbol. While `@object` symbols use the Global Offset Table, `@function` symbols are relocated through the Procedure Linking Table, a table of trampoline calls which are fixed up at runtime. This means that static references to functions end up pointing not to the object itself (and its info table) but instead to some linker-generated assembly. When the garbage collector attempts to examine the info table of one of these references, it finds nonsense and fails. # A solution Peter demonstrated that manually modifying the assembler produced by llc, passing this through GHC's mangler, and assembling the result yields a functional binary. As far as I can tell, LLVM's intermediate language doesn't expose any way to force a function to `.type @object`. Unfortunately this means that, at least for now, the only fix is to augment the mangler with logic to perform this transform. I've done this in my `llvm-dynamic` branch[1] (in addition to finding a bug in the `rewriteInstructions` function used by AVX rewriting). This branch compiles on my x86_64 machine to produce what appears to be a functional compiler. Unfortunately installation issues (which I'll describe shortly in a new thread) prevent me from verifying this. I'm currently waiting for a build on my ARM box but assuming this fix works this means that GHC could (finally) have first-class, stable ARM support. Comments? Cheers, - Ben [1] https://github.com/bgamari/ghc/tree/llvm-dynamic

3 6

Re: Pattern synonyms for 7.8?
by Dr. ÉRDI Gergő 08 Jan '14

08 Jan '14

Hi, please don't commit it just yet, I'd like the eventual single commit to also include the user documentation. Thanks, Gergo On Jan 8, 2014 10:46 PM, "Austin Seipp" <aseipp(a)pobox.com> wrote: > Oh, to be honest, I was just going to squash it into a single Big > Commit, with you set as the author, Gergo. This seems to be the > general way we do it for new features. > > If you'd like I can just go ahead and do this for you. > > On Wed, Jan 8, 2014 at 8:33 AM, Dr. ERDI Gergo <gergo(a)erdi.hu> wrote: > > On Wed, 8 Jan 2014, Simon Peyton Jones wrote: > > > >> It'd be good if what we finally commit to HEAD has a sensible history > > > > > > Yes, of course. I'll clean that up next week. I just have to run now. > > > > > > -- > > > > .--= ULLA! =-----------------. > > \ http://gergo.erdi.hu \ > > `---= gergo(a)erdi.hu =-------' > > Ha paranoiásokkal akarsz megismerkedni, kezdd el követni ôket. > > > > -- > Regards, > Austin - PGP: 4096R/0x91384671 >

1 0

Re: Pattern synonyms for 7.8?
by Dr. ERDI Gergo 08 Jan '14

08 Jan '14

On Wed, 8 Jan 2014, Austin Seipp wrote: > Oh, to be honest, I was just going to squash it into a single Big > Commit, with you set as the author, Gergo. This seems to be the > general way we do it for new features. > > If you'd like I can just go ahead and do this for you. Sure, thanks. I'm getting 8 unexpected test failures but I haven't tried them on master yet to see if they are caused by my code: driver T4437 [bad stdout] (normal) generics GenDerivOutput [stderr mismatch] (normal) generics GenDerivOutput1_0 [stderr mismatch] (normal) generics GenDerivOutput1_1 [stderr mismatch] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/should_run T5237 [stat not good enough] (normal) rename/should_compile T7336 [stderr mismatch] (normal) th T8633 [bad exit code] (normal) I'll look at these next week when I'm back. Bye, Gergo

1 0