Thanks for having the patience to read through my code! That's exactly
what I was missing. I did print out the return value in my debug code at
some point, but the prettyprinter only shows the suffix of the
dictionary variable without the rhs so I totally missed it.
Also, I noticed that
Simon Peyton Jones via ghc-devs writes:
> Ben
>
> This sounds like a good decision to me, thanks.
>
> Is there a possibility to have a slow CI-on-windows job (not part of
> the "this must pass before merging" step), which will slowly, but
> reliably, fail if the Windows build fails. E.g. does it
Ben
This sounds like a good decision to me, thanks.
Is there a possibility to have a slow CI-on-windows job (not part of the "this
must pass before merging" step), which will slowly, but reliably, fail if the
Windows build fails. E.g. does it help to make the build be 100% sequential?
Or is
Hi everyone,
After multiple weeks of effort struggling to get Windows CI into a stable
condition I'm sorry to say that we're going to need to revert to
allowing it to fail for a bit longer. The status quo is essentially
holding up the entire merge queue and we still seem quite far from
resolving
Sorry if this bothered you, I have problem sending email to the list,
sending this for bgamari to further diagnostic the situation.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> Did you try it on the code I sent or did you use some other test case?
I tried your code.
It's still possible that this is an application bug, of course (maybe in one of
the dependencies, if not in your application).
> Is there a test-suite in GHC that stresses the threaded runtime?
Some of
Ok, I will file an issue. I just wanted to rule out any application level
issues first. Did you try it on the code I sent or did you use some other
test case? Is there a test-suite in GHC that stresses the threaded runtime?
-harendra
On Mon, 3 Feb 2020 at 14:09, Ömer Sinan Ağacan wrote:
> In
In your code (elabRnExpr) you have
_ <- perhaps_disable_default_warnings $ simplifyInteractive residual
You’ll notice that
simplifyInteractive :: WantedConstraints -> TcM (Bag EvBind)
So you are discarding the “evidence bindings” returned by simplifyInteractive.
Those are precisely the
Jurriaan,
It would be good to dig out the patches that affect packages without which GHC
cannot build. (E.g. haskeline.) Would that take long? You have them
already... It doesn't have to be perfect or git-tracked; just send a patch
file in an email. I'm just trying to avoid re-inventing
In that case it'd be good to move the discussion to Gitlab. Could you file an
issue?
I was able to reproduce on GHC HEAD. With debug runtime I consistently get this
assertion error:
internal error: ASSERTION FAILED: file rts/Messages.c, line 95
(GHC version 8.11.0.20200201 for
10 matches
Mail list logo
