July 2022 - Haskell-Cafe

[ANN] cabal-clean (new tool)
by Andreas Abel 19 Aug '22

19 Aug '22

=== Wondering where your disk space goes with too many Haskell projects compiled with too many GHC versions? === https://hackage.haskell.org/package/cabal-clean https://github.com/andreasabel/cabal-clean `cabal-clean` is a small executable that removes outdated cabal build artifacts from `dist-newstyle`. A build tree is considered outdated if there is one with either - a newer version of the package you are building, or - a newer minor version of the GHC compiler. In contrast to `cabal clean`, the tool `cabal-clean` retains the latest build trees for each GHC major version. Thus, it is geared towards multi-GHC development. Example: (self-applied to cabal-clean's build directory) --- 3.7M ghc-8.8.4 /cabal-clean-0.1.20210815 --- 3.5M ghc-8.10.6/cabal-clean-0.1.20210815 --- 3.7M ghc-9.0.1 /cabal-clean-0.1.20210815 --- 3.5M ghc-8.10.6/cabal-clean-0.1.20210924 +++ 3.6M ghc-8.10.7/cabal-clean-0.1.20210924 +++ 3.7M ghc-9.0.1 /cabal-clean-0.1.20210924 The directories prefixed with --- will be deleted, the ones with +++ retained. Disclaimers: 1. cabal-clean does not check whether deletion will cause dangling references like broken symlinks etc. (Could happen if you created a symlink to an executable that resides in one of the deleted build directories.) 2. cabal-clean does not read nor utilize information from the .cabal file. 3. Calls `du` ("disk usage"), so, might not work on Windows. Enjoy, Andreas

6 6

[ANNOUNCE] GHC 9.4.1-rc1 is now available
by Ben Gamari 08 Aug '22

08 Aug '22

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-c… [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [release notes]: https://downloads.haskell.org/~ghc/9.4.1-rc1/docs/users_guide/9.4.1-notes.h…

6 19

Re: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1-rc1 is now available
by Kazu Yamamoto 02 Aug '22

02 Aug '22

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

2 1

Why do I see the escape chars in Emacs with haskell-mode
by Henry Laxen 30 Jul '22

30 Jul '22

Dear Cafe, Greeting Gentle Haskellers, I know this may really be a question for the emacs guys, but I thought for sure someone here has encoutered the same thing and would recognize the problem right away. Here is my progam: module Main where main = xprint "hi" Yes, xprint is intensional, I want an error. I am in haskell mode in emacs. I type C-c C-l running haskell-process-load-file, and get: Hours of hacking await! If I break, you can: 1. Restart: M-x haskell-process-restart 2. Configure logging: C-h v haskell-process-log (useful for debugging) 3. General config: M-x customize-mode 4. Hide these tips: C-h v haskell-process-show-debug-tips .[;1m/home/henry/a.hs:2:8-13: .[;1m.[31merror:.[0m.[0m.[;1m.[0m.[0m.[;1m … • Variable not in scope: xprint :: [Char] -> t • Perhaps you meant ‘print’ (imported from Prelude).[0m.[0m .[;1m/home/henry/a.hs:2:8-13: .[;1m.[31merror:.[0m.[0m.[;1m.[0m.[0m.[;1m … • Variable not in scope: xprint :: [Char] -> t • Perhaps you meant ‘print’ (imported from Prelude).[0m.[0m Compilation failed. but when I swich to the *haskell* buffer and type :r, I get the beautiful, colorized message: [1 of 1] Compiling Main ( /home/henry/a.hs, interpreted ) /home/henry/a.hs:2:8-13: error: • Variable not in scope: xprint :: [Char] -> t • Perhaps you meant ‘print’ (imported from Prelude) | 2 | main = xprint "hi" | ^^^^^^ Failed, no modules loaded. Where the escape sequences have been interpreted correctly. What do I have misconfigured? Please point me in a direction. Thanks in advance. Best wishes, Henry Laxen -- Nadine and Henry Laxen The rest is silence Gral. Manuel Márquez de León 1301 Onix #2302 Zona Urban Rio Never try to teach a pig to sing; Tijuana It wastes your time +52 (333) 667-8633 And it annoys the pig

2 1

Re: [Haskell-cafe] [Haskell] [ANNOUNCE] GHC 9.2.4 released
by Kazu Yamamoto 28 Jul '22

28 Jul '22

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

1 0

[Haskell] [ANNOUNCE] GHC 9.2.4 released
by Zubin Duggal 28 Jul '22

28 Jul '22

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-s… [Deep Subsumption Proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0511-d…

1 0

Re: [Haskell-cafe] success on a slightly modified version of your suggestion for 21506
by Carter Schonwald 27 Jul '22

27 Jul '22

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 <george.colpitts(a)gmail.com> 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 <ben(a)well-typed.com> wrote: > >> George Colpitts <george.colpitts(a)gmail.com> writes: >> >> > +Kazu Yamamoto <kazu(a)iij.ad.jp> >> > >> > 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(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >

1 0

ANN: Copilot 3.10
by Ivan Perez 26 Jul '22

26 Jul '22

Dear all, We are very happy to announce the release of Copilot 3.10. Copilot is a runtime verification system implemented as a Haskell DSL that generates hard-realtime C99. You can learn more about it at [1]. This new version of Copilot contains a small but important change in how structs are handled in C functions invoked by the monitors when property violations are detected. This change is API-breaking, so users of Copilot may need to adapt their systems accordingly. The release also contains a number of bug fixes, provides a simplified API, deprecates outdated elements, removes unused code, and relaxes version constraints for dependencies. A full list of changes merged is available at [2]. A substantial effort is being made to achieve NASA's Class D software classification, most notably in terms of development process (which you can partly witness in how issues and PRs are being handled on our github repo), test coverage (mostly with quickcheck), and proofs of correctness of the generated code (with what4). Copilot is being used by the Safety-Critical Avionics Systems Branch (D320) of NASA Langley Research Center to conduct experiments related to flight safety of aerial vehicles. We have also built Ogma [3], a tool that allows us to generate full monitoring applications (e.g., NASA's Core Flight System [4] applications) from requirements in structured natural language. We'd like to take this opportunity to welcome Will Pogge to the team with his first commit, and thank the Galois team for their contributions. We also want to thank everyone who uses and helps promote Copilot; we are seeing increased attention, and gave three talks in the last two months at JPL, USC, and VCU, with two more taking place this month. We invite you all to explore Copilot, to try it, and to extend it. If you like it, please help us draw attention to this work with a star on github or a mention online. Happy Haskelling, The Copilot Team [1] https://github.com/Copilot-Language/copilot [2] https://github.com/Copilot-Language/copilot/milestone/14?closed=1 [3] https://github.com/nasa/ogma [4] https://cfs.gsfc.nasa.gov/

4 7

Munich Haskell Meeting, 2022-07-28 @ 19:30
by Leah Neukirchen 25 Jul '22

25 Jul '22

Dear all, This week, our monthly Munich Haskell Meeting will take place again on Thursday, July 28 at Hirschgarten (Biergarten, self-service area) at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html Please sign up here if you are coming so we'll look out for you. https://dudle.inf.tu-dresden.de/haskell-munich-jul-2022/ Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

Re: [Haskell-cafe] [ANNOUNCE] GHC 9.4.1-rc1 is now available
by Ben Gamari 24 Jul '22

24 Jul '22

George Colpitts <george.colpitts(a)gmail.com> writes: > +Kazu Yamamoto <kazu(a)iij.ad.jp> > > 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

1 0