Re: Nofib

Hi Simon, To modify nofib, simply submit a merge request to https://gitlab.haskell.org/ghc/nofib with the appropriate change. Once it's integrated, run `git submodule update --remote` in the GHC repo to update the submodule and push the update as part of your work. Cheers, Hécate Le 10/11

Something to learn from: On Telemetry in the Rust compiler

We should all certainly learn something from reading this post on telemetry and user trust. I know I did: https://estebank.github.io/rustc-metrics.html Cheers, Hécate -- Hécate ✨ : @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

GHCi tags generation: the end

/ghc/-/wikis/commentary/GHCi/Tags Thanks to everyone who was involved in this, especially Emily Martins. Cheers, Hécate -- Hécate ✨ : @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD ___ ghc-devs mailing list ghc-devs@haskell.org http

Coordination on FreeBSD CI, default WinIO and Info Tables profiling work

it takes to do certain things. :) Please do feel free to create your own for projects that are not fit for a single milestone (or are not related to release milestones at all). Cheers, Hécate -- Hécate ✨ : @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD __

Getting Info Table Profiling to the finish line

unlocks on our side. The epic is at https://gitlab.haskell.org/groups/ghc/-/epics/3 Please feel free to link future tickets that are related to this newer, better way of doing space profiling. My thanks to Matthew Pickering, David Eichmann, and Ben Gamari. Cheers, Hécate (with a project

Re: Deprecating Safe Haskell, or heavily investing in it?

of that? Something based upon eBPF would certainly incur less modifications to the RTS? Le 27/12/2022 à 21:12, Viktor Dukhovni a écrit : On Tue, Dec 27, 2022 at 06:09:59PM +0100, Hécate wrote: Now, there are two options (convenient!) that are left to us: 1. Deprecate Safe Haskell: We remove

Deprecating Safe Haskell, or heavily investing in it?

re can be no half-measures that they usually tend to make us slide back into the status quo. So, what do you think? ¹ https://gitlab.haskell.org/ghc/ghc/-/issues/?label_name%5B%5D=Safe%20Haskell ² https://gitlab.haskell.org/ghc/ghc/-/issues/19605 ³ https://github.com/haskell/directory/is

Re: Gitlab slow?

fast per se, it's about in line with what I would expect. Are either of you seeing significantly longer load times? Cheers, - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Hécate

Re: GitLab runners having issues

___ ghc-devs mailing list ghc-devs@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@haskell.org http://mail

GHC.Pack deprecation process: Step 1

Hi everyone, As discussed earlier this year¹, the deprecation process for GHC.Pack starts with the 9.6.1 milestone². ¹ https://gitlab.haskell.org/ghc/ghc/-/issues/21461 ² https://gitlab.haskell.org/ghc/ghc/-/issues/21541 Cheers, Hécate -- Hécate ✨ : @TechnoEmpress IRC: Hecate WWW: https

Re: Release Timelines

___ ghc-devs mailing list ghc-devs@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

Re: GHC development asks too much of the host system

of ghcid, hls, ... would it be nice if ghc development would be that nice as well? I'd assume so, I've just never even tried. Cheers,  Moritz On Tue, 19 Jul 2022 at 18:21, Hécate wrote: Hello ghc-devs, I hadn't made significant contributions to the GHC code base in a while

Re: GHC development asks too much of the host system

helpful to have more information.  There may be things we can't reasonably address (e.g. make a small, light, non-optimising compiler instead, throwing away most of the code base) but I bet that sheer size isn't the only factor. Thanks! Simon On Tue, 19 Jul 2022 at 17:21, Hécate wrote:

Re: GHC development asks too much of the host system

sonably address (e.g. make a small, light, non-optimising compiler instead, throwing away most of the code base) but I bet that sheer size isn't the only factor. Thanks! Simon On Tue, 19 Jul 2022 at 17:21, Hécate wrote: Hello ghc-devs, I hadn't made significant contributions

GHC development asks too much of the host system

n the scale of hours , as this is a hobby project. Hope this will open some eyes. Cheers, Hécate -- Hécate ✨ : @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/

Re: Haddock needs help

mailing-list, as GHC is our main (if not only) consumer, and GHC developers have already made contributions to Haddock. Cheers, Hécate Le 26/05/2022 à 17:12, Mikolaj Konarski a écrit : Talking as a Haskell user, but also a cabal maintainer: the Haddock work Hécate describes is crucial for the health

Haddock needs help

