- ghc-devs - Haskell.org

GHC Trac
by Simon Peyton Jones 21 Mar '15

21 Mar '15

Is it just me, or is GHC's Trac super-slow (again)? Actually it's not just slow but offline from where I am. Simon

3 3

RE: Shake fails test with GHC 7.10 RC3
by Simon Peyton Jones 21 Mar '15

21 Mar '15

| FWIW, I've been noodling over this today since I saw this email, and | sitting down, I think this may be a blocker worth holding up for after | thinking about it. At least, it is until we can quantify how much it | might bite (can we find a workaround? How often does it hit in | practice?) I'm reluctant to delay 7.10 further. I'm sure there are other bugs, and we'll want 7.10.2 before too long. But we won't find them until we push it out. The danger is that we stay in about-to-release mode for ages, and that holds everyone up. We've had three release candidates out over a period of months and Neil seems to be the only one who has tripped over it. I think it'd be better to push it out. (We planned to do so today!) What do others think? Simon | -----Original Message----- | From: mad.one(a)gmail.com [mailto:mad.one@gmail.com] On Behalf Of Austin | Seipp | Sent: 20 March 2015 22:48 | To: Herbert Valerio Riedel | Cc: Simon Peyton Jones; Austin Seipp | Subject: Re: Shake fails test with GHC 7.10 RC3 | | FWIW, I've been noodling over this today since I saw this email, and | sitting down, I think this may be a blocker worth holding up for after | thinking about it. At least, it is until we can quantify how much it | might bite (can we find a workaround? How often does it hit in | practice?) | | I'm testing Iavor's patches that he wanted in at the last minute (I'm | really hesitant for that, since we could break something), so we've | got some time, but I'd like to at least narrow this down a bit more. | | On Fri, Mar 20, 2015 at 12:37 PM, Herbert Valerio Riedel | <hvriedel(a)gmail.com> wrote: | > | > ...does this in any way affect today's GHC 7.10.1 release? I.e. is this | > blocking the release? | > | > | > On 2015-03-20 at 18:19:09 +0100, Simon Peyton Jones wrote: | >> Neil | >> | >> Could you open a ticket for this, and attach the info to it? Lots of | useful info in this thread, but may get lost. | >> | >> Re empty cases, see Note [Empty case alternatives] in CoreSyn. "A | >> case expression can have empty alternatives if (and only if) the | >> scrutinee is bound to raise an exception or diverge." | >> | >> So yes, case (\_ -> ...) of {} is definitely wrong. Could someone | >> extend Core Lint to check for this? The function to call is | >> exprIsHNF: if we have | >> case e of {} | >> then exprIsHNF should never return True. | >> | >> That is a powerful clue, and adding it to Lint will nail the moment at | which it first happens. Good progress. | >> | >> (I'd do it myself but I'm struggling with backlog, and only have 3 | days left before going on holiday for 10 days.) | >> | >> Simon | >> | >> | -----Original Message----- | >> | From: Neil Mitchell [mailto:ndmitchell@gmail.com] | >> | Sent: 20 March 2015 16:57 | >> | To: Carter Schonwald | >> | Cc: Simon Peyton Jones; ghc-devs(a)haskell.org | >> | Subject: Re: Shake fails test with GHC 7.10 RC3 | >> | | >> | > do you use a deepSeq when catching errors from a pure | computation? Or | >> | > is it in a context where you know the value should be treated | strictly? | >> | | >> | The computation is essentially (error "here" :: IO ()), so the IO | monadic | >> | binding should force the exception. In the full source code to | Shake it's | >> | actually in ContT/ReaderT/IO, but a modification to insert liftIO | (if | >> | done in exactly the right way) gives the same result. That | simplified | >> | code is at http://community.haskell.org/~ndm/temp/src.zip | >> | (to run, compile with the logic from | >> | https://github.com/ndmitchell/shake/blob/master/.ghci :benchmark, | then | >> | run "main oracle test"). | >> | | >> | > https://github.com/ndmitchell/shake/issues/216 seems to be the | ticket | >> | > in question | >> | | >> | That is the ticket. The test that is failing is the "oracle" | >> | (Test.Oracle) test suite, and you can see full logs of both success | and | >> | failure at Travis: | >> | https://travis-ci.org/ndmitchell/shake/builds/54748475 . Note that | it | >> | succeeds on GHC 7.2, 7.4, 7.6 and 7.8, but fails on GHC 7.10 RC3 | and GHC | >> | Head. | >> | | >> | Alas, the actual error is coming from deep in the middle of Shake, | >> | specifically this line: | >> | | https://github.com/ndmitchell/shake/blob/master/src/Development/Shake/Cor | >> | e.hs#L329 | >> | | >> | Thinking some more on what I saw, my best guess is that: | >> | | >> | case (\_ -> ...) of {} | >> | | >> | Is a fatal error in GHC. I am guessing that {} means there are no | >> | alternatives because GHC managed to show that the scrutinee throws | an | >> | exception. In addition, evaluating a literal lambda to WHNF will | not | >> | throw an exception, so you have a contradiction. | >> | | >> | Making increasingly wild speculative guesses, I could imagine this | code | >> | compiling to CMM that just fell off the end of a basic block, | arriving at | >> | the next statement of supposedly unconnected code. That actually | matches | >> | what I'm seeing - I have the exception, using print I can see I am | at the | >> | line before, and that I never get to the line after, but pop up | somewhere | >> | nearby and continue onwards seemingly ignoring the exception ever | >> | happened. | >> | | >> | If someone can confirm the above pattern of Core is always illegal | and | >> | always indicates a GHC error then I can reduce the test case driven | >> | purely by the Core, which would be far easier - at the moment Shake | >> | passes through these routines several times to set things up, | making it | >> | harder to simplify them too much without changing the preparation | steps. | >> | | >> | Thanks, Neil | >> | | >> | | >> | >> | >> | >> On Fri, Mar 20, 2015 at 12:01 AM, Neil Mitchell | >> | >> <ndmitchell(a)gmail.com> | >> | >> wrote: | >> | >> > More delving later, it seems the incorrect optimized version | has | >> | >> > been turned into: | >> | >> > | >> | >> > case (\ _ [Occ=Dead, OS=OneShot] -> error "here") of _ | [Occ=Dead] | >> | >> > {} | >> | >> > | >> | >> > While the working one has been turned into: | >> | >> > | >> | >> > errorFunc argument realWorldToken | >> | >> > | >> | >> > where errorFunc _ = error "here" | >> | >> > | >> | >> > I'm not familiar with case ... of _ {} - what does it mean | when | >> | >> > there are no alternatives to the case? And why isn't case on a | >> | >> > literal lambda optimised out? Is it the OneShot annotation | (perhaps | >> | >> > coming from the state hack?) | >> | >> > | >> | >> > The full trace is at | >> | >> > https://gist.github.com/ndmitchell/b222e04eb0c3a397c758. I've | >> | >> > uploaded bad (optimises the error out) and good (works as | expected) | >> | >> > versions of the Core. The summary files are the subexpression | that | >> | >> > changed making a single difference (moving a monomorphic | NOINLINE | >> | >> > function from one module to another) plus the handful of | functions | >> | >> > they depend on, which I've reformatted/inlined/simplified to | produce | >> | the expressions above. | >> | >> > The full versions are the entire -ddump-simpl output from | about | >> | >> > halfway through the build, starting when the differences occur | - | >> | >> > let me know if you need further back. The dodgy function is | "exec". | >> | >> > | >> | >> > Thanks, Neil | >> | >> > | >> | >> > On Thu, Mar 19, 2015 at 11:07 PM, Neil Mitchell | >> | >> > <ndmitchell(a)gmail.com> | >> | >> > wrote: | >> | >> >> Herbert, thanks for the list of patches, nothing obvious | there - | >> | >> >> my best guess is it's something incredibly sensitive and it | only | >> | >> >> needs the tiniest change anywhere to make it happen. Things | like | >> | >> >> moving NOINLINE monomorphic-type definitions from one module | to | >> | >> >> another are causing the bug to appear/disappear, which isn't | what | >> | I'd expect. | >> | >> >> | >> | >> >> Simon, changing from error to error in IO causes the bug to | >> | >> >> disappear, but then so do most things. The error return type | is | >> | >> >> type IO (), so I suspect that forces it to be raised at the | right | >> | >> >> place - but it's certainly one of the possibilities for what | is | >> | >> >> going wrong. Diffing the Core is a great idea. | >> | >> >> | >> | >> >> I'll keep reducing and see what I get to. Given the | sensitivity of | >> | >> >> the bug, I'm sure a NOINLINE on an out-of-the-way function | will | >> | >> >> make it go away, so I can easily fix Shake itself - so I'm | more | >> | >> >> tracking it down from the point of GHC now. | >> | >> >> | >> | >> >> Thanks, Neil | >> | >> >> | >> | >> >> | >> | >> >> On Wed, Mar 18, 2015 at 5:04 PM, Simon Peyton Jones | >> | >> >> <simonpj(a)microsoft.com> wrote: | >> | >> >>> I'm really sorry but I can't think of anything. Sounds | horrible. | >> | >> >>> | >> | >> >>> If you throw exceptions using 'error' (not in IO), then you | are | >> | >> >>> of course vulnerable to strictness changes. If the thing | isn't | >> | >> >>> actually evaluated inside the catch block, you won't see the | >> | >> >>> exception. But I'm sure you've thought of that. | >> | >> >>> | >> | >> >>> I'd experiment with one of the smaller changes you describe, | such | >> | >> >>> as adding a putStrLn, and comparing Core, before and after. | >> | >> >>> Switching off -O will make a huge difference, so hard to | compare. | >> | >> >>> Turning off the state hack will have a more global effect. | But | >> | >> >>> the other changes sound more pin-point and hence the | differences | >> | will be smaller. | >> | >> >>> | >> | >> >>> Simon | >> | >> >>> | >> | >> >>> | -----Original Message----- | >> | >> >>> | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On | Behalf | >> | >> >>> | Of | >> | >> >>> Neil | >> | >> >>> | Mitchell | >> | >> >>> | Sent: 18 March 2015 15:33 | >> | >> >>> | To: ghc-devs(a)haskell.org | >> | >> >>> | Subject: Shake fails test with GHC 7.10 RC3 | >> | >> >>> | | >> | >> >>> | Hi, | >> | >> >>> | | >> | >> >>> | Testing GHC 7.10 RC3 I've found a bug where Shake seems | to | >> | >> >>> | catch | >> | >> >>> the | >> | >> >>> | wrong exception in the wrong place. It's only hit by one | of my | >> | >> >>> tests, | >> | >> >>> | and I've managed to isolate it to a fragment of code with | no | >> | >> >>> | unsafePerformIO, that throws exceptions using error (so | not in | >> | >> >>> | IO), | >> | >> >>> and | >> | >> >>> | operates in IO. Turning off the stack hack makes the bug | go | >> | >> >>> | away, | >> | >> >>> but | >> | >> >>> | then so does -O0, marking one of the functions it calls | >> | >> >>> | NOINLINE, | >> | >> >>> or | >> | >> >>> | moving an INLINE function it calls to a different module, | or | >> | >> >>> | adding | >> | >> >>> a | >> | >> >>> | putStrLn under a catch block - it's very sensitive to the | >> | >> >>> | exact conditions. This test and this exact code worked | fine | >> | >> >>> | with GHC 7.10 RC2. | >> | >> >>> | | >> | >> >>> | I was wondering if there have been any state hack related | >> | >> >>> | changes | >> | >> >>> or | >> | >> >>> | other potentially dangerous optimisation changes since | RC2? | >> | >> >>> | I'll continue to try reducing the bug, but it's somewhat | >> | >> >>> | difficult as | >> | >> >>> the | >> | >> >>> | larger system is quite big, and the code is very | sensitive. | >> | >> >>> | | >> | >> >>> | Thanks, Neil | >> | >> >>> | _______________________________________________ | >> | >> >>> | ghc-devs mailing list | >> | >> >>> | ghc-devs(a)haskell.org | >> | >> >>> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | >> | >> > | >> | >> > On Thu, Mar 19, 2015 at 11:24 PM, Simon Peyton Jones | >> | >> > <simonpj(a)microsoft.com> wrote: | >> | >> >> Thanks! I think a -ddump-simpl before and after the smallest | >> | >> >> change the makes the difference would be illuminating. | >> | >> >> | >> | >> >> Simon | >> | >> >> | >> | >> >> | -----Original Message----- | >> | >> >> | From: Neil Mitchell [mailto:ndmitchell@gmail.com] | >> | >> >> | Sent: 19 March 2015 23:07 | >> | >> >> | To: Simon Peyton Jones | >> | >> >> | Cc: ghc-devs(a)haskell.org | >> | >> >> | Subject: Re: Shake fails test with GHC 7.10 RC3 | >> | >> >> | | >> | >> >> | Herbert, thanks for the list of patches, nothing obvious | there - | >> | >> >> | my best guess is it's something incredibly sensitive and it | only | >> | >> >> | needs the tiniest change anywhere to make it happen. Things | like | >> | >> >> | moving NOINLINE monomorphic-type definitions from one | module to | >> | >> >> | another are causing the bug to appear/disappear, which | isn't what | >> | I'd expect. | >> | >> >> | | >> | >> >> | Simon, changing from error to error in IO causes the bug to | >> | >> >> disappear, | >> | >> >> | but then so do most things. The error return type is type | IO (), | >> | >> >> | so I suspect that forces it to be raised at the right place | - | >> | >> >> | but it's certainly one of the possibilities for what is | going | >> | >> >> | wrong. Diffing the Core is a great idea. | >> | >> >> | | >> | >> >> | I'll keep reducing and see what I get to. Given the | sensitivity | >> | >> >> | of | >> | >> >> the | >> | >> >> | bug, I'm sure a NOINLINE on an out-of-the-way function will | make | >> | >> >> | it | >> | >> >> go | >> | >> >> | away, so I can easily fix Shake itself - so I'm more | tracking it | >> | >> >> | down from the point of GHC now. | >> | >> >> | | >> | >> >> | Thanks, Neil | >> | >> >> | | >> | >> >> | | >> | >> >> | On Wed, Mar 18, 2015 at 5:04 PM, Simon Peyton Jones | >> | >> >> | <simonpj(a)microsoft.com> wrote: | >> | >> >> | > I'm really sorry but I can't think of anything. Sounds | >> | horrible. | >> | >> >> | > | >> | >> >> | > If you throw exceptions using 'error' (not in IO), then | you | >> | >> >> | > are of | >> | >> >> | course vulnerable to strictness changes. If the thing | isn't | >> | >> >> | actually evaluated inside the catch block, you won't see | the | >> | >> >> | exception. But | >> | >> >> I'm | >> | >> >> | sure you've thought of that. | >> | >> >> | > | >> | >> >> | > I'd experiment with one of the smaller changes you | describe, | >> | >> >> | > such | >> | >> >> as | >> | >> >> | adding a putStrLn, and comparing Core, before and after. | >> | >> >> | Switching | >> | >> >> off - | >> | >> >> | O will make a huge difference, so hard to compare. Turning | off | >> | >> >> | the | >> | >> >> state | >> | >> >> | hack will have a more global effect. But the other changes | >> | >> >> | sound | >> | >> >> more | >> | >> >> | pin-point and hence the differences will be smaller. | >> | >> >> | > | >> | >> >> | > Simon | >> | >> >> | > | >> | >> >> | > | -----Original Message----- | >> | >> >> | > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] | On | >> | >> >> | > | Behalf | >> | >> >> Of | >> | >> >> | Neil | >> | >> >> | > | Mitchell | >> | >> >> | > | Sent: 18 March 2015 15:33 | >> | >> >> | > | To: ghc-devs(a)haskell.org | >> | >> >> | > | Subject: Shake fails test with GHC 7.10 RC3 | >> | >> >> | > | | >> | >> >> | > | Hi, | >> | >> >> | > | | >> | >> >> | > | Testing GHC 7.10 RC3 I've found a bug where Shake | seems to | >> | >> >> | > | catch | >> | >> >> the | >> | >> >> | > | wrong exception in the wrong place. It's only hit by | one of | >> | >> >> | > | my | >> | >> >> | tests, | >> | >> >> | > | and I've managed to isolate it to a fragment of code | with | >> | >> >> | > | no unsafePerformIO, that throws exceptions using error | (so | >> | >> >> | > | not in | >> | >> >> IO), | >> | >> >> | and | >> | >> >> | > | operates in IO. Turning off the stack hack makes the | bug go | >> | >> >> away, | >> | >> >> | but | >> | >> >> | > | then so does -O0, marking one of the functions it | calls | >> | >> >> NOINLINE, or | >> | >> >> | > | moving an INLINE function it calls to a different | module, | >> | >> >> | > | or | >> | >> >> adding | >> | >> >> | a | >> | >> >> | > | putStrLn under a catch block - it's very sensitive to | the | >> | >> >> | > | exact conditions. This test and this exact code worked | fine | >> | >> >> | > | with GHC | >> | >> >> 7.10 | >> | >> >> | > | RC2. | >> | >> >> | > | | >> | >> >> | > | I was wondering if there have been any state hack | related | >> | >> >> changes or | >> | >> >> | > | other potentially dangerous optimisation changes since | RC2? | >> | >> >> | > | I'll continue to try reducing the bug, but it's | somewhat | >> | >> >> | > | difficult as | >> | >> >> the | >> | >> >> | > | larger system is quite big, and the code is very | sensitive. | >> | >> >> | > | | >> | >> >> | > | Thanks, Neil | >> | >> >> | > | _______________________________________________ | >> | >> >> | > | ghc-devs mailing list | >> | >> >> | > | ghc-devs(a)haskell.org | >> | >> >> | > | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc- | devs | >> | >> _______________________________________________ | >> | >> ghc-devs mailing list | >> | >> ghc-devs(a)haskell.org | >> | >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | >> | > | >> | > | >> _______________________________________________ | >> ghc-devs mailing list | >> ghc-devs(a)haskell.org | >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs | > | > -- | > "Elegance is not optional" -- Richard O'Keefe | > | | | | -- | Regards, | | Austin Seipp, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/

6 10

RE: [GHC] #10158: Panic compiling singletons: StgCmmEnv: variable not found
by Simon Peyton Jones 20 Mar '15

20 Mar '15

Replying by email since Trac is down. I nailed this one. This diff fixes it. It was a missing 'runFlatten'. However I propose not to commit a fix, because Richard's D653 refactors all that code and, I'm 99% certain, fixes the bug in a better way. I would like D653 to land though. Richard are you doing that, or are you waiting for Austin to? Simon Modified compiler/typecheck/TcInteract.hs diff --git a/compiler/typecheck/TcInteract.hs b/compiler/typecheck/TcInteract.hs index e83709c..4d4b31c 100644 --- a/compiler/typecheck/TcInteract.hs +++ b/compiler/typecheck/TcInteract.hs @@ -1420,6 +1420,7 @@ shortCutReduction old_ev fsk ax_co fam_tc tc_args | otherwise = ASSERT( not (isDerived old_ev) ) -- Caller ensures this ASSERT( ctEvEqRel old_ev == NomEq ) + runFlatten $ do { (xis, cos) <- flattenManyNom old_ev tc_args -- ax_co :: F args ~ G tc_args -- cos :: xis ~ tc_args | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | GHC | Sent: 14 March 2015 03:07 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #10158: Panic compiling singletons: StgCmmEnv: | variable not found | | #10158: Panic compiling singletons: StgCmmEnv: variable not found | -------------------------------------+----------------------------------- | -- | Reporter: trommler | Owner: | Type: bug | Status: new | Priority: highest | Milestone: | Component: Compiler | Version: 7.11 | (CodeGen) | Keywords: | Resolution: | Architecture: | Operating System: Unknown/Multiple | Unknown/Multiple | Type of failure: None/Unknown | Test Case: | Blocked By: | Blocking: | Related Tickets: | Differential Revisions: | -------------------------------------+----------------------------------- | -- | Changes (by goldfire): | | * priority: normal => highest | | | Comment: | | Yikes! I hope I'm not overstating the importance of my library to GHC, | but | this sounds serious. | | Is this reproducible on the 7.10 branch? If so, please set the milestone | to 7.10.1. | | -- | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10158#comment:1> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets

2 1

Shake fails test with GHC 7.10 RC3
by Neil Mitchell 20 Mar '15

20 Mar '15

Hi, Testing GHC 7.10 RC3 I've found a bug where Shake seems to catch the wrong exception in the wrong place. It's only hit by one of my tests, and I've managed to isolate it to a fragment of code with no unsafePerformIO, that throws exceptions using error (so not in IO), and operates in IO. Turning off the stack hack makes the bug go away, but then so does -O0, marking one of the functions it calls NOINLINE, or moving an INLINE function it calls to a different module, or adding a putStrLn under a catch block - it's very sensitive to the exact conditions. This test and this exact code worked fine with GHC 7.10 RC2. I was wondering if there have been any state hack related changes or other potentially dangerous optimisation changes since RC2? I'll continue to try reducing the bug, but it's somewhat difficult as the larger system is quite big, and the code is very sensitive. Thanks, Neil

4 9

ANNOUNCE: GHC 7.10.1 Release Candidate 3
by Austin Seipp 19 Mar '15

19 Mar '15

We are pleased to announce the third release candidate for GHC 7.10.1: https://downloads.haskell.org/~ghc/7.10.1-rc3 https://downloads.haskell.org/~ghc/7.10.1-rc3/docs/html/ This includes the source tarball and bindists for Windows and Debian Linux. FreeBSD, CentOS and Mac OS X binary distributions will follow soon. These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.10.1 final release at the end of this week - so please test as much as possible; bugs are much cheaper if we find them before the release! The list of issues we plan on fixing can always be found in an up-to-date form here: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

12 17

Extracting kind variables from LHsTyVarBndr
by Jan Stolarek 19 Mar '15

19 Mar '15

forall hi, is there a function somewhere in the source code that extracts kind variable names from LHsTyVarBndr? I couldn't find anything. Writing one seems a bit scary given the fact that not all fields in HsType constructors are obvious to me. Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

2 1

RE: [Diffusion] [Committed] rHADDOCK4bb685bd0f57: Track changes in HsSyn for quasi-quotes
by Simon Peyton Jones 19 Mar '15

19 Mar '15

Austin I'm puzzled about this. This relates to something I did ages ago, and I thought was fully committed. I didn't intend to commit anything yesterday. Something mysterious. I hope I have not messed up. Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 19 March 2015 00:13 | To: Simon Peyton Jones | Subject: [Diffusion] [Committed] rHADDOCK4bb685bd0f57: Track changes in | HsSyn for quasi-quotes | | simonpj committed rHADDOCK4bb685bd0f57: Track changes in HsSyn for | quasi-quotes (authored by simonpj). | | Track changes in HsSyn for quasi-quotes | | | AFFECTED FILES | /haddock-api/src/Haddock/Backends/LaTeX.hs | /haddock-api/src/Haddock/Backends/Xhtml/Decl.hs | /haddock-api/src/Haddock/Interface/Rename.hs | | USERS | simonpj (Author) | | COMMIT | https://phabricator.haskell.org/rHADDOCK4bb685bd0f57 | | REPLY HANDLER ACTIONS | Reply to comment. | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj

2 1

Bootstrapping 7.8 using 7.10
by Yitzchak Gale 18 Mar '15

18 Mar '15

Moving here from Reddit, as suggested by Herbert. This a continuation of a thread that started with Edward Yang's post here: http://mail.haskell.org/pipermail/glasgow-haskell-users/2014-October/025389… continued here, a few months later: http://mail.haskell.org/pipermail/glasgow-haskell-users/2014-December/02552… and ended here, in the following month: http://mail.haskell.org/pipermail/glasgow-haskell-users/2015-January/025551… Herbert Valerio Riedel wrote on Reddit (http://www.reddit.com/r/haskell/comments/2zc2jg/ghc_7101_rc3_is_out_test_it…) > I think I remember what the problem was with your patch (and why it > wasn't picked up rightaway): you needed tweaks to boot packages such > as transformers would cause the GHC source-tarball to diverge from > the officially released upstream packages. One solution would be to > rather provide an out-of-tree patch a user can apply manually, > rather than making an official GHC 7.8.5 release with unofficial > modifications to upstream packages (which would also require some > administration overhead on the Git level as upstream packages are > automatically mirrored Git submodules). I think Edward's last post (in January, linked above) addressed those concerns. In summary: release upstream point releases for hpc and hoopl that only bump the dependencies of base and time, and provide instance Applicative IO in the GHC sources for 7.8.5 so that no change is needed for transformers. Will that work? Can we go with this? Thanks, Yitz

2 2

HEAD not buildable by 7.10.1 RC3?
by Karel Gardas 18 Mar '15

18 Mar '15

Hi, for a few last days I'm not able to build amd64/solaris11 build of HEAD using 7.10.1. I've been using RC1 for this, then post RC2 and now RC3 and the issue is still the same: ld: fatal: library -lHSghc-7.11.20150318-5E218FiotzLAN97RtaMkIl: not found ld: fatal: file processing errors. No output written to ghc/stage1/build/tmp/ghc-stage1 collect2: ld returned 1 exit status gmake[1]: *** [ghc/stage1/build/tmp/ghc-stage1] Error 1 gmake: *** [all] Error 2 the problem is that the library which is created is named: libHSghc-7.11-5E218FiotzLAN97RtaMkIl.a and so <year><month><day> is missing there, hence linking fails. I assume this may be caused by the patch below, but I'm not sure so if I'm mistaken here I'm sorry for this Edward. Anyway, I would like to raise this concern since we're already in RC3 for 7.10.1 and if something needs to be changed there, it would be better to do that rather sooner IMHO. Although this is issue on Solaris I assume it to be same on Linux, except that we probably don't have user/buildbot building HEAD with not yet release 7.10.1 and so we do not have this reported. Solaris11/amd64 is kind of special here, since the support for this platform is new in 7.10.1 and so I need to use this unreleased compiler. For compilation log please have a look into amd64/solaris11 buildbot output: http://haskell.inf.elte.hu/builders/solaris-amd64-head/232/10.html -- this is still using post-RC2 as a bootstrap compiler, but the issue with RC3 is the same. Thanks! Karel commit 838d8044896b6544d8c80c2ab5de63d97220f06c Author: Edward Z. Yang <ezyang(a)cs.stanford.edu> Date: Wed Mar 11 14:53:17 2015 +0100 Update Cabal submodule to latest 1.22 snapshot This changes the library file name format NOTE: This patch originally updated to Cabal HEAD, but was reduced to update to Cabal 1.22 HEAD by hvr as this is needed in order to update the filepath submodule to version 1.4.0, and subsequently to be cherry-picked into the ghc-7.10 branch Signed-off-by: Edward Z. Yang <ezyang(a)cs.stanford.edu> Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D707

2 1

Minor doc patch for ghc 7.10 + did I submit the patch correctly/follow the process?
by Doug Burke 18 Mar '15

18 Mar '15

I've submitted a small patch for 7.10.1 to the docs, to re-arrange the order of the "important changes", since - as a "casual" user, things like the AMP/BPP seem like they should be mentioned first, before changes labelled as experimental. The change is at https://phabricator.haskell.org/D736 I'm sending this email to a) make sure this change gets seen b) ask if I did this the right way; I'm happy to write this up as an addendum to the newcomers guide/something else on the wiki if it is a sensible path for a doc-only patch I followed a combination of the phabricator intro [1] and newcomers guide [2] but 1) I did not create a ticket; should I have done so? The existing documentation assumes that you are fixing a bug. It's not clearto me if "RFE to the docs" should be treated the same way 2) since the master branch doesn't contain the 7.10 doc file, and the newcomer guide assumes you are working from the master branch, I did # downloading the submodules seems excessive for a doc-only patch % git config --global url."git://github.com/ghc/packages-".insteadOf git:// github.com/ghc/packages/ % git clone --recursive git://github.com/ghc/ghc % cd git % arc install-certificate ... enter in the token as requested % git checkout ghc-7.10 # as I'm on a very slow download link the repository needed to be updated, so % git fetch origin % git pull origin ghc-7.10 # since some of these were in need of updating and 'arc diff' complained % git submodule update ... edit docs/users_guide/7.10.1-notes.xml # just to check I didn't make any obvious snafus % xmllint 7.10.1-notes.xml % git diff % git add 7.10.1-notes.xml % git commit -m '...' # finally get to arc; the first time I tried it complained about a missing "branch" # so I guessed it made sense to use the branch I had started with, rather than the # suggested one (which I think was master) % arc diff ghc-7.10 ... edit the file and guess at what to put in for reviewers (which I just left as blank and fortunately it looks like it defaults to something sensible). Which is a rather heavy weight process when all I wanted to do was re-organize several paragraphs of a text file! Note that I was lazy and didn't try building ghc since it really is a simple doc change and I didn't want to go and spend even more time working out what I needed to build ghc documentation. Doug [1] https://ghc.haskell.org/trac/ghc/wiki/Phabricator [2] https://ghc.haskell.org/trac/ghc/wiki/Newcomers

3 3