GHC

Hi *, Welcome for the latest entry in the GHC Weekly News. The past week, GHC HQ met up to discuss the status of the approaching 7.10.2 release. 7.10.2 status After quite some delay due to a number of tricky regressions in 7.10.1, 7.10.2 is ... [More] nearing the finish line. Austin cut release candidate 2 on Friday and so far the only reports of trouble appear to be some validation issues, most of which have already been fixed thanks to Richard Eisenberg. 7.10.2 will include a number of significant bug-fixes. These include, #10521, where overlap of floating point STG registers weren't properly accounted for, resulting in incorrect results in some floating point computations. This was fixed by the amazing Reid Barton. #10534, a type-safety hole enabling a user to write unsafeCoerce with data families and coerce. Fix due to the remarkable Richard Eisenberg. #10538, where some programs would cause the simplifier to emit an empty case, resulting in runtime crashes. Fix due to the industrious Simon Peyton Jones. #10527, where the simplifier would expend a great deal of effort simplifying arguments which were never demanded by the callee. #10414, where a subtle point of the runtime system's black-holing mechanism resulting in hangs on a carefully constructed testcase. #10236, where incorrect DWARF annotations would be generated, resulting in incorrect backtraces. Fixed by Peter Wortmann #7450, where cached free variable information was being unnecessarily dropped by the specialiser, resulting in non-linear compile times for some programs. See the ​status page for a complete listing of issues fixed in this release. In the coming days we will being working with FP Complete to test the pre-release against Stackage. While Hackage tends to be too large to build in bulk, the selection of packages represented in Stackage is feasible to build and is likely to catch potential regressions. Hopefully this sort of large-scale validation will become common-place for future releases. If all goes well, 7.10.2 will mark the end of the 7.10 series. However, there is always the small possibility that a major regression will be found. In this case we will cut a 7.10.3 release which will include a few ​patches which didn't make it into 7.10.2. Other matters It has been suggested in #10601 that GHC builds should ship with DWARF symbols for the base libraries and runtime system. While we all want to see this new capability in users' hands, 7.10.2 will, like 7.10.1, not be shipping with debug symbols. GHC HQ will be discussing the feasibility of including debug symbols with 7.12 in the future. In the meantime, we will be adding options to build.mk to make it easier for users to build their own compilers with debug-enabled libraries. In this week's GHC meeting the effort to port GHC's build system to the Shake? build system briefly came up. Despite the volume of updates on the ​Wiki Simon reports that the project is still moving along. The current state of the Shake-based build system can be found on ​Github. While debugging #7540 it became clear that there may be trouble lurking in the profiler. Namely when profiling GHC itself lintAnnots is showing up strongly where it logically should not. This was previously addressed in #10007, which was closed after a patch by Simon Marlow was merged. As it appears that this did not fully resolve the issue I'll be looking further into this. ~ Ben [Less]

