Re: Expanding a particular type family in type errors

Answering my own question: it looks like cleaning this up in GHC.Tc.Errors is rather impractical—there are just too many types buried inside other datatypes that would have to be updated—so it has to be wired into pprType. Fortunately, I can branch on userStyle to decide whether or not to do

Expanding a particular type family in type errors

Hi all, As part of my ongoing rework of arrow notation , I have introduced two wired-in type families, which assist in the typechecking process. The details are not terribly important (you can read the proposal if you’d like for

Re: [RFC] Compiler pipeline timings visualization

Sergej Jaskiewicz via ghc-devs writes: > tl;dr: I propose adding a new GHC flag for generating a log that allows > visualizing how much time each stage in the compiler pipleline took, similar > to Clang's -ftime-trace. > > Hello, everyone. Hi Sergej, [snip] > The latter option is much closer

Re: [RFC] Compiler pipeline timings visualization

Andreas Klebinger writes: > Hi Sergej, > > I think this is a good idea in general, and it seems you did some great > work there already. > Something like this can also help with pinpointing performance issues > inside the compiler > so would not just be useful to end users. > > intuitively I

Re: Justifying sched_yield() in the RTS

Ben Gamari writes: > Travis Whitaker writes: > >> Hello GHC devs, >> >> Through the course of reading some recent material posted by Linus >> Torvalds ^1 ^2, I remembered stumbling upon GHC Trac #3553 ^3 some >> years ago. >> > For what it's worth Simon Marlow and I discussed this a few weeks

Re: Justifying sched_yield() in the RTS

Travis Whitaker writes: > Hello GHC devs, > > Through the course of reading some recent material posted by Linus > Torvalds ^1 ^2, I remembered stumbling upon GHC Trac #3553 ^3 some > years ago. > For what it's worth Simon Marlow and I discussed this a few weeks ago and he agreed that it would

Re: git prune?

Simon Peyton Jones via ghc-devs writes: > I'm getting lots of the messages below. > Running 'git prune' makes no difference. > Simon > Indeed, the warning is on the server side (hence the "remote:" prefix). I'll need to take care of this on the server. Cheers, - Ben signature.asc

git prune?

I'm getting lots of the messages below. Running 'git prune' makes no difference. Simon simonpj@MSRC-3645512:~/code/HEAD-5/testsuite/tests/th$ git push --set-upstream origin wip/T18121 Counting objects: 13, done. Delta compression using up to 20 threads. Compressing objects: 100% (13/13),

Re: Justifying sched_yield() in the RTS

There are more related updates in https://gitlab.haskell.org/ghc/ghc/issues/9221, also including a short discussion of Linus's post. Simon Marlow's overall response was: > I'm very supportive of making this better, but as usual I will require > thorough data to back up any changes :) > >

RE: [RFC] Compiler pipeline timings visualization

This sounds great! Event logging needn't add much cost if we don't log much -- eg just compiler phases. It simply depends on how many events you generate! For naïve uses, the log you show in [9] is a bit complicated. Something even simpler might be good. Simon | -Original Message-

Re: [RFC] Compiler pipeline timings visualization

Hi Sergej, I think this is a good idea in general, and it seems you did some great work there already. Something like this can also help with pinpointing performance issues inside the compiler so would not just be useful to end users. intuitively I would assume that instead of adding another

[RFC] Compiler pipeline timings visualization

tl;dr: I propose adding a new GHC flag for generating a log that allows visualizing how much time each stage in the compiler pipleline took, similar to Clang's -ftime-trace. Hello, everyone. I'd like to tell you about a feature I've been working on recently, namely, the ability to generate and

Justifying sched_yield() in the RTS

Hello GHC devs, Through the course of reading some recent material posted by Linus Torvalds ^1 ^2, I remembered stumbling upon GHC Trac #3553 ^3 some years ago. Looking past the harsh tone Linus used in his notes, I think he makes some pretty reasonable points about the problems that can be