- ghc-devs - Haskell.org

RE: [commit: ghc] wip/T10613: State hack hack in ticky report (02493dc)
by Simon Peyton Jones 15 Apr '16

15 Apr '16

Joachim The commit message says something about "tick reports", but the change to the code is entirely un-commented, and appears to have nothing to do with ticky reports. Could you add a comment or Note to explain? Thanks! Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 14 April 2016 21:35 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] wip/T10613: State hack hack in ticky report | (02493dc) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : wip/T10613 | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.has | kell.org%2ftrac%2fghc%2fchangeset%2f02493dcf580141110e90fa943ec70640115 | de0ed%2fghc&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c306055dca | afa407e7ce708d364a49c11%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=d% | 2f7isihh6dMDZX93hTY8rsMQ7y%2f6mkiDm2asfPXpMrQ%3d | | >--------------------------------------------------------------- | | commit 02493dcf580141110e90fa943ec70640115de0ed | Author: Joachim Breitner <mail(a)joachim-breitner.de> | Date: Wed Mar 23 11:10:25 2016 +0100 | | State hack hack in ticky report | | In the ticky report, do not mark a function with a State# argument | as | its first argument as single-entry. | | | >--------------------------------------------------------------- | | 02493dcf580141110e90fa943ec70640115de0ed | compiler/codeGen/StgCmmClosure.hs | 5 ++++- | 1 file changed, 4 insertions(+), 1 deletion(-) | | diff --git a/compiler/codeGen/StgCmmClosure.hs | b/compiler/codeGen/StgCmmClosure.hs | index b467048..3b83b8e 100644 | --- a/compiler/codeGen/StgCmmClosure.hs | +++ b/compiler/codeGen/StgCmmClosure.hs | @@ -234,7 +234,10 @@ mkLFReEntrant _ _ [] _ | = pprPanic "mkLFReEntrant" empty | mkLFReEntrant top fvs args arg_descr | = LFReEntrant top os_info (length args) (null fvs) arg_descr | - where os_info = idOneShotInfo (head args) | + where | + state_hack_hack = isStateHackType (idType (head args)) | + os_info | state_hack_hack = noOneShotInfo | + | otherwise = idOneShotInfo (head args) | | ------------- | mkLFThunk :: Type -> TopLevelFlag -> [Id] -> UpdateFlag -> | LambdaFormInfo | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha | skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c306055dcaafa4 | 07e7ce708d364a49c11%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=c0Gvy1 | OhKUN%2f%2f5Gtx9pCjHEFyj0FMdQBuEzEF4bfvio%3d

2 1

GHC 8 and Template Haskell
by Iavor Diatchki 14 Apr '16

14 Apr '16

Hello, Now that "OVERLAPPING" and "OVERLAPPABLE" are pragmas on the instances, do we have a way to generate instances with such pragmas using Template Haskell? I can't seem to find a way to do this, which is unfortunate. If I am not missing anything, would there be objections to adding it to the TH library before the next release---I would volunteer to do the change ASAP. Let me know, -Iavor

6 8

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

14 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 12 Apr '16

12 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