- ghc-devs - Haskell.org

intent to enable 2fa requirement for github.com/haskell org
by Carter Schonwald 18 Mar '20

18 Mar '20

hey everyone, because so much important stuff for the community, it makes sense to add 2fa required for the org, are there any good reasons to either wait to do this, or not do it? Feedback welcome! (if theres no objections i'll do it friday or this weekend, so theres some lead time for anyone who's not setup for that yet) Best wishes and great health to all -carter

5 6

Specializing functions with implicit parameters
by Alexis King 16 Mar '20

16 Mar '20

Hi all, I discovered today that GHC never specializes functions with implicit parameters. This is not that surprising—I wouldn’t expect GHC to specialize the implicit parameters themselves—but it’s unfortunate because it means a single implicit parameter somewhere can transitively destroy specialization that would otherwise be very helpful. Is there any obstacle to specializing these functions’ other dictionaries and leaving the implicit parameters alone? That is, if I have a function foo :: (?foo :: Bool, Show a) => a -> String could GHC specialize `foo @Int` to foo :: (?foo :: Bool) => Int -> String treating the implicit parameter little differently from an ordinary function argument? As far as I can tell, there isn’t any real obstacle to doing this, so unless I’m missing something, I might give it a try myself. I just wanted to make sure I wasn’t missing anything before diving in. Thanks, Alexis

4 4

Re: performance testing
by David Eichmann 11 Mar '20

11 Mar '20

-------- Forwarded Message -------- Subject: Re: performance testing Date: Wed, 11 Mar 2020 12:08:52 +0000 From: David Eichmann <davide(a)well-typed.com> To: Richard Eisenberg <rae(a)richarde.dev> > Ah yes -- very helpful. So the baseline is always (implicitly) the > parent commit, if that commit has performance info in the set of > notes. So if I have this situation (time flows down) > > origin/master: blah > wip/xyz: big cool change (that slows things down) > attempt1: comment out some of big cool change > attempt2: comment out more of big cool change With you so far. > and I do a perf test on attempt1, it's quite likely that the perf test > will*pass*, because it's comparing to the previous commit. Yes, assuming you actually ran performance tests on the previous commit with a clean working tree (remember we don't record performance metrics if the git tree has changes, though you'll see a warning in the test output in that case). I'd suggest outputting a graph as described in the wiki if you're wondering which commits have recorded performance metrics. > And then when I do a perf test on attempt2 and see a metric*decrease*, > that might just be because I've fixed the perf problem... but I > haven't actually made an improvement. Right. The decrease is compared to attempt1, but this may not be a decrease compared to earlier commits. Again I'd suggest graphing the data if you want to inspect this yourself. David E -- David Eichmann, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England

1 0

performance testing
by Richard Eisenberg 11 Mar '20

11 Mar '20

Hi all, I'm very confused by how to do performance testing. I have a patch that seems to cause a performance regression. So I built the patch locally (`validate` flavor, with `make`) and then reproduced the regression. Good. Then, I make a small change, rebuild, commit, and then test. But now it seems that the baseline has changed. (This took some time to discover after seemingly non-deterministic results!) So: how can I make several different commits, with different experiments, switch between them at will, all without changing my baseline? I do *not* have the magic "metric decrease" bit in my commit message. Or, at least, I didn't put it there. Thanks! Richard

2 2

GHC HEAD (Quickest) segfaults during compilation of optparse-applicative
by Csaba Hruska 10 Mar '20

10 Mar '20

Hello, GHC HEAD (9668781a36941e7552fcec38f6d4e1d5ec3ef6d1) compiled with the Quickest flavour segfaults when compiles optparse-applicative-0.15.1.0. But it compiles fine with the Quick or the default flavours. [image: image.png] Everything compiles fine (with vanilla Quickest GHC HEAD) until the Options.Applicative.Help.Core module where GHC segfaults. (as I understand the error code) Is this a known bug? If not then I'll submit an issue. Thanks, Csaba

2 3

Selector thunks again
by David Feuer 09 Mar '20

09 Mar '20

The fragility of this feature remains frustrating. A few days ago, I wrote this code for building a complete binary tree from its breadth-first traversal. (This is an improvement of a version by Will Ness.) data Tree a = Empty | Node a (Tree a) (Tree a) deriving Show -- An infinite list data IL a = a :< IL a infixr 5 :< bft :: [a] -> Tree a bft xs = tree where tree :< subtrees = go xs subtrees go :: [a] -> IL (Tree a) -> IL (Tree a) go (a : as) ~(b1 :< ~(b2 :< bs)) = Node a b1 b2 :< go as bs go [] _ = fix (Empty :<) When GHC compiles the lazy patterns, we get something essentially like this: go (a : as) ys = Node a (case ys of b1 :< _ -> b1) (case ys of _ :< b2 :< _ -> b2) :< go as (case ys of _ :< _ :< bs -> bs) Now `case ys of b1 :< _ -> b1` is a selector thunk, which is cool. The GC can reduce it as soon as either of the other thunks is forced. But neither of the other two case expressions is a selector thunk, so neither will ever be reduced by the GC. If I consume the result tree using an inorder traversal, for example, then all the elements in the left subtree of the root will remain live until I start to consume the right subtree of the root. I can instead write this: go (a : as) ys = Node a b1 b2 :< go as bs where {-# NOINLINE b2bs #-} b1 :< b2bs = ys b2 :< bs = b2bs Now all the suspended selections are selector thunks, so things should clean up nicely. There are still three problems, though. The first is that this is harder to read. The second is that now we have four suspended selections instead of three. Finally, if b1 is not the first one forced, we'll need to force two thunks instead of one. Can't we do any better?

2 1

Class op rules
by Christiaan Baaij 09 Mar '20

09 Mar '20

Hello, The other day I was experimenting with RULES and got this warning: src/Clash/Sized/Vector.hs:2159:11: warning: [-Winline-rule-shadowing] Rule "map Pack" may never fire because rule "Class op pack" for ‘pack’ might fire first Probable fix: add phase [n] or [~n] to the competing rule | 2159 | {-# RULES "map Pack" map pack = id #-} The warning seems to suggests two things: 1. "Class op" -> "dictionary projection" are implemented as rewrite rules and executed the same way as other user-defined RULES 2. These rules run first, and you cannot run anything before them Now my question is, is 1. actually true? or is that warning just a (white) lie? If 1. is actually true, would there be any objections to adding a "-1" phase: where RULES specified to start from phase "-1" onward fire before any of the Class op rules. I'm quite willing to implement the above if A) Class op rules are actually implemented as builtin RULES; B) there a no objections to this "-1" phase. Thanks, Christiaan

5 7

Typechecker plugin proposal, ticket #15147
by Nicolas Frisby 06 Mar '20

06 Mar '20

If you know of any typechecker plugin authors I've missed, please add them to the thread. In the comments of ticket https://gitlab.haskell.org/ghc/ghc/issues/15147 several of us agreed that the behavior of the typechecker plugin interface should change: GHC should no longer unflatten the fmvs in the Wanteds before passing them to the plugin. This is presumably a breaking change to plugins. We might be able to get by with some sort of flag indicating if the plugin expects the Wanteds flattened or not, but ideally GHC would just always pass them flattened. I'm unaware of any established policy about interface changes at this level, whether we've somehow committed to backwards-compatibility here or not. Anyone know? Plugin authors: would you look over the ticket comments and share your thoughts here? We're looking to build some sort of consensus about how to proceed without shocking the API users. Thank you for your time. -Nick

2 1

Number of threads in haskell program
by chessai . 04 Mar '20

04 Mar '20

Hi devs, Recently I became interested in obtaining the rough number of (non-GC) threads that are alive in a Haskell program. Intuitively this seemed like something that the RTS would expose in some way - but I couldn't find any such exposition in base. I then thought that I could simply total the size of each run_queue_hd in each capability, but the machinery for doing that doesn't seem to be exposed. Any thoughts? Thanks

2 1

Blocking MVar# primops not performing stack checks?
by Shao, Cheng 04 Mar '20

04 Mar '20

Hi all, When an MVar# primop blocks, it jumps to a function in HeapStackCheck.cmm which pushes a RET_SMALL stack frame before returning to the scheduler (e.g. the takeMVar# primop jumps to stg_block_takemvar for stack adjustment). But these functions directly bump Sp without checking for possible stack overflow, I wonder if it is a bug? Cheers, Cheng

3 2