October 2014 - ghc-devs

arc land changes author
by Joachim Breitner 19 Dec '15

19 Dec '15

Hi, I was just about to apply a DR by David. First I ran $ arc patch D390 which put me on a feature branch. Then I reworded the commit with $ git commit --amend and then I tried to land it with $ arc land Luckily I also passed --hold... It even asked me if I want to land the commit although I am not the author: This branch has revision 'D390: Reorder GHC.List; fix performance regressions' but you are not the author. Land this revision by dfeuer? [y/N] y But it still put me in the author field: $ git show HEAD commit a387c359b99667ce55016de3816b5d9873a155db Author: Joachim Breitner <mail(a)joachim-breitner.de> Date: Wed Oct 29 08:17:05 2014 +0100 Reorder GHC.List; fix performance regressions Summary: Rearrange some oddly placed code. (and undid my commit message changes....) Did I do something wrong? Anyways, it said something along the lines of Cleaning up feature branch... (Use `git checkout -b 'arcpatch-D390' 'a3ceb0e7f44d53f728fb8bd0dfb4c97297818029'` if you want it back.) so with $ git commit --amend -C a3ceb0e7f44d53f728fb8bd0dfb4c97297818029 I was able to get the edited commit message with the right author back. 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 2

Automating GHC build for Windows
by Roman Kuznetsov 29 Mar '15

29 Mar '15

Hello *, As I am still new in this, I will ask. Were there any attempt to automate GHC build process on Windows with some kind of CI engine, like Hudson, Jenkins, etc.? It seems to be rather helpful to publish build results if not after each commit, but at least once every day. WDYT? -- Sincerely yours, Roman Kuznetsov

7 16

RE: cminusminus.org does not have a link to the spec
by Simon Peyton Jones 19 Jan '15

19 Jan '15

Sergei C-- was originally envisaged as a target language for a variety of compilers. But in fact LLVM, which was developed at a similar time, "won" that race and has built a far larger ecosystem. That's fine with us -- it's great how successful LLVM has been -- but it means that C-- is now used essentially only in GHC. I'm not sure where the original C-- documents now are; Norman can you say? (I do know that the cminusminus.org has lapsed.) The GHC variant of C-- is defined mainly by the Cmm data type in GHC's source code. It does have a concrete syntax, because some bits of GHC's runtime system are written in Cmm. But I fear that this concrete language is not well documented. (Simon Marlow may know more here.) Because GHC's Cmm is part of GHC, we are free to change it. Would you like to say more about the change you want to make, and why you want to make it? Is this relating directly to GHC or to some other project? Simon | -----Original Message----- | From: Sergei Trofimovich [mailto:slyich@gmail.com] | Sent: 14 September 2014 17:16 | To: Simon Peyton Jones | Subject: cminusminus.org does not have a link to the spec | | Hello Simon! | | I had a plan to tweak a bit "import" statement | syntax of Cmm in GHC. | | Namely, to distinct between | import some_c_function; | import some_c_global_variable; | | To try it I first attempted to find latest c-- spec | (to find some design sketches if available) at | | http://www.cminusminus.org/c-downloads/ | | But seems the links (and images?) have gone away | as well as rsync server described at: | | http://www.cminusminus.org/the-c-rsync-server/ | | Maybe you could forward it to site admins so they would | tweak links or point me to working copy. | | Apologies for bothering you on such minor | | Thank you! | | -- | | Sergei

4 6

Status updates
by Austin Seipp 18 Dec '14

18 Dec '14

