tl;dr. GHC 8.0.2 is coming. If you have a fix which you'd like to see merged into 8.0.2 and isn't already present in the tree, please speak up! Hello everyone, Over the last week I have been working down the (rather long) merge queue for the ghc-8.0 branch in preparation for a 8.0.2 release. At this point I think have merged nearly everything which will likely make it in to 8.0.2. If you have a patch which hasn't made it to the ghc-8.0 branch that you would like to see merged, please raise your concern on the appropriate Trac ticket. Thanks! - Ben
Hello Ben, Could we have these patches added? http://git.haskell.org/ghc.git/commit/56f47d4a4e418235285d8b8cfe23bde6473f17... http://git.haskell.org/ghc.git/commit/567dbd9bcb602accf3184b83050f2982cbb775... These allow reify to reach local variables when used with addModFinalizer. Best, Facundo On Mon, Aug 29, 2016 at 4:00 PM, Ben Gamari <ben@well-typed.com> wrote:
tl;dr. GHC 8.0.2 is coming. If you have a fix which you'd like to see merged into 8.0.2 and isn't already present in the tree, please speak up!
Hello everyone,
Over the last week I have been working down the (rather long) merge queue for the ghc-8.0 branch in preparation for a 8.0.2 release. At this point I think have merged nearly everything which will likely make it in to 8.0.2.
If you have a patch which hasn't made it to the ghc-8.0 branch that you would like to see merged, please raise your concern on the appropriate Trac ticket.
Thanks!
- Ben
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Hello, I don't have a patch, but I think that #12433 is a really serious bug that deserves a timely fix, as compiling with `-dynamic` on Linux produces code that runs but produces incorrect results. Unfortunately, I don't have time to look into it, and the bug is not in a part of the compiler I have experience with. -Iavor On Mon, Aug 29, 2016 at 2:02 PM, Facundo Domínguez < facundo.dominguez@tweag.io> wrote:
Hello Ben,
Could we have these patches added?
http://git.haskell.org/ghc.git/commit/56f47d4a4e418235285d8b8cfe23bd e6473f17fc http://git.haskell.org/ghc.git/commit/567dbd9bcb602accf3184b83050f29 82cbb7758b
These allow reify to reach local variables when used with addModFinalizer.
Best, Facundo
On Mon, Aug 29, 2016 at 4:00 PM, Ben Gamari <ben@well-typed.com> wrote:
tl;dr. GHC 8.0.2 is coming. If you have a fix which you'd like to see merged into 8.0.2 and isn't already present in the tree, please speak up!
Hello everyone,
Over the last week I have been working down the (rather long) merge queue for the ghc-8.0 branch in preparation for a 8.0.2 release. At this point I think have merged nearly everything which will likely make it in to 8.0.2.
If you have a patch which hasn't made it to the ghc-8.0 branch that you would like to see merged, please raise your concern on the appropriate Trac ticket.
Thanks!
- Ben
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Facundo Domínguez <facundo.dominguez@tweag.io> writes:
Hello Ben,
Could we have these patches added?
http://git.haskell.org/ghc.git/commit/56f47d4a4e418235285d8b8cfe23bde6473f17... http://git.haskell.org/ghc.git/commit/567dbd9bcb602accf3184b83050f2982cbb775...
These allow reify to reach local variables when used with addModFinalizer.
Hmm, I'm not sure; #11832 is strictly speaking a feature request which we try to avoid merging in minor releases to avoid introducing bugs. Given that 8.2.1 isn't that far away (hopefully early 2017), how terrible would it be if we punted this? Cheers, - Ben
Depends how you look at it I guess. It's arguably a fix to addModFinalizer, which never really worked for the use case it was intended since it was first introduced. This function was added by the author of language-c-inline, who wanted things like cos :: Double -> Double cos x = [c| cos($x) |] to work by having a new C wrapper function for the quasiquote be generated and written to disk at the end of the type checking phase. Doing it at the end means all quasiquotes in the whole module can be dumped at once. Problem is, the type environment was not available by then, so the user was forced to provide an explicit type annotation to help with the code generation, as is done in inline-c: cos :: Double -> Double cos x = [c| double { cos($double:x) } |]
From GHC 7.8, types for locally bound variables weren't even available at the quasiquotation site, for reasons. But it's perfectly safe to make them available by the time all type checking is finished.
We could wait of course, but in the meantime this is completely holding up the "inline" features of inline-java. Because for inline-java we decided that the (redundant) type annotations such as the above were really too verbose in the case of Java, and would require significant hacks to the language-java parser, so we don't support them. That's why I for one am keen to have addModFinalizer make into a release as soon as possible. But I completely understand your risk aversion for a point release. Here's some data to help you evaluate the risk: the patch is specific to TH finalizers registered using addModFinalizer, a function that is currently used by only one package out there at the moment: expandth (based on github code search - short of being able to code search all of Hackage directly). -- Mathieu Boespflug Founder at http://tweag.io. On 30 August 2016 at 17:59, Ben Gamari <ben@well-typed.com> wrote:
Facundo Domínguez <facundo.dominguez@tweag.io> writes:
Hello Ben,
Could we have these patches added?
http://git.haskell.org/ghc.git/commit/56f47d4a4e418235285d8b8cfe23bd e6473f17fc http://git.haskell.org/ghc.git/commit/567dbd9bcb602accf3184b83050f29 82cbb7758b
These allow reify to reach local variables when used with addModFinalizer.
Hmm, I'm not sure; #11832 is strictly speaking a feature request which we try to avoid merging in minor releases to avoid introducing bugs. Given that 8.2.1 isn't that far away (hopefully early 2017), how terrible would it be if we punted this?
Cheers,
- Ben
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
"Boespflug, Mathieu" <m@tweag.io> writes:
Depends how you look at it I guess. It's arguably a fix to addModFinalizer, which never really worked for the use case it was intended since it was first introduced. This function was added by the author of language-c-inline, who wanted things like
cos :: Double -> Double cos x = [c| cos($x) |]
to work by having a new C wrapper function for the quasiquote be generated and written to disk at the end of the type checking phase. Doing it at the end means all quasiquotes in the whole module can be dumped at once. Problem is, the type environment was not available by then, so the user was forced to provide an explicit type annotation to help with the code generation, as is done in inline-c:
cos :: Double -> Double cos x = [c| double { cos($double:x) } |]
From GHC 7.8, types for locally bound variables weren't even available at the quasiquotation site, for reasons. But it's perfectly safe to make them available by the time all type checking is finished.
We could wait of course, but in the meantime this is completely holding up the "inline" features of inline-java. Because for inline-java we decided that the (redundant) type annotations such as the above were really too verbose in the case of Java, and would require significant hacks to the language-java parser, so we don't support them. That's why I for one am keen to have addModFinalizer make into a release as soon as possible.
But I completely understand your risk aversion for a point release. Here's some data to help you evaluate the risk: the patch is specific to TH finalizers registered using addModFinalizer, a function that is currently used by only one package out there at the moment: expandth (based on github code search - short of being able to code search all of Hackage directly).
Fair enough; this is compelling enough a reason to me. I've gone ahead and merged it. However, would either you or Facundo be able to write a release notes entry? Thanks, - Ben
If it merges ok, I’d be inclined to put this in. · We know it’ll help someone (Mathieu and colleages). · It (should) affect a new and as-yet little-used feature, so it’s unlikely to harm anyone. (Of course, ANY change can have unexpected consequences.) · And you could regard it as a kind of bug-fix. I think we could bend the rules here. Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Boespflug, Mathieu Sent: 30 August 2016 19:05 To: Ben Gamari <ben@well-typed.com> Cc: GHC developers <ghc-devs@haskell.org> Subject: Re: Last call for merge requests for 8.0.2 Depends how you look at it I guess. It's arguably a fix to addModFinalizer, which never really worked for the use case it was intended since it was first introduced. This function was added by the author of language-c-inline, who wanted things like cos :: Double -> Double cos x = [c| cos($x) |] to work by having a new C wrapper function for the quasiquote be generated and written to disk at the end of the type checking phase. Doing it at the end means all quasiquotes in the whole module can be dumped at once. Problem is, the type environment was not available by then, so the user was forced to provide an explicit type annotation to help with the code generation, as is done in inline-c: cos :: Double -> Double cos x = [c| double { cos($double:x) } |] From GHC 7.8, types for locally bound variables weren't even available at the quasiquotation site, for reasons. But it's perfectly safe to make them available by the time all type checking is finished. We could wait of course, but in the meantime this is completely holding up the "inline" features of inline-java. Because for inline-java we decided that the (redundant) type annotations such as the above were really too verbose in the case of Java, and would require significant hacks to the language-java parser, so we don't support them. That's why I for one am keen to have addModFinalizer make into a release as soon as possible. But I completely understand your risk aversion for a point release. Here's some data to help you evaluate the risk: the patch is specific to TH finalizers registered using addModFinalizer, a function that is currently used by only one package out there at the moment: expandth (based on github code search - short of being able to code search all of Hackage directly). -- Mathieu Boespflug Founder at http://tweag.io<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftweag.io&data=01%7c01%7csimonpj%40microsoft.com%7cad4d06adb11c4cc9f1a408d3d10038a5%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=hMxE52Ftatu3waJaDsfVjEZeUNld8ier92n%2bTOyqOAA%3d>. On 30 August 2016 at 17:59, Ben Gamari <ben@well-typed.com<mailto:ben@well-typed.com>> wrote: Facundo Domínguez <facundo.dominguez@tweag.io<mailto:facundo.dominguez@tweag.io>> writes:
Hello Ben,
Could we have these patches added?
http://git.haskell.org/ghc.git/commit/56f47d4a4e418235285d8b8cfe23bde6473f17fc<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fgit.haskell.org%2fghc.git%2fcommit%2f56f47d4a4e418235285d8b8cfe23bde6473f17fc&data=01%7c01%7csimonpj%40microsoft.com%7cad4d06adb11c4cc9f1a408d3d10038a5%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=mrvqQEGkKEmitdQ8tIzeQMFgQ4BK8D5aDemG8%2f4cALg%3d> http://git.haskell.org/ghc.git/commit/567dbd9bcb602accf3184b83050f2982cbb7758b<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fgit.haskell.org%2fghc.git%2fcommit%2f567dbd9bcb602accf3184b83050f2982cbb7758b&data=01%7c01%7csimonpj%40microsoft.com%7cad4d06adb11c4cc9f1a408d3d10038a5%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bJD1ibohX2hB2Da6HeL8J4hA0TsE193W6%2b8OVYisjoI%3d>
These allow reify to reach local variables when used with addModFinalizer.
Hmm, I'm not sure; #11832 is strictly speaking a feature request which we try to avoid merging in minor releases to avoid introducing bugs. Given that 8.2.1 isn't that far away (hopefully early 2017), how terrible would it be if we punted this? Cheers, - Ben _______________________________________________ ghc-devs mailing list ghc-devs@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.haskell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-devs&data=01%7c01%7csimonpj%40microsoft.com%7cad4d06adb11c4cc9f1a408d3d10038a5%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=V5lt94aEjJCKJuVcnL8qglhDZytwINtKV4wKRIeR9zY%3d>
Ben, We'd like to have the patch to this bug [1] included as well, if possible. Thanks, Facundo [1] https://ghc.haskell.org/trac/ghc/ticket/12559 On Mon, Aug 29, 2016 at 4:00 PM, Ben Gamari <ben@well-typed.com> wrote:
tl;dr. GHC 8.0.2 is coming. If you have a fix which you'd like to see merged into 8.0.2 and isn't already present in the tree, please speak up!
Hello everyone,
Over the last week I have been working down the (rather long) merge queue for the ghc-8.0 branch in preparation for a 8.0.2 release. At this point I think have merged nearly everything which will likely make it in to 8.0.2.
If you have a patch which hasn't made it to the ghc-8.0 branch that you would like to see merged, please raise your concern on the appropriate Trac ticket.
Thanks!
- Ben
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
participants (5)
-
Ben Gamari -
Boespflug, Mathieu -
Facundo Domínguez -
Iavor Diatchki -
Simon Peyton Jones