From ryan.gl.scott at gmail.com Wed Aug 2 13:43:08 2023 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Wed, 2 Aug 2023 09:43:08 -0400 Subject: [Haskell-cafe] Call for Lightning Talks: Haskell Implementors' Workshop 2023 Message-ID: ACM SIGPLAN Haskell Implementors' Workshop https://icfp23.sigplan.org/home/hiw-2023 Seattle, Washington, United States, September 4, 2023 Co-located with ICFP 2023 https://icfp23.sigplan.org/ --------------- The 15th Haskell Implementors' Workshop is to be held alongside ICFP 2023 this year in Seattle. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure to share their work and to discuss future directions and collaborations with others. We have a number of slots for lightning talks. Lightning talks will be ~7 minutes and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Lightning talks are proposed by submitting a title and an abstract. Submissions will not be part of the peer-review process. Notification of acceptance will be continuous until slots are full. Accepted lightning talks will be posted on the workshop’s website. Submissions should be made via this Google form: https://forms.gle/2jGceompwNghbRQR9 Accepted lightning talks will be posted on the workshop’s website. Scope and target audience ------------------------- The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community are encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are especially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Contact ------- * Ryan Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From icfp.publicity at googlemail.com Thu Aug 3 06:26:03 2023 From: icfp.publicity at googlemail.com (ICFP Publicity) Date: Thu, 3 Aug 2023 14:26:03 +0800 Subject: [Haskell-cafe] ICFP 2023: Call for Participation Message-ID: ===================================================================== Call for Participation The 28th ACM SIGPLAN International Conference on Functional Programming (ICFP 2023) and affiliated events https://icfp23.sigplan.org Seattle, USA; Sep 4-9, 2023 ===================================================================== ICFP is a celebration of the art and science of functional programming, providing a forum for researchers and developers to engage on a variety of topics, from foundations to features, and from abstraction to application. You are invited to participate in a full week dedicated to functional programming, featuring the ICFP main conference as well as several other related events. * Accepted Papers: https://icfp23.sigplan.org/track/icfp-2023-papers#event-overview * Registration: https://icfp23.sigplan.org/attending/registration The early-bird deadline is August 5, 2023 * Hotel: The Westin Seattle https://icfp23.sigplan.org/venue/icfp-2023-venue Conference hotel reservation cutoff: August 11, 2023 There are several events affiliated with ICFP: September 4 Erlang - https://icfp23.sigplan.org/home/erlang-2023 FHPN - https://icfp23.sigplan.org/home/FHPNC-2023 HIW - https://icfp23.sigplan.org/home/hiw-2023 HOPE - https://icfp23.sigplan.org/home/hope-2023 PLMW - https://icfp23.sigplan.org/track/plmw-icfp-2023 TyDe - https://icfp23.sigplan.org/home/TyDe-2023 September 5-7 ICFP - Main conference September 8 Haskell - https://icfp23.sigplan.org/home/haskellsymp-2023 FARM - https://icfp23.sigplan.org/home/farm-2023 FUNARCH - https://icfp23.sigplan.org/home/FUNARCH-2023 ML - https://icfp23.sigplan.org/home/mlworkshop-2023 miniKanren - https://icfp23.sigplan.org/home/minikanren-2023 Tutorial: Vehicle, A Specification Language for Neural Network Properties Tutorial: Porting Lwt applications to OCaml 5 and Eio September 9 Haskell - https://icfp23.sigplan.org/home/haskellsymp-2023 Scheme - https://icfp23.sigplan.org/home/scheme-2023 OCaml - https://icfp23.sigplan.org/home/ocaml-2023 DeclMed - https://icfp23.sigplan.org/home/declmed-2023 Tutorial: Teaching and Learning Compilers Incrementally Tutorial: Teaching functional programming Conference organizers: https://icfp23.sigplan.org/committee/icfp-2023-organizing-committee ===================================================================== From ben at smart-cactus.org Thu Aug 3 14:10:27 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 03 Aug 2023 10:10:27 -0400 Subject: [Haskell-cafe] Haskell GitLab abuse In-Reply-To: References: Message-ID: <87wmycnrn3.fsf@smart-cactus.org> Bryan Richter via Haskell-Cafe writes: > Yeah, unfortunately we are aware of various attempts to abuse the GHC > GitLab instance. I will delete this particular user, and sometime in the > near future I'll take steps to systematically clean out any other lurking > spam. > I have dealt with this particular pocket of spam; thankfully it was just many projects from a few users. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 515 bytes Desc: not available URL: From anton.kholomiov at gmail.com Sun Aug 6 15:28:22 2023 From: anton.kholomiov at gmail.com (Anton Kholomiov) Date: Sun, 6 Aug 2023 18:28:22 +0300 Subject: [Haskell-cafe] [ANNOUNCE] mig - new library to write composable web-servers Message-ID: I'm happy to announce the release of a new library for web-servers. It offers simple and concise functions to build servers from small parts. Servers are monoids, and we can aggregate them with functions like `mconcat`. Main features: * lightweight library * expressive DSL to compose servers * type-safe handlers * handlers are encoded with generic haskell functions * built on top of WAI and warp server libraries. For DSL design I wanted to touch the middle ground between scotty (being small and simple, but imperative) and servant (being composable, but somewhat advanced on type-level features) I like scotty for being very simple and servant for being composable, type-safe and how functions are used as handlers which provides decoupling of Web-handlers from application logic. But sometimes scotty feels too imperative and lacks a servant's composability. And servant with type-level magic and huge errors can feel too complicated. So I wanted to create something in the middle. Something composable and simple at the same time. And be able to use arbitrary haskell functions as handlers. There are only two functions to combine servers. And types of inputs and outputs are encoded with newtype-wrpappers with phantom types which provide type-safety. It's very first release. So feedback is welcome and I'm sure there are places to improve. I hope that you will enjoy the lib. links: * [github](https://github.com/anton-k/mig) * [hackage](https://hackage.haskell.org/package/mig-0.1.0.1) * [examples]( https://github.com/anton-k/mig/tree/main/examples/mig-example-apps) * [example of a handle pattern app]( https://github.com/anton-k/handle-pattern-mig-app) * [example of a reader pattern app]( https://github.com/anton-k/reader-pattern-mig-app) Cheers, Anton -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Aug 7 15:57:43 2023 From: ben at well-typed.com (Ben Gamari) Date: Mon, 07 Aug 2023 11:57:43 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.6 is now available Message-ID: <87edke7slk.fsf@smart-cactus.org> The GHC developers are happy to announce the availability of GHC 9.4.6. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.4.6 This release is primarily a bugfix release addressing some issues found in 9.4.6. These include: * Many bug fixes for the simplifier, preventing compiler panics, loops and incorrect code generation (#22761, #22549, #23208, #22761, #22272, #23146, #23012, #22547). * Bug fixes for the typechecker involving newtype family instances, making type equalities more robust and bugs having to do with defaulting representation polymorphic type variables (#23329, #23333, #23143, #23154, #23176). * Some bug fixes for code generation, particularly on the aarch64 backend, including adding more memory barriers for array read operations (#23541, #23749). * Some bug fixes for windows builds, ensuring the reliablility of IO manager shutdown and a bug fix for the RTS linker on windows (#23691, #22941). * A bug fix for the non-moving GC ensuring mutator allocations are properly accounted for (#23312). * A bug fix preventing some segfaults by ensuring that pinned allocations respect block size (#23400). * Many bug fixes for the bytecode interpreter, allowing a greater subset of the language to be interpreted (#22376, #22840, #22051, #21945, #23068, #22958). * ... and a few 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, 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 compiling, - Zubin & Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.4.6/docs/users_guide/9.4.6-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 ivanperezdominguez at gmail.com Tue Aug 8 06:14:07 2023 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Mon, 7 Aug 2023 23:14:07 -0700 Subject: [Haskell-cafe] [ANN] Yampa 0.14.4 Message-ID: Hi everyone, I'm very happy to announce the release of Yampa 0.14.4 and yampa-test 0.14.4. Yampa is a fast, elegant Functional Reactive Programming implementation. Yampa prides itself in being a long-standing community project. It has now been around for 20 years!!! See https://github.com/ivanperez-keera/yampa#features for details on Yampa's features. This release introduces a benchmark that can be used to evaluate the performance of a proposed change to Yampa, as well as to compare different ways of writing the same expressions. We hope that the benchmarks will improve and grow over time, and that they will help speed up the process of evaluating pull requests submitted to the project. Performance can be tricky to evaluate precisely, so no eyes are too many. We invite everyone to go to the Github repo and discuss ways to make the benchmarks more reliable, representative, and useful. This release also introduces version bounds for dependencies that did not have them, which will make Yampa easier to install. The current release has been tested with all major GHC versions from 7.6 to 9.6. Special thanks go to @johannes-riecken for a regular contribution to support the Yampa project. For details, see: - https://github.com/ivanperez-keera/Yampa/releases/tag/v0.14.4 The Yampa ecosystem comprises many projects. You can explore the current versions at: - https://hackage.haskell.org/package/Yampa - https://hackage.haskell.org/package/yampa-test - https://hackage.haskell.org/package/yampa-gloss - https://hackage.haskell.org/package/simple-affine-space - https://hackage.haskell.org/package/SpaceInvaders - https://hackage.haskell.org/package/haskanoid # Code The github repos are located at: - https://github.com/ivanperez-keera/Yampa/ - https://github.com/ivanperez-keera/yampa-gloss/ - https://github.com/ivanperez-keera/simple-affine-space/ - https://github.com/ivanperez-keera/SpaceInvaders/ - https://github.com/ivanperez-keera/haskanoid/ # What's coming This release comes exactly 2 months after the last release. The next release is planned for Oct 7, 2023. There are several issues open that you can contribute to. Following our roadmap, we plan to: - Create demos and examples using GHC's web backends. - Remove unnecessarily exposed elements from the interface (e.g., FRP.Yampa.Arrow.arr3) that are not used and belong in other libraries. This topic is open to discussion. - Switch from the old mailing list to a new discussion method. We will in the future lose access to Yale's CS department-based mailman list, and are thinking of the best place to move to. For now, the Discussions tab on Github has been enabled. # Other news I'm also happy to report that the paper "The Beauty and Elegance of Functional Reactive Animation" has been accepted for presentation at FARM 2023. The paper discusses different animations that can easily be created using Yampa. I invite you all to download the paper once it's published, and to stop by FARM 2023 if you are at ICFP next month! # Donations Our project is seeking donations to help continue developing Yampa, create new open source libraries, new material, and give talks. No donation is too small. Any contribution will absolutely help. See https://github.com/sponsors/ivanperez-keera for details. If you can help, please come forward. All the best, Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Achten at cs.ru.nl Tue Aug 8 08:57:43 2023 From: P.Achten at cs.ru.nl (Peter Achten) Date: Tue, 8 Aug 2023 10:57:43 +0200 Subject: [Haskell-cafe] [Call for submissions TFPiE 2024] Trends in Functional Programming in Education - January 9 2024, Seton Hall University, USA Message-ID: <52f3f359-ae4b-06cb-d383-db1ecb4b2dfc@cs.ru.nl> TFPIE 2024 Call for papers https://wiki.tfpie.science.ru.nl/TFPIE2024 (January 9th 2024, West Orange, NJ, USA, co-located with TFP 2024 at Seton Hall University) TFPIE 2024 welcomes submissions describing techniques used in the classroom, tools used in and/or developed for the classroom and any creative use of functional programming (FP) to aid education in or outside Computer Science. Topics of interest include, but are not limited to:   FP and beginning CS students   FP and Computational Thinking   FP and Artificial Intelligence   FP in Robotics   FP and Music   Advanced FP for undergraduates   FP in graduate education   Engaging students in research using FP   FP in Programming Languages   FP in the high school curriculum   FP as a stepping stone to other CS topics   FP and Philosophy   The pedagogy of teaching FP   FP and e-learning: MOOCs, automated assessment etc.   Best Lectures - more details below In addition to papers, we are requesting best lecture presentations. What's your best lecture topic in an FP related course? Do you have a fun way to present FP concepts to novices or perhaps an especially interesting presentation of a difficult topic? In either case, please consider sharing it. Best lecture topics will be selected for presentation based on a short abstract describing the lecture and its interest to TFPIE attendees. The length of the presentation should be comparable to that of a paper. In addition, the speaker can provide commentary on effectiveness or student feedback. Submissions Potential presenters are invited to submit an extended abstract (4-6 pages) or a draft paper (up to 20 pages) in EPTCS style. The authors of accepted presentations will have their preprints and their slides made available on the workshop's website. Papers and abstracts can be submitted via easychair at the following link: https://easychair.org/conferences/?conf=tfpie2024 After the workshop, presenters are invited to submit (a revised version of) their article for the formal review. The PC will select the best articles for publication in the Electronic Proceedings in Theoretical Computer Science (EPTCS). Articles rejected for presentation and extended abstracts will not be formally reviewed by the PC. Important Dates Submission deadline: December 26th 2023, Anywhere on Earth Notification: by December 30th 2023 (Note: submissions will be evaluated on a rolling basis, so earlier submissions will receive an earlier response) TFPIE Registration Deadline: TBA Workshop: January 9th 2024 Submission for formal review: April 19th 2024, Anywhere on Earth. Notification of full article: May 24th 2024 Camera ready: June 28th 2024 Program Committee - TBD         Stephen Chang (Chair) - UMass Boston, USA Registration information See https://wiki.tfpie.science.ru.nl/TFPIE2024 for updated information. Registration and attendance are mandatory for at least one author of every paper that is presented at the workshop. Presenters will have their registration fee waived. Only papers that have been presented at TFPIE may be submitted to the post-reviewing process. From carter.schonwald at gmail.com Wed Aug 9 17:16:50 2023 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 9 Aug 2023 13:16:50 -0400 Subject: [Haskell-cafe] [ANNOUNCE] mig - new library to write composable web-servers In-Reply-To: References: Message-ID: as i said on reddit, this is super cool and hits a design combination i've long wanted to see (and never had the time myself to explore doing) On Sun, Aug 6, 2023 at 11:28 AM Anton Kholomiov wrote: > > I'm happy to announce the release of a new library for web-servers. > It offers simple and concise functions to build servers from small parts. > Servers are monoids, and we can aggregate them with functions like `mconcat`. > > Main features: > > * lightweight library > * expressive DSL to compose servers > * type-safe handlers > * handlers are encoded with generic haskell functions > * built on top of WAI and warp server libraries. > > For DSL design I wanted to touch the middle ground between scotty (being small and simple, but imperative) and servant (being composable, but somewhat advanced on type-level features) > > I like scotty for being very simple and servant for being composable, type-safe and how functions are used as handlers which provides decoupling of Web-handlers from application logic. But sometimes scotty feels too imperative and lacks a servant's composability. And servant with type-level magic and huge errors can feel too complicated. So I wanted to create something in the middle. Something composable and simple at the same time. And be able to use arbitrary haskell functions as handlers. > > There are only two functions to combine servers. And types of inputs and outputs are encoded with newtype-wrpappers with phantom types which provide type-safety. > > It's very first release. So feedback is welcome and I'm sure there are places to improve. > I hope that you will enjoy the lib. > > links: > * [github](https://github.com/anton-k/mig) > * [hackage](https://hackage.haskell.org/package/mig-0.1.0.1) > * [examples](https://github.com/anton-k/mig/tree/main/examples/mig-example-apps) > * [example of a handle pattern app](https://github.com/anton-k/handle-pattern-mig-app) > * [example of a reader pattern app](https://github.com/anton-k/reader-pattern-mig-app) > > Cheers, > Anton > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From ben at well-typed.com Thu Aug 10 15:08:14 2023 From: ben at well-typed.com (Ben Gamari) Date: Thu, 10 Aug 2023 11:08:14 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha2 is now available Message-ID: <87jzu35415.fsf@smart-cactus.org> The GHC developers are very pleased to announce the availability of the second alpha prerelease of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.8.1-alpha2 GHC 9.8 will bring a number of new features and improvements, including: * Preliminary support the `TypeApplications` language extension [type-binders], allowing types to be bound in type declarations. * Support for the `ExtendedLiterals` extension, providing syntax for non-word-sized numeric literals in the surface language [extended-literals] * Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns * Better support for user-defined warnings by way of the `WARNING` pragma [warnings] * The introduction of the new `GHC.TypeError.Unsatisfiable` constraint, allowing more predictable user-defined type errors [unsatisfiable] * Implementation of the export deprecation proposal, allowing module exports to be marked with `DEPRECATE` pragmas [deprecated-exports] * The addition of build semaphore support for parallel compilation; with coming support in `cabal-install` this will allow better use of parallelism in multi-package builds [jsem] * More efficient representation of info table provenance information, reducing binary sizes by over 50% in some cases when `-finfo-table-map` is in use A full accounting of changes can be found in the [release notes]. This alpha includes around two dozen bug-fixes relative to alpha 1. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, 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 compiling, ~ Ben [type-binders]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst [extended-literals]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst [unsatisfiable]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst [warnings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst [deprecated-exports]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst [jsem]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst [release notes]: https://downloads.haskell.org/ghc/9.8.1-alpha2/docs/users_guide/9.8.1-notes.html [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From vamchale at gmail.com Sun Aug 13 01:49:20 2023 From: vamchale at gmail.com (Vanessa McHale) Date: Sat, 12 Aug 2023 21:49:20 -0400 Subject: [Haskell-cafe] [ANN] avif - libavif bindings on Hackage Message-ID: <433F0590-BF71-4BC0-8E10-2853D23BF77F@gmail.com> Hello all, I have release avif, a Haskell wrapper around libavif compatible with JuicyPixels. https://hackage.haskell.org/package/avif Cheers, Vanessa McHale -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: favicon.png Type: image/png Size: 2792 bytes Desc: not available URL: From coot at coot.me Sun Aug 20 21:01:38 2023 From: coot at coot.me (coot at coot.me) Date: Sun, 20 Aug 2023 21:01:38 +0000 Subject: [Haskell-cafe] IOSim on Hackage Message-ID: Hello dear Haskell-Cafe, I realised that I haven't shared here that we (the networking team of IOG) released io-sim on Hackage. We found and fixed countless bugs thanks to it, including some concurrent ones. Here's a blog post which I wrote some time ago: https://engineering.iog.io/2023-04-14-io-sim-annoucement https://hackage.haskell.org/package/io-sim https://hackage.haskell.org/package/io-classes Cheers, Marcin Szamotulski -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 509 bytes Desc: OpenPGP digital signature URL: From palotai.robin at gmail.com Mon Aug 21 13:30:07 2023 From: palotai.robin at gmail.com (Robin Palotai) Date: Mon, 21 Aug 2023 15:30:07 +0200 Subject: [Haskell-cafe] IOSim on Hackage In-Reply-To: References: Message-ID: Nice! Always good to see more production tooling to emerge. A question, not that it is your responsibility to consider, but in case you have thoughts, would be keen to hear: Are there any long term integrative plan on bringing the various Io/exception/concurrency abstractions on a compatible basis? Currently there's for example unliftio/Rio, which is already not compatible with dejafu. Dejafu is class based, but might not play well with these io-classes. Also, the emulated semantics might differ. Etc. To a player who wants "just" some robust working ecosystem, all these choices and turbulence is quite hard to navigate or make choices about. And input about observed pros/cons and long term plans appreciated. Thank you, Robin On Sun, Aug 20, 2023, 23:02 wrote: > Hello dear Haskell-Cafe, > > I realised that I haven't shared here that we (the networking team of IOG) > released io-sim on Hackage. We found and fixed countless bugs thanks to it, > including some concurrent ones. Here's a blog post which I wrote some time > ago: > https://engineering.iog.io/2023-04-14-io-sim-annoucement > > https://hackage.haskell.org/package/io-sim > https://hackage.haskell.org/package/io-classes > > Cheers, > Marcin Szamotulski > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Tue Aug 22 12:29:48 2023 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Tue, 22 Aug 2023 14:29:48 +0200 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha2 is now available In-Reply-To: <87jzu35415.fsf@smart-cactus.org> References: <87jzu35415.fsf@smart-cactus.org> Message-ID: Thanks Ben. For the sake of the future announcements, the first item should have s/TypeApplications/TypeApplications/ On Thu, 10 Aug 2023 at 17:09, Ben Gamari wrote: > > The GHC developers are very pleased to announce the availability of the > second alpha prerelease of GHC 9.8.1. Binary distributions, source > distributions, and documentation are available at > > https://downloads.haskell.org/ghc/9.8.1-alpha2 > > GHC 9.8 will bring a number of new features and improvements, including: > > * Preliminary support the `TypeApplications` language extension > [type-binders], > allowing types to be bound in type declarations. > > * Support for the `ExtendedLiterals` extension, providing syntax for > non-word-sized numeric literals in the surface language > [extended-literals] > > * Improved rewrite rule matching behavior, allowing limited matching of > higher-order patterns > > * Better support for user-defined warnings by way of the `WARNING` pragma > [warnings] > > * The introduction of the new `GHC.TypeError.Unsatisfiable` > constraint, allowing more predictable user-defined type errors > [unsatisfiable] > > * Implementation of the export deprecation proposal, allowing module > exports to be marked with `DEPRECATE` pragmas [deprecated-exports] > > * The addition of build semaphore support for parallel compilation; > with coming support in `cabal-install` this will allow better use of > parallelism in multi-package builds [jsem] > > * More efficient representation of info table provenance information, > reducing binary sizes by over 50% in some cases when > `-finfo-table-map` is in use > > A full accounting of changes can be found in the [release notes]. > This alpha includes around two dozen bug-fixes relative to alpha 1. > > We would like to thank GitHub, IOG, the Zw3rk stake pool, > Well-Typed, 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 compiling, > > ~ Ben > > > [type-binders]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst > [extended-literals > ]: > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst > [unsatisfiable]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst > [warnings]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst > [deprecated-exports > ]: > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst > [jsem]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst > [release notes]: > https://downloads.haskell.org/ghc/9.8.1-alpha2/docs/users_guide/9.8.1-notes.html > [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From noonsilk at gmail.com Tue Aug 22 12:36:21 2023 From: noonsilk at gmail.com (Noon van der Silk) Date: Tue, 22 Aug 2023 13:36:21 +0100 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha2 is now available In-Reply-To: References: <87jzu35415.fsf@smart-cactus.org> Message-ID: Hey Arnaud, > For the sake of the future announcements, the first item should have s/TypeApplications/TypeApplications/ I assume you mean "TypeApplications" instead of "TypeApplications", right? :D -- Noon On Tue, 22 Aug 2023 at 13:30, Arnaud Spiwack wrote: > Thanks Ben. > > For the sake of the future announcements, the first item should have > s/TypeApplications/TypeApplications/ > > > On Thu, 10 Aug 2023 at 17:09, Ben Gamari wrote: > >> >> The GHC developers are very pleased to announce the availability of the >> second alpha prerelease of GHC 9.8.1. Binary distributions, source >> distributions, and documentation are available at >> >> https://downloads.haskell.org/ghc/9.8.1-alpha2 >> >> GHC 9.8 will bring a number of new features and improvements, including: >> >> * Preliminary support the `TypeApplications` language extension >> [type-binders], >> allowing types to be bound in type declarations. >> >> * Support for the `ExtendedLiterals` extension, providing syntax for >> non-word-sized numeric literals in the surface language >> [extended-literals] >> >> * Improved rewrite rule matching behavior, allowing limited matching of >> higher-order patterns >> >> * Better support for user-defined warnings by way of the `WARNING` >> pragma [warnings] >> >> * The introduction of the new `GHC.TypeError.Unsatisfiable` >> constraint, allowing more predictable user-defined type errors >> [unsatisfiable] >> >> * Implementation of the export deprecation proposal, allowing module >> exports to be marked with `DEPRECATE` pragmas [deprecated-exports] >> >> * The addition of build semaphore support for parallel compilation; >> with coming support in `cabal-install` this will allow better use of >> parallelism in multi-package builds [jsem] >> >> * More efficient representation of info table provenance information, >> reducing binary sizes by over 50% in some cases when >> `-finfo-table-map` is in use >> >> A full accounting of changes can be found in the [release notes]. >> This alpha includes around two dozen bug-fixes relative to alpha 1. >> >> We would like to thank GitHub, IOG, the Zw3rk stake pool, >> Well-Typed, 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 compiling, >> >> ~ Ben >> >> >> [type-binders]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst >> [extended-literals >> ]: >> >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst >> [unsatisfiable]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst >> [warnings]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst >> [deprecated-exports >> ]: >> >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst >> [jsem]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst >> [release notes]: >> https://downloads.haskell.org/ghc/9.8.1-alpha2/docs/users_guide/9.8.1-notes.html >> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > > -- > Arnaud Spiwack > Director, Research at https://moduscreate.com and https://tweag.io. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Noon van der Silk, ن http://silky.github.io/ "My programming language is kindness." -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Tue Aug 22 16:32:35 2023 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Tue, 22 Aug 2023 18:32:35 +0200 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha2 is now available In-Reply-To: References: <87jzu35415.fsf@smart-cactus.org> Message-ID: 😱 Thanks Sam and Noon! I'm obviously great at copy-pasting. On Tue, 22 Aug 2023 at 14:36, Noon van der Silk wrote: > Hey Arnaud, > > > For the sake of the future announcements, the first item should have > s/TypeApplications/TypeApplications/ > > I assume you mean "TypeApplications" instead of "TypeApplications", right? > > :D > > -- > Noon > > > On Tue, 22 Aug 2023 at 13:30, Arnaud Spiwack > wrote: > >> Thanks Ben. >> >> For the sake of the future announcements, the first item should have >> s/TypeApplications/TypeApplications/ >> >> >> On Thu, 10 Aug 2023 at 17:09, Ben Gamari wrote: >> >>> >>> The GHC developers are very pleased to announce the availability of the >>> second alpha prerelease of GHC 9.8.1. Binary distributions, source >>> distributions, and documentation are available at >>> >>> https://downloads.haskell.org/ghc/9.8.1-alpha2 >>> >>> GHC 9.8 will bring a number of new features and improvements, including: >>> >>> * Preliminary support the `TypeApplications` language extension >>> [type-binders], >>> allowing types to be bound in type declarations. >>> >>> * Support for the `ExtendedLiterals` extension, providing syntax for >>> non-word-sized numeric literals in the surface language >>> [extended-literals] >>> >>> * Improved rewrite rule matching behavior, allowing limited matching of >>> higher-order patterns >>> >>> * Better support for user-defined warnings by way of the `WARNING` >>> pragma [warnings] >>> >>> * The introduction of the new `GHC.TypeError.Unsatisfiable` >>> constraint, allowing more predictable user-defined type errors >>> [unsatisfiable] >>> >>> * Implementation of the export deprecation proposal, allowing module >>> exports to be marked with `DEPRECATE` pragmas [deprecated-exports] >>> >>> * The addition of build semaphore support for parallel compilation; >>> with coming support in `cabal-install` this will allow better use of >>> parallelism in multi-package builds [jsem] >>> >>> * More efficient representation of info table provenance information, >>> reducing binary sizes by over 50% in some cases when >>> `-finfo-table-map` is in use >>> >>> A full accounting of changes can be found in the [release notes]. >>> This alpha includes around two dozen bug-fixes relative to alpha 1. >>> >>> We would like to thank GitHub, IOG, the Zw3rk stake pool, >>> Well-Typed, 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 compiling, >>> >>> ~ Ben >>> >>> >>> [type-binders]: >>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst >>> [extended-literals >>> ]: >>> >>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst >>> [unsatisfiable]: >>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst >>> [warnings]: >>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst >>> [deprecated-exports >>> ]: >>> >>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst >>> [jsem]: >>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst >>> [release notes]: >>> https://downloads.haskell.org/ghc/9.8.1-alpha2/docs/users_guide/9.8.1-notes.html >>> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >> >> >> >> -- >> Arnaud Spiwack >> Director, Research at https://moduscreate.com and https://tweag.io. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > > -- > Noon van der Silk, ن > > http://silky.github.io/ > > "My programming language is kindness." > -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Wed Aug 23 10:50:10 2023 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 23 Aug 2023 11:50:10 +0100 Subject: [Haskell-cafe] Can I get 'forall (a :: k). Typeable a => Dict (Typeable k)'? Message-ID: Morally I think that class Typeable (a :: k) should have been class Typeable k => Typeable (a :: k) If I'm wrong, could someone please elaborate why? If I'm right, please read on ... That would be a breaking change, but could we at least get kindable :: forall (a :: k). Typeable a => Dict (Typable (a :: k)) in the meantime? Tom From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Wed Aug 23 10:54:00 2023 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 23 Aug 2023 11:54:00 +0100 Subject: [Haskell-cafe] Can I get 'forall (a :: k). Typeable a => Dict (Typeable k)'? In-Reply-To: References: Message-ID: On rereading maybe my question is a big ambiguous. What I'm really asking is "do people support the addition of (and see the value of) a function of the following type?" forall (a :: k). Typeable a => Dict (Typable (a :: k)) It might require changes to GHC, I'm not sure. I suppose the new/proposed ghc-experimental package would be a good place for it to start its life. Tom On Wed, Aug 23, 2023 at 11:50:10AM +0100, Tom Ellis wrote: > Morally I think that > > class Typeable (a :: k) > > should have been > > class Typeable k => Typeable (a :: k) > > If I'm wrong, could someone please elaborate why? If I'm right, > please read on ... > > That would be a breaking change, but could we at least get > > kindable :: forall (a :: k). Typeable a => Dict (Typable (a :: k)) > > in the meantime? From oleg.grenrus at iki.fi Wed Aug 23 10:58:16 2023 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Wed, 23 Aug 2023 13:58:16 +0300 Subject: [Haskell-cafe] Can I get 'forall (a :: k). Typeable a => Dict (Typeable k)'? In-Reply-To: References: Message-ID: <416b7f73-ebc6-92ab-0c3f-056019cd3227@iki.fi> What you mean "could we get", add to base or be able to define? I think you can:     {-# LANGUAGE GADTs, RankNTypes, KindSignatures, PolyKinds, ConstraintKinds #-}     import Data.Kind     import Type.Reflection     data Dict (c :: Constraint) where       Dict :: c => Dict c     kindable :: forall {k} (a :: k). Typeable a => Dict (Typeable (a :: k))     kindable = Dict works? Or am I missing something? Also isn't TypeRep a from Type.Reflection the same as Dict (Typeable a) for all practical purposes, `kindable = Type.Reflection.typeRep`, yet better?     kindable' :: forall {k} (a :: k). Typeable a => TypeRep a     kindable' = typeRep - Oleg On 23.8.2023 13.50, Tom Ellis wrote: > Morally I think that > > class Typeable (a :: k) > > should have been > > class Typeable k => Typeable (a :: k) > > If I'm wrong, could someone please elaborate why? If I'm right, > please read on ... > > That would be a breaking change, but could we at least get > > kindable :: forall (a :: k). Typeable a => Dict (Typable (a :: k)) > > in the meantime? > > Tom > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From oleg.grenrus at iki.fi Wed Aug 23 10:59:12 2023 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Wed, 23 Aug 2023 13:59:12 +0300 Subject: [Haskell-cafe] Can I get 'forall (a :: k). Typeable a => Dict (Typeable k)'? In-Reply-To: References: Message-ID: <1175b291-d295-3bd6-5977-a1bae59ea738@iki.fi> As I answered in my other mail: no. There is Type.Reflection.typeRep, which does that. Also Dict is not in base, you'd first need to add that there. - Oleg On 23.8.2023 13.54, Tom Ellis wrote: > On rereading maybe my question is a big ambiguous. What I'm really > asking is "do people support the addition of (and see the value of) a > function of the following type?" > > forall (a :: k). Typeable a => Dict (Typable (a :: k)) > > It might require changes to GHC, I'm not sure. I suppose the > new/proposed ghc-experimental package would be a good place for it to > start its life. > > Tom > > On Wed, Aug 23, 2023 at 11:50:10AM +0100, Tom Ellis wrote: >> Morally I think that >> >> class Typeable (a :: k) >> >> should have been >> >> class Typeable k => Typeable (a :: k) >> >> If I'm wrong, could someone please elaborate why? If I'm right, >> please read on ... >> >> That would be a breaking change, but could we at least get >> >> kindable :: forall (a :: k). Typeable a => Dict (Typable (a :: k)) >> >> in the meantime? > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From adam at well-typed.com Wed Aug 23 11:10:24 2023 From: adam at well-typed.com (Adam Gundry) Date: Wed, 23 Aug 2023 12:10:24 +0100 Subject: [Haskell-cafe] Can I get 'forall (a :: k). Typeable a => Dict (Typeable k)'? In-Reply-To: References: Message-ID: <599fcd1e-8e49-aa41-eaa4-026e84f73a11@well-typed.com> Hi Tom, I think you are looking for Type.Reflection.typeRepKind typeRepKind :: TypeRep (a :: k) -> TypeRep k which combined with typeRep :: Typeable a => TypeRep a withTypeable :: forall k (a :: k) rep (r :: TYPE rep). TypeRep a -> (Typeable a => r) -> r should allow you to define kindable :: forall (a :: k). Typeable a => Dict (Typeable k) as your subject line asked for, albeit not the message body. :-) Cheers, Adam On 23/08/2023 11:50, Tom Ellis wrote: > Morally I think that > > class Typeable (a :: k) > > should have been > > class Typeable k => Typeable (a :: k) > > If I'm wrong, could someone please elaborate why? If I'm right, > please read on ... > > That would be a breaking change, but could we at least get > > kindable :: forall (a :: k). Typeable a => Dict (Typable (a :: k)) > > in the meantime? > > Tom -- 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 tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Wed Aug 23 11:11:23 2023 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 23 Aug 2023 12:11:23 +0100 Subject: [Haskell-cafe] Can I get 'forall (a :: k). Typeable a => Dict (Typeable k)'? In-Reply-To: <416b7f73-ebc6-92ab-0c3f-056019cd3227@iki.fi> References: <416b7f73-ebc6-92ab-0c3f-056019cd3227@iki.fi> Message-ID: No, sorry, it's me who's missing something. The subject line of my email is correct, but the content was not. What I wanted was a way of writing forall (a :: k). Typeable a => Dict (Typeable k) or, if you like forall (a :: k). Typeable a => TypeRep k Given your suggestion I searched for usages of TypeRep in the documentation and found that (something equivalent to) it already exists: typeRepKind :: TypeRep (a :: k) -> TypeRep k https://www.stackage.org/haddock/lts-21.8/base-4.17.2.0/Type-Reflection.html#v:typeRepKind So problem solved. Thanks! Tom On Wed, Aug 23, 2023 at 01:58:16PM +0300, Oleg Grenrus wrote: > I missing something? > > On 23.8.2023 13.50, Tom Ellis wrote: > > Morally I think that > > > > class Typeable (a :: k) > > > > should have been > > > > class Typeable k => Typeable (a :: k) > > > > If I'm wrong, could someone please elaborate why? If I'm right, > > please read on ... > > > > That would be a breaking change, but could we at least get > > > > kindable :: forall (a :: k). Typeable a => Dict (Typable (a :: k)) > > > > in the meantime? From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Wed Aug 23 11:11:54 2023 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 23 Aug 2023 12:11:54 +0100 Subject: [Haskell-cafe] Can I get 'forall (a :: k). Typeable a => Dict (Typeable k)'? In-Reply-To: <599fcd1e-8e49-aa41-eaa4-026e84f73a11@well-typed.com> References: <599fcd1e-8e49-aa41-eaa4-026e84f73a11@well-typed.com> Message-ID: On Wed, Aug 23, 2023 at 12:10:24PM +0100, Adam Gundry wrote: > I think you are looking for Type.Reflection.typeRepKind > > typeRepKind :: TypeRep (a :: k) -> TypeRep k [...] > as your subject line asked for, albeit not the message body. :-) Yes, exactly, thank you! Tom From ryan.gl.scott at gmail.com Wed Aug 23 13:35:59 2023 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Wed, 23 Aug 2023 09:35:59 -0400 Subject: [Haskell-cafe] Can I get 'forall (a :: k). Typeable a => Dict (Typeable k)'? Message-ID: To respond to your original point: > Morally I think that > > class Typeable (a :: k) > > should have been > > class Typeable k => Typeable (a :: k) > > This has been considered before, although it is not entirely straightforward to implement. See [1] and [2], which track the idea of having GHC solve these constraints automatically, without the need for users to explicitly reach for `typeRepKind`. Best, Ryan ----- [1] https://gitlab.haskell.org/ghc/ghc/-/issues/14190 [2] https://gitlab.haskell.org/ghc/ghc/-/issues/16627 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Wed Aug 23 14:38:47 2023 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 23 Aug 2023 15:38:47 +0100 Subject: [Haskell-cafe] Can I get 'forall (a :: k). Typeable a => Dict (Typeable k)'? In-Reply-To: References: Message-ID: On Wed, Aug 23, 2023 at 09:35:59AM -0400, Ryan Scott wrote: > > Morally I think that > > > > class Typeable (a :: k) > > > > should have been > > > > class Typeable k => Typeable (a :: k) > > This has been considered before, although it is not entirely > straightforward to implement. See [1] and [2], which track the idea of > having GHC solve these constraints automatically, without the need for > users to explicitly reach for `typeRepKind`. > > [1] https://gitlab.haskell.org/ghc/ghc/-/issues/14190 > [2] https://gitlab.haskell.org/ghc/ghc/-/issues/16627 Interesting reading. Thanks Ryan! From ben at smart-cactus.org Wed Aug 23 19:07:40 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 23 Aug 2023 15:07:40 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha2 is now available In-Reply-To: References: <87jzu35415.fsf@smart-cactus.org> Message-ID: <87350937d3.fsf@smart-cactus.org> Arnaud Spiwack writes: > 😱 > Thanks Sam and Noon! I'm obviously great at copy-pasting. > Regardless, thanks for bringing the mistake to my attention. It will be fixed with the next alpha. 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 ben at well-typed.com Thu Aug 24 01:30:10 2023 From: ben at well-typed.com (Ben Gamari) Date: Wed, 23 Aug 2023 21:30:10 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha3 is now available Message-ID: <87zg2h1b39.fsf@smart-cactus.org> The GHC developers are very pleased to announce the availability of the third alpha prerelease of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.8.1-alpha3 GHC 9.8 will bring a number of new features and improvements, including: * Preliminary support the `TypeAbstractions` language extension, allowing types to be bound in type declarations [TypeAbstractions]. * Support for the `ExtendedLiterals` extension, providing syntax for non-word-sized numeric literals in the surface language [extended-literals] * Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns * Better support for user-defined warnings by way of the `WARNING` pragma [warnings] * The introduction of the new `GHC.TypeError.Unsatisfiable` constraint, allowing more predictable user-defined type errors [unsatisfiable] * Implementation of the export deprecation proposal, allowing module exports to be marked with `DEPRECATE` pragmas [deprecated-exports] * The addition of build semaphore support for parallel compilation; with coming support in `cabal-install` this will allow better use of parallelism in multi-package builds [jsem] * More efficient representation of info table provenance information, reducing binary sizes by over 50% in some cases when `-finfo-table-map` is in use A full accounting of changes can be found in the [release notes]. This alpha includes roughly a dozen changes relative to alpha 2, including what we believe should be nearly the last changes to GHC's boot libraries. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, 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 compiling, ~ Ben [TypeAbstractions]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst [extended-literals]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst [unsatisfiable]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst [warnings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst [deprecated-exports]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst [jsem]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst [release notes]: https://downloads.haskell.org/ghc/9.8.1-alpha3/docs/users_guide/9.8.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 julianbrunner at gmail.com Fri Aug 25 15:59:54 2023 From: julianbrunner at gmail.com (Julian Brunner) Date: Fri, 25 Aug 2023 17:59:54 +0200 Subject: [Haskell-cafe] OAuth on gitlab.haskell.org Message-ID: Hello, I last used gitlab.haskell.org in 2022 via OAuth on my GitHub account. However, this seems to no longer be an option. The account itself (https://gitlab.haskell.org/julianbrunner) seems to still exist, but I am unable to log in or request a password reset. I could not find any way to contact anyone on gitlab.haskell.org or any information on the removal of the OAuth option. Does anyone know how I can get my account back or who I should contact to get this sorted out? Cheers, Julian From allbery.b at gmail.com Fri Aug 25 16:04:24 2023 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 25 Aug 2023 12:04:24 -0400 Subject: [Haskell-cafe] OAuth on gitlab.haskell.org In-Reply-To: References: Message-ID: You need to do one of: 1. email to ghc-devs at haskell.org; 2. contact an admin on Libera.Chat IRC #ghc; OR 3. contact an admin in the GHC room on Matrix. On Fri, Aug 25, 2023 at 12:00 PM Julian Brunner wrote: > > Hello, > > I last used gitlab.haskell.org in 2022 via OAuth on my GitHub account. > However, this seems to no longer be an option. The account itself > (https://gitlab.haskell.org/julianbrunner) seems to still exist, but I > am unable to log in or request a password reset. I could not find any > way to contact anyone on gitlab.haskell.org or any information on the > removal of the OAuth option. Does anyone know how I can get my account > back or who I should contact to get this sorted out? > > Cheers, > Julian > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com From coot at coot.me Fri Aug 25 17:40:50 2023 From: coot at coot.me (coot at coot.me) Date: Fri, 25 Aug 2023 17:40:50 +0000 Subject: [Haskell-cafe] IOSim on Hackage In-Reply-To: References: Message-ID: Hi Robin, Some time ago we received a question about Dejafu on GitHub. Duncan provided a longer answer so let me share the link: https://github.com/input-output-hk/io-sim/issues/53 (tldr: `io-sim` simulates time, while dejafu might provide nicer partial order reduction). I haven't thoroughly reviewed `unliftio`, so my answer can only be partial. My impression is that a subset of `unliftio` can be supported by `io-sim`, but not things that require `OS` support or cross language barrier, e.g. disk access, spawning processes, foreign calls. With `io-sim` one has to implement such things as `IO` is not available in `IOSim` monad :smile: - but this isn't that hard as it sounds and gives some interesting opportunities. One of teams in IOG simulates file system API with `fs-sim` (https://github.com/input-output-hk/fs-sim) - they're planning to publish it on Hackage. We implemented the Berkeley Socket interface (actually something a bit more general as we needed to support some Windows stuff too), which we also plan to publish on Hackage at some point. The advantage of owning an implementation is that one can do failure injection, something that otherwise requires a middleman between the process and OS (or a special kernel driver) - which isn't that easy as writing something in Haskell. To be honest I have too little experience with working with Dejafu to be able to give a very good comparison. I spent a fair bit of time debugging deadlocks and race conditions with `io-sim`, and that's how `io-sim` support for debugging such bugs got quite decent. In particular all threads, `TVar`'s and `MVar`s can be named, one can emit traces when `TVar`s are committed - still debugging race conditions or deadlocks is fun :wink:. This is also useful for writing quickcheck property style tests, which have access to internal state changes, which becomes independent of thread scheduling (unlike `putStrLn` or something similar). Two outstanding issues are: * add support for `IORef`s: for `io-sim` this is streightforward, for `io-sim-por` (the partial reduction algorightm we have) probably complex, just because POR is complex in itself; * add support for `MVar` inspection (as we do with `TVar`s; the simulated `MVar`s are implemented with `TVar`s). There are probably some places were we missing some APIs from one of the packages which we want to support (`base`, `async`, `stm` & `time`). We want to keep up with their evolution. The list of issues is quite short now (we churned quite a number of issues in the past!): https://github.com/orgs/input-output-hk/projects/19/views/24 Best regards, Marcin ------- Original Message ------- On Monday, August 21st, 2023 at 15:30, Robin Palotai wrote: > Nice! Always good to see more production tooling to emerge. > A question, not that it is your responsibility to consider, but in case you have thoughts, would be keen to hear: > > Are there any long term integrative plan on bringing the various Io/exception/concurrency abstractions on a compatible basis? Currently there's for example unliftio/Rio, which is already not compatible with dejafu. Dejafu is class based, but might not play well with these io-classes. Also, the emulated semantics might differ. Etc. > > To a player who wants "just" some robust working ecosystem, all these choices and turbulence is quite hard to navigate or make choices about. And input about observed pros/cons and long term plans appreciated. > > Thank you, > Robin > > On Sun, Aug 20, 2023, 23:02 wrote: > > > Hello dear Haskell-Cafe, > > > > I realised that I haven't shared here that we (the networking team of IOG) released io-sim on Hackage. We found and fixed countless bugs thanks to it, including some concurrent ones. Here's a blog post which I wrote some time ago: > > https://engineering.iog.io/2023-04-14-io-sim-annoucement > > > > https://hackage.haskell.org/package/io-sim > > https://hackage.haskell.org/package/io-classes > > > > Cheers, > > Marcin Szamotulski > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 509 bytes Desc: OpenPGP digital signature URL: From carter.schonwald at gmail.com Fri Aug 25 22:04:59 2023 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 25 Aug 2023 18:04:59 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.6 is now available In-Reply-To: <87edke7slk.fsf@smart-cactus.org> References: <87edke7slk.fsf@smart-cactus.org> Message-ID: you like to 9.4.6 instead of .7 ... On Mon, Aug 7, 2023 at 11:58 AM Ben Gamari wrote: > > The GHC developers are happy to announce the availability of GHC 9.4.6. > Binary > distributions, source distributions, and documentation are available at > > https://downloads.haskell.org/ghc/9.4.6 > > This release is primarily a bugfix release addressing some issues > found in 9.4.6. These include: > > * Many bug fixes for the simplifier, preventing compiler panics, loops and > incorrect code generation (#22761, #22549, #23208, #22761, #22272, > #23146, > #23012, #22547). > * Bug fixes for the typechecker involving newtype family instances, making > type equalities more robust and bugs having to do with defaulting > representation > polymorphic type variables (#23329, #23333, #23143, #23154, #23176). > * Some bug fixes for code generation, particularly on the aarch64 backend, > including adding more memory barriers for array read operations > (#23541, #23749). > * Some bug fixes for windows builds, ensuring the reliablility of IO > manager shutdown > and a bug fix for the RTS linker on windows (#23691, #22941). > * A bug fix for the non-moving GC ensuring mutator allocations are > properly > accounted for (#23312). > * A bug fix preventing some segfaults by ensuring that pinned allocations > respect > block size (#23400). > * Many bug fixes for the bytecode interpreter, allowing a greater subset > of the language to be interpreted (#22376, #22840, #22051, #21945, > #23068, #22958). > * ... and a few 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, > 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 compiling, > > - Zubin & Ben > > > [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new > [release notes]: > https://downloads.haskell.org/~ghc/9.4.6/docs/users_guide/9.4.6-notes.html > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From palotai.robin at gmail.com Fri Aug 25 22:15:57 2023 From: palotai.robin at gmail.com (Robin Palotai) Date: Sat, 26 Aug 2023 00:15:57 +0200 Subject: [Haskell-cafe] IOSim on Hackage In-Reply-To: References: Message-ID: Thank you Marcin for the overview! The dejafu issue is indeed insightful as well. Let me recap my understanding of unliftio - you are probably aware, but let's have it down for future reference. (Monad)UnliftIO, the typeclass, itself is "just" an IO abstraction similar to previous ones like MonadIO or MonadBaseControl, but more restrictive: Only those instances are admitted, that play nicely with running them in plain IO, also with concurrenty. This in practice mostly means ReaderT IO and things isomorphic to it. So excluded is StateT etc - because it gets hairy to forkIO a StateT IO computation - the state is practically discarded (hm, one might be able to do something funky with async and StateT, though it would still operate on some forked state, and one would need to manually merge back isn't it..) Anyway UnliftIO's take in this case, is to be honest and use explicit mutable state (like MVars) in a concurrent setting. Unliftio, the ecosystem (well, mostly the 'unlftio' package), is akin to lifted-base and lifted-whatever, providing operations with UnliftIO constraint. Now, about unliftio and dejafu.. I pondered using them together (some thread lingering in https://github.com/barrucadu/dejafu/issues/298). But one can't just program against some newtyped monad that has both a MonadConc instance (for dejafu's sake) and also an UnliftIO instance (for production running), because - and let's shelve API differences - the semantics on exception handling and cleanup differs: UnliftIO follows the safe-exceptions tradition, and a) the default catch doesn't catch async exceptions (so, as long as your own code is concerned, you can promptly kill a thread without accidentally catching the async exception with a sync-intended handler), also b) the default cleanup actions run under uninterruptibleMask (of which there's a mega-issue-thread, but the intention is to rather be correct and maybe deadlock, rather than leave resources in uncleaned state, in case the cleanup handler gets interrupted itself too).* All in all, dejafu expects (or simulates) MonadConc according to the base behavior (unsurprisingly). So MonadConc would need to be banished into some internal layer of unliftio (in some unlfitio-concurrency package?), which sounds like a rather tedious work (but maybe not impossible). But having this, at least when unliftio and dejafu is concerned, would be desirable - it would be worth a separate story the subtle differences I ran into when using unliftio's supposedly "just lifted" versions of some async operations, that subtly differ in exception handling / masking behavior compared to the original, and can lead to some "interesting" results. Not having dejafu available, I have to resort to random threadDelay injections when testing, which is not very nice (or fast, or comprehensive). Having this said, I certainly see the utility of an abstraction that provides seamless mocking and testable concurrency. Mockable time sounds especially useful. And one, if really wants, can implement the safe-exceptions behavior on top of any abstraction (hm.. I guess), and avoid using oddly-behaving instances. I hope one day I can try io-classes / io-sim. Good luck with it & thanks again! *: I'm rather content with unliftio's choices about exception and cleanup behavior, just sad it creates such non-uniformity in tooling / mindset needed. ezt írta (időpont: 2023. aug. 25., P, 19:41): > Hi Robin, > > Some time ago we received a question about Dejafu on GitHub. Duncan > provided a longer answer so let me share the link: > > https://github.com/input-output-hk/io-sim/issues/53 > (tldr: `io-sim` simulates time, while dejafu might provide nicer partial > order reduction). > > I haven't thoroughly reviewed `unliftio`, so my answer can only be > partial. My impression is that a subset of `unliftio` can be supported by > `io-sim`, but not things that require `OS` support or cross language > barrier, e.g. disk access, spawning processes, foreign calls. With > `io-sim` one has to implement such things as `IO` is not available in > `IOSim` monad :smile: - but this isn't that hard as it sounds and gives > some interesting opportunities. One of teams in IOG simulates file system > API with `fs-sim` (https://github.com/input-output-hk/fs-sim) - they're > planning to publish it on Hackage. We implemented the Berkeley Socket > interface (actually something a bit more general as we needed to support > some Windows stuff too), which we also plan to publish on Hackage at some > point. The advantage of owning an implementation is that one can do > failure injection, something that otherwise requires a middleman between > the process and OS (or a special kernel driver) - which isn't that easy as > writing something in Haskell. > > To be honest I have too little experience with working with Dejafu to be > able to give a very good comparison. I spent a fair bit of time debugging > deadlocks and race conditions with `io-sim`, and that's how `io-sim` > support for debugging such bugs got quite decent. In particular all > threads, `TVar`'s and `MVar`s can be named, one can emit traces when > `TVar`s are committed - still debugging race conditions or deadlocks is fun > :wink:. > This is also useful for writing quickcheck property style tests, which > have access to internal state changes, which becomes independent of thread > scheduling (unlike `putStrLn` or something similar). > > Two outstanding issues are: > * add support for `IORef`s: for `io-sim` this is streightforward, for > `io-sim-por` (the partial reduction algorightm we have) probably complex, > just because POR is complex in itself; > * add support for `MVar` inspection (as we do with `TVar`s; the simulated > `MVar`s are implemented with `TVar`s). > There are probably some places were we missing some APIs from one of the > packages which we want to support (`base`, `async`, `stm` & `time`). We > want to keep up with their evolution. The list of issues is quite short > now (we churned quite a number of issues in the past!): > https://github.com/orgs/input-output-hk/projects/19/views/24 > > > > Best regards, > Marcin > > ------- Original Message ------- > On Monday, August 21st, 2023 at 15:30, Robin Palotai < > palotai.robin at gmail.com> wrote: > > > > Nice! Always good to see more production tooling to emerge. > > A question, not that it is your responsibility to consider, but in case > you have thoughts, would be keen to hear: > > > > > Are there any long term integrative plan on bringing the various > Io/exception/concurrency abstractions on a compatible basis? Currently > there's for example unliftio/Rio, which is already not compatible with > dejafu. Dejafu is class based, but might not play well with these > io-classes. Also, the emulated semantics might differ. Etc. > > > > > To a player who wants "just" some robust working ecosystem, all these > choices and turbulence is quite hard to navigate or make choices about. And > input about observed pros/cons and long term plans appreciated. > > > > > Thank you, > > Robin > > > > > On Sun, Aug 20, 2023, 23:02 wrote: > > > > > > Hello dear Haskell-Cafe, > > > > > > > I realised that I haven't shared here that we (the networking team of > IOG) released io-sim on Hackage. We found and fixed countless bugs thanks > to it, including some concurrent ones. Here's a blog post which I wrote > some time ago: > > > https://engineering.iog.io/2023-04-14-io-sim-annoucement > > > > > > > https://hackage.haskell.org/package/io-sim > > > https://hackage.haskell.org/package/io-classes > > > > > > > Cheers, > > > Marcin Szamotulski > > > _______________________________________________ > > > Haskell-Cafe mailing list > > > To (un)subscribe, modify options or view archives go to: > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From palotai.robin at gmail.com Fri Aug 25 22:30:46 2023 From: palotai.robin at gmail.com (Robin Palotai) Date: Sat, 26 Aug 2023 00:30:46 +0200 Subject: [Haskell-cafe] IOSim on Hackage In-Reply-To: References: Message-ID: A follow-up question: what is the approach with using third-party libraries that operate in terms of plain IO? Without a MonadIO constraint, lifting is not possible (even less MonadBaseControl or UnliftIO-style callback lifting... which is a great thing in UnliftIO by the way). Given that being able to simulate is a goal, do I assume right that the approch would be to rewrite those third-party libs in terms of io-classes? Or maybe to inject some mockable behavior (like a monad-parameterized Handle pattern, or just plain monadic functions), and use a fake during simulation, while the true implementation otherwise? Thanks, Robin Robin Palotai ezt írta (időpont: 2023. aug. 26., Szo, 0:15): > Thank you Marcin for the overview! The dejafu issue is indeed insightful > as well. > > Let me recap my understanding of unliftio - you are probably aware, but > let's have it down for future reference. > > (Monad)UnliftIO, the typeclass, itself is "just" an IO abstraction similar > to previous ones like MonadIO or MonadBaseControl, but more restrictive: > Only those instances are admitted, that play nicely with running them in > plain IO, also with concurrenty. This in practice mostly means ReaderT IO > and things isomorphic to it. So excluded is StateT etc - because it gets > hairy to forkIO a StateT IO computation - the state is practically > discarded (hm, one might be able to do something funky with async and > StateT, though it would still operate on some forked state, and one would > need to manually merge back isn't it..) Anyway UnliftIO's take in this > case, is to be honest and use explicit mutable state (like MVars) in a > concurrent setting. > > Unliftio, the ecosystem (well, mostly the 'unlftio' package), is akin to > lifted-base and lifted-whatever, providing operations with UnliftIO > constraint. > > Now, about unliftio and dejafu.. I pondered using them together (some > thread lingering in https://github.com/barrucadu/dejafu/issues/298). But > one can't just program against some newtyped monad that has both a > MonadConc instance (for dejafu's sake) and also an UnliftIO instance (for > production running), because - and let's shelve API differences - the > semantics on exception handling and cleanup differs: UnliftIO follows the > safe-exceptions tradition, and a) the default catch doesn't catch async > exceptions (so, as long as your own code is concerned, you can promptly > kill a thread without accidentally catching the async exception with a > sync-intended handler), also b) the default cleanup actions run under > uninterruptibleMask (of which there's a mega-issue-thread, but the > intention is to rather be correct and maybe deadlock, rather than leave > resources in uncleaned state, in case the cleanup handler gets interrupted > itself too).* > > All in all, dejafu expects (or simulates) MonadConc according to the base > behavior (unsurprisingly). So MonadConc would need to be banished into some > internal layer of unliftio (in some unlfitio-concurrency package?), which > sounds like a rather tedious work (but maybe not impossible). > > But having this, at least when unliftio and dejafu is concerned, would be > desirable - it would be worth a separate story the subtle differences I ran > into when using unliftio's supposedly "just lifted" versions of some async > operations, that subtly differ in exception handling / masking behavior > compared to the original, and can lead to some "interesting" results. Not > having dejafu available, I have to resort to random threadDelay injections > when testing, which is not very nice (or fast, or comprehensive). > > Having this said, I certainly see the utility of an abstraction that > provides seamless mocking and testable concurrency. Mockable time sounds > especially useful. And one, if really wants, can implement the > safe-exceptions behavior on top of any abstraction (hm.. I guess), and > avoid using oddly-behaving instances. > > I hope one day I can try io-classes / io-sim. Good luck with it & thanks > again! > > *: I'm rather content with unliftio's choices about exception and cleanup > behavior, just sad it creates such non-uniformity in tooling / mindset > needed. > > ezt írta (időpont: 2023. aug. 25., P, 19:41): > >> Hi Robin, >> >> Some time ago we received a question about Dejafu on GitHub. Duncan >> provided a longer answer so let me share the link: >> >> https://github.com/input-output-hk/io-sim/issues/53 >> (tldr: `io-sim` simulates time, while dejafu might provide nicer partial >> order reduction). >> >> I haven't thoroughly reviewed `unliftio`, so my answer can only be >> partial. My impression is that a subset of `unliftio` can be supported by >> `io-sim`, but not things that require `OS` support or cross language >> barrier, e.g. disk access, spawning processes, foreign calls. With >> `io-sim` one has to implement such things as `IO` is not available in >> `IOSim` monad :smile: - but this isn't that hard as it sounds and gives >> some interesting opportunities. One of teams in IOG simulates file system >> API with `fs-sim` (https://github.com/input-output-hk/fs-sim) - they're >> planning to publish it on Hackage. We implemented the Berkeley Socket >> interface (actually something a bit more general as we needed to support >> some Windows stuff too), which we also plan to publish on Hackage at some >> point. The advantage of owning an implementation is that one can do >> failure injection, something that otherwise requires a middleman between >> the process and OS (or a special kernel driver) - which isn't that easy as >> writing something in Haskell. >> >> To be honest I have too little experience with working with Dejafu to be >> able to give a very good comparison. I spent a fair bit of time debugging >> deadlocks and race conditions with `io-sim`, and that's how `io-sim` >> support for debugging such bugs got quite decent. In particular all >> threads, `TVar`'s and `MVar`s can be named, one can emit traces when >> `TVar`s are committed - still debugging race conditions or deadlocks is fun >> :wink:. >> This is also useful for writing quickcheck property style tests, which >> have access to internal state changes, which becomes independent of thread >> scheduling (unlike `putStrLn` or something similar). >> >> Two outstanding issues are: >> * add support for `IORef`s: for `io-sim` this is streightforward, for >> `io-sim-por` (the partial reduction algorightm we have) probably complex, >> just because POR is complex in itself; >> * add support for `MVar` inspection (as we do with `TVar`s; the simulated >> `MVar`s are implemented with `TVar`s). >> There are probably some places were we missing some APIs from one of the >> packages which we want to support (`base`, `async`, `stm` & `time`). We >> want to keep up with their evolution. The list of issues is quite short >> now (we churned quite a number of issues in the past!): >> https://github.com/orgs/input-output-hk/projects/19/views/24 >> >> >> >> Best regards, >> Marcin >> >> ------- Original Message ------- >> On Monday, August 21st, 2023 at 15:30, Robin Palotai < >> palotai.robin at gmail.com> wrote: >> >> >> > Nice! Always good to see more production tooling to emerge. >> > A question, not that it is your responsibility to consider, but in case >> you have thoughts, would be keen to hear: >> > >> >> > Are there any long term integrative plan on bringing the various >> Io/exception/concurrency abstractions on a compatible basis? Currently >> there's for example unliftio/Rio, which is already not compatible with >> dejafu. Dejafu is class based, but might not play well with these >> io-classes. Also, the emulated semantics might differ. Etc. >> > >> >> > To a player who wants "just" some robust working ecosystem, all these >> choices and turbulence is quite hard to navigate or make choices about. And >> input about observed pros/cons and long term plans appreciated. >> > >> >> > Thank you, >> > Robin >> > >> >> > On Sun, Aug 20, 2023, 23:02 wrote: >> > >> >> > > Hello dear Haskell-Cafe, >> > > >> >> > > I realised that I haven't shared here that we (the networking team of >> IOG) released io-sim on Hackage. We found and fixed countless bugs thanks >> to it, including some concurrent ones. Here's a blog post which I wrote >> some time ago: >> > > https://engineering.iog.io/2023-04-14-io-sim-annoucement >> > > >> >> > > https://hackage.haskell.org/package/io-sim >> > > https://hackage.haskell.org/package/io-classes >> > > >> >> > > Cheers, >> > > Marcin Szamotulski >> > > _______________________________________________ >> > > Haskell-Cafe mailing list >> > > To (un)subscribe, modify options or view archives go to: >> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > Only members subscribed via the mailman list are allowed to post. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at haskell.foundation Sat Aug 26 04:37:14 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Sat, 26 Aug 2023 07:37:14 +0300 Subject: [Haskell-cafe] OAuth on gitlab.haskell.org In-Reply-To: References: Message-ID: Hi Julian, sorry for the trouble. You *should* be able to use password reset on GitLab in order to create a password and log in with it. Others have done this. I turned off GitHub oauth because there was a deluge of spam accounts that were bypassing account approval by using it. I do want to turn it back on eventually, but we need to do some other work first to have better spam protection. This mailing list is where I announced the change when it happened. I do wish I had a better way to reach active users who might run into this... Let me know if you continue to have trouble getting in. -Bryan On Fri, 25 Aug 2023, 19.00 Julian Brunner, wrote: > Hello, > > I last used gitlab.haskell.org in 2022 via OAuth on my GitHub account. > However, this seems to no longer be an option. The account itself > (https://gitlab.haskell.org/julianbrunner) seems to still exist, but I > am unable to log in or request a password reset. I could not find any > way to contact anyone on gitlab.haskell.org or any information on the > removal of the OAuth option. Does anyone know how I can get my account > back or who I should contact to get this sorted out? > > Cheers, > Julian > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at haskell.foundation Sat Aug 26 04:39:22 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Sat, 26 Aug 2023 07:39:22 +0300 Subject: [Haskell-cafe] OAuth on gitlab.haskell.org In-Reply-To: References: Message-ID: Sorry, when I said "this mailing list" I thought I was talking to ghc-devs at haskell.org! Perhaps *this* list *would* have been better. Here was the message: https://mail.haskell.org/pipermail/ghc-devs/2023-May/021222.html On Sat, 26 Aug 2023, 7.37 Bryan Richter, wrote: > Hi Julian, sorry for the trouble. > > You *should* be able to use password reset on GitLab in order to create a > password and log in with it. Others have done this. > > I turned off GitHub oauth because there was a deluge of spam accounts that > were bypassing account approval by using it. I do want to turn it back on > eventually, but we need to do some other work first to have better spam > protection. > > This mailing list is where I announced the change when it happened. I do > wish I had a better way to reach active users who might run into this... > > Let me know if you continue to have trouble getting in. > > -Bryan > > On Fri, 25 Aug 2023, 19.00 Julian Brunner, > wrote: > >> Hello, >> >> I last used gitlab.haskell.org in 2022 via OAuth on my GitHub account. >> However, this seems to no longer be an option. The account itself >> (https://gitlab.haskell.org/julianbrunner) seems to still exist, but I >> am unable to log in or request a password reset. I could not find any >> way to contact anyone on gitlab.haskell.org or any information on the >> removal of the OAuth option. Does anyone know how I can get my account >> back or who I should contact to get this sorted out? >> >> Cheers, >> Julian >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zubin at well-typed.com Sat Aug 26 10:38:46 2023 From: zubin at well-typed.com (Zubin Duggal) Date: Sat, 26 Aug 2023 16:08:46 +0530 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.4.7 is now available Message-ID: The GHC developers are happy to announce the availability of GHC 9.4.7. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.4.7 The GHC developers are happy to announce the availability of GHC 9.4.7. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org](https://downloads.haskell.org/ghc/9.4.7). This release is primarily a bugfix release addressing some issues found in 9.4.6. These include: * A bump to bytestring-0.11.5.2 allowing GHC to be bootstrapped on systems where the bootstrap compiler is built with the `pthread_condattr_setclock` symbol available (#23789). * A number of bug fixes for scoping bugs in the specialiser, preventing simplifier panics (#21391, #21689, #21828, #23762). * Distributing dynamically linked alpine bindists (#23349, #23828). * A bug fix for the release notes syntax, allowing them to built on systems with older python and sphinx versions (#23807, #23818). * ... and a few more. See the [release notes] for a full accounting. 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 compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.4.7/docs/users_guide/9.4.7-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From coot at coot.me Sat Aug 26 10:58:52 2023 From: coot at coot.me (coot at coot.me) Date: Sat, 26 Aug 2023 10:58:52 +0000 Subject: [Haskell-cafe] IOSim on Hackage In-Reply-To: References: Message-ID: If it comes to exception handling, we follow `base` rather than `safe-execeptions` package (there's a trade-off between async exceptions vs deadlocks, as safe exceptions is using `uninterruptibleMask`). But one can always create a type class which provide the same semantics as `safe-exceptions` do (think of `io-classes` as a description of interface which `base` provides). We provide instances for `ReaderT` transformer in `io-classes`, instances for some other transformers are provided in a more experimental package `io-classes-mtl` (we don't use it in production). > All in all, dejafu expects (or simulates) MonadConc according to > the base behavior (unsurprisingly). So MonadConc would need to be > banished into some internal layer of unliftio (in some unlfitio-concurrency package?), which sounds like a rather tedious work (but > maybe not impossible). Some monad transformers are not really well suited for concurrency, e.g. `StateT` is one example. One would need a strategy for merging state when something like `concurrently` finishes. There's `lifted-async` on Hackage, but we were not convinced that it's the right choice. I did experiment with this a bit, but unfortunately I wasn't able to find the branch now. > A follow-up question: what is the approach with using third-party libraries that operate in terms of plain IO? One would need to generalise the library to be polymorphic over `IO`. One example we have is the `MonadST` (https://hackage.haskell.org/package/io-classes-1.2.0.0/docs/Control-Monad-Class-MonadST.html#t:MonadST). So for MonadUnliftIO this could be: ``` class MonadUnliftIO m io where ... ``` where `m` has the same meaning but `io` is either `IO` or `IOSim`; Alternatively `io` could be captured as an associated type family. Cheers, Marcin Sent with Proton Mail secure email. ------- Original Message ------- On Saturday, August 26th, 2023 at 00:30, Robin Palotai wrote: > A follow-up question: what is the approach with using third-party libraries that operate in terms of plain IO? Without a MonadIO constraint, lifting is not possible (even less MonadBaseControl or UnliftIO-style callback lifting... which is a great thing in UnliftIO by the way). > Given that being able to simulate is a goal, do I assume right that the approch would be to rewrite those third-party libs in terms of io-classes? Or maybe to inject some mockable behavior (like a monad-parameterized Handle pattern, or just plain monadic functions), and use a fake during simulation, while the true implementation otherwise? > > Thanks, > Robin > > Robin Palotai ezt írta (időpont: 2023. aug. 26., Szo, 0:15): > > > Thank you Marcin for the overview! The dejafu issue is indeed insightful as well. > > Let me recap my understanding of unliftio - you are probably aware, but let's have it down for future reference. > > > > (Monad)UnliftIO, the typeclass, itself is "just" an IO abstraction similar to previous ones like MonadIO or MonadBaseControl, but more restrictive: Only those instances are admitted, that play nicely with running them in plain IO, also with concurrenty. This in practice mostly means ReaderT IO and things isomorphic to it. So excluded is StateT etc - because it gets hairy to forkIO a StateT IO computation - the state is practically discarded (hm, one might be able to do something funky with async and StateT, though it would still operate on some forked state, and one would need to manually merge back isn't it..) Anyway UnliftIO's take in this case, is to be honest and use explicit mutable state (like MVars) in a concurrent setting. > > > > Unliftio, the ecosystem (well, mostly the 'unlftio' package), is akin to lifted-base and lifted-whatever, providing operations with UnliftIO constraint. > > > > Now, about unliftio and dejafu.. I pondered using them together (some thread lingering in https://github.com/barrucadu/dejafu/issues/298). But one can't just program against some newtyped monad that has both a MonadConc instance (for dejafu's sake) and also an UnliftIO instance (for production running), because - and let's shelve API differences - the semantics on exception handling and cleanup differs: UnliftIO follows the safe-exceptions tradition, and a) the default catch doesn't catch async exceptions (so, as long as your own code is concerned, you can promptly kill a thread without accidentally catching the async exception with a sync-intended handler), also b) the default cleanup actions run under uninterruptibleMask (of which there's a mega-issue-thread, but the intention is to rather be correct and maybe deadlock, rather than leave resources in uncleaned state, in case the cleanup handler gets interrupted itself too).* > > > > All in all, dejafu expects (or simulates) MonadConc according to the base behavior (unsurprisingly). So MonadConc would need to be banished into some internal layer of unliftio (in some unlfitio-concurrency package?), which sounds like a rather tedious work (but maybe not impossible). > > > > But having this, at least when unliftio and dejafu is concerned, would be desirable - it would be worth a separate story the subtle differences I ran into when using unliftio's supposedly "just lifted" versions of some async operations, that subtly differ in exception handling / masking behavior compared to the original, and can lead to some "interesting" results. Not having dejafu available, I have to resort to random threadDelay injections when testing, which is not very nice (or fast, or comprehensive). > > > > Having this said, I certainly see the utility of an abstraction that provides seamless mocking and testable concurrency. Mockable time sounds especially useful. And one, if really wants, can implement the safe-exceptions behavior on top of any abstraction (hm.. I guess), and avoid using oddly-behaving instances. > > > > I hope one day I can try io-classes / io-sim. Good luck with it & thanks again! > > > > *: I'm rather content with unliftio's choices about exception and cleanup behavior, just sad it creates such non-uniformity in tooling / mindset needed. > > > > ezt írta (időpont: 2023. aug. 25., P, 19:41): > > > > > Hi Robin, > > > > > > Some time ago we received a question about Dejafu on GitHub. Duncan provided a longer answer so let me share the link: > > > > > > https://github.com/input-output-hk/io-sim/issues/53 > > > (tldr: `io-sim` simulates time, while dejafu might provide nicer partial order reduction). > > > > > > I haven't thoroughly reviewed `unliftio`, so my answer can only be partial. My impression is that a subset of `unliftio` can be supported by `io-sim`, but not things that require `OS` support or cross language barrier, e.g. disk access, spawning processes, foreign calls. With `io-sim` one has to implement such things as `IO` is not available in `IOSim` monad :smile: - but this isn't that hard as it sounds and gives some interesting opportunities. One of teams in IOG simulates file system API with `fs-sim` (https://github.com/input-output-hk/fs-sim) - they're planning to publish it on Hackage. We implemented the Berkeley Socket interface (actually something a bit more general as we needed to support some Windows stuff too), which we also plan to publish on Hackage at some point. The advantage of owning an implementation is that one can do failure injection, something that otherwise requires a middleman between the process and OS (or a special kernel driver) - which isn't that easy as writing something in Haskell. > > > > > > To be honest I have too little experience with working with Dejafu to be able to give a very good comparison. I spent a fair bit of time debugging deadlocks and race conditions with `io-sim`, and that's how `io-sim` support for debugging such bugs got quite decent. In particular all threads, `TVar`'s and `MVar`s can be named, one can emit traces when `TVar`s are committed - still debugging race conditions or deadlocks is fun :wink:. > > > This is also useful for writing quickcheck property style tests, which have access to internal state changes, which becomes independent of thread scheduling (unlike `putStrLn` or something similar). > > > > > > Two outstanding issues are: > > > * add support for `IORef`s: for `io-sim` this is streightforward, for `io-sim-por` (the partial reduction algorightm we have) probably complex, just because POR is complex in itself; > > > * add support for `MVar` inspection (as we do with `TVar`s; the simulated `MVar`s are implemented with `TVar`s). > > > There are probably some places were we missing some APIs from one of the packages which we want to support (`base`, `async`, `stm` & `time`). We want to keep up with their evolution. The list of issues is quite short now (we churned quite a number of issues in the past!): > > > https://github.com/orgs/input-output-hk/projects/19/views/24 > > > > > > > > > > > > Best regards, > > > Marcin > > > > > > ------- Original Message ------- > > > On Monday, August 21st, 2023 at 15:30, Robin Palotai wrote: > > > > > > > > > > Nice! Always good to see more production tooling to emerge. > > > > A question, not that it is your responsibility to consider, but in case you have thoughts, would be keen to hear: > > > > > > > > > > > Are there any long term integrative plan on bringing the various Io/exception/concurrency abstractions on a compatible basis? Currently there's for example unliftio/Rio, which is already not compatible with dejafu. Dejafu is class based, but might not play well with these io-classes. Also, the emulated semantics might differ. Etc. > > > > > > > > > > > To a player who wants "just" some robust working ecosystem, all these choices and turbulence is quite hard to navigate or make choices about. And input about observed pros/cons and long term plans appreciated. > > > > > > > > > > > Thank you, > > > > Robin > > > > > > > > > > > On Sun, Aug 20, 2023, 23:02 wrote: > > > > > > > > > > > > Hello dear Haskell-Cafe, > > > > > > > > > > > > > I realised that I haven't shared here that we (the networking team of IOG) released io-sim on Hackage. We found and fixed countless bugs thanks to it, including some concurrent ones. Here's a blog post which I wrote some time ago: > > > > > https://engineering.iog.io/2023-04-14-io-sim-annoucement > > > > > > > > > > > > > https://hackage.haskell.org/package/io-sim > > > > > https://hackage.haskell.org/package/io-classes > > > > > > > > > > > > > Cheers, > > > > > Marcin Szamotulski > > > > > _______________________________________________ > > > > > Haskell-Cafe mailing list > > > > > To (un)subscribe, modify options or view archives go to: > > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 509 bytes Desc: OpenPGP digital signature URL: From leah at vuxu.org Sat Aug 26 18:45:13 2023 From: leah at vuxu.org (Leah Neukirchen) Date: Sat, 26 Aug 2023 20:45:13 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2023-08-30 @ 19:30 Message-ID: <87a5ud3ao6.fsf@vuxu.org> Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Wednesday, August 30 at Augustiner-Kurgarten (De-la-Paz-Straße 10, 80639 München) at 19h30. Different location as Rumpler is on summer holidays! For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this nuudel so we can reserve enough seats! It is OK to add yourself to the nuudel anonymously or pseudonymously. https://nuudel.digitalcourage.de/xYna3xETL2UACtzT Everybody is welcome! cu, -- Leah Neukirchen https://leahneukirchen.org/ From dennis.raddle at gmail.com Sun Aug 27 01:32:53 2023 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Sat, 26 Aug 2023 18:32:53 -0700 Subject: [Haskell-cafe] debugging <> exception Message-ID: I'm getting Exception: <>. It doesn't print the line number. When I load the program into ghci, it still doesn't print the line number. When I trace the program in ghci it never gets to the point of emitting the exception. I set up my program in stack. I tried both "stack ghci" and just "ghci".. the latter to make sure it wasn't using any compiled code (at least in my own code). If it doesn't print a line number does this mean it's happening in compiled code? Any ideas how I can go about debugging this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Sun Aug 27 01:43:30 2023 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Sat, 26 Aug 2023 18:43:30 -0700 Subject: [Haskell-cafe] debugging <> exception In-Reply-To: References: Message-ID: Sounds like a Heisenbug (turning profiling or debugging on may affect the reproducibility of the bug). Run the program for a while with profiling enabled, and the functions involved in the infinite loop might be apparent. Ivan On Sat, 26 Aug 2023 at 18:33, Dennis Raddle wrote: > I'm getting Exception: <>. > > It doesn't print the line number. When I load the program into ghci, it > still doesn't print the line number. When I trace the program in ghci it > never gets to the point of emitting the exception. > > I set up my program in stack. I tried both "stack ghci" and just "ghci".. > the latter to make sure it wasn't using any compiled code (at least in my > own code). If it doesn't print a line number does this mean it's happening > in compiled code? > > Any ideas how I can go about debugging this? > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sun Aug 27 01:50:10 2023 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 26 Aug 2023 21:50:10 -0400 Subject: [Haskell-cafe] debugging <> exception In-Reply-To: References: Message-ID: <> doesn't produce line numbers, since it happens at STG level while evaluating a thunk: it overwrites the entry point with the <> exception before evaluating it, so if the thunk is immediately re-entered, the <> is thrown. This is better than entering a tight loop, but not much easier to debug. On Sat, Aug 26, 2023 at 9:44 PM Ivan Perez wrote: > > Sounds like a Heisenbug (turning profiling or debugging on may affect the reproducibility of the bug). > > Run the program for a while with profiling enabled, and the functions involved in the infinite loop might be apparent. > > Ivan > > On Sat, 26 Aug 2023 at 18:33, Dennis Raddle wrote: >> >> I'm getting Exception: <>. >> >> It doesn't print the line number. When I load the program into ghci, it still doesn't print the line number. When I trace the program in ghci it never gets to the point of emitting the exception. >> >> I set up my program in stack. I tried both "stack ghci" and just "ghci".. the latter to make sure it wasn't using any compiled code (at least in my own code). If it doesn't print a line number does this mean it's happening in compiled code? >> >> Any ideas how I can go about debugging this? >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh allbery.b at gmail.com From dennis.raddle at gmail.com Mon Aug 28 01:49:30 2023 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Sun, 27 Aug 2023 18:49:30 -0700 Subject: [Haskell-cafe] debugging <> exception In-Reply-To: References: Message-ID: Thanks everyone. Once I learned what a <> actually is (I still have a vague understanding but it has something to do with circular definitions) I was able to simply inspect the code that I suspected had the problem and found a typo. It works now. On Sat, Aug 26, 2023 at 6:44 PM Ivan Perez wrote: > Sounds like a Heisenbug (turning profiling or debugging on may affect the > reproducibility of the bug). > > Run the program for a while with profiling enabled, and the functions > involved in the infinite loop might be apparent. > > Ivan > > On Sat, 26 Aug 2023 at 18:33, Dennis Raddle > wrote: > >> I'm getting Exception: <>. >> >> It doesn't print the line number. When I load the program into ghci, it >> still doesn't print the line number. When I trace the program in ghci it >> never gets to the point of emitting the exception. >> >> I set up my program in stack. I tried both "stack ghci" and just "ghci".. >> the latter to make sure it wasn't using any compiled code (at least in my >> own code). If it doesn't print a line number does this mean it's happening >> in compiled code? >> >> Any ideas how I can go about debugging this? >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From julianbrunner at gmail.com Mon Aug 28 13:20:46 2023 From: julianbrunner at gmail.com (Julian Brunner) Date: Mon, 28 Aug 2023 15:20:46 +0200 Subject: [Haskell-cafe] OAuth on gitlab.haskell.org In-Reply-To: References: Message-ID: Thank you for the information. I do not know what changed since when I tried it on Friday, but the password reset worked today, so I can access my account again. Thank you! On Sat, Aug 26, 2023 at 6:39 AM Bryan Richter wrote: > > Sorry, when I said "this mailing list" I thought I was talking to ghc-devs at haskell.org! Perhaps *this* list *would* have been better. > > Here was the message: https://mail.haskell.org/pipermail/ghc-devs/2023-May/021222.html > > On Sat, 26 Aug 2023, 7.37 Bryan Richter, wrote: >> >> Hi Julian, sorry for the trouble. >> >> You *should* be able to use password reset on GitLab in order to create a password and log in with it. Others have done this. >> >> I turned off GitHub oauth because there was a deluge of spam accounts that were bypassing account approval by using it. I do want to turn it back on eventually, but we need to do some other work first to have better spam protection. >> >> This mailing list is where I announced the change when it happened. I do wish I had a better way to reach active users who might run into this... >> >> Let me know if you continue to have trouble getting in. >> >> -Bryan >> >> On Fri, 25 Aug 2023, 19.00 Julian Brunner, wrote: >>> >>> Hello, >>> >>> I last used gitlab.haskell.org in 2022 via OAuth on my GitHub account. >>> However, this seems to no longer be an option. The account itself >>> (https://gitlab.haskell.org/julianbrunner) seems to still exist, but I >>> am unable to log in or request a password reset. I could not find any >>> way to contact anyone on gitlab.haskell.org or any information on the >>> removal of the OAuth option. Does anyone know how I can get my account >>> back or who I should contact to get this sorted out? >>> >>> Cheers, >>> Julian >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post.