- ghc-devs - Haskell.org

How to navigate around the source tree?
by Matthew Pickering 25 Oct '19

25 Oct '19

Hi, The module rework has broken my workflow. Now my tags file is useless for jumping for modules as there are multiple "Utils" and "Types" modules. Invariable I am jumping to the wrong one. What do other people do to avoid this? Can we either revert these changes or give these modules unique names to facilitate that only reliable way of navigating the code base. Perhaps `HsUtils` and `StgUtils` would be appropriate to disambiguate `Hs/Utils` and `StgToCmm/Utils`. Cheers, Matt

8 12

Urgent: git problem
by Simon Peyton Jones 23 Oct '19

23 Oct '19

Aieee! All my GHC repos are failing with this. As a result I can't pull. What should I do? Thanks! Simon git pull error: cannot lock ref 'refs/remotes/origin/wip/rae/remove-tc-dep': 'refs/remotes/origin/wip/rae' exists; cannot create 'refs/remotes/origin/wip/rae/remove-tc-dep' >From gitlab.haskell.org:ghc/ghc ! [new branch] wip/rae/remove-tc-dep -> origin/wip/rae/remove-tc-dep (unable to update local ref) error: cannot lock ref 'refs/remotes/origin/wip/rae/split-up-modules': 'refs/remotes/origin/wip/rae' exists; cannot create 'refs/remotes/origin/wip/rae/split-up-modules' ! [new branch] wip/rae/split-up-modules -> origin/wip/rae/split-up-modules (unable to update local ref) simonpj@MSRC-3645512:~/code/HEAD-2$

6 9

Why is libraries/ghci built with stage 0 compiler instead of stage 1?
by Ömer Sinan Ağacan 18 Oct '19

18 Oct '19

Stage 1 compiler doesn't have interpreter, and doesn't run plugins or TH, so I think GHCi stuff should not be used by stage 1 compiler, but for some reason the "ghci" library (libraries/ghci) is built with stage 0 compiler instead of stage 1. Anyone know what this is? Thanks, Ömer

2 1

atomicModifyMutVar2
by Simon Peyton Jones 17 Oct '19

17 Oct '19

David I'm deeply puzzled atomicModifyMutVar2#. I have read the proposal<https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0149-a…>, and the comments in primops.txt.pp (reproduced below). Question 1 I think the "real" type of atomicModifyMutVar2 is atomicModifyMutVar2# :: MutVar# s a -> (a -> (a,b)) -> State# s -> (# State# s, a, (a, b) #) Nowhere is this explicitly stated, but I believe that the intended semantics of a call case (atomicModifyMutVar2# mv f s) of (# s', x, r #) -> blah Then, suppose the old value of the MutVar was 'old' * The primop builds a thunk t = f old * The new value of the mutable variable is (fst t) * The result r is t * The result x is old Question: is that correct? We should state it explicitly. Question 2 Next question: Why does f have to return a pair? So far as I can tell, it's only so that a client can force it. The 'b' part never seems to play a useful role. So we could equally well have had atomicModifyMutVar2# :: MutVar# s a -> (a -> Box a) -> State# s -> (# State# s, a, Unit a #) where Unit is defined in Data.Tuple data Unit a = Unit a Now you can force the result of (f old), just as with a pair. But the 'b' would no longer complicate matters. Question: is the 'b' in the pair significant? Or could we use Unit? Question 3 In the comments below you say "but we don't know about pairs here". Are you sure? What stops you importing Data.Tuple into GHC.Prim? This fancy footwork is one more complication, if it could be avoided. Thanks Simon primop AtomicModifyMutVar2Op "atomicModifyMutVar2#" GenPrimOp MutVar# s a -> (a -> c) -> State# s -> (# State# s, a, c #) { Modify the contents of a {\tt MutVar\#}, returning the previous contents and the result of applying the given function to the previous contents. Note that this isn't strictly speaking the correct type for this function; it should really be {\tt MutVar\# s a -> (a -> (a,b)) -> State\# s -> (\# State\# s, a, (a, b) \#)}, but we don't know about pairs here. } with out_of_line = True has_side_effects = True can_fail = True

3 12

Re: [Reminder] Merge window for 8.10 closing
by Ryan Scott 16 Oct '19

