- ghc-devs - Haskell.org

Limiting size of global package database
by Michael Snoyman 31 Dec '14

31 Dec '14

tl;dr: Now that ghc (the library) doesn't depend on Cabal (the library), can we remove Cabal from the global package database installed with GHC? A problem that comes up quite a bit for users of GHC is conflicting package versions versus the version of a package that shipped with GHC. Some examples I've run into in the past include binary-0.7/GHC-7.6, and bytestring0-0.10/GHC-7.4. This is problematic for two reasons: 1. End users can be confused by having multiple versions of a package installed (one global, one user). I've seen at least a dozen questions on Stack Overflow, Reddit, and mailing lists about things like "ByteString is not bytestring-0.10.0.0-Data.ByteString.Internal.ByteString". 2. Any packages depended on by the ghc package can be very dangerous to upgrade, as then you're blocked from using the ghc package with the new version. This most often comes into play with doctest, though I've been affected by it on other projects as well. For both of these reasons, I think we should limit the number of packages included in the global package database. One seemingly small step we could do on that front is not include extraneous packages. In GHC 7.10rc1, that includes Cabal and xhtml: both packages are in the global package database, but could just as easily be removed from there and installed by users. The motivation for that would be to avoid problem (1) above. I realize that this change wouldn't affect point (2) above at all. Frankly, that's the issue that causes me quite a bit more trouble, and I'd love to see it resolved somehow, but it's unlikely to occur during the GHC 7.10 window. I'm writing this email now because I think there's a chance of resolving the smaller issue immediately, but I'd like to explore the wider issue of ghc-the-library dependencies for GHC 7.12. I've opened up an issue[1] on Stackage's issue tracker about this as well. [1] https://github.com/fpco/fpco/issues/3978

3 3

Cabal 1.22 RC now available
by Johan Tibell 30 Dec '14

30 Dec '14

I've just uploaded the Cabal-1.22.0.0 RC: http://johantibell.com/files/Cabal-1.22.0.0-rc.tar.gz I know it's a bit late, but if you could update the GHC 7.10 branch to use it (Git tag: Cabal-v1.22.0.0-rc) that would be great. When do you need the actual release to happen, so it's out before GHC 7.10? -- Johan

1 0

RE: Which of these commits to merge into ghc-7.10?
by Simon Peyton Jones 30 Dec '14

30 Dec '14

| As I'm currently merging some commits into the ghc-7.10 branch, which | of the following commits do you deem suitable for 7.10? | | - | http://git.haskell.org/ghc.git/commitdiff/a6f0f5ab45b2643b561e0a0a54a4 | f14745ab2152 See https://ghc.haskell.org/trac/ghc/ticket/3064#comment:21 | http://git.haskell.org/ghc.git/commitdiff/3e96d89b1d37a989b92a11587de2 | 9e347ef19328 Yes, this can go in | http://git.haskell.org/ghc.git/commitdiff/679a661890c9e5a218d8328658ca | e2b71d367024 This is ok too; should be no change in functionality. | http://git.haskell.org/ghc.git/commitdiff/c3394e0d2cce4bbaa034dc77473a | dd151781ef93 Not so sure here... I may not have gotten the change in the test harness right. Simon

1 0

Re: master: Eliminate so-called "silent superclass parameters" (a6f0f5a)
by Joachim Breitner 29 Dec '14

29 Dec '14

Hi Am Montag, den 29.12.2014, 18:40 +0100 schrieb Joachim Breitner: > Am Dienstag, den 23.12.2014, 16:29 +0000 schrieb git(a)git.haskell.org: > > commit a6f0f5ab45b2643b561e0a0a54a4f14745ab2152 > > Author: Simon Peyton Jones <simonpj(a)microsoft.com> > > Date: Tue Dec 23 15:39:50 2014 +0000 > > > > Eliminate so-called "silent superclass parameters" > > you may or may not have noticed that ghcspeed stopped producing results > since this commits. > > The reason is that running nofib fails: reproduced locally, filed as: https://ghc.haskell.org/trac/ghc/ticket/9938 Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

Fwd: [Haskell-beginners] ghc prelude home
by Carter Schonwald 29 Dec '14

29 Dec '14

seems we need to update the various ghc pages to point to 7.8.4? also maybe provide links to how folks can install cabal-install, though I guess the new haskell.org page will accomplish that too ---------- Forwarded message ---------- From: Christian Maeder <Christian.Maeder(a)dfki.de> Date: Mon, Dec 29, 2014 at 8:53 AM Subject: Re: [Haskell-beginners] ghc prelude home To: gale(a)sefer.org, The Haskell-Beginners Mailing List - Discussion of primarily beginner-level topics related to Haskell <beginners(a)haskell.org>, Antoine Latter <aslatter(a)gmail.com>, GHC Users Mailing List < glasgow-haskell-users(a)haskell.org> Cc: Doug McIlroy <doug(a)cs.dartmouth.edu> 23 December 2014 GHC 7.8.4 Released! https://www.haskell.org/ghc/ So 7.8.4 is out! Only the download subpage https://www.haskell.org/ghc/download is not updated yet. Also http://downloads.haskell.org/~ghc/latest/ still refers to http://downloads.haskell.org/~ghc/7.8.3/ (and has a funny 7.8.4 subdirectory). I send this also to glasgow-haskell-users to reach someone who can fix this. Cheers Christian Am 28.12.2014 um 22:28 schrieb Yitzchak Gale: > Yes, sorry, neither 7.8.4 nor 7.10.1 is actually out yet. > They are both release candidates, and will be out soon. > > Thanks, > Yitz > > On Sun, Dec 28, 2014 at 9:50 PM, Antoine Latter <aslatter(a)gmail.com> > wrote: > >> I don't think GHC 7.10 is out yet: https://www.haskell.org/ghc/download >> >> Although that page doesn't have 7.8.4 on it. >> > _______________________________________________ > Beginners mailing list > Beginners(a)haskell.org > http://www.haskell.org/mailman/listinfo/beginners > > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