company can spare some engineering hours for you to give a hand, you're most welcome to do so. Just so we are clear, I am immensely grateful to the people who have submitted fixes and patches these past months, but this situation is untenable. Hécate ✨ : @TechnoEmpress IRC: Hecate WWW: https

Re: Release Status - 9.4.1-alpha2/9.2.3/9.0.* series

. Best Wishes, Matt ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Hécate ✨ : @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

Re: gitlab spam

askell.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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Welcome to Bryan (Devops Engineer)

/listinfo/ghc-devs -- Hécate ✨ : @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Deprecation of GHCi's tag generation feature, starting with GHC 9.4

to replace the tags feature. This is being documented in the "Tags" wiki page³. You are invited to help with broadcasting this announcement to your fellow Haskell users. I will post on Reddit and the Haskell Discourse but increasing the coverage of this will be important. Cheers, Hécate

Deprecation process for GHC.Pack

/-/issues/21540>) 3. By error (GHC 9.10) (#21536 <https://gitlab.haskell.org/ghc/ghc/-/issues/21536>) You can read more about the whole thing here: https://gitlab.haskell.org/ghc/ghc/-/issues/21461 Cheers, have a nice week! -- Hécate ✨ : @TechnoEmpress IRC: Hecate WWW:https://gli

Re: "Modularizing GHC" paper

___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Hécate ✨ : @TechnoE

Re: Our ambitions for GHC 9.6

Of course it wouldn't be funny if I didn't forget to add a link to the page that lists everything, so here it is: https://gitlab.haskell.org/ghc/ghc/-/wikis/status/ghc-9.6 Le 03/05/2022 à 16:56, Hécate a écrit : Hi everyone, With 9.4 just around the corner, I am gathering broad ambitions

Our ambitions for GHC 9.6

in the future of GHC! Cheers, Hécate. -- Hécate ✨ : @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Documenting primtypes, round 1: ByteArray# and Array#

d koz ross. Cheers -- Hécate ✨ : @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How to coordinate Haddock MR with GHC MR?

that Haddock transitions to GHC 9.6. Please advise. Norman ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Hécate ✨ : @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

Re: 9.4 release planning (& GHCJS merge process)

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

Re: 9.4 release planning (& GHCJS merge process)

t; 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!

Re: 9.4 release planning (& GHCJS merge process)

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 éc

Re: 9.4 release planning (& GHCJS merge process)

e 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 bran

[PSA] Patches to Haddock regarding GHC development move to GitLab!

/haddock. I will try and warn folks who currently have PRs opened on GitHub targeting ghc-head, but please know that they'll be closed in the next few days. Have a great end of the week, Hécate, for the Haddock Team. -- Hécate ✨ : @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

Re: How to build Haddock documentation quickly?

l.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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

[RFC] Split the GHC.* hierarchy from `base` in its own package, `ghc-base`

in the ticket so that this discussion may be better archived. Cheers! -- Hécate ✨ : @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Documenting GHC: blogs, wiki pages, Notes, Haddocks, etc

of appearing with its title or inserting a link with the section name it is currently decoupled from. Am Di., 14. Sept. 2021 um 16:25 Uhr schrieb Hécate : Hi, The named chunks can be positioned through the use of the export list syntax: module Foo   ( main

Re: Documenting GHC: blogs, wiki pages, Notes, Haddocks, etc

n Am Di., 14. Sept. 2021 um 14:32 Uhr schrieb Hécate : > today’s Haddock doesn’t understand Notes.  But we could fix that if we were minded to. I may have missed an episode or two here but what prevents us from writing Notes as Named Chunks¹, write them where Haddock expects y

Re: Documenting GHC: blogs, wiki pages, Notes, Haddocks, etc

bdb857c77298d6fdec12626b65e014aaeee33=04%7C01%7Csimonpj%40microsoft.com%7Cdb46814133bc4404b6d308d9685a487e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63769255360954%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=4616hEpSSUcOZ5zQYZMmEbF6mTJcIVKx2nlgA8ENsHM%3D=0>. ___

Re: Coding style: Using StandaloneKindSignatures in GHC

) such a standalone kind signature in our style guide. The cases where at least one parameter of a datatype does not have kind Type are the places we need the extra information. This is indeed quite reasonable. I will follow you on that point. -- Hécate ✨ : @TechnoEmpress IRC: Uniaika WWW: https

Re: Coding style: Using StandaloneKindSignatures in GHC

After reading this proposal, I agree that StandaloneKindSignatures ought to be encouraged in the codebases, and I vote that we mention them in the coding style¹. Cheers, Hécate ——— ¹ https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/coding-style Cheers, Hécate. Le 18/05/2021 à 19:58

Re: linting GHC

implemented in HLint, you can use this (sad) workaround: ``` TERM=dumb hadrian/build -j lint:compiler ``` which remove all the colours from the output. Hope this helps, sorry for the confusion. Cheers, Hécate Le 30/04/2021 à 22:12, Richard Eisenberg a écrit : Hi devs, I see in CI that we'

Integrating more base Instances in the `stock` deriving strategy?

lived with it in my code bases, and I'd like to know if there are deeper issues pertaining to their exclusion from the `stock` deriving strategy. Here is the link to the discussion ticket: https://gitlab.haskell.org/ghc/ghc/-/issues/19707 Cheers, and have a nice week! -- Hécate

GHC Proposal: GHC Maintainer Preview

c-proposals/pull/417 Have a nice week-end! -- Hécate ✨ : @TechnoEmpress IRC: Uniaika WWW: https://glitchbra.in RUN: BSD ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: HLint in the GHC CI, an eight-months retrospective

, this should be taken care of for you. Hope it clarified things! Cheers, Hécate Le 25 mars 2021 21:39:15 Richard Eisenberg a écrit : Thanks for this update! Glad to know this effort is going well. One quick question: suppose I am editing something in `base`. My understanding is that my edit

HLint in the GHC CI, an eight-months retrospective

. Have a very nice day, Hécate --- [0]: https://github.com/ndmitchell/hlint [1]: https://gitlab.haskell.org/ghc/ghc/-/issues/18424 [2]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4147 -- Hécate ✨ : @TechnoEmpress IRC: Uniaika WWW: https://glitchbra.in RUN: BSD

Re: -ddump-json

_ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Hécate ✨ : @TechnoEmpress IRC: Uniaika WWW: https://glitchbra.in RUN: BSD ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-b

Re: A small documentation PR on github

that the PRs receive all the love they deserve! Cheers! Hécate Le 03/07/2020 à 12:20, Alexander Kjeldaas a écrit : Hi devs! I created a small documentation PR for the GHC FFI on github and noticed that there's another one-liner PR from May 2019 that was not merged. https://github.com/ghc

Re: Search in GitLab

g is among the major motivations behind it. -- Best, Artem On Mon, Jun 15, 2020, 5:07 PM Hécate <mailto:hec...@glitchbra.in>> wrote: On 15/06/2020 19:50, Ben Gamari wrote: > Frankly, this makes me wonder whether we should change the output > produced for loops. The current er

Re: Search in GitLab

On 15/06/2020 19:50, Ben Gamari wrote: Frankly, this makes me wonder whether we should change the output produced for loops. The current error is essentially un-Googleable, as we see here. I know I have personally struggled with this same issue in the past. I wholeheartedly agree with this

Re: Strange library git glitch

My bad, it seems like this is another issue. I found this StackOverflow page quite helpful in explaining the hows and whys: https://stackoverflow.com/questions/4873980/git-diff-says-subproject-is-dirty Cheers, Hécate Le 15/05/2020 à 16:30, Hécate a écrit : Hi Simon, I usually manage

Re: Strange library git glitch

Hi Simon, I usually manage to get it to disappear by using `git submodule update --recursive`. Is it a flag you've used in your previous attempts? Cheers, Hécate. Le 15/05/2020 à 16:24, Simon Peyton Jones via ghc-devs a écrit : No amount of git submodule update makes it go away.  Any

Re: A future for the Windows packaging situation.

>Hopefully that wouldn't become the only way to download GHC. That wasn't my intention to suggest it to be the One True Way to download it. >Sounds great, but is it reasonable? GNU/Linux package managers AFAIK don't install Haskell libraries either Some do! On Fedora, the Haskell libraries

A future for the Windows packaging situation.

user base, this would would be wonderful. Thank you for reading until the end. Cheers, Hécate. PS: I am in no way trying to berate anyone for their implied incompetence, or imply that Windows users are stupid and/or technologically impaired. This would be misinterpreting my words and lead

[8.12] Documentation plans

Hello ghc-devs For everyone who doesn't know me (yet), I am Hécate, and I coordinate the the Haskell Docs initiative. You may have seen me on various community channels and on social media to recruit lost souls^W^Wmotivated volunteers to help improve the documentation of the `base` library