September 2016 - ghc-devs

Cross-compiling Template Haskell via -fexternal-interpreter and IPC
by Alberto Valverde 30 May '17

30 May '17

Hello, I'm trying to put together a GHC 8.0.1 cross-compiler with Template Haskell support. Initially to target Windows (32bits) from a Linux host but a similar procedure should enable to target other platforms too. I'd like to contribute the patches back so I'm asking for advice on how to implement it in order to increase the chances of them being accepted. I've managed to get a working stage 1 cross-compiler with some patches which correctly builds all stage1 libs and GHC + stage 2 compiler and ghc-iserv.exe. However, compiling TH by using wine and ghc-iserver.exe fails because the file descriptor ids that GHC passes as arguments to "wine ghc-iserv.exe" don't make sense in the emulated windows world. I've hacked around this to test the feasibility of the approach by using stdin/stdout instead of creating new pipes and, surprisingly, managed to cross-compile a simple Template Haskell program. I'm considering using a socket for communicating between both processes as a more permanent solution but this would incur in a dependency on the "network" package. Would this be acceptable? Named pipes have also crossed my mind but I'm not sure how well they're supported by wine. Thanks for your attention. Alberto P.S: Code is in the "cross-mingw-hacks" branches of these repositories and is based on the ghc-8.0.1-release tag: https://github.com/albertov/ghc https://github.com/albertov/hsc2hs A Docker image script here that builds it is here: https://github.com/albertov/ghc-cross-compiler-windows-x86

6 11

GHC 8.0.1-rc4 source tarball availability
by Ben Gamari 15 May '17

15 May '17

tl;dr: If you would like to produce a binary distribution for GHC 8.0.1-rc4 then let us know, grab the source distribution and start building. The binary distributions will be all released one week from today. Hello GHC packagers, I am happy to announce the release of the 8.0.1-rc4 source distribution to binary packagers. This release should resolve all of the issues noted in the release candidate 3 announcement. You will find the usual artifacts at http://downloads.haskell.org/~ghc/8.0.1-rc4/ For this candidate we are again following our new release policy [1], with a one-week delay between the release of the source and binary distributions. The goal of this policy is to give all platforms the opportunity for support from the first day of a release. If all of the expected binary releases are submitted before the week-long delay has elapsed, we will move forward with the release of the binaries on an accelerated schedule. It would be appreciated if you could reply to this message confirming that you intend to offer a binary distribution this release. Otherwise, let either Austin or I know if you have any trouble building your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case we encounter unexpected issues but all of my builds with this tarball thusfar have gone quite well. Good luck and thanks for all of your work! Cheers, - Ben [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html

12 75

Improving trac notifications
by Matthew Pickering 13 Feb '17

13 Feb '17

I subscribe to the ghc-tickets[1] mailing list which provides updates to all trac tickets. This is very useful, however when a ticket description is updated the whole description is included in the email which makes it hard to see what actually changed. The web interface shows a nice diff[2] of the changes, I think it would be good if emails could also include a diff rather than the current quite useless output. After a bit of investigation, it appears that the easiest way to achieve this is apply a simple patch to our copy of trac. The current format is hard coded on line 558 in this module, it seems easy to modify this section to instead provide a diff. http://www.edgewall.org/docs/trac-trunk/epydoc/trac.ticket.notification-pys… There is also already a module which has the diff operations implemented which could be used. http://www.edgewall.org/docs/trac-trunk/epydoc/trac.versioncontrol.diff-mod… Another option would be to use something like the `AnnouncerPlugin`[3] but that seems like much more work and would still require someone to write a custom formatter. Any thoughts? Matt [1]: https://mail.haskell.org/mailman/listinfo/ghc-tickets [2]: https://ghc.haskell.org/trac/ghc/ticket/10873?action=diff&version=6 [3]: https://trac-hacks.org/wiki/AnnouncerPlugin

3 8

Inlining Wiki Page
by Matthew Pickering 13 Jan '17

13 Jan '17

Dear Devs, I've spent the last day looking at the inliner. In doing so I updated the wiki page about inlining to be a lot more useful to other people wanting to understand the intricacies and problems. https://ghc.haskell.org/trac/ghc/wiki/Inlining This looks like the perfect place for a newcomer to start working on GHC. The inliner is quite well contained, there are lots of open tickets with well-specified aims and lots of investigatory work to be done. So the purpose of this email is: 1. Please tag any tickets relevant to inlining/specialisation with "Inlining" 2. Any newcomers keen to get involved should read the wiki page and see if they can tackle one of the tickets there. Matt

3 3

timings for individual compiler passes (in rc3)
by Johannes Waldmann 08 Dec '16

08 Dec '16

