Re: Proposal: Roundtrip serialization of Cmm (parser-compatible pretty-printer output)

Thanks I opened a discourse thread about this https://discourse.haskell.org/t/the-differences-between-cmm-parser-and-pretty-printer/12673 El lun, 4 ago 2025 a la(s) 1:28 p.m., Ben Gamari (b...@smart-cactus.org) escribió: > Diego Antonio Rosario Palomino writes: > > >>Hi Diego, > > > >>In the f

Re: GHC 9.10.3-rc3 is now available

Sorry, I just pushed the tag. On 8 August 2025 6:14:26 pm IST, Viktor Dukhovni wrote: >On Fri, Aug 08, 2025 at 06:02:26PM +0530, Zubin Duggal wrote: > >> The GHC developers are very pleased to announce the availability >> of the third release candidate for GHC 9.10.3. Binary distributions, source

Re: GHC 9.10.3-rc3 is now available

On Fri, Aug 08, 2025 at 06:02:26PM +0530, Zubin Duggal wrote: > The GHC developers are very pleased to announce the availability > of the third release candidate for GHC 9.10.3. Binary distributions, source > distributions, and documentation are available at [downloads.haskell.org][] > and > via

Re: Generating fresh names in a source plugin

Right, so I'm suggesting that any changes or additions should be recorded in that Note so it can be the primary source of information on tags that it apparently wanted to be. And perhaps it deserves special mention in the Commentary as such. On Tue, Aug 5, 2025 at 10:26 AM Wolfgang Jeltsch wrote:

Re: Generating fresh names in a source plugin

Am Dienstag, dem 05.08.2025 um 17:18 +0300 schrieb Wolfgang Jeltsch: > Am Montag, dem 04.08.2025 um 23:18 +0100 schrieb Simon Peyton Jones: > > > > > you can’t reliably tell what tags GHC uses and what tags it may > > > use > > > in the future. In the end, I used `grep` and my own eyes to check >

Re: Generating fresh names in a source plugin

Am Montag, dem 04.08.2025 um 18:37 -0400 schrieb Brandon Allbery: > And indeed, there is `Note [Uniques for wired-in prelude things and > known tags]` in compiler/GHC/Builtin/Uniques.hs. This doesn’t list which tags cause special compiler behavior, only which ones are used by GHC in general. Also

Re: Generating fresh names in a source plugin

Am Montag, dem 04.08.2025 um 23:18 +0100 schrieb Simon Peyton Jones: > > > you can’t reliably tell what tags GHC uses and what tags it may use > > in the future. In the end, I used `grep` and my own eyes to check > > potentially the whole GHC codebase for tag use. > > Indeed this is bad.  Can you

Re: Generating fresh names in a source plugin

There's supposed to be one already, IIRC. And indeed, there is `Note [Uniques for wired-in prelude things and known tags]` in compiler/GHC/Builtin/Uniques.hs. If you've found more, they should probably be added there. On Mon, Aug 4, 2025 at 6:19 PM Simon Peyton Jones < simon.peytonjo...@gmail.com

Re: Generating fresh names in a source plugin

> > think there is at least another tag that is treated specially: `f`, > having to do with type families, from what I remember. The fact that some > tags do cause special compiler behavior makes the situation quite tricky. If you believe that the tag has significance beyond debugging etc, you m

Re: Generating fresh names in a source plugin

Am Montag, dem 04.08.2025 um 15:16 +0100 schrieb Simon Peyton Jones: > I have created https://gitlab.haskell.org/ghc/ghc/-/issues/26264 to > document my learning journey. Thank you for this. I find the reference to `takeUniqFromNameCache` interesting. I understand that the name cache that a `Hsc`

Re: Generating fresh names in a source plugin

