- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] ghc doesn't work after installing 9.4.1 on my Mac
by Shayne Fletcher 09 Aug '22

09 Aug '22

Known issue George. See e.g. https://gitlab.haskell.org/ghc/ghc/-/issues/21985 On Tue, Aug 9, 2022, 4:33 PM George Colpitts <george.colpitts(a)gmail.com> wrote: > Unfortunately ghc doesn't work after installing 9.4.1 on my Mac. Does it > work for others? > > After the install finishes when I do the following: > > $ ghc --version > bash: /usr/local/bin/ghc: Permission denied > $ sudo chmod +x /usr/local/bin/ghc > $ghc --version > /usr/local/bin/ghc: line 1: exec: : not found > $ cat /usr/local/bin/ghc > exec "$executablename" -B"$libdir" ${1+"$@"} > $ cat /usr/local/bin/ghc-9.4.1 > #!/bin/sh > exedir="/usr/local/lib/ghc-9.4.1/bin" > exeprog="ghc-9.4.1" > executablename="/usr/local/lib/ghc-9.4.1/bin/ghc-9.4.1" > bindir="/usr/local/bin" > libdir="/usr/local/lib/ghc-9.4.1/lib" > docdir="/usr/local/share/doc/ghc-9.4.1" > includedir="/usr/local/include" > > exec "$executablename" -B"$libdir" ${1+"$@"} > > > Thanks > George > > > > On Sun, Aug 7, 2022 at 6:30 PM Ben Gamari <ben(a)well-typed.com> wrote: > >> The GHC developers are very pleased to announce the availability of GHC >> 9.4.1. Binary distributions, source distributions, and documentation are >> available at downloads.haskell.org: >> >> https://downloads.haskell.org/ghc/9.4.1 >> >> This release includes: >> >> - 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]. See >> the accompanying >> [blog post] for details on migrating packaging to Hadrian. >> >> We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, >> Well-Typed, 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 testing, >> >> - Ben >> >> >> [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/docs/users_guide/9.4.1-notes.html >> [blog post]: >> https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >

1 0

[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

Agda Implementors' Meeting XXXI - Edinburgh, 10-16 November 2022
by Orestis Melkonian 06 Aug '22

06 Aug '22

--------------------------------------------------------------- Agda Implementors' Meeting XXXI Call for participation http://wiki.portal.chalmers.se/agda/pmwiki.php?n=Main.AIMXXXI --------------------------------------------------------------- The 31st Agda Implementors' Meeting will take place in Edinburgh, Scotland from Thursday 10 November 2022 to Wednesday 16 November 2022. Note that AIMXXXI was initially planned for 2019 but got postponed due to COVID-19, whilst we had several online meetings XXXII-XXXV. The meeting will consist of: * Presentations concerning theory, implementation, and use cases of Agda and other Agda-like languages. * Discussions around issues related to the Agda language. * Plenty of time to work in, on, under or around Agda, in collaboration with other participants. * A full day dedicated to the EuroProofNet COST action, including talks and discussions on translating libraries and proofs between Agda and other proof assistants. Please direct enquiries about that to Jesper Cockx <Jesper(a)sikanda.be>. To register for AIM XXXI, please fill out the form below and send it to Orestis Melkonian by email <orestis.melkonian(a)ed.ac.uk>, or simply edit the AIMXXI wiki page yourself. > --------------------------------------------------------------- > Registration form for Agda Implementors' Meeting XXXI > > Name: > > Title and optionally abstract (if you want to give a talk or lead a discussion): > > Suggestions for code sprints (optional): > > Dietary restrictions: > > Additional comments: > > --------------------------------------------------------------- More information is available at http://wiki.portal.chalmers.se/agda/pmwiki.php?n=Main.AIMXXXI Please spread the word about this meeting. Best regards, Orestis

1 0

[ANN] plutus-simple-model-0.3 - minimal library to test Plutus/Cardano applications
by Anton Kholomiov 05 Aug '22

05 Aug '22

I’m happy to announce the release of a new version for plutus-simple-model <https://github.com/mlabs-haskell/plutus-simple-model>. It’s a minimal library to write test for Plutus/Cardano applications. It’s easy to use and blazing fast. We use it extensively in Mlabs City to test our Plutus applications. The new release is focused on those main features: - Reduce dependency set to make it as lean as possible. It depends only on plutus and cardano-ledger. - Support for Babbage era (use new features available in Vasil) - Support for Plutus V2 features (inlined datums, reference inputs, reference scripts, forward to redeemer, etc) - Write tutorial <https://mlabs-haskell.github.io/plutus-simple-model/> and update Hackage docs The main thing is Plutus V2 support. Also with cutdown on the list of dependencies it becomes much easier to update and use. I have removed big deps like plutus-apps, ouroboros and cardano-node. With this rewrite also it became 10 times faster. Links: github repo: https://github.com/mlabs-haskell/plutus-simple-model tutorial: https://mlabs-haskell.github.io/plutus-simple-model/ Cheers! Anton

1 0

Capturing typeclass dictionaries from constructors
by Clinton Mead 05 Aug '22

05 Aug '22

Hi All I've asked the following question on StackOverflow, but I thought here might be a good place for it also. Sorry for the crosspost but I'm never sure what the best place to ask Haskell questions is: https://stackoverflow.com/questions/73244177/capturing-typeclass-dictionari… I've copied the StackOverflow post below: --- Below is code that will happily compile (once adding the constraints package). Foo1 and Foo2 are two alternate definitions of Foo, which I can write f1 and f2 sensibly for. However, I *think* Foo3 is reasonable as well. Yet I don't know how to write f3. It seems to me that Haskell should store a pointer to the typeclass dictionary inside the Foo3 constructor, for whatever a is passed when Foo3 is created, so then I should be able to just call silly. Since silly just returns String, it doesn't matter if a has been erased by now, I should be able to happily call the silly pointed to by the dictionary stored in the constructor Foo3. Is my reasoning right? And if so, how can I write f3. Alternative, have I missed something and is there a good reason why I need either Dict or Proxy here because without them I haven't got enough information? {-# LANGUAGE ScopedTypeVariables #-} import Data.Constraint (Dict(Dict), withDict)import Data.Proxy (Proxy) data Aliceclass C a where silly :: Stringinstance C Alice where silly = "Silly Alice" data Foo1 where Foo1 :: Dict (C a) -> Foo1 f1 :: Foo1 -> Stringf1 (Foo1 (dict :: Dict (C a))) = withDict dict $ silly @a data Foo2 where Foo2 :: C a => Proxy a -> Foo2 f2 :: Foo2 -> Stringf2 (Foo2 (_ :: Proxy a)) = silly @a data Foo3 where Foo3 :: C a => Foo3 mkFoo3 :: forall a. C a => Foo3mkFoo3 = Foo3 @a f3 :: Foo3 -> Stringf3 = undefined

2 1

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 29 Jul '22

29 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