Hi. There is this (closed) https://ghc.haskell.org/trac/ghc/ticket/11653 and it's landed in 8.rc3. Thats good, and I want to make an effort to use this. But how? Just "-v2"? This gives a lot of noise. And no summary? Automatic analysis (of the output text stream, by external program) could be somewhat easier if each data set (starting at "\n!!!") did occupy exactly one line (currently, line breaks do occur). Anyway, what do I look for? Any large or suspicious number - but what exactly is "suspicious"? Anything above 1 second? Are we to believe the assignment of cost to pass, or could there be mis-attribution because result of an earlier pass is only forced later? Oh, and where do you want discussion of this feature (mailing list, ticket, ...)? I do hope that it will prove useful, in the sense that it could allow non-developers like me, or even build bots, to help spot performance problems. (E.g., you could advertise to enable this on travis. Yes, their build times depend on a lot of things, but still.) - J.W.

3 6

IRC: Logging #ghc with ircbrowse.net?
by Ben Gamari 25 Nov '16

25 Nov '16

Hello GHC developers, In the past we have relied upon Phabricator's Chatlog application to log the #ghc freenode channel. While Chatlog did its job admirably, it seems that Phacility has deprecated it with no proposed replacement. Thankfully, there appears to be no shortage of alternatives. In particular, Chris Done's ircbrowse.net seems to offer a great deal of functionality and already mirrors a number of other Haskell-related channels. Would anyone be opposed to adding #ghc to the list of channels monitored by ircbrowse.net? Cheers, - Ben

3 3

Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion
by Carter Schonwald 06 Oct '16

06 Oct '16

