February 2019 - ghc-devs

--share option for hadrian doesn't work with hs-boot files
by Matthew Pickering 22 Feb '19

22 Feb '19

I have been trying the new `--share` option implemented in hadrian but I haven't actually managed to complete any builds yet with it enabled after the initial one. The current error is ``` <no location info>: error: ‘Var.AnonArgFlag’ is exported by the hs-boot file, but not exported by the module Error when running Shake build system: at action, called at src/Rules.hs:35:19 in main:Rules at need, called at src/Rules.hs:52:5 in main:Rules * Depends on: _build/stage0/bin/ghc at need, called at src/Utilities.hs:71:18 in main:Utilities * Depends on: _build/stage0/compiler/build/libHSghc-8.9.a at need, called at src/Rules/Library.hs:118:5 in main:Rules.Library * Depends on: _build/stage0/compiler/build/Var.o * Raised the exception: user error (Development.Shake.cmd, system command failed ``` I get this after building Simon's `FunTy` patch which does add this flag and the definition to `Var.hs-boot` and then switching back to master with the cache enabled. Could you please write down some advice Andrey about how to solve issues like this? It seems very fragile making sure that every case is covered. Cheers, Matt

1 0

spj-wibbles
by Simon Peyton Jones 21 Feb '19

21 Feb '19

Matthew, Ben, David I've just submitted MR 426. It's a batch of four patches<https://gitlab.haskell.org/ghc/ghc/merge_requests/426/commits>, one of which makes the GHC tree validate again. Might you keep an eye on it. David/anyone: one of them "Stop inferring polymorphic kinds" makes a small change to HsSyn (removing a field). I don't know whether that'll require changing Haddock - or how to do so. Might you check? Gotta run Thanks! Simon

1 0

CI failing
by Simon Peyton Jones 21 Feb '19

21 Feb '19

Ben, Matthew I believe that 'master' fails validate. See Trac #16346. The question is: how did it get past CI? The bug would only show up if -dcore-lint was on for libraries. Simon

2 1

ZipN fusion
by Simon Peyton Jones 21 Feb '19

21 Feb '19

Dear devs Can someone help Alexandre by merging Phab:5249? See https://phabricator.haskell.org/D5249#151827 Many thanks Simon

2 1

Validate has died
by Simon Peyton Jones 19 Feb '19

19 Feb '19

>From master I'm getting 2052 "framework failures" in the testsuite, which all look like the one below. I also get 4468 expected passes, so not every test fails. This is with "sh validate". Yes I know I should get onto Hadrian, and I have a branch for that. But Hadrian isn't really working for me because it's putting build artefacts in my source tree rather than in my build tree (talking to Andrey about that). But I think that old 'validate' is still supposed to work, isn't it? I'm a bit stuck Thanks Simon Unexpected results from: TEST="AmapCoerce ArithInt16 ArithInt8 ArithWord16 ArithWord8 AtomicPrimops BinaryArray BinaryLiterals0 BinaryLiterals1 BinaryLiterals2 CPRRepeat CPUTime001 CallArity1 Capi_Ctype_001 Capi_Ctype_002 CarryOverflow CgStaticPointers CgStaticPointersNoFullLazyness Chan002 Chan003 CmmSwitchTest64 CmpInt16 CmpInt8 CmpWord16 CmpWord8 CopySmallArray Defer01 Defer02 DeriveNullTermination DocsInHiFile0 DocsInHiFile1 DsLambdaCase DsMultiWayIf DsStaticPointers DsStrict DsStrictData DsStrictFail DsStrictLet EvalTest EventlogOutput1 EventlogOutput2 FloatFnInverses Freeman GEq1 GEq2 GFullyStrict GFunctor1 GHCiWildcardKind GMap1 GMapAssoc GMapTop GShow1 GUniplate1 GcStaticPointers GenNewtype GhciCurDir GhciKinds HexFloatLiterals HooplPostorder IOError001 IOError002 IndT... etc... snip of a typical error subprocess.CalledProcessError: Command '['git', 'rev-parse', 'HEAD']' returned non-zero exit status 128 Traceback (most recent call last): File "/home/simonpj/code/HEAD-4/testsuite/driver/testlib.py", line 840, in test_common_work do_test(name, way, func, args, files) File "/home/simonpj/code/HEAD-4/testsuite/driver/testlib.py", line 928, in do_test result = func(*[name,way] + args) File "/home/simonpj/code/HEAD-4/testsuite/driver/testlib.py", line 1019, in makefile_test return run_command(name, way, cmd) File "/home/simonpj/code/HEAD-4/testsuite/driver/testlib.py", line 1012, in run_command return simple_run( name, '', override_options(cmd), '' ) File "/home/simonpj/code/HEAD-4/testsuite/driver/testlib.py", line 1396, in simple_run return check_stats(name, way, stats_file, opts.stats_range_fields) File "/home/simonpj/code/HEAD-4/testsuite/driver/testlib.py", line 1185, in check_stats head_commit = Perf.commit_hash('HEAD') File "/home/simonpj/code/HEAD-4/testsuite/driver/perf_notes.py", line 92, in commit_hash stderr=subprocess.STDOUT) \ File "/usr/lib/python3.5/subprocess.py", line 626, in check_output **kwargs).stdout File "/usr/lib/python3.5/subprocess.py", line 708, in run output=stdout, stderr=stderr)

3 4

Put 'haddock' in the 'ghc' repo
by Vladislav Zavialov 19 Feb '19

19 Feb '19

Hello devs, There appears to be no good workflow for contributing patches that change both GHC and Haddock. For contributors who have push access to both repositories, it is at least tolerable: 1. create a Haddock branch with the required changes 2. create a GHC branch with the required changes Then wait for the GHC change to get merged to `master`, and 3a. fast-forward the Haddock change to the `ghc-head` branch 3b. in case a fast-forward is impossible, cherry-pick the commit to `ghc-head` and push another commit to GHC `master` to update the Haddock submodule Roundabout, but possible. For contributors who do not have push access to both repositories, each step is much harder, as working with forks implies messing with .gitmodules, which arguably should stay constant. To avoid all this friction, I propose the following principle: * all SCC (strongly connected components) of dependencies must go to the same repo. For example, since GHC depends on Haddock to build documentation, and Haddock depends on GHC, they must go to the same repo. This way, a single commit can update both of them in sync. All the best, Vladislav

2 1

CI Docker Images
by Matthew Pickering 18 Feb '19

18 Feb '19

Hi Mark, Ben Where are the dockerfiles (or nix expressions) which are used to build the docker images? I want to update them and push some new images to ghcci but I can't find any trace about how the images have been made. Cheers, Matt

1 1

GItLab commenting
by Simon Peyton Jones 18 Feb '19

18 Feb '19

Friends In reviewing MR!361, I wanted to point out that a Note on line 1481 of a file needed rewriting. But the patch only modified lines 236 or so. How can I get it to display line 1481? (Or, more simply, just display the whole file?) I can get it to show 10 more lines at a time by clicking the little grey "..." symbols. But getting 1000 lines down would take 100 clicks - hardly sensible. Moreover, what if I want to comment on a file that isn't in the patch at all? Thanks Simon

2 3

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