RE: Fat interface files?

Thanks Mortiz That wiki page is about extensible interface files in general. It says nothing about specifically putting Core terms into interface files. For the Core part, since GHC already puts Core into unfoldings, the simple thing is just to expose all unfoldings, no? Simon From: ghc-devs

RE: GHC's internal confusion about Ints and Words

Now I've gone ahead and effectively assume Cmm is lying to me when generating Foreign Function Calls, and rely on the (new) sized hints to produce the appropriate argument packing on the stack Why not instead just stop Cmm lying? S From: Moritz Angermann Sent: 20 October 2020 15:03 To: Carter

RE: GHC's internal confusion about Ints and Words

Moritz I’m afraid I don’t understand any of this. Not your fault, but I just don’t have enough context to know what you mean. Is there a current bug? If so, can you demonstrate it? If not, what is the problem you want to solve? Examples are always helpful. Maybe it’s worth opening a tick

RE: type parameters in a HsType

I think you are asking for a function to find the free variable of a HsType: freeVars :: HsType Ps -> [Located RdrName] Then you could see if the free vars intersects the binders. Right? If so, try GHC.Rename.HsType.extractHsTyRdrTyVars Simon From: ghc-devs On Behalf Of Tseen She Sent: 06 Oc

RE: Help making exception-related primops open-kinded

You would have to be pretty careful to make them open-kinded. You'd need to make sure that the implementation of these primops (which is quite complicated) never touches or moves that result value. Maybe it is so, and if so it'd be useful -- but should be *prominently* document in the RTS C co

RE: How is GHC.Prim.unpackInt8X64# meant to be used?

Hmm. It’s not clear to me why we have *any* limitation on the size of unboxed tuples. For boxed tuples I know: we need an info table, code etc. But not so for unboxed. Why do we need a limit at all? Simon From: ghc-devs On Behalf Of Ryan Scott Sent: 25 September 2020 23:21 To: GHC develope

Quick Look has landed

Dimitrios, Jurriaan, Alejandro I'm happy to tell you that Quick Look has landed on GHC's master branch. It'll be in GHC 9.2, but is usable already by building HEAD. Good work! The implementation is very faithful to the paper, which was an invaluable guide. Simon ___

RE: Parser depends on DynFlags, depends on Hooks, depends on TcM, DsM, ...

s by passing hooks separately > to DynFlags and providing a separate plugin interface to modify hooks. > But doing so will necessarily break existing plugins. > > Adam > > > On 14/09/2020 11:25, Simon Peyton Jones via ghc-devs wrote: > > I

RE: Parser depends on DynFlags, depends on Hooks, depends on TcM, DsM, ...

- | From: Adam Gundry | Sent: 14 September 2020 13:12 | To: Simon Peyton Jones | Cc: ghc-devs@haskell.org | Subject: Re: Parser depends on DynFlags, depends on Hooks, depends on | TcM, DsM, ... | | On 14/09/2020 12:45, Simon Peyton Jones via ghc-devs wrote: | > | I guess this can

RE: Parser depends on DynFlags, depends on Hooks, depends on TcM, DsM, ...

oviding a separate plugin interface to modify hooks. | But doing so will necessarily break existing plugins. | | Adam | | | On 14/09/2020 11:25, Simon Peyton Jones via ghc-devs wrote: | > I thought I’d sent a message about this DynFlags thing, but I can’t | > trace it now.   So h

RE: Parser depends on DynFlags, depends on Hooks, depends on TcM, DsM, ...

I thought I’d sent a message about this DynFlags thing, but I can’t trace it now. So here’s a resend. Currently * The DynFlags record includes Hooks * Hooks in contains functions, that mention TcM, DsM etc This is bad. We should think of DynFlags as an abstract syntax tree. That is,

RE: Simplifier vs. rules problem