In writing the following huge wall of text, I had and idea that I think many folks would find palatable: What if simple small patches (such as hypothetical drive by doc patches ) had a mailing list where folks could email the simple / small patches as email attachments plus a body text that summarizes the patch, what it does, and why it's simple! What's even nice about this is its future proof and even agnostic to how the contributor made the change set locally! They could use mercurial or fossil for all we care. Or github. Or whatever! My personal stance is that ghc already way easier to contribute to / get involved with than it was 2-5 years ago. This is even more impressive when you consider the number of contributors (who aren't students) that focus on ghc work full time has actually DECREASED over that period. Community engagement / management is a totally orthogonal skill from contributing. Both take effort. Guiding new contributors requires both. My personal stance is that ghc keeps on getting better and getting more contributors. And occasionally chatting about ways to make things better that we have the bandwidth to do is something that should happen every year or so. Like a health checkup. I suspect one funnel for improvement may be figuring out how to make it more visible how many contributors / how actively deved various subsystems are. I feel like many new folks veer towards subsystems that are already actively worked on, which are often the ones that are both the most mature and thus hardest to easily contribute to! Perhaps I should see if there's an easy way to quantify that in a way that's easy to communicate to new contributors. There's an interesting data presentation challenge in that! I've definitely found that for new potential contributors that orienting them to focus on subsystem that's important but doesn't get much activity leads to more successful first contributions. But that requires someone actively helping orient folks, which I like to think I've helped out with at points in recent years. Making this something that's easy to point at / discover along with "newcomer tickets" might help a lot Tweaking the way we do tickets or code review I think doesn't change the important / fundamental challenges of doing a good patch for a project like ghc or llvm. (I think in some ways that llvm / gcc / clang are the right size projects to compare ghc against ) On Saturday, September 24, 2016, Brandon Allbery <allbery.b(a)gmail.com> wrote: > > On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty < > chak(a)justtesting.org > <javascript:_e(%7B%7D,'cvml','chak(a)justtesting.org');>> wrote: > >> Why are you so hostile to Chris? I don’t think that this is an >> appropriate way to treat somebody who is making a suggestion in good faith. > > > It may be in good faith. but it's not in good sense. There is a lot in the > background that made Rust's setup possible, and he's not bringing that to > the table, just assuming it'll somehow happen or that everyone else will > drop everything for the next few months and make it happen. And I feel like > he's being really pushy about committing already overworked people to this > --- and insisting that anyone opposed must have a hidden agenda or > otherwise cannot possibly have good reason to be opposed. It's not helpful > at all; it's basically a good way to stall ghc for the next few months at > least. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b(a)gmail.com <javascript:_e(%7B%7D,'cvml','allbery.b(a)gmail.com');> > ballbery(a)sinenomine.net > <javascript:_e(%7B%7D,'cvml','ballbery(a)sinenomine.net');> > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net >

15 31

GHC 8.0.2 status
by Ben Gamari 04 Oct '16

04 Oct '16

Hello everyone, The week before ICFP I was able to get the ghc-8.0 branch ready for an 8.0.2 release, which I intended to cut this week. In the intervening time an additional rather serious issue was reported affected Mac OS X Sierra (#12479). Since this issue affects the usability of GHC on the new OS X release, we'll be deferring the 8.0.2 release until it has been resolved. While there appears to be an actionable path forward on this ticket, we will need someone with an affected machine and an understanding of GHC's use of dynamic linking to step up to implement. Otherwise it looks like the release will be delayed at least until October 9, when darchon has time to have a look. Sorry to be the bearer of bad news! Cheers, - Ben

4 3

Getting rid of -XImpredicativeTypes
by Simon Peyton Jones 04 Oct '16

04 Oct '16

Friends GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to support impredicative polymorphism. But it is vestigial.... if it works, it's really a fluke. We don't really have a systematic story here at all. I propose, therefore, to remove it entirely. That is, if you use -XImpredicativeTypes, you'll get a warning that it does nothing (ie. complete no-op) and you should remove it. Before I pull the trigger, does anyone think they are using it in a mission-critical way? Now that we have Visible Type Application there is a workaround: if you want to call a polymorphic function at a polymorphic type, you can explicitly apply it to that type. For example: {-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-} module Vta where f x = id @(forall a. a->a) id @Int x You can also leave out the @Int part of course. Currently we have to use -XImpredicativeTypes to allow the @(forall a. a->a). Is that sensible? Or should we allow it regardless? I rather think the latter... if you have Visible Type Application (i.e. -XTypeApplications) then applying to a polytype is nothing special. So I propose to lift that restriction. I should go through the GHC Proposals Process for this, but I'm on a plane, so I'm going to at least start with an email. Simon

9 15

Re: How, precisely, can we improve?
by Moritz Angermann 02 Oct '16

02 Oct '16

Richard, thank you for trying to give this some technical basis. As someone who as contributed some tiny bugfixes to ghc, I found the process a bit cumbersome, yet manageable[1]. I’d however like to propose some concrete changes, and please excuse if these have been discussed and found to not be actionable. What I’d really like to see improved is the “multiple (web)services, multiple accounts” issue solved. As it is right now I need to have a github account (ghc-proposals, soon tiny PR against ghc), a trac account (for the wiki and issue tracker; which never seems to remember me), a phabricator account[2], likely a stack overflow account for questions and answers. On top of that I also need to be on a large set of mailing lists if I want to not miss anything, and an irc client and twitter client to tap into the most recent discussions. And there’s another wiki on haskell.org for which I would need to sign up and get an approved account. I’d like to see the following: 1. Unify the issue tracker and code review into phabricator. Hence *if* I want to contribute to the ghc codebase, I essentially only need a phabricator account[3]. And a simple one page website on haskell.org that runs me through the “Contributing to GHC” as in: > GHC Development is facilitated through phabricator. > > Please go to https://phabricator.haskell.org[4] and > create an account. > > If you want to report a bug, please file a bugreport through > the “Maniphest” module, you can find on the left. > > If you are looking for something to contribute, and browse the > Open Tasks at https://phabricator.haskell.org/maniphest/query/open/[5] > > Clone the GHC tree and build it > [ clone and build instructions here; note about stage2 pinning to reduce compile times and other > build system features ] > > Hack to your hearts content on GHC (you might get some quick responses > regarding ghc’s internals at irc://irc.freenode.net/ghc, as well as in > the ghc commentary at …[6], or the ghc-dev mailing list for which you > can sign up at ...) > > Validate your build [ plus instructions how to do so, and how to run > performance measurements on the changed ghc; if one is interested in > that as well ] > > Upload your patch to GHC using the arc command line tool. You will have > to set up your token during the first use, just follow the instructions. > > To upload your patch, commit your local changes; and run > $ arc diff origin/master > > arc will run a few linters against your diff, and provide you with a form > to fill in all the details regarding your patch. This form is usually > prepopulated with the commit messages from your local commits. > > During the review process you might have to update your diff. To do so > you can rebase your changes against the most recent master and/or add > additional commits to it; once you are done updating your patch, run > $ arc diff --update > > Once your diff has been accepted, someone with commit rights with “land” your > diff into the official ghc tree. And have this prominently liked from https://www.haskell.org/ under “Contributing” 2. Move the Wiki someplace else. I don’t know if the wiki in phabricator is any good, I’ve never used it. However, finding something in the ghc wiki has been more hit and miss for me than anything else. The built in search almost never reveals what I’m looking for, and resorting to a search engine only sometimes helps me find what I’m looking for. (This might totally be my fault). 3. Reduce the number of Mailing lists. I’m supposedly not on the haskell ml; so I missed https://mail.haskell.org/pipermail/haskell/2016-September/024995.html, and only saw it due to https://twitter.com/ezyang/status/780134457101516800. Are our MLs really that high volume that we need so many? 4. I like the idea of trivial pull requests to be accepted on GH as well. And I don’t see it as a big hurdle to ask someone to please be so kind and submit the patch through phabricator if it’s more involved with a link to https://www.haskell.org/contributing (see above). In conclusion I’d like to propose to reduce the fragmentation of tooling, and accept the status quo of what open source development seems looks like to many (github for code, stackoverflow questions (and documentation soon?)) as much as we can. Cheers, Moritz — [1]: I didn’t understand phabriactor and arc in the beginning, however today I appreciate the process phabricator and arc offer a lot! (Over PRs) [2]: for which you can actually use your bitbucket, github, twitter, … account. [3]: I will also need some access to the staging area, if I want to use that feature. [4]: Can we have http://phabricator.haskell.org redirect to https://phabricator.haskell.org? Instead of having both? [5]: I guess one could create some Trivial, Easy, Medium and Hard queries. [6]: This is currently scattered across the trac wiki. > On Sep 26, 2016, at 9:27 AM, Richard Eisenberg <rae(a)cs.brynmawr.edu> wrote: > > 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 > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

16 39