- ghc-devs - Haskell.org

Notes from Ben's "contribute to ghc" discussion
by Simon Peyton Jones 27 Sep '16

27 Sep '16

Friends Here are the notes I took from session 2 of the Haskell Implementors Meeting. The bolding is my choice of emphasis. Simon * Doc bugs. Two kinds o Typos. Friction stops me o Explanations needed e.g. read/show * Lightweight pushes * Make user manual into its own repo, to make it easier to take pull requests. But that makes it harder when making synchronised changes to GHC and user manual. * Auto-push: Ability to push to Phab and have it committed automatically if it validates. * Style guides. Is having a defined style solving a problem we don't really have? One piece of guidance: adhere to the style of the surrounding code. Low priority. * Docker images. We should have one. * Remove old documentation! * Cross compilation is difficult. * Have a GHC StackOverflow on haskell.org (Jacob Zalewski jakzale(a)gmail.com<mailto:jakzale@gmail.com> offers to do this! - thank you). It has a useful new Documentation feature. Eg this would be good for "how do I look up a RdrName to get a Name... there seem to be six different functions that do that".

17 48

Adding ConApp to Core
by Simon Peyton Jones 27 Sep '16

27 Sep '16

Andres, Richard, Stephanie The more I think about our idea of introducing ConApp the more I like it. I wrote it up in a ticket https://ghc.haskell.org/trac/ghc/ticket/12618 Simon

4 5

Improving the contributing to ghc experience
by Moritz Angermann 27 Sep '16

27 Sep '16

Friends, as you all have seen over the last few days, making the contributing to ghc experience easier for those who have not yet contributed to ghc, is a topic of interest to many of us. I’d like to thank Edward Z. Yang for seizing the opportunity to convince us to test drive the ghc-proposal process for this as well. Hence I went ahead and created the proposal with the help of others! So far it’s basically a small collection of what was mentioned on the mailing list. The hope is that facilitating the discussion though the ghc-proposal process would produce a coherent set of proposed changes and help making this a reality. I henceforth invite you to add your comments, critique and suggestions to the proposal that can be found at https://github.com/ghc-proposals/ghc-proposals/pull/9 Cheers, Moritz

3 4

Re: Notes from Ben's "contribute to ghc" discussion
by Matthew Pickering 26 Sep '16

26 Sep '16

