Re: Improving the Get Haskell Experience
On Mon, Jul 13, 2015 at 3:34 AM, Kosyrev Serge _deepf...@feelingofgreen.ru wrote: ..And so, I can't help but wonder.. what if the Stack authors would have applied their expertise to provide the same user experience they achieved.. ..but with Nix as an underlying technology? Backpack (very roughly, a Nix-like Cabal package mechanism) is still in development. Once it's out there, perhaps FPComplete will look into using it with Stack? -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: Backporting srcLoc to the GHC 7.10 branch
* There is some change you want to make to 7.10.2. I'm not sure precisely what it is. | The change would be to put the latest two commits from | | https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip | | on top of 7.10 branch. Aha. Now you say the top two commits I can see what you are talking about, namely the entire CallStack feature. Specifically https://github.com/nh2/ghc/commit/5cd10eb4b6eef06f53bbdcfae4b9f8f505ea522c | * The change is an API change, which we do not normally make. | But you argue that it will harm no one (why are you so sure?), | and you are confident that it will not break anything (why?) | | The API change is precisely at this commit. | | https://github.com/nh2/ghc/commit/d4e476817a7df449b71a2acc515b4d0fa6f8 | 9b6b It's much more than that! The main commit (the one you want) adds `CallStack`, `getCallStack` etc, as well as special treatment for implicit parameters of that type. That widens the API, which is certainly less disruptive than changing it. Let's see what Ben and Herbert have to say. Do any other ghc-devs, or Mark or Michael, have an opinion? Simon | | I never said that it will not harm anyone or that it will not break | anything. I only said that it is a small price to pay. | | The change is your own in the typechecker, a two SrcSpans turning into | RealSrcSpans. I think we can agree at least that it is not a large | change. I understand if it gets rejected on this basis regardless, I | am merely trying my chances. | | * FP Complete and Zalora specifically want this change. | Zalora = you? Who at FP Complete wants the change? | | Some of us at Zalora, yes. This thread of messages was created my FP | Complete and they did the backport. They even say that they'll include | the changes into their custom build of GHC and ship that to their | customers. So it seems like they'd want the change. The very first | message in this thread is Michael Snoyman asking if such backport | could make it into 7.10. | | Ben and Herbert are the guys you have to persuade if you really want | this. | I suspect it'll be more effective to open a ticket, milestoned for | 7.10.2, with specifics on it. Email gets lost; tickets don't. | | Noted, thanks. | | Thanks | | Simon | | | | -Original Message- | | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | | Mateusz Kowalczyk | | Sent: 06 July 2015 17:40 | | To: ghc-devs@haskell.org | | Subject: Re: Backporting srcLoc to the GHC 7.10 branch | | | | On 04/20/2015 05:29 PM, Niklas Hambüchen wrote: | | Hello everybody, | | | | I'm glad to announce that I performed the suggested backporting | as | | part | | of | | my work for FP Complete! | | | | With the help of Eric (thanks for your support in #ghc!) we now | | have | | this | | patch for 7.10 and 7.8. | | | | As promised, here are the commits: | | | | * https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc- | ip | | * https://github.com/nh2/ghc/commits/ghc-7.8.4-release-srcloc-ip | | | | You can see in the history that I only needed to cherry-pick | Make | | the location in TcLclEnv and CtLoc into a RealSrcSpan as a | | dependent | | commit, | | so the changes beyond the actual feature are fairly minimal. | | | | For 7.8, I had to do a little more cleanup, see the Use | wrapIPTc | | instead | | of coercionToTcCoercion on wrapIP commit. | | | | Regarding the commit of the feature itself, I had to do quite | some | | merge | | resolution, especially due to the (lack of) the -fwarn- | redundant- | | constraints patch https://github.com/nh2/ghc/commit/32973bf3 | | (alias | | but it | | was Christmas, so I did some recreational programming that went | | much further). | | However, the type checker had a strong opinion of what the right | | merge decision was, at least for the 7.10 backport; for 7.8 | there | | was an ambiguity (whether to return `Nothing` or `Just` in | | `interactDict`), | | which | | was resolved with Eric's help. | | | | Please be invited to review the two commits. | | | | We would like to make 7.8 and 7.10 binaries with this feature | | available | | as | | well, and will do so after getting a review! | | | | Niklas | | | | ___ | | ghc-devs mailing list | | ghc-devs@haskell.org | | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | | | | | | Hi all, | | | | In light of how small the actual backported changes are, I wonder | if | | it would be possible to include it in 7.10.2 (or .3 if we're doing | | that). I know that at first it was rejected but it was rejected | | before the diff existed. In practice, the only API change was two | | SrcSpans changing into RealSrcSpans inside the typechecker.
Re: ANNOUNCE: GHC 7.10.2 Release Candidate 2
On 3 July 2015 at 15:49, Austin Seipp aus...@well-typed.com wrote: We are pleased to announce the first release candidate for GHC 7.10.2: Thanks! I have updated my Fedora Copr 7.10.2 repo to RC2: https://copr.fedoraproject.org/coprs/petersen/ghc-7.10.2 There are builds for Fedora 22 (release) and 23 (devel). Cheers, Jens ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Improving the Get Haskell Experience
On Mon, Jul 13, 2015 at 12:34 AM, Kosyrev Serge _deepf...@feelingofgreen.ru wrote: Greg Weber g...@gregweber.info writes: The main reason I am using stack is for its support for building a project containing multiple packages. There aren't any other tools that make this a first-class concept that is easy to use and not buggy. In addition, stack has a first-class concept of curated package sets. All of these are required to have smooth installs in real world projects, and they aren't likely to appear in cabal-install in a short time frame. The problem that I'm personally facing all too often, is exploratory development, where the modus operandi is to try using versions/branches that are not yet released on Hackage. Things like this happen especially during GHC version transitions, where ghc-new buildability of libraries/tools is often in flux, and so you /have/ to chase the tail (or is it HEAD?). As an example, the version of ghc-mod that works with 7.10 is still unreleased on Cabal -- months passed, the prospects still indefinite. But it also happens out of plain curiosity and willingness to try out how new things could affect the way of problem expression. For an example of that, let's take the 'nokinds' branch of GHC, where Richard Eisenberg does research on formulating GHC with dependent types. Another situation where these things matter especially is collaborative development -- trying to help with bugs, for example. All these things ring of the same, actually.. ..where Hackage puts a mild barrier to sharing small contributions with the world, Stack puts a wall. I think you are using the wrong terminology. You probably mean to compare stackage with Hackage. But your replly is supposed to be about stack, which has first-class support for building packages that are not on Hackage as part of your project, including fetching the package from github for you. https://github.com/commercialhaskell/stack/wiki/stack.yaml#project-config Which is a good thing. But also a bad one. ..and unless I'm wrong, and we're indeed moving to a world where people would increasingly use Stack, this dichotomy is /bound/ to become more pressing. Curiously, there's a technology to solve to both sides of the story -- Nix, which was mentioned before, but I think its salient point applies especially well to this dichotomy: 1. use the existing curated releases, but also can 2. override packages with a Github fork URL, commit id and the physical checkout hash -- and have everything pick it up in a transparent, fixpoint way. Again, there is already support for this in stack. Give it a try. Admittedly it's not been made as trivial to use -- there's more moving parts to factor, and up until now there just wasn't any party seriously interested in doing the user-facing parts. ..And so, I can't help but wonder.. what if the Stack authors would have applied their expertise to provide the same user experience they achieved.. ..but with Nix as an underlying technology? Then stack would be forcing Windows users to use cygwin -- respectfully, Косырев Серёга ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Backporting srcLoc to the GHC 7.10 branch
Hi Simon, We had a small pow-wow over here. We're already providing relevant customers with a custom-built GHC, and only using this feature internally to their codebases, so it's not a necessity to get this into upstream GHC 7.10. It would be nice if the library ecosystem could start to add in support for this feature, but on the other hand having it out in the wild ties everyone's hands with improving the feature before the 7.12 release. So put FP Complete down as somewhat ambivalent on whether it should go out. On Mon, Jul 13, 2015 at 3:16 AM Simon Peyton Jones simo...@microsoft.com wrote: * There is some change you want to make to 7.10.2. I'm not sure precisely what it is. | The change would be to put the latest two commits from | | https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip | | on top of 7.10 branch. Aha. Now you say the top two commits I can see what you are talking about, namely the entire CallStack feature. Specifically https://github.com/nh2/ghc/commit/5cd10eb4b6eef06f53bbdcfae4b9f8f505ea522c | * The change is an API change, which we do not normally make. | But you argue that it will harm no one (why are you so sure?), | and you are confident that it will not break anything (why?) | | The API change is precisely at this commit. | | https://github.com/nh2/ghc/commit/d4e476817a7df449b71a2acc515b4d0fa6f8 | 9b6b It's much more than that! The main commit (the one you want) adds `CallStack`, `getCallStack` etc, as well as special treatment for implicit parameters of that type. That widens the API, which is certainly less disruptive than changing it. Let's see what Ben and Herbert have to say. Do any other ghc-devs, or Mark or Michael, have an opinion? Simon | | I never said that it will not harm anyone or that it will not break | anything. I only said that it is a small price to pay. | | The change is your own in the typechecker, a two SrcSpans turning into | RealSrcSpans. I think we can agree at least that it is not a large | change. I understand if it gets rejected on this basis regardless, I | am merely trying my chances. | | * FP Complete and Zalora specifically want this change. | Zalora = you? Who at FP Complete wants the change? | | Some of us at Zalora, yes. This thread of messages was created my FP | Complete and they did the backport. They even say that they'll include | the changes into their custom build of GHC and ship that to their | customers. So it seems like they'd want the change. The very first | message in this thread is Michael Snoyman asking if such backport | could make it into 7.10. | | Ben and Herbert are the guys you have to persuade if you really want | this. | I suspect it'll be more effective to open a ticket, milestoned for | 7.10.2, with specifics on it. Email gets lost; tickets don't. | | Noted, thanks. | | Thanks | | Simon | | | | -Original Message- | | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | | Mateusz Kowalczyk | | Sent: 06 July 2015 17:40 | | To: ghc-devs@haskell.org | | Subject: Re: Backporting srcLoc to the GHC 7.10 branch | | | | On 04/20/2015 05:29 PM, Niklas Hambüchen wrote: | | Hello everybody, | | | | I'm glad to announce that I performed the suggested backporting | as | | part | | of | | my work for FP Complete! | | | | With the help of Eric (thanks for your support in #ghc!) we now | | have | | this | | patch for 7.10 and 7.8. | | | | As promised, here are the commits: | | | | * https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc- | ip | | * https://github.com/nh2/ghc/commits/ghc-7.8.4-release-srcloc-ip | | | | You can see in the history that I only needed to cherry-pick | Make | | the location in TcLclEnv and CtLoc into a RealSrcSpan as a | | dependent | | commit, | | so the changes beyond the actual feature are fairly minimal. | | | | For 7.8, I had to do a little more cleanup, see the Use | wrapIPTc | | instead | | of coercionToTcCoercion on wrapIP commit. | | | | Regarding the commit of the feature itself, I had to do quite | some | | merge | | resolution, especially due to the (lack of) the -fwarn- | redundant- | | constraints patch https://github.com/nh2/ghc/commit/32973bf3 | | (alias | | but it | | was Christmas, so I did some recreational programming that went | | much further). | | However, the type checker had a strong opinion of what the right | | merge decision was, at least for the 7.10 backport; for 7.8 | there | | was an ambiguity (whether to return `Nothing` or `Just` in | | `interactDict`), | | which | | was resolved with Eric's help. | | | | Please be invited to review the two commits. | | | | We would like to make 7.8 and 7.10 binaries
Re: Backporting srcLoc to the GHC 7.10 branch
I'm on board with that, and as always am happy to run as many Stackage builds as necessary, preferably using Herbert's PPAs (which make the process so darn easy). On Mon, Jul 13, 2015 at 3:17 PM Simon Peyton Jones simo...@microsoft.com wrote: We (Ben/Herbert/myself/Simon) had a pow-wow too. ·We have a *strong* bias against making changes late in the release cycle ·And especially ones that change the API at all But on the other hand ·Mateusz did first float this back in mid-April and we didn’t pay enough attention at the time which is making us feel guilty. ·Although nothing is risk free, it seems unlikely to break anything because the changes only have an effect if you import the new module. ·Stackage gives us a pretty good smoke-test for if we’ve broken anything. ·Zalora want this strongly; and FP Complete do mildly. As to the stability of the feature itself, I’ll feel no compunction about changing it a bit in 7.12, say. We often change new features in the light of feedback, and putting it in a release is a way to get people to actually use it and thereby get that feedback. So we decided, *strictly without setting a precedent*, to try applying the patch to 7.10.2, validating with the usual test suite and Stackage. I hope that’s ok with everyone. Simon *From:* Michael Snoyman [mailto:mich...@snoyman.com] *Sent:* 13 July 2015 18:33 *To:* Simon Peyton Jones; Mateusz Kowalczyk; ghc-devs@haskell.org *Cc:* Mark Lentczner *Subject:* Re: Backporting srcLoc to the GHC 7.10 branch Hi Simon, We had a small pow-wow over here. We're already providing relevant customers with a custom-built GHC, and only using this feature internally to their codebases, so it's not a necessity to get this into upstream GHC 7.10. It would be nice if the library ecosystem could start to add in support for this feature, but on the other hand having it out in the wild ties everyone's hands with improving the feature before the 7.12 release. So put FP Complete down as somewhat ambivalent on whether it should go out. On Mon, Jul 13, 2015 at 3:16 AM Simon Peyton Jones simo...@microsoft.com wrote: * There is some change you want to make to 7.10.2. I'm not sure precisely what it is. | The change would be to put the latest two commits from | | https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip | | on top of 7.10 branch. Aha. Now you say the top two commits I can see what you are talking about, namely the entire CallStack feature. Specifically https://github.com/nh2/ghc/commit/5cd10eb4b6eef06f53bbdcfae4b9f8f505ea522c | * The change is an API change, which we do not normally make. | But you argue that it will harm no one (why are you so sure?), | and you are confident that it will not break anything (why?) | | The API change is precisely at this commit. | | https://github.com/nh2/ghc/commit/d4e476817a7df449b71a2acc515b4d0fa6f8 | 9b6b It's much more than that! The main commit (the one you want) adds `CallStack`, `getCallStack` etc, as well as special treatment for implicit parameters of that type. That widens the API, which is certainly less disruptive than changing it. Let's see what Ben and Herbert have to say. Do any other ghc-devs, or Mark or Michael, have an opinion? Simon | | I never said that it will not harm anyone or that it will not break | anything. I only said that it is a small price to pay. | | The change is your own in the typechecker, a two SrcSpans turning into | RealSrcSpans. I think we can agree at least that it is not a large | change. I understand if it gets rejected on this basis regardless, I | am merely trying my chances. | | * FP Complete and Zalora specifically want this change. | Zalora = you? Who at FP Complete wants the change? | | Some of us at Zalora, yes. This thread of messages was created my FP | Complete and they did the backport. They even say that they'll include | the changes into their custom build of GHC and ship that to their | customers. So it seems like they'd want the change. The very first | message in this thread is Michael Snoyman asking if such backport | could make it into 7.10. | | Ben and Herbert are the guys you have to persuade if you really want | this. | I suspect it'll be more effective to open a ticket, milestoned for | 7.10.2, with specifics on it. Email gets lost; tickets don't. | | Noted, thanks. | | Thanks | | Simon | | | | -Original Message- | | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | | Mateusz Kowalczyk | | Sent: 06 July 2015 17:40 | | To: ghc-devs@haskell.org | | Subject: Re: Backporting srcLoc to the GHC 7.10 branch | | | | On 04/20/2015 05:29 PM, Niklas Hambüchen wrote: | | Hello everybody, | | | | I'm glad to announce that I performed the suggested
RE: Backporting srcLoc to the GHC 7.10 branch
We (Ben/Herbert/myself/Simon) had a pow-wow too. ·We have a strong bias against making changes late in the release cycle ·And especially ones that change the API at all But on the other hand ·Mateusz did first float this back in mid-April and we didn’t pay enough attention at the time which is making us feel guilty. ·Although nothing is risk free, it seems unlikely to break anything because the changes only have an effect if you import the new module. ·Stackage gives us a pretty good smoke-test for if we’ve broken anything. ·Zalora want this strongly; and FP Complete do mildly. As to the stability of the feature itself, I’ll feel no compunction about changing it a bit in 7.12, say. We often change new features in the light of feedback, and putting it in a release is a way to get people to actually use it and thereby get that feedback. So we decided, strictly without setting a precedent, to try applying the patch to 7.10.2, validating with the usual test suite and Stackage. I hope that’s ok with everyone. Simon From: Michael Snoyman [mailto:mich...@snoyman.com] Sent: 13 July 2015 18:33 To: Simon Peyton Jones; Mateusz Kowalczyk; ghc-devs@haskell.org Cc: Mark Lentczner Subject: Re: Backporting srcLoc to the GHC 7.10 branch Hi Simon, We had a small pow-wow over here. We're already providing relevant customers with a custom-built GHC, and only using this feature internally to their codebases, so it's not a necessity to get this into upstream GHC 7.10. It would be nice if the library ecosystem could start to add in support for this feature, but on the other hand having it out in the wild ties everyone's hands with improving the feature before the 7.12 release. So put FP Complete down as somewhat ambivalent on whether it should go out. On Mon, Jul 13, 2015 at 3:16 AM Simon Peyton Jones simo...@microsoft.commailto:simo...@microsoft.com wrote: * There is some change you want to make to 7.10.2. I'm not sure precisely what it is. | The change would be to put the latest two commits from | | https://github.com/nh2/ghc/commits/ghc-7.10.1-release-srcloc-ip | | on top of 7.10 branch. Aha. Now you say the top two commits I can see what you are talking about, namely the entire CallStack feature. Specifically https://github.com/nh2/ghc/commit/5cd10eb4b6eef06f53bbdcfae4b9f8f505ea522c | * The change is an API change, which we do not normally make. | But you argue that it will harm no one (why are you so sure?), | and you are confident that it will not break anything (why?) | | The API change is precisely at this commit. | | https://github.com/nh2/ghc/commit/d4e476817a7df449b71a2acc515b4d0fa6f8 | 9b6b It's much more than that! The main commit (the one you want) adds `CallStack`, `getCallStack` etc, as well as special treatment for implicit parameters of that type. That widens the API, which is certainly less disruptive than changing it. Let's see what Ben and Herbert have to say. Do any other ghc-devs, or Mark or Michael, have an opinion? Simon | | I never said that it will not harm anyone or that it will not break | anything. I only said that it is a small price to pay. | | The change is your own in the typechecker, a two SrcSpans turning into | RealSrcSpans. I think we can agree at least that it is not a large | change. I understand if it gets rejected on this basis regardless, I | am merely trying my chances. | | * FP Complete and Zalora specifically want this change. | Zalora = you? Who at FP Complete wants the change? | | Some of us at Zalora, yes. This thread of messages was created my FP | Complete and they did the backport. They even say that they'll include | the changes into their custom build of GHC and ship that to their | customers. So it seems like they'd want the change. The very first | message in this thread is Michael Snoyman asking if such backport | could make it into 7.10. | | Ben and Herbert are the guys you have to persuade if you really want | this. | I suspect it'll be more effective to open a ticket, milestoned for | 7.10.2, with specifics on it. Email gets lost; tickets don't. | | Noted, thanks. | | Thanks | | Simon | | | | -Original Message- | | From: ghc-devs [mailto:ghc-devs-boun...@haskell.orgmailto:ghc-devs-boun...@haskell.org] On Behalf Of | | Mateusz Kowalczyk | | Sent: 06 July 2015 17:40 | | To: ghc-devs@haskell.orgmailto:ghc-devs@haskell.org | | Subject: Re: Backporting srcLoc to the GHC 7.10 branch | | | | On 04/20/2015 05:29 PM, Niklas Hambüchen wrote: | | Hello everybody, | | | | I'm glad to announce that I performed the suggested backporting | as | | part | | of | | my work for FP Complete! | | | | With the help of Eric (thanks for your support in #ghc!) we now | | have | | this | | patch for 7.10 and 7.8. | | | | As promised, here are the commits: | | | | *
Re: Improving the Get Haskell Experience
Greg Weber g...@gregweber.info writes: The main reason I am using stack is for its support for building a project containing multiple packages. There aren't any other tools that make this a first-class concept that is easy to use and not buggy. In addition, stack has a first-class concept of curated package sets. All of these are required to have smooth installs in real world projects, and they aren't likely to appear in cabal-install in a short time frame. The problem that I'm personally facing all too often, is exploratory development, where the modus operandi is to try using versions/branches that are not yet released on Hackage. Things like this happen especially during GHC version transitions, where ghc-new buildability of libraries/tools is often in flux, and so you /have/ to chase the tail (or is it HEAD?). As an example, the version of ghc-mod that works with 7.10 is still unreleased on Cabal -- months passed, the prospects still indefinite. But it also happens out of plain curiosity and willingness to try out how new things could affect the way of problem expression. For an example of that, let's take the 'nokinds' branch of GHC, where Richard Eisenberg does research on formulating GHC with dependent types. Another situation where these things matter especially is collaborative development -- trying to help with bugs, for example. All these things ring of the same, actually.. ..where Hackage puts a mild barrier to sharing small contributions with the world, Stack puts a wall. Which is a good thing. But also a bad one. ..and unless I'm wrong, and we're indeed moving to a world where people would increasingly use Stack, this dichotomy is /bound/ to become more pressing. Curiously, there's a technology to solve to both sides of the story -- Nix, which was mentioned before, but I think its salient point applies especially well to this dichotomy: 1. use the existing curated releases, but also can 2. override packages with a Github fork URL, commit id and the physical checkout hash -- and have everything pick it up in a transparent, fixpoint way. Admittedly it's not been made as trivial to use -- there's more moving parts to factor, and up until now there just wasn't any party seriously interested in doing the user-facing parts. ..And so, I can't help but wonder.. what if the Stack authors would have applied their expertise to provide the same user experience they achieved.. ..but with Nix as an underlying technology? -- respectfully, Косырев Серёга ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
