Perhaps #10317 is related?
https://ghc.haskell.org/trac/ghc/ticket/10317
You might try building with the latest ghc-7.10 branch.
On Wed, Jun 3, 2015 at 12:27 AM, Evan Laforge wrote:
> On Tue, Jun 2, 2015 at 7:20 PM, Carter Schonwald
> wrote:
>> could you share a minimal program that reproduces
>From https://github.com/ghc/ghc/blob/master/rts/RtsFlags.c#L1238 it seems that
>the behavior described in my email below is intended:
```
if (rts_argv[arg][2] == '\0') {
#if defined(PROFILING)
RtsFlags.ParFlags.nNodes = 1;
#else
RtsFlags.P
On Jun 2, 2015 6:03 PM, "Wolfgang Jeltsch"
wrote:
>
> Hi,
>
> bug #10009 appears on the status page with status “new”, although the
> bug should have been fixed in HEAD. Can this fix *please* be a part of
> GHC 7.10.2? At the moment, this bug breaks the incremental-computing
> package in a nontriv
On Tue, Jun 2, 2015 at 7:20 PM, Carter Schonwald
wrote:
> could you share a minimal program that reproduces the problem?
That's the thing, it's a thousand line shakefile that builds a 100k
line program, and it's happening only rarely now. Since it happens so
rarely it seems really difficult to p
Hi,
The behavior of the -N flag (without argument) with the profiling runtime seems
inconsistent compared to the behavior without profiling. The following program
```
module Main where
import GHC.Conc
main :: IO ()
main = print numCapabilities
```
when compiled with `ghc -threaded -fforce-rec
could you share a minimal program that reproduces the problem?
On Tue, Jun 2, 2015 at 9:36 PM, Evan Laforge wrote:
> After I upgraded to 7.10.1 I started noticing that my shakefile would
> lock up on exit. It's after the 'main' function exits, and none of
> the shake tests have a problem, so pr
After I upgraded to 7.10.1 I started noticing that my shakefile would
lock up on exit. It's after the 'main' function exits, and none of
the shake tests have a problem, so presumably it's a GHC thing, that
shake somehow causes to happen. Only kill -9 gets it to quit. Here's
a stack trace from th
Hi,
bug #10009 appears on the status page with status “new”, although the
bug should have been fixed in HEAD. Can this fix *please* be a part of
GHC 7.10.2? At the moment, this bug breaks the incremental-computing
package in a nontrivial way (and I think it breaks HList too).
All the best,
Wolfga
Hi Adam,
yes, this seems to be the same bug.
I just annotated ticket #10009. I hope the fix will make it into
GHC 7.10.2.
Can anyone say when GHC 7.10.2 will be released approximately?
All the best,
Wolfgang
Am Dienstag, den 02.06.2015, 13:00 -0400 schrieb adam vogt:
> Hi Wolfgang,
>
>
> htt
Hi *,
I've just finished merging all the latest patches for GHC 7.10.2 into
the STABLE branch. All in all, we've fixed a lot of bugs (over 80
tickets closed)!
So, we'll probably be doing a 7.10.2 release here in a few weeks. The
tentative plan was around the 14th, although it's not set in stone.
Hi Wolfgang,
https://ghc.haskell.org/trac/ghc/ticket/10009 might be the same regression
(fixed in HEAD)
Regards,
Adam
On Tue, Jun 2, 2015 at 12:28 PM, Wolfgang Jeltsch <
g9ks1...@acme.softbase.org> wrote:
> Hi,
>
> the following (contrived) code is accepted by GHC 7.8.3, but not 7.10.1:
>
> > {
Hi,
that's an interesting example. To me this looks like a bug in GHC,
although the issue is certainly a bit subtle.
The reason I think it is a bug is that, if we name all the type functions
in the signature and apply improvements using the fact that we are working
with functions, then we get:
Hi,
the following (contrived) code is accepted by GHC 7.8.3, but not 7.10.1:
> {-# LANGUAGE TypeFamilies #-}
>
> type family F a :: *
>
> type family G b :: *
>
> x :: G (F a) ~ a => F a
> x = undefined
GHC 7.10.1 reports:
> Could not deduce (F a0 ~ F a)
> from the context (G (F a) ~ a)
>
We went round and round on this back in August.
The ultimate decision was to leave the existing behavior for quot and div
as sufficient consensus for changing it was not reached.
I've updated the ticket in question to reflect that resolution.
-Edward
On Mon, Jun 1, 2015 at 6:40 PM, Nikita Karet
The current behavior is quite intentional.
On Mon, Jun 1, 2015 at 1:23 PM, David Feuer wrote:
> I think this is a mistake, yes. They should not raise such exceptions, but
> rather just wrap around—minBound `quot` (-1) should be -minBound=minBound.
> That would justify the behavior of rem and mod
15 matches
Mail list logo
