March 2019 - ghc-devs

Testing GHC against Hackage via CI
by Ben Gamari 05 Mar '19

05 Mar '19

Hello everyone, As many of you know, recently I have been working on bringing up infrastructure for using CI-produced binary distributions to build a subset of Hackage using the head.hackage patchset. Happily, this effort has now converged on a usable result, embodied in two merge requests: * https://gitlab.haskell.org/ghc/head.hackage/merge_requests/2 * https://gitlab.haskell.org/ghc/ghc/merge_requests/465 ghc/head.hackage!2 adds CI support to head.hackage. In addition to the usual pass/fail status, this job produces (e.g. [1]) a few additional products: * a JSON summary of the run, describing the dependency graph and pass/fail state of each package. we can feed to an external service to track newly-failing packages. * a (rendered) graphviz graph showing the dependency structure of the built packages, each node colored by its pass/fail state * a tarball of build logs, each including statistics from -ddump-timings. The hope here is that we can use this to track compiler performance on real-world code ghc/ghc!465 adds a job to GHC's own CI pipeline to trigger a head.hackage job using the binary distribution produced earlier in the pipeline. This job will run automatically under a variety of circumstances: * via the scheduled nightly pipeline * on merge requests labelled with the `user-facing` label * when manually started using a button on the MR's Pipelines tab Currently the head.hackage MR tests only a small number of Hackage packages (and their dependencies). Specifically, we currently build `aeson`, `criterion`, `singletons`, `servant`, and `scotty`. This pulls in 127 packages in total. There are a few things that remain to be done: * Better document the existence of the job and how it is triggered * Document how to update the list of tested packages * Work out how to handle tracking of persistent breakage (e.g. we want a notification when a package initially breaks but not in later builds) * Automatically push patched packages to a Hackage repository (e.g. head.hackage.org) as a result of CI. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/head.hackage/-/jobs/38022

2 2

Re: Testing GHC against Hackage via CI
by Ryan Scott 05 Mar '19

05 Mar '19

This is fantastic work! I'm looking forward to using this. Are there plans to merge GitLab's fork of head.hackage back into the upstream repo [1]? I ask since I regularly submit patches to upstream, but if the GitLab CI is using the fork, then it may take some time for upstream changes to make their way back to the fork. Ryan S. ----- [1] https://github.com/hvr/head.hackage

2 1

__mingw_vsnw_printf definition
by Ben Gamari 05 Mar '19

05 Mar '19

Hi Tamar, Recently I've been working on (finally) stabilizing our remaining CI configurations (namely i386/Linux and Windows). I've opened a number of tickets (see the list in !487 [1]) but one of these in particular I'd like your input on. Specifically #16387: The problem is the apparent multiple-definition of __mingw_vsnwprintf: once in mingwex.a and again in RtsSymbols. Unfortunately I have been unable to reproduce this error locally, so debugging has been a bit tricky. The RtsSymbols entry was introduced in 4de585a5c1ac3edc2914cebcac1753b514051a89 (which lifted the MAX_PATH restriction in the RTS) but there was no explanation for why. Do you happen to recall why you added it? Note [Symbols for MinGW's printf] seems relevant, but seems to only discuss the entries for _lock_file and _unlock_file. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/merge_requests/487

1 0

gitlab migration
by Richard Eisenberg 02 Mar '19

02 Mar '19

Hi all, As I'm wrapping up some ICFP papers, I realize that I sometimes link to Trac tickets in published papers. It would be a shame for all these links to suddenly go dead, and I'm sure that my papers aren't the only places external sites link to Trac. Is it expected that, after the full migration, the Trac URLs will redirect? Thanks, Richard

2 1