Hi *, Welcome for the latest entry in the GHC Weekly News. The past week, GHC HQ met up to discuss the status of the approaching 7.10.2 release. 7.10.2 status After quite some delay due to a number of tricky regressions in 7.10.1, 7.10.2 is ... [More] nearing the finish line. Austin cut release candidate 2 on Friday and so far the only reports of trouble appear to be some validation issues, most of which have already been fixed thanks to Richard Eisenberg. 7.10.2 will include a number of significant bug-fixes. These include, #10521, where overlap of floating point STG registers weren't properly accounted for, resulting in incorrect results in some floating point computations. This was fixed by the amazing Reid Barton. #10534, a type-safety hole enabling a user to write unsafeCoerce with data families and coerce. Fix due to the remarkable Richard Eisenberg. #10538, where some programs would cause the simplifier to emit an empty case, resulting in runtime crashes. Fix due to the industrious Simon Peyton Jones. #10527, where the simplifier would expend a great deal of effort simplifying arguments which were never demanded by the callee. #10414, where a subtle point of the runtime system's black-holing mechanism resulting in hangs on a carefully constructed testcase. #10236, where incorrect DWARF annotations would be generated, resulting in incorrect backtraces. Fixed by Peter Wortmann #7450, where cached free variable information was being unnecessarily dropped by the specialiser, resulting in non-linear compile times for some programs. See the ​status page for a complete listing of issues fixed in this release. In the coming days we will being working with FP Complete to test the pre-release against Stackage. While Hackage tends to be too large to build in bulk, the selection of packages represented in Stackage is feasible to build and is likely to catch potential regressions. Hopefully this sort of large-scale validation will become common-place for future releases. If all goes well, 7.10.2 will mark the end of the 7.10 series. However, there is always the small possibility that a major regression will be found. In this case we will cut a 7.10.3 release which will include a few ​patches which didn't make it into 7.10.2. Other matters It has been suggested in #10601 that GHC builds should ship with DWARF symbols for the base libraries and runtime system. While we all want to see this new capability in users' hands, 7.10.2 will, like 7.10.1, not be shipping with debug symbols. GHC HQ will be discussing the feasibility of including debug symbols with 7.12 in the future. In the meantime, we will be adding options to build.mk to make it easier for users to build their own compilers with debug-enabled libraries. In this week's GHC meeting the effort to port GHC's build system to the Shake? build system briefly came up. Despite the volume of updates on the ​Wiki Simon reports that the project is still moving along. The current state of the Shake-based build system can be found on ​Github. While debugging #7540 it became clear that there may be trouble lurking in the profiler. Namely when profiling GHC itself lintAnnots is showing up strongly where it logically should not. This was previously addressed in #10007, which was closed after a patch by Simon Marlow was merged. As it appears that this did not fully resolve the issue I'll be looking further into this. ~ Ben [Less]

Hi *, Welcome for the latest entry in the GHC Weekly News. The past week, GHC HQ met up to discuss the status of the approaching 7.10.2 release. 7.10.2 status After quite some delay due to a number of tricky regressions in 7.10.1, 7.10.2 is ... [More] nearing the finish line. Austin cut release candidate 2 on Friday and so far the only reports of trouble appear to be some validation issues, most of which have already been fixed thanks to Richard Eisenberg. 7.10.2 will include a number of significant bug-fixes. These include, #10521, where overlap of floating point STG registers weren't properly accounted for, resulting in incorrect results in some floating point computations. This was fixed by the amazing Reid Barton. #10534, a type-safety hole enabling a user to write unsafeCoerce with data families and coerce. Fix due to the remarkable Richard Eisenberg. #10538, where some programs would cause the simplifier to emit an empty case, resulting in runtime crashes. Fix due to the industrious Simon Peyton Jones. #10527, where the simplifier would expend a great deal of effort simplifying arguments which were never demanded by the callee. #10414, where a subtle point of the runtime system's black-holing mechanism resulting in hangs on a carefully constructed testcase. #10236, where incorrect DWARF annotations would be generated, resulting in incorrect backtraces. Fixed by Peter Wortmann #7450, where cached free variable information was being unnecessarily dropped by the specialiser, resulting in non-linear compile times for some programs. See the ​status page for a complete listing of issues fixed in this release. In the coming days we will being working with FP Complete to test the pre-release against Stackage. While Hackage tends to be too large to build in bulk, the selection of packages represented in Stackage is feasible to build and is likely to catch potential regressions. Hopefully this sort of large-scale validation will become common-place for future releases. If all goes well, 7.10.2 will mark the end of the 7.10 series. However, there is always the small possibility that a major regression will be found. In this case we will cut a 7.10.3 release which will include a few ​patches which didn't make it into 7.10.2. Other matters It has been suggested in #10601 that GHC builds should ship with DWARF symbols for the base libraries and runtime system. While we all want to see this new capability in users' hands, 7.10.2 will, like 7.10.1, not be shipping with debug symbols. GHC HQ will be discussing the feasibility of including debug symbols with 7.12 in the future. In the meantime, we will be adding options to build.mk to make it easier for users to build their own compilers with debug-enabled libraries. In this week's GHC meeting the effort to port GHC's build system to the Shake? build system briefly came up. Despite the volume of updates on the ​Wiki Simon reports that the project is still moving along. The current state of the Shake-based build system can be found on ​Github. While debugging #7540 it became clear that there may be trouble lurking in the profiler. Namely when profiling GHC itself lintAnnots is showing up strongly where it logically should not. This was previously addressed in #10007, which was closed after a patch by Simon Marlow was merged. As it appears that this did not fully resolve the issue I'll be looking further into this. ~ Ben [Less]

