- ghc-devs - Haskell.org

Name of units in plugins
by Spiwack, Arnaud 18 Feb '19

18 Feb '19

Dear all, (first, I don't know if this is the best place for questions/discussions about the GHC API, if not, let me know where to redirect the conversation). I've been writing a plugin that substitutes call to a function by calls to another (it's a plugin reimplementation of the assert feature of GHC). And to be able to point at the names of these two functions, I need to construct a name (well, and OccName) made of three parts: unit id, module name, definition name. This question is about the unit name. Currently I simply use stringToUnitId. But the real name of my unit has a magic string in it (see https://github.com/aspiwack/assert-plugin/blob/a538d72581bae43ebf44c332e19c… ). It's rather unpleasant, it seems to change every time the cabal file change (at least). The assert-explainer plugin uses another approach, only using the module name, then calling findImportedModule ( https://github.com/ocharles/assert-explainer/blob/dc6ea213d4d0576954ec883ee… ). This is much more robust to changes, but is also less precise (technically, there can be several imported modules with the same name, with package-qualified imports). So, the question is: is there a better, recommended way to recover the OccName (or Name!) of a function I defined in the same unit my plugin is defined in. Best, Arnaud

2 6

RE: Distributed local dev builds
by Andrey Mokhov 17 Feb '19

17 Feb '19

Hi Julian, Have a look at this MR: https://gitlab.haskell.org/ghc/ghc/merge_requests/317 As soon as it lands, you'll be able to run Hadrian builds with a local cache as follows: hadrian/build --shared=path/to/cache In this mode, build rules are cached, and if you happen to rerun a build rule with unchanged dependencies the resulting files will be copied from the cache instead of executing actual build commands. This should significantly speed up switching between branches. Note however that this does not give you a way to run distributed builds: at the moment it is not possible to offload any build rules to other machines. Cheers, Andrey ---------------------------------------------------------------------- Message: 1 Date: Sun, 17 Feb 2019 13:36:40 +1100 From: Julian Leviston <julian(a)leviston.net> To: GHC developers <ghc-devs(a)haskell.org> Subject: Distributed local dev builds Message-ID: <86D5D29A-8839-4D0F-907F-029B626B5E3A(a)leviston.net> Content-Type: text/plain; charset=utf-8 Hi all, I have several fairly high-spec machines on my network where I usually build GHC, and I was wondering if it was easy/trivial/possible to set up a distributed build where it farmed out some of the compute work to the other machines? I seem to need to build from scratch somewhat often when I switch branches I'm working on. Is this going to be the aim of distributed shake, which hadrian is based on? Thanks! Julian

1 0

GitLab forks and submodules
by Moritz Angermann 17 Feb '19

17 Feb '19

Hi *, so what do we do with submodules? If you point someone to a fork of ghc, say: gitlab.haskell.org/foo/ghc and they try to check it out, they will run into issues because foo didn't clone all the submodules. So how is one supposed to clone a forked ghc repository? Cheers, Moritz

8 15

Distributed local dev builds
by Julian Leviston 17 Feb '19

17 Feb '19

Hi all, I have several fairly high-spec machines on my network where I usually build GHC, and I was wondering if it was easy/trivial/possible to set up a distributed build where it farmed out some of the compute work to the other machines? I seem to need to build from scratch somewhat often when I switch branches I’m working on. Is this going to be the aim of distributed shake, which hadrian is based on? Thanks! Julian

1 0

Re: scopedSort and kind variable left-biasing
by Ryan Scott 15 Feb '19

15 Feb '19

As Vlad notes in [1], getting rid of FreeKiTyVars isn't as simple as it would appear, as we still treat kinds and types differently in other places, such as data type declarations. For instance: data Proxy (a :: k) = Proxy -- k is brought into scope implicitly by `extractDataDefnKindVars` I don't know how to overcome this awkwardness, so if you have suggestions, please comment at [1]. Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/merge_requests/361#note_6709

1 0

Is this the correct way to get Stg for a module?
by Christopher Done 15 Feb '19

15 Feb '19

Hi all, I'm attempting to get the Stg for a module with the intention of interpreting it myself. Here is a self-contained GHC-8.4.3-specific test-case to get STG: https://gist.github.com/chrisdone/08ef9e8447b71c9dadc5bba949cda638#file-pri… I'm using the handy helpers GHC.parseModule, GHC.typecheckModule, GHC.desugarModule to get the Core. For getting the STG I copied what is done in HscMain.hs in GHC, right before it generates Cmm: https://github.com/ghc/ghc/blob/ghc-8.4/compiler/main/HscMain.hs#L1312-L1318 Can anyone confirm that the part I've highlighted in my Gist is the correct way to get Stg? I can't really tell whether I missed anything or did something wrong. Cheers!

1 0

typecheck/should_fail/all.T
by Simon Peyton Jones 15 Feb '19

15 Feb '19

There's a mysterious line 4607 at the top of testsuite/tests/typecheck/should_fail/all.T Should it be there? What does it do? Could it be bad? Simon

2 2

scopedSort and kind variable left-biasing
by Ryan Scott 14 Feb '19

14 Feb '19

Consider this function: f :: Proxy (a :: j) -> Proxy (b :: k) If you just collect the free type variables of `f`'s type in left-to-right order, you'd be left with [a,j,b,k]. But the type of `f` is not `forall (a :: j) j (b :: k) k. Proxy a -> Proxy b`, as that would be ill scoped. `j` must come before `a`, since `j` appears in `a`'s kind, and similarly, `k` must come before `b`. Fortunately, GHC is quite smart about sorting free variables such that they respect dependency order. If you ask GHCi what the type of `f` is (with -fprint-explicit-foralls enabled), it will tell you this: λ> :type +v f f :: forall j k (a :: j) (b :: k). Proxy a -> Proxy b As expected, `j` appears before `a`, and `k` appears before `b`. In a different context, I've been trying to implement a type variable sorting algorithm similar to the one that GHC is using. My previous understanding was that the entirely of this sorting algorithm was implemented in `Type.scopedSort`. To test my understanding, I decided to write a program using the GHC API which directly uses `scopedSort` on the example above: main :: IO () main = do let tv :: String -> Int -> Type -> TyVar tv n uniq ty = mkTyVar (mkSystemName (mkUniqueGrimily uniq) (mkTyVarOcc n)) ty j = tv "j" 0 liftedTypeKind a = tv "a" 1 (TyVarTy j) k = tv "k" 2 liftedTypeKind b = tv "b" 3 (TyVarTy k) sorted = scopedSort [a, j, b, k] putStrLn $ showSDocUnsafe $ ppr sorted To my surprise, however, running this program does /not/ give the answer [j,k,a,b], like what :type reported: λ> main [j_0, a_1, k_2, b_3] Instead, it gives the answer [j,a,k,b]! Strictly speaking, this answer meets the specification of ScopedSort, since it respects dependency order and preserves the left-to-right ordering of variables that don't depend on each other (i.e., `j` appears to the left of `k`, and `a` appears to the left of `b`). But it's noticeably different that what :type reports. The order that :type reports, [j,k,a,b], appears to bias kind variables to the left such that all kind variables (`j` and `k`) appear before any type variables (`a` and `b`). >From what I can tell, scopedSort isn't the full story here. That is, something else appears to be left-biasing the kind variables. My question is: which part of GHC is doing this left-biasing? Ryan S.

3 8

Re: Performance of pattern synonyms
by Carter Schonwald 14 Feb '19

14 Feb '19

Hey Matthew, One dimension of analsysis that would be instructive would be to characterize the differences in core / stg for these different versions Also : am I correct in believing that these all are the exact same algorithm in terms of representation or am I overlooking some differences between the 3 different codes ? On Mon, Feb 11, 2019 at 4:07 PM Matthew Roberts <matthew.roberts(a)mq.edu.au> wrote: > My apologies, > > The link to the source was broken by some repo work - I have fixed it and > it should be stable now. This page was intended just to be a way of > showing the results to my collaborators, not a full explanation that anyone > can follow, but I thought the graphs at least show off what I am seeing. > > Regardless, it is all there in the code and hopefully not too obtuse. I > can improve the discussion on the page if enough people are interested :) > > Matt > > On 12 Feb 2019, at 5:14 AM, Carter Schonwald <carter.schonwald(a)gmail.com> > wrote: > > I'm looking at these links, but i'm actually having a hard time finding > the actual different definitions of this microbenchmark... > > On Mon, Feb 11, 2019 at 9:22 AM Richard Eisenberg <rae(a)cs.brynmawr.edu> > wrote: > >> >> >> On Feb 11, 2019, at 8:55 AM, Simon Peyton Jones <simonpj(a)microsoft.com> >> wrote: >> >> What exactly is “the alternative compile-time implementation”? >> >> >> In my response, I interpreted this to be macro-expansion, the alternative >> we discuss in the paper. The paper includes a nice discussion of how the >> semantics differs between what we currently have and macro-expansion. >> >> Richard >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> <https://protect-au.mimecast.com/s/DjjUCK1DOrC8NwxohMgjBd?domain=mail.haskel…> >> > >

1 0

Marge has been stabilised
by Matthew Pickering 13 Feb '19

13 Feb '19

Hi all, I think I have finally managed to stablise the merge bot (Marge). If you have a patch ready to merge then 1. Make sure that CI shows as passing 2. Make sure it has been approved by at least one person 3. Make sure it is not marked as WIP Once these three conditions are met, assign the PR to "Marge Bot" and then she will pick it up and merge it, hopefully within 24 hours depending on her current state. Any more questions, feel free to ask. I included some more specific detail below. Cheers, Matt ------ Here is her current mode of operation. Every 30 minutes whilst idle she will try to find new MRs to batch together. If she finds at least two MRs to batch together then she creates a batch as a new merge request. A batch is the series of MRs rebased on top of each other from oldest to newest. She then waits for this merge request to pass CI, checking every 10 minutes to see if it has done so. Once the MR has passed CI, she rebases and merges each MR in the batch one by one to the target branch. In between each MR she merges she waits 5 minutes. Due to the fact each MR is merged one by one: 1. The original MR will be closed automatically. 2. A CI job will trigger for each MR as it lands on master.

4 10