From gergo at erdi.hu Thu Nov 3 09:46:42 2022 From: gergo at erdi.hu (=?ISO-8859-2?Q?=C9RDI_Gerg=F5?=) Date: Thu, 3 Nov 2022 17:46:42 +0800 (+08) Subject: Is Prep supposed to keep thing in (reverse) dependency order? Message-ID: Hi, I was under the impression that the Prep'd Core is still in reverse dependency order, i.e. if definition A refers to intra-module definition B, then A's binding will always be preceding B's binding. I've been exploiting this (hopefully not made-up and accidental!) property in my work so far. However, for the following input: ``` $s$fFunctorFun_$sfmap :: forall a b. (a -> b) -> Fun '[AnnexType, CSASource, Currency, String] a -> Fun '[AnnexType, CSASource, Currency, String] b $s$fFunctorFun_$sfmap = (\ (@a) (@b) (f :: a -> b) (g :: Fun '[AnnexType, CSASource, Currency, String] a) (x1 :: AnnexType) -> let { g1 :: TFun '[CSASource, Currency, String] a g1 = (g `cast` ) x1 } in (\ (x2 :: CSASource) -> $s$fApplicativeFun_$s$fFunctorFun2 @Currency @a @b f (((g1 `cast` ) x2) `cast` ) `cast` ) `cast` ) ``` I am getting the following output from Prep: ``` sat_s2iCp :: forall a b. (a -> b) -> Fun '[AnnexType, CSASource, Currency, String] a -> Fun '[AnnexType, CSASource, Currency, String] b sat_s2iCp = (\ (@a) (@b) (f :: a -> b) (g :: Fun '[AnnexType, CSASource, Currency, String] a) (x1 :: AnnexType) -> let { g1 :: TFun '[CSASource, Currency, String] a g1 = (g `cast` ) x1 } in let { sat_s2iCo :: CSASource -> Currency -> Fun '[String] b sat_s2iCo = \ (x2 :: CSASource) -> $s$fApplicativeFun_$s$fFunctorFun2 @Currency @a @b f (((g1 `cast` ) x2) `cast` ) } in sat_s2iCo `cast` ) `cast` $s$fFunctorFun_$sfmap :: forall a b. (a -> b) -> Fun '[AnnexType, CSASource, Currency, String] a -> Fun '[AnnexType, CSASource, Currency, String] b $s$fFunctorFun_$sfmap = \ (@a) (@b) (eta_B0 :: a -> b) (eta_B1 :: Fun '[AnnexType, CSASource, Currency, String] a) -> sat_s2iCp @a @b eta_B0 eta_B1 ``` Note that the body of `$s$fFunctorFun_$sfmap` has been lifted out to `sat_s2iCp`, but the binding of `sat_s2iCp` precedes the binding of `$s$fFunctorFun_$sfmap`. Is this expected, for some reason, or is this a GHC bug? If the latter, I'm happy to file a ticket but I can't promise an actual end-to-end compilable reproducer... From ben at well-typed.com Thu Nov 3 20:58:14 2022 From: ben at well-typed.com (Ben Gamari) Date: Thu, 03 Nov 2022 16:58:14 -0400 Subject: [ANNOUNCE] GHC 9.4.3 is now available Message-ID: <87mt97ep1h.fsf@smart-cactus.org> The GHC developers are happy to announce the availability of GHC 9.4.3. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.4.3 This release is primarily a bugfix release addressing a few issues found in 9.4.2. These include: * An issue where recursively calls could be speculatively evaluated, resulting in non-termination (#20836) * A code generation issue in the AArch64 native code generator backend resulting in incorrect runtime results in some circumstances (#22282) * A crash on Darwin when running executables compiled with IPE support (#22080) * A long-standing interface-file determinism issue where full paths would leak into the interface file (#22162) * A bug in the `process` library where file handles specified as `NoStream` would still be usable in the child (process#251) Note that, as GHC 9.4 is the first release series where the release artifacts are all generated by our new Hadrian build system, it is possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. See the accompanying [blog post] for details on migrating packaging to Hadrian. We would also like to emphasize that GHC 9.4 must be used in conjunction with Cabal-3.8 or later. This is particularly important for Windows users due to changes in GHC's Windows toolchain. 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 Haskelling, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian/bootstrap/README.md [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian [blog post]: https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From Gergo.Erdi at sc.com Fri Nov 4 01:31:03 2022 From: Gergo.Erdi at sc.com (Erdi, Gergo) Date: Fri, 4 Nov 2022 01:31:03 +0000 Subject: [External] Is Prep supposed to keep thing in (reverse) dependency order? In-Reply-To: References: Message-ID: PUBLIC Never mind, I think I got myself confused about different stages of the pipeline. The order of binds generated by Prep is correct, what was tripping me up really was that sat_s2iCp is a local Id bound by a top-level bind. But that's OK, I handle this situation now and everything else works out. Sorry! -----Original Message----- From: ghc-devs On Behalf Of ÉRDI Gergo Sent: Thursday, November 3, 2022 5:47 PM To: GHC Devs Subject: [External] Is Prep supposed to keep thing in (reverse) dependency order? ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails. Always report suspicious emails using the Report As Phishing button in Outlook to protect the Bank and our clients. Hi, I was under the impression that the Prep'd Core is still in reverse dependency order, i.e. if definition A refers to intra-module definition B, then A's binding will always be preceding B's binding. I've been exploiting this (hopefully not made-up and accidental!) property in my work so far. However, for the following input: ``` $s$fFunctorFun_$sfmap :: forall a b. (a -> b) -> Fun '[AnnexType, CSASource, Currency, String] a -> Fun '[AnnexType, CSASource, Currency, String] b $s$fFunctorFun_$sfmap = (\ (@a) (@b) (f :: a -> b) (g :: Fun '[AnnexType, CSASource, Currency, String] a) (x1 :: AnnexType) -> let { g1 :: TFun '[CSASource, Currency, String] a g1 = (g `cast` ) x1 } in (\ (x2 :: CSASource) -> $s$fApplicativeFun_$s$fFunctorFun2 @Currency @a @b f (((g1 `cast` ) x2) `cast` ) `cast` ) `cast` ) ``` I am getting the following output from Prep: ``` sat_s2iCp :: forall a b. (a -> b) -> Fun '[AnnexType, CSASource, Currency, String] a -> Fun '[AnnexType, CSASource, Currency, String] b sat_s2iCp = (\ (@a) (@b) (f :: a -> b) (g :: Fun '[AnnexType, CSASource, Currency, String] a) (x1 :: AnnexType) -> let { g1 :: TFun '[CSASource, Currency, String] a g1 = (g `cast` ) x1 } in let { sat_s2iCo :: CSASource -> Currency -> Fun '[String] b sat_s2iCo = \ (x2 :: CSASource) -> $s$fApplicativeFun_$s$fFunctorFun2 @Currency @a @b f (((g1 `cast` ) x2) `cast` ) } in sat_s2iCo `cast` ) `cast` $s$fFunctorFun_$sfmap :: forall a b. (a -> b) -> Fun '[AnnexType, CSASource, Currency, String] a -> Fun '[AnnexType, CSASource, Currency, String] b $s$fFunctorFun_$sfmap = \ (@a) (@b) (eta_B0 :: a -> b) (eta_B1 :: Fun '[AnnexType, CSASource, Currency, String] a) -> sat_s2iCp @a @b eta_B0 eta_B1 ``` Note that the body of `$s$fFunctorFun_$sfmap` has been lifted out to `sat_s2iCp`, but the binding of `sat_s2iCp` precedes the binding of `$s$fFunctorFun_$sfmap`. Is this expected, for some reason, or is this a GHC bug? If the latter, I'm happy to file a ticket but I can't promise an actual end-to-end compilable reproducer... _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org https://clicktime.symantec.com/15tpDJfA3uiEzBJsnQUvo?h=L7HCari1kV6LycjbY5WpaWCMbvgGs4-4hXbMYMfiHcI=&u=http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products. From zubin at well-typed.com Mon Nov 7 07:50:04 2022 From: zubin at well-typed.com (Zubin Duggal) Date: Mon, 7 Nov 2022 13:20:04 +0530 Subject: [Haskell] [ANNOUNCE] GHC 9.2.5 released Message-ID: <20221107075004.pyhwecu65kl2xjmn@zubin-msi> The GHC developers are very happy to at announce the availability of GHC 9.2.5. Binary distributions, source distributions, and documentation are available at [`downloads.haskell.org`](https://downloads.haskell.org/ghc/9.2.5). Download Page: https://www.haskell.org/ghc/download_ghc_9_2_5.html Blog Post: https://www.haskell.org/ghc/blog/20221107-ghc-9.2.5-released.html This release is primarily a bugfix release addressing a few issues found in 9.2.4. These include: * Code generation issues in the AArch64 native code generator backend resulting in incorrect runtime results in some circumstances (#22282, #21964) * Fixes for a number of issues with the simplifier leading to core lint errors and suboptimal performance (#21694, #21755, #22114) * A long-standing interface-file determinism issue where full paths would leak into the interface file (#22162) * A runtime system bug where creating empty mutable arrays resulted in a crash (#21962) - ... 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 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.2.5/docs/html/users_guide/9.2.5-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 ben at well-typed.com Mon Nov 7 14:14:22 2022 From: ben at well-typed.com (Ben Gamari) Date: Mon, 07 Nov 2022 09:14:22 -0500 Subject: GitLab maintenance today Message-ID: <87cz9yj1hx.fsf@smart-cactus.org> Hi all, Today we will be doing some maintenance on gitlab.haskell.org to address #22418. I can't yet say precisely when the outage will begin but I do expect there to be one. I will try to provide at least 30 minutes notice. 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 Nov 8 11:01:55 2022 From: bryan at haskell.foundation (Bryan Richter) Date: Tue, 8 Nov 2022 13:01:55 +0200 Subject: GitLab runners having issues Message-ID: Hi everyone, Unfortunately, many CI jobs are failing for similar reasons on a number of runners. Examples: 1. Running /usr/local/bin/cabal update --index=2020-12-21T14:48:20Z... Downloading the latest package list from hackage.haskell.org Version of /root.json is less than the previous version /usr/local/bin/cabal update --index=2020-12-21T14:48:20Z failed error: cabal update failed -- https://gitlab.haskell.org/ghc/ghc/-/jobs/1224391 2. ERROR: Job failed: failed to pull image "registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-v15.0.0" -- https://gitlab.haskell.org/ghc/ghc/-/jobs/1224641 Moritz, can you look into these? Could it have something to do with the GitLab emergency upgrade that happened yesterday? Or were the runners reconfigured in some way? I don't have administrative access to these runners. I have created an issue: https://gitlab.haskell.org/ghc/ghc/-/issues/22422 -Bryan From bryan at haskell.foundation Wed Nov 9 08:22:16 2022 From: bryan at haskell.foundation (Bryan Richter) Date: Wed, 9 Nov 2022 10:22:16 +0200 Subject: GitLab runners having issues In-Reply-To: References: Message-ID: It looks like this was "resolved" -- it was an intermittent issue that went away on its own. I will start tracking it appropriately. Speaking of which, tracking spurious failures is not functioning right now, due to a problem with the ghc-perf-import bot. Until that gets resolved (later today, no doubt!), we'll see a higher pipeline failure rate. -Bryan On Tue, Nov 8, 2022 at 1:01 PM Bryan Richter wrote: > > Hi everyone, > > Unfortunately, many CI jobs are failing for similar reasons on a > number of runners. Examples: > > 1. > > Running /usr/local/bin/cabal update --index=2020-12-21T14:48:20Z... > Downloading the latest package list from hackage.haskell.org > Version of /root.json is less than the previous version > /usr/local/bin/cabal update --index=2020-12-21T14:48:20Z failed > error: cabal update failed > > -- https://gitlab.haskell.org/ghc/ghc/-/jobs/1224391 > > > 2. > > ERROR: Job failed: failed to pull image > "registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-v15.0.0" > > -- https://gitlab.haskell.org/ghc/ghc/-/jobs/1224641 > > Moritz, can you look into these? > > Could it have something to do with the GitLab emergency upgrade that > happened yesterday? Or were the runners reconfigured in some way? > > I don't have administrative access to these runners. > > I have created an issue: https://gitlab.haskell.org/ghc/ghc/-/issues/22422 > > -Bryan From hecate at glitchbra.in Wed Nov 9 08:24:51 2022 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Wed, 9 Nov 2022 09:24:51 +0100 Subject: GitLab runners having issues In-Reply-To: References: Message-ID: <93a16ea2-6128-6a30-9c74-b097aeb4381e@glitchbra.in> Thanks for the update Bryan! Le 09/11/2022 à 09:22, Bryan Richter via ghc-devs a écrit : > It looks like this was "resolved" -- it was an intermittent issue that > went away on its own. I will start tracking it appropriately. > > Speaking of which, tracking spurious failures is not functioning right > now, due to a problem with the ghc-perf-import bot. Until that gets > resolved (later today, no doubt!), we'll see a higher pipeline failure > rate. > > -Bryan > > On Tue, Nov 8, 2022 at 1:01 PM Bryan Richter wrote: >> Hi everyone, >> >> Unfortunately, many CI jobs are failing for similar reasons on a >> number of runners. Examples: >> >> 1. >> >> Running /usr/local/bin/cabal update --index=2020-12-21T14:48:20Z... >> Downloading the latest package list from hackage.haskell.org >> Version of /root.json is less than the previous version >> /usr/local/bin/cabal update --index=2020-12-21T14:48:20Z failed >> error: cabal update failed >> >> -- https://gitlab.haskell.org/ghc/ghc/-/jobs/1224391 >> >> >> 2. >> >> ERROR: Job failed: failed to pull image >> "registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-v15.0.0" >> >> -- https://gitlab.haskell.org/ghc/ghc/-/jobs/1224641 >> >> Moritz, can you look into these? >> >> Could it have something to do with the GitLab emergency upgrade that >> happened yesterday? Or were the runners reconfigured in some way? >> >> I don't have administrative access to these runners. >> >> I have created an issue: https://gitlab.haskell.org/ghc/ghc/-/issues/22422 >> >> -Bryan > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD From jaro.reinders at gmail.com Mon Nov 14 09:47:39 2022 From: jaro.reinders at gmail.com (J. Reinders) Date: Mon, 14 Nov 2022 10:47:39 +0100 Subject: Status of Stream Fusion? Message-ID: Dear GHC devs, I’m interested in stream fusion and would like to see what it takes to fix the remaining issues, so that it can replace foldr/build fusion in base. First of all I would like to know what exactly the challenges are that are left. I believe one of the main remaining problems is the fusion of ‘concatMap’. Is that really the only thing? Secondly, I would like to know what has already been tried. I know Sebastian Graf has spent a lot of effort trying to get SpecConstr to work on lambda arguments without success. I’ve read that Sebastian now considers the static argument transformation more promising. However, Duncan Coutts proposed in his thesis to make rewrite rules slightly more powerful and use the rewrite rule: concatMap (λx → Stream next (f x)) = concatMap' next f Has that ever been tried? If so, what is the problem with this rewrite rule approach? I can understand that the `f x` function application is usually in a more reduced form, but it seems relatively easy to make the rewrite rule matcher smart enough to see through beta-reductions like that. So my main questions are: 1. Is the ‘concatMap’ problem really the only problem left on the way to using stream fusion instead of foldr/build fusion in base? 2. Has the rewrite rule approach to solving the ‘concatMap’ problem ever been tried? Any other information about the current status of stream fusion is also much appreciated. Cheers, Jaro Reinders From sgraf1337 at gmail.com Mon Nov 14 10:24:39 2022 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Mon, 14 Nov 2022 11:24:39 +0100 Subject: Status of Stream Fusion? In-Reply-To: References: Message-ID: Hi Jaro, I'm very glad that you are interested in picking up the pieces I left behind! Re: SpecConstr: Yes, that pass is already moderately complicated and gets much more complicated when you start specialisation for non-bound lambdas, because that would need higher-order pattern unification in RULEs to be useful (as well as SpecConstr applying those RULEs when specialising). One smart suggestion by Simon to prevent that was to only specialise on bound lambdas only and do a pass before that assigns a name to every lambda. I'm not sure if that is enough for the recursive specialisation problem arising in stream fusion, though. I simply haven't played it through so far. Re: Static argument transformation: I find that much more promising indeed. Not the pass that transforms the RHS of a binding, but a my new idea that evaluates in the Simplifier for a recursive function whether it makes sense to inline its on-the-fly SAT'd form. See https://gitlab.haskell.org/ghc/ghc/-/issues/18962 and the prototype https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4553 for details. It does just fine on concatMap stream fusion pipelines (at least when the stepper function is small enough to inline), although I remember there are a few annoying issues regarding SAT'ing stable unfoldings (think INLINE recursive functions). Just thinking about it makes me excited again, but I've to finish other stuff in my PhD first. Re: Beefing up rewrite rules: I *think* the RULE you suggest amounts to implementing pattern unification in RULEs (perhaps you could prevent that by saying that `x` may not occur freely in `next` or `f`, but the paper explicitly *wants* `x` to occur in `next`). I'd find that cool, but I'm a bit wary that the RULE matcher (which I'm not very familiar with) might behave subtly different in certain key scenarios than vanilla pattern unification and we might get breaking changes as a result. At the moment, RULEs matching only ever matches a term against a pattern, where the former has no "unification variables", so it might be simpler than full-blown pattern unification. So in short, the problem was never that we couldn't write down the RULE, but that it's hard to implement in GHC. I can't really answer (1) or (2), but perhaps my summary above is useful to you. Sebastian Am Mo., 14. Nov. 2022 um 10:47 Uhr schrieb J. Reinders < jaro.reinders at gmail.com>: > Dear GHC devs, > > I’m interested in stream fusion and would like to see what it takes to fix > the remaining issues, so that it can replace foldr/build fusion in base. > > First of all I would like to know what exactly the challenges are that are > left. I believe one of the main remaining problems is the fusion of > ‘concatMap’. Is that really the only thing? > > Secondly, I would like to know what has already been tried. I know > Sebastian Graf has spent a lot of effort trying to get SpecConstr to work > on lambda arguments without success. I’ve read that Sebastian now considers > the static argument transformation more promising. > > However, Duncan Coutts proposed in his thesis to make rewrite rules > slightly more powerful and use the rewrite rule: > > concatMap (λx → Stream next (f x)) = concatMap' next f > > Has that ever been tried? If so, what is the problem with this rewrite > rule approach? I can understand that the `f x` function application is > usually in a more reduced form, but it seems relatively easy to make the > rewrite rule matcher smart enough to see through beta-reductions like that. > > So my main questions are: > > 1. Is the ‘concatMap’ problem really the only problem left on the way to > using stream fusion instead of foldr/build fusion in base? > > 2. Has the rewrite rule approach to solving the ‘concatMap’ problem ever > been tried? > > Any other information about the current status of stream fusion is also > much appreciated. > > Cheers, > > Jaro Reinders > > _______________________________________________ > 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 Nov 14 10:26:38 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 14 Nov 2022 10:26:38 +0000 Subject: Status of Stream Fusion? In-Reply-To: References: Message-ID: Jaro 1. Is the ‘concatMap’ problem really the only problem left on the way to > using stream fusion instead of foldr/build fusion in base? > Can you say precisely what you mean by "using stream fusion instead of foldr/build fusion in base"? For example, do you have a prototype library that demonstrates what you intend, all except concatMap? concatMap (λx → Stream next (f x)) = concatMap' next f > If it was lined up nicely like that it'd be easy. But what about concatMap (\x. Stream next (x*2 +x)) Then you want matching to succeed, with the substitution f :-> (\p. p*2 +p) This is called "higher order matching" and is pretty tricky. You could start with this paper . My comment on #22361 also refers to the potential usefulness of higher order matching. Simon On Mon, 14 Nov 2022 at 09:47, J. Reinders wrote: > Dear GHC devs, > > I’m interested in stream fusion and would like to see what it takes to fix > the remaining issues, so that it can replace foldr/build fusion in base. > > First of all I would like to know what exactly the challenges are that are > left. I believe one of the main remaining problems is the fusion of > ‘concatMap’. Is that really the only thing? > > Secondly, I would like to know what has already been tried. I know > Sebastian Graf has spent a lot of effort trying to get SpecConstr to work > on lambda arguments without success. I’ve read that Sebastian now considers > the static argument transformation more promising. > > However, Duncan Coutts proposed in his thesis to make rewrite rules > slightly more powerful and use the rewrite rule: > > concatMap (λx → Stream next (f x)) = concatMap' next f > > Has that ever been tried? If so, what is the problem with this rewrite > rule approach? I can understand that the `f x` function application is > usually in a more reduced form, but it seems relatively easy to make the > rewrite rule matcher smart enough to see through beta-reductions like that. > > So my main questions are: > > 1. Is the ‘concatMap’ problem really the only problem left on the way to > using stream fusion instead of foldr/build fusion in base? > > 2. Has the rewrite rule approach to solving the ‘concatMap’ problem ever > been tried? > > Any other information about the current status of stream fusion is also > much appreciated. > > Cheers, > > Jaro Reinders > > _______________________________________________ > 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 Nov 14 11:03:06 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 14 Nov 2022 11:03:06 +0000 Subject: Gitlab slow? Message-ID: Is it just me, or is GitLab taking an unusually long time to serve up pages when looking at GHC tickets? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at haskell.foundation Mon Nov 14 11:08:50 2022 From: bryan at haskell.foundation (Bryan Richter) Date: Mon, 14 Nov 2022 13:08:50 +0200 Subject: Gitlab slow? In-Reply-To: References: Message-ID: I find it very slow, as well. :( Eventually I want to be able to help out with these problems, but right now my priorities are different and I don't have the bandwidth. We rely on Ben still. (I am at least relieving him of other tasks that would be competing for his time!) On Mon, Nov 14, 2022 at 1:03 PM Simon Peyton Jones wrote: > > Is it just me, or is GitLab taking an unusually long time to serve up pages when looking at GHC tickets? > > Simon > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From jaro.reinders at gmail.com Mon Nov 14 11:32:35 2022 From: jaro.reinders at gmail.com (J. Reinders) Date: Mon, 14 Nov 2022 12:32:35 +0100 Subject: Status of Stream Fusion? In-Reply-To: References: Message-ID: <5A9EAA0E-860F-4B7A-9D43-947B27E064FF@gmail.com> Thank you both for the quick responses. > Can you say precisely what you mean by "using stream fusion instead of foldr/build fusion in base"? For example, do you have a prototype library that demonstrates what you intend, all except concatMap? I believe the stream-fusion library [1] and in particular the Data.List.Stream module [2] implements a version of Data.List from base with stream fusion instead of foldr/build fusion. It is pretty old at this point, so it may not completely match up with the current Data.List module any more and it doesn’t use skip-less stream fusion yet. I now also see that #915 [3] tracks the exact issue of replacing foldr/build fusion with stream fusion in base, but is closed because it required more research at the time. And in that thread, Sebastian already asked the same question as me 5 years ago [4]: > At least this could get rid of the concatMap roadblock, are there any others I'm not aware of? [1] https://hackage.haskell.org/package/stream-fusion [2] https://hackage.haskell.org/package/stream-fusion-0.1.2.5/docs/Data-List-Stream.html [3] https://gitlab.haskell.org/ghc/ghc/-/issues/915 [4] https://gitlab.haskell.org/ghc/ghc/-/issues/915#note_141373 > But what about > > concatMap (\x. Stream next (x*2 +x)) > > Then you want matching to succeed, with the substitution > f :-> (\p. p*2 +p) > > This is called "higher order matching" and is pretty tricky. First of all, I’d like to clarify I’ll write ‘unification variable’, but that might be the wrong term. What I mean is a variable that is bound by a ‘forall’ in a rewrite rule. So in the example program, I’ll call ‘f’ and ’next’ unification variables and ‘x’ a local variable. Higher order matching sounds like it makes the problem too general (although I’ll admit I haven’t looked into it fully). For this matching I feel like the core is to change the free variable ‘x’ in the expression ‘(x*2 +x)’ into a bound variable to get ‘\p -> p*2 +p’. That part sounds very easy. The only problem that remains is when to actually perform this change. I would suggest that this should happen when a unification variable ‘f’ is applied to a locally bound variable ‘x’. The local variable ‘x’ should only be allowed to occur in unification variables that are applied to it. And indeed this seems to be what Sebastian suggests: > perhaps you could prevent that by saying that `x` may not occur freely in `next` or `f`, but the paper explicitly *wants* `x` to occur in `next` The paper explicitly says that ‘x’ should *not* occur in ’next’ and ‘f’ (except indirectly because ‘f’ is applied to ‘x’), so that doesn’t seem like a problem to me. In a way I’m suggesting that function application could be used in rewrite rules to indicate which local variables may scope over which unification variables. If a unification variable is applied to a local variable then the local variable may occur in that unification variable. It should not only match on a literal application. I believe the reason that this is easier than higher order matching in general because it is restricted to applications of unification variables to locally bound variables. No other forms are required for the concatMap rule. There can be some discussion about whether this syntax is really desirable because it changes the way locally bound variables are treated in rewrite rules, but I personally think the current behavior is not very reliable anyway. And I don’t think many people are using rewrite rules that contain local variables. But maybe it would be better to introduce special syntax for indicating scoping in rewrite rules. Duncan Coutts also uses this alternative notation: λx → Stream (⟨next⟩[]) (⟨e⟩[x]) But I’d guess it would be difficult to extend GHC’s parser to support that syntax. Re-using function application seems preferable from that perspective. Another alternative that I considered was this syntax: concatMap (\x -> Stream next e) = concatMap' next (\x -> e) Now the matching local variable name on the left and the right could be used to infer that they are really the same and that ‘x’ should only be allowed to scope over ‘e’. GHC could just take the intersection of the scopes on the left and the right to deduce where the local variable ‘x’ should be allowed to occur (in this case that intersection is just ‘e’). But this syntax seems a bit more magical to me, so it isn’t my first choice. This also leads to ambiguities if two locally bound variables on the same side share the same name, but that could simply be rejected. Cheers, Jaro From sgraf1337 at gmail.com Mon Nov 14 13:03:01 2022 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Mon, 14 Nov 2022 14:03:01 +0100 Subject: Status of Stream Fusion? In-Reply-To: <5A9EAA0E-860F-4B7A-9D43-947B27E064FF@gmail.com> References: <5A9EAA0E-860F-4B7A-9D43-947B27E064FF@gmail.com> Message-ID: > I believe the reason that this is easier than higher order matching in general because it is restricted to applications of unification variables to locally bound variables. Indeed, it is easier to confine oneself to the pattern fragment. I think that's entirely the point of pattern unification: Meta variables may appear in the head of an application, but then the arguments may only be distinct bound variables. E.g., `α x x` would be disallowed. Perhaps it is possible to tweak RULEs just enough to match forall f next. concatMap (λx → Stream next (f x)) = concatMap' next f (Now that I re-read your RULE, the explicit app `f x` makes sense compared to the absence of an app in `next` to indicate it must not mention `x`. I completely overread it before.) If `f x` should match `x*2+x` with `f := \x -> 2*x+x` then that means RULE matching modulo beta reductions, for a start. Do we also want eta? I think we do, because we are already matching modulo eta since https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6222 (and are very careful not to increase arity of target term in doing so). There are many other troubling issues with pattern unification stemming from meta variables on both sides of the equation, but perhaps they don't come up because the target term does not contain meta variables. Solving a meta variable simply does `eqExpr` with solutions from other use sites, as today. It doesn't matter much that we are `eq`ing lambdas, because that's pretty simple to do. I can't think of an obvious example where higher-order pattern *matching* (urgh, what an unfortunate intersection of meaning between "higher-order pattern unification" and "pattern matching") would be much more complicated, but I'm no expert in the field. I didn't know the paper Simon cited, but note that Miller's higher-order pattern unification (which has become bog standard in dependently-typed langs) identifies a useful subset that is also efficient to check. It's surprising that the authors do not compare the pattern fragment to the identified fragment of their implementation (although they cite it in one place as [16]). Anyway, unless someone comes up with a tricky counter-example for a RULE that would be complicated to check, you should probably just give it a try. Cheers, Sebastian Am Mo., 14. Nov. 2022 um 12:32 Uhr schrieb J. Reinders < jaro.reinders at gmail.com>: > Thank you both for the quick responses. > > > Can you say precisely what you mean by "using stream fusion instead of > foldr/build fusion in base"? For example, do you have a prototype library > that demonstrates what you intend, all except concatMap? > > > I believe the stream-fusion library [1] and in particular the > Data.List.Stream module [2] implements a version of Data.List from base > with stream fusion instead of foldr/build fusion. It is pretty old at this > point, so it may not completely match up with the current Data.List module > any more and it doesn’t use skip-less stream fusion yet. > > I now also see that #915 [3] tracks the exact issue of replacing > foldr/build fusion with stream fusion in base, but is closed because it > required more research at the time. And in that thread, Sebastian already > asked the same question as me 5 years ago [4]: > > > At least this could get rid of the concatMap roadblock, are there any > others I'm not aware of? > > [1] https://hackage.haskell.org/package/stream-fusion > [2] > https://hackage.haskell.org/package/stream-fusion-0.1.2.5/docs/Data-List-Stream.html > [3] https://gitlab.haskell.org/ghc/ghc/-/issues/915 > [4] https://gitlab.haskell.org/ghc/ghc/-/issues/915#note_141373 > > > But what about > > > > concatMap (\x. Stream next (x*2 +x)) > > > > Then you want matching to succeed, with the substitution > > f :-> (\p. p*2 +p) > > > > This is called "higher order matching" and is pretty tricky. > > > First of all, I’d like to clarify I’ll write ‘unification variable’, but > that might be the wrong term. What I mean is a variable that is bound by a > ‘forall’ in a rewrite rule. So in the example program, I’ll call ‘f’ and > ’next’ unification variables and ‘x’ a local variable. > > Higher order matching sounds like it makes the problem too general > (although I’ll admit I haven’t looked into it fully). For this matching I > feel like the core is to change the free variable ‘x’ in the expression > ‘(x*2 +x)’ into a bound variable to get ‘\p -> p*2 +p’. That part sounds > very easy. The only problem that remains is when to actually perform this > change. I would suggest that this should happen when a unification variable > ‘f’ is applied to a locally bound variable ‘x’. The local variable ‘x’ > should only be allowed to occur in unification variables that are applied > to it. > > And indeed this seems to be what Sebastian suggests: > > > perhaps you could prevent that by saying that `x` may not occur freely > in `next` or `f`, but the paper explicitly *wants* `x` to occur in `next` > > > The paper explicitly says that ‘x’ should *not* occur in ’next’ and ‘f’ > (except indirectly because ‘f’ is applied to ‘x’), so that doesn’t seem > like a problem to me. > > In a way I’m suggesting that function application could be used in rewrite > rules to indicate which local variables may scope over which unification > variables. If a unification variable is applied to a local variable then > the local variable may occur in that unification variable. It should not > only match on a literal application. > > I believe the reason that this is easier than higher order matching in > general because it is restricted to applications of unification variables > to locally bound variables. No other forms are required for the concatMap > rule. > > There can be some discussion about whether this syntax is really desirable > because it changes the way locally bound variables are treated in rewrite > rules, but I personally think the current behavior is not very reliable > anyway. And I don’t think many people are using rewrite rules that contain > local variables. But maybe it would be better to introduce special syntax > for indicating scoping in rewrite rules. Duncan Coutts also uses this > alternative notation: > > λx → Stream (⟨next⟩[]) (⟨e⟩[x]) > > But I’d guess it would be difficult to extend GHC’s parser to support that > syntax. Re-using function application seems preferable from that > perspective. Another alternative that I considered was this syntax: > > concatMap (\x -> Stream next e) = concatMap' next (\x -> e) > > Now the matching local variable name on the left and the right could be > used to infer that they are really the same and that ‘x’ should only be > allowed to scope over ‘e’. GHC could just take the intersection of the > scopes on the left and the right to deduce where the local variable ‘x’ > should be allowed to occur (in this case that intersection is just ‘e’). > But this syntax seems a bit more magical to me, so it isn’t my first > choice. This also leads to ambiguities if two locally bound variables on > the same side share the same name, but that could simply be rejected. > > Cheers, > > Jaro > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaro.reinders at gmail.com Mon Nov 14 13:27:31 2022 From: jaro.reinders at gmail.com (J. Reinders) Date: Mon, 14 Nov 2022 14:27:31 +0100 Subject: Status of Stream Fusion? In-Reply-To: References: <5A9EAA0E-860F-4B7A-9D43-947B27E064FF@gmail.com> Message-ID: <760C9029-3688-4B7F-90AE-1FA1EBF2D466@gmail.com> I think higher order pattern unification is different from higher order matching because the unification means both sides are allowed to be patterns that may contain meta variables, while matching works on only one pattern and one concrete term. The example pattern ‘forall a. someFunction (\x -> a x x)’ would indeed be a potential problem, but indeed I think disallowing that is fine because it is never necessary to write such patterns in practice. The paper linked by Simon contains another example: ‘forall f x. f x’ matched to ‘0’, which is also a problem because it has infinitely many possible solutions, but I would consider this out of scope because it involves an application of two unification variables. For the practical examples I’ve seen up to now, we only need to handle the application of one unification variable with one locally bound variable. I’m pretty optimistic now that it is possible to implement an algorithm that covers the practical use cases (also the Simon’s ‘mapFB' example falls into this category) while being much simpler than existing algorithms for both higher order unification and higher order matching. I’ll do some experiments with the rule matcher. Cheers, Jaro > On 14 Nov 2022, at 14:03, Sebastian Graf wrote: > > > I believe the reason that this is easier than higher order matching in general because it is restricted to applications of unification variables to locally bound variables. > > Indeed, it is easier to confine oneself to the pattern fragment. I think that's entirely the point of pattern unification: Meta variables may appear in the head of an application, but then the arguments may only be distinct bound variables. E.g., `α x x` would be disallowed. > > Perhaps it is possible to tweak RULEs just enough to match > > forall f next. concatMap (λx → Stream next (f x)) = concatMap' next f > > (Now that I re-read your RULE, the explicit app `f x` makes sense compared to the absence of an app in `next` to indicate it must not mention `x`. I completely overread it before.) > > If `f x` should match `x*2+x` with `f := \x -> 2*x+x` then that means RULE matching modulo beta reductions, for a start. > Do we also want eta? I think we do, because we are already matching modulo eta since https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6222 (and are very careful not to increase arity of target term in doing so). > > There are many other troubling issues with pattern unification stemming from meta variables on both sides of the equation, but perhaps they don't come up because the target term does not contain meta variables. Solving a meta variable simply does `eqExpr` with solutions from other use sites, as today. It doesn't matter much that we are `eq`ing lambdas, because that's pretty simple to do. > I can't think of an obvious example where higher-order pattern *matching* (urgh, what an unfortunate intersection of meaning between "higher-order pattern unification" and "pattern matching") would be much more complicated, but I'm no expert in the field. > > I didn't know the paper Simon cited, but note that Miller's higher-order pattern unification (which has become bog standard in dependently-typed langs) identifies a useful subset that is also efficient to check. It's surprising that the authors do not compare the pattern fragment to the identified fragment of their implementation (although they cite it in one place as [16]). > > Anyway, unless someone comes up with a tricky counter-example for a RULE that would be complicated to check, you should probably just give it a try. > > Cheers, > Sebastian > > > Am Mo., 14. Nov. 2022 um 12:32 Uhr schrieb J. Reinders : > Thank you both for the quick responses. > > > Can you say precisely what you mean by "using stream fusion instead of foldr/build fusion in base"? For example, do you have a prototype library that demonstrates what you intend, all except concatMap? > > > I believe the stream-fusion library [1] and in particular the Data.List.Stream module [2] implements a version of Data.List from base with stream fusion instead of foldr/build fusion. It is pretty old at this point, so it may not completely match up with the current Data.List module any more and it doesn’t use skip-less stream fusion yet. > > I now also see that #915 [3] tracks the exact issue of replacing foldr/build fusion with stream fusion in base, but is closed because it required more research at the time. And in that thread, Sebastian already asked the same question as me 5 years ago [4]: > > > At least this could get rid of the concatMap roadblock, are there any others I'm not aware of? > > [1] https://hackage.haskell.org/package/stream-fusion > [2] https://hackage.haskell.org/package/stream-fusion-0.1.2.5/docs/Data-List-Stream.html > [3] https://gitlab.haskell.org/ghc/ghc/-/issues/915 > [4] https://gitlab.haskell.org/ghc/ghc/-/issues/915#note_141373 > > > But what about > > > > concatMap (\x. Stream next (x*2 +x)) > > > > Then you want matching to succeed, with the substitution > > f :-> (\p. p*2 +p) > > > > This is called "higher order matching" and is pretty tricky. > > > First of all, I’d like to clarify I’ll write ‘unification variable’, but that might be the wrong term. What I mean is a variable that is bound by a ‘forall’ in a rewrite rule. So in the example program, I’ll call ‘f’ and ’next’ unification variables and ‘x’ a local variable. > > Higher order matching sounds like it makes the problem too general (although I’ll admit I haven’t looked into it fully). For this matching I feel like the core is to change the free variable ‘x’ in the expression ‘(x*2 +x)’ into a bound variable to get ‘\p -> p*2 +p’. That part sounds very easy. The only problem that remains is when to actually perform this change. I would suggest that this should happen when a unification variable ‘f’ is applied to a locally bound variable ‘x’. The local variable ‘x’ should only be allowed to occur in unification variables that are applied to it. > > And indeed this seems to be what Sebastian suggests: > > > perhaps you could prevent that by saying that `x` may not occur freely in `next` or `f`, but the paper explicitly *wants* `x` to occur in `next` > > > The paper explicitly says that ‘x’ should *not* occur in ’next’ and ‘f’ (except indirectly because ‘f’ is applied to ‘x’), so that doesn’t seem like a problem to me. > > In a way I’m suggesting that function application could be used in rewrite rules to indicate which local variables may scope over which unification variables. If a unification variable is applied to a local variable then the local variable may occur in that unification variable. It should not only match on a literal application. > > I believe the reason that this is easier than higher order matching in general because it is restricted to applications of unification variables to locally bound variables. No other forms are required for the concatMap rule. > > There can be some discussion about whether this syntax is really desirable because it changes the way locally bound variables are treated in rewrite rules, but I personally think the current behavior is not very reliable anyway. And I don’t think many people are using rewrite rules that contain local variables. But maybe it would be better to introduce special syntax for indicating scoping in rewrite rules. Duncan Coutts also uses this alternative notation: > > λx → Stream (⟨next⟩[]) (⟨e⟩[x]) > > But I’d guess it would be difficult to extend GHC’s parser to support that syntax. Re-using function application seems preferable from that perspective. Another alternative that I considered was this syntax: > > concatMap (\x -> Stream next e) = concatMap' next (\x -> e) > > Now the matching local variable name on the left and the right could be used to infer that they are really the same and that ‘x’ should only be allowed to scope over ‘e’. GHC could just take the intersection of the scopes on the left and the right to deduce where the local variable ‘x’ should be allowed to occur (in this case that intersection is just ‘e’). But this syntax seems a bit more magical to me, so it isn’t my first choice. This also leads to ambiguities if two locally bound variables on the same side share the same name, but that could simply be rejected. > > Cheers, > > Jaro > From sgraf1337 at gmail.com Mon Nov 14 13:30:29 2022 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Mon, 14 Nov 2022 14:30:29 +0100 Subject: Status of Stream Fusion? In-Reply-To: <760C9029-3688-4B7F-90AE-1FA1EBF2D466@gmail.com> References: <5A9EAA0E-860F-4B7A-9D43-947B27E064FF@gmail.com> <760C9029-3688-4B7F-90AE-1FA1EBF2D466@gmail.com> Message-ID: Yes, if you confine yourself to Miller's "pattern fragment" (Meta variables may appear in the head of an application, but then the arguments may only be *distinct* bound variables) then you might be fine. Thanks for giving it a try! Am Mo., 14. Nov. 2022 um 14:27 Uhr schrieb J. Reinders < jaro.reinders at gmail.com>: > I think higher order pattern unification is different from higher order > matching because the unification means both sides are allowed to be > patterns that may contain meta variables, while matching works on only one > pattern and one concrete term. > > The example pattern ‘forall a. someFunction (\x -> a x x)’ would indeed be > a potential problem, but indeed I think disallowing that is fine because it > is never necessary to write such patterns in practice. > > The paper linked by Simon contains another example: ‘forall f x. f x’ > matched to ‘0’, which is also a problem because it has infinitely many > possible solutions, but I would consider this out of scope because it > involves an application of two unification variables. For the practical > examples I’ve seen up to now, we only need to handle the application of one > unification variable with one locally bound variable. > > I’m pretty optimistic now that it is possible to implement an algorithm > that covers the practical use cases (also the Simon’s ‘mapFB' example falls > into this category) while being much simpler than existing algorithms for > both higher order unification and higher order matching. > > I’ll do some experiments with the rule matcher. > > Cheers, > Jaro > > > On 14 Nov 2022, at 14:03, Sebastian Graf wrote: > > > > > I believe the reason that this is easier than higher order matching in > general because it is restricted to applications of unification variables > to locally bound variables. > > > > Indeed, it is easier to confine oneself to the pattern fragment. I think > that's entirely the point of pattern unification: Meta variables may appear > in the head of an application, but then the arguments may only be distinct > bound variables. E.g., `α x x` would be disallowed. > > > > Perhaps it is possible to tweak RULEs just enough to match > > > > forall f next. concatMap (λx → Stream next (f x)) = concatMap' next f > > > > (Now that I re-read your RULE, the explicit app `f x` makes sense > compared to the absence of an app in `next` to indicate it must not mention > `x`. I completely overread it before.) > > > > If `f x` should match `x*2+x` with `f := \x -> 2*x+x` then that means > RULE matching modulo beta reductions, for a start. > > Do we also want eta? I think we do, because we are already matching > modulo eta since https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6222 > (and are very careful not to increase arity of target term in doing so). > > > > There are many other troubling issues with pattern unification stemming > from meta variables on both sides of the equation, but perhaps they don't > come up because the target term does not contain meta variables. Solving a > meta variable simply does `eqExpr` with solutions from other use sites, as > today. It doesn't matter much that we are `eq`ing lambdas, because that's > pretty simple to do. > > I can't think of an obvious example where higher-order pattern > *matching* (urgh, what an unfortunate intersection of meaning between > "higher-order pattern unification" and "pattern matching") would be much > more complicated, but I'm no expert in the field. > > > > I didn't know the paper Simon cited, but note that Miller's higher-order > pattern unification (which has become bog standard in dependently-typed > langs) identifies a useful subset that is also efficient to check. It's > surprising that the authors do not compare the pattern fragment to the > identified fragment of their implementation (although they cite it in one > place as [16]). > > > > Anyway, unless someone comes up with a tricky counter-example for a RULE > that would be complicated to check, you should probably just give it a try. > > > > Cheers, > > Sebastian > > > > > > Am Mo., 14. Nov. 2022 um 12:32 Uhr schrieb J. Reinders < > jaro.reinders at gmail.com>: > > Thank you both for the quick responses. > > > > > Can you say precisely what you mean by "using stream fusion instead of > foldr/build fusion in base"? For example, do you have a prototype library > that demonstrates what you intend, all except concatMap? > > > > > > I believe the stream-fusion library [1] and in particular the > Data.List.Stream module [2] implements a version of Data.List from base > with stream fusion instead of foldr/build fusion. It is pretty old at this > point, so it may not completely match up with the current Data.List module > any more and it doesn’t use skip-less stream fusion yet. > > > > I now also see that #915 [3] tracks the exact issue of replacing > foldr/build fusion with stream fusion in base, but is closed because it > required more research at the time. And in that thread, Sebastian already > asked the same question as me 5 years ago [4]: > > > > > At least this could get rid of the concatMap roadblock, are there any > others I'm not aware of? > > > > [1] https://hackage.haskell.org/package/stream-fusion > > [2] > https://hackage.haskell.org/package/stream-fusion-0.1.2.5/docs/Data-List-Stream.html > > [3] https://gitlab.haskell.org/ghc/ghc/-/issues/915 > > [4] https://gitlab.haskell.org/ghc/ghc/-/issues/915#note_141373 > > > > > But what about > > > > > > concatMap (\x. Stream next (x*2 +x)) > > > > > > Then you want matching to succeed, with the substitution > > > f :-> (\p. p*2 +p) > > > > > > This is called "higher order matching" and is pretty tricky. > > > > > > First of all, I’d like to clarify I’ll write ‘unification variable’, but > that might be the wrong term. What I mean is a variable that is bound by a > ‘forall’ in a rewrite rule. So in the example program, I’ll call ‘f’ and > ’next’ unification variables and ‘x’ a local variable. > > > > Higher order matching sounds like it makes the problem too general > (although I’ll admit I haven’t looked into it fully). For this matching I > feel like the core is to change the free variable ‘x’ in the expression > ‘(x*2 +x)’ into a bound variable to get ‘\p -> p*2 +p’. That part sounds > very easy. The only problem that remains is when to actually perform this > change. I would suggest that this should happen when a unification variable > ‘f’ is applied to a locally bound variable ‘x’. The local variable ‘x’ > should only be allowed to occur in unification variables that are applied > to it. > > > > And indeed this seems to be what Sebastian suggests: > > > > > perhaps you could prevent that by saying that `x` may not occur freely > in `next` or `f`, but the paper explicitly *wants* `x` to occur in `next` > > > > > > The paper explicitly says that ‘x’ should *not* occur in ’next’ and ‘f’ > (except indirectly because ‘f’ is applied to ‘x’), so that doesn’t seem > like a problem to me. > > > > In a way I’m suggesting that function application could be used in > rewrite rules to indicate which local variables may scope over which > unification variables. If a unification variable is applied to a local > variable then the local variable may occur in that unification variable. It > should not only match on a literal application. > > > > I believe the reason that this is easier than higher order matching in > general because it is restricted to applications of unification variables > to locally bound variables. No other forms are required for the concatMap > rule. > > > > There can be some discussion about whether this syntax is really > desirable because it changes the way locally bound variables are treated in > rewrite rules, but I personally think the current behavior is not very > reliable anyway. And I don’t think many people are using rewrite rules that > contain local variables. But maybe it would be better to introduce special > syntax for indicating scoping in rewrite rules. Duncan Coutts also uses > this alternative notation: > > > > λx → Stream (⟨next⟩[]) (⟨e⟩[x]) > > > > But I’d guess it would be difficult to extend GHC’s parser to support > that syntax. Re-using function application seems preferable from that > perspective. Another alternative that I considered was this syntax: > > > > concatMap (\x -> Stream next e) = concatMap' next (\x -> e) > > > > Now the matching local variable name on the left and the right could be > used to infer that they are really the same and that ‘x’ should only be > allowed to scope over ‘e’. GHC could just take the intersection of the > scopes on the left and the right to deduce where the local variable ‘x’ > should be allowed to occur (in this case that intersection is just ‘e’). > But this syntax seems a bit more magical to me, so it isn’t my first > choice. This also leads to ambiguities if two locally bound variables on > the same side share the same name, but that could simply be rejected. > > > > Cheers, > > > > Jaro > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon Nov 14 16:33:25 2022 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 14 Nov 2022 11:33:25 -0500 Subject: Gitlab slow? In-Reply-To: References: Message-ID: <87pmdp5wef.fsf@smart-cactus.org> Bryan Richter via ghc-devs writes: > I find it very slow, as well. :( > > Eventually I want to be able to help out with these problems, but > right now my priorities are different and I don't have the bandwidth. > We rely on Ben still. (I am at least relieving him of other tasks that > would be competing for his time!) > Hmm, interesting. I'm not seeing anything particularly concerning with the load times. According to Firefox's network profiler https://gitlab.haskell.org/ghc/ghc/-/issues/22451 takes about 3 seconds to load, with the DOM being loaded with 500ms. While this isn't fast per se, it's about in line with what I would expect. Are either of you seeing significantly longer load times? 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 hecate at glitchbra.in Mon Nov 14 16:50:18 2022 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Mon, 14 Nov 2022 17:50:18 +0100 Subject: Gitlab slow? In-Reply-To: <87pmdp5wef.fsf@smart-cactus.org> References: <87pmdp5wef.fsf@smart-cactus.org> Message-ID: I believe we can get a long way with enabling tracing in our GitLab instance, especially since Grafana can be used for visualisation, through its associated product Tempo (which is compatible with Jaeger). https://docs.gitlab.com/ee/development/distributed_tracing.html Le 14/11/2022 à 17:33, Ben Gamari a écrit : > Bryan Richter via ghc-devs writes: > >> I find it very slow, as well. :( >> >> Eventually I want to be able to help out with these problems, but >> right now my priorities are different and I don't have the bandwidth. >> We rely on Ben still. (I am at least relieving him of other tasks that >> would be competing for his time!) >> > Hmm, interesting. I'm not seeing anything particularly concerning with > the load times. According to Firefox's network profiler > https://gitlab.haskell.org/ghc/ghc/-/issues/22451 takes about 3 seconds > to load, with the DOM being loaded with 500ms. While this isn't fast per > se, it's about in line with what I would expect. > > Are either of you seeing significantly longer load times? > > Cheers, > > - Ben > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD From simon.peytonjones at gmail.com Tue Nov 15 09:57:55 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 15 Nov 2022 09:57:55 +0000 Subject: Gitlab slow? In-Reply-To: <87pmdp5wef.fsf@smart-cactus.org> References: <87pmdp5wef.fsf@smart-cactus.org> Message-ID: It is fast again now... Simon On Mon, 14 Nov 2022 at 16:35, Ben Gamari wrote: > Bryan Richter via ghc-devs writes: > > > I find it very slow, as well. :( > > > > Eventually I want to be able to help out with these problems, but > > right now my priorities are different and I don't have the bandwidth. > > We rely on Ben still. (I am at least relieving him of other tasks that > > would be competing for his time!) > > > Hmm, interesting. I'm not seeing anything particularly concerning with > the load times. According to Firefox's network profiler > https://gitlab.haskell.org/ghc/ghc/-/issues/22451 takes about 3 seconds > to load, with the DOM being loaded with 500ms. While this isn't fast per > se, it's about in line with what I would expect. > > Are either of you seeing significantly longer load times? > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz.angermann at gmail.com Wed Nov 16 05:30:02 2022 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Wed, 16 Nov 2022 13:30:02 +0800 Subject: How do you build GHC 9.2.4 cross compilers for windows? Message-ID: Hi, Does anyone know how to build a 9.2.4 windows cross compiler? Hadrian seems to get in the way a lot? This is the essence of what we tried to get working: ./configure --enable-bootstrap-with-devel-snapshot --build=x86_64-apple-darwin --host=x86_64-apple-darwin --target=x86_64-w64-mingw32 hadrian --flavour=default+no_dynamic_ghc --docs=no-sphinx -j Can someone please advise how this is supposed to be built now? Cheers, Moritz -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at haskell.foundation Wed Nov 16 09:40:14 2022 From: bryan at haskell.foundation (Bryan Richter) Date: Wed, 16 Nov 2022 11:40:14 +0200 Subject: GitLab runners having issues In-Reply-To: References: Message-ID: Update: spurious failure tracking has been fixed! On Wed, Nov 9, 2022 at 10:22 AM Bryan Richter wrote: > > It looks like this was "resolved" -- it was an intermittent issue that > went away on its own. I will start tracking it appropriately. > > Speaking of which, tracking spurious failures is not functioning right > now, due to a problem with the ghc-perf-import bot. Until that gets > resolved (later today, no doubt!), we'll see a higher pipeline failure > rate. > > -Bryan > > On Tue, Nov 8, 2022 at 1:01 PM Bryan Richter wrote: > > > > Hi everyone, > > > > Unfortunately, many CI jobs are failing for similar reasons on a > > number of runners. Examples: > > > > 1. > > > > Running /usr/local/bin/cabal update --index=2020-12-21T14:48:20Z... > > Downloading the latest package list from hackage.haskell.org > > Version of /root.json is less than the previous version > > /usr/local/bin/cabal update --index=2020-12-21T14:48:20Z failed > > error: cabal update failed > > > > -- https://gitlab.haskell.org/ghc/ghc/-/jobs/1224391 > > > > > > 2. > > > > ERROR: Job failed: failed to pull image > > "registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-v15.0.0" > > > > -- https://gitlab.haskell.org/ghc/ghc/-/jobs/1224641 > > > > Moritz, can you look into these? > > > > Could it have something to do with the GitLab emergency upgrade that > > happened yesterday? Or were the runners reconfigured in some way? > > > > I don't have administrative access to these runners. > > > > I have created an issue: https://gitlab.haskell.org/ghc/ghc/-/issues/22422 > > > > -Bryan From ben at smart-cactus.org Wed Nov 16 18:57:04 2022 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 16 Nov 2022 13:57:04 -0500 Subject: How do you build GHC 9.2.4 cross compilers for windows? In-Reply-To: References: Message-ID: <87k03u6845.fsf@smart-cactus.org> Moritz Angermann writes: > Hi, > > Does anyone know how to build a 9.2.4 windows cross compiler? Hadrian seems > to get in > the way a lot? > > This is the essence of what we tried to get working: > > ./configure --enable-bootstrap-with-devel-snapshot > --build=x86_64-apple-darwin --host=x86_64-apple-darwin > --target=x86_64-w64-mingw32 > hadrian --flavour=default+no_dynamic_ghc --docs=no-sphinx -j > > Can someone please advise how this is supposed to be built now? > Can you explain what went wrong? In general cross-compiling for Windows should be like any other target. Sadly I've been unable to test Windows in particular due to a nixpkgs bug [1] but I have had plenty of luck compiling for other platforms. Cheers, - Ben [1] https://github.com/NixOS/nixpkgs/issues/144126 -------------- 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 Nov 22 11:13:41 2022 From: bryan at haskell.foundation (Bryan Richter) Date: Tue, 22 Nov 2022 13:13:41 +0200 Subject: Upcoming maintenance on Haskell services Message-ID: Hello folks, On Thursday 24 November at 6 AM UTC, I will start a 4-hour maintenance window for the following Haskell services: 1. downloads.haskell.org 2. gitlab.haskell.org In particular, I expect the following outages: 1. downloads.haskell.org will be read-only for the duration of the window. * No uploads 2. gitlab.haskell.org will be read-only for the duration of the window. * No CI pipelines(!) * No git pushes * No commenting on issues or merge requests 3. gitlab.haskell.org will furthermore be entirely inaccessible very briefly. * There will be 1-2 outages. * Each outage will last a few seconds. The reason for the maintenance is that our hosting sponsor, Equinix Metal, is performing a facilities migration. One of our servers, gitlab-storage, is slated for retirement. All data and services that run on that server must be moved to a new server. I'm sending this first notification to a wide audience as an extra precaution in case something goes wrong. :) In reality, I expect this maintenance to only affect GHC developers and a small group of ecosystem maintainers. In particular, web access of https://downloads.haskell.org should *not* be affected by this maintenance. I will send further updates to a smaller audience. Note: The actual migration will be quick. Most of the maintenance window will be spent waiting for DNS propagation. -Bryan Haskell Foundation DevOps From clintonmead at gmail.com Wed Nov 23 01:28:46 2022 From: clintonmead at gmail.com (Clinton Mead) Date: Wed, 23 Nov 2022 12:28:46 +1100 Subject: 'Caching' of results of default instance definitions Message-ID: Hi All My apologies if this is the wrong place to post questions about GHC internals from a non-GHC dev, I thought about using GHC Users but it seems quiet on that mailing list and I think my question relates closely to how GHC implements things, so I suspect only a dev could answer anyway. I have posted the following StackOverflow question: https://stackoverflow.com/questions/74540639/when-are-the-results-of-default-methods-in-instances-cached I won't repeat the full contents here, but basically my question is that if I have a class with a "method" which has a default definition, and that default definition has no arguments on the LHS, will a separate "instance" of that default definition be created for each instance of that class that inherits that default definition? The important consequence of that being that the default definition is only computed once per type. Or is the default definition treated as a definition generalised over a typeclass, and hence having a hidden typeclass variable and therefore treated as a function, so it needs to be recomputed every time it's referenced? Any feedback or references will be appreciated. Thanks, Clinton -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Wed Nov 23 03:46:17 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 22 Nov 2022 22:46:17 -0500 Subject: 'Caching' of results of default instance definitions In-Reply-To: References: Message-ID: On Wed, Nov 23, 2022 at 12:28:46PM +1100, Clinton Mead wrote: > I have a class with a "method" which has a default definition, and that > default definition has no arguments on the LHS, will a separate "instance" > of that default definition be created for each instance of that class that > inherits that default definition? The important consequence of that being > that the default definition is only computed once per type. Typically, an instance method will have the instance type variable present in either one of the parameter types or in the result type, making it possible to infer at call sites which instance to invoke. Such methods are polymorphic, and rarely admit a sensible default value. However, when a such a default value is possible, and if you disable any inlining that might trigger separate per call site evaluation, then indeed you can get a "once per-type" value. The below prints "Foo wuz here" only three times. Main.hs: module Main (main) where import Again import M main :: IO () main = do print $ one : foo print $ 'X' : foo print $ [one] : foo again where one = 1 :: Int Again.hs: module Again(again) where import M {-# NOINLINE again #-} again :: IO () again = do print $ one : foo print $ 'X' : foo print $ [one] : foo where one = 1 :: Int M.hs {-# LANGUAGE FlexibleInstances #-} module M (foo) where import Debug.Trace class M a where {-# NOINLINE foo #-} foo :: [a] foo = trace "Foo wuz here" $ [] instance M Int instance M Char instance M ([Int]) With `TypeApplications` and `AllowAmbiguousTypes`, you can define non-polymorphic instance methods that require an explicit type application at the call site. In that case, with inlining disabled and optimisation enabled, the various default `foo @sometype` calls can be collapsed to a single constant across multiple types. M.hs: {-# LANGUAGE AllowAmbiguousTypes, FlexibleInstances #-} {-# OPTIONS_GHC -O2 #-} module M (foo) where import Debug.Trace class M a where {-# NOINLINE foo #-} foo :: Int foo = trace "Foo wuz here" $ 42 instance M Int instance M Char instance M ([Int]) With the above class definition and instance definitions and the print statements necessarily written with type applications: print $ foo @Int print $ foo @Char print $ foo @[Int] the trace string is printed just once. -- Viktor. From Gergo.Erdi at sc.com Wed Nov 23 06:24:08 2022 From: Gergo.Erdi at sc.com (Erdi, Gergo) Date: Wed, 23 Nov 2022 06:24:08 +0000 Subject: Almost all tests fail after 08bf28819b Message-ID: PUBLIC Hi, Even though I've rebuilt everything from scratch, I'm unable to run most tests on `master` from (including) 08bf28819b78e740550a73a90eda62cce8d21c90. The error message is the same for all tests: ghc: /home/mi/prog/ghc/_build/stage1/lib/x86_64-linux-ghc-9.5.20221122/base-4.17.0.0/HSbase-4.17.0.0.o: unknown symbol `newArena' ghc: Could not load Object Code /home/mi/prog/ghc/_build/stage1/lib/x86_64-linux-ghc-9.5.20221122/base-4.17.0.0/HSbase-4.17.0.0.o. ghc: unable to load unit `base-4.17.0.0' Am I doing something wrong locally, or did something that breaks tests sneak through during the Gitlab outage yesterday? Thanks, Gergo This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products. -------------- next part -------------- An HTML attachment was scrubbed... URL: From strake888 at proton.me Wed Nov 23 06:29:07 2022 From: strake888 at proton.me (Matthew Farkas-Dyck) Date: Wed, 23 Nov 2022 06:29:07 +0000 Subject: Almost all tests fail after 08bf28819b In-Reply-To: References: Message-ID: I had the same problem. Deleting the _build directory and rebuilding solved it for me. I'm also on amd64 Linux, by the by. From Gergo.Erdi at sc.com Thu Nov 24 04:46:47 2022 From: Gergo.Erdi at sc.com (Erdi, Gergo) Date: Thu, 24 Nov 2022 04:46:47 +0000 Subject: Almost all tests fail after 08bf28819b In-Reply-To: References: Message-ID: PUBLIC Nope, still getting the same error after deleting all of _build. I'm also on AMD64 Linux. I've tried with GHC 9.2.5 and 9.4.3. For reference, my exact command line (after deleting _build) is: ./boot && ./configure && ./hadrian/build-stack --flavour=devel2 -j10 test --only="ann01" -----Original Message----- From: Matthew Farkas-Dyck Sent: Wednesday, November 23, 2022 2:29 PM To: Erdi, Gergo Cc: ghc-devs at haskell.org Subject: Re: Almost all tests fail after 08bf28819b I had the same problem. Deleting the _build directory and rebuilding solved it for me. I'm also on amd64 Linux, by the by. This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products. From bryan at haskell.foundation Thu Nov 24 06:15:17 2022 From: bryan at haskell.foundation (Bryan Richter) Date: Thu, 24 Nov 2022 08:15:17 +0200 Subject: GitLab maintenance has started Message-ID: Hi all, I've started the migration, so the maintenance period has officially started. GitLab itself will go read-only soon. As a reminder, I scheduled 4 hours for the maintenance window. I'll send updates at major points of the migration. -Bryan From sylvain at haskus.fr Thu Nov 24 09:36:13 2022 From: sylvain at haskus.fr (Sylvain Henry) Date: Thu, 24 Nov 2022 10:36:13 +0100 Subject: Almost all tests fail after 08bf28819b In-Reply-To: References: Message-ID: <2da5c102-d403-e9bf-d8cc-6cf34b6de212@haskus.fr> With devel2 only the static libs are built. Hence the RTS linker is used. https://gitlab.haskell.org/ghc/ghc/-/commit/08bf28819b78e740550a73a90eda62cce8d21c#de77f4916e67137b0ad5e12cc6c2704c64313900 made some symbols public (newArena, arenaAlloc, arenaFree) but they weren't added to rts/RtsSymbols.c so the RTS linker isn't aware of them. We should have a CI job testing the static configuration. Wait, there is one, and tests have been failing with this error too: https://gitlab.haskell.org/ghc/ghc/-/jobs/1242286#L2859 Too bad it was a job allowed to fail :) On 24/11/2022 05:46, Erdi, Gergo via ghc-devs wrote: > PUBLIC > > Nope, still getting the same error after deleting all of _build. I'm also on AMD64 Linux. I've tried with GHC 9.2.5 and 9.4.3. For reference, my exact command line (after deleting _build) is: > > ./boot && ./configure && ./hadrian/build-stack --flavour=devel2 -j10 test --only="ann01" > > -----Original Message----- > From: Matthew Farkas-Dyck > Sent: Wednesday, November 23, 2022 2:29 PM > To: Erdi, Gergo > Cc:ghc-devs at haskell.org > Subject: Re: Almost all tests fail after 08bf28819b > > I had the same problem. Deleting the _build directory and rebuilding solved it for me. > > I'm also on amd64 Linux, by the by. > > This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations > > Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm > > Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. > > Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. > > Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. > > Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products. > _______________________________________________ > 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 Thu Nov 24 09:41:30 2022 From: bryan at haskell.foundation (Bryan Richter) Date: Thu, 24 Nov 2022 11:41:30 +0200 Subject: GitLab maintenance has started In-Reply-To: References: Message-ID: Hello again, After a few surprises, I have finished my migration. Unfortunately, CI IS STILL BROKEN. All CI runners disabled themselves while GitLab was in maintenance mode. (That's not very helpful, but never mind.) As I do not have the access or privileges required to restart the runners, they will stay dead until the proper people can restart them. Sorry for the trouble! -Bryan On Thu, Nov 24, 2022 at 8:15 AM Bryan Richter wrote: > > Hi all, > > I've started the migration, so the maintenance period has officially started. > > GitLab itself will go read-only soon. > > As a reminder, I scheduled 4 hours for the maintenance window. > > I'll send updates at major points of the migration. > > -Bryan From moritz.angermann at gmail.com Thu Nov 24 09:49:25 2022 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Thu, 24 Nov 2022 17:49:25 +0800 Subject: GitLab maintenance has started In-Reply-To: References: Message-ID: The zw3rk runners should be back. On Thu, 24 Nov 2022 at 17:41, Bryan Richter via ghc-devs < ghc-devs at haskell.org> wrote: > Hello again, > > After a few surprises, I have finished my migration. > > Unfortunately, CI IS STILL BROKEN. > > All CI runners disabled themselves while GitLab was in maintenance > mode. (That's not very helpful, but never mind.) > > As I do not have the access or privileges required to restart the > runners, they will stay dead until the proper people can restart them. > > Sorry for the trouble! > > -Bryan > > On Thu, Nov 24, 2022 at 8:15 AM Bryan Richter > wrote: > > > > Hi all, > > > > I've started the migration, so the maintenance period has officially > started. > > > > GitLab itself will go read-only soon. > > > > As a reminder, I scheduled 4 hours for the maintenance window. > > > > I'll send updates at major points of the migration. > > > > -Bryan > _______________________________________________ > 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 Thu Nov 24 09:51:24 2022 From: bryan at haskell.foundation (Bryan Richter) Date: Thu, 24 Nov 2022 11:51:24 +0200 Subject: GitLab maintenance has started In-Reply-To: References: Message-ID: I can confirm that! Great! [Attached screenshot shows runners online in the GitLab Runners Admin UI] On Thu, Nov 24, 2022 at 11:49 AM Moritz Angermann wrote: > > The zw3rk runners should be back. > > On Thu, 24 Nov 2022 at 17:41, Bryan Richter via ghc-devs wrote: >> >> Hello again, >> >> After a few surprises, I have finished my migration. >> >> Unfortunately, CI IS STILL BROKEN. >> >> All CI runners disabled themselves while GitLab was in maintenance >> mode. (That's not very helpful, but never mind.) >> >> As I do not have the access or privileges required to restart the >> runners, they will stay dead until the proper people can restart them. >> >> Sorry for the trouble! >> >> -Bryan >> >> On Thu, Nov 24, 2022 at 8:15 AM Bryan Richter wrote: >> > >> > Hi all, >> > >> > I've started the migration, so the maintenance period has officially started. >> > >> > GitLab itself will go read-only soon. >> > >> > As a reminder, I scheduled 4 hours for the maintenance window. >> > >> > I'll send updates at major points of the migration. >> > >> > -Bryan >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 64614 bytes Desc: not available URL: From bryan at haskell.foundation Thu Nov 24 11:43:43 2022 From: bryan at haskell.foundation (Bryan Richter) Date: Thu, 24 Nov 2022 13:43:43 +0200 Subject: GitLab maintenance has started In-Reply-To: References: Message-ID: Jobs are getting picked up, but now it looks like they are failing to upload artifacts. I am looking into it now. On Thu, Nov 24, 2022 at 11:51 AM Bryan Richter wrote: > > I can confirm that! Great! > > [Attached screenshot shows runners online in the GitLab Runners Admin UI] > > On Thu, Nov 24, 2022 at 11:49 AM Moritz Angermann > wrote: > > > > The zw3rk runners should be back. > > > > On Thu, 24 Nov 2022 at 17:41, Bryan Richter via ghc-devs wrote: > >> > >> Hello again, > >> > >> After a few surprises, I have finished my migration. > >> > >> Unfortunately, CI IS STILL BROKEN. > >> > >> All CI runners disabled themselves while GitLab was in maintenance > >> mode. (That's not very helpful, but never mind.) > >> > >> As I do not have the access or privileges required to restart the > >> runners, they will stay dead until the proper people can restart them. > >> > >> Sorry for the trouble! > >> > >> -Bryan > >> > >> On Thu, Nov 24, 2022 at 8:15 AM Bryan Richter wrote: > >> > > >> > Hi all, > >> > > >> > I've started the migration, so the maintenance period has officially started. > >> > > >> > GitLab itself will go read-only soon. > >> > > >> > As a reminder, I scheduled 4 hours for the maintenance window. > >> > > >> > I'll send updates at major points of the migration. > >> > > >> > -Bryan > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From bryan at haskell.foundation Thu Nov 24 13:34:29 2022 From: bryan at haskell.foundation (Bryan Richter) Date: Thu, 24 Nov 2022 15:34:29 +0200 Subject: GitLab maintenance has started In-Reply-To: References: Message-ID: Looks like artifacts are being successfully uploaded now! I think I'm actually done now. Happy Haskelling, -Bryan On Thu, Nov 24, 2022 at 1:43 PM Bryan Richter wrote: > > Jobs are getting picked up, but now it looks like they are failing to > upload artifacts. I am looking into it now. > > On Thu, Nov 24, 2022 at 11:51 AM Bryan Richter wrote: > > > > I can confirm that! Great! > > > > [Attached screenshot shows runners online in the GitLab Runners Admin UI] > > > > On Thu, Nov 24, 2022 at 11:49 AM Moritz Angermann > > wrote: > > > > > > The zw3rk runners should be back. > > > > > > On Thu, 24 Nov 2022 at 17:41, Bryan Richter via ghc-devs wrote: > > >> > > >> Hello again, > > >> > > >> After a few surprises, I have finished my migration. > > >> > > >> Unfortunately, CI IS STILL BROKEN. > > >> > > >> All CI runners disabled themselves while GitLab was in maintenance > > >> mode. (That's not very helpful, but never mind.) > > >> > > >> As I do not have the access or privileges required to restart the > > >> runners, they will stay dead until the proper people can restart them. > > >> > > >> Sorry for the trouble! > > >> > > >> -Bryan > > >> > > >> On Thu, Nov 24, 2022 at 8:15 AM Bryan Richter wrote: > > >> > > > >> > Hi all, > > >> > > > >> > I've started the migration, so the maintenance period has officially started. > > >> > > > >> > GitLab itself will go read-only soon. > > >> > > > >> > As a reminder, I scheduled 4 hours for the maintenance window. > > >> > > > >> > I'll send updates at major points of the migration. > > >> > > > >> > -Bryan > > >> _______________________________________________ > > >> ghc-devs mailing list > > >> ghc-devs at haskell.org > > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From terrorjack at type.dance Thu Nov 24 15:41:17 2022 From: terrorjack at type.dance (Cheng Shao) Date: Thu, 24 Nov 2022 16:41:17 +0100 Subject: Almost all tests fail after 08bf28819b In-Reply-To: <2da5c102-d403-e9bf-d8cc-6cf34b6de212@haskus.fr> References: <2da5c102-d403-e9bf-d8cc-6cf34b6de212@haskus.fr> Message-ID: Sorry, my oversight. I'll open an MR to fix the static configuration :/ On Thu, Nov 24, 2022 at 10:36 AM Sylvain Henry wrote: > With devel2 only the static libs are built. Hence the RTS linker is used. > > > https://gitlab.haskell.org/ghc/ghc/-/commit/08bf28819b78e740550a73a90eda62cce8d21c#de77f4916e67137b0ad5e12cc6c2704c64313900 > made some symbols public (newArena, arenaAlloc, arenaFree) but they weren't > added to rts/RtsSymbols.c so the RTS linker isn't aware of them. > > We should have a CI job testing the static configuration. Wait, there is > one, and tests have been failing with this error too: > https://gitlab.haskell.org/ghc/ghc/-/jobs/1242286#L2859 Too bad it was a > job allowed to fail :) > > > > On 24/11/2022 05:46, Erdi, Gergo via ghc-devs wrote: > > PUBLIC > > Nope, still getting the same error after deleting all of _build. I'm also on AMD64 Linux. I've tried with GHC 9.2.5 and 9.4.3. For reference, my exact command line (after deleting _build) is: > > ./boot && ./configure && ./hadrian/build-stack --flavour=devel2 -j10 test --only="ann01" > > -----Original Message----- > From: Matthew Farkas-Dyck > Sent: Wednesday, November 23, 2022 2:29 PM > To: Erdi, Gergo > Cc: ghc-devs at haskell.org > Subject: Re: Almost all tests fail after 08bf28819b > > I had the same problem. Deleting the _build directory and rebuilding solved it for me. > > I'm also on amd64 Linux, by the by. > > This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations > > Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm > > Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. > > Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. > > Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. > > Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products. > _______________________________________________ > ghc-devs mailing listghc-devs at haskell.orghttp://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 strake888 at proton.me Thu Nov 24 19:10:59 2022 From: strake888 at proton.me (Matthew Farkas-Dyck) Date: Thu, 24 Nov 2022 19:10:59 +0000 Subject: Almost all tests fail after 08bf28819b In-Reply-To: References: Message-ID: Ah, it seems i was in error earlier... i can reproduce this now. ☹ +1 for CI job testing static build ------- Original Message ------- On Wednesday, November 23rd, 2022 at 20:46, Erdi, Gergo wrote: > > > PUBLIC > > Nope, still getting the same error after deleting all of _build. I'm also on AMD64 Linux. I've tried with GHC 9.2.5 and 9.4.3. For reference, my exact command line (after deleting _build) is: > > ./boot && ./configure && ./hadrian/build-stack --flavour=devel2 -j10 test --only="ann01" > > -----Original Message----- > From: Matthew Farkas-Dyck strake888 at proton.me > > Sent: Wednesday, November 23, 2022 2:29 PM > To: Erdi, Gergo Gergo.Erdi at sc.com > > Cc: ghc-devs at haskell.org > Subject: Re: Almost all tests fail after 08bf28819b > > I had the same problem. Deleting the _build directory and rebuilding solved it for me. > > I'm also on amd64 Linux, by the by. > > This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations > > Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm > > Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. > > Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. > > Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. > > Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products. From terrorjack at type.dance Thu Nov 24 22:26:30 2022 From: terrorjack at type.dance (Cheng Shao) Date: Thu, 24 Nov 2022 23:26:30 +0100 Subject: Almost all tests fail after 08bf28819b In-Reply-To: References: Message-ID: The fix just landed on d198a19ae08fec797121e3907ca93c5840db0c53 on master. On Thu, Nov 24, 2022 at 8:11 PM Matthew Farkas-Dyck via ghc-devs < ghc-devs at haskell.org> wrote: > Ah, it seems i was in error earlier... i can reproduce this now. ☹ > > +1 for CI job testing static build > > ------- Original Message ------- > On Wednesday, November 23rd, 2022 at 20:46, Erdi, Gergo > wrote: > > > > > > > > PUBLIC > > > > Nope, still getting the same error after deleting all of _build. I'm > also on AMD64 Linux. I've tried with GHC 9.2.5 and 9.4.3. For reference, my > exact command line (after deleting _build) is: > > > > ./boot && ./configure && ./hadrian/build-stack --flavour=devel2 -j10 > test --only="ann01" > > > > -----Original Message----- > > From: Matthew Farkas-Dyck strake888 at proton.me > > > > Sent: Wednesday, November 23, 2022 2:29 PM > > To: Erdi, Gergo Gergo.Erdi at sc.com > > > > Cc: ghc-devs at haskell.org > > Subject: Re: Almost all tests fail after 08bf28819b > > > > I had the same problem. Deleting the _build directory and rebuilding > solved it for me. > > > > I'm also on amd64 Linux, by the by. > > > > This email and any attachments are confidential and may also be > privileged. If you are not the intended recipient, please delete all copies > and notify the sender immediately. You may wish to refer to the > incorporation details of Standard Chartered PLC, Standard Chartered Bank > and their subsidiaries at https: //www.sc.com/en/our-locations > > > > Where you have a Financial Markets relationship with Standard Chartered > PLC, Standard Chartered Bank and their subsidiaries (the "Group"), > information on the regulatory standards we adhere to and how it may affect > you can be found in our Regulatory Compliance Statement at https: // > www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: // > www.sc.com/rcs/fm > > > > Insofar as this communication is not sent by the Global Research team > and contains any market commentary, the market commentary has been prepared > by the sales and/or trading desk of Standard Chartered Bank or its > affiliate. It is not and does not constitute research material, independent > research, recommendation or financial advice. Any market commentary is for > information purpose only and shall not be relied on for any other purpose > and is subject to the relevant disclaimers available at https: // > www.sc.com/en/regulatory-disclosures/#market-disclaimer. > > > > Insofar as this communication is sent by the Global Research team and > contains any research materials prepared by members of the team, the > research material is for information purpose only and shall not be relied > on for any other purpose, and is subject to the relevant disclaimers > available at https: // > research.sc.com/research/api/application/static/terms-and-conditions. > > > > Insofar as this e-mail contains the term sheet for a proposed > transaction, by responding affirmatively to this e-mail, you agree that you > have understood the terms and conditions in the attached term sheet and > evaluated the merits and risks of the transaction. We may at times also > request you to sign the term sheet to acknowledge the same. > > > > Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ > for important information with respect to derivative products. > _______________________________________________ > 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 Gergo.Erdi at sc.com Fri Nov 25 04:02:01 2022 From: Gergo.Erdi at sc.com (Erdi, Gergo) Date: Fri, 25 Nov 2022 04:02:01 +0000 Subject: Almost all tests fail after 08bf28819b In-Reply-To: References: Message-ID: PUBLIC Thanks, I can confirm I was able to build and validate on the devel2 flavour with this commit merged. From: Cheng Shao Sent: Friday, November 25, 2022 6:27 AM To: Matthew Farkas-Dyck Cc: Erdi, Gergo ; ghc-devs at haskell.org Subject: [External] Re: Almost all tests fail after 08bf28819b The fix just landed on d198a19ae08fec797121e3907ca93c5840db0c53 on master. This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at haskell.foundation Tue Nov 29 20:49:49 2022 From: david at haskell.foundation (David Christiansen) Date: Tue, 29 Nov 2022 21:49:49 +0100 Subject: Implementors for deprecated exports? Message-ID: Dear GHC developers, The HF's Stability Working Group ( https://github.com/haskellfoundation/stability) has been looking into ways to help Haskell developers maintain their code in the face of changes to the language and libraries. Out of the ideas we found, one is already an accepted GHC proposal, just waiting for implementation! This is adding the ability to deprecate an export, rather than just a definition, which would allow a function to be moved to a new home, with the old location re-exporting it under a deprecation warning for a few releases. We're wondering: do any of you feel inspired to implement this? If you did, we'd do our best to make sure that you are supported with design advice and code review. This is probably not a good first contribution to GHC; you'll need some familiarity with GHC and how to build it. The accepted proposal is here: https://github.com/ghc-proposals/ghc-proposals/pull/134 The GHC ticket that it emerged from is here: https://gitlab.haskell.org/ghc/ghc/-/issues/4879 All the best, David and Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Tue Nov 29 22:51:22 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 29 Nov 2022 22:51:22 +0000 Subject: Implementors for deprecated exports? In-Reply-To: References: Message-ID: Just to say: this is part of an effort (by the Stability Working Group) to help us, as a community, walk the line between stability (which is essential for Haskell to be useful) and dynamism (which is essential for Haskell to be truly alive). It's not an easy line to walk (you can see meeting notes here) , but there are quite a few things we can do to avoid unnecessary breakage and ease transitions. Everything takes work, though, hence this invitation for contributions. Please consider helping. But in a wider sense, if you have ideas relevant to the scope of the Working Group , do talk to us. Thanks! Simon On Tue, 29 Nov 2022 at 20:50, David Christiansen wrote: > Dear GHC developers, > > The HF's Stability Working Group ( > https://github.com/haskellfoundation/stability) has been looking into > ways to help Haskell developers maintain their code in the face of changes > to the language and libraries. > > Out of the ideas we found, one is already an accepted GHC proposal, just > waiting for implementation! This is adding the ability to deprecate an > export, rather than just a definition, which would allow a function to be > moved to a new home, with the old location re-exporting it under a > deprecation warning for a few releases. > > We're wondering: do any of you feel inspired to implement this? If you > did, we'd do our best to make sure that you are supported with design > advice and code review. This is probably not a good first contribution to > GHC; you'll need some familiarity with GHC and how to build it. > > The accepted proposal is here: > https://github.com/ghc-proposals/ghc-proposals/pull/134 > > The GHC ticket that it emerged from is here: > https://gitlab.haskell.org/ghc/ghc/-/issues/4879 > > All the best, > David and Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at haskell.foundation Wed Nov 30 07:31:37 2022 From: bryan at haskell.foundation (Bryan Richter) Date: Wed, 30 Nov 2022 09:31:37 +0200 Subject: Merge failures due to stats increase Message-ID: Last night, Marge's merge requests failed several times because of a stats increase. compile_time/bytes allocated increased from x86_64-linux-fedora33-release baseline @ def47dd32491311289bff26230b664c895f178cc: Expected T9872a (normal) compile_time/bytes allocated: 1655471856.0 +/-1% Lower bound T9872a (normal) compile_time/bytes allocated: 1638917137 Upper bound T9872a (normal) compile_time/bytes allocated: 1672026575 Actual T9872a (normal) compile_time/bytes allocated: 1674083264 Deviation T9872a (normal) compile_time/bytes allocated: 1.1 % *** unexpected stat test failure for T9872a(normal) This happened on three separate attempts, each with a deviation of 1.1%: * https://gitlab.haskell.org/ghc/ghc/-/jobs/1247176 * https://gitlab.haskell.org/ghc/ghc/-/jobs/1247312 * https://gitlab.haskell.org/ghc/ghc/-/jobs/1247512 The reason I'm making an email out of this is that none of the individual patches that Marge is merging have this problem, but it seems to happen consistently when they are combined. You can see a list of patches by looking at the list of mentions on https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9439. There were other problems with Marge's merges last night that I DO understand and have fixed. But this one, of course, is over my head. :) Maybe somebody can look at the list of patches and deduce something useful. Otherwise, I will continue monitoring Marge's progress, and try to find a smaller set of patches that can make it through. I'll prioritize getting the Javascript backend through. -Bryan From mail at joachim-breitner.de Wed Nov 30 16:33:44 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 30 Nov 2022 17:33:44 +0100 Subject: DKIM failures for gitlab mail Message-ID: <15a1738d1daedaad7a7f7b8a3b2db9944dd3ed7b.camel@joachim-breitner.de> Hi Bryan (I assume), I noticed that a small number of Gitlab notification emails end up in my spamfilter. While there is not much you can do about triggering some bayesian style spam filter at my email provider (mailbox.org), I did notice this in the headers: X-Spam-Status: No, score=2.704 tagged_above=2 required=6 tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HS_RSPAMD_10_11=2.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: spamfilter01.heinlein-hosting.de (amavisd-new); dkim=fail (1024-bit key) reason="fail (bad RSA signature)" header.d=gitlab.haskell.org DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gitlab.haskell.org; s=mail; t=1669733134; bh=D0NUcHiskEnwSP99umP3zo8Fz8fl74OgAJ8NRDKCsp4=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:List-Id: List-Unsubscribe; b=R+WMLfhRZZdYxMd6K6w+iodDe8EHzwONNArNyboqsU5NnafPRhKZ1UeGxO/BCMvEK M7XHRRrBsPfRYpTph7xSGY427KGXieASVg1GDhAiwKSLBCiqDdkBaoJLLUIfUD02NS ouI3tvQ9mddNdaEK7retq8N+29hzs/ezf9cpgy+Q= It seems the DKIM configuration is broken? There is a DKIM record for the domain that’s valid acccording to https://www.dmarcanalyzer.com/de/dkim-de/dkim-record-check/?dmarcdns%5Btype%5D=dkim&dmarcdns%5Bselector%5D=mail&dmarcdns%5Bdomain%5D=gitlab.haskell.org&g-recaptcha-response=03AEkXODBDl43rk3Ww0q4J1LNooZNlqBYhWGd3spu68KM7nc3js92zXASAuHqVAek5IJj2iV26sx7LzrDQYX08fq2lnL5CvX4P4x7GOekNSV9yG9J48z0I3SxPzy5tQomgP4u9YR8yQqsmZwezj8coIagpBTce9Ubytv_nRg3oKmJjSYsJP5Pwc4Jmgn___e1nbsHUEqNWabdCJHX0Q02oZ3n3sRS5K8LpYOAFhYhOhMQF9QPQ74Uy8fc38lcuK3LJP6Dk5Z2xmgLJypXJiW4svbNTqnndkSehXM-Y5HJ7xdFZ3aMA4yiOwOOYjZwKc2reQDQ6v6TLrYnigFYgA6D4MM2PBRoc6-D5Zr3xbkjPMOlFVXNMGHpu_w4_nTIaTyRhYaBb1ilz7lYa15f8si5-vVuqT-XFe0U1nVsYHWBj-ejC3Ih7QQzaXdlegM3VMLZ94qBeK5b6uA7fbJv_EpMx3K6EbwVyfmsElNx9KnHOciAcQguIXUxU-EOTN900w-lAoqhxVG-VyqIQe8L99_eW6Ns5IV2tLp4qSg but maybe Postfix is not using the right key? Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From ietf-dane at dukhovni.org Wed Nov 30 17:11:48 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 30 Nov 2022 12:11:48 -0500 Subject: DKIM failures for gitlab mail In-Reply-To: <15a1738d1daedaad7a7f7b8a3b2db9944dd3ed7b.camel@joachim-breitner.de> References: <15a1738d1daedaad7a7f7b8a3b2db9944dd3ed7b.camel@joachim-breitner.de> Message-ID: On Wed, Nov 30, 2022 at 05:33:44PM +0100, Joachim Breitner wrote: > I noticed that a small number of Gitlab notification emails end up in > my spamfilter. While there is not much you can do about triggering some > bayesian style spam filter at my email provider (mailbox.org), I did > notice this in the headers: > > X-Spam-Status: No, score=2.704 tagged_above=2 required=6 > tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HS_RSPAMD_10_11=2.5, > HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, > URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no > Authentication-Results: spamfilter01.heinlein-hosting.de (amavisd-new); > dkim=fail (1024-bit key) reason="fail (bad RSA signature)" > header.d=gitlab.haskell.org > DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; > d=gitlab.haskell.org; > s=mail; t=1669733134; > bh=D0NUcHiskEnwSP99umP3zo8Fz8fl74OgAJ8NRDKCsp4=; > h=Date:From:Reply-To:To:In-Reply-To:References:Subject:List-Id: > List-Unsubscribe; > b=R+WMLfhRZZdYxMd6K6w+iodDe8EHzwONNArNyboqsU5NnafPRhKZ1UeGxO/BCMvEK > M7XHRRrBsPfRYpTph7xSGY427KGXieASVg1GDhAiwKSLBCiqDdkBaoJLLUIfUD02NS > ouI3tvQ9mddNdaEK7retq8N+29hzs/ezf9cpgy+Q= Indeed the signature in "b=" was not made by the key at mail._domainkey.gitlab.haskell.org. Running the below: sig=$( printf "%s\n%s\n%s\n" \ R+WMLfhRZZdYxMd6K6w+iodDe8EHzwONNArNyboqsU5NnafPRhKZ1UeGxO/BCMvE \ KM7XHRRrBsPfRYpTph7xSGY427KGXieASVg1GDhAiwKSLBCiqDdkBaoJLLUIfUD0 \ 2NSouI3tvQ9mddNdaEK7retq8N+29hzs/ezf9cpgy+Q= ) pkey=$( dig +short -t txt mail._domainkey.gitlab.haskell.org | perl -MMIME::Base64 -ne ' /^"v=DKIM1;/ or next; print decode_base64($1) if m{;\s*p=(\S+?)(?:;|$)} ' | openssl pkey -pubin -inform DER ) openssl rsautl -raw -encrypt -pubin \ -inkey <( printf "%s\n" "$pkey" ) \ -in <(printf "%s\n" "$sig" | openssl base64 -d) | xxd -p the output is: 509bfc93a492f1b5328308e51624d9a7ed1378861f577b11413c5034bc0c 673d61660434d4bc30844e7648da0f9605923805973a313a8c3bc82215cc ac447e47551087c544a0592ac3ae48474584bad7d9ca5b850a67493a7977 d28aaa3a9a7580d165dc4f31ff484bdbc40e94a2be1750e71c51c555b5c1 6bc051947bb07ae4 Which is not a PKCS#1.5 padded signature block. So either the "b=" value was corrupted in transit, or it was signed by a key that is different from what is published in DNS. > but maybe Postfix is not using the right key? Strictly speaking that's not Postfix itself, but some DKIM milter, but nits aside, more likely a stale public key is published in DNS. -- Viktor.