- ghc-devs - Haskell.org

docker GHC image for hacking
by Greg Weber 10 Dec '14

10 Dec '14

Friends, As someone who started hacking on GHC last month I wanted to tell you that there is to high an overhead to getting started and overall to contributing to GHC. One thing that can help is to make getting to the point of compiling GHC a much faster experience rather than starting off by dreading the process of installing dependencies. I created a docker image that has everything needed pre-installed. I do know that there are existing docker images for running the GHC compiler, but I am not aware of any designed for hacking on it. Please give it a try and let me know if it works for you. The beauty is that once you have GHC checked out, if you have docker installed you are a single command away from having a working GHC environment: docker run --rm -i -t -v `pwd`:/home/ghc gregweber/ghc-haskell-dev /bin/bash Once getting some feedback, I would like to document this on the wiki and recommend it for Linux users (definitely for anyone that is familiar with docker). Thank you, Greg Weber

7 9

Linker change in GHC 7.8 leads to widespread issues
by Bryan O'Sullivan 10 Dec '14

10 Dec '14

Hi folks, It seems that something somewhere in linker-land changed in GHC 7.8 such that packages that include C components now need to be built with position-independent code on some platforms. This affects a number of my packages. I am not sure whether the correct fix is to pepper all of these packages (and presumably dozens to hundreds of other packages on Hackage) with "-fPIC" and issue new releases, or to instead teach Cabal to do this. It would certainly be vastly less disruptive to all of the affected package authors to have Cabal automatically do the right thing here. Could someone who's closer to both piles of code please suggest which approach they believe is more appropriate?

11 20

help writing a test case
by Greg Weber 09 Dec '14

09 Dec '14

https://phabricator.haskell.org/D518 Can someone give me guidance on how to write a test case? I am trying to write a test case for a new flag that generates a file (much like -ddump-to-file). I started by trying to cat the generated file to get it into the stdout/stderr +test('T8624', normal, run_command,+ ['echo $MAKE && $MAKE T8624 && cat T8624.th.hs']) But I get this error: cd . && echo $MAKE && $MAKE T8624 && cat T8624.th.hs </dev/null >T8624.run.stdout 2>T8624.run.stderrmakemake[1]: Entering directory '/home/ghc/testsuite/tests/th'cc T8624.o -o T8624/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o: In function `_start':(.text+0x20): undefined reference to `main'collect2: error: ld returned 1 exit status<builtin>: recipe for target 'T8624' failedmake[1]: *** [T8624] Error 1make[1]: Leaving directory '/home/ghc/testsuite/tests/th'Wrong exit code (expected 0 , actual 2 )

1 0

ghc.haskell.org slow?
by Simon Peyton Jones 08 Dec '14

08 Dec '14

Is it just me, or is access to ghc.haskell.org and git.haskell.org very slow? I guess it could be at my end; I don't know how to tell. But git pull and Trac access takes tens of seconds, even minutes Simon

4 3

Re: Status and future of the LLVM backend
by Ben Gamari 08 Dec '14

08 Dec '14

Joachim Breitner <nomeata(a)debian.org> writes: > Hi, > > > Am Montag, den 08.12.2014, 08:20 -0500 schrieb Ben Gamari: >> > Again Google finds me a bug, but this time one that has no fix >> > associated with it: >> > https://ghc.haskell.org/trac/ghc/ticket/8951 >> > >> > Ben, can you help me out here? >> > >> I've been unable to reproduce this issue in my environment. The build >> succeeded using your packaging on my Odroid XU running Debian Jessie. > > Weird. Can you try creating a sid chroot and building it in there? > > I managed to finish the build with this patch attached: > Great! > So what does that tell us? Maybe Peter can help us: Is it normal for a > Debian system to pretend that its a pre-v6 ARM, even if the actual > hardware is not? > Could you confirm that arm_HOST_ARCH_PRE_ARMv6 is actually defined in mk/config.h? If so we should try to figure out why. The architecture is determined by autoconf. Perhaps you could attach config.log? >> >> It seems that this is likely due to dh_autoreconf which overwrites all >> config.subs with /usr/share/misc/config.sub. It's totally unclear to me >> how the first build succeeded, however. >> >> Have you seen this in the past? > > Yes, likely a bug in dh_autoreconf that does not handle rebuilds well > (or a bug in how we use it). > Hmm, alright. Why exactly do we overwrite config.sub and config.guess? I guess we are trying to ensure that the build systems in libraries/* are generated by the system's autoconf (taking the place of `boot`)? Is there a reason we can't just use autoreconf as `boot` does? Cheers, - Ben

2 1

GHC Weekly News - 2014/12/08
by Austin Seipp 08 Dec '14

08 Dec '14

