- ghc-devs - Haskell.org

Lint warnings
by Simon Peyton Jones 15 Apr '16

15 Apr '16

Lint has started emitting lots of warnings like this, when compiling libraries. Lint warning: case binder's type has no constructors ds_sPA5 V1 p_a7vb Does anyone have any idea why? Simon

1 0

RE: [GHC] #11863: MSN Customer Service %% 18552337309 %% Live Tech Assistance Phone Number
by Simon Peyton Jones 15 Apr '16

15 Apr '16

Devs, Is there anything anyone can do to kill off this spam? Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | GHC | Sent: 15 April 2016 13:08 | Cc: ghc-tickets(a)haskell.org | Subject: [GHC] #11863: MSN Customer Service %% 18552337309 %% Live Tech | Assistance Phone Number | | #11863: MSN Customer Service %% 18552337309 %% Live Tech Assistance | Phone Number | -------------------------------------+--------------------------------- | - | -------------------------------------+--- | Reporter: roxiertaylor | Owner: | Type: bug | Status: new | Priority: normal | Milestone: | Component: Compiler | Version: 7.10.3 | Keywords: | Operating System: | Unknown/Multiple | Architecture: | Type of failure: None/Unknown | Unknown/Multiple | | Test Case: | Blocked By: | Blocking: | Related Tickets: | Differential Rev(s): | Wiki Page: | -------------------------------------+--------------------------------- | - | -------------------------------------+--- | MSN Customer Service %% 18552337309 %% Live Tech Assistance Phone | Number Msn Customer Service Number . | Msn Customer Service Phone Number . | Msn Customer Service Contact Number . | Msn Customer Service Telephone Number . | Msn Customer Service Helpline Number . | Msn Customer Service Toll Free Number . | Phone Number For Msn . | Msn Customer Support Phone Number . | Msn Customer Service Help Desk Number . | Msn Customer Service Landline Number . | Msn Customer Service 24/7 Number . | Msn Customer Service Number . | Msn Customer Service Number . | Msn tech support number . | Msn tech support phone number . | Msn tech support contact number . | Msn tech support helpline number . | Msn tech support help . | Msn tech support help desk number . | Msn tech support telephone number . | Msn tech support mobile number . | Msn tech support landline number . | Msn tech support toll free number . | Msn tech support 24/7 hours number . | Msn tech support contact details . | Msn tech support contact info . | Msn tech support line . | Msn tech support number . | Msn tech support number . | Msn tech support representative . | Msn tech support phone number . | Msn tech support phone number . | Msn tech support team . | Msn tech support live support . | Msn tech support assistance . | Msn tech support assistance number . | Msn tech support assistance contact number . | Msn tech support assistance phone number . | Msn tech support assistance helpline number . | Msn tech support assistance help desk number . | Msn customer support assistance 24/7 . | Msn tech support online support . | Msn tech support number . | Msn tech support number . | Msn tech support no. . | Msn team support number . | Msn team support phone number . | Msn team support contact number . | Msn team support helpline number . | Msn team support help . | Msn team support help desk number . | Msn team support telephone number . | Msn team support mobile number . | Msn team support landline number . | Msn team support toll free number . | Msn team support 24/7 hours number . | Msn team support contact details . | Msn team support contact info . | Msn team support line . | Msn team support number . | Msn team support number . | Msn team support representative . | Msn team support phone number . | Msn team support phone number . | Msn team support team . | Msn team support team support . | Msn team support assistance . | Msn team support assistance number . | Msn team support assistance contact number . | Msn team support assistance phone number . | Msn team support assistance helpline number . | Msn team support assistance help desk number . | Msn customer support assistance 24/7 . | Msn team support online support . | Msn team support number . | Msn team support no. . | Msn help desk number . | Msn help desk phone number . | Msn help desk contact number . | Msn help desk helpline number . | Msn help desk help . | Msn help desk help desk number . | Msn help desk telephone number . | Msn help desk mobile number . | Msn help desk landline number . | Msn help desk toll free number . | Msn help desk 24/7 hours number . | Msn help desk contact details . | | (call) I*855*2I2*2247 Msn Customer Service and Support Phone Number | Helpline (USA) | | -- | Ticket URL: | <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.ha | skell.org%2ftrac%2fghc%2fticket%2f11863&data=01%7c01%7csimonpj%40064d.m | gd.microsoft.com%7cf0b502d0bd064851372f08d365270a49%7c72f988bf86f141af9 | 1ab2d7cd011db47%7c1&sdata=q42%2bpnHzKHYRpQAa5RTUN%2bpY6AAjGeD%2fDGtVJn9 | PILc%3d> | GHC | <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ha | skell.org%2fghc%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cf0 | b502d0bd064851372f08d365270a49%7c72f988bf86f141af91ab2d7cd011db47%7c1&s | data=xCiJdocJi4IW1A9Yzb922NIefegLQTA5x6FJjwXzvMo%3d> | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha | skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | tickets&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cf0b502d0bd064 | 851372f08d365270a49%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9gk1SL | AtX%2fhlwci77qo95c2JsBgFKbqt2KEV4IQqTOU%3d

2 1

Re: GHC 8 and Template Haskell
by Ben Gamari 15 Apr '16

15 Apr '16

Bardur Arantsson <spam(a)scientician.net> writes: > On 04/14/2016 08:17 PM, Austin Seipp wrote: >> Here's a question, on top of this one: why don't we require >> template-haskell changes for most corresponding syntax changes? We >> tend to play catch up with template-haskell sometimes and it's >> relatively strange. I mean, in some sense, we could have said a while >> back "This needs another revision, please add template haskell >> support" and avoided it all. >> >> Richard has a better insight into this than I do, I'm sure, but it >> seems - to me, anyway - like template-haskell support is a reasonable >> bar for most surface-level syntax change to cross, before getting >> merged. >> >> My intuition tells me that, most of the time, a lot of us simply >> forget to make the changes, or ask for them in reviews, and so it >> goes. >> > > ISTM that this kind of thing could be reasonably handled by simply > having a checklist for new functionality -- which includes TH support as > a checkbox. > Indeed, I have a list that I try to check against while reviewing. I've put it up here [1] (and added checking for template-haskell support) although I agree that it would be nice if this were better integrated into the review process. > I'm sure others there are other frequently-forgotten-but-important > things that people can think of to put into such a checklist. > > (Not sure if GHC has a "Release" checklist, but I'd imagine one of those > might also be useful.) There is the MakingReleases page [2]. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/PatchChecklist [2] https://ghc.haskell.org/trac/ghc/wiki/MakingReleases

1 0

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