Richard Eisenberg writes:
> Hi devs,
>
> On my kind=type branch (D808), I have this test failure for
> stranal/sigs/UnsatFun:
>
Hmmm. I was curious and so took the opportunity to do a bit of digging.
This likely isn't helpful but you never know...
> -UnsatFun.g: b
This shows up in more recent builds of my packages on Travis CI, e.g.
https://travis-ci.org/haskell-opengl/OpenGL/jobs/93814917#L296, but I don't
have a clue what's causing it (GHC? cabal? Something else?), if I should
ignore it or if I should somehow act on that. :-/ My gut feeling is that
it's
Hi,
Am Sonntag, den 29.11.2015, 10:42 -0500 schrieb Richard Eisenberg:
> On my kind=type branch (D808), I have this test failure for
> stranal/sigs/UnsatFun:
>
> Strictness signatures
> UnsatFun.$trModule: m
> UnsatFun.f: b
>
Jens Petersen writes:
> On 18 November 2015 at 23:48, Ben Gamari wrote:
>> We are pleased to announce the third release candidate of GHC 7.10.3:
>
> Thanks, I built it for Fedora and RHEL/CentOS 7 in my copr repo:
>
Thanks Jens!
On that note, 7.10.3
Done in https://phabricator.haskell.org/D1530.
On Wed, Nov 25, 2015 at 12:36 PM, Simon Peyton Jones
wrote:
> I'm all for it, if the broader community (e.g. the developers of those
> packages) are ok.
>
> Simon
>
> | -Original Message-
> | From: ghc-devs
These responses are helpful, thanks.
Is there a primer for how to read the output? Or a small function that produces
the output that I could quickly reverse engineer?
There is a suggestion to look at the core before and after my patch. Is there a
certain phase I should look at? What should I
2015-11-29 21:42 GMT+01:00 Edward Z. Yang :
> [...] If the messages are bothersome, we could setup Cabal to not print out
> fields if it knows that GHC doesn't support them.
>
I would very much appreciate that, especially given the fact that "old
versions of GHC" include GHC HEAD