Hi *, Here are some status updates: - I've merged the Applicative Monad patchset! Yay! Many thanks to Nathan Howell for helping me out in the end there. Please let me know if anything explodes horribly (I hope not). - Gabor has set up some build documentation for us based on HEAD, hooray! See here - http://haskell.inf.elte.hu/ - I still need to fix haskell.org/ghc to link to this properly (there may be other dead links, please let me know). - As I'm sure most of you were aware, it was a slow week due to ICFP & related events being most of last week. - As I'm also sure you were aware, Haskell.org suffered a lot of instability this past week. I've been focusing most of my efforts since about Thursday on this, since it's come and gone a lot and has needed some consistent monitoring. Unfortunately, it is not done yet, and there is still more work to be done. :( - ghc.haskell.org was migrated to a new server in the US as a part of this effort this weekend (send a thanks to Herbert). In general, you should notice nothing really new, but latency for UK citizens may be a bit higher than it was before now. - Now that Applicative/Monad is done, there are some more changes to 'base' that will happen (Bifunctors, Foldable/Traversable) that will need to happen. So I'm sure this discussion will start soon. - I still can't set up the Windows bot yet, sorry! Phabricator work is still not yet available upstream. Hopefully soon. - Sergei spent some time filing bugs that we should fix in the testsuite, because they fail --slow validate. I believe these are two of them: - https://ghc.haskell.org/trac/ghc/ticket/9567 - https://ghc.haskell.org/trac/ghc/ticket/9566 We'll probably need to fix these before we turn it on. Simon, these look like something up your alley... - For those who missed ICFP, Simon gave a nice status update for GHC, which is on YouTube: https://www.youtube.com/watch?v=Ex79K4lvJno&list=PL4UWOFngo5DW6nKDjK0UB5Oy9… -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

6 7

Trouble committing
by Andreas Voellmy 14 Dec '14

14 Dec '14

Hi GHCers, I just fixed a bug (#9423) and went through the Phab workflow. Then I did a fresh checkout from git and ran: $ git checkout master $ arc patch --nobranch D129 $ git push origin master as explained on https://ghc.haskell.org/trac/ghc/wiki/Phabricator, but on the last command I get this error: fatal: remote error: access denied or repository not exported: /ghc.git Maybe I just no longer have commit access to ghc? If so, could someone restore my access? Or I'd be happy if someone else can push the patch. Thanks, Andi

4 4

Proposal: Improving the LLVM backend by packaging it
by Austin Seipp 28 Nov '14

28 Nov '14

Hi *, A few days ago a discussion on IRC occurred about the LLVM backend, its current status, and what we could do to make it a rock solid part of GHC for all our users. Needless to say, the situation right now isn't so hot: we have no commitment to version support, two major versions are busted, others are seriously buggy, and yet there are lots of things we could improve on. So I give you a proposal, from a few of us to you all, about improving it: https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend I won't repeat what's on the wiki page too much, but the TL;DR version is: we should start packaging a version of LLVM, and shipping it with e.g. binary distributions of GHC. It's just a lot better for everyone. I know we're normally fairly hesitant about things like this (shipping external dependencies), but I think it's the only sane thing to do here, and the situation is fairly unique in that it's not actually very complicated to implement or support, I think. We'd like to do this for 7.12. I've also wrangled some people to help. Those people know who they are (because they're CC'd), and I will now badger them into submission until it is fixed for 7.12. Please let me know what you think. PS. Joachim, I would be particularly interested in upstream needs for Debian, as I know of their standard packaging policy to not duplicate things. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

8 20

small `arc` victory -- commit message not changed
by Richard Eisenberg 10 Nov '14

10 Nov '14

I just revised a Phab revision using `arc`, and it all worked swimmingly, doing exactly what I wanted, even though this was non-trivial. I describe the process below, and am happy to add to the Phab wiki page, but wanted to check here first to make sure I wasn't making an invisible dreadful mistake. Here's my story: - I had done a few edits in TcSplice and posted the (boring) revision D359. - Austin and Harbormaster both had good suggestions for me. - I spent a week completing other tasks. - I rebased my WIP branch against master. This worried me about what Phab might think. - I incorporated the suggestions. As is my usual workflow, I then rebased to integrate these changes into my original commits. As previously discussed, I think breaking a patch into separable commits is a Good Thing, and I curate these commits to be reader-friendly as I work. In the process, I de-Phabified my previous commit message, worried I was inviting demons, but determined to proceed. - I then updated my Phab revision with this: arc diff --allow-untracked --head HEAD --update D359 Explanation: --allow-untracked is because I have testsuite garbage floating in my working directory, and I'm never confident enough to modify .gitignore to ignore this garbage. `--head HEAD`, I think, is the magic bit. It specifies the *end* of the commit range to be included in the Phab diff. (The beginning was inferred to be origin/master, but can be specified without flags on the command line.) According to `arc help`, "This [flag] disables many Arcanist/Phabricator features which depend on having access to the working copy." Indeed, it was this warning which made me think `--head` was my friend. Of course, specifying `--head HEAD` on the command line seems redundant, but it still effectively stopped `arc` from touching my commits, thinking that this would break my git-ness. So, `arc` did the best job it could without touching my git information, which is exactly what I wanted. Results: My new code is now viewable and reviewable at D359. Despite all of my rebasing, the diffs are clean. You can even ask for the differences between my two revisions, and Phab does the right thing -- even though there's a week's worth of other commits that were rebased in. I'm sure Harbormaster is hard at work right now checking my changes. Fellow devs can offer nice feedback. And, I have retained control over my git structure. Hooray! Question: Have I done anything wrong here? By "wrong", I mean both in a technical sense (e.g., is Harbormaster now deeply confused?) and in a project-management sense (e.g., would this be a bad pattern for others to follow?). Should I put this workflow on the wiki? If no one tells me otherwise, I plan on using `--head` every time. Thanks, Richard

3 2

`arc` changes my commit messages
by Richard Eisenberg 09 Nov '14

09 Nov '14

Hi all, Is there a way to put `arc` into a read-only mode? Frequently while working on a patch, I make several commits, preferring to separate out testing commits from productive work commits and non-productive (whitespace, comments) commits. Sometimes each of these categories are themselves broken into several commits. These commits are *not* my internal workflow. They are intentionally curated by rebasing as I'm ready to publish the patch, as I think the patches are easy to read this way. (Tell me if I'm wrong, here!) I've resolved myself not to use `arc land`, but instead to apply the patch using git. Yet, when I call `arc diff`, even if I haven't amended my patch during the `arc diff`ing process, the commit message of the tip of my branch is changed, and without telling me. I recently pushed my (tiny, uninteresting) fix to #9692. Luckily, my last commit happened to be the meat, so the amended commit message is still wholly relevant. But, that won't always be the case, and I was surprised to see a Phab-ified commit message appear in the Trac ticket after pushing. I know I could use more git-ery to restore my old commit message. But is there a way to stop `arc` from doing the message change in the first place? Thanks! Richard