Hi *, Welcome for the latest entry in the GHC Weekly News. The past week, GHC HQ met up for a quick catch up on 7.10.2 (which you'll want to read up on, see below), and some other technical nonsense about some work we've been doing. As a result ... [More] the current weekly notes have been slow - the current priority is the next release though, which leads us to... 7.10.2 status 7.10.2 is going to be out soon - our current plan is to have a release candidate on the weekend of Saturday the 13th, and the final release the next week. That means if you want something fixed, you'd better hollar very soon, or we're just not going to get to it! If you're wondering what's currently been fixed/scheduled, the ​status page shows the current set of tickets we've fixed and plan on fixing. List chatter Edward Z. Yang has written up a new wiki page to clearly explain and document all the various confusion around package keys, package ids, etc as a result of all the new Backpack work. If you're interested in this, it's definitely worth a read. ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009173.html Mark Lentczner sez: The Haskell Platform has finally outgrown Travis-CI, now going beyond the 50 minute build limit. Mark asks what alternatives we can use going forward. ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009174.html Jan Stolarek asks: in some cases, GHC will generate default instances or values, but that source code has no textual information location (for example, consider an instance clause without the where) - what do people think about fixing this, and are there anythings to look out for? ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009202.html David Luposchainsky has opened a new thread - about moving fail out of Monad and into its own typeclass, MonadFail. This change is a request that's very long in the tooth (older than the AMP or FTP changes by a landslide), but David's proposal has a clearly set out goal to tackle compatibility, warnings, and implementation. ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009186.html Noteworthy commits Commit 19ec6a84d6344c2808d0d41da11956689a0e4ae9 - Fix for CAF retention when dynamically loading & unloading code Commit 4a0b7a10442eec3747d5f95ef186a79bb0648754 - Build: run autoreconf jobs in parallel Closed tickets #10460, #7672, #9252, #9506, #10294, #5316, #10408, #10386, #9960, #10145, #9259, #10386, #9507, #8723, #10442, #5014, #4215, #10443, #8244, #10499, #10500, #10428, #10488, #10489, #10406, #10501, #10441, #10406, #10502, #9101, #9663, and #9945. [Less]

Hi *, Welcome for the latest entry in the GHC Weekly News. The past week, GHC HQ met up for a quick catch up on 7.10.2 (which you'll want to read up on, see below), and some other technical nonsense about some work we've been doing. As a result ... [More] the current weekly notes have been slow - the current priority is the next release though, which leads us to... 7.10.2 status 7.10.2 is going to be out soon - our current plan is to have a release candidate on the weekend of Saturday the 13th, and the final release the next week. That means if you want something fixed, you'd better hollar very soon, or we're just not going to get to it! If you're wondering what's currently been fixed/scheduled, the ​status page shows the current set of tickets we've fixed and plan on fixing. List chatter Edward Z. Yang has written up a new wiki page to clearly explain and document all the various confusion around package keys, package ids, etc as a result of all the new Backpack work. If you're interested in this, it's definitely worth a read. ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009173.html Mark Lentczner sez: The Haskell Platform has finally outgrown Travis-CI, now going beyond the 50 minute build limit. Mark asks what alternatives we can use going forward. ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009174.html Jan Stolarek asks: in some cases, GHC will generate default instances or values, but that source code has no textual information location (for example, consider an instance clause without the where) - what do people think about fixing this, and are there anythings to look out for? ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009202.html David Luposchainsky has opened a new thread - about moving fail out of Monad and into its own typeclass, MonadFail. This change is a request that's very long in the tooth (older than the AMP or FTP changes by a landslide), but David's proposal has a clearly set out goal to tackle compatibility, warnings, and implementation. ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009186.html Noteworthy commits Commit 19ec6a84d6344c2808d0d41da11956689a0e4ae9 - Fix for CAF retention when dynamically loading & unloading code Commit 4a0b7a10442eec3747d5f95ef186a79bb0648754 - Build: run autoreconf jobs in parallel Closed tickets #10460, #7672, #9252, #9506, #10294, #5316, #10408, #10386, #9960, #10145, #9259, #10386, #9507, #8723, #10442, #5014, #4215, #10443, #8244, #10499, #10500, #10428, #10488, #10489, #10406, #10501, #10441, #10406, #10502, #9101, #9663, and #9945. [Less]

Hi *, Welcome for the latest entry in the GHC Weekly News. The past week, GHC HQ met up for a quick catch up on 7.10.2 (which you'll want to read up on, see below), and some other technical nonsense about some work we've been doing. As a result ... [More] the current weekly notes have been slow - the current priority is the next release though, which leads us to... 7.10.2 status 7.10.2 is going to be out soon - our current plan is to have a release candidate on the weekend of Saturday the 13th, and the final release the next week. That means if you want something fixed, you'd better hollar very soon, or we're just not going to get to it! If you're wondering what's currently been fixed/scheduled, the ​status page shows the current set of tickets we've fixed and plan on fixing. List chatter Edward Z. Yang has written up a new wiki page to clearly explain and document all the various confusion around package keys, package ids, etc as a result of all the new Backpack work. If you're interested in this, it's definitely worth a read. ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009173.html Mark Lentczner sez: The Haskell Platform has finally outgrown Travis-CI, now going beyond the 50 minute build limit. Mark asks what alternatives we can use going forward. ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009174.html Jan Stolarek asks: in some cases, GHC will generate default instances or values, but that source code has no textual information location (for example, consider an instance clause without the where) - what do people think about fixing this, and are there anythings to look out for? ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009202.html David Luposchainsky has opened a new thread - about moving fail out of Monad and into its own typeclass, MonadFail. This change is a request that's very long in the tooth (older than the AMP or FTP changes by a landslide), but David's proposal has a clearly set out goal to tackle compatibility, warnings, and implementation. ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009186.html Noteworthy commits Commit 19ec6a84d6344c2808d0d41da11956689a0e4ae9 - Fix for CAF retention when dynamically loading & unloading code Commit 4a0b7a10442eec3747d5f95ef186a79bb0648754 - Build: run autoreconf jobs in parallel Closed tickets #10460, #7672, #9252, #9506, #10294, #5316, #10408, #10386, #9960, #10145, #9259, #10386, #9507, #8723, #10442, #5014, #4215, #10443, #8244, #10499, #10500, #10428, #10488, #10489, #10406, #10501, #10441, #10406, #10502, #9101, #9663, and #9945. [Less]

Hi *, Welcome for the latest entry in the GHC Weekly News. The past week, GHC HQ met up for a quick catch up on 7.10.2 (which you'll want to read up on, see below), and some other technical nonsense about some work we've been doing. As a result ... [More] the current weekly notes have been slow - the current priority is the next release though, which leads us to... 7.10.2 status 7.10.2 is going to be out soon - our current plan is to have a release candidate on the weekend of Saturday the 13th, and the final release the next week. That means if you want something fixed, you'd better hollar very soon, or we're just not going to get to it! If you're wondering what's currently been fixed/scheduled, the ​status page shows the current set of tickets we've fixed and plan on fixing. List chatter Edward Z. Yang has written up a new wiki page to clearly explain and document all the various confusion around package keys, package ids, etc as a result of all the new Backpack work. If you're interested in this, it's definitely worth a read. ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009173.html Mark Lentczner sez: The Haskell Platform has finally outgrown Travis-CI, now going beyond the 50 minute build limit. Mark asks what alternatives we can use going forward. ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009174.html Jan Stolarek asks: in some cases, GHC will generate default instances or values, but that source code has no textual information location (for example, consider an instance clause without the where) - what do people think about fixing this, and are there anythings to look out for? ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009202.html David Luposchainsky has opened a new thread - about moving fail out of Monad and into its own typeclass, MonadFail. This change is a request that's very long in the tooth (older than the AMP or FTP changes by a landslide), but David's proposal has a clearly set out goal to tackle compatibility, warnings, and implementation. ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009186.html Noteworthy commits Commit 19ec6a84d6344c2808d0d41da11956689a0e4ae9 - Fix for CAF retention when dynamically loading & unloading code Commit 4a0b7a10442eec3747d5f95ef186a79bb0648754 - Build: run autoreconf jobs in parallel Closed tickets #10460, #7672, #9252, #9506, #10294, #5316, #10408, #10386, #9960, #10145, #9259, #10386, #9507, #8723, #10442, #5014, #4215, #10443, #8244, #10499, #10500, #10428, #10488, #10489, #10406, #10501, #10441, #10406, #10502, #9101, #9663, and #9945. [Less]

Hi *, It's that time once again - to get some info on what's happening in the world of GHC! It's been a quiet few weeks as a UK Holiday punted one of GHC HQ's meetings off, and this week we were only partially there. The main point of discussion ... [More] was 7.10.2, and continuing work on compiler performance. The good news is, the past few weeks have seen good work on both these fronts! 7.10.2 status 7.10.2 is swimming along very nicely - the ​status page shows the current set of tickets we've fixed and plan on fixing. Not much has changed from last time, except we've fixed even more bugs! We're currently sitting at about 85 bugs fixed, some of them pretty important - code generation bugs, compiler performance fixes, some RTS and event manager work. Your author is actually quite happy with what GHC 7.10.2 looks like, at this rate. List chatter Austin Seipp announced that GHC 7.10.2 will be release soon, and developers/users should get bugs they want fixed reported to us ASAP so we can do something. ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009150.html Mark Lentczner announced a Haskell Platform alpha featuring GHC 7.10.2 ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009128.html Facundo Dominguez asks: sometimes we want to create a static pointer in a function with a local definition, how can we do that? The current problem is the desugarer gets in the way and current approaches are currently rejected, but Facundo has some ideas/questions about a fix. ​https://mail.haskell.org/pipermail/ghc-devs/2015-May/009110.html David Macek has made great progress on getting native MSYS2 packages for windows working - which should be a great boon to all our Windows users! ​https://mail.haskell.org/pipermail/ghc-devs/2015-May/009089.html Joachim Breitner announced the new GHC performance dashboard, which can be used to track all of GHC's performance-based tests over time. Whoohoo! ​https://mail.haskell.org/pipermail/ghc-devs/2015-May/009032.html Joachim Breitner asked: is there a way to programmatically 'Raise a Concern' on a Phabricator commit? With the new ​https://perf.haskell.org/ghc/ work, it'd be nice if regressions could be automatically flagged. The current problem is there is no API endpoint, but one can be built. ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009128.html Adam Gundry asked ghc-devs about some input on changes to the new typechecker plugins API. After some discussion and elbow grease, the new changes have already landed in HEAD and will be in 7.12.1. ​https://mail.haskell.org/pipermail/ghc-devs/2015-May/009097.html Noteworthy commits Commit 45d9a15c4b85a2ed89579106bdafd84accf2cb39 - Fix a huge space leak in the mighty simplifier Commit c89bd681d34d3339771ebdde8aa468b1d9ab042b - Fix quadratic behavior in tidyOccName Commit b03f074fd51adfb9bc4f5275294712ee62741aed - ghci: Allow :back and :forward to take counts Commit 8e4dc8fb63b8d3bfee485c1c830776f3ed704f4d - Greatly speed up nativeCodeGen/seqBlocks Commit c256357242ee2dd282fd0516260edccbb7617244 - Speed up elimCommonBlocks by grouping blocks also by outgoing labels Commit f5188f3acd73a07b648924a58b9882c2d0a3dbcb - Fix weird behavior of -ignore-dot-ghci and -ghci-script Commit 4fffbc34c024231c3c9fac7a2134896cc09c7fb7 - New handling of overlapping instances in Safe Haskell Commit f16ddcee0c64a92ab911a7841a8cf64e3ac671fd - Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382 Commit cf7573b8207bbb17c58612f3345e0b17d74cfb58 - More accurate allocation stats for :set -s Closed tickets #10407, #10408, #10177, #10359, #10403, #10248, #9579, #10415, #10419, #10427, #10429, #10397, #10422, #10335, #10366, #10110, #10397, #10349, #10244, #8555, #8799, #9131, #10396, #10354, #10278, #9899, #3533, #9950, #10092, #9950, #10430, #9682, #9584, #10446, #10410, #10298, #10449, #10399, #7695, #10261, #8292, #10360, #10126, #10317, #10101, #10322, #10313, #10471, #10473, #7170, #10473, #10423, #10466, #8695, #10461, #10052, #10370, #10425, #10452, #10474, [Less]

Hi *, It's that time once again - to get some info on what's happening in the world of GHC! It's been a quiet few weeks as a UK Holiday punted one of GHC HQ's meetings off, and this week we were only partially there. The main point of discussion ... [More] was 7.10.2, and continuing work on compiler performance. The good news is, the past few weeks have seen good work on both these fronts! 7.10.2 status 7.10.2 is swimming along very nicely - the ​status page shows the current set of tickets we've fixed and plan on fixing. Not much has changed from last time, except we've fixed even more bugs! We're currently sitting at about 85 bugs fixed, some of them pretty important - code generation bugs, compiler performance fixes, some RTS and event manager work. Your author is actually quite happy with what GHC 7.10.2 looks like, at this rate. List chatter Austin Seipp announced that GHC 7.10.2 will be release soon, and developers/users should get bugs they want fixed reported to us ASAP so we can do something. ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009150.html Mark Lentczner announced a Haskell Platform alpha featuring GHC 7.10.2 ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009128.html Facundo Dominguez asks: sometimes we want to create a static pointer in a function with a local definition, how can we do that? The current problem is the desugarer gets in the way and current approaches are currently rejected, but Facundo has some ideas/questions about a fix. ​https://mail.haskell.org/pipermail/ghc-devs/2015-May/009110.html David Macek has made great progress on getting native MSYS2 packages for windows working - which should be a great boon to all our Windows users! ​https://mail.haskell.org/pipermail/ghc-devs/2015-May/009089.html Joachim Breitner announced the new GHC performance dashboard, which can be used to track all of GHC's performance-based tests over time. Whoohoo! ​https://mail.haskell.org/pipermail/ghc-devs/2015-May/009032.html Joachim Breitner asked: is there a way to programmatically 'Raise a Concern' on a Phabricator commit? With the new ​https://perf.haskell.org/ghc/ work, it'd be nice if regressions could be automatically flagged. The current problem is there is no API endpoint, but one can be built. ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009128.html Adam Gundry asked ghc-devs about some input on changes to the new typechecker plugins API. After some discussion and elbow grease, the new changes have already landed in HEAD and will be in 7.12.1. ​https://mail.haskell.org/pipermail/ghc-devs/2015-May/009097.html Noteworthy commits Commit 45d9a15c4b85a2ed89579106bdafd84accf2cb39 - Fix a huge space leak in the mighty simplifier Commit c89bd681d34d3339771ebdde8aa468b1d9ab042b - Fix quadratic behavior in tidyOccName Commit b03f074fd51adfb9bc4f5275294712ee62741aed - ghci: Allow :back and :forward to take counts Commit 8e4dc8fb63b8d3bfee485c1c830776f3ed704f4d - Greatly speed up nativeCodeGen/seqBlocks Commit c256357242ee2dd282fd0516260edccbb7617244 - Speed up elimCommonBlocks by grouping blocks also by outgoing labels Commit f5188f3acd73a07b648924a58b9882c2d0a3dbcb - Fix weird behavior of -ignore-dot-ghci and -ghci-script Commit 4fffbc34c024231c3c9fac7a2134896cc09c7fb7 - New handling of overlapping instances in Safe Haskell Commit f16ddcee0c64a92ab911a7841a8cf64e3ac671fd - Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382 Commit cf7573b8207bbb17c58612f3345e0b17d74cfb58 - More accurate allocation stats for :set -s Closed tickets #10407, #10408, #10177, #10359, #10403, #10248, #9579, #10415, #10419, #10427, #10429, #10397, #10422, #10335, #10366, #10110, #10397, #10349, #10244, #8555, #8799, #9131, #10396, #10354, #10278, #9899, #3533, #9950, #10092, #9950, #10430, #9682, #9584, #10446, #10410, #10298, #10449, #10399, #7695, #10261, #8292, #10360, #10126, #10317, #10101, #10322, #10313, #10471, #10473, #7170, #10473, #10423, #10466, #8695, #10461, #10052, #10370, #10425, #10452, #10474, [Less]

Hi *, It's that time once again - to get some info on what's happening in the world of GHC! It's been a quiet few weeks as a UK Holiday punted one of GHC HQ's meetings off, and this week we were only partially there. The main point of discussion ... [More] was 7.10.2, and continuing work on compiler performance. The good news is, the past few weeks have seen good work on both these fronts! 7.10.2 status 7.10.2 is swimming along very nicely - the ​status page shows the current set of tickets we've fixed and plan on fixing. Not much has changed from last time, except we've fixed even more bugs! We're currently sitting at about 85 bugs fixed, some of them pretty important - code generation bugs, compiler performance fixes, some RTS and event manager work. Your author is actually quite happy with what GHC 7.10.2 looks like, at this rate. List chatter Austin Seipp announced that GHC 7.10.2 will be release soon, and developers/users should get bugs they want fixed reported to us ASAP so we can do something. ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009150.html Mark Lentczner announced a Haskell Platform alpha featuring GHC 7.10.2 ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009128.html Facundo Dominguez asks: sometimes we want to create a static pointer in a function with a local definition, how can we do that? The current problem is the desugarer gets in the way and current approaches are currently rejected, but Facundo has some ideas/questions about a fix. ​https://mail.haskell.org/pipermail/ghc-devs/2015-May/009110.html David Macek has made great progress on getting native MSYS2 packages for windows working - which should be a great boon to all our Windows users! ​https://mail.haskell.org/pipermail/ghc-devs/2015-May/009089.html Joachim Breitner announced the new GHC performance dashboard, which can be used to track all of GHC's performance-based tests over time. Whoohoo! ​https://mail.haskell.org/pipermail/ghc-devs/2015-May/009032.html Joachim Breitner asked: is there a way to programmatically 'Raise a Concern' on a Phabricator commit? With the new ​https://perf.haskell.org/ghc/ work, it'd be nice if regressions could be automatically flagged. The current problem is there is no API endpoint, but one can be built. ​https://mail.haskell.org/pipermail/ghc-devs/2015-June/009128.html Adam Gundry asked ghc-devs about some input on changes to the new typechecker plugins API. After some discussion and elbow grease, the new changes have already landed in HEAD and will be in 7.12.1. ​https://mail.haskell.org/pipermail/ghc-devs/2015-May/009097.html Noteworthy commits Commit 45d9a15c4b85a2ed89579106bdafd84accf2cb39 - Fix a huge space leak in the mighty simplifier Commit c89bd681d34d3339771ebdde8aa468b1d9ab042b - Fix quadratic behavior in tidyOccName Commit b03f074fd51adfb9bc4f5275294712ee62741aed - ghci: Allow :back and :forward to take counts Commit 8e4dc8fb63b8d3bfee485c1c830776f3ed704f4d - Greatly speed up nativeCodeGen/seqBlocks Commit c256357242ee2dd282fd0516260edccbb7617244 - Speed up elimCommonBlocks by grouping blocks also by outgoing labels Commit f5188f3acd73a07b648924a58b9882c2d0a3dbcb - Fix weird behavior of -ignore-dot-ghci and -ghci-script Commit 4fffbc34c024231c3c9fac7a2134896cc09c7fb7 - New handling of overlapping instances in Safe Haskell Commit f16ddcee0c64a92ab911a7841a8cf64e3ac671fd - Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382 Commit cf7573b8207bbb17c58612f3345e0b17d74cfb58 - More accurate allocation stats for :set -s Closed tickets #10407, #10408, #10177, #10359, #10403, #10248, #9579, #10415, #10419, #10427, #10429, #10397, #10422, #10335, #10366, #10110, #10397, #10349, #10244, #8555, #8799, #9131, #10396, #10354, #10278, #9899, #3533, #9950, #10092, #9950, #10430, #9682, #9584, #10446, #10410, #10298, #10449, #10399, #7695, #10261, #8292, #10360, #10126, #10317, #10101, #10322, #10313, #10471, #10473, #7170, #10473, #10423, #10466, #8695, #10461, #10052, #10370, #10425, #10452, #10474, [Less]