April 2016 - ghc-devs

Waiting for finalizers to run; exposing Capability internals
by Ryan Trinkle 13 Apr '16

13 Apr '16

Hi everyone, I'm attempting to create benchmarks that include the cost of finalizers that the code creates. To do this, I'm running the test, running performGC, and then waiting for finalizers to finish. However, that last part is a bit of a beast. I'm trying to determine if I can make an improvement to GHC that will better support this. Currently, to wait for finalizers to finish, I do the following: * Run with -N1 * Ensure (i.e., hope) that no finalizers in the program ever block * Repeatedly check whether rts_unsafeGetMyCapability()->run_queue_hd == END_TSO_QUEUE. If it does not, yield; if it does, terminate the program. In my testing, this appears to work. However, since the Capability_ struct is not available in the rts headers provided by GHC, I was only able to achieve this by pasting the relevant headers into my project. I don't expect this kind of functionality to be very forwards compatible, but copy/paste is a level of hackery that I'd prefer to avoid. I'm not very experienced with GHC or RTS development, but I'd like to contribute something that would help make this code more maintainable. A couple of things come to mind: - I could add a function that does the exact check I need (rts_unsafeGetMyCapability()->run_queue_hd == END_TSO_QUEUE) and expose it to userspace. This is probably the simplest approach, and would certainly be the easiest for me, but it also strikes me as a fairly inelegant addition to the RTS API. - I could expose the private header files, rts/*.h, as <rts/private/*.h> to userspace C files. This seems like a generally useful approach, but I would want to ensure that it did not create maintenance headaches for anyone. I'm also very open to other suggestions. Thanks for reading, and I look forward to hearing your input. Regards, Ryan

1 0

GHC 8.0.1-rc3 source tarball availability
by Ben Gamari 13 Apr '16

13 Apr '16

tl;dr: If you would like to produce a binary distribution for GHC 8.0.1-rc3 then let us know, grab the source distribution and start building. The binary distributions will be all released one week from today. Hello GHC packagers, Austin and I are happy to announce the release of the 8.0.1-rc3 source distribution to binary packagers. You will find the tarball and usual assortment of signatures at http://downloads.haskell.org/~ghc/8.0.1-rc3/ This release is the first where we are following our new release policy [1], where a one-week delay will be introduced between the release of the source and binary distributions. The goal of this policy is to give all platforms the opportunity for support from the first day of a release. If all of the expected binary releases are submitted before the week-long delay is through, we can move forward with the release ahead of schedule. Given how late release candidate 3 is, we'd naturally like to get the binary releases out as soon is possible: The sooner we can get this -rc out the door the sooner we can get to the final release. Moreover, it would be appreciated if you could confirm that you intend to offer a binary distribution this release. Otherwise, let either Austin or I know if you have any trouble building your distribution. I have yet to push the 8.0.1-rc3 tag in case we encounter unexpected issues but all of my builds with this tarball thusfar have gone quite well. Good luck and thanks for all of your work! Cheers, - Ben [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html

7 20

How does topological sorting of kind variables really work?
by Ryan Scott 13 Apr '16

13 Apr '16

I'm doing some work in GHC that requires explicitly applying kinds to the kind variables of a data type. I noticed that the order in which the implicit kind variables are sorted is not as predictable as I originally thought. To illustrate what I mean, here is a GHCi session I had recently (with GHC HEAD): $ /opt/ghc/head/bin/ghci -XTypeInType GHCi, version 8.1.20160412: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci > data T (a :: j -> k -> l) (b :: (x, y, z)) = MkT > :t MkT MkT :: forall x y z l k j (a :: j -> k -> l) (b :: (x, y, z)). T a b Much to my surprise, the order of the kind variables wasn't [j, k, l, x, y, z], but rather [x, y, z, l, k, j]! I know that type variables are sorted with a stable topological sort [1], but there must be some other subtlety that I'm missing. How does GHC come up with the order [x, y, z, l, k, j]? Ryan S. ----- [1] http://git.haskell.org/ghc.git/blob/d81cdc227cd487659995ddea577214314c9b4b9…

4 9

7.10.3 fails to build with Xcode 7.3
by Manuel M T Chakravarty 13 Apr '16

13 Apr '16

I just noticed that GHC 7.10.3 (latest release version) fails to build with version 7.3 of Xcode (which just came out of beta). Maybe this is due to https://ghc.haskell.org/trac/ghc/ticket/11744 The problem manifests in the form of a SEGV when dll-split is invoked for the first time — specifically lldb has the following to say, Process 17348 launched: '../lib/bin/dll-split' (x86_64) Process 17348 stopped * thread #1: tid = 0x4a821e, 0x0000000100e26357 libHSrts-ghc7.10.3.dylib`stg_returnToStackTop + 7, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1e) frame #0: 0x0000000100e26357 libHSrts-ghc7.10.3.dylib`stg_returnToStackTop + 7 libHSrts-ghc7.10.3.dylib`stg_returnToStackTop: -> 0x100e26357 <+7>: movq 0x1e(%rax), %rbx 0x100e2635b <+11>: movq 0x10(%rbx), %rbp 0x100e2635f <+15>: leaq 0x126(%rbx), %r15 0x100e26366 <+22>: movq $0x0, 0x904(%r13) Interestingly, the GHC 8.0.1-rc2 build does not exhibit that same failure. It does, however, fail to build due to an undefined symbol: Undefined symbols for architecture x86_64: "_stg_sel_18_upd_info", referenced from: _sc9J_info in Monad.dyn_o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) `gcc' failed in phase `Linker'. (Exit code: 1) make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1 make: *** [all] Error 2 (This may be unrelated to Xcode 7.3 and a known problem on OS X with that RC. I didn’t follow the 8.0.1-rc2 tickets in detail.) As I assume that there will be no further 7.10 release, I am posting this here just to save others the time to track the problem down. Manuel PS: I wish I had the time to check GHC builds with Xcode beta releases, but alas, I usually don’t.

3 4

reduce needs for InScopeSets?
by Richard Eisenberg 12 Apr '16

12 Apr '16

Hi all, I now frequently run across ASSERTion failures triggered by the new substitution invariant checks. This is surely a good thing, but it's gotten me thinking about the need for InScopeSets in substitutions at all. It seems to me that the only(?) use of the InScopeSet is in the uniqAway in substTyVarBndr. uniqAway is used here when the kind of a tyvar changes. Why do we need a new unique when a tyvar's kind changes? Can't we just update the kinds of tyvar occurrences? One might argue that updating tyvar occurrences' kinds is inefficient. This may be true, but we can tackle that problem head-on by storing a separate TyVarEnv Type that contains tyvar occurrence updates. There's still no need for a new unique. If we can get rid of InScopeSets in substitutions, that would be a wonderful thing, I think. Separately, I also see that substTyVar does not currently recur into a tyvar's kind, if the tyvar is not mapped by the substitution. This behavior seems wrong to me, but I guess it's worked thus far. Thoughts? Richard

2 2

TH changes for ghc 8.0
by Erik de Castro Lopo 12 Apr '16

12 Apr '16

Hi all, I'm working on updating persistent-template for ghc-8.0 and reading the migration guide: https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0#template-haskell-2.11.0… specifically the bit that says: > * the DataD, NewtypeD, DataInstD, and NewtypeInstD constructors have a new > field `Maybe Kind` (#10828), and take a `CxtQ` instead of a `[Name]` for > the derived classes (#10819). If you don't know what to do, use `Nothing` > for the kind signature, and `cxt []` for the derived classes. Using `Nothing` as suggested is working out well enough, but I'm a bit befuddled by the change from `[Name]` to `CtxQ` and the usage of `ctx []`. I can't seem to find *any* function named `ctx`. Any light people may be about to shed on this would be much appreciated. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

5 6

Broken haddock in new GHC HEAD build
by Conal Elliott 11 Apr '16

11 Apr '16

I built GHC HEAD from git yesterday (using GHC 7.10.3 on Mac OS 10.9.5), and the haddock I got dies with bash-3.2$ haddock --version dyld: Symbol not found: _ghc_GHC_modInfoExportszugo_info Referenced from: /Users/conal/git-repos/ghc-2016-04-05/inplace/lib/bin/haddock Expected in: /Users/conal/git-repos/ghc-2016-04-05/compiler/stage2/build/libHSghc-8.1-ghc8.1.20160405.dylib in /Users/conal/git-repos/ghc-2016-04-05/inplace/lib/bin/haddock Trace/BPT trap: 5 Luckily, I have a working haddock from 2016-03-07 sources that I copied into my new GHC bin (~/git-repos/ghc-2016-04-05/inplace/bin/) for now. -- Conal

2 2

how to cabal-install with ghc-8.rc3 ?
by Johannes Waldmann 11 Apr '16

11 Apr '16

Hi. I would love to test rc3. Building (with 7.10.3) from source went fine. But then I cannot cabal-install anything: random-1.1: installed package info from too old version of Cabal (key field does not match id field) Failed to install random-1.1 What is the recommended upgrade path? ( bootstrap.sh in cabal/cabal-install (current from github) does not work, tries to download a Cabal version that's not on hackage ) Thanks, J.W.

2 2

GHC 8.0.1-rc3 and required version of elfutils [Was: GHC 8.0.1-rc3 source tarball availability]
by Andrés Sicard-Ramírez 11 Apr '16

11 Apr '16

On 10 April 2016 at 20:55, Ben Gamari <ben(a)well-typed.com> wrote: > I've pushed a new tarball based on > 9c48d8a02dd80bba3bd313bc52add841530e28dc. I have pushed essentially > everything into this candidate that I expect will go into 8.0.1. It > validates but it isn't nearly as well tested as the previous tree. I'll > try doing some further builds tomorrow and let you all know if anything > goes awry. >From running `./configure` on http://downloads.haskell.org/~ghc/8.0.1-rc3/ghc-8.0.0.20160408-x86_64-unkno… it seems that the required version of elfutils is 0.158, however this version of elfutils is not checked when running `./configure` on http://downloads.haskell.org/~ghc/8.0.1-rc3/ghc-8.0.0.20160411-src.tar.xz That is, instead of get an error on configuration time because my version of elfutils is too old, I get an error on compilation time. -- Andrés

2 3

heres an integer-simple build of ghc 7.10.3 for OS X
by Carter Schonwald 10 Apr '16

10 Apr '16

1-2 industrial folks who need to distribute applications on mac seem to have trouble building ghc 7.10.3 with integer simple on OS X 10.11 (probably because of various build tool changes that happened), so I took the time to make a build on my 10.10 mac. should be useful for others too! http://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unoff… https will work,but you'll get a warning that its an aws wildcard cert :) for those who prefer https and dont mind the cert warning https://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unof… shasum -a512 ghc-7.10.3-x86_64-apple-darwin-integer-simple-built-by-carter.tar.bz2 is 37ccb3c3fe3f21b7c56ed09b8c3d59601bde21d651d17609f62b4b41f3658e6f5a7089a0b271d44d18ba856256681a124bc34b3525c245f4917940a66a3aec63

1 1