5 4

Wiki: special namespace for proposals?
by Yuras Shumovich 08 Nov '14

08 Nov '14

Hello, Would it be better to organize proposals under one namespace? Right now they belongs to root namespace, so title index ( https://ghc.haskell.org/trac/ghc/wiki/TitleIndex ) is hard to use. I was going to start new page describing language extension, but I don't want do increase entropy even more. What about creating special namespace, e.g. "Proposals"? Probably makes sense to divide if farther? Thanks, Yuras

9 11

Phabricator guidance
by Simon Peyton Jones 07 Nov '14

07 Nov '14

I suppose I will have to look at this. But I have no clue how to do so. D202 itself seems to be a very small patch (only ten lines or so), so presumably it applies on top of some other patch? But what? Someone said I could use arc patch D202 to apply the patch in my own tree, which is crucial for reproducing the error that Jan is stuck on. BUT the patch presumably applies to a particular commit, NOT the head of my current tree. But what is the base commit to which it applies? Does arc patch check out the base commit before applying? I can't find any documentation of 'arc patch'. Can anyone else? It would be good to document this workflow, since it's a very useful one. Thanks Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 06 October 2014 10:12 | To: Simon Peyton Jones | Subject: [Differential] [Commented On] D202: Injective type families | | jstolarek added a comment. | | Bump. Austin put this on feature list for GHC 7.10 and I'd really like | to this feature to make it into the next stable version of GHC. | Currently I'm not making *any* progress because of the "Not in scope" | errors. I've spent time looking at the code, seeing how things are | done in other places but none of this got me closer to solving the | problem :-/ Help? | | REPOSITORY | rGHC Glasgow Haskell Compiler | | REVISION DETAIL | https://phabricator.haskell.org/D202 | | REPLY HANDLER ACTIONS | Reply to comment, or !reject, !abandon, !reclaim, !resign, !rethink, | !unsubscribe. | | To: jstolarek, austin, simonpj | Cc: thomie, goldfire, simonmar, ezyang, carter

4 5