From a.pelenitsyn at gmail.com Tue Feb 1 02:31:41 2022 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Mon, 31 Jan 2022 21:31:41 -0500 Subject: downloading ghc head version In-Reply-To: References: Message-ID: Hey Harendra, How do you feel about Nix? This simple one-command-away way always worked for me great: https://github.com/mpickering/ghc-artefact-nix (Modulo a caveat with the newer versions of Nix https://github.com/mpickering/ghc-artefact-nix/issues/16 which is easily fixed by changing the command in README from `nix run` to `nix shell`). Interestingly, this Nix expression seems to work okay currently. It uses fedora builds, not deb ones. But when I tried to reconstruct the link it is supposed to use, I also couldn't download anything there: https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/master/raw/ghc-x86_64-fedora33-linux.tar.gz?job=validate-x86_64-linux-fedora33 -- Best, Artem On Mon, 31 Jan 2022 at 17:43, Harendra Kumar wrote: > It seems the latest artifacts download link > (https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/...) at GHC > gitlab is not working. > > If this is not the right place to ask this, can someone point me to > the right place? > > -harendra > > On Wed, 26 Jan 2022 at 18:38, Harendra Kumar > wrote: > > > > Hi, > > > > I am trying to set up a CI for ghc head version. I am not sure what is > > the official supported method to install a nightly/head version of > > GHC. haskell/actions/setup on github seems to support it via ghcup. > > But it almost always fails, I saw it succeeding once till now. It > > tries to download it from the following URL, but fails with 404 not > > found: > > > > downloading: > https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/master/raw/ghc-x86_64-deb9-linux-integer-simple.tar.xz?job=validate-x86_64-linux-deb9-integer-simple > > > > I tried this link in the browser and I get the same error. Is that the > > right way to install it? If not, can someone suggest a reliable way to > > get the head version, other than building it myself? > > > > Thanks, > > Harendra > _______________________________________________ > 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 matthewtpickering at gmail.com Tue Feb 1 11:58:57 2022 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 1 Feb 2022 11:58:57 +0000 Subject: downloading ghc head version In-Reply-To: References: Message-ID: Right, it appears the problem was we stopped producing the deb9 bindists due to deb9 being EOL. https://gitlab.haskell.org/ghc/ghc/-/commit/871ce2a300ed35639a39a86f4c85fbcb605c5d7d Is your problem sorted now? Matt On Tue, Feb 1, 2022 at 12:09 AM Harendra Kumar wrote: > > I replaced deb9 with deb10 in the URL that ghcup install was using > earlier in the CI and it seems to work. The following command > installed ghc successfully: > > $ ghcup install ghc -u > https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/master/raw/ghc-x86_64-deb10-linux-integer-simple.tar.xz?job=validate-x86_64-linux-deb10-integer-simple > head > $ ghc-head --version > The Glorious Glasgow Haskell Compilation System, version 9.3.20220130 > > Maybe the deb9 build has been retired now? It worked once in our CI a > few days and then never worked. > > -harendra > > On Tue, 1 Feb 2022 at 05:24, Harendra Kumar wrote: > > > > Ah, nice. That looks like a useful repo. Thanks! > > > > I tried the nix expression: > > > > nix run -f https://github.com/mpickering/ghc-artefact-nix/archive/master.tar.gz > > ghcHEAD > > > > on my debian linux, but it is trying to download the fedora tar from > > https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/master/raw/ghc-x86_64-fedora33-linux.tar.xz?job=validate-x86_64-linux-fedora33 > > . ghc-head-from.sh also downloads from the same link. Is it supposed > > to work on debian as well? The nix expression as well as > > ghc-head-from.sh finally failed with the followinf error on my > > machine: > > > > utils/ghc-cabal/dist-install/build/tmp/ghc-cabal: error while loading > > shared libraries: libstdc++.so.6: cannot open shared object file: No > > such file or directory > > > > I looked at https://github.com/mpickering/ghc-artefact-nix/blob/master/gitlab-artifact.nix, > > but it does not seem to have a debian x86_64 config. > > > > -harendra > > > > On Tue, 1 Feb 2022 at 05:00, Matthew Pickering > > wrote: > > > > > > I will look tomorrow but see where ghc-head-from gets the bindist from > > > > > > https://github.com/mpickering/ghc-artefact-nix/blob/master/ghc-head-from.sh > > > > > > On Mon, Jan 31, 2022 at 10:43 PM Harendra Kumar > > > wrote: > > > > > > > > It seems the latest artifacts download link > > > > (https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/...) at GHC > > > > gitlab is not working. > > > > > > > > If this is not the right place to ask this, can someone point me to > > > > the right place? > > > > > > > > -harendra > > > > > > > > On Wed, 26 Jan 2022 at 18:38, Harendra Kumar wrote: > > > > > > > > > > Hi, > > > > > > > > > > I am trying to set up a CI for ghc head version. I am not sure what is > > > > > the official supported method to install a nightly/head version of > > > > > GHC. haskell/actions/setup on github seems to support it via ghcup. > > > > > But it almost always fails, I saw it succeeding once till now. It > > > > > tries to download it from the following URL, but fails with 404 not > > > > > found: > > > > > > > > > > downloading: https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/master/raw/ghc-x86_64-deb9-linux-integer-simple.tar.xz?job=validate-x86_64-linux-deb9-integer-simple > > > > > > > > > > I tried this link in the browser and I get the same error. Is that the > > > > > right way to install it? If not, can someone suggest a reliable way to > > > > > get the head version, other than building it myself? > > > > > > > > > > Thanks, > > > > > Harendra > > > > _______________________________________________ > > > > ghc-devs mailing list > > > > ghc-devs at haskell.org > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From harendra.kumar at gmail.com Tue Feb 1 12:37:50 2022 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Tue, 1 Feb 2022 18:07:50 +0530 Subject: downloading ghc head version In-Reply-To: References: Message-ID: Yes, it is working with deb10. All good. Not sure why haskell/actions/setup is still using the deb9 URL. Thanks for your help. On Tue, 1 Feb 2022 at 17:29, Matthew Pickering wrote: > > Right, it appears the problem was we stopped producing the deb9 > bindists due to deb9 being EOL. > > https://gitlab.haskell.org/ghc/ghc/-/commit/871ce2a300ed35639a39a86f4c85fbcb605c5d7d > > Is your problem sorted now? > > Matt > > On Tue, Feb 1, 2022 at 12:09 AM Harendra Kumar wrote: > > > > I replaced deb9 with deb10 in the URL that ghcup install was using > > earlier in the CI and it seems to work. The following command > > installed ghc successfully: > > > > $ ghcup install ghc -u > > https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/master/raw/ghc-x86_64-deb10-linux-integer-simple.tar.xz?job=validate-x86_64-linux-deb10-integer-simple > > head > > $ ghc-head --version > > The Glorious Glasgow Haskell Compilation System, version 9.3.20220130 > > > > Maybe the deb9 build has been retired now? It worked once in our CI a > > few days and then never worked. > > > > -harendra > > > > On Tue, 1 Feb 2022 at 05:24, Harendra Kumar wrote: > > > > > > Ah, nice. That looks like a useful repo. Thanks! > > > > > > I tried the nix expression: > > > > > > nix run -f https://github.com/mpickering/ghc-artefact-nix/archive/master.tar.gz > > > ghcHEAD > > > > > > on my debian linux, but it is trying to download the fedora tar from > > > https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/master/raw/ghc-x86_64-fedora33-linux.tar.xz?job=validate-x86_64-linux-fedora33 > > > . ghc-head-from.sh also downloads from the same link. Is it supposed > > > to work on debian as well? The nix expression as well as > > > ghc-head-from.sh finally failed with the followinf error on my > > > machine: > > > > > > utils/ghc-cabal/dist-install/build/tmp/ghc-cabal: error while loading > > > shared libraries: libstdc++.so.6: cannot open shared object file: No > > > such file or directory > > > > > > I looked at https://github.com/mpickering/ghc-artefact-nix/blob/master/gitlab-artifact.nix, > > > but it does not seem to have a debian x86_64 config. > > > > > > -harendra > > > > > > On Tue, 1 Feb 2022 at 05:00, Matthew Pickering > > > wrote: > > > > > > > > I will look tomorrow but see where ghc-head-from gets the bindist from > > > > > > > > https://github.com/mpickering/ghc-artefact-nix/blob/master/ghc-head-from.sh > > > > > > > > On Mon, Jan 31, 2022 at 10:43 PM Harendra Kumar > > > > wrote: > > > > > > > > > > It seems the latest artifacts download link > > > > > (https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/...) at GHC > > > > > gitlab is not working. > > > > > > > > > > If this is not the right place to ask this, can someone point me to > > > > > the right place? > > > > > > > > > > -harendra > > > > > > > > > > On Wed, 26 Jan 2022 at 18:38, Harendra Kumar wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > I am trying to set up a CI for ghc head version. I am not sure what is > > > > > > the official supported method to install a nightly/head version of > > > > > > GHC. haskell/actions/setup on github seems to support it via ghcup. > > > > > > But it almost always fails, I saw it succeeding once till now. It > > > > > > tries to download it from the following URL, but fails with 404 not > > > > > > found: > > > > > > > > > > > > downloading: https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/master/raw/ghc-x86_64-deb9-linux-integer-simple.tar.xz?job=validate-x86_64-linux-deb9-integer-simple > > > > > > > > > > > > I tried this link in the browser and I get the same error. Is that the > > > > > > right way to install it? If not, can someone suggest a reliable way to > > > > > > get the head version, other than building it myself? > > > > > > > > > > > > Thanks, > > > > > > Harendra > > > > > _______________________________________________ > > > > > ghc-devs mailing list > > > > > ghc-devs at haskell.org > > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simon.peytonjones at gmail.com Tue Feb 1 15:38:33 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 1 Feb 2022 15:38:33 +0000 Subject: White space in CI Message-ID: Devs As you'll see from this pipeline record https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7105/pipelines CI consistently fails once a single commit has trailing whitespace, even if it is fixed in a subsequent commit - dce2054d introduced trailing whitespace - 6411223c removed it again. - but all subsequent pipelines fail This came as a big surprise. It doesn't make sense to lint each individual commit. Let's just lint the final version! (I will squash them in due course, but I didn't want to lose my work-in-progress history.) Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From nr at cs.tufts.edu Tue Feb 1 19:46:48 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Tue, 01 Feb 2022 14:46:48 -0500 Subject: How to exploit ./hadrian/ghci to find errors quickly? In-Reply-To: (sfid-H-20220128-171925-+45.52-1@multi.osbf.lua) References: <20220124220205.D735E2C285E@homedog.cs.tufts.edu> <010f017e8e34809c-2f18386c-a19e-4550-b06d-290057b41129-000000@us-east-2.amazonses.com> <20220128165200.8E9322C1AEB@homedog.cs.tufts.edu> <20220128214514.83F492C2670@homedog.cs.tufts.edu> (sfid-H-20220128-171925-+45.52-1@multi.osbf.lua) Message-ID: <20220201194648.31EC12C2D28@homedog.cs.tufts.edu> > The Binary runGet issue usually means that your build tree is out of date. > It's probably worth deleting and building from scratch again. For those who may come after me: if ./hadrian/ghci barfs with a Binary runGet issue, the build tree that needs to be deleted is `.hadrian_ghci`, not `_build`. NR From nr at cs.tufts.edu Wed Feb 2 14:49:49 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Wed, 02 Feb 2022 09:49:49 -0500 Subject: How to exploit ./hadrian/ghci to find errors quickly? In-Reply-To: (sfid-H-20220128-130256-+52.59-1@multi.osbf.lua) References: <20220124220205.D735E2C285E@homedog.cs.tufts.edu> <010f017e8e34809c-2f18386c-a19e-4550-b06d-290057b41129-000000@us-east-2.amazonses.com> <20220128165200.8E9322C1AEB@homedog.cs.tufts.edu> (sfid-H-20220128-130256-+52.59-1@multi.osbf.lua) Message-ID: <20220202144949.A22D02C2D13@homedog.cs.tufts.edu> > > [Finding the locations of compiler errors after a change] > > This is the typical use case for a language server. > I have haskell-language-server installed and use it extensively on GHC > for stuff like jump to definition and immediate compilation feedback. > > There's also "jump to next error" if you want that. I've now reached the stage where I make a change in a module, and it compiles, but the change causes a compiler error in another module far away. Is there a way to ask the language server to jump to an error in another module? (I'm using Emacs lsp-mode, and all I've found for errors is `flycheck-next-error`, which is not ideal. But if the language server can monitor the whole project, I'll get some Emacs help on how to get the info there.) Norman From nr at cs.tufts.edu Wed Feb 2 17:27:39 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Wed, 02 Feb 2022 12:27:39 -0500 Subject: way to lint my GHC sources? Message-ID: <20220202172739.D723D2C2D12@homedog.cs.tufts.edu> Is there a way for me to run the GHC linter on my GHC source tree, without having to push an MR out to CI? Norman From maurer.benjamin at gmail.com Wed Feb 2 17:59:51 2022 From: maurer.benjamin at gmail.com (Benjamin Maurer) Date: Wed, 2 Feb 2022 18:59:51 +0100 Subject: way to lint my GHC sources? In-Reply-To: <20220202172739.D723D2C2D12@homedog.cs.tufts.edu> References: <20220202172739.D723D2C2D12@homedog.cs.tufts.edu> Message-ID: You can run `./hadrian/build lint:compiler` or `lint:base`, if you have hlint on your path. Regards, Ben Am Mi., 2. Feb. 2022 um 18:29 Uhr schrieb Norman Ramsey : > Is there a way for me to run the GHC linter on my GHC source tree, > without having to push an MR out to CI? > > > Norman > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Thu Feb 3 18:56:43 2022 From: ben at well-typed.com (Ben Gamari) Date: Thu, 03 Feb 2022 13:56:43 -0500 Subject: 9.2.2 release schedule? In-Reply-To: References: <87lf097t3u.fsf@smart-cactus.org> Message-ID: <87r18jok32.fsf@smart-cactus.org> Shayne Fletcher writes: > On Fri, Dec 24, 2021 at 1:31 PM Ben Gamari wrote: > >> Shayne Fletcher writes: >> >> > Anyone know of any scheduling plans for ghc-9.2.2? >> > >> It should be out by mid-January. There are quite a few >> backports that we need to push through and the focus recently has been >> on finalizing 9.0.2 but I'll be turning my attention to 9.2.2 after I >> the holiday. >> >> > g'day again ben :) what's the latest? > At the moment there are still around 20 patches left in the backport queue. Ideally we would also backport fixes to some of the alignment issues that Bodigrim's work on text recently turned up. I'm hoping to get these merged this week. 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 matthewtpickering at gmail.com Tue Feb 8 10:30:32 2022 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 8 Feb 2022 10:30:32 +0000 Subject: Notes Linter Message-ID: Hello, Just merged is a new linter which checks the consistency of notes. In particular it checks that all note references reference an existing Note. The linter is integrated into the testsuite so you can run the linter (without building GHC) by saying ./hadrian/build test --only=notes and can accept the new output of the linter by saying ./hadrian/build test --only=notes --test-accept But you should probably not need to do this and instead fix your note references! Any issues please open a ticket. Cheers, Matt From nr at cs.tufts.edu Tue Feb 8 15:37:23 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Tue, 08 Feb 2022 10:37:23 -0500 Subject: ettiquette for changing an MR under review? Message-ID: <20220208153723.2E6102C1A86@homedog.cs.tufts.edu> I have an MR currently under review. Review has already identified a change I need to make, and I have made it in my local repository. Do I push the change now, or do I wait for a more complete review? And if I push it now, do I force-push or do I push the changes as a separate commit? Norman From simon.peytonjones at gmail.com Tue Feb 8 22:54:07 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 8 Feb 2022 22:54:07 +0000 Subject: ettiquette for changing an MR under review? In-Reply-To: <20220208153723.2E6102C1A86@homedog.cs.tufts.edu> References: <20220208153723.2E6102C1A86@homedog.cs.tufts.edu> Message-ID: I'd just make the changes, and push as a new patch. Once everything has settled down, you can compress all the patches into one and force push. Simon On Tue, 8 Feb 2022 at 20:44, Norman Ramsey wrote: > I have an MR currently under review. Review has already identified a > change I need to make, and I have made it in my local repository. > Do I push the change now, or do I wait for a more complete review? > And if I push it now, do I force-push or do I push the changes as a > separate commit? > > > Norman > _______________________________________________ > 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 tillk.vogt at googlemail.com Wed Feb 9 11:16:22 2022 From: tillk.vogt at googlemail.com (Tillmann Vogt) Date: Wed, 9 Feb 2022 12:16:22 +0100 Subject: Runnig a compiler plugin over ALL code Message-ID: Hi, I am running a compiler plugin over hundreds of libraries to extract statistical data. I use the plugin like it is done here: https://github.com/coot/ghc-tags-plugin So I just have to add a cabal.project.local to a library with: ignore-project: False package test     ghc-options: -package-db=/home/till/.cabal/store/ghc-8.10.7/package.db                  -plugin-package=ghc-core-graph                  -fplugin=GhcPlugins.Optimind But unfortunately the plugin only runs over code that is used in the main function or that is used in other functions. Example: main = putStrLn (show (f 0)) f x = sin x g = h + i Then the compiler plugin only runs over f, h, i   but not not g (unused top level functions). Can the plugin be forced to run over all code? -Tillmann From matthewtpickering at gmail.com Wed Feb 9 11:18:35 2022 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 9 Feb 2022 11:18:35 +0000 Subject: Runnig a compiler plugin over ALL code In-Reply-To: References: Message-ID: The imagine the plugin doesn't run over that definition because it doesn't exist when your plugin runs. I imagine it's a core plugin, so you might need to run it earlier in the pipeline? Matt On Wed, Feb 9, 2022 at 11:16 AM Tillmann Vogt via ghc-devs wrote: > > Hi, > > I am running a compiler plugin over hundreds of libraries to extract > statistical data. I use the plugin like it is done here: > > https://github.com/coot/ghc-tags-plugin > > So I just have to add a cabal.project.local to a library with: > > > ignore-project: False > > package test > ghc-options: -package-db=/home/till/.cabal/store/ghc-8.10.7/package.db > -plugin-package=ghc-core-graph > -fplugin=GhcPlugins.Optimind > > But unfortunately the plugin only runs over code that is used in the > main function or that is used in other functions. > > Example: > > main = putStrLn (show (f 0)) > > f x = sin x > > g = h + i > > Then the compiler plugin only runs over f, h, i but not not g (unused > top level functions). > > Can the plugin be forced to run over all code? > > -Tillmann > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From nr at cs.tufts.edu Wed Feb 9 15:35:56 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Wed, 09 Feb 2022 10:35:56 -0500 Subject: how to complete a review on gitlab? Message-ID: <20220209153556.8F2422C2664@homedog.cs.tufts.edu> I've been assigned a few merge requests to review on gitlab. One I've completed and approved. One I've completed and have decided that somebody else needs to approve it; I'm not qualified. Two I've not yet started. Is there any way to tell gitlab, "I'm done with these two"? Norman From lists at richarde.dev Wed Feb 9 18:07:04 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Wed, 9 Feb 2022 18:07:04 +0000 Subject: how to complete a review on gitlab? In-Reply-To: <20220209153556.8F2422C2664@homedog.cs.tufts.edu> References: <20220209153556.8F2422C2664@homedog.cs.tufts.edu> Message-ID: <010f017edfaadf6c-47cc08fa-dbe5-4929-a6ff-ac7db4b32a0d-000000@us-east-2.amazonses.com> I think you just unassign yourself using the widget on the right: Click on the reviewers button, and you should see yourself highlighted. Click your own icon, and that should remove you from the ticket. Richard > On Feb 9, 2022, at 10:35 AM, Norman Ramsey wrote: > > I've been assigned a few merge requests to review on gitlab. One I've > completed and approved. One I've completed and have decided that > somebody else needs to approve it; I'm not qualified. Two I've not > yet started. > > Is there any way to tell gitlab, "I'm done with these two"? > > > Norman > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From lists at richarde.dev Wed Feb 9 19:13:41 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Wed, 9 Feb 2022 19:13:41 +0000 Subject: the linters are killing me slowly Message-ID: <010f017edfe7da82-48d79a3d-6d10-46fb-85ef-ff82d913dd36-000000@us-east-2.amazonses.com> Hi devs, Can we please, please not have the linters stop more useful output during CI? Over the past few months, I've lost several days of productivity due to the current design. Why several days? Because I typically end up with only 1.5-2 hours for GHC work in a day, and when I have to spend half of that recreating test results (which, sometimes, don't work, especially if I use Hadrian, as recommended), I often decide to prioritize other tasks that I have a more reasonable chance of actually finishing. It was floated some time ago that "Draft" MRs could skip linters. But I actually have a non-Draft MR now, and it failed the new Notes linter. (Why, actually, is that even a separate pass? I thought there was a test case for that, which I'm thrilled with.) It just feels to me that the current workflow is optimized for those of us who work on GHC close to 100% of the time. This is not the way to get new contributors. Frustrated, Richard From ben at smart-cactus.org Thu Feb 10 02:04:09 2022 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 09 Feb 2022 21:04:09 -0500 Subject: the linters are killing me slowly In-Reply-To: <010f017edfe7da82-48d79a3d-6d10-46fb-85ef-ff82d913dd36-000000@us-east-2.amazonses.com> References: <010f017edfe7da82-48d79a3d-6d10-46fb-85ef-ff82d913dd36-000000@us-east-2.amazonses.com> Message-ID: <8735kro4u2.fsf@smart-cactus.org> Richard Eisenberg writes: > Hi devs, > Hi Richard, > Can we please, please not have the linters stop more useful output > during CI? Over the past few months, I've lost several days of > productivity due to the current design. Mmm, yes, this doesn't sound good. I'm sorry it's been such a hassle. > Why several days? Because I typically end up with only 1.5-2 hours for > GHC work in a day, and when I have to spend half of that recreating > test results (which, sometimes, don't work, especially if I use > Hadrian, as recommended), I often decide to prioritize other tasks > that I have a more reasonable chance of actually finishing. > > It was floated some time ago that "Draft" MRs could skip linters. But > I actually have a non-Draft MR now, and it failed the new Notes > linter. (Why, actually, is that even a separate pass? I thought there > was a test case for that, which I'm thrilled with.) > It's a separate pass to help the contributor distinguish > It just feels to me that the current workflow is optimized for those > of us who work on GHC close to 100% of the time. This is not the way > to get new contributors. > Yes, I am sympathetic with this concern. One alternative design that we could try is to rather allow linters to fail *except* in Marge jobs. This would mean that we would need to be very careful not to pass jobs with failing lints to Marge as doing so would spoil the entire Marge batch. However, it would also mean that it would make contribution in a less-than-full-time setting a bit easier. How does this sound? If we had more devops capacity we could mitigate the Marge-spoilage problem by teaching Marge not to consider MRs which are failing lints. However, at the moment I don't think we have the bandwidth to implement this. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From lists at richarde.dev Thu Feb 10 03:27:06 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Thu, 10 Feb 2022 03:27:06 +0000 Subject: the linters are killing me slowly In-Reply-To: <8735kro4u2.fsf@smart-cactus.org> References: <010f017edfe7da82-48d79a3d-6d10-46fb-85ef-ff82d913dd36-000000@us-east-2.amazonses.com> <8735kro4u2.fsf@smart-cactus.org> Message-ID: <010f017ee1ab98f5-95ae87bf-c083-410e-a7a6-5b38d7d220fd-000000@us-east-2.amazonses.com> Thanks for the response, Ben; it was more measured than my email. :) I have had a string of days when seemingly basic tasks in Haskell failed, all for different reasons. And I suppose I knew that this list would be forgiving of any trespasses. I do think there is a very happy resolution to all of this: put these lint checks in the testsuite. I believe that was Matthew's idea in yesterday's call, and I think that solves the problem very nicely. Errors get reported concurrently with other errors, a contributor can run the checks locally, and it seems possible to get the linters runnable even without a built GHC. (For example, even if the testsuite requires building GHC, the lint tests can call some lint-ghc script. But, of course, contributors can call lint-ghc directly, too.) Would that satisfy our needs here? Thanks, Richard > On Feb 9, 2022, at 9:04 PM, Ben Gamari wrote: > > Richard Eisenberg > writes: > >> Hi devs, >> > Hi Richard, > >> Can we please, please not have the linters stop more useful output >> during CI? Over the past few months, I've lost several days of >> productivity due to the current design. > > Mmm, yes, this doesn't sound good. I'm sorry it's been such a hassle. > >> Why several days? Because I typically end up with only 1.5-2 hours for >> GHC work in a day, and when I have to spend half of that recreating >> test results (which, sometimes, don't work, especially if I use >> Hadrian, as recommended), I often decide to prioritize other tasks >> that I have a more reasonable chance of actually finishing. >> >> It was floated some time ago that "Draft" MRs could skip linters. But >> I actually have a non-Draft MR now, and it failed the new Notes >> linter. (Why, actually, is that even a separate pass? I thought there >> was a test case for that, which I'm thrilled with.) >> > It's a separate pass to help the contributor distinguish > >> It just feels to me that the current workflow is optimized for those >> of us who work on GHC close to 100% of the time. This is not the way >> to get new contributors. >> > Yes, I am sympathetic with this concern. One alternative design that we > could try is to rather allow linters to fail *except* in Marge jobs. > This would mean that we would need to be very careful not to pass jobs > with failing lints to Marge as doing so would spoil the entire Marge > batch. However, it would also mean that it would make contribution in a > less-than-full-time setting a bit easier. How does this sound? > > If we had more devops capacity we could mitigate the Marge-spoilage > problem by teaching Marge not to consider MRs which are failing lints. > However, at the moment I don't think we have the bandwidth to implement > this. > > Cheers, > > - Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From moritz.angermann at gmail.com Thu Feb 10 03:29:34 2022 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Thu, 10 Feb 2022 11:29:34 +0800 Subject: the linters are killing me slowly In-Reply-To: <8735kro4u2.fsf@smart-cactus.org> References: <010f017edfe7da82-48d79a3d-6d10-46fb-85ef-ff82d913dd36-000000@us-east-2.amazonses.com> <8735kro4u2.fsf@smart-cactus.org> Message-ID: Just to add to this. I think we should *optimize* for people not working full time on GHC. Anything that's going to be smooth for people working only a few hours a week on GHC will implicitly improve the situation for those working more hours on GHC as well. As in what is pleasant for someone with little time should also make it pleasant for someone with lots of time. I don't see why marge would be an issue though? If we allow all failures, why would someone assign something to marge that still *has* failures? Isn't the idea that you assign to marge once you've cleaned up all failures? I mean ideally we'd want to get a summary of all failures (without the noise). The only drawback I can see is this: if we allow all failures, and then end up with lots of MRs, we might run into build constraints (e.g. you are going to wait hours for your MR to even be picked up by the fleat of CI machines). I don't see this happening immediately. And maybe if this happens we can get ~7k EUR / year form the HF? That's about as much as the builders I provide cost per year. Cheers, Moritz On Thu, 10 Feb 2022 at 10:04, Ben Gamari wrote: > Richard Eisenberg writes: > > > Hi devs, > > > Hi Richard, > > > Can we please, please not have the linters stop more useful output > > during CI? Over the past few months, I've lost several days of > > productivity due to the current design. > > Mmm, yes, this doesn't sound good. I'm sorry it's been such a hassle. > > > Why several days? Because I typically end up with only 1.5-2 hours for > > GHC work in a day, and when I have to spend half of that recreating > > test results (which, sometimes, don't work, especially if I use > > Hadrian, as recommended), I often decide to prioritize other tasks > > that I have a more reasonable chance of actually finishing. > > > > It was floated some time ago that "Draft" MRs could skip linters. But > > I actually have a non-Draft MR now, and it failed the new Notes > > linter. (Why, actually, is that even a separate pass? I thought there > > was a test case for that, which I'm thrilled with.) > > > It's a separate pass to help the contributor distinguish > > > It just feels to me that the current workflow is optimized for those > > of us who work on GHC close to 100% of the time. This is not the way > > to get new contributors. > > > Yes, I am sympathetic with this concern. One alternative design that we > could try is to rather allow linters to fail *except* in Marge jobs. > This would mean that we would need to be very careful not to pass jobs > with failing lints to Marge as doing so would spoil the entire Marge > batch. However, it would also mean that it would make contribution in a > less-than-full-time setting a bit easier. How does this sound? > > If we had more devops capacity we could mitigate the Marge-spoilage > problem by teaching Marge not to consider MRs which are failing lints. > However, at the moment I don't think we have the bandwidth to implement > this. > > Cheers, > > - Ben > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sven.tennie at gmail.com Thu Feb 10 08:25:12 2022 From: sven.tennie at gmail.com (Sven Tennie) Date: Thu, 10 Feb 2022 09:25:12 +0100 Subject: the linters are killing me slowly In-Reply-To: <010f017ee1ab98f5-95ae87bf-c083-410e-a7a6-5b38d7d220fd-000000@us-east-2.amazonses.com> References: <010f017edfe7da82-48d79a3d-6d10-46fb-85ef-ff82d913dd36-000000@us-east-2.amazonses.com> <8735kro4u2.fsf@smart-cactus.org> <010f017ee1ab98f5-95ae87bf-c083-410e-a7a6-5b38d7d220fd-000000@us-east-2.amazonses.com> Message-ID: Hi Richard, Am Do., 10. Feb. 2022 um 04:29 Uhr schrieb Richard Eisenberg < lists at richarde.dev>: > [...] > > I do think there is a very happy resolution to all of this: put these lint > checks in the testsuite. I believe that was Matthew's idea in yesterday's > call, and I think that solves the problem very nicely. Errors get reported > concurrently with other errors, a contributor can run the checks locally, > and it seems possible to get the linters runnable even without a built GHC. > (For example, even if the testsuite requires building GHC, the lint tests > can call some lint-ghc script. But, of course, contributors can call > lint-ghc directly, too.) > > Would that satisfy our needs here? > What do you think about the idea of having a Hadrian target ready-for-ci (or something like this) that would run all simple checks? That target should be executed before you push your changes. Of course, no one would force you to do so, but that way you could exchange local CPU cycles for CI waiting time... What "simple" means would of course have to be discussed, I would count at least linters as simple and maybe ghc-in-ghci. This idea is very similar to putting the linters into the testsuite. The difference is mainly the place where the checks are implemented and the UX. Best regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Thu Feb 10 08:43:07 2022 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 10 Feb 2022 08:43:07 +0000 Subject: the linters are killing me slowly In-Reply-To: <010f017edfe7da82-48d79a3d-6d10-46fb-85ef-ff82d913dd36-000000@us-east-2.amazonses.com> References: <010f017edfe7da82-48d79a3d-6d10-46fb-85ef-ff82d913dd36-000000@us-east-2.amazonses.com> Message-ID: I think we could run the linters in the same step as the rest of the builds. As long as the hadrian-ghci job runs as the initial step to weed out any obviously bad commits. On Wed, Feb 9, 2022 at 7:15 PM Richard Eisenberg wrote: > > Hi devs, > > Can we please, please not have the linters stop more useful output during CI? Over the past few months, I've lost several days of productivity due to the current design. Why several days? Because I typically end up with only 1.5-2 hours for GHC work in a day, and when I have to spend half of that recreating test results (which, sometimes, don't work, especially if I use Hadrian, as recommended), I often decide to prioritize other tasks that I have a more reasonable chance of actually finishing. > > It was floated some time ago that "Draft" MRs could skip linters. But I actually have a non-Draft MR now, and it failed the new Notes linter. (Why, actually, is that even a separate pass? I thought there was a test case for that, which I'm thrilled with.) > > It just feels to me that the current workflow is optimized for those of us who work on GHC close to 100% of the time. This is not the way to get new contributors. > > Frustrated, > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From Gergo.Erdi at sc.com Thu Feb 10 09:40:15 2022 From: Gergo.Erdi at sc.com (Erdi, Gergo) Date: Thu, 10 Feb 2022 09:40:15 +0000 Subject: Where do I put the *definition* of a DFunId? Message-ID: PUBLIC PUBLIC Hi, I'm trying to make a module out of thin air and register it to GHC so that other modules can import it. So far, I have had success with making a ModIface and a ModDetails, and then registering them using the following function: registerModule :: (GhcMonad m) => ModIface -> ModDetails -> m () registerModule iface details = modifySession $ extendHpt . addModule where mod_info = HomeModInfo iface details Nothing mod = mi_module iface modOrig = ModOrigin (Just True) [] [] True addModule = modifyUnitState $ \us -> us { moduleNameProvidersMap = M.insert (moduleName mod) (M.singleton mod modOrig) $ moduleNameProvidersMap us } extendHpt env = env { hsc_unit_env = let ue = hsc_unit_env env in ue { ue_hpt = hpt } } where hpt = addToHpt (hsc_HPT env) (moduleName mod) mod_info This worked when I was only _declaring_ functions and TyCons in these modules. However, now I would also like to add instances. And I'm hitting a problem here, because I don't know where to put the actual definitions of the instance. I'm completely lost here. Here's what I'm doing in detail. First, I make a fresh DFunId from a fresh Unique: let tag = occNameString . getDFunTyKey $ ty occ = mkDFunOcc (occNameString (getOccName showClass) <> tag) False emptyOccSet name = mkExternalName uniq mod occ loc dfun = mkDictFunId name [] [] showClass [ty] Then, I make a ClsInst that describes my instance: return ClsInst { is_cls_nm = getName showClass , is_tcs = [KnownTc $ getName tycon] , is_dfun_name = getName dfun , is_tvs = [] , is_cls = showClass , is_tys = [ty] , is_dfun = dfun , is_flag = OverlapFlag (NoOverlap NoSourceText) False , is_orphan = NotOrphan (getOccName $ getName tycon) } And then I add 'AnId dfun' to my ModDetails's type env in 'md_types',, add the instance to the 'md_insts', and fill the 'mi_decls' and 'mi_insts' of the ModIface accordingly. This gives me a ModIface/ModDetails pair just like before - but I never said what the definition of 'dfun' is! When I try compiling a real source module that imports this synthetic module and tries to use the instance, it gets as far as the "Desugar (after optimization)" step, and then fails with: ghc-mu-core-to-exp: panic! (the 'impossible' happened) GHC version 9.3.20211130: lookupIdSubst $fShowOrderPolicy InScope {foo mapM_} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/GHC/Utils/Panic.hs:181:37 in ghc-lib-0.20211130-7QA7vLTw0OYJmMsraoHe3v:GHC.Utils.Panic pprPanic, called at compiler/GHC/Core/Subst.hs:260:17 in ghc-lib-0.20211130-7QA7vLTw0OYJmMsraoHe3v:GHC.Core.Subst I'm not surprised that eventually it crashes and burns, because, again, I have only declared my DFunId ('$fShowOrderPolicy' in this case), but never defined it. Its definition would be a CoreExpr, right? So where would I put the pair of '(dfun, myCoreExprOfTheRightType)' for GHC to pick it up? Or is it the case that GHC would only need an 'Id's definition if it is trying to inline/specialize it, i.e. should I just attach the definition to the DFunId as an unfolding? Or is 'registerModule' already incomplete and it should put the 'CoreProgram' of the module to somewhere deep in the GHC state? 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 lists at richarde.dev Thu Feb 10 13:20:19 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Thu, 10 Feb 2022 13:20:19 +0000 Subject: the linters are killing me slowly In-Reply-To: References: <010f017edfe7da82-48d79a3d-6d10-46fb-85ef-ff82d913dd36-000000@us-east-2.amazonses.com> <8735kro4u2.fsf@smart-cactus.org> <010f017ee1ab98f5-95ae87bf-c083-410e-a7a6-5b38d7d220fd-000000@us-east-2.amazonses.com> Message-ID: <010f017ee3cab4ee-da152f9c-9e2e-4d0b-b44f-8fbf664e1aaa-000000@us-east-2.amazonses.com> > On Feb 10, 2022, at 3:25 AM, Sven Tennie wrote: > > > What do you think about the idea of having a Hadrian target ready-for-ci (or something like this) that would run all simple checks? That could work. But my experience with the current linters is that local execution gives different results than the execution in CI. Somehow, the CI execution is clever enough to flag only new breakages (or breakages in files that have been touched, perhaps), whereas when I've run existing linters locally, I get a slew of reports that are unrelated to my work. I suppose the same problem could come up if the linters are in the testsuite, though. Richard From nr at cs.tufts.edu Thu Feb 10 23:31:56 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Thu, 10 Feb 2022 18:31:56 -0500 Subject: the linters are killing me slowly In-Reply-To: (sfid-H-20220210-090241-+149.71-1@multi.osbf.lua) References: <010f017edfe7da82-48d79a3d-6d10-46fb-85ef-ff82d913dd36-000000@us-east-2.amazonses.com> <8735kro4u2.fsf@smart-cactus.org> <010f017ee1ab98f5-95ae87bf-c083-410e-a7a6-5b38d7d220fd-000000@us-east-2.amazonses.com> (sfid-H-20220210-090241-+149.71-1@multi.osbf.lua) Message-ID: <20220210233156.E05E52C2CC6@homedog.cs.tufts.edu> > What do you think about the idea of having a Hadrian target ready-for-ci > (or something like this) that would run all simple checks? I *love* this idea! Norman From simon.peytonjones at gmail.com Fri Feb 11 10:03:41 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Fri, 11 Feb 2022 10:03:41 +0000 Subject: Where do I put the *definition* of a DFunId? In-Reply-To: References: Message-ID: A `ModDetails` gives the type signatures for everything, but no actual code. For example if you have `f :: Int -> Int` in the `md_types`, the `ModDetails` doesn't include the binding `f = rhs` for `f`. Presumably you must also be generating these bindings (in a `ModGuts` perhaps?) and generating code for them that will ultimately be linked into the program to run. Well, put the `DFunId` binding in the same place, alongside `f`. Does that help? Simon On Thu, 10 Feb 2022 at 09:49, Erdi, Gergo via ghc-devs wrote: > PUBLIC > > PUBLIC > > Hi, > > > > I’m trying to make a module out of thin air and register it to GHC so that > other modules can import it. So far, I have had success with making a > ModIface and a ModDetails, and then registering them using the following > function: > > > > registerModule :: (GhcMonad m) => ModIface -> ModDetails -> m () > > registerModule iface details = modifySession $ extendHpt . addModule > > where > > mod_info = HomeModInfo iface details Nothing > > > > mod = mi_module iface > > modOrig = ModOrigin (Just True) [] [] True > > > > addModule = modifyUnitState $ \us -> us > > { moduleNameProvidersMap = M.insert (moduleName mod) (M.singleton > mod modOrig) $ moduleNameProvidersMap us > > } > > > > extendHpt env = env > > { hsc_unit_env = let ue = hsc_unit_env env in ue > > { ue_hpt = hpt > > } > > } > > > > where > > hpt = addToHpt (hsc_HPT env) (moduleName mod) mod_info > > > > > > This worked when I was only _*declaring*_ functions and TyCons in these > modules. However, now I would also like to add instances. And I’m hitting a > problem here, because I don’t know where to put the actual definitions of > the instance. I’m completely lost here. > > > > Here’s what I’m doing in detail. First, I make a fresh DFunId from a fresh > Unique: > > > > let tag = occNameString . getDFunTyKey $ ty > > occ = mkDFunOcc (occNameString (getOccName showClass) <> tag) > False emptyOccSet > > name = mkExternalName uniq mod occ loc > > dfun = mkDictFunId name [] [] showClass [ty] > > > > Then, I make a ClsInst that describes my instance: > > > > return ClsInst > > { is_cls_nm = getName showClass > > , is_tcs = [KnownTc $ getName tycon] > > , is_dfun_name = getName dfun > > , is_tvs = [] > > , is_cls = showClass > > , is_tys = [ty] > > , is_dfun = dfun > > , is_flag = OverlapFlag (NoOverlap NoSourceText) False > > , is_orphan = NotOrphan (getOccName $ getName tycon) > > } > > > > And then I add ‘AnId dfun’ to my ModDetails’s type env in ‘md_types’,, add > the instance to the ‘md_insts’, and fill the ‘mi_decls’ and ‘mi_insts’ of > the ModIface accordingly. This gives me a ModIface/ModDetails pair just > like before – but I never said what the definition of ‘dfun’ is! > > > > When I try compiling a real source module that imports this synthetic > module and tries to use the instance, it gets as far as the “Desugar (after > optimization)” step, and then fails with: > > > > ghc-mu-core-to-exp: panic! (the 'impossible' happened) > > GHC version 9.3.20211130: > > lookupIdSubst > > > > $fShowOrderPolicy > > InScope {foo mapM_} > > Call stack: > > CallStack (from HasCallStack): > > callStackDoc, called at compiler/GHC/Utils/Panic.hs:181:37 in > ghc-lib-0.20211130-7QA7vLTw0OYJmMsraoHe3v:GHC.Utils.Panic > > pprPanic, called at compiler/GHC/Core/Subst.hs:260:17 in > ghc-lib-0.20211130-7QA7vLTw0OYJmMsraoHe3v:GHC.Core.Subst > > > > > > I’m not surprised that eventually it crashes and burns, because, again, I > have only declared my DFunId (‘$fShowOrderPolicy’ in this case), but never > defined it. Its definition would be a CoreExpr, right? So where would I put > the pair of ‘(dfun, myCoreExprOfTheRightType)’ for GHC to pick it up? Or is > it the case that GHC would only need an ‘Id’s definition if it is trying to > inline/specialize it, i.e. should I just attach the definition to the > DFunId as an unfolding? Or is ‘registerModule’ already incomplete and it > should put the ‘CoreProgram’ of the module to somewhere deep in the GHC > state? > > > > 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. > _______________________________________________ > 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 at erdi.hu Fri Feb 11 10:41:04 2022 From: gergo at erdi.hu (=?ISO-8859-2?Q?=C9RDI_Gerg=F5?=) Date: Fri, 11 Feb 2022 18:41:04 +0800 (+08) Subject: Where do I put the *definition* of a DFunId? In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022, Simon Peyton Jones wrote: > A `ModDetails` gives the type signatures for everything, but no actual code.  For > example if you have `f :: Int -> Int` in the `md_types`, the `ModDetails` doesn't > include the binding `f = rhs` for `f`. Yes, this on its own makes sense. > Presumably you must also be generating these bindings (in a `ModGuts` perhaps?) and > generating code for them that will ultimately be linked into the program to run. I am not generating a `ModGuts`. My intention is to use these instances from "normal" (hand-written) source input to GHC. GHC should use the `DFunUnfolding`s during specialization to get rid of overloaded code, after which I should have inlined-due-to-specialization versions of my definitions. > Well, put the `DFunId` binding in the same place, alongside `f`. For the sake of argument, suppose that I did make a `ModGuts`. In that case, what kind of internal state would be updated based on the contents of that `ModGuts` such that references to my `DFunId` would work? From gergo at erdi.hu Fri Feb 11 10:52:45 2022 From: gergo at erdi.hu (=?ISO-8859-2?Q?=C9RDI_Gerg=F5?=) Date: Fri, 11 Feb 2022 18:52:45 +0800 (+08) Subject: Where do I put the *definition* of a DFunId? In-Reply-To: References: Message-ID: On Fri, 11 Feb 2022, ÉRDI Gergő wrote: >> Presumably you must also be generating these bindings (in a `ModGuts` >> perhaps?) and >> generating code for them that will ultimately be linked into the program to >> run. BTW, I thought that linking is done on the object file level, i.e. I thought it is perfectly kosher to reference a term-level thing only by Id, with no definition around, as long as later there will be an object file that provides a suitably name-mangled symbol? Is this not true and GHC requires to see the definitions of all referenced Ids? From nr at cs.tufts.edu Fri Feb 11 20:59:11 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Fri, 11 Feb 2022 15:59:11 -0500 Subject: install stage0 libraries? Message-ID: <20220211205911.1EE802C2CDB@homedog.cs.tufts.edu> If I understand correctly, the way Hadrian works is that all of the .conf files, binaries, and so on in _build/stage0 are built with the bootstrap compiler. I need to write client code that uses the ghc library built from GHC HEAD (so ghc-9.3), but I'd prefer to use the bootstrap compiler. (The HLS works with the bootstrap compiler.) Is there a way to get Hadrian to install the stage0 libraries in a way that cabal-install can find it using standard options? I tried to do it myself using `ghc-pkg register`, and all I accomplished was to make an unrecoverable mess of my system. (The problem I'm trying to solve is to get my client code to compile against the latest library, while also enabling the HLS to find all the things.) Norman From Gergo.Erdi at sc.com Wed Feb 16 02:56:01 2022 From: Gergo.Erdi at sc.com (Erdi, Gergo) Date: Wed, 16 Feb 2022 02:56:01 +0000 Subject: Where do I put the *definition* of a DFunId? In-Reply-To: References: Message-ID: PUBLIC > I'm not surprised that eventually it crashes and burns, because, > again, I have only declared my DFunId ('$fShowOrderPolicy' in this > case), but never defined it. Its definition would be a CoreExpr, > right? So where would I put the pair of '(dfun, > myCoreExprOfTheRightType)' for GHC to pick it up? Or is it the case > that GHC would only need an 'Id's definition if it is trying to > inline/specialize it, i.e. should I just attach the definition to the > DFunId as an unfolding? Or is 'registerModule' already incomplete and > it should put the 'CoreProgram' of the module to somewhere deep in the > GHC state? I tried adding a reasonable-looking unfolding to the DFun, but I am still getting the same error when compiling code that uses the instance: $fShowOrderPolicy [InlPrag=CONLIKE] :: Show OrderPolicy [LclIdX[DFunId], Unf=DFun: \ -> C:Show \ _ [Occ=Dead] -> unpackCStringUtf8# "foo"# \ _ [Occ=Dead] _ [Occ=Dead] _ [Occ=Dead] -> unpackCStringUtf8# "bar"# \ _ [Occ=Dead] _ [Occ=Dead] -> unpackCStringUtf8# "baz"#] panic! (the 'impossible' happened) GHC version 9.3.20211130: lookupIdSubst $fShowOrderPolicy InScope {foo mapM_} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/GHC/Utils/Panic.hs:181:37 in ghc-lib-0.20211130-7QA7vLTw0OYJmMsraoHe3v:GHC.Utils.Panic pprPanic, called at compiler/GHC/Core/Subst.hs:260:17 in ghc-lib-0.20211130-7QA7vLTw0OYJmMsraoHe3v:GHC.Core.Subst I have added a minimal working reproducer to https://gitlab.haskell.org/ghc/ghc/-/issues/21080 So the question remains, where do I need to put the DFun's definition (a CoreExpr of the right type) for it to be usable as an instance? 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 nr at cs.tufts.edu Fri Feb 18 16:56:41 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Fri, 18 Feb 2022 11:56:41 -0500 Subject: struggling to get master to build Message-ID: <20220218165641.4E56D2C2718@homedog.cs.tufts.edu> I recently pulled to bring my local copy of GHC HEAD up to 67dd5724297094af93be1887ef000845722c6f2b. But I cannot seem to get it to build. I'm following these steps: git pull --ff-only --prune --recurse-submodules --force rm -r _build ./boot ./configure ./hadrian build -j The build is failing with this error message: Warning: -rtsopts and -with-rtsopts have no effect with -shared. Call hs_init_ghc() from your main() function to set these options. ld.lld: error: can't create dynamic relocation R_X86_64_64 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in _build/stage1/rts/build/S/adjustor/NativeAmd64Asm.thr_dyn_o >>> referenced by _build/stage1/rts/build/S/adjustor/NativeAmd64Asm.thr_dyn_o:(.text+0x50) collect2: error: ld returned 1 exit status `cc' failed in phase `Linker'. (Exit code: 1) Command failed Build failed. The offending command is very long indeed; it is appended to this message. What am I doing wrong, and what do I need to change? Norman Command line: _build/stage0/bin/ghc -Wall -Wcompat -hisuf thr_dyn_hi -osuf thr_dyn_o -hcsuf thr_dyn_hc -fPIC -dynamic -optc-DTHREADED_RTS -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id rts-1.0.2' -i -i/home/nr/asterius/ghc/_build/stage1/rts/build -i/home/nr/asterius/ghc/_build/stage1/rts/build/autogen -i/home/nr/asterius/ghc/rts -Irts/include -I_build/stage1/rts/build -I_build/stage1/rts/build/include -Irts/include -optP-include -optP_build/stage1/rts/build/autogen/cabal_macros.h -ghcversion-file=rts/include/ghcversion.h -outputdir _build/stage1/rts/build -fdiagnostics-color=always -dynamic -shared -dynload deploy -optl-Wl,-rpath,$ORIGIN -optl-Wl,-zorigin -fno-use-rpaths -no-auto-link-packages -rtsopts -lc -lm -lrt -ldl -lpthread -lnuma -L_build/stage1/rts/build -lffi -Wnoncanonical-monad-instances -optc-Wno-error=inline -optP-Wno-nonportable-include-path _build/stage1/rts/build/S/adjustor/NativeAmd64Asm.thr_dyn_o _build/stage1/rts/build/c/Adjustor.thr_dyn_o _build/stage1/rts/build/c/adjustor/AdjustorPool.thr_dyn_o _build/stage1/rts/build/c/ExecPage.thr_dyn_o _build/stage1/rts/build/c/Arena.thr_dyn_o _build/stage1/rts/build/c/Capability.thr_dyn_o _build/stage1/rts/build/c/CheckUnload.thr_dyn_o _build/stage1/rts/build/c/CloneStack.thr_dyn_o _build/stage1/rts/build/c/ClosureFlags.thr_dyn_o _build/stage1/rts/build/c/ClosureSize.thr_dyn_o _build/stage1/rts/build/c/Disassembler.thr_dyn_o _build/stage1/rts/build/c/FileLock.thr_dyn_o _build/stage1/rts/build/c/ForeignExports.thr_dyn_o _build/stage1/rts/build/c/Globals.thr_dyn_o _build/stage1/rts/build/c/Hash.thr_dyn_o _build/stage1/rts/build/c/Heap.thr_dyn_o _build/stage1/rts/build/c/Hpc.thr_dyn_o _build/stage1/rts/build/c/HsFFI.thr_dyn_o _build/stage1/rts/build/c/Inlines.thr_dyn_o _build/stage1/rts/build/c/Interpreter.thr_dyn_o _build/stage1/rts/build/c/IOManager.thr_dyn_o _build/stage1/rts/build/c/LdvProfile.thr_dyn_o _build/stage1/rts/build/c/Libdw.thr_dyn_o _build/stage1/rts/build/c/LibdwPool.thr_dyn_o _build/stage1/rts/build/c/Linker.thr_dyn_o _build/stage1/rts/build/c/ReportMemoryMap.thr_dyn_o _build/stage1/rts/build/c/Messages.thr_dyn_o _build/stage1/rts/build/c/OldARMAtomic.thr_dyn_o _build/stage1/rts/build/c/PathUtils.thr_dyn_o _build/stage1/rts/build/c/Pool.thr_dyn_o _build/stage1/rts/build/c/Printer.thr_dyn_o _build/stage1/rts/build/c/ProfHeap.thr_dyn_o _build/stage1/rts/build/c/ProfilerReport.thr_dyn_o _build/stage1/rts/build/c/ProfilerReportJson.thr_dyn_o _build/stage1/rts/build/c/Profiling.thr_dyn_o _build/stage1/rts/build/c/IPE.thr_dyn_o _build/stage1/rts/build/c/Proftimer.thr_dyn_o _build/stage1/rts/build/c/RaiseAsync.thr_dyn_o _build/stage1/rts/build/c/RetainerProfile.thr_dyn_o _build/stage1/rts/build/c/RetainerSet.thr_dyn_o _build/stage1/rts/build/c/RtsAPI.thr_dyn_o _build/stage1/rts/build/c/RtsDllMain.thr_dyn_o _build/stage1/rts/build/c/RtsFlags.thr_dyn_o _build/stage1/rts/build/c/RtsMain.thr_dyn_o _build/stage1/rts/build/c/RtsMessages.thr_dyn_o _build/stage1/rts/build/c/RtsStartup.thr_dyn_o _build/stage1/rts/build/c/RtsSymbolInfo.thr_dyn_o _build/stage1/rts/build/c/RtsSymbols.thr_dyn_o _build/stage1/rts/build/c/RtsUtils.thr_dyn_o _build/stage1/rts/build/c/STM.thr_dyn_o _build/stage1/rts/build/c/Schedule.thr_dyn_o _build/stage1/rts/build/c/Sparks.thr_dyn_o _build/stage1/rts/build/c/SpinLock.thr_dyn_o _build/stage1/rts/build/c/StableName.thr_dyn_o _build/stage1/rts/build/c/StablePtr.thr_dyn_o _build/stage1/rts/build/c/StaticPtrTable.thr_dyn_o _build/stage1/rts/build/c/Stats.thr_dyn_o _build/stage1/rts/build/c/StgCRun.thr_dyn_o _build/stage1/rts/build/c/StgPrimFloat.thr_dyn_o _build/stage1/rts/build/c/Task.thr_dyn_o _build/stage1/rts/build/c/ThreadLabels.thr_dyn_o _build/stage1/rts/build/c/ThreadPaused.thr_dyn_o _build/stage1/rts/build/c/Threads.thr_dyn_o _build/stage1/rts/build/c/Ticky.thr_dyn_o _build/stage1/rts/build/c/Timer.thr_dyn_o _build/stage1/rts/build/c/TopHandler.thr_dyn_o _build/stage1/rts/build/c/Trace.thr_dyn_o _build/stage1/rts/build/c/TraverseHeap.thr_dyn_o _build/stage1/rts/build/c/TraverseHeapTest.thr_dyn_o _build/stage1/rts/build/c/WSDeque.thr_dyn_o _build/stage1/rts/build/c/Weak.thr_dyn_o _build/stage1/rts/build/c/eventlog/EventLog.thr_dyn_o _build/stage1/rts/build/c/eventlog/EventLogWriter.thr_dyn_o _build/stage1/rts/build/c/hooks/FlagDefaults.thr_dyn_o _build/stage1/rts/build/c/hooks/LongGCSync.thr_dyn_o _build/stage1/rts/build/c/hooks/MallocFail.thr_dyn_o _build/stage1/rts/build/c/hooks/OnExit.thr_dyn_o _build/stage1/rts/build/c/hooks/OutOfHeap.thr_dyn_o _build/stage1/rts/build/c/hooks/StackOverflow.thr_dyn_o _build/stage1/rts/build/c/linker/CacheFlush.thr_dyn_o _build/stage1/rts/build/c/linker/Elf.thr_dyn_o _build/stage1/rts/build/c/linker/LoadArchive.thr_dyn_o _build/stage1/rts/build/c/linker/M32Alloc.thr_dyn_o _build/stage1/rts/build/c/linker/MMap.thr_dyn_o _build/stage1/rts/build/c/linker/MachO.thr_dyn_o _build/stage1/rts/build/c/linker/macho/plt.thr_dyn_o _build/stage1/rts/build/c/linker/macho/plt_aarch64.thr_dyn_o _build/stage1/rts/build/c/linker/PEi386.thr_dyn_o _build/stage1/rts/build/c/linker/SymbolExtras.thr_dyn_o _build/stage1/rts/build/c/linker/elf_got.thr_dyn_o _build/stage1/rts/build/c/linker/elf_plt.thr_dyn_o _build/stage1/rts/build/c/linker/elf_plt_aarch64.thr_dyn_o _build/stage1/rts/build/c/linker/elf_plt_arm.thr_dyn_o _build/stage1/rts/build/c/linker/elf_reloc.thr_dyn_o _build/stage1/rts/build/c/linker/elf_reloc_aarch64.thr_dyn_o _build/stage1/rts/build/c/linker/elf_tlsgd.thr_dyn_o _build/stage1/rts/build/c/linker/elf_util.thr_dyn_o _build/stage1/rts/build/c/sm/BlockAlloc.thr_dyn_o _build/stage1/rts/build/c/sm/CNF.thr_dyn_o _build/stage1/rts/build/c/sm/Compact.thr_dyn_o _build/stage1/rts/build/c/sm/Evac.thr_dyn_o _build/stage1/rts/build/c/sm/Evac_thr.thr_dyn_o _build/stage1/rts/build/c/sm/GC.thr_dyn_o _build/stage1/rts/build/c/sm/GCAux.thr_dyn_o _build/stage1/rts/build/c/sm/GCUtils.thr_dyn_o _build/stage1/rts/build/c/sm/MBlock.thr_dyn_o _build/stage1/rts/build/c/sm/MarkWeak.thr_dyn_o _build/stage1/rts/build/c/sm/NonMoving.thr_dyn_o _build/stage1/rts/build/c/sm/NonMovingCensus.thr_dyn_o _build/stage1/rts/build/c/sm/NonMovingMark.thr_dyn_o _build/stage1/rts/build/c/sm/NonMovingScav.thr_dyn_o _build/stage1/rts/build/c/sm/NonMovingShortcut.thr_dyn_o _build/stage1/rts/build/c/sm/NonMovingSweep.thr_dyn_o _build/stage1/rts/build/c/sm/Sanity.thr_dyn_o _build/stage1/rts/build/c/sm/Scav.thr_dyn_o _build/stage1/rts/build/c/sm/Scav_thr.thr_dyn_o _build/stage1/rts/build/c/sm/Storage.thr_dyn_o _build/stage1/rts/build/c/sm/Sweep.thr_dyn_o _build/stage1/rts/build/c/fs.thr_dyn_o _build/stage1/rts/build/c/adjustor/NativeAmd64.thr_dyn_o _build/stage1/rts/build/c/posix/GetEnv.thr_dyn_o _build/stage1/rts/build/c/posix/GetTime.thr_dyn_o _build/stage1/rts/build/c/posix/Ticker.thr_dyn_o _build/stage1/rts/build/c/posix/OSMem.thr_dyn_o _build/stage1/rts/build/c/posix/OSThreads.thr_dyn_o _build/stage1/rts/build/c/posix/Select.thr_dyn_o _build/stage1/rts/build/c/posix/Signals.thr_dyn_o _build/stage1/rts/build/c/posix/TTY.thr_dyn_o _build/stage1/rts/build/cmm/Apply.thr_dyn_o _build/stage1/rts/build/cmm/Compact.thr_dyn_o _build/stage1/rts/build/cmm/Exception.thr_dyn_o _build/stage1/rts/build/cmm/HeapStackCheck.thr_dyn_o _build/stage1/rts/build/cmm/PrimOps.thr_dyn_o _build/stage1/rts/build/cmm/StgMiscClosures.thr_dyn_o _build/stage1/rts/build/cmm/StgStartup.thr_dyn_o _build/stage1/rts/build/cmm/StgStdThunks.thr_dyn_o _build/stage1/rts/build/cmm/Updates.thr_dyn_o _build/stage1/rts/build/cmm/AutoApply.thr_dyn_o -o _build/stage1/rts/build/libHSrts-1.0.2_thr-ghc9.3.20220217.so -O2 -H32m -this-unit-id rts -XHaskell98 -no-global-package-db -package-db=/home/nr/asterius/ghc/_build/stage1/lib/package.conf.d -ghcversion-file=rts/include/ghcversion.h -haddock -Irts -I_build/stage1/rts/build '-DRtsWay="rts_thr_dyn"' -DFS_NAMESPACE=rts -DCOMPILING_RTS -DTHREADED_RTS -Wno-deprecated-flags -Wcpp-undef ===> Command failed with error code: 1 From ben at smart-cactus.org Fri Feb 18 17:29:41 2022 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 18 Feb 2022 12:29:41 -0500 Subject: struggling to get master to build In-Reply-To: <20220218165641.4E56D2C2718@homedog.cs.tufts.edu> References: <20220218165641.4E56D2C2718@homedog.cs.tufts.edu> Message-ID: <8735kgytg0.fsf@smart-cactus.org> Norman Ramsey writes: > I recently pulled to bring my local copy of GHC HEAD up to > 67dd5724297094af93be1887ef000845722c6f2b. But I cannot seem > to get it to build. > > I'm following these steps: > > git pull --ff-only --prune --recurse-submodules --force > > rm -r _build > > ./boot > > ./configure > > ./hadrian build -j > > The build is failing with this error message: > > Warning: -rtsopts and -with-rtsopts have no effect with -shared. > Call hs_init_ghc() from your main() function to set these options. > ld.lld: error: can't create dynamic relocation R_X86_64_64 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output > >>> defined in _build/stage1/rts/build/S/adjustor/NativeAmd64Asm.thr_dyn_o > >>> referenced by _build/stage1/rts/build/S/adjustor/NativeAmd64Asm.thr_dyn_o:(.text+0x50) > collect2: error: ld returned 1 exit status > `cc' failed in phase `Linker'. (Exit code: 1) > Command failed > Build failed. > > The offending command is very long indeed; it is appended to this message. > It looks like this may be fall-out from !7511, presumably because lld apparently disallows text relocations by default. This is presumably Linux; which distribution are you using? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Fri Feb 18 17:35:45 2022 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 18 Feb 2022 12:35:45 -0500 Subject: struggling to get master to build In-Reply-To: <20220218165641.4E56D2C2718@homedog.cs.tufts.edu> References: <20220218165641.4E56D2C2718@homedog.cs.tufts.edu> Message-ID: <87zgmoxele.fsf@smart-cactus.org> Norman Ramsey writes: > I recently pulled to bring my local copy of GHC HEAD up to > 67dd5724297094af93be1887ef000845722c6f2b. But I cannot seem > to get it to build. > > I'm following these steps: > > git pull --ff-only --prune --recurse-submodules --force > > rm -r _build > > ./boot > > ./configure > > ./hadrian build -j > > The build is failing with this error message: > > Warning: -rtsopts and -with-rtsopts have no effect with -shared. > Call hs_init_ghc() from your main() function to set these options. > ld.lld: error: can't create dynamic relocation R_X86_64_64 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output > >>> defined in _build/stage1/rts/build/S/adjustor/NativeAmd64Asm.thr_dyn_o > >>> referenced by _build/stage1/rts/build/S/adjustor/NativeAmd64Asm.thr_dyn_o:(.text+0x50) > collect2: error: ld returned 1 exit status > `cc' failed in phase `Linker'. (Exit code: 1) > Command failed > Build failed. > > The offending command is very long indeed; it is appended to this message. > > What am I doing wrong, and what do I need to change? > Norman, could you open a ticket to track this and confirm that https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7604 fixes this? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From nr at cs.tufts.edu Fri Feb 18 18:03:48 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Fri, 18 Feb 2022 13:03:48 -0500 Subject: struggling to get master to build In-Reply-To: <8735kgytg0.fsf@smart-cactus.org> (sfid-H-20220218-123037-+68.78-1@multi.osbf.lua) References: <20220218165641.4E56D2C2718@homedog.cs.tufts.edu> <8735kgytg0.fsf@smart-cactus.org> (sfid-H-20220218-123037-+68.78-1@multi.osbf.lua) Message-ID: <20220218180348.3AC7F2C2636@homedog.cs.tufts.edu> > It looks like this may be fall-out from !7511, presumably because lld > apparently disallows text relocations by default. This is presumably > Linux; which distribution are you using? Debian 11 (bullseye). I'll check out the MR you mentioned, and I'll open that ticket. N From matthewtpickering at gmail.com Tue Feb 22 17:14:35 2022 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 22 Feb 2022 17:14:35 +0000 Subject: 9.4 release planning (& GHCJS merge process) Message-ID: Hi all, Firstly we are anticipating branching 9.4 in about 6 weeks time (approx start of April). Most of the major features originally milestoned[1] for this release have landed and the main branch is currently in a nice state. This timeline will be solidified once the 9.2.2 release has been completed. The major outstanding work that I am aware of is Windows toolchain work (#21019) (Ben Gamari) Partial Register Stall (#20405) (Andreas Klebinger) hi-haddock (!6224) (Zubin Duggal / Matthew Pickering ) Directed Coercions (!6476) (Sam Derbyshire) Secondly, we are anticipating adding a javascript backend inspired by GHCJS as the highlight of the 9.6 release. This work is led by the team at IOHK. * The planning and progress of this process is tracked on this wiki page - https://gitlab.haskell.org/ghc/ghc/-/wikis/javascript-backend * We anticipate reviewing and merging patches incrementally into a feature branch until the point where test coverage is suitable and the patches can be merged into the main branch. Cheers, Matt [1]: https://gitlab.haskell.org/ghc/ghc/-/milestones/370 From matthewtpickering at gmail.com Tue Feb 22 17:21:33 2022 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 22 Feb 2022 17:21:33 +0000 Subject: Well-Typed GHC team update Message-ID: Hi all, We have recently reorganised the structure of the Well-Typed team working on the GHC project. In short, I am now responsible for more of the management tasks that Ben has traditionally carried out. In particular I have responsibility for organising the work between us and keeping track of the tasks that need to be completed. With that in mind, if you need something doing, please email/ping me and not Ben with your request and I will make sure someone deals with it. On gitlab you can also notify me directly by using the @hq-shepard tag, which provides the level of indirection for when this changes again in the future. The team working at Well-Typed on GHC currently consists of Myself (Matthew Pickering) Ben Gamari Andreas Klebinger Sam Derbyshire Zubin Duggal Cheers, Matt From lists at richarde.dev Tue Feb 22 17:26:17 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Tue, 22 Feb 2022 17:26:17 +0000 Subject: Well-Typed GHC team update In-Reply-To: References: Message-ID: <010f017f2278327d-9c4b9b45-f6f8-4cb2-ba69-136b07c72017-000000@us-east-2.amazonses.com> As a wishing-I-were-more-frequent GHC contributor, I just want to say how much I appreciate the work this team is doing. Over the past year or so (maybe a little longer?), this team has expanded significantly and has become more systematized. The effect is simply wonderful. I no longer worry that GHC tickets get lost, and the responsiveness is excellent. Thank you, all, and thanks both to Well-Typed and its financial backers for making all this possible! Richard > On Feb 22, 2022, at 12:21 PM, Matthew Pickering wrote: > > Hi all, > > We have recently reorganised the structure of the Well-Typed team > working on the GHC project. > > In short, I am now responsible for more of the management tasks that > Ben has traditionally carried out. In particular I have responsibility > for organising the work between us and keeping track of the tasks that > need to be completed. > > With that in mind, if you need something doing, please email/ping me > and not Ben with your request and I will make sure someone deals with > it. On gitlab you can also notify me directly by using the @hq-shepard > tag, which provides the level of indirection for when this changes > again in the future. > > The team working at Well-Typed on GHC currently consists of > > Myself (Matthew Pickering) > Ben Gamari > Andreas Klebinger > Sam Derbyshire > Zubin Duggal > > Cheers, > > Matt > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From hecate at glitchbra.in Tue Feb 22 19:33:54 2022 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Tue, 22 Feb 2022 20:33:54 +0100 Subject: 9.4 release planning (& GHCJS merge process) In-Reply-To: References: Message-ID: <4735b972-9739-afee-110b-7b131afc66cb@glitchbra.in> Hi Matthew, thank you for this update and the other one regarding your team. I have multiple questions regarding the release: 1. Could a migration guide be provided? Or better, a script/tool? From what I understand, going from 9.2 to 9.4 means breaking changes have been introduced. 2. The 8.10 series has gained a status of LTS amongst industrial users, thanks to both the numerous backports but also the wider support in the ecosystem. Could you please clarify whether or not it will still be an LTS after this release, and the status of 9.0 and 9.2 (which have brought numerous new things themselves but seem to have been quickly replaced by the next release each time). It's quite confusing, and when the question arises in professional circles, a (seemingly) valid answer that is brought up is "We can wait 6 more months and have a breaking release that will force us to migrate painfully, let's not move yet". 3. From what I can see in the "Likely highlights" (this phrasing is unclear to me, you don't expect some of those changes to make it to the release?), it is mostly an engineering release (which is great). Do you think that the 9.4 series could benefit from the same longevity as the 8.10 did and take its place as a continuously-improved version while Language / R&D versions of GHC are published anew? 4. There was a talk of slowing the release schedule to once a year, and last I heard, Ben was sympathetic to it. Could you express the official position of your team on the matter? Again, I'd like to echo Richard's words in the other thread, thank you and your team for all this work, this is immensely appreciated. Cheers, Hécate Le 22/02/2022 à 18:14, Matthew Pickering a écrit : > Hi all, > > Firstly we are anticipating branching 9.4 in about 6 weeks time > (approx start of April). Most of the major features originally > milestoned[1] for this release have landed and the main branch is > currently in a nice state. This timeline will be solidified once the > 9.2.2 release has been completed. > > The major outstanding work that I am aware of is > > Windows toolchain work (#21019) (Ben Gamari) > Partial Register Stall (#20405) (Andreas Klebinger) > hi-haddock (!6224) (Zubin Duggal / Matthew Pickering ) > Directed Coercions (!6476) (Sam Derbyshire) > > Secondly, we are anticipating adding a javascript backend inspired by > GHCJS as the highlight of the 9.6 release. This work is led by the > team at IOHK. > > * The planning and progress of this process is tracked on this wiki > page - https://gitlab.haskell.org/ghc/ghc/-/wikis/javascript-backend > * We anticipate reviewing and merging patches incrementally into a > feature branch until the point where test coverage is suitable and the > patches can be merged into the main branch. > > Cheers, > > Matt > > > [1]: https://gitlab.haskell.org/ghc/ghc/-/milestones/370 > _______________________________________________ > 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 Wed Feb 23 09:30:39 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 23 Feb 2022 09:30:39 +0000 Subject: Well-Typed GHC team update In-Reply-To: <010f017f2278327d-9c4b9b45-f6f8-4cb2-ba69-136b07c72017-000000@us-east-2.amazonses.com> References: <010f017f2278327d-9c4b9b45-f6f8-4cb2-ba69-136b07c72017-000000@us-east-2.amazonses.com> Message-ID: Massive up-vote to what Richard says here: I really appreciate the skill, collegiality, and effectiveness of the team at Well Typed. Thank you so much. Simon On Tue, 22 Feb 2022 at 17:28, Richard Eisenberg wrote: > As a wishing-I-were-more-frequent GHC contributor, I just want to say how > much I appreciate the work this team is doing. Over the past year or so > (maybe a little longer?), this team has expanded significantly and has > become more systematized. The effect is simply wonderful. I no longer worry > that GHC tickets get lost, and the responsiveness is excellent. > > Thank you, all, and thanks both to Well-Typed and its financial backers > for making all this possible! > > Richard > > > On Feb 22, 2022, at 12:21 PM, Matthew Pickering < > matthewtpickering at gmail.com> wrote: > > > > Hi all, > > > > We have recently reorganised the structure of the Well-Typed team > > working on the GHC project. > > > > In short, I am now responsible for more of the management tasks that > > Ben has traditionally carried out. In particular I have responsibility > > for organising the work between us and keeping track of the tasks that > > need to be completed. > > > > With that in mind, if you need something doing, please email/ping me > > and not Ben with your request and I will make sure someone deals with > > it. On gitlab you can also notify me directly by using the @hq-shepard > > tag, which provides the level of indirection for when this changes > > again in the future. > > > > The team working at Well-Typed on GHC currently consists of > > > > Myself (Matthew Pickering) > > Ben Gamari > > Andreas Klebinger > > Sam Derbyshire > > Zubin Duggal > > > > Cheers, > > > > Matt > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Wed Feb 23 15:55:16 2022 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 23 Feb 2022 15:55:16 +0000 Subject: 9.4 release planning (& GHCJS merge process) In-Reply-To: <4735b972-9739-afee-110b-7b131afc66cb@glitchbra.in> References: <4735b972-9739-afee-110b-7b131afc66cb@glitchbra.in> Message-ID: 1. We will provide a migration guide. The draft for the guide is located here - https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.4 2. 8.10 has never officially been an LTS but due to various reasons has been a larger number of backports than other releases. I suggest that the decision about whether the 9.4 release will attain a similar status is left to the community rather than us (the developers) who lack perspective about how companies are using releases unless explicitly told about it. 3. The likely highlights was a list produced by Ben after the 9.2 release was finalised. Most (if not all) the features on the list will be present in the release. Of course, comprehensive release notes will be produced which detail all the new features and changes. 4. It is an unfortunate fact that whatever the proposed release schedule has been that the releases have never actually come at those timings. Again, I think we have to defer the question about release frequency to the wider community. The decision about this release cycle was made after considering the state of the master branch, which features we wanted in the release and the availability of the release managers. Cheers, Matt On Tue, Feb 22, 2022 at 7:34 PM Hécate wrote: > > Hi Matthew, thank you for this update and the other one regarding your team. > > I have multiple questions regarding the release: > > 1. Could a migration guide be provided? Or better, a script/tool? From > what I understand, going from 9.2 to 9.4 means breaking changes have > been introduced. > > 2. The 8.10 series has gained a status of LTS amongst industrial users, > thanks to both the numerous backports but also the wider support in the > ecosystem. Could you please clarify whether or not it will still be an > LTS after this release, and the status of 9.0 and 9.2 (which have > brought numerous new things themselves but seem to have been quickly > replaced by the next release each time). It's quite confusing, and when > the question arises in professional circles, a (seemingly) valid answer > that is brought up is "We can wait 6 more months and have a breaking > release that will force us to migrate painfully, let's not move yet". > > 3. From what I can see in the "Likely highlights" (this phrasing is > unclear to me, you don't expect some of those changes to make it to the > release?), it is mostly an engineering release (which is great). Do you > think that the 9.4 series could benefit from the same longevity as the > 8.10 did and take its place as a continuously-improved version while > Language / R&D versions of GHC are published anew? > > 4. There was a talk of slowing the release schedule to once a year, and > last I heard, Ben was sympathetic to it. Could you express the official > position of your team on the matter? > > Again, I'd like to echo Richard's words in the other thread, thank you > and your team for all this work, this is immensely appreciated. > > Cheers, > Hécate > > Le 22/02/2022 à 18:14, Matthew Pickering a écrit : > > Hi all, > > > > Firstly we are anticipating branching 9.4 in about 6 weeks time > > (approx start of April). Most of the major features originally > > milestoned[1] for this release have landed and the main branch is > > currently in a nice state. This timeline will be solidified once the > > 9.2.2 release has been completed. > > > > The major outstanding work that I am aware of is > > > > Windows toolchain work (#21019) (Ben Gamari) > > Partial Register Stall (#20405) (Andreas Klebinger) > > hi-haddock (!6224) (Zubin Duggal / Matthew Pickering ) > > Directed Coercions (!6476) (Sam Derbyshire) > > > > Secondly, we are anticipating adding a javascript backend inspired by > > GHCJS as the highlight of the 9.6 release. This work is led by the > > team at IOHK. > > > > * The planning and progress of this process is tracked on this wiki > > page - https://gitlab.haskell.org/ghc/ghc/-/wikis/javascript-backend > > * We anticipate reviewing and merging patches incrementally into a > > feature branch until the point where test coverage is suitable and the > > patches can be merged into the main branch. > > > > Cheers, > > > > Matt > > > > > > [1]: https://gitlab.haskell.org/ghc/ghc/-/milestones/370 > > _______________________________________________ > > 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 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From hecate at glitchbra.in Wed Feb 23 18:31:45 2022 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Wed, 23 Feb 2022 19:31:45 +0100 Subject: 9.4 release planning (& GHCJS merge process) In-Reply-To: References: <4735b972-9739-afee-110b-7b131afc66cb@glitchbra.in> Message-ID: <6f990538-668d-c35a-e010-df50fd4a526a@glitchbra.in> Hi Matthew! 1 & 3. Thank you very much for the information. :) 2 & 4. I'm slightly concerned that you seem to leave this kind of decision to "the community", because last time I heard, the weekly meetings of GHC developers are not necessarily advertised to said community, and I fail to see how much of a democratic process it can be if a significant portion of the decision-making process is done outside of the community that you wish to make responsible for such important things as LTS statuses  (which is widely, widely incompatible with the adoption of Haskell as a reliable foundation for industrial usage). Moreover, if memory serves well, it was the GHC DevOps Group that pushed for the 6-months release schedule (or at least I get a strong impression of it reading this thread https://mail.haskell.org/pipermail/ghc-devops-group/2017-October/000067.html). Now looking at the mailing-list and updates, it would seem that the group has disbanded, but I find it too bad that current GHCHQ doesn't take on the responsibilities that are rightfully yours. My question is: Do you intend to provide the community with the proper information and means to make a decision, or at least express their opinion? Or would you be rather more comfortable with the small subset of people who post on ghc-devs to voice their opinion on the matter and follow the trend? Is GHCHQ bound to these "community opinions"? Or can I just pay WT to have it do what I want if I wish to decide on a different course of action for the GHC release cycle. ;) There is one point that you make that is quite worrisome: > I suggest that the decision about whether the 9.4 release will attain a similar > status is left to the community rather than us (the developers) who > lack perspective about how companies are using releases unless explicitly told about it. I sincerely believe that there is something lost in translation, because from my ESL (English as a Second Language) perspective, this looks like the 5-people team in charge of the compiler do not have any say in what to release, when or even have no access to wider community information, like what the State of Haskell Ecosystem surveys provide. But maybe you'd like more help to figure out what are the broader usages of GHC, and I can assure you that the Haskell Foundation would be immensely glad to provide such insights. And just so we are clear, I have nothing to reproach in terms of engineering, it's all been wonderful from my perspective as both a hobbyist and industrial user, and I know that product management isn't necessarily the reason why you signed in on this, but it's an unfortunate and essential part of the job that I'd like to clear out, for everyone's sake.  :) Please do not take this as an attack against you and your team, and I'm truly sorry if my phrasing have led to think so. Cheers, Hécate Le 23/02/2022 à 16:55, Matthew Pickering a écrit : > 1. We will provide a migration guide. The draft for the guide is > located here - https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.4 > > 2. 8.10 has never officially been an LTS but due to various reasons > has been a larger number of backports than other releases. I suggest > that the decision about whether the 9.4 release will attain a similar > status is left to the community rather than us (the developers) who > lack perspective about > how companies are using releases unless explicitly told about it. > > 3. The likely highlights was a list produced by Ben after the 9.2 > release was finalised. Most (if not all) the features on the list will > be present in the release. Of course, comprehensive release notes will > be produced which detail all the new features and changes. > > 4. It is an unfortunate fact that whatever the proposed release > schedule has been that the releases have never actually come at those > timings. Again, I think we have to defer the question about release > frequency to the wider community. The decision about this release > cycle was made after considering the state of the master branch, which > features we wanted in the release and the availability of the release > managers. > > Cheers, > > Matt > > On Tue, Feb 22, 2022 at 7:34 PM Hécate wrote: >> Hi Matthew, thank you for this update and the other one regarding your team. >> >> I have multiple questions regarding the release: >> >> 1. Could a migration guide be provided? Or better, a script/tool? From >> what I understand, going from 9.2 to 9.4 means breaking changes have >> been introduced. >> >> 2. The 8.10 series has gained a status of LTS amongst industrial users, >> thanks to both the numerous backports but also the wider support in the >> ecosystem. Could you please clarify whether or not it will still be an >> LTS after this release, and the status of 9.0 and 9.2 (which have >> brought numerous new things themselves but seem to have been quickly >> replaced by the next release each time). It's quite confusing, and when >> the question arises in professional circles, a (seemingly) valid answer >> that is brought up is "We can wait 6 more months and have a breaking >> release that will force us to migrate painfully, let's not move yet". >> >> 3. From what I can see in the "Likely highlights" (this phrasing is >> unclear to me, you don't expect some of those changes to make it to the >> release?), it is mostly an engineering release (which is great). Do you >> think that the 9.4 series could benefit from the same longevity as the >> 8.10 did and take its place as a continuously-improved version while >> Language / R&D versions of GHC are published anew? >> >> 4. There was a talk of slowing the release schedule to once a year, and >> last I heard, Ben was sympathetic to it. Could you express the official >> position of your team on the matter? >> >> Again, I'd like to echo Richard's words in the other thread, thank you >> and your team for all this work, this is immensely appreciated. >> >> Cheers, >> Hécate >> >> Le 22/02/2022 à 18:14, Matthew Pickering a écrit : >>> Hi all, >>> >>> Firstly we are anticipating branching 9.4 in about 6 weeks time >>> (approx start of April). Most of the major features originally >>> milestoned[1] for this release have landed and the main branch is >>> currently in a nice state. This timeline will be solidified once the >>> 9.2.2 release has been completed. >>> >>> The major outstanding work that I am aware of is >>> >>> Windows toolchain work (#21019) (Ben Gamari) >>> Partial Register Stall (#20405) (Andreas Klebinger) >>> hi-haddock (!6224) (Zubin Duggal / Matthew Pickering ) >>> Directed Coercions (!6476) (Sam Derbyshire) >>> >>> Secondly, we are anticipating adding a javascript backend inspired by >>> GHCJS as the highlight of the 9.6 release. This work is led by the >>> team at IOHK. >>> >>> * The planning and progress of this process is tracked on this wiki >>> page - https://gitlab.haskell.org/ghc/ghc/-/wikis/javascript-backend >>> * We anticipate reviewing and merging patches incrementally into a >>> feature branch until the point where test coverage is suitable and the >>> patches can be merged into the main branch. >>> >>> Cheers, >>> >>> Matt >>> >>> >>> [1]: https://gitlab.haskell.org/ghc/ghc/-/milestones/370 >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> 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 hecate at glitchbra.in Thu Feb 24 11:51:51 2022 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Thu, 24 Feb 2022 12:51:51 +0100 Subject: 9.4 release planning (& GHCJS merge process) In-Reply-To: <6f990538-668d-c35a-e010-df50fd4a526a@glitchbra.in> References: <4735b972-9739-afee-110b-7b131afc66cb@glitchbra.in> <6f990538-668d-c35a-e010-df50fd4a526a@glitchbra.in> Message-ID: <3df0b963-084b-b419-30db-5a27865689e2@glitchbra.in> Following a private discussion where many historical things and processes have been described to me, I'd like to amend my previous email, as Matt & his team are indeed not the correct recipients of some of my questions. The details pertaining to a possible "official" LTS release will be addressed to those in charge of this kind of decision. Again Matt, I'm very happy that you're taking the helm for the WT team, your work has been nothing else than important and excellent for the future of Haskell. Cheers, Hécate Le 23/02/2022 à 19:31, Hécate a écrit : > Hi Matthew! > > 1 & 3. Thank you very much for the information. :) > > 2 & 4. I'm slightly concerned that you seem to leave this kind of > decision to "the community", because last time I heard, the weekly > meetings of GHC developers are not necessarily advertised to said > community, and I fail to see how much of a democratic process it can > be if a significant portion of the decision-making process is done > outside of the community that you wish to make responsible for such > important things as LTS statuses  (which is widely, widely > incompatible with the adoption of Haskell as a reliable foundation for > industrial usage). > > Moreover, if memory serves well, it was the GHC DevOps Group that > pushed for the 6-months release schedule (or at least I get a strong > impression of it reading this thread > https://mail.haskell.org/pipermail/ghc-devops-group/2017-October/000067.html). > Now looking at the mailing-list and updates, it would seem that the > group has disbanded, but I find it too bad that current GHCHQ doesn't > take on the responsibilities that are rightfully yours. > > My question is: Do you intend to provide the community with the proper > information and means to make a decision, or at least express their > opinion? Or would you be rather more comfortable with the small subset > of people who post on ghc-devs to voice their opinion on the matter > and follow the trend? Is GHCHQ bound to these "community opinions"? Or > can I just pay WT to have it do what I want if I wish to decide on a > different course of action for the GHC release cycle. ;) > > There is one point that you make that is quite worrisome: > > > I suggest that the decision about whether the 9.4 release will > attain a similar > > status is left to the community rather than us (the developers) who > > lack perspective about how companies are using releases unless > explicitly told about it. > > I sincerely believe that there is something lost in translation, > because from my ESL (English as a Second Language) perspective, this > looks like the 5-people team in charge of the compiler do not have any > say in what to release, when or even have no access to wider community > information, like what the State of Haskell Ecosystem surveys provide. > But maybe you'd like more help to figure out what are the broader > usages of GHC, and I can assure you that the Haskell Foundation would > be immensely glad to provide such insights. > > > And just so we are clear, I have nothing to reproach in terms of > engineering, it's all been wonderful from my perspective as both a > hobbyist and industrial user, and I know that product management isn't > necessarily the reason why you signed in on this, but it's an > unfortunate and essential part of the job that I'd like to clear out, > for everyone's sake.  :) > Please do not take this as an attack against you and your team, and > I'm truly sorry if my phrasing have led to think so. > > > Cheers, > Hécate > > Le 23/02/2022 à 16:55, Matthew Pickering a écrit : >> 1. We will provide a migration guide. The draft for the guide is >> located here - https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.4 >> >> 2. 8.10 has never officially been an LTS but due to various reasons >> has been a larger number of backports than other releases. I suggest >> that the decision about whether the 9.4 release will attain a similar >> status is left to the community rather than us (the developers) who >> lack perspective about >> how companies are using releases unless explicitly told about it. >> >> 3. The likely highlights was a list produced by Ben after the 9.2 >> release was finalised. Most (if not all) the features on the list will >> be present in the release. Of course, comprehensive release notes will >> be produced which detail all the new features and changes. >> >> 4. It is an unfortunate fact that whatever the proposed release >> schedule has been that the releases have never actually come at those >> timings. Again, I think we have to defer the question about release >> frequency to the wider community. The decision about this release >> cycle was made after considering the state of the master branch, which >> features we wanted in the release and the availability of the release >> managers. >> >> Cheers, >> >> Matt >> >> On Tue, Feb 22, 2022 at 7:34 PM Hécate wrote: >>> Hi Matthew, thank you for this update and the other one regarding >>> your team. >>> >>> I have multiple questions regarding the release: >>> >>> 1. Could a migration guide be provided? Or better, a script/tool? From >>> what I understand, going from 9.2 to 9.4 means breaking changes have >>> been introduced. >>> >>> 2. The 8.10 series has gained a status of LTS amongst industrial users, >>> thanks to both the numerous backports but also the wider support in the >>> ecosystem. Could you please clarify whether or not it will still be an >>> LTS after this release, and the status of 9.0 and 9.2 (which have >>> brought numerous new things themselves but seem to have been quickly >>> replaced by the next release each time). It's quite confusing, and when >>> the question arises in professional circles, a (seemingly) valid answer >>> that is brought up is "We can wait 6 more months and have a breaking >>> release that will force us to migrate painfully, let's not move yet". >>> >>> 3. From what I can see in the "Likely highlights" (this phrasing is >>> unclear to me, you don't expect some of those changes to make it to the >>> release?), it is mostly an engineering release (which is great). Do you >>> think that the 9.4 series could benefit from the same longevity as the >>> 8.10 did and take its place as a continuously-improved version while >>> Language / R&D versions of GHC are published anew? >>> >>> 4. There was a talk of slowing the release schedule to once a year, and >>> last I heard, Ben was sympathetic to it. Could you express the official >>> position of your team on the matter? >>> >>> Again, I'd like to echo Richard's words in the other thread, thank you >>> and your team for all this work, this is immensely appreciated. >>> >>> Cheers, >>> Hécate >>> >>> Le 22/02/2022 à 18:14, Matthew Pickering a écrit : >>>> Hi all, >>>> >>>> Firstly we are anticipating branching 9.4 in about 6 weeks time >>>> (approx start of April). Most of the major features originally >>>> milestoned[1] for this release have landed and the main branch is >>>> currently in a nice state. This timeline will be solidified once the >>>> 9.2.2 release has been completed. >>>> >>>> The major outstanding work that I am aware of is >>>> >>>> Windows toolchain work (#21019) (Ben Gamari) >>>> Partial Register Stall (#20405) (Andreas Klebinger) >>>> hi-haddock (!6224) (Zubin Duggal / Matthew Pickering ) >>>> Directed Coercions (!6476) (Sam Derbyshire) >>>> >>>> Secondly, we are anticipating adding a javascript backend inspired by >>>> GHCJS as the highlight of the 9.6 release. This work is led by the >>>> team at IOHK. >>>> >>>> * The planning and progress of this process is tracked on this wiki >>>> page - https://gitlab.haskell.org/ghc/ghc/-/wikis/javascript-backend >>>> * We anticipate reviewing and merging patches incrementally into a >>>> feature branch until the point where test coverage is suitable and the >>>> patches can be merged into the main branch. >>>> >>>> Cheers, >>>> >>>> Matt >>>> >>>> >>>> [1]: https://gitlab.haskell.org/ghc/ghc/-/milestones/370 >>>> _______________________________________________ >>>> 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 >>> >>> _______________________________________________ >>> 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 ben at well-typed.com Thu Feb 24 16:44:56 2022 From: ben at well-typed.com (Ben Gamari) Date: Thu, 24 Feb 2022 11:44:56 -0500 Subject: 9.4 release planning (& GHCJS merge process) In-Reply-To: <3df0b963-084b-b419-30db-5a27865689e2@glitchbra.in> References: <4735b972-9739-afee-110b-7b131afc66cb@glitchbra.in> <6f990538-668d-c35a-e010-df50fd4a526a@glitchbra.in> <3df0b963-084b-b419-30db-5a27865689e2@glitchbra.in> Message-ID: <874k4oxlho.fsf@smart-cactus.org> Hécate writes: > Following a private discussion where many historical things and > processes have been described to me, I'd like to amend my previous > email, as Matt & his team are indeed not the correct recipients of some > of my questions. > > The details pertaining to a possible "official" LTS release will be > addressed to those in charge of this kind of decision. > Indeed, while we've been quiet the stability working group has been discussing proposals for adjusting the release cycle to realize the promise of predictability that GHC has been trying to deliver in the past. Currently Chris Dornan and I are working on one such proposal, which suggests keeping the six-month release cadence but adopting a tick-tock cycle, we will commit to backporting to every other release for up to two years. The hope is that this will clearly communicate to commercial users desiring stability which releases they should adopt, while preserving the fast release cadence that ensures that new features can end up in users' hands quickly. If anyone is interested in participating in these discussions, please do be in touch. Otherwise, do expect to see a proposal before the HF Tech Track in the next few weeks. 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 Thu Feb 24 16:56:30 2022 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Thu, 24 Feb 2022 17:56:30 +0100 Subject: 9.4 release planning (& GHCJS merge process) In-Reply-To: <874k4oxlho.fsf@smart-cactus.org> References: <4735b972-9739-afee-110b-7b131afc66cb@glitchbra.in> <6f990538-668d-c35a-e010-df50fd4a526a@glitchbra.in> <3df0b963-084b-b419-30db-5a27865689e2@glitchbra.in> <874k4oxlho.fsf@smart-cactus.org> Message-ID: <0789b207-4927-a560-6727-0717c35d4ced@glitchbra.in> Hi Ben, this is really helpful for me and other commercial users. Thank you very much for clarifying this. :) Cheers, Hécate. Le 24/02/2022 à 17:44, Ben Gamari a écrit : > Hécate writes: > >> Following a private discussion where many historical things and >> processes have been described to me, I'd like to amend my previous >> email, as Matt & his team are indeed not the correct recipients of some >> of my questions. >> >> The details pertaining to a possible "official" LTS release will be >> addressed to those in charge of this kind of decision. >> > Indeed, while we've been quiet the stability working group has been > discussing proposals for adjusting the release cycle to realize the > promise of predictability that GHC has been trying to deliver in the > past. > > Currently Chris Dornan and I are working on one such proposal, which > suggests keeping the six-month release cadence but adopting a tick-tock > cycle, we will commit to backporting to every other release for up to > two years. The hope is that this will clearly communicate to commercial > users desiring stability which releases they should adopt, while > preserving the fast release cadence that ensures that new features can > end up in users' hands quickly. > > If anyone is interested in participating in these discussions, please do > be in touch. Otherwise, do expect to see a proposal before the HF Tech > Track in the next few weeks. > > Cheers, > > - Ben -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD