- ghc-devs - Haskell.org

D2903 Needs Review
by Thomas Jakway 07 Feb '17

07 Feb '17

If anyone has a free moment I'd appreciate feedback on D2903: https://phabricator.haskell.org/D2903 -Thomas

2 1

Handling of unlifted types
by Erik de Castro Lopo 07 Feb '17

07 Feb '17

Hi all, I'm working on pulling the core parts of Joachim Breitner's ghc-heap-view library into GHC. The WIP Phab review is here: https://phabricator.haskell.org/D3055 Currently that library has a function: getClosureData :: a -> IO Closure which works fine for lifted types. However, some of the supported closure types in http://hackage.haskell.org/trac/ghc/browser/includes/rts/storage/InfoTables… actually refer to unlifted types, like the `MUT_ARR_PTRS_*` and `SMALL_MUT_ARR_PTRS_*`. I've had a look at the levity polymorphism stuff implemented in ghc 8.0 and came up with a new type for `getClosureData`: getClosureData :: forall (r :: RuntimeRep) (a :: TYPE r). a -> IO Closure but that results in: A representation-polymorphic type is not allowed here: Type: a Kind: TYPE r In the type of binder ‘x’ Am I barking up the wrong tree here? Any one have a clue on how I might make progress on this? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

3 2

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