December 2014 - ghc-devs

Random holiday fun: Vote for buildbot naming conventions!
by Austin Seipp 07 Jan '15

07 Jan '15

Hi *, Everyone has been working hard getting things ready for the branch/RC later this week - and that's really appreciated! As always, GHC wouldn't be what it is without you. But it's the holidays - that's stressful for some, and real time consuming for others. So to keep things light and a little interesting, and if you have a minute as an experiment, I'd like to ask you all something: What naming conventions should we use for GHC buildbots? We've been adding more bots recently, and we've just gotten hold of some new hardware this week. Currently, GHC buildbots don't have any reserved name or identifier, or DNS entries. I'd like to change that - we mostly refer to them by IP, but this is annoying A) to remember and B) to tell other people. We'll likely begin to lease out these machines to developers so they can test and debug - meaning they'll be mentioned more. I'd like to propose a theme for naming buildbots - this theme would be used to populate DNS entries under the *.ghc.haskell.org domain. The question is: what naming convention do we use? So I created a poll for this. You can see that poll and vote for your favorite options on Phabricator: - https://phabricator.haskell.org/V3 It's an approval vote rather than a plurality; so feel free to select multiple choices. The winner with the most votes will get selected. Note: the selection of options is relatively random and pre-selected; there is an upper limit on the number of choices - 10 max - so I merely picked some categories I thought would work and be generic enough. I imagine this vote will be open for about a week or so. I'd like it if developers could vote on their favorites, or simply leave comments on the vote for further suggestion - we could institute a vote with better names. Thanks all - and be sure to have happy holidays. P.S I did not know RFC 1178 existed before today. Seems like there's one for everything... -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 2

Bash completion in GHC 7.10
by Lennart Kolmodin 07 Jan '15

07 Jan '15

Hi everybody! TL;DL GHC 7.10 will have better bash completion, try it out! I'd like your help to verify the categorisation of DynFlags into ghc / ghci / shared or hidden flags. I've been working on improving the command line completion support in GHC 7.10. The main idea is that it should be more convenient to use GHC from the command line, without knowing all the flags by heart. You should be able to partly type a flag and then hit TAB twice to display the possible completions. For example; $ ghc -f<TAB><TAB> If you'd like to try it out, here's what you need to do; $ cd ghc-head $ source completion/ghc.bash Et voilà! Your bash shell will now have these super powers! There's a README <https://github.com/ghc/ghc/blob/master/completion/README> with details for a permanent setup. End users should ultimately not have to do anything to get this working. Linux distributions, and packages for other OSs are responsible for copying the required file to the right location. GHC had some basic support for command line completion even before my work, but now it also includes two significant changes compared to GHC 7.8; - "ghc" and "ghci" has different completions. - GHC 7.10 will ship and maintain the necessary bash components (and the scripts you contribute for other shells!). To support different completions for ghc and ghci, the DynFlags have been annotated with which mode the flags works. How this works has been documented under "Note [Supporting CLI completion]". Essentially all flags have been divided into four groups; - Flags only useful for ghc - Flags only useful for ghci - Flags useful from both ghc and ghci - Flags that should be invisible I've made this categorisation best I could, but it'd be nice to have another few pair of eyes glance through the flags. The separation of flags is well contained within the DynFlags module, please have a look! https://github.com/ghc/ghc/blob/master/compiler/main/DynFlags.hs The work was implemented in D337 <https://phabricator.haskell.org/D337>, D532 <https://phabricator.haskell.org/D532> and D536 <https://phabricator.haskell.org/D536> and is tracked in trac #9259 <https://ghc.haskell.org/trac/ghc/ticket/9259>. Regards, Lennart

4 4

Compiling nofib-analyse
by Simon Peyton Jones 05 Jan '15

05 Jan '15

When building nofib-analyse (in nofib), I get /home/simonpj/local/bin/ghc -O -cpp --make Main -o nofib-analyse Main.hs:14:18: Could not find module 'Text.Html' Use -v to see a list of the files searched for. There are rather a lot of HTML packages. Which one is needed? Does this meant that it's essential to install this package before running nofib, a manual step? I wonder if it'd be better to remove the HTML dependency, or make it optional? Simon

2 4

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