Interesting. I have opened https://gitlab.haskell.org/ghc/ghc/-/issues/18677 for this. Simon | -Original Message- | From: ghc-devs On Behalf Of | michael.sper...@active-group.de | Sent: 11 September 2020 15:24 | To: ghc-devs@haskell.org | Subject: Simplifier vs. rules problem | |

RE: Parser depends on DynFlags, depends on Hooks, depends on TcM, DsM, ...

And for sure the *parser* should not depend on the *desugarer* and *typechecker*. (Which it does, as described below.) S From: ghc-devs On Behalf Of Sebastian Graf Sent: 10 September 2020 14:12 To: Sylvain Henry Cc: ghc-devs Subject: Parser depends on DynFlags, depends on Hooks, depends on

RE: WebUI for GHC/Haskell tooling (eventlog)

Csaba I don’t know anything useful about tooling, WebUI, eventlog2html, etc. But I do know that these things are important, so thank you so much for working on them! I assume you in touch with the (new, unified) team working on the Haskell IDE? Thanks again Simon From: ghc-devs On Behalf

RE: !RE: Implicit reboxing of unboxed tuple in let-patterns

: Re: !RE: Implicit reboxing of unboxed tuple in let-patterns On Mon, Sep 7, 2020 at 5:12 AM Simon Peyton Jones via ghc-devs mailto:ghc-devs@haskell.org>> wrote: 1. I don’t understand the details of Iavor’s proposal to add that “unlifted patterns are strict”, in addition to (1). Do yo

!RE: Implicit reboxing of unboxed tuple in let-patterns

I’m a bit late to this debate, but here are a few thoughts. 1. “Right now, there is one rule: if the type of any variable bound in the pattern is unlifted, then the binding is strict.”Not only is this rule simple and consistent, it is also necessary: we cannot bind a variable of unlifte

Perf baselines

Ben CI is saying (on !3889) Missing Baseline Metrics these metrics trivially pass because a baseline (expected value) cannot be recovered from previous git commits. This may be due to HEAD having new tests or having expected changes, the presence of expected changes since the last run of the tes

RE: Breakage on master

SSERTs, you should just have to import | GHC.Utils.Panic to fix the issue or is there something else? | | Sylvain | | On 19/08/2020 10:24, Simon Peyton Jones via ghc-devs wrote: | > | Strangely, `./validate --legacy --slow` also appears to work fine | for | > | me | > | on 55fd1dc55990623

RE: Breakage on master

| Strangely, `./validate --legacy --slow` also appears to work fine for | me | on 55fd1dc55990623dcf3b2e6143e766242315d757. | | Simon, can you describe how you were previously building GHC? ./validate --legacy --fast with this validate.mk (below). But the issue is terribly simple: assertPp

RE: Breakage on master

| meantime the issue can be worked around by reverting | accbc242e555822a2060091af7188ce6e9b0144e. Alas, not so. git revert accbc242e555822a2060091af7188ce6e9b0144e warning: Failed to merge submodule utils/haddock (commits don't follow merge-base) error: could not revert accbc242e5... DynFlags

RE: The curious case of #367: Infinite loops can hang Concurrent Haskell

My question is earlier: why do we generate code that we will never to get out again? Ah, well, if you say, for example f x = f x then it seems reasonably to generate an infinite loop. I don’t know if that’s what’s happening here, but it seems reasonable in principle. I’m unsur

RE: The curious case of #367: Infinite loops can hang Concurrent Haskell

| and the question then becomes, do we want to investigate if we can | a) detect this is dead code | b) remove it in Cmm or higher, or flat out prevent it from being | generated. | c) we don't care about producing this code, and hope the linker will | eliminate it. I'm still puzzled. Why do

RE: The curious case of #367: Infinite loops can hang Concurrent Haskell

Moritz I'm not getting this. | So, my question then is this: are we fine with ghc generating this | code? Or, if we are not, do we want to figure out if we can eliminate | it? What exactly is "this code" and "it"? You could be asking * Should we switch off -fomit-yields by default? * Shou

RE: Hi. I'm new to this mailing list and have a few questions.

Welcome Anselm. ghc-devs is a very informal mailing list, and we welcome newcomers. For example, I have a feature idea in the back of my mind, which I imagine would be easy to implement What Richard says is right, but you should feel free to fly the kite on this list if you want – or on Haske

RE: How should we treat changes to the GHC API?

My real question is this: * Who “owns” (as in: takes responsibility for) the GHC API? If no person, or no group of people, feels responsible for it, it’ll just grow in a disorganised fashion, which is why we are where we are. This discussion thread has focused mainly on stability, but there

RE: How should we treat changes to the GHC API?

What I’m after is a clear opportunity for informed debate, and a clear yes/no decision. That need not be high overhead. It means paying some upfront cost for design changes. But that’s better than the legacy cost of dealing with things that turn out, in retrospect, to be less well designed th

How should we treat changes to the GHC API?

A recent MR for GHC (adding machinery for plugins to write data to extensible interface files) made me wonder: how we should treat significant changes to the GHC API? Changes to the GHC API, especially to bits used by plugins or by IDEs, a

RE: New Windows I/O manager in GHC 8.12

Tamar, I salute you! This is a big piece of work – thank you! Simon From: ghc-devs On Behalf Of Phyx Sent: 17 July 2020 16:04 To: ghc-devs@haskell.org Devs Subject: New Windows I/O manager in GHC 8.12 Hi All, In case you've missed it, about 150 or so commits were committed to master yesterda

RE: Unmerged Patch: 3358

Matthew It looks from https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3358 as if it was blocked on something to do with 'text'. Is that unblocked now? The MR also says "Fast forward merge is not possible". So it sounds as if the steps are: * Check that the change to text, whatever that is

RE: Error messages

Thanks Erik. Error message quality is crucial, as you say. But it's a very hard thing to measure, because it's a matter of human judgement. For example, you suggest | I would like to suggest that a prerequesite for merging of new features would | be that it provides good error messages and

RE: HEAD doesn't build. Totally stalled.

t.com%7Cfe3793e59fa24b1203da08d829977b95%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637305077875360775&sdata=w9%2Fhwx19Qm5sVTXCcz63uOFGzUY0WeLKhSK%2BKNkakpA%3D&reserved=0> You should be able to just comment them out. I’ll prepare a proper fix. Cheers, Moritz On Tue, 14 Jul 2020 at 6:41 PM, Simon Peyto

RE: HEAD doesn't build. Totally stalled.

amp;sdata=ZsFoKS2k97fO4RSeSpv%2FYgwx08l68PcFJhigZB9mbNw%3D&reserved=0> You should be able to just comment them out. I’ll prepare a proper fix. Cheers, Moritz On Tue, 14 Jul 2020 at 6:41 PM, Simon Peyton Jones via ghc-devs mailto:ghc-devs@haskell.org>> wrote: I’m getting this failu

RE: HEAD doesn't build. Totally stalled.

amp;sdata=C8UXF5FKuQ3MuoRuV5UgOH2bftZ3GMgXiKx4B1BAtZM%3D&reserved=0> You should be able to just comment them out. I’ll prepare a proper fix. Cheers, Moritz On Tue, 14 Jul 2020 at 6:41 PM, Simon Peyton Jones via ghc-devs mailto:ghc-devs@haskell.org>> wrote: I’m getting this failure i

Review for !2377 Haddock and GHC

Fellow GHC devs I'd like to ask your help with reviewing a GHC patch !2377: Accumulate Haddock comments in P (#17544, #17561, #8944) It's a substantial patch to the parser, changi

RE: HEAD doesn't build. Totally stalled.

r fix. Cheers, Moritz On Tue, 14 Jul 2020 at 6:41 PM, Simon Peyton Jones via ghc-devs mailto:ghc-devs@haskell.org>> wrote: I’m getting this failure in a clean HEAD build. Any ideas?I’m totally stalled because I can’t build GHC any more. I’m using Windows Subsystem for Linux (WSL). H

HEAD doesn't build. Totally stalled.

I'm getting this failure in a clean HEAD build. Any ideas?I'm totally stalled because I can't build GHC any more. I'm using Windows Subsystem for Linux (WSL). Help help! Thanks Simon /home/simonpj/code/HEAD-9/rts/dist/build/libHSrts_thr_p.a(RtsSymbols.thr_p_o): RtsSymbols.c:rtsSyms: error: u

RE: Perf notes

Simon, you are on windows, correct? If so the result you posted is using the "x86_64-linux-deb9" environment as a baseline when it should be using "x86_64" which is much closer to the result you're getting. WSL actually. (Windows Subsystem for Linux.) Simon From: David Eichmann Sent: 02 July

RE: Perf notes

Re the doubling of bytes-allocated on T9803, that's a good point. Due to the recent change in RSA keys, CI is recently failing to upload metrics (e.g. [1])! I'll fix that then see if I can track down where / if the metric has really regressed in master. Thanks Yes we run CI on MRs, but once me

RE: Perf notes

2. Run the relevant perf tests 3. Checkout your branches HEAD commit again 4. Run the relevant tests again. If that doesn't do it, I can have a closer look. David E On 6/26/20 11:29 AM, Simon Peyton Jones via ghc-devs wrote: Despite a recent git fetch https://gitlab.hask

Perf notes

Despite a recent git fetch https://gitlab.haskell.org/ghc/ghc-performance-notes.git refs/notes/perf:refs/notes/ci/perf I'm getting lots of perf regressions in HEAD. For example => T9203(normal) 1 of 1 [0, 0, 0] ]0;T9203(normal) 1 of 1 [0, 0, 0]cd "T9203.run" && "/home/simonpj/code/HEAD-3/

RE: GHC/ | GHC doesn't inline small type class method marked as INLINE with profiling enabled (#18372)

I get a 404 for https://gitlab.haskell.org/ghc/ghc/-/issues/18372 You may need to re-submit this… s From: Andrzej Rybczak Sent: 21 June 2020 15:44 To: Simon Peyton Jones Subject: GHC/ | GHC doesn't inline small type class method marked as INLINE with profiling enabled (#18372) Andrzej Rybc

Gitlab corrupt

Ben Something is amiss. "corrupt" sounds bad! Simon bash$ git fetch error: garbage at end of loose object '62be92e5be07b34fc25c77e36223268c4a6eadec' fatal: loose object 62be92e5be07b34fc25c77e36223268c4a6eadec (stored in ./objects/62/be92e5be07b34fc25c77e36223268c4a6eadec) is corrupt fatal: Th

RE: Gitlab is stuck

All good now? | -Original Message- | From: Ben Gamari | Sent: 19 June 2020 14:37 | To: Simon Peyton Jones ; GHC developers | Subject: Re: Gitlab is stuck | | Simon Peyton Jones via ghc-devs writes: | | > Something is badly wrong with gitlab. I'm trying to push a bra

Gitlab is stuck

Something is badly wrong with gitlab. I'm trying to push a branch. Is some disk full? I am fully stalled. Thanks Simon bash$ git push --force Counting objects: 79, done. Delta compression using up to 20 threads. Compressing objects: 100% (65/65), done. Writing objects: 100% (79/79), 46.21 Ki

Gitlab 503

I'm getting a lot of "Gitlab is unavailable" 503 messages, after editing a wiki page. Does anyone know what is happening? Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Search in GitLab

tic. Simon | -Original Message- | From: Ben Gamari | Sent: 15 June 2020 18:50 | To: Simon Peyton Jones ; GHC developers | Subject: Re: Search in GitLab | | Simon Peyton Jones via ghc-devs writes: | | > Does anyone know how to search better in GitLab. | > Currently I'm usi

Search in GitLab

