Re: `arc` changes my commit messages
A diff per commit is not that bad, this is my usual workflow. Using 'git rebase -i' and 'edit' you can amend individual commits in a stack. The workflow is * git rebase -i oldest commit in the stack * 'edit' the commit you want to modify * modify away * arc diff * git commit --continue Landing is a bit more tricky though. 'arc patch D1234 arc land' is probably the easiest way, because you can't do arc land during a git rebase. Cheers, Simon On 21/10/14 14:46, Johan Tibell wrote: This is probably the biggest shortcoming of Phab. If you don't want this merging behavior you need to make a separate Phab review *per commit*. When I use arc I usually use git to rewrite the message after the review to something less messy. On Tue, Oct 21, 2014 at 11:04 AM, Richard Eisenberg e...@cis.upenn.edu mailto:e...@cis.upenn.edu wrote: 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 ___ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.10 STABLE freeze date
(Sorry for the late reply, was away Saturday.) This looks good to me. I'll try to review it on Monday. I will be spending a lot of time in Differential this week... On Fri, Nov 7, 2014 at 4:05 PM, Edward Z. Yang ezy...@mit.edu wrote: Hey Austin, Simon and I have been talking about fixing #8427 (https://ghc.haskell.org/trac/ghc/ticket/8427), but our current plan of action will involve interface file changes at least and maybe some invasive changes. A heads up! Edward Excerpts from Austin Seipp's message of 2014-11-07 13:35:38 -0800: Hi all, After some deliberation, we've decided that the STABLE freeze for 7.10 will happen in approximately two weeks, on November 21st. We're hoping to stick to this date closely, but do read below. This is perhaps a short time to freeze, but right now, we've only got a couple things we're planning on focusing on for the next few weeks. And these are really the major things we're waiting for. See below: - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 These are just: - D155, LLVM 3.5 compatibility, - D396 and D169, DWARF/source code note work. These are mostly in me and Simon's court to do another review round, but I think will be OK to get them in on time. - D168, Partial type signatures. The ball is in Simon's court on this one, but he's had several good rounds of discussion with Thomas etc from what I understand. Based on our discussions earlier this week, I think these all will make it just in time for the freeze. Nota bene: if there is *any* delay, it will be for these, as we picked them as the highest priority in our own views. It is unlikely we will delay any so people can sneak in a few other things. So, if you want something of yours in, you better get me, Simon Simon, Herbert, etc's attention pronto! That way we'll have time to get it in first. To make things easier, we'll also be pushing the lhs-hs conversion pretty soon so cherry picking/merges are easier, and do some other cleanups. And outside of that, we've still been having a healthy flow of bug fixes falling into the tree, which is great. So if you're just bugfixing, please keep doing so - we'll be pulling bugfixes into the tree continuously. We will also be pulling in submodule/library updates continuously, like we did for the 7.8 branch. Let me know if you have questions, objections, or really really really want something - but I won't be as nice as last time I'm afraid. ;) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.10 STABLE freeze date
Hi Iavor, Yes, feel free. Simon's work landed on Thursday(?), so you should be clear for landing. On Fri, Nov 7, 2014 at 10:15 PM, Iavor Diatchki iavor.diatc...@gmail.com wrote: Hello, I'd like to get the type-checker plugin code in 7.10. I've been waiting for Simon PJ to merge in his constraint solver changes in HEAD, which I believe is very close to happening, and then I'll redo my work on top of that. -Iavor On Fri, Nov 7, 2014 at 8:10 PM, Dr. ERDI Gergo ge...@erdi.hu wrote: On Fri, 7 Nov 2014, Austin Seipp wrote: And these are really the major things we're waiting for. See below: - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 These are just: - D155, LLVM 3.5 compatibility, - D396 and D169, DWARF/source code note work. These are mostly in me and Simon's court to do another review round, but I think will be OK to get them in on time. - D168, Partial type signatures. The ball is in Simon's court on this one, but he's had several good rounds of discussion with Thomas etc from what I understand. Hi, I'm almost done with implementing pattern synonym signatures (#8584): I have it fully working on my wip/T8584 branch, I just need to add some tests, and also come up with an acceptable syntax. I also hope to finish fixing #9732 / #9783 over the next couple days. Please let me know ASAP if there's anything more I'll need to do to get these into 7.10, because my schedule for working on GHC will be rather spotty for the next couple weeks. Bye, Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.10 STABLE freeze date
On Fri, Nov 7, 2014 at 10:10 PM, Dr. ERDI Gergo ge...@erdi.hu wrote: On Fri, 7 Nov 2014, Austin Seipp wrote: And these are really the major things we're waiting for. See below: - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 These are just: - D155, LLVM 3.5 compatibility, - D396 and D169, DWARF/source code note work. These are mostly in me and Simon's court to do another review round, but I think will be OK to get them in on time. - D168, Partial type signatures. The ball is in Simon's court on this one, but he's had several good rounds of discussion with Thomas etc from what I understand. Hi, I'm almost done with implementing pattern synonym signatures (#8584): I have it fully working on my wip/T8584 branch, I just need to add some tests, and also come up with an acceptable syntax. I also hope to finish fixing #9732 / #9783 over the next couple days. Great, thank you Gergo. Please let me know ASAP if there's anything more I'll need to do to get these into 7.10, because my schedule for working on GHC will be rather spotty for the next couple weeks. Bye, Gergo That's fine. Part of the reason the freeze period is so long this year is due to the expectation people may have some spotty availability. It is the holiday season, after all. I'll be regularly merging bugfixes etc, so it should not be hard to merge things later. (Also, the 7.10 branch will be much easier to build this time; a lot easier for everyone who might backport themselves.) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 7.10 STABLE freeze date
This is fantastic! On the iOS front I have D206 (fixing dead-strip) hanging in phabricator on the testsuite makefile, due do the libgmp.10 dependency. See https://phabricator.haskell.org/D206 I'd really like to have this get into 7.10 as well. So we do not need to disable deadstripping anymore for iOS targets. Cheers, Moritz On Nov 9, 2014, at 1:13 AM, Luke Iannini lukex...@gmail.com wrote: Hello, I've submitted a patch to finish the already-merged (but incomplete) ARM64 support that adds support for modern iOS devices https://ghc.haskell.org/trac/ghc/ticket/7942 Best Luke (I've also submitted a patch to LLVM to add an ARM64 GHC calling convention that is in review) On Fri, Nov 7, 2014 at 1:35 PM Austin Seipp aus...@well-typed.com wrote: Hi all, After some deliberation, we've decided that the STABLE freeze for 7.10 will happen in approximately two weeks, on November 21st. We're hoping to stick to this date closely, but do read below. This is perhaps a short time to freeze, but right now, we've only got a couple things we're planning on focusing on for the next few weeks. And these are really the major things we're waiting for. See below: - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 These are just: - D155, LLVM 3.5 compatibility, - D396 and D169, DWARF/source code note work. These are mostly in me and Simon's court to do another review round, but I think will be OK to get them in on time. - D168, Partial type signatures. The ball is in Simon's court on this one, but he's had several good rounds of discussion with Thomas etc from what I understand. Based on our discussions earlier this week, I think these all will make it just in time for the freeze. Nota bene: if there is *any* delay, it will be for these, as we picked them as the highest priority in our own views. It is unlikely we will delay any so people can sneak in a few other things. So, if you want something of yours in, you better get me, Simon Simon, Herbert, etc's attention pronto! That way we'll have time to get it in first. To make things easier, we'll also be pushing the lhs-hs conversion pretty soon so cherry picking/merges are easier, and do some other cleanups. And outside of that, we've still been having a healthy flow of bug fixes falling into the tree, which is great. So if you're just bugfixing, please keep doing so - we'll be pulling bugfixes into the tree continuously. We will also be pulling in submodule/library updates continuously, like we did for the 7.8 branch. Let me know if you have questions, objections, or really really really want something - but I won't be as nice as last time I'm afraid. ;) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs — Moritz Angermann +49 170 54 33 0 74 mor...@lichtzwerge.de lichtzwerge GmbH Freisinger Landstr. 25 85748 Garching b. München Amtsgericht München HRB 207882 Geschäftsführung: Moritz Angermann, Ralf Sangl USt-Id: DE291948767 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: 7.10 STABLE freeze date
I did this earlier this week. Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Iavor Diatchki Sent: 08 November 2014 04:15 To: Dr. ERDI Gergo Cc: ghc-devs@haskell.org Subject: Re: 7.10 STABLE freeze date Hello, I'd like to get the type-checker plugin code in 7.10. I've been waiting for Simon PJ to merge in his constraint solver changes in HEAD, which I believe is very close to happening, and then I'll redo my work on top of that. -Iavor On Fri, Nov 7, 2014 at 8:10 PM, Dr. ERDI Gergo ge...@erdi.humailto:ge...@erdi.hu wrote: On Fri, 7 Nov 2014, Austin Seipp wrote: And these are really the major things we're waiting for. See below: - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 These are just: - D155, LLVM 3.5 compatibility, - D396 and D169, DWARF/source code note work. These are mostly in me and Simon's court to do another review round, but I think will be OK to get them in on time. - D168, Partial type signatures. The ball is in Simon's court on this one, but he's had several good rounds of discussion with Thomas etc from what I understand. Hi, I'm almost done with implementing pattern synonym signatures (#8584): I have it fully working on my wip/T8584 branch, I just need to add some tests, and also come up with an acceptable syntax. I also hope to finish fixing #9732 / #9783 over the next couple days. Please let me know ASAP if there's anything more I'll need to do to get these into 7.10, because my schedule for working on GHC will be rather spotty for the next couple weeks. Bye, Gergo ___ ghc-devs mailing list ghc-devs@haskell.orgmailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Concrete syntax for pattern synonym type signatures
On Sun, Nov 9, 2014 at 2:11 PM, Simon Peyton Jones simo...@microsoft.com wrote: On this thread: * I'm strongly of the opinion that pattern signatures should start pattern P :: ...blah... Just like value signatures, the pattern name comes first, then a double colon. This has the benefit that it lets users logically continue exporting 'pattern Foo', which is a very nice syntax. The only downside is that the error message when users forget to turn on pattern synonyms is somewhat more baroque than it can be with the extra keyword shoehorned in, but the keyword is pretty awful looking. * One other possibility would be two = thus pattern P :: (Eq b) = (Num a, Eq a) = ...blha... If you wanted something which had a match-required part but no match-provided part, you'd end up with patter P :: () = (Num a, Eq a) = ...blah... which is a little odd, but perhaps no odder than pattern P :: ( | Num a, Eq a ) = ...blah... The nested (=) version has a certain appeal to it. It already parses. The trick is just in properly interpreting it, but users already interpret (Foo a, Bar b) = .. differently in different contexts, e.g. in class and instance declarations. They can adapt. -Edward | -Original Message- | From: Dr. ERDI Gergo [mailto:ge...@erdi.hu] | Sent: 09 November 2014 07:56 | To: Simon Peyton Jones | Cc: GHC Devs | Subject: RE: Concrete syntax for pattern synonym type signatures | | On Tue, 4 Nov 2014, Simon Peyton Jones wrote: | | pattern P :: forall tvs. (match-provided ; match-required) = tau | | The ; match-required part is optional, and the match-provided part | might be empty. So P1 and P2 would look like this: | | pattern P1 :: forall a. (; Num a) = b - (a,b) | pattern P2 :: forall a. (; Num a, Ord a) = a - a | | Doesn't the ';' look a bit like something that could be incidentially | introduced by some layout-aware syntax rule? Wouldn't, e.g., '|' be more | explicit as a separator? | | example: | | pattern P :: forall tvs. (Eq b | Num a, Eq a) = b - T a ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Reviving the LTS Discussions (ALT: A separate LTS branch)
Austin, thanks for starting this thread. I think David raises a lot of very important points. In particular, I don't think an LTS plan can be successful unless there's significant demand (probably from commercial Haskell users), and it would almost certainly require that those users make a commitment to do some of the work themselves. I think David's suggestion is probably a good place to start. For that matter, anyone who's interested could probably just fork the github repo, pull in patches they want, and work away, but it does seem a bit nicer/more efficient to be able to integrate with trac. John On Fri Nov 07 2014 at 11:45:34 PM David Feuer david.fe...@gmail.com wrote: GHC is an open source project. People work on it because 1. They enjoy it and find it interesting, 2. They need it to work well to support their own software, 3. They're trying to write a paper/get a degree/impress their peers, or, in very rare cases, 4. Someone pays them to do it. People are also willing to do some kinds of minor maintenance work because 5. They feel a sense of obligation to the community but this is not likely, on its own, to keep many people active. What does this have to do with LTS releases? The fact is that having people who want an LTS release does not necessarily mean that anyone else should do much of anything about it. If they don't really care, they're likely to half-build an LTS process and then get sidetracked. So what do I think should be done about this? I think GHC headquarters should make a standing offer to any person, group, or company interested in producing an LTS release: an offer of Trac, and Phabricator, and Harbormaster, and generally all the infrastructure that GHC already uses. Also an offer of advice on how to manage releases, deal with common issues, etc. But a promise of programming power seems likely to be an empty one, and I don't see the point of trying to push it. If someone wants an LTS release, they need to either make one themselves or pay someone to do the job. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Typechecker plugins: request for review and another workflow question
Hello, I just finished merging HEAD into the branch implementing constraint solver plugins (`wip/tc-plugins`), so things should be fully up to date. For ease of review, I squashed everything into a single commit: https://github.com/ghc/ghc/commit/31729d092c813edc4ef5682db2ee18b33aea6911 could interested folks (I know of SimonPJ, Richard, and Adam) have a look and let me know if things look reasonable? On a related note: I know that we are using phabricator for code review, but I don't know how to use it yet, so please let me know if I can do something to make the review easier. -Iavor ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Commit messages for WIP branches (Was: Question about `validate` workflow)
On Nov 9, 2014, at 2:42 PM, Joachim Breitner m...@joachim-breitner.de wrote: Am Samstag, den 08.11.2014, 22:33 -0500 schrieb Richard Eisenberg: I've stopped validating locally, allowing Travis to do it for me. If you use a `wip/...` branch and push to the main GHC repo, you can find build reports at travis-ci.org/ghc/ghc. Or, I'm sure if you clue Travis in, this can also work if you push to your own GitHub fork of GHC. of course this spams ghc-commits quite a lot. Which brings me to ask: why send email to ghc-commits for `wip/*` branch commits? I've personally gone back and forth between using the main GHC repo for my WIP because of precisely this issue. If there were no emails generated, I would surely always use the GHC repo -- it's easier for others to find my work, and tracking a branch in my head is easier than a separate remote and a branch. As it is, I'm always slightly embarrassed when I push to my `wip/rae` branch, causing other people to get emails about my internal GHC meanderings. But, I'm using GHC's repo now for better integration with Phab, for when Harbormaster pulls base commits. So, I propose: Do not send commit emails for commits to `wip/*` branches. What do we think? Thanks, Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Concrete syntax for pattern synonym type signatures
On Nov 9, 2014, at 2:11 PM, Simon Peyton Jones simo...@microsoft.com wrote: * One other possibility would be two = thus pattern P :: (Eq b) = (Num a, Eq a) = ...blha... I should note that I can say this in 7.8.3: foo :: Show a = Eq a = a - String foo x = show x ++ show (x == x) Note that I've separated the two constraints with a =, not a comma. This syntax does what you might expect. (I actually believe that this is an improvement over the conventional syntax, but that's a story for another day.) For better or worse, this trick does not work for GADT constructors (which is a weird incongruence with function type signatures), so adding the extra arrow does not really steal syntax from GADT pattern synonyms. Richard ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
