Re: 177 unexpected test failures on a new system -- is this yet another linker issue?

On Thu, Nov 10, 2016 at 11:12 PM, Ömer Sinan Ağacan wrote: > I'm trying to validate on a new system (not sure if related, but it has gcc > 6.2.1 and ld 2.27.0), and I'm having 177 unexpected failures, most (maybe > even > all) of them are similar to this one: > > =>

Re: 177 unexpected test failures on a new system -- is this yet another linker issue?

Ömer Sinan Ağacan writes: > I'm trying to validate on a new system (not sure if related, but it has gcc > 6.2.1 and ld 2.27.0), and I'm having 177 unexpected failures, most (maybe > even > all) of them are similar to this one: Hmm, I have a rather similar setup and yet I

177 unexpected test failures on a new system -- is this yet another linker issue?

I'm trying to validate on a new system (not sure if related, but it has gcc 6.2.1 and ld 2.27.0), and I'm having 177 unexpected failures, most (maybe even all) of them are similar to this one: => T5976(ext-interp) 1 of 1 [0, 0, 0] cd "./th/T5976.run" &&

Breakage due to CallStack refactoring

Hi Simon, In 317236db308d you performed some refactoring of CallStack defaulting and noted that there was no change in visisble behavior. However, it isn't seem that this is true. The following two tests [1] now fail as callstacks are no longer produced in their output, TEST="assert T10845"

install pandoc with cabal update

hello y try to install pandoc in mode offline but the standard installation from source preconise to execute cabal update . it seems that cabal update try to connect and download package from hackage.haskell.org. do you known how to execute offline installation ? ghc 7.10.3 cabal 1.24.0.0

Re: ppr of HsDo

As a follow up, I will be continuing with the least-invasive change, which is to keep the existing braces/semis, and make sure that they are all produced correctly. Alan On Thu, Nov 10, 2016 at 12:06 PM, Alan & Kim Zimmerman wrote: > For context, I am putting in a test

Re: ppr of HsDo

For context, I am putting in a test suite similar to the one for ghc-exactprint to ensure that the pretty printer always generates code that can be round tripped back to the original AST. This means that fears of some uncaught case requiring us do it the guaranteed safe way should be allayed. In

RE: ppr of HsDo

It’s not about GHC’s programming style, is it? It’s about what the pretty-printer does. If it were me I’d use braces and semicolons everywhere, so that I could guarantee to parse it easily. But that’s not a strong opinion and I would willingly yield to others! Simon From: Alan & Kim

Re: ppr of HsDo

Thanks. And any thoughts on my proposal to do away with the braces/semi completely? I suspect GHC is the only significant body of code that uses that style still. Alan On Thu, Nov 10, 2016 at 10:24 AM, Simon Peyton Jones wrote: > I think it’s because the “;” is

RE: ppr of HsDo

I think it’s because the “;” is treated as part of the let not part of the do. After all, how does the implicit layout of the let know that the let-bindings are finished? This should work foo = do { let { x = 1 }; Just 5 } Now the let bindings are clearly brought to an end. Or