From ben at well-typed.com Fri Jul 22 13:05:15 2022 From: ben at well-typed.com (Ben Gamari) Date: Fri, 22 Jul 2022 09:05:15 -0400 Subject: [ANNOUNCE] GHC 9.4.1-rc1 is now available Message-ID: <87o7xhz4ax.fsf@smart-cactus.org> The GHC developers are happy to announce the availability of the first (and likely last) release candidate of GHC 9.4.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org]. This major release will include: - A new profiling mode, `-fprof-late`, which adds automatic cost-center annotations to all top-level functions *after* Core optimisation has run. This provides informative profiles while interfering significantly less with GHC's aggressive optimisations, making it easier to understand the performance of programs which depend upon simplification.. - A variety of plugin improvements including the introduction of a new plugin type, *defaulting plugins*, and the ability for typechecking plugins to rewrite type-families. - An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing. - Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs. - Generalisation of a variety of primitive types to be levity polymorphic. Consequently, the `ArrayArray#` type can at long last be retired, replaced by standard `Array#`. - Introduction of the `\cases` syntax from [GHC proposal 0302] - A complete overhaul of GHC's Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO. - Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects. - A refactoring of GHC's error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support. - Significant compile-time improvements to runtime and memory consumption. - On overhaul of our packaging infrastructure, allowing full traceability of release artifacts and more reliable binary distributions. - Reintroduction of deep subsumption (which was previously dropped with the *simplified subsumption* change) as a language extension. - ... and much more. See the [release notes] for a full accounting. Note that, as 9.4.1 is the first release for which the released artifacts will all be generated by our Hadrian build system, it is possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. We will be publishing a blog post describing the migration process to Hadrian in the coming weeks. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy testing, - Ben [downloads.haskell.org]: https://downloads.haskell.org/ghc/9.4.1-rc1/ [GHC proposal 0302]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-cases.rst [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian/bootstrap/README.md [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian [release notes]: https://downloads.haskell.org/~ghc/9.4.1-rc1/docs/users_guide/9.4.1-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From george.colpitts at gmail.com Fri Jul 22 17:43:25 2022 From: george.colpitts at gmail.com (George Colpitts) Date: Fri, 22 Jul 2022 14:43:25 -0300 Subject: [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: <87o7xhz4ax.fsf@smart-cactus.org> References: <87o7xhz4ax.fsf@smart-cactus.org> Message-ID: Hi Ben, I expected https://gitlab.haskell.org/ghc/ghc/-/issues/21506 (ghc-9.4.1-alpha1 does not install on macos: ghc-pkg-9.4.0-20220501 cannot be opened because the developer cannot be verified) to be fixed in rc1 but it is not. Are my expectations wrong? What is the ETA for fixing it? Thanks George On Fri, Jul 22, 2022 at 10:05 AM Ben Gamari wrote: > > The GHC developers are happy to announce the availability of the first > (and likely last) release candidate of GHC 9.4.1. Binary distributions, > source > distributions, and documentation are available at [downloads.haskell.org]. > > This major release will include: > > - A new profiling mode, `-fprof-late`, which adds automatic cost-center > annotations to all top-level functions *after* Core optimisation has > run. This provides informative profiles while interfering > significantly less with GHC's aggressive optimisations, making it > easier to understand the performance of programs which depend upon > simplification.. > > - A variety of plugin improvements including the introduction of a new > plugin type, *defaulting plugins*, and the ability for typechecking > plugins to rewrite type-families. > > - An improved constructed product result analysis, allowing unboxing of > nested structures, and a new boxity analysis, leading to less reboxing. > > - Introduction of a tag-check elision optimisation, bringing > significant performance improvements in strict programs. > > - Generalisation of a variety of primitive types to be levity > polymorphic. Consequently, the `ArrayArray#` type can at long last be > retired, replaced by standard `Array#`. > > - Introduction of the `\cases` syntax from [GHC proposal 0302] > > - A complete overhaul of GHC's Windows support. This includes a > migration to a fully Clang-based C toolchain, a deep refactoring of > the linker, and many fixes in WinIO. > > - Support for multiple home packages, significantly improving support > in IDEs and other tools for multi-package projects. > > - A refactoring of GHC's error message infrastructure, allowing GHC to > provide diagnostic information to downstream consumers as structured > data, greatly easing IDE support. > > - Significant compile-time improvements to runtime and memory consumption. > > - On overhaul of our packaging infrastructure, allowing full > traceability of release artifacts and more reliable binary > distributions. > > - Reintroduction of deep subsumption (which was previously dropped with > the > *simplified subsumption* change) as a language extension. > > - ... and much more. See the [release notes] for a full accounting. > > Note that, as 9.4.1 is the first release for which the released artifacts > will > all be generated by our Hadrian build system, it is possible that there > will be > packaging issues. If you enounter trouble while using a binary > distribution, > please open a [ticket]. Likewise, if you are a downstream packager, do > consider > migrating to [Hadrian] to run your build; the Hadrian build system can be > built > using `cabal-install`, `stack`, or the in-tree [bootstrap script]. We will > be > publishing a blog post describing the migration process to Hadrian in the > coming weeks. > > We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk > stake pool, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell > Foundation, and other anonymous contributors whose on-going financial > and in-kind support has facilitated GHC maintenance and release > management over the years. Finally, this release would not have been > possible without the hundreds of open-source contributors whose work > comprise this release. > > As always, do give this release a try and open a [ticket] if you see > anything amiss. > > Happy testing, > > - Ben > > [downloads.haskell.org]: https://downloads.haskell.org/ghc/9.4.1-rc1/ > [GHC proposal 0302]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-cases.rst > [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new > [bootstrap script]: > https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian/bootstrap/README.md > [Hadrian]: > https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian > [release notes]: > https://downloads.haskell.org/~ghc/9.4.1-rc1/docs/users_guide/9.4.1-notes.html > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sat Jul 23 03:30:28 2022 From: ben at well-typed.com (Ben Gamari) Date: Fri, 22 Jul 2022 23:30:28 -0400 Subject: [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: References: <87o7xhz4ax.fsf@smart-cactus.org> Message-ID: <87edyczeti.fsf@smart-cactus.org> George Colpitts writes: > Hi Ben, > > I expected https://gitlab.haskell.org/ghc/ghc/-/issues/21506 (ghc-9.4.1-alpha1 > does not install on macos: ghc-pkg-9.4.0-20220501 cannot be opened because > the developer cannot be verified) to be fixed in rc1 but it is not. Are my > expectations wrong? What is the ETA for fixing it? > Thanks for letting us know, George. The fix that we have [1] is present in 9.4.1-rc1. If that commit doesn't resolve the issue then there is something that we don't understand. Does `/usr/bin/xattr` exist? Running `xattr -rc` manually on the binary distribution allow you to run the compiler? Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/commit/641972d65b476aac11424bde6c3bcfda1c65aef5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From george.colpitts at gmail.com Sat Jul 23 11:20:17 2022 From: george.colpitts at gmail.com (George Colpitts) Date: Sat, 23 Jul 2022 08:20:17 -0300 Subject: [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: <87edyczeti.fsf@smart-cactus.org> References: <87o7xhz4ax.fsf@smart-cactus.org> <87edyczeti.fsf@smart-cactus.org> Message-ID: Hi Ben /ust/bin/xattr exists on my machine. Running "xattr -rc ." manually does not fix the bug as noted at the start of 21506. It was sufficient in the past but no longer fixes this error. As noted farther down in 21506 the workaround given in #17418 no longer works. It did not work in 9.2.2 either. The current workaround is similar to what Kazu explained in https://twitter.com/kazu_yamamoto/status/1500643489985761282 sudo xattr -rc . sudo spctl --global-disable ./configure sudo make install sudo spctl --global-enable It seems there are files created during sudo make install that have an issue as xattr -rc . was never run on them. Perhaps this is related to using Hadrian. Is it possible that the fix that was made was never tested? Thanks George On Sat, Jul 23, 2022 at 12:30 AM Ben Gamari wrote: > George Colpitts writes: > > > Hi Ben, > > > > I expected https://gitlab.haskell.org/ghc/ghc/-/issues/21506 > (ghc-9.4.1-alpha1 > > does not install on macos: ghc-pkg-9.4.0-20220501 cannot be opened > because > > the developer cannot be verified) to be fixed in rc1 but it is not. Are > my > > expectations wrong? What is the ETA for fixing it? > > > Thanks for letting us know, George. The fix that we have [1] is present > in 9.4.1-rc1. If that commit doesn't resolve the issue then there is > something that we don't understand. Does `/usr/bin/xattr` exist? Running > `xattr -rc` manually on the binary distribution allow you to run the > compiler? > > Cheers, > > - Ben > > > [1] > https://gitlab.haskell.org/ghc/ghc/-/commit/641972d65b476aac11424bde6c3bcfda1c65aef5 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sat Jul 23 13:03:53 2022 From: ben at well-typed.com (Ben Gamari) Date: Sat, 23 Jul 2022 09:03:53 -0400 Subject: [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: References: <87o7xhz4ax.fsf@smart-cactus.org> <87edyczeti.fsf@smart-cactus.org> Message-ID: <87bktgyo9s.fsf@smart-cactus.org> George Colpitts writes: > Hi Ben > > /ust/bin/xattr exists on my machine. Running "xattr -rc ." manually does > not fix the bug as noted at the start of 21506. It was sufficient in the > past but no longer fixes this error. As noted farther down in 21506 > > the workaround given in #17418 no longer works. > It did not work in 9.2.2 either. The current workaround is similar to what > Kazu explained in > https://twitter.com/kazu_yamamoto/status/1500643489985761282 > > sudo xattr -rc . > > sudo spctl --global-disable > > ./configure > > sudo make install > > sudo spctl --global-enable > > It seems there are files created during sudo make install that have an > issue as xattr -rc . was never run on them. Perhaps this is related to > using Hadrian. Is it possible that the fix that was made was never tested? > I tested the change both manually and via CI on the hardware that I have access to; in both cases installing the binary distribution resulted in a functional compiler. However, given how the effects of SIP are essentially undocumented, it is very hard to know what variables may be at play here. Running spctl --status on the machine on which I tested claims: > spctl --status objc[48908]: Class SPExecutionPolicy is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class AppWrapper is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class AppWrapperPolicyResult is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class AppWrapperPolicy is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPLog is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class MIS is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPExecutionHistoryItem is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPExecutionPolicyItem is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class SPDeveloperPolicy is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[48908]: Class GKScanResult is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. assessments enabled Which to me suggests that SIP (which, I imagine, is responsible for #21506) is enabled. However, the lack of comprehensive documentation here makes it very hard to say with certainty what might differ between your machine and mine. Without more information I don't know how to proceed here. Perhaps someone (Moritz or Simon, perhaps) with more familiarity with macOS has some insight? Thanks for your help in testing, George! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From george.colpitts at gmail.com Sat Jul 23 14:51:52 2022 From: george.colpitts at gmail.com (George Colpitts) Date: Sat, 23 Jul 2022 11:51:52 -0300 Subject: [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: <87bktgyo9s.fsf@smart-cactus.org> References: <87o7xhz4ax.fsf@smart-cactus.org> <87edyczeti.fsf@smart-cactus.org> <87bktgyo9s.fsf@smart-cactus.org> Message-ID: +Kazu Yamamoto Hi Ben My 2 machines also have: $ spctl --status assessments enabled I've duplicated the issue on both of my machines. It would be good to know if anybody else is seeing it. Kazu, I know you have seen this in the past. Do you get the same error installing rc1? When I run sudo make install I get a popup that says: *“libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib” cannot be opened because the developer cannot be verified.* When I cancel out of that I get another popup with the same error. When I hit cancel on that the script ends with the output: # We finally replace the original file. mv '/usr/local/lib/ghc-9.4.0.20220721/lib/package.conf.d/process-1.6.14.0.conf.copy.copy' '/usr/local/lib/ghc-9.4.0.20220721/lib/package.conf.d/process-1.6.14.0.conf' '/usr/local/lib/ghc-9.4.0.20220721/bin/ghc-pkg' --global-package-db "/usr/local/lib/ghc-9.4.0.20220721/lib/package.conf.d" recache dyld[32239]: Library not loaded: '@rpath/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' Referenced from: '/usr/local/lib/ghc-9.4.0.20220721/bin/ghc-pkg-9.4.0.20220721' Reason: tried:* '/usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (code signature in '/usr/local/lib/ghc-9.4.0.20220721/lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' not valid for use in process: library load disallowed by system policy), '$ORIGIN/../../../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such file), '/usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (code signature in '/usr/local/lib/ghc-9.4.0.20220721/lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' not valid for use in process: library load disallowed by system policy),* '$ORIGIN/../../../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such file), '/usr/local/lib/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such file), '/usr/lib/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such file) make: *** [update_package_db] Abort trap: 6 gcolpitts at macMini-2018 ghc-9.4.0.20220721-x86_64-apple-darwin % Hope this helps. Speculations: /usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib is created after xattr -rc . was run so it doesn't have the necessary attributes. Is it possible that ghc developers and/or the test machines have this file on another of the paths in the error message and that is why it works for them? I hope I didn't offend you by asking if the fix had been tested; I assume it had been but I thought it was important to rule that out. More than happy to test. I really appreciate all the work you and others have put into GHC ! Cheers George On Sat, Jul 23, 2022 at 10:03 AM Ben Gamari wrote: > George Colpitts writes: > > > Hi Ben > > > > /ust/bin/xattr exists on my machine. Running "xattr -rc ." manually does > > not fix the bug as noted at the start of 21506. It was sufficient in the > > past but no longer fixes this error. As noted farther down in 21506 > > > > the workaround given in #17418 no longer works. > > It did not work in 9.2.2 either. The current workaround is similar to > what > > Kazu explained in > > https://twitter.com/kazu_yamamoto/status/1500643489985761282 > > > > sudo xattr -rc . > > > > sudo spctl --global-disable > > > > ./configure > > > > sudo make install > > > > sudo spctl --global-enable > > > > It seems there are files created during sudo make install that have an > > issue as xattr -rc . was never run on them. Perhaps this is related to > > using Hadrian. Is it possible that the fix that was made was never > tested? > > > I tested the change both manually and via CI on the hardware that I have > access to; in both cases installing the binary distribution resulted in > a functional compiler. However, given how the effects of SIP are > essentially undocumented, it is very hard to know what variables may be > at play here. Running spctl --status on the machine on which I tested > claims: > > > spctl --status > objc[48908]: Class SPExecutionPolicy is implemented in both > /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy > and /usr/sbin/spctl. One of the two will be used. Which one is undefined. > objc[48908]: Class AppWrapper is implemented in both > /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy > and /usr/sbin/spctl. One of the two will be used. Which one is undefined. > objc[48908]: Class AppWrapperPolicyResult is implemented in both > /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy > and /usr/sbin/spctl. One of the two will be used. Which one is undefined. > objc[48908]: Class AppWrapperPolicy is implemented in both > /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy > and /usr/sbin/spctl. One of the two will be used. Which one is undefined. > objc[48908]: Class SPLog is implemented in both > /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy > and /usr/sbin/spctl. One of the two will be used. Which one is undefined. > objc[48908]: Class MIS is implemented in both > /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy > and /usr/sbin/spctl. One of the two will be used. Which one is undefined. > objc[48908]: Class SPExecutionHistoryItem is implemented in both > /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy > and /usr/sbin/spctl. One of the two will be used. Which one is undefined. > objc[48908]: Class SPExecutionPolicyItem is implemented in both > /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy > and /usr/sbin/spctl. One of the two will be used. Which one is undefined. > objc[48908]: Class SPDeveloperPolicy is implemented in both > /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy > and /usr/sbin/spctl. One of the two will be used. Which one is undefined. > objc[48908]: Class GKScanResult is implemented in both > /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy > and /usr/sbin/spctl. One of the two will be used. Which one is undefined. > assessments enabled > > Which to me suggests that SIP (which, I imagine, is responsible for > #21506) is enabled. However, the lack of comprehensive documentation > here makes it very hard to say with certainty what might differ between > your machine and mine. Without more information I don't know how to > proceed here. Perhaps someone (Moritz or Simon, perhaps) with more > familiarity with macOS has some insight? > > Thanks for your help in testing, George! > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Sun Jul 24 11:43:54 2022 From: george.colpitts at gmail.com (George Colpitts) Date: Sun, 24 Jul 2022 08:43:54 -0300 Subject: [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: References: <87o7xhz4ax.fsf@smart-cactus.org> <87edyczeti.fsf@smart-cactus.org> <87bktgyo9s.fsf@smart-cactus.org> Message-ID: + address that hopefully doesn't bounce for Moritz On Sat, Jul 23, 2022 at 11:51 AM George Colpitts wrote: > +Kazu Yamamoto > > Hi Ben > > My 2 machines also have: > > $ spctl --status > assessments enabled > > I've duplicated the issue on both of my machines. It would be good to know > if anybody else is seeing it. Kazu, I know you have seen this in the past. > Do you get the same error installing rc1? > When I run sudo make install I get a popup that says: > > *“libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib” cannot be opened because > the developer cannot be verified.* > > When I cancel out of that I get another popup with the same error. When I > hit cancel on that the script ends with the output: > > # We finally replace the original file. > mv > '/usr/local/lib/ghc-9.4.0.20220721/lib/package.conf.d/process-1.6.14.0.conf.copy.copy' > '/usr/local/lib/ghc-9.4.0.20220721/lib/package.conf.d/process-1.6.14.0.conf' > '/usr/local/lib/ghc-9.4.0.20220721/bin/ghc-pkg' --global-package-db > "/usr/local/lib/ghc-9.4.0.20220721/lib/package.conf.d" recache > dyld[32239]: Library not loaded: > '@rpath/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' > Referenced from: > '/usr/local/lib/ghc-9.4.0.20220721/bin/ghc-pkg-9.4.0.20220721' > Reason: tried:* > '/usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' > (code signature in > '/usr/local/lib/ghc-9.4.0.20220721/lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' > not valid for use in process: library load disallowed by system policy), > '$ORIGIN/../../../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' > (no such file), > '/usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' > (code signature in > '/usr/local/lib/ghc-9.4.0.20220721/lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' > not valid for use in process: library load disallowed by system policy),* > '$ORIGIN/../../../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' > (no such file), > '/usr/local/lib/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such > file), '/usr/lib/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib' (no such > file) > make: *** [update_package_db] Abort trap: 6 > gcolpitts at macMini-2018 ghc-9.4.0.20220721-x86_64-apple-darwin % > > Hope this helps. > > Speculations: > > /usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib > is created after xattr -rc . was run so it doesn't have the necessary > attributes. Is it possible that ghc developers and/or the test machines > have this file on another of the paths in the error message and that is why > it works for them? > > I hope I didn't offend you by asking if the fix had been tested; I assume > it had been but I thought it was important to rule that out. > > More than happy to test. I really appreciate all the work you and others > have put into GHC ! > > Cheers > George > > On Sat, Jul 23, 2022 at 10:03 AM Ben Gamari wrote: > >> George Colpitts writes: >> >> > Hi Ben >> > >> > /ust/bin/xattr exists on my machine. Running "xattr -rc ." manually does >> > not fix the bug as noted at the start of 21506. It was sufficient in the >> > past but no longer fixes this error. As noted farther down in 21506 >> > >> > the workaround given in #17418 no longer >> works. >> > It did not work in 9.2.2 either. The current workaround is similar to >> what >> > Kazu explained in >> > https://twitter.com/kazu_yamamoto/status/1500643489985761282 >> > >> > sudo xattr -rc . >> > >> > sudo spctl --global-disable >> > >> > ./configure >> > >> > sudo make install >> > >> > sudo spctl --global-enable >> > >> > It seems there are files created during sudo make install that have an >> > issue as xattr -rc . was never run on them. Perhaps this is related to >> > using Hadrian. Is it possible that the fix that was made was never >> tested? >> > >> I tested the change both manually and via CI on the hardware that I have >> access to; in both cases installing the binary distribution resulted in >> a functional compiler. However, given how the effects of SIP are >> essentially undocumented, it is very hard to know what variables may be >> at play here. Running spctl --status on the machine on which I tested >> claims: >> >> > spctl --status >> objc[48908]: Class SPExecutionPolicy is implemented in both >> /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy >> and /usr/sbin/spctl. One of the two will be used. Which one is undefined. >> objc[48908]: Class AppWrapper is implemented in both >> /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy >> and /usr/sbin/spctl. One of the two will be used. Which one is undefined. >> objc[48908]: Class AppWrapperPolicyResult is implemented in both >> /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy >> and /usr/sbin/spctl. One of the two will be used. Which one is undefined. >> objc[48908]: Class AppWrapperPolicy is implemented in both >> /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy >> and /usr/sbin/spctl. One of the two will be used. Which one is undefined. >> objc[48908]: Class SPLog is implemented in both >> /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy >> and /usr/sbin/spctl. One of the two will be used. Which one is undefined. >> objc[48908]: Class MIS is implemented in both >> /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy >> and /usr/sbin/spctl. One of the two will be used. Which one is undefined. >> objc[48908]: Class SPExecutionHistoryItem is implemented in both >> /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy >> and /usr/sbin/spctl. One of the two will be used. Which one is undefined. >> objc[48908]: Class SPExecutionPolicyItem is implemented in both >> /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy >> and /usr/sbin/spctl. One of the two will be used. Which one is undefined. >> objc[48908]: Class SPDeveloperPolicy is implemented in both >> /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy >> and /usr/sbin/spctl. One of the two will be used. Which one is undefined. >> objc[48908]: Class GKScanResult is implemented in both >> /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy >> and /usr/sbin/spctl. One of the two will be used. Which one is undefined. >> assessments enabled >> >> Which to me suggests that SIP (which, I imagine, is responsible for >> #21506) is enabled. However, the lack of comprehensive documentation >> here makes it very hard to say with certainty what might differ between >> your machine and mine. Without more information I don't know how to >> proceed here. Perhaps someone (Moritz or Simon, perhaps) with more >> familiarity with macOS has some insight? >> >> Thanks for your help in testing, George! >> >> Cheers, >> >> - Ben >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sun Jul 24 14:33:29 2022 From: ben at well-typed.com (Ben Gamari) Date: Sun, 24 Jul 2022 10:33:29 -0400 Subject: [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: References: <87o7xhz4ax.fsf@smart-cactus.org> <87edyczeti.fsf@smart-cactus.org> <87bktgyo9s.fsf@smart-cactus.org> Message-ID: <878roizilc.fsf@smart-cactus.org> George Colpitts writes: > +Kazu Yamamoto > > Hi Ben > > My 2 machines also have: > > $ spctl --status > assessments enabled > Hmm, interesting. Then I am truly perplexed. > Speculations: > > /usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib > is created after xattr -rc . was run so it doesn't have the necessary > attributes. Is it possible that ghc developers and/or the test machines > have this file on another of the paths in the error message and that is why > it works for them? > I'm not sure where this would be but at this point anything is possible. What happens if you try to install to do something like (in the extracted binary distribution), $ ./configure --prefix=`pwd`/tmp $ make install # this will fail $ xattr -rc . $ make install # perhaps this will finish successfully? # tmp/bin/ghc --version # GHC should be usable > I hope I didn't offend you by asking if the fix had been tested; I assume > it had been but I thought it was important to rule that out. > Not to worry; it's a very reasonable question to ask given the circumstances. > More than happy to test. I really appreciate all the work you and others > have put into GHC ! > Ultimately I think we may just need to bite the bullet and start properly notarising/codesigning releases (resolving #17418). At this point we have spent more time trying to avoid the notarisation requirement than it would likely take to satisfy it. Unfortunately, this will require that I find an Apple device somewhere which may take a few weeks. I'm afraid I am on holiday next week but I would quite grateful if we could arrange for a chat after I return such that we can debug this in realtime. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From george.colpitts at gmail.com Sun Jul 24 16:58:41 2022 From: george.colpitts at gmail.com (George Colpitts) Date: Sun, 24 Jul 2022 13:58:41 -0300 Subject: success on a slightly modified version of your suggestion for 21506 In-Reply-To: <878roizilc.fsf@smart-cactus.org> References: <87o7xhz4ax.fsf@smart-cactus.org> <87edyczeti.fsf@smart-cactus.org> <87bktgyo9s.fsf@smart-cactus.org> <878roizilc.fsf@smart-cactus.org> Message-ID: Hi Ben Thanks for the quick responses particularly on the weekend before your vacation. you wrote: What happens if you try to install to do something like (in the extracted binary distribution), $ ./configure --prefix=`pwd`/tmp $ make install # this will fail $ xattr -rc . $ make install # perhaps this will finish successfully? # tmp/bin/ghc --version # GHC should be usable success on both my machines using a slightly modified version of your suggestion above for 21506: ./configure --prefix=`pwd`/tmp # specifying ./tmp seems to be critical xattr -rc . # seems to be necessary also sudo make install # seems to works , output ends with "recache" ./tmp/bin/ghc --version # success , although admittedly the smallest smoke test possible You wrote: > Ultimately I think we may just need to bite the bullet and start properly notarising/codesigning releases (resolving #17418). At this point we have spent more time trying to avoid the notarisation requirement than it would likely take to satisfy it. Unfortunately, this will require that I find an Apple device somewhere which may take a few weeks. I'm afraid I am on holiday next week but I would quite grateful if we could arrange for a chat after I return such that we can debug this in realtime. Sure, we can chat when you return from your vacation. Not sure if it is worth trying to fix the release on the basis of what I write above. My opinion is: it is if we can get reports of at least one other person having this issue. I am fine with not doing this for 9.4.1 I agree that we should raise the priority of "notarising/codesigning releases (resolving #17418)". My opinion is that it is not worth delaying 9.4.1 for this. Have a great vacation. Cheers George On Sun, Jul 24, 2022 at 11:33 AM Ben Gamari wrote: > George Colpitts writes: > > > +Kazu Yamamoto > > > > Hi Ben > > > > My 2 machines also have: > > > > $ spctl --status > > assessments enabled > > > Hmm, interesting. Then I am truly perplexed. > > > Speculations: > > > > > /usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib > > is created after xattr -rc . was run so it doesn't have the necessary > > attributes. Is it possible that ghc developers and/or the test machines > > have this file on another of the paths in the error message and that is > why > > it works for them? > > > I'm not sure where this would be but at this point anything is possible. > What happens > if you try to install to do something like (in the extracted binary > distribution), > > $ ./configure --prefix=`pwd`/tmp > $ make install # this will fail > $ xattr -rc . > $ make install # perhaps this will finish successfully? > # tmp/bin/ghc --version # GHC should be usable > > > I hope I didn't offend you by asking if the fix had been tested; I assume > > it had been but I thought it was important to rule that out. > > > Not to worry; it's a very reasonable question to ask given the > circumstances. > > > More than happy to test. I really appreciate all the work you and others > > have put into GHC ! > > > Ultimately I think we may just need to bite the bullet and start > properly notarising/codesigning releases (resolving #17418). At this point > we have > spent more time trying to avoid the notarisation requirement than > it would likely take to satisfy it. Unfortunately, this will require > that I find an Apple device somewhere which may take a few weeks. > > I'm afraid I am on holiday next week but I would quite grateful if we > could arrange for a chat after I return such that we can debug this in > realtime. > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clintonmead at gmail.com Mon Jul 25 04:15:49 2022 From: clintonmead at gmail.com (Clinton Mead) Date: Mon, 25 Jul 2022 14:15:49 +1000 Subject: Compilation of Overloaded strings and saving constant results Message-ID: Hi All I'm presuming (correct me if I'm wrong) that when I have an overloaded string literal in my program, let's say it's overloaded to Text, the conversion from [Char] -> Text happens at runtime, instead of what would be ideal being that the compiler somehow does that conversion at compile time and puts the raw bytes that represent the Text object in the executable? If it does work like that, that's not a big deal. But let's say I have: f :: Text -> Text -> Text f x y = Text.concat ["Hello", x, "World", y] This is desugared like so: f :: Text -> Text -> Text f x y = Text.concat [fromString "Hello", x, fromString "World", y] Would there be a [Char] -> Text conversion from ['H', 'e', 'l', 'l', 'o'] -> Text "Hello" everytime 'f' is called, or is 'f' rewritten something like this: f :: Text -> Text -> Text f x y = Text.concat [hello, x, world, y] hello :: Text hello = fromString "Hello" world :: Text world = fromString "World" So the [Char] -> Text conversion is only done once and memomised? I guess this brings up the more general question, if I have this: f x = h x (g (42 :: Int)) Can I rely on GHC rewriting it like this? f x = h x y y = g (42 :: Int) Or is this a transformation I should do explicitly if I want to rely on it? (I've added ":: Int" because I guess it can't do this when there's polymorphism sneaking in) Thanks, Clinton -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Mon Jul 25 04:23:17 2022 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Mon, 25 Jul 2022 13:23:17 +0900 (JST) Subject: [ANNOUNCE] GHC 9.4.1-rc1 is now available In-Reply-To: References: <87bktgyo9s.fsf@smart-cactus.org> Message-ID: <20220725.132317.759628945463268605.kazu@iij.ad.jp> Hi George, > I've duplicated the issue on both of my machines. It would be good to know > if anybody else is seeing it. Kazu, I know you have seen this in the past. > Do you get the same error installing rc1? > When I run sudo make install I get a popup that says: I had no problem on 9.4.1-rc1. "xattr -rc ." and "make install" worked perfectly. macOS Monterey v12.4 Xcode 13.4.1 --Kazu From adam at well-typed.com Mon Jul 25 19:53:52 2022 From: adam at well-typed.com (Adam Gundry) Date: Mon, 25 Jul 2022 20:53:52 +0100 Subject: Compilation of Overloaded strings and saving constant results In-Reply-To: References: Message-ID: <6eb2f66b-88b2-3fbf-55d7-dcc4bb272cd3@well-typed.com> Hi Clinton, On 25/07/2022 05:15, Clinton Mead wrote: > I'm presuming (correct me if I'm wrong) that when I have an overloaded > string literal in my program, let's say it's overloaded to Text, the > conversion from [Char] -> Text happens at runtime, instead of what would > be ideal being that the compiler somehow does that conversion at compile > time and puts the raw bytes that represent the Text object in the > executable? GHC can actually do a little bit better than this, because a literal is stored in the binary as a CString# rather than a list of Char. Thus the conversion doesn't need to follow a linked list, but it is still O(n). > If it does work like that, that's not a big deal. But let's say I have: > > f :: Text -> Text -> Text > f x y = Text.concat ["Hello", x, "World", y] > > This is desugared like so: > > f :: Text -> Text -> Text > f x y = Text.concat [fromString "Hello", x, fromString "World", y] > > Would there be a [Char] -> Text conversion from ['H', 'e', 'l', 'l', > 'o'] -> Text "Hello" everytime 'f' is called, or is 'f' > rewritten something like this: > > f :: Text -> Text -> Text > f x y = Text.concat [hello, x, world, y] > > hello :: Text > hello = fromString "Hello" > > world :: Text > world = fromString "World" > > So the [Char] -> Text conversion is only done once and memomised? This transformation is known as "let floating" or "full-laziness" and is enabled with -O1. The easiest way to see this is to put this definition in a module and compile it, like this: $ ghc-9.2.2 M.hs -ddump-simpl -dno-typeable-binds -dsuppress-all -O0 The Core output takes a bit of decoding, but if you squint you can see the definition of f is essentially unchanged: f = \ x_arM y_arN -> concat (: (($fIsStringText `cast` ) (unpackCString# "Hello"#)) (: x_arM (: (($fIsStringText `cast` ) (unpackCString# "World"#)) (: y_arN [])))) If you compile with -O1 instead you get: f4 = "Hello"# f3 = unpackCString# f4 f2 = "World"# f1 = unpackCString# f2 f = \ x_arI y_arJ -> concat (: f3 (: x_arI (: f1 (: y_arJ [])))) which is pretty much what you wanted. > I guess this brings up the more general question, if I have this: > > f x = h x (g (42 :: Int)) > > Can I rely on GHC rewriting it like this? > > f x = h x y > y = g (42 :: Int) > > Or is this a transformation I should do explicitly if I want to rely on it? In this case, a similar experiment shows that GHC will float out the function call (here I've used NOINLINE to prevent the function applications being optimised out): f x = h x (g 42) {-# NOINLINE g #-} g :: Int -> Int g x = x {-# NOINLINE h #-} h :: Int -> Int -> Int h x y = x * y Compiling the above gives this Core: f2 = I# 42# f1 = g f2 f = \ x_atQ -> h x_atQ f1 Whether you can rely on this is a slightly different question though. There are lots of heuristics in GHC's optimiser which mean that in more complicated situations it will not always apply full-laziness as much as possible. Moreover, full-laziness can introduce space leaks. My colleague Edsko wrote a nice blog post a few years ago that explores this in more detail: https://www.well-typed.com/blog/2016/09/sharing-conduit/ Hope this helps, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England From carter.schonwald at gmail.com Wed Jul 27 13:25:39 2022 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 27 Jul 2022 09:25:39 -0400 Subject: success on a slightly modified version of your suggestion for 21506 In-Reply-To: References: <87o7xhz4ax.fsf@smart-cactus.org> <87edyczeti.fsf@smart-cactus.org> <87bktgyo9s.fsf@smart-cactus.org> <878roizilc.fsf@smart-cactus.org> Message-ID: that matches my experience, namely that i've successfully installed ghc 9.2.2 on osx 12.4 aka monterey a few times On Sun, Jul 24, 2022 at 12:59 PM George Colpitts wrote: > Hi Ben > > Thanks for the quick responses particularly on the weekend before your > vacation. > > you wrote: > > What happens > if you try to install to do something like (in the extracted binary > distribution), > > > $ ./configure --prefix=`pwd`/tmp > $ make install # this will fail > $ xattr -rc . > $ make install # perhaps this will finish successfully? > # tmp/bin/ghc --version # GHC should be usable > > > success on both my machines using a slightly modified version of your > suggestion above for 21506: > > ./configure --prefix=`pwd`/tmp # specifying ./tmp seems to be critical > > xattr -rc . # seems to be necessary > also > > sudo make install # seems to works , output ends > with "recache" > > ./tmp/bin/ghc --version # success , although admittedly > the smallest smoke test possible > > You wrote: > > > > Ultimately I think we may just need to bite the bullet and start > properly notarising/codesigning releases (resolving #17418). At this point > we have > spent more time trying to avoid the notarisation requirement than > it would likely take to satisfy it. Unfortunately, this will require > that I find an Apple device somewhere which may take a few weeks. > > > I'm afraid I am on holiday next week but I would quite grateful if we > could arrange for a chat after I return such that we can debug this in > realtime. > > > Sure, we can chat when you return from your vacation. > > Not sure if it is worth trying to fix the release on the basis of what I > write above. My opinion is: it is if we can get reports of at least one > other person having this issue. I am fine with not doing this for 9.4.1 > > I agree that we should raise the priority of "notarising/codesigning > releases (resolving #17418)". My opinion is that it is not worth delaying > 9.4.1 for this. > > Have a great vacation. > > Cheers > George > > > > > > > On Sun, Jul 24, 2022 at 11:33 AM Ben Gamari wrote: > >> George Colpitts writes: >> >> > +Kazu Yamamoto >> > >> > Hi Ben >> > >> > My 2 machines also have: >> > >> > $ spctl --status >> > assessments enabled >> > >> Hmm, interesting. Then I am truly perplexed. >> >> > Speculations: >> > >> > >> /usr/local/lib/ghc-9.4.0.20220721/bin/../lib/x86_64-osx-ghc-9.4.0.20220721/libHSterminfo-0.4.1.5-ghc9.4.0.20220721.dylib >> > is created after xattr -rc . was run so it doesn't have the necessary >> > attributes. Is it possible that ghc developers and/or the test machines >> > have this file on another of the paths in the error message and that is >> why >> > it works for them? >> > >> I'm not sure where this would be but at this point anything is possible. >> What happens >> if you try to install to do something like (in the extracted binary >> distribution), >> >> $ ./configure --prefix=`pwd`/tmp >> $ make install # this will fail >> $ xattr -rc . >> $ make install # perhaps this will finish successfully? >> # tmp/bin/ghc --version # GHC should be usable >> >> > I hope I didn't offend you by asking if the fix had been tested; I >> assume >> > it had been but I thought it was important to rule that out. >> > >> Not to worry; it's a very reasonable question to ask given the >> circumstances. >> >> > More than happy to test. I really appreciate all the work you and others >> > have put into GHC ! >> > >> Ultimately I think we may just need to bite the bullet and start >> properly notarising/codesigning releases (resolving #17418). At this >> point we have >> spent more time trying to avoid the notarisation requirement than >> it would likely take to satisfy it. Unfortunately, this will require >> that I find an Apple device somewhere which may take a few weeks. >> >> I'm afraid I am on holiday next week but I would quite grateful if we >> could arrange for a chat after I return such that we can debug this in >> realtime. >> >> Cheers, >> >> - Ben >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zubin at well-typed.com Thu Jul 28 11:17:13 2022 From: zubin at well-typed.com (Zubin Duggal) Date: Thu, 28 Jul 2022 16:47:13 +0530 Subject: [Haskell] [ANNOUNCE] GHC 9.2.4 released Message-ID: <20220728111713.owpnsu43zwq2klhn@zubin-msi> The GHC developers are very happy to at announce the availability of GHC 9.2.4. Binary distributions, source distributions, and documentation are available at [`downloads.haskell.org`](https://downloads.haskell.org/ghc/9.2.4). Download Page: https://www.haskell.org/ghc/download_ghc_9_2_4.html Blog Post: https://www.haskell.org/ghc/blog/20220728-ghc-9.2.4-released.html This release will include: - The new `DeepSubsumption` language extension which reverses the effects of the [Simplified Subsumption Proposal] introduced in GHC 9.0. This is an attempt to make GHC 9.2.4 more backwards compatible with GHC 8.10 and eases migration for users who depended on this feature. This extension is enabled by default with the `Haskell2010` and `Haskell98` languages but disabled with the `GHC2021` language originally introduced in GHC 9.2.1. See the [Deep Subsumption Proposal] for more details. - Fixes for segfaults that may arise due to a bug in the implementation of the `keepAlive#` primop. This may regress performance for certain programs which use this primop or functions which use the primop, such as `withForeignPtr`. These regressions are mostly small, but can be larger in certain edge cases. Judicious use of `unsafeWithForeignPtr` when its argument is known not to statically diverge can mitigate these in many cases. It is our judgment that the critical correctness issues justify the regression in performance and that it is important to get a release out with the fix while we work on a better approach which will improve performance for future releases (#21708). We have a [wiki page](https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/with-combinator) that tracks possible solutions to this problem, and Ben wrote a [blog post](https://www.haskell.org/ghc/blog/20210607-the-keepAlive-story.html) detailing the introduction of the `keepAlive#` primop and its history. - Fixes for a number of miscompilations on AArch64 and other platforms (#21624, #21773, #20735, #21685). - Fixes for segfaults due to bugs in the RTS and GC (#21708, #21880, #21885). - Fixing the behaviour of Ctrl-C with GHCi on Windows (#21889). - ... and much more. See the [release notes] for a full accounting. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.2.4/docs/users_guide/9.2.4-notes.html [Simplified Subsumption Proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst [Deep Subsumption Proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0511-deep-subsumption.rst -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From george.colpitts at gmail.com Thu Jul 28 15:52:01 2022 From: george.colpitts at gmail.com (George Colpitts) Date: Thu, 28 Jul 2022 12:52:01 -0300 Subject: [Haskell] [ANNOUNCE] GHC 9.2.4 released In-Reply-To: <20220728111713.owpnsu43zwq2klhn@zubin-msi> References: <20220728111713.owpnsu43zwq2klhn@zubin-msi> Message-ID: Thanks Zubin, this is good news. On a Mac when do ./configure I see checking Xcode version... xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance not found (too old?) I assume I can ignore that but FWIW it's weird as I do have that directory and it is not old: $ ls -ld /Library/Developer/CommandLineTools drwxr-xr-x@ 5 root wheel 160 27 May 20:54 /Library/Developer/CommandLineTools $ xcode-select --version xcode-select version 2395. On a Mac it is still necessary to do xattr -rc . before doing sudo make install this is also true for 9.4.1-rc1 which I noted in 21506 . Thanks George On Thu, Jul 28, 2022 at 8:17 AM Zubin Duggal wrote: > The GHC developers are very happy to at announce the availability of GHC > 9.2.4. Binary distributions, source distributions, and documentation are > available at [`downloads.haskell.org`]( > https://downloads.haskell.org/ghc/9.2.4). > > Download Page: https://www.haskell.org/ghc/download_ghc_9_2_4.html > Blog Post: > https://www.haskell.org/ghc/blog/20220728-ghc-9.2.4-released.html > > This release will include: > > - The new `DeepSubsumption` language extension which reverses the > effects of the [Simplified Subsumption Proposal] introduced in GHC > 9.0. This > is an attempt to make GHC 9.2.4 more backwards compatible with GHC > 8.10 and > eases migration for users who depended on this feature. > > This extension is enabled by default with the `Haskell2010` > and `Haskell98` languages but disabled with the `GHC2021` > language originally introduced in GHC 9.2.1. > > See the [Deep Subsumption Proposal] for more details. > > - Fixes for segfaults that may arise due to a bug in the implementation > of the > `keepAlive#` primop. This may regress performance for certain programs > which > use this primop or functions which use the primop, such as > `withForeignPtr`. > These regressions are mostly small, but can be larger in certain edge > cases. > Judicious use of `unsafeWithForeignPtr` when its argument is known not > to > statically diverge can mitigate these in many cases. It is our > judgment that > the critical correctness issues justify the regression in performance > and that > it is important to get a release out with the fix while we work on a > better > approach which will improve performance for future releases (#21708). > > We have a [wiki page]( > https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/with-combinator) > that tracks possible solutions to this problem, and Ben wrote a > [blog post]( > https://www.haskell.org/ghc/blog/20210607-the-keepAlive-story.html) > detailing the introduction of the `keepAlive#` primop and its history. > > - Fixes for a number of miscompilations on AArch64 and other platforms > (#21624, > #21773, #20735, #21685). > > - Fixes for segfaults due to bugs in the RTS and GC (#21708, #21880, > #21885). > > - Fixing the behaviour of Ctrl-C with GHCi on Windows (#21889). > > - ... and much more. See the [release notes] for a full accounting. > > As some of the fixed issues do affect correctness users are encouraged to > upgrade promptly. > > We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk > stake pool, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, > and other anonymous > contributors whose on-going financial and in-kind support has > facilitated GHC maintenance and release management over the years. > Finally, this release would not have been possible without the hundreds > of open-source contributors whose work comprise this release. > > As always, do give this release a try and open a [ticket] if you see > anything amiss. > > Happy compiling, > > - Zubin > > [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new > [release notes]: > https://downloads.haskell.org/~ghc/9.2.4/docs/users_guide/9.2.4-notes.html > [Simplified Subsumption Proposal]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst > [Deep Subsumption Proposal]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0511-deep-subsumption.rst > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Fri Jul 29 02:10:54 2022 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Fri, 29 Jul 2022 11:10:54 +0900 (JST) Subject: [Haskell] [ANNOUNCE] GHC 9.2.4 released In-Reply-To: References: <20220728111713.owpnsu43zwq2klhn@zubin-msi> Message-ID: <20220729.111054.1976367299003263525.kazu@iij.ad.jp> Hi, > On a Mac it is still necessary to do > > xattr -rc . > > before doing > > sudo make install For 9.2.4, "xattr -rc ." is not good enough on my Mac (upgraded to v12.5 today). "sudo spctl --global-disable" is necessary, sigh. --Kazu