GHC

Hi *, Welcome for the latest entry in the GHC Weekly News. Today GHC HQ met to discuss the status of the imminent 7.10.2 release. 7.10.2 Status In the past weeks we have been busily tracking down a number of regressions in the ghc-7.10 branch. ... [More] At this point we have built up an impressive ​list of fixes. Thanks to everyone who has helped in this process! In addition to resolving a number of simplifier regressions and portability issues (some mentioned in the Weekly News from 6 July), GHC 7.10.2 should be the first release which works out-of-the-box with GHCJS, thanks to a fix from Luite Stegeman. Moreover, we will have support for running in even the most minimal container environment (#10623). At this point we have successfully tested the pre-release against Stackage (thanks for Michael Snoyman and Herbert Valerio Riedel for making this possible) and have found no major issues. A source tarball will be finalized and sent to the binary builders today. With luck we will have releasable binaries by the end of the week. 7.11 Things Testing Thomas Miedema has been doing some amazing work fixing some long-standing validation failures on the master branch. Moreover, he has been examining the viability of enabling ​larger swaths of the testsuite in Harbormaster validations. In addition, Thomas has been doing some great work smoothing over a variety of rough edges in the build system and generally keeping things running smoothly. Thanks Thomas! Typeable implementation Another subject of discussion in this week's GHC call was ​Phabricator D757, a long-languishing change which moves the generation of Typeable instances from types' use sites to their definition sites. This change involves a trade-off as it moves compilation effort to the defining module, which will adversely affect compilation times of modules defining many types. Moreover, in the event that Typeable is never actually used this time is wasted effort. That being said, the current design of generating Typeable instances at the point of use makes the class a bit of a black sheep at the moment. Runtime system matters This week Simon Marlow will merge his ​D524, a rework of the runtime system's allocator which he reports has improved performance significantly in his workloads. This commit splits the concerns of reserving address space and requesting backing memory for this address space. While the former is relatively cheap, the latter can be quite expensive due to page-table setup. Consequently, his rework allocates a large chunk of addressing space up front and then incrementally commits it as needed. Interested readers are encouraged to look at the patch, which offers a nice glimpse into the inner workings of GHC's memory allocator. Simon also has finished ​Phab:D1076, which should improve garbage collector performance by reworking the logic responsible for scavenging static objects. This work will be merged shortly. Also discussed was the profiler mis-attribution issue mentioned in the Weekly News from 6 July 2015 (#10007). Peter Wortmann is currently looking at this issue, which ends up being due to an infelicity in the semantics implemented by the runtime system. Simon Marlow expressed that he did not know of a way to resolve this that isn't quite invasive. We will have to see what Peter proposes. Applicative do For some time now Simon Marlow has been working on ​implementing the ApplicativeDo proposal. Today in the call we discussed the status of this work and concluded that while some refactoring is likely possible, the work can be merged as-is. Hopefully at some point in the next few weeks this work will land. Haddock comments for GADT constructors It came to our attention that the GHC parser was unable to parse Haddock comments attached to GADT constructors. As it turns out, this is a rather long-standing problem. Despite this fact, the ​fix ended up being quite straightforward and will be in 7.12. Backwards Compatibility In general one should be able to compile the current GHC master branch with the last two compiler releases. Recently, however, the reality is a bit less clear-cut: while the current ghc-7.10 branch GHC will technically build with GHC 7.6 and 7.8, the tree does not necessarily pass the validate script due to a variety of imports rendered redundant by AMP and FTP. Moreover, the official policy on backwards compatibility is rather well-hidden on the Commentary/CodingStyle page. This was discussed in today's meeting and it was decided that we will in the future maintain full validation-compatibility with the previous two releases. To ease this we will relax the use of -Werror when building the stage 1 compiler. On a related note, this week Thomas Miedema ​ripped out some #ifdefs for GHC 7.6 compatibility from the master branch. Be aware that you will now need GHC 7.8 or newer to build master. Mac OS X El Capitan support It is well-known that the next Mac OS X release, El Capitan, will default to "root-less" mode, a security feature which restricts the operations available to even the root user. As a result of this feature some system calls in the El Capitan developer preview fail with EPERM instead of the usual EACCES. This change uncovered a bug in the unix library where EPERM was not treated similarly to EACCES. This was ​fixed in November 2014, a fix which is included in GHC 7.10.1. However, there have been a ​few calls on ghc-devs for a bugfix release of the 7.8 series including the updated unix. We discussed this in the call today and concluded that we would not make such a release. Given that El Capitan is not yet released and the issue is fixed in 7.10, it doesn't seem worthwhile to put more developer time into 7.8. We would suggest that any El Capitan user unable to update to GHC 7.10.1 or newer disable root-less mode for the time being. This can be accomplished with, sudo nvram boot-args="rootless=0" Infrastructure Recently it came to our attention that one of the build machines used by Harbormaster (Phabricator's build mechanism) was still running GHC 7.6. If you have seen strange validation issues on Harbormaster builds in the past, this is may be the cause. As of today this is fixed; all Harbormaster validations are now being built with GHC 7.8.4. Harbormaster has historically had trouble working with Differentials which changed submodule revisions. This has made testing revisions involving submodules quite tricky. Thanks to a ​patch from Adam Sandberg Eriksson Harbormaster can now grab submodule commits from non-upstream repositories if set in .gitmodules. Herbert Valerio Riedel has been making great strides improving the responsiveness of Trac. A Trac upgrade, a move to Postresql, and some fiddling with the WSGI configuration should result in a much better experience for everyone. Have a great week! ~ Ben [Less]

Hi *, Welcome for the latest entry in the GHC Weekly News. Today GHC HQ met to discuss the status of the imminent 7.10.2 release. 7.10.2 Status In the past weeks we have been busily tracking down a number of regressions in the ghc-7.10 branch. ... [More] At this point we have built up an impressive ​list of fixes. Thanks to everyone who has helped in this process! In addition to resolving a number of simplifier regressions and portability issues (some mentioned in the Weekly News from 6 July), GHC 7.10.2 should be the first release which works out-of-the-box with GHCJS, thanks to a fix from Luite Stegeman. Moreover, we will have support for running in even the most minimal container environment (#10623). At this point we have successfully tested the pre-release against Stackage (thanks for Michael Snoyman and Herbert Valerio Riedel for making this possible) and have found no major issues. A source tarball will be finalized and sent to the binary builders today. With luck we will have releasable binaries by the end of the week. 7.11 Things Testing Thomas Miedema has been doing some amazing work fixing some long-standing validation failures on the master branch. Moreover, he has been examining the viability of enabling ​larger swaths of the testsuite in Harbormaster validations. In addition, Thomas has been doing some great work smoothing over a variety of rough edges in the build system and generally keeping things running smoothly. Thanks Thomas! Typeable implementation Another subject of discussion in this week's GHC call was ​Phabricator D757, a long-languishing change which moves the generation of Typeable instances from types' use sites to their definition sites. This change involves a trade-off as it moves compilation effort to the defining module, which will adversely affect compilation times of modules defining many types. Moreover, in the event that Typeable is never actually used this time is wasted effort. That being said, the current design of generating Typeable instances at the point of use makes the class a bit of a black sheep at the moment. Runtime system matters This week Simon Marlow will merge his ​D524, a rework of the runtime system's allocator which he reports has improved performance significantly in his workloads. This commit splits the concerns of reserving address space and requesting backing memory for this address space. While the former is relatively cheap, the latter can be quite expensive due to page-table setup. Consequently, his rework allocates a large chunk of addressing space up front and then incrementally commits it as needed. Interested readers are encouraged to look at the patch, which offers a nice glimpse into the inner workings of GHC's memory allocator. Simon also has finished ​Phab:D1076, which should improve garbage collector performance by reworking the logic responsible for scavenging static objects. This work will be merged shortly. Also discussed was the profiler mis-attribution issue mentioned in the Weekly News from 6 July 2015 (#10007). Peter Wortmann is currently looking at this issue, which ends up being due to an infelicity in the semantics implemented by the runtime system. Simon Marlow expressed that he did not know of a way to resolve this that isn't quite invasive. We will have to see what Peter proposes. Applicative do For some time now Simon Marlow has been working on ​implementing the ApplicativeDo proposal. Today in the call we discussed the status of this work and concluded that while some refactoring is likely possible, the work can be merged as-is. Hopefully at some point in the next few weeks this work will land. Haddock comments for GADT constructors It came to our attention that the GHC parser was unable to parse Haddock comments attached to GADT constructors. As it turns out, this is a rather long-standing problem. Despite this fact, the ​fix ended up being quite straightforward and will be in 7.12. Backwards Compatibility In general one should be able to compile the current GHC master branch with the last two compiler releases. Recently, however, the reality is a bit less clear-cut: while the current ghc-7.10 branch GHC will technically build with GHC 7.6 and 7.8, the tree does not necessarily pass the validate script due to a variety of imports rendered redundant by AMP and FTP. Moreover, the official policy on backwards compatibility is rather well-hidden on the Commentary/CodingStyle page. This was discussed in today's meeting and it was decided that we will in the future maintain full validation-compatibility with the previous two releases. To ease this we will relax the use of -Werror when building the stage 1 compiler. On a related note, this week Thomas Miedema ​ripped out some #ifdefs for GHC 7.6 compatibility from the master branch. Be aware that you will now need GHC 7.8 or newer to build master. Mac OS X El Capitan support It is well-known that the next Mac OS X release, El Capitan, will default to "root-less" mode, a security feature which restricts the operations available to even the root user. As a result of this feature some system calls in the El Capitan developer preview fail with EPERM instead of the usual EACCES. This change uncovered a bug in the unix library where EPERM was not treated similarly to EACCES. This was ​fixed in November 2014, a fix which is included in GHC 7.10.1. However, there have been a ​few calls on ghc-devs for a bugfix release of the 7.8 series including the updated unix. We discussed this in the call today and concluded that we would not make such a release. Given that El Capitan is not yet released and the issue is fixed in 7.10, it doesn't seem worthwhile to put more developer time into 7.8. We would suggest that any El Capitan user unable to update to GHC 7.10.1 or newer disable root-less mode for the time being. This can be accomplished with, sudo nvram boot-args="rootless=0" Infrastructure Recently it came to our attention that one of the build machines used by Harbormaster (Phabricator's build mechanism) was still running GHC 7.6. If you have seen strange validation issues on Harbormaster builds in the past, this is may be the cause. As of today this is fixed; all Harbormaster validations are now being built with GHC 7.8.4. Harbormaster has historically had trouble working with Differentials which changed submodule revisions. This has made testing revisions involving submodules quite tricky. Thanks to a ​patch from Adam Sandberg Eriksson Harbormaster can now grab submodule commits from non-upstream repositories if set in .gitmodules. Herbert Valerio Riedel has been making great strides improving the responsiveness of Trac. A Trac upgrade, a move to Postresql, and some fiddling with the WSGI configuration should result in a much better experience for everyone. Have a great week! ~ Ben [Less]

Hi *, Welcome for the latest entry in the GHC Weekly News. Today GHC HQ met to discuss the status of the imminent 7.10.2 release. 7.10.2 Status In the past weeks we have been busily tracking down a number of regressions in the ghc-7.10 branch. ... [More] At this point we have built up an impressive ​list of fixes. Thanks to everyone who has helped in this process! In addition to resolving a number of simplifier regressions and portability issues (some mentioned in the Weekly News from 6 July), GHC 7.10.2 should be the first release which works out-of-the-box with GHCJS, thanks to a fix from Luite Stegeman. Moreover, we will have support for running in even the most minimal container environment (#10623). At this point we have successfully tested the pre-release against Stackage (thanks for Michael Snoyman and Herbert Valerio Riedel for making this possible) and have found no major issues. A source tarball will be finalized and sent to the binary builders today. With luck we will have releasable binaries by the end of the week. 7.11 Things Testing Thomas Miedema has been doing some amazing work fixing some long-standing validation failures on the master branch. Moreover, he has been examining the viability of enabling ​larger swaths of the testsuite in Harbormaster validations. In addition, Thomas has been doing some great work smoothing over a variety of rough edges in the build system and generally keeping things running smoothly. Thanks Thomas! Typeable implementation Another subject of discussion in this week's GHC call was ​Phabricator D757, a long-languishing change which moves the generation of Typeable instances from types' use sites to their definition sites. This change involves a trade-off as it moves compilation effort to the defining module, which will adversely affect compilation times of modules defining many types. Moreover, in the event that Typeable is never actually used this time is wasted effort. That being said, the current design of generating Typeable instances at the point of use makes the class a bit of a black sheep at the moment. Runtime system matters This week Simon Marlow will merge his ​D524, a rework of the runtime system's allocator which he reports has improved performance significantly in his workloads. This commit splits the concerns of reserving address space and requesting backing memory for this address space. While the former is relatively cheap, the latter can be quite expensive due to page-table setup. Consequently, his rework allocates a large chunk of addressing space up front and then incrementally commits it as needed. Interested readers are encouraged to look at the patch, which offers a nice glimpse into the inner workings of GHC's memory allocator. Simon also has finished ​Phab:D1076, which should improve garbage collector performance by reworking the logic responsible for scavenging static objects. This work will be merged shortly. Also discussed was the profiler mis-attribution issue mentioned in the Weekly News from 6 July 2015 (#10007). Peter Wortmann is currently looking at this issue, which ends up being due to an infelicity in the semantics implemented by the runtime system. Simon Marlow expressed that he did not know of a way to resolve this that isn't quite invasive. We will have to see what Peter proposes. Applicative do For some time now Simon Marlow has been working on ​implementing the ApplicativeDo proposal. Today in the call we discussed the status of this work and concluded that while some refactoring is likely possible, the work can be merged as-is. Hopefully at some point in the next few weeks this work will land. Haddock comments for GADT constructors It came to our attention that the GHC parser was unable to parse Haddock comments attached to GADT constructors. As it turns out, this is a rather long-standing problem. Despite this fact, the ​fix ended up being quite straightforward and will be in 7.12. Backwards Compatibility In general one should be able to compile the current GHC master branch with the last two compiler releases. Recently, however, the reality is a bit less clear-cut: while the current ghc-7.10 branch GHC will technically build with GHC 7.6 and 7.8, the tree does not necessarily pass the validate script due to a variety of imports rendered redundant by AMP and FTP. Moreover, the official policy on backwards compatibility is rather well-hidden on the Commentary/CodingStyle page. This was discussed in today's meeting and it was decided that we will in the future maintain full validation-compatibility with the previous two releases. To ease this we will relax the use of -Werror when building the stage 1 compiler. On a related note, this week Thomas Miedema ​ripped out some #ifdefs for GHC 7.6 compatibility from the master branch. Be aware that you will now need GHC 7.8 or newer to build master. Mac OS X El Capitan support It is well-known that the next Mac OS X release, El Capitan, will default to "root-less" mode, a security feature which restricts the operations available to even the root user. As a result of this feature some system calls in the El Capitan developer preview fail with EPERM instead of the usual EACCES. This change uncovered a bug in the unix library where EPERM was not treated similarly to EACCES. This was ​fixed in November 2014, a fix which is included in GHC 7.10.1. However, there have been a ​few calls on ghc-devs for a bugfix release of the 7.8 series including the updated unix. We discussed this in the call today and concluded that we would not make such a release. Given that El Capitan is not yet released and the issue is fixed in 7.10, it doesn't seem worthwhile to put more developer time into 7.8. We would suggest that any El Capitan user unable to update to GHC 7.10.1 or newer disable root-less mode for the time being. This can be accomplished with, sudo nvram boot-args="rootless=0" Infrastructure Recently it came to our attention that one of the build machines used by Harbormaster (Phabricator's build mechanism) was still running GHC 7.6. If you have seen strange validation issues on Harbormaster builds in the past, this is may be the cause. As of today this is fixed; all Harbormaster validations are now being built with GHC 7.8.4. Harbormaster has historically had trouble working with Differentials which changed submodule revisions. This has made testing revisions involving submodules quite tricky. Thanks to a ​patch from Adam Sandberg Eriksson Harbormaster can now grab submodule commits from non-upstream repositories if set in .gitmodules. Herbert Valerio Riedel has been making great strides improving the responsiveness of Trac. A Trac upgrade, a move to Postresql, and some fiddling with the WSGI configuration should result in a much better experience for everyone. Have a great week! ~ Ben [Less]

Hi *, Welcome for the latest entry in the GHC Weekly News. Today GHC HQ met to discuss the status of the imminent 7.10.2 release. 7.10.2 Status In the past weeks we have been busily tracking down a number of regressions in the ghc-7.10 branch. ... [More] At this point we have built up an impressive ​list of fixes. Thanks to everyone who has helped in this process! In addition to resolving a number of simplifier regressions and portability issues (some mentioned in the Weekly News from 6 July), GHC 7.10.2 should be the first release which works out-of-the-box with GHCJS, thanks to a fix from Luite Stegeman. Moreover, we will have support for running in even the most minimal container environment (#10623). At this point we have successfully tested the pre-release against Stackage (thanks for Michael Snoyman and Herbert Valerio Riedel for making this possible) and have found no major issues. A source tarball will be finalized and sent to the binary builders today. With luck we will have releasable binaries by the end of the week. 7.11 Things Testing Thomas Miedema has been doing some amazing work fixing some long-standing validation failures on the master branch. Moreover, he has been examining the viability of enabling ​larger swaths of the testsuite in Harbormaster validations. In addition, Thomas has been doing some great work smoothing over a variety of rough edges in the build system and generally keeping things running smoothly. Thanks Thomas! Typeable implementation Another subject of discussion in this week's GHC call was ​Phabricator D757, a long-languishing change which moves the generation of Typeable instances from types' use sites to their definition sites. This change involves a trade-off as it moves compilation effort to the defining module, which will adversely affect compilation times of modules defining many types. Moreover, in the event that Typeable is never actually used this time is wasted effort. That being said, the current design of generating Typeable instances at the point of use makes the class a bit of a black sheep at the moment. Runtime system matters This week Simon Marlow will merge his ​D524, a rework of the runtime system's allocator which he reports has improved performance significantly in his workloads. This commit splits the concerns of reserving address space and requesting backing memory for this address space. While the former is relatively cheap, the latter can be quite expensive due to page-table setup. Consequently, his rework allocates a large chunk of addressing space up front and then incrementally commits it as needed. Interested readers are encouraged to look at the patch, which offers a nice glimpse into the inner workings of GHC's memory allocator. Simon also has finished ​Phab:D1076, which should improve garbage collector performance by reworking the logic responsible for scavenging static objects. This work will be merged shortly. Also discussed was the profiler mis-attribution issue mentioned in the Weekly News from 6 July 2015 (#10007). Peter Wortmann is currently looking at this issue, which ends up being due to an infelicity in the semantics implemented by the runtime system. Simon Marlow expressed that he did not know of a way to resolve this that isn't quite invasive. We will have to see what Peter proposes. Applicative do For some time now Simon Marlow has been working on ​implementing the ApplicativeDo proposal. Today in the call we discussed the status of this work and concluded that while some refactoring is likely possible, the work can be merged as-is. Hopefully at some point in the next few weeks this work will land. Haddock comments for GADT constructors It came to our attention that the GHC parser was unable to parse Haddock comments attached to GADT constructors. As it turns out, this is a rather long-standing problem. Despite this fact, the ​fix ended up being quite straightforward and will be in 7.12. Backwards Compatibility In general one should be able to compile the current GHC master branch with the last two compiler releases. Recently, however, the reality is a bit less clear-cut: while the current ghc-7.10 branch GHC will technically build with GHC 7.6 and 7.8, the tree does not necessarily pass the validate script due to a variety of imports rendered redundant by AMP and FTP. Moreover, the official policy on backwards compatibility is rather well-hidden on the Commentary/CodingStyle page. This was discussed in today's meeting and it was decided that we will in the future maintain full validation-compatibility with the previous two releases. To ease this we will relax the use of -Werror when building the stage 1 compiler. On a related note, this week Thomas Miedema ​ripped out some #ifdefs for GHC 7.6 compatibility from the master branch. Be aware that you will now need GHC 7.8 or newer to build master. Mac OS X El Capitan support It is well-known that the next Mac OS X release, El Capitan, will default to "root-less" mode, a security feature which restricts the operations available to even the root user. As a result of this feature some system calls in the El Capitan developer preview fail with EPERM instead of the usual EACCES. This change uncovered a bug in the unix library where EPERM was not treated similarly to EACCES. This was ​fixed in November 2014, a fix which is included in GHC 7.10.1. However, there have been a ​few calls on ghc-devs for a bugfix release of the 7.8 series including the updated unix. We discussed this in the call today and concluded that we would not make such a release. Given that El Capitan is not yet released and the issue is fixed in 7.10, it doesn't seem worthwhile to put more developer time into 7.8. We would suggest that any El Capitan user unable to update to GHC 7.10.1 or newer disable root-less mode for the time being. This can be accomplished with, sudo nvram boot-args="rootless=0" Infrastructure Recently it came to our attention that one of the build machines used by Harbormaster (Phabricator's build mechanism) was still running GHC 7.6. If you have seen strange validation issues on Harbormaster builds in the past, this is may be the cause. As of today this is fixed; all Harbormaster validations are now being built with GHC 7.8.4. Harbormaster has historically had trouble working with Differentials which changed submodule revisions. This has made testing revisions involving submodules quite tricky. Thanks to a ​patch from Adam Sandberg Eriksson Harbormaster can now grab submodule commits from non-upstream repositories if set in .gitmodules. Herbert Valerio Riedel has been making great strides improving the responsiveness of Trac. A Trac upgrade, a move to Postresql, and some fiddling with the WSGI configuration should result in a much better experience for everyone. Have a great week! ~ Ben [Less]

Hi *, Welcome for the latest entry in the GHC Weekly News. Today GHC HQ met to discuss the status of the imminent 7.10.2 release. 7.10.2 Status In the past weeks we have been busily tracking down a number of regressions in the ghc-7.10 branch. ... [More] At this point we have built up an impressive ​list of fixes. Thanks to everyone who has helped in this process! In addition to resolving a number of simplifier regressions and portability issues (some mentioned in the Weekly News from 6 July), GHC 7.10.2 should be the first release which works out-of-the-box with GHCJS, thanks to a fix from Luite Stegeman. Moreover, we will have support for running in even the most minimal container environment (#10623). At this point we have successfully tested the pre-release against Stackage (thanks for Michael Snoyman and Herbert Valerio Riedel for making this possible) and have found no major issues. A source tarball will be finalized and sent to the binary builders today. With luck we will have releasable binaries by the end of the week. 7.11 Things Testing Thomas Miedema has been doing some amazing work fixing some long-standing validation failures on the master branch. Moreover, he has been examining the viability of enabling ​larger swaths of the testsuite in Harbormaster validations. In addition, Thomas has been doing some great work smoothing over a variety of rough edges in the build system and generally keeping things running smoothly. Thanks Thomas! Typeable implementation Another subject of discussion in this week's GHC call was ​Phabricator D757, a long-languishing change which moves the generation of Typeable instances from types' use sites to their definition sites. This change involves a trade-off as it moves compilation effort to the defining module, which will adversely affect compilation times of modules defining many types. Moreover, in the event that Typeable is never actually used this time is wasted effort. That being said, the current design of generating Typeable instances at the point of use makes the class a bit of a black sheep at the moment. Runtime system matters This week Simon Marlow will merge his ​D524, a rework of the runtime system's allocator which he reports has improved performance significantly in his workloads. This commit splits the concerns of reserving address space and requesting backing memory for this address space. While the former is relatively cheap, the latter can be quite expensive due to page-table setup. Consequently, his rework allocates a large chunk of addressing space up front and then incrementally commits it as needed. Interested readers are encouraged to look at the patch, which offers a nice glimpse into the inner workings of GHC's memory allocator. Simon also has finished ​Phab:D1076, which should improve garbage collector performance by reworking the logic responsible for scavenging static objects. This work will be merged shortly. Also discussed was the profiler mis-attribution issue mentioned in the Weekly News from 6 July 2015 (#10007). Peter Wortmann is currently looking at this issue, which ends up being due to an infelicity in the semantics implemented by the runtime system. Simon Marlow expressed that he did not know of a way to resolve this that isn't quite invasive. We will have to see what Peter proposes. Applicative do For some time now Simon Marlow has been working on ​implementing the ApplicativeDo proposal. Today in the call we discussed the status of this work and concluded that while some refactoring is likely possible, the work can be merged as-is. Hopefully at some point in the next few weeks this work will land. Haddock comments for GADT constructors It came to our attention that the GHC parser was unable to parse Haddock comments attached to GADT constructors. As it turns out, this is a rather long-standing problem. Despite this fact, the ​fix ended up being quite straightforward and will be in 7.12. Backwards Compatibility In general one should be able to compile the current GHC master branch with the last two compiler releases. Recently, however, the reality is a bit less clear-cut: while the current ghc-7.10 branch GHC will technically build with GHC 7.6 and 7.8, the tree does not necessarily pass the validate script due to a variety of imports rendered redundant by AMP and FTP. Moreover, the official policy on backwards compatibility is rather well-hidden on the Commentary/CodingStyle page. This was discussed in today's meeting and it was decided that we will in the future maintain full validation-compatibility with the previous two releases. To ease this we will relax the use of -Werror when building the stage 1 compiler. On a related note, this week Thomas Miedema ​ripped out some #ifdefs for GHC 7.6 compatibility from the master branch. Be aware that you will now need GHC 7.8 or newer to build master. Mac OS X El Capitan support It is well-known that the next Mac OS X release, El Capitan, will default to "root-less" mode, a security feature which restricts the operations available to even the root user. As a result of this feature some system calls in the El Capitan developer preview fail with EPERM instead of the usual EACCES. This change uncovered a bug in the unix library where EPERM was not treated similarly to EACCES. This was ​fixed in November 2014, a fix which is included in GHC 7.10.1. However, there have been a ​few calls on ghc-devs for a bugfix release of the 7.8 series including the updated unix. We discussed this in the call today and concluded that we would not make such a release. Given that El Capitan is not yet released and the issue is fixed in 7.10, it doesn't seem worthwhile to put more developer time into 7.8. We would suggest that any El Capitan user unable to update to GHC 7.10.1 or newer disable root-less mode for the time being. This can be accomplished with, sudo nvram boot-args="rootless=0" Infrastructure Recently it came to our attention that one of the build machines used by Harbormaster (Phabricator's build mechanism) was still running GHC 7.6. If you have seen strange validation issues on Harbormaster builds in the past, this is may be the cause. As of today this is fixed; all Harbormaster validations are now being built with GHC 7.8.4. Harbormaster has historically had trouble working with Differentials which changed submodule revisions. This has made testing revisions involving submodules quite tricky. Thanks to a ​patch from Adam Sandberg Eriksson Harbormaster can now grab submodule commits from non-upstream repositories if set in .gitmodules. Herbert Valerio Riedel has been making great strides improving the responsiveness of Trac. A Trac upgrade, a move to Postresql, and some fiddling with the WSGI configuration should result in a much better experience for everyone. Have a great week! ~ 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 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]