March 2014 - ghc-devs

GHC Trac registration failed
by Ken Bateman 12 Mar '14

12 Mar '14

I tried to register at https://ghc.haskell.org/trac/ghc/register but I never received a verification email. I've checked my spam folder. Could somebody help me out? The account name is novadenizen, and it's attached to this gmail address. -Ken

1 0

RE: FW: [GHC] #4385: Type-level natural numbers
by Simon Peyton Jones 12 Mar '14

12 Mar '14

I think a new section on “Type-level naturals” would make more sense. That way it’s easier to find, and makes it easier to tell a coherent story Do it on HEAD; Austin can merge as reqd. Simon From: Iavor Diatchki [mailto:iavor.diatchki@gmail.com] Sent: 12 March 2014 16:26 To: Simon Peyton Jones Subject: Re: FW: [GHC] #4385: Type-level natural numbers Hello, There are some docs under `Promoted Literals`. I can add a few more paragraphs to capture the current state. Two questions: - Should I add the new stuff in the same place, or should I move everything under a new Section (e.g., `Type-Level Naturals` or something) - Is there a special branch for the release candidate, or should I only do it on the `master` branch? -Iavor On Tue, Mar 11, 2014 at 1:33 PM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Iavor? -----Original Message----- From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org<mailto:ghc-tickets-bounces@haskell.org>] On Behalf Of GHC Sent: 11 March 2014 20:12 Cc: ghc-tickets(a)haskell.org<mailto:ghc-tickets@haskell.org> Subject: Re: [GHC] #4385: Type-level natural numbers #4385: Type-level natural numbers --------------------------------------------+------------------------------ Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by Lemming): Type-level natural numbers are advertised everywhere for GHC-7.8, but I cannot find documentation in http://www.haskell.org/ghc/docs/7.8.1-rc2/html/users_guide/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4385#comment:66> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ ghc-tickets mailing list ghc-tickets(a)haskell.org<mailto:ghc-tickets@haskell.org> http://www.haskell.org/mailman/listinfo/ghc-tickets

1 0

SV: GHC 7.8 release
by Niklas Larsson 12 Mar '14

12 Mar '14

I'll try to reproduce it and see if I can pin it down.. Niklas ----- Ursprungligt meddelande ----- Från: "Simon Peyton Jones" <simonpj(a)microsoft.com> Skickat: ‎2014-‎03-‎12 16:05 Till: "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> Ämne: GHC 7.8 release Friends The status of the GHC 7.8 release is here https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8/RC2. Alas we are currently stalled on #8870, #8834: we are getting seg-faults on Windows. (For example, on my laptop, the stage2 compiler seg-faults when compiling some (but not all) files. Although few people develop GHC on Windows, many people *use* GHC on Windows, so we can’t really release in this state. We need help! Austin is trying, but it’s all working on his Windows build. He’s trying to get more machines to see if he can reproduce the failure there. Does anyone feel able to help? Even git-bisecting to find the offending commit would be a huge help. In principle I can do that (at two hours per bisection) but I was defeated by an out-of-sync Haddock. I need to know how to remove Haddock from the build altogether. But others are far more skilled than me. On #8834 Simon M speculates that we may have the callee-saves register wrong on Win64. Does anyone feel up to looking into that? Until we find what’s going on, 7.8 is stalled. Thanks! Simon

1 0

RE: [commit: ghc] master: Call Arity: Resurrect fakeBoringCalls (7f919de)
by Simon Peyton Jones 12 Mar '14

12 Mar '14