Am Montag, dem 04.08.2025 um 16:12 +0200 schrieb Andreas Klebinger: > On 03/08/2025 17:25, Kai Prott wrote: > > According to the documentation, "the payload part of the Uniques > > allocated from this UniqSupply are guaranteed distinct wrt all other > > supplies, regardless of their 'tag'." (Assumi

Re: Generating fresh names in a source plugin

Am Sonntag, dem 03.08.2025 um 17:25 +0200 schrieb Kai Prott: > Also just curious: why do you need to construct a unique? Before the > GHC renamer a plugin can get away with generating essentially strings > that are "unique" and use them in `mkUnqual` or similar. > > Most of the time, I just generat

Re: Proposal: Roundtrip serialization of Cmm (parser-compatible pretty-printer output)

Diego Antonio Rosario Palomino writes: >>Hi Diego, > >>In the future it would make things easier if you could use one of the >>common email quoting conventions (i.e. starting lines with >). It is >>otherwise a bit hard to distinguish your replies from the questions >>you are responding to. > > I

Re: Generating fresh names in a source plugin

extending_ghc.html#compiler-plugins>. > Is it adequate? > > I notice that > >- it mentions the module GHC.Plugins (but only in code fragments) >- it does not mention GHC.Tc.Plugins; neither does GHC.Plugins >re-export GHC.Tc.Plugins > > It would be great if so

Re: Generating fresh names in a source plugin

Some slight additions to Kais message: On 03/08/2025 17:25, Kai Prott wrote: Hi, what I have used In the past (and that I am fairly confident works) is exactly what you say: use `uniqFromTag` or `mkSplitUniqSupply`. According to the documentation, "the payload part of the Uniques allocated

Re: Generating fresh names in a source plugin

te? I notice that - it mentions the module GHC.Plugins (but only in code fragments) - it does not mention GHC.Tc.Plugins; neither does GHC.Plugins re-export GHC.Tc.Plugins It would be great if some plugin authors felt able to offer patches to improve. Maybe open a GHC ticket? Simon

Re: Generating fresh names in a source plugin

Hi, what I have used In the past (and that I am fairly confident works) is exactly what you say: use `uniqFromTag` or `mkSplitUniqSupply`. According to the documentation, "the payload part of the Uniques allocated from this UniqSupply are guaranteed distinct wrt all other supplies, regardless o

Re: Generating fresh names in a source plugin

Hello, again! After some more digging, I came to the conclusion that `uniqFromTag` is likely what I should use. However, what exactly is the tag for? The note „Uniques and tags“ only says the following: > The tag […] is typically used to make it easier to distinguish uniques > constructed by dif

Re: Proposal: Roundtrip serialization of Cmm (parser-compatible pretty-printer output)

Very related GHC gitlab issue : https://gitlab.haskell.org/ghc/ghc/-/issues/23989 El lun, 28 jul 2025 a la(s) 7:39 p.m., Diego Antonio Rosario Palomino ( diegorosario2...@gmail.com) escribió: > >Hi Diego, > > >In the future it would make things easier if you could use one of the > >common email q

Re: GHC/ | Failed pipeline for wip/T23109 | a90f83d4

It seems to have fixed itself. Works now. Simon On Wed, 30 Jul 2025 at 12:12, Bryan Richter wrote: > (Sorry for spamming emails) > > I should also mention that the large number of "spurious failures" on the > linked dashboard is, itself, a spurious result. These errors are *not* > spurious, bu

Re: GHC 9.10.3-rc1 is now available

Thanks! I did test builds for Fedora Rawhide and EPEL 10: https://koji.fedoraproject.org/koji/taskinfo?taskID=135425601 (quick rawhide) https://koji.fedoraproject.org/koji/taskinfo?taskID=135469895 (perf rawhide) https://koji.fedoraproject.org/koji/taskinfo?taskID=135480867 (quick epel10) If anyon

Re: GHC/ | Failed pipeline for wip/T23109 | a90f83d4

(Sorry for spamming emails) I should also mention that the large number of "spurious failures" on the linked dashboard is, itself, a spurious result. These errors are *not* spurious, but they are being treated as such. That causes up to 10 needless retries per failure. That's something I have on m

Re: GHC/ | Failed pipeline for wip/T23109 | a90f83d4

I'm loathe to pause a lint runner, but I will do so in this case, to see if the problem is localized to that system. On Wed, 30 Jul 2025 at 14:08, Bryan Richter wrote: > It looks like most lint jobs are failing because they want to run on a > Docker image that is missing from the GitLab registry

Re: GHC/ | Failed pipeline for wip/T23109 | a90f83d4

It looks like most lint jobs are failing because they want to run on a Docker image that is missing from the GitLab registry. I know Ben talked about having some scheme for expiring images. I don't think that has been put into place, however. There could also just be fallout from the server migrat

Re: GHC/ | Failed pipeline for wip/T23109 | a90f83d4

Dear GHC devs This mr !10479 seems Utterly Broken. Looks as if something is wrong with CI. Can anyone help? https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10479 Thanks Simon On Wed, 30 Jul 2025 at 09:05, GitLab wrote: > [image: GitLab] > [image: ✖] Pipeline #113076 has failed! > > Pr

Re: Fwd: Proposal: Roundtrip serialization of Cmm (parser-compatible pretty-printer output)

Thanks a lot Diego, that indeed addresses my concerns. :) Le 28/07/2025 à 20:26, Diego Antonio Rosario Palomino a écrit : -- Forwarded message - De: *Diego Antonio Rosario Palomino* Date: lun, 28 jul 2025 a la(s) 12:56 p.m. Subject: Re: Proposal: Roundtrip serialization of

