Re: Why are there no Show instances for internal types

Tom Sydney Kerckhove writes: > On 19-03-17 02:08:56, Rahul Muttineni wrote: >> Syd, can you tell us what kind of things you were trying to print out? > > Maybe I wasn't very clear. > I'm trying to visualise the internal structure of some of the > typechecker's output. >

Re: Stat too good

Simon Peyton Jones via ghc-devs writes: > Ben, > I still get these four stat-too-good "failures" on 64-bit Linux. > > Unexpected stat failures: > >/tmp/ghctest-ca0gfq/test spaces/./perf/compiler/T13035.run T13035 [stat > too good] (normal) > >

Re: Why are there no Show instances for internal types

On 18-03-17 16:13:52, Ben Gamari wrote: > > > On March 18, 2017 9:03:48 AM EDT, Tom Sydney Kerckhove > wrote: > > Snip. > > > >My questions for you: > > > >- Is there a reason that there are no derived 'Show' instances for most > > types? > > As Richard mentioned,

Re: Why are there no Show instances for internal types

On 19-03-17 02:08:56, Rahul Muttineni wrote: > Syd, can you tell us what kind of things you were trying to print out? Maybe I wasn't very clear. I'm trying to visualise the internal structure of some of the typechecker's output. I specifically do NOT need to see the output of Outputable's

Re: Compiling CMM tests with LLVM

Erik de Castro Lopo wrote: > Hi all, > > I'm working on a minor change to CMM (#13442) and while writing the > tests realized that the CMM tests were only run with `-fasm` and not > with `-fllvm`. Furthermore other than running the test manually myself, > I could not figure out how to make it

Compiling CMM tests with LLVM

Hi all, I'm working on a minor change to CMM (#13442) and while writing the tests realized that the CMM tests were only run with `-fasm` and not with `-fllvm`. Furthermore other than running the test manually myself, I could not figure out how to make it compile with LLVM. My test (in my WIP

Re: Why are there no Show instances for internal types

Rahul Muttineni writes: > I think another way to go about this problem is to figure out an > alternative to baking in DynFlags to SDocContext (which I feel is the core > problem here). The only use of those DynFlags is via sdocWithDynFlags and > 94 call sites use them. >

Re: Why are there no Show instances for internal types

Am Samstag, den 18.03.2017, 14:03 +0100 schrieb Tom Sydney Kerckhove: > > - 'Outputting' a value requires DynFlags. (yes, I know about pprTrace) You can often get away with showSDocUnsafe . ppr :: Outputable a => a -> String Greetings, Joachim -- Joachim “nomeata” Breitner  

Re: Why are there no Show instances for internal types

I think another way to go about this problem is to figure out an alternative to baking in DynFlags to SDocContext (which I feel is the core problem here). The only use of those DynFlags is via sdocWithDynFlags and 94 call sites use them. - In the frontend, it's used to check for the presence of

Re: Why are there no Show instances for internal types

On March 18, 2017 9:03:48 AM EDT, Tom Sydney Kerckhove wrote: Snip. > >My questions for you: > >- Is there a reason that there are no derived 'Show' instances for most > types? As Richard mentioned, we don't derive Show due to code size and compilation time

Re: Why are there no Show instances for internal types

And I guess it would be bad to use Show, but make custom instances for the problematic types that did not loop? Alan On 18 Mar 2017 9:44 pm, "Edward Z. Yang" wrote: > We can't add Show instances for these types because many types > below them, e.g., Type, are cyclic, and would

Re: Why are there no Show instances for internal types

We can't add Show instances for these types because many types below them, e.g., Type, are cyclic, and would result in infinite output. Perhaps we can add a new type class which a) faithfully represents the Haskell syntax, but b) can deal with cyclic data. I think that's something people would

Re: Stat too good

Just FYI: I'm on 64-bit Linux and don't see those failures (I just validated at 763f43e6d3) Cheers, Michal On Fri, Mar 17, 2017 at 6:49 PM Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > Ben, > > I still get these four stat-too-good “failures” on 64-bit Linux. > > Unexpected

Re: PSA: perf.haskell.org/ghc temporarily out of order

Hi, correct. It seems that 'make boot' tries to compile all of nofib, even those that are not to be run. So this ought to be revised. Greetings, Joachim Am Samstag, den 18.03.2017, 01:56 -0400 schrieb Reid Barton: > Don't know whether it is the same issue, but perf.haskell.org seems > to >

Re: Travis again over time

On Sat, Mar 18, 2017, at 05:36, Alan & Kim Zimmerman wrote: > FYI, liquidhaskell switched from travis to circleci.com because of > timeout > problems. > > It seems the time available is larger there. IIRC CircleCI doesn't have an overall build timeout at all, just (configurable) per-command

Re: Why are there no Show instances for internal types

My take is that we don't have these because they would slow down compilation times and add bloat. But enough people have asked for them (and, I can think of a few times when I would use them myself) that I think they should be added. It is conceivable that we could make the instances only when

Why are there no Show instances for internal types

Dear GHC Devs, I am trying to use GHC as a library but I'm having a lot of trouble with understanding what everything means. Up to now, I have been able to figure out what to do by reading the sources, but it ocured to me that much of my struggles could have been mitigated if the relevant types

Re: Travis again over time

FYI, liquidhaskell switched from travis to circleci.com because of timeout problems. It seems the time available is larger there. And you get access to the build artifacts afterward, as per your configuration. Alan On 9 March 2017 at 19:17, Joachim Breitner wrote: >