GHC ARM64 calling convention
by Erik de Castro Lopo 28 Dec '14

28 Dec '14

Hi Luke, I found your llvm git tree which contains a patch [0] implementing the GHC calling convention for GHC. I also notice that: a) It has not been submitted upstream. b) It can be cherry picked and applied on top of current llvm HEAD. c) It can be applied to the llvm 3.5 tree and most importantly of all d) It actually works. With this patch applied to the llvm 3.5 tree, I was able to build an x86_64-linux to aarch64-linux cross-compiler which was able to build a simple "hello world" program that actually ran correctly. Are you in the process of trying to get this patch into LLVM? Do you need any help? Cheers, Erik [0] https://github.com/lukexi/llvm/commit/2d351c3d095e2fe42bc287947404d884841a1… -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

2 2

GHC 7.10.x migration guide
by Herbert Valerio Riedel 27 Dec '14

27 Dec '14

Hello! I've started collecting the most common compile-errors (and their respective fixes) I have encountered while compiling Hackage packages with GHC 7.10 in https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10 Feel free to contribute to this migration guide. HTH, hvr

1 0

Status and future of the LLVM backend
by Ben Gamari 27 Dec '14

27 Dec '14

I've written down some thoughts on the current status and future direction of the LLVM backend here [1]. Have a look when you get a chance. To summarize, * it seems like LLVM 3.4 chokes on the code produced by my 3.5 rework when the `$def` symbols are marked as internal * ARM is broken (again) due to a bug in the GHC calling convention implementation; an LLVM fix is waiting to be merged * I have code reworking TNTC for LLVM 3.6; unfortunately LLVM 3.6 support will likely need to wait until 7.12 * Austin's LLVM packaging proposal seems very much like the right way forward * Anticipating this proposal, I have started collecting [2] optimization passes Cheers, - Ben [1]: http://smart-cactus.org/~ben/posts/2014-11-28-state-of-llvm-backend.html [2]: https://github.com/bgamari/ghc-llvm-analyses

4 25

Failing tests: literals T5681 annotations
by Joachim Breitner 26 Dec '14

26 Dec '14

Hi, the CI weather is bad these days. Maybe a broken-window-effect? I currently observe Unexpected results from: TEST="literals T5681 annotations" Details: Compile failed (status 256) errors were: /tmp/ghc13786_0/ghc13786_5.s: Assembler messages: /tmp/ghc13786_0/ghc13786_5.s:26:0: Error: can't resolve `.rodata' {.rodata section} - `Main_zdwwork_info$def' {.text section} /tmp/ghc13786_0/ghc13786_5.s:46:0: Error: can't resolve `.rodata' {.rodata section} - `Main_work_info$def' {.text section} /tmp/ghc13786_0/ghc13786_5.s:66:0: Error: can't resolve `.rodata' {.rodata section} - `Main_main1_info$def' {.text section} /tmp/ghc13786_0/ghc13786_5.s:86:0: Error: can't resolve `.rodata' {.rodata section} - `Main_main_info$def' {.text section} /tmp/ghc13786_0/ghc13786_5.s:106:0: Error: can't resolve `.rodata' {.rodata section} - `Main_main2_info$def' {.text section} /tmp/ghc13786_0/ghc13786_5.s:126:0: Error: can't resolve `.rodata' {.rodata section} - `ZCMain_main_info$def' {.text section} *** unexpected failure for T5681(optllvm) =====> T8131(optllvm) 1496 of 4230 [0, 1, 0] Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: /usr/bin/ld: reopening annotations.o: No such file or directory /usr/bin/ld:annotations.o: bfd_stat failed: No such file or directory /usr/bin/ld: reopening annotations.o: No such file or directory /usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.22 internal error, aborting at ../../bfd/merge.c line 873 in _bfd_merged_section_offset /usr/bin/ld: Please report this bug. collect2: ld returned 1 exit status make[3]: *** [annotations] Error 1 *** unexpected failure for annotations(normal) Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: /usr/bin/ld: reopening literals.o: No such file or directory /usr/bin/ld:literals.o: bfd_stat failed: No such file or directory /usr/bin/ld: reopening literals.o: No such file or directory /usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.22 internal error, aborting at ../../bfd/merge.c line 873 in _bfd_merged_section_offset /usr/bin/ld: Please report this bug. collect2: ld returned 1 exit status make[3]: *** [literals] Error 1 *** unexpected failure for literals(normal) Does anyone feel responsible? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 4

ghc-7.10.1-rc1 build GC log messages
by Tuncer Ayaz 25 Dec '14

25 Dec '14

Building ghc-7.10.1-rc1, I see the following new messages: HC [stage 1] compiler/stage2/build/Dwarf.p_o <<ghc: 607994600 bytes, 145 GCs, 14478288/51516200 avg/max bytes residency (8 samples), 103M in use, 0.00 INIT (0.00 elapsed), 0.88 MUT (1.10 elapsed), 0.76 GC (0.77 elapsed) :ghc>> Is this a debug log or normal from now on during a ghc build? I don't mind, but I just wanted to make sure it's not a mistakenly enabled debug flag somewhere.

2 2