- ghc-devs - Haskell.org

Disabled Travis
by Ben Gamari 23 Jan '19

23 Jan '19

Hi All, Travis appears [1] to be both broken and struggling to keep up with our builds. I have disabled it for now. If you have an interest in maintaining Travis then feel free to fix and reenable it. Cheers, - Ben [1] https://travis-ci.org/ghc/ghc/builds

1 0

Drop into a nix shell with ghcHEAD
by Matthew Pickering 22 Jan '19

22 Jan '19

Hi all, I have written a devastating new script which makes it easy to test snippets and packages with build artefacts built by the gitlab CI. One invocation of `nix-shell` will enter an environment with the most recent build artefact from master. Usage: ``` > nix-shell https://github.com/mpickering/ghc-artefact-nix/archive/master.tar.gz unpacking 'https://github.com/mpickering/ghc-artefact-nix/archive/master.tar.gz'... <lots more output> > ghc --version The Glorious Glasgow Haskell Compilation System, version 8.7.20190115 ``` Repo: https://github.com/mpickering/ghc-artefact-nix So far we have tested it works on NixOS and darwin but support for other platforms that nix supports and we build artefacts for should be easy. It might already work on i386 and aarch64 as well but I didn't test these. Cheers, Matt

2 3

MR does not merge
by Simon Peyton Jones 21 Jan '19

21 Jan '19

Ben Six days ago I submitted this MR https://gitlab.haskell.org/ghc/ghc/merge_requests/109 Just tiny refactorings. I said "merge when validated" But six days later, it still appears not to have merged. What's up? I was expecting it to merge in a matter of an hour or two. Thanks Simon

9 14

ANN: Multiple positions for GHC developers
by Manuel M T Chakravarty 21 Jan '19

21 Jan '19

Please excuse this non-technical message, but I assume this is interesting for the members of this list: https://iohk.io/careers/#op-302245-ghc-web-backend-developer (There are multiple positions, same spec.) Cheers, Manuel

1 0

Reproducing bugs without Stack
by Eric Crockett 20 Jan '19

20 Jan '19

Devs, I use Stack for all of my Haskell development. I recently ran into several bugs, which I suspected to be GHC bugs. In the process of creating new tickets, I noticed a banner reading "*Please try to provide reproduction instructions which do not require "Stack"." *The request is reasonable to help weed out bugs in Stack itself, but I could use some advice on how to do that. In particular, I'm having trouble reproducing bugs related to profiling. For example, #16182 <https://ghc.haskell.org/trac/ghc/ticket/16182> is about runtime crashes with the -hr profiling option. This was clearly a GHC bug rather than a problem with stack, yet I have so far been unable to produce the bug without Stack. Similarly, for #16166 <https://ghc.haskell.org/trac/ghc/ticket/16166>, I filed the ticket, then after failing to reproduce the bug with cabal, assumed it must be a stack bug. Fortunately, RyanGlScott noticed and was able to confirm that it is in fact a GHC bug. Ryan explained that my problem reproducing with cabal is due to differences in the profiling options used by stack and cabal. In summary, it would be helpful to have some instructions on how to take a bug produced using Stack to one produced without. For example, if `stack build [--profile] foo` produces a compile bug, how should I use cabal to definitively determine if the bug is a problem with Stack or GHC? Presumably it would begin with `cabal sandbox init`. Are there special options to put in the cabal.config file so that cabal uses the same profiling options as stack? Will those options be used when building all dependencies? Thanks, Eric Crockett

2 1

Gitlab pain
by Simon Peyton Jones 19 Jan '19

19 Jan '19

I'm getting lost in a maze of twisty little passages, all alike. I'm looking at https://gitlab.haskell.org/ghc/ghc/merge_requests/10#note_1877 and https://gitlab.haskell.org/ghc/ghc/merge_requests/10 But the note in the former starting "Another module should reference the symbol..." doesn't show up in the latter, anywhere. How can I see the current state of play on this MR, the ground truth? Simon

8 10

Gitlab notifications
by Simon Peyton Jones 18 Jan '19

18 Jan '19

I don't seem to be receiving notifications for my own MR: https://gitlab.haskell.org/ghc/ghc/merge_requests/128 Richard and Ryan both commented, but I received literally no email about it. I'm set to "Watch" the GHC project. Any ideas? Simon PS: I am getting some notifications * Thurs (today): 3 emails, about !79, !133 * Weds: 6 emails about !51, !125, !124 * Tues: 22 messages about a variety of tickets

2 2

Hackage and ghc shipped package contents mismatch
by Moritz Angermann 18 Jan '19

18 Jan '19

Dear friends, the other day I've run into an issue where I could not build a package. It turned out that the underlying reason was that the packages ghc ships with are not necessarily the same as they are on hackage. Ryan was kind enough to open Ticket 16199[1]. My use case is that I reduce the set of packages I use from the package database that ghc ships, and build the others myself. Thus if packages in the package database as shipped with ghc do not match the ones found on hackage for the SAME VERSION, I run into issues. I've since devised a script to compute the difference between packages in GHC and the ones on hackage with the same version[2]. I've then sat out to compute the differences for ghc8.4 and ghc8.6 using the following approach: for release in ghc-8.4.1-release ghc-8.4.2-release ghc-8.4.3-release ghc-8.4.4-release \ ghc-8.6.4-release ghc-8.6.2-release ghc-8.6.3-release; do git checkout $release git reset --hard HEAD && git clean -xffd git submodule update --init --recursive && git clean -xffd ../verify-packages.sh mkdir -p ../$release find package-diffs -not -empty -type f -exec cp {} ../$release \; done I've compiled them[3] for inspection (and because I need to patch my hackage packages to match the ones that ghc ships). I'm sorry to report that I found discrepancies between the package we ship with GHC and the ones on haskell for each ghc release in 8.4 and 8.6. Some changes are minor, such as version bumps, as can be represented with revisions on hackage as well. Other are not so minor. The one over which I tripped was transformers-0.5.5.0. The diff[4] is 20K. I therefore propose that we make sure to only ship packages with GHC that match their respective versions on hackage. Cheers, Moritz -- [1]: http://ghc.haskell.org/trac/ghc/ticket/16199 [2]: https://gitlab.haskell.org/ghc/ghc/merge_requests/139 [3]: https://github.com/angerman/haskell.nix/tree/master/patches [4]: https://github.com/angerman/haskell.nix/blob/master/patches/ghc863/transfor…

2 1

MutVar# and GC
by chessai . 18 Jan '19

18 Jan '19

Devs, I've heard from a few friends that MutVars, TVars, etc. are more challenging for the garbage collector. I'm writing to ask if someone can answer: 1. Is this true, and 2: Why? I can't seem to find anything like a writeup or documentation that mentions this. The HeapObjects trac page also mentions nothing about these supposed difficulties that GC faces with mutable heap objects. Thanks

3 4

RE: [GHC] #16105: Haddock's resource directory isn't properly handled by Hadrian
by Simon Peyton Jones 17 Jan '19

17 Jan '19

I feel as if I'm seeing the same commits many times. Is that right? Simon | -----Original Message----- | From: ghc-tickets <ghc-tickets-bounces(a)haskell.org> On Behalf Of GHC | Sent: 17 January 2019 17:47 | Subject: Re: [GHC] #16105: Haddock's resource directory isn't properly | handled by Hadrian | | #16105: Haddock's resource directory isn't properly handled by Hadrian | -------------------------------------+------------------------------------- | Reporter: harpocrates | Owner: harpocrates | Type: bug | Status: patch | Priority: normal | Milestone: | Component: Build System | Version: 8.6.3 | (Hadrian) | | Resolution: | Keywords: | Operating System: Unknown/Multiple | Architecture: | | Unknown/Multiple | Type of failure: None/Unknown | Test Case: | Blocked By: | Blocking: | Related Tickets: | Differential Rev(s): | Wiki Page: | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha | skell.org%2Fghc%2Fghc%2Fmerge_requests%2F107&data=02%7C01%7Csimonpj%40m | icrosoft.com%7C372045a12b644a9571cb08d67ca3db5e%7C72f988bf86f141af91ab2d7cd | 011db47%7C1%7C0%7C636833440531332748&sdata=5xl9%2FYs97X%2FZx6gFnQllwe0G | %2F6nns48JAQLpFH%2FcptU%3D&reserved=0 | -------------------------------------+------------------------------------- | | Comment (by Ben Gamari <ben@…>): | | In [changeset:"2e05912086bbb8eab213d44af300ecc396d912aa/ghc" 2e05912/ghc]: | {{{ | #!CommitTicketReference repository="ghc" | revision="2e05912086bbb8eab213d44af300ecc396d912aa" | Hadrian: handle Haddock's resource directory | | Fixes #16105 | | * Require Haddock's resource as runtime dependencies of the Haddock | builder. This means we no longer have to `need` particular resources | in every other documentation rule. | | * Do a _tracked_ copy of both the 'html' and 'latex' folder resource | folders. | | * Move resources into `stage1/lib` (NB: the `haddock` binary goes in | `stage1/bin`). Besides now actually matching the Haddock script | wrapper generated by BinaryDist, this also prepares for Haddock | in relocatable build folder detecting its own resources. | }}} | | -- | Ticket URL: | <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske | ll.org%2Ftrac%2Fghc%2Fticket%2F16105%23comment%3A4&data=02%7C01%7Csimon | pj%40microsoft.com%7C372045a12b644a9571cb08d67ca3db5e%7C72f988bf86f141af91a | b2d7cd011db47%7C1%7C0%7C636833440531332748&sdata=bYvB5fV1dorg3j1nJogVvh | %2Fs7c4onmFfOXJXZ1ZAZj8%3D&reserved=0> | GHC | <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.haske | ll.org%2Fghc%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C372045a12b644a | 9571cb08d67ca3db5e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63683344053 | 1332748&sdata=3xcWX15vR8Vcl3wNn3P%2FsM%2FeBp6nTusSMSkfs%2FXTrGo%3D& | reserved=0> | The Glasgow Haskell Compiler

1 0