Does anyone know how to search better in GitLab. Currently I'm using the standard GitLab search. I'm searching for "<>" where I intend the quotes meaning exactly that string as usual in a search term. But I get lots of results mentioning loop, without the angle brackets. Moreover I want to sort

RE: Introducing GHC whole program compiler (GHC-WPC)

I’ve always thought that whole-program compilation has the possibility of doing optimisations that are simply inaccessible without the whole program, but been daunted by the engineering challenges of making WPC actually work. So it’s fantastic that you’ve made progress on this. Well done! Que

RE: Looking for a recent error reporting change

Is there a reason you want to stick with 8.6.5? One way to find what you want is to use git-bisect to find the commit that made the change. I think various people have automated setups for this. Simon From: ghc-devs On Behalf Of Chris Smith Sent: 14 June 2020 14:43 To: ghc-devs@haskell.org Su

Evac.c

I'm getting this in HEAD. Should I worry? It says "error"! Simon rts/sm/Evac.c:463:5: error: note: called from here ACQUIRE_SPIN_LOCK(&gen->sync); ^ | 463 | ACQUIRE_SPIN_LOCK(&gen->sync); | ^ In file included from incl

RE: keepAlive# primop

I’m pretty reluctant to change the Core Language to support one very dark corner use-case. Then every Core consumer and producer must understand the semantics of this new field, and respect that semantics. As I understand it, our definition keepAlive# k x s = case nodiv x s of (# s1, r #) ->

RE: profiling a constructor?

This would be a sensible thing to be able to count with -ticky. Not hard to add either. (Richard is asking for number of allocations, not what is live at any moment.) Simon | -Original Message- | From: ghc-devs On Behalf Of Richard | Eisenberg | Sent: 23 May 2020 13:59 | To: GHC

RE: Strange library git glitch

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 ideas? _

Strange library git glitch

I'm getting this strange output from 'git diff' bash$ git diff diff --git a/libraries/exceptions b/libraries/exceptions --- a/libraries/exceptions +++ b/libraries/exceptions @@ -1 +1 @@ -Subproject commit fe4166f8d23d8288ef2cbbf9e36118b6b99e0d7d +Subproject commit fe4166f8d23d8288ef2cbbf9e36

RE: Unique invariants: GHC invocation vs scope?

Generally, there is no assumption that binders are unique, anywhere in GHC. The Simplifier does remove gratuitious shadowing (like (\x. \x. e)), but there is really no guarantee at any stage. Simon From: ghc-devs On Behalf Of Csaba Hruska Sent: 08 May 2020 14:03 To: GHC developers Subject: U

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), done

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-

Connecting the Wolfram Language to Haskell

Friends Short summary: can someone familiar with using the GHC API offer advice on getting the Wolfram Language connected to Haskell? Many of you will know of the Wolfram Language, which is IMHO pretty cool and not well enough known.There are lots of inte

RE: Why doesn’t the simple optimizer fuse casts?

Good spot. The very simple optimiser is, well, very simple. So let's not do anything complicated. But could you submit a ticket, and patch, to replace that Cast with mkCast? Thanks! Simon | -Original Message- | From: ghc-devs On Behalf Of Alexis King | Sent: 27 April 2020 22:5

RE: T13456

se it. | | Sylvain | | | On 28/04/2020 09:50, Simon Peyton Jones via ghc-devs wrote: | > Ben | > | > I'm still getting framework failures from the testsuite, as below. | > | > But now it's not just me: it's CI! See !2600 which is failing in this | way. | >

RE: T13456

3456 | | | | Simon Peyton Jones via ghc-devs writes: | | | | > I'm getting this failure (below) from validate fairly consistently. | | > It is often silenced by adding an empty file | | > ghci/should_run/T13456.stderr But it's troubling. Does anyone else | see | | this? How

RE: Desugaring matches with already-desugared RHSs?

Alexis We have data MatchGroup p body = MG { mg_ext :: XMG p body -- Post-typechecker, types of args and result , mg_alts:: Located [LMatch p body] -- The alternatives , mg_origin :: Origin } explicitly parameterised over 'body'. And we use that parameterisation: |

RE: Demand signature grammar

Great thanks! There is also https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/strictness-analysis and a couple of sub-pages, as you'll see in the index. It'd be good if they were somehow connected together? Simon | -Original Message- | From: ghc-devs On Behalf Of Ben G

T13456

I'm getting this failure (below) from validate fairly consistently. It is often silenced by adding an empty file ghci/should_run/T13456.stderr But it's troubling. Does anyone else see this? How can I debug it? Thanks Simon Framework failures: /tmp/ghctest-31oxzmog/test spaces/ghci/shoul

T13456

Ben, Omer I find that when running the testsuite, I get the garbage below, for ghci/should_run/T13456. Adding an empty file T13456.stderr seems to fix it in one of my trees, but not in another. Very strange. Any ideas? Simon Framework failures: T13456.run T13456 [Traceback (most recent ca

TcTypeNats

Sylvain TcTypeNats still exists in compiler/typecheck/ An omission? Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

HsTick and HsBinTick

Friends I think HsTick and HsBinTick are added (only) by GHC.HsToCore.Coverage So I think the cannot occur in HsExpr GhcPs or HcExpr GhcRn If so we should change the data type decl to say this explicitly. Can anyone confirm or deny and add a ticket if so? Simon

Safe primops

Andreas, Simon, and other back-end-knowledgeable devs Can I draw your attention to this question? https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3011#note_264584 It's about identifying which primops execute in-line without GC, and without thread-switching. Thanks Simon ___

RE: Fusing loops by specializing on functions with SpecConstr?

Cool -- but please do write a blog post or something to distil what you have learned. I have not followed this thread in detail, and I bet others haven't either. But it'd be a pity for your learning not to be shared somehow! Thanks Simon | -Original Message- | From: ghc-devs On Behalf

Building libraries with an in-place GHC

Devs I want to reproduce #18018, but that needs me to build pandoc with my freshly-built HEAD. I tried this (below) but as you can see that didn't work. What should I do? Thanks Simon bash$ cabal install --with-compiler=/home/simonpj/code/HEAD-3/inplace/bin/ghc-stage2 --package-db=/home/sim

RE: Module Renaming: GHC.Core.Op

I wondered that too. I'd be happy with "Opt" instead of "Op". Simon | -Original Message- | From: ghc-devs On Behalf Of Andreas | Klebinger | Sent: 03 April 2020 21:27 | To: ghc-devs@haskell.org | Subject: Module Renaming: GHC.Core.Op | | Hello devs, | | While I looked at th

RE: Fusing loops by specializing on functions with SpecConstr?

I have started a wiki page for join points here https://gitlab.haskell.org/ghc/ghc/-/wikis/Join-points-in-GHC Do add to it Simon | -Original Message- | From: ghc-devs On Behalf Of Joachim | Breitner | Sent: 01 April 2020 19:37 | To: ghc-devs | Subject: Re: Fusing loops by specializing

RE: Fusing loops by specializing on functions with SpecConstr?

Thanks. Perhaps I was thinking of Section 5 of the join-point paper https://www.microsoft.com/en-us/research/publication/compiling-without-continuations/ That's about compositions of tiny tail recursive loops. Alexis, just conceivably this might be relevant to your thinking on FRP ... but I'm w

RE: Fusing loops by specializing on functions with SpecConstr?

Joachim: this conversation is triggering some hind-brain neurons related to exitification, or something like that. I recall that we discovered we could get some surprising fusion of recursive functions expressed as join points. Something like f . g . h where h loops for a while and returns,

RE: Fusing loops by specializing on functions with SpecConstr?

Wow – tricky stuff! I would never have thought of trying to optimise that program, but it’s fascinating that you get lots and lots of them from FRP. * Don’t lose this thread! Make a ticket, or a wiki page. If the former, put the main payload (including Alexis’s examples) into the Descrip

RE: Advice implementing new constraint entailment rules

Do you know about implication constraints? If not, look back at the OutsideIn(X) paper. An implication constraint carries with it the place to put its Given bindings: see the ic_binds field of Constraint.Implication. And that is exactly what you want. I suspect you'll want an implication to

RE: Roadmap to compacting ModIface

Thanks for writing this down Matthew. But I look at #17097 and I am baffled. Why is that the right list of tasks? Why do we need FastStrings backed by an unpinned ByteArray? (And similarly for each other bullet.) What will the API look like if this project is successful? Why do we want ModI

RE: [core libraries] Re: intent to enable 2fa requirement for github.com/haskell org

I have not been following this. What is the consequence for a regular GHC developer, or someone contributing to GHC? In any announcement please give a way to verify “am I affected?” Thanks Simon From: haskell-core-librar...@googlegroups.com On Behalf Of Carter Schonwald Sent: 18 March 2020

RE: Specializing functions with implicit parameters

Spot on Alexis.Should not be hard to fix this. I think the best thing would be in mkCallUDs * not to use SpecDict for implicit parameters; instead use UnspecArg * don’t require length theta = length dicts. Need to think about what else instead. Isn’t it implied by the arity test?

RE: Selector thunks again

David Yes, quite right. Do make a ticket. But it’s not easy to see a truly robust way to fix this. Selector thunks look like a = case x of (p,q) -> p You example has thunks of the form a = case x of (_,b) -> case b of (c,_) -> c We want this thunk to vanish entir

RE: Class op rules

But now that this has been brought up: currently, does adding an {-# INLINE op #-} (with or without phase) for a class op actually do anything? Currently it does nothing, I think, and therefore should perhaps be rejected today. So I hope no one is doing that. Worth double checking: * Hack

RE: Class op rules

Here’s how it works: * The rewrite fromopi (D m1 … mn) --> mi is done by a BuiltinRule: see MkId.mkDictSelId, and the BuiltinRule that is made there. * At the moment, BuiltinRules are always active (in all phases), see GHC.Core.ruleActivation. To allow them to be selectivel

RE: Advice implementing new constraint entailment rules

Hi Matt I think you are right to say that we need to apply proper staging to the constraint solver. But I don't understand your constraint rewriting rules. Before moving to the implementation, could we discuss the specification? You already have some typeset rules in a paper of some kind, wh

RE: Calling an unknown function from low-level Cmm

I don’t know the answer to this, but Alexis when you find out can I ask (I know I'm a broken record on this) that you write a Note to explain, with pointers from the various places you looked when you were trying to find out the answer? Thanks! Simon | -Original Message- | From: ghc-

RE: Confused about PAP object layout

I’m not following this in detail, but do please make sure that the results of this discussion end up in a suitable Note. Obviously it’s not transparently clear as-is, and I can see clarity emerging Thanks! Simon From: ghc-devs On Behalf Of Simon Marlow Sent: 24 February 2020 08:22 To: Ömer S

RE: Allowing Windows CI to fail

Ben This sounds like a good decision to me, thanks. Is there a possibility to have a slow CI-on-windows job (not part of the "this must pass before merging" step), which will slowly, but reliably, fail if the Windows build fails. E.g. does it help to make the build be 100% sequential? Or is th

RE: Free dictionary variables in elaborated core expressions

In your code (elabRnExpr) you have _ <- perhaps_disable_default_warnings $ simplifyInteractive residual You’ll notice that simplifyInteractive :: WantedConstraints -> TcM (Bag EvBind) So you are discarding the “evidence bindings” returned by simplifyInteractive. Those are precisely the bindi

RE: Simplifying subsumption

Jurriaan, It would be good to dig out the patches that affect packages without which GHC cannot build. (E.g. haskeline.) Would that take long? You have them already... It doesn't have to be perfect or git-tracked; just send a patch file in an email. I'm just trying to avoid re-inventing th

Simplifying subsumption

Jurriaan, Ben I have a MR up for #17775, which implements the now-accepted GHC proposal to simplify subsumption. https://gitlab.haskell.org/ghc/ghc/merge_requests/2600 However, it requires some eta expansions in haskeline, and maybe other packages. I don't know how to do that. Could you, or ano

RE: Feasibility of native RTS support for continuations?

| Now that is very interesting, and certainly not something I would have | expected! Why would asynchronous exceptions need to capture any portion of | the stack? Exceptions obviously trigger stack unwinding, so I assumed the | “abort to the current prompt” part of my implementation would alrea

RE: stage2 build fails

| Out of curiosity, is there a reason you are not using Hadrian in this | tree? Yes... I tried again three weeks ago and ran into several obstacles that I asked about on ghc-devs at the time. I'd be happy to re-state them when it's a good time to do so. I think this thread is the most recent

RE: stage2 build fails

tefan | | On Tue, Jan 28, 2020 at 10:41:33AM +, Simon Peyton Jones via ghc-devs | wrote: | > I did "sh validate --legacy" which uses "make maintainer-clean". | > | > I'll try again to double check. Is there any particular file I should | remove? | >

RE: stage2 build fails

ly for me (beware that this removes any untracked | file). Maybe this helps? | | Cheers, | Stefan | | On Tue, Jan 28, 2020 at 10:41:33AM +0000, Simon Peyton Jones via ghc-devs | wrote: | > I did "sh validate --legacy" which uses "make maintainer-clean". | > | &g

RE: stage2 build fails

I did "sh validate --legacy" which uses "make maintainer-clean". I'll try again to double check. Is there any particular file I should remove? Simon | -Original Message- | From: Ben Gamari | Sent: 27 January 2020 18:59 | To: Simon Peyton Jones ; ghc-devs | Subject: RE: stage2 bui

RE: Feasibility of native RTS support for continuations?

Alexis I've thought about this quite a bit in the past, but got stalled for lack of cycles to think about it more. But there's a paper or two: https://www.microsoft.com/en-us/research/publication/composable-scheduler-activations-haskell/ On that link you can also see a link to an earlier, shor

RE: stage2 build fails

To: Simon Peyton Jones ; ghc-devs | Subject: Re: stage2 build fails | | Simon Peyton Jones via ghc-devs writes: | | > I'm getting this with "sh validate -legacy" | > | > compiler/main/DynFlags.hs:1344:15: error: [-Woverlapping-patterns, - | Werror=overlappin

RE: stage2 build fails

It would be good to know how to fix this. It's blocking my builds. For some reason it doesn't seem to kill CI Simon From: Simon Peyton Jones Sent: 25 January 2020 20:26 To: ghc-devs Subject: stage2 build fails I'm getting this with "sh validate -legacy" compiler/main/DynFlags.hs:1344:15: erro

stage2 build fails

I'm getting this with "sh validate -legacy" compiler/main/DynFlags.hs:1344:15: error: [-Woverlapping-patterns, -Werror=overlapping-patterns] Pattern match is redundant In an equation for 'settings': settings s | otherwise = ... | 1344 | | otherwise = panic $ "Invalid

RE: GHC perf

We store the metrics in git notes *per-commit*. All metrics for commit XX are stored on the git note for commit XX. You can even view the raw data with this command (where XX is the commit hash): OK. But the master repo *already* has perf notes for that commit (I assume). Do mine somehow over

RE: GHC perf

Thanks This information is a bit spread out over the wiki page. Which wiki page? Yes, it'd be fantastic to write this out clearly. Thanks! $ git checkout a12b34c56 && git submodule update --init $ ./hadrian/build.sh test --only-perf $ git checkout x98y76z54 && git submodule update --init

<    1   2   3   4   5   6   7   8   9   10   >