Hi *, Once more, it's time for some news about GHC! This week's regularly scheduled programming (get it?) has brought you... - As of last week, GHC officially has no more `.lhs` files in its source repository; instead, they've all been converted to `.hs` and are now much more consistent with each other: https://www.haskell.org/pipermail/ghc-devs/2014-December/007552.html - Joachim Breitner has reported that the `linker_unload` test in GHC has been failing, but it's been surprisingly hard to reproduce reliably on our build machines! https://www.haskell.org/pipermail/ghc-devs/2014-December/007528.html - Moritz Angermann posted a proposal about the "Out of Process Template Haskell" project, started by the GHCJS developers. In short, they want to work out how to get Template Haskell working in a stage2 GHC for things like iOS or Browser devices: https://www.haskell.org/pipermail/ghc-devs/2014-December/007555.html - Lennart Augustsson has an inquiry about his program: why is it running out of memory? But the stranger thing: why does it only run out if heap profiling ''is not enabled''? Nobody has quite figured out, but if you're a guru, it may be a good chance to help out: https://www.haskell.org/pipermail/ghc-devs/2014-December/007582.html - Yuras Shumovich tracked down some nasty bugs in the typechecker's linter, causing several programs to fail to work when compiled by GHC. A quick diagnosis, but no fix has been merged quite yet: https://www.haskell.org/pipermail/ghc-devs/2014-December/007580.html - Richard Eisenberg wants feedback on a what he thinks is a design wart in the use of `-XStandaloneDeriving`, and he's not only proposed a solution, but wants to know what people think; typechecking fans are surely puzzling away already: https://www.haskell.org/pipermail/ghc-devs/2014-December/007589.html - David Spies has run into an interesting situation: why does -O make his program **slower** instead of faster? Well, nobody has quite figured out why yet, but it's an interesting question - maybe on a lazy monday developer can help figure out: https://www.haskell.org/pipermail/ghc-devs/2014-December/thread.html - Richard E. has another thread on the list, this time about development work flows: what do we do about painful merges? https://www.haskell.org/pipermail/ghc-devs/2014-December/007586.html Closed tickets this week include: #9850, #9005, #9828, #9833, #9582, #8935, #9186, #9480, #9497, #7908, #4347, #3977, #3859, #3844, #3814, #3771, #3739, #2182, #9812, #4921, #7947, #9240, #5401, #3625, #3517, #9444, #9142, #3447, #8894, #3065, #3191, #2697, #2836, #5443, #7736, #2489, #2456, #2204, #9777, #9859, #9869, #9808 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

inferred contexts from `deriving`
by Richard Eisenberg 08 Dec '14

08 Dec '14

Hi devs, I've just hit on (what I view to be) a design wart in what is allowed in an instance context inferred through the use of non-standalone `deriving`. I've posed a problem and potential solution in #8984 (https://ghc.haskell.org/trac/ghc/ticket/8984#comment:6) See Note [Exotic derived instance contexts] (https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcDeriv.hs#L1915) for some background info. I would love input on this issue, as it all boils down to a simple design choice. The implementation is dead easy no matter what. Please post any further comments to the ticket, but I wanted to bleat here because it seems easy to ignore emails from #8984, whose title is about tweaking an error message. Thanks, Richard

1 0

painful merges
by Richard Eisenberg 07 Dec '14

07 Dec '14

Hi devs, There are various times when we want to make some change to a large number of lines/files, but the change is very very boring. Two somewhat recent cases that come to mind are de-tabbing and the .lhs -> .hs conversion. These sorts of changes cause painful merges for anyone who is working on a branch. However, this pain is mitigated substantially if two properties hold: 1) The commit does *nothing* interesting. 2) The branch-writer knows about the commit in question. If these two properties hold, then the branch-writer can merge with the commit previous to the painful one, resolve all conflicts, and then merge the painful commit. During the painful merge, the branch-writer can be blissfully carefree about understanding the code -- after all, the painful merge is uninteresting and mechanical. Then, the branch-writer can continuing merging more commits, paying closer attention. In most cases, it should be easy for us to maintain property (1) going forward. Property (2) is harder, so I propose the following: ** All commits expected to be painful to merge, but are otherwise uninteresting, include "[painful merge]" in the commit message. ** This seems to be a really easy workflow to implement, and it would make, for example, the long, drawn-out debate over detabbing perhaps easier to resolve. Bikeshedding over the keyword [painful merge] welcome, along with more constructive comments. Is anyone aware of this convention implemented in other projects? Thanks, Richard

1 0

testsuite no longer parellel?
by Richard Eisenberg 07 Dec '14

07 Dec '14

Hi devs, Previously, I've had much success with the THREADS environment variable for getting the testsuite to run multiple tests in parallel. This no longer seems to be working on my Macs. Is this an expected change? Is there something I can do to fix this locally? It takes a long time to run tests one at a time! Thanks! Richard

1 0

ghc.haskell.org
by Simon Peyton Jones 05 Dec '14

05 Dec '14

Is it just me, or is ghc.haskell.org very slow at serving up Trac pages today?

1 0