- ghc-devs - Haskell.org

Typechecker tests failures
by Yuras Shumovich 12 Dec '14

12 Dec '14

Hello, I was working on #9605, and found a number of failed tests: Unexpected failures: should_compile T7891 [exit code non-0] (hpc,optasm,optllvm) should_compile tc124 [exit code non-0] (hpc,optasm,optllvm) should_run T7861 [bad exit code] (normal,hpc,optasm,ghci,threaded1,threaded2,dyn,optllvm) They seem to be unrelated to my work, and they are skipped when "fast" is enabled. T7891 and tc124 fail with Core Lint errors. Looks like Phabricator uses "fast" way to validate revisions, so the failures were not noticed. Thanks, Yuras

2 2

Please test: release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches
by Johan Tibell 12 Dec '14

12 Dec '14

I've uploaded release candidates for Cabal/cabal-install patch releases on the 1.18 and 1.20 branches: https://www.haskell.org/cabal/release/cabal-1.18.1.5/Cabal-1.18.1.5.tar.gz https://www.haskell.org/cabal/release/cabal-install-1.18.0.6/cabal-install-… https://www.haskell.org/cabal/release/cabal-1.20.0.3/Cabal-1.20.0.3.tar.gz https://www.haskell.org/cabal/release/cabal-install-1.20.0.4/cabal-install-… Please test, especially if one of your fixes are in this release. You can install both both lib and exe using: cabal install <Cabal URL> <cabal-install URL> Changelogs: Cabal-1.18.1.5: e4660ff17f923e999080e21a20062d0df8d24bb6 The download dir on haskell.org moved fb3db6313b43632fdc9d598140b3eb5a681eb90b Bump Cabal version number to 1.18.1.5 12a698b6db8a2ca55367c54611a269048f4cef7b Build C sources with -fPIC when GHC is using dynamic libraries. cabal-install-1.18.0.6: 79ccaa85bba7957344fb1dca06d84220eff9b73c Bump cabal-install version number to 1.18.0.6 97dc39636bd547782647cb792ceca6c60a7e5ab1 Merge branch '1.18' of https://github.com/snoyberg/cabal into 1.18 4fbb20f52c842a7c7c173555ff7f0c8b5b67dfa1 Support for network-2.6 6f74da062e6d1bdc6db51acd55d0e2676fa56bf2 SavedConfig Monoid instance: make list fields work like Flags. 7380144203a233f81ff67052fc3256cf47b9b71f cabal update: use sandbox config file #1884 Cabal-1.20.0.3 7d7f560cc84dfe643d916efbab7c382b1df5a9e2 Bump cabal-install version number to 1.20.0.4 813ce2fc23da81b7bf07418a28258a962c44713e Bump Cabal version number to 1.20.0.3 cee305209129480f28190ee7026076962ba9ca97 The download dir on haskell.org moved b172747adec9ec8d57d8215e9d1cabb448aa6036 Build C sources with -fPIC when GHC is using dynamic libraries. 93aba465d35d03b29b1d9bd3a456815272a38a41 Revert 97c6a72984931f4ccf628736024d3459a033af6c. 343257e96fab526da27d143b653433f45c6c1401 s/2.15/2.14.4/ cabal-install-1.20.0.4 7d7f560cc84dfe643d916efbab7c382b1df5a9e2 Bump cabal-install version number to 1.20.0.4 caf257cd96e766b293943bbac07d766ec2f552dd Self-constraint not included in frozen constraints b19175519de6fc40683527c1104ce2a513a03612 Merge branch '1.20' of https://github.com/snoyberg/cabal into 1.20 1c0d8aafbe42921baa56fc36383f34763f69d327 Revert "Remove redundant network constraint" 58517f76cb2ccb33c007da596ede265f1192d3b8 Remove redundant network constraint a747778c25bd339fed9c9a7c77eb3adbf0f162e0 Support for network-2.6 5fcf3d994e5c5a0f101ac04e092a8beedadcdc8d SavedConfig Monoid instance: make list fields work like Flags. 13f9051d34463037569becf6d3f736a8d8a4570e cabal update: use sandbox config file #1884 93aba465d35d03b29b1d9bd3a456815272a38a41 Revert 97c6a72984931f4ccf628736024d3459a033af6c. aa0a6979f3223387aae830cf1d21b2c21978d767 Read installed package info file as UTF-8

1 1

Including Cabal-1.18.1.5 in GHC 7.8.4
by Johan Tibell 12 Dec '14

12 Dec '14

I'm going to make a bugfix release on the Cabal 1.18 branch the next few days. The release candidate is already out. Here are the commits: e4660ff17f923e999080e21a20062d0df8d24bb6 The download dir on haskell.org moved fb3db6313b43632fdc9d598140b3eb5a681eb90b Bump Cabal version number to 1.18.1.5 12a698b6db8a2ca55367c54611a269048f4cef7b Build C sources with -fPIC when GHC is using dynamic libraries. The only one of interest is that we now pass -fPIC when needed. Should we include this bugfix release in the GHC release? It's quite difficult for some users to upgrade from the Cabal version that ships with GHC so included the newest one makes sense. P.S. I'm looking to make a 1.22 release soon as well, for inclusion in GHC 7.10. -- Johan

1 0

RE: [Diffusion] [Build Failed] rGHC37b3646c9da4: Testsuite wibbles from constraint-solver improvements
by Simon Peyton Jones 11 Dec '14

11 Dec '14

This is a single stat failure in haddock.base; doesn't happen for me. Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 10 December 2014 18:48 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHC37b3646c9da4: Testsuite wibbles | from constraint-solver improvements | | Harbormaster failed to build B2572: rGHC37b3646c9da4: Testsuite wibbles | from constraint-solver improvements! | | USERS | simonpj (Author) | GHC - Testsuite (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHC37b3646c9da4 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Testsuite

2 1

-O/-O2 causes program to run too slow
by David Spies 10 Dec '14

10 Dec '14

I have a program I wrote to submit for the Car Game problem on Kattis: https://open.kattis.com/problems/cargame but it runs over the 5-second time-limit I downloaded the test data and found that on GHC 7.8.3, if I switch from -O2 to -O0, it runs three times faster (almost certainly fast enough for Kattis to accept). Can someone tell me what's going on? Is this a bug?

3 4

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