From zubin at well-typed.com Tue Jan 9 09:55:19 2024 From: zubin at well-typed.com (Zubin Duggal) Date: Tue, 9 Jan 2024 15:25:19 +0530 Subject: [ANNOUNCE] GHC 9.6.4 is now available Message-ID: The GHC developers are happy to announce the availability of GHC 9.6.4. Binary distributions, source distributions, and documentation are available on the [release page](https://www.haskell.org/ghc/download_ghc_9_6_4.html). This release is primarily a bugfix release addressing a few issues found in the 9.6 series. These include: * A fix for a bug where certain warnings flags were not recognised (#24071) * Fixes for a number of simplifier bugs (#23952, #23862). * Fixes for compiler panics with certain package databases involving unusable units and module reexports (#21097, #16996, #11050). * A fix for a typechecker crash (#24083). * A fix for a code generator bug on AArch64 platforms resulting in invalid conditional jumps (#23746). * Fixes for some memory leaks in GHCi (#24107, #24118) * And a few other fixes A full accounting of changes can be found in the [release notes]. 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 hacking! -Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.6.4/docs/users_guide/9.6.4-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 kazu at iij.ad.jp Wed Jan 10 02:41:10 2024 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed, 10 Jan 2024 11:41:10 +0900 (JST) Subject: Upcoming GHC 9.4.8 release In-Reply-To: <20231026.103712.109163977995540406.kazu@iij.ad.jp> References: <20231025.105757.548341736261247555.kazu@iij.ad.jp> <20231026.103712.109163977995540406.kazu@iij.ad.jp> Message-ID: <20240110.114110.770640928370554831.kazu@iij.ad.jp> Hi, GHC 9.4.8 has solved my issue that profiles cannot be taken on M1 mac. Thanks! --Kazu > Hello Zubin, > >> The fix for the issue (!11254) has been marked for backport and will >> be included in the release. > > Thanks in advance! > > --Kazu From simon.peytonjones at gmail.com Thu Jan 11 15:28:44 2024 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Thu, 11 Jan 2024 15:28:44 +0000 Subject: GHC proposals not rendering Message-ID: If you go to https://github.com/ghc-proposals/ghc-proposals/pull/448, and click on the "rendered" link, namely https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-type-variable-scoping.rst, Github is now displaying the .rst source, not the rendered proposal. This has started happening (consistently across other proposals) today. Does anyone know why? How can I fix this? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodrigo.m.mesquita at gmail.com Thu Jan 11 15:38:26 2024 From: rodrigo.m.mesquita at gmail.com (Rodrigo Mesquita) Date: Thu, 11 Jan 2024 15:38:26 +0000 Subject: GHC proposals not rendering In-Reply-To: References: Message-ID: <44EC7EF7-6B8E-474A-9CC2-D96D6C1507F7@gmail.com> FWIW, I’m able to render/preview successfully other proposals, but 448-type-variable-scoping loads very slowly and ultimately fails to render for me too. A comment in https://github.com/github/markup/issues/1016 (issue related to .rst not rendering) says that forcing a change in the file triggered a re-render successfully. Rodrigo > On 11 Jan 2024, at 15:28, Simon Peyton Jones wrote: > > If you go to https://github.com/ghc-proposals/ghc-proposals/pull/448, and click on the "rendered" link, namely https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-type-variable-scoping.rst, Github is now displaying the .rst source, not the rendered proposal. > > This has started happening (consistently across other proposals) today. > > Does anyone know why? How can I fix this? > > Simon > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Thu Jan 11 16:53:15 2024 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Thu, 11 Jan 2024 16:53:15 +0000 Subject: Nofib patch Message-ID: Friends I have forgotten the workflow for adding a patch to nofib. The patch is below. (Trivial). Could someone apply it (and update GHC head to use it). Or tell me how to do it. Or both! Thanks Simon This patch makes 'veritas' stop using 'forall' as a function name. Reason: 'forall' is now a keyword diff --git a/real/veritas/Kernel.hs b/real/veritas/Kernel.hs index b1c69ef..2c491a7 100644 --- a/real/veritas/Kernel.hs +++ b/real/veritas/Kernel.hs @@ -384,7 +384,7 @@ constructor (SG sg) i j k {- Datatype elimination -} recurse tmL (TM (tm@(Binder Pi (Symbol_dec tm1 _) _ _ _)) _ sg) - = if forall ok (zip tmL tyL) + = if vforall ok (zip tmL tyL) then TM (Recurse (map fst tmL) tm [] []) tm sg else @@ -570,7 +570,7 @@ def (TM tm1 tm2 sg) make_data tmLL (TH tm sg) - = if forall (forall (wf_param sg1)) tmLL + = if vforall (vforall (wf_param sg1)) tmLL then if exists (eq_trm tm) non_empty_thms then diff --git a/real/veritas/Main.hs b/real/veritas/Main.hs index c0ed8e3..5191a67 100644 --- a/real/veritas/Main.hs +++ b/real/veritas/Main.hs @@ -107,7 +107,7 @@ goto_next tr@(TreeSt t _ _) incomplete_tree (Tree _ tl (SOME _) _ _ ) = False -incomplete_tree (Tree _ tl NONE _ _ ) = forall is_complete tl +incomplete_tree (Tree _ tl NONE _ _ ) = vforall is_complete tl diff --git a/real/veritas/Sub_Core3.hs b/real/veritas/Sub_Core3.hs index f6fd733..12c2987 100644 --- a/real/veritas/Sub_Core3.hs +++ b/real/veritas/Sub_Core3.hs @@ -248,7 +248,7 @@ eval (Constant F _ _) = False --eval (Constant _ _ _) = error "EvalError" -- ** exn eval (Binder Forall dc tm _ _) - = eval_quant forall dc tm + = eval_quant vforall dc tm eval (Binder Exists dc tm _ _) = eval_quant exists dc tm diff --git a/real/veritas/Vtslib.hs b/real/veritas/Vtslib.hs index 9a6c0fe..9ae06ab 100644 --- a/real/veritas/Vtslib.hs +++ b/real/veritas/Vtslib.hs @@ -1,4 +1,4 @@ -module Vtslib( Option(..) , Sum(..) , forall , exists , assoc , +module Vtslib( Option(..) , Sum(..) , vforall , exists , assoc , haskey , uncurry , curry , for , map' , module Core_datatype ) where @@ -14,9 +14,9 @@ data Sum a b = Inl a | Inr b N.B. forall & exists rewritten from ML -} -forall :: ( a -> Bool ) -> [a] -> Bool +vforall :: ( a -> Bool ) -> [a] -> Bool -forall p = and . ( map p ) +vforall p = and . ( map p ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Fri Jan 12 12:49:24 2024 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Fri, 12 Jan 2024 12:49:24 +0000 Subject: GHC proposals not rendering In-Reply-To: <44EC7EF7-6B8E-474A-9CC2-D96D6C1507F7@gmail.com> References: <44EC7EF7-6B8E-474A-9CC2-D96D6C1507F7@gmail.com> Message-ID: But it used to work fine. What has changed? It seems like a pretty serious bug! On Thu, 11 Jan 2024 at 15:38, Rodrigo Mesquita wrote: > FWIW, I’m able to render/preview successfully other proposals, but > 448-type-variable-scoping loads very slowly and ultimately fails to render > for me too. > > A comment in https://github.com/github/markup/issues/1016 (issue related > to .rst not rendering) says that forcing a change in the file triggered a > re-render successfully. > > Rodrigo > > > On 11 Jan 2024, at 15:28, Simon Peyton Jones > wrote: > > If you go to https://github.com/ghc-proposals/ghc-proposals/pull/448, and > click on the "rendered" link, namely > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-type-variable-scoping.rst, > Github is now displaying the .rst source, not the rendered proposal. > > This has started happening (consistently across other proposals) today. > > Does anyone know why? How can I fix this? > > Simon > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at haskell.foundation Fri Jan 19 11:51:34 2024 From: bryan at haskell.foundation (Bryan Richter) Date: Fri, 19 Jan 2024 13:51:34 +0200 Subject: Do you use stack to build hadrian? Message-ID: If nobody uses stack to build hadrian, (or even if a few people do), there's talk of removing that option because very few people do use it. Feel free to weigh in at https://gitlab.haskell.org/ghc/ghc/-/issues/24274#note_541913 -Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at haskell.foundation Fri Jan 19 12:16:30 2024 From: bryan at haskell.foundation (Bryan Richter) Date: Fri, 19 Jan 2024 14:16:30 +0200 Subject: GHC proposals not rendering In-Reply-To: References: <44EC7EF7-6B8E-474A-9CC2-D96D6C1507F7@gmail.com> Message-ID: I'm guessing GitHub had to limit the size of .rst files that get rendered. I can imagine the kinds of annoying security or abuse issues they might be working around... The smallest file that doesn't work that I found by clicking around: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst (42KB) The largest that does still work: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0581-namespace-specified-imports.rst (25KB) On Fri, 12 Jan 2024 at 14:49, Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > But it used to work fine. What has changed? It seems like a pretty > serious bug! > > On Thu, 11 Jan 2024 at 15:38, Rodrigo Mesquita < > rodrigo.m.mesquita at gmail.com> wrote: > >> FWIW, I’m able to render/preview successfully other proposals, but >> 448-type-variable-scoping loads very slowly and ultimately fails to render >> for me too. >> >> A comment in https://github.com/github/markup/issues/1016 (issue related >> to .rst not rendering) says that forcing a change in the file triggered a >> re-render successfully. >> >> Rodrigo >> >> >> On 11 Jan 2024, at 15:28, Simon Peyton Jones >> wrote: >> >> If you go to https://github.com/ghc-proposals/ghc-proposals/pull/448, >> and click on the "rendered" link, namely >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-type-variable-scoping.rst, >> Github is now displaying the .rst source, not the rendered proposal. >> >> This has started happening (consistently across other proposals) today. >> >> Does anyone know why? How can I fix this? >> >> Simon >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Fri Jan 19 15:07:29 2024 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Fri, 19 Jan 2024 15:07:29 +0000 Subject: GHC proposals not rendering In-Reply-To: References: <44EC7EF7-6B8E-474A-9CC2-D96D6C1507F7@gmail.com> Message-ID: Maybe there's a config parameter that can be changed? It's extremely annoying, and a definite regression. Is there anyone at Github we can ask? Simon On Fri, 19 Jan 2024 at 12:16, Bryan Richter wrote: > I'm guessing GitHub had to limit the size of .rst files that get rendered. > I can imagine the kinds of annoying security or abuse issues they might be > working around... > > The smallest file that doesn't work that I found by clicking around: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst > (42KB) > > The largest that does still work: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0581-namespace-specified-imports.rst > (25KB) > > On Fri, 12 Jan 2024 at 14:49, Simon Peyton Jones < > simon.peytonjones at gmail.com> wrote: > >> But it used to work fine. What has changed? It seems like a pretty >> serious bug! >> >> On Thu, 11 Jan 2024 at 15:38, Rodrigo Mesquita < >> rodrigo.m.mesquita at gmail.com> wrote: >> >>> FWIW, I’m able to render/preview successfully other proposals, but >>> 448-type-variable-scoping loads very slowly and ultimately fails to render >>> for me too. >>> >>> A comment in https://github.com/github/markup/issues/1016 (issue >>> related to .rst not rendering) says that forcing a change in the file >>> triggered a re-render successfully. >>> >>> Rodrigo >>> >>> >>> On 11 Jan 2024, at 15:28, Simon Peyton Jones < >>> simon.peytonjones at gmail.com> wrote: >>> >>> If you go to https://github.com/ghc-proposals/ghc-proposals/pull/448, >>> and click on the "rendered" link, namely >>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-type-variable-scoping.rst, >>> Github is now displaying the .rst source, not the rendered proposal. >>> >>> This has started happening (consistently across other proposals) today. >>> >>> Does anyone know why? How can I fix this? >>> >>> Simon >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> >>> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Fri Jan 19 19:06:35 2024 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 19 Jan 2024 14:06:35 -0500 Subject: GHC proposals not rendering In-Reply-To: References: <44EC7EF7-6B8E-474A-9CC2-D96D6C1507F7@gmail.com> Message-ID: <87wms5xhvq.fsf@smart-cactus.org> Simon Peyton Jones writes: > Maybe there's a config parameter that can be changed? It's extremely > annoying, and a definite regression. Is there anyone at Github we can ask? > If the problem is size then I rather doubt that there is anything that we can do about this beyond open a ticket and hope that someone notices. Indeed this sort of issue is why I have in the past been rather skeptical of relying on external services to host GHC's development. You can only expect to get the service that you pay for; in this case, that is nothing :) However, I am a bit curious as to why Rust's RFCs process has never run into this limitation. Perhaps it only affects RestructuredText? 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 adam at well-typed.com Mon Jan 22 08:16:13 2024 From: adam at well-typed.com (Adam Gundry) Date: Mon, 22 Jan 2024 08:16:13 +0000 Subject: GHC proposals not rendering In-Reply-To: <87wms5xhvq.fsf@smart-cactus.org> References: <44EC7EF7-6B8E-474A-9CC2-D96D6C1507F7@gmail.com> <87wms5xhvq.fsf@smart-cactus.org> Message-ID: I suspect this is a regression specific to reStructuredText rendering, but it's affecting a few different repositories [1] so hopefully Github will fix it at some point. In the meantime, for accepted proposals one can use https://ghc-proposals.readthedocs.io/en/latest/ which Joachim set up some time ago [2]. I'm not sure how frequently it is updated, as it doesn't have the GHC2024 proposal listed. And it sometimes tries to redirect to https://ghc-proposals.haskell.org which apparently doesn't exist. Joachim, do you know the status of this? (Of course, this doesn't help for rendering proposals that have not yet been accepted.) Cheers, Adam [1] https://github.com/orgs/community/discussions/86715 [2] https://mail.haskell.org/pipermail/ghc-devs/2019-May/017632.html On 19/01/2024 19:06, Ben Gamari wrote: > Simon Peyton Jones writes: > >> Maybe there's a config parameter that can be changed? It's extremely >> annoying, and a definite regression. Is there anyone at Github we can ask? >> > If the problem is size then I rather doubt that there is anything that > we can do about this beyond open a ticket and hope that someone notices. > Indeed this sort of issue is why I have in the past been rather > skeptical of relying on external services to host GHC's development. You > can only expect to get the service that you pay for; in this case, that > is nothing :) > > However, I am a bit curious as to why Rust's RFCs process has never run > into this limitation. Perhaps it only affects RestructuredText? > > Cheers, > > - Ben -- 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 mail at joachim-breitner.de Mon Jan 22 09:40:15 2024 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 22 Jan 2024 10:40:15 +0100 Subject: GHC proposals not rendering In-Reply-To: References: <44EC7EF7-6B8E-474A-9CC2-D96D6C1507F7@gmail.com> <87wms5xhvq.fsf@smart-cactus.org> Message-ID: <4773dbaa71a93abd46ae53844c7cbe59a0f3567d.camel@joachim-breitner.de> Hi, Am Montag, dem 22.01.2024 um 08:16 +0000 schrieb Adam Gundry: > In the meantime, for accepted proposals one can use > > https://ghc-proposals.readthedocs.io/en/latest/ > > which Joachim set up some time ago [2]. I'm not sure how frequently it > is updated, as it doesn't have the GHC2024 proposal listed. And it > sometimes tries to redirect to https://ghc-proposals.haskell.org which > apparently doesn't exist. Joachim, do you know the status of this? not sure if that subdomain ever existed, I reconfigured readthedocs to not refer to it. Also, they changed something recently, where I think they did not require a .readthedocs.yaml file and now they do. Let me add a simple one and see if it works again… Hmm, looks like the webhook integration also failed… updated. Ok, is updated again. But note that we never made that official, and more work would be needed to make that good (e.g. show the metadata, include the PR number in the main list), probably requiring some sphinx-python-hacking. And a decent domain. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Mon Jan 22 09:56:10 2024 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 22 Jan 2024 10:56:10 +0100 Subject: GHC proposals not rendering In-Reply-To: References: <44EC7EF7-6B8E-474A-9CC2-D96D6C1507F7@gmail.com> Message-ID: Hi, it’s not simply file size: we have (from wc -c proposals/*|sort -n) 43501 proposals/0380-ghc2021.rst 44051 proposals/0242-unsaturated-type-families.rst but #380 doesn't work but #242 works. I tried some rst linters, but nothing popped up. It could be output size or render time: It loading the file does take a while, as if github tries to render it and then gives up. That’s quite annoying, not sure what to do here now. Cheers, Joachim Am Freitag, dem 19.01.2024 um 14:16 +0200 schrieb Bryan Richter via ghc-devs: > I'm guessing GitHub had to limit the size of .rst files that get rendered. I can imagine the kinds of annoying security or abuse issues they might be working around... > > The smallest file that doesn't work that I found by clicking around: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst (42KB) > > The largest that does still work: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0581-namespace-specified-imports.rst (25KB) > > On Fri, 12 Jan 2024 at 14:49, Simon Peyton Jones wrote: > > But it used to work fine. What has changed?  It seems like a pretty serious bug! > > > > On Thu, 11 Jan 2024 at 15:38, Rodrigo Mesquita wrote: > > > FWIW, I’m able to render/preview successfully other proposals, but 448-type-variable-scoping loads very slowly and ultimately fails to render for me too. > > > > > > A comment in https://github.com/github/markup/issues/1016 (issue related to .rst not rendering) says that forcing a change in the file triggered a re-render successfully. > > > > > > Rodrigo > > > > > > > > > > On 11 Jan 2024, at 15:28, Simon Peyton Jones wrote: > > > > > > > > If you go to https://github.com/ghc-proposals/ghc-proposals/pull/448, and click on the "rendered" link, namely https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-type-variable-scoping.rst, Github is now displaying the .rst source, not the rendered proposal. > > > > > > > > This has started happening (consistently across other proposals) today. > > > > > > > > Does anyone know why?  How can I fix this? > > > > > > > > Simon > > > > _______________________________________________ > > > > ghc-devs mailing list > > > > ghc-devs at haskell.org > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From bryan at haskell.foundation Mon Jan 22 13:22:32 2024 From: bryan at haskell.foundation (Bryan Richter) Date: Mon, 22 Jan 2024 15:22:32 +0200 Subject: GHC proposals not rendering In-Reply-To: References: <44EC7EF7-6B8E-474A-9CC2-D96D6C1507F7@gmail.com> Message-ID: I cataloged all the proposals that fail to render. The others are ok. https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0378-dependent-type-design.rst https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-type-variable-scoping.rst https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0583-hasfield-redesign.rst On Mon, 22 Jan 2024 at 11:56, Joachim Breitner wrote: > Hi, > > it’s not simply file size: we have (from wc -c proposals/*|sort -n) > > 43501 proposals/0380-ghc2021.rst > 44051 proposals/0242-unsaturated-type-families.rst > > but #380 doesn't work but #242 works. > > I tried some rst linters, but nothing popped up. > > It could be output size or render time: It loading the file does take a > while, as if github tries to render it and then gives up. > > That’s quite annoying, not sure what to do here now. > > Cheers, > Joachim > > > Am Freitag, dem 19.01.2024 um 14:16 +0200 schrieb Bryan Richter via > ghc-devs: > > I'm guessing GitHub had to limit the size of .rst files that get > rendered. I can imagine the kinds of annoying security or abuse issues they > might be working around... > > > > The smallest file that doesn't work that I found by clicking around: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst > (42KB) > > > > The largest that does still work: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0581-namespace-specified-imports.rst > (25KB) > > > > On Fri, 12 Jan 2024 at 14:49, Simon Peyton Jones < > simon.peytonjones at gmail.com> wrote: > > > But it used to work fine. What has changed? It seems like a pretty > serious bug! > > > > > > On Thu, 11 Jan 2024 at 15:38, Rodrigo Mesquita < > rodrigo.m.mesquita at gmail.com> wrote: > > > > FWIW, I’m able to render/preview successfully other proposals, but > 448-type-variable-scoping loads very slowly and ultimately fails to render > for me too. > > > > > > > > A comment in https://github.com/github/markup/issues/1016 (issue > related to .rst not rendering) says that forcing a change in the file > triggered a re-render successfully. > > > > > > > > Rodrigo > > > > > > > > > > > > > On 11 Jan 2024, at 15:28, Simon Peyton Jones < > simon.peytonjones at gmail.com> wrote: > > > > > > > > > > If you go to > https://github.com/ghc-proposals/ghc-proposals/pull/448, and click on the > "rendered" link, namely > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-type-variable-scoping.rst, > Github is now displaying the .rst source, not the rendered proposal. > > > > > > > > > > This has started happening (consistently across other proposals) > today. > > > > > > > > > > Does anyone know why? How can I fix this? > > > > > > > > > > Simon > > > > > _______________________________________________ > > > > > ghc-devs mailing list > > > > > ghc-devs at haskell.org > > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > > _______________________________________________ > > > ghc-devs mailing list > > > ghc-devs at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at haskell.foundation Mon Jan 22 13:30:20 2024 From: bryan at haskell.foundation (Bryan Richter) Date: Mon, 22 Jan 2024 15:30:20 +0200 Subject: GHC proposals not rendering In-Reply-To: References: <44EC7EF7-6B8E-474A-9CC2-D96D6C1507F7@gmail.com> Message-ID: This is strongly correlated with filesize. It's the list of the largest files in the repo, except #242 is missing. $ wc -c *.rst --total=never | sort -n | tail -n 7 43501 0380-ghc2021.rst 44051 0242-unsaturated-type-families.rst 55686 0448-type-variable-scoping.rst 56526 0583-hasfield-redesign.rst 56885 0281-visible-forall.rst 71114 0378-dependent-type-design.rst 92654 0111-linear-types.rst So yeah, perhaps it's actually limiting the size of the *output* or something. On Mon, 22 Jan 2024 at 15:22, Bryan Richter wrote: > I cataloged all the proposals that fail to render. The others are ok. > > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0378-dependent-type-design.rst > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-type-variable-scoping.rst > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0583-hasfield-redesign.rst > > > > On Mon, 22 Jan 2024 at 11:56, Joachim Breitner > wrote: > >> Hi, >> >> it’s not simply file size: we have (from wc -c proposals/*|sort -n) >> >> 43501 proposals/0380-ghc2021.rst >> 44051 proposals/0242-unsaturated-type-families.rst >> >> but #380 doesn't work but #242 works. >> >> I tried some rst linters, but nothing popped up. >> >> It could be output size or render time: It loading the file does take a >> while, as if github tries to render it and then gives up. >> >> That’s quite annoying, not sure what to do here now. >> >> Cheers, >> Joachim >> >> >> Am Freitag, dem 19.01.2024 um 14:16 +0200 schrieb Bryan Richter via >> ghc-devs: >> > I'm guessing GitHub had to limit the size of .rst files that get >> rendered. I can imagine the kinds of annoying security or abuse issues they >> might be working around... >> > >> > The smallest file that doesn't work that I found by clicking around: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst >> (42KB) >> > >> > The largest that does still work: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0581-namespace-specified-imports.rst >> (25KB) >> > >> > On Fri, 12 Jan 2024 at 14:49, Simon Peyton Jones < >> simon.peytonjones at gmail.com> wrote: >> > > But it used to work fine. What has changed? It seems like a pretty >> serious bug! >> > > >> > > On Thu, 11 Jan 2024 at 15:38, Rodrigo Mesquita < >> rodrigo.m.mesquita at gmail.com> wrote: >> > > > FWIW, I’m able to render/preview successfully other proposals, but >> 448-type-variable-scoping loads very slowly and ultimately fails to render >> for me too. >> > > > >> > > > A comment in https://github.com/github/markup/issues/1016 (issue >> related to .rst not rendering) says that forcing a change in the file >> triggered a re-render successfully. >> > > > >> > > > Rodrigo >> > > > >> > > > >> > > > > On 11 Jan 2024, at 15:28, Simon Peyton Jones < >> simon.peytonjones at gmail.com> wrote: >> > > > > >> > > > > If you go to >> https://github.com/ghc-proposals/ghc-proposals/pull/448, and click on >> the "rendered" link, namely >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-type-variable-scoping.rst, >> Github is now displaying the .rst source, not the rendered proposal. >> > > > > >> > > > > This has started happening (consistently across other proposals) >> today. >> > > > > >> > > > > Does anyone know why? How can I fix this? >> > > > > >> > > > > Simon >> > > > > _______________________________________________ >> > > > > ghc-devs mailing list >> > > > > ghc-devs at haskell.org >> > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > >> > > _______________________________________________ >> > > ghc-devs mailing list >> > > ghc-devs at haskell.org >> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Mon Jan 22 16:15:13 2024 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 22 Jan 2024 16:15:13 +0000 Subject: GHC proposals not rendering In-Reply-To: References: <44EC7EF7-6B8E-474A-9CC2-D96D6C1507F7@gmail.com> Message-ID: Is there any workaround at all? E.g. a web site where you can give it a URL for a RST file, and it'll typeset the RST for you? Or is it impossible to to typeset RST? Simon On Mon, 22 Jan 2024 at 13:22, Bryan Richter via ghc-devs < ghc-devs at haskell.org> wrote: > I cataloged all the proposals that fail to render. The others are ok. > > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0378-dependent-type-design.rst > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-type-variable-scoping.rst > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0583-hasfield-redesign.rst > > > > On Mon, 22 Jan 2024 at 11:56, Joachim Breitner > wrote: > >> Hi, >> >> it’s not simply file size: we have (from wc -c proposals/*|sort -n) >> >> 43501 proposals/0380-ghc2021.rst >> 44051 proposals/0242-unsaturated-type-families.rst >> >> but #380 doesn't work but #242 works. >> >> I tried some rst linters, but nothing popped up. >> >> It could be output size or render time: It loading the file does take a >> while, as if github tries to render it and then gives up. >> >> That’s quite annoying, not sure what to do here now. >> >> Cheers, >> Joachim >> >> >> Am Freitag, dem 19.01.2024 um 14:16 +0200 schrieb Bryan Richter via >> ghc-devs: >> > I'm guessing GitHub had to limit the size of .rst files that get >> rendered. I can imagine the kinds of annoying security or abuse issues they >> might be working around... >> > >> > The smallest file that doesn't work that I found by clicking around: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst >> (42KB) >> > >> > The largest that does still work: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0581-namespace-specified-imports.rst >> (25KB) >> > >> > On Fri, 12 Jan 2024 at 14:49, Simon Peyton Jones < >> simon.peytonjones at gmail.com> wrote: >> > > But it used to work fine. What has changed? It seems like a pretty >> serious bug! >> > > >> > > On Thu, 11 Jan 2024 at 15:38, Rodrigo Mesquita < >> rodrigo.m.mesquita at gmail.com> wrote: >> > > > FWIW, I’m able to render/preview successfully other proposals, but >> 448-type-variable-scoping loads very slowly and ultimately fails to render >> for me too. >> > > > >> > > > A comment in https://github.com/github/markup/issues/1016 (issue >> related to .rst not rendering) says that forcing a change in the file >> triggered a re-render successfully. >> > > > >> > > > Rodrigo >> > > > >> > > > >> > > > > On 11 Jan 2024, at 15:28, Simon Peyton Jones < >> simon.peytonjones at gmail.com> wrote: >> > > > > >> > > > > If you go to >> https://github.com/ghc-proposals/ghc-proposals/pull/448, and click on >> the "rendered" link, namely >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-type-variable-scoping.rst, >> Github is now displaying the .rst source, not the rendered proposal. >> > > > > >> > > > > This has started happening (consistently across other proposals) >> today. >> > > > > >> > > > > Does anyone know why? How can I fix this? >> > > > > >> > > > > Simon >> > > > > _______________________________________________ >> > > > > ghc-devs mailing list >> > > > > ghc-devs at haskell.org >> > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > >> > > _______________________________________________ >> > > ghc-devs mailing list >> > > ghc-devs at haskell.org >> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Mon Jan 22 20:48:44 2024 From: adam at well-typed.com (Adam Gundry) Date: Mon, 22 Jan 2024 20:48:44 +0000 Subject: GHC proposals not rendering In-Reply-To: References: <44EC7EF7-6B8E-474A-9CC2-D96D6C1507F7@gmail.com> Message-ID: <722a83e5-28f2-4d74-967d-a68236809ec2@well-typed.com> On 22/01/2024 16:15, Simon Peyton Jones wrote: > Is there any workaround at all?   E.g. a web site where you can give it > a URL for a RST file,  and it'll typeset the RST for you?  Or is it > impossible to to typeset RST? I tend to use pandoc to preview RST files locally. There are also a few websites that allow you to enter RST content directly and see a live preview (e.g. https://snippets.documatt.com/). They may not exactly line up with how GitHub renders things, of course, and I don't know of any that let you feed in a URL to an RST file hosted elsewhere. Adam > On Mon, 22 Jan 2024 at 13:22, Bryan Richter via ghc-devs > > wrote: > > I cataloged all the proposals that fail to render. The others are ok. > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0378-dependent-type-design.rst > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-type-variable-scoping.rst > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0583-hasfield-redesign.rst > > > > On Mon, 22 Jan 2024 at 11:56, Joachim Breitner > > wrote: > > Hi, > > it’s not simply file size: we have (from wc -c proposals/*|sort -n) > >   43501 proposals/0380-ghc2021.rst >   44051 proposals/0242-unsaturated-type-families.rst > > but #380 doesn't work but #242 works. > > I tried some rst linters, but nothing popped up. > > It could be output size or render time: It loading the file does > take a > while, as if github tries to render it and then gives up. > > That’s quite annoying, not sure what to do here now. > > Cheers, > Joachim > > > Am Freitag, dem 19.01.2024 um 14:16 +0200 schrieb Bryan Richter via > ghc-devs: > > I'm guessing GitHub had to limit the size of .rst files that > get rendered. I can imagine the kinds of annoying security or > abuse issues they might be working around... > > > > The smallest file that doesn't work that I found by clicking > around: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-ghc2021.rst (42KB) > > > > The largest that does still work: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0581-namespace-specified-imports.rst (25KB) > > > > On Fri, 12 Jan 2024 at 14:49, Simon Peyton Jones > > wrote: > > > But it used to work fine. What has changed?  It seems like > a pretty serious bug! > > > > > > On Thu, 11 Jan 2024 at 15:38, Rodrigo Mesquita > > wrote: > > > > FWIW, I’m able to render/preview successfully other > proposals, but 448-type-variable-scoping loads very slowly and > ultimately fails to render for me too. > > > > > > > > A comment in https://github.com/github/markup/issues/1016 >  (issue related to > .rst not rendering) says that forcing a change in the file > triggered a re-render successfully. > > > > > > > > Rodrigo > > > > > > > > > > > > > On 11 Jan 2024, at 15:28, Simon Peyton Jones > > wrote: > > > > > > > > > > If you go to > https://github.com/ghc-proposals/ghc-proposals/pull/448 > , and > click on the "rendered" link, namely > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-type-variable-scoping.rst , Github is now displaying the .rst source, not the rendered proposal. > > > > > > > > > > This has started happening (consistently across other > proposals) today. > > > > > > > > > > Does anyone know why?  How can I fix this? > > > > > > > > > > Simon -- 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 ben at smart-cactus.org Tue Jan 23 01:30:47 2024 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 22 Jan 2024 20:30:47 -0500 Subject: GHC proposals not rendering In-Reply-To: <722a83e5-28f2-4d74-967d-a68236809ec2@well-typed.com> References: <44EC7EF7-6B8E-474A-9CC2-D96D6C1507F7@gmail.com> <722a83e5-28f2-4d74-967d-a68236809ec2@well-typed.com> Message-ID: <87y1cgzvi3.fsf@smart-cactus.org> Adam Gundry writes: > On 22/01/2024 16:15, Simon Peyton Jones wrote: >> Is there any workaround at all?   E.g. a web site where you can give it >> a URL for a RST file,  and it'll typeset the RST for you?  Or is it >> impossible to to typeset RST? > > I tend to use pandoc to preview RST files locally. There are also a few > websites that allow you to enter RST content directly and see a live > preview (e.g. https://snippets.documatt.com/). They may not exactly line > up with how GitHub renders things, of course, and I don't know of any > that let you feed in a URL to an RST file hosted elsewhere. > As noted during the SWG meeting today, I suspect that the easiest way forward here may be to just render PRs via CI. However, I don't know how easy it is to preserve artifacts such that they are viewable using GitHub Actions. Jose will have a quick look at this. 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 bryan at haskell.foundation Tue Jan 23 06:12:43 2024 From: bryan at haskell.foundation (Bryan Richter) Date: Tue, 23 Jan 2024 08:12:43 +0200 Subject: GHC proposals not rendering In-Reply-To: <87y1cgzvi3.fsf@smart-cactus.org> References: <44EC7EF7-6B8E-474A-9CC2-D96D6C1507F7@gmail.com> <722a83e5-28f2-4d74-967d-a68236809ec2@well-typed.com> <87y1cgzvi3.fsf@smart-cactus.org> Message-ID: One really hacky solution that might work would just be to split a proposal across two files. On Tue, 23 Jan 2024 at 03:31, Ben Gamari wrote: > Adam Gundry writes: > > > On 22/01/2024 16:15, Simon Peyton Jones wrote: > >> Is there any workaround at all? E.g. a web site where you can give it > >> a URL for a RST file, and it'll typeset the RST for you? Or is it > >> impossible to to typeset RST? > > > > I tend to use pandoc to preview RST files locally. There are also a few > > websites that allow you to enter RST content directly and see a live > > preview (e.g. https://snippets.documatt.com/). They may not exactly > line > > up with how GitHub renders things, of course, and I don't know of any > > that let you feed in a URL to an RST file hosted elsewhere. > > > As noted during the SWG meeting today, I suspect that the easiest way > forward here may be to just render PRs via CI. However, I don't know how > easy it is to preserve artifacts such that they are viewable using > GitHub Actions. Jose will have a quick look at this. > > Cheers, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Tue Jan 23 08:36:38 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 23 Jan 2024 08:36:38 +0000 Subject: GHC proposals not rendering In-Reply-To: <87y1cgzvi3.fsf@smart-cactus.org> References: <44EC7EF7-6B8E-474A-9CC2-D96D6C1507F7@gmail.com> <722a83e5-28f2-4d74-967d-a68236809ec2@well-typed.com> <87y1cgzvi3.fsf@smart-cactus.org> Message-ID: On Mon, Jan 22, 2024 at 08:30:47PM -0500, Ben Gamari wrote: > > On 22/01/2024 16:15, Simon Peyton Jones wrote: > >> Is there any workaround at all?   E.g. a web site where you can give it > >> a URL for a RST file,  and it'll typeset the RST for you?  Or is it > >> impossible to to typeset RST? > > > > I tend to use pandoc to preview RST files locally. There are also a few > > websites that allow you to enter RST content directly and see a live > > preview (e.g. https://snippets.documatt.com/). They may not exactly line > > up with how GitHub renders things, of course, and I don't know of any > > that let you feed in a URL to an RST file hosted elsewhere. > > > As noted during the SWG meeting today, I suspect that the easiest way > forward here may be to just render PRs via CI. However, I don't know how > easy it is to preserve artifacts such that they are viewable using > GitHub Actions. Jose will have a quick look at this. Perhaps the artifacts could be deployed as Github Pages. But in the first instance I like Bryan's suggestion of just splitting the documents into small-enough pieces. From me at michaelpj.com Tue Jan 23 10:16:33 2024 From: me at michaelpj.com (Michael Peyton Jones) Date: Tue, 23 Jan 2024 10:16:33 +0000 Subject: GHC proposals not rendering In-Reply-To: References: <44EC7EF7-6B8E-474A-9CC2-D96D6C1507F7@gmail.com> <722a83e5-28f2-4d74-967d-a68236809ec2@well-typed.com> <87y1cgzvi3.fsf@smart-cactus.org> Message-ID: If you got the readthedocs site working, that does provide per-PR previews of the built documentation relatively easily. M On Tue, Jan 23, 2024 at 8:37 AM Tom Ellis < tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk> wrote: > On Mon, Jan 22, 2024 at 08:30:47PM -0500, Ben Gamari wrote: > > > On 22/01/2024 16:15, Simon Peyton Jones wrote: > > >> Is there any workaround at all? E.g. a web site where you can give > it > > >> a URL for a RST file, and it'll typeset the RST for you? Or is it > > >> impossible to to typeset RST? > > > > > > I tend to use pandoc to preview RST files locally. There are also a > few > > > websites that allow you to enter RST content directly and see a live > > > preview (e.g. https://snippets.documatt.com/). They may not exactly > line > > > up with how GitHub renders things, of course, and I don't know of any > > > that let you feed in a URL to an RST file hosted elsewhere. > > > > > As noted during the SWG meeting today, I suspect that the easiest way > > forward here may be to just render PRs via CI. However, I don't know how > > easy it is to preserve artifacts such that they are viewable using > > GitHub Actions. Jose will have a quick look at this. > > Perhaps the artifacts could be deployed as Github Pages. But in the > first instance I like Bryan's suggestion of just splitting the > documents into small-enough pieces. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Tue Jan 23 14:20:25 2024 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 23 Jan 2024 14:20:25 +0000 Subject: GHC Weekly call Message-ID: Dear GHC developers Every week (2pm London time, Tuesdays) we hold a call for people to share what they are working on GHC-land. Would you like to come? The call is open to *any member of the GHC Team. *And *the GHC Team is inclusive*: if you are working on GHC you are a member of the Team: see here for details . Why come? - It gives you a window into what is happening in GHC land - It gives you a chance to influence what is happening - It builds community -- you get face-to-face contact with others working on GHC If you'd like to come, drop a line to Matthew Pickering matthew at well-typed.com See you there! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Tue Jan 23 21:22:13 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 23 Jan 2024 21:22:13 +0000 Subject: Help needed with optimization Message-ID: Hello GHC devs, I'm trying to understand why my code is not being optimized in the way I would expect. I'm completely stuck and I think I need the advice of an expert. I'm writing an effect system on top of transformers. The effect system wraps monad transformers in a newtype that encodes the composition structure of the transformers at the type level. Because it's a newtype all of the class members are inherited directly from the underlying type using coerce. When I implement something using this effect system I would expect to generate exactly the same code as if I had written it using transformers directly. However, it generates significantly worse code, even in a very simple case. Firstly, a case where I do get the same code. All of these compile to the constant 1. Hooray! https://github.com/tomjaguarpaw/ad/blob/cd0d876ddb448fe611515e8768dee66dc02ed650/Eff-Optimize/Main.hs#L26-L54 Secondly, a simple cases where I do not get the same code. `mySumMTL` and `mySumNewtype` yield the same code, as expected. After all, `mySumNewtype` does exactly the same thing as `mySumMTL`, it's just wrapped in some newtypes. However, `mySumEff` yields worse code, despite *also* being the same thing as `mySumMTL` just wrapped in some newtypes. https://github.com/tomjaguarpaw/ad/blob/cd0d876ddb448fe611515e8768dee66dc02ed650/Eff-Optimize/Main.hs#L62-L94 You can compare the generated loops at: https://github.com/tomjaguarpaw/ad/blob/cd0d876ddb448fe611515e8768dee66dc02ed650/Eff-Optimize/optimizer-output.md Does anyone have a clue what's going wrong in the optimizer here? I don't think the singleton that I pass around to access the type level index at runtime has anything to do with it. That seems to be optimized away by inlining. Is the simplifier confused by all the coercions? Thanks for any help anyone may be able to shed, Tom From mail at joachim-breitner.de Tue Jan 23 21:36:29 2024 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 23 Jan 2024 22:36:29 +0100 Subject: GHC proposals not rendering In-Reply-To: References: <44EC7EF7-6B8E-474A-9CC2-D96D6C1507F7@gmail.com> <722a83e5-28f2-4d74-967d-a68236809ec2@well-typed.com> <87y1cgzvi3.fsf@smart-cactus.org> Message-ID: Hi, yes, I enabled that PR preview feature yesterday, but it seems that I also have to grand permissions to their OAuth App to the ghc-proposals github org … done. Hmm, now every PR that isn’t based on a recent master is red, because it lacks the configuration. Also not nice. Maybe I should disable this again? At least until the readthedocs setup and output is satisfying (numbering etc. – any volunteers?) Cheers, Joachim Am Dienstag, dem 23.01.2024 um 10:16 +0000 schrieb Michael Peyton Jones: > > If you got the readthedocs site working, that does provide per-PR previews of the built documentation relatively easily. > > > > M > > > > On Tue, Jan 23, 2024 at 8:37 AM Tom Ellis wrote: > > > > On Mon, Jan 22, 2024 at 08:30:47PM -0500, Ben Gamari wrote: > > > > > > > > On 22/01/2024 16:15, Simon Peyton Jones wrote: > > > > > > > > > > Is there any workaround at all?   E.g. a web site where you can give it > > > > > > > > > > a URL for a RST file,  and it'll typeset the RST for you?  Or is it > > > > > > > > > > impossible to to typeset RST? > > > > > > > > > > > > > > > > I tend to use pandoc to preview RST files locally. There are also a few > > > > > > > > websites that allow you to enter RST content directly and see a live > > > > > > > > preview (e.g. https://snippets.documatt.com/). They may not exactly line > > > > > > > > up with how GitHub renders things, of course, and I don't know of any > > > > > > > > that let you feed in a URL to an RST file hosted elsewhere. > > > > > > > > > > > > > > As noted during the SWG meeting today, I suspect that the easiest way > > > > > > forward here may be to just render PRs via CI. However, I don't know how > > > > > > easy it is to preserve artifacts such that they are viewable using > > > > > > GitHub Actions. Jose will have a quick look at this. > > > > > > > > Perhaps the artifacts could be deployed as Github Pages.  But in the > > > > first instance I like Bryan's suggestion of just splitting the > > > > documents into small-enough pieces. > > > > _______________________________________________ > > > > ghc-devs mailing list > > > > ghc-devs at haskell.org > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simon.peytonjones at gmail.com Tue Jan 23 22:50:15 2024 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 23 Jan 2024 22:50:15 +0000 Subject: Help needed with optimization In-Reply-To: References: Message-ID: Tom Ha! I could not resist having a look. See https://gitlab.haskell.org/ghc/ghc/-/issues/24371 Simon On Tue, 23 Jan 2024 at 21:22, Tom Ellis < tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk> wrote: > Hello GHC devs, > > I'm trying to understand why my code is not being optimized in the way > I would expect. I'm completely stuck and I think I need the advice of > an expert. > > I'm writing an effect system on top of transformers. The effect > system wraps monad transformers in a newtype that encodes the > composition structure of the transformers at the type level. Because > it's a newtype all of the class members are inherited directly from > the underlying type using coerce. When I implement something using > this effect system I would expect to generate exactly the same code as > if I had written it using transformers directly. However, it > generates significantly worse code, even in a very simple case. > > Firstly, a case where I do get the same code. All of these compile to > the constant 1. Hooray! > > > https://github.com/tomjaguarpaw/ad/blob/cd0d876ddb448fe611515e8768dee66dc02ed650/Eff-Optimize/Main.hs#L26-L54 > > Secondly, a simple cases where I do not get the same code. `mySumMTL` > and `mySumNewtype` yield the same code, as expected. After all, > `mySumNewtype` does exactly the same thing as `mySumMTL`, it's just > wrapped in some newtypes. However, `mySumEff` yields worse code, > despite *also* being the same thing as `mySumMTL` just wrapped in some > newtypes. > > > https://github.com/tomjaguarpaw/ad/blob/cd0d876ddb448fe611515e8768dee66dc02ed650/Eff-Optimize/Main.hs#L62-L94 > > You can compare the generated loops at: > > > https://github.com/tomjaguarpaw/ad/blob/cd0d876ddb448fe611515e8768dee66dc02ed650/Eff-Optimize/optimizer-output.md > > Does anyone have a clue what's going wrong in the optimizer here? I > don't think the singleton that I pass around to access the type level > index at runtime has anything to do with it. That seems to be > optimized away by inlining. Is the simplifier confused by all the > coercions? > > Thanks for any help anyone may be able to shed, > > Tom > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaronallen8455 at gmail.com Wed Jan 24 02:44:09 2024 From: aaronallen8455 at gmail.com (Aaron Allen) Date: Tue, 23 Jan 2024 20:44:09 -0600 Subject: Google Summer of Code Ideas Message-ID: Hello, Haskell will be applying for the Google Summer of Code 2024 program and it would be great to have some project ideas involving GHC. If anything comes to mind, you can submit an idea proposal using the instructions found here: https://summer.haskell.org/ideas.html. Kind Regards, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Wed Jan 24 08:21:55 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 24 Jan 2024 08:21:55 +0000 Subject: Help needed with optimization In-Reply-To: References: Message-ID: Thanks Simon. I'll reply on the ticket. On Tue, Jan 23, 2024 at 10:50:15PM +0000, Simon Peyton Jones wrote: > Ha! I could not resist having a look. See > https://gitlab.haskell.org/ghc/ghc/-/issues/24371 > > On Tue, 23 Jan 2024 at 21:22, Tom Ellis wrote: > > > I'm trying to understand why my code is not being optimized in the way > > I would expect. I'm completely stuck and I think I need the advice of > > an expert. > > > > I'm writing an effect system on top of transformers. The effect > > system wraps monad transformers in a newtype that encodes the > > composition structure of the transformers at the type level. Because > > it's a newtype all of the class members are inherited directly from > > the underlying type using coerce. When I implement something using > > this effect system I would expect to generate exactly the same code as > > if I had written it using transformers directly. However, it > > generates significantly worse code, even in a very simple case. > > > > Firstly, a case where I do get the same code. All of these compile to > > the constant 1. Hooray! > > > > > > https://github.com/tomjaguarpaw/ad/blob/cd0d876ddb448fe611515e8768dee66dc02ed650/Eff-Optimize/Main.hs#L26-L54 > > > > Secondly, a simple cases where I do not get the same code. `mySumMTL` > > and `mySumNewtype` yield the same code, as expected. After all, > > `mySumNewtype` does exactly the same thing as `mySumMTL`, it's just > > wrapped in some newtypes. However, `mySumEff` yields worse code, > > despite *also* being the same thing as `mySumMTL` just wrapped in some > > newtypes. > > > > > > https://github.com/tomjaguarpaw/ad/blob/cd0d876ddb448fe611515e8768dee66dc02ed650/Eff-Optimize/Main.hs#L62-L94 > > > > You can compare the generated loops at: > > > > > > https://github.com/tomjaguarpaw/ad/blob/cd0d876ddb448fe611515e8768dee66dc02ed650/Eff-Optimize/optimizer-output.md > > > > Does anyone have a clue what's going wrong in the optimizer here? I > > don't think the singleton that I pass around to access the type level > > index at runtime has anything to do with it. That seems to be > > optimized away by inlining. Is the simplifier confused by all the > > coercions? > > > > Thanks for any help anyone may be able to shed, From ben at well-typed.com Thu Jan 25 21:31:49 2024 From: ben at well-typed.com (Ben Gamari) Date: Thu, 25 Jan 2024 16:31:49 -0500 Subject: GHC 9.10 release Message-ID: <87msstrtfh.fsf@smart-cactus.org> Hi all, I am currently in the midst of planning the GHC 9.10 release [1], which we hope to fork on 23 Feb 2024. If you have a major patch that you would like to see included in 9.10, please be in touch. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/milestones/380 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From vladislav at serokell.io Thu Jan 25 22:33:13 2024 From: vladislav at serokell.io (Vladislav Zavialov) Date: Thu, 25 Jan 2024 23:33:13 +0100 Subject: GHC 9.10 release In-Reply-To: <87msstrtfh.fsf@smart-cactus.org> References: <87msstrtfh.fsf@smart-cactus.org> Message-ID: Let's try to land https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8820 by Torsten Schmits if possible. Vlad On Thu, Jan 25, 2024 at 10:32 PM Ben Gamari wrote: > > Hi all, > > I am currently in the midst of planning the GHC 9.10 release [1], which > we hope to fork on 23 Feb 2024. If you have a major patch that you would > like to see included in 9.10, please be in touch. > > Cheers, > > - Ben > > > [1] https://gitlab.haskell.org/ghc/ghc/-/milestones/380 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From sylvain at haskus.fr Fri Jan 26 09:55:05 2024 From: sylvain at haskus.fr (Sylvain Henry) Date: Fri, 26 Jan 2024 10:55:05 +0100 Subject: GHC 9.10 release In-Reply-To: <87msstrtfh.fsf@smart-cactus.org> References: <87msstrtfh.fsf@smart-cactus.org> Message-ID: I'd like the support for C sources with the JS backend to be included too: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11502 I've added it to the items on the milestone page. Cheers, Sylvain On 25/01/2024 22:31, Ben Gamari wrote: > Hi all, > > I am currently in the midst of planning the GHC 9.10 release [1], which > we hope to fork on 23 Feb 2024. If you have a major patch that you would > like to see included in 9.10, please be in touch. > > Cheers, > > - Ben > > > [1] https://gitlab.haskell.org/ghc/ghc/-/milestones/380 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From sam.derbyshire at gmail.com Fri Jan 26 10:21:18 2024 From: sam.derbyshire at gmail.com (Sam Derbyshire) Date: Fri, 26 Jan 2024 11:21:18 +0100 Subject: GHC 9.10 release In-Reply-To: <87msstrtfh.fsf@smart-cactus.org> References: <87msstrtfh.fsf@smart-cactus.org> Message-ID: I think we should make sure that !10140 lands for 9.10. -------------- next part -------------- An HTML attachment was scrubbed... URL: From facundo.dominguez at tweag.io Fri Jan 26 12:28:52 2024 From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=) Date: Fri, 26 Jan 2024 09:28:52 -0300 Subject: How to disable the simple optimizer Message-ID: Dear devs, I noticed that GHC sometimes inlines bindings during desugaring, e.g foo = z where z = z1 + z2 z1 = 42 z2 = 1 is desugared to foo = 42 + 1 This inlining is problematic when using a plugin like Liquid Haskell, which wants to analyse in Core the local bindings provided by the user. Until ghc-9.6 LH didn't experience the inlining when using the GHC API. And this is despite the fact that using ghc from the command line would seem to always inline during desugaring, even when using -O0. When using ghc-9.8.1 though, even the output of the GHC API started having the bindings inlined. Some debugging with -ddump-ds and -ddump-ds-preopt shows that inlining must be happening in the simple optimizer. Is there anything one could do to disable the optimizations? Thanks in advance, Facundo -- All views and opinions expressed in this email message are the personal opinions of the author and do not represent those of the organization or its customers. From eric at seidel.io Fri Jan 26 13:05:53 2024 From: eric at seidel.io (Eric Seidel) Date: Fri, 26 Jan 2024 07:05:53 -0600 Subject: How to disable the simple optimizer In-Reply-To: References: Message-ID: <9EE5EAEA-1EE3-4BDC-BD84-D560AA447FF2@seidel.io> I have not been involved in the development of LiquidHaskell for a long time, but this was a problem back when I was involved as well. Back then we installed a custom desugarer that did not inline simple bindings. But I don’t think that approach would work in a plugin setting. Sent from my iPhone > On Jan 26, 2024, at 06:29, Facundo Domínguez wrote: > > Dear devs, > > I noticed that GHC sometimes inlines bindings during desugaring, e.g > > foo = z > where > z = z1 + z2 > z1 = 42 > z2 = 1 > > is desugared to > > foo = 42 + 1 > > This inlining is problematic when using a plugin like Liquid Haskell, > which wants to analyse in Core the local bindings provided by the > user. > > Until ghc-9.6 LH didn't experience the inlining when using the GHC > API. And this is despite the fact that using ghc from the command > line would seem to always inline during desugaring, even when using > -O0. > > When using ghc-9.8.1 though, even the output of the GHC API started > having the bindings inlined. Some debugging with -ddump-ds and > -ddump-ds-preopt shows that inlining must be happening in the simple > optimizer. > > Is there anything one could do to disable the optimizations? > > Thanks in advance, > Facundo > > -- > All views and opinions expressed in this email message are the > personal opinions of the author and do not represent those of the > organization or its customers. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simon.peytonjones at gmail.com Fri Jan 26 13:10:53 2024 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Fri, 26 Jan 2024 13:10:53 +0000 Subject: How to disable the simple optimizer In-Reply-To: References: Message-ID: Hi Facundo Currently there is no way to disable the simple optimiser, but it would be easy to add a flag to do so. I'm not sure if that is really what you want -- you'll be left with a program with a lot of "junk" like (let x = y in ...). But maybe LH doesn't mind the junk! If you decide that is what you want, I'm sure we (or you) can add a flag to control it. The relevant code is in GHC.HsToCore, below Before you go much further, do open a ticket. Simon I think this the code you want to disable with a flag: ; let simpl_opts = initSimpleOpts dflags ; let (ds_binds, ds_rules_for_imps, occ_anald_binds) = simpleOptPgm simpl_opts mod final_pgm rules_for_imps -- The simpleOptPgm gets rid of type -- bindings plus any stupid dead code ; putDumpFileMaybe logger Opt_D_dump_occur_anal "Occurrence analysis" FormatCore (pprCoreBindings occ_anald_binds $$ pprRules ds_rules_for_imps ) ; endPassHscEnvIO hsc_env name_ppr_ctx CoreDesugarOpt ds_binds ds_rules_for_imps On Fri, 26 Jan 2024 at 12:29, Facundo Domínguez wrote: > Dear devs, > > I noticed that GHC sometimes inlines bindings during desugaring, e.g > > foo = z > where > z = z1 + z2 > z1 = 42 > z2 = 1 > > is desugared to > > foo = 42 + 1 > > This inlining is problematic when using a plugin like Liquid Haskell, > which wants to analyse in Core the local bindings provided by the > user. > > Until ghc-9.6 LH didn't experience the inlining when using the GHC > API. And this is despite the fact that using ghc from the command > line would seem to always inline during desugaring, even when using > -O0. > > When using ghc-9.8.1 though, even the output of the GHC API started > having the bindings inlined. Some debugging with -ddump-ds and > -ddump-ds-preopt shows that inlining must be happening in the simple > optimizer. > > Is there anything one could do to disable the optimizations? > > Thanks in advance, > Facundo > > -- > All views and opinions expressed in this email message are the > personal opinions of the author and do not represent those of the > organization or its customers. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From facundo.dominguez at tweag.io Fri Jan 26 14:30:48 2024 From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=) Date: Fri, 26 Jan 2024 11:30:48 -0300 Subject: How to disable the simple optimizer In-Reply-To: References: Message-ID: > Back then we installed a custom desugarer that did not inline simple bindings. Ah, it is interesting how the problems repeat. I think I could compose a custom desugarer by copying bits of the GHC API as a workaround. > Before you go much further, do open a ticket. Thanks Simon. I created a ticket now [1]. Facundo [1] https://gitlab.haskell.org/ghc/ghc/-/issues/24386 On Fri, Jan 26, 2024 at 10:11 AM Simon Peyton Jones wrote: > > Hi Facundo > > Currently there is no way to disable the simple optimiser, but it would be easy to add a flag to do so. > > I'm not sure if that is really what you want -- you'll be left with a program with a lot of "junk" like (let x = y in ...). But maybe LH doesn't mind the junk! > > If you decide that is what you want, I'm sure we (or you) can add a flag to control it. The relevant code is in GHC.HsToCore, below > > Before you go much further, do open a ticket. > > Simon > > I think this the code you want to disable with a flag: > > ; let simpl_opts = initSimpleOpts dflags > ; let (ds_binds, ds_rules_for_imps, occ_anald_binds) > = simpleOptPgm simpl_opts mod final_pgm rules_for_imps > -- The simpleOptPgm gets rid of type > -- bindings plus any stupid dead code > ; putDumpFileMaybe logger Opt_D_dump_occur_anal "Occurrence analysis" > FormatCore (pprCoreBindings occ_anald_binds $$ pprRules ds_rules_for_imps ) > > ; endPassHscEnvIO hsc_env name_ppr_ctx CoreDesugarOpt ds_binds ds_rules_for_imps > > On Fri, 26 Jan 2024 at 12:29, Facundo Domínguez wrote: >> >> Dear devs, >> >> I noticed that GHC sometimes inlines bindings during desugaring, e.g >> >> foo = z >> where >> z = z1 + z2 >> z1 = 42 >> z2 = 1 >> >> is desugared to >> >> foo = 42 + 1 >> >> This inlining is problematic when using a plugin like Liquid Haskell, >> which wants to analyse in Core the local bindings provided by the >> user. >> >> Until ghc-9.6 LH didn't experience the inlining when using the GHC >> API. And this is despite the fact that using ghc from the command >> line would seem to always inline during desugaring, even when using >> -O0. >> >> When using ghc-9.8.1 though, even the output of the GHC API started >> having the bindings inlined. Some debugging with -ddump-ds and >> -ddump-ds-preopt shows that inlining must be happening in the simple >> optimizer. >> >> Is there anything one could do to disable the optimizations? >> >> Thanks in advance, >> Facundo >> >> -- >> All views and opinions expressed in this email message are the >> personal opinions of the author and do not represent those of the >> organization or its customers. >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- All views and opinions expressed in this email message are the personal opinions of the author and do not represent those of the organization or its customers. From adam at well-typed.com Fri Jan 26 20:57:25 2024 From: adam at well-typed.com (Adam Gundry) Date: Fri, 26 Jan 2024 20:57:25 +0000 Subject: GHC 9.10 release In-Reply-To: <87msstrtfh.fsf@smart-cactus.org> References: <87msstrtfh.fsf@smart-cactus.org> Message-ID: <725a994c-6bb6-4bc2-b247-7433e0d7eea0@well-typed.com> I think we should make sure to include GHC2024 (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11882). A question has arisen about whether it should be on by default, though. Anyone who has an opinion on the question, please do comment on https://github.com/ghc-proposals/ghc-proposals/pull/632 which seeks to resolve this. Cheers, Adam On 25/01/2024 21:31, Ben Gamari wrote: > Hi all, > > I am currently in the midst of planning the GHC 9.10 release [1], which > we hope to fork on 23 Feb 2024. If you have a major patch that you would > like to see included in 9.10, please be in touch. > > Cheers, > > - Ben > > > [1] https://gitlab.haskell.org/ghc/ghc/-/milestones/380 -- 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 adam at well-typed.com Sun Jan 28 09:58:45 2024 From: adam at well-typed.com (Adam Gundry) Date: Sun, 28 Jan 2024 09:58:45 +0000 Subject: GHC Steering Committee Call for Nominations Message-ID: Dear Haskellers, The GHC Steering Committee is seeking nominations for new members. The committee scrutinizes, debates and eventually decides to accept or reject proposals to change the language or major features supported by GHC. Our processes are described in the GitHub repository where proposals are submitted (https://github.com/ghc-proposals/ghc-proposals). In particular, please have a look at the committee bylaws (https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst). We are looking for members who have the ability to: - understand GHC proposals (e.g. for new language extensions), - find holes and missing corner cases in the specifications, - foresee the interaction with other language or compiler features, - comment constructively and improve proposals through engagement with others, - judge the cost/benefit ratio of changes, and - come to a justifiable conclusion. Ideally, committee members should: - have substantial experience of writing or teaching Haskell; - have a track record of active contributions to the Haskell community; or - have expertise in language design and implementation, in either Haskell or related languages. It is our aim that this committee be diverse; by representing different viewpoints, we will make decisions that benefit larger segments of our community. Even if you are uncertain whether your background qualifies you for the role, you are warmly encouraged to apply. The committee's work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. To nominate yourself, please send an email to me (as the committee secretary) at adam at well-typed.com by February 16th 2024, briefly summarising your background and relevant experience. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. Self-nominations are the norm. You can nominate someone else, but please obtain their explicit consent to do so. (We don't want to choose someone who turns out to be unable to serve.) On behalf of the committee, Adam Gundry -- 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 dsf at seereason.com Sun Jan 28 16:34:13 2024 From: dsf at seereason.com (David Fox) Date: Sun, 28 Jan 2024 08:34:13 -0800 Subject: GHC 9.10 release In-Reply-To: References: <87msstrtfh.fsf@smart-cactus.org> Message-ID: I see the javascript optimiser is also on the milestone page - is this the proposed merge? https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11507 On Fri, Jan 26, 2024 at 1:55 AM Sylvain Henry wrote: > I'd like the support for C sources with the JS backend to be included > too: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11502 > > I've added it to the items on the milestone page. > > Cheers, > Sylvain > > > On 25/01/2024 22:31, Ben Gamari wrote: > > Hi all, > > > > I am currently in the midst of planning the GHC 9.10 release [1], which > > we hope to fork on 23 Feb 2024. If you have a major patch that you would > > like to see included in 9.10, please be in touch. > > > > Cheers, > > > > - Ben > > > > > > [1] https://gitlab.haskell.org/ghc/ghc/-/milestones/380 > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stegeman at gmail.com Sun Jan 28 16:39:39 2024 From: stegeman at gmail.com (Luite Stegeman) Date: Sun, 28 Jan 2024 17:39:39 +0100 Subject: GHC 9.10 release In-Reply-To: References: <87msstrtfh.fsf@smart-cactus.org> Message-ID: Yes, I'm updating that to add some tests and cleanup. Should be ready soon. On Sun, Jan 28, 2024 at 5:34 PM David Fox wrote: > > I see the javascript optimiser is also on the milestone page - is this the proposed merge? https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11507 > > On Fri, Jan 26, 2024 at 1:55 AM Sylvain Henry wrote: >> >> I'd like the support for C sources with the JS backend to be included >> too: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11502 >> >> I've added it to the items on the milestone page. >> >> Cheers, >> Sylvain >> >> >> On 25/01/2024 22:31, Ben Gamari wrote: >> > Hi all, >> > >> > I am currently in the midst of planning the GHC 9.10 release [1], which >> > we hope to fork on 23 Feb 2024. If you have a major patch that you would >> > like to see included in 9.10, please be in touch. >> > >> > Cheers, >> > >> > - Ben >> > >> > >> > [1] https://gitlab.haskell.org/ghc/ghc/-/milestones/380 >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From zubin at well-typed.com Mon Jan 29 07:39:38 2024 From: zubin at well-typed.com (Zubin Duggal) Date: Mon, 29 Jan 2024 13:09:38 +0530 Subject: Upcoming GHC 9.8.2 release Message-ID: Hello all, We are currently in the process of preparing the 9.8.2 release, which should be released mid-February. If you would like any patches to be considered for inclusion into this release, please ensure that the corresponding MRs are marked with the ~"backport needed:9.8" label. Any submodule bumps that have made it into previous releases like 9.6.4 will also be backported to 9.8.2. Requests for additional submodule updates should be made on the release tracking ticket: https://gitlab.haskell.org/ghc/ghc/-/issues/24079 Cheers, Zubin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: