- ghc-devs - Haskell.org

Hadrian update
by Andrey Mokhov 06 Feb '17

06 Feb '17

Hello everyone, This is a quick update on the current state of Hadrian, the new build system for GHC (https://github.com/snowleopard/hadrian) Current status ============ We've been slowly but steadily fixing issues, and are getting close to the stage where GHC-devs can start using Hadrian in their everyday development, perhaps at first alongside Make as a fallback option. Here are key remaining issues and what we plan to do about them: * Build rules for distribution and installation are not fully implemented. I don't understand very well the requirements for these build rules and plan to spend some time with Simon Marlow to complete the implementation in March. If anyone can do this earlier, feel free to volunteer, I'm happy to help. * Ability to build stage1 GHC only. This is a quick fix on Hadrian's side but is currently blocked by Shake refactoring. Neil Mitchell is working on this. * Hadrian can't build GHC in the dynamic way. Jose Calderon has bravely taken up the challenge to fix this oldest surviving ticket (#4). There are a lot of other minor issues and continuous refactoring, but I think the above three are most important. If I missed anything, please let me know. How to help ========== 1) One of the simplest way to help the project is to try Hadrian and report any issues you encounter. To try it, clone it into your GHC tree and run it using "hadrian/build.sh" or "hadrian/build.bat", adding "-j --flavour=quickest" to speed things up. See the README for more details: https://github.com/snowleopard/hadrian 2) Whenever you are doing any changes in the GHC that affect the build system, please CC me (@snowleopard) to the corresponding Phab differential. This can save me a lot of time when Hadrian breaks because of changes in GHC. 3) Email me if you have time to write some code or docs for Hadrian - I'll find a good place to start with. Cheers, Andrey

1 0

Phabricator upgrade tomorrow
by Ben Gamari 05 Feb '17

05 Feb '17

Hello everyone! Currently our Phabricator installation is quite old, based on a commit from last July. Given that I have a bit of breathing room now between 8.0.2 and 8.2.1, I'd like to take this opportunity to do an upgrade tomorrow if no one objects. Given that this is the first time I have attempted an upgrade, I expect this may take a few hours in the middle of the day EST. I would expect that the GHC Phabricator instance would be down for much of this time. Let me know if this will cause you undue burden. Cheers, - Ben

2 2

Is there a way to avoid time limit when using travis?
by Takenobu Tani 04 Feb '17

04 Feb '17

Dear devs, Is there a way to avoid time limit when using travis? I started using travis [1]. It is very convenient :) But timeout occurs [2]. The log messages are as follows: =====> InstEqContext2(normal) 1806 of 5700 [0, 0, 0] =====> InstEqContext3(normal) 1807 of 5700 [0, 0, 0] =====> InstContextNorm(normal) 1808 of 5700 [0, 0, 0] The job exceeded the maximum time limit for jobs, and has been terminated. How do you avoid this? Paid plan or something? [1]: https://ghc.haskell.org/trac/ghc/wiki/Travis [2]: https://travis-ci.org/takenobu-hs/ghc/builds/197987055 Regards, Takenobu

3 4

RE: Panic from rewritableTyVarsOfType
by Ben Gamari 03 Feb '17

03 Feb '17

Simon Peyton Jones <simonpj(a)microsoft.com> writes: > Ben, Richard > > rewritableTyVarsOfType is used when deciding whether to split a [WD] > constraint into [W] and [D]. For example, if we are adding > [WD] C a > and there is an inert > [WD] a ~ Int > then we want to split the [WD] into > [W] C a > [D] C a > so that the [D] one can be rewritten and perhaps yield improvement etc. > > There is no point in rewriting coercions or cases in t, because they > won't help (C t) to reduce. That's why rewriteableTyVarsOfType differs > from tyVarsOfType. And indeed the arg of a class C should be a > monotype. > Ahh, I see. > So rewriteableTyVarsOfType doesn't expect foralls, hence the panic. > But it's seeing a forall in an /equality/ constraint. > > FIRST ISSUE: I'm a bit surprised about that (smacks of impredicative > polymorphism) so the first thing to check is that this is really > supposed to happen in this program. Richard should be able to help. > Indeed this test is meant to fail, just not with a panic. I suspect this means that my solver logic isn't catching requests for polytypes as early as it needs to. > SECOND ISSUE: But regardless, I now realise that shouldSplitWD only > needs to split a [WD] equality if the LHS matches. If we have > [WD] a ~ ty -- work item > [D] a ~ ty2 -- inert > then we want to split the [WD] so we can get [D] ty ~ ty2. But > otherwise there is no point. > > Richard do you agree? > > I'll try that out. > > Meanwhile to get you rolling, you can replace rewritableTyVars with > tyCoVarsOfType and it'll all work, just a bit less efficiently. > Thanks Simon! Indeed that allows things to proceed and in the process, confirms that there is a bug in my solver logic. Cheers, - Ben

2 2

Disable messages with GHC API
by Christopher Done 03 Feb '17

03 Feb '17

In Intero, after loading modules, for each one I run the following function: https://github.com/commercialhaskell/intero/blob/300ac5a/src/GhciInfo.hs#L7… If there are warnings or any output, they get outputted. As they are already outputted by regular :load, I don’t need the same output twice. How do I disable non-severe output for any GhcMonad m => m a? I’m using GHC 8.0.1 presently. I tried the following before calling getModInfo, expecting there to be no output anymore: + GHC.setSessionDynFlags + df {log_action = \ref dflags severity srcSpan style msg -> return ()} And this had no effect. I tried some other things but ran out of patience to keep a record of them all. Ciao!

4 5

Talkative Join points warning
by Ben Gamari 03 Feb '17

03 Feb '17

Hi Luke, I've noticed that a new WARN in OccurAnal seems to be quite loud. Validations now produce thousands of lines of the form, WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 OccurAnal failed to rediscover join point(s): [$j_shTG] WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 OccurAnal failed to rediscover join point(s): [$w$j_sl22] WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 OccurAnal failed to rediscover join point(s): [$w$j_sl1W] WARNING: file compiler/simplCore/OccurAnal.hs, line 2633 OccurAnal failed to rediscover join point(s): [$w$j_sl1Q] Do you think we could either quiet the warning down a bit or perhaps disable it by default? It makes it rather difficult to see through the noise. This is actually perhaps another case where Simon Marlow suggestion of introducing a family of -v* flags (e.g. -fvanishing-join-points) might be helpful. Cheers, - Ben

4 3

eagerlyBlackhole# efficiency thought
by David Feuer 02 Feb '17

02 Feb '17

We discussed trying to come up with a primitive eagerlyBlackhole# :: a -> a -- meaning eagerlyBlackhole a = runRW# $ \s -> case noDuplicate# s of _ -> a that would guarantee that the thunk is entered by only one thread. There are important situations where that check is redundant. Consider this code: (m >>= \a -> strictToLazyST (f a)) >>= o The implementation of >>= needs to wrap up the execution of its first argument in eagerlyBlackhole#. In this case, however, there is no risk that two threads will execute m, because it's forced within the same outer eagerlyBlackhole in which it was created. Is there a cheap way to detect this situation at run-time, when executing m, to avoid the synchronization delay? This probably doesn't arise too much for unsafePerformIO, but in lazy ST there may be a lot of nested no-duplicate thunks. I looked into trying to fix things up with RULES for *> and such, but I ran into trouble with eta expansion and in any case there are limits to what they can do to help >>=, and the whole thing is rather complicated.

1 0

Master broken?
by Simon Peyton Jones 02 Feb '17

02 Feb '17

My clean build of origin/master, on 64-bit Linux is showing these failures Unexpected failures: /tmp/ghctest-5_qx1p/test spaces/./pmcheck/should_compile/T11195.run T11195 [exit code non-0] (normal) Unexpected stat failures: /tmp/ghctest-5_qx1p/test spaces/./perf/compiler/T5837.run T5837 [stat too good] (normal) /tmp/ghctest-5_qx1p/test spaces/./perf/compiler/T12234.run T12234 [stat too good] (optasm) (I do wish the summary omitted those long paths; makes it hard to read.) I'm happy about the perf improvements, but why don't they happen for other people? T11195 is a very long-running pattern-match perf test that regularly fails on a heavily loaded machine, with a timeout. It's very tiresome, but I don't think it's a regression. Simon

2 1

RE: D2038: [WIP] TysPrim: Generalize kind of (->)
by Simon Peyton Jones 01 Feb '17

01 Feb '17

Replying by email because I'm on a train. Simon Huh. Put otherwise, your point is this. Suppose we have the following kind for `(->)`: (->) :: forall v1 v2 r1 r2. TYPE v1 r1 -> TYPE v2 r2 -> Type To coerce from (C a -> Int) to (a -> Int) we'd have to cough up a coercion `g`: g : (->) Vanilla Vanilla Ptr Ptr (C a) Int ~R (->) Constraint Vanilla Ptr Ptr a Int And now (Nth 1 g :: Vanilla ~R Constraint). Nothing about `KindCo` there; it's just that `(->)` takes some kind arguments. But that can only happen if `(->)` has suitable roles. What if it doesn't? What if we just had an axiom axArrow v :: (->) Vanilla v ~R (->) Constraint v or something like that. Then we get [W] g : (->) Vanilla Vanilla Ptr Ptr (C a) Int ~R (->) Constraint Vanilla Ptr Ptr a Int We decompose partly and solve thus g = (axArrow Vanilla) <Ptr> <Ptr> axC <Int> Simon From: noreply(a)phabricator.haskell.org [mailto:noreply@phabricator.haskell.org] Sent: 31 January 2017 12:51 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: [Differential] [Commented On] D2038: [WIP] TysPrim: Generalize kind of (->) goldfire added a comment. View Revision<https://phabricator.haskell.org/D2038> In D2038#89360<https://phabricator.haskell.org/D2038#89360>, @simonpj<https://phabricator.haskell.org/p/simonpj/> wrote: To avoid being able to extract ContraintRep ~R LiftedPtrRep we decided to weaken one of the coercion constructors, the one that gets a kind coercion from a type coercion. We don't need it, and it's awkward here. The problem is that we need it with this patch. I was able to weaken this coercion constructor (KindCo) in my patch D3023<https://phabricator.haskell.org/D3023>, but this patch uses it in a fundamental way that we can't get around. To wit: class C a where meth :: a axC :: (C a :: Constraint) ~R (a :: Type) Now, we wish to cast C a -> a to a -> a.. This cast will look like (->) ?? <LiftedRep> axC <a>. What goes in the ??? It's got to be something involving KindCo axC, which is disallowed as per our earlier decision. Therein lies the problem. As for reify: Yes, I'm agreed with that email. But is that implemented yet? Is a design settled on? I don't see a ghc-proposal. Are we wiling to take a dependency on that work in order to get this done? To be clear, my chief worry isn't that these problems cannot be solved by any means -- I'm just worried about the timing of this all and our desire to get 8.2 out the door. REPOSITORY rGHC Glasgow Haskell Compiler REVISION DETAIL https://phabricator.haskell.org/D2038 EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: bgamari, goldfire, austin Cc: simonpj, RyanGlScott, thomie

3 8

More history in perf.haskell.org graphs
by Reid Barton 01 Feb '17

01 Feb '17

Hi Joachim, The graphs like https://perf.haskell.org/ghc/#graph/buildtime/make are very helpful, but I haven't found a way to adjust the range of commits shown from the default of the last 50 commits. For example, suppose I wanted to see the history of build time over the past 12 months and then narrow in on commits that caused regressions. Is there a way to do that using the https://perf.haskell.org/ghc/ website? Failing that, is the data that goes into these graphs available for download in some form? Regards, Reid Barton

3 2