Could we please have a Note to explain what is going on here? It clearly isn't obvious, or it would have been right the first time! Everyone: practically *whenever* you fix a bug, please add a Note. By definition something subtle is happening. Thanks Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 12 March 2014 12:23 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Call Arity: Resurrect fakeBoringCalls | (7f919de) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/7f919dec1579641bbcd02978a0038c8 | a3723d8b7/ghc | | >--------------------------------------------------------------- | | commit 7f919dec1579641bbcd02978a0038c8a3723d8b7 | Author: Joachim Breitner <mail(a)joachim-breitner.de> | Date: Wed Mar 12 11:15:16 2014 +0100 | | Call Arity: Resurrect fakeBoringCalls | | (Otherwise the analysis was wrong, as covered by the new test case.) | | | >--------------------------------------------------------------- | | 7f919dec1579641bbcd02978a0038c8a3723d8b7 | compiler/simplCore/CallArity.hs | 16 | ++++++++++++++-- | testsuite/tests/callarity/unittest/CallArity1.hs | 4 ++++ | testsuite/tests/callarity/unittest/CallArity1.stderr | 3 +++ | testsuite/tests/perf/compiler/all.T | 3 ++- | 4 files changed, 23 insertions(+), 3 deletions(-) | | diff --git a/compiler/simplCore/CallArity.hs | b/compiler/simplCore/CallArity.hs | index 6334d8d..db0406d 100644 | --- a/compiler/simplCore/CallArity.hs | +++ b/compiler/simplCore/CallArity.hs | @@ -348,7 +348,8 @@ callArityTopLvl exported int1 (b:bs) | exported' = filter isExportedId int2 ++ exported | int' = int1 `addInterestingBinds` b | (ae1, bs') = callArityTopLvl exported' int' bs | - (ae2, b') = callArityBind ae1 int1 b | + ae1' = fakeBoringCalls int' b ae1 | + (ae2, b') = callArityBind ae1' int1 b | | | callArityRHS :: CoreExpr -> CoreExpr | @@ -434,7 +435,8 @@ callArityAnal arity int (Let bind e) | where | int_body = int `addInterestingBinds` bind | (ae_body, e') = callArityAnal arity int_body e | - (final_ae, bind') = callArityBind ae_body int bind | + ae_body' = fakeBoringCalls int_body bind ae_body | + (final_ae, bind') = callArityBind ae_body' int bind | | -- This is a variant of callArityAnal that is additionally told whether | -- the expression is called once or multiple times, and treats thunks | appropriately. | @@ -468,6 +470,16 @@ addInterestingBinds int bind | = int `delVarSetList` bindersOf bind -- Possible shadowing | `extendVarSetList` interestingBinds bind | | +-- For every boring variable in the binder, this amends the CallArityRes | to | +-- report safe information about them (co-called with everything else, | arity 0). | +fakeBoringCalls :: VarSet -> CoreBind -> CallArityRes -> CallArityRes | +fakeBoringCalls int bind res | + = addCrossCoCalls (domRes boring) (domRes res) $ (boring `lubRes` | res) | + where | + boring = ( emptyUnVarGraph | + , mkVarEnv [ (v, 0) | v <- bindersOf bind, not (v | `elemVarSet` int)]) | + | + | -- Used for both local and top-level binds | -- First argument is the demand from the body | callArityBind :: CallArityRes -> VarSet -> CoreBind -> (CallArityRes, | CoreBind) | diff --git a/testsuite/tests/callarity/unittest/CallArity1.hs | b/testsuite/tests/callarity/unittest/CallArity1.hs | index 8a142d5..6dd6182 100644 | --- a/testsuite/tests/callarity/unittest/CallArity1.hs | +++ b/testsuite/tests/callarity/unittest/CallArity1.hs | @@ -163,6 +163,10 @@ exprs = | , (n, Var go `mkApps` [d `mkLApps` [1]]) | , (go, mkLams [x] $ mkACase (Var n) (Var go `mkApps` [Var n | `mkVarApps` [x]]) ) ]) $ | Var go `mkApps` [mkLit 0, go `mkLApps` [0,1]] | + , ("a thunk (non-function-type) co-calls with the body (d 1 would be | bad)",) $ | + mkLet d (f `mkLApps` [0]) $ | + mkLet x (d `mkLApps` [1]) $ | + Var d `mkVarApps` [x] | ] | | main = do | diff --git a/testsuite/tests/callarity/unittest/CallArity1.stderr | b/testsuite/tests/callarity/unittest/CallArity1.stderr | index d5d7d91..c331a64 100644 | --- a/testsuite/tests/callarity/unittest/CallArity1.stderr | +++ b/testsuite/tests/callarity/unittest/CallArity1.stderr | @@ -78,3 +78,6 @@ a thunk (function type), in mutual recursion, still | calls once, d part of mutual | go 1 | d 1 | n 0 | +a thunk (non-function-type) co-calls with the body (d 1 would be bad): | + x 0 | + d 0 | diff --git a/testsuite/tests/perf/compiler/all.T | b/testsuite/tests/perf/compiler/all.T | index fc0abc9..b03a48f 100644 | --- a/testsuite/tests/perf/compiler/all.T | +++ b/testsuite/tests/perf/compiler/all.T | @@ -133,7 +133,7 @@ test('T3294', | # 2012-10-08: 1373514844 (x86/Linux) | # 2013-11-13: 1478325844 (x86/Windows, 64bit machine) | # 2014-01-12: 1565185140 (x86/Linux) | - (wordsize(64), 2897630040, 5)]), | + (wordsize(64), 2705289664, 5)]), | # old: 1357587088 (amd64/Linux) | # 29/08/2012: 2961778696 (amd64/Linux) | # (^ increase due to new codegen, see #7198) | @@ -141,6 +141,7 @@ test('T3294', | # 08/06/2013: 2901451552 (amd64/Linux) (reason unknown) | # 12/12/2013: 3083825616 (amd64/Linux) (reason unknown) | # 18/02/2014: 2897630040 (amd64/Linux) (call arity | improvements) | + # 12/03/2014: 2705289664 (amd64/Linux) (more call arity | improvements) | conf_3294 | ], | compile, | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

Request: export runTcInteractive from TcRnDriver
by p.k.f.holzenspies＠utwente.nl 12 Mar '14

12 Mar '14

Dear GHC-devs, Is there a reason why, in HEAD, TcRnDriver does *not* export runTcInteractive? If not, can it please be added? (I considered sending a patch with this email, but it's so trivial a change that the check of the patch is more work than manually adding runTcInteractive to the export list.) I'm developing against the GHC API of 7.6.3 and it would have saved me hours of work to have precisely that function. Seeing it's in HEAD, but not being exported seems a shame ;) Regards, Philip

3 3

Getting warnings when pushing to git.haskell.org
by Johan Tibell 11 Mar '14

11 Mar '14

Hi, I get the following warning every time I push to git.haskell.org. Anyone have an idea what the correct fix is? $ git push origin master perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LC_CTYPE = "UTF-8", LANG = (unset) are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). Counting objects: 13, done. Delta compression using up to 8 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 652 bytes | 0 bytes/s, done. Total 7 (delta 6), reused 0 (delta 0) remote: performing tab-check... remote: perl: warning: Setting locale failed. remote: perl: warning: Please check that your locale settings: remote: LANGUAGE = (unset), remote: LC_ALL = (unset), remote: LC_CTYPE = "UTF-8", remote: LANG = (unset) remote: are supported and installed on your system. remote: perl: warning: Falling back to the standard locale ("C"). remote: mirroring ssh://git@git.haskell.org/ghc to ssh:// git(a)github.com/ghc/ghc ... remote: To ssh://git@github.com/ghc/ghc remote: 22e4bba..d8b3826 master -> master remote: running notifier To ssh://git@git.haskell.org/ghc.git 22e4bba..d8b3826 master -> master

2 1

Safe Haskell
by Simon Peyton Jones 11 Mar '14

11 Mar '14

David Any views about https://ghc.haskell.org/trac/ghc/ticket/8827? We propose to remove the recursive check (see the ticket for what that means). Simon

1 0

Template Haskell of GHC 7.8 (again)
by Kazu Yamamoto 11 Mar '14

11 Mar '14

Hi, With the attached file, say Printf.hs, GHCi 7.6.3 works as follows: % ghci Printf.hs [1 of 1] Compiling Printf ( Printf.hs, interpreted ) Ok, modules loaded: Printf. > :set -XTemplateHaskell > putStrLn ( $(pr "Hello") ) Hello "Hello" is printed. Good. However, with GHC 7.8, the following error occurs: % ghci Printf.hs [1 of 1] Compiling Printf ( Printf.hs, interpreted ) Ok, modules loaded: Printf. > :set -XTemplateHaskell > putStrLn ( $(pr "Hello") ) unknown package: main Is this a bug of Template Haskell of GHC 7.8? --Kazu {-# LANGUAGE TemplateHaskell #-} -- -- derived from: http://www.haskell.org/ghc/docs/latest/html/users_guide/template-haskell.ht… -- module Printf (pr) where import Language.Haskell.TH data Format = D | S | L String parse :: String -> [Format] parse s = [ L s ] gen :: [Format] -> Q Exp gen [D] = [| \n -> show n |] gen [S] = [| \s -> s |] gen [L s] = stringE s -- | -- -- >>> :set -XTemplateHaskell -- >>> putStrLn ( $(pr "Hello") ) -- Hello pr :: String -> Q Exp pr s = gen (parse s)

2 3

Template Haskell of GHC 7.8
by Kazu Yamamoto 11 Mar '14

11 Mar '14

Hi, The tests for doctest are not passed again with GHC 7.8: ---- 17) Property.runProperty reports the values for which a property that takes multiple arguments fails expected: ["False","0","\"\""] but got: ["<interactive>:24:66:"," \8216doctest_prop\8217 is not in the type environment at a reify"," In the splice: $(polyQuickCheck 'doctest_prop)"] ---- This comes from: ----src/Property.hs where quickCheck term vars = "let doctest_prop " ++ unwords vars ++ " = " ++ term ++ " in $(polyQuickCheck 'doctest_prop)" ---- It seems to me that the behavior of GHC 7.8's Template Haskell changed. Would you tell me how to fix this? --Kazu

1 1

Card marking for newly allocated arrays
by Johan Tibell 10 Mar '14

10 Mar '14

Hi, For MutableArray#s, a card is supposed to be marked if the array is pointing to an object in a younger generation than itself resides in. Since the array always points to elements in the same or an older generation when it gets allocated, we should be fine with marking the array as clean upon allocation and setting all the cards to zero. Right now it's marked as *dirty* and all cards are (modulo a bug) marked as zero. I think we should mark these arrays as clean to avoid some GC costs later. We could avoid writing the card table on allocation as well, as it's always safe to default to dirty. However, this will incur extra GC costs later (after the first write to the array) as the whole array will appear as dirty (due to garbage values in the card table as it wasn't initialized) even if only a single element was written. I'm leaning towards 1) marking arrays as clean and 2) zeroing out the card table when the array is created. Thoughts? -- Johan

2 1