Re: Fwd: Proposal: Roundtrip serialization of Cmm (parser-compatible pretty-printer output)

Diego Antonio Rosario Palomino writes: > -- Forwarded message - > De: Diego Antonio Rosario Palomino > Date: lun, 28 jul 2025 a la(s) 12:56 p.m. > Subject: Re: Proposal: Roundtrip serialization of Cmm (parser-compatible > pretty-printer output) > To: Hécat

Re: Proposal: Roundtrip serialization of Cmm (parser-compatible pretty-printer output)

Hi Diego, Thank you very much for your work in this direction, it's sorely needed. I'm all for having proper roundtrip correctness for Cmm, but I am not sure altering the parser is the way to go. In my opinion, GHC should produce valid textual Cmm, that can be ingested by the parser at it is t

Re: Proposal: Roundtrip serialization of Cmm (parser-compatible pretty-printer output)

Diego Like Andreas says, in general being able to parse the output that GHC itself produces would be a good idea. A few thoughts - Do you have any use-cases in mind? Suppose you were 100% successful -- would anyone use it? - - You need a compelling reason to change the input languag

Re: Proposal: Roundtrip serialization of Cmm (parser-compatible pretty-printer output)

The idea of making Cmm roundtripable comes up every now and then. While the ability to feed dump output to GHC for debugging or similar purposes is useful In the end we always ended up prioritizing one of the many other things that needed doing. Or in other words making Cmm (more) roundtripable

Re: Correct parsers for bounded integral values

