September 2016 - ghc-devs

RE: [Diffusion] [Build Failed] rGHC3f27237b0e6d: Make tcrun042 fail
by Simon Peyton Jones 30 Sep '16

30 Sep '16

rn003 is failing apparently (see below) But it’s fine on my machine. I don’t know how to see the actual error message. Any ideas? Simon From: noreply(a)phabricator.haskell.org [mailto:noreply@phabricator.haskell.org] Sent: 30 September 2016 17:31 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: [Diffusion] [Build Failed] rGHC3f27237b0e6d: Make tcrun042 fail Harbormaster failed to build B11120: rGHC3f27237b0e6d: Make tcrun042 fail! BRANCHES master USERS simonpj (Author) O7 (Auditor) COMMIT https://phabricator.haskell.org/rGHC3f27237b0e6d EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: simonpj, Harbormaster

3 3

RE: [Diffusion] [Build Failed] rGHC3f27237b0e6d: Make tcrun042 fail
by Simon Peyton Jones 30 Sep '16

30 Sep '16

Thanks Chris, that’s helpful. I got to your final link, but it didn’t show me what rn003 did. There seem to be two logs for some reason. I tried clicking “Unlimited” lines, but I still didn’t see a clear failure from rn003. Does it fail for anyone else? From: Christopher Allen [mailto:cma@bitemyapp.com] Sent: 30 September 2016 17:41 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: [Diffusion] [Build Failed] rGHC3f27237b0e6d: Make tcrun042 fail For some contrast, at work if I get notification that a build failed, if I click the Red X in the Github PR I go straight to the build and its output. (Screenshot attached of where it takes me) On Fri, Sep 30, 2016 at 11:39 AM, Christopher Allen <cma(a)bitemyapp.com<mailto:cma@bitemyapp.com>> wrote: It's a bit tricky, you have to follow these steps: Click the commit link in the email: https://phabricator.haskell.org/rGHC3f27237b0e6d Click the build link on the commit page: B11120: rGHC3f27237b0e6d: Make tcrun042 fail<https://phabricator.haskell.org/B11120>! Click another build link on the build page: [GHC] Linux/amd64: Continuous Integration<https://phabricator.haskell.org/harbormaster/build/13355/> Then you're here: https://phabricator.haskell.org/harbormaster/build/13355/ which has the build output. On Fri, Sep 30, 2016 at 11:36 AM, Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>> wrote: rn003 is failing apparently (see below) But it’s fine on my machine. I don’t know how to see the actual error message. Any ideas? Simon From: noreply(a)phabricator.haskell.org<mailto:noreply@phabricator.haskell.org> [mailto:noreply@phabricator.haskell.org<mailto:noreply@phabricator.haskell.org>] Sent: 30 September 2016 17:31 To: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Subject: [Diffusion] [Build Failed] rGHC3f27237b0e6d: Make tcrun042 fail Harbormaster failed to build B11120: rGHC3f27237b0e6d: Make tcrun042 fail! BRANCHES master USERS simonpj (Author) O7 (Auditor) COMMIT https://phabricator.haskell.org/rGHC3f27237b0e6d EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: simonpj, Harbormaster _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel…> -- Chris Allen Currently working on http://haskellbook.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbook…> -- Chris Allen Currently working on http://haskellbook.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbook…>

2 1

git question
by Simon Peyton Jones 30 Sep '16

30 Sep '16

Friends I have a batch of several commits lined up on my local machine, validated, and ready to push to the master. But one seems to have accidentally got diff --git a/utils/haddock b/utils/haddock index 073d899..a3309e7 160000 --- a/utils/haddock +++ b/utils/haddock @@ -1 +1 @@ -Subproject commit 073d899a8f94ddec698f617a38d3420160a7fd0b +Subproject commit a3309e797c42dae9bccdeb17ce52fcababbaff8a I did not want to meddle with Haddock. Question: how can I remove this change from my commit? I know how to do git rebase –interactive, and I can aske to “edit” that commit… but what then? Thanks Simon

4 5

A few technical suggestions
by lonetiger＠gmail.com 30 Sep '16

30 Sep '16

