RE: Recognizing default method implementations

Is there a way to recognize that an Id / Var refers to a default method implementation, e.g. $dm/= in the following? I'm afraid not. There has never been a reason to do so. And it might not be robust e.g. it might be inlined. What is the problem you are trying to solve? Simon PS: I am

RE: [EXTERNAL] Unexpected duplicate join points in "Core" output?

November 2021 21:27 | To: ghc-devs@haskell.org | Subject: Re: [EXTERNAL] Unexpected duplicate join points in "Core" | output? | | On Sun, Nov 21, 2021 at 06:53:53AM -0500, Carter Schonwald wrote: | | > On Sat, Nov 20, 2021 at 4:17 PM Simon Peyton Jones via ghc-devs < | > ghc-devs

RE: [EXTERNAL] can GHC generate an irreducible control-flow graph? If so, how?

GHC breaks strongly connected components with a so-called loop-breaker. In this case, maybe countA is the loop-breaker; then countB can inline at all its call sites, and it'll look very reducible. See "Secrets of the GHC inliner". If you make countA and countB each call themselves, as well as

RE: [EXTERNAL] Unexpected duplicate join points in "Core" output?

There is absolutely no reason not to common-up those to join points. But we can't common up some join points when we could if they were let's. Consider join j1 x = x+1 in case v of A -> f (join j2 x = x+1 in ...j2...) B -> j1... C -> j1... Even though j2 is identical

Defaulting design choices

Sam, Richard, Adam, Vlad, Ryan, and other people interested in GHC's type system. Following discussion with Richard, I have created a new ticket #20686 for Make the design of defaulting explicit. This should inform !6851 which is trying to

RE: Output language of typechecking pass?

Is there anywhere on the GHC wiki that explains how to interpret this output, and says that the type and dictionary applications ARE there, just not shown by '-ddump-tc'? Perhaps it would be helpful to add some basic description of what comes out of the typechecker to a page like this one?

RE: Alpha-equivalence for recursive let-bindings

Huh! Dead right! Would you like to: * Open a ticket (you can use the text from this email) * Submit a MR? On the MR, * Add a Note that again gives your killer example; and mention why we don't need the check for NonRec * Worth also pointing out that letrec { x = e1; y = e2 }

RE: Exact Print Annotations : Anchor in a SrcSpan

Alan I'm way behind with this exact-print stuff and Anchors in particular. If you and your co-workers on it are confident you know what to do, that's great - although as ever, please document the design carefully. (I volunteer as a reader of such a design overview. I know that a current

RE: build-system design document: how relevant is it now?

It's already a sub-tree of "attic" -- ie out of date, retained for archive. The title index is useful: https://gitlab.haskell.org/ghc/ghc/-/wikis/index Maybe "attic" isn't the best name. Maybe each page should have a header saying "Historical value only". But I hate the idea of

RE: Specialisation doesn't kick in -- NOW WITH MINIMAL WORKING EXAMPLE (RE: Instantiation of overloaded definition *in Core*)

I’m out of cycles. Do please open a ticket. You are more likely to get attention that way. Matthew: maybe you can help with reproducing this? SImon PS: I am leaving Microsoft at the end of November 2021, at which point simo...@microsoft.com will cease to work.

RE: Gitlab

. (For now, it just forwards to simo...@microsoft.com.) | -Original Message- | From: ghc-devs On Behalf Of Tom Ellis | Sent: 21 October 2021 10:07 | To: ghc-devs@haskell.org | Subject: Re: Gitlab | | On Thu, Oct 21, 2021 at 08:59:48AM +, Simon Peyton Jones via ghc- | devs

Gitlab

Is it just me, or is Gitlab offline again? I'm getting error code 500. Simon PS: I am leaving Microsoft at the end of November 2021, at which point simo...@microsoft.com will cease to work. Use simon.peytonjo...@gmail.com

RE: Cmm comments are not Haddock comments---should this change?

Sounds like a good idea to me. I think `foo` works as we as @foo@ in Haddock comments, and is a whole lot less obtrusive when looking at the comments in their non-typeset form (which is all I ever do). Simon PS: I am leaving Microsoft at the end of November 2021, at which point

RE: Specialisation doesn't kick in -- NOW WITH MINIMAL WORKING EXAMPLE (RE: Instantiation of overloaded definition *in Core*)

Yes I have a full build. No it was not built with Hadrian. I did not realise that your system relied not only on GHC as a library, but also on the build system that you use to build GHC. I guess I can try that, but probably not today. But what is “settings”? Simon PS: I am leaving

RE: Specialisation doesn't kick in -- NOW WITH MINIMAL WORKING EXAMPLE (RE: Instantiation of overloaded definition *in Core*)

As for opening a ticket – a big part of the problem is that I don’t even know yet if I’m doing something wrong, or GHC is! So it’s not clear what the ticket would even be for – “I’m using the GHC API wrongly” is not a strong bug report  Plenty of tickets turn out to be non-bugs. But they are

gitlab.haskell.org

I'm getting "502" from gitlab.haskell.org. Is it just me? Thanks Simon PS: I am leaving Microsoft at the end of November 2021, at which point simo...@microsoft.com will cease to work. Use simon.peytonjo...@gmail.com instead.

RE: Specialisation doesn't kick in -- NOW WITH MINIMAL WORKING EXAMPLE (RE: Instantiation of overloaded definition *in Core*)

I could not compile Main.hs: ~/code/HEAD-1/inplace/bin/ghc-stage1 -c Gergo.hs -package ghc Gergo.hs:4:1: error: Could not find module 'Paths_ghc_lib' Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 4 | import qualified Paths_ghc_lib as GHC |

RE: how does a CAF become unreachable?

| Can anyone show an example? Sure xs = [1..1000] :: [Int] ys = [2..2000] :: [Float] main = do { print xs; print ys } After printing xs, the CAF for xs is unreachable and can be GC'd. No point in keeping it around. Indeed this applies from the moment (print xs)

RE: -O* does more than what's in optLevelFlags?

Oh, now I get it. I misunderstood you. But the point is, I do *not* want to set optLevel. I want to turn on individual optimizations. But as it stands today, if I turn on any optimizations, that doesn’t do anything unless I *also* set optLevel to >= 1. Yes I agree. Nothing should consult

RE: -O* does more than what's in optLevelFlags?

Is this a documentation bug, an implementation bug (as in, if any of the relevant opts are set, then the CoreToDos should always include the optimization steps selected), or a design bug (there is no way to support this meaningfully)? Maybe a documentation bug? You should update the

RE: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*)

It's incredibly hard to debug this sort of thing remotely, without the ability to reproduce it. First, you are using a variant of GHC, with changes that we can only guess at. Second, even with unmodified GHC I often find that unexpected things happen - until I dig deeper and it becomes

RE: Why can't arguments be levity polymorphic for inline functions?

We do have a few such functions, and we give them a "compulsory unfolding" which means they MUST be inlined at EVERY call site. But * Usually if a module exports a function, it generates code for that function. But for these guys it can't. We don't have a mechanism for *not* generating

RE: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*)

Grego, Yes I think that should auto-specialise. Which version of GHC are you using? Do you have this patch? commit ef0135934fe32da5b5bb730dbce74262e23e72e8 Author: Simon Peyton Jones simo...@microsoft.com Date: Thu Apr 8 22:42:31 2021 +0100 Make the

RE: Instantiation of overloaded definition *in Core*

You can look it up in the class instance environment, which the Simplifier does have access to it. That's relatively easy when you have a simple dictionary like (Monad IO). But if you want (Eq [Int]) you first of all have to look up the (Eq [a]) dictionary, then the Eq Int dictionary, and

RE: SOLVED: GHC 9.3 API panics with "No home unit"

Norman, I'm glad you are unstuck. We badly need a bird's eye view of the GHC API, with chapters about specific bits. It shouldn't be a question of trial an error. But it evolved rather than being designed, and since then everyone's shortest path to completion is simply to find a way through

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

latest%2Fmarkup.html%23named-chunks=04%7C01%7Csimonpj%40microsoft.com%7C1bd0b32d10d941aff47008d977883fda%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637672251247580027%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=34wGCjxKe4A0u9hiIHHG82PN82gxV1MM%2B7w2Kl2RFT0%3D=0>

RE: More type safety in Core?

One difficulty is that I think that writing Core-to-Core passes might become a lot more challenging. It gets gnarly writing code that satisfies the type checker, depending of course on how strong the invariants are. I think Typesafe runtime code

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

Alfredo writes (below for full thread) That is a deceptively simple question you ask there :-) I don't have a strong view myself, but I can offer the perspective of somebody who was been for a long time on the "other side of the trenches" (i.e. working Haskell programmer, not necessarily

Resuming normal service

Friends What with the summer holidays and leaving MSR, I've been rather preoccupied and have done almost nothing on GHC for the last six weeks. I'm getting back in action now - I hope. But my GHC backlog is huge. If you are waiting on some response from me, please feel free to ping me. Simon

RE: Question about specialization

Harendra That comes as a surprise to me. Could you possibly make a repo case, and say what version of the compiler does, and does not, specialise the function? File it as a ticket … to me it looks like a bug. Thanks Simon From: ghc-devs On Behalf Of Harendra Kumar Sent: 06 September 2021

RE: New implementation for `ImpredicativeTypes`

Of course not. The same was true for QuickLook, though, wasn't it? No, not at all. QuickLook required zero changes to GHC's intermediate language - it impacted only the type inference system. Adding existentials will entail a substantial change to the intermediate language, affecting every

RE: New implementation for `ImpredicativeTypes`

If I understand correctly, the recent ICFP paper "An Existential Crisis

RE: Using overloaded syntax to avoid `base` dependency (RE: Marking ParsedModule fragments as non-user-originating)

But then, does that mean that the `ol_witness` field of the `OverLit` is not used by the renamer at all? * In (HsOverLit GhcPs), which is the output of the parser, and the input of the renamer, the ol_witness field is garbage. See GHC.Hs.Utils.mkHsIntegral, which fills that field

RE: Potential improvement in compacting GC

Thanks Omer I had an interesting conversation with Steve Blackburn, the brains behind the MMTk memory management toolkit recently https://www.mmtk.io/ MMTk is designed to be a re-usable, open-source garbage collector, specifically designed to be usable with lots of languages. In principle this

RE: Using overloaded syntax to avoid `base` dependency (RE: Marking ParsedModule fragments as non-user-originating)

I don't really understand how my question fits into the 'bug report' bucket. The quoted passage is not from the user manual, but rather, from a GHC Note Only that GHC is doing something that you think is wrong - or at least not as documented. If so, that's a bug. If not, the conversation is

RE: Using overloaded syntax to avoid `base` dependency (RE: Marking ParsedModule fragments as non-user-originating)

Gergo, If you think you have uncovered a bug, could you submit a bug report on the issue tracker, with a way to reproduce it? It's a bit hard to decode exactly what is happening from what you say. The user manual documentation doesn't say this in so many words (that's a bug), but with

RE: Can NamedFieldPuns be added to `GHC.LanguageExtensions.Types.Extension`?

issues, but only with other plugins, and probably with vanishingly few of them. Grep in Hackage! Simon From: ghc-devs On Behalf Of Alfredo Di Napoli Sent: 06 July 2021 10:14 To: Simon Peyton Jones via ghc-devs Subject: Can NamedFieldPuns be added to `GHC.LanguageExtensions.Types.Extension

RE: Trying to speedup GHC compile times...Help!

ghc-devs@haskell.org | Subject: Re: Trying to speedup GHC compile times...Help! | | On Fri, Jul 02, 2021 at 08:08:39AM +, Simon Peyton Jones via ghc-devs | wrote: | | > I strongly urge you to keep a constantly-update status wiki page, | > which lists the ideas you are working

RE: Marking ParsedModule fragments as non-user-originating

The typechecker now complains that the `ViewPatterns` language extension is not turned on I think it's the renamer: rnPatAndThen mk p@(ViewPat _ expr pat) = do { liftCps $ do { vp_flag <- xoptM LangExt.ViewPatterns ; checkErr vp_flag (badViewPat p) } More

RE: Trying to speedup GHC compile times...Help!

under binders). i.e. the IntMap is not just used to generate new variable names, but to ensure the compiler does less work in the form of doing fewer substitutions. On Fri, 2 Jul 2021 at 16:12, Simon Peyton Jones via ghc-devs mailto:ghc-devs@haskell.org>> wrote: There are lot of places where i

RE: Trying to speedup GHC compile times...Help!

, at 4:08 AM, Simon Peyton Jones via ghc-devs mailto:ghc-devs@haskell.org>> wrote: Jeff Great stuff! Welcome. I strongly urge you to keep a constantly-update status wiki page, which lists the ideas you are working on, and points to relevant resources and tickets. An email threa

RE: Trying to speedup GHC compile times...Help!

Jeff Great stuff! Welcome. I strongly urge you to keep a constantly-update status wiki page, which lists the ideas you are working on, and points to relevant resources and tickets. An email thread like this is a good way to gather ideas, but NOT a good way to organise and track them.

RE: Is there a way to prevent reboxing in W/W (due to OPAQUE pragma proposal)

Christiaan I'm totally paged out on this. Would you like to do this via a comment on !5562, giving a concrete example of a small program that doesn't behave as you expect with your patch? Sebastian may be able to help too. Simon From: ghc-devs On Behalf Of Christiaan Baaij Sent: 24 June

RE: Is simplified subsumption really necessary?

evs@haskell.org> Cc: Simon Peyton Jones <mailto:simo...@microsoft.com> Subject: Re: Is simplified subsumption really necessary? On 6/16/21 12:00 PM, Simon Peyton Jones via ghc-devs wrote: I'm sorry to hear that Chris. It's exactly backwards from what I would expect - the typing rules with

RE: Is simplified subsumption really necessary?

nversation. Simon From: John Ericson Sent: 18 June 2021 16:56 To: ghc-devs Cc: Simon Peyton Jones Subject: Re: Is simplified subsumption really necessary? On 6/16/21 12:00 PM, Simon Peyton Jones via ghc-devs wrote: I'm sorry to hear that Chris. It's exactly backwards from what I wou

RE: Error message degradation for (<= :: Nat -> Nat -> Constraint) in GHC 9.2+

Christiaan, Do please submit a bug report on GHC's issue tracker, with a way to reproduce it. Thanks Simon From: ghc-devs On Behalf Of Christiaan Baaij Sent: 17 June 2021 10:44 To: ghc-devs Subject: Error message degradation for (<= :: Nat -> Nat -> Constraint) in GHC 9.2+ Hi Ghc-Devs,

RE: Is simplified subsumption really necessary?

rather, it's that it completely screws up my intuition about what should be valid Haskell. I'm sorry to hear that Chris. It's exactly backwards from what I would expect - the typing rules with simple subsumption are, well, simpler than those for complicated subsumption, and so one might hope

RE: abstract interpreter for GHC Core or STG

I wonder if there was an attempt in the past to create an abstract interpreter for GHC Core or STG to approximate the program runtime behaviour? No, not that I know of. Because of all the primops, concurrency, STM, etc, it would be something of a challenge. The AAM story could be

RE: ghcup failed

ows/wsl/install-win10 Thanks Simon From: ghc-devs On Behalf Of Simon Peyton Jones via ghc-devs Sent: 02 June 2021 20:07 To: GHC Cc: Julian Ospald Subject: ghcup failed Dear devs I wanted to install GHC 8.10 on my WSL2 (Windows Subsystem for Linux) computer. So I went here https://www.haskell.

ghcup failed

Dear devs I wanted to install GHC 8.10 on my WSL2 (Windows Subsystem for Linux) computer. So I went here https://www.haskell.org/ghcup/ and followed the instructions (the curl … command). There was a long pause then [ Info ] verifying digest of: ghc-8.10.4-x86_64-deb9-linux.tar.xz [ Info ]

RE: value of documenting error messages?

| e.g. "conflicting_trait_implementations" seems better than "E0119" I don't think so. If the compiler prints "E0119" and I search for that, I know I'm going to get exactly that, not similar but subtly different things. (A free text search might also throw up illuminating info, but is much

RE: value of documenting error messages?

Rust has taken an interesting approach for this: every error message is given a unique number like "E0119" and there is an error

Errors in haddock git fetch

I'm getting these errors from `git submodule update`. Should I worry? Simon >From https://gitlab.haskell.org/ghc/haddock * [new branch]az/T19834 -> origin/az/T19834 * [new branch]az/T19834-2

RE: Coding style: Using StandaloneKindSignatures in GHC

I’m good with those rules. Simon From: ghc-devs On Behalf Of Richard Eisenberg Sent: 21 May 2021 21:21 To: Chris Smith Cc: GHC developers Subject: Re: Coding style: Using StandaloneKindSignatures in GHC I agree with Chris here. Let me expand upon my counter-proposal: * A datatype

RE: Coding style: Using StandaloneKindSignatures in GHC

I'm all for "encourage" but not keen on "require". Simon | -Original Message- | From: ghc-devs On Behalf Of Hécate | Sent: 18 May 2021 19:18 | To: ghc-devs@haskell.org | Subject: Re: Coding style: Using StandaloneKindSignatures in GHC | | After reading this proposal, I agree that

RE: ZuriHac 2021 - GHC Track - Call for Contributions

Andreas, Niklas Would an "ask me anything" slot be useful? We could get a handful of GHC devs (eg me) together and invite participants to ask about GHC specifics. Not so much personal "how long have you worked on GHC?" but more technical "how does class instance lookup work?". I'd be

Warnings

If 'transformers' purposely has orphan instances, shouldn't we switch off the warnings about them? Simon "/opt/ghc/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -package-db libraries/bootstrapping.conf -this-unit-id transformers-0.5.6.2 -hide-all-packages -package-env - -i

Compiling libraries

Ben and other friends What is the approved way to build libraries with (and for) a compiler that I've just built? I tried this: bash$ cabal v2-install --with-ghc=/home/simonpj/code/ghc-9.2-branch/inplace/bin/ghc-stage2 streamly --allow-newer but it failed with Data/Primitive/Types.hs:273:844:

RE: magicDict

me is similar to 'withTypeable' or 'withFile', | and avoids arguing which is reify or reflect. | | On Mon, Apr 26, 2021 at 9:41 AM Simon Peyton Jones via ghc-devs mailto:d...@haskell.org>> wrote: | > | > Can we just agree a name, then? Please correct me if I'm wron

RE: magicDict

ut in existing applications magicDict gets the arguments | in the reverse order. | 2. Easier to chain 'withDict d1 (withDict d2 ...)'. | 3. The name is similar to 'withTypeable' or 'withFile', | and avoids arguing which is reify or reflect. | | On Mon, Apr 26, 2021 at 9:41 AM Simon Peyto

RE: magicDict

Can we just agree a name, then? Please correct me if I'm wrong, but * I think Ed prefers 'reifyDict', * That is compatible with the existing reflection library * Arnaud disagrees but isn't going to die in the trenches for this one * Virtually anything is better than 'magicDict'.

RE: magicDict

%2FxqVcJvVpRJSkBIEZojqmKyqhpv7gr9XU%3Dreserved=0 | | On Thu, Apr 22, 2021 at 3:27 PM Spiwack, Arnaud | wrote: | > | > Let me upvote `reflectDict`. | > | > On Thu, Apr 22, 2021 at 12:41 PM Simon Peyton Jones via ghc-devs | wrote: | >> | >> Ed, and other ghc-devs | >>

magicDict

Ed, and other ghc-devs We are busy tidying up magicDict, and making it much more type-safe: see * https://gitlab.haskell.org/ghc/ghc/-/issues/16646 * https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5573 As part of that change we're think of changing its currently-rather-obscure name.

RE: External STG Interpreter blog post

That's extremely impressive, Csaba. Maybe of interest to folk who have been thinking about "fat interface files". Simon From: ghc-devs On Behalf Of Csaba Hruska Sent: 10 April 2021 11:49 To: GHC developers Subject: External STG Interpreter blog post Hello, I've written a blog post about

RE: Multiple versions of happy

./configure Hope that helps. Cheers, Sebastian Am Di., 30. März 2021 um 15:19 Uhr schrieb Simon Peyton Jones via ghc-devs mailto:ghc-devs@haskell.org>>: What's the approved mechanism to install multiple versions of happy/alex etc? Eg I tried to build ghc-9.0 and got this: checking for ma

Multiple versions of happy

What's the approved mechanism to install multiple versions of happy/alex etc? Eg I tried to build ghc-9.0 and got this: checking for makeinfo... no checking for python3... /usr/bin/python3 checking for ghc-pkg matching /opt/ghc/bin/ghc... /opt/ghc/bin/ghc-pkg checking for happy...

RE: Why TcLclEnv and DsGblEnv need to store the same IORef for errors?

. Nothing deeper than that I think. Simon From: ghc-devs On Behalf Of Alfredo Di Napoli Sent: 30 March 2021 08:42 To: Simon Peyton Jones via ghc-devs Subject: Why TcLclEnv and DsGblEnv need to store the same IORef for errors? Hello folks, as some of you might know me and Richard are reworking

RE: Type inference of singular matches on GADTs

I'm not saying this is a good idea for GHC or that it's implementable. But the idea of having type inference account for exhaustivity in this way does not seem, a priori, unspecified. No, but I’m pointing out that specifying it might be tricky, involving some highly non-local reasoning. I

RE: Type inference of singular matches on GADTs

I haven't thought about how to implement such a thing. At the least, it would probably require some annotation saying that we expect `\HNil -> ()` to be exhaustive (as GHC won't, in general, make that assumption). Even with that, could we get type inference to behave? Possibly. As I wrote in

config.sub

Folks I'm getting a lot of this simonpj@MSRC-3645512:~/code/HEAD-3$ git status On branch wip/T19569 Your branch is up to date with 'origin/wip/T19569'. Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git restore ..." to discard changes in

RE: Options for targeting Windows XP?

This link gives some (old) background https://wiki.haskell.org/GHC/FAQ#Why_isn.27t_GHC_available_for_.NET_or_on_the_JVM.3F Simon From: ghc-devs On Behalf Of Moritz Angermann Sent: 26 March 2021 08:00 To: Clinton Mead Cc: ghc-devs Subject: Re: Options for targeting Windows XP? I believe there

RE: Type inference of singular matches on GADTs

What would you expect of 1. \x -> case x of HNil -> blah Here the lambda and the case are separated. 1. \x -> (x, case x of HNil -> blah) Here the lambda and the case are separated more, and x is used twice. What if there are more data constructors that share a common return type?

GitLab is down: urgent

GHC's GitLab seems to be down. Ben? (I just get 502's) Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: On CI

We need to do something about this, and I'd advocate for just not making stats fail with marge. Generally I agree. One point you don’t mention is that our perf tests (which CI forces us to look at assiduously) are often pretty weird cases. So there is at least a danger that these more

RE: Build failure -- missing dependency? Help!

ion of modules from separate packages and respects the dependency between `base` and `ghc-bignum`. So we should add a similar fake import into libraries/base/GHC/Exception/Type.hs-boot. I will open a MR. Sylvain On 14/03/2021 21:53, Simon Peyton Jones via ghc-devs wrote: I'm getting this (with

Build failure -- missing dependency? Help!

I'm getting this (with 'sh validate -legacy'). Oddly * It does not happen on HEAD * It does happen on wip/T19495, a tiny patch with one innocuous change to GHC.Tc.Gen.HsType I can't see how my patch could possible cause "missing files" in ghc-bignum! I'm guessing that there is a missing

RE: Inlining of `any @[]` vs `elem @[]`

Ah, sorry, I thought it was just curiosity about what has changed. I am not sure whether there will be future 8.10 releases; but you can open a ticket asking Ben to backport the fix (which you have found) to 8.10, if there is to be such a release. Simon | -Original Message- | From:

RE: Inlining of `any @[]` vs `elem @[]`

| I wonder why that is? What changed between GHC 8.10.3 and 9.0.1? Was | the definition of `elem` changed in `base`? I'm not sure... you could investigate, but I'm inclined just to declare victory! S | -Original Message- | From: ÉRDI Gergő | Sent: 12 March 2021 10:02 | To: Simon

RE: WSL2

at 07:53:20PM +, Simon Peyton Jones via ghc- | devs wrote: | | > Voila | | Thanks! | | > /etc/nsswitch.conf group entry | > group: files systemd | | The main "suspicious" thing here (decoded traces below my signature) | is that the nsswitch.conf file i

RE: WSL2

@haskell.org | Subject: Re: WSL2 | | On Thu, Mar 11, 2021 at 12:21:15PM +, Simon Peyton Jones via ghc- | devs wrote: | | > Like Tom, I'm not following the details, but if you want me to run | > some commands and send you the output I can do that. Just send the | > script! |

RE: Inlining of `any @[]` vs `elem @[]`

Gergo With HEAD, and -O, I get the exact same (good code) for these two functions: f x = any (x ==) [1, 5, 7::Int] g x = elem x [2, 6, 9 :: Int] namely f = \ (x_aga :: Int) -> case x_aga of { GHC.Types.I# x1_a13b -> case x1_a13b of { __DEFAULT ->

RE: WSL2

PS: since this is not, apparently, just my stupidity, it would be good to open a ticket and transfer this thread to it. Would someone like to do that? | -Original Message- | From: ghc-devs On Behalf Of Tom Ellis | Sent: 11 March 2021 11:41 | To: ghc-devs@haskell.org | Subject: Re:

RE: WSL2

Like Tom, I'm not following the details, but if you want me to run some commands and send you the output I can do that. Just send the script! | -Original Message- | From: ghc-devs On Behalf Of Tom Ellis | Sent: 11 March 2021 11:41 | To: ghc-devs@haskell.org | Subject: Re: WSL2 |

RE: WSL2

//bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; VERSION_CODENAME=focal UBUNTU_CODENAME=focal | -Original Message- | From: Ben Gamari | Sent: 10 March 2021 17:22 | To: Simon Peyton Jones ; ghc-devs | Subject: Re: WSL2 |

WSL2

Friends I've just installed WSL2 and built GHC. I get this (single) validation failure in libraries/unix/tests/getGroupEntryForName. It seems to be just an error message wibble, but I can't push a change to master because that'll affect everyone else. Any ideas? Simon => 1 of 1 [0, 0, 0]

RE: MR template text

changed it? On 24 Feb 2021, at 3:14 am, Simon Peyton Jones via ghc-devs mailto:ghc-devs@haskell.org>> wrote: I often see MRs in my inbox that say Thank you for your contribution to GHC! Please take a few moments to verify that your commits fulfill the following: [ ] are either indivi

MR template text

I often see MRs in my inbox that say Thank you for your contribution to GHC! Please take a few moments to verify that your commits fulfill the following: [ ] are either individually buildable or squashed This is because the author hasn't changed the Description of the MR, but rather has left

RE: On CI

imistic caching. Therefore, evict the "optimistic caches" and restart building the libraries. That way we can validate that the build failure was a true build failure and not just due to the aggressive caching scheme. Just my 2p Josef ____________ From: ghc-de

RE: On CI

1. Building and testing happen together. When tests failure spuriously, we also have to rebuild GHC in addition to re-running the tests. That's pure waste.

RE: Plan for GHC 9.2

Ben Can we get record dot syntax into 9.2? * Shayne is really nearly there in !4532; he has been working hard and recently. * It depends on my !4981 (was 4722) which fixes some bugs and I'm keen to commit. So, is it ok in principle to pull to trigger on !4981, and hopefully !4532? Simon

cep_app traces

Ben I'm getting a lot of cpe_app(keepAlive#) 3 cpe_app(keepAlive) trace messages from HEAD. Maybe it's a leftover from tracing when you were developing? Remove? Simon ___ ghc-devs mailing list ghc-devs@haskell.org

RE: Plan for GHC 9.2

Yes I agree, unlifted data types would be terrific. From: ghc-devs On Behalf Of Sebastian Graf Sent: 11 February 2021 10:25 To: Ben Gamari Cc: ghc-devs Subject: Re: Plan for GHC 9.2 Hi, Since my hopes of finally merging Nested CPR have recently been crushed again, I hope that we can include

RE: Stop holding hadrian back with backwards compatibility

build with hadrian, and then continue using make with the artifacts (partially) built by Hadrian I agree this is a non-goal. Simon From: ghc-devs On Behalf Of Moritz Angermann Sent: 10 February 2021 13:32 To: Richard Eisenberg Cc: ghc-devs Subject: Re: Stop holding hadrian back with

Happy version downgrade

Friends I can't build ghc-9.0 because of this: checking for ghc-pkg matching /opt/ghc/bin/ghc... /opt/ghc/bin/ghc-pkg checking for happy... /home/simonpj/.cabal/bin/happy checking for version of happy... 1.20.0 configure: error: Happy version 1.19 is required to compile GHC. What is the

RE: Inspecting function arguments in GHCi

Andrew We have very poor documentation of the inner workings of the entire breakpoint and debugging mechanism. And very few (zero?) people who truly understand it. You could do a great service by starting a Note or a wiki page or something that lays out the moving parts. You may not feel that

RE: presentation: Next-gen Haskell Compilation Techniques

I may not emphasize in the talk, but the goal of the grin compiler project is to build a compiler pipeline that allows easy experimentation of different compilation techniques. Anything between whole program compilation to per module incremental codegen. So the whole program compilation is not

Title index

Ben On GHC's wiki home page we have Title Index over in the right margin. I thought the title index was auto-generated. But it doesn't contain this

Nominations close Jan 11th for the Haskell Foundation Board

Friends Happy new year! The closing date for self-nominations for membership of the Board of the Haskell Foundation is in just under a week: Monday January 11th 2021 The Haskell Foundation is a new non-profit organisation that seeks to articulate the benefits of

HEAD user manual

Where can I find the GHC user manual for HEAD these days? I tried https://ghc.gitlab.haskell.org/ghc/doc/, but that takes me to 8.11. The user documentation page https://gitlab.haskell.org/ghc/ghc/-/wikis/ghc-users-guide#ghc-users-documentation has the same link. Thanks Simon

RE: Correct way of extending the context of the typechecker

Yiyun You might need to explain in a bit more detail. The simplest thing may be this. * Define, say, (==>) in some ordinary Haskell source module, say Liquid.Haskell * Look up "Liquid.Haskell.==>", to get its Name, via GHC.Iface.Env.lookupOrig * Then you can look up that Name, via

  1   2   3   4   5   6   7   8   9   10   >