Hello, I also think that the instances for the bounded types are pretty unfortunate, but the change might have unintended consequences. I am not particularly opposed to it though. One thing to consider, though, is that it might be more productive to change the other parsing libraries (parsec, etc

Re: Correct parsers for bounded integral values

For base introducing a new function `readBoundedNum :: (Bounded a, Num a) => String -> a` or similar seems very reasonable to me. Changing "read" to throw an exception or similar after decades less so. On 20/07/2025 22:08, Viktor Dukhovni wrote: On Sun, Jul 20, 2025 at 09:12:20PM +0200, Stefan

Re: Correct parsers for bounded integral values

On Mon, Jul 21, 2025 at 05:56:46PM +0200, Stefan Klinger wrote: > > - One way to avoid difficulties with handling negative minBound is > > to parse signed values via the corresponding unsigned type, which > > can accommodate `-minBound` as a positive value, and then negate > >

Re: Correct parsers for bounded integral values

Thanks for the encouragement Rodrigo! I'll follow the process and hope to open a ticket soon. Viktor Dukhovni (2025-Jul-21, excerpt): > It is also fair to point out that once an Int or other bounded integral > type is read, arithmetic with that type (addition, subtraction and > multiplication)

Re: Correct parsers for bounded integral values

On Sun, Jul 20, 2025 at 09:12:20PM +0200, Stefan Klinger wrote: > I'd like to bring to your attention a discussion that I have started > over at Haskell-cafe [1]. I was complaining about the silent overflow > of parsers for bounded integers: > > > read "298" :: Word8 > 42 FWIW, there ha

Re: Correct parsers for bounded integral values

Hi Stefan, this looks like great (and well explained) work! To modify the behavior of existing libraries you need to tackle the change per library and upstream it by opening a ticket on the associated issue tracker and discussing with the developers/maintainers. For `base` itself there is a sta

Re: openFile gives "file is locked" error on Linux when creating a non-existing file

It is likely this GHC issue: https://gitlab.haskell.org/ghc/ghc/-/issues/18832 . On Sat, 28 Jun 2025 at 17:56, Harendra Kumar wrote: > > We instrumented the GHC locking mechanism as suggested by Viktor and > deployed the instrumented GHC in CI. We got our first crash after 4 months! > > Summary f

Re: CI hickups

I fixed the issue now. Andreas will update the documentation so that it works next time. Cheers, Matt On Wed, Jul 2, 2025 at 9:42 PM Andreas Klebinger via ghc-devs wrote: > > Hello devs, > > There are currently issues with the perf-notes repository tokken which > cause CI pipelines to fail. >

Re: [External] Build failure

Hi Simon, I suspect you need to click on the arrow right next to the line numbers in the log to unfold the complete log starting “Test via Hadrian" — Apoorv On Jun 30, 2025, at 11:47 AM, Simon Peyton Jones wrote: Friends My build !14410 has started consistently failing to show me testsuite

Re: openFile gives "file is locked" error on Linux when creating a non-existing file

We instrumented the GHC locking mechanism as suggested by Viktor and deployed the instrumented GHC in CI. We got our first crash after 4 months! Summary from the preliminary investigation of the crash: * The problem is not filesystem dependent or inode reuse related. * After understanding it bett

Re: RTS: mmap fails on RISC-V with Linux 6.8

Am 18. Juni 2025 16:34:09 MESZ schrieb Andreas Klebinger : >There have been changes to upstream that likely fixes this. > >See https://gitlab.haskell.org/ghc/ghc/-/issues/25492 > >If you can reproduce this issue using a ghc build base of a recent ghc master >version please let us know! > >Cheers

Re: RTS: mmap fails on RISC-V with Linux 6.8

There have been changes to upstream that likely fixes this. See https://gitlab.haskell.org/ghc/ghc/-/issues/25492 If you can reproduce this issue using a ghc build base of a recent ghc master version please let us know! Cheers On 27/05/2025 20:35, Heinrich Schuchardt via ghc-devs wrote: The

RE: Placing GitLab behind Anubis

Hécate via ghc-devs writes: > From experience it takes a couple of seconds and it's just client JS. > Right, I believe the amount of work is configurable. This is a knob that we will may need to twiddle. freedesktop.org's challenge takes less than a second on my laptop. Cheers, - Ben signatu

RE: Placing GitLab behind Anubis

From experience it takes a couple of seconds and it's just client JS. Le 17 juin 2025 07:27:41 GMT+02:00, Mark Seemann a écrit : >Hi > >I'm currently just a lurker here, so my opinion may not count as much as those >who actually contribute, but perhaps other readers have the same questions as >

RE: Placing GitLab behind Anubis

Hi I'm currently just a lurker here, so my opinion may not count as much as those who actually contribute, but perhaps other readers have the same questions as I do. - What does 'small' mean? Are we talking about a second of work, minutes, hours? - Do clients need to install custom software to

Re: GHC 9.14 fork status

Hi Ben, Can we land the following patches: * https://gitlab.haskell.org/ghc/ghc/-/merge_requests/14183 * https://gitlab.haskell.org/ghc/ghc/-/merge_requests/14321 * https://gitlab.haskell.org/ghc/ghc/-/merge_requests/14377 If someone could help landing #14183, that would be good. Matt On Thu,

Re: GHC 9.14 boot library status

Artem Pelenitsyn writes: > Hi Ben, > > In the spreadsheet, Cabal says desired version 3.15.0.0, while it should be > 3.16.0.0 I believe: Cabal reserves odd numbers for development versions. > Sigh, yes, quite right. Thanks for noticing! Fixed. Cheers, - Ben signature.asc Description: PGP sig

Re: GHC 9.14 boot library status

Hi Ben, In the spreadsheet, Cabal says desired version 3.15.0.0, while it should be 3.16.0.0 I believe: Cabal reserves odd numbers for development versions. Thanks for all your hard work! -- Best, Artem On Thu, Jun 12, 2025, 7:00 PM Ben Gamari wrote: > Hi all, > > This week I have been pushin

Re: Features for GHC 9.14?

Matthew Pickering writes: > Hi Ben, > > Can you clarify what date in July the release is scheduled for? > Indeed the preliminary schedule previously given in the milestone is not realistic at this point. I have updated the schedule to a more realistic September date as I hope to fork soon after w

Re: Features for GHC 9.14?

George Colpitts writes: > According to https://gitlab.haskell.org/ghc/ghc/-/milestones/400#tab-issues > the final release is scheduled for September. > > Will we be supporting llvm 20? > Yes, we will likely enable LLVM 20 support. Cheers, - Ben signature.asc Description: PGP signature __

Re: Features for GHC 9.14?

Spam detection software, running on the system "mail.haskell.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for detail

Re: Features for GHC 9.14?

Hi Ben, Can you clarify what date in July the release is scheduled for? I think we have managed to merge the significant features which were targeted for this release. * Explicit Level Imports (Matt) * Debugger Improvements (Rodrigo) * MHU GHCi Support (Hannes) * Improved Prinop Performance in t

Re: can't move to latest version of llvm on ghc 9.12.2

The obvious workaround is to change the configure file to LlvmMaxVersion=21 then rerun configure and sudo make install. I did that and smoke tested llvm 20.15 and it seems to work fine. In case anybody else is interested in testing llvm 20 on 9.12.2 On Wed, Apr 2, 2025 at 9:06 AM George Colpit

Re: GitLab account request

I've approved you. On Fri, May 16, 2025 at 1:52 PM Florian Ragwitz wrote: > Hi, > > I'd like for the gitlab.haskell.org account request for the account > "rafl" to be approved, so that I can participate in issue discussions > and submit changes for review, please. > > Thanks! > _

Re: GitLab Account creation request

Hi Iris, I’ve approved your request now. Welcome! Feel free to ask questions. Rodrigo > On 14 May 2025, at 10:14, Iris <0...@owo.li> wrote: > > Dear GHC developers, > I am interested in contributing to the GHC project and would like to have an > account(iris) on the GitLab instance. > > Best

Re: Marge

IIRC it's been discussed but that part of the bot is hard to change. On Mon, Apr 28, 2025 at 4:03 PM Simon Peyton Jones < simon.peytonjo...@gmail.com> wrote: > > Marge is configured to require at least two MRs. > > Interesting, thank you. I didn't know that. Maybe after a while, if > there is

Re: Marge

> Marge is configured to require at least two MRs. Interesting, thank you. I didn't know that. Maybe after a while, if there is only one, it should do it anyway. Simon On Mon, 28 Apr 2025 at 17:24, Brandon Allbery wrote: > The dashboard ( > https://grafana.gitlab.haskell.org/d/iiCppweMz/ma

Re: Marge

The dashboard ( https://grafana.gitlab.haskell.org/d/iiCppweMz/marge-bot?orgId=2&from=now-24h&to=now&timezone=browser&refresh=30m) says it's the only mergeable MR, and Marge is configured to require at least two MRs. On Mon, Apr 28, 2025 at 12:18 PM Simon Peyton Jones < simon.peytonjo...@gmail.com

Re: Questions regarding the RISCV native codegen & performance

Thank you so much, again! I can't overstate how useful all these recommendations are, and I'm looking forward to see how these play out in simulations. So I guess it's time for me to work! Sincerely yours, Dani. On 18/4/25 14:41, Sven Tennie wrote: Hey Daniel 👋 Thanks a lot for your ki

Re: Questions regarding the RISCV native codegen & performance

Thank you so much for all the information and the help. Seriously, this is much more than I was hoping to get, even the suggestion for generating commented assembly code (which is, I assume, the method that Compiler Explorer uses to relate the high-level Haskell code with the assembly output

Re: Questions regarding the RISCV native codegen & performance

Hey Daniel 👋 Thanks a lot for your kind words. The AArch64 ISA might also be some source of inspiration. AArch64 has some combined instructions which RISC-V hasn't. E.g ADD of two registers with an included shift. Though, we don't seem to use many of them and I haven't found any usage that wouldn

Re: Questions regarding the RISCV native codegen & performance

Hey Daniel 👋 That's really an interesting topic, because we never analyzed the emitted RISC-V assembly with statistical measures. So, if I may ask for a favour: If you spot anything that could be better expressed with the current ISA, please open a ticket and label it as RISC-V: https://gitlab.ha

Re: Questions regarding the RISCV native codegen & performance

Hi Daniel. I think Sven Tennie and the LoongArch contributors are the experts in NCG for these kinds of instruction sets. I have cced them. Cheers, Matt On Tue, Apr 15, 2025 at 5:40 PM Daniel Trujillo Viedma < danihacker.vie...@gmail.com> wrote: > Hello, ghc-devs! My name is Daniel Trujillo, I'

Re: Testsuite tests

Hi Simon, You have disabled the build of profiled libraries in your user settings, so the test doesn't run, because it requires profiled libraries. If you want to disabled profiled things (including the rts) from your build, then import `Flavour` and use the `disableProfiledLibs :: Flavour -> Fla

Re: Next steps forward for a stable Template Haskell

AM Matthew Pickering < matthewtpicker...@gmail.com> wrote: > Hi Teo, I went back and read > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13297 > > I think my comment is a very good summary there. Which I will paste into > this thread. > > ``` > > Why are these

Re: Next steps forward for a stable Template Haskell

Hi Teo, I went back and read https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13297 I think my comment is a very good summary there. Which I will paste into this thread. ``` Why are these packages not re-installable? 1. If you are not using the internal interpreter (or dynamic

Re: Testsuite tests

> > It seems that you have not built profiled libraries? It's impossible to > say without knowing your custom local configuration. Could you share that? Sure! UserSettings.hs is attached. Funnily enough the build system takes ages (many minutes) building profied version of the runtime system, d

Re: Late CC profiling

> But then we'll add cost centres to data constructor workers and wrappers. ... but have the "add cost centre" pass skip over data constructor workers and wrappers. We already do this. See compiler/GHC/Core/LateCC/TopLevelBinds.hs:112 where we already check for constructor bindings. I've added th

Re: Late CC profiling

If you are sure there is no need to tidy the class method selectors then it would be clearest to have a explicit "materializeImplicitBinds" step in the pipeline after tidy and before lateCC runs. Yes, I want to put all the materialisation in one place. I think you are suggesting Plan A - Tid

Re: Late CC profiling

A interesting wrinkle! I agree with matt that having class methods show up in the profile can be very helpful at times. Constructors and their wrappers on the other hand should be of no concern. We explicitly try to avoid wrapping them in cost centres as they generally add no useful information

Re: Late CC profiling

Hi Simon, It does seem strange (at first glance) that these implicit things happen in two different places. However, I think you should do this refactoring in a separate MR to !10479, it seems unrelated to the purpose of that patch and affects other things like you have mentioned. Why do you thi

Re: Testsuite tests

It seems that you have not built profiled libraries? It's impossible to say without knowing your custom local configuration. Could you share that? On Fri, Apr 4, 2025 at 10:30 PM Simon Peyton Jones < simon.peytonjo...@gmail.com> wrote: > Friends > > In CI for !10479 I'm getting test failures for

Re: can't move to latest version of llvm on ghc 9.12.2

Looking at https://gitlab.haskell.org/ghc/ghc/-/issues/25011 it seems the desire was to fail with a proper error when LLVM was not found at all. To me failing when the llvm version is too new seems like a unintended side effect of fixing the former. I agree that simply warning and trying anway i

Re: GHC 9.6.7 is now available

On Mon, Mar 24, 2025 at 6:42 AM Shayne Fletcher < shayne.fletcher...@gmail.com> wrote: > the tag ghc repo tag ghc-9.6.7-release has not been created. please fix. > this is looking resolved. thanks! -- Shayne Fletcher ___ ghc-devs mailing list ghc-devs

Re: [External] Re: GHC memory usage when typechecking from source vs. loading ModIfaces

ofile, I still get way more than 2k > ModuleNodes and NodeKey_Modules…. > > > > *From:* Matthew Pickering > *Sent:* Tuesday, April 1, 2025 5:44 PM > *To:* Erdi, Gergo > *Cc:* GHC Devs ; ÉRDI Gergő ; > Montelatici, Raphael Laurent ; Dijkstra, Atze > > *Subject:

Re: can't move to latest version of llvm on ghc 9.12.2

Filed https://gitlab.haskell.org/ghc/ghc/-/issues/25915 On Tue, Apr 1, 2025 at 2:11 PM Andreas Klebinger via ghc-devs < ghc-devs@haskell.org> wrote: > Looking at https://gitlab.haskell.org/ghc/ghc/-/issues/25011 it seems the > desire was to fail with a proper error when LLVM was not found at all.

Re: GHC memory usage when typechecking from source vs. loading ModIfaces

in attached archives… > > > > *From:* Matthew Pickering > *Sent:* Friday, March 28, 2025 8:40 PM > *To:* Erdi, Gergo > *Cc:* GHC Devs ; ÉRDI Gergő ; > Montelatici, Raphael Laurent ; Dijkstra, Atze > > *Subject:* [External] Re: GHC memory usage when typechecking from so

Re: [External] Re: GHC memory usage when typechecking from source vs. loading ModIfaces

M > *To:* Erdi, Gergo > *Cc:* GHC Devs ; ÉRDI Gergő ; > Montelatici, Raphael Laurent ; Dijkstra, Atze > > *Subject:* [External] Re: GHC memory usage when typechecking from source > vs. loading ModIfaces > > > > I think you are missing > https://gitlab.haskell

Re: Next steps forward for a stable Template Haskell

Good work! I have added some comments. Before long it would be good to update the Wiki roadmap doc, so there is one source of truth. Simon On Wed, 2 Apr 2025 at 18:26, Teo Camarasu wrote: > Hi folks, > > At Tuesday's GHC devs meeting, we talked about having a discussion about > template-haske

RE: [External] Re: GHC memory usage when typechecking from source vs. loading ModIfaces

memory usage during any single module’s typechecking). From: Matthew Pickering Sent: Wednesday, April 2, 2025 6:03 PM To: Erdi, Gergo Cc: GHC Devs ; ÉRDI Gergő ; Montelatici, Raphael Laurent ; Dijkstra, Atze Subject: [External] Re: GHC memory usage when typechecking from source vs. loading

Re: GHC memory usage when typechecking from source vs. loading ModIfaces

PUBLIC zcat ../repro-hs.patch.gz |patch -p0 From: Matthew Pickering Sent: Wednesday, April 2, 2025 5:39 PM To: Erdi, Gergo Cc: GHC Devs ; ÉRDI Gergő ; Montelatici, Raphael Laurent ; Dijkstra, Atze Subject: [External] Re: GHC memory usage when typechecking from source vs. loading ModIfaces

Re: can't move to latest version of llvm on ghc 9.12.2

Thanks, I'll file a ticket today or tomorrow. On Tue, Apr 1, 2025 at 2:11 PM Andreas Klebinger via ghc-devs < ghc-devs@haskell.org> wrote: > Looking at https://gitlab.haskell.org/ghc/ghc/-/issues/25011 it seems the > desire was to fail with a proper error when LLVM was not found at all. > > To me

Re: can't move to latest version of llvm on ghc 9.12.2

I was trying to find out if it works but I ran into the problem I described. Yes, there were a few years where the latest version didn't work but in many years it did. ghc used to give a warning, this is an unsupported version but we'll try it anyways. I would like to return to that. In any case I

Re: can't move to latest version of llvm on ghc 9.12.2

Have you demonstrated that it works? IIRC the current behavior is because some LLVM version (16, IIRC) didn't work with GHC (threw errors from opt, I think). On Tue, Apr 1, 2025 at 10:49 AM George Colpitts wrote: > llvm 20 is out but unlike in earlier versions of ghc moving to it means > you can

Re: GHC memory usage when typechecking from source vs. loading ModIfaces

rong ghc-debug output. Indeed there are > 2301 ModuleGraphs in the heap at the end of typechecking :O > > > > *From:* Erdi, Gergo > *Sent:* Tuesday, April 1, 2025 12:51 PM > *To:* Matthew Pickering > *Cc:* GHC Devs ; ÉRDI Gergő ; > Montelatici, Raphael Laurent ; Dijkstra,

RE: GHC memory usage when typechecking from source vs. loading ModIfaces

Subject: Re: GHC memory usage when typechecking from source vs. loading ModIfaces This sounds extremely interesting, but I don’t understand where you are getting this number from! How do you see in the eventlog HTMLs that I’ve included that there are ~2000 ModuleGraphs? I’ve now tried using

Re: GHC memory usage when typechecking from source vs. loading ModIfaces

repro has 2294 modules, wouldn’t that mean 2294 ModuleGraphs by that metric? From: Matthew Pickering Sent: Saturday, March 29, 2025 1:53 AM To: Erdi, Gergo Cc: GHC Devs ; ÉRDI Gergő ; Montelatici, Raphael Laurent ; Dijkstra, Atze Subject: [External] Re: GHC memory usage when typechecking from

Re: gitlab.haskell.org outage this weekend

Ben Gamari writes: > Ben Gamari writes: > >> Hi all, >> >> As you may know, Haskell.org is currently in the process of moving its >> infrastructure to new hosting facilities. As part of this effort, GHC's >> GitLab instance will be taken down for migration on Saturday 29 March >> 2025 from 09:00

Re: gitlab.haskell.org outage this weekend

Ben Gamari writes: > Hi all, > > As you may know, Haskell.org is currently in the process of moving its > infrastructure to new hosting facilities. As part of this effort, GHC's > GitLab instance will be taken down for migration on Saturday 29 March > 2025 from 09:00 to 17:00. > Hi all, I will b

Re: GHC memory usage when typechecking from source vs. loading ModIfaces

scattered around in closures etc. (basically the same >> problem the HPT had before it was made into a mutable reference). >> >> -Original Message- >> From: ghc-devs On Behalf Of Erdi, Gergo >> via ghc-devs >> Sent: Friday, March 28, 2025 4:49 PM >> To: M

Re: GHC memory usage when typechecking from source vs. loading ModIfaces

< > ghc-devs@haskell.org> > Cc: ÉRDI Gergő ; Montelatici, Raphael Laurent < > raphael.montelat...@sc.com>; Dijkstra, Atze > Subject: [External] Re: GHC memory usage when typechecking from source vs. > loading ModIfaces > > Hi, > > Unfortunately, I am forced to return to

RE: GHC memory usage when typechecking from source vs. loading ModIfaces

eference). -Original Message- From: ghc-devs On Behalf Of Erdi, Gergo via ghc-devs Sent: Friday, March 28, 2025 4:49 PM To: Matthew Pickering ; GHC Devs Cc: ÉRDI Gergő ; Montelatici, Raphael Laurent ; Dijkstra, Atze Subject: [External] Re: GHC memory usage when typechecking from source v

Re: CFP - Haskell Implementors' Workshop 2025

This is a reminder that the call for proposals for the Haskell Implementors’ Workshop 2025 is open and the deadline is approaching. Please submit your proposals until April 4, 2025 using the following link. https://docs.google.com/forms/d/e/1FAIpQLSdczGbxJYGc4eusvPrxwBbZl561PnKeYnoZ2hYsdw_ZpSfupQ/v

Re: GHC 9.6.7 is now available

the tag ghc repo tag ghc-9.6.7-release has not been created. please fix. On Mon, Mar 24, 2025 at 2:44 AM Luite Stegeman wrote: > The GHC developers are very pleased to announce the availability of > GHC 9.6.7. Binary distributions, source distributions, and > documentation are available at > >

Re: fail to build ghc in github action

Hi Chaowen, Have you tried the proposed "The package list for 'hackage.haskell.org' does not exist. Run 'cabal update' to download it."? I.e. I guess you only need to add `cabal update` to the list of commands to run. Best regards, Sven Am So., 23. März 2025 um 11:37 Uhr schrieb chaowen guo <

Re: Gitlab access

Dear Jar Jar, I couldn’t find the account you mentioned in the pending users. Could you try again perhaps? Cheers, Rodrigo > On 5 Mar 2025, at 09:07, Jar Jar wrote: > > Hi ghc-devs, > > Please accept gitlab access request for : spamdefence+hask...@torinthiel.pl >

Re: GHC API stability: draft report of actions

Hello! This is to announce that I updated the report after a first round of feedback in the last GHC Weekly call. Comments welcome. On Fri, Feb 21, 2025 at 4:41 PM Facundo Domínguez < facundo.doming...@tweag.io> wrote: > Dear GHC devs, > > As part of the initiative to stabilize the GHC API [1], I

Re: GHC 9.10 release tags missing from Git

PUBLIC Indeed. For some reason I thought I saw 9.10.2 and 9.10.3 in `ghcup tui`. I must have hallucinated it :D From: Jens Petersen Sent: Thursday, February 6, 2025 12:28 PM To: Erdi, Gergo Cc: ghc-devs@haskell.org Subject: [External] Re: GHC 9.10 release tags missing from Git On Thu, 6 Feb

Re: GHC 9.10 release tags missing from Git

On Thu, 6 Feb 2025 at 10:17, Erdi, Gergo via ghc-devs wrote: > The latest release tag for the ghc-9.10 branch on the Git repo is > ghc-9.10.1-release, even though we've had 9.10.2 and 9.10.3 in the > meantime. Could someone who knows the exact commits tag them please? > I think you are confused

RE: [External] Re: GHC memory usage when typechecking from source vs. loading ModIfaces

in the HPT after typechecking every single module. Of course, this has catastrophic runtime performance, since I end up re-re-re-re-rehydrating every ModDetails for a total of 8,443,380 times (not counting the initial rehydration just after typechecking to put it in the HPT). So I get 290s MUT

  1   2   3   4   5   6   7   8   9   10   >