Hi All, I wanted to give my own thoughts/suggestions for things we could do on the short/medium term To make things a bit better. As a whole I may be one of the few who likes the current setup so I Propose enhancing the current toolset. I find the mail patch to mailing list approach of GCC et al quite cumbersome to be honest. And the discussion quickly becomes hard to follow as it branches lot. My proposals (sorry for the brevity, I can expand if needed): * Link phab to github Phabricator seems to have build in OAuth support. As you'll likely need a github account anyway, why not also support github logins? This would reduce the barrier of needing multiple accounts that is often a complaint. Would it be possible to maybe also extract the user's public key from github automatically? That would reduce one of the barriers as well. https://secure.phabricator.com/book/phabricator/article/configuring_account… * Link Trac to github - used to login (OAuth support) - readonly issues (to begin with?). we already have a code mirror, why not mirror more content. - sync issues back between the two - gives us an ability to see which github users an issue affects since they can then reference it. - updates the users when an issue is fixed since it will be closed on GH. - Gives us an indication of the importance of the tickets As a whole, I find Trac MUCH better for ticket triaging than Github or Phab, both of which seem to be quite bare and simple in what they provide. I am not in favor of ditching it. Also we have and continue to accept patches just uploaded to Trac as a diff. We tend to ask people to upload it to phab for better reviews and so it's attributed to them when we commit. Some don't (and we then do it ourselves), most due. If they don't need another login then I suspect almost all would. There's a (seemingly) actively maintained project that does all the above, could we leverage it? https://github.com/trac-hacks/trac-github * There is a trac plugin to generate a new section on trac /doc which allows you to render and edit documentations checked into repo. Could this be used to allow easier editing of non generated documentation? It's currently based on SVN, but maybe a git one exists too? https://github.com/trac-hacks/tracdocs * Newcomers - Expose newcomers information more by creating a new landing page - Clean up build instructions. For windows, I have scripts to automate setup. Often heard complain is that it is hard, but never hear why it's hard. In any case, my setup script for a 100% unattended build env setup for Windows are here: https://github.com/Mistuke/GhcDevelChoco/releases These are entirely self contained environments that can be removed by a simple rm -rf /. You can have as many as you want on the same machine without them interfering with eachother or with whatever else you might have done to your GHC already installed. It's not 100% production ready but it works and does so well. * Updated Phab reviewers list to be more automated - Assign reviewers next to the static list (as is currently done) to maybe also include significant contributors to that file? The reason for this is that currently it's always the same people reviewing patches. Their time is spread thin. Particularly on less popular platforms it basically comes down to 4 people. * Update trac linters and pre-commit linters to be the same. - particularly reject summaries that would be rejected on commit. Often when I try landing patches (especially from others) I have to edit the summary. Maybe arc should reject the diff if a push would fail? Also I want to say I love the summary document you have to fill in. It ensures useful information is there later when I have to find out why a change was made. So whatever we do, don't remove this. * Phab plugin to on signup ask for public key if none found. - It's recently been made a requirement to require a public key to push to phab. The error you get when you don't do this and try to push a patch is very very cryptic and unintuitive. Could we make a plugin that asks the user to upload a public key on trac if they haven't done so? Like a banner at the top? * Automate trac tickets - Particular on new tickets post a friendly reminder that if they want they can give it a hand in fixing it themselves. - Parse information added, in particular check if reproduction steps are there etc. - If stack is used, kindly ask if a repo without can be used. The amount of bug reports with stack is increasing and regardless of my own opinion on the tool, these reports are not very useful as is. - Maybe automatically CC people from a pool based on the information in the ticket? I tend to miss tickets because my filters are quite strict. Generally if the ticket doesn't mention my name, is directed at me or has "Windows" in the body somewhere it will skip my inbox. I review filtered tickets only once a week. - If a newcomer assigns a ticket to themselves, have trac automatically post links to useful pages: * how to setup build environment. * how to get help * assign a mentor? * after x amount of time with no progress, remind them again that help is available Kind Regards, Tamar

3 2

Re: Request for feedback: deriving strategies syntax
by Ryan Scott 28 Sep '16

28 Sep '16