16 Oct '19

I've been working on a fix for #13154 [1] that I'd like to get into GHC 8.10. My patch [2] is mostly done; I just need to find the time to add comments and perform some slight code cleanup. (Hopefully this week!) Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/issues/13154 [2] https://gitlab.haskell.org/RyanGlScott/ghc/tree/wip/T13154-take-two

1 0

[Reminder] Merge window for 8.10 closing
by Ben Gamari 16 Oct '19

16 Oct '19

Hello everyone, As described on the GHC status page [1] the freeze for GHC 8.10 is coming up shortly. If you have work that you would like to get into 8.10 and haven't yet opened an MR you should either do so today or be in touch with me. After this freeze begins there will be approximately a week of reduced merge rate to let the master branch settle before the branch, which could happen as early as early next week. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/milestones/54?title=8.10.1

2 1

Help with debugging a batch mode (or type checker) bug
by Ömer Sinan Ağacan 15 Oct '19

15 Oct '19

Hi, In !1304 I'm currently having a bug where I get correct IdInfos for imported Ids in one-shot mode (-c), but not when I use batch mode (--make). If I add a few prints I can see that in hscIncrementalCompile right before hscIncrementalFrontend the hsc_HPT has the correct IdInfos for the imported Ids, but somehow in the desugarer output the IdInfo is lost. Can anyone point me to the right places in the typechecker or the desugarer for me to look at? Thanks, Ömer

2 4

Switch/Case optimisations
by chessai . 14 Oct '19

14 Oct '19

I thought Andreas Klebinger in particular might find this interesting. The talk is here: https://youtu.be/IAdLwUXRUvg?t=1867 (timestamp is 31:07) basically, if you have an interpreter consisting of a switch statement inside an infinite loop, there's a mechanical transformation using GOTOs that causes a 15% speedup in the switch statement blob, there's n + 1 basic blocks, each of which has a jmp back to the first basic block with probability 1, and the first basic block has a jmp that will go to one of the other n basic blocks with probability 1 / n whereas in the goto statement setup, there's n basic blocks, each of which has a jmp that will go to one of the other n - 1 basic blocks with probability 1 / (n - 1) so if your sequence of instructions is produced by a markov decision process, then the branch predictor will efficiently predict in the latter situation but not necessarily the former in the goto setup the callgraph looks like a complete graph on n vertices whereas in the switch setup it looks like a bipartite graph on (1, n) vertices (where the edges represent both "is called by" and "calls") and because of all those extra edges (n^2 rather than 2n) there's more spots for the branch predictor to build up data At 39:13 he explains that you get per-address jmp predictions. If you only share a single relative jmp, the cpu only knows how common every opcode is. But, if you have a jmp from each opcode, to the next, the cpu can determine how common an opcode A is followed an opcode B. He references godbolt (https://godbolt.org/) which seems like a useful tool. and mentions that ruby, jvm (on android only?), and some arm compilers implement this. There are some tradeoffs - code size does increase. According to a GCC developer in the audience, GCC is not currently able to do this. I have no idea about Clang. Thanks

1 0

validate-x86_64-darwin failing
by Richard Eisenberg 14 Oct '19

14 Oct '19

Hi devs, validate-x86_64-darwin seems to be failing. I've restarted it when I came across the failure, but several small patches last night tripped on this. Richard

4 6

CI fails in git submodule update --init --recursive for 386-linux-deb9
by Roland Senn 13 Oct '19

13 Oct '19

Hi After pushing some commits, while running a CI pipeline, I persistently get the following error for the validate-i386-linux-deb9 step: $ git submodule update --init --recursive fatal: Unable to create '/builds/RolandSenn/ghc/.git/modules/libraries/Cabal/index.lock': File exists. Another git process seems to be running in this repository, e.g. an editor opened by 'git commit'. Please make sure all processes are terminated then try again. If it still fails, a git process may have crashed in this repository earlier: remove the file manually to continue. Unable to checkout '63331c95ed15cc7e3d83850d308dc3a86a8c3c76' in submodule path 'libraries/Cabal' See https://gitlab.haskell.org/RolandSenn/ghc/pipelines/11311 . How can I fix this? I have no access to this 386 linux machine, so I'm unable to delete the file. Roland

1 0