Thank you for this comment Anthony. I thought about it over the last day and think you have it spot on. This is the key sentence: > The truth is that it what I complained about is *not a problem* > for GHC devs in so far as they are happy doing GHC development! It seems that the point that you are getting at is that currently the development process is heavily optimised for existing developers. There are quite a few moving parts but once you get a handle on them all it works well for me at least. The argument seems to be that we should (much) more heavily optimise for new contributors. (I think this is what Chris is saying as well). What I am trying to say is that we should meet in the middle. We should keep using phabricator as for regular contributors github is too painful to use for a project of GHC's size (as rust exemplifies with the custom bots). In order to improve the newcomer's experience it would be beneficial to consolidate as much as possible to one domain so that new contributors have only one place to look. Does this sound sensible to you? I would also like to take this chance to apologies to Chris for cutting off the discussion we were having. I would appreciate it if you would directly respond to the suggestions in this message. Matt On Sun, Sep 25, 2016 at 2:13 AM, Anthony Cowley <acowley(a)seas.upenn.edu> wrote: > On Sat, Sep 24, 2016 at 8:17 PM, Matthew Pickering > <matthewtpickering(a)gmail.com> wrote: >> I think this comment is useful because it highlights the point that it >> isn't very clear what "the point" even is. >> > [snip] >> >> Ultimately, I'm not sure what exactly what the point is. I read posts >> like this ( http://www.arcadianvisions.com/blog/2016/ghc-contributing.html >> ) and find myself disagreeing with almost every point. The comments in >> the reddit thread provide most of the refutations. The post doesn't >> address the >> fact that the feature was a small syntactic change which as erik >> pointed out, it perhaps the most difficult change to integrate as it >> must certainly pay it's way. > > > Matthew, if you are going to claim that you champion the concerns of > new contributers, you must do more than dismiss criticism without > offering a single word of reply. As I was involved in the discussion > you linked and remember it very differently than you, I went back to > try to understand what you possibly could have read. The top-level > replies are: > > - Me clarifying that I like GHC > - Someone who likes arc and notes, but hates the build system > - Someone who argued that a syntactic change would be the "deep end of > the difficulty pool" because they apparently did not realize the patch > was already done. > - Someone arguing that consistent style is not important > - A strangely worded suggestion that there exist refutations but it > would be inappropriate to mention them > - Agreement that GHC dev is off-putting > - Agreement that GHC dev is off-putting > - GHC is a great compiler > - Someone who likes GHC dev > - A pro GitHub post > - Someone complaining about how I was treated > > So, you read those comments in response to a specific, itemized, > literally bullet-pointed complaint that getting changes into GHC by an > outsider requires an ill-defined marathon of mailing lists and forums > in which GHC devs do not participate very much, and what you took away > from it was that the post was largely refuted. > > GHC is a fine research compiler and several people do tremendous work > on it. But please do not keep asking what the problem is if you are > going to completely ignore it when it is written down time and time > again. The truth is that it what I complained about is *not a problem* > for GHC devs in so far as they are happy doing GHC development! > Mystery solved, we can all move on with our lives productively using > GHC or contributing to it. Chris's reaction to the title of the talk > is entirely understandable to me, as I had interpreted it the same > way. > > Anthony

1 0

Solaris feature_tests.h
by Ben Gamari 26 Sep '16

26 Sep '16

Hi Karel, A few months ago we reverted a cleanup [1] to PosixSource.h due to breakage on Solaris. I believe I have found [2] a build log from a failing build, but sadly it's far from clear what is going on. Do you suppose you could send us your /usr/include/sys/feature_tests.h? I suspect this will shed some light on what has gone wrong. For the record, I've opened #12624 to track this issue. Cheers, - Ben [1] https://git.haskell.org/ghc.git/commitdiff/cac3fb06f4b282eee21159c364c4d08e… [2] http://haskell.inf.elte.hu/builders/solaris-amd64-head/573/10.html

2 1

Custom warning suppression
by David Feuer 24 Sep '16

24 Sep '16

Currently, the only way to suppress custom warnings and deprecations is with -fno-warn-warnings-deprecations, which is a rather large hammer. I see two ways we can improve this, and I propose that we should do both. 1. Per-binding suppression Add -fno-warn-binding, -fno-deprecate-binding, -fwarn-binding options, and -fdeprecate-binding options. These would take the (optionally qualified) name of a binding and control warnings tied to it. So if you invoked -fno-warn-binding "sillyFunction", then GHC would not warn you about the silliness of anything named sillyFunction. -fno-warn-binding "Data.Silly.sillyFunction" would limit the suppression to the silly function in Data.Silly. -fno-deprecate-binding would refrain from emitting deprecation warnings for the binding in question. -fno-deprecate-binding would presumably imply no-warn-binding, since someone who doesn't care that a function is going to be removed probably also doesn't care what else is wrong with it. 2. Named warning classes I'd like to add an optional "warning class" to the WARNING pragma, preceding the warning description. This would be a short string indicating what sort of warning is involved. This would be totally free-form, but the documentation would suggest a few conventional options such as "partial" and "slow". Then whole warning classes could be controlled with -fno-warn-class and -first-class.

4 3

RE: Test T12504 on Windows
by Richard Cook 21 Sep '16

21 Sep '16

Thanks! Yes, I did mean to reply all. -Richard Sent via the Samsung Galaxy S7 edge, an AT&T 4G LTE smartphone -------- Original message --------From: lonetiger(a)gmail.com Date: 9/20/16 6:03 PM (GMT-08:00) To: Richard Cook <rcook(a)rcook.org>, Simon Peyton Jones <simonpj(a)microsoft.com>, ghc-devs(a)haskell.org Subject: RE: Test T12504 on Windows I believe you forgot to press Reply-All Richard. In any case a fix is up at https://phabricator.haskell.org/D2537 Sorry, should have caught this during review. Tamar From: Richard Cook Sent: Tuesday, September 20, 2016 23:35 To: Phyx Subject: Re: Test T12504 on Windows Dear All, This is the test case that was added to validate the fix to hsc2hs. Here's the commit that added the test case: https://git.haskell.org/ghc.git/commitdiff/76286af5c621f032c4afab1f26b992e8… Output on Windows should include backslashes, other platforms should use forward slashes. This is keyed off the WINDOWS Makefile variable. -Richard On Tue, Sep 20, 2016 at 3:10 PM, Phyx <lonetiger(a)gmail.com> wrote:The new output is correct. hsc2hs was patched to fix the error messages it gives. We missed a test it seems. I'll update the test output when I get home. Thanks Simon, Tamar On Tue, Sep 20, 2016, 23:06 Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org> wrote:Test hsc2hs/T12504 is failing thus on Windows. Something path-y.Simon -{-# LINE 1 "T12504/path/to/T12504.hsc" #-}-{-# LINE 2 "T12504/path/to/T12504.hsc" #-}+{-# LINE 1 "T12504\\path\\to\\T12504.hsc" #-}+{-# LINE 2 "T12504\\path\\to\\T12504.hsc" #-}*** unexpected failure for T12504(normal)_______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

RE: Test T12504 on Windows
by lonetiger＠gmail.com 21 Sep '16

21 Sep '16

I believe you forgot to press Reply-All Richard. In any case a fix is up at https://phabricator.haskell.org/D2537 Sorry, should have caught this during review. Tamar From: Richard Cook

1 0

Test T12504 on Windows
by Simon Peyton Jones 20 Sep '16

20 Sep '16

Test hsc2hs/T12504 is failing thus on Windows. Something path-y. Simon -{-# LINE 1 "T12504/path/to/T12504.hsc" #-} -{-# LINE 2 "T12504/path/to/T12504.hsc" #-} +{-# LINE 1 "T12504\\path\\to\\T12504.hsc" #-} +{-# LINE 2 "T12504\\path\\to\\T12504.hsc" #-} *** unexpected failure for T12504(normal)

2 1

building ghc-8.0 branch on Win10
by Josh Berman 19 Sep '16

19 Sep '16

Hi, I was able to build the "master" branch of ghc 8.0.1 using the instructions found here: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows When I switched to the "ghc-8.0" branch, though, I get the following error: configure: error: > You've selected: > BUILD: x86_64-w64-mingw32 (the architecture we're building on) > HOST: x86_64-unknown-mingw32 (the architecture the compiler we're > building will execute on) > TARGET: x86_64-unknown-mingw32 (the architecture the compiler we're > building will produce code for) > BUILD must equal HOST; that is, we do not support building GHC itself > with a cross-compiler. To cross-compile GHC itself, set TARGET: stage > 1 will be a cross-compiler, and stage 2 will be the cross-compiled > GHC. Anyone know off the top of their heads what the issue is? Thanks, - Josh Berman

5 7