Hello, everyone! Sorry for not being able to respond to some of the recent feedback. Well, it seems I'm at a bit of an impasse again. I originally changed "builtin" to "bespoke" because enough GHC devs voiced their displeasure (ranging from moderate to severe) with "builtin". I hoped that choosing "bespoke" would strike a happy medium where we could have a term that (1) reasonably describes its intended purpose, (2) wouldn't be highly misleading upon an initial glance, and (3) wouldn't be too off-putting to use as a reserved keyword. Unfortunately, I over-estimated how well "bespoke" meets criterion 3, since several people have _also_ voiced their displeasure with it! (Again, ranging from moderate to severe.) So we're back to square one, it seems. I don't want to push this patch without a general feeling of community consensus, but the patch is complete after all, with the exception of bikeshedding, so I'd like to try and come up with a colo(u)r that folks will be happy with so we can proceed and I can work on other things that need this feature. So, instead of "builtin" and "bespoke", I propose reconsidering an earlier suggestion of Elliot Cameron's: "standard". I had previously expressed reservations about "standard" before, since I felt it might be miscontrued as meaning "a Haskell standard" (e.g., the Haskell Report). But upon further thought, I have actually come to like the word "standard". Here's why: 1. It's simple. "Standard" is recognizable whether you speak American English, British English, or pretty much any other variant that I'm aware of. 2. It has precedent. A GHC error message already uses the phrase "standard derivable classes" to refer to Eq, Ord, Functor, etc. If we adopt "standard" as our keyword, then we could endow this phrase with a more precise meaning. 3. It reflects history. This deriving strategy (that I'm proposing to name "standard") was the very first deriving strategy that GHC supported (to my knowledge), so it makes sense to refer to this strategy as the "standard" one, since all other strategies were added later. 4. It's not too ambiguous. As opposed to say, "default" (which could be confused with -XDefaultSignatures, i.e., the anyclass strategy), I think that "standard" has a pretty obvious connotation in the context of deriving. There is the possibility of misinterpreting "standard" to refer to the Haskell Report, but that wouldn't be the worst misconception in the world to make, since several "standard derivable classes" are actually in the Haskell Report (whereas neither GeneralizedNewtypeDeriving nor DeriveAnyClass are). What does everyone think? Ryan S.

6 7

How, precisely, can we improve?
by Richard Eisenberg 28 Sep '16

28 Sep '16

Like many of you, I'm sure, I'm saddened by the occasional tone of the recent exchange about contributions to GHC. I'd like to move the conversation forward -- and I'd like to do so on a technical basis. So, I ask: How, precisely, can we improve? I think it would be best to have answers to this question start their own thread, as I expect several good answers to this question. As I ask this, I am not making the assumption that we cannot, nor is this meant to be rhetorical. I am asking a question in search of precise, technical answers. "Be more like Rust" is not an answer to this question, as it is imprecise. (I'm not at all maligning the overall goal of emulating a successful process. It's just that "be more like Rust" is not actionable.) "Accept PRs on GitHub" *is* an answer to this question, but one we have revisited several times in recent memory. (I believe https://mail.haskell.org/pipermail/ghc-devs/2015-September/009744.html is the most recent.) Perhaps we can revisit this yet again, but it would be great if new technical content can be injected into the debate. I hope the rejection of the proposal linked there is not considered "dismissive", as the proposal generated vigorous debate -- the opposite of dismissiveness. (For what it's worth, I'm weakly in favor of accepting PRs on GitHub. However, I have no experience setting up or maintaining infrastructure for an open source project and have happily deferred to those who have such experience and who have come out against this idea.) "Have process (X) for accepting new language features" *is* an answer to my question. This is in flight and I hope addresses the concern in the community. It seems to me that this step addresses the grievances described in "The Process" part of http://www.arcadianvisions.com/blog/2016/ghc-contributing.html "Have a formal mentorship system" *is* another answer to my question, and one I think we can readily adopt. Can you (for all values of "you") suggest a concrete model with a link? It seems to me that folks who ask for help get the help they need. But this surely requires the courage and wherewithal to ask for the help. Perhaps there is a better way to advertise our availability and desire to mentor. I, personally, have onboarded (or attempted to) several contributors and enjoy doing so. Though my ability to mentor wanes when I have gotten busy, I have always prioritized helping out the newest contributors, letting other, more confident actors' emails slip if necessary. If I have erred, I am sorry. "Don't be dismissive" is not an answer to my question, as it is both imprecise and not technical. The most recent thread indeed had posts that seemed quite dismissive, but these posts emanated from people with a variety of viewpoints. It was hardly GHC HQ (whatever that means). What, precisely, has been dismissed? It looks to me that we (regular GHC contributors) take the community's concerns seriously. Fixes may be slow in coming, but that's not dismissiveness. Of course I'm biased here, but I am truly and earnestly asking for clarification. Emboldened by the technical, respectful discussion recently on the merits (and usage patterns) of stack (starting at https://mail.haskell.org/pipermail/haskell-cafe/2016-September/124847.html) I look forward to a similarly technical, respectful discussion on our contribution process. Thanks for all that you (for all values of "you") do to help grow our community and make it stronger. Richard -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae <http://cs.brynmawr.edu/~rae>

2 1

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