March 2020 - ghc-devs

Getting the inferred types of TH's UnboundVarEs
by Sandy Maguire 20 Mar '20

20 Mar '20

Hi all, I'm writing some TH code that should generate property tests. For example, the expression: $(generate [e| law "idempotent" (insert a (insert a b) == insert a b) |]) should generate the code property $ \a b -> insert a (insert a b) === insert a b I do this by looking for UnboundVarEs in the Exp returned by the [e| quote, and binding them in a lambda. All of this works. However, now I'm trying to get the inferred types of `a` and `b` in the above. GHC clearly is typechecking the quote, since it will fail if I replace `b` with something nonsensical. *Is there some existent way to get the inferred type of an UnboundVarE --- ideally without reimplementing the typechecker?* Thanks! Sandy

3 5

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

20 Mar '20

Awesome! After talking with several folks, feedback has been that best practices are to make sure the notice is a week before hand. So what I’ll do is personally reach out to those who aren’t 2fa enabled in the Haskell gh org (and haven’t commented on this thread )and ask them to enable 2fa on their GitHub account. Perhaps I should attach a 2fa options explainer ! I’ll look at folks responses and if everyone active has made the switch over, I’ll look to do a transition next Monday or Tuesday. Be well! (Nyc and many other places are pretty strange right now :/ ) -Carter On Wed, Mar 18, 2020 at 7:42 PM Duncan Coutts <duncan(a)dcoutts.me.uk> wrote: > On Wed, 2020-03-18 at 19:05 -0400, Carter Schonwald wrote: > > No. You don’t. You can use a yubi key and or a totp tool like google > > Authenticator or 1Password etc. no phones required > > It took me a while, but I have successfully managed to turn 2FA back > into 1FA. > > In case it helps anyone else, generate your 2FA response with > > $ oathtool --totp -b $the-2fa-secret > > Where $the-2fa-secret is the code github gives you after the recovery > codes (initially shown as a barcode, but they'll give you the actual > code if you click the link). > > > On Wed, Mar 18, 2020 at 6:16 PM Duncan Coutts <duncan(a)dcoutts.me.uk> > wrote: > > > On Wed, 2020-03-18 at 14:46 -0400, Carter Schonwald wrote: > > > > 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! > > > > > > I think I might get cut off. > > > > > > Is it not still the case that github's 2fa needs a program running on a > > > mobile phone, or an SMS-capable mobile phone? Is there any support for > > > normal tools running on a normal Linux machine? > > > > >

3 3

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

19 Mar '20

No. You don’t. You can use a yubi key and or a totp tool like google Authenticator or 1Password etc. no phones required On Wed, Mar 18, 2020 at 6:16 PM Duncan Coutts <duncan(a)dcoutts.me.uk> wrote: > On Wed, 2020-03-18 at 14:46 -0400, Carter Schonwald wrote: > > 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! > > I think I might get cut off. > > Is it not still the case that github's 2fa needs a program running on a > mobile phone, or an SMS-capable mobile phone? Is there any support for > normal tools running on a normal Linux machine? > > (I think last time I tried to use the SMS route, it refused to send SMS > messages to my landline, despite the fact that I can receive them) > > > Duncan > >

1 0

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

19 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 17 Mar '20

17 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 11 Mar '20

11 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 10 Mar '20

10 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