From george.colpitts at gmail.com  Sat Nov  1 12:05:29 2014
From: george.colpitts at gmail.com (George Colpitts)
Date: Sat, 1 Nov 2014 09:05:29 -0300
Subject: Proposal: Improving the LLVM backend by packaging it
Message-ID: <CAB-d4A5QGNP9gWKKDh+824jgc6Wk7tjXeV90k0VvSeS=vt-AYw@mail.gmail.com>

I think this is a great idea. My understanding from the wiki page is that
the full plan involves:


   1. We need to *fix compatibility with recent LLVM versions*. This really
   sucks for users. *Ben Gamari* is working on this, see #9142
   <https://ghc.haskell.org/trac/ghc/ticket/9142> and ?Phab:D155
   <https://phabricator.haskell.org/D155>
   2. We need to fix up the LLVM IR generation in GHC, and fix the compiler
   driver to invoke the tools with a better set of optimizations. *Nathan
   Howell* has been wrangled into looking into this.
   3. We need to ship a pre-built version of LLVM for developers and users,
   and put them in binary distributions for major platforms. *Austin Seipp*
   could handle this.
   4. We can fix other bugs, like LLVM -split-obj support, which opens the
   way to shipping GHC with LLVM-optimized base libraries. *Reid Barton*
   expressed some interest in this.

I assume that 1. will come with 7.10.1. Is there any way we could do 3. in
one of the 7.10 releases before 7.12.1?

Basing this question on Austin's words "we *only* need opt and llc, so the
distributions can be tiny. " and "it's not actually very complicated to
implement or support, I think." :) I guess it might be more difficult than
I think but I thought it was worth asking the question as I believe 3. on
its own is worthwhile and would hopefully simplify support for LLVM in GHC.

Thanks
George

On Fri, Oct 24, 2014 at 8:52 PM, Austin Seipp <austin at well-typed.com> wrote:

> Hi *,
>
> A few days ago a discussion on IRC occurred about the LLVM backend,
> its current status, and what we could do to make it a rock solid part
> of GHC for all our users.
>
> Needless to say, the situation right now isn't so hot: we have no
> commitment to version support, two major versions are busted, others
> are seriously buggy, and yet there are lots of things we could improve
> on.
>
> So I give you a proposal, from a few of us to you all, about improving it:
>
> https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend
>
> I won't repeat what's on the wiki page too much, but the TL;DR version
> is: we should start packaging a version of LLVM, and shipping it with
> e.g. binary distributions of GHC. It's just a lot better for everyone.
>
> I know we're normally fairly hesitant about things like this (shipping
> external dependencies), but I think it's the only sane thing to do
> here, and the situation is fairly unique in that it's not actually
> very complicated to implement or support, I think.
>
> We'd like to do this for 7.12. I've also wrangled some people to help.
> Those people know who they are (because they're CC'd), and I will now
> badger them into submission until it is fixed for 7.12.
>
> Please let me know what you think.
>
> PS. Joachim, I would be particularly interested in upstream needs for
> Debian, as I know of their standard packaging policy to not duplicate
> things.
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141101/2173f9e1/attachment.html>

From ggreif at gmail.com  Sat Nov  1 14:21:59 2014
From: ggreif at gmail.com (Gabor Greif)
Date: Sat, 1 Nov 2014 15:21:59 +0100
Subject: [commit: ghc] wip/T9705: Add test case for T9705 (1cca652)
In-Reply-To: <20141101111509.50D2A3A300@ghc.haskell.org>
References: <20141101111509.50D2A3A300@ghc.haskell.org>
Message-ID: <CAK-hX0mF8+GKNJ5A4J4cF5jetvz=MMm9vZBwZBempk2eUAcoSA@mail.gmail.com>

Hello Gerg?,

you seem to test pattern synonyms in _class_ declarations here. Would
it make sense to also test _instance_ declarations?

Cheers,

    Gabor

On 11/1/14, git at git.haskell.org <git at git.haskell.org> wrote:
> Repository : ssh://git at git.haskell.org/ghc
>
> On branch  : wip/T9705
> Link       :
> http://ghc.haskell.org/trac/ghc/changeset/1cca652e8d4a8b87daf70bded87cddc39d973dab/ghc
>
>>---------------------------------------------------------------
>
> commit 1cca652e8d4a8b87daf70bded87cddc39d973dab
> Author: Dr. ERDI Gergo <gergo at erdi.hu>
> Date:   Tue Oct 21 20:51:55 2014 +0800
>
>     Add test case for T9705
>
>
>>---------------------------------------------------------------
>
> 1cca652e8d4a8b87daf70bded87cddc39d973dab
>  testsuite/tests/patsyn/should_fail/T9705.hs     | 3 +++
>  testsuite/tests/patsyn/should_fail/T9705.stderr | 4 ++++
>  testsuite/tests/patsyn/should_fail/all.T        | 1 +
>  3 files changed, 8 insertions(+)
>
> diff --git a/testsuite/tests/patsyn/should_fail/T9705.hs
> b/testsuite/tests/patsyn/should_fail/T9705.hs
> new file mode 100644
> index 0000000..54d1d00
> --- /dev/null
> +++ b/testsuite/tests/patsyn/should_fail/T9705.hs
> @@ -0,0 +1,3 @@
> +{-# LANGUAGE PatternSynonyms #-}
> +class C a where
> +    pattern P = ()
> diff --git a/testsuite/tests/patsyn/should_fail/T9705.stderr
> b/testsuite/tests/patsyn/should_fail/T9705.stderr
> new file mode 100644
> index 0000000..d9a3a49
> --- /dev/null
> +++ b/testsuite/tests/patsyn/should_fail/T9705.stderr
> @@ -0,0 +1,4 @@
> +
> +T9705.hs:3:5:
> +    Pattern synonyms not allowed in instance declarations
> +      pattern P = ()
> diff --git a/testsuite/tests/patsyn/should_fail/all.T
> b/testsuite/tests/patsyn/should_fail/all.T
> index bff6bdf..298f23b 100644
> --- a/testsuite/tests/patsyn/should_fail/all.T
> +++ b/testsuite/tests/patsyn/should_fail/all.T
> @@ -6,3 +6,4 @@ test('T8961', normal, multimod_compile_fail, ['T8961',''])
>  test('as-pattern', normal, compile_fail, [''])
>  test('T9161-1', normal, compile_fail, [''])
>  test('T9161-2', normal, compile_fail, [''])
> +test('T9705', normal, compile_fail, [''])
>
> _______________________________________________
> ghc-commits mailing list
> ghc-commits at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits
>

From jessica.l.hamilton at gmail.com  Sat Nov  1 14:36:08 2014
From: jessica.l.hamilton at gmail.com (Jessica Hamilton)
Date: Sun, 2 Nov 2014 03:36:08 +1300
Subject: Porting to Haiku
Message-ID: <CABCZxrBDFiOpAPYJEpF46b4E7=TfRKatJDx52WbTdWVNsgxNjQ@mail.gmail.com>

Hi,

I (and one other) am working on porting GHC to Haiku; we've
successfully got a working GHC cross-compiler running on Haiku, and
now are able to also build GHC on Haiku from the cross-compiler when
using the "quickest" profile in the mk/build.mk file.

However, using the default build profile, we're running into a couple of issues.

1. A random segfault in ghc-stage1 (is probably an issue in Haiku, not
entirely sure yet), with the following call stack:
runCFinalizers + 0x3a
runAllCFinalizers + 0x37
hs_exit_ +0x99
shutdownHaskellAndExit + 0x2f
hs_main + 0xb1
.../ghc-7.8.3/inplace/lib/bin/ghc-stage1 + 0xc7b374
_start + 0x4b
runtime_loader + 0x130

I can't really see anything obvious in the source code myself
(although our debugger fails to enumerate the semaphores, and also
needs to be killed). Restarting the build is sufficient to get past
the issue, however.

2. A more pressing issue is with ghc-cabal. It fails with the error
"resource exhausted" when running the following command:
inplace/bin/ghc-cabal copy compiler stage2

This error is reproducible every time. I've tried setting up a profile
build in the mk/build.mk file in order to get a stack trace from
ghc-cabal; however, after rebuilding GHC from scratch, running
ghc-cabal +RTS -xc, it still complains that the flag -xc requires the
program to be built with -prof.

Some advice would be handy before diving into another couple hours of
rebuilding GHC to try and get a profiled build of ghc-cabal out of the
build system ;-)

Cheers,
Jessica

From bgamari.foss at gmail.com  Sat Nov  1 15:43:51 2014
From: bgamari.foss at gmail.com (Ben Gamari)
Date: Sat, 01 Nov 2014 11:43:51 -0400
Subject: Proposal: Improving the LLVM backend by packaging it
In-Reply-To: <CAEs96n3CrBJT1893q8QvmfRd_WOYTFG6vvEEs2kEt9BMKaUdfQ@mail.gmail.com>
References: <CAEs96n3CrBJT1893q8QvmfRd_WOYTFG6vvEEs2kEt9BMKaUdfQ@mail.gmail.com>
Message-ID: <87y4rvhqo8.fsf@gmail.com>

Austin Seipp <austin at well-typed.com> writes:

> Hi *,
>
> A few days ago a discussion on IRC occurred about the LLVM backend,
> its current status, and what we could do to make it a rock solid part
> of GHC for all our users.
>
> Needless to say, the situation right now isn't so hot: we have no
> commitment to version support, two major versions are busted, others
> are seriously buggy, and yet there are lots of things we could improve
> on.
>
> So I give you a proposal, from a few of us to you all, about improving it:
>
> https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend
>
I'm certainly not opposed to this idea and there is precedent in this
area set by the Rust folks. That being said, I suspect some
distributions may care pretty deeply about being able to compile against
their own LLVM packaging, especially if they are already shipping the
same LLVM version as we require. It would be really nice to hear your
thoughts on this, Joachim.

Do you envision that LLVM always be built alongside GHC when bringing up
a new working tree? I suppose there will also be a "make fetch-llvm"
rule to grab a compatible binary snapshot from an archive
for bringing up builds on small machines (presumably these could be
built at least for the first-tier platforms?)

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141101/18f31c37/attachment.sig>

From mail at joachim-breitner.de  Sat Nov  1 15:58:40 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 01 Nov 2014 16:58:40 +0100
Subject: Proposal: Improving the LLVM backend by packaging it
In-Reply-To: <87y4rvhqo8.fsf@gmail.com>
References: <CAEs96n3CrBJT1893q8QvmfRd_WOYTFG6vvEEs2kEt9BMKaUdfQ@mail.gmail.com>
 <87y4rvhqo8.fsf@gmail.com>
Message-ID: <1414857520.12004.1.camel@joachim-breitner.de>

Hi,


Am Samstag, den 01.11.2014, 11:43 -0400 schrieb Ben Gamari:
> I'm certainly not opposed to this idea and there is precedent in this
> area set by the Rust folks. That being said, I suspect some
> distributions may care pretty deeply about being able to compile against
> their own LLVM packaging, especially if they are already shipping the
> same LLVM version as we require. It would be really nice to hear your
> thoughts on this, Joachim.

it would be nice if we would not have to do this, but if LLVM does not
provide a stable enough interface I see the technical need for it.

I asked the stakeholders in Debian for optinions? but only got one reply
from the LLVM maintainer, saying:

> Obviously, I don't really like code duplication on a project like LLVM.
> Especially since it seems like a fork.
> 
> If upstream goes this way (and I agree that it is going to be hard for the Debian
> maintainer of ghc to go against that), it is going to be hard for the maintainer,
> especially if there is no plan to sync LLVM from time to time (if they do,
> well, you should be quite fine, LLVM is not super hard to maintain and we
> can always exchange info).
> 
> However, I think upstream (ghc) should try to work more closely with LLVM and find a better
> way to collaborate. Having patches applied in LLVM itself is simple and usually
> fast.
> 
> BTW, there are discussion on LLVM mailing list on this topic.
> 
> So, I am not going to give a green or red light. I don't think this is going
> to affect my work... Mostly, it is going to affect yours.


So the Debian packaging will just follow whatever upstream does here.

Greetings,
Joachim

? https://lists.debian.org/debian-haskell/2014/10/msg00017.html



-- 
Joachim Breitner
  e-Mail: mail at joachim-breitner.de
  Homepage: http://www.joachim-breitner.de
  Jabber-ID: nomeata at joachim-breitner.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141101/0a4cc47a/attachment.sig>

From austin at well-typed.com  Sat Nov  1 16:05:16 2014
From: austin at well-typed.com (Austin Seipp)
Date: Sat, 1 Nov 2014 11:05:16 -0500
Subject: Proposal: Improving the LLVM backend by packaging it
In-Reply-To: <87y4rvhqo8.fsf@gmail.com>
References: <CAEs96n3CrBJT1893q8QvmfRd_WOYTFG6vvEEs2kEt9BMKaUdfQ@mail.gmail.com>
 <87y4rvhqo8.fsf@gmail.com>
Message-ID: <CAEs96n2Lu-Q8qVPDEoA5L2tZiMf3vK98rV8afsMZJM5s6QZf6A@mail.gmail.com>

On Sat, Nov 1, 2014 at 10:43 AM, Ben Gamari <bgamari.foss at gmail.com> wrote:
> Austin Seipp <austin at well-typed.com> writes:
>
>> Hi *,
>>
>> A few days ago a discussion on IRC occurred about the LLVM backend,
>> its current status, and what we could do to make it a rock solid part
>> of GHC for all our users.
>>
>> Needless to say, the situation right now isn't so hot: we have no
>> commitment to version support, two major versions are busted, others
>> are seriously buggy, and yet there are lots of things we could improve
>> on.
>>
>> So I give you a proposal, from a few of us to you all, about improving it:
>>
>> https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend
>>
> I'm certainly not opposed to this idea and there is precedent in this
> area set by the Rust folks. That being said, I suspect some
> distributions may care pretty deeply about being able to compile against
> their own LLVM packaging, especially if they are already shipping the
> same LLVM version as we require. It would be really nice to hear your
> thoughts on this, Joachim.

Yes, this is a worry of mine too.

> Do you envision that LLVM always be built alongside GHC when bringing up a new working tree?

No - on Tier 1 platforms, I suggest we always provide binary packages
for developers to grab. Those same binaries would be shipped with the
actual binary distributions we create.

On Tier 2 platforms, people may have to compile things, but we can
provide some guidelines (and perhaps utilities/scripts) to help manage
this.

> I suppose there will also be a "make fetch-llvm"
> rule to grab a compatible binary snapshot from an archive
> for bringing up builds on small machines (presumably these could be
> built at least for the first-tier platforms?)

Yes, something like that is what I envisioned (a make target or a shell script).

> Cheers,
>
> - Ben



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From mail at joachim-breitner.de  Sat Nov  1 16:12:21 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 01 Nov 2014 17:12:21 +0100
Subject: Proposal: Improving the LLVM backend by packaging it
In-Reply-To: <CAEs96n2Lu-Q8qVPDEoA5L2tZiMf3vK98rV8afsMZJM5s6QZf6A@mail.gmail.com>
References: <CAEs96n3CrBJT1893q8QvmfRd_WOYTFG6vvEEs2kEt9BMKaUdfQ@mail.gmail.com>
 <87y4rvhqo8.fsf@gmail.com>
 <CAEs96n2Lu-Q8qVPDEoA5L2tZiMf3vK98rV8afsMZJM5s6QZf6A@mail.gmail.com>
Message-ID: <1414858341.12004.6.camel@joachim-breitner.de>

Hi,

Am Samstag, den 01.11.2014, 11:05 -0500 schrieb Austin Seipp:
> > Do you envision that LLVM always be built alongside GHC when bringing up a new working tree?
> 
> No - on Tier 1 platforms, I suggest we always provide binary packages
> for developers to grab. Those same binaries would be shipped with the
> actual binary distributions we create.
> 
> On Tier 2 platforms, people may have to compile things, but we can
> provide some guidelines (and perhaps utilities/scripts) to help manage
> this.

for the Distributions it would be most easy if the custom llvm would
come within the source tarball, would be built by the regular build
process and installed along with GHC, in a private path
(/usr/lib/ghc/somewhere). We certainly don?t want to have a separate
packaging with separate binary packages "llvm-ghc" around.

How long does building those two llvm binaries take? If it is
sufficiently quick, maybe that would be a suitable distribution for
developers as well, and avoids having to separately build, distribute,
download, and install the binaries.

Greetings,
Joachim


-- 
Joachim Breitner
  e-Mail: mail at joachim-breitner.de
  Homepage: http://www.joachim-breitner.de
  Jabber-ID: nomeata at joachim-breitner.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141101/072c6489/attachment.sig>

From austin at well-typed.com  Sat Nov  1 16:21:40 2014
From: austin at well-typed.com (Austin Seipp)
Date: Sat, 1 Nov 2014 11:21:40 -0500
Subject: Proposal: Improving the LLVM backend by packaging it
In-Reply-To: <1414857520.12004.1.camel@joachim-breitner.de>
References: <CAEs96n3CrBJT1893q8QvmfRd_WOYTFG6vvEEs2kEt9BMKaUdfQ@mail.gmail.com>
 <87y4rvhqo8.fsf@gmail.com>
 <1414857520.12004.1.camel@joachim-breitner.de>
Message-ID: <CAEs96n3GKA13JTeUUzv3mQLAEgMpofy+6KtPetgrfa0RscJJtA@mail.gmail.com>

Joachim, thanks for the forward and discussion.

Just to rehash two points for the people reading at home:

 - I *do not* want to ship GHC specific patches to LLVM in the builds
we use, anymore than anyone else does. I don't have any plans or even
patches I would apply right now. A stock LLVM is ideal - one that's
just been picked to work well by us. Even if it has some bugs or
workarounds are needed, that's probably OK.

 - If any patches _are_ needed, I'd of course like to get upstream to
accept them ASAP so they can make it into a stable release. I don't
want to maintain a patchset forever, and nobody else does either. And
I've found the LLVM developers very helpful/reasonable when submitting
patches in the past, so I imagine this will be the way we go.

I think the problem with patches, really, isn't getting them accepted
(which is easy) or even writing them (which is also sometimes pretty
easy) - it's that we have limited effort and developer time to
dedicate to this at all. We already have limited GHC hackers - the
intersection of GHC *and* LLVM hackers is even smaller.

I'd love to work more with LLVM upstream to fix problems... but the
time to do so is pretty limited for most of us, I think, and the
current backend has real issues in the design that cooperation just
can't fundamentally fix - cooperation can't fix the fact a new release
may change IR semantics and break existing GHC releases, for example.
Users will simply suffer from that. And some of those changes may not
be totally trivial to accommodate (as Ben's recent work shows).

In terms of synchronization, GHC has a 1yr release vs LLVM's 6 month
release. It seems reasonable to upgrade once a year or so to match a
newer LLVM.


On Sat, Nov 1, 2014 at 10:58 AM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Hi,
>
>
> Am Samstag, den 01.11.2014, 11:43 -0400 schrieb Ben Gamari:
>> I'm certainly not opposed to this idea and there is precedent in this
>> area set by the Rust folks. That being said, I suspect some
>> distributions may care pretty deeply about being able to compile against
>> their own LLVM packaging, especially if they are already shipping the
>> same LLVM version as we require. It would be really nice to hear your
>> thoughts on this, Joachim.
>
> it would be nice if we would not have to do this, but if LLVM does not
> provide a stable enough interface I see the technical need for it.
>
> I asked the stakeholders in Debian for optinions? but only got one reply
> from the LLVM maintainer, saying:
>
>> Obviously, I don't really like code duplication on a project like LLVM.
>> Especially since it seems like a fork.
>>
>> If upstream goes this way (and I agree that it is going to be hard for the Debian
>> maintainer of ghc to go against that), it is going to be hard for the maintainer,
>> especially if there is no plan to sync LLVM from time to time (if they do,
>> well, you should be quite fine, LLVM is not super hard to maintain and we
>> can always exchange info).
>>
>> However, I think upstream (ghc) should try to work more closely with LLVM and find a better
>> way to collaborate. Having patches applied in LLVM itself is simple and usually
>> fast.
>>
>> BTW, there are discussion on LLVM mailing list on this topic.
>>
>> So, I am not going to give a green or red light. I don't think this is going
>> to affect my work... Mostly, it is going to affect yours.
>
>
> So the Debian packaging will just follow whatever upstream does here.
>
> Greetings,
> Joachim
>
> ? https://lists.debian.org/debian-haskell/2014/10/msg00017.html
>
>
>
> --
> Joachim Breitner
>   e-Mail: mail at joachim-breitner.de
>   Homepage: http://www.joachim-breitner.de
>   Jabber-ID: nomeata at joachim-breitner.de
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From austin at well-typed.com  Sat Nov  1 16:26:26 2014
From: austin at well-typed.com (Austin Seipp)
Date: Sat, 1 Nov 2014 11:26:26 -0500
Subject: Proposal: Improving the LLVM backend by packaging it
In-Reply-To: <1414858341.12004.6.camel@joachim-breitner.de>
References: <CAEs96n3CrBJT1893q8QvmfRd_WOYTFG6vvEEs2kEt9BMKaUdfQ@mail.gmail.com>
 <87y4rvhqo8.fsf@gmail.com>
 <CAEs96n2Lu-Q8qVPDEoA5L2tZiMf3vK98rV8afsMZJM5s6QZf6A@mail.gmail.com>
 <1414858341.12004.6.camel@joachim-breitner.de>
Message-ID: <CAEs96n3yQ7rcscy16AOqe_cBgc5wTexsc_oZNikqCqBAaf-KqQ@mail.gmail.com>

On Sat, Nov 1, 2014 at 11:12 AM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Hi,
>
> Am Samstag, den 01.11.2014, 11:05 -0500 schrieb Austin Seipp:
>> > Do you envision that LLVM always be built alongside GHC when bringing up a new working tree?
>>
>> No - on Tier 1 platforms, I suggest we always provide binary packages
>> for developers to grab. Those same binaries would be shipped with the
>> actual binary distributions we create.
>>
>> On Tier 2 platforms, people may have to compile things, but we can
>> provide some guidelines (and perhaps utilities/scripts) to help manage
>> this.
>
> for the Distributions it would be most easy if the custom llvm would
> come within the source tarball, would be built by the regular build
> process and installed along with GHC, in a private path
> (/usr/lib/ghc/somewhere). We certainly don?t want to have a separate
> packaging with separate binary packages "llvm-ghc" around.

Yes, that seems like a reasonable desire.

If we do this, my plan was actually to mirror a copy of the llvm git
repository (an official one is maintained by llvm.org) to
git.haskell.org, which is where we would base our own builds off of.

We could certainly let source distributions build their own copy.

> How long does building those two llvm binaries take? If it is
> sufficiently quick, maybe that would be a suitable distribution for
> developers as well, and avoids having to separately build, distribute,
> download, and install the binaries.

In practice it takes a while... I haven't timed it, but I'd guess on
average it adds about 30-40 minutes for most people just to build
llvm. I'm not sure how many things we can disable to make the build
faster, but I'd ballpark it at half an hour at best (it's a few
thousand source files, after all).

This would mostly hurt if you cleaned up the tree later (e.g. 'make
distclean'), which I do rather frequently in order to get a pristine
build tree.

> Greetings,
> Joachim
>
>
> --
> Joachim Breitner
>   e-Mail: mail at joachim-breitner.de
>   Homepage: http://www.joachim-breitner.de
>   Jabber-ID: nomeata at joachim-breitner.de
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From mail at joachim-breitner.de  Sat Nov  1 16:47:47 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 01 Nov 2014 17:47:47 +0100
Subject: Proposal: Improving the LLVM backend by packaging it
In-Reply-To: <CAEs96n3yQ7rcscy16AOqe_cBgc5wTexsc_oZNikqCqBAaf-KqQ@mail.gmail.com>
References: <CAEs96n3CrBJT1893q8QvmfRd_WOYTFG6vvEEs2kEt9BMKaUdfQ@mail.gmail.com>
 <87y4rvhqo8.fsf@gmail.com>
 <CAEs96n2Lu-Q8qVPDEoA5L2tZiMf3vK98rV8afsMZJM5s6QZf6A@mail.gmail.com>
 <1414858341.12004.6.camel@joachim-breitner.de>
 <CAEs96n3yQ7rcscy16AOqe_cBgc5wTexsc_oZNikqCqBAaf-KqQ@mail.gmail.com>
Message-ID: <1414860467.12004.11.camel@joachim-breitner.de>

Hi,


Am Samstag, den 01.11.2014, 11:26 -0500 schrieb Austin Seipp:
> > How long does building those two llvm binaries take? If it is
> > sufficiently quick, maybe that would be a suitable distribution for
> > developers as well, and avoids having to separately build, distribute,
> > download, and install the binaries.
> 
> In practice it takes a while... I haven't timed it, but I'd guess on
> average it adds about 30-40 minutes for most people just to build
> llvm. I'm not sure how many things we can disable to make the build
> faster, but I'd ballpark it at half an hour at best (it's a few
> thousand source files, after all).
> 
> This would mostly hurt if you cleaned up the tree later (e.g. 'make
> distclean'), which I do rather frequently in order to get a pristine
> build tree.

yes, me too. Which means that we?d have to go through the trouble of
distributing binaries...

But then: Do GHC developers actually need the LLVM binaries (unless they
want to test the llvm backend, of course)?

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141101/3b610e35/attachment.sig>

From bgamari.foss at gmail.com  Sat Nov  1 17:31:29 2014
From: bgamari.foss at gmail.com (Ben Gamari)
Date: Sat, 01 Nov 2014 13:31:29 -0400
Subject: Proposal: Improving the LLVM backend by packaging it
In-Reply-To: <CAEs96n3GKA13JTeUUzv3mQLAEgMpofy+6KtPetgrfa0RscJJtA@mail.gmail.com>
References: <CAEs96n3CrBJT1893q8QvmfRd_WOYTFG6vvEEs2kEt9BMKaUdfQ@mail.gmail.com>
 <87y4rvhqo8.fsf@gmail.com> <1414857520.12004.1.camel@joachim-breitner.de>
 <CAEs96n3GKA13JTeUUzv3mQLAEgMpofy+6KtPetgrfa0RscJJtA@mail.gmail.com>
Message-ID: <87r3xmj09a.fsf@gmail.com>


Austin Seipp <austin at well-typed.com> writes:

> Joachim, thanks for the forward and discussion.
>
> Just to rehash two points for the people reading at home:
>
>  - I *do not* want to ship GHC specific patches to LLVM in the builds
> we use, anymore than anyone else does. I don't have any plans or even
> patches I would apply right now. A stock LLVM is ideal - one that's
> just been picked to work well by us. Even if it has some bugs or
> workarounds are needed, that's probably OK.
>
I agree. Shipping a known-stable LLVM is one thing; patching our own
LLVM is quite another. Patching LLVM should be avoided if at all
possible. Thankfully LLVM is quite modular so this shouldn't be so
difficult.

[snip]

> I'd love to work more with LLVM upstream to fix problems... but the
> time to do so is pretty limited for most of us, I think, and the
> current backend has real issues in the design that cooperation just
> can't fundamentally fix - cooperation can't fix the fact a new release
> may change IR semantics and break existing GHC releases, for example.
> Users will simply suffer from that. And some of those changes may not
> be totally trivial to accommodate (as Ben's recent work shows).
>
While this is technically true I wonder whether IR changes will be a
persistent problem going forward. I don't have a deep knowledge of the
history of the LLVM IR but my impression is that the maintainers are
fairly deliberate in their consideration of sematic changes (despite the
arguable `symbol_offset` and `prefix_data` mis-step in 3.5). The alias
change was an unexpected turn but frankly our previous use of aliases
was a bit odd and was never supposed to work in the first place
(something is amiss when you are relying on the optimizer to elide
aliases to produce valid code).

The alias rework and (hopefully) upcoming TNTC rework make me optimistic
that our use of LLVM moving closer to how the interfaces are designed to
be used. Hopefully this will be accompanied by a corresponding
improvement in maintainability.

There are other reasons besides IR instability that we might want to
distribute our own LLVM. These might include,

 * Decoupling GHC from changes in LLVM's optimization passes

 * Wanting to ship own optimization passes that need to link against
   LLVM.

 * Wanting to use a library like llvm-general in GHC
   
 * Wanting to use leverage related libraries such as Polly

I'm not sure how these weigh against the maintenance and packaging costs
of shipping our own LLVM.  I've not seen evidence that changes in LLVM's
optimizer have hurt us in the past; then again if we are going to be
more selective about which optimizations we ask LLVM to perform perhaps
this will become a bigger concern in the future.

Shipping our own passes would be great and is probably necessary to
continue to improve performance. It not clear whether LLVM's analysis
pass interface is stable enough to facilitate this without shipping our
own LLVM. Max's analysis is now three years old; I'll try dusting off
the code and see how bad the damage is.

It's not clear to me that we really want to add a dependency on another
library to GHC. Being able to leverage things like Polly sounds tempting
but adding another moving part to LlvmGen will likely incur a
maintenance cost. Moreover, the fact that there still isn't a
llvm-general release targeting LLVM 3.5 is a bit worrying.

As a quite note, I spoke briefly with a few Rustaceans and they report
that they were hoping to ultimately avoid shipping an LLVM with
rustc. At this point Rust doesn't have an active packaging effort so
perhaps the rustc precedent isn't as useful as I originally thought.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141101/1a5fe5b3/attachment.sig>

From bgamari.foss at gmail.com  Sat Nov  1 17:38:56 2014
From: bgamari.foss at gmail.com (Ben Gamari)
Date: Sat, 01 Nov 2014 13:38:56 -0400
Subject: Proposal: Improving the LLVM backend by packaging it
In-Reply-To: <CAEs96n2Lu-Q8qVPDEoA5L2tZiMf3vK98rV8afsMZJM5s6QZf6A@mail.gmail.com>
References: <CAEs96n3CrBJT1893q8QvmfRd_WOYTFG6vvEEs2kEt9BMKaUdfQ@mail.gmail.com>
 <87y4rvhqo8.fsf@gmail.com>
 <CAEs96n2Lu-Q8qVPDEoA5L2tZiMf3vK98rV8afsMZJM5s6QZf6A@mail.gmail.com>
Message-ID: <87oasqizwv.fsf@gmail.com>

Austin Seipp <austin at well-typed.com> writes:

> On Sat, Nov 1, 2014 at 10:43 AM, Ben Gamari <bgamari.foss at gmail.com> wrote:
>>
>> I'm certainly not opposed to this idea and there is precedent in this
>> area set by the Rust folks. That being said, I suspect some
>> distributions may care pretty deeply about being able to compile against
>> their own LLVM packaging, especially if they are already shipping the
>> same LLVM version as we require. It would be really nice to hear your
>> thoughts on this, Joachim.
>
> Yes, this is a worry of mine too.
>
>> Do you envision that LLVM always be built alongside GHC when bringing
>> up a new working tree?
>
> No - on Tier 1 platforms, I suggest we always provide binary packages
> for developers to grab. Those same binaries would be shipped with the
> actual binary distributions we create.
>
Good. That would greatly improve the ease-of-building. That being said,
we'll also need to have logic in the build system to build LLVM from
source as the Debian packaging guidelines prohibit the packaging rules
From downloading binaries, IIRC. Unfortunately my cursory look didn't
turn up any language in the packaging policy[1] to support this.

> On Tier 2 platforms, people may have to compile things, but we can
> provide some guidelines (and perhaps utilities/scripts) to help manage
> this.
>
Good, I suppose the Debian packaging could just use these.

Cheers,

- Ben


[1] https://www.debian.org/doc/debian-policy/ch-source.html#s-standardsversion

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141101/9f579d4d/attachment-0001.sig>

From bgamari.foss at gmail.com  Sat Nov  1 17:43:35 2014
From: bgamari.foss at gmail.com (Ben Gamari)
Date: Sat, 01 Nov 2014 13:43:35 -0400
Subject: Proposal: Improving the LLVM backend by packaging it
In-Reply-To: <CAEs96n3yQ7rcscy16AOqe_cBgc5wTexsc_oZNikqCqBAaf-KqQ@mail.gmail.com>
References: <CAEs96n3CrBJT1893q8QvmfRd_WOYTFG6vvEEs2kEt9BMKaUdfQ@mail.gmail.com>
 <87y4rvhqo8.fsf@gmail.com>
 <CAEs96n2Lu-Q8qVPDEoA5L2tZiMf3vK98rV8afsMZJM5s6QZf6A@mail.gmail.com>
 <1414858341.12004.6.camel@joachim-breitner.de>
 <CAEs96n3yQ7rcscy16AOqe_cBgc5wTexsc_oZNikqCqBAaf-KqQ@mail.gmail.com>
Message-ID: <87lhnuizp4.fsf@gmail.com>

Austin Seipp <austin at well-typed.com> writes:

> On Sat, Nov 1, 2014 at 11:12 AM, Joachim Breitner
> <mail at joachim-breitner.de> wrote:
>> Hi,
>>
>> for the Distributions it would be most easy if the custom llvm would
>> come within the source tarball, would be built by the regular build
>> process and installed along with GHC, in a private path
>> (/usr/lib/ghc/somewhere). We certainly don?t want to have a separate
>> packaging with separate binary packages "llvm-ghc" around.
>
> Yes, that seems like a reasonable desire.
>
> If we do this, my plan was actually to mirror a copy of the llvm git
> repository (an official one is maintained by llvm.org) to
> git.haskell.org, which is where we would base our own builds off of.
>
> We could certainly let source distributions build their own copy.
>
>> How long does building those two llvm binaries take? If it is
>> sufficiently quick, maybe that would be a suitable distribution for
>> developers as well, and avoids having to separately build, distribute,
>> download, and install the binaries.
>
> In practice it takes a while... I haven't timed it, but I'd guess on
> average it adds about 30-40 minutes for most people just to build
> llvm. I'm not sure how many things we can disable to make the build
> faster, but I'd ballpark it at half an hour at best (it's a few
> thousand source files, after all).
>
This sounds about right.

> This would mostly hurt if you cleaned up the tree later (e.g. 'make
> distclean'), which I do rather frequently in order to get a pristine
> build tree.
>
Ideally `make clean` would be a bit more complete so it could be used
more often. Much of my use of `make distclean` comes from superstition
after thinking `make clean` would be sufficient only to find out
half-way through the build that there is still vestigal state hanging
around.

Perhaps the Shake build system (if it happens) will be better in this
regard?

Cheers,

-  Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141101/4f5a2907/attachment.sig>

From hvriedel at gmail.com  Sat Nov  1 17:53:16 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Sat, 01 Nov 2014 18:53:16 +0100
Subject: Proposal: Improving the LLVM backend by packaging it
In-Reply-To: <CAEs96n3yQ7rcscy16AOqe_cBgc5wTexsc_oZNikqCqBAaf-KqQ@mail.gmail.com>
 (Austin Seipp's message of "Sat, 1 Nov 2014 11:26:26 -0500")
References: <CAEs96n3CrBJT1893q8QvmfRd_WOYTFG6vvEEs2kEt9BMKaUdfQ@mail.gmail.com>
 <87y4rvhqo8.fsf@gmail.com>
 <CAEs96n2Lu-Q8qVPDEoA5L2tZiMf3vK98rV8afsMZJM5s6QZf6A@mail.gmail.com>
 <1414858341.12004.6.camel@joachim-breitner.de>
 <CAEs96n3yQ7rcscy16AOqe_cBgc5wTexsc_oZNikqCqBAaf-KqQ@mail.gmail.com>
Message-ID: <874muin6yb.fsf@gmail.com>

On 2014-11-01 at 17:26:26 +0100, Austin Seipp wrote:

[...]

>> How long does building those two llvm binaries take? If it is
>> sufficiently quick, maybe that would be a suitable distribution for
>> developers as well, and avoids having to separately build, distribute,
>> download, and install the binaries.
>
> In practice it takes a while... I haven't timed it, but I'd guess on
> average it adds about 30-40 minutes for most people just to build
> llvm. I'm not sure how many things we can disable to make the build
> faster, but I'd ballpark it at half an hour at best (it's a few
> thousand source files, after all).
>
> This would mostly hurt if you cleaned up the tree later (e.g. 'make
> distclean'), which I do rather frequently in order to get a pristine
> build tree.

This also hurts buildbots as 30+ minutes is even more than a validate
run takes... :-/

Otoh, we don't have to force everyone to build GHC's bundled LLVM, and
could allow to use the system-wide installed LLVM binaries if a matching
version is provided by the system. As an example, I currently have
llvm-3.4 and llvm-3.5 installed, and could easily have a llvm-3.6
snapshot installed via the package manager (e.g. via
http://llvm.org/apt/).

Cheers,
  hvr

From hvriedel at gmail.com  Sat Nov  1 17:58:45 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Sat, 01 Nov 2014 18:58:45 +0100
Subject: Proposal: Improving the LLVM backend by packaging it
In-Reply-To: <87lhnuizp4.fsf@gmail.com> (Ben Gamari's message of "Sat, 01 Nov
 2014 13:43:35 -0400")
References: <CAEs96n3CrBJT1893q8QvmfRd_WOYTFG6vvEEs2kEt9BMKaUdfQ@mail.gmail.com>
 <87y4rvhqo8.fsf@gmail.com>
 <CAEs96n2Lu-Q8qVPDEoA5L2tZiMf3vK98rV8afsMZJM5s6QZf6A@mail.gmail.com>
 <1414858341.12004.6.camel@joachim-breitner.de>
 <CAEs96n3yQ7rcscy16AOqe_cBgc5wTexsc_oZNikqCqBAaf-KqQ@mail.gmail.com>
 <87lhnuizp4.fsf@gmail.com>
Message-ID: <87zjcals4q.fsf@gmail.com>

On 2014-11-01 at 18:43:35 +0100, Ben Gamari wrote:

[...]

>> This would mostly hurt if you cleaned up the tree later (e.g. 'make
>> distclean'), which I do rather frequently in order to get a pristine
>> build tree.
>>
> Ideally `make clean` would be a bit more complete so it could be used
> more often. Much of my use of `make distclean` comes from superstition
> after thinking `make clean` would be sufficient only to find out
> half-way through the build that there is still vestigal state hanging
> around.

I regularly run ./validate, which by definition has to reset everything
to a zero-state. Moreover, I keep a few GHC source-trees around, and
wouldn't want to have to keep redundant LLVM binaries around. So using
'make clean' isn't an option for everyone. I'd rather install the
required LLVM version system-wide (or rather, reachable via PATH), and
have ./configure try to pick that one up, before deciding it needs to
build its own LLVM.

From merijn at inconsistent.nl  Sat Nov  1 23:01:35 2014
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Sat, 1 Nov 2014 16:01:35 -0700
Subject: How to treat testsuite timeout as success?
Message-ID: <A3F0F066-78EF-4C4A-AF5D-4506BD697B25@inconsistent.nl>

Ola!

I was trying to re-re-fix https://ghc.haskell.org/trac/ghc/ticket/8089 and add a test-case for this fix. However, I'm having trouble creating a test that can actually be successful. The simplest case exhibiting the issue (on OSX) is that "main = threadDelay maxBound" crashes, I need a way to treat a timeout of say 5-10s as success, since the testsuite won't let my test run for 25,000 days :D

I can't add a timeout inside the haskell code (along the lines of "threadDelay 10000000 >> exitSuccess" since installing any other timers with a timeout shorter than the crashing one masks the crash. Marking the test as expected to fail doesn't help, as this treats both a crash due to the bug and a timeout as success. Clearly only timeout should be considered successful.

Cheers,
Merijn

PS - For the curious willing to help verify that the third time's the charm: https://phabricator.haskell.org/D407

From ezyang at mit.edu  Sun Nov  2 01:00:10 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Sat, 01 Nov 2014 18:00:10 -0700
Subject: How to treat testsuite timeout as success?
In-Reply-To: <A3F0F066-78EF-4C4A-AF5D-4506BD697B25@inconsistent.nl>
References: <A3F0F066-78EF-4C4A-AF5D-4506BD697B25@inconsistent.nl>
Message-ID: <1414889982-sup-5200@sabre>

Probably the easiest thing to do is write a little stub program
which calls the actual test with a timeout.

Edward

Excerpts from Merijn Verstraaten's message of 2014-11-01 16:01:35 -0700:
> Ola!
> 
> I was trying to re-re-fix https://ghc.haskell.org/trac/ghc/ticket/8089 and add a test-case for this fix. However, I'm having trouble creating a test that can actually be successful. The simplest case exhibiting the issue (on OSX) is that "main = threadDelay maxBound" crashes, I need a way to treat a timeout of say 5-10s as success, since the testsuite won't let my test run for 25,000 days :D
> 
> I can't add a timeout inside the haskell code (along the lines of "threadDelay 10000000 >> exitSuccess" since installing any other timers with a timeout shorter than the crashing one masks the crash. Marking the test as expected to fail doesn't help, as this treats both a crash due to the bug and a timeout as success. Clearly only timeout should be considered successful.
> 
> Cheers,
> Merijn
> 
> PS - For the curious willing to help verify that the third time's the charm: https://phabricator.haskell.org/D407

From gergo at erdi.hu  Sun Nov  2 06:07:35 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Sun, 2 Nov 2014 14:07:35 +0800 (SGT)
Subject: [commit: ghc] wip/T9705: Add test case for T9705 (1cca652)
In-Reply-To: <CAK-hX0mF8+GKNJ5A4J4cF5jetvz=MMm9vZBwZBempk2eUAcoSA@mail.gmail.com>
References: <20141101111509.50D2A3A300@ghc.haskell.org>
 <CAK-hX0mF8+GKNJ5A4J4cF5jetvz=MMm9vZBwZBempk2eUAcoSA@mail.gmail.com>
Message-ID: <alpine.DEB.2.10.1411021406410.2047@galaxy>

On Sat, 1 Nov 2014, Gabor Greif wrote:

> Hello Gerg?,
>
> you seem to test pattern synonyms in _class_ declarations here. Would
> it make sense to also test _instance_ declarations?

Excellent point. I've added a separate test for that, and also this made 
me notice that the error message only mentions instance declarations, 
whereas pattern synonyms are prohibited both in classes and instances, so 
I've changed the message accordingly.

Thanks,
 	Gergo

From gergo at erdi.hu  Sun Nov  2 06:38:54 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Sun, 2 Nov 2014 14:38:54 +0800 (SGT)
Subject: Can't compile GHC-7.8.3 from git, fails on haskell98 library
Message-ID: <alpine.DEB.2.10.1411021415170.2047@galaxy>

Hi,

On a completely clean clone, I've checked out the tag ghc-7.8.3-release, 
ran sync-all get, boot, and configure, but the build fails on haskell98. 
Any ideas what I could be doing wrong?

Thanks,
 	Gergo

"inplace/bin/ghc-cabal" check libraries/haskell98
"inplace/bin/ghc-cabal" configure libraries/haskell98 dist-install "" 
--with-ghc="/home/cactus/prog/haskell/ghc/ghc-7.8-build/inplace/bin/ghc-stage1" 
--with-ghc-pkg="/home/cactus/prog/haskell/ghc/ghc-7.8-build/inplace/bin/ghc-pkg" 
--disable-library-for-ghci --enable-library-vanilla 
--disable-library-profiling --enable-shared 
--with-hscolour="/home/cactus/.cabal/bin/HsColour" 
--configure-option=CFLAGS=" -fno-stack-protector   " 
--configure-option=LDFLAGS="   " --configure-option=CPPFLAGS="   " 
--gcc-options=" -fno-stack-protector       " --with-gcc="/usr/bin/gcc" 
--with-ld="/usr/bin/ld" --configure-option=--with-cc="/usr/bin/gcc" 
--with-ar="/usr/bin/ar" --with-ranlib="/usr/bin/ranlib" 
--with-alex="/home/cactus/.cabal/bin/alex" 
--with-happy="/home/cactus/.cabal/bin/happy"
Configuring haskell98-2.0.0.4...
ghc-cabal: At least the following dependencies are missing:
base ==4.8.*
make[1]: *** [libraries/haskell98/dist-install/package-data.mk] Error 1


From thomasmiedema at gmail.com  Sun Nov  2 10:19:32 2014
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Sun, 2 Nov 2014 11:19:32 +0100
Subject: [core libraries] RE: Core libraries bug tracker
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF221DC5B1@DBXPRD3001MB024.064d.mgd.msft.net>
References: <618BE556AADD624C9C918AA5D5911BEF2208A6B5@DB3PRD3001MB020.064d.mgd.msft.net>
 <618BE556AADD624C9C918AA5D5911BEF221D5E42@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAJumaK8Q71SdvZPDor75D1zjaw2DX9K1czZaNrxG_y1E+EFHxA@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF221DC5B1@DBXPRD3001MB024.064d.mgd.msft.net>
Message-ID: <CAD3WKgjHHgsAzOV_0UofoPRLhgWhbfbj5VERWgFv2HWwEstX5w@mail.gmail.com>

Herbert/Austin,

in the GHC Trac, when I set a ticket to component 'Core Libraries', ekmett
is automatically set as owner. This might prevent others from working on
that ticket, and I doubt Edward himself is working on all >100 of them.
Please change the default to not set the owner.

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141102/65ef4269/attachment-0001.html>

From gergo at erdi.hu  Sun Nov  2 13:29:06 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Sun, 2 Nov 2014 21:29:06 +0800 (SGT)
Subject: Can't compile GHC-7.8.3 from git, fails on haskell98 library
In-Reply-To: <alpine.DEB.2.10.1411021415170.2047@galaxy>
References: <alpine.DEB.2.10.1411021415170.2047@galaxy>
Message-ID: <alpine.DEB.2.10.1411022127230.2047@galaxy>

On Sun, 2 Nov 2014, Dr. ERDI Gergo wrote:

> On a completely clean clone, I've checked out the tag ghc-7.8.3-release, ran 
> sync-all get, boot, and configure, but the build fails on haskell98. Any 
> ideas what I could be doing wrong?

I've worked around this by manually checking out the 'ghc-7.8' branch of 
various submodules until I got it to work (I think the ones I needed to 
change were dph, haskell98, haskell2010, template-haskell, and haddock, 
but I'm not sure). It seems the `ghc-7.8.3-release` tag is in a horrible 
shape in terms of reproducable building of imported repos. Is anyone 
looking into fixing this?

Bye,
 	Gergo

From carter.schonwald at gmail.com  Sun Nov  2 13:56:36 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 2 Nov 2014 08:56:36 -0500
Subject: Can't compile GHC-7.8.3 from git, fails on haskell98 library
In-Reply-To: <alpine.DEB.2.10.1411022127230.2047@galaxy>
References: <alpine.DEB.2.10.1411021415170.2047@galaxy>
 <alpine.DEB.2.10.1411022127230.2047@galaxy>
Message-ID: <CAHYVw0yLTjyH38U3=_9Euct6UQzmfUmiaxmfxbpsM1MV1nrVwA@mail.gmail.com>

The checkout clone process for 7.8.3 is very different from head.  What
exact commands where you trying to do for the initial clone?

I would use
Git clone -b ghc-7.8.3 ghcUrl ; ./sync-all get
I think.

Point being the clone process is different.

On Sunday, November 2, 2014, Dr. ERDI Gergo <gergo at erdi.hu> wrote:

> On Sun, 2 Nov 2014, Dr. ERDI Gergo wrote:
>
>  On a completely clean clone, I've checked out the tag ghc-7.8.3-release,
>> ran sync-all get, boot, and configure, but the build fails on haskell98.
>> Any ideas what I could be doing wrong?
>>
>
> I've worked around this by manually checking out the 'ghc-7.8' branch of
> various submodules until I got it to work (I think the ones I needed to
> change were dph, haskell98, haskell2010, template-haskell, and haddock, but
> I'm not sure). It seems the `ghc-7.8.3-release` tag is in a horrible shape
> in terms of reproducable building of imported repos. Is anyone looking into
> fixing this?
>
> Bye,
>         Gergo
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141102/f8252142/attachment.html>

From gergo at erdi.hu  Sun Nov  2 14:09:53 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Sun, 2 Nov 2014 22:09:53 +0800 (SGT)
Subject: Can't compile GHC-7.8.3 from git, fails on haskell98 library
In-Reply-To: <CAHYVw0yLTjyH38U3=_9Euct6UQzmfUmiaxmfxbpsM1MV1nrVwA@mail.gmail.com>
References: <alpine.DEB.2.10.1411021415170.2047@galaxy>
 <alpine.DEB.2.10.1411022127230.2047@galaxy>
 <CAHYVw0yLTjyH38U3=_9Euct6UQzmfUmiaxmfxbpsM1MV1nrVwA@mail.gmail.com>
Message-ID: <alpine.DEB.2.10.1411022208070.2047@galaxy>

On Sun, 2 Nov 2014, Carter Schonwald wrote:

> The checkout clone process for 7.8.3 is very different from head.? What exact commands
> where you trying to do for the initial clone?
> I would use
> Git clone -b ghc-7.8.3 ghcUrl ; ./sync-all get?I think.?
> 
> Point being the clone process is different.?

I was on the ghc-7.8.3-release git tag and updated the submodules, so I 
was on the right commit I think. Does 'sync-all get' check out the correct 
commits or at least branches? I think that's the part that what went 
wrong.

From ekmett at gmail.com  Sun Nov  2 14:49:07 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 2 Nov 2014 09:49:07 -0500
Subject: [core libraries] RE: Core libraries bug tracker
In-Reply-To: <CAD3WKgjHHgsAzOV_0UofoPRLhgWhbfbj5VERWgFv2HWwEstX5w@mail.gmail.com>
References: <618BE556AADD624C9C918AA5D5911BEF2208A6B5@DB3PRD3001MB020.064d.mgd.msft.net>
 <618BE556AADD624C9C918AA5D5911BEF221D5E42@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAJumaK8Q71SdvZPDor75D1zjaw2DX9K1czZaNrxG_y1E+EFHxA@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF221DC5B1@DBXPRD3001MB024.064d.mgd.msft.net>
 <CAD3WKgjHHgsAzOV_0UofoPRLhgWhbfbj5VERWgFv2HWwEstX5w@mail.gmail.com>
Message-ID: <CAJumaK_kFNOzTfFPhkv53rkrshL5JBQLs+m7sXopjdDYaetshw@mail.gmail.com>

Alternately, I can make a blanket decree that anyone can feel free to steal
any ticket from me at any time as I mostly work through hvr, dfeuer, and
thoughtpolice anyways to chip away at these.

I lack a strong preference either way.

-Edward

On Sun, Nov 2, 2014 at 5:19 AM, Thomas Miedema <thomasmiedema at gmail.com>
wrote:

> Herbert/Austin,
>
> in the GHC Trac, when I set a ticket to component 'Core Libraries', ekmett
> is automatically set as owner. This might prevent others from working on
> that ticket, and I doubt Edward himself is working on all >100 of them.
> Please change the default to not set the owner.
>
> Thanks,
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141102/561427c2/attachment.html>

From carter.schonwald at gmail.com  Sun Nov  2 14:54:40 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 2 Nov 2014 09:54:40 -0500
Subject: Can't compile GHC-7.8.3 from git, fails on haskell98 library
In-Reply-To: <alpine.DEB.2.10.1411022208070.2047@galaxy>
References: <alpine.DEB.2.10.1411021415170.2047@galaxy>
 <alpine.DEB.2.10.1411022127230.2047@galaxy>
 <CAHYVw0yLTjyH38U3=_9Euct6UQzmfUmiaxmfxbpsM1MV1nrVwA@mail.gmail.com>
 <alpine.DEB.2.10.1411022208070.2047@galaxy>
Message-ID: <CAHYVw0xWyqdxap9297y4OJjjqX=x=FiBEgR9bcGXy=oNQi9LyA@mail.gmail.com>

Are you sure there's a -release tag?
What was the exact clone and checkout you did?

On Sunday, November 2, 2014, Dr. ERDI Gergo <gergo at erdi.hu> wrote:

> On Sun, 2 Nov 2014, Carter Schonwald wrote:
>
>  The checkout clone process for 7.8.3 is very different from head.  What
>> exact commands
>> where you trying to do for the initial clone?
>> I would use
>> Git clone -b ghc-7.8.3 ghcUrl ; ./sync-all get I think.
>>
>> Point being the clone process is different.
>>
>
> I was on the ghc-7.8.3-release git tag and updated the submodules, so I
> was on the right commit I think. Does 'sync-all get' check out the correct
> commits or at least branches? I think that's the part that what went wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141102/ff336df0/attachment.html>

From gergo at erdi.hu  Sun Nov  2 15:03:13 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Sun, 2 Nov 2014 23:03:13 +0800 (SGT)
Subject: Can't compile GHC-7.8.3 from git, fails on haskell98 library
In-Reply-To: <CAHYVw0xWyqdxap9297y4OJjjqX=x=FiBEgR9bcGXy=oNQi9LyA@mail.gmail.com>
References: <alpine.DEB.2.10.1411021415170.2047@galaxy>
 <alpine.DEB.2.10.1411022127230.2047@galaxy>
 <CAHYVw0yLTjyH38U3=_9Euct6UQzmfUmiaxmfxbpsM1MV1nrVwA@mail.gmail.com>
 <alpine.DEB.2.10.1411022208070.2047@galaxy>
 <CAHYVw0xWyqdxap9297y4OJjjqX=x=FiBEgR9bcGXy=oNQi9LyA@mail.gmail.com>
Message-ID: <alpine.DEB.2.10.1411022257320.2047@galaxy>

On Sun, 2 Nov 2014, Carter Schonwald wrote:

> Are you sure there's a -release tag?What was the exact clone and checkout you did?

You don't see the same tag? Are we even looking at the same repo? Mine was 
cloned from ssh://git at git.haskell.org/ghc.git and the tag in question is:

22:58:13 [cactus at galaxy ghc-7.8]$ git rev-parse ghc-7.8.3-release
4b1bcd4bfed2de5a1cd5ab2eb64e396ae647d963

Also how I arrived at that commit should be irrelevant -- there should be 
no weird dangling external state by git branch names or tag names or 
anything like that.

From hvriedel at gmail.com  Sun Nov  2 16:02:16 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Sun, 02 Nov 2014 17:02:16 +0100
Subject: Can't compile GHC-7.8.3 from git, fails on haskell98 library
In-Reply-To: <alpine.DEB.2.10.1411022127230.2047@galaxy> (ERDI Gergo's message
 of "Sun, 2 Nov 2014 21:29:06 +0800 (SGT)")
References: <alpine.DEB.2.10.1411021415170.2047@galaxy>
 <alpine.DEB.2.10.1411022127230.2047@galaxy>
Message-ID: <87a949oak7.fsf@gmail.com>

Hello Gergo,

On 2014-11-02 at 14:29:06 +0100, Dr. ERDI Gergo wrote:
> On Sun, 2 Nov 2014, Dr. ERDI Gergo wrote:
>
>> On a completely clean clone, I've checked out the tag
>> ghc-7.8.3-release, ran sync-all get, boot, and configure, but the
>> build fails on haskell98. Any ideas what I could be doing wrong?
>
> I've worked around this by manually checking out the 'ghc-7.8' branch
> of various submodules until I got it to work (I think the ones I
> needed to change were dph, haskell98, haskell2010, template-haskell,
> and haddock, but I'm not sure). It seems the `ghc-7.8.3-release` tag
> is in a horrible shape in terms of reproducable building of imported
> repos. Is anyone looking into fixing this?

Starting with GHC 7.8.x, fingerprints are written into
annotated & gpg-signed release tags:

  http://git.haskell.org/ghc.git/tag/refs/tags/ghc-7.8.3-release

That way you're able to restore via the fingerprint for a given release
via:

 ./utils/fingerprint/fingerprint.py restore -f <(git show ghc-7.8.3-release | grep -F '|')

I'm just surprised I couldn't find that described anywhere in the wiki,
I was sure it was written down somewhere...

hth,
  hvr

From simonpj at microsoft.com  Sun Nov  2 19:05:56 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Sun, 2 Nov 2014 19:05:56 +0000
Subject: [core libraries] RE: Core libraries bug tracker
In-Reply-To: <CAJumaK_kFNOzTfFPhkv53rkrshL5JBQLs+m7sXopjdDYaetshw@mail.gmail.com>
References: <618BE556AADD624C9C918AA5D5911BEF2208A6B5@DB3PRD3001MB020.064d.mgd.msft.net>
 <618BE556AADD624C9C918AA5D5911BEF221D5E42@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAJumaK8Q71SdvZPDor75D1zjaw2DX9K1czZaNrxG_y1E+EFHxA@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF221DC5B1@DBXPRD3001MB024.064d.mgd.msft.net>
 <CAD3WKgjHHgsAzOV_0UofoPRLhgWhbfbj5VERWgFv2HWwEstX5w@mail.gmail.com>
 <CAJumaK_kFNOzTfFPhkv53rkrshL5JBQLs+m7sXopjdDYaetshw@mail.gmail.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F389022@DB3PRD3001MB020.064d.mgd.msft.net>

Better to make them owner-less initially I think.  After all, you might really take ownership of some tickets!

S

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Edward Kmett
Sent: 02 November 2014 14:49
To: Thomas Miedema
Cc: core-libraries-committee at haskell.org; ghc-devs at haskell.org
Subject: Re: [core libraries] RE: Core libraries bug tracker

Alternately, I can make a blanket decree that anyone can feel free to steal any ticket from me at any time as I mostly work through hvr, dfeuer, and thoughtpolice anyways to chip away at these.

I lack a strong preference either way.

-Edward

On Sun, Nov 2, 2014 at 5:19 AM, Thomas Miedema <thomasmiedema at gmail.com<mailto:thomasmiedema at gmail.com>> wrote:
Herbert/Austin,

in the GHC Trac, when I set a ticket to component 'Core Libraries', ekmett is automatically set as owner. This might prevent others from working on that ticket, and I doubt Edward himself is working on all >100 of them. Please change the default to not set the owner.

Thanks,
Thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141102/cc441751/attachment-0001.html>

From ekmett at gmail.com  Sun Nov  2 21:30:39 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 2 Nov 2014 16:30:39 -0500
Subject: [core libraries] RE: Core libraries bug tracker
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F389022@DB3PRD3001MB020.064d.mgd.msft.net>
References: <618BE556AADD624C9C918AA5D5911BEF2208A6B5@DB3PRD3001MB020.064d.mgd.msft.net>
 <618BE556AADD624C9C918AA5D5911BEF221D5E42@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAJumaK8Q71SdvZPDor75D1zjaw2DX9K1czZaNrxG_y1E+EFHxA@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF221DC5B1@DBXPRD3001MB024.064d.mgd.msft.net>
 <CAD3WKgjHHgsAzOV_0UofoPRLhgWhbfbj5VERWgFv2HWwEstX5w@mail.gmail.com>
 <CAJumaK_kFNOzTfFPhkv53rkrshL5JBQLs+m7sXopjdDYaetshw@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F389022@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CAJumaK-ovpO+18w8cRwaN1Sw40aX_qrPmk-emxVcTxVU3p25NA@mail.gmail.com>

Sounds good to me.

On Sun, Nov 2, 2014 at 2:05 PM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

>  Better to make them owner-less initially I think.  After all, you might
> *really* take ownership of some tickets!
>
>
>
> S
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Edward
> Kmett
> *Sent:* 02 November 2014 14:49
> *To:* Thomas Miedema
> *Cc:* core-libraries-committee at haskell.org; ghc-devs at haskell.org
> *Subject:* Re: [core libraries] RE: Core libraries bug tracker
>
>
>
> Alternately, I can make a blanket decree that anyone can feel free to
> steal any ticket from me at any time as I mostly work through hvr, dfeuer,
> and thoughtpolice anyways to chip away at these.
>
>
>
> I lack a strong preference either way.
>
>
>
> -Edward
>
>
>
> On Sun, Nov 2, 2014 at 5:19 AM, Thomas Miedema <thomasmiedema at gmail.com>
> wrote:
>
>   Herbert/Austin,
>
>
>
> in the GHC Trac, when I set a ticket to component 'Core Libraries', ekmett
> is automatically set as owner. This might prevent others from working on
> that ticket, and I doubt Edward himself is working on all >100 of them.
> Please change the default to not set the owner.
>
>
>
> Thanks,
>
> Thomas
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141102/8e74b866/attachment.html>

From gintautas.miliauskas at gmail.com  Sun Nov  2 21:42:31 2014
From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas)
Date: Sun, 2 Nov 2014 22:42:31 +0100
Subject: GHC on Windows (extended/broad discussion)
In-Reply-To: <CAFC_MejtEdnC1B4yAA6xezgYB1L=UzhGr4_LvQFqpZ4gRSuc6Q@mail.gmail.com>
References: <CAEs96n0LErrHqBL-N517Odg4kWLFvs9WtzUpeXXBAuhWAw813Q@mail.gmail.com>
 <CAFC_MehNi=hgEAXD4MgnDCfwauBc+j1rm54TzH-YxqeuMSsAhg@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F37F0D2@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAFC_Mejfumw4K5kQ1WBWJOG2VC57mOPnEP4QyyNUw3OY4bfF0A@mail.gmail.com>
 <54527870.66bbb40a.6c56.ffffb18b@mx.google.com>
 <CAFC_MejtEdnC1B4yAA6xezgYB1L=UzhGr4_LvQFqpZ4gRSuc6Q@mail.gmail.com>
Message-ID: <CAFC_MehmqrN5NgtJAn9FdD6WbTRt3c=68AkynbykOFMYQ_p-hA@mail.gmail.com>

Alright, based on the votes let's do Wednesday (Nov 5) 8:00pm.

Kyrill, what's your timezone? Did this go too much into the evening for
you? Would be good to know for next time.

Shall we use Hangouts for the call? Skype would also work for me, but
Hangouts is probably a bit easier and more portable.

Looking forward to seeing everyone!

I will try to take notes of the meeting and send them to the mailing list
afterwards.

On Thu, Oct 30, 2014 at 9:03 PM, Gintautas Miliauskas <
gintautas.miliauskas at gmail.com> wrote:

> Updated.
>
> Note that I'm on vacation starting Friday (Nov 7) and will be back only on
> Nov 24.
>
> On Thu, Oct 30, 2014 at 6:40 PM, <lonetiger at gmail.com> wrote:
>
>>  Hi Gintautas,
>>
>> Is it possible for you to add the rest of next week to the schedule
>> times? I?m unavailable on the given dates.
>>
>> Kind Regards,
>> Tamar
>>
>> *From:* Gintautas Miliauskas <gintautas.miliauskas at gmail.com>
>> *Sent:* ?Thursday?, ?October? ?30?, ?2014 ?16?:?34
>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>> *Cc:* kyra <kyrab at mail.ru>, ghc-devs at haskell.org
>>
>>
>>
>> On Tue, Oct 28, 2014 at 11:02 PM, Simon Peyton Jones <
>> simonpj at microsoft.com> wrote:
>>
>>>   The people problem is tricky. At work, this would be the right time
>>> to do a video chat and at least see the faces of the other people involved.
>>> Would folks be interested in a Skype/Hangout sometime? It would be
>>> interesting to hear what interests / skills / resources / constraints we
>>> have between us.
>>>
>>>
>>>
>>> I think that?s a great idea, thanks.  It?s easier to work with people
>>> with whom you have formed a personal relationship, and a video conf is a
>>> good way to do that.
>>>
>>
>> Let's try that. Shall we try to find a good timeslot? Sign up at
>> http://doodle.com/34e598zc7m8sbaqm
>>
>> --
>> Gintautas Miliauskas <http://doodle.com/34e598zc7m8sbaqm>
>>  <http://doodle.com/34e598zc7m8sbaqm>
>>
>
>
>
> --
> Gintautas Miliauskas
>



-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141102/a6e0224c/attachment.html>

From gintautas at miliauskas.lt  Sun Nov  2 21:59:26 2014
From: gintautas at miliauskas.lt (Gintautas Miliauskas)
Date: Sun, 2 Nov 2014 22:59:26 +0100
Subject: GHC on Windows (extended/broad discussion)
In-Reply-To: <CAEs96n1AefFZmGW=EG9OzR06iYM2ySf=ZXXG-Hrk5SjKEgnbAA@mail.gmail.com>
References: <CAEs96n0LErrHqBL-N517Odg4kWLFvs9WtzUpeXXBAuhWAw813Q@mail.gmail.com>
 <CAFC_MehNi=hgEAXD4MgnDCfwauBc+j1rm54TzH-YxqeuMSsAhg@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F37F0D2@DB3PRD3001MB020.064d.mgd.msft.net>
 <CABHktDX2HnCzqKtpeoASoXYhyuxxZn0MhyH-8LPsYoPCUdmh7A@mail.gmail.com>
 <871tpr42g1.fsf@gmail.com>
 <CAFC_MejmkT_0NBo_MX+RPNLs-1v46TgEaXSqVUvYEvXLxOgnFg@mail.gmail.com>
 <CAEs96n1AefFZmGW=EG9OzR06iYM2ySf=ZXXG-Hrk5SjKEgnbAA@mail.gmail.com>
Message-ID: <CAFC_Meg1bviQgBVSxF_R2NQk-fn4tiPxcXZz8Hejy_y_1T_uNQ@mail.gmail.com>

Hi Austin,

thanks for the explanation. All of this makes sense. I was just thinking
that maybe it would make sense to have a couple more reviewers with a
mandate to deal with cleanups quickly before you get to the juicier
reviews, the ones that actually need attention / routing to interested
parties. On the other hand, going through the queue once a day is pretty
good, and if you think you can manage that, sounds great! (I am not just
speaking for myself, but for the project and for other potential
contributors - fast turnaround time is always motivating.)


On Thu, Oct 30, 2014 at 9:38 PM, Austin Seipp <austin at well-typed.com> wrote:

> Hey Gintautas,
>
> Yes, I apologize about that (and I missed this request in my quick
> read over this email yesterday). To be clear, I apologize if my
> review/merge latencies are too long. :) What normally happens it that
> I review and merge patches in bulk, about once or twice a week. I'll
> review about, say, a dozen patches one day, and wait a few days for
> more to come in, then sweep up everything in that time at once.
>
> So there are two things: a review latency, *and* a merge latency.
>
> However, two things are also clear:
>
>  1) This is annoying for people who submit 'rapid improvements', e.g.
> in the process of working on GHC, you may fix 4 or 5 things, and then
> not having those in the mainline is a bit of a drain!
>  2) Phabricator building patches actually means the merge latency can
> be *shorter*, because in the past, we'd always have to double check if
> a patch worked in the first place (so it took *even longer* before!)
>
> Another thing is that I'm the primary person who lands things off
> Phabricator, although occasionally other people do too. This is
> somewhat suboptimal in some cases, since really, providing something
> has the OK (from me or someone else), anyone should be able to merge
> it. So I think this can be improved too.
>
> Finally, it's also worth mentioning that Phabricator reviews are
> special (and unlike GitHub) in that people who are *not* reviewers *do
> not* see the patch by default! That means if I am the *only* person on
> the review, it is pretty high guarantee that the review will only be
> done by me, and it will only be merged by me, unless I poke someone
> else. Others can see your review using a slightly different search
> criterion, however, but that's not the default.
>
> Note this is not a mistake - it is intentional in the design. Why?
> Because realistically, I'd say for about 85% of the patches that come
> in, they are irrelevant to 90% of all GHC developers, and
> historically, 90% of developers will never bother committing it
> either. It is often pointless to spam them with emails, and enlarging
> their review queue beyond what's necessary makes things even *worse*
> for them, since they can't tell what may really deserve their
> attention. I do want more people reviewing code actively - but to do
> that, there must be a tradeoff - we should try and keep contributor
> burden low. Most developers are just our friends after all, including
> you - not paid GHC hackers! I don't want to overburden you; we need
> you!
>
> I am one of the exceptions to this: I realistically care and want to
> see about 95% of all patches that go into the tree, at least to keep
> up to date with what's happening, and also to ensure things get proper
> oversight - by, say, adding someone else to a review who I want to
> look at it. This is why I'm the common denominator, and a reviewer of
> almost every patch (and I think I'm fairly keen on who might care
> about what).
>
> However it's clear that if this is slowing you down we should try to
> fix it - we want you to help after all! We already have nearly 40
> people with commit rights to GHC, and you've clearly dedicated
> yourself to helping. That's fantastic. Perhaps it's time for you to
> enter the fray as well so I can get out of your way. :) But I do still
> want you to submit code reviews, as everyone else does - it really
> does help everyone, and increases a sense of shared ownership, IMO.
>
> In light of this though, I do think I need to ramp up my merge
> frequency. So how does a plan of just trying to merge all outstanding
> patches every day sound? This is normally very trivial amounts of time
> these days, considering Phabricator tends to catch the most obvious
> failures.
>
> BTW: I merged your pull request on the Win32 repository, so we can
> update MinGW - I didn't realize that it was open at all, and in fact I
> completely forgot I had permissions to merge things on that
> repository! Most of the external library management is normally dealt
> with by Herbert or individual maintainers.
>
> On Wed, Oct 29, 2014 at 6:36 AM, Gintautas Miliauskas
> <gintautas at miliauskas.lt> wrote:
> > By the way, regarding that repository, could someone merge my pull
> request?
> >
> > In general, it's a bit frustrating how a lot of the patches in the
> > Phabricator queue seem to take a while to get noticed. Don't take it
> > personally, I'm just sharing my impressions, but I do feel it's taking
> away
> > some momentum - not good for me & other contributors, and not good for
> the
> > project. I know reviewers are understaffed, maybe consider spreading
> commit
> > rights a bit more widely until the situation improves?
> >
> > On Wed, Oct 29, 2014 at 11:04 AM, Herbert Valerio Riedel
> > <hvriedel at gmail.com> wrote:
> >>
> >> On 2014-10-29 at 10:59:18 +0100, Phyx wrote:
> >>
> >> [...]
> >>
> >> >> The Win32 package for example, is dreadfully lacking in
> >> >> maintainership. While we merge patches, it would be great to see a
> >> >> Windows developer spearhead and clean it up
> >> >
> >> > A while back I was looking at adding some functionality to this
> >> > package, but could never figure out which one was actually being
> >> > used. I think there are multiple repositories out there.
> >>
> >> I'm not sure which multiple repositories you have seen, but
> >>
> >>   http://hackage.haskell.org/package/Win32
> >>
> >> points quite clearly to
> >>
> >>   https://github.com/haskell/win32
> >>
> >> and that's the official upstream repository GHC tracks (via a locally
> >> mirrored repo at git.haskell.org)
> >>
> >> Cheers,
> >>   hvr
> >
> >
> >
> >
> > --
> > Gintautas Miliauskas
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>



-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141102/aecf0773/attachment-0001.html>

From gintautas.miliauskas at gmail.com  Sun Nov  2 22:17:03 2014
From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas)
Date: Sun, 2 Nov 2014 23:17:03 +0100
Subject: Tests with compilation errors
In-Reply-To: <CAEs96n3gVRMjoYiH=uWCdMg41+899LKdYfGefURPRANXdd6-PA@mail.gmail.com>
References: <CAFC_Mei94SsP8Bu0_cH7snFwTjqsudgUT5JmC7pJb8jy_ELV=g@mail.gmail.com>
 <CAEs96n3gVRMjoYiH=uWCdMg41+899LKdYfGefURPRANXdd6-PA@mail.gmail.com>
Message-ID: <CAFC_Mego-rZwSU7v_Wztt7bFBfbhH2A4OGkvhJtR3FJw6xV4HA@mail.gmail.com>

Thanks for the detailed explanations. A few thoughts here:

Having multiple "configurations" of the source tree (in that some parts of
it may be missing or not) does not sound like a good idea, it just seems
like additional complexity for no particular reason. AFAIU, it means that
if I check out additional libraries into my repository (or build those
libraries somehow?), tests for other packages might start failing, which is
weird.

It sounds like the current decision of keeping "random" and a few other
packages not built is rather ad hoc. Is that the case?

Ideally there would be one ghc testsuite that would always include all
tests (when a faster test run is desired, a more generic mechanism of test
filtering should be used, some test suites react to a "fast" flag, right?).
If there are tests that we do not want to run as part of the global test
suite, it seems that they should live together with the library
implementation then and be maintained there, separately from ghc.

What's the compilation cost of the additional libraries relative to the
complete build? (If you don't know off the bat, how do I get them built to
measure the overhead?) Is it really significant? If it is, can we split off
related tests? If it isn't, let's just enable them by default.

On Thu, Oct 30, 2014 at 10:19 PM, Austin Seipp <austin at well-typed.com>
wrote:

> On Thu, Oct 30, 2014 at 6:48 AM, Gintautas Miliauskas
> <gintautas.miliauskas at gmail.com> wrote:
> > Going through some validate.sh results, I found compilation errors due to
> > missing libraries, like this one:
> >
> > =====> stm052(normal) 4088 of 4108 [0, 21, 0]
> > cd ../../libraries/stm/tests &&
> > 'C:/msys64/home/Gintas/ghc/bindisttest/install   dir/bin/ghc.exe'
> > -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output
> -no-user-package-db
> > -rtsopt
> > s -fno-warn-tabs -fno-ghci-history -o stm052 stm052.hs  -package stm
> >>stm052.comp.stderr 2>&1
> > Compile failed (status 256) errors were:
> >
> > stm052.hs:10:8:
> >     Could not find module ?System.Random?
> >     Use -v to see a list of the files searched for.
> >
> > I was surprised to see that these are not listed in the test summary at
> the
> > end of the test run, but only counted towards the "X had missing
> libraries"
> > row. That setup makes it really easy to miss them, and I can't think of a
> > good reason to sweep such tests under the rug; a broken test is a failing
> > test.
>
> Actually, these tests aren't broken in the way you think :) It's a bit
> long-winded to explain...
>
> Basically, GHC can, if you let it, build extra dependencies in its
> build process, one of which is the 'random' library. 'random' was not
> ever a true requirement to build GHC (aka a 'bootlib' as we call
> them). So why is this test here?
>
> Because 'random' was actually a dependency of the Data Parallel
> Haskell package, and until not too long ago (earlier this year),
> `./validate` built and compiled DPH - with all its dependencies;
> random, vector, primitive - by default. This actually adds a pretty
> noticeable time to the build (you are compiling 5-8 more libraries
> after all), and at the time, DPH was also not ready for the
> Applicative-Monad patch. So we turned it off, as well as the
> dependencies.
>
> Additionally, GHC does have some 'extra' libraries which you can
> optionally build during the build process, but which are turned off by
> default. Originally this was because the weirdo './sync-all' script
> used to not need everything, and 'stm' was a library that wasn't
> cloned by default.
>
> Now that we've submoduleified everything though, these tests and the
> extra libraries could be built by default. Which we could certainly
> do.
>
> > How about at least listing such failed tests in the list of failed tests
> of
> > the end?
>
> I'd probably be OK with this.
>
> > At least in this case the error does not seem to be due to some missing
> > external dependencies (which probably would not be a great idea
> anyway...).
> > The test does pass if I remove the "-no-user-package-db" argument. What
> was
> > the intention here? Does packaging work somehow differently on Linux?
> (I'm
> > currently testing on Windows.)
>
> I'm just guessing but, I imagine you really don't want to remove
> '-no-user-package-db' at all, for any platform, otherwise Weird Things
> Might Happen, I'd assume.
>
> The TL;DR here is that when you build a copy of GHC and all the
> libraries, it actually *does* register the built packages for the
> compiler... this always happens, *even if you do not install it*. The
> primary 'global' package DB just sits in tree instead, under
> ./inplace.
>
> When you run ./validate, what happens is that after the build, we
> actually create a binary distribution and then test *that* compiler
> instead, as you can see (obviously for a good reason - broken bindists
> would be bad). The binary distribution obviously has its own set of
> binary packages it came with; those are the packages you built into it
> after all. The reason we tell GHC to ignore the user package db here
> is precisely because we *do not* want to pick it up! We only want to
> test the binary distribution with the packages *it* has.
>
> Now you might say, well, Austin, the version numbers are different!
> How would it pick that up? Not always... What if I built a copy of GHC
> HEAD today, then built something with it using Cabal? Then that will
> install into my user package database. Now I go back to my GHC tree
> and hack away _on the same day_ and run './validate'... the version
> number hasn't changed *at all* because it's date based, meaning the
> binary distribution could certainly pick up the previously installed
> libraries, which I installed via the older compiler. But I don't want
> that! I only want to run those tests with the compiler I'm validating
> *now*.
>
> I imagine the reason you see this test pass if you remove this
> argument is precisely for this reason: it doesn't fail because it's
> picking up a package database in your existing environment. But that's
> really, really not what you want (I'd be surprised if it worked and
> didn't result in some horrible error or crash).
>
> > On a related note, how about separating test failures from failing
> > performance tests ("stat too good" / "stat not good enough")? The latter
> are
> > important, but they seem to be much more prone to fail without good
> reason.
> > Perhaps do some color coding of the test runner output? That would also
> > help.
>
> I also think this is a good idea.
>
> > --
> > Gintautas Miliauskas
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>



-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141102/59a9e403/attachment.html>

From mail at joachim-breitner.de  Sun Nov  2 22:51:23 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 02 Nov 2014 23:51:23 +0100
Subject: unexpected failure for scc001
Message-ID: <1414968683.6639.1.camel@joachim-breitner.de>

Hi,

it seems that adding the oneShot annotation to the interface causes
scc001 to fail:


Actual prof output differs from expected:
--- ./profiling/should_run/scc001.prof.sample   2014-11-02 20:21:03.000000000 +0100
+++ ./profiling/should_run/scc001.prof  2014-11-02 20:46:39.000000000 +0100
@@ -1,28 +1,33 @@
-       Fri Oct 14 16:27 2011 Time and Allocation Profiling Report  (Final)
+       Sun Nov  2 20:46 2014 Time and Allocation Profiling Report  (Final)
 
           scc001 +RTS -hc -p -RTS
 
-       total time  =        0.00 secs   (0 ticks @ 20 ms)
-       total alloc =      46,020 bytes  (excludes profiling overheads)
+       total time  =        0.00 secs   (0 ticks @ 1000 us, 1 processor)
+       total alloc =      51,344 bytes  (excludes profiling overheads)
 
 COST CENTRE MODULE                %time %alloc
 
-MAIN        MAIN                    0.0   23.0
-CAF         GHC.IO.Encoding.Iconv   0.0    1.3
-CAF         GHC.IO.Handle.FD        0.0   74.2
+MAIN        MAIN               0.0    1.9
+CAF         GHC.IO.Encoding    0.0    5.4
+CAF         GHC.Conc.Signal    0.0    1.3
+CAF         GHC.IO.Handle.FD   0.0   67.3
+main        Main               0.0   22.8
 
 
                                                       individual     inherited
 COST CENTRE MODULE                  no.     entries  %time %alloc   %time %alloc
 
-MAIN        MAIN                    101           0    0.0   23.0     0.0  100.0
- CAF        GHC.Show                141           0    0.0    0.3     0.0    0.3
- CAF        GHC.IO.Handle.FD        128           0    0.0   74.2     0.0   74.2
- CAF        GHC.IO.Encoding.Iconv   120           0    0.0    1.3     0.0    1.3
- CAF        GHC.Conc.Signal         110           0    0.0    0.7     0.0    0.7
- CAF        Main                    107           0    0.0    0.4     0.0    0.4
-  (...)     Main                    206           1    0.0    0.0     0.0    0.0
-  h         Main                    205           1    0.0    0.0     0.0    0.0
-  main      Main                    202           1    0.0    0.0     0.0    0.0
-   g        Main                    204           1    0.0    0.0     0.0    0.0
-   f        Main                    203           1    0.0    0.0     0.0    0.0
+MAIN        MAIN                     44           0    0.0    1.9     0.0  100.0
+ main       Main                     89           0    0.0   22.8     0.0   22.8
+  g         Main                     91           1    0.0    0.0     0.0    0.0
+  f         Main                     90           1    0.0    0.0     0.0    0.0
+ CAF        Main                     87           0    0.0    0.1     0.0    0.1
+  (...)     Main                     93           1    0.0    0.0     0.0    0.0
+  h         Main                     92           1    0.0    0.0     0.0    0.0
+  main      Main                     88           1    0.0    0.0     0.0    0.0
+ CAF        GHC.IO.Handle.Text       84           0    0.0    0.2     0.0    0.2
+ CAF        GHC.IO.Encoding.Iconv    80           0    0.0    0.5     0.0    0.5
+ CAF        GHC.IO.Handle.FD         79           0    0.0   67.3     0.0   67.3
+ CAF        GHC.Show                 77           0    0.0    0.6     0.0    0.6
+ CAF        GHC.Conc.Signal          74           0    0.0    1.3     0.0    1.3
+ CAF        GHC.IO.Encoding          72           0    0.0    5.4     0.0    5.4
*** unexpected failure for scc001(profasm)

Now after reading some of the code it seems that the output is
normalized considerably before comparing.

But I?m not fully sure what is being checked here. So things change: Is
that change a regression? An improvement? Or just an a wobble that
should not worry me?

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141102/42bb7c00/attachment.sig>

From gintautas.miliauskas at gmail.com  Sun Nov  2 22:53:32 2014
From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas)
Date: Sun, 2 Nov 2014 23:53:32 +0100
Subject: Problem with installing "primitive" on Windows/i686
Message-ID: <CAFC_Mej4XBK9qyH-vnk43BAF=_T6sBn9zG2fvybPkVewU4UBLA@mail.gmail.com>

Installation of Alex in the msys2 i686 instructions is broken, more details
in https://ghc.haskell.org/trac/ghc/ticket/9712. Before I spend more time
on this, maybe someone knows off the bat what's going on?

$ cabal install alex
Resolving dependencies...
Downloading primitive-0.5.4.0...
Configuring primitive-0.5.4.0...
Failed to install primitive-0.5.4.0
Build log (
C:\Users\Gintas\AppData\Roaming\cabal\logs\primitive-0.5.4.0.log ):
[1 of 1] Compiling Main             (
C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\setup.hs,
C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\Main.o
)
Linking
C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\setup.exe
...
Configuring primitive-0.5.4.0...
setup-Simple-Cabal-1.18.1.3-i386-windows-ghc-7.8.3.exe: Missing dependency
on
a foreign library:
* Missing (or bad) header file: primitive-memops.h
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
If the header file does exist, it may contain errors that are caught by the
C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.


-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141102/e08f45a3/attachment-0001.html>

From gintautas.miliauskas at gmail.com  Mon Nov  3 00:24:54 2014
From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas)
Date: Mon, 3 Nov 2014 01:24:54 +0100
Subject: Automating GHC build for Windows
In-Reply-To: <CAHnG2CxK9QC-yN+hGz-EkwK39MrXQvekVNxFpRvN-gLgsh7Jyg@mail.gmail.com>
References: <CAD78TFJ+2BvKxCK9nCxsPDVR=tMaEhWESEknXAwp_zCJ_P+Amg@mail.gmail.com>
 <1413916715.326367.181663173.2FBCEE30@webmail.messagingengine.com>
 <CAEs96n1vizQgobwsOpxYztAtf5bBtoaCK552DtysO4cVLaYF7Q@mail.gmail.com>
 <CAHnG2Cwi3bwNa_X+gk4vdHFKm1YbyQwv1nHgdhJA+RWtS-tCOQ@mail.gmail.com>
 <CAFC_MegfiYS6T6ahtMhxa9_gNRrTGa4xW6pUWjonTZr-XJn8Pw@mail.gmail.com>
 <CAHnG2CybhW6K=KBGG4Kw-ygjLLcxKnYMW7xkGZdT-8s58_dkSA@mail.gmail.com>
 <CAFC_MejcnCQpEE=Ej3Dojnw8-4APK_zWYgnAjn=e95wP4e9nYQ@mail.gmail.com>
 <CAHnG2CyLNJ+zvxASn7_0CM59Rg9tf9G3hTOD8VmjvYjkwbLV7w@mail.gmail.com>
 <CAFC_Meh1QiF5ABja_ozjewMg=FS8r78oUz8bxoP=BNUXANkskg@mail.gmail.com>
 <CAHnG2CxK9QC-yN+hGz-EkwK39MrXQvekVNxFpRvN-gLgsh7Jyg@mail.gmail.com>
Message-ID: <CAFC_Meim57TpLXa5-r+-pm1u5Bhot++TQ3H_zLiWkcXq8mtMkw@mail.gmail.com>

Without knowing much about the surrounding code, I would try two things
here.

1. Is it possible that the file was opened by for writing and not closed
because of lazy I/O?

2. Since the error is completely deterministic, you could try "freezing"
evaluation right before the crash (either by a breakpoint in ghci or just
adding a time delay / console read on the code), and then using a utility
app
<http://serverfault.com/questions/1966/how-do-you-find-what-process-is-holding-a-file-open-in-windows>
to
check which process is keeping the file open, whether it's the same process
or something else.

If any of the involved paths is a directory, this could be #8482
<https://ghc.haskell.org/trac/ghc/ticket/8482>, although that does not seem
to be the case.

On Thu, Oct 30, 2014 at 7:13 PM, P?li G?bor J?nos <pali.gabor at gmail.com>
wrote:

> 2014-10-30 16:24 GMT+01:00 Gintautas Miliauskas <gintautas at miliauskas.lt>:
> > I wonder what's going on with DeleteFile. What is the step that's
> failing?
>
> Basically it happens at the same point, that is, at the "configure"
> phase but at the ghc-prim package.  Note that the previously mentioned
> workaround has a "removeFile" action [1], I guess the failure of that
> triggers the DeleteFile exception.
>
> > Can you post the log?
>
> "inplace/bin/ghc-cabal.exe" configure libraries/ghc-prim dist-install
> "" --with-ghc="C:/msys64/home/ghc-builder/ghc/inplace/bin/ghc-stage1.exe"
> --with-ghc-pkg="C:/msys64/home/ghc-builder/ghc/inplace/bin/ghc-pkg.exe"
> --flag=include-ghc-prim --disable-library-for-ghci
> --enable-library-vanilla --enable-library-for-ghci
> --enable-library-profiling --disable-shared
> --configure-option=CFLAGS=" -U__i686 -march=i686 -fno-stack-protector
>  " --configure-option=LDFLAGS="   " --configure-option=CPPFLAGS="   "
> --gcc-options=" -U__i686 -march=i686 -fno-stack-protector       "
> --with-gcc="C:/msys64/home/ghc-builder/ghc/inplace/mingw/bin/gcc.exe"
> --with-ld="C:/msys64/home/ghc-builder/ghc/inplace/mingw/bin/ld.exe"
>
> --configure-option=--with-cc="C:/msys64/home/ghc-builder/ghc/inplace/mingw/bin/gcc.exe"
> --with-ar="/usr/bin/ar" --with-alex="/usr/local/bin/alex"
> --with-happy="/usr/local/bin/happy"
> Configuring ghc-prim-0.3.1.0...
> ghc-cabal.exe: DeleteFile "dist-install\\setup-config": permission
> denied (The process cannot access the file because it is being used by
> another process.)
> libraries/ghc-prim/ghc.mk:4: recipe for target
> 'libraries/ghc-prim/dist-install/package-data.mk' failed
> make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1
> Makefile:71: recipe for target 'all' failed
>
> > I also wonder why this issue is not arising on other Windows machines...
>
> As the comment in the workaround goes, it has a "Big fat hairy race
> condition".  Therefore I am inclined to believe that it may be a
> problem for other systems as well, but I am the most unfortunate one
> who hits this error with 100% probability :-)
>
> [1]
> https://github.com/ghc/ghc/blob/master/libraries/bin-package-db/GHC/PackageDb.hs#L267
>



-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141103/e0fecbfd/attachment.html>

From david.feuer at gmail.com  Mon Nov  3 01:10:54 2014
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 2 Nov 2014 20:10:54 -0500
Subject: thenIO removal
Message-ID: <CAMgWh9uV5LJJ1j0w1jNn4n70eFdeNfti5=r3U-UFzOa4DSgK9Q@mail.gmail.com>

GHC.Base has a function, thenIO, that isn't used anywhere in the libraries
or compiler, and isn't exported anywhere "public". But for some reason,
it's listed in compiler/prelude/PrelNames.lhs, which causes a validation
failure if I remove it. Is there a reason that a completely unused function
is wired in? Is it a historical artifact, or an optimization that was never
completed, or something else? Should I wipe it out of PrelNames, or do we
want to use it for something?

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141102/50a1810b/attachment.html>

From mail at joachim-breitner.de  Mon Nov  3 08:22:08 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 03 Nov 2014 09:22:08 +0100
Subject: thenIO removal
In-Reply-To: <CAMgWh9uV5LJJ1j0w1jNn4n70eFdeNfti5=r3U-UFzOa4DSgK9Q@mail.gmail.com>
References: <CAMgWh9uV5LJJ1j0w1jNn4n70eFdeNfti5=r3U-UFzOa4DSgK9Q@mail.gmail.com>
Message-ID: <1415002928.1386.1.camel@joachim-breitner.de>

Hi,


Am Sonntag, den 02.11.2014, 20:10 -0500 schrieb David Feuer:
> GHC.Base has a function, thenIO, that isn't used anywhere in the
> libraries or compiler, and isn't exported anywhere "public". But for
> some reason, it's listed in compiler/prelude/PrelNames.lhs, which
> causes a validation failure if I remove it. Is there a reason that a
> completely unused function is wired in? Is it a historical artifact,
> or an optimization that was never completed, or something else? Should
> I wipe it out of PrelNames, or do we want to use it for something?

I find uses in compiler/typecheck/TcRnDriver.lhs in tcUserStmt, it seems
to be related to ghci?s support for IO actions. If you can rewrite that
easily, then it surely can go, but there likely is a reason for it. If
you find that reason, a Note would be appreciated.


Greeting,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141103/084f9aaa/attachment.sig>

From kyrab at mail.ru  Mon Nov  3 09:09:45 2014
From: kyrab at mail.ru (Kyra)
Date: Mon, 03 Nov 2014 12:09:45 +0300
Subject: GHC on Windows (extended/broad discussion)
In-Reply-To: <CAFC_MehmqrN5NgtJAn9FdD6WbTRt3c=68AkynbykOFMYQ_p-hA@mail.gmail.com>
References: <CAEs96n0LErrHqBL-N517Odg4kWLFvs9WtzUpeXXBAuhWAw813Q@mail.gmail.com>
 <CAFC_MehNi=hgEAXD4MgnDCfwauBc+j1rm54TzH-YxqeuMSsAhg@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F37F0D2@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAFC_Mejfumw4K5kQ1WBWJOG2VC57mOPnEP4QyyNUw3OY4bfF0A@mail.gmail.com>
 <54527870.66bbb40a.6c56.ffffb18b@mx.google.com>
 <CAFC_MejtEdnC1B4yAA6xezgYB1L=UzhGr4_LvQFqpZ4gRSuc6Q@mail.gmail.com>
 <CAFC_MehmqrN5NgtJAn9FdD6WbTRt3c=68AkynbykOFMYQ_p-hA@mail.gmail.com>
Message-ID: <54574659.3050901@mail.ru>

My timezone is GMT+5 (mostly, sometimes I visit Moscow, which is +3).

Cheers,
Kyra

On 03.11.2014 0:42, Gintautas Miliauskas wrote:
> Alright, based on the votes let's do Wednesday (Nov 5) 8:00pm.
>
> Kyrill, what's your timezone? Did this go too much into the evening 
> for you? Would be good to know for next time.
>
> Shall we use Hangouts for the call? Skype would also work for me, but 
> Hangouts is probably a bit easier and more portable.
>
> Looking forward to seeing everyone!
>
> I will try to take notes of the meeting and send them to the mailing 
> list afterwards.
>
> On Thu, Oct 30, 2014 at 9:03 PM, Gintautas Miliauskas 
> <gintautas.miliauskas at gmail.com 
> <mailto:gintautas.miliauskas at gmail.com>> wrote:
>
>     Updated.
>
>     Note that I'm on vacation starting Friday (Nov 7) and will be back
>     only on Nov 24.
>
>     On Thu, Oct 30, 2014 at 6:40 PM, <lonetiger at gmail.com
>     <mailto:lonetiger at gmail.com>> wrote:
>
>         Hi Gintautas,
>
>         Is it possible for you to add the rest of next week to the
>         schedule times? I?m unavailable on the given dates.
>
>         Kind Regards,
>         Tamar
>
>         *From:* Gintautas Miliauskas
>         <mailto:gintautas.miliauskas at gmail.com>
>         *Sent:* ?Thursday?, ?October? ?30?, ?2014 ?16?:?34
>         *To:* Simon Peyton Jones <mailto:simonpj at microsoft.com>
>         *Cc:* kyra <mailto:kyrab at mail.ru>, ghc-devs at haskell.org
>         <mailto:ghc-devs at haskell.org>
>
>
>
>         On Tue, Oct 28, 2014 at 11:02 PM, Simon Peyton Jones
>         <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
>
>             The people problem is tricky. At work, this would be the
>             right time to do a video chat and at least see the faces
>             of the other people involved. Would folks be interested in
>             a Skype/Hangout sometime? It would be interesting to hear
>             what interests / skills / resources / constraints we have
>             between us.
>
>             I think that?s a great idea, thanks.  It?s easier to work
>             with people with whom you have formed a personal
>             relationship, and a video conf is a good way to do that.
>
>
>         Let's try that. Shall we try to find a good timeslot? Sign up
>         at http://doodle.com/34e598zc7m8sbaqm
>
>         --
>         Gintautas Miliauskas<http://doodle.com/34e598zc7m8sbaqm>
>         <http://doodle.com/34e598zc7m8sbaqm>
>
>
>
>
>     -- 
>     Gintautas Miliauskas
>
>
>
>
> -- 
> Gintautas Miliauskas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141103/52c6ebba/attachment-0001.html>

From ezyang at mit.edu  Mon Nov  3 09:10:19 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Mon, 03 Nov 2014 01:10:19 -0800
Subject: package hashes
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F384849@DB3PRD3001MB020.064d.mgd.msft.net>
References: <618BE556AADD624C9C918AA5D5911BEF3F384849@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <1415005537-sup-7146@sabre>

So, there seem to be two things going on here:

1. For some reason, your checkout thinks that the package key is
unambiguous, whereas all the checkouts I've run it on think it
is ambiguous, and thus must be qualified.  I actually can't
reproduce your version of the error, but it seems harmless.
I think the right thing to do here is force GHC to always print
fully qualified; I suspect one of the DynFlags will do it for us.

2. But the test seems to be gaining a new entry entirely, what gives?
Well, the test-case is using grep to pull out the part of --show-iface that
it cares about.  However, --show-iface is using the pretty-printing
combinators, so when a field is sufficiently long it spills over to the
next line, and it isn't picked up by grep.  So the test here is actually
a bit broken.  I think if we force GHC to have infinite columns
that will fix the second problem.

Edward

Excerpts from Simon Peyton Jones's message of 2014-10-30 08:26:45 -0700:
> Edward
> 
> On branch wip/new-flatten-skolems-Oct14, I'm getting this test failure repeatably on test safePkgO1.  I'm pretty sure I have done nothing to mess with package hashes!
> 
> Any ideas?
> 
> Simon
> 
> =====> safePkg01(normal) 108 of 120 [0, 0, 0]
> cd ./check/pkg01 && $MAKE -s --no-print-directory safePkg01 VANILLA=--enable-library-vanilla PROF=--disable-library-profiling DYN=--enable-shared    </dev/null >safePkg01.run.stdout 2>safePkg01.run.stderr
> Actual stdout output differs from expected:
> --- ./check/pkg01/safePkg01.stdout   2014-10-29 15:09:16.000000000 +0000
> +++ ./check/pkg01/safePkg01.run.stdout       2014-10-30 15:25:17.799094762 +0000
> @@ -29,17 +29,17 @@
> require own pkg trusted: True
>  M_SafePkg6
> -package dependencies: array-0.5.0.1 at array_<HASH>
> +package dependencies: array-0.5.0.1 base-4.8.0.0*
> trusted: trustworthy
> require own pkg trusted: False
>  M_SafePkg7
> -package dependencies: array-0.5.0.1 at array_<HASH>
> +package dependencies: array-0.5.0.1 base-4.8.0.0*
> trusted: safe
> require own pkg trusted: False
>  M_SafePkg8
> -package dependencies: array-0.5.0.1 at array_<HASH>
> +package dependencies: array-0.5.0.1 base-4.8.0.0
> trusted: trustworthy
> require own pkg trusted: False

From gergo at erdi.hu  Mon Nov  3 10:13:24 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Mon, 3 Nov 2014 18:13:24 +0800 (SGT)
Subject: RFC: Concrete syntax for pattern synonym type signatures
Message-ID: <alpine.DEB.2.10.1411031812500.2047@galaxy>

Background
----------

As explained on
https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms#Staticsemantics
the type of a pattern synonym can be fully described with the
following pieces of information:

* If the pattern synonym is bidirectional
* Universially-bound type variables, and required constraints on them
* The type of the pattern itself, closed over the universially-bound type variables
* Existentially-bound type variables, and the constraints provided by them
* The types of the arguments, closed over the universially and
   existentially bound type variables

Here's an example showing all of these axes in action:

     data T a b where
       MkT :: (Eq a, Ord b, Show c) => a -> (b, b) -> c -> T a b

     pattern P x y = MkT 5 (y, True) x

In this case:

* The name of the pattern synonym is `P`
* The pattern synonym is bidirectional
* The universially-bound tyvars/required constraints are `forall a. Num a`
* The type of the pattern is `T a Bool`
* The existentially-bound tyvars/provided constraints are
   `forall c. (Eq a, Ord Bool, Show c)`
* The type of the arguments are `c` and `Bool`.

The problem, then, is finding a concrete syntax that captures all of
this information. This syntax is needed for at least two purposes:

* Showing pattern synonym type information in Haddock/GHCi
* Pattern synonym type signatures (#8584)

Current state of things
-----------------------

GHCi 7.8.3 shows the type above as:

pattern (Eq t, Ord Bool, Show c) => P c Bool :: Num t => (T t Bool)

Not only does it not show directionality, I think this is very
confusing in every other way as well, especially with explicit foralls:

pattern forall c. (Eq t, Ord Bool, Show c) => P c Bool :: forall t. Num t 
=> (T t Bool)

I am currently working on implementing #8584, which means I need to
parse these type signatures. I managed to get the above monstrosity to
parse (unambigiously from actual pattern synonym definitions) by
throwing in an extra 'type' keyword:

pattern type (Eq t, Ord Bool, Show c) => P c Bool :: Num t => (T t Bool)

Request for help
----------------

Surely we can do better than that! So let's come up with a nice syntax
for pattern synonym type signatures. It will be used in the pattern
synonym type signature annotations of GHC 7.10, and we could also
retrofit it into GHC 7.8.4 and its Haddock, so that documentation
generated with today's tools will look consistent with code you will
be able to enter in tomorrow's version.

Bye,
 	Gergo

From simonpj at microsoft.com  Mon Nov  3 12:40:46 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 3 Nov 2014 12:40:46 +0000
Subject: thenIO removal
In-Reply-To: <1415002928.1386.1.camel@joachim-breitner.de>
References: <CAMgWh9uV5LJJ1j0w1jNn4n70eFdeNfti5=r3U-UFzOa4DSgK9Q@mail.gmail.com>
 <1415002928.1386.1.camel@joachim-breitner.de>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F38BA5E@DB3PRD3001MB020.064d.mgd.msft.net>

It's not a big deal.  

You can probably replace both those bindIOName uses with bindMName (i.e (>>=)), in TcRnDriver.  That will just make GHCi generate code with uses of overloaded (>>=) that must be evaluated, rather than calling bindIO directly.  It should work just fine, but it'll make everything a tiny bit slower and more indirect.  If it simplified the code a lot, then fine, but it doesn't really.  So I'm inclined to leave it.

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Joachim
| Breitner
| Sent: 03 November 2014 08:22
| To: ghc-devs at haskell.org
| Subject: Re: thenIO removal
| 
| Hi,
| 
| 
| Am Sonntag, den 02.11.2014, 20:10 -0500 schrieb David Feuer:
| > GHC.Base has a function, thenIO, that isn't used anywhere in the
| > libraries or compiler, and isn't exported anywhere "public". But for
| > some reason, it's listed in compiler/prelude/PrelNames.lhs, which
| > causes a validation failure if I remove it. Is there a reason that a
| > completely unused function is wired in? Is it a historical artifact,
| > or an optimization that was never completed, or something else? Should
| > I wipe it out of PrelNames, or do we want to use it for something?
| 
| I find uses in compiler/typecheck/TcRnDriver.lhs in tcUserStmt, it seems
| to be related to ghci?s support for IO actions. If you can rewrite that
| easily, then it surely can go, but there likely is a reason for it. If
| you find that reason, a Note would be appreciated.
| 
| 
| Greeting,
| Joachim
| 
| --
| Joachim ?nomeata? Breitner
|   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
|   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
|   Debian Developer: nomeata at debian.org


From simonpj at microsoft.com  Mon Nov  3 13:28:26 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 3 Nov 2014 13:28:26 +0000
Subject: GHC Trac
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F38C0EE@DB3PRD3001MB020.064d.mgd.msft.net>

Is it just me, or is the GHC Trac soul-destroyingly slow at the moment?  IT takes minutes to load one page!

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141103/05ecf291/attachment.html>

From ggreif at gmail.com  Mon Nov  3 14:10:12 2014
From: ggreif at gmail.com (Gabor Greif)
Date: Mon, 3 Nov 2014 15:10:12 +0100
Subject: GHC Trac
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F38C0EE@DB3PRD3001MB020.064d.mgd.msft.net>
References: <618BE556AADD624C9C918AA5D5911BEF3F38C0EE@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CAK-hX0nOGd0zRRa8=qAtOomqM4Fd_aEZzXgwOsYxr3HDF+s6FA@mail.gmail.com>

Hopping from one ticket to the next takes about 5 seconds for me. I
call that very slow.

Cheers,

    Gabor

On 11/3/14, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> Is it just me, or is the GHC Trac soul-destroyingly slow at the moment?  IT
> takes minutes to load one page!
>
> Simon
>

From gintautas.miliauskas at gmail.com  Mon Nov  3 14:12:53 2014
From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas)
Date: Mon, 3 Nov 2014 15:12:53 +0100
Subject: GHC on Windows (extended/broad discussion)
In-Reply-To: <CAFC_MehmqrN5NgtJAn9FdD6WbTRt3c=68AkynbykOFMYQ_p-hA@mail.gmail.com>
References: <CAEs96n0LErrHqBL-N517Odg4kWLFvs9WtzUpeXXBAuhWAw813Q@mail.gmail.com>
 <CAFC_MehNi=hgEAXD4MgnDCfwauBc+j1rm54TzH-YxqeuMSsAhg@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F37F0D2@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAFC_Mejfumw4K5kQ1WBWJOG2VC57mOPnEP4QyyNUw3OY4bfF0A@mail.gmail.com>
 <54527870.66bbb40a.6c56.ffffb18b@mx.google.com>
 <CAFC_MejtEdnC1B4yAA6xezgYB1L=UzhGr4_LvQFqpZ4gRSuc6Q@mail.gmail.com>
 <CAFC_MehmqrN5NgtJAn9FdD6WbTRt3c=68AkynbykOFMYQ_p-hA@mail.gmail.com>
Message-ID: <CAFC_MeiXUYSVm_rDVsR=ZzuMYJESEKpGx0ErUeKSnQU+aCe_jg@mail.gmail.com>

> Alright, based on the votes let's do Wednesday (Nov 5) 8:00pm.
>

Sorry, forgot to specify the timezone: 8:00pm UTC.


-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141103/2ceff319/attachment.html>

From austin at well-typed.com  Mon Nov  3 14:16:46 2014
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 3 Nov 2014 08:16:46 -0600
Subject: Problem with installing "primitive" on Windows/i686
In-Reply-To: <CAFC_Mej4XBK9qyH-vnk43BAF=_T6sBn9zG2fvybPkVewU4UBLA@mail.gmail.com>
References: <CAFC_Mej4XBK9qyH-vnk43BAF=_T6sBn9zG2fvybPkVewU4UBLA@mail.gmail.com>
Message-ID: <CAEs96n08VxWD4QPU0Op_G0V_AQpL8RoAR-TB-Jh-ZvYZ7ObKaQ@mail.gmail.com>

Gintautas,

I'm afraid I don't quite know what's going on immediately, but at a
glance it seems to be some Cabal bug.

I'm not quite sure why it specifically has the 'includes' directive
set to primitive-memops.h, considering 'include-dirs' and 'c-sources'
are set properly.

Have you tried fiddling with any of these and seen any different behavior?

On Sun, Nov 2, 2014 at 4:53 PM, Gintautas Miliauskas
<gintautas.miliauskas at gmail.com> wrote:
> Installation of Alex in the msys2 i686 instructions is broken, more details
> in https://ghc.haskell.org/trac/ghc/ticket/9712. Before I spend more time on
> this, maybe someone knows off the bat what's going on?
>
> $ cabal install alex
> Resolving dependencies...
> Downloading primitive-0.5.4.0...
> Configuring primitive-0.5.4.0...
> Failed to install primitive-0.5.4.0
> Build log ( C:\Users\Gintas\AppData\Roaming\cabal\logs\primitive-0.5.4.0.log
> ):
> [1 of 1] Compiling Main             (
> C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\setup.hs,
> C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\Main.o
> )
> Linking
> C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\setup.exe
> ...
> Configuring primitive-0.5.4.0...
> setup-Simple-Cabal-1.18.1.3-i386-windows-ghc-7.8.3.exe: Missing dependency
> on
> a foreign library:
> * Missing (or bad) header file: primitive-memops.h
> This problem can usually be solved by installing the system package that
> provides this library (you may need the "-dev" version). If the library is
> already installed but in a non-standard location then you can use the flags
> --extra-include-dirs= and --extra-lib-dirs= to specify where it is.
> If the header file does exist, it may contain errors that are caught by the
> C
> compiler at the preprocessing stage. In this case you can re-run configure
> with the verbosity flag -v3 to see the error messages.
>
>
> --
> Gintautas Miliauskas
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From gintautas.miliauskas at gmail.com  Mon Nov  3 14:31:33 2014
From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas)
Date: Mon, 3 Nov 2014 15:31:33 +0100
Subject: GHC on Windows (extended/broad discussion)
In-Reply-To: <CAFC_MeiXUYSVm_rDVsR=ZzuMYJESEKpGx0ErUeKSnQU+aCe_jg@mail.gmail.com>
References: <CAEs96n0LErrHqBL-N517Odg4kWLFvs9WtzUpeXXBAuhWAw813Q@mail.gmail.com>
 <CAFC_MehNi=hgEAXD4MgnDCfwauBc+j1rm54TzH-YxqeuMSsAhg@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F37F0D2@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAFC_Mejfumw4K5kQ1WBWJOG2VC57mOPnEP4QyyNUw3OY4bfF0A@mail.gmail.com>
 <54527870.66bbb40a.6c56.ffffb18b@mx.google.com>
 <CAFC_MejtEdnC1B4yAA6xezgYB1L=UzhGr4_LvQFqpZ4gRSuc6Q@mail.gmail.com>
 <CAFC_MehmqrN5NgtJAn9FdD6WbTRt3c=68AkynbykOFMYQ_p-hA@mail.gmail.com>
 <CAFC_MeiXUYSVm_rDVsR=ZzuMYJESEKpGx0ErUeKSnQU+aCe_jg@mail.gmail.com>
Message-ID: <CAFC_Megr1aeUSdvy=MjoMvQfnTfiXzV1LB0Yw9bO_JLYu7XyCA@mail.gmail.com>

(Aaand I messed up the initial calendar invitation. It should be set to the
correct time now, 8pm UTC.)

On Mon, Nov 3, 2014 at 3:12 PM, Gintautas Miliauskas <
gintautas.miliauskas at gmail.com> wrote:

>
> Alright, based on the votes let's do Wednesday (Nov 5) 8:00pm.
>>
>
> Sorry, forgot to specify the timezone: 8:00pm UTC.
>
>
> --
> Gintautas Miliauskas
>



-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141103/cb6ace20/attachment.html>

From eir at cis.upenn.edu  Mon Nov  3 15:04:15 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 3 Nov 2014 10:04:15 -0500
Subject: RFC: Concrete syntax for pattern synonym type signatures
In-Reply-To: <alpine.DEB.2.10.1411031812500.2047@galaxy>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
Message-ID: <5282C912-B6A5-4A5B-9507-210DCD4D5C0F@cis.upenn.edu>

How about

> pattern type forall a. Num a => P :: forall c. (Eq a, Ord Bool, Show c) => c -> Bool -> T a Bool

or

> pattern type forall a. Num a => P <- forall c. (Eq a, Ord Bool, Show c) => c -> Bool -> T a Bool

for a unidirectional pattern. (Note that `::` became `<-`.)

This resembles the syntax for GADT-style data constructors, but with the universal constraints listed.

This may not be (much) better than the original form, but I like that it corresponds closely with at least one piece of existing syntax.

Richard

On Nov 3, 2014, at 5:13 AM, "Dr. ERDI Gergo" <gergo at erdi.hu> wrote:

> Background
> ----------
> 
> As explained on
> https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms#Staticsemantics
> the type of a pattern synonym can be fully described with the
> following pieces of information:
> 
> * If the pattern synonym is bidirectional
> * Universially-bound type variables, and required constraints on them
> * The type of the pattern itself, closed over the universially-bound type variables
> * Existentially-bound type variables, and the constraints provided by them
> * The types of the arguments, closed over the universially and
>  existentially bound type variables
> 
> Here's an example showing all of these axes in action:
> 
>    data T a b where
>      MkT :: (Eq a, Ord b, Show c) => a -> (b, b) -> c -> T a b
> 
>    pattern P x y = MkT 5 (y, True) x
> 
> In this case:
> 
> * The name of the pattern synonym is `P`
> * The pattern synonym is bidirectional
> * The universially-bound tyvars/required constraints are `forall a. Num a`
> * The type of the pattern is `T a Bool`
> * The existentially-bound tyvars/provided constraints are
>  `forall c. (Eq a, Ord Bool, Show c)`
> * The type of the arguments are `c` and `Bool`.
> 
> The problem, then, is finding a concrete syntax that captures all of
> this information. This syntax is needed for at least two purposes:
> 
> * Showing pattern synonym type information in Haddock/GHCi
> * Pattern synonym type signatures (#8584)
> 
> Current state of things
> -----------------------
> 
> GHCi 7.8.3 shows the type above as:
> 
> pattern (Eq t, Ord Bool, Show c) => P c Bool :: Num t => (T t Bool)
> 
> Not only does it not show directionality, I think this is very
> confusing in every other way as well, especially with explicit foralls:
> 
> pattern forall c. (Eq t, Ord Bool, Show c) => P c Bool :: forall t. Num t => (T t Bool)
> 
> I am currently working on implementing #8584, which means I need to
> parse these type signatures. I managed to get the above monstrosity to
> parse (unambigiously from actual pattern synonym definitions) by
> throwing in an extra 'type' keyword:
> 
> pattern type (Eq t, Ord Bool, Show c) => P c Bool :: Num t => (T t Bool)
> 
> Request for help
> ----------------
> 
> Surely we can do better than that! So let's come up with a nice syntax
> for pattern synonym type signatures. It will be used in the pattern
> synonym type signature annotations of GHC 7.10, and we could also
> retrofit it into GHC 7.8.4 and its Haddock, so that documentation
> generated with today's tools will look consistent with code you will
> be able to enter in tomorrow's version.
> 
> Bye,
> 	Gergo
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From eir at cis.upenn.edu  Mon Nov  3 15:11:14 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 3 Nov 2014 10:11:14 -0500
Subject: GHC Trac
In-Reply-To: <CAK-hX0nOGd0zRRa8=qAtOomqM4Fd_aEZzXgwOsYxr3HDF+s6FA@mail.gmail.com>
References: <618BE556AADD624C9C918AA5D5911BEF3F38C0EE@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAK-hX0nOGd0zRRa8=qAtOomqM4Fd_aEZzXgwOsYxr3HDF+s6FA@mail.gmail.com>
Message-ID: <19B8518D-47AA-4E71-9712-59EF9CC4C6F2@cis.upenn.edu>

It's never the speediest, but I don't feel my soul is being destroyed. Seems about its usual slowness to me.

Richard

On Nov 3, 2014, at 9:10 AM, Gabor Greif <ggreif at gmail.com> wrote:

> Hopping from one ticket to the next takes about 5 seconds for me. I
> call that very slow.
> 
> Cheers,
> 
>    Gabor
> 
> On 11/3/14, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>> Is it just me, or is the GHC Trac soul-destroyingly slow at the moment?  IT
>> takes minutes to load one page!
>> 
>> Simon
>> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From david.feuer at gmail.com  Mon Nov  3 15:16:08 2014
From: david.feuer at gmail.com (David Feuer)
Date: Mon, 3 Nov 2014 10:16:08 -0500
Subject: thenIO removal
Message-ID: <CAMgWh9v3uCmahU0ioVozssv9VboHWkrm9Xr=Gerjg1cqyvntmA@mail.gmail.com>

Simon Peyton Jones wrote:

>
> It's not a big deal.
>
> You can probably replace both those bindIOName uses with bindMName (i.e
> (>>=)), in TcRnDriver.  That will just make GHCi generate code with uses of
> overloaded (>>=) that must be evaluated, rather than calling bindIO
> directly.  It should work just fine, but it'll make everything a tiny bit
> slower and more indirect.  If it simplified the code a lot, then fine, but
> it doesn't really.  So I'm inclined to leave it.
>

That's fine; I don't know why my search didn't turn that up (perhaps it's
referenced in some weird indirect way). If we're going to keep thenIO, we
should surely define (*>) = (>>) = thenIO, right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141103/3a8f5452/attachment.html>

From gintautas.miliauskas at gmail.com  Mon Nov  3 16:30:32 2014
From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas)
Date: Mon, 3 Nov 2014 17:30:32 +0100
Subject: ghc panic during build
Message-ID: <CAFC_Mei-KwGK4Av=_tFf-ab5Cpnn4On=-YjPjtjTwmafFe_Y7w@mail.gmail.com>

Just got this during a build:

"inplace/bin/ghc-stage1.exe" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O
-Werror -Wall -H64m -O0    -this-package-key base_ESD4aQEEWwsHtYJVc1BwtJ
-hide-all-packages -i -ilibraries/base/.
-ilibraries/base/dist-install/build
-ilibraries/base/dist-install/build/autogen
-Ilibraries/base/dist-install/build
-Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include
-optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include
-optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package-key
ghcpr_BE58KUgBe9ELCsPXiJ1Q2r -package-key integ_BcPVjqcazPNGsNFG4agFty
-package-key rts -this-package-key base -XHaskell2010 -O2 -O -dcore-lint
-fno-warn-deprecated-flags -fno-warn-tabs  -no-user-package-db -rtsopts
 -odir libraries/base/dist-install/build -hidir
libraries/base/dist-install/build -stubdir
libraries/base/dist-install/build   -c libraries/base/./GHC/TypeLits.hs -o
libraries/base/dist-install/build/GHC/TypeLits.o
ghc-stage1.exe: panic! (the 'impossible' happened)
  (GHC version 7.9.20141031 for x86_64-unknown-mingw32):
        Ix{Int}.index: Index (2053) out of range ((0,10))

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

libraries/base/ghc.mk:4: recipe for target
'libraries/base/dist-install/build/GHC/TypeLits.o' failed

I may have been building in a non-clean repository after a git pull though,
could that have caused this?

-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141103/cc9f4327/attachment.html>

From simonpj at microsoft.com  Mon Nov  3 16:48:29 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 3 Nov 2014 16:48:29 +0000
Subject: ghc panic during build
In-Reply-To: <CAFC_Mei-KwGK4Av=_tFf-ab5Cpnn4On=-YjPjtjTwmafFe_Y7w@mail.gmail.com>
References: <CAFC_Mei-KwGK4Av=_tFf-ab5Cpnn4On=-YjPjtjTwmafFe_Y7w@mail.gmail.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F38C807@DB3PRD3001MB020.064d.mgd.msft.net>

Usually this is to do with stale .hi files

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Gintautas Miliauskas
Sent: 03 November 2014 16:31
To: ghc-devs at haskell.org
Subject: ghc panic during build

Just got this during a build:

"inplace/bin/ghc-stage1.exe" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O -Werror -Wall -H64m -O0    -this-package-key base_ESD4aQEEWwsHtYJVc1BwtJ -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include   -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package-key ghcpr_BE58KUgBe9ELCsPXiJ1Q2r -package-key integ_BcPVjqcazPNGsNFG4agFty -package-key rts -this-package-key base -XHaskell2010 -O2 -O -dcore-lint -fno-warn-deprecated-flags -fno-warn-tabs  -no-user-package-db -rtsopts      -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build   -c libraries/base/./GHC/TypeLits.hs -o libraries/base/dist-install/build/GHC/TypeLits.o
ghc-stage1.exe: panic! (the 'impossible' happened)
  (GHC version 7.9.20141031 for x86_64-unknown-mingw32):
        Ix{Int}.index: Index (2053) out of range ((0,10))

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

libraries/base/ghc.mk:4<http://ghc.mk:4>: recipe for target 'libraries/base/dist-install/build/GHC/TypeLits.o' failed

I may have been building in a non-clean repository after a git pull though, could that have caused this?

--
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141103/3ce7f8c3/attachment.html>

From mlen at mlen.pl  Mon Nov  3 17:18:48 2014
From: mlen at mlen.pl (Mateusz Lenik)
Date: Mon, 3 Nov 2014 18:18:48 +0100
Subject: Resurrecting ticky code
Message-ID: <20141103171848.GA73387@polaris.local>

Hi *,

Recently I started working on resurrecting ticky code[1] and got to the point
where I can compile and run bumpHistogram as well as accompanying code in RTS.

Work in progress version can be found at [2], but there are few things
remaining to get it working: 

* missing calls to tickyReturnNewCon, tickyUnboxedTupleReturn and
  tickyVectoredReturn need to be added. Unfortunately I'm not familiar with the
  code enough to find the right place to insert them.

* magic eight needs to be replaced by a constant both Haskell and C files.
  Preprocessor macro seems to be the simplest choice here, however I don't find
  it the cleanest way to do it.

I would be very grateful if someone could take a look and point me into the
right direction.


Best,
Mateusz

1: https://ghc.haskell.org/trac/ghc/ticket/8308
2: https://github.com/mlen/ghc/compare/ticky

-- 
Mateusz Lenik
GPG: B865 E86A D36C 11A5 C1F8  C1D9 AAD4 CEC9 6B94 92C4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141103/b44151ea/attachment-0001.sig>

From simonpj at microsoft.com  Mon Nov  3 17:28:49 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 3 Nov 2014 17:28:49 +0000
Subject: Major commit to the constraint solver
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F38D4BA@DB3PRD3001MB020.064d.mgd.msft.net>

Friends

I've pushed branch wip/new-flatten-skolems-Oct14.  (It has some rebasing near the top.)

It branches off master some a few days ago; i.e. it is almost completely up to date.

Can you try building it?  I want to push it to HEAD, but would like some independent validation first.

Three things don't validate for me:

*         Several tests fail with ioManagerWakeup problems: reported as Trac #9722

*         ghcirun002 experiences stack overflow in the bytecode interpreter, but so does HEAD: Trac #9741

*         I get an odd wibble in safePk01, see this thread<https://www.haskell.org/pipermail/ghc-devs/2014-November/007065.html> with Edward

I'd like to push to master soon.

Thanks

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141103/43a2254c/attachment.html>

From eir at cis.upenn.edu  Mon Nov  3 18:07:55 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 3 Nov 2014 13:07:55 -0500
Subject: ghc panic during build
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F38C807@DB3PRD3001MB020.064d.mgd.msft.net>
References: <CAFC_Mei-KwGK4Av=_tFf-ab5Cpnn4On=-YjPjtjTwmafFe_Y7w@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F38C807@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <7019F46D-3177-44A0-87D0-52B6A8E1C97C@cis.upenn.edu>

Try `make clean` in the libraries directory and then building again. I usually need to run `make` twice in a row to build after cleaning the libraries.

On Nov 3, 2014, at 11:48 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> Usually this is to do with stale .hi files
>  
> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Gintautas Miliauskas
> Sent: 03 November 2014 16:31
> To: ghc-devs at haskell.org
> Subject: ghc panic during build
>  
> Just got this during a build:
> 
>  
> 
> "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O -Werror -Wall -H64m -O0    -this-package-key base_ESD4aQEEWwsHtYJVc1BwtJ -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include   -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package-key ghcpr_BE58KUgBe9ELCsPXiJ1Q2r -package-key integ_BcPVjqcazPNGsNFG4agFty -package-key rts -this-package-key base -XHaskell2010 -O2 -O -dcore-lint -fno-warn-deprecated-flags -fno-warn-tabs  -no-user-package-db -rtsopts      -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build   -c libraries/base/./GHC/TypeLits.hs -o libraries/base/dist-install/build/GHC/TypeLits.o
> 
> ghc-stage1.exe: panic! (the 'impossible' happened)
> 
>   (GHC version 7.9.20141031 for x86_64-unknown-mingw32):
> 
>         Ix{Int}.index: Index (2053) out of range ((0,10))
> 
>  
> 
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
> 
>  
> 
> libraries/base/ghc.mk:4: recipe for target 'libraries/base/dist-install/build/GHC/TypeLits.o' failed
> 
>  
> 
> I may have been building in a non-clean repository after a git pull though, could that have caused this?
> 
>  
> 
> --
> 
> Gintautas Miliauskas
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141103/777f8c6b/attachment.html>

From mail at joachim-breitner.de  Mon Nov  3 18:18:19 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 03 Nov 2014 19:18:19 +0100
Subject: Major commit to the constraint solver
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F38D4BA@DB3PRD3001MB020.064d.mgd.msft.net>
References: <618BE556AADD624C9C918AA5D5911BEF3F38D4BA@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <1415038699.1388.8.camel@joachim-breitner.de>

Hi,


Am Montag, den 03.11.2014, 17:28 +0000 schrieb Simon Peyton Jones:
> I?ve pushed branch wip/new-flatten-skolems-Oct14.  (It has some
> rebasing near the top.)
>  
> It branches off master some a few days ago; i.e. it is almost
> completely up to date.
>  
> Can you try building it?  I want to push it to HEAD, but would like
> some independent validation first.

Travis build branches automatically, and is already trying to build it:
https://travis-ci.org/ghc/ghc/builds/39856856

It just finished, but it is not completely happy:

Actual stderr output differs from expected:
--- /dev/null	2014-11-03 17:30:32.067943898 +0000
+++ ./indexed-types/should_compile/PushedInAsGivens.comp.stderr	2014-11-03 18:11:53.225519481 +0000
@@ -0,0 +1,27 @@
+
+PushedInAsGivens.hs:10:31:
+    Couldn't match expected type ?a1? with actual type ?a?
+      because type variable ?a1? would escape its scope
+    This (rigid, skolem) type variable is bound by
+      the type signature for foo :: (F Int ~ [a1]) => a1 -> Int
+      at PushedInAsGivens.hs:9:20-44
+    Relevant bindings include
+      x :: a1 (bound at PushedInAsGivens.hs:10:17)
+      foo :: a1 -> Int (bound at PushedInAsGivens.hs:10:13)
+      y :: a (bound at PushedInAsGivens.hs:9:5)
+      bar :: a -> (a, Int) (bound at PushedInAsGivens.hs:9:1)
+    In the expression: y
+    In the first argument of ?length?, namely ?[x, y]?
+
+PushedInAsGivens.hs:11:15:
+    Couldn't match expected type ?[a]? with actual type ?F Int?
+    Relevant bindings include
+      y :: a (bound at PushedInAsGivens.hs:9:5)
+      bar :: a -> (a, Int) (bound at PushedInAsGivens.hs:9:1)
+    In the expression: foo y
+    In the expression: (y, foo y)
+    In the expression:
+      let
+        foo :: (F Int ~ [a]) => a -> Int
+        foo x = length [...]
+      in (y, foo y)
=====> T2715(normal) 3281 of 4140 [0, 0, 0] 
*** unexpected failure for PushedInAsGivens(normal)

Actual stdout output differs from expected:
--- ./safeHaskell/check/pkg01/safePkg01.stdout	2014-11-03 17:30:57.327803827 +0000
+++ ./safeHaskell/check/pkg01/safePkg01.run.stdout	2014-11-03 18:12:11.178706914 +0000
@@ -29,17 +29,17 @@
 require own pkg trusted: True
 
 M_SafePkg6
-package dependencies: array-0.5.0.1 at array_<HASH>
+package dependencies: array-0.5.0.1 base-4.8.0.0*
 trusted: trustworthy
 require own pkg trusted: False
 
 M_SafePkg7
-package dependencies: array-0.5.0.1 at array_<HASH>
+package dependencies: array-0.5.0.1 base-4.8.0.0*
 trusted: safe
 require own pkg trusted: False
 
 M_SafePkg8
-package dependencies: array-0.5.0.1 at array_<HASH>
+package dependencies: array-0.5.0.1 base-4.8.0.0
 trusted: trustworthy
 require own pkg trusted: False
 
*** unexpected failure for safePkg01(normal)

Is there more you want us to do besides what Travis just did for us?

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141103/240c1b0f/attachment.sig>

From jan.stolarek at p.lodz.pl  Mon Nov  3 18:57:16 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Mon, 3 Nov 2014 19:57:16 +0100
Subject: [GHC] #9358: Improve flag description in the user guide
In-Reply-To: <063.ea01e100738402f9155cc536f2ed235b@haskell.org>
References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org>
 <063.ea01e100738402f9155cc536f2ed235b@haskell.org>
Message-ID: <201411031957.16775.jan.stolarek@p.lodz.pl>

>  Jan, you said you'd be willing to do this updating before 7.10
Yes, that's the plan. The question is do I have to make it before the mid-November feature freeze? 
Austin, what's your opinion?
 
>  So far as I can see, there simply is no list of what is enabled by -O or
>  -O2.
I can make such a list if you want.

>  It's more than a simple on/off  thing because the order matters.
Hmm.... in which cases does it matter? Can you give an example?

Janek

From jan.stolarek at p.lodz.pl  Mon Nov  3 19:20:26 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Mon, 3 Nov 2014 20:20:26 +0100
Subject: [commit: ghc] master: Add GHC.Prim.oneShot (c271e32)
In-Reply-To: <20141102180413.A14C23A300@ghc.haskell.org>
References: <20141102180413.A14C23A300@ghc.haskell.org>
Message-ID: <201411032020.26081.jan.stolarek@p.lodz.pl>

Perhaps this should be documented in the User's Guide?

Janek

Dnia niedziela, 2 listopada 2014, git at git.haskell.org napisa?:
> Repository : ssh://git at git.haskell.org/ghc
>
> On branch  : master
> Link       :
> http://ghc.haskell.org/trac/ghc/changeset/c271e32eac65ee95ba1aacc72ed1b24b5
>8ef17ad/ghc
>
> >---------------------------------------------------------------
>
> commit c271e32eac65ee95ba1aacc72ed1b24b58ef17ad
> Author: Joachim Breitner <mail at joachim-breitner.de>
> Date:   Sun Jan 26 11:36:23 2014 +0000
>
>     Add GHC.Prim.oneShot
>
>     to allow the programer to explictitly set the oneShot flag. This helps
>     with #7994 and will be used in left folds. Also see
>     https://ghc.haskell.org/trac/ghc/wiki/OneShot
>
>     This commit touches libraries/base/GHC/Event/Manager.hs (which used to
>     have a local definition of the name oneShot) to avoid a shadowing
> error.
>
>     Differential Revision: https://phabricator.haskell.org/D392
>
> >---------------------------------------------------------------
>
> c271e32eac65ee95ba1aacc72ed1b24b58ef17ad
>  compiler/basicTypes/MkId.lhs                       | 42
> ++++++++++++++++++++-- compiler/prelude/PrelNames.lhs                     |
>  3 +-
>  libraries/base/GHC/Event/Manager.hs                |  6 ++--
>  libraries/ghc-prim/GHC/Magic.hs                    | 11 +++++-
>  testsuite/.gitignore                               |  1 +
>  .../should_compile => simplCore/prog003}/Makefile  |  0
>  testsuite/tests/simplCore/prog003/OneShot1.hs      | 21 +++++++++++
>  testsuite/tests/simplCore/prog003/OneShot2.hs      | 24 +++++++++++++
>  .../simplCore/prog003/simplCore.oneShot.stderr     | 21 +++++++++++
>  .../simplCore/prog003/simplCore.oneShot.stdout     |  1 +
>  testsuite/tests/simplCore/prog003/test.T           |  7 ++++
>  11 files changed, 130 insertions(+), 7 deletions(-)
>
> Diff suppressed because of size. To see it, use:
>
>     git diff-tree --root --patch-with-stat --no-color --find-copies-harder
> --ignore-space-at-eol --cc c271e32eac65ee95ba1aacc72ed1b24b58ef17ad
> _______________________________________________
> ghc-commits mailing list
> ghc-commits at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits



From mail at joachim-breitner.de  Mon Nov  3 19:26:57 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 03 Nov 2014 20:26:57 +0100
Subject: [commit: ghc] master: Add GHC.Prim.oneShot (c271e32)
In-Reply-To: <201411032020.26081.jan.stolarek@p.lodz.pl>
References: <20141102180413.A14C23A300@ghc.haskell.org>
 <201411032020.26081.jan.stolarek@p.lodz.pl>
Message-ID: <1415042817.3423.1.camel@joachim-breitner.de>

Hi,


Am Montag, den 03.11.2014, 20:20 +0100 schrieb Jan Stolarek:
> Perhaps this should be documented in the User's Guide?

I don?t like having documentation scattered around, so I?d rather put
all documentation in a singe place: The haddocks for this function.

I should add a link to
https://www.haskell.org/ghc/docs/latest/html/users_guide/special-ids.html
though. Done.

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141103/e14fa974/attachment.sig>

From jan.stolarek at p.lodz.pl  Mon Nov  3 19:35:14 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Mon, 3 Nov 2014 20:35:14 +0100
Subject: Resurrecting ticky code
In-Reply-To: <20141103171848.GA73387@polaris.local>
References: <20141103171848.GA73387@polaris.local>
Message-ID: <201411032035.14095.jan.stolarek@p.lodz.pl>

Hi,

I originally reported #8308 so I suppose I could help :-) But I need to find some time to take a 
look at your code - the ticket was reported over a year ago and I admit I don't remember much. 
I'll take a look at your patch soon (hopefully this week).

Janek

Dnia poniedzia?ek, 3 listopada 2014, Mateusz Lenik napisa?:
> Hi *,
>
> Recently I started working on resurrecting ticky code[1] and got to the
> point where I can compile and run bumpHistogram as well as accompanying
> code in RTS.
>
> Work in progress version can be found at [2], but there are few things
> remaining to get it working:
>
> * missing calls to tickyReturnNewCon, tickyUnboxedTupleReturn and
>   tickyVectoredReturn need to be added. Unfortunately I'm not familiar with
> the code enough to find the right place to insert them.
>
> * magic eight needs to be replaced by a constant both Haskell and C files.
>   Preprocessor macro seems to be the simplest choice here, however I don't
> find it the cleanest way to do it.
>
> I would be very grateful if someone could take a look and point me into the
> right direction.
>
>
> Best,
> Mateusz
>
> 1: https://ghc.haskell.org/trac/ghc/ticket/8308
> 2: https://github.com/mlen/ghc/compare/ticky



From ezyang at mit.edu  Mon Nov  3 21:23:29 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Mon, 03 Nov 2014 13:23:29 -0800
Subject: Major commit to the constraint solver
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F38D4BA@DB3PRD3001MB020.064d.mgd.msft.net>
References: <618BE556AADD624C9C918AA5D5911BEF3F38D4BA@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <1415049246-sup-6696@sabre>

Excerpts from Simon Peyton Jones's message of 2014-11-03 09:28:49 -0800:
> *         I get an odd wibble in safePk01, see this thread<https://www.haskell.org/pipermail/ghc-devs/2014-November/007065.html> with Edward

Hello Simon,

Here's what you should do for the safePkg01 wibble:

    1. Apply the attached patch to your tree (this will
       break the tests temporarily.)

    2. Accept the new output for safePkg01 which no longer has
       the package keys in it.

    3. Remove the noramliseArrayPackageKey goop from all.T

I could do the changes myself but it's your branch so I don't want to
touch it unduly.

BTW, here is why your change removed the package keys: --show-iface
previously pretty-printed as if -dppr-debug was always on.  You touched
this code so that --show-iface only prints in debug style if you
actually asked for -dppr-debug; this changed the output of these tests.

Edward
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Tweak-Safe-Haskell-test-to-show-iface-with-large-col.patch
Type: application/octet-stream
Size: 3609 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141103/b5142aec/attachment.obj>

From gintautas.miliauskas at gmail.com  Mon Nov  3 21:37:46 2014
From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas)
Date: Mon, 3 Nov 2014 22:37:46 +0100
Subject: Automating GHC build for Windows
In-Reply-To: <CAFC_Meim57TpLXa5-r+-pm1u5Bhot++TQ3H_zLiWkcXq8mtMkw@mail.gmail.com>
References: <CAD78TFJ+2BvKxCK9nCxsPDVR=tMaEhWESEknXAwp_zCJ_P+Amg@mail.gmail.com>
 <1413916715.326367.181663173.2FBCEE30@webmail.messagingengine.com>
 <CAEs96n1vizQgobwsOpxYztAtf5bBtoaCK552DtysO4cVLaYF7Q@mail.gmail.com>
 <CAHnG2Cwi3bwNa_X+gk4vdHFKm1YbyQwv1nHgdhJA+RWtS-tCOQ@mail.gmail.com>
 <CAFC_MegfiYS6T6ahtMhxa9_gNRrTGa4xW6pUWjonTZr-XJn8Pw@mail.gmail.com>
 <CAHnG2CybhW6K=KBGG4Kw-ygjLLcxKnYMW7xkGZdT-8s58_dkSA@mail.gmail.com>
 <CAFC_MejcnCQpEE=Ej3Dojnw8-4APK_zWYgnAjn=e95wP4e9nYQ@mail.gmail.com>
 <CAHnG2CyLNJ+zvxASn7_0CM59Rg9tf9G3hTOD8VmjvYjkwbLV7w@mail.gmail.com>
 <CAFC_Meh1QiF5ABja_ozjewMg=FS8r78oUz8bxoP=BNUXANkskg@mail.gmail.com>
 <CAHnG2CxK9QC-yN+hGz-EkwK39MrXQvekVNxFpRvN-gLgsh7Jyg@mail.gmail.com>
 <CAFC_Meim57TpLXa5-r+-pm1u5Bhot++TQ3H_zLiWkcXq8mtMkw@mail.gmail.com>
Message-ID: <CAFC_MejbxTLQOwFst3xGhXVksK7KTS-cyqwRE0PLV99zT53e0g@mail.gmail.com>

Potentially related issues:

https://github.com/haskell/cabal/issues/1698
https://ghc.haskell.org/trac/ghc/ticket/2924
https://ghc.haskell.org/trac/ghc/ticket/3231
https://ghc.haskell.org/trac/ghc/ticket/2650

On Mon, Nov 3, 2014 at 1:24 AM, Gintautas Miliauskas <
gintautas.miliauskas at gmail.com> wrote:

> Without knowing much about the surrounding code, I would try two things
> here.
>
> 1. Is it possible that the file was opened by for writing and not closed
> because of lazy I/O?
>
> 2. Since the error is completely deterministic, you could try "freezing"
> evaluation right before the crash (either by a breakpoint in ghci or just
> adding a time delay / console read on the code), and then using a utility
> app
> <http://serverfault.com/questions/1966/how-do-you-find-what-process-is-holding-a-file-open-in-windows> to
> check which process is keeping the file open, whether it's the same process
> or something else.
>
> If any of the involved paths is a directory, this could be #8482
> <https://ghc.haskell.org/trac/ghc/ticket/8482>, although that does not
> seem to be the case.
>
> On Thu, Oct 30, 2014 at 7:13 PM, P?li G?bor J?nos <pali.gabor at gmail.com>
> wrote:
>
>> 2014-10-30 16:24 GMT+01:00 Gintautas Miliauskas <gintautas at miliauskas.lt
>> >:
>> > I wonder what's going on with DeleteFile. What is the step that's
>> failing?
>>
>> Basically it happens at the same point, that is, at the "configure"
>> phase but at the ghc-prim package.  Note that the previously mentioned
>> workaround has a "removeFile" action [1], I guess the failure of that
>> triggers the DeleteFile exception.
>>
>> > Can you post the log?
>>
>> "inplace/bin/ghc-cabal.exe" configure libraries/ghc-prim dist-install
>> "" --with-ghc="C:/msys64/home/ghc-builder/ghc/inplace/bin/ghc-stage1.exe"
>> --with-ghc-pkg="C:/msys64/home/ghc-builder/ghc/inplace/bin/ghc-pkg.exe"
>> --flag=include-ghc-prim --disable-library-for-ghci
>> --enable-library-vanilla --enable-library-for-ghci
>> --enable-library-profiling --disable-shared
>> --configure-option=CFLAGS=" -U__i686 -march=i686 -fno-stack-protector
>>  " --configure-option=LDFLAGS="   " --configure-option=CPPFLAGS="   "
>> --gcc-options=" -U__i686 -march=i686 -fno-stack-protector       "
>> --with-gcc="C:/msys64/home/ghc-builder/ghc/inplace/mingw/bin/gcc.exe"
>> --with-ld="C:/msys64/home/ghc-builder/ghc/inplace/mingw/bin/ld.exe"
>>
>> --configure-option=--with-cc="C:/msys64/home/ghc-builder/ghc/inplace/mingw/bin/gcc.exe"
>> --with-ar="/usr/bin/ar" --with-alex="/usr/local/bin/alex"
>> --with-happy="/usr/local/bin/happy"
>> Configuring ghc-prim-0.3.1.0...
>> ghc-cabal.exe: DeleteFile "dist-install\\setup-config": permission
>> denied (The process cannot access the file because it is being used by
>> another process.)
>> libraries/ghc-prim/ghc.mk:4: recipe for target
>> 'libraries/ghc-prim/dist-install/package-data.mk' failed
>> make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1
>> Makefile:71: recipe for target 'all' failed
>>
>> > I also wonder why this issue is not arising on other Windows machines...
>>
>> As the comment in the workaround goes, it has a "Big fat hairy race
>> condition".  Therefore I am inclined to believe that it may be a
>> problem for other systems as well, but I am the most unfortunate one
>> who hits this error with 100% probability :-)
>>
>> [1]
>> https://github.com/ghc/ghc/blob/master/libraries/bin-package-db/GHC/PackageDb.hs#L267
>>
>
>
>
> --
> Gintautas Miliauskas
>



-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141103/e447c434/attachment-0001.html>

From gintautas.miliauskas at gmail.com  Mon Nov  3 23:07:09 2014
From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas)
Date: Tue, 4 Nov 2014 00:07:09 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
Message-ID: <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>

+ghc-devs

Hi Ray,

thanks for the feedback. ghc-stage1 is a native application, it is built
using a host ghc and a mingw gcc bundled with the ghc distribution (in
order to keep Windows builds more predictable). The thing is, the same
builds (using make) that were stable on cygwin seem to be crashing on
msys2, even though the (bundled) gcc used for the build is the same. It
could be that msys2 is triggering a bug in ghc somehow, but it could be
something going on in msys2 itself.

The tricky part is that the crashes are rare, one in thousands of ghc
invocations within a make build, and I'm having trouble pinning one down to
investigate. I'll try some basic tracing first, but ideas for something
more sophisticated would be very helpful.

A PKGBUILD for ghc should be feasible, although the bootstrapping is a bit
tricky (some Haskell tools need to be preinstalled). I'm not sure how
useful it would be since for Windows there is already a nicely packaged
native Haskell Platform installer.


On Mon, Nov 3, 2014 at 3:30 AM, Ray Donnelly <mingw.android at gmail.com>
wrote:

> On Sun, Nov 2, 2014 at 11:45 PM, Gintautas Miliauskas
> <gintautas.miliauskas at gmail.com> wrote:
> > Hello,
> >
> > I have been working on building GHC, the Glasgow Haskell Compiler, on
> > Windows using msys2 [1]. We have been having some strange trouble with
> ghc
> > segfaulting during the bootstrapping process (i.e., during make). The
> > crashes are not very hard to reproduce, but they are not predictable
> either.
> > This is almost certainly a bug in ghc itself and not with msys2 (although
> > the crashes do not seem to occur in other environments), but I've been
> > having some trouble pinning it down.
> >
>
> Hi Gintuatas,
>
> Great. I spotted that MSYS2 was the recommended env. for GHC on
> Windows, hopefully it will remain so!
>
> > What's a good way to debug such crashes? Is it possible to somehow stop
> the
> > ghc process when it segfaults and attach gdb, or to dump core somehow for
> > later inspection?
> >
> > [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
> >
> > Here's one example crash:
> >
> > "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf  o -hcsuf hc -static  -H32m
> -O
> > -Werror -Wall -H64m -O0    -this-package-key ghc_4ugNArSu5ba0Z1uHXrbTlU
> > -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm
> > -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci
> > -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main
> > -icompiler/nativeGen -icompiler/parser -icompiler/prelude
> > -icompiler/profiling -icompiler/rename -icompiler/simplCore
> > -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn
> > -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils
> > -icompiler/vectorise -icompiler/stage2/build
> -icompiler/stage2/build/autogen
> > -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/.
> > -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build
> > -Icompiler/stage2   -optP-DGHCI -optP-include
> > -optPcompiler/stage2/build/autogen/cabal_macros.h -package-key
> > Win32_43THQMouBnk2wpnouztX1X -package-key array_GX4NwjS8xZkC2ZPtjgwhnz
> > -package-key base_ESD4aQEEWwsHtYJVc1BwtJ -package-key
> > binpa_17GphrLqCXt1H1lm4Kse1p -package-key bytes_Kc0PyaputnzDnBdZW0y2Gv
> > -package-key conta_ChF4XLXB9JmByIycPzerow -package-key
> > direc_HU5aFxMIQNwGQFzisjuinu -package-key filep_34DFDFT9FVD9pRLLgh8IdQ
> > -package-key hoopl_IZAd44CED5NCOlpg8p2Kaj -package-key
> > hpc_1QTsfQSN40FHN9p3mydARY -package-key proce_7ZlAbRkwiRO8qgXx3NNP0G
> > -package-key templ_F6UJgDtBcDIFWuHmMGEFzy -package-key
> > time_HGs4JcQCd4wF6U8vJQ5fNH -package-key trans_5jw4w9yTgmZ89ByuixDAKP
> -Wall
> > -fno-warn-name-shadowing -this-package-key ghc -XHaskell2010
> > -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O2
> > -fwarn-tabs -O -dcore-lint  -no-user-package-db -rtsopts      -odir
> > compiler/stage2/build -hidir compiler/stage2/build -stubdir
> > compiler/stage2/build   -c compiler/basicTypes/UniqSupply.lhs -o
> > compiler/stage2/build/UniqSupply.o
> >
> > compiler/ghc.mk:657: recipe for target
> 'compiler/stage2/build/UniqSupply.o'
> > failed
> > make[1]: *** [compiler/stage2/build/UniqSupply.o] Segmentation fault
> >
>
> Well, it's pretty much the same story as with Linux. Build the
> executable and as many libraries as you can with (something like)
> "-ggdb -O0" then use gdb command line or some IDE of choice.
> Personally I use Qt Creator (we have packages for this) as it can
> debug external programs and, even though I don't dislike command
> lines, I find debugging from them a bit too masochistic.
>
> Is ghc-stage1.exe an MSYS2 program or a native one? Which compiler is
> it built with exactly?
>
> What would be involved in creating a PKGBUILD for ghc? We'd love to
> have one, and it'd certainly make me a lot more inclined to dive in to
> see what's going on if one existed already.
>
> Ray.
>
> >
> > --
> > Gintautas Miliauskas
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Msys2-users mailing list
> > Msys2-users at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/msys2-users
> >
>



-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141104/f56327ff/attachment.html>

From david.macek.0 at gmail.com  Mon Nov  3 23:55:57 2014
From: david.macek.0 at gmail.com (David Macek)
Date: Tue, 04 Nov 2014 00:55:57 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
Message-ID: <5458160D.5000305@gmail.com>

On 4. 11. 2014 0:07, Gintautas Miliauskas wrote:
> A PKGBUILD for ghc should be feasible, although the bootstrapping is a bit tricky (some Haskell tools need to be preinstalled). I'm not sure how useful it would be since for Windows there is already a nicely packaged native Haskell Platform installer.

It definitely helps MSYS2 users by providing an easily installable ghc package. That in turn could help with setting up ghc development environment. Hopefully after Windows ghc migrates to gcc 4.8, ghc package will be able to use the MSYS2 packaged toolchain to reduce duplication.

I have this so far, but I give no guarantees: https://github.com/elieux/MINGW-packages/tree/ghc

To use:
- download ghc and put it in PATH
- optionally alter ghc/lib/settings to use MSYS2 toolchain instead of the bundled one (see below)
- use cabal-install PKGBUILD to build Cabal and put it in PATH
- use built Cabal to download and build Alex and Happy and put them in PATH (I think they're installed somewhere inside AppData by default)
- run ghc PKGBUILD

Related: https://www.haskell.org/pipermail/ghc-devs/2014-October/006759.html

My ghc/lib/settings (from version 7.6.3):

[("GCC extra via C opts", " -fwrapv"),
 ("C compiler command", "gcc.exe"),
 ("C compiler flags", " -fno-stack-protector  -Wl,--hash-size=31 -Wl,--reduce-memory-overheads"),
 ("ar command", "ar.exe"),
 ("ar flags", "q"),
 ("ar supports at file", "YES"),
 ("touch command", "$topdir/touchy.exe"),
 ("dllwrap command", "dllwrap.exe"),
 ("windres command", "windres.exe"),
 ("perl command", "perl.exe"),
 ("target os", "OSMinGW32"),
 ("target arch", "ArchX86_64"),
 ("target word size", "8"),
 ("target has GNU nonexec stack", "False"),
 ("target has .ident directive", "True"),
 ("target has subsections via symbols", "False"),
 ("LLVM llc command", ""),
 ("LLVM opt command", "")
 ]

-- 
David Macek

From gintautas.miliauskas at gmail.com  Tue Nov  4 00:05:51 2014
From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas)
Date: Tue, 4 Nov 2014 01:05:51 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <5458160D.5000305@gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
 <5458160D.5000305@gmail.com>
Message-ID: <CAFC_MejW=7bLLcg8bByk7+Pm1gEWNtVfew8dchoTKK4ejsD3ZA@mail.gmail.com>

Nice!

This needs a host ghc (with alex and happy) preinstalled, correct?

On Tue, Nov 4, 2014 at 12:55 AM, David Macek <david.macek.0 at gmail.com>
wrote:

> On 4. 11. 2014 0:07, Gintautas Miliauskas wrote:
> > A PKGBUILD for ghc should be feasible, although the bootstrapping is a
> bit tricky (some Haskell tools need to be preinstalled). I'm not sure how
> useful it would be since for Windows there is already a nicely packaged
> native Haskell Platform installer.
>
> It definitely helps MSYS2 users by providing an easily installable ghc
> package. That in turn could help with setting up ghc development
> environment. Hopefully after Windows ghc migrates to gcc 4.8, ghc package
> will be able to use the MSYS2 packaged toolchain to reduce duplication.
>
> I have this so far, but I give no guarantees:
> https://github.com/elieux/MINGW-packages/tree/ghc
>
> To use:
> - download ghc and put it in PATH
> - optionally alter ghc/lib/settings to use MSYS2 toolchain instead of the
> bundled one (see below)
> - use cabal-install PKGBUILD to build Cabal and put it in PATH
> - use built Cabal to download and build Alex and Happy and put them in
> PATH (I think they're installed somewhere inside AppData by default)
> - run ghc PKGBUILD
>
> Related:
> https://www.haskell.org/pipermail/ghc-devs/2014-October/006759.html
>
> My ghc/lib/settings (from version 7.6.3):
>
> [("GCC extra via C opts", " -fwrapv"),
>  ("C compiler command", "gcc.exe"),
>  ("C compiler flags", " -fno-stack-protector  -Wl,--hash-size=31
> -Wl,--reduce-memory-overheads"),
>  ("ar command", "ar.exe"),
>  ("ar flags", "q"),
>  ("ar supports at file", "YES"),
>  ("touch command", "$topdir/touchy.exe"),
>  ("dllwrap command", "dllwrap.exe"),
>  ("windres command", "windres.exe"),
>  ("perl command", "perl.exe"),
>  ("target os", "OSMinGW32"),
>  ("target arch", "ArchX86_64"),
>  ("target word size", "8"),
>  ("target has GNU nonexec stack", "False"),
>  ("target has .ident directive", "True"),
>  ("target has subsections via symbols", "False"),
>  ("LLVM llc command", ""),
>  ("LLVM opt command", "")
>  ]
>
> --
> David Macek
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141104/c007afd6/attachment.html>

From david.macek.0 at gmail.com  Tue Nov  4 00:12:01 2014
From: david.macek.0 at gmail.com (David Macek)
Date: Tue, 04 Nov 2014 01:12:01 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <CAFC_MejW=7bLLcg8bByk7+Pm1gEWNtVfew8dchoTKK4ejsD3ZA@mail.gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
 <5458160D.5000305@gmail.com>
 <CAFC_MejW=7bLLcg8bByk7+Pm1gEWNtVfew8dchoTKK4ejsD3ZA@mail.gmail.com>
Message-ID: <545819D1.4010405@gmail.com>

On 4. 11. 2014 1:05, Gintautas Miliauskas wrote:
> Nice!
> 
> This needs a host ghc (with alex and happy) preinstalled, correct?

Maybe I misunderstood, but the answer should be clear from my message. Yes, the ghc PKGBUILD expects working ghc, alex and happy in PATH. ghc has to be downloaded (until an MSYS2 package becomes available), cabal can be built using cabal-install PKGBUILD and alex and happy can then be downloaded and built using cabal.

-- 
David Macek

From gintautas.miliauskas at gmail.com  Tue Nov  4 00:12:52 2014
From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas)
Date: Tue, 4 Nov 2014 01:12:52 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
Message-ID: <CAFC_Meg9tk5=D8dojBW4zuMXDNa-DEni707DqV6D8C+s5oFfVA@mail.gmail.com>

>
>
> thanks for the feedback. ghc-stage1 is a native application, it is built
> using a host ghc and a mingw gcc bundled with the ghc distribution (in
> order to keep Windows builds more predictable). The thing is, the same
> builds (using make) that were stable on cygwin seem to be crashing on
> msys2, even though the (bundled) gcc used for the build is the same. It
> could be that msys2 is triggering a bug in ghc somehow, but it could be
> something going on in msys2 itself.
>

Interesting data point: in one of my experiments the following command
segfaulted:

"inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Werror
-optc-Wall -optc-Wall -optc-Wextra -optc-Wstrict-prototypes
-optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline
-optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn
-optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes
-optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header
-optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build
-optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common
-optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer
-optc-fno-omit-frame-pointer -optc-g -optc-O0
-optc-DRtsWay=\"rts_thr_debug\" -static -optc-DTHREADED_RTS -optc-DDEBUG
 -H32m -O -Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist
-Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header
-Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint
 -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build
-Irts/dist/build/autogen           -O2 -O0    -c rts/sm/GCUtils.c -o
rts/dist/build/sm/GCUtils.thr_debug_o
[...]
rts/ghc.mk:236: recipe for target 'rts/dist/build/sm/GCUtils.thr_debug_o'
failed
make[1]: *** [rts/dist/build/sm/GCUtils.thr_debug_o] Segmentation fault
make[1]: *** Deleting file 'rts/dist/build/sm/GCUtils.thr_debug_o'

Note that while the command is invoking ghc, actually it is only building a
C file, so it's just forwarding on the work to gcc The issue is thus
unlikely to be somewhere deep in ghc, it's either on the surface or in
msys2. There could be a problem with our gcc build, but other compiler
versions crash too, so I don't think that's it.


-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141104/dc056827/attachment.html>

From gintautas.miliauskas at gmail.com  Tue Nov  4 00:45:09 2014
From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas)
Date: Tue, 4 Nov 2014 01:45:09 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <CAOYw7duty5OoX35NJq-mtc=MqyH6T7L9y2DfzHhWQxYAr1n2bg@mail.gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
 <CAOYw7duty5OoX35NJq-mtc=MqyH6T7L9y2DfzHhWQxYAr1n2bg@mail.gmail.com>
Message-ID: <CAFC_MeiZiHE+jioQJ36ZBQP4YyQqK3Ysm7uhjsWeUZLz1cnt0Q@mail.gmail.com>

I have a suspicion that the segmentation faults are related to fork errors,
which appear in logs from time to time. After a few builds fork() errors
become very frequent, and segfaults seem to occur more often. I just ran
the build (validate.sh) in a loop, and after a while got a bunch of
segfaults in Makefile rules as basic as rm invocations in the initial "make
clean", e.g.:

"rm" -rf driver/split/dist
driver/split/ghc.mk:19: recipe for target 'clean_driver/split_dist' failed
make[1]: *** [clean_driver/split_dist] Segmentation fault
Makefile:94: recipe for target 'maintainer-clean' failed

Closing and reopening the msys2 console seems to help - for some time.




On Tue, Nov 4, 2014 at 1:30 AM, Ray Donnelly <mingw.android at gmail.com>
wrote:

> On Mon, Nov 3, 2014 at 11:07 PM, Gintautas Miliauskas
> <gintautas.miliauskas at gmail.com> wrote:
> > +ghc-devs
> >
> > Hi Ray,
> >
> > thanks for the feedback. ghc-stage1 is a native application, it is built
> > using a host ghc and a mingw gcc bundled with the ghc distribution (in
> order
> > to keep Windows builds more predictable). The thing is, the same builds
> > (using make) that were stable on cygwin seem to be crashing on msys2,
> even
> > though the (bundled) gcc used for the build is the same. It could be that
> > msys2 is triggering a bug in ghc somehow, but it could be something
> going on
> > in msys2 itself.
> >
> > The tricky part is that the crashes are rare, one in thousands of ghc
> > invocations within a make build, and I'm having trouble pinning one down
> to
> > investigate. I'll try some basic tracing first, but ideas for something
> more
> > sophisticated would be very helpful.
>
> Ah, ok. I skim read your initial email and applied totally incorrect
> weighting to the "not very hard to reproduce" bit, apologies!
>
> It *should* be possible to setup post-mortem debugging using either Qt
> Creator (Tools->Options->Debugger, tick "Use Qt Creator for
> post-mortem debugging") or Dr. Mingw
> (https://github.com/jrfonseca/drmingw). I briefly tested both options:
>
> Qt Creator: It seems there's a bug in its handling of the
> -wincrashevent command line which I've just added a note about to the
> MINGW-packages todo list since I'd find this feature more than very
> useful:
> https://github.com/Alexpux/MINGW-packages/blob/master/TODO.md
>
> Dr Mingw: Launching the crashing executable from Windows Explorer, it
> launches it and gives me useful information.
>
> Unfortunately, regardless of the debugger used, when invoking the
> crashing executable from the mintty commandline, something inhibits
> all post mortem debugging. I will ask the mingw-w64 guys if they know
> what this is. I guess intrusive dialogs would be annoying, but I'd
> like an env. var override for that I think.
>
> There is another possibility, and that's that bash is crashing, which
> is an MSYS2 program. We do have a way of hooking into post-mortem
> debugging there since Cygwin provided a way and we improved it. If you
> check your msys2_shell.bat you'll see:
> rem set
> MSYS=error_start:%WD%../../mingw64/bin/qtcreator.exe|-debug|<process-id>
>
> If you remove the rem and make sure the path is correct (it may have
> rotted some since I last used it) then hopefully you'll get something
> useful. To be really useful, you should rebuild two packages,
> MSYS2-packages/{msys2-runtime,bash}/PKGBUILD with
> options=('debug' '!strip')
> and then install them.
>
> Finally, can anyone else confirm the problem?
>
> There may be some edge cases when e.g. PATH is around 1024 characters,
> I've seen some hardcoded limits in the msys2-runtime (nee Cygwin)
> code base for things like that. I'd advise cutting your Windows PATH
> down to just the essentials.
>
> Cheers,
>
> Ray.
>
> >
> > A PKGBUILD for ghc should be feasible, although the bootstrapping is a
> bit
> > tricky (some Haskell tools need to be preinstalled). I'm not sure how
> useful
> > it would be since for Windows there is already a nicely packaged native
> > Haskell Platform installer.
> >
> >
> > On Mon, Nov 3, 2014 at 3:30 AM, Ray Donnelly <mingw.android at gmail.com>
> > wrote:
> >>
> >> On Sun, Nov 2, 2014 at 11:45 PM, Gintautas Miliauskas
> >> <gintautas.miliauskas at gmail.com> wrote:
> >> > Hello,
> >> >
> >> > I have been working on building GHC, the Glasgow Haskell Compiler, on
> >> > Windows using msys2 [1]. We have been having some strange trouble with
> >> > ghc
> >> > segfaulting during the bootstrapping process (i.e., during make). The
> >> > crashes are not very hard to reproduce, but they are not predictable
> >> > either.
> >> > This is almost certainly a bug in ghc itself and not with msys2
> >> > (although
> >> > the crashes do not seem to occur in other environments), but I've been
> >> > having some trouble pinning it down.
> >> >
> >>
> >> Hi Gintuatas,
> >>
> >> Great. I spotted that MSYS2 was the recommended env. for GHC on
> >> Windows, hopefully it will remain so!
> >>
> >> > What's a good way to debug such crashes? Is it possible to somehow
> stop
> >> > the
> >> > ghc process when it segfaults and attach gdb, or to dump core somehow
> >> > for
> >> > later inspection?
> >> >
> >> > [1]
> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
> >> >
> >> > Here's one example crash:
> >> >
> >> > "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf  o -hcsuf hc -static
> -H32m
> >> > -O
> >> > -Werror -Wall -H64m -O0    -this-package-key
> ghc_4ugNArSu5ba0Z1uHXrbTlU
> >> > -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm
> >> > -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar
> -icompiler/ghci
> >> > -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main
> >> > -icompiler/nativeGen -icompiler/parser -icompiler/prelude
> >> > -icompiler/profiling -icompiler/rename -icompiler/simplCore
> >> > -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn
> >> > -icompiler/stranal -icompiler/typecheck -icompiler/types
> >> > -icompiler/utils
> >> > -icompiler/vectorise -icompiler/stage2/build
> >> > -icompiler/stage2/build/autogen
> >> > -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/.
> >> > -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build
> >> > -Icompiler/stage2   -optP-DGHCI -optP-include
> >> > -optPcompiler/stage2/build/autogen/cabal_macros.h -package-key
> >> > Win32_43THQMouBnk2wpnouztX1X -package-key array_GX4NwjS8xZkC2ZPtjgwhnz
> >> > -package-key base_ESD4aQEEWwsHtYJVc1BwtJ -package-key
> >> > binpa_17GphrLqCXt1H1lm4Kse1p -package-key bytes_Kc0PyaputnzDnBdZW0y2Gv
> >> > -package-key conta_ChF4XLXB9JmByIycPzerow -package-key
> >> > direc_HU5aFxMIQNwGQFzisjuinu -package-key filep_34DFDFT9FVD9pRLLgh8IdQ
> >> > -package-key hoopl_IZAd44CED5NCOlpg8p2Kaj -package-key
> >> > hpc_1QTsfQSN40FHN9p3mydARY -package-key proce_7ZlAbRkwiRO8qgXx3NNP0G
> >> > -package-key templ_F6UJgDtBcDIFWuHmMGEFzy -package-key
> >> > time_HGs4JcQCd4wF6U8vJQ5fNH -package-key trans_5jw4w9yTgmZ89ByuixDAKP
> >> > -Wall
> >> > -fno-warn-name-shadowing -this-package-key ghc -XHaskell2010
> >> > -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing
> >> > -O2
> >> > -fwarn-tabs -O -dcore-lint  -no-user-package-db -rtsopts      -odir
> >> > compiler/stage2/build -hidir compiler/stage2/build -stubdir
> >> > compiler/stage2/build   -c compiler/basicTypes/UniqSupply.lhs -o
> >> > compiler/stage2/build/UniqSupply.o
> >> >
> >> > compiler/ghc.mk:657: recipe for target
> >> > 'compiler/stage2/build/UniqSupply.o'
> >> > failed
> >> > make[1]: *** [compiler/stage2/build/UniqSupply.o] Segmentation fault
> >> >
> >>
> >> Well, it's pretty much the same story as with Linux. Build the
> >> executable and as many libraries as you can with (something like)
> >> "-ggdb -O0" then use gdb command line or some IDE of choice.
> >> Personally I use Qt Creator (we have packages for this) as it can
> >> debug external programs and, even though I don't dislike command
> >> lines, I find debugging from them a bit too masochistic.
> >>
> >> Is ghc-stage1.exe an MSYS2 program or a native one? Which compiler is
> >> it built with exactly?
> >>
> >> What would be involved in creating a PKGBUILD for ghc? We'd love to
> >> have one, and it'd certainly make me a lot more inclined to dive in to
> >> see what's going on if one existed already.
> >>
> >> Ray.
> >>
> >> >
> >> > --
> >> > Gintautas Miliauskas
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> >
> >> > _______________________________________________
> >> > Msys2-users mailing list
> >> > Msys2-users at lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/msys2-users
> >> >
> >
> >
> >
> >
> > --
> > Gintautas Miliauskas
>



-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141104/447f70f8/attachment-0001.html>

From austin at well-typed.com  Tue Nov  4 00:59:11 2014
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 3 Nov 2014 18:59:11 -0600
Subject: [GHC] #9358: Improve flag description in the user guide
In-Reply-To: <201411031957.16775.jan.stolarek@p.lodz.pl>
References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org>
 <063.ea01e100738402f9155cc536f2ed235b@haskell.org>
 <201411031957.16775.jan.stolarek@p.lodz.pl>
Message-ID: <CAEs96n20d+Qo2EvAm4yRoZ9jmVS2cspDW6F-2D6dLXTgp+xhig@mail.gmail.com>

For updating the users guide, no, I don't think hitting the freeze is
really necessary. We're mostly worried about big features as opposed
to big documentation upgrades. So do please take your time and let me
know what to merge if you don't get it done by then.

On Mon, Nov 3, 2014 at 12:57 PM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:
>>  Jan, you said you'd be willing to do this updating before 7.10
> Yes, that's the plan. The question is do I have to make it before the mid-November feature freeze?
> Austin, what's your opinion?
>
>>  So far as I can see, there simply is no list of what is enabled by -O or
>>  -O2.
> I can make such a list if you want.
>
>>  It's more than a simple on/off  thing because the order matters.
> Hmm.... in which cases does it matter? Can you give an example?
>
> Janek
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From eir at cis.upenn.edu  Tue Nov  4 01:11:14 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 3 Nov 2014 20:11:14 -0500
Subject: Major commit to the constraint solver
In-Reply-To: <1415049246-sup-6696@sabre>
References: <618BE556AADD624C9C918AA5D5911BEF3F38D4BA@DB3PRD3001MB020.064d.mgd.msft.net>
 <1415049246-sup-6696@sabre>
Message-ID: <35290F9D-00EA-43DF-947C-3327CC0BF52B@cis.upenn.edu>

I've done a validate on my Mac. Here is the output (indented), with comments (outdented):

   ../../libraries/base/tests/IO  hReady002 [bad stderr] (normal)

Succeeded on a later run

   cabal/cabal01                  cabal01 [bad exit code] (normal)

Wrong exit code (expected 0 , actual 2 )
Stdout:
install1:
bin
lib
install2:
bin
lib

Stderr:
tar: --format: Cannot stat: No such file or directory
tar: ustar: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors.
make[2]: *** [cabal01] Error 1

*** unexpected failure for cabal01(normal)

   cabal/cabal06                  cabal06 [bad stdout] (normal)

Actual stdout output differs from expected:
--- ./cabal06/cabal06.stdout	2014-11-03 13:23:21.000000000 -0500
+++ ./cabal06/cabal06.run.stdout	2014-11-03 20:00:56.000000000 -0500
@@ -1,7 +1,7 @@
 Does the first instance of q depend on p-1.0?
-1
+       1
 Does the second instance of q depend on p-1.0?
-1
+       1
 Configuring r-1.0...
 Configuring r-1.0...
 10
*** unexpected failure for cabal06(normal)

   driver/objc                    objc-hi [exit code non-0] (normal)
   driver/objc                    objcpp-hi [exit code non-0] (normal)
   driver/sigof02                 sigof02dmt [bad stderr] (normal)

These three are almost certainly not related to your work.

   indexed-types/should_compile   PushedInAsGivens [stderr mismatch] (normal)

Actual stderr output differs from expected:
--- /dev/null	2014-11-03 20:06:19.000000000 -0500
+++ ./PushedInAsGivens.comp.stderr	2014-11-03 20:06:21.000000000 -0500
@@ -0,0 +1,27 @@
+
+PushedInAsGivens.hs:10:31:
+    Couldn't match expected type ?a1? with actual type ?a?
+      because type variable ?a1? would escape its scope
+    This (rigid, skolem) type variable is bound by
+      the type signature for foo :: (F Int ~ [a1]) => a1 -> Int
+      at PushedInAsGivens.hs:9:20-44
+    Relevant bindings include
+      x :: a1 (bound at PushedInAsGivens.hs:10:17)
+      foo :: a1 -> Int (bound at PushedInAsGivens.hs:10:13)
+      y :: a (bound at PushedInAsGivens.hs:9:5)
+      bar :: a -> (a, Int) (bound at PushedInAsGivens.hs:9:1)
+    In the expression: y
+    In the first argument of ?length?, namely ?[x, y]?
+
+PushedInAsGivens.hs:11:15:
+    Couldn't match expected type ?[a]? with actual type ?F Int?
+    Relevant bindings include
+      y :: a (bound at PushedInAsGivens.hs:9:5)
+      bar :: a -> (a, Int) (bound at PushedInAsGivens.hs:9:1)
+    In the expression: foo y
+    In the expression: (y, foo y)
+    In the expression:
+      let
+        foo :: (F Int ~ [a]) => a -> Int
+        foo x = length [...]
+      in (y, foo y)
*** unexpected failure for PushedInAsGivens(normal)

   llvm/should_compile            T5486 [stderr mismatch] (optllvm)
   llvm/should_compile            T5681 [stderr mismatch] (optllvm)
   llvm/should_compile            T7571 [stderr mismatch] (optllvm)

These seem to be some clang misconfiguration.

   perf/compiler                  T4801 [stat too good] (normal)
   perf/compiler                  T5631 [stat not good enough] (normal)
   rts                            T5435_dyn_asm [bad stdout] (normal)

These three have been failing on and off for a while.

   safeHaskell/check/pkg01        safePkg01 [bad stdout] (normal)

Edward addressed this one, I believe.



So, it seems the one real hit is the one you were expecting -- that's good. Unfortunately, we also see that validation on a Mac doesn't work so well these days. My experience is that there's usually a few failing tests, but not nearly this many. Perhaps it's a sign of the success of the Travis/Harbormaster validation runs that folks aren't validating at home, lessening the pressure to keep clean validation on a variety of platforms.

Anyway, I hope this is helpful.

Richard

On Nov 3, 2014, at 4:23 PM, "Edward Z. Yang" <ezyang at mit.edu> wrote:

> Excerpts from Simon Peyton Jones's message of 2014-11-03 09:28:49 -0800:
>> *         I get an odd wibble in safePk01, see this thread<https://www.haskell.org/pipermail/ghc-devs/2014-November/007065.html> with Edward
> 
> Hello Simon,
> 
> Here's what you should do for the safePkg01 wibble:
> 
>    1. Apply the attached patch to your tree (this will
>       break the tests temporarily.)
> 
>    2. Accept the new output for safePkg01 which no longer has
>       the package keys in it.
> 
>    3. Remove the noramliseArrayPackageKey goop from all.T
> 
> I could do the changes myself but it's your branch so I don't want to
> touch it unduly.
> 
> BTW, here is why your change removed the package keys: --show-iface
> previously pretty-printed as if -dppr-debug was always on.  You touched
> this code so that --show-iface only prints in debug style if you
> actually asked for -dppr-debug; this changed the output of these tests.
> 
> Edward
> <0001-Tweak-Safe-Haskell-test-to-show-iface-with-large-col.patch>_______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From allbery.b at gmail.com  Tue Nov  4 01:18:50 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 3 Nov 2014 20:18:50 -0500
Subject: Major commit to the constraint solver
In-Reply-To: <35290F9D-00EA-43DF-947C-3327CC0BF52B@cis.upenn.edu>
References: <618BE556AADD624C9C918AA5D5911BEF3F38D4BA@DB3PRD3001MB020.064d.mgd.msft.net>
 <1415049246-sup-6696@sabre>
 <35290F9D-00EA-43DF-947C-3327CC0BF52B@cis.upenn.edu>
Message-ID: <CAKFCL4UBPzwuQSokKHdQ9dXerk8CJ8RuYOb8UE_hDMLN3s0nvw@mail.gmail.com>

On Mon, Nov 3, 2014 at 8:11 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> Stderr:
> tar: --format: Cannot stat: No such file or directory
> tar: ustar: Cannot stat: No such file or directory
> tar: Error exit delayed from previous errors.
> make[2]: *** [cabal01] Error 1
>

Apple got rid of gnutar, it's now libarchive tar.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141103/ef46d78a/attachment.html>

From merijn at inconsistent.nl  Tue Nov  4 05:36:13 2014
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Mon, 3 Nov 2014 21:36:13 -0800
Subject: Problem with select(2) in single threaded runtime.
Message-ID: <BE8FFA80-AF02-46D9-B686-B49D2904E3E4@inconsistent.nl>

While adding a test case for https://phabricator.haskell.org/D407 I noticed that while my initial patch fixed the crash for the threaded runtime, the single threaded runtime was still affected. I dove into the RTS and have hit a snag.

In awaitEvent (rts/posix/Select.c) select(2) is called with the timeout computed from the Haskell call. On my current (OSX) machine my test case overflows "struct timeval", causing select to return EINVAL and crash the runtime. Unfortunately, there appears to be no portable to find the maximum size of time_t/suseconds_t (the types of the struct timeval fields), and therefore no portable way to avoid this overflow.

The most practical thing I can think of is to add a configure case that checks sizeof(time_t) and sizeof(suseconds_t) and guesses they're just unsigned values of the relevant type, but I'm open to better suggestions. Alternatively, the solution is to hardcode the max value for every platform, in which case I avoid you all to tell me the maximum value on your specific platform :p

Cheers,
Merijn

From merijn at inconsistent.nl  Tue Nov  4 06:42:11 2014
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Mon, 3 Nov 2014 22:42:11 -0800
Subject: Problem with select(2) in single threaded runtime.
In-Reply-To: <BE8FFA80-AF02-46D9-B686-B49D2904E3E4@inconsistent.nl>
References: <BE8FFA80-AF02-46D9-B686-B49D2904E3E4@inconsistent.nl>
Message-ID: <94903F9A-97C6-4B23-B8E6-DEB6317018AF@inconsistent.nl>

Worse, it appears the maximum size of time_t is unrelated to the maximum value accepted by select(2). After diving into my system's header files time_t appears to be 'long', but a timeout of INT_MAX seconds already triggers "EINVAL".

At this point, the only option I see is to verify the max timeout for every platform, by reading the source and/or trying all possible timeouts until the max is found and hard coding these max values using CPP.

If anyone has a better solution, you're more than welcome to enlighten me!

Cheers,
Merijn

> On 3 Nov 2014, at 21:36, Merijn Verstraaten <merijn at inconsistent.nl> wrote:
> 
> While adding a test case for https://phabricator.haskell.org/D407 I noticed that while my initial patch fixed the crash for the threaded runtime, the single threaded runtime was still affected. I dove into the RTS and have hit a snag.
> 
> In awaitEvent (rts/posix/Select.c) select(2) is called with the timeout computed from the Haskell call. On my current (OSX) machine my test case overflows "struct timeval", causing select to return EINVAL and crash the runtime. Unfortunately, there appears to be no portable to find the maximum size of time_t/suseconds_t (the types of the struct timeval fields), and therefore no portable way to avoid this overflow.
> 
> The most practical thing I can think of is to add a configure case that checks sizeof(time_t) and sizeof(suseconds_t) and guesses they're just unsigned values of the relevant type, but I'm open to better suggestions. Alternatively, the solution is to hardcode the max value for every platform, in which case I avoid you all to tell me the maximum value on your specific platform :p
> 
> Cheers,
> Merijn
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From hvriedel at gmail.com  Tue Nov  4 08:34:48 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Tue, 04 Nov 2014 09:34:48 +0100
Subject: Problem with select(2) in single threaded runtime.
In-Reply-To: <94903F9A-97C6-4B23-B8E6-DEB6317018AF@inconsistent.nl> (Merijn
 Verstraaten's message of "Mon, 3 Nov 2014 22:42:11 -0800")
References: <BE8FFA80-AF02-46D9-B686-B49D2904E3E4@inconsistent.nl>
 <94903F9A-97C6-4B23-B8E6-DEB6317018AF@inconsistent.nl>
Message-ID: <87oasn1hzr.fsf@gmail.com>

On 2014-11-04 at 07:42:11 +0100, Merijn Verstraaten wrote:
> Worse, it appears the maximum size of time_t is unrelated to the
> maximum value accepted by select(2). 

Fwiw, I found the following on
http://pubs.opengroup.org/onlinepubs/009695399/functions/pselect.html

,----
| Implementations may place limitations on the maximum timeout interval
| supported. All implementations shall support a maximum timeout interval
| of at least 31 days. If the timeout argument specifies a timeout
| interval greater than the implementation-defined maximum value, the
| maximum value shall be used as the actual timeout value. Implementations
| may also place limitations on the granularity of timeout intervals. If
| the requested timeout interval requires a finer granularity than the
| implementation supports, the actual timeout interval shall be rounded up
| to the next supported value.
`----

So I'm a bit surprised you get an EINVAL instead of the timeout being
capped to the implementation's max supported value.

Was the passed `timeval` structure valid? I.e. is the tv_usec value inside
the [0,1e6-1] range? and was tv_sec>=0 ?

From simonpj at microsoft.com  Tue Nov  4 08:44:20 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 4 Nov 2014 08:44:20 +0000
Subject: Major commit to the constraint solver
In-Reply-To: <1415038699.1388.8.camel@joachim-breitner.de>
References: <618BE556AADD624C9C918AA5D5911BEF3F38D4BA@DB3PRD3001MB020.064d.mgd.msft.net>
 <1415038699.1388.8.camel@joachim-breitner.de>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F38EC84@DB3PRD3001MB020.064d.mgd.msft.net>

That's great; I didn't realise that.

How can I navigate to the build log.  I went to 
https://travis-ci.org/ghc/ghc/builds
clicked on "Branch summary", found my branch, clicked on the link for "617" but it didn't show me the build log that you did.  (It did have a red button saying "617 failed".

Thanks

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Joachim Breitner
|  Sent: 03 November 2014 18:18
|  To: ghc-devs at haskell.org
|  Subject: Re: Major commit to the constraint solver
|  
|  Hi,
|  
|  
|  Am Montag, den 03.11.2014, 17:28 +0000 schrieb Simon Peyton Jones:
|  > I?ve pushed branch wip/new-flatten-skolems-Oct14.  (It has some
|  > rebasing near the top.)
|  >
|  > It branches off master some a few days ago; i.e. it is almost
|  > completely up to date.
|  >
|  > Can you try building it?  I want to push it to HEAD, but would like
|  > some independent validation first.
|  
|  Travis build branches automatically, and is already trying to build
|  it:
|  https://travis-ci.org/ghc/ghc/builds/39856856
|  
|  It just finished, but it is not completely happy:
|  
|  Actual stderr output differs from expected:
|  --- /dev/null	2014-11-03 17:30:32.067943898 +0000
|  +++ ./indexed-types/should_compile/PushedInAsGivens.comp.stderr	2014-
|  11-03 18:11:53.225519481 +0000
|  @@ -0,0 +1,27 @@
|  +
|  +PushedInAsGivens.hs:10:31:
|  +    Couldn't match expected type ?a1? with actual type ?a?
|  +      because type variable ?a1? would escape its scope
|  +    This (rigid, skolem) type variable is bound by
|  +      the type signature for foo :: (F Int ~ [a1]) => a1 -> Int
|  +      at PushedInAsGivens.hs:9:20-44
|  +    Relevant bindings include
|  +      x :: a1 (bound at PushedInAsGivens.hs:10:17)
|  +      foo :: a1 -> Int (bound at PushedInAsGivens.hs:10:13)
|  +      y :: a (bound at PushedInAsGivens.hs:9:5)
|  +      bar :: a -> (a, Int) (bound at PushedInAsGivens.hs:9:1)
|  +    In the expression: y
|  +    In the first argument of ?length?, namely ?[x, y]?
|  +
|  +PushedInAsGivens.hs:11:15:
|  +    Couldn't match expected type ?[a]? with actual type ?F Int?
|  +    Relevant bindings include
|  +      y :: a (bound at PushedInAsGivens.hs:9:5)
|  +      bar :: a -> (a, Int) (bound at PushedInAsGivens.hs:9:1)
|  +    In the expression: foo y
|  +    In the expression: (y, foo y)
|  +    In the expression:
|  +      let
|  +        foo :: (F Int ~ [a]) => a -> Int
|  +        foo x = length [...]
|  +      in (y, foo y)
|  =====> T2715(normal) 3281 of 4140 [0, 0, 0]
|  *** unexpected failure for PushedInAsGivens(normal)
|  
|  Actual stdout output differs from expected:
|  --- ./safeHaskell/check/pkg01/safePkg01.stdout	2014-11-03
|  17:30:57.327803827 +0000
|  +++ ./safeHaskell/check/pkg01/safePkg01.run.stdout	2014-11-03
|  18:12:11.178706914 +0000
|  @@ -29,17 +29,17 @@
|   require own pkg trusted: True
|  
|   M_SafePkg6
|  -package dependencies: array-0.5.0.1 at array_<HASH>
|  +package dependencies: array-0.5.0.1 base-4.8.0.0*
|   trusted: trustworthy
|   require own pkg trusted: False
|  
|   M_SafePkg7
|  -package dependencies: array-0.5.0.1 at array_<HASH>
|  +package dependencies: array-0.5.0.1 base-4.8.0.0*
|   trusted: safe
|   require own pkg trusted: False
|  
|   M_SafePkg8
|  -package dependencies: array-0.5.0.1 at array_<HASH>
|  +package dependencies: array-0.5.0.1 base-4.8.0.0
|   trusted: trustworthy
|   require own pkg trusted: False
|  
|  *** unexpected failure for safePkg01(normal)
|  
|  Is there more you want us to do besides what Travis just did for us?
|  
|  Greetings,
|  Joachim
|  
|  --
|  Joachim ?nomeata? Breitner
|    mail at joachim-breitner.de ? http://www.joachim-breitner.de/
|    Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
|    Debian Developer: nomeata at debian.org


From mail at joachim-breitner.de  Tue Nov  4 08:55:25 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 04 Nov 2014 09:55:25 +0100
Subject: Major commit to the constraint solver
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F38EC84@DB3PRD3001MB020.064d.mgd.msft.net>
References: <618BE556AADD624C9C918AA5D5911BEF3F38D4BA@DB3PRD3001MB020.064d.mgd.msft.net>
 <1415038699.1388.8.camel@joachim-breitner.de>
 <618BE556AADD624C9C918AA5D5911BEF3F38EC84@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <1415091325.1384.3.camel@joachim-breitner.de>

Hi,


Am Dienstag, den 04.11.2014, 08:44 +0000 schrieb Simon Peyton Jones:
> That's great; I didn't realise that.
> 
> How can I navigate to the build log.  I went to 
> https://travis-ci.org/ghc/ghc/builds
> clicked on "Branch summary", found my branch, clicked on the link for
> "617" but it didn't show me the build log that you did.  (It did have
> a red button saying "617 failed".

We build everything twice, once with -DDEBUG and once without.
Therefore, at the bottom of the page you were looking at
(presumably https://travis-ci.org/ghc/ghc/builds/39856856),
there are two links named 617.1 and 617.2. These take you to the build
log, e.g. https://travis-ci.org/ghc/ghc/jobs/39856857

But: Travis tries to prettify the logs using plenty of JavaScript, this
will easily bring your browser to its knees. So the trick is: After
following the link, and while the page is loading, in the top right
corner look for the square with the three horizontal lines. This link
takes to to a text-only view of the logs, e.g.
https://s3.amazonaws.com/archive.travis-ci.org/jobs/39856857/log.txt

(The latter is mentioned on
https://ghc.haskell.org/trac/ghc/wiki/Travis, but maybe not very
visible. I could add a paragraph describing the steps to reach the
logs.)

By the way, you can usually find your branch on the Build History
(https://travis-ci.org/ghc/ghc/builds) directly, if it has been built
recently. The column ?Commit? mentions the branch its on.

Greetings,
Joachim



-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141104/112a5651/attachment.sig>

From simonpj at microsoft.com  Tue Nov  4 09:09:09 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 4 Nov 2014 09:09:09 +0000
Subject: [GHC] #9358: Improve flag description in the user guide
In-Reply-To: <201411031957.16775.jan.stolarek@p.lodz.pl>
References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org>
 <063.ea01e100738402f9155cc536f2ed235b@haskell.org>
 <201411031957.16775.jan.stolarek@p.lodz.pl>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F38ED1E@DB3PRD3001MB020.064d.mgd.msft.net>


|  >  Jan, you said you'd be willing to do this updating before 7.10
|  Yes, that's the plan. The question is do I have to make it before the
|  mid-November feature freeze?
|  Austin, what's your opinion?

Great.  Sooner the better.  Post freeze Austin has to do merging work, but not impossible.

|  >  It's more than a simple on/off  thing because the order matters.
|  Hmm.... in which cases does it matter? Can you give an example?

Well, for example, as you'll see in SimplCore, the -O1 pipeline runs the float-out twice.  So just saying "float-out is on" doesn't tell you all you might want to know.  It might be worth translating SimplCore.getCoreToDo into English and putting it in the manual as a rough idea.  But maybe that is too much, I'm not sure.  (eg it would get out of date)

Perhaps just listing what is on by default in -O1 and -O2 would get a long way.

Simon

From jan.stolarek at p.lodz.pl  Tue Nov  4 09:17:10 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Tue, 4 Nov 2014 10:17:10 +0100
Subject: [GHC] #9358: Improve flag description in the user guide
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F38ED1E@DB3PRD3001MB020.064d.mgd.msft.net>
References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org>
 <201411031957.16775.jan.stolarek@p.lodz.pl>
 <618BE556AADD624C9C918AA5D5911BEF3F38ED1E@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <201411041017.10513.jan.stolarek@p.lodz.pl>

> Post freeze Austin has to do merging work
Right. I'll do my best to finish this ASAP.

Jan

From simonpj at microsoft.com  Tue Nov  4 09:41:49 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 4 Nov 2014 09:41:49 +0000
Subject: Major commit to the constraint solver
In-Reply-To: <1415091325.1384.3.camel@joachim-breitner.de>
References: <618BE556AADD624C9C918AA5D5911BEF3F38D4BA@DB3PRD3001MB020.064d.mgd.msft.net>
 <1415038699.1388.8.camel@joachim-breitner.de>
 <618BE556AADD624C9C918AA5D5911BEF3F38EC84@DB3PRD3001MB020.064d.mgd.msft.net>
 <1415091325.1384.3.camel@joachim-breitner.de>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F38EF6B@DB3PRD3001MB020.064d.mgd.msft.net>

Aha.  Yes, I did click on one of those links, and my browser was fine: but the displayed log was simply truncated at 10,000 lines, which removed all the interesting stuff. 

Moving the tip to the top, just under "What does it do?", and giving a bit more navigation info, would be a good plan.

thanks

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Joachim Breitner
|  Sent: 04 November 2014 08:55
|  To: ghc-devs at haskell.org
|  Subject: Re: Major commit to the constraint solver
|  
|  Hi,
|  
|  
|  Am Dienstag, den 04.11.2014, 08:44 +0000 schrieb Simon Peyton Jones:
|  > That's great; I didn't realise that.
|  >
|  > How can I navigate to the build log.  I went to
|  > https://travis-ci.org/ghc/ghc/builds
|  > clicked on "Branch summary", found my branch, clicked on the link
|  for
|  > "617" but it didn't show me the build log that you did.  (It did
|  have
|  > a red button saying "617 failed".
|  
|  We build everything twice, once with -DDEBUG and once without.
|  Therefore, at the bottom of the page you were looking at (presumably
|  https://travis-ci.org/ghc/ghc/builds/39856856),
|  there are two links named 617.1 and 617.2. These take you to the build
|  log, e.g. https://travis-ci.org/ghc/ghc/jobs/39856857
|  
|  But: Travis tries to prettify the logs using plenty of JavaScript,
|  this will easily bring your browser to its knees. So the trick is:
|  After following the link, and while the page is loading, in the top
|  right corner look for the square with the three horizontal lines. This
|  link takes to to a text-only view of the logs, e.g.
|  https://s3.amazonaws.com/archive.travis-ci.org/jobs/39856857/log.txt
|  
|  (The latter is mentioned on
|  https://ghc.haskell.org/trac/ghc/wiki/Travis, but maybe not very
|  visible. I could add a paragraph describing the steps to reach the
|  logs.)
|  
|  By the way, you can usually find your branch on the Build History
|  (https://travis-ci.org/ghc/ghc/builds) directly, if it has been built
|  recently. The column ?Commit? mentions the branch its on.
|  
|  Greetings,
|  Joachim
|  
|  
|  
|  --
|  Joachim ?nomeata? Breitner
|    mail at joachim-breitner.de ? http://www.joachim-breitner.de/
|    Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
|    Debian Developer: nomeata at debian.org


From simonpj at microsoft.com  Tue Nov  4 09:52:23 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 4 Nov 2014 09:52:23 +0000
Subject: Resurrecting ticky code
In-Reply-To: <20141103171848.GA73387@polaris.local>
References: <20141103171848.GA73387@polaris.local>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F38F02E@DB3PRD3001MB020.064d.mgd.msft.net>

We don?t have "vectored returns" any more, so you can drop that one.

For "magic eight" there are some native-wordsize constants defined already.
E.g. see how PrelRules.wordSizeInBits is computed.

Thanks to Jan for helping

SImon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Mateusz Lenik
|  Sent: 03 November 2014 17:19
|  To: ghc-devs at haskell.org
|  Subject: Resurrecting ticky code
|  
|  Hi *,
|  
|  Recently I started working on resurrecting ticky code[1] and got to
|  the point where I can compile and run bumpHistogram as well as
|  accompanying code in RTS.
|  
|  Work in progress version can be found at [2], but there are few things
|  remaining to get it working:
|  
|  * missing calls to tickyReturnNewCon, tickyUnboxedTupleReturn and
|    tickyVectoredReturn need to be added. Unfortunately I'm not familiar
|  with the
|    code enough to find the right place to insert them.
|  
|  * magic eight needs to be replaced by a constant both Haskell and C
|  files.
|    Preprocessor macro seems to be the simplest choice here, however I
|  don't find
|    it the cleanest way to do it.
|  
|  I would be very grateful if someone could take a look and point me
|  into the right direction.
|  
|  
|  Best,
|  Mateusz
|  
|  1: https://ghc.haskell.org/trac/ghc/ticket/8308
|  2: https://github.com/mlen/ghc/compare/ticky
|  
|  --
|  Mateusz Lenik
|  GPG: B865 E86A D36C 11A5 C1F8  C1D9 AAD4 CEC9 6B94 92C4

From mail at joachim-breitner.de  Tue Nov  4 10:05:37 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 04 Nov 2014 11:05:37 +0100
Subject: Major commit to the constraint solver
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F38EF6B@DB3PRD3001MB020.064d.mgd.msft.net>
References: <618BE556AADD624C9C918AA5D5911BEF3F38D4BA@DB3PRD3001MB020.064d.mgd.msft.net>
 <1415038699.1388.8.camel@joachim-breitner.de>
 <618BE556AADD624C9C918AA5D5911BEF3F38EC84@DB3PRD3001MB020.064d.mgd.msft.net>
 <1415091325.1384.3.camel@joachim-breitner.de>
 <618BE556AADD624C9C918AA5D5911BEF3F38EF6B@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <1415095537.1384.6.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 04.11.2014, 09:41 +0000 schrieb Simon Peyton Jones:
> Moving the tip to the top, just under "What does it do?", and giving a
> bit more navigation info, would be a good plan.

done: https://ghc.haskell.org/trac/ghc/wiki/Travis#Whatdoesitdo

Writing good Wiki pages is much harder than writing compiler code... :-)

Greetings,
Joachim
-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141104/e242b5db/attachment-0001.sig>

From simonpj at microsoft.com  Tue Nov  4 10:32:22 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 4 Nov 2014 10:32:22 +0000
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <alpine.DEB.2.10.1411031812500.2047@galaxy>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>

Here is one principle: for GADTs, the pattern type signature should look like the GADT data constructor.  So if we have

	data S a where
        S1 :: p -> q -> S (p,q)
        S2 :: ...blah...

      pattern P x y = S1 x y

then surely the signature for P should be
	P :: p -> q -> S (p,q)

The same goes for constraints in the constructor's type. Thus, using your example:

|       data T a b where
|         MkT :: (Eq a, Ord b, Show c) => a -> (b, b) -> c -> T a b

If I say
	pattern P x y z = MkT x y z
then the signature for P should be identical to that of MkT.


-----------

It gets a bit more interesting when you have nested patterns that instantiate the type.  For example, with the same type T, consider

	pattern P x y z = MkT (x,y) (False,True) [z]

the "right" signature for P must presumably be
	P :: (Eq (p,q), Show [r]) => p -> q -> r -> T (p,q) Bool

We don't need to distinguish 'r' as existential, any more than we do in the original signature for MkT.

Note that we must retain the instantiated but un-simplified constraints (Eq (p,b), Show [r]), because when pattern-matching against P, those are the constraints brought into scope.

---------

The general story, for both data constructors and pattern synonyms, is that if the type is
	D :: forall abc. (C1, C2...) => blah
then the constraints (C1, C2...) are 
 - *required* when using D in an expression, 
 - *provided* (i.e. brought into scope) pattern matching against D.

The tricky case comes when the pattern synonym involves some constraints that are *required* during *pattern-matching*.  A simple example is

	pattern P1 x = (8, x)

Here we *require* a (Num a) dictionary *both* when using P1 in an expression (to build the value 8), *and* when using P in pattern matching (to build a value 8 to compare with the value being matched).  I'll call the constraints that are *required* when matching the "match-required constraints".

The same happens for view patterns:

      gr :: Ord a => a -> a -> Maybe a
	gr v x | x > v = Just v
             | otherwise = Nothing

	pattern P2 x = (gr 8 -> Just x)

Here, (Ord a, Num a) are match-required.  (P2 is uni-directional, so we can't use P2 in expressions.)

We can't give a signature to P1 like this
	P1 :: forall a. Num a => b -> (a,b)
because that looks as if (Num a) would be *provided* when pattern matching (see "general story" above), whereas actually it is required.  This is the nub of the problem Gergo is presenting us with.

Notice that P1 is bidirectional, and can be used in expressions, where again we *require* (Num a), so P1's "term type" really is something like (Num a) => b -> (a,b).

The more I think about this, the more I think we'll just have to bite the bullet and adapt the syntax for constraints in pattern types, to distinguish the match-required and match-provided parts. Suppose we let pattern signatures look like this:

  pattern P :: forall tvs. (match-provided ; match-required) => tau

The "; match-required" part is optional, and the "match-provided" part might be empty.  So P1 and P2 would look like this:

  pattern P1 :: forall a. (; Num a) => b -> (a,b)
  pattern P2 :: forall a. (; Num a, Ord a) => a -> a

Because the "match-required" part is optional (and relatively rare) the common case looks just like an ordinary data constructor.


None of this addresses the bidirectional/unidirectional question, but that's a pretty separate matter.  

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Dr.
|  ERDI Gergo
|  Sent: 03 November 2014 10:13
|  To: GHC Devs
|  Subject: RFC: Concrete syntax for pattern synonym type signatures
|  
|  Background
|  ----------
|  
|  As explained on
|  https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms#Staticsemantics
|  the type of a pattern synonym can be fully described with the
|  following pieces of information:
|  
|  * If the pattern synonym is bidirectional
|  * Universially-bound type variables, and required constraints on them
|  * The type of the pattern itself, closed over the universially-bound
|  type variables
|  * Existentially-bound type variables, and the constraints provided by
|  them
|  * The types of the arguments, closed over the universially and
|     existentially bound type variables
|  
|  Here's an example showing all of these axes in action:
|  
|       data T a b where
|         MkT :: (Eq a, Ord b, Show c) => a -> (b, b) -> c -> T a b
|  
|       pattern P x y = MkT 5 (y, True) x
|  
|  In this case:
|  
|  * The name of the pattern synonym is `P`
|  * The pattern synonym is bidirectional
|  * The universially-bound tyvars/required constraints are `forall a.
|  Num a`
|  * The type of the pattern is `T a Bool`
|  * The existentially-bound tyvars/provided constraints are
|     `forall c. (Eq a, Ord Bool, Show c)`
|  * The type of the arguments are `c` and `Bool`.
|  
|  The problem, then, is finding a concrete syntax that captures all of
|  this information. This syntax is needed for at least two purposes:
|  
|  * Showing pattern synonym type information in Haddock/GHCi
|  * Pattern synonym type signatures (#8584)
|  
|  Current state of things
|  -----------------------
|  
|  GHCi 7.8.3 shows the type above as:
|  
|  pattern (Eq t, Ord Bool, Show c) => P c Bool :: Num t => (T t Bool)
|  
|  Not only does it not show directionality, I think this is very
|  confusing in every other way as well, especially with explicit
|  foralls:
|  
|  pattern forall c. (Eq t, Ord Bool, Show c) => P c Bool :: forall t.
|  Num t => (T t Bool)
|  
|  I am currently working on implementing #8584, which means I need to
|  parse these type signatures. I managed to get the above monstrosity to
|  parse (unambigiously from actual pattern synonym definitions) by
|  throwing in an extra 'type' keyword:
|  
|  pattern type (Eq t, Ord Bool, Show c) => P c Bool :: Num t => (T t
|  Bool)
|  
|  Request for help
|  ----------------
|  
|  Surely we can do better than that! So let's come up with a nice syntax
|  for pattern synonym type signatures. It will be used in the pattern
|  synonym type signature annotations of GHC 7.10, and we could also
|  retrofit it into GHC 7.8.4 and its Haddock, so that documentation
|  generated with today's tools will look consistent with code you will
|  be able to enter in tomorrow's version.
|  
|  Bye,
|   	Gergo
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  http://www.haskell.org/mailman/listinfo/ghc-devs

From simonpj at microsoft.com  Tue Nov  4 10:55:48 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 4 Nov 2014 10:55:48 +0000
Subject: Can't install packages with my inplace compiler
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F38F616@DB3PRD3001MB020.064d.mgd.msft.net>

When I say


cabal install --with-ghc=/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-stage2

I get this


ghc-stage2: ghc no longer supports single-file style package databases (dist/package.conf.inplace) use 'ghc-pkg init' to create the database with the correct format.

Now, this is an old build tree, and I could blow it away entirely, but maybe there is something else going on.  What should I do?

Thanks (all on Linux)

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141104/cdb48cb7/attachment.html>

From hvriedel at gmail.com  Tue Nov  4 11:20:06 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Tue, 04 Nov 2014 12:20:06 +0100
Subject: Can't install packages with my inplace compiler
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F38F616@DB3PRD3001MB020.064d.mgd.msft.net>
 (Simon Peyton Jones's message of "Tue, 4 Nov 2014 10:55:48 +0000")
References: <618BE556AADD624C9C918AA5D5911BEF3F38F616@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <87ioiv1ac9.fsf@gmail.com>

Hello Simon,

On 2014-11-04 at 11:55:48 +0100, Simon Peyton Jones wrote:
> When I say
>
> cabal install --with-ghc=/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-stage2
>
> I get this
>
> ghc-stage2: ghc no longer supports single-file style package databases
> (dist/package.conf.inplace) use 'ghc-pkg init' to create the database
> with the correct format.
>
> Now, this is an old build tree, and I could blow it away entirely, but
> maybe there is something else going on.  What should I do?

What does `cabal --version` say? If it doesn't say something like

  $ cabal --version
  cabal-install version 1.21.1.0
  using version 1.21.1.0 of the Cabal library 

you probably need a newer one (in which case you should build the
`cabal` binary from Git, and to make life easier compile `Cabal` and
`cabal-install` with GHC 7.8.x rather than GHC HEAD)

Cheers,
  hvr

From simonpj at microsoft.com  Tue Nov  4 11:59:57 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 4 Nov 2014 11:59:57 +0000
Subject: Can't install packages with my inplace compiler
In-Reply-To: <87ioiv1ac9.fsf@gmail.com>
References: <618BE556AADD624C9C918AA5D5911BEF3F38F616@DB3PRD3001MB020.064d.mgd.msft.net>
 <87ioiv1ac9.fsf@gmail.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F390912@DB3PRD3001MB020.064d.mgd.msft.net>

It says 

simonpj at cam-05-unx:~/tmp/singletons-1.0$ cabal --version
cabal-install version 1.21.0.0
using version 1.21.0.0 of the Cabal library


Oddly if I try "cabal update; cabal install cabal-install" it says:
	Resolving dependencies...
	Downloading Cabal-1.20.0.2...

so it looks as if it's about to install an *older* version than the one I have already!

What now?

Thanks

SImon

|  -----Original Message-----
|  From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com]
|  Sent: 04 November 2014 11:20
|  To: Simon Peyton Jones
|  Cc: GHC Devs
|  Subject: Re: Can't install packages with my inplace compiler
|  
|  Hello Simon,
|  
|  On 2014-11-04 at 11:55:48 +0100, Simon Peyton Jones wrote:
|  > When I say
|  >
|  > cabal install
|  > --with-ghc=/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-stage2
|  >
|  > I get this
|  >
|  > ghc-stage2: ghc no longer supports single-file style package
|  databases
|  > (dist/package.conf.inplace) use 'ghc-pkg init' to create the
|  database
|  > with the correct format.
|  >
|  > Now, this is an old build tree, and I could blow it away entirely,
|  but
|  > maybe there is something else going on.  What should I do?
|  
|  What does `cabal --version` say? If it doesn't say something like
|  
|    $ cabal --version
|    cabal-install version 1.21.1.0
|    using version 1.21.1.0 of the Cabal library
|  
|  you probably need a newer one (in which case you should build the
|  `cabal` binary from Git, and to make life easier compile `Cabal` and
|  `cabal-install` with GHC 7.8.x rather than GHC HEAD)
|  
|  Cheers,
|    hvr

From gintautas.miliauskas at gmail.com  Tue Nov  4 12:07:49 2014
From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas)
Date: Tue, 4 Nov 2014 13:07:49 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <CAOYw7duD_LeGNRF6-JZj8jWeV1zV1GVdVGTYu=V3KYMKYTEXSw@mail.gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
 <CAOYw7duty5OoX35NJq-mtc=MqyH6T7L9y2DfzHhWQxYAr1n2bg@mail.gmail.com>
 <CAFC_MeiZiHE+jioQJ36ZBQP4YyQqK3Ysm7uhjsWeUZLz1cnt0Q@mail.gmail.com>
 <CAOYw7duD_LeGNRF6-JZj8jWeV1zV1GVdVGTYu=V3KYMKYTEXSw@mail.gmail.com>
Message-ID: <CAFC_Meh9cc20eL6G_d5H+99+SZhEJMb58w5DtN1ddM5eGn=wcg@mail.gmail.com>

I had a problem <https://github.com/Alexpux/MSYS2-packages/issues/116> with
building msys2-runtime, but debug bash installed successfully.
I uncommented the hook to invoke qtcreator.exe on crashing (your .bat file
needs escaping, puill request pending...), but I'm not quite sure how to
check that it works. I tried building this crasher program with
/usr/bin/gcc:

#include <stdio.h>
int main() {
  char *s = 0;
  printf("hi\n");
  printf("%s\n", s);
  printf("bye\n");
  return 0;
}

But running it just prints "hi", no indications of a crash or anything,
regardless of the value of the MSYS variable:

$ /usr/bin/gcc -o crash crash.c
$ ./crash.exe
hi
$ echo $?
0



On Tue, Nov 4, 2014 at 1:56 AM, Ray Donnelly <mingw.android at gmail.com>
wrote:

> On Tue, Nov 4, 2014 at 12:45 AM, Gintautas Miliauskas
> <gintautas.miliauskas at gmail.com> wrote:
> > I have a suspicion that the segmentation faults are related to fork
> errors,
> > which appear in logs from time to time. After a few builds fork() errors
> > become very frequent, and segfaults seem to occur more often. I just ran
> the
> > build (validate.sh) in a loop, and after a while got a bunch of
> segfaults in
> > Makefile rules as basic as rm invocations in the initial "make clean",
> e.g.:
> >
> > "rm" -rf driver/split/dist
> > driver/split/ghc.mk:19: recipe for target 'clean_driver/split_dist'
> failed
> > make[1]: *** [clean_driver/split_dist] Segmentation fault
> > Makefile:94: recipe for target 'maintainer-clean' failed
> >
> > Closing and reopening the msys2 console seems to help - for some time.
>
> Interesting .. how much process spawning do you think happens? On
> MSYS2 we run massive builds (bootstrapping builds of GCC for 2 arches
> for example), but MSYS2 shares a memory map, so heap corruption could
> happen and cause later problems. My recommendation about building
> debug bash and msys2-runtime and set
> MSYS=error_start:%WD%../../mingw64/bin/qtcreator.exe|-debug|<process-id>
> stands all the more then. You may need to setup path mappings in Qt C
> to map from MSYS2 paths to Windows paths. You need to do this as QtC
> needs to use the native GDB instead of the MSYS2 one so that QtC and
> GDB are in the same pathing namespace.
>
> There may be a way of building msys2-runtime to check for memory
> overruns too, perhaps just building it with the 'debug' option will
> enable that, I'm not sure ..
>
> >
> >
> >
> >
> > On Tue, Nov 4, 2014 at 1:30 AM, Ray Donnelly <mingw.android at gmail.com>
> > wrote:
> >>
> >> On Mon, Nov 3, 2014 at 11:07 PM, Gintautas Miliauskas
> >> <gintautas.miliauskas at gmail.com> wrote:
> >> > +ghc-devs
> >> >
> >> > Hi Ray,
> >> >
> >> > thanks for the feedback. ghc-stage1 is a native application, it is
> built
> >> > using a host ghc and a mingw gcc bundled with the ghc distribution (in
> >> > order
> >> > to keep Windows builds more predictable). The thing is, the same
> builds
> >> > (using make) that were stable on cygwin seem to be crashing on msys2,
> >> > even
> >> > though the (bundled) gcc used for the build is the same. It could be
> >> > that
> >> > msys2 is triggering a bug in ghc somehow, but it could be something
> >> > going on
> >> > in msys2 itself.
> >> >
> >> > The tricky part is that the crashes are rare, one in thousands of ghc
> >> > invocations within a make build, and I'm having trouble pinning one
> down
> >> > to
> >> > investigate. I'll try some basic tracing first, but ideas for
> something
> >> > more
> >> > sophisticated would be very helpful.
> >>
> >> Ah, ok. I skim read your initial email and applied totally incorrect
> >> weighting to the "not very hard to reproduce" bit, apologies!
> >>
> >> It *should* be possible to setup post-mortem debugging using either Qt
> >> Creator (Tools->Options->Debugger, tick "Use Qt Creator for
> >> post-mortem debugging") or Dr. Mingw
> >> (https://github.com/jrfonseca/drmingw). I briefly tested both options:
> >>
> >> Qt Creator: It seems there's a bug in its handling of the
> >> -wincrashevent command line which I've just added a note about to the
> >> MINGW-packages todo list since I'd find this feature more than very
> >> useful:
> >> https://github.com/Alexpux/MINGW-packages/blob/master/TODO.md
> >>
> >> Dr Mingw: Launching the crashing executable from Windows Explorer, it
> >> launches it and gives me useful information.
> >>
> >> Unfortunately, regardless of the debugger used, when invoking the
> >> crashing executable from the mintty commandline, something inhibits
> >> all post mortem debugging. I will ask the mingw-w64 guys if they know
> >> what this is. I guess intrusive dialogs would be annoying, but I'd
> >> like an env. var override for that I think.
> >>
> >> There is another possibility, and that's that bash is crashing, which
> >> is an MSYS2 program. We do have a way of hooking into post-mortem
> >> debugging there since Cygwin provided a way and we improved it. If you
> >> check your msys2_shell.bat you'll see:
> >> rem set
> >> MSYS=error_start:%WD%../../mingw64/bin/qtcreator.exe|-debug|<process-id>
> >>
> >> If you remove the rem and make sure the path is correct (it may have
> >> rotted some since I last used it) then hopefully you'll get something
> >> useful. To be really useful, you should rebuild two packages,
> >> MSYS2-packages/{msys2-runtime,bash}/PKGBUILD with
> >> options=('debug' '!strip')
> >> and then install them.
> >>
> >> Finally, can anyone else confirm the problem?
> >>
> >> There may be some edge cases when e.g. PATH is around 1024 characters,
> >> I've seen some hardcoded limits in the msys2-runtime (nee Cygwin)
> >> code base for things like that. I'd advise cutting your Windows PATH
> >> down to just the essentials.
> >>
> >> Cheers,
> >>
> >> Ray.
> >>
> >> >
> >> > A PKGBUILD for ghc should be feasible, although the bootstrapping is a
> >> > bit
> >> > tricky (some Haskell tools need to be preinstalled). I'm not sure how
> >> > useful
> >> > it would be since for Windows there is already a nicely packaged
> native
> >> > Haskell Platform installer.
> >> >
> >> >
> >> > On Mon, Nov 3, 2014 at 3:30 AM, Ray Donnelly <mingw.android at gmail.com
> >
> >> > wrote:
> >> >>
> >> >> On Sun, Nov 2, 2014 at 11:45 PM, Gintautas Miliauskas
> >> >> <gintautas.miliauskas at gmail.com> wrote:
> >> >> > Hello,
> >> >> >
> >> >> > I have been working on building GHC, the Glasgow Haskell Compiler,
> on
> >> >> > Windows using msys2 [1]. We have been having some strange trouble
> >> >> > with
> >> >> > ghc
> >> >> > segfaulting during the bootstrapping process (i.e., during make).
> The
> >> >> > crashes are not very hard to reproduce, but they are not
> predictable
> >> >> > either.
> >> >> > This is almost certainly a bug in ghc itself and not with msys2
> >> >> > (although
> >> >> > the crashes do not seem to occur in other environments), but I've
> >> >> > been
> >> >> > having some trouble pinning it down.
> >> >> >
> >> >>
> >> >> Hi Gintuatas,
> >> >>
> >> >> Great. I spotted that MSYS2 was the recommended env. for GHC on
> >> >> Windows, hopefully it will remain so!
> >> >>
> >> >> > What's a good way to debug such crashes? Is it possible to somehow
> >> >> > stop
> >> >> > the
> >> >> > ghc process when it segfaults and attach gdb, or to dump core
> somehow
> >> >> > for
> >> >> > later inspection?
> >> >> >
> >> >> > [1]
> >> >> > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows
> >> >> >
> >> >> > Here's one example crash:
> >> >> >
> >> >> > "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf  o -hcsuf hc -static
> >> >> > -H32m
> >> >> > -O
> >> >> > -Werror -Wall -H64m -O0    -this-package-key
> >> >> > ghc_4ugNArSu5ba0Z1uHXrbTlU
> >> >> > -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm
> >> >> > -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar
> >> >> > -icompiler/ghci
> >> >> > -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen
> -icompiler/main
> >> >> > -icompiler/nativeGen -icompiler/parser -icompiler/prelude
> >> >> > -icompiler/profiling -icompiler/rename -icompiler/simplCore
> >> >> > -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn
> >> >> > -icompiler/stranal -icompiler/typecheck -icompiler/types
> >> >> > -icompiler/utils
> >> >> > -icompiler/vectorise -icompiler/stage2/build
> >> >> > -icompiler/stage2/build/autogen
> >> >> > -Icompiler/stage2/build -Icompiler/stage2/build/autogen
> -Icompiler/.
> >> >> > -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build
> >> >> > -Icompiler/stage2   -optP-DGHCI -optP-include
> >> >> > -optPcompiler/stage2/build/autogen/cabal_macros.h -package-key
> >> >> > Win32_43THQMouBnk2wpnouztX1X -package-key
> >> >> > array_GX4NwjS8xZkC2ZPtjgwhnz
> >> >> > -package-key base_ESD4aQEEWwsHtYJVc1BwtJ -package-key
> >> >> > binpa_17GphrLqCXt1H1lm4Kse1p -package-key
> >> >> > bytes_Kc0PyaputnzDnBdZW0y2Gv
> >> >> > -package-key conta_ChF4XLXB9JmByIycPzerow -package-key
> >> >> > direc_HU5aFxMIQNwGQFzisjuinu -package-key
> >> >> > filep_34DFDFT9FVD9pRLLgh8IdQ
> >> >> > -package-key hoopl_IZAd44CED5NCOlpg8p2Kaj -package-key
> >> >> > hpc_1QTsfQSN40FHN9p3mydARY -package-key
> proce_7ZlAbRkwiRO8qgXx3NNP0G
> >> >> > -package-key templ_F6UJgDtBcDIFWuHmMGEFzy -package-key
> >> >> > time_HGs4JcQCd4wF6U8vJQ5fNH -package-key
> trans_5jw4w9yTgmZ89ByuixDAKP
> >> >> > -Wall
> >> >> > -fno-warn-name-shadowing -this-package-key ghc -XHaskell2010
> >> >> > -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2
> -Rghc-timing
> >> >> > -O2
> >> >> > -fwarn-tabs -O -dcore-lint  -no-user-package-db -rtsopts      -odir
> >> >> > compiler/stage2/build -hidir compiler/stage2/build -stubdir
> >> >> > compiler/stage2/build   -c compiler/basicTypes/UniqSupply.lhs -o
> >> >> > compiler/stage2/build/UniqSupply.o
> >> >> >
> >> >> > compiler/ghc.mk:657: recipe for target
> >> >> > 'compiler/stage2/build/UniqSupply.o'
> >> >> > failed
> >> >> > make[1]: *** [compiler/stage2/build/UniqSupply.o] Segmentation
> fault
> >> >> >
> >> >>
> >> >> Well, it's pretty much the same story as with Linux. Build the
> >> >> executable and as many libraries as you can with (something like)
> >> >> "-ggdb -O0" then use gdb command line or some IDE of choice.
> >> >> Personally I use Qt Creator (we have packages for this) as it can
> >> >> debug external programs and, even though I don't dislike command
> >> >> lines, I find debugging from them a bit too masochistic.
> >> >>
> >> >> Is ghc-stage1.exe an MSYS2 program or a native one? Which compiler is
> >> >> it built with exactly?
> >> >>
> >> >> What would be involved in creating a PKGBUILD for ghc? We'd love to
> >> >> have one, and it'd certainly make me a lot more inclined to dive in
> to
> >> >> see what's going on if one existed already.
> >> >>
> >> >> Ray.
> >> >>
> >> >> >
> >> >> > --
> >> >> > Gintautas Miliauskas
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> ------------------------------------------------------------------------------
> >> >> >
> >> >> > _______________________________________________
> >> >> > Msys2-users mailing list
> >> >> > Msys2-users at lists.sourceforge.net
> >> >> > https://lists.sourceforge.net/lists/listinfo/msys2-users
> >> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Gintautas Miliauskas
> >
> >
> >
> >
> > --
> > Gintautas Miliauskas
>



-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141104/40a0330f/attachment-0001.html>

From david.macek.0 at gmail.com  Tue Nov  4 12:28:20 2014
From: david.macek.0 at gmail.com (David Macek)
Date: Tue, 04 Nov 2014 13:28:20 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <CAFC_Meh9cc20eL6G_d5H+99+SZhEJMb58w5DtN1ddM5eGn=wcg@mail.gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
 <CAOYw7duty5OoX35NJq-mtc=MqyH6T7L9y2DfzHhWQxYAr1n2bg@mail.gmail.com>
 <CAFC_MeiZiHE+jioQJ36ZBQP4YyQqK3Ysm7uhjsWeUZLz1cnt0Q@mail.gmail.com>
 <CAOYw7duD_LeGNRF6-JZj8jWeV1zV1GVdVGTYu=V3KYMKYTEXSw@mail.gmail.com>
 <CAFC_Meh9cc20eL6G_d5H+99+SZhEJMb58w5DtN1ddM5eGn=wcg@mail.gmail.com>
Message-ID: <5458C664.9060507@gmail.com>

On 4. 11. 2014 13:07, Gintautas Miliauskas wrote:
> But running it just prints "hi", no indications of a crash or anything, regardless of the value of the MSYS variable:

Either the compiler, or C library is too smart for this. I'd guess your compiler is working with undefined behavior optimizations, because with my compiler, I get both "hi" and "bye" (or not, when I pass -Og). Try this code:

#include <stdio.h>
int main() {
  printf("hi\n");
  ((void(*)())(0))();
  printf("bye\n");
  return 0;
}


-- 
David Macek

From simonpj at microsoft.com  Tue Nov  4 12:39:48 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 4 Nov 2014 12:39:48 +0000
Subject: [Diffusion] [Build Failed] rGHC652a5efe774a: Add flattening-notes
In-Reply-To: <20141104122759.85192.92836@phabricator.haskell.org>
References: <diffusion-audit-PHID-CMIT-pbf7wwwssuv4udcbhgzw@phabricator.haskell.org>
 <20141104122759.85192.92836@phabricator.haskell.org>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F390B40@DB3PRD3001MB020.064d.mgd.msft.net>

I'm seeing all these build failures, but it builds fine for me.

Simon

|  -----Original Message-----
|  From: noreply at phabricator.haskell.org
|  [mailto:noreply at phabricator.haskell.org]
|  Sent: 04 November 2014 12:28
|  To: Simon Peyton Jones
|  Subject: [Diffusion] [Build Failed] rGHC652a5efe774a: Add flattening-
|  notes
|  
|  Harbormaster failed to build B1665: rGHC652a5efe774a: Add flattening-
|  notes!
|  
|  USERS
|    simonpj (Author)
|    GHC - Type checker/inferencer (Auditor)
|  
|  COMMIT
|    https://phabricator.haskell.org/rGHC652a5efe774a
|  
|  To: simonpj, GHC - Type checker/inferencer

From david.macek.0 at gmail.com  Tue Nov  4 12:57:24 2014
From: david.macek.0 at gmail.com (David Macek)
Date: Tue, 04 Nov 2014 13:57:24 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <CAOYw7duty5OoX35NJq-mtc=MqyH6T7L9y2DfzHhWQxYAr1n2bg@mail.gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>	<CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>	<CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
 <CAOYw7duty5OoX35NJq-mtc=MqyH6T7L9y2DfzHhWQxYAr1n2bg@mail.gmail.com>
Message-ID: <5458CD34.6040600@gmail.com>

On 4. 11. 2014 1:30, Ray Donnelly wrote:
> Finally, can anyone else confirm the problem?

I'm sorry if I missed it, but I can't find what source version you're using, Gintautas. Release/trunk?

-- 
David Macek

From gintautas.miliauskas at gmail.com  Tue Nov  4 13:14:14 2014
From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas)
Date: Tue, 4 Nov 2014 14:14:14 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <5458CD34.6040600@gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
 <CAOYw7duty5OoX35NJq-mtc=MqyH6T7L9y2DfzHhWQxYAr1n2bg@mail.gmail.com>
 <5458CD34.6040600@gmail.com>
Message-ID: <CAFC_Meg_UZATRAWKnf5daM5Qo0eCYp6CUPh1fovnC7gVATeQwg@mail.gmail.com>

I'm working on ghc trunk.

You were indeed right, the compiler was probably optimizing out my code.
The suggested crasher code works, and qtcreator gets invoked, although I
did not manage to set up gdb yet.

I think I have an idea of what's going wrong here. hvr@ was right in
pointing out that we need to be careful with the PATH. It seems that the
bundled gcc is picking up the system-wide DLLs, and bad things happen
because of version incompatibilities. That does not explain why "rm" is
crashing, but maybe that's fallout from cross-process damage. I will do
some more testing. If this is indeed the cause, then hopefully debugging
will not be needed anyway.

On Tue, Nov 4, 2014 at 1:57 PM, David Macek <david.macek.0 at gmail.com> wrote:

> On 4. 11. 2014 1:30, Ray Donnelly wrote:
> > Finally, can anyone else confirm the problem?
>
> I'm sorry if I missed it, but I can't find what source version you're
> using, Gintautas. Release/trunk?
>
> --
> David Macek
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141104/c6d81b2b/attachment.html>

From thomasmiedema at gmail.com  Tue Nov  4 13:39:49 2014
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Tue, 4 Nov 2014 14:39:49 +0100
Subject: [Diffusion] [Build Failed] rGHC652a5efe774a: Add flattening-notes
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F390B40@DB3PRD3001MB020.064d.mgd.msft.net>
References: <diffusion-audit-PHID-CMIT-pbf7wwwssuv4udcbhgzw@phabricator.haskell.org>
 <20141104122759.85192.92836@phabricator.haskell.org>
 <618BE556AADD624C9C918AA5D5911BEF3F390B40@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CAD3WKgg-NKPSd_2u+MJSuQusm2srnfwS06WM9VHwr4FCEtU7qA@mail.gmail.com>

current master builds fine, but it doesn't validate
<https://phabricator.haskell.org/harbormaster/build/1678/>. The error is:
"perf/compiler T5631 [stat not good enough]"

You can see the validate status of all commits on this page:
https://phabricator.haskell.org/diffusion/GHC/history/


On Tue, Nov 4, 2014 at 1:39 PM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> I'm seeing all these build failures, but it builds fine for me.
>
> Simon
>
> |  -----Original Message-----
> |  From: noreply at phabricator.haskell.org
> |  [mailto:noreply at phabricator.haskell.org]
> |  Sent: 04 November 2014 12:28
> |  To: Simon Peyton Jones
> |  Subject: [Diffusion] [Build Failed] rGHC652a5efe774a: Add flattening-
> |  notes
> |
> |  Harbormaster failed to build B1665: rGHC652a5efe774a: Add flattening-
> |  notes!
> |
> |  USERS
> |    simonpj (Author)
> |    GHC - Type checker/inferencer (Auditor)
> |
> |  COMMIT
> |    https://phabricator.haskell.org/rGHC652a5efe774a
> |
> |  To: simonpj, GHC - Type checker/inferencer
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141104/e7844ea1/attachment.html>

From simonpj at microsoft.com  Tue Nov  4 13:53:24 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 4 Nov 2014 13:53:24 +0000
Subject: [Diffusion] [Build Failed] rGHC652a5efe774a: Add flattening-notes
In-Reply-To: <CAD3WKgg-NKPSd_2u+MJSuQusm2srnfwS06WM9VHwr4FCEtU7qA@mail.gmail.com>
References: <diffusion-audit-PHID-CMIT-pbf7wwwssuv4udcbhgzw@phabricator.haskell.org>
 <20141104122759.85192.92836@phabricator.haskell.org>
 <618BE556AADD624C9C918AA5D5911BEF3F390B40@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAD3WKgg-NKPSd_2u+MJSuQusm2srnfwS06WM9VHwr4FCEtU7qA@mail.gmail.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F390CF0@DB3PRD3001MB020.064d.mgd.msft.net>

Ah, thanks. I think the commit I was looking at was *before* the major fixup.  Sorry

Looking one at the end, I do see just the one failure you mention
Unexpected stat failures:

perf/compiler T5631 [stat not good enough] (normal)


But I can?t persuade Phab to show me the build log, and it doesn?t happen for me. So I am stuck once more.

Simon

From: Thomas Miedema [mailto:thomasmiedema at gmail.com]
Sent: 04 November 2014 13:40
To: Simon Peyton Jones
Cc: GHC Devs
Subject: Re: [Diffusion] [Build Failed] rGHC652a5efe774a: Add flattening-notes

current master builds fine, but it doesn't validate<https://phabricator.haskell.org/harbormaster/build/1678/>. The error is: "perf/compiler T5631 [stat not good enough]"

You can see the validate status of all commits on this page:
https://phabricator.haskell.org/diffusion/GHC/history/


On Tue, Nov 4, 2014 at 1:39 PM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
I'm seeing all these build failures, but it builds fine for me.

Simon

|  -----Original Message-----
|  From: noreply at phabricator.haskell.org<mailto:noreply at phabricator.haskell.org>
|  [mailto:noreply at phabricator.haskell.org<mailto:noreply at phabricator.haskell.org>]
|  Sent: 04 November 2014 12:28
|  To: Simon Peyton Jones
|  Subject: [Diffusion] [Build Failed] rGHC652a5efe774a: Add flattening-
|  notes
|
|  Harbormaster failed to build B1665: rGHC652a5efe774a: Add flattening-
|  notes!
|
|  USERS
|    simonpj (Author)
|    GHC - Type checker/inferencer (Auditor)
|
|  COMMIT
|    https://phabricator.haskell.org/rGHC652a5efe774a
|
|  To: simonpj, GHC - Type checker/inferencer
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://www.haskell.org/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141104/ad09a503/attachment-0001.html>

From david.macek.0 at gmail.com  Tue Nov  4 15:10:53 2014
From: david.macek.0 at gmail.com (David Macek)
Date: Tue, 04 Nov 2014 16:10:53 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <CAFC_Meg_UZATRAWKnf5daM5Qo0eCYp6CUPh1fovnC7gVATeQwg@mail.gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
 <CAOYw7duty5OoX35NJq-mtc=MqyH6T7L9y2DfzHhWQxYAr1n2bg@mail.gmail.com>
 <5458CD34.6040600@gmail.com>
 <CAFC_Meg_UZATRAWKnf5daM5Qo0eCYp6CUPh1fovnC7gVATeQwg@mail.gmail.com>
Message-ID: <5458EC7D.3080008@gmail.com>

On 4. 11. 2014 14:14, Gintautas Miliauskas wrote:
> I'm working on ghc trunk.

I'm trying to reproduce your errors, but I failed at ./boot with:

Booting .
'autoreconf' is not recognized as an internal or external command,
operable program or batch file.
Running autoreconf failed with exitcode 256 at ./boot line 163, <PKGS> line 12.

It seems that /mingw64/bin/perl's system("autoreconf") fails to execute because it's passing the command line to cmd, not bash (/usr/bin/autoreconf is a script).

Gintautas, do you have mingw-w64-x86_64-perl installed?

Can we do something about this, or is boot going to work only in pure msys2 shell?

-- 
David Macek

From simonpj at microsoft.com  Tue Nov  4 15:38:52 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 4 Nov 2014 15:38:52 +0000
Subject: Phab and I differ
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F391D67@DB3PRD3001MB020.064d.mgd.msft.net>

I built and validated this commit just fine.  Phab says

Unexpected failures:
ghci/should_run ghcirun004 [bad stdout or stderr] (ghci)
rts linker_unload [bad exit code] (normal)
stranal/should_compile str001 [exit code non-0] (optasm)
stranal/should_compile str002 [exit code non-0] (optasm)
stranal/should_compile test [exit code non-0] (optasm)


but none of them fail for me.  I don't know how to see enough of Phab's log to see what it thinks when wrong. (it just shows me 25 lines; clicking on "unlimited" still only shows 30  lines)

|  -----Original Message-----
|  From: noreply at phabricator.haskell.org
|  [mailto:noreply at phabricator.haskell.org]
|  Sent: 04 November 2014 15:32
|  To: Simon Peyton Jones
|  Subject: [Diffusion] [Build Failed] rGHC6a1c05f01429: A little
|  refactoring of HsSplice and friends
|  
|  Harbormaster failed to build B1678: rGHC6a1c05f01429: A little
|  refactoring of HsSplice and friends!
|  
|  USERS
|    simonpj (Author)
|    GHC - Type checker/inferencer (Auditor)
|    GHC - Core/System FC (Auditor)
|    GHC - Renamer (Auditor)
|    GHC - HsSyn/Parser (Auditor)
|  
|  COMMIT
|    https://phabricator.haskell.org/rGHC6a1c05f01429
|  
|  To: simonpj, GHC - Type checker/inferencer, GHC - Core/System FC, GHC
|  - Renamer, GHC - HsSyn/Parser

From gintautas.miliauskas at gmail.com  Tue Nov  4 15:44:44 2014
From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas)
Date: Tue, 4 Nov 2014 16:44:44 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <CAFC_Meg_UZATRAWKnf5daM5Qo0eCYp6CUPh1fovnC7gVATeQwg@mail.gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
 <CAOYw7duty5OoX35NJq-mtc=MqyH6T7L9y2DfzHhWQxYAr1n2bg@mail.gmail.com>
 <5458CD34.6040600@gmail.com>
 <CAFC_Meg_UZATRAWKnf5daM5Qo0eCYp6CUPh1fovnC7gVATeQwg@mail.gmail.com>
Message-ID: <CAFC_Meg9dT1kxr7ohBvuLGk=envCnwqUixXwDO1ZpGHi7BTG1Q@mail.gmail.com>

>
>
> I think I have an idea of what's going wrong here. hvr@ was right in
> pointing out that we need to be careful with the PATH. It seems that the
> bundled gcc is picking up the system-wide DLLs, and bad things happen
> because of version incompatibilities. That does not explain why "rm" is
> crashing, but maybe that's fallout from cross-process damage. I will do
> some more testing. If this is indeed the cause, then hopefully debugging
> will not be needed anyway.
>

Update: even after setting PATH to have the embedded gcc path in the first
position to make sure that the right DLLs are, I still got a few segfaults,
so this is probably not it.

-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141104/f7f20794/attachment.html>

From gintautas.miliauskas at gmail.com  Tue Nov  4 15:46:24 2014
From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas)
Date: Tue, 4 Nov 2014 16:46:24 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <5458EC7D.3080008@gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
 <CAOYw7duty5OoX35NJq-mtc=MqyH6T7L9y2DfzHhWQxYAr1n2bg@mail.gmail.com>
 <5458CD34.6040600@gmail.com>
 <CAFC_Meg_UZATRAWKnf5daM5Qo0eCYp6CUPh1fovnC7gVATeQwg@mail.gmail.com>
 <5458EC7D.3080008@gmail.com>
Message-ID: <CAFC_Meiy4REPCsKyYmZDSLsEZq-CY5RSTaPb4k1SL2EFH7Wzqw@mail.gmail.com>

I'm using /usr/bin/perl, and don't have the mingw perl installed.

On Tue, Nov 4, 2014 at 4:10 PM, David Macek <david.macek.0 at gmail.com> wrote:

> On 4. 11. 2014 14:14, Gintautas Miliauskas wrote:
> > I'm working on ghc trunk.
>
> I'm trying to reproduce your errors, but I failed at ./boot with:
>
> Booting .
> 'autoreconf' is not recognized as an internal or external command,
> operable program or batch file.
> Running autoreconf failed with exitcode 256 at ./boot line 163, <PKGS>
> line 12.
>
> It seems that /mingw64/bin/perl's system("autoreconf") fails to execute
> because it's passing the command line to cmd, not bash (/usr/bin/autoreconf
> is a script).
>
> Gintautas, do you have mingw-w64-x86_64-perl installed?
>
> Can we do something about this, or is boot going to work only in pure
> msys2 shell?
>
> --
> David Macek
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141104/30cb3a92/attachment.html>

From hvriedel at gmail.com  Tue Nov  4 16:07:35 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Tue, 04 Nov 2014 17:07:35 +0100
Subject: Phab and I differ
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F391D67@DB3PRD3001MB020.064d.mgd.msft.net>
 (Simon Peyton Jones's message of "Tue, 4 Nov 2014 15:38:52 +0000")
References: <618BE556AADD624C9C918AA5D5911BEF3F391D67@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <87y4rrymns.fsf@gmail.com>

On 2014-11-04 at 16:38:52 +0100, Simon Peyton Jones wrote:
> I built and validated this commit just fine.  Phab says
>
> Unexpected failures:
> ghci/should_run ghcirun004 [bad stdout or stderr] (ghci)
> rts linker_unload [bad exit code] (normal)
> stranal/should_compile str001 [exit code non-0] (optasm)
> stranal/should_compile str002 [exit code non-0] (optasm)
> stranal/should_compile test [exit code non-0] (optasm)
>
>
> but none of them fail for me.  I don't know how to see enough of
> Phab's log to see what it thinks when wrong. (it just shows me 25
> lines; clicking on "unlimited" still only shows 30 lines)

It seems to me that compiling T3064 may be the culprit, as that seems
to eat up an humongous amount of RAM...

From merijn at inconsistent.nl  Tue Nov  4 17:18:44 2014
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Tue, 4 Nov 2014 09:18:44 -0800
Subject: Problem with select(2) in single threaded runtime.
In-Reply-To: <87oasn1hzr.fsf@gmail.com>
References: <BE8FFA80-AF02-46D9-B686-B49D2904E3E4@inconsistent.nl>
 <94903F9A-97C6-4B23-B8E6-DEB6317018AF@inconsistent.nl>
 <87oasn1hzr.fsf@gmail.com>
Message-ID: <5949308B-F8C4-4F10-BE02-525B392B4019@inconsistent.nl>

Hi Herbert,

> On 4 Nov 2014, at 0:34, Herbert Valerio Riedel <hvriedel at gmail.com> wrote:
> 
> Was the passed `timeval` structure valid? I.e. is the tv_usec value inside
> the [0,1e6-1] range? and was tv_sec>=0 ?

The simple test I wrote is:

#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <limits.h>
#include <sys/select.h>
#include <sys/time.h>

int main(int argc, char **argv)
{
    fd_set set;
    FD_ZERO(&set);

    struct timeval tv;
    tv.tv_sec = INT_MAX;
    tv.tv_usec = 0;

    FD_SET(0, &set);

    int ret = select(1, &set, &set, &set, &tv);
    printf("Result %d: %s\n", ret, strerror(errno));
    printf("time_t: %lu suseconds_t: %lu\n", sizeof(time_t), sizeof(suseconds_t));
    return 0;
}

This exits with EINVAL for me on OSX, if I replace INT_MAX with 1000, it runs just fine. The man page on OSX mentions EINVAL for values that exceed the maximum timeout, so it looks like OSX is not following the spec, then...

Cheers,
Merijn

From hvriedel at gmail.com  Tue Nov  4 17:32:30 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Tue, 04 Nov 2014 18:32:30 +0100
Subject: Problem with select(2) in single threaded runtime.
In-Reply-To: <5949308B-F8C4-4F10-BE02-525B392B4019@inconsistent.nl> (Merijn
 Verstraaten's message of "Tue, 4 Nov 2014 09:18:44 -0800")
References: <BE8FFA80-AF02-46D9-B686-B49D2904E3E4@inconsistent.nl>
 <94903F9A-97C6-4B23-B8E6-DEB6317018AF@inconsistent.nl>
 <87oasn1hzr.fsf@gmail.com>
 <5949308B-F8C4-4F10-BE02-525B392B4019@inconsistent.nl>
Message-ID: <87r3xizxap.fsf@gmail.com>

On 2014-11-04 at 18:18:44 +0100, Merijn Verstraaten wrote:

[...]

> This exits with EINVAL for me on OSX, if I replace INT_MAX with 1000,
> it runs just fine. The man page on OSX mentions EINVAL for values that
> exceed the maximum timeout, so it looks like OSX is not following the
> spec, then...

Btw, I also stumbled over these ancient bug-reports:

 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=18909

 http://gnats.netbsd.org/11287

So it seems that BSD-ish systems have (or had?) this arbitrary 1e8
second limit in combination with the questionable EINVAL response which
seems in conflict with the POSIX specification.

I'm wondering if there's already an Autoconf test somewhere we could
steal for detecting this peculiarity of select() on BSD systems...

Cheers,
  hvr

From eir at cis.upenn.edu  Tue Nov  4 18:17:13 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 4 Nov 2014 13:17:13 -0500
Subject: Phab and I differ
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F391D67@DB3PRD3001MB020.064d.mgd.msft.net>
References: <618BE556AADD624C9C918AA5D5911BEF3F391D67@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <A8E29DFD-A313-4BFD-91D8-3FFA638A3167@cis.upenn.edu>

Is it possible to get the full build logs on Phab? I just had a testsuite (framework) failure, but I can't see what test caused it! (https://phabricator.haskell.org/harbormaster/build/1686/)

Thanks,
Richard

On Nov 4, 2014, at 10:38 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> I built and validated this commit just fine.  Phab says
> 
> Unexpected failures:
> ghci/should_run ghcirun004 [bad stdout or stderr] (ghci)
> rts linker_unload [bad exit code] (normal)
> stranal/should_compile str001 [exit code non-0] (optasm)
> stranal/should_compile str002 [exit code non-0] (optasm)
> stranal/should_compile test [exit code non-0] (optasm)
> 
> 
> but none of them fail for me.  I don't know how to see enough of Phab's log to see what it thinks when wrong. (it just shows me 25 lines; clicking on "unlimited" still only shows 30  lines)
> 
> |  -----Original Message-----
> |  From: noreply at phabricator.haskell.org
> |  [mailto:noreply at phabricator.haskell.org]
> |  Sent: 04 November 2014 15:32
> |  To: Simon Peyton Jones
> |  Subject: [Diffusion] [Build Failed] rGHC6a1c05f01429: A little
> |  refactoring of HsSplice and friends
> |  
> |  Harbormaster failed to build B1678: rGHC6a1c05f01429: A little
> |  refactoring of HsSplice and friends!
> |  
> |  USERS
> |    simonpj (Author)
> |    GHC - Type checker/inferencer (Auditor)
> |    GHC - Core/System FC (Auditor)
> |    GHC - Renamer (Auditor)
> |    GHC - HsSyn/Parser (Auditor)
> |  
> |  COMMIT
> |    https://phabricator.haskell.org/rGHC6a1c05f01429
> |  
> |  To: simonpj, GHC - Type checker/inferencer, GHC - Core/System FC, GHC
> |  - Renamer, GHC - HsSyn/Parser
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From moritz at lichtzwerge.de  Tue Nov  4 18:28:18 2014
From: moritz at lichtzwerge.de (Moritz Angermann)
Date: Tue, 4 Nov 2014 19:28:18 +0100
Subject: Building head with head
Message-ID: <611257BE-C328-491D-AD04-C66C4ABB09D1@lichtzwerge.de>

Hi,

today I tried to build head with head on os x.  The result was:

Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal ...
"touch" utils/ghc-cabal/dist/build/tmp/ghc-cabal
"cp" utils/ghc-cabal/dist/build/tmp/ghc-cabal inplace/bin/ghc-cabal
"inplace/bin/ghc-cabal" configure libraries/binary dist-boot "" --with-ghc="/usr/local/bin/ghc" --with-ghc-pkg="/usr/local/bin/ghc-pkg"  --package-db=/Users/angerman/code/ghc/libraries/bootstrapping.conf --disable-library-for-ghci --enable-library-vanilla --disable-library-profiling --disable-shared --configure-option=CFLAGS=" -m64 -fno-stack-protector   " --configure-option=LDFLAGS=" -m64  " --configure-option=CPPFLAGS=" -m64  " --gcc-options=" -m64 -fno-stack-protector     -m64  "   --constraint "binary == 0.7.1.0"   --constraint "Cabal == 1.21.1.0"   --constraint "hpc == 0.6.0.2"   --constraint "bin-package-db == 0.0.0.0"   --constraint "hoopl == 3.10.0.2"   --constraint "transformers == 0.4.1.0"   --constraint "terminfo == 0.4.0.0" --with-gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-alex="/Users/angerman/.cabal/bin/alex" --with-happy="/Users/angerman/.cabal/bin/happy"
"inplace/bin/ghc-cabal" configure utils/hsc2hs dist "" --with-ghc="/usr/local/bin/ghc" --with-ghc-pkg="/usr/local/bin/ghc-pkg"  --package-db=/Users/angerman/code/ghc/libraries/bootstrapping.conf --disable-library-for-ghci --disable-library-vanilla --disable-library-profiling --disable-shared --configure-option=CFLAGS=" -m64 -fno-stack-protector   " --configure-option=LDFLAGS=" -m64  " --configure-option=CPPFLAGS=" -m64  " --gcc-options=" -m64 -fno-stack-protector     -m64  "   --constraint "binary == 0.7.1.0"   --constraint "Cabal == 1.21.1.0"   --constraint "hpc == 0.6.0.2"   --constraint "bin-package-db == 0.0.0.0"   --constraint "hoopl == 3.10.0.2"   --constraint "transformers == 0.4.1.0"   --constraint "terminfo == 0.4.0.0" --with-gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-alex="/Users/angerman/.cabal/bin/alex" --with-happy="/Users/angerman/.cabal/bin/happy"
Configuring hsc2hs-0.67...
Configuring binary-0.7.1.0...
ghc-cabal: '/usr/local/bin/ghc-pkg' exited with an error:
ghc-pkg: ghc no longer supports single-file style package databases
(/Users/angerman/code/ghc/libraries/bootstrapping.conf)
use 'ghc-pkg init' to create the database with the correct format.
make[1]: *** [utils/hsc2hs/dist/package-data.mk] Error 1
make[1]: *** Waiting for unfinished jobs....
ghc-cabal: '/usr/local/bin/ghc-pkg' exited with an error:
ghc-pkg: ghc no longer supports single-file style package databases
(/Users/angerman/code/ghc/libraries/bootstrapping.conf)
use 'ghc-pkg init' to create the database with the correct format.
make[1]: *** [libraries/binary/dist-boot/package-data.mk] Error 1

Does anyone know what needs to be done to make this work?

Best,
 Moritz

From david.macek.0 at gmail.com  Tue Nov  4 18:43:36 2014
From: david.macek.0 at gmail.com (David Macek)
Date: Tue, 04 Nov 2014 19:43:36 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <CAFC_Meiy4REPCsKyYmZDSLsEZq-CY5RSTaPb4k1SL2EFH7Wzqw@mail.gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
 <CAOYw7duty5OoX35NJq-mtc=MqyH6T7L9y2DfzHhWQxYAr1n2bg@mail.gmail.com>
 <5458CD34.6040600@gmail.com>
 <CAFC_Meg_UZATRAWKnf5daM5Qo0eCYp6CUPh1fovnC7gVATeQwg@mail.gmail.com>
 <5458EC7D.3080008@gmail.com>
 <CAFC_Meiy4REPCsKyYmZDSLsEZq-CY5RSTaPb4k1SL2EFH7Wzqw@mail.gmail.com>
Message-ID: <54591E58.2060002@gmail.com>

Hi. I just built GHC from master (1c35f9f1cb7a293da85d649904ce731a65824cfe) in my somewhat outdated MSYS2. I followed the wiki page with a few exceptions.

- I cleared my PATH before running the shell (I left only Windows and System32)
- my installation is not up-to-date
- I do not have msys2 libtool, automake nor binutils; if the build used any of those, they came from mingw64 or from the host ghc
- I had to run boot in pure msys2 shell, because mingw64 perl caused it to fail

I saw no segfaults, but I may have missed them. I did not get a ghc.exe, but that may be correct behavior for all I know. My simple test program compiled and ran fine. I saw a lot of warnings during ghc's build though:

- checking for DocBook DTD... I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd
- something with not finding any implementation of a module out of [ xxx.dylib, xxx, ... ], I think it was in cabal builds
- "could not find link destionations for: xxx"

I hope it helps somehow. Maybe your issues come from mixing msys2 and mingw toolchain after all.



-- 
David Macek

From hvriedel at gmail.com  Tue Nov  4 18:48:08 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Tue, 04 Nov 2014 19:48:08 +0100
Subject: Phab and I differ
In-Reply-To: <A8E29DFD-A313-4BFD-91D8-3FFA638A3167@cis.upenn.edu> (Richard
 Eisenberg's message of "Tue, 4 Nov 2014 13:17:13 -0500")
References: <618BE556AADD624C9C918AA5D5911BEF3F391D67@DB3PRD3001MB020.064d.mgd.msft.net>
 <A8E29DFD-A313-4BFD-91D8-3FFA638A3167@cis.upenn.edu>
Message-ID: <87mw86ztsn.fsf@gmail.com>

On 2014-11-04 at 19:17:13 +0100, Richard Eisenberg wrote:
> Is it possible to get the full build logs on Phab? I just had a
> testsuite (framework) failure, but I can't see what test caused it!
> (https://phabricator.haskell.org/harbormaster/build/1686/)

It's most likely the T3064 test-case (eating up time & space resources)
I mentioned in an earlier post that leads to these framework failures
and similar collateral test-case failures.

From ezyang at mit.edu  Tue Nov  4 18:49:46 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Tue, 04 Nov 2014 10:49:46 -0800
Subject: Can't install packages with my inplace compiler
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F390912@DB3PRD3001MB020.064d.mgd.msft.net>
References: <618BE556AADD624C9C918AA5D5911BEF3F38F616@DB3PRD3001MB020.064d.mgd.msft.net>
 <87ioiv1ac9.fsf@gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F390912@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <1415126925-sup-4219@sabre>

Yeah, that's too old; and there's not been a release of a Cabal
which is new enough to do what you want.

Try:

    git clone https://github.com/haskell/cabal
    cd cabal/Cabal
    cabal install
    cd ../cabal-install
    cabal install

Edward

Excerpts from Simon Peyton Jones's message of 2014-11-04 03:59:57 -0800:
> It says 
> 
> simonpj at cam-05-unx:~/tmp/singletons-1.0$ cabal --version
> cabal-install version 1.21.0.0
> using version 1.21.0.0 of the Cabal library
> 
> 
> Oddly if I try "cabal update; cabal install cabal-install" it says:
>     Resolving dependencies...
>     Downloading Cabal-1.20.0.2...
> 
> so it looks as if it's about to install an *older* version than the one I have already!
> 
> What now?
> 
> Thanks
> 
> SImon
> 
> |  -----Original Message-----
> |  From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com]
> |  Sent: 04 November 2014 11:20
> |  To: Simon Peyton Jones
> |  Cc: GHC Devs
> |  Subject: Re: Can't install packages with my inplace compiler
> |  
> |  Hello Simon,
> |  
> |  On 2014-11-04 at 11:55:48 +0100, Simon Peyton Jones wrote:
> |  > When I say
> |  >
> |  > cabal install
> |  > --with-ghc=/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-stage2
> |  >
> |  > I get this
> |  >
> |  > ghc-stage2: ghc no longer supports single-file style package
> |  databases
> |  > (dist/package.conf.inplace) use 'ghc-pkg init' to create the
> |  database
> |  > with the correct format.
> |  >
> |  > Now, this is an old build tree, and I could blow it away entirely,
> |  but
> |  > maybe there is something else going on.  What should I do?
> |  
> |  What does `cabal --version` say? If it doesn't say something like
> |  
> |    $ cabal --version
> |    cabal-install version 1.21.1.0
> |    using version 1.21.1.0 of the Cabal library
> |  
> |  you probably need a newer one (in which case you should build the
> |  `cabal` binary from Git, and to make life easier compile `Cabal` and
> |  `cabal-install` with GHC 7.8.x rather than GHC HEAD)
> |  
> |  Cheers,
> |    hvr

From merijn at inconsistent.nl  Tue Nov  4 19:04:50 2014
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Tue, 4 Nov 2014 11:04:50 -0800
Subject: Problem with select(2) in single threaded runtime.
In-Reply-To: <87r3xizxap.fsf@gmail.com>
References: <BE8FFA80-AF02-46D9-B686-B49D2904E3E4@inconsistent.nl>
 <94903F9A-97C6-4B23-B8E6-DEB6317018AF@inconsistent.nl>
 <87oasn1hzr.fsf@gmail.com>
 <5949308B-F8C4-4F10-BE02-525B392B4019@inconsistent.nl>
 <87r3xizxap.fsf@gmail.com>
Message-ID: <05690DB2-F127-4A94-B45E-D20A0F759263@inconsistent.nl>

On 4 Nov 2014, at 9:32, Herbert Valerio Riedel <hvriedel at gmail.com> wrote:
> 
> I'm wondering if there's already an Autoconf test somewhere we could
> steal for detecting this peculiarity of select() on BSD systems...

I googled around for ways to detect this, but I haven't found anything so far. I've been scarred by autotools, to if someone less horrified knows how to do this "properly", please chime in :)

Cheers,
Merijn

From simonpj at microsoft.com  Tue Nov  4 21:04:42 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 4 Nov 2014 21:04:42 +0000
Subject: Can't install packages with my inplace compiler
In-Reply-To: <1415126925-sup-4219@sabre>
References: <618BE556AADD624C9C918AA5D5911BEF3F38F616@DB3PRD3001MB020.064d.mgd.msft.net>
 <87ioiv1ac9.fsf@gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F390912@DB3PRD3001MB020.064d.mgd.msft.net>
 <1415126925-sup-4219@sabre>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F392330@DB3PRD3001MB020.064d.mgd.msft.net>

| Yeah, that's too old; and there's not been a release of a Cabal
| which is new enough to do what you want.

Wow!  I'm doing the most basic thing: using Cabal to install a package with a specified GHC.

I'll try what you suggest.

Duncan: would a release be a good plan?

Simon

| 
| Try:
| 
|     git clone https://github.com/haskell/cabal
|     cd cabal/Cabal
|     cabal install
|     cd ../cabal-install
|     cabal install
| 
| Edward
| 
| Excerpts from Simon Peyton Jones's message of 2014-11-04 03:59:57 -0800:
| > It says
| >
| > simonpj at cam-05-unx:~/tmp/singletons-1.0$ cabal --version
| > cabal-install version 1.21.0.0
| > using version 1.21.0.0 of the Cabal library
| >
| >
| > Oddly if I try "cabal update; cabal install cabal-install" it says:
| >     Resolving dependencies...
| >     Downloading Cabal-1.20.0.2...
| >
| > so it looks as if it's about to install an *older* version than the one
| I have already!
| >
| > What now?
| >
| > Thanks
| >
| > SImon
| >
| > |  -----Original Message-----
| > |  From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com]
| > |  Sent: 04 November 2014 11:20
| > |  To: Simon Peyton Jones
| > |  Cc: GHC Devs
| > |  Subject: Re: Can't install packages with my inplace compiler
| > |
| > |  Hello Simon,
| > |
| > |  On 2014-11-04 at 11:55:48 +0100, Simon Peyton Jones wrote:
| > |  > When I say
| > |  >
| > |  > cabal install
| > |  > --with-ghc=/home/simonpj/5builds/HEAD-2/inplace/bin/ghc-stage2
| > |  >
| > |  > I get this
| > |  >
| > |  > ghc-stage2: ghc no longer supports single-file style package
| > |  databases
| > |  > (dist/package.conf.inplace) use 'ghc-pkg init' to create the
| > |  database
| > |  > with the correct format.
| > |  >
| > |  > Now, this is an old build tree, and I could blow it away entirely,
| > |  but
| > |  > maybe there is something else going on.  What should I do?
| > |
| > |  What does `cabal --version` say? If it doesn't say something like
| > |
| > |    $ cabal --version
| > |    cabal-install version 1.21.1.0
| > |    using version 1.21.1.0 of the Cabal library
| > |
| > |  you probably need a newer one (in which case you should build the
| > |  `cabal` binary from Git, and to make life easier compile `Cabal` and
| > |  `cabal-install` with GHC 7.8.x rather than GHC HEAD)
| > |
| > |  Cheers,
| > |    hvr

From simonpj at microsoft.com  Tue Nov  4 21:05:53 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 4 Nov 2014 21:05:53 +0000
Subject: [commit: ghc] wip/rae: Fix #1476 by making splice patterns
 work. (eb257c3)
In-Reply-To: <20141104185841.A69913A300@ghc.haskell.org>
References: <20141104185841.A69913A300@ghc.haskell.org>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F39233D@DB3PRD3001MB020.064d.mgd.msft.net>

|     Unfortunately, splice patterns in brackets still do not work
|     because we don't run splices in brackets. Without running a pattern
|     splice, we can't know what variables it binds, so we're stuck.

Not just "don't" but "can't"!!  This isn't a compiler deficiency: the code is not there to run!

Simon


From alan.zimm at gmail.com  Tue Nov  4 21:41:24 2014
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Tue, 4 Nov 2014 23:41:24 +0200
Subject: GHC AST Annotations (again)
Message-ID: <CANma=H8r1ubcRi20NGgeuv40=yntqZGa=GoG9qoq4n-SMzT+Cw@mail.gmail.com>

Hi all

Hopefully I will be able to stop harassing everyone on this topic soon.

The final versions of the patches for this are ready for review.

It has been split into three parts

D412 Extends the HsLit values to have an extra field for the original
source text, which can differ from the literal value.

D426 adds various extra locations in the HsSyn AST to allow the additions
of API annotations everywhere needed.

D438 modifies the Lexer/Parser to produce API annotations and comments as
part of the ParsedSource result.

Please review if you are interested.

Links

https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations
https://ghc.haskell.org/trac/ghc/ticket/9628
https://phabricator.haskell.org/D412
https://phabricator.haskell.org/D426
https://phabricator.haskell.org/D438

Regards
  Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141104/8fddc8ef/attachment.html>

From pali.gabor at gmail.com  Tue Nov  4 22:16:37 2014
From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=)
Date: Tue, 4 Nov 2014 23:16:37 +0100
Subject: Automating GHC build for Windows
In-Reply-To: <CAFC_Meim57TpLXa5-r+-pm1u5Bhot++TQ3H_zLiWkcXq8mtMkw@mail.gmail.com>
References: <CAD78TFJ+2BvKxCK9nCxsPDVR=tMaEhWESEknXAwp_zCJ_P+Amg@mail.gmail.com>
 <1413916715.326367.181663173.2FBCEE30@webmail.messagingengine.com>
 <CAEs96n1vizQgobwsOpxYztAtf5bBtoaCK552DtysO4cVLaYF7Q@mail.gmail.com>
 <CAHnG2Cwi3bwNa_X+gk4vdHFKm1YbyQwv1nHgdhJA+RWtS-tCOQ@mail.gmail.com>
 <CAFC_MegfiYS6T6ahtMhxa9_gNRrTGa4xW6pUWjonTZr-XJn8Pw@mail.gmail.com>
 <CAHnG2CybhW6K=KBGG4Kw-ygjLLcxKnYMW7xkGZdT-8s58_dkSA@mail.gmail.com>
 <CAFC_MejcnCQpEE=Ej3Dojnw8-4APK_zWYgnAjn=e95wP4e9nYQ@mail.gmail.com>
 <CAHnG2CyLNJ+zvxASn7_0CM59Rg9tf9G3hTOD8VmjvYjkwbLV7w@mail.gmail.com>
 <CAFC_Meh1QiF5ABja_ozjewMg=FS8r78oUz8bxoP=BNUXANkskg@mail.gmail.com>
 <CAHnG2CxK9QC-yN+hGz-EkwK39MrXQvekVNxFpRvN-gLgsh7Jyg@mail.gmail.com>
 <CAFC_Meim57TpLXa5-r+-pm1u5Bhot++TQ3H_zLiWkcXq8mtMkw@mail.gmail.com>
Message-ID: <CAHnG2Cx+aZv+0tSLUcgaYkEiGZ59hyJp56xYY8kZP=_gWanbvA@mail.gmail.com>

2014-11-03 1:24 GMT+01:00 Gintautas Miliauskas <gintautas.miliauskas at gmail.com>:
> Without knowing much about the surrounding code, I would try two things
> here.
[..]
> 2. Since the error is completely deterministic, you could try "freezing"
> evaluation right before the crash ([..] just
> adding a time delay / console read on the code), and then using a utility
> app to check which process is keeping the file open, whether it's the same
> process or something else.

I tried this approach and it seems I do not even need to check the
environment further: when ghc-cabal.exe stops in writeFileAtomic
(waiting for a keypress) and displays the parameters it was called
with, it says that the same dist-boot\setup-configXXXX.tmp file is
about to renamed (to dist-boot\setup-config) twice after each other
(perhaps from different threads?)!  Note that I do not experience the
same when the writeFileAtomic function is called for other files.

Well, I guess this can easily cause the problems I have seen so far...
I can also imagine that this bug is present on other systems as well,
but does not cause any harm (for some reason) so it is basically
invisible.

However, first it would be nice if somebody else could confirm that it
is indeed the case.

From gintautas.miliauskas at gmail.com  Tue Nov  4 22:20:12 2014
From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas)
Date: Tue, 4 Nov 2014 23:20:12 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <54591E58.2060002@gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
 <CAOYw7duty5OoX35NJq-mtc=MqyH6T7L9y2DfzHhWQxYAr1n2bg@mail.gmail.com>
 <5458CD34.6040600@gmail.com>
 <CAFC_Meg_UZATRAWKnf5daM5Qo0eCYp6CUPh1fovnC7gVATeQwg@mail.gmail.com>
 <5458EC7D.3080008@gmail.com>
 <CAFC_Meiy4REPCsKyYmZDSLsEZq-CY5RSTaPb4k1SL2EFH7Wzqw@mail.gmail.com>
 <54591E58.2060002@gmail.com>
Message-ID: <CAFC_MehHXa2i2DeZLH_Oa2trFz+HWAh6ADoy1a9kb3fb8KT9=g@mail.gmail.com>

Hi David,

ghc should appear as inplace/bin/ghc-stage2.exe after a successful build.

The warnings are expected.

Did you run make with parallelism? I don't have a smoking gun, but the
build seems to be somewhat stable with -j1, while it crashes a lot of the
time with -j5 (I have a 4-core CPU). I have only tried a couple of runs
with -j1 (takes a while...), so I can't say for sure that non-parallel
builds are stable, but 2/2 runs succeeded.

Another data point: I ran the validate script in a loop and stored the
logs, and most crashes seem to be in rts/, but not all of them. Not sure
why.

$ grep Segmentation *.log
1.log:make[1]: ***
[libraries/base/dist-install/build/Text/Show/Functions.o] Segmentation fault
10.log:make[1]: *** [rts/dist/build/Hpc.o] Segmentation fault
11.log:make[1]: *** [rts/dist/build/RtsFlags.thr_l_o] Segmentation fault
12.log:make[1]: *** [rts/dist/build/sm/GCAux.o] Segmentation fault
13.log:make[1]: *** [rts/dist/build/win32/GetEnv.thr_l_o] Segmentation fault
14.log:make[1]: *** [rts/dist/build/sm/Scav.l_o] Segmentation fault
15.log:make[1]: *** [compiler/stage1/build/RegAlloc/Linear/State.o]
Segmentation fault
18.log:make[1]: ***
[libraries/filepath/dist-install/build/.depend-v.haskell] Segmentation fault
19.log:make[1]: *** [libraries/base/dist-install/build/.depend-v.haskell]
Segmentation fault
4.log:make[1]: *** [rts/dist/build/RtsDllMain.o] Segmentation fault
5.log:make[1]: *** [rts/dist/build/sm/Evac_thr.thr_o] Segmentation fault
6.log:make[1]: *** [rts/dist/build/sm/Scav_thr.thr_l_o] Segmentation fault
7.log:make[1]: *** [rts/dist/build/Linker.thr_debug_o] Segmentation fault
8.log:make[1]: *** [rts/dist/build/sm/Storage.debug_o] Segmentation fault
9.log:make[1]: *** [rts/dist/build/hooks/OutOfHeap.thr_debug_o]
Segmentation fault


On Tue, Nov 4, 2014 at 7:43 PM, David Macek <david.macek.0 at gmail.com> wrote:

> Hi. I just built GHC from master
> (1c35f9f1cb7a293da85d649904ce731a65824cfe) in my somewhat outdated MSYS2. I
> followed the wiki page with a few exceptions.
>
> - I cleared my PATH before running the shell (I left only Windows and
> System32)
> - my installation is not up-to-date
> - I do not have msys2 libtool, automake nor binutils; if the build used
> any of those, they came from mingw64 or from the host ghc
> - I had to run boot in pure msys2 shell, because mingw64 perl caused it to
> fail
>
> I saw no segfaults, but I may have missed them. I did not get a ghc.exe,
> but that may be correct behavior for all I know. My simple test program
> compiled and ran fine. I saw a lot of warnings during ghc's build though:
>
> - checking for DocBook DTD... I/O error : Attempt to load network entity
> http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd
> - something with not finding any implementation of a module out of [
> xxx.dylib, xxx, ... ], I think it was in cabal builds
> - "could not find link destionations for: xxx"
>
> I hope it helps somehow. Maybe your issues come from mixing msys2 and
> mingw toolchain after all.
>
>
>
> --
> David Macek
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Msys2-users mailing list
> Msys2-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/msys2-users
>



-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141104/23099eab/attachment.html>

From david.macek.0 at gmail.com  Tue Nov  4 22:23:07 2014
From: david.macek.0 at gmail.com (David Macek)
Date: Tue, 04 Nov 2014 23:23:07 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <CAFC_MehHXa2i2DeZLH_Oa2trFz+HWAh6ADoy1a9kb3fb8KT9=g@mail.gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
 <CAOYw7duty5OoX35NJq-mtc=MqyH6T7L9y2DfzHhWQxYAr1n2bg@mail.gmail.com>
 <5458CD34.6040600@gmail.com>
 <CAFC_Meg_UZATRAWKnf5daM5Qo0eCYp6CUPh1fovnC7gVATeQwg@mail.gmail.com>
 <5458EC7D.3080008@gmail.com>
 <CAFC_Meiy4REPCsKyYmZDSLsEZq-CY5RSTaPb4k1SL2EFH7Wzqw@mail.gmail.com>
 <54591E58.2060002@gmail.com>
 <CAFC_MehHXa2i2DeZLH_Oa2trFz+HWAh6ADoy1a9kb3fb8KT9=g@mail.gmail.com>
Message-ID: <545951CB.8040604@gmail.com>

On 4. 11. 2014 23:20, Gintautas Miliauskas wrote:
> ghc should appear as inplace/bin/ghc-stage2.exe after a successful build.

It's there.

> Did you run make with parallelism? I don't have a smoking gun, but the build seems to be somewhat stable with -j1, while it crashes a lot of the time with -j5 (I have a 4-core CPU). I have only tried a couple of runs with -j1 (takes a while...), so I can't say for sure that non-parallel builds are stable, but 2/2 runs succeeded.

Nope. I'll try with -j5.

-- 
David Macek

From gintautas.miliauskas at gmail.com  Tue Nov  4 22:26:33 2014
From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas)
Date: Tue, 4 Nov 2014 23:26:33 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <545951CB.8040604@gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
 <CAOYw7duty5OoX35NJq-mtc=MqyH6T7L9y2DfzHhWQxYAr1n2bg@mail.gmail.com>
 <5458CD34.6040600@gmail.com>
 <CAFC_Meg_UZATRAWKnf5daM5Qo0eCYp6CUPh1fovnC7gVATeQwg@mail.gmail.com>
 <5458EC7D.3080008@gmail.com>
 <CAFC_Meiy4REPCsKyYmZDSLsEZq-CY5RSTaPb4k1SL2EFH7Wzqw@mail.gmail.com>
 <54591E58.2060002@gmail.com>
 <CAFC_MehHXa2i2DeZLH_Oa2trFz+HWAh6ADoy1a9kb3fb8KT9=g@mail.gmail.com>
 <545951CB.8040604@gmail.com>
Message-ID: <CAFC_MeiO=C9HymcA0fkBxMiRXNiCL-t36YG6qgF3B0zagi5wyw@mail.gmail.com>

Oh, and David, thanks for your help. It's really appreciated. This issue
has been driving me nuts recently, and I don't have a good strategy to root
it out...

On Tue, Nov 4, 2014 at 11:23 PM, David Macek <david.macek.0 at gmail.com>
wrote:

> On 4. 11. 2014 23:20, Gintautas Miliauskas wrote:
> > ghc should appear as inplace/bin/ghc-stage2.exe after a successful build.
>
> It's there.
>
> > Did you run make with parallelism? I don't have a smoking gun, but the
> build seems to be somewhat stable with -j1, while it crashes a lot of the
> time with -j5 (I have a 4-core CPU). I have only tried a couple of runs
> with -j1 (takes a while...), so I can't say for sure that non-parallel
> builds are stable, but 2/2 runs succeeded.
>
> Nope. I'll try with -j5.
>
> --
> David Macek
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141104/f236ad01/attachment.html>

From pali.gabor at gmail.com  Tue Nov  4 22:42:38 2014
From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=)
Date: Tue, 4 Nov 2014 23:42:38 +0100
Subject: Automating GHC build for Windows
In-Reply-To: <CAHnG2Cx+aZv+0tSLUcgaYkEiGZ59hyJp56xYY8kZP=_gWanbvA@mail.gmail.com>
References: <CAD78TFJ+2BvKxCK9nCxsPDVR=tMaEhWESEknXAwp_zCJ_P+Amg@mail.gmail.com>
 <1413916715.326367.181663173.2FBCEE30@webmail.messagingengine.com>
 <CAEs96n1vizQgobwsOpxYztAtf5bBtoaCK552DtysO4cVLaYF7Q@mail.gmail.com>
 <CAHnG2Cwi3bwNa_X+gk4vdHFKm1YbyQwv1nHgdhJA+RWtS-tCOQ@mail.gmail.com>
 <CAFC_MegfiYS6T6ahtMhxa9_gNRrTGa4xW6pUWjonTZr-XJn8Pw@mail.gmail.com>
 <CAHnG2CybhW6K=KBGG4Kw-ygjLLcxKnYMW7xkGZdT-8s58_dkSA@mail.gmail.com>
 <CAFC_MejcnCQpEE=Ej3Dojnw8-4APK_zWYgnAjn=e95wP4e9nYQ@mail.gmail.com>
 <CAHnG2CyLNJ+zvxASn7_0CM59Rg9tf9G3hTOD8VmjvYjkwbLV7w@mail.gmail.com>
 <CAFC_Meh1QiF5ABja_ozjewMg=FS8r78oUz8bxoP=BNUXANkskg@mail.gmail.com>
 <CAHnG2CxK9QC-yN+hGz-EkwK39MrXQvekVNxFpRvN-gLgsh7Jyg@mail.gmail.com>
 <CAFC_Meim57TpLXa5-r+-pm1u5Bhot++TQ3H_zLiWkcXq8mtMkw@mail.gmail.com>
 <CAHnG2Cx+aZv+0tSLUcgaYkEiGZ59hyJp56xYY8kZP=_gWanbvA@mail.gmail.com>
Message-ID: <CAHnG2CyEdNjHtERqAPeF4VqntyT+aTYKrUx8uv==himMFJXUGA@mail.gmail.com>

2014-11-04 23:16 GMT+01:00 P?li G?bor J?nos <pali.gabor at gmail.com>:
> it says that the same dist-boot\setup-configXXXX.tmp file is
> about to renamed (to dist-boot\setup-config) twice after each other
> (perhaps from different threads?)! [..]
>
> Well, I guess this can easily cause the problems I have seen so far...
> I can also imagine that this bug is present on other systems as well,
> but does not cause any harm (for some reason) so it is basically
> invisible.
>
> However, first it would be nice if somebody else could confirm that it
> is indeed the case.

Yeah, for what it is worth, this also happens on my FreeBSD builder
too, but it works fine despite of that.

From juhpetersen at gmail.com  Wed Nov  5 03:56:25 2014
From: juhpetersen at gmail.com (Jens Petersen)
Date: Wed, 5 Nov 2014 12:56:25 +0900
Subject: Problems compiling with llvm-3.5.0-2 on ARM
In-Reply-To: <CAHz445U2HKCv7VnP1wkk1kdSiJDSXcMNcHiTfM9fB+FsRKtCfA@mail.gmail.com>
References: <CAHz445U2HKCv7VnP1wkk1kdSiJDSXcMNcHiTfM9fB+FsRKtCfA@mail.gmail.com>
Message-ID: <CAEDGBqJQZKOdraP-Kt2xaWrw1JkBUvFdYSvvCAcGVZ=HAJHsBw@mail.gmail.com>

Hi Jarl,

I think I just ran into this too for Fedora 22 rawhide on ARM and found
your posts...

On 30 October 2014 16:11, Jarl Gunnar Flaten <jarl.flaten at gmail.com> wrote:

> (cf. reddit thread
> <http://www.reddit.com/r/haskell/comments/2kpsz5/ghc_problem_new_llvm_schedule_reentered_unsafely/>
> )
>
> I am trying to compile a simple "hello world" program (test.hs). When
> compiling I am notified:
>
> > [1 of 1] Compiling Main             ( test.hs, test.o )
> > You are using a new version of LLVM that hasn't been tested yet!
>
> > test: schedule: re-entered unsafely.
> >    Perhaps a 'foreign import unsafe' should be 'safe'?
>
> Isn't working. I'm not familiar enough with neither LLVM nor Haskell to troubleshoot from either of these; I don't even know if the messages are even related.
>
> They are related in the sense that llvm-3.5 seems to this problem and it
is not officially supported by ghc-7.6 or ghc-7.8 (hence the warning).
ghc-7.8 supports 3.4 and 7.6 seems to mostly work with some patches.

Can you provide more details on your environment: OS and ghc version etc?

I am not sure yet what is causing this: perhaps you could try compiling
with "-threaded" and see if that helps?

Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141105/50fef5c2/attachment.html>

From david.macek.0 at gmail.com  Wed Nov  5 07:01:52 2014
From: david.macek.0 at gmail.com (David Macek)
Date: Wed, 05 Nov 2014 08:01:52 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <545951CB.8040604@gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
 <CAOYw7duty5OoX35NJq-mtc=MqyH6T7L9y2DfzHhWQxYAr1n2bg@mail.gmail.com>
 <5458CD34.6040600@gmail.com>
 <CAFC_Meg_UZATRAWKnf5daM5Qo0eCYp6CUPh1fovnC7gVATeQwg@mail.gmail.com>
 <5458EC7D.3080008@gmail.com>
 <CAFC_Meiy4REPCsKyYmZDSLsEZq-CY5RSTaPb4k1SL2EFH7Wzqw@mail.gmail.com>
 <54591E58.2060002@gmail.com>
 <CAFC_MehHXa2i2DeZLH_Oa2trFz+HWAh6ADoy1a9kb3fb8KT9=g@mail.gmail.com>
 <545951CB.8040604@gmail.com>
Message-ID: <5459CB60.2080807@gmail.com>

On 4. 11. 2014 23:23, David Macek wrote:
> Nope. I'll try with -j5.

So that looks like another successful build. Unless "make" can ignore the -j argument, I'd say the issue is caused or activated by your configuration.

I'm running validate to double check (detected 4 CPUs). Maybe we should work out a precise, minimalistic recipe to replicate the issue (I haven't tried installing clean MSYS2 yet).

By the way, have you ruled out anti-virus software (and other BLODApps) as a possible cause?

-- 
David Macek

From ekmett at gmail.com  Wed Nov  5 07:04:46 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 5 Nov 2014 02:04:46 -0500
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CAJumaK-UpWirPtfeMX0xHAf34H9CpxKXrdaHh_ErTPsGNXMpow@mail.gmail.com>

One note on the syntax front, 'pattern type' was mentioned as annoyingly
trying to shoehorn the word 'type' in to lean on an existing keyword, even
though its about a term level construction rather than a type level one.

We do have some perfectly serviceable keywords available to us that
indicate a more 'term/pattern' orientation, e.g. 'case' and 'of' come to
mind as things that are viable candidates for similar abuse here.

I'm just digging through the lexical lego bin for parts. I don't quite know
how to put them together to make a nice syntax though.

-Edward


On Tue, Nov 4, 2014 at 5:32 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Here is one principle: for GADTs, the pattern type signature should look
> like the GADT data constructor.  So if we have
>
>         data S a where
>         S1 :: p -> q -> S (p,q)
>         S2 :: ...blah...
>
>       pattern P x y = S1 x y
>
> then surely the signature for P should be
>         P :: p -> q -> S (p,q)
>
> The same goes for constraints in the constructor's type. Thus, using your
> example:
>
> |       data T a b where
> |         MkT :: (Eq a, Ord b, Show c) => a -> (b, b) -> c -> T a b
>
> If I say
>         pattern P x y z = MkT x y z
> then the signature for P should be identical to that of MkT.
>
>
> -----------
>
> It gets a bit more interesting when you have nested patterns that
> instantiate the type.  For example, with the same type T, consider
>
>         pattern P x y z = MkT (x,y) (False,True) [z]
>
> the "right" signature for P must presumably be
>         P :: (Eq (p,q), Show [r]) => p -> q -> r -> T (p,q) Bool
>
> We don't need to distinguish 'r' as existential, any more than we do in
> the original signature for MkT.
>
> Note that we must retain the instantiated but un-simplified constraints
> (Eq (p,b), Show [r]), because when pattern-matching against P, those are
> the constraints brought into scope.
>
> ---------
>
> The general story, for both data constructors and pattern synonyms, is
> that if the type is
>         D :: forall abc. (C1, C2...) => blah
> then the constraints (C1, C2...) are
>  - *required* when using D in an expression,
>  - *provided* (i.e. brought into scope) pattern matching against D.
>
> The tricky case comes when the pattern synonym involves some constraints
> that are *required* during *pattern-matching*.  A simple example is
>
>         pattern P1 x = (8, x)
>
> Here we *require* a (Num a) dictionary *both* when using P1 in an
> expression (to build the value 8), *and* when using P in pattern matching
> (to build a value 8 to compare with the value being matched).  I'll call
> the constraints that are *required* when matching the "match-required
> constraints".
>
> The same happens for view patterns:
>
>       gr :: Ord a => a -> a -> Maybe a
>         gr v x | x > v = Just v
>              | otherwise = Nothing
>
>         pattern P2 x = (gr 8 -> Just x)
>
> Here, (Ord a, Num a) are match-required.  (P2 is uni-directional, so we
> can't use P2 in expressions.)
>
> We can't give a signature to P1 like this
>         P1 :: forall a. Num a => b -> (a,b)
> because that looks as if (Num a) would be *provided* when pattern matching
> (see "general story" above), whereas actually it is required.  This is the
> nub of the problem Gergo is presenting us with.
>
> Notice that P1 is bidirectional, and can be used in expressions, where
> again we *require* (Num a), so P1's "term type" really is something like
> (Num a) => b -> (a,b).
>
> The more I think about this, the more I think we'll just have to bite the
> bullet and adapt the syntax for constraints in pattern types, to
> distinguish the match-required and match-provided parts. Suppose we let
> pattern signatures look like this:
>
>   pattern P :: forall tvs. (match-provided ; match-required) => tau
>
> The "; match-required" part is optional, and the "match-provided" part
> might be empty.  So P1 and P2 would look like this:
>
>   pattern P1 :: forall a. (; Num a) => b -> (a,b)
>   pattern P2 :: forall a. (; Num a, Ord a) => a -> a
>
> Because the "match-required" part is optional (and relatively rare) the
> common case looks just like an ordinary data constructor.
>
>
> None of this addresses the bidirectional/unidirectional question, but
> that's a pretty separate matter.
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Dr.
> |  ERDI Gergo
> |  Sent: 03 November 2014 10:13
> |  To: GHC Devs
> |  Subject: RFC: Concrete syntax for pattern synonym type signatures
> |
> |  Background
> |  ----------
> |
> |  As explained on
> |  https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms#Staticsemantics
> |  the type of a pattern synonym can be fully described with the
> |  following pieces of information:
> |
> |  * If the pattern synonym is bidirectional
> |  * Universially-bound type variables, and required constraints on them
> |  * The type of the pattern itself, closed over the universially-bound
> |  type variables
> |  * Existentially-bound type variables, and the constraints provided by
> |  them
> |  * The types of the arguments, closed over the universially and
> |     existentially bound type variables
> |
> |  Here's an example showing all of these axes in action:
> |
> |       data T a b where
> |         MkT :: (Eq a, Ord b, Show c) => a -> (b, b) -> c -> T a b
> |
> |       pattern P x y = MkT 5 (y, True) x
> |
> |  In this case:
> |
> |  * The name of the pattern synonym is `P`
> |  * The pattern synonym is bidirectional
> |  * The universially-bound tyvars/required constraints are `forall a.
> |  Num a`
> |  * The type of the pattern is `T a Bool`
> |  * The existentially-bound tyvars/provided constraints are
> |     `forall c. (Eq a, Ord Bool, Show c)`
> |  * The type of the arguments are `c` and `Bool`.
> |
> |  The problem, then, is finding a concrete syntax that captures all of
> |  this information. This syntax is needed for at least two purposes:
> |
> |  * Showing pattern synonym type information in Haddock/GHCi
> |  * Pattern synonym type signatures (#8584)
> |
> |  Current state of things
> |  -----------------------
> |
> |  GHCi 7.8.3 shows the type above as:
> |
> |  pattern (Eq t, Ord Bool, Show c) => P c Bool :: Num t => (T t Bool)
> |
> |  Not only does it not show directionality, I think this is very
> |  confusing in every other way as well, especially with explicit
> |  foralls:
> |
> |  pattern forall c. (Eq t, Ord Bool, Show c) => P c Bool :: forall t.
> |  Num t => (T t Bool)
> |
> |  I am currently working on implementing #8584, which means I need to
> |  parse these type signatures. I managed to get the above monstrosity to
> |  parse (unambigiously from actual pattern synonym definitions) by
> |  throwing in an extra 'type' keyword:
> |
> |  pattern type (Eq t, Ord Bool, Show c) => P c Bool :: Num t => (T t
> |  Bool)
> |
> |  Request for help
> |  ----------------
> |
> |  Surely we can do better than that! So let's come up with a nice syntax
> |  for pattern synonym type signatures. It will be used in the pattern
> |  synonym type signature annotations of GHC 7.10, and we could also
> |  retrofit it into GHC 7.8.4 and its Haddock, so that documentation
> |  generated with today's tools will look consistent with code you will
> |  be able to enter in tomorrow's version.
> |
> |  Bye,
> |       Gergo
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  http://www.haskell.org/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141105/a39698d4/attachment.html>

From duncan at well-typed.com  Wed Nov  5 09:41:12 2014
From: duncan at well-typed.com (Duncan Coutts)
Date: Wed, 05 Nov 2014 09:41:12 +0000
Subject: Can't install packages with my inplace compiler
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F392330@DB3PRD3001MB020.064d.mgd.msft.net>
References: <618BE556AADD624C9C918AA5D5911BEF3F38F616@DB3PRD3001MB020.064d.mgd.msft.net>
 <87ioiv1ac9.fsf@gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F390912@DB3PRD3001MB020.064d.mgd.msft.net>
 <1415126925-sup-4219@sabre>
 <618BE556AADD624C9C918AA5D5911BEF3F392330@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <1415180472.6486.50.camel@dunky.localdomain>

On Tue, 2014-11-04 at 21:04 +0000, Simon Peyton Jones wrote:
> | Yeah, that's too old; and there's not been a release of a Cabal
> | which is new enough to do what you want.
> 
> Wow!  I'm doing the most basic thing: using Cabal to install a package with a specified GHC.
> 
> I'll try what you suggest.

Actually I'd suggest you use the Cabal and cabal-install that are part
of the ghc source tree, rather than Cabal/cabal-install HEAD. The two
are not always the same.

We try to avoid getting into situations where older cabal binaries
cannot use the current ghc, but it does happen sometimes when we make
changes in ghc that are not fully backwards compatible. In this case we
(or rather I) removed ghc's support for single-file style package dbs
and we later discovered that Cabal was in one place still using that
style. It's plausible that we might want to add back some hack to
ghc-pkg to allow older Cabal versions to work with ghc head.

So in this situation we have to use the Cabal library (that you built
with ghc head), to build cabal-install and its dependencies in the old
style, using Setup.hs. That'll also need the dev version of zlib, due to
the AMP things.

> Duncan: would a release be a good plan?

We tend not to make intermediate releases to support ghc head because
when we're making changes to work with ghc head we're not always in a
good spot to make releases for the general public (we tend to be in the
middle of things and not have enough testing feedback). Also, people
using ghc head already have the corresponding version of
Cabal/cabal-install in their source tree which they can install and use.

On the other hand, when we think we're in a reasonable state with Cabal
testing, and ghc is getting into release mode and we have more people
needing to test ghc head, then of course making a release becomes
important.

My point is that when Edward and I were making all these breaking
changes to Cabal/ghc in the packaging area is exactly the wrong time to
make a cabal release. In this situation we just have to tell ghc hackers
to use the Cabal/cabal-install from the ghc tree.

-- 
Duncan Coutts, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/


From simonpj at microsoft.com  Wed Nov  5 09:50:26 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 5 Nov 2014 09:50:26 +0000
Subject: Can't install packages with my inplace compiler
In-Reply-To: <1415180472.6486.50.camel@dunky.localdomain>
References: <618BE556AADD624C9C918AA5D5911BEF3F38F616@DB3PRD3001MB020.064d.mgd.msft.net>
 <87ioiv1ac9.fsf@gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F390912@DB3PRD3001MB020.064d.mgd.msft.net>
 <1415126925-sup-4219@sabre>
 <618BE556AADD624C9C918AA5D5911BEF3F392330@DB3PRD3001MB020.064d.mgd.msft.net>
 <1415180472.6486.50.camel@dunky.localdomain>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3946FF@DB3PRD3001MB020.064d.mgd.msft.net>

|  Actually I'd suggest you use the Cabal and cabal-install that are part
|  of the ghc source tree, rather than Cabal/cabal-install HEAD. The two
|  are not always the same.

Aha ok, thank you.  How exactly do I do that?  Where is the executable cabal-install in the tree?  IN inplace/bin I see an executable ghc-cabal. Is that it?

Alternatively, "Plan B" on https://ghc.haskell.org/trac/ghc/wiki/Debugging/InstallingPackagesInplace
(which I confess I'd forgotten about) describes a different plan that doesn't mention cabal-install at all.  Is that better?

Thanks

Simon

|  -----Original Message-----
|  From: Duncan Coutts [mailto:duncan at well-typed.com]
|  Sent: 05 November 2014 09:41
|  To: Simon Peyton Jones
|  Cc: Edward Z. Yang; Herbert Valerio Riedel; GHC Devs
|  Subject: Re: Can't install packages with my inplace compiler
|  
|  On Tue, 2014-11-04 at 21:04 +0000, Simon Peyton Jones wrote:
|  > | Yeah, that's too old; and there's not been a release of a Cabal
|  > | which is new enough to do what you want.
|  >
|  > Wow!  I'm doing the most basic thing: using Cabal to install a
|  package with a specified GHC.
|  >
|  > I'll try what you suggest.
|  
|  Actually I'd suggest you use the Cabal and cabal-install that are part
|  of the ghc source tree, rather than Cabal/cabal-install HEAD. The two
|  are not always the same.
|  
|  We try to avoid getting into situations where older cabal binaries
|  cannot use the current ghc, but it does happen sometimes when we make
|  changes in ghc that are not fully backwards compatible. In this case
|  we (or rather I) removed ghc's support for single-file style package
|  dbs and we later discovered that Cabal was in one place still using
|  that style. It's plausible that we might want to add back some hack to
|  ghc-pkg to allow older Cabal versions to work with ghc head.
|  
|  So in this situation we have to use the Cabal library (that you built
|  with ghc head), to build cabal-install and its dependencies in the old
|  style, using Setup.hs. That'll also need the dev version of zlib, due
|  to the AMP things.
|  
|  > Duncan: would a release be a good plan?
|  
|  We tend not to make intermediate releases to support ghc head because
|  when we're making changes to work with ghc head we're not always in a
|  good spot to make releases for the general public (we tend to be in
|  the middle of things and not have enough testing feedback). Also,
|  people using ghc head already have the corresponding version of
|  Cabal/cabal-install in their source tree which they can install and
|  use.
|  
|  On the other hand, when we think we're in a reasonable state with
|  Cabal testing, and ghc is getting into release mode and we have more
|  people needing to test ghc head, then of course making a release
|  becomes important.
|  
|  My point is that when Edward and I were making all these breaking
|  changes to Cabal/ghc in the packaging area is exactly the wrong time
|  to make a cabal release. In this situation we just have to tell ghc
|  hackers to use the Cabal/cabal-install from the ghc tree.
|  
|  --
|  Duncan Coutts, Haskell Consultant
|  Well-Typed LLP, http://www.well-typed.com/


From jan.stolarek at p.lodz.pl  Wed Nov  5 10:11:39 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Wed, 5 Nov 2014 11:11:39 +0100
Subject: Removing -ddump-simpl-phases and -ddump-core-pipeline flags?
Message-ID: <201411051111.39621.jan.stolarek@p.lodz.pl>

As part of #9358 I'm considering removing these two flags:

-ddump-simpl-phases: dumps simplifier statistics for phases of the simplifier but it works only 
when used together with -ddump-simpl-stats. User can limit which statistics are displayed by 
passing in either the simplifier phase number (0,1,2), phase name (final, main, 
post-worker-wrapper, Gentle) or both (separated with ":"). So for 
example -ddump-simpl-phases=0:main,1 dumps statistics for all pases labeled as phase 1 and only 
those pases of phase 0 that are named "main". Has anyone ever used that flag? Do we consider it 
useful?

-ddump-core-pipeline: this seems like a partially implemented stub. The name is very misleading 
because it is related to plugins. The only thing that it seems to do at the moment is that 
when -ddump-to-file is set then -ddump-core-pipeline will result in dumping plugin passes to 
file.

Janek

From ggreif at gmail.com  Wed Nov  5 10:26:29 2014
From: ggreif at gmail.com (Gabor Greif)
Date: Wed, 5 Nov 2014 11:26:29 +0100
Subject: package 'categories' fails with HEAD
Message-ID: <CAK-hX0m-3=iExfH+6_MqsJoe1Z5qY8Ed0G9taSg6P0mjfyNQyg@mail.gmail.com>

Hi all,

some time ago I filed:

https://github.com/ekmett/categories/issues/4

against the 'categories' library. But I cannot see what is wrong with
the code. It also builds with older GHCs (though I should re-check
with 7.8.3).

So I conjecture this is a HEAD problem in GHC HEAD. It seems weird.

Any ideas what this could be?

Cheers,

    Gabor

From david.macek.0 at gmail.com  Wed Nov  5 10:36:47 2014
From: david.macek.0 at gmail.com (David Macek)
Date: Wed, 05 Nov 2014 11:36:47 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <5459CB60.2080807@gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
 <CAOYw7duty5OoX35NJq-mtc=MqyH6T7L9y2DfzHhWQxYAr1n2bg@mail.gmail.com>
 <5458CD34.6040600@gmail.com>
 <CAFC_Meg_UZATRAWKnf5daM5Qo0eCYp6CUPh1fovnC7gVATeQwg@mail.gmail.com>
 <5458EC7D.3080008@gmail.com>
 <CAFC_Meiy4REPCsKyYmZDSLsEZq-CY5RSTaPb4k1SL2EFH7Wzqw@mail.gmail.com>
 <54591E58.2060002@gmail.com>
 <CAFC_MehHXa2i2DeZLH_Oa2trFz+HWAh6ADoy1a9kb3fb8KT9=g@mail.gmail.com>
 <545951CB.8040604@gmail.com> <5459CB60.2080807@gmail.com>
Message-ID: <5459FDBF.8070405@gmail.com>

Sorry for the large amount of messages.

On 5. 11. 2014 8:01, David Macek wrote:
> I'm running validate to double check (detected 4 CPUs).

I got the validate results:

> Unexpected results from:
> TEST="linker_unload listCommand002 T5681 T5486 T7571 ghcpkg05 T3924 T7702 plugins01 T6106 ghci038 T8172 ghci032 T5975a T5975b ghci058 T3064 T3307 environment001 T876 T3738 T4830 T5205 T7436 lazy-bs-alloc T1407 rdynamic T7037 T5423 T8124 T5435_dyn_asm prog012 prog013 prog001 prog002 prog003 T4006"
> 
> OVERALL SUMMARY for test run started at 11/05/14 09:04:01 Central Europe Standard Time
>  1:01:50 spent to go through
>     4095 total tests, which gave rise to
>    14911 test cases, of which
>    11167 were skipped
> 
>       58 had missing libraries
>     3578 expected passes
>       71 expected failures
> 
>        1 caused framework failures
>        1 unexpected passes
>       36 unexpected failures
> 
> Unexpected passes:
>    rts  linker_unload (normal)
> 
> Unexpected failures:
>    ../../libraries/base/tests     T4006 [bad stdout] (normal)
>    ../../libraries/base/tests/IO  T3307 [bad exit code] (normal)
>    ../../libraries/base/tests/IO  environment001 [bad stdout] (normal)
>    cabal                          ghcpkg05 [bad stderr] (normal)
>    callarity/perf                 T3924 [stat too good] (normal)
>    ghci.debugger/scripts          listCommand002 [bad stderr] (ghci)
>    ghci/linking                   T1407 [bad stderr] (ghci)
>    ghci/prog001                   prog001 [bad stderr] (ghci)
>    ghci/prog002                   prog002 [bad stderr] (ghci)
>    ghci/prog003                   prog003 [bad exit code] (ghci)
>    ghci/prog012                   prog012 [bad stderr] (ghci)
>    ghci/prog013                   prog013 [bad stderr] (ghci)
>    ghci/scripts                   T5975a [bad stderr] (ghci)
>    ghci/scripts                   T5975b [bad stderr] (ghci)
>    ghci/scripts                   T6106 [bad stderr] (ghci)
>    ghci/scripts                   T8172 [bad stdout] (ghci)
>    ghci/scripts                   ghci032 [bad stderr] (ghci)
>    ghci/scripts                   ghci038 [bad stderr] (ghci)
>    ghci/scripts                   ghci058 [bad stderr] (ghci)
>    llvm/should_compile            T5486 [stderr mismatch] (optllvm)
>    llvm/should_compile            T5681 [stderr mismatch] (optllvm)
>    llvm/should_compile            T7571 [stderr mismatch] (optllvm)
>    perf/compiler                  T3064 [stat not good enough] (normal)
>    perf/should_run                T3738 [stat too good] (normal)
>    perf/should_run                T4830 [stat too good] (normal)
>    perf/should_run                T5205 [stat too good] (normal)
>    perf/should_run                T7436 [stat too good] (normal)
>    perf/should_run                T876 [stat not good enough] (normal)
>    perf/should_run                lazy-bs-alloc [stat not good enough] (normal)
>    plugins                        plugins01 [bad stderr] (normal)
>    rts                            T5423 [bad stdout] (normal)
>    rts                            T5435_dyn_asm [bad stdout] (normal)
>    rts                            T7037 [bad stdout] (normal)
>    rts                            T8124 [exit code non-0] (threaded1)
>    rts                            rdynamic [bad exit code] (normal)
>    simplCore/should_compile       T7702 [stderr mismatch] (normal)

I assume that means the build itself had no errors.

-- 
David Macek

From simonpj at microsoft.com  Wed Nov  5 10:57:14 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 5 Nov 2014 10:57:14 +0000
Subject: Removing -ddump-simpl-phases and -ddump-core-pipeline flags?
In-Reply-To: <201411051111.39621.jan.stolarek@p.lodz.pl>
References: <201411051111.39621.jan.stolarek@p.lodz.pl>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3949AB@DB3PRD3001MB020.064d.mgd.msft.net>

I don't use either, so fine with me!

| -----Original Message-----
| From: Jan Stolarek [mailto:jan.stolarek at p.lodz.pl]
| Sent: 05 November 2014 10:12
| To: ghc-devs at haskell.org
| Cc: Simon Peyton Jones
| Subject: Removing -ddump-simpl-phases and -ddump-core-pipeline flags?
| 
| As part of #9358 I'm considering removing these two flags:
| 
| -ddump-simpl-phases: dumps simplifier statistics for phases of the
| simplifier but it works only
| when used together with -ddump-simpl-stats. User can limit which
| statistics are displayed by
| passing in either the simplifier phase number (0,1,2), phase name (final,
| main,
| post-worker-wrapper, Gentle) or both (separated with ":"). So for
| example -ddump-simpl-phases=0:main,1 dumps statistics for all pases
| labeled as phase 1 and only
| those pases of phase 0 that are named "main". Has anyone ever used that
| flag? Do we consider it
| useful?
| 
| -ddump-core-pipeline: this seems like a partially implemented stub. The
| name is very misleading
| because it is related to plugins. The only thing that it seems to do at
| the moment is that
| when -ddump-to-file is set then -ddump-core-pipeline will result in
| dumping plugin passes to
| file.
| 
| Janek

From svenpanne at gmail.com  Wed Nov  5 11:29:59 2014
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 5 Nov 2014 12:29:59 +0100
Subject: Can't install packages with my inplace compiler
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3946FF@DB3PRD3001MB020.064d.mgd.msft.net>
References: <618BE556AADD624C9C918AA5D5911BEF3F38F616@DB3PRD3001MB020.064d.mgd.msft.net>
 <87ioiv1ac9.fsf@gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F390912@DB3PRD3001MB020.064d.mgd.msft.net>
 <1415126925-sup-4219@sabre>
 <618BE556AADD624C9C918AA5D5911BEF3F392330@DB3PRD3001MB020.064d.mgd.msft.net>
 <1415180472.6486.50.camel@dunky.localdomain>
 <618BE556AADD624C9C918AA5D5911BEF3F3946FF@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CANBN=muS11uTUz706gLNy2riB74rnn6-qA_=Rryy5x6VGNBRmw@mail.gmail.com>

Hmmm, is this cabal mess the reason for the problems with GHC head and
Cabal head on https://travis-ci.org/haskell-opengl/StateVar/jobs/39533455#L102?
I've brought up the problem in another thread, but there was no
conclusion. As it is, there seems to be no way to test things with GHC
head on Travis CI, which is really bad. :-/ What can be done here?

From jan.stolarek at p.lodz.pl  Wed Nov  5 14:02:24 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Wed, 5 Nov 2014 15:02:24 +0100
Subject: "Hidden" LLVM flags
Message-ID: <201411051502.25133.jan.stolarek@p.lodz.pl>

DynFlags list some LLVM flags as "hidden":

  ( "llvm-tbaa",                        Opt_LlvmTBAA, nop), -- hidden flag
  ( "llvm-pass-vectors-in-regs",        Opt_LlvmPassVectorsInRegisters, nop), -- hidden flag

Do I undertsand correctly that "hidden" means "not documented in the User's Guide"? Is there a 
good reason for this? I'd like to document them as part of #9358, especially that -fllvm-tbaa is 
enabled by default for all optimisation levels.

Janek

From jan.stolarek at p.lodz.pl  Wed Nov  5 14:35:37 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Wed, 5 Nov 2014 15:35:37 +0100
Subject: "Hidden" LLVM flags
In-Reply-To: <201411051502.25133.jan.stolarek@p.lodz.pl>
References: <201411051502.25133.jan.stolarek@p.lodz.pl>
Message-ID: <201411051535.37987.jan.stolarek@p.lodz.pl>

I found this note in CmmCallConv:

-- On X86_64, we always pass 128-bit-wide vectors in registers. On 32-bit X86
-- and for all larger vector sizes on X86_64, LLVM's GHC calling convention
-- does not currently pass vectors in registers. The patch to update the GHC
-- calling convention to support passing SIMD vectors in registers is small and
-- well-contained, so it may make it into LLVM 3.4. The hidden
-- -fllvm-pass-vectors-in-regs flag will generate LLVM code that attempts to
-- pass vectors in registers, but it must only be used with a version of LLVM
-- that has an updated GHC calling convention.

What's the status? Is this patch present in LLVM 3.4?

As a side note I'm puzzled by the implementation:

passVectorInReg :: Width -> DynFlags -> Bool
passVectorInReg W128 dflags = case platformArch (targetPlatform dflags) of
                                ArchX86_64 -> True
                                _          -> gopt Opt_LlvmPassVectorsInRegisters dflags
passVectorInReg _    dflags = gopt Opt_LlvmPassVectorsInRegisters dflags

It seems that by enabling -fllvm-pass-vectors-in-regs I can change the calling convention for 
vectors of any length other than 128 bits.

Janek

Dnia ?roda, 5 listopada 2014, Jan Stolarek napisa?:
> DynFlags list some LLVM flags as "hidden":
>
>   ( "llvm-tbaa",                        Opt_LlvmTBAA, nop), -- hidden flag
>   ( "llvm-pass-vectors-in-regs",        Opt_LlvmPassVectorsInRegisters,
> nop), -- hidden flag
>
> Do I undertsand correctly that "hidden" means "not documented in the User's
> Guide"? Is there a good reason for this? I'd like to document them as part
> of #9358, especially that -fllvm-tbaa is enabled by default for all
> optimisation levels.
>
> Janek
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs



From alan.zimm at gmail.com  Wed Nov  5 15:20:30 2014
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Wed, 5 Nov 2014 17:20:30 +0200
Subject: GHC AST Annotations (again)
In-Reply-To: <CANma=H8r1ubcRi20NGgeuv40=yntqZGa=GoG9qoq4n-SMzT+Cw@mail.gmail.com>
References: <CANma=H8r1ubcRi20NGgeuv40=yntqZGa=GoG9qoq4n-SMzT+Cw@mail.gmail.com>
Message-ID: <CANma=H9HKZY5kcSCafQFMMuCgNay7w3Hm+znXuroQNRZn+=CgQ@mail.gmail.com>

I have placed an ordering on it so that D426 comes first, then D438 and
finally D412, there was a very minor merge update required for D412.

On Tue, Nov 4, 2014 at 11:41 PM, Alan & Kim Zimmerman <alan.zimm at gmail.com>
wrote:

> Hi all
>
> Hopefully I will be able to stop harassing everyone on this topic soon.
>
> The final versions of the patches for this are ready for review.
>
> It has been split into three parts
>
> D412 Extends the HsLit values to have an extra field for the original
> source text, which can differ from the literal value.
>
> D426 adds various extra locations in the HsSyn AST to allow the additions
> of API annotations everywhere needed.
>
> D438 modifies the Lexer/Parser to produce API annotations and comments as
> part of the ParsedSource result.
>
> Please review if you are interested.
>
> Links
>
> https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations
> https://ghc.haskell.org/trac/ghc/ticket/9628
> https://phabricator.haskell.org/D412
> https://phabricator.haskell.org/D426
> https://phabricator.haskell.org/D438
>
> Regards
>   Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141105/69571ef3/attachment.html>

From nicolas.frisby at gmail.com  Wed Nov  5 15:39:28 2014
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Wed, 5 Nov 2014 09:39:28 -0600
Subject: Tests with compilation errors
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F38550D@DB3PRD3001MB020.064d.mgd.msft.net>
References: <CAFC_Mei94SsP8Bu0_cH7snFwTjqsudgUT5JmC7pJb8jy_ELV=g@mail.gmail.com>
 <CAEs96n3gVRMjoYiH=uWCdMg41+899LKdYfGefURPRANXdd6-PA@mail.gmail.com>
 <CADfHYo5Mjjj71mwDcK8ZZy-zRndaVN2HK=6uvoVaR8RXLeYpQw@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F38550D@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CADfHYo7Bqd2E_XYJiFvC=1edvw3gXmm7i-SEP00nERsmFVxxmQ@mail.gmail.com>

I skimmed Austin's message again and then began the hunt from the main wiki
page. I ended up with these open tabs:

https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries
https://ghc.haskell.org/trac/ghc/wiki/Debugging/InstallingPackagesInplace
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries#Classifyingbootpackages
https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Details

Nothing jumped out at me as "just the right spot". The main mismatch seems
to be the motivation of the text; Austin's message had more of "this is why
it is the way it is" than I see on the wiki. Also, I didn't notice any
mention of the details that Austin gave about validate.sh.

HTH

On Fri, Oct 31, 2014 at 3:25 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

>  Nick,
>
>
>
> Where in the wiki would you have looked for it?
>
>
>
> This isn?t at trick question.  It?s quite hard to know where to record
> info!
>
>
>
> S
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Nicolas
> Frisby
> *Sent:* 30 October 2014 22:42
> *To:* Austin Seipp
> *Cc:* ghc-devs at haskell.org
> *Subject:* Re: Tests with compilation errors
>
>
>
> This reply is very informative! Could you put it on the wiki for me to
> digest at a later date? (Or maybe there's already a consolidated place to
> find it all on there?)
>
>
>
> Thanks very much for sharing all of this.
>
>
>
> On Thu, Oct 30, 2014 at 2:19 PM, Austin Seipp <austin at well-typed.com>
> wrote:
>
>  On Thu, Oct 30, 2014 at 6:48 AM, Gintautas Miliauskas
> <gintautas.miliauskas at gmail.com> wrote:
> > Going through some validate.sh results, I found compilation errors due to
> > missing libraries, like this one:
> >
> > =====> stm052(normal) 4088 of 4108 [0, 21, 0]
> > cd ../../libraries/stm/tests &&
> > 'C:/msys64/home/Gintas/ghc/bindisttest/install   dir/bin/ghc.exe'
> > -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output
> -no-user-package-db
> > -rtsopt
> > s -fno-warn-tabs -fno-ghci-history -o stm052 stm052.hs  -package stm
> >>stm052.comp.stderr 2>&1
> > Compile failed (status 256) errors were:
> >
> > stm052.hs:10:8:
> >     Could not find module ?System.Random?
> >     Use -v to see a list of the files searched for.
> >
> > I was surprised to see that these are not listed in the test summary at
> the
> > end of the test run, but only counted towards the "X had missing
> libraries"
> > row. That setup makes it really easy to miss them, and I can't think of a
> > good reason to sweep such tests under the rug; a broken test is a failing
> > test.
>
> Actually, these tests aren't broken in the way you think :) It's a bit
> long-winded to explain...
>
> Basically, GHC can, if you let it, build extra dependencies in its
> build process, one of which is the 'random' library. 'random' was not
> ever a true requirement to build GHC (aka a 'bootlib' as we call
> them). So why is this test here?
>
> Because 'random' was actually a dependency of the Data Parallel
> Haskell package, and until not too long ago (earlier this year),
> `./validate` built and compiled DPH - with all its dependencies;
> random, vector, primitive - by default. This actually adds a pretty
> noticeable time to the build (you are compiling 5-8 more libraries
> after all), and at the time, DPH was also not ready for the
> Applicative-Monad patch. So we turned it off, as well as the
> dependencies.
>
> Additionally, GHC does have some 'extra' libraries which you can
> optionally build during the build process, but which are turned off by
> default. Originally this was because the weirdo './sync-all' script
> used to not need everything, and 'stm' was a library that wasn't
> cloned by default.
>
> Now that we've submoduleified everything though, these tests and the
> extra libraries could be built by default. Which we could certainly
> do.
>
> > How about at least listing such failed tests in the list of failed tests
> of
> > the end?
>
> I'd probably be OK with this.
>
> > At least in this case the error does not seem to be due to some missing
> > external dependencies (which probably would not be a great idea
> anyway...).
> > The test does pass if I remove the "-no-user-package-db" argument. What
> was
> > the intention here? Does packaging work somehow differently on Linux?
> (I'm
> > currently testing on Windows.)
>
> I'm just guessing but, I imagine you really don't want to remove
> '-no-user-package-db' at all, for any platform, otherwise Weird Things
> Might Happen, I'd assume.
>
> The TL;DR here is that when you build a copy of GHC and all the
> libraries, it actually *does* register the built packages for the
> compiler... this always happens, *even if you do not install it*. The
> primary 'global' package DB just sits in tree instead, under
> ./inplace.
>
> When you run ./validate, what happens is that after the build, we
> actually create a binary distribution and then test *that* compiler
> instead, as you can see (obviously for a good reason - broken bindists
> would be bad). The binary distribution obviously has its own set of
> binary packages it came with; those are the packages you built into it
> after all. The reason we tell GHC to ignore the user package db here
> is precisely because we *do not* want to pick it up! We only want to
> test the binary distribution with the packages *it* has.
>
> Now you might say, well, Austin, the version numbers are different!
> How would it pick that up? Not always... What if I built a copy of GHC
> HEAD today, then built something with it using Cabal? Then that will
> install into my user package database. Now I go back to my GHC tree
> and hack away _on the same day_ and run './validate'... the version
> number hasn't changed *at all* because it's date based, meaning the
> binary distribution could certainly pick up the previously installed
> libraries, which I installed via the older compiler. But I don't want
> that! I only want to run those tests with the compiler I'm validating
> *now*.
>
> I imagine the reason you see this test pass if you remove this
> argument is precisely for this reason: it doesn't fail because it's
> picking up a package database in your existing environment. But that's
> really, really not what you want (I'd be surprised if it worked and
> didn't result in some horrible error or crash).
>
> > On a related note, how about separating test failures from failing
> > performance tests ("stat too good" / "stat not good enough")? The latter
> are
> > important, but they seem to be much more prone to fail without good
> reason.
> > Perhaps do some color coding of the test runner output? That would also
> > help.
>
> I also think this is a good idea.
>
> > --
> > Gintautas Miliauskas
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141105/6f332a3c/attachment-0001.html>

From carter.schonwald at gmail.com  Wed Nov  5 15:49:51 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 5 Nov 2014 10:49:51 -0500
Subject: Problems compiling with llvm-3.5.0-2 on ARM
In-Reply-To: <CAEDGBqJQZKOdraP-Kt2xaWrw1JkBUvFdYSvvCAcGVZ=HAJHsBw@mail.gmail.com>
References: <CAHz445U2HKCv7VnP1wkk1kdSiJDSXcMNcHiTfM9fB+FsRKtCfA@mail.gmail.com>
 <CAEDGBqJQZKOdraP-Kt2xaWrw1JkBUvFdYSvvCAcGVZ=HAJHsBw@mail.gmail.com>
Message-ID: <CAHYVw0zRtXz3jX6+VqQ6GYNVxD1ve98k1AUb=nZtf_koy-isvw@mail.gmail.com>

TL;DR, you cant use llvm 3.5 or 3.6 with any current ghc release. use 3.4
or older

On Tue, Nov 4, 2014 at 10:56 PM, Jens Petersen <juhpetersen at gmail.com>
wrote:

> Hi Jarl,
>
> I think I just ran into this too for Fedora 22 rawhide on ARM and found
> your posts...
>
> On 30 October 2014 16:11, Jarl Gunnar Flaten <jarl.flaten at gmail.com>
> wrote:
>
>> (cf. reddit thread
>> <http://www.reddit.com/r/haskell/comments/2kpsz5/ghc_problem_new_llvm_schedule_reentered_unsafely/>
>> )
>>
>> I am trying to compile a simple "hello world" program (test.hs). When
>> compiling I am notified:
>>
>> > [1 of 1] Compiling Main             ( test.hs, test.o )
>> > You are using a new version of LLVM that hasn't been tested yet!
>>
>> > test: schedule: re-entered unsafely.
>> >    Perhaps a 'foreign import unsafe' should be 'safe'?
>>
>> Isn't working. I'm not familiar enough with neither LLVM nor Haskell to troubleshoot from either of these; I don't even know if the messages are even related.
>>
>> They are related in the sense that llvm-3.5 seems to this problem and it
> is not officially supported by ghc-7.6 or ghc-7.8 (hence the warning).
> ghc-7.8 supports 3.4 and 7.6 seems to mostly work with some patches.
>
> Can you provide more details on your environment: OS and ghc version etc?
>
> I am not sure yet what is causing this: perhaps you could try compiling
> with "-threaded" and see if that helps?
>
> Jens
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141105/6b0e2975/attachment.html>

From gintautas.miliauskas at gmail.com  Wed Nov  5 16:14:08 2014
From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas)
Date: Wed, 5 Nov 2014 17:14:08 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <5459FDBF.8070405@gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
 <CAOYw7duty5OoX35NJq-mtc=MqyH6T7L9y2DfzHhWQxYAr1n2bg@mail.gmail.com>
 <5458CD34.6040600@gmail.com>
 <CAFC_Meg_UZATRAWKnf5daM5Qo0eCYp6CUPh1fovnC7gVATeQwg@mail.gmail.com>
 <5458EC7D.3080008@gmail.com>
 <CAFC_Meiy4REPCsKyYmZDSLsEZq-CY5RSTaPb4k1SL2EFH7Wzqw@mail.gmail.com>
 <54591E58.2060002@gmail.com>
 <CAFC_MehHXa2i2DeZLH_Oa2trFz+HWAh6ADoy1a9kb3fb8KT9=g@mail.gmail.com>
 <545951CB.8040604@gmail.com> <5459CB60.2080807@gmail.com>
 <5459FDBF.8070405@gmail.com>
Message-ID: <CAFC_Meh+y9O1rdHWWjT8EDB0kWhFbDLSJT88kYBAEMbzh=ObdA@mail.gmail.com>

Hi David,

more messages means more progress on this issue, so fire away.

Your validate output looks reasonable, some tests are known to fail on
Windows.

I just verified that at least here the build seems to be stable with -j1:
40/40 builds were successful. Great! Now we know that something is up with
multithreaded make.

Thanks for pointing out that virus scanners could be an issue. I found that
Microsoft Security Essentials realtime scanning was on. I'll try disabling
it and see if that helps with the -j5 case.

> So that looks like another successful build. Unless "make" can ignore the
-j argument, I'd say the issue is caused or activated by your configuration.

I would be very happy if that were the case, but there were reports about
instabilities on msys2 from others too. Herbert wrote:

> PS: Fwiw, It seems to me the Cygwin environment seems more reliable
compared to the
>   Msys2 environment. On Cygwin I never had any aborted GHC builds,
>   while on Msys2 it seems to happen from time to time (but
 >  non-deterministic, and rather seldom)

Herbert, were you running make with -jN, N >1?


On Wed, Nov 5, 2014 at 11:36 AM, David Macek <david.macek.0 at gmail.com>
wrote:

> Sorry for the large amount of messages.
>
> On 5. 11. 2014 8:01, David Macek wrote:
> > I'm running validate to double check (detected 4 CPUs).
>
> I got the validate results:
>
> > Unexpected results from:
> > TEST="linker_unload listCommand002 T5681 T5486 T7571 ghcpkg05 T3924
> T7702 plugins01 T6106 ghci038 T8172 ghci032 T5975a T5975b ghci058 T3064
> T3307 environment001 T876 T3738 T4830 T5205 T7436 lazy-bs-alloc T1407
> rdynamic T7037 T5423 T8124 T5435_dyn_asm prog012 prog013 prog001 prog002
> prog003 T4006"
> >
> > OVERALL SUMMARY for test run started at 11/05/14 09:04:01 Central Europe
> Standard Time
> >  1:01:50 spent to go through
> >     4095 total tests, which gave rise to
> >    14911 test cases, of which
> >    11167 were skipped
> >
> >       58 had missing libraries
> >     3578 expected passes
> >       71 expected failures
> >
> >        1 caused framework failures
> >        1 unexpected passes
> >       36 unexpected failures
> >
> > Unexpected passes:
> >    rts  linker_unload (normal)
> >
> > Unexpected failures:
> >    ../../libraries/base/tests     T4006 [bad stdout] (normal)
> >    ../../libraries/base/tests/IO  T3307 [bad exit code] (normal)
> >    ../../libraries/base/tests/IO  environment001 [bad stdout] (normal)
> >    cabal                          ghcpkg05 [bad stderr] (normal)
> >    callarity/perf                 T3924 [stat too good] (normal)
> >    ghci.debugger/scripts          listCommand002 [bad stderr] (ghci)
> >    ghci/linking                   T1407 [bad stderr] (ghci)
> >    ghci/prog001                   prog001 [bad stderr] (ghci)
> >    ghci/prog002                   prog002 [bad stderr] (ghci)
> >    ghci/prog003                   prog003 [bad exit code] (ghci)
> >    ghci/prog012                   prog012 [bad stderr] (ghci)
> >    ghci/prog013                   prog013 [bad stderr] (ghci)
> >    ghci/scripts                   T5975a [bad stderr] (ghci)
> >    ghci/scripts                   T5975b [bad stderr] (ghci)
> >    ghci/scripts                   T6106 [bad stderr] (ghci)
> >    ghci/scripts                   T8172 [bad stdout] (ghci)
> >    ghci/scripts                   ghci032 [bad stderr] (ghci)
> >    ghci/scripts                   ghci038 [bad stderr] (ghci)
> >    ghci/scripts                   ghci058 [bad stderr] (ghci)
> >    llvm/should_compile            T5486 [stderr mismatch] (optllvm)
> >    llvm/should_compile            T5681 [stderr mismatch] (optllvm)
> >    llvm/should_compile            T7571 [stderr mismatch] (optllvm)
> >    perf/compiler                  T3064 [stat not good enough] (normal)
> >    perf/should_run                T3738 [stat too good] (normal)
> >    perf/should_run                T4830 [stat too good] (normal)
> >    perf/should_run                T5205 [stat too good] (normal)
> >    perf/should_run                T7436 [stat too good] (normal)
> >    perf/should_run                T876 [stat not good enough] (normal)
> >    perf/should_run                lazy-bs-alloc [stat not good enough]
> (normal)
> >    plugins                        plugins01 [bad stderr] (normal)
> >    rts                            T5423 [bad stdout] (normal)
> >    rts                            T5435_dyn_asm [bad stdout] (normal)
> >    rts                            T7037 [bad stdout] (normal)
> >    rts                            T8124 [exit code non-0] (threaded1)
> >    rts                            rdynamic [bad exit code] (normal)
> >    simplCore/should_compile       T7702 [stderr mismatch] (normal)
>
> I assume that means the build itself had no errors.
>
> --
> David Macek
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141105/178c8b2a/attachment.html>

From gintautas.miliauskas at gmail.com  Wed Nov  5 17:13:04 2014
From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas)
Date: Wed, 5 Nov 2014 18:13:04 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <CAFC_Meh+y9O1rdHWWjT8EDB0kWhFbDLSJT88kYBAEMbzh=ObdA@mail.gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
 <CAOYw7duty5OoX35NJq-mtc=MqyH6T7L9y2DfzHhWQxYAr1n2bg@mail.gmail.com>
 <5458CD34.6040600@gmail.com>
 <CAFC_Meg_UZATRAWKnf5daM5Qo0eCYp6CUPh1fovnC7gVATeQwg@mail.gmail.com>
 <5458EC7D.3080008@gmail.com>
 <CAFC_Meiy4REPCsKyYmZDSLsEZq-CY5RSTaPb4k1SL2EFH7Wzqw@mail.gmail.com>
 <54591E58.2060002@gmail.com>
 <CAFC_MehHXa2i2DeZLH_Oa2trFz+HWAh6ADoy1a9kb3fb8KT9=g@mail.gmail.com>
 <545951CB.8040604@gmail.com> <5459CB60.2080807@gmail.com>
 <5459FDBF.8070405@gmail.com>
 <CAFC_Meh+y9O1rdHWWjT8EDB0kWhFbDLSJT88kYBAEMbzh=ObdA@mail.gmail.com>
Message-ID: <CAFC_MejuO-P=0G4+uS=JUhrn9Zmif5gqHMTrPq9O17j00j6-ug@mail.gmail.com>

>
> Thanks for pointing out that virus scanners could be an issue. I found
> that Microsoft Security Essentials realtime scanning was on. I'll try
> disabling it and see if that helps with the -j5 case.
>

For what it's worth, I tried disabling the virus scanner, but it did not
help, 4/8 validation runs segfaulted (-j5).


-- 
Gintautas Miliauskas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141105/87ca2bc5/attachment.html>

From mikolaj at well-typed.com  Wed Nov  5 17:25:33 2014
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Wed, 5 Nov 2014 18:25:33 +0100
Subject: Can't compile GHC-7.8.3 from git, fails on haskell98 library
In-Reply-To: <87a949oak7.fsf@gmail.com>
References: <alpine.DEB.2.10.1411021415170.2047@galaxy>
 <alpine.DEB.2.10.1411022127230.2047@galaxy>
 <87a949oak7.fsf@gmail.com>
Message-ID: <CAHFo2upC7r692E+Ux-RhFNkLy3qp1nPy0NBUwTH3d61upYXS6A@mail.gmail.com>

> Starting with GHC 7.8.x, fingerprints are written into
> annotated & gpg-signed release tags:
>
>   http://git.haskell.org/ghc.git/tag/refs/tags/ghc-7.8.3-release
>
> That way you're able to restore via the fingerprint for a given release
> via:
>
>  ./utils/fingerprint/fingerprint.py restore -f <(git show ghc-7.8.3-release | grep -F '|')
>
> I'm just surprised I couldn't find that described anywhere in the wiki,
> I was sure it was written down somewhere...

Oh, pretty useful. I also couldn't find it on the wiki and this page

    https://ghc.haskell.org/trac/ghc/wiki/GitRepoReorganization

even claims it's going to be obsolete (starting with 7.10?).

Google shows that something related was mentioned in

    https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources?version=93

but the new version of the page missed that info.

This emails refers to the no-longer available info on the wiki, too:

    https://www.haskell.org/pipermail/ghc-devs/2014-January/003930.html

I wonder what happened and which info is meaningful only
for GHC < 7.8 or even ==7.8 and which parts make sense
for 7.10 as well.

Cheers,
Mikolaj

From austin at well-typed.com  Wed Nov  5 18:10:23 2014
From: austin at well-typed.com (Austin Seipp)
Date: Wed, 5 Nov 2014 12:10:23 -0600
Subject: Removing -ddump-simpl-phases and -ddump-core-pipeline flags?
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3949AB@DB3PRD3001MB020.064d.mgd.msft.net>
References: <201411051111.39621.jan.stolarek@p.lodz.pl>
 <618BE556AADD624C9C918AA5D5911BEF3F3949AB@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CAEs96n0x-KjSiz8_gorC_nOw9G5xNDd6FY7U2Msy8qNVwN0q=A@mail.gmail.com>

Yep, I say remove them both.

On Wed, Nov 5, 2014 at 4:57 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> I don't use either, so fine with me!
>
> | -----Original Message-----
> | From: Jan Stolarek [mailto:jan.stolarek at p.lodz.pl]
> | Sent: 05 November 2014 10:12
> | To: ghc-devs at haskell.org
> | Cc: Simon Peyton Jones
> | Subject: Removing -ddump-simpl-phases and -ddump-core-pipeline flags?
> |
> | As part of #9358 I'm considering removing these two flags:
> |
> | -ddump-simpl-phases: dumps simplifier statistics for phases of the
> | simplifier but it works only
> | when used together with -ddump-simpl-stats. User can limit which
> | statistics are displayed by
> | passing in either the simplifier phase number (0,1,2), phase name (final,
> | main,
> | post-worker-wrapper, Gentle) or both (separated with ":"). So for
> | example -ddump-simpl-phases=0:main,1 dumps statistics for all pases
> | labeled as phase 1 and only
> | those pases of phase 0 that are named "main". Has anyone ever used that
> | flag? Do we consider it
> | useful?
> |
> | -ddump-core-pipeline: this seems like a partially implemented stub. The
> | name is very misleading
> | because it is related to plugins. The only thing that it seems to do at
> | the moment is that
> | when -ddump-to-file is set then -ddump-core-pipeline will result in
> | dumping plugin passes to
> | file.
> |
> | Janek
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From berthold at Mathematik.Uni-Marburg.de  Wed Nov  5 20:31:27 2014
From: berthold at Mathematik.Uni-Marburg.de (Jost Berthold)
Date: Wed, 05 Nov 2014 21:31:27 +0100
Subject: "precedence when printing context" patch breaks ghc-7.8 branch
Message-ID: <545A891F.7050202@mathematik.uni-marburg.de>

Hi,

A build of the ghc-7.8 branch in its current state failed for me today 
in compiler/types/TypeRep.lhs

I am at commit 7b1d4c4 ("release note blurb..."), there was only one 
more since ("revert 'revert'...").

It seems as though the merge of commit d71f316ef ("...precedence when 
printing contexts..") does not fit into ghc-7.8 (that patch works on 
HEAD, of course). Error message is:

compiler/types/TypeRep.lhs:540:35:
     Not in scope: data constructor `TyOpPrec'

(a constructor introduced by that patch)

I have no idea how to fix this (GHC itself suggests "TopPrec", but that 
actually reverts the fix :-) )

Cheers,
Jost Berthold

From austin at well-typed.com  Wed Nov  5 20:35:45 2014
From: austin at well-typed.com (Austin Seipp)
Date: Wed, 5 Nov 2014 14:35:45 -0600
Subject: "precedence when printing context" patch breaks ghc-7.8 branch
In-Reply-To: <545A891F.7050202@mathematik.uni-marburg.de>
References: <545A891F.7050202@mathematik.uni-marburg.de>
Message-ID: <CAEs96n2XqW9Ms89P5+HqkcMKO=hcVNetbtnm7Q+hZTYBcFraow@mail.gmail.com>

Gah, sorry about that. I'll fix it!

On Wed, Nov 5, 2014 at 2:31 PM, Jost Berthold
<berthold at mathematik.uni-marburg.de> wrote:
> Hi,
>
> A build of the ghc-7.8 branch in its current state failed for me today in
> compiler/types/TypeRep.lhs
>
> I am at commit 7b1d4c4 ("release note blurb..."), there was only one more
> since ("revert 'revert'...").
>
> It seems as though the merge of commit d71f316ef ("...precedence when
> printing contexts..") does not fit into ghc-7.8 (that patch works on HEAD,
> of course). Error message is:
>
> compiler/types/TypeRep.lhs:540:35:
>     Not in scope: data constructor `TyOpPrec'
>
> (a constructor introduced by that patch)
>
> I have no idea how to fix this (GHC itself suggests "TopPrec", but that
> actually reverts the fix :-) )
>
> Cheers,
> Jost Berthold
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From austin at well-typed.com  Wed Nov  5 21:32:00 2014
From: austin at well-typed.com (Austin Seipp)
Date: Wed, 5 Nov 2014 15:32:00 -0600
Subject: "precedence when printing context" patch breaks ghc-7.8 branch
In-Reply-To: <CAEs96n2XqW9Ms89P5+HqkcMKO=hcVNetbtnm7Q+hZTYBcFraow@mail.gmail.com>
References: <545A891F.7050202@mathematik.uni-marburg.de>
 <CAEs96n2XqW9Ms89P5+HqkcMKO=hcVNetbtnm7Q+hZTYBcFraow@mail.gmail.com>
Message-ID: <CAEs96n1j5Gtd3Oxcy-rnTz_vOvwGUa8OaPNJgOfzMc0xvHY=YQ@mail.gmail.com>

Thanks Jost; I somehow totally missed this and reverted it (I'll look
into fixing it properly shortly).

On Wed, Nov 5, 2014 at 2:35 PM, Austin Seipp <austin at well-typed.com> wrote:
> Gah, sorry about that. I'll fix it!
>
> On Wed, Nov 5, 2014 at 2:31 PM, Jost Berthold
> <berthold at mathematik.uni-marburg.de> wrote:
>> Hi,
>>
>> A build of the ghc-7.8 branch in its current state failed for me today in
>> compiler/types/TypeRep.lhs
>>
>> I am at commit 7b1d4c4 ("release note blurb..."), there was only one more
>> since ("revert 'revert'...").
>>
>> It seems as though the merge of commit d71f316ef ("...precedence when
>> printing contexts..") does not fit into ghc-7.8 (that patch works on HEAD,
>> of course). Error message is:
>>
>> compiler/types/TypeRep.lhs:540:35:
>>     Not in scope: data constructor `TyOpPrec'
>>
>> (a constructor introduced by that patch)
>>
>> I have no idea how to fix this (GHC itself suggests "TopPrec", but that
>> actually reverts the fix :-) )
>>
>> Cheers,
>> Jost Berthold
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From thomasmiedema at gmail.com  Wed Nov  5 21:55:44 2014
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Wed, 5 Nov 2014 22:55:44 +0100
Subject: Update Trac link 'Patches for review'
Message-ID: <CAD3WKgi_C_SFSTh2EFXAjt6DXDveP67JRO5QD=kVaU-KZ27Qng@mail.gmail.com>

Dear Trac admins,

on the left panel of the Trac wiki there is a link
<https://ghc.haskell.org/trac/ghc/query?status=patch&ol=id&col=summary&col=owner&col=type&col=priority&col=milestone&col=component&order=priority>
called
'Patches for review'. This shows a mix of tickets that have patches
attached, and tickets that are being reviewed on Phabricator.

Can someone change that link to only show the tickets that have patches
attached, such that those are more easily found? You can do this by
appending "&differential=" to the url.

The list of open Phabricator reviews
<https://phabricator.haskell.org/differential/> can be discovered on the
Phabricator homepage, but I'm afraid the tickets
<https://ghc.haskell.org/trac/ghc/query?status=patch&differential=&col=id&col=summary&col=owner&col=type&col=priority&col=milestone&col=component&order=priority>
that have patches attached are now sometimes overlooked.

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141105/97f95c42/attachment.html>

From ezyang at mit.edu  Thu Nov  6 01:46:22 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Wed, 05 Nov 2014 17:46:22 -0800
Subject: Building head with head
In-Reply-To: <611257BE-C328-491D-AD04-C66C4ABB09D1@lichtzwerge.de>
References: <611257BE-C328-491D-AD04-C66C4ABB09D1@lichtzwerge.de>
Message-ID: <1415238348-sup-6923@sabre>

Hello Moritz,

I tried to do this relatively recently and recorded the problems
here:   https://ghc.haskell.org/trac/ghc/ticket/9652

I didn't finish diagnosing the further error.

Edward

Excerpts from Moritz Angermann's message of 2014-11-04 10:28:18 -0800:
> Hi,
> 
> today I tried to build head with head on os x.  The result was:
> 
> Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal ...
> "touch" utils/ghc-cabal/dist/build/tmp/ghc-cabal
> "cp" utils/ghc-cabal/dist/build/tmp/ghc-cabal inplace/bin/ghc-cabal
> "inplace/bin/ghc-cabal" configure libraries/binary dist-boot "" --with-ghc="/usr/local/bin/ghc" --with-ghc-pkg="/usr/local/bin/ghc-pkg"  --package-db=/Users/angerman/code/ghc/libraries/bootstrapping.conf --disable-library-for-ghci --enable-library-vanilla --disable-library-profiling --disable-shared --configure-option=CFLAGS=" -m64 -fno-stack-protector   " --configure-option=LDFLAGS=" -m64  " --configure-option=CPPFLAGS=" -m64  " --gcc-options=" -m64 -fno-stack-protector     -m64  "   --constraint "binary == 0.7.1.0"   --constraint "Cabal == 1.21.1.0"   --constraint "hpc == 0.6.0.2"   --constraint "bin-package-db == 0.0.0.0"   --constraint "hoopl == 3.10.0.2"   --constraint "transformers == 0.4.1.0"   --constraint "terminfo == 0.4.0.0" --with-gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-alex="/Users/angerman/.cabal/bin/alex" --with-happy="/Users/angerman/.cabal/bin/happy"
> "inplace/bin/ghc-cabal" configure utils/hsc2hs dist "" --with-ghc="/usr/local/bin/ghc" --with-ghc-pkg="/usr/local/bin/ghc-pkg"  --package-db=/Users/angerman/code/ghc/libraries/bootstrapping.conf --disable-library-for-ghci --disable-library-vanilla --disable-library-profiling --disable-shared --configure-option=CFLAGS=" -m64 -fno-stack-protector   " --configure-option=LDFLAGS=" -m64  " --configure-option=CPPFLAGS=" -m64  " --gcc-options=" -m64 -fno-stack-protector     -m64  "   --constraint "binary == 0.7.1.0"   --constraint "Cabal == 1.21.1.0"   --constraint "hpc == 0.6.0.2"   --constraint "bin-package-db == 0.0.0.0"   --constraint "hoopl == 3.10.0.2"   --constraint "transformers == 0.4.1.0"   --constraint "terminfo == 0.4.0.0" --with-gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-alex="/Users/angerman/.cabal/bin/alex" --with-happy="/Users/angerman/.cabal/bin/happy"
> Configuring hsc2hs-0.67...
> Configuring binary-0.7.1.0...
> ghc-cabal: '/usr/local/bin/ghc-pkg' exited with an error:
> ghc-pkg: ghc no longer supports single-file style package databases
> (/Users/angerman/code/ghc/libraries/bootstrapping.conf)
> use 'ghc-pkg init' to create the database with the correct format.
> make[1]: *** [utils/hsc2hs/dist/package-data.mk] Error 1
> make[1]: *** Waiting for unfinished jobs....
> ghc-cabal: '/usr/local/bin/ghc-pkg' exited with an error:
> ghc-pkg: ghc no longer supports single-file style package databases
> (/Users/angerman/code/ghc/libraries/bootstrapping.conf)
> use 'ghc-pkg init' to create the database with the correct format.
> make[1]: *** [libraries/binary/dist-boot/package-data.mk] Error 1
> 
> Does anyone know what needs to be done to make this work?
> 
> Best,
>  Moritz

From ezyang at mit.edu  Thu Nov  6 02:37:02 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Wed, 05 Nov 2014 18:37:02 -0800
Subject: loadInterfaceForModule
Message-ID: <1415241300-sup-7745@sabre>

Hello Gergely,

I was cleaning up LoadIface and I noticed in 

    commit 69fa2e558d56178d33950df815c3233606b0d44e
    Author: Austin Seipp <austin at well-typed.com>
    Date:   Fri Nov 1 22:15:53 2013 -0500

        Add support for module reification (#1480)

        Authored-by: Gergely Risko <gergely at risko.hu>
        Signed-off-by: Austin Seipp <austin at well-typed.com>

You added a function loadInterfaceForModule which has the exact same
type as loadModuleInterface, except when debugging is on it has an extra
check to ensure you don't try to load the the current module (this seems
like a general invariant that would be good to enforce).

Was there any particular reason you created an extra function for this,
or can we just use the existing function?

Edward

From juhpetersen at gmail.com  Thu Nov  6 09:40:28 2014
From: juhpetersen at gmail.com (Jens Petersen)
Date: Thu, 6 Nov 2014 18:40:28 +0900
Subject: Problems compiling with llvm-3.5.0-2 on ARM
In-Reply-To: <CAHYVw0zRtXz3jX6+VqQ6GYNVxD1ve98k1AUb=nZtf_koy-isvw@mail.gmail.com>
References: <CAHz445U2HKCv7VnP1wkk1kdSiJDSXcMNcHiTfM9fB+FsRKtCfA@mail.gmail.com>
 <CAEDGBqJQZKOdraP-Kt2xaWrw1JkBUvFdYSvvCAcGVZ=HAJHsBw@mail.gmail.com>
 <CAHYVw0zRtXz3jX6+VqQ6GYNVxD1ve98k1AUb=nZtf_koy-isvw@mail.gmail.com>
Message-ID: <CAEDGBqJ+RDxC9EZnP6mgivsBji0dSrmmwwSkXC8d7MSpH2khUg@mail.gmail.com>

On 6 November 2014 00:49, Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> TL;DR, you cant use llvm 3.5 or 3.6 with any current ghc release. use 3.4
> or older
>

Can we expect 3.5 (3.6) to work with ghc-7.10?
(FWIW helloworld seems to work ok with ghc-7.8.3 on x86_64, but not on
ARMv7.)

Or anyone have any patches?

Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141106/8337fb4c/attachment-0001.html>

From alexander at plaimi.net  Thu Nov  6 09:54:18 2014
From: alexander at plaimi.net (Alexander Berntsen)
Date: Thu, 06 Nov 2014 10:54:18 +0100
Subject: Abstracting over constraints: Can this be implemented in GHC?
Message-ID: <545B454A.9090504@plaimi.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I want to be able to write essentially this function:

f :: (a -> d) -> (b, c) -> (d, d)
f g (x, y) = (g x, g y)

What do we need here for this to work?

Well, given 'g :: a -> d', we need 'a' ~ 'b' ~ 'c' from the
constraints of 'g'. So let 'g = show', such that 'g :: Show a => a ->
String'. We need that forall 'a'. 'Show a'. And from that, forall 'b'
and 'c', 'Show b' and 'Show C'.

f show (1.2, False) = ("1.2", "False")

Another example, let 'g = (>2.0)'. Now 'g :: (Ord a, Fractional a) =>
a -> Bool'. So we need that forall 'a', 'Ord a, Fractional A'. From
this we need that forall 'b' and 'c', 'Ord b, Fractional b', and 'Ord
c, Fractional c'.

f (>5.0) (15, 6/2) = (True, False)

One last example, let 'g = id'. now 'g :: a -> a'. No constraints!

f id (x, y) = (x, y)


How close can we get to this today? Quite close. But the alternatives
all feel emphatically wrong to me.

? :set -XRankNTypes
? :set -XConstraintKinds
? let f :: forall b c d k. (k b, k c) => (forall a. k a => a -> d) ->
(b, c) -> (d, d); f g (x, y) = (g x, g y)
? (f :: (Show x, Show y) => (forall a. Show a => a -> d) -> (x, y) ->
(d, d)) show (1.2, False)

We need to specify k every time we use f. That's dreadful! While a
nicer syntax (which is suggested, but I don't think it's being
actively worked on right now) would allow us to write (f @Show) show
(1.2, False) or similar -- it's still not quite right. (Though an
obviously massive improvement over the status quo.)

Of course, were we merely concerned with getting the job done, we
would write either 'bimap g g', 'g *** g' or '\(x, y) -> (g x, g y)'.
The former two may look obscure at first ("hmm, why don't they just
use 'join'?"), so the latter might actually be best. But it's The
Wrong Thing! At least *I* think so.


So what do I want here? I guess kind-level forall for constraints, so
that 'f' can infer the constraints on 'b' and 'c' from the constraints
on 'a' imposed by 'g'. Is this implementable presently? Ever? :-]


CC'ing you, SPJ, because, well, types. Also CC'ing you, ekmett,
because you have an interesting library called Constraints, so maybe
you have some related insight to offer.
- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlRbRUoACgkQRtClrXBQc7WYbQD+Icr54KvxNA90SKIzPpp726hI
wZF4OUtuTXqyXPlU3UYBAIvg8J5uRX+UfNJKOI3PZubCfkJLuraNiW0EIgGD+hgd
=fWFQ
-----END PGP SIGNATURE-----

From simonpj at microsoft.com  Thu Nov  6 09:56:29 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 6 Nov 2014 09:56:29 +0000
Subject: [GHC] #9741: Interpreter stack checks are not quite right
In-Reply-To: <061.c9b25321d9587be7d727c9c3fb7b3660@haskell.org>
References: <046.3063371461063dd3b4b1c60903b205f1@haskell.org>
 <061.c9b25321d9587be7d727c9c3fb7b3660@haskell.org>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3972BF@DB3PRD3001MB020.064d.mgd.msft.net>

|   Oh, and the reason you have the debug RTS in your compiler is because
|  `-ticky` implies `-debug

Interesting.  I didn't know that.  Is that a good idea? Wouldn't it be better to make them independent?

Simon

|  -----Original Message-----
|  From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf
|  Of GHC
|  Sent: 06 November 2014 08:37
|  Cc: ghc-tickets at haskell.org
|  Subject: Re: [GHC] #9741: Interpreter stack checks are not quite right
|  
|  #9741: Interpreter stack checks are not quite right
|  -------------------------------------+--------------------------------
|  --
|  -------------------------------------+---
|                Reporter:  simonpj     |            Owner:  simonmar
|                    Type:  bug         |           Status:  closed
|                Priority:  highest     |        Milestone:  7.10.1
|               Component:  Compiler    |          Version:  7.8.3
|              Resolution:  fixed       |         Keywords:
|        Operating System:              |     Architecture:
|  Unknown/Multiple
|    Unknown/Multiple                   |       Difficulty:  Unknown
|         Type of failure:              |       Blocked By:
|    None/Unknown                       |  Related Tickets:
|               Test Case:              |
|                Blocking:              |
|  Differential Revisions:              |
|  -------------------------------------+--------------------------------
|  --
|  -------------------------------------+---
|  
|  Comment (by simonmar):
|  
|   Oh, and the reason you have the debug RTS in your compiler is because
|  `-ticky` implies `-debug`.  Incidentally this is probably slowing down
|  your builds quite a lot, so you might want to turn it off.
|  
|  --
|  Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9741#comment:5>
|  GHC <http://www.haskell.org/ghc/>
|  The Glasgow Haskell Compiler
|  _______________________________________________
|  ghc-tickets mailing list
|  ghc-tickets at haskell.org
|  http://www.haskell.org/mailman/listinfo/ghc-tickets

From gergely at risko.hu  Thu Nov  6 10:48:50 2014
From: gergely at risko.hu (Gergely Risko)
Date: Thu, 06 Nov 2014 11:48:50 +0100
Subject: loadInterfaceForModule
References: <1415241300-sup-7745@sabre>
Message-ID: <87mw847gfh.fsf@errge.nilcons.com>

Hi Edward,

Thank you for your mail.

On 2014-11-05 18:37 (Wednesday), "Edward Z. Yang" <ezyang at mit.edu> writes:
> Hello Gergely,
>
> You added a function loadInterfaceForModule which has the exact same
> type as loadModuleInterface, except when debugging is on it has an extra
> check to ensure you don't try to load the the current module (this seems
> like a general invariant that would be good to enforce).

As you can imagine after 1 year I only have limited recollection on
this, but now I checked out the repository to see the differences for
myself and I agree with your assessment, my function seems superfluous.

Also loadModuleInterfaces seems to be just a mapM_ of
loadModuleInterface instead of the four line implementation.  Maybe it
is being done like that for performance, but looking into
initIfaceTcRn does not seem very expensive.  Am I mistaken?

> Was there any particular reason you created an extra function for this,
> or can we just use the existing function?

Feel free to use the existing one.  By the way, these changes were
done as part of making it possible for TH to handle annotations,
therefore the relevant tests are in tests/annotations (grep for
reifyModule).

Thanks for taking care of this!
Gergely


From mlen at mlen.pl  Thu Nov  6 11:57:44 2014
From: mlen at mlen.pl (Mateusz Lenik)
Date: Thu, 6 Nov 2014 12:57:44 +0100
Subject: Resurrecting ticky code
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F38F02E@DB3PRD3001MB020.064d.mgd.msft.net>
References: <20141103171848.GA73387@polaris.local>
 <618BE556AADD624C9C918AA5D5911BEF3F38F02E@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <20141106115744.GA28375@polaris.local>

On Tue, Nov 04, 2014 at 09:52:23AM +0000, Simon Peyton Jones wrote:
> We don?t have "vectored returns" any more, so you can drop that one.

Thanks!

> 
> For "magic eight" there are some native-wordsize constants defined already.
> E.g. see how PrelRules.wordSizeInBits is computed.

As far as I understood that constant in ticky code was associated with number
of bins in the histogram, so I need to find a way to define it both in C and in
Haskell (preferably once). Actually there are nine bins, but eight is the index
of the last one.

Best,
Mateusz

> 
> Thanks to Jan for helping
> 
> SImon
> 
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> |  Mateusz Lenik
> |  Sent: 03 November 2014 17:19
> |  To: ghc-devs at haskell.org
> |  Subject: Resurrecting ticky code
> |  
> |  Hi *,
> |  
> |  Recently I started working on resurrecting ticky code[1] and got to
> |  the point where I can compile and run bumpHistogram as well as
> |  accompanying code in RTS.
> |  
> |  Work in progress version can be found at [2], but there are few things
> |  remaining to get it working:
> |  
> |  * missing calls to tickyReturnNewCon, tickyUnboxedTupleReturn and
> |    tickyVectoredReturn need to be added. Unfortunately I'm not familiar
> |  with the
> |    code enough to find the right place to insert them.
> |  
> |  * magic eight needs to be replaced by a constant both Haskell and C
> |  files.
> |    Preprocessor macro seems to be the simplest choice here, however I
> |  don't find
> |    it the cleanest way to do it.
> |  
> |  I would be very grateful if someone could take a look and point me
> |  into the right direction.
> |  
> |  
> |  Best,
> |  Mateusz
> |  
> |  1: https://ghc.haskell.org/trac/ghc/ticket/8308
> |  2: https://github.com/mlen/ghc/compare/ticky
> |  
> |  --
> |  Mateusz Lenik
> |  GPG: B865 E86A D36C 11A5 C1F8  C1D9 AAD4 CEC9 6B94 92C4

-- 
Mateusz Lenik
GPG: B865 E86A D36C 11A5 C1F8  C1D9 AAD4 CEC9 6B94 92C4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141106/3613a7be/attachment.sig>

From jan.stolarek at p.lodz.pl  Thu Nov  6 12:06:41 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Thu, 6 Nov 2014 13:06:41 +0100
Subject: ANN: Updating flag description in the User's Guide
Message-ID: <201411061306.41801.jan.stolarek@p.lodz.pl>

Devs,

I have some important information for everyone.

  TL;DR1 As a rule of thumb, whenever you modify DynFlags or StaticFlags please
  make absolutely sure that your changes are described in the User's Guide. See
  Note [Updating flag description in the User's Guide] in DynFlags.

  TL;DR2 Your help is needed to update the User's Guide.

I've spent last two days on updating the flag descriptions in the User's Guide
(#9358). Saying that things were a complete mess would be an understatement. We
had lots of flags that were not documented in the user's guide, we had
documentation for flags that no longer exist, lots of flags were incorrectly
labeled as static, etc. It seems that we don't have a habit of updating User's
Guide when we change the code responsible for flags. I updated huge chunks of
the documentation and things are in a better shape now. But if we forget to
update documentation when we make changes then in 2 or 3 years things will most
likely be as bad as they were before my clean-up. I added a Note and lots of
references to it to remind us about that. If things go well we might even have a
Herald rule to remind about updating User's Guide whenever DynFlags and
StaticFlags are modified by a commit/revision [1].

However, the task of updating flag descriptions in the User's Guide is not
finished. My main focus were the -f*/-fno-* optimisation flags described
primarily in sections 4.10 and 4.19.15 (note that HEAD has different section
numbers than 7.8.3). I updated what I could but there are still some
descriptions missing - I'm not familiar with some of flags that we have. Here's
where your help is required.

These flags are currently completely missing from the User's Guide:

  -fbuilding-cabal-package
  -fflat-cache
  -fhpc-no-auto
  -fkill-absence
  -fkill-one-shot
  -fsimple-list-literals
  -fspecialise-aggressively
  -fuse-rpaths
  -fspec-constr-recursive
  -ffloat-lam-args
  -ffloat-all-lams

If you can provide description for any of these flags please edit flags.xml and
using.xml. I suspect that -fkill-absence might be related to demand analysis -
CCing Nicolas Frisby.

Following flags are listed in Flag Reference section (4.19) with a brief one
sentence description but they don't have a detailed description in section 4.10
(using.xml):

  -fcall-arity (CCing Joachim)
  -funfolding-fun-discount
  -funfolding-dict-discount
  -funfolding-keeness-factor
  -frule-check (see #9776)

Following flags have a detailed description but it is confusing:

  -fdo-eta-reduction
  -fdo-lambda-eta-expansion

Follwoing flags have a description but it is too brief. We should have more
details:

  -fdicts-cheap
  -fdicts-strict
  -fdmd-tx-dict-sel (Nicolas, can you update that?)
  -fmax-inline-memcpy-insns
  -fmax-inline-memset-insns
  -fmax-worker-args
  -fno-opt-coercion
  -fno-pre-inlining
  -fsimplifier-phases
  -fspec-constr-threshold
  -fspec-constr-count
  -fstrictness-before

These flags were deliberately omitted from the User's Guide because they are
deprectaed and will be removed:

  -fext-core
  -frewrite-rules

For these flags Flag Reference section provides the description of their -fno-*
version:

  -fembed-manifest
  -fgen-manifest
  -fghci-history
  -fghci-sandbox
  -fpre-inlining
  -fprint-bind-contents
  -fprof-count-entries
  -fshared-implib

This seems to go against our convention of describing the flags. Should we
revert to desribing their normal version (ie. ones that enable something, not
disable)?

As part of my work I also removed -ddump-core-pipeline and -ddump-simpl-phases,
which weren;t very useful. And I cleaned up DynFlags by putting some of the long
lists of flags into alphabetical order. This change is a bit invasive - I'm
sorry if it causes merge conflicts, but I believe that in the long run this is
beneficial.

As I already said I focused primarily on -f* flags. But we should also make sure
that documentation of remaining flags is up to date, especially the -d* ones. I
don't have more time to put into this so I'm asking for a collective effort to
update the User's Guide, especially that we are moving closer to 7.10 release.

Janek

[1] https://phabricator.haskell.org/T52

From mail at joachim-breitner.de  Thu Nov  6 12:27:53 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 06 Nov 2014 13:27:53 +0100
Subject: Daily documentation build?
Message-ID: <1415276873.1392.7.camel@joachim-breitner.de>

Hi,

a while ago someone said that we have daily builds of the documentation.
But...

 * it is slightly tricky to find it. Starting from
https://ghc.haskell.org/trac/ghc/wiki/ I had to follow the ?Guilde is
also availble? link about daily builds, and then the link from the
summary. Ok if one knows where to look, but hard to discover by itself.

 * it seems that they are not built any more.
http://haskell.inf.elte.hu/docs/ lists Aug-18 as the latest.

Having that would have made it easier for me to review the state of the
docs on flags that Jan is writing about.

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141106/4efc1829/attachment.sig>

From marlowsd at gmail.com  Thu Nov  6 12:28:58 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 06 Nov 2014 12:28:58 +0000
Subject: ANN: Updating flag description in the User's Guide
In-Reply-To: <201411061306.41801.jan.stolarek@p.lodz.pl>
References: <201411061306.41801.jan.stolarek@p.lodz.pl>
Message-ID: <545B698A.8090804@gmail.com>

On 06/11/2014 12:06, Jan Stolarek wrote:
> Devs,
>
> I have some important information for everyone.
>
>    TL;DR1 As a rule of thumb, whenever you modify DynFlags or StaticFlags please
>    make absolutely sure that your changes are described in the User's Guide. See
>    Note [Updating flag description in the User's Guide] in DynFlags.
>
>    TL;DR2 Your help is needed to update the User's Guide.
>
> I've spent last two days on updating the flag descriptions in the User's Guide
> (#9358). Saying that things were a complete mess would be an understatement. We
> had lots of flags that were not documented in the user's guide, we had
> documentation for flags that no longer exist, lots of flags were incorrectly
> labeled as static, etc. It seems that we don't have a habit of updating User's
> Guide when we change the code responsible for flags. I updated huge chunks of
> the documentation and things are in a better shape now. But if we forget to
> update documentation when we make changes then in 2 or 3 years things will most
> likely be as bad as they were before my clean-up. I added a Note and lots of
> references to it to remind us about that. If things go well we might even have a
> Herald rule to remind about updating User's Guide whenever DynFlags and
> StaticFlags are modified by a commit/revision [1].

Your efforts are much appreciated, thankyou :)

> These flags are currently completely missing from the User's Guide:
>
>    -fbuilding-cabal-package
>    -fflat-cache
>    -fhpc-no-auto
>    -fkill-absence
>    -fkill-one-shot
>    -fsimple-list-literals
>    -fspecialise-aggressively
>    -fuse-rpaths
>    -fspec-constr-recursive
>    -ffloat-lam-args
>    -ffloat-all-lams

Sometimes we add flags that are for experimentation or development 
purposes and not intended for user consumption, and these tend not to be 
added to the User's Guide.  I suspect many of the flags you mention fall 
into this category.  I suggest for these we have a specific comment in 
the source "developer use only; undocumented" so that we know they don't 
need to go in the User's Guide.

> For these flags Flag Reference section provides the description of their -fno-*
> version:
>
>    -fembed-manifest
>    -fgen-manifest
>    -fghci-history
>    -fghci-sandbox
>    -fpre-inlining
>    -fprint-bind-contents
>    -fprof-count-entries
>    -fshared-implib
>
> This seems to go against our convention of describing the flags. Should we
> revert to desribing their normal version (ie. ones that enable something, not
> disable)?

Flags that are on by default we often document the no- version 
deliberately, because this is the form the user is most likely to want. 
  Documenting the positive version sounds strange and is likely to be 
confusing.  I'm surprised you didn't include -fomit-yields here.

> As part of my work I also removed -ddump-core-pipeline and -ddump-simpl-phases,

isn't -ddump-simpl-phases useful?  what's the other way to do that?

Cheers,
Simon

From johan.tibell at gmail.com  Thu Nov  6 12:30:13 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 6 Nov 2014 13:30:13 +0100
Subject: [commit: ghc] master: Remove -ddump-simpl-phases flag (ad8457f)
In-Reply-To: <20141106120506.948D33A300@ghc.haskell.org>
References: <20141106120506.948D33A300@ghc.haskell.org>
Message-ID: <CAK-tuPZ3qyzMnCpxn+1HU-WH2On13LUbbvc3UHzSp7xkSV+0PA@mail.gmail.com>

I think this flag is useful for debugging e.g. why something didn't
optimize the way you thought.
On Nov 6, 2014 1:05 PM, <git at git.haskell.org> wrote:

> Repository : ssh://git at git.haskell.org/ghc
>
> On branch  : master
> Link       :
> http://ghc.haskell.org/trac/ghc/changeset/ad8457f93807e3b7a9a24867ed69dc93662a29e3/ghc
>
> >---------------------------------------------------------------
>
> commit ad8457f93807e3b7a9a24867ed69dc93662a29e3
> Author: Jan Stolarek <jan.stolarek at p.lodz.pl>
> Date:   Wed Nov 5 13:37:25 2014 +0100
>
>     Remove -ddump-simpl-phases flag
>
>
> >---------------------------------------------------------------
>
> ad8457f93807e3b7a9a24867ed69dc93662a29e3
>  compiler/main/DynFlags.hs        | 15 +++------------
>  compiler/simplCore/CoreMonad.lhs | 40
> ++++++----------------------------------
>  compiler/simplCore/SimplCore.lhs |  9 +++++----
>  docs/users_guide/debugging.xml   | 11 -----------
>  docs/users_guide/flags.xml       |  6 ------
>  5 files changed, 14 insertions(+), 67 deletions(-)
>
> Diff suppressed because of size. To see it, use:
>
>     git diff-tree --root --patch-with-stat --no-color --find-copies-harder
> --ignore-space-at-eol --cc ad8457f93807e3b7a9a24867ed69dc93662a29e3
> _______________________________________________
> ghc-commits mailing list
> ghc-commits at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141106/c323bd2c/attachment.html>

From simonpj at microsoft.com  Thu Nov  6 12:32:34 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 6 Nov 2014 12:32:34 +0000
Subject: Daily documentation build?
In-Reply-To: <1415276873.1392.7.camel@joachim-breitner.de>
References: <1415276873.1392.7.camel@joachim-breitner.de>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F397619@DB3PRD3001MB020.064d.mgd.msft.net>

|   * it is slightly tricky to find it. Starting from
|  https://ghc.haskell.org/trac/ghc/wiki/ I had to follow the ?Guilde is
|  also availble? link about daily builds, and then the link from the
|  summary. Ok if one knows where to look, but hard to discover by
|  itself.

Where would you expect to find it?  Serious question!


Here's how you can:
GHC home page: https://www.haskell.org/ghc/
Click on "Documentation": https://www.haskell.org/haskellwiki/GHC
"You can find the latest documentation for the current HEAD here"

But it'd not very prominent.  Where else should we add a link?

Simon


|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Joachim Breitner
|  Sent: 06 November 2014 12:28
|  To: ghc-devs at haskell.org
|  Subject: Daily documentation build?
|  
|  Hi,
|  
|  a while ago someone said that we have daily builds of the
|  documentation.
|  But...
|  
|   * it is slightly tricky to find it. Starting from
|  https://ghc.haskell.org/trac/ghc/wiki/ I had to follow the ?Guilde is
|  also availble? link about daily builds, and then the link from the
|  summary. Ok if one knows where to look, but hard to discover by
|  itself.
|  
|   * it seems that they are not built any more.
|  http://haskell.inf.elte.hu/docs/ lists Aug-18 as the latest.
|  
|  Having that would have made it easier for me to review the state of
|  the docs on flags that Jan is writing about.
|  
|  Greetings,
|  Joachim
|  
|  --
|  Joachim ?nomeata? Breitner
|    mail at joachim-breitner.de ? http://www.joachim-breitner.de/
|    Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
|    Debian Developer: nomeata at debian.org


From marlowsd at gmail.com  Thu Nov  6 12:34:27 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 06 Nov 2014 12:34:27 +0000
Subject: STM and GC write barrier
In-Reply-To: <CAO27hRqwbL+dEFbScQi6QOm7BVS=MmHnJHGAVVVbWrCQzR=--w@mail.gmail.com>
References: <CAO27hRqwbL+dEFbScQi6QOm7BVS=MmHnJHGAVVVbWrCQzR=--w@mail.gmail.com>
Message-ID: <545B6AD3.6010104@gmail.com>

On 15/09/2014 17:50, Ryan Yates wrote:
> I'm starting to get to the bottom of something that has been puzzling me
> for a while.  Recently commit 6d784c43592290ec16db8b7f0f2a012dff3ed497
> [1] introduced the GC write barrier for TVars.  Not fully understanding
> things and reading the commit message to be saying that this was an
> optimization, I implemented my hardware transactional memory support
> without the write barrier (avoiding the extra work inside a
> transaction).  This resulted in occasional crashes where a TVar which
> was point to a valid heap object when it was committed, pointed to
> garbage later.  My understanding was that the TVar ended up in a later
> generation then the value that it came to point to and without getting
> added to the mut list, the value was collected.  Adding the write
> barrier to all TVars written in my hardware transaction made the problem
> go away.
>
> While this all makes sense to me, what doesn't make as much sense is how
> STM prior to the commit above was not susceptible to the same problem.
>   Is there some machinery to avoid this issue that I'm still missing?

Sorry for the delay, I'm just catching up with this mailing list.

Prior to this commit, the garbage collector would treat *all* TVars in 
the old generation as potentially modified, and traverse them all during 
every GC.  This is expensive when there are a lot of TVars, which meant 
that TVar-based data structures such as TChan would perform very badly 
with a large number of elements.  The fix is to track writes to TVars in 
the old generation, which is what that commit did.

Cheers,
Simon

From mail at joachim-breitner.de  Thu Nov  6 12:42:03 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 06 Nov 2014 13:42:03 +0100
Subject: Daily documentation build?
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F397619@DB3PRD3001MB020.064d.mgd.msft.net>
References: <1415276873.1392.7.camel@joachim-breitner.de>
 <618BE556AADD624C9C918AA5D5911BEF3F397619@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <1415277723.1392.9.camel@joachim-breitner.de>

Hi,


Am Donnerstag, den 06.11.2014, 12:32 +0000 schrieb Simon Peyton Jones:
> |   * it is slightly tricky to find it. Starting from
> |  https://ghc.haskell.org/trac/ghc/wiki/ I had to follow the ?Guilde is
> |  also availble? link about daily builds, and then the link from the
> |  summary. Ok if one knows where to look, but hard to discover by
> |  itself.
> 
> Where would you expect to find it?  Serious question!

I was expecting that question, but I don?t have a good answer.

Probably there where I can actually find it:

Sidebar link ?Infrastructure? ? link ?user documentation?.

I guess we are fine.

Greetings,
Joachim
-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141106/f073e37e/attachment.sig>

From mail at joachim-breitner.de  Thu Nov  6 12:44:38 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 06 Nov 2014 13:44:38 +0100
Subject: [commit: ghc] master: Fix a couple of inaccurate stack checks
 (3bebf3c)
In-Reply-To: <20141105181551.49A673A300@ghc.haskell.org>
References: <20141105181551.49A673A300@ghc.haskell.org>
Message-ID: <1415277878.1392.11.camel@joachim-breitner.de>

Hi Simon,


with

Am Mittwoch, den 05.11.2014, 18:15 +0000 schrieb git at git.haskell.org:
> commit 3bebf3c2d92e6defc6d17ffa237cc4a9cad71dcf
> Author: Simon Marlow <marlowsd at gmail.com>
> Date:   Tue Nov 4 21:31:00 2014 +0000
> 
>     Fix a couple of inaccurate stack checks

I observe a 5% runtime performance regression in nofib?s "integer"
benchmark:
http://ghcspeed-nomeata.rhcloud.com/timeline/?exe=2&base=2%2B68&ben=nofib%2Ftime%2Finteger&env=2&revs=50&equid=on

(The graph looks weird because codespeed doesn?t get the order of
commits right.)

Expected? Or worth looking into?

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141106/3e790bca/attachment.sig>

From dev at rodlogic.net  Thu Nov  6 12:48:51 2014
From: dev at rodlogic.net (RodLogic)
Date: Thu, 6 Nov 2014 10:48:51 -0200
Subject: ANN: Updating flag description in the User's Guide
In-Reply-To: <545B698A.8090804@gmail.com>
References: <201411061306.41801.jan.stolarek@p.lodz.pl>
 <545B698A.8090804@gmail.com>
Message-ID: <CA++tqLbxcOKKPwjFeB90cWoJRn2Vdu+ew5x6qUda6mdR_3b-7Q@mail.gmail.com>

What about standardizing on an 'experimental' prefix such as -fx-use-rpaths
or -fx-kill-oneshot? These flags would not be added to the user guide and
their intent clear when actually using them.

On Thu, Nov 6, 2014 at 10:28 AM, Simon Marlow <marlowsd at gmail.com> wrote:

> On 06/11/2014 12:06, Jan Stolarek wrote:
>
>> Devs,
>>
>> I have some important information for everyone.
>>
>>    TL;DR1 As a rule of thumb, whenever you modify DynFlags or StaticFlags
>> please
>>    make absolutely sure that your changes are described in the User's
>> Guide. See
>>    Note [Updating flag description in the User's Guide] in DynFlags.
>>
>>    TL;DR2 Your help is needed to update the User's Guide.
>>
>> I've spent last two days on updating the flag descriptions in the User's
>> Guide
>> (#9358). Saying that things were a complete mess would be an
>> understatement. We
>> had lots of flags that were not documented in the user's guide, we had
>> documentation for flags that no longer exist, lots of flags were
>> incorrectly
>> labeled as static, etc. It seems that we don't have a habit of updating
>> User's
>> Guide when we change the code responsible for flags. I updated huge
>> chunks of
>> the documentation and things are in a better shape now. But if we forget
>> to
>> update documentation when we make changes then in 2 or 3 years things
>> will most
>> likely be as bad as they were before my clean-up. I added a Note and lots
>> of
>> references to it to remind us about that. If things go well we might even
>> have a
>> Herald rule to remind about updating User's Guide whenever DynFlags and
>> StaticFlags are modified by a commit/revision [1].
>>
>
> Your efforts are much appreciated, thankyou :)
>
>  These flags are currently completely missing from the User's Guide:
>>
>>    -fbuilding-cabal-package
>>    -fflat-cache
>>    -fhpc-no-auto
>>    -fkill-absence
>>    -fkill-one-shot
>>    -fsimple-list-literals
>>    -fspecialise-aggressively
>>    -fuse-rpaths
>>    -fspec-constr-recursive
>>    -ffloat-lam-args
>>    -ffloat-all-lams
>>
>
> Sometimes we add flags that are for experimentation or development
> purposes and not intended for user consumption, and these tend not to be
> added to the User's Guide.  I suspect many of the flags you mention fall
> into this category.  I suggest for these we have a specific comment in the
> source "developer use only; undocumented" so that we know they don't need
> to go in the User's Guide.
>
>  For these flags Flag Reference section provides the description of their
>> -fno-*
>> version:
>>
>>    -fembed-manifest
>>    -fgen-manifest
>>    -fghci-history
>>    -fghci-sandbox
>>    -fpre-inlining
>>    -fprint-bind-contents
>>    -fprof-count-entries
>>    -fshared-implib
>>
>> This seems to go against our convention of describing the flags. Should we
>> revert to desribing their normal version (ie. ones that enable something,
>> not
>> disable)?
>>
>
> Flags that are on by default we often document the no- version
> deliberately, because this is the form the user is most likely to want.
> Documenting the positive version sounds strange and is likely to be
> confusing.  I'm surprised you didn't include -fomit-yields here.
>
>  As part of my work I also removed -ddump-core-pipeline and
>> -ddump-simpl-phases,
>>
>
> isn't -ddump-simpl-phases useful?  what's the other way to do that?
>
> Cheers,
> Simon
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141106/d353ef2a/attachment.html>

From pali.gabor at gmail.com  Thu Nov  6 12:49:11 2014
From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=)
Date: Thu, 6 Nov 2014 13:49:11 +0100
Subject: Daily documentation build?
In-Reply-To: <1415276873.1392.7.camel@joachim-breitner.de>
References: <1415276873.1392.7.camel@joachim-breitner.de>
Message-ID: <CAHnG2CyJoS9KsLT8XjE2uhXcZ1xk5yg_R89=NdiPC2snmos5iQ@mail.gmail.com>

2014-11-06 13:27 GMT+01:00 Joachim Breitner <mail at joachim-breitner.de>:
> a while ago someone said that we have daily builds of the documentation.
> But...

I guess that was me, but I cannot do the Windows builds any more,
because the Cabal library update broken the build for me.  (See my
previous mails on the subject, even from a few days back ago.)
However, this would be essential to generate a full documentation
snapshot.

>  * it seems that they are not built any more.
> http://haskell.inf.elte.hu/docs/ lists Aug-18 as the latest.

That is September 18, to be more precise.

> Having that would have made it easier for me to review the state of the
> docs on flags that Jan is writing about.

Until the Windows build is fixed, I could do documentation builds
without the Win32 library if that is okay.

From jan.stolarek at p.lodz.pl  Thu Nov  6 12:53:39 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Thu, 6 Nov 2014 13:53:39 +0100
Subject: Daily documentation build?
In-Reply-To: <1415277723.1392.9.camel@joachim-breitner.de>
References: <1415276873.1392.7.camel@joachim-breitner.de>
 <618BE556AADD624C9C918AA5D5911BEF3F397619@DB3PRD3001MB020.064d.mgd.msft.net>
 <1415277723.1392.9.camel@joachim-breitner.de>
Message-ID: <201411061353.40065.jan.stolarek@p.lodz.pl>

> ?* it is slightly tricky to find it. Starting from
> https://ghc.haskell.org/trac/ghc/wiki/ I had to follow the ?Guilde is
> also availble? link about daily builds, and then the link from the
> summary. Ok if one knows where to look, but hard to discover by itself.
Yeah, I had the same problem in the past. That's why I added the link to "Infrastructure" page (as 
you have already realized).

Seems that the build bots are down. It would be good to have them working again but fixing #9772 
would be even better.

Janek

From jan.stolarek at p.lodz.pl  Thu Nov  6 13:02:09 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Thu, 6 Nov 2014 14:02:09 +0100
Subject: ANN: Updating flag description in the User's Guide
In-Reply-To: <545B698A.8090804@gmail.com>
References: <201411061306.41801.jan.stolarek@p.lodz.pl>
 <545B698A.8090804@gmail.com>
Message-ID: <201411061402.09408.jan.stolarek@p.lodz.pl>

> Sometimes we add flags that are for experimentation or development
> purposes and not intended for user consumption, and these tend not to be
> added to the User's Guide.  I suspect many of the flags you mention fall
> into this category.  I suggest for these we have a specific comment in
> the source "developer use only; undocumented" so that we know they don't
> need to go in the User's Guide.
I don't like that policy. What if some of the mentioned flags could be useful for my development 
work but I have no idea how to use these flags because they are not documented? I think we should 
have these documented as well, possibly with a note saying that this is experimental/unstable.

> isn't -ddump-simpl-phases useful?  what's the other way to do that?
I'll reply in a thread started by Johan.

Janek

From jan.stolarek at p.lodz.pl  Thu Nov  6 13:10:02 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Thu, 6 Nov 2014 14:10:02 +0100
Subject: [commit: ghc] master: Remove -ddump-simpl-phases flag (ad8457f)
In-Reply-To: <CAK-tuPZ3qyzMnCpxn+1HU-WH2On13LUbbvc3UHzSp7xkSV+0PA@mail.gmail.com>
References: <20141106120506.948D33A300@ghc.haskell.org>
 <CAK-tuPZ3qyzMnCpxn+1HU-WH2On13LUbbvc3UHzSp7xkSV+0PA@mail.gmail.com>
Message-ID: <201411061410.02495.jan.stolarek@p.lodz.pl>

Simon Marlow wrote:
> isn't -ddump-simpl-phases useful? ?what's the other way to do that?
-dverbose-core2core + -ddump-simple-stats

Johan Tibell wrote:
> I think this flag is useful for debugging e.g. why something didn't
> optimize the way you thought.
Well, you can get that information using flags mentioned above. It seemed that -ddump-simpl-phases 
is not used and can be safely removed. It wasn't documented at all, so the only way to figure out 
how it works was to look hard at the code. The output itself was rather cryptic - no information 
about the phase for which the stats are displayed. Again, the only way to make sense of that 
output was looking at the code to figure out the precise ordering of Core optimisations. 
With -dverbose-core2core the output makes a lot more sense because it directly follows the output 
of the phase.

Simon PJ and Austin spoke in favour of removing that flag, so I went ahead and did that. But if 
indeed was used by someone to do their work we could revert that.

Janek

From jan.stolarek at p.lodz.pl  Thu Nov  6 13:13:37 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Thu, 6 Nov 2014 14:13:37 +0100
Subject: ANN: Updating flag description in the User's Guide
In-Reply-To: <CA++tqLbxcOKKPwjFeB90cWoJRn2Vdu+ew5x6qUda6mdR_3b-7Q@mail.gmail.com>
References: <201411061306.41801.jan.stolarek@p.lodz.pl>
 <545B698A.8090804@gmail.com>
 <CA++tqLbxcOKKPwjFeB90cWoJRn2Vdu+ew5x6qUda6mdR_3b-7Q@mail.gmail.com>
Message-ID: <201411061413.37799.jan.stolarek@p.lodz.pl>

> What about standardizing on an 'experimental' prefix such as -fx-use-rpaths
> or -fx-kill-oneshot? These flags would not be added to the user guide and
> their intent clear when actually using them.
As already stated in an earlier reply I think we should have documentation for the sake of other 
developers.

I don't like the idea of separate prefix for experimental flags. This could be problematic when 
the flag becomes stable - we would have to change its name and that would break backwards 
compatibility.

Janek

From johan.tibell at gmail.com  Thu Nov  6 13:31:28 2014
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 6 Nov 2014 14:31:28 +0100
Subject: ANN: Updating flag description in the User's Guide
In-Reply-To: <201411061413.37799.jan.stolarek@p.lodz.pl>
References: <201411061306.41801.jan.stolarek@p.lodz.pl>
 <545B698A.8090804@gmail.com>
 <CA++tqLbxcOKKPwjFeB90cWoJRn2Vdu+ew5x6qUda6mdR_3b-7Q@mail.gmail.com>
 <201411061413.37799.jan.stolarek@p.lodz.pl>
Message-ID: <CAK-tuPYxciO2W28U-MwN9YJLnGjzGFDv2g=O-wnb2uypcayTPg@mail.gmail.com>

Agreed. For example, the HTTP standard has moved away from X-prefixed
headers for similar reasons.

On Thu, Nov 6, 2014 at 2:13 PM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:

> > What about standardizing on an 'experimental' prefix such as
> -fx-use-rpaths
> > or -fx-kill-oneshot? These flags would not be added to the user guide and
> > their intent clear when actually using them.
> As already stated in an earlier reply I think we should have documentation
> for the sake of other
> developers.
>
> I don't like the idea of separate prefix for experimental flags. This
> could be problematic when
> the flag becomes stable - we would have to change its name and that would
> break backwards
> compatibility.
>
> Janek
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141106/7a7c1420/attachment.html>

From jan.stolarek at p.lodz.pl  Thu Nov  6 13:35:37 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Thu, 6 Nov 2014 14:35:37 +0100
Subject: Resurrecting ticky code
In-Reply-To: <20141103171848.GA73387@polaris.local>
References: <20141103171848.GA73387@polaris.local>
Message-ID: <201411061435.37088.jan.stolarek@p.lodz.pl>

Mateusz,

I had a moment to take a look at your patch. Here are some hints:

> * missing calls to tickyReturnNewCon, tickyUnboxedTupleReturn and
>   tickyVectoredReturn need to be added. Unfortunately I'm not familiar with
> the code enough to find the right place to insert them.
I think that you should look at StgCmmExpr and try to figure out places that we might be 
interested in for ticky measurements. For example, I'm looking at cgIdApp and I see we're doing 
ticky profiling for SlowCall and DirectEntry but we're not doing it for ReturnIt, EnterIt and 
JumpToIt*. I suggest adding ticky profiling there. I think it's possible to figure out more 
places where it makes sense to have ticky counters.

> * magic eight needs to be replaced by a constant both Haskell and C files.
>   Preprocessor macro seems to be the simplest choice here, however I don't
> find it the cleanest way to do it.
I don't know how to define such a constant - I would have to spent some time to try to figure it 
out. Perhaps you can go to #ghc IRC channel and ask there? Usually there are some people that 
work on the RTS and might be familiar with how this is done (Edward for example).

Oh, and if you're working on a patch please assign yourself as the owner of #8308 so that no one 
else starts working on this. If you have a patch for review please submit it using Phabricator 
[1].

Janek

[1] https://ghc.haskell.org/trac/ghc/wiki/Phabricator

From fryguybob at gmail.com  Thu Nov  6 14:10:08 2014
From: fryguybob at gmail.com (Ryan Yates)
Date: Thu, 6 Nov 2014 09:10:08 -0500
Subject: STM and GC write barrier
In-Reply-To: <545B6AD3.6010104@gmail.com>
References: <CAO27hRqwbL+dEFbScQi6QOm7BVS=MmHnJHGAVVVbWrCQzR=--w@mail.gmail.com>
 <545B6AD3.6010104@gmail.com>
Message-ID: <CAO27hRrOHSK6wscvKGSsKybGFC-xFVGFqQc2ArMZWHUpAhW6nQ@mail.gmail.com>

Ok, that explains it.  Thanks!

On Thu, Nov 6, 2014 at 7:34 AM, Simon Marlow <marlowsd at gmail.com> wrote:

> On 15/09/2014 17:50, Ryan Yates wrote:
>
>> I'm starting to get to the bottom of something that has been puzzling me
>> for a while.  Recently commit 6d784c43592290ec16db8b7f0f2a012dff3ed497
>> [1] introduced the GC write barrier for TVars.  Not fully understanding
>> things and reading the commit message to be saying that this was an
>> optimization, I implemented my hardware transactional memory support
>> without the write barrier (avoiding the extra work inside a
>> transaction).  This resulted in occasional crashes where a TVar which
>> was point to a valid heap object when it was committed, pointed to
>> garbage later.  My understanding was that the TVar ended up in a later
>> generation then the value that it came to point to and without getting
>> added to the mut list, the value was collected.  Adding the write
>> barrier to all TVars written in my hardware transaction made the problem
>> go away.
>>
>> While this all makes sense to me, what doesn't make as much sense is how
>> STM prior to the commit above was not susceptible to the same problem.
>>   Is there some machinery to avoid this issue that I'm still missing?
>>
>
> Sorry for the delay, I'm just catching up with this mailing list.
>
> Prior to this commit, the garbage collector would treat *all* TVars in the
> old generation as potentially modified, and traverse them all during every
> GC.  This is expensive when there are a lot of TVars, which meant that
> TVar-based data structures such as TChan would perform very badly with a
> large number of elements.  The fix is to track writes to TVars in the old
> generation, which is what that commit did.
>
> Cheers,
> Simon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141106/9cb61e17/attachment.html>

From austin at well-typed.com  Thu Nov  6 17:38:25 2014
From: austin at well-typed.com (Austin Seipp)
Date: Thu, 6 Nov 2014 11:38:25 -0600
Subject: Daily documentation build?
In-Reply-To: <201411061353.40065.jan.stolarek@p.lodz.pl>
References: <1415276873.1392.7.camel@joachim-breitner.de>
 <618BE556AADD624C9C918AA5D5911BEF3F397619@DB3PRD3001MB020.064d.mgd.msft.net>
 <1415277723.1392.9.camel@joachim-breitner.de>
 <201411061353.40065.jan.stolarek@p.lodz.pl>
Message-ID: <CAEs96n1uq0K_OjpfQVXPcBHk3wFhUv4miiLCp0yS7UmvT5RR9g@mail.gmail.com>

I also wonder if it would be nice for Phabricator to upload
documentation/artifacts somewhere. Maybe I should implement this, for
the Continuous Integration builds on Phab.

The main thing is I don't want the build to get all spammy with a
million emails, like it did before. But maybe that's workaroundable.

On Thu, Nov 6, 2014 at 6:53 AM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:
>>  * it is slightly tricky to find it. Starting from
>> https://ghc.haskell.org/trac/ghc/wiki/ I had to follow the ?Guilde is
>> also availble? link about daily builds, and then the link from the
>> summary. Ok if one knows where to look, but hard to discover by itself.
> Yeah, I had the same problem in the past. That's why I added the link to "Infrastructure" page (as
> you have already realized).
>
> Seems that the build bots are down. It would be good to have them working again but fixing #9772
> would be even better.
>
> Janek
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From pali.gabor at gmail.com  Fri Nov  7 09:45:33 2014
From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=)
Date: Fri, 7 Nov 2014 10:45:33 +0100
Subject: Daily documentation build?
In-Reply-To: <CAHnG2CyJoS9KsLT8XjE2uhXcZ1xk5yg_R89=NdiPC2snmos5iQ@mail.gmail.com>
References: <1415276873.1392.7.camel@joachim-breitner.de>
 <CAHnG2CyJoS9KsLT8XjE2uhXcZ1xk5yg_R89=NdiPC2snmos5iQ@mail.gmail.com>
Message-ID: <CAHnG2CzpadNZ4eunbPkOWJFR1qRRLuGAnspfifWsaU9BQ=Gucg@mail.gmail.com>

2014-11-06 13:49 GMT+01:00 P?li G?bor J?nos <pali.gabor at gmail.com>:
>> Having that would have made it easier for me to review the state of the
>> docs on flags that Jan is writing about.
>
> Until the Windows build is fixed, I could do documentation builds
> without the Win32 library if that is okay.

All right, I have now generated the documentation build without the
Haddock of the Win32 library -- with a ".noWin32" suffix -- and added
to the site:

http://haskell.inf.elte.hu/docs/7.9.20141107.noWin32/

And I have set up a cron job to do this daily.  This will
automatically omit the suffix and add the Win32 documentation, when
the Windows builds are available.

From gergo at erdi.hu  Fri Nov  7 09:53:23 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Fri, 7 Nov 2014 17:53:23 +0800 (SGT)
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <CAJumaK-UpWirPtfeMX0xHAf34H9CpxKXrdaHh_ErTPsGNXMpow@mail.gmail.com>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAJumaK-UpWirPtfeMX0xHAf34H9CpxKXrdaHh_ErTPsGNXMpow@mail.gmail.com>
Message-ID: <alpine.DEB.2.10.1411071752390.2047@galaxy>

On Wed, 5 Nov 2014, Edward Kmett wrote:

> One note on the syntax front, 'pattern type' was mentioned as annoyingly trying to
> shoehorn the word 'type' in to lean on an existing keyword, even though its about a
> term level construction rather than a type level one.
> We do have some perfectly serviceable keywords available to us that indicate a more
> 'term/pattern' orientation, e.g. 'case' and 'of' come to mind as things that are
> viable candidates for similar abuse here.

careful there, or someone might suggest

type of pattern P :: ...


:P

From jan.stolarek at p.lodz.pl  Fri Nov  7 11:03:36 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Fri, 7 Nov 2014 12:03:36 +0100
Subject: How do I write multi-file test that are expected to fail?
Message-ID: <201411071203.36819.jan.stolarek@p.lodz.pl>

I want to write a test where I import several modules into module Foo and expect that compilation 
of Foo fails. How do I do that? If I write:

test('T6018fail', normal, compile_fail, [''])

I get en error:

T6018fail.hs:5:1:
    Failed to load interface for `T6018Afail'
    Use -v to se a list of the files searched for.

If I use multimod_compile instead of compile_fail then I get an error because compilation is 
expected to succeed. Help?

Janek

From jan.stolarek at p.lodz.pl  Fri Nov  7 11:12:06 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Fri, 7 Nov 2014 12:12:06 +0100
Subject: How do I write multi-file test that are expected to fail?
In-Reply-To: <201411071203.36819.jan.stolarek@p.lodz.pl>
References: <201411071203.36819.jan.stolarek@p.lodz.pl>
Message-ID: <201411071212.06793.jan.stolarek@p.lodz.pl>

Ok, nevermind. Solved. Instructions from the wiki didn't work because I haven't symlinked new 
files to my build tree.

Janek

Dnia pi?tek, 7 listopada 2014, Jan Stolarek napisa?:
> I want to write a test where I import several modules into module Foo and
> expect that compilation of Foo fails. How do I do that? If I write:
>
> test('T6018fail', normal, compile_fail, [''])
>
> I get en error:
>
> T6018fail.hs:5:1:
>     Failed to load interface for `T6018Afail'
>     Use -v to se a list of the files searched for.
>
> If I use multimod_compile instead of compile_fail then I get an error
> because compilation is expected to succeed. Help?
>
> Janek
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs



From marlowsd at gmail.com  Fri Nov  7 11:42:17 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 07 Nov 2014 11:42:17 +0000
Subject: ANN: Updating flag description in the User's Guide
In-Reply-To: <201411061402.09408.jan.stolarek@p.lodz.pl>
References: <201411061306.41801.jan.stolarek@p.lodz.pl>
 <545B698A.8090804@gmail.com> <201411061402.09408.jan.stolarek@p.lodz.pl>
Message-ID: <545CB019.3090503@gmail.com>

On 06/11/2014 13:02, Jan Stolarek wrote:
>> Sometimes we add flags that are for experimentation or development
>> purposes and not intended for user consumption, and these tend not to be
>> added to the User's Guide.  I suspect many of the flags you mention fall
>> into this category.  I suggest for these we have a specific comment in
>> the source "developer use only; undocumented" so that we know they don't
>> need to go in the User's Guide.
> I don't like that policy. What if some of the mentioned flags could be useful for my development
> work but I have no idea how to use these flags because they are not documented? I think we should
> have these documented as well, possibly with a note saying that this is experimental/unstable.

Requiring that all experimental flags be fully documented in the User's 
Guide is both too onerous for the developer, and too confusing for 
users, IMO.  It's a User's Guide, not a developer's guide, after all! 
The developer has access to the source code, so they can find out what a 
flag actually does, and if it's not obvious then a comment should suffice.

Cheers,
Simon


From thomasmiedema at gmail.com  Fri Nov  7 12:54:45 2014
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Fri, 7 Nov 2014 13:54:45 +0100
Subject: Daily documentation build?
In-Reply-To: <CAHnG2CzpadNZ4eunbPkOWJFR1qRRLuGAnspfifWsaU9BQ=Gucg@mail.gmail.com>
References: <1415276873.1392.7.camel@joachim-breitner.de>
 <CAHnG2CyJoS9KsLT8XjE2uhXcZ1xk5yg_R89=NdiPC2snmos5iQ@mail.gmail.com>
 <CAHnG2CzpadNZ4eunbPkOWJFR1qRRLuGAnspfifWsaU9BQ=Gucg@mail.gmail.com>
Message-ID: <CAD3WKgj8GQbi7Uk1GsXoMZ6a5gVToZzLi6tOf4u7YfnNR82J+g@mail.gmail.com>

>
> All right, I have now generated the documentation build without the
> Haddock of the Win32 library -- with a ".noWin32" suffix -- and added
> to the site:
>
> http://haskell.inf.elte.hu/docs/7.9.20141107.noWin32/


Thanks, for working on this. Fyi: that link only shows a few empty bz2
files at the moment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141107/db593f2f/attachment.html>

From austin at well-typed.com  Fri Nov  7 13:48:18 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 7 Nov 2014 07:48:18 -0600
Subject: Update Trac link 'Patches for review'
In-Reply-To: <CAD3WKgi_C_SFSTh2EFXAjt6DXDveP67JRO5QD=kVaU-KZ27Qng@mail.gmail.com>
References: <CAD3WKgi_C_SFSTh2EFXAjt6DXDveP67JRO5QD=kVaU-KZ27Qng@mail.gmail.com>
Message-ID: <CAEs96n16-wB-7vdWWAvkmdjUs6xBZvr_tVZFg7XeDBQ_ExaVkA@mail.gmail.com>

Hi Thomas,

This is now done, sorry for taking so long (we really need to revision
control and automate these templates).

On Wed, Nov 5, 2014 at 3:55 PM, Thomas Miedema <thomasmiedema at gmail.com> wrote:
> Dear Trac admins,
>
> on the left panel of the Trac wiki there is a link called 'Patches for
> review'. This shows a mix of tickets that have patches attached, and tickets
> that are being reviewed on Phabricator.
>
> Can someone change that link to only show the tickets that have patches
> attached, such that those are more easily found? You can do this by
> appending "&differential=" to the url.
>
> The list of open Phabricator reviews can be discovered on the Phabricator
> homepage, but I'm afraid the tickets that have patches attached are now
> sometimes overlooked.
>
> Thanks,
> Thomas
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From austin at well-typed.com  Fri Nov  7 13:49:54 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 7 Nov 2014 07:49:54 -0600
Subject: How do I write multi-file test that are expected to fail?
In-Reply-To: <201411071212.06793.jan.stolarek@p.lodz.pl>
References: <201411071203.36819.jan.stolarek@p.lodz.pl>
 <201411071212.06793.jan.stolarek@p.lodz.pl>
Message-ID: <CAEs96n3zyee2qqppc8-tG-nMq0YMCa1ZWTB3_bnBQzyKb3=8Bg@mail.gmail.com>

Relatedly, there is also a different syntax: multimod_compile_fail
(grep for it, e.g. prog002).

But I wonder what the difference is in your case from what you're
doing now (I haven't looked closely).

On Fri, Nov 7, 2014 at 5:12 AM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:
> Ok, nevermind. Solved. Instructions from the wiki didn't work because I haven't symlinked new
> files to my build tree.
>
> Janek
>
> Dnia pi?tek, 7 listopada 2014, Jan Stolarek napisa?:
>> I want to write a test where I import several modules into module Foo and
>> expect that compilation of Foo fails. How do I do that? If I write:
>>
>> test('T6018fail', normal, compile_fail, [''])
>>
>> I get en error:
>>
>> T6018fail.hs:5:1:
>>     Failed to load interface for `T6018Afail'
>>     Use -v to se a list of the files searched for.
>>
>> If I use multimod_compile instead of compile_fail then I get an error
>> because compilation is expected to succeed. Help?
>>
>> Janek
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From jan.stolarek at p.lodz.pl  Fri Nov  7 13:53:41 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Fri, 7 Nov 2014 14:53:41 +0100
Subject: How do I write multi-file test that are expected to fail?
In-Reply-To: <CAEs96n3zyee2qqppc8-tG-nMq0YMCa1ZWTB3_bnBQzyKb3=8Bg@mail.gmail.com>
References: <201411071203.36819.jan.stolarek@p.lodz.pl>
 <201411071212.06793.jan.stolarek@p.lodz.pl>
 <CAEs96n3zyee2qqppc8-tG-nMq0YMCa1ZWTB3_bnBQzyKb3=8Bg@mail.gmail.com>
Message-ID: <201411071453.41927.jan.stolarek@p.lodz.pl>

> Relatedly, there is also a different syntax: multimod_compile_fail
> (grep for it, e.g. prog002).
multimod_compile_fail is what I was looking for. Found that on the wiki.

Janek

From austin at well-typed.com  Fri Nov  7 13:54:08 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 7 Nov 2014 07:54:08 -0600
Subject: Problems compiling with llvm-3.5.0-2 on ARM
In-Reply-To: <CAEDGBqJ+RDxC9EZnP6mgivsBji0dSrmmwwSkXC8d7MSpH2khUg@mail.gmail.com>
References: <CAHz445U2HKCv7VnP1wkk1kdSiJDSXcMNcHiTfM9fB+FsRKtCfA@mail.gmail.com>
 <CAEDGBqJQZKOdraP-Kt2xaWrw1JkBUvFdYSvvCAcGVZ=HAJHsBw@mail.gmail.com>
 <CAHYVw0zRtXz3jX6+VqQ6GYNVxD1ve98k1AUb=nZtf_koy-isvw@mail.gmail.com>
 <CAEDGBqJ+RDxC9EZnP6mgivsBji0dSrmmwwSkXC8d7MSpH2khUg@mail.gmail.com>
Message-ID: <CAEs96n1xJfmE=eX2D-JvvuH9mnKX+es0AFgPOJ+E9PAiGPjRQQ@mail.gmail.com>

Jens,

Yes, we'd like to land D155 before 7.10.

I've CC'd the relevant people on the patch. Can anyone speak up as to
how far along this is? I believe after Peter's review, the ball is in
your court, Ben?

On Thu, Nov 6, 2014 at 3:40 AM, Jens Petersen <juhpetersen at gmail.com> wrote:
> On 6 November 2014 00:49, Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>>
>> TL;DR, you cant use llvm 3.5 or 3.6 with any current ghc release. use 3.4
>> or older
>
>
> Can we expect 3.5 (3.6) to work with ghc-7.10?
> (FWIW helloworld seems to work ok with ghc-7.8.3 on x86_64, but not on
> ARMv7.)
>
> Or anyone have any patches?
>
> Jens
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From pali.gabor at gmail.com  Fri Nov  7 15:27:47 2014
From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=)
Date: Fri, 7 Nov 2014 16:27:47 +0100
Subject: Daily documentation build?
In-Reply-To: <CAD3WKgj8GQbi7Uk1GsXoMZ6a5gVToZzLi6tOf4u7YfnNR82J+g@mail.gmail.com>
References: <1415276873.1392.7.camel@joachim-breitner.de>
 <CAHnG2CyJoS9KsLT8XjE2uhXcZ1xk5yg_R89=NdiPC2snmos5iQ@mail.gmail.com>
 <CAHnG2CzpadNZ4eunbPkOWJFR1qRRLuGAnspfifWsaU9BQ=Gucg@mail.gmail.com>
 <CAD3WKgj8GQbi7Uk1GsXoMZ6a5gVToZzLi6tOf4u7YfnNR82J+g@mail.gmail.com>
Message-ID: <CAHnG2CzHeg1gWOUgntiYTkwr-x3V8c=w42e4AQ=+1FG25a9-6A@mail.gmail.com>

2014-11-07 13:54 GMT+01:00 Thomas Miedema <thomasmiedema at gmail.com>:
> Thanks, for working on this. Fyi: that link only shows a few empty bz2 files
> at the moment.

Ooops, sorry -- it is now fixed.

From eir at cis.upenn.edu  Fri Nov  7 15:36:42 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Fri, 7 Nov 2014 10:36:42 -0500
Subject: Abstracting over constraints: Can this be implemented in GHC?
In-Reply-To: <545B454A.9090504@plaimi.net>
References: <545B454A.9090504@plaimi.net>
Message-ID: <46BEE07D-DABA-44D0-BC11-FBDD3718ACF1@cis.upenn.edu>

I don't see a way to do this without a proxy parameter (or an explicit type application, once those are available). But, I also don't see a reason why inference can't be extended to include this case. Figuring out how it would work would be a proper, full-on research project, though.

Interesting.

Richard

On Nov 6, 2014, at 4:54 AM, Alexander Berntsen <alexander at plaimi.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> I want to be able to write essentially this function:
> 
> f :: (a -> d) -> (b, c) -> (d, d)
> f g (x, y) = (g x, g y)
> 
> What do we need here for this to work?
> 
> Well, given 'g :: a -> d', we need 'a' ~ 'b' ~ 'c' from the
> constraints of 'g'. So let 'g = show', such that 'g :: Show a => a ->
> String'. We need that forall 'a'. 'Show a'. And from that, forall 'b'
> and 'c', 'Show b' and 'Show C'.
> 
> f show (1.2, False) = ("1.2", "False")
> 
> Another example, let 'g = (>2.0)'. Now 'g :: (Ord a, Fractional a) =>
> a -> Bool'. So we need that forall 'a', 'Ord a, Fractional A'. From
> this we need that forall 'b' and 'c', 'Ord b, Fractional b', and 'Ord
> c, Fractional c'.
> 
> f (>5.0) (15, 6/2) = (True, False)
> 
> One last example, let 'g = id'. now 'g :: a -> a'. No constraints!
> 
> f id (x, y) = (x, y)
> 
> 
> How close can we get to this today? Quite close. But the alternatives
> all feel emphatically wrong to me.
> 
> ? :set -XRankNTypes
> ? :set -XConstraintKinds
> ? let f :: forall b c d k. (k b, k c) => (forall a. k a => a -> d) ->
> (b, c) -> (d, d); f g (x, y) = (g x, g y)
> ? (f :: (Show x, Show y) => (forall a. Show a => a -> d) -> (x, y) ->
> (d, d)) show (1.2, False)
> 
> We need to specify k every time we use f. That's dreadful! While a
> nicer syntax (which is suggested, but I don't think it's being
> actively worked on right now) would allow us to write (f @Show) show
> (1.2, False) or similar -- it's still not quite right. (Though an
> obviously massive improvement over the status quo.)
> 
> Of course, were we merely concerned with getting the job done, we
> would write either 'bimap g g', 'g *** g' or '\(x, y) -> (g x, g y)'.
> The former two may look obscure at first ("hmm, why don't they just
> use 'join'?"), so the latter might actually be best. But it's The
> Wrong Thing! At least *I* think so.
> 
> 
> So what do I want here? I guess kind-level forall for constraints, so
> that 'f' can infer the constraints on 'b' and 'c' from the constraints
> on 'a' imposed by 'g'. Is this implementable presently? Ever? :-]
> 
> 
> CC'ing you, SPJ, because, well, types. Also CC'ing you, ekmett,
> because you have an interesting library called Constraints, so maybe
> you have some related insight to offer.
> - -- 
> Alexander
> alexander at plaimi.net
> https://secure.plaimi.net/~alexander
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iF4EAREIAAYFAlRbRUoACgkQRtClrXBQc7WYbQD+Icr54KvxNA90SKIzPpp726hI
> wZF4OUtuTXqyXPlU3UYBAIvg8J5uRX+UfNJKOI3PZubCfkJLuraNiW0EIgGD+hgd
> =fWFQ
> -----END PGP SIGNATURE-----
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 


From austin at well-typed.com  Fri Nov  7 18:16:22 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 7 Nov 2014 12:16:22 -0600
Subject: RFC: Dropping Windows XP support
Message-ID: <CAEs96n25Bf2eDCn+dNMHCgKHPQ03F6kZXFBfzEuAacR6rojpBw@mail.gmail.com>

Hi all,

This is a quick discussion about the current system requirements for
Windows builds.

Spurred by a recent[1] LLVM discussion, I'd like to raise the question
of dropping support for Windows XP, and bumping the minimum required
version to Windows Vista or even Windows 7.

For one, Microsoft doesn't support XP anymore, so most people are
moving off it anyway. 'Soon' even XP Embedded will be obsoleted.

But second, Vista and beyond introduced useful new APIs we could use.
I was digging through the LLVM thread and two came out to me:

 1) We could switch to using slim reader/writer locks, which in some
workloads may work out better than critical sections (they'll win on
more read-heavy workloads). The downsides is there's no recursive
locking but we don't use that anyway (and recursive locks are
considered bad by many anyway[2]).

 2) We could probably use an actual condition variables API that was
introduced with Vista. Currently we use a giant EVENT object to
emulate the API, which could be replaced with the real deal.

Both of these could be nice wins for simplicity and performance I think.

I know there are some corporate users out there who this may impact,
and users as well. I'd like to know what people think. Particularly
what version we should standardize on.

FWIW, I don't plan on changing any of this until the 7.12 release at least.

[1] http://article.gmane.org/gmane.comp.compilers.llvm.devel/78419
[2] http://www.zaval.org/resources/library/butenhof1.html

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From david.feuer at gmail.com  Fri Nov  7 18:20:44 2014
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 7 Nov 2014 13:20:44 -0500
Subject: RFC: Dropping Windows XP support
In-Reply-To: <CAEs96n25Bf2eDCn+dNMHCgKHPQ03F6kZXFBfzEuAacR6rojpBw@mail.gmail.com>
References: <CAEs96n25Bf2eDCn+dNMHCgKHPQ03F6kZXFBfzEuAacR6rojpBw@mail.gmail.com>
Message-ID: <CAMgWh9vGH2H77TeZAZHs1zW1CihqTZbb3qAbQL+yBtP=maZOwg@mail.gmail.com>

+1. Windows XP was Microsoft's most successful OS thus far, but it's pretty
much dead now. One potentially related potential concern: how will this
change affect Wine support?

On Fri, Nov 7, 2014 at 1:16 PM, Austin Seipp <austin at well-typed.com> wrote:

> Hi all,
>
> This is a quick discussion about the current system requirements for
> Windows builds.
>
> Spurred by a recent[1] LLVM discussion, I'd like to raise the question
> of dropping support for Windows XP, and bumping the minimum required
> version to Windows Vista or even Windows 7.
>
> For one, Microsoft doesn't support XP anymore, so most people are
> moving off it anyway. 'Soon' even XP Embedded will be obsoleted.
>
> But second, Vista and beyond introduced useful new APIs we could use.
> I was digging through the LLVM thread and two came out to me:
>
>  1) We could switch to using slim reader/writer locks, which in some
> workloads may work out better than critical sections (they'll win on
> more read-heavy workloads). The downsides is there's no recursive
> locking but we don't use that anyway (and recursive locks are
> considered bad by many anyway[2]).
>
>  2) We could probably use an actual condition variables API that was
> introduced with Vista. Currently we use a giant EVENT object to
> emulate the API, which could be replaced with the real deal.
>
> Both of these could be nice wins for simplicity and performance I think.
>
> I know there are some corporate users out there who this may impact,
> and users as well. I'd like to know what people think. Particularly
> what version we should standardize on.
>
> FWIW, I don't plan on changing any of this until the 7.12 release at least.
>
> [1] http://article.gmane.org/gmane.comp.compilers.llvm.devel/78419
> [2] http://www.zaval.org/resources/library/butenhof1.html
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141107/b42a58dd/attachment-0001.html>

From mail at joachim-breitner.de  Fri Nov  7 20:07:32 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 07 Nov 2014 21:07:32 +0100
Subject: [commit: ghc] master: Fix a couple of inaccurate stack checks
 (3bebf3c)
In-Reply-To: <1415277878.1392.11.camel@joachim-breitner.de>
References: <20141105181551.49A673A300@ghc.haskell.org>
 <1415277878.1392.11.camel@joachim-breitner.de>
Message-ID: <1415390852.27140.3.camel@joachim-breitner.de>

Hi,


Am Donnerstag, den 06.11.2014, 13:44 +0100 schrieb Joachim Breitner:
> Am Mittwoch, den 05.11.2014, 18:15 +0000 schrieb git at git.haskell.org:
> > commit 3bebf3c2d92e6defc6d17ffa237cc4a9cad71dcf
> > Author: Simon Marlow <marlowsd at gmail.com>
> > Date:   Tue Nov 4 21:31:00 2014 +0000
> > 
> >     Fix a couple of inaccurate stack checks
> 
> I observe a 5% runtime performance regression in nofib?s "integer"
> benchmark:
> http://ghcspeed-nomeata.rhcloud.com/timeline/?exe=2&base=2%2B68&ben=nofib%2Ftime%2Finteger&env=2&revs=50&equid=on
> 
> (The graph looks weird because codespeed doesn?t get the order of
> commits right.)
> 
> Expected? Or worth looking into?

I?m no longer sure its caused by this commit. That test suddenly behaves
rather erratic. Maybe it was something else that pushed it close to some
GC run threshold. *shrug*

Greetings,
Joachim
-- 
Joachim Breitner
  e-Mail: mail at joachim-breitner.de
  Homepage: http://www.joachim-breitner.de
  Jabber-ID: nomeata at joachim-breitner.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141107/8924bb97/attachment.sig>

From george.colpitts at gmail.com  Fri Nov  7 20:26:19 2014
From: george.colpitts at gmail.com (George Colpitts)
Date: Fri, 7 Nov 2014 16:26:19 -0400
Subject: Is anybody able to build HEAD on Mac with Yosemite wtih Xcode 6.1 and
 GHC 7.8.3
Message-ID: <CAB-d4A7EhwZ3KN0dqm8DRBK8YdZByU+7gCLpEH=aBuMEvpGcWA@mail.gmail.com>

Hi

I was previously able to build using Builder
<https://ghc.haskell.org/trac/ghc/wiki/Builder> on my Mac using 10.9, Xcode
6.0 and ghc 7.8.3. Currently with 10.10 and Xcode 6.1 I am getting the
following error using Builder. Has anybody been able to build HEAD on Mac
with Yosemite wtih Xcode 6.1 and GHC 7.8.3?

make test_bindist

bindisttest/"install   dir"/bin/runghc bindisttest/HelloWorld >
bindisttest/output
<command line>: can't load .so/.DLL for:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib
(dlopen(/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib,
9): no suitable image found.  Did find:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib:
mach-o, but wrong filetype)
make[1]: *** [test_bindist] Error 1
make: *** [test_bindist] Error 2

?Thanks
George
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141107/e439993b/attachment.html>

From marlowsd at gmail.com  Fri Nov  7 20:36:09 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 07 Nov 2014 20:36:09 +0000
Subject: Phabricator guidance
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F31EA61@DB3PRD3001MB020.064d.mgd.msft.net>
References: <618BE556AADD624C9C918AA5D5911BEF3F31B677@DB3PRD3001MB020.064d.mgd.msft.net>
 <87vbnwckta.fsf@gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F31C986@DB3PRD3001MB020.064d.mgd.msft.net>
 <201410071405.53497.jan.stolarek@p.lodz.pl>
 <618BE556AADD624C9C918AA5D5911BEF3F31EA61@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <545D2D39.8080408@gmail.com>

On 07/10/2014 15:52, Simon Peyton Jones wrote:
> Much better thank you.
>
> Now I get as far as
> compiler/typecheck/TcTyClsDecls.lhs:421:26: Warning:
>      Pattern match(es) are non-exhaustive
>      In a case alternative: Patterns not matched: KindedTyVarSig (L _ _)
>
> No time to investigate right now.
>
> =============
>
> New workflow question for Austin/Herbert.  Suppose Jan updates D202 to fix the above.  What's my workflow for getting his fix. If I say "arc patch D202" again, it probably won't work well because I'm already on local branch arcpatch-D202.
>
> I suppose I can
> 	git checkout master
> 	git branch --delete arcpatch-D202
> 	arc patch D202
>
> but is there a better way?

"arc patch" always makes a new branch, unless you ask it not to.  So it 
doesn't matter what branch you're currently on.

Cheers,
Simon



>
> S
>
> |  -----Original Message-----
> |  From: Jan Stolarek [mailto:jan.stolarek at p.lodz.pl]
> |  Sent: 07 October 2014 13:06
> |  To: ghc-devs at haskell.org
> |  Cc: Simon Peyton Jones; Herbert Valerio Riedel
> |  Subject: Re: Phabricator guidance
> |
> |  Ugh. Arc is not easy to use :-/ Indeed 3e17822 does not seem to be in
> |  the revision on phab, although it exists in my local tree. I just
> |  pushed a fixed to Phab. Simon, does `arc patch D202` work now?
> |
> |  Herbert, remember how I complained on IRC that `arc diff` does not
> |  automatically recognize that I'm updating a revision and I need to
> |  manually specify base commit? You told me that I need to add revision
> |  information to the commit message. I did that and `arc diff`indeed
> |  recognized the revision without me explicitly specifying the base
> |  commit. But now it turns out that it created an incomplete revision by
> |  pushing only the latest commit from my branch :-/
> |
> |  Janek
> |
> |  Dnia wtorek, 7 pa?dziernika 2014, Simon Peyton Jones napisa?:
> |  > Aha, that helps.  And looking further at
> |  > https://phabricator.haskell.org/D202, I can see under "Revision
> |  update
> |  > history" that there are four diffs all stashed in this on Phab
> |  ticket.
> |  > (That contradicts my previous model which was one patch per Phab
> |  > ticket; people have been complaining about that.)
> |  >
> |  > So my new questions are:
> |  >
> |  > * How can I apply "Diff 1" or "Diff 2"?  Using "arc patch" only
> |  > applies "Diff 4"
> |  >
> |  > * How can I apply all of "Diff 1" ... "Diff 4" in one go?
> |  >
> |  > Simon
> |  >
> |  > |  -----Original Message-----
> |  > |  From: Herbert Valerio Riedel [mailto:hvriedel at gmail.com]
> |  > |  Sent: 07 October 2014 10:05
> |  > |  To: Simon Peyton Jones
> |  > |  Cc: ghc-devs at haskell.org
> |  > |  Subject: Re: Phabricator guidance
> |  > |
> |  > |  On 2014-10-07 at 10:57:00 +0200, Simon Peyton Jones wrote:
> |  > |  > I suppose I will have to look at this. But I have no clue how to
> |  > | do
> |  > |
> |  > |  so.
> |  > |
> |  > |  > D202 itself seems to be a very small patch (only ten lines or
> |  > | so),
> |  > |
> |  > |  so presumably it applies on top of some other patch?  But what?
> |  > |
> |  > |  > Someone said I could use
> |  > |  > 	arc patch D202
> |  > |  > to apply the patch in my own tree, which is crucial for
> |  > | reproducing  > the error that Jan is stuck on.
> |  > |  >
> |  > |  > BUT the patch presumably applies to a  > particular commit, NOT
> |  > | the head of my current tree.  But what is the  > base commit to
> |  > | which it applies?  Does arc patch check out the base  > commit
> |  > | before applying?
> |  > |
> |  > |  If you actually perform 'arc patch D202', this is the output you
> |  > | currently get:
> |  > |
> |  > |
> |  > |  ,----
> |  > |
> |  > |  | Created and checked out branch arcpatch-D202.
> |  > |  |
> |  > |  |
> |  > |  |     This diff is against commit
> |  > |
> |  > |  3e17822f5f4e4d2f582dc0a053f532125f9777c7, but
> |  > |
> |  > |  |     the commit is nowhere in the working copy. Try to apply it
> |  > |
> |  > |  against the
> |  > |
> |  > |  |     current working copy state?
> |  > |
> |  > |  (3549c952b535803270872adaf87262f2df0295a4)
> |  > |
> |  > |  |     [Y/n] n
> |  > |
> |  > |  `----
> |  > |
> |  > |  So yes, 'arc' tries apply the code-revision on top of the commit
> |  is
> |  > | was based on; and in this case, it is actually missing from ghc.git
> |  > | :-  /
> |  > |
> |  > |  What's more, you can also declare that a code-revisions builds on
> |  > | top  of another code-revision, in which case 'arc' will
> |  > | automatically try  to
> |  > |  (recursively) apply that other code-revision to your source-tree
> |  > | first, before applying the one you are actually requesting on top.
> |  > |
> |  > |
> |  > |  I hope Austin or someone else may chime in to provide further
> |  > | assistance if this doesn't help...
> |  >
> |  > _______________________________________________
> |  > ghc-devs mailing list
> |  > ghc-devs at haskell.org
> |  > http://www.haskell.org/mailman/listinfo/ghc-devs
> |
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From allbery.b at gmail.com  Fri Nov  7 20:39:07 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Fri, 7 Nov 2014 15:39:07 -0500
Subject: Is anybody able to build HEAD on Mac with Yosemite wtih Xcode 6.1
 and GHC 7.8.3
In-Reply-To: <CAB-d4A7EhwZ3KN0dqm8DRBK8YdZByU+7gCLpEH=aBuMEvpGcWA@mail.gmail.com>
References: <CAB-d4A7EhwZ3KN0dqm8DRBK8YdZByU+7gCLpEH=aBuMEvpGcWA@mail.gmail.com>
Message-ID: <CAKFCL4X+2=GKyfWFD9e75K4r=Nf1wRtwWjRCrd4_meRFAk+9KA@mail.gmail.com>

On Fri, Nov 7, 2014 at 3:26 PM, George Colpitts <george.colpitts at gmail.com>
wrote:

> <command line>: can't load .so/.DLL for:
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib
> (dlopen(/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib,
> 9): no suitable image found.  Did find:
>
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib:
> mach-o, but wrong filetype)
>

I'm afraid to ask how you managed that.

    pyanfar:3380 Z$ file
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib:
Mach-O universal binary with 2 architectures

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib
(for architecture x86_64): Mach-O 64-bit dynamically linked shared library
stub x86_64

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib
(for architecture i386): Mach-O dynamically linked shared library stub i386


Do you somehow have ARM or PPC objects lying around? (Granted, I am on 10.9
still; I am upgrading a machine to 10.10 but may not have a Haskell
environment on it for a bit.)

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141107/44e9c6da/attachment.html>

From allbery.b at gmail.com  Fri Nov  7 20:43:02 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Fri, 7 Nov 2014 15:43:02 -0500
Subject: Is anybody able to build HEAD on Mac with Yosemite wtih Xcode 6.1
 and GHC 7.8.3
In-Reply-To: <CAKFCL4X+2=GKyfWFD9e75K4r=Nf1wRtwWjRCrd4_meRFAk+9KA@mail.gmail.com>
References: <CAB-d4A7EhwZ3KN0dqm8DRBK8YdZByU+7gCLpEH=aBuMEvpGcWA@mail.gmail.com>
 <CAKFCL4X+2=GKyfWFD9e75K4r=Nf1wRtwWjRCrd4_meRFAk+9KA@mail.gmail.com>
Message-ID: <CAKFCL4VU31XFUC58rOC9HEaRLaR6pV49JM1LLwSvcYGtshpe9g@mail.gmail.com>

On Fri, Nov 7, 2014 at 3:39 PM, Brandon Allbery <allbery.b at gmail.com> wrote:

>
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib
> (for architecture x86_64): Mach-O 64-bit dynamically linked shared library
> stub x86_64
>

On second thought... "shared library stub"? What's Apple up to now? This
may well be the problem; they don't actually contain anything except
symbols. (But again, this may be because I'm still on 10.9.)

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141107/15e5b923/attachment.html>

From austin at well-typed.com  Fri Nov  7 21:35:38 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 7 Nov 2014 15:35:38 -0600
Subject: 7.10 STABLE freeze date
Message-ID: <CAEs96n0g-nNfxuU-RPbruj7GTfKT3p2qwJ+1_UK2RLAZgBhH+Q@mail.gmail.com>

Hi all,

After some deliberation, we've decided that the STABLE freeze for 7.10
will happen in approximately two weeks, on November 21st. We're hoping
to stick to this date closely, but do read below.

This is perhaps a short time to freeze, but right now, we've only got
a couple things we're planning on focusing on for the next few weeks.
And these are really the major things we're waiting for. See below:

 - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1

These are just:

 - D155, LLVM 3.5 compatibility,
 - D396 and D169, DWARF/source code note work. These are mostly in me
and Simon's court to do another review round, but I think will be OK
to get them in on time.
 - D168, Partial type signatures. The ball is in Simon's court on this
one, but he's had several good rounds of discussion with Thomas etc
from what I understand.

Based on our discussions earlier this week, I think these all will
make it just in time for the freeze.

Nota bene: if there is *any* delay, it will be for these, as we picked
them as the highest priority in our own views. It is unlikely we will
delay any so people can sneak in a few other things. So, if you want
something of yours in, you better get me, Simon & Simon, Herbert,
etc's attention pronto! That way we'll have time to get it in first.

To make things easier, we'll also be pushing the lhs->hs conversion
pretty soon so cherry picking/merges are easier, and do some other
cleanups.

And outside of that, we've still been having a healthy flow of bug
fixes falling into the tree, which is great. So if you're just
bugfixing, please keep doing so - we'll be pulling bugfixes into the
tree continuously.

We will also be pulling in submodule/library updates continuously,
like we did for the 7.8 branch.

Let me know if you have questions, objections, or really really really
want something - but I won't be as nice as last time I'm afraid. ;)

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From austin at well-typed.com  Fri Nov  7 21:37:43 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 7 Nov 2014 15:37:43 -0600
Subject: Reviving the LTS Discussions (ALT: A separate LTS branch)
Message-ID: <CAEs96n1WZymn5WsW4Qc5XMNC=+DSvzFK_2wVN9ZTUFNSAkdRzw@mail.gmail.com>

Hi *,

I want to draw attention to a topic that's come up a few times before,
spurred by discussion a few weeks ago by John Lato, and more
frequently (in other forms) by people like Gintautaus, with people
taking more mindshare in merging and getting patches and features
flowing.

The basic problem boils down to: what do we do about long term
releases for GHC, how can we manage them, and what sort of effort
would be required to maintain something like that?

The problem with GHC has always been one of time allocation for
humans. And we're really aggressive about fixing problems and
addressing things, with frequent updates and improvements to lots of
our core features.

That's fantastic! I am constantly amazed that despite almost all of
our contributions being major volunteer work. But that comes as a cost
in other ways:

  1) We have very little resources dedicated to maintaining things
like a long term branch. I certainly cannot do it alone while having
enough time to sensibly manage everything else I do.

  2) High rates of churn often 'leave people in the dust'. When you
refactor a big ball of code, and you improve it, you often don't want
to think about the old ball of code. And having to remember the old
ball of code from 6 months ago can be a significant undertaking, even
for the best of us.

  3) High rates of churn can introduce new bugs. While in my personal
and professional experience I think Haskell is exceptional at
preventing bugs, and we have lots of tests for GHC to catch
regressions, we can often break things. The rate of this is not clear
because it's got a significant amount of variables attached.

1 and 3 hurt users. 2 hurts developers. All of them are unfortunate.
There are a lot of these kinds of issues in various forms but the
specifics can be discussed later.

So what does this have to do with John's email he sent me.

Well, he had a helpful idea that's been picked up by most other
people: we should have a separated stable team that deals with longer
term maintenance.

The pattern of a separated stable/longterm team is actually one that's
common in a lot of older and higher profile FOSS projects, where
people maintaining long term versions are dedicated developers, but
simply on a different schedule than others. It's just two teams on one
project: same goal, different priorities and needs.

The question is who's going to do it of course - but I'm hoping our
volunteer streak will kick in. :)

There are some advantages to this:

  1) We can pick a stable branch, and we can have a separated group of
people maintain it.

  2) Most developers workflows won't change in the majority of cases,
and we can keep on humming along.

  3) Users can have an 'endorsed' version that we delegate as a stable
compiler for a designated period of time, based on the LTS Team's
projections.

But there are still some more difficulties:

  1) We need to decide how to pick a LTS branch, and when. The current
release cycle *roughly speaking* dedicates about a year to each
release, while HEAD steams along. Do we turn each major release into
an LTS branch, and give it over to the LTS team, or do we only
consider every other release, or do we pick and choose?

  2) We need to define a scope of things an LTS branch would address.
For example, API stability, what kind of bugfixes we get in (simple
mitigations vs thorough fixes that may be more substantial).

  3) We probably need some policies on working conventions. For
example, using the bug tracker, how to assign people to bugs, and how
to make sure everyone is on the same page.

  4) We need to decide who's going to do what.

So, to be clear, I would suggest having a separate group of committers
who can follow a designated long term branch, and maintain it. These
people do not necessarily need to contribute upstream features or
massive things, but do need to show pretty clear commitment and
stewardship. I think if we start this, we'll have to sort of do self
nominations the first time, since there may be
new-but-interested-GHC-hackers who might want to help.

Beyond that, as mentioned above, we need to define scope, and some
technical procedures. But this can all be hashed over VoIP, the lists,
etc etc.

I've tried to think up a good start to this conversation, and I think
John's suggestion is a good one - so I'm eager to see where it goes
this time.

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From ezyang at mit.edu  Fri Nov  7 22:05:15 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Fri, 07 Nov 2014 14:05:15 -0800
Subject: 7.10 STABLE freeze date
In-Reply-To: <CAEs96n0g-nNfxuU-RPbruj7GTfKT3p2qwJ+1_UK2RLAZgBhH+Q@mail.gmail.com>
References: <CAEs96n0g-nNfxuU-RPbruj7GTfKT3p2qwJ+1_UK2RLAZgBhH+Q@mail.gmail.com>
Message-ID: <1415397804-sup-4779@sabre>

Hey Austin,

Simon and I have been talking about fixing #8427
(https://ghc.haskell.org/trac/ghc/ticket/8427), but our
current plan of action will involve interface file changes
at least and maybe some invasive changes. A heads up!

Edward

Excerpts from Austin Seipp's message of 2014-11-07 13:35:38 -0800:
> Hi all,
> 
> After some deliberation, we've decided that the STABLE freeze for 7.10
> will happen in approximately two weeks, on November 21st. We're hoping
> to stick to this date closely, but do read below.
> 
> This is perhaps a short time to freeze, but right now, we've only got
> a couple things we're planning on focusing on for the next few weeks.
> And these are really the major things we're waiting for. See below:
> 
>  - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1
> 
> These are just:
> 
>  - D155, LLVM 3.5 compatibility,
>  - D396 and D169, DWARF/source code note work. These are mostly in me
> and Simon's court to do another review round, but I think will be OK
> to get them in on time.
>  - D168, Partial type signatures. The ball is in Simon's court on this
> one, but he's had several good rounds of discussion with Thomas etc
> from what I understand.
> 
> Based on our discussions earlier this week, I think these all will
> make it just in time for the freeze.
> 
> Nota bene: if there is *any* delay, it will be for these, as we picked
> them as the highest priority in our own views. It is unlikely we will
> delay any so people can sneak in a few other things. So, if you want
> something of yours in, you better get me, Simon & Simon, Herbert,
> etc's attention pronto! That way we'll have time to get it in first.
> 
> To make things easier, we'll also be pushing the lhs->hs conversion
> pretty soon so cherry picking/merges are easier, and do some other
> cleanups.
> 
> And outside of that, we've still been having a healthy flow of bug
> fixes falling into the tree, which is great. So if you're just
> bugfixing, please keep doing so - we'll be pulling bugfixes into the
> tree continuously.
> 
> We will also be pulling in submodule/library updates continuously,
> like we did for the 7.8 branch.
> 
> Let me know if you have questions, objections, or really really really
> want something - but I won't be as nice as last time I'm afraid. ;)
> 

From austin at well-typed.com  Fri Nov  7 22:07:44 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 7 Nov 2014 16:07:44 -0600
Subject: GHC Weekly News - 2014/11/07
Message-ID: <CAEs96n3oiuEpDipm22Zj0ZN6wXtipG9JLAqJ8UF+pC=UYAL6mQ@mail.gmail.com>

Hello *,

It's that time again, so get ready for some good ol' fashion news
about your favorite compiler.

  - Austin announced the 7.10 STABLE freeze date earlier today, which
is two weeks from the time of this posting: November 21st, 2014. If
you're a developer and have a feature you want, you'd better get it
reviewed and checked soon!
https://www.haskell.org/pipermail/ghc-devs/2014-November/007206.html
  - Austin also opened a discussion about a possible LTS branch for
GHC, spawned off from a suggestion by John Lato a few weeks email.
This discussion has been brought up several times before this, but for
the most part has fizzled out a bit. But maybe with a different focus
- on a separate branch with a team of maintainers - we can hash out a
plan of action, and just give it a whirl.
https://www.haskell.org/pipermail/ghc-devs/2014-November/007207.html
  - This past week, Simon PJ, Austin, Gintautas Miliauskas, and
several others met over a video chat to discuss the future of windows
builds. And it went pretty well! We've scribed up some notes, and sort
of laid out what we think will be happening for Windows in the near
future. https://www.haskell.org/pipermail/ghc-devs/2014-October/006897.html
  - Gergo Erdi opened up an RFC about type signatures for pattern
synonyms, which is one of the last pieces of the pattern synonyms
implementation we've been missing.
https://www.haskell.org/pipermail/ghc-devs/2014-November/007066.html
  - Simon PJ pushed a major overhaul of the constraint solver, just in
time for GHC 7.10. This was the result of a few months of work that
Simon has been glad to get off his plate, and hopefully should make
the type checker faster, leaner, and more modular (as usual).
  - Jan Stolarek talked about his planned improvements to the users
guide, which is ticket #9358. Hopefully for 7.10 the resulting
documentation will be *much* more clear and up to date.
https://www.haskell.org/pipermail/ghc-devs/2014-November/007169.html
  - Alan Zimmerman has got some more patches up for adding annotations
to the GHC Abstract Syntax Tree (AST). The hope is this new
representation will make it much easier for tools to enrich the AST
with their own custom metadata. Alan has been working on this for
several weeks now, so a good review is in order!
https://www.haskell.org/pipermail/ghc-devs/2014-November/007133.html
  - Mateusz Lenik, a new contributor, has discussed improving the
'Ticky Ticky' profiling code and resurrecting some of the older
features; luckily Jan inspired this work and had some comments. Thanks
Mateusz! https://www.haskell.org/pipermail/ghc-devs/2014-November/007078.html
  - Alexander Berntsen asked an question about abstracting over
constraints in GHC. Richard replied, but it seems this work might be
quite difficult!
https://www.haskell.org/pipermail/ghc-devs/2014-November/007165.html
  - Austin Seipp brought up a question about Windows support: can we
officially drop support for XP, now that Microsoft has done the same?
And what minimum version requirements should we endorse? Vista or
Windows 7 would give improvements due to API improvements, with
Windows 7 offering even more. If you're a GHC on Windows user, please
let us know! https://www.haskell.org/pipermail/ghc-devs/2014-November/007199.html

And this weeks closed tickets include quite a long list, thanks to
everyone cleaning up the bug tracker: #9747, #9236, #9753, #9752,
#9262, #8953, #9084, #9738, #8571, #8295, #8261, #9754, #110, #9345,
#8849, #8819, #9658, #8960, #9395, #9705, #9433, #9633, #9359, #9081,
#8482, #3376, #9712, #9739, #9211, #9728, #9750, #9768, #9773, #9741,
#9284, #9774, #9771, #9001, #8626, #8986, #9268, #8975, #8962, #8921,
#8089, #8843, #8829, #9295, #7913, #2528, #9779.

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From gershomb at gmail.com  Sat Nov  8 00:19:59 2014
From: gershomb at gmail.com (Gershom B)
Date: Fri, 7 Nov 2014 19:19:59 -0500
Subject: RFC: Dropping Windows XP support
In-Reply-To: <CAEs96n25Bf2eDCn+dNMHCgKHPQ03F6kZXFBfzEuAacR6rojpBw@mail.gmail.com>
References: <CAEs96n25Bf2eDCn+dNMHCgKHPQ03F6kZXFBfzEuAacR6rojpBw@mail.gmail.com>
Message-ID: <etPan.545d61be.2ae8944a.5d3c@mbp.local>

One concern here is that even with XP falling out of support, Windows Server 2003 remains supported through July 2015, and so we should give it a little chunk of time after that falls out of support from Microsoft before we stop supporting that. I think the limitations in Server 2003 are roughly the same as XP.

http://www.microsoft.com/en-us/server-cloud/products/windows-server-2003/

However, the next Windows Server (2008) should share all Vista features.

Cheers,
Gershom


On November 7, 2014 at 1:16:39 PM, Austin Seipp (austin at well-typed.com) wrote:
> Hi all,
> 
> This is a quick discussion about the current system requirements for
> Windows builds.
> 
> Spurred by a recent[1] LLVM discussion, I'd like to raise the question
> of dropping support for Windows XP, and bumping the minimum required
> version to Windows Vista or even Windows 7.
> 
> For one, Microsoft doesn't support XP anymore, so most people are
> moving off it anyway. 'Soon' even XP Embedded will be obsoleted.
> 
> But second, Vista and beyond introduced useful new APIs we could use.
> I was digging through the LLVM thread and two came out to me:
> 
> 1) We could switch to using slim reader/writer locks, which in some
> workloads may work out better than critical sections (they'll win on
> more read-heavy workloads). The downsides is there's no recursive
> locking but we don't use that anyway (and recursive locks are
> considered bad by many anyway[2]).
> 
> 2) We could probably use an actual condition variables API that was
> introduced with Vista. Currently we use a giant EVENT object to
> emulate the API, which could be replaced with the real deal.
> 
> Both of these could be nice wins for simplicity and performance I think.
> 
> I know there are some corporate users out there who this may impact,
> and users as well. I'd like to know what people think. Particularly
> what version we should standardize on.
> 
> FWIW, I don't plan on changing any of this until the 7.12 release at least.
> 
> [1] http://article.gmane.org/gmane.comp.compilers.llvm.devel/78419
> [2] http://www.zaval.org/resources/library/butenhof1.html
> 
> --
> Regards,
> 
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 


From gergo at erdi.hu  Sat Nov  8 04:10:12 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Sat, 8 Nov 2014 12:10:12 +0800 (SGT)
Subject: 7.10 STABLE freeze date
In-Reply-To: <CAEs96n0g-nNfxuU-RPbruj7GTfKT3p2qwJ+1_UK2RLAZgBhH+Q@mail.gmail.com>
References: <CAEs96n0g-nNfxuU-RPbruj7GTfKT3p2qwJ+1_UK2RLAZgBhH+Q@mail.gmail.com>
Message-ID: <alpine.DEB.2.10.1411081152300.2047@galaxy>

On Fri, 7 Nov 2014, Austin Seipp wrote:

> And these are really the major things we're waiting for. See below:
>
> - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1
>
> These are just:
>
> - D155, LLVM 3.5 compatibility,
> - D396 and D169, DWARF/source code note work. These are mostly in me
> and Simon's court to do another review round, but I think will be OK
> to get them in on time.
> - D168, Partial type signatures. The ball is in Simon's court on this
> one, but he's had several good rounds of discussion with Thomas etc
> from what I understand.

Hi,

I'm almost done with implementing pattern synonym signatures (#8584): I 
have it fully working on my wip/T8584 branch, I just need to add some 
tests, and also come up with an acceptable syntax.

I also hope to finish fixing #9732 / #9783 over the next couple days.

Please let me know ASAP if there's anything more I'll need to do to get 
these into 7.10, because my schedule for working on GHC will be rather 
spotty for the next couple weeks.

Bye,
 	Gergo

From iavor.diatchki at gmail.com  Sat Nov  8 04:15:16 2014
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 7 Nov 2014 20:15:16 -0800
Subject: 7.10 STABLE freeze date
In-Reply-To: <alpine.DEB.2.10.1411081152300.2047@galaxy>
References: <CAEs96n0g-nNfxuU-RPbruj7GTfKT3p2qwJ+1_UK2RLAZgBhH+Q@mail.gmail.com>
 <alpine.DEB.2.10.1411081152300.2047@galaxy>
Message-ID: <CAGK9nuqPMrrtsPviR7UC6fT0prK0nWP-LTvgZgwxjZGi=WytPA@mail.gmail.com>

Hello,

I'd like to get the type-checker plugin code in 7.10.  I've been waiting
for Simon PJ to merge in his constraint solver changes in HEAD, which I
believe is very close to happening, and then I'll redo my work on top of
that.

-Iavor

On Fri, Nov 7, 2014 at 8:10 PM, Dr. ERDI Gergo <gergo at erdi.hu> wrote:

> On Fri, 7 Nov 2014, Austin Seipp wrote:
>
>  And these are really the major things we're waiting for. See below:
>>
>> - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1
>>
>> These are just:
>>
>> - D155, LLVM 3.5 compatibility,
>> - D396 and D169, DWARF/source code note work. These are mostly in me
>> and Simon's court to do another review round, but I think will be OK
>> to get them in on time.
>> - D168, Partial type signatures. The ball is in Simon's court on this
>> one, but he's had several good rounds of discussion with Thomas etc
>> from what I understand.
>>
>
> Hi,
>
> I'm almost done with implementing pattern synonym signatures (#8584): I
> have it fully working on my wip/T8584 branch, I just need to add some
> tests, and also come up with an acceptable syntax.
>
> I also hope to finish fixing #9732 / #9783 over the next couple days.
>
> Please let me know ASAP if there's anything more I'll need to do to get
> these into 7.10, because my schedule for working on GHC will be rather
> spotty for the next couple weeks.
>
> Bye,
>         Gergo
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141107/2f7fe708/attachment-0001.html>

From thomasmiedema at gmail.com  Sat Nov  8 04:30:24 2014
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Sat, 8 Nov 2014 05:30:24 +0100
Subject: 7.10 STABLE freeze date
In-Reply-To: <CAGK9nuqPMrrtsPviR7UC6fT0prK0nWP-LTvgZgwxjZGi=WytPA@mail.gmail.com>
References: <CAEs96n0g-nNfxuU-RPbruj7GTfKT3p2qwJ+1_UK2RLAZgBhH+Q@mail.gmail.com>
 <alpine.DEB.2.10.1411081152300.2047@galaxy>
 <CAGK9nuqPMrrtsPviR7UC6fT0prK0nWP-LTvgZgwxjZGi=WytPA@mail.gmail.com>
Message-ID: <CAD3WKgjh8Jq6+oTN4PZXpAxfKyo9dSfY8XqsQknHKnmt=aTwyA@mail.gmail.com>

On Sat, Nov 8, 2014 at 5:15 AM, Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> Hello,
>
> I'd like to get the type-checker plugin code in 7.10.  I've been waiting
> for Simon PJ to merge in his constraint solver changes in HEAD, which I
> believe is very close to happening, and then I'll redo my work on top of
> that.
>

Looks like you can start right away, see
http://git.haskell.org/ghc.git/commit/5770029a1f8509a673b2277287fc8fe90b9b6002
Aka "Simon's major commit to re-engineer the constraint solver"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141108/66e0132c/attachment.html>

From david.feuer at gmail.com  Sat Nov  8 07:45:29 2014
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 8 Nov 2014 02:45:29 -0500
Subject: Reviving the LTS Discussions (ALT: A separate LTS branch)
Message-ID: <CAMgWh9uz7CCEd78_JRRes2Xys6c0YbYz8uaHnLMtBBvdN71ncg@mail.gmail.com>

GHC is an open source project. People work on it because

1. They enjoy it and find it interesting,
2. They need it to work well to support their own software,
3. They're trying to write a paper/get a degree/impress their peers, or, in
very rare cases,
4. Someone pays them to do it.
People are also willing to do some kinds of minor maintenance work because
5. They feel a sense of obligation to the community
but this is not likely, on its own, to keep many people active.

What does this have to do with LTS releases? The fact is that having people
who want an LTS release does not necessarily mean that anyone else should
do much of anything about it. If they don't really care, they're likely to
half-build an LTS process and then get sidetracked.

So what do I think should be done about this? I think "GHC headquarters"
should make a standing offer to any person, group, or company interested in
producing an LTS release: an offer of Trac, and Phabricator, and
Harbormaster, and generally all the infrastructure that GHC already uses.
Also an offer of advice on how to manage releases, deal with common issues,
etc. But a promise of programming power seems likely to be an empty one,
and I don't see the point of trying to push it. If someone wants an LTS
release, they need to either make one themselves or pay someone to do the
job.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141108/67e7ff5f/attachment.html>

From lonetiger at gmail.com  Sat Nov  8 12:09:41 2014
From: lonetiger at gmail.com (Tamar Christina)
Date: Sat, 8 Nov 2014 04:09:41 -0800
Subject: RFC: Dropping Windows XP support
Message-ID: <9216333213896137374@unknownmsgid>

I don't think we should worry about windows server 2003. Unless I'm
mistaken the support Microsoft still provides is mostly maintenance.
The older version of GHC won't suddenly stop working on 2003, as such
all programs will continue to run just fine.

>From a development standpoint removing <= NT 5 support from would be
very beneficial. For those on the older platforms, they can use the
older GHCs, which I think is the policy most companies have taken
w.r.t. Xp/2003.

Regards,
TamarFrom: Gershom B
Sent: ?08/?11/?2014 01:20
To: Austin Seipp; ghc-devs at haskell.org;
glasgow-haskell-users at haskell.org
Subject: Re: RFC: Dropping Windows XP support
One concern here is that even with XP falling out of support, Windows
Server 2003 remains supported through July 2015, and so we should give
it a little chunk of time after that falls out of support from
Microsoft before we stop supporting that. I think the limitations in
Server 2003 are roughly the same as XP.

http://www.microsoft.com/en-us/server-cloud/products/windows-server-2003/

However, the next Windows Server (2008) should share all Vista features.

Cheers,
Gershom


On November 7, 2014 at 1:16:39 PM, Austin Seipp (austin at well-typed.com) wrote:
> Hi all,
>
> This is a quick discussion about the current system requirements for
> Windows builds.
>
> Spurred by a recent[1] LLVM discussion, I'd like to raise the question
> of dropping support for Windows XP, and bumping the minimum required
> version to Windows Vista or even Windows 7.
>
> For one, Microsoft doesn't support XP anymore, so most people are
> moving off it anyway. 'Soon' even XP Embedded will be obsoleted.
>
> But second, Vista and beyond introduced useful new APIs we could use.
> I was digging through the LLVM thread and two came out to me:
>
> 1) We could switch to using slim reader/writer locks, which in some
> workloads may work out better than critical sections (they'll win on
> more read-heavy workloads). The downsides is there's no recursive
> locking but we don't use that anyway (and recursive locks are
> considered bad by many anyway[2]).
>
> 2) We could probably use an actual condition variables API that was
> introduced with Vista. Currently we use a giant EVENT object to
> emulate the API, which could be replaced with the real deal.
>
> Both of these could be nice wins for simplicity and performance I think.
>
> I know there are some corporate users out there who this may impact,
> and users as well. I'd like to know what people think. Particularly
> what version we should standardize on.
>
> FWIW, I don't plan on changing any of this until the 7.12 release at least.
>
> [1] http://article.gmane.org/gmane.comp.compilers.llvm.devel/78419
> [2] http://www.zaval.org/resources/library/butenhof1.html
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

From gergo at erdi.hu  Sat Nov  8 14:02:42 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Sat, 8 Nov 2014 22:02:42 +0800 (SGT)
Subject: let/app invariant violated by code generated with mkCoreApp
Message-ID: <alpine.DEB.2.10.1411082154270.2047@galaxy>

Hi,

I'm trying to attach (f Void#) as a compulsory unfolding to an Id. Here's 
what I tried originally:

     let unfolding = mkCoreApp (Var worker_id) (Var voidPrimId)
         wrapper_id' = setIdUnfolding wrapper_id $ mkCompulsoryUnfolding unfolding

However, when I try to use wrapper_id' in the desugarer, the Core linter 
looks at me strange. This is the original Core:

f :: Int
[LclIdX, Str=DmdType]
f = break<1>() GHC.Types.I# Main.$WPAT

and this is the error message ($WPAT is the wrapper_id', PAT is the 
worker_id in this example)

<no location info>: Warning:
     In the expression: I# (PAT void#)
     This argument does not satisfy the let/app invariant: PAT void#

Now, I thought I'd make sure mkCoreApp generated correct Core by writing 
it out by hand:

     let unfolding = Case (Var voidPrimId) voidArgId pat_ty [(DEFAULT,[],App (Var worker_id) (Var voidArgId))]

however, bizarrely, this *still* results in *the same* error message, as 
if something was transforming it back to a straight App.

Anyone have any hints what I'm doing wrong here?

Bye,
 	Gergo

-- 

   .--= ULLA! =-----------------.
    \     http://gergo.erdi.hu   \
     `---= gergo at erdi.hu =-------'
You are in a twisty maze of little install diskettes.

From gergo at erdi.hu  Sat Nov  8 16:23:02 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Sun, 9 Nov 2014 00:23:02 +0800 (SGT)
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <alpine.DEB.2.10.1411090008180.2047@galaxy>

Just a small note about parsing:

On Tue, 4 Nov 2014, Simon Peyton Jones wrote:

> The more I think about this, the more I think we'll just have to bite 
> the bullet and adapt the syntax for constraints in pattern types, to 
> distinguish the match-required and match-provided parts. Suppose we let 
> pattern signatures look like this:
>
>  pattern P :: forall tvs. (match-provided ; match-required) => tau
>
> The "; match-required" part is optional, and the "match-provided" part 
> might be empty.  So P1 and P2 would look like this:
>
>  pattern P1 :: forall a. (; Num a) => b -> (a,b)
>  pattern P2 :: forall a. (; Num a, Ord a) => a -> a
>
> Because the "match-required" part is optional (and relatively rare) the 
> common case looks just like an ordinary data constructor.

One thing worth noting is that implementing a parser for this would be far 
from straightforward, because currently contexts are parsed as types and 
then fixed up into contexts:

-- We parse a context as a btype so that we don't get reduce/reduce
-- errors in ctype.  The basic problem is that
--      (Eq a, Ord a)
-- looks so much like a tuple type.  We can't tell until we find the =>

So we would need to add a way of parsing (T1, T2, ..., Tn; U1, U2, ..., Um)
into a type, which would then require rejecting everywhere else where 
we really do mean a type... Sounds painful. Also painful: rewriting the 
whole context parsing code :/

Richard's suggestion:

> pattern type forall a. Num a => P :: forall c. (Eq a, Ord Bool, Show c) =>
>   c -> Bool -> T a Bool

has the nice property (unlike the current horrible syntax) that the 
foralls close left-to-right; also, it is very easy to parse :)

I'm hoping to see some more suggestions or general comments!

Bye,
 	Gergo

From howard_b_golden at yahoo.com  Sat Nov  8 19:32:17 2014
From: howard_b_golden at yahoo.com (Howard B. Golden)
Date: Sat, 8 Nov 2014 19:32:17 +0000 (UTC)
Subject: Fw: Long term support - in general and Windows XP specifically
In-Reply-To: <1352995615.41061.1415473015324.JavaMail.yahoo@jws10093.mail.ne1.yahoo.com>
References: <CAEs96n3oiuEpDipm22Zj0ZN6wXtipG9JLAqJ8UF+pC=UYAL6mQ@mail.gmail.com>
 <1352995615.41061.1415473015324.JavaMail.yahoo@jws10093.mail.ne1.yahoo.com>
Message-ID: <166829581.44041.1415475137332.JavaMail.yahoo@jws10065.mail.ne1.yahoo.com>

Hi,


I am combining the two topics because the issues are both support-related.

First, long term support (LTS) is an important goal in making GHC/Haskell a viable production platform. I would argue that providing it is a necessary condition to encourage more adoption of Haskell by "plain users" (as opposed to those willing to take more risks). This includes both individuals and organizations. I believe this makes LTS a high priority for the community.

LTS requires support of both GHC and stable libraries. Any plan for LTS must incorporate a plan for identifying libraries to keep supporting for the same period. This must be part of the effort. FP Complete's Stackage is one approach.

Practically, each LTS version requires significant maintainer resources. Therefore, there is a tension between how many versions to support, how long to support them, and how much demand there will be for new features. The developers need to get a sense of how much value the "plain user" will get from a new release versus bug fixes and backports to an LTS release. As a thought experiment (and perhaps a survey of users), how many users are content with GHC 7.4, 7.6 and 7.8, or even earlier releases? Will they clamor for the new features in 7.10, or is this more aimed at those who are experimenting or are willing to take greater risk? What is the current demographic of users/GHC release usage? Based on the results of this study, we'll have a better idea of what release to make the first LTS one. I would suggest starting with a prior release based on what is being used now. For example, find out how many users are using 7.4 and ask what difficulties they would have in adopting 7.6. Try to get a sense of what the first LTS release should be, recognizing that you won't get unanimous agreement.

I am an interested observer, not an active developer, so take my comments with this in mind. I wonder if the release of 7.10 is being rushed. Perhaps once a year releases are too frequent for everyone except the bleeding edge, who may be satisfied with snapshots. Maybe a reallocation of developer effort should be considered. This question deserves to be considered even if it is ultimately discarded.

The issue of Windows XP support should be considered using a similar approach. If an LTS release is created with Windows XP support, this should satisfy XP users for a period of time. It could then be discussed when XP support would no longer be part of a later version. I don't know what API differences there are between XP and Vista or Window 7 that impact GHC. Do the newer APIs provide a significant benefit that justifies dropping XP support? Could newer features be used only where essential, so degraded XP support can be maintained longer?

I hope my perspective is of value to the developers.

Regards,

Howard
Northridge, CA, USA



----- Original Message -----
From: Austin Seipp <austin at well-typed.com>
To: "ghc-devs at haskell.org" <ghc-devs at haskell.org>
Cc: 

Sent: Friday, November 7, 2014 2:07 PM
Subject: GHC Weekly News - 2014/11/07


[Excerpt]
  - Austin also opened a discussion about a possible LTS branch for
GHC, spawned off from a suggestion by John Lato a few weeks email.
This discussion has been brought up several times before this, but for
the most part has fizzled out a bit. But maybe with a different focus
- on a separate branch with a team of maintainers - we can hash out a
plan of action, and just give it a whirl.
https://www.haskell.org/pipermail/ghc-devs/2014-November/007207.html
  - Austin Seipp brought up a question about Windows support: can we
officially drop support for XP, now that Microsoft has done the same?
And what minimum version requirements should we endorse? Vista or
Windows 7 would give improvements due to API improvements, with
Windows 7 offering even more. If you're a GHC on Windows user, please
let us know! https://www.haskell.org/pipermail/ghc-devs/2014-November/007199.html

From marlowsd at gmail.com  Sat Nov  8 21:25:16 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Sat, 08 Nov 2014 21:25:16 +0000
Subject: Wiki: special namespace for proposals?
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F337066@DB3PRD3001MB020.064d.mgd.msft.net>
References: <1413324772.2582.3.camel@gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F337066@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <545E8A3C.2050900@gmail.com>

On 15/10/14 09:37, Simon Peyton Jones wrote:
> I think that would be a fine idea, but it's always hard
> - pages change their status (a proposal becomes part of GHC)
> - a page may "belong" in multiple places
> - people keep URLs in bookmarks, and they are linked from other pages in Trac
>    so moving pages is painful.
>
> The last is significant.  Do we leave "this page has moved" stub pages (i.e. still cluttering the TitleIndex).  Or do we move them, and live with dead links.   I'm very un-keen on dead links in Trac itself.  Maybe there is some way to rewrite all of those, at least?

You can leave indirections in place in Trac, like this:

[[redirect(wiki:Building/Preparation/Windows)]]

I've done this a few times when I moved pages to better organise things. 
  I agree that it does leave some clutter in TitleIndex, that's 
unfortunate, but I think it's worth it to have good organisation.

Cheers,
Simon


> I don't have a strong opinion here
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> |  Yuras Shumovich
> |  Sent: 14 October 2014 23:13
> |  To: ghc-devs at haskell.org Devs
> |  Subject: Wiki: special namespace for proposals?
> |
> |
> |  Hello,
> |
> |  Would it be better to organize proposals under one namespace? Right
> |  now they belongs to root namespace, so title index (
> |  https://ghc.haskell.org/trac/ghc/wiki/TitleIndex ) is hard to use.
> |
> |  I was going to start new page describing language extension, but I
> |  don't want do increase entropy even more. What about creating special
> |  namespace, e.g. "Proposals"? Probably makes sense to divide if
> |  farther?
> |
> |  Thanks,
> |  Yuras
> |
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  http://www.haskell.org/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>


From iavor.diatchki at gmail.com  Sat Nov  8 22:30:16 2014
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sat, 8 Nov 2014 14:30:16 -0800
Subject: Question about `validate` workflow
Message-ID: <CAGK9nupggcBHDe-bEcHMHbY0B=ge9wZAj_Wp3ZTUrLBxTtgqsg@mail.gmail.com>

Hello,

I was wondering how do other devs `validate` their tree?  In particular, I
just merged a whole bunch of stuff and am validating things.  However,
every time something goes wrong (e.g., unused import warning), the whole
process starts from the beginning, which is quite time consuming.

I am using CPUS=4 ./validate --fast

Can I do something, to "validate continue", at least until I get a basic
validate to pass?  I don't mind redoing everything one final time to make
sure things are OK, it is just that it seems wasteful while I am fixing
things.

-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141108/23f4a579/attachment.html>

From thomasmiedema at gmail.com  Sat Nov  8 22:35:27 2014
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Sat, 8 Nov 2014 23:35:27 +0100
Subject: Question about `validate` workflow
In-Reply-To: <CAGK9nupggcBHDe-bEcHMHbY0B=ge9wZAj_Wp3ZTUrLBxTtgqsg@mail.gmail.com>
References: <CAGK9nupggcBHDe-bEcHMHbY0B=ge9wZAj_Wp3ZTUrLBxTtgqsg@mail.gmail.com>
Message-ID: <CAD3WKgiifYk8L_KA4Ozvk_XrJrbUwzZ8hLcJWQGytGMyc_+Kyg@mail.gmail.com>

>
> I was wondering how do other devs `validate` their tree?  In particular, I
> just merged a whole bunch of stuff and am validating things.  However,
> every time something goes wrong (e.g., unused import warning), the whole
> process starts from the beginning, which is quite time consuming.
>


$ ./validate --help
...
--no-clean        don't make clean first, just carry on from
                     a previous interrupted validation run
...

I don't know if it works!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141108/6532a8f7/attachment-0001.html>

From fuuzetsu at fuuzetsu.co.uk  Sat Nov  8 23:33:04 2014
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Sat, 08 Nov 2014 23:33:04 +0000
Subject: Fw: Long term support - in general and Windows XP specifically
In-Reply-To: <166829581.44041.1415475137332.JavaMail.yahoo@jws10065.mail.ne1.yahoo.com>
References: <CAEs96n3oiuEpDipm22Zj0ZN6wXtipG9JLAqJ8UF+pC=UYAL6mQ@mail.gmail.com>
 <1352995615.41061.1415473015324.JavaMail.yahoo@jws10093.mail.ne1.yahoo.com>
 <166829581.44041.1415475137332.JavaMail.yahoo@jws10065.mail.ne1.yahoo.com>
Message-ID: <545EA830.2040502@fuuzetsu.co.uk>

On 11/08/2014 07:32 PM, Howard B. Golden wrote:
> Hi,
> 
> 
> I am combining the two topics because the issues are both
> support-related.
> 
> First, long term support (LTS) is an important goal in making
> GHC/Haskell a viable production platform. I would argue that
> providing it is a necessary condition to encourage more adoption of
> Haskell by "plain users" (as opposed to those willing to take more
> risks). This includes both individuals and organizations. I believe
> this makes LTS a high priority for the community.
> 
> LTS requires support of both GHC and stable libraries. Any plan for
> LTS must incorporate a plan for identifying libraries to keep
> supporting for the same period. This must be part of the effort. FP
> Complete's Stackage is one approach.
> 
> Practically, each LTS version requires significant maintainer
> resources. Therefore, there is a tension between how many versions to
> support, how long to support them, and how much demand there will be
> for new features. The developers need to get a sense of how much
> value the "plain user" will get from a new release versus bug fixes
> and backports to an LTS release. As a thought experiment (and perhaps
> a survey of users), how many users are content with GHC 7.4, 7.6 and
> 7.8, or even earlier releases? Will they clamor for the new features
> in 7.10, or is this more aimed at those who are experimenting or are
> willing to take greater risk? What is the current demographic of
> users/GHC release usage? Based on the results of this study, we'll
> have a better idea of what release to make the first LTS one. I would
> suggest starting with a prior release based on what is being used
> now. For example, find out how many users are using 7.4 and ask what
> difficulties they would have in adopting 7.6. Try to get a sense of
> what the first LTS release should be, recognizing that you won't get
> unanimous agreement.
> 
> I am an interested observer, not an active developer, so take my
> comments with this in mind. I wonder if the release of 7.10 is being
> rushed. Perhaps once a year releases are too frequent for everyone
> except the bleeding edge, who may be satisfied with snapshots. Maybe
> a reallocation of developer effort should be considered. This
> question deserves to be considered even if it is ultimately
> discarded.

If organisations care then they should voice their thoughts *and*
provide some developer effort to make the backports. Delaying new
releases and pulling off volunteers to do soul-crushing fix backporting
because it might, just might, make it easier for some business out there
to achieve something is silly. No one wants to put their free time into
porting stuff years back especially if it might not even matter.

> The issue of Windows XP support should be considered using a similar
> approach. If an LTS release is created with Windows XP support, this
> should satisfy XP users for a period of time. It could then be
> discussed when XP support would no longer be part of a later version.
> I don't know what API differences there are between XP and Vista or
> Window 7 that impact GHC. Do the newer APIs provide a significant
> benefit that justifies dropping XP support? Could newer features be
> used only where essential, so degraded XP support can be maintained
> longer?

XP came out in 2001. There's LTS and then there's 13 year old OS that's
after EOL from its own developer.

> I hope my perspective is of value to the developers.
> 
> Regards,
> 
> Howard Northridge, CA, USA
> 
> 
> 
> ----- Original Message ----- From: Austin Seipp
> <austin at well-typed.com> To: "ghc-devs at haskell.org"
> <ghc-devs at haskell.org> Cc:
> 
> Sent: Friday, November 7, 2014 2:07 PM Subject: GHC Weekly News -
> 2014/11/07
> 
> 
> [Excerpt] - Austin also opened a discussion about a possible LTS
> branch for GHC, spawned off from a suggestion by John Lato a few
> weeks email. This discussion has been brought up several times before
> this, but for the most part has fizzled out a bit. But maybe with a
> different focus - on a separate branch with a team of maintainers -
> we can hash out a plan of action, and just give it a whirl. 
> https://www.haskell.org/pipermail/ghc-devs/2014-November/007207.html 
> - Austin Seipp brought up a question about Windows support: can we 
> officially drop support for XP, now that Microsoft has done the
> same? And what minimum version requirements should we endorse? Vista
> or Windows 7 would give improvements due to API improvements, with 
> Windows 7 offering even more. If you're a GHC on Windows user,
> please let us know!
> https://www.haskell.org/pipermail/ghc-devs/2014-November/007199.html 
> _______________________________________________ ghc-devs mailing
> list ghc-devs at haskell.org 
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 


-- 
Mateusz K.

From bheklilr2 at gmail.com  Sun Nov  9 00:05:38 2014
From: bheklilr2 at gmail.com (Aaron Stevens)
Date: Sat, 8 Nov 2014 18:05:38 -0600
Subject: Fw: Long term support - in general and Windows XP specifically
In-Reply-To: <545EA830.2040502@fuuzetsu.co.uk>
References: <CAEs96n3oiuEpDipm22Zj0ZN6wXtipG9JLAqJ8UF+pC=UYAL6mQ@mail.gmail.com>
 <1352995615.41061.1415473015324.JavaMail.yahoo@jws10093.mail.ne1.yahoo.com>
 <166829581.44041.1415475137332.JavaMail.yahoo@jws10065.mail.ne1.yahoo.com>
 <545EA830.2040502@fuuzetsu.co.uk>
Message-ID: <CAAbcvkK+Cd6hEj2hQuQcOm1_d6DPLZuOR9aS46-KX5JPtjfvTA@mail.gmail.com>

I'll chime in as a Windows developer and say that personally I won't ever
use anything older than W7 ever again. While my company doesn't use
Haskell, we've already switched 99% of our systems to W7 from XP with a few
exceptions for legacy systems that aren't even networked anymore. There
might be some company or user out there still stuck in the past, but I have
never run into them.

I think it's time to drop support for XP, particularly if it means
improvements for the overwhelming majority of Windows haskellers.
On Nov 8, 2014 5:33 PM, "Mateusz Kowalczyk" <fuuzetsu at fuuzetsu.co.uk> wrote:

> On 11/08/2014 07:32 PM, Howard B. Golden wrote:
> > Hi,
> >
> >
> > I am combining the two topics because the issues are both
> > support-related.
> >
> > First, long term support (LTS) is an important goal in making
> > GHC/Haskell a viable production platform. I would argue that
> > providing it is a necessary condition to encourage more adoption of
> > Haskell by "plain users" (as opposed to those willing to take more
> > risks). This includes both individuals and organizations. I believe
> > this makes LTS a high priority for the community.
> >
> > LTS requires support of both GHC and stable libraries. Any plan for
> > LTS must incorporate a plan for identifying libraries to keep
> > supporting for the same period. This must be part of the effort. FP
> > Complete's Stackage is one approach.
> >
> > Practically, each LTS version requires significant maintainer
> > resources. Therefore, there is a tension between how many versions to
> > support, how long to support them, and how much demand there will be
> > for new features. The developers need to get a sense of how much
> > value the "plain user" will get from a new release versus bug fixes
> > and backports to an LTS release. As a thought experiment (and perhaps
> > a survey of users), how many users are content with GHC 7.4, 7.6 and
> > 7.8, or even earlier releases? Will they clamor for the new features
> > in 7.10, or is this more aimed at those who are experimenting or are
> > willing to take greater risk? What is the current demographic of
> > users/GHC release usage? Based on the results of this study, we'll
> > have a better idea of what release to make the first LTS one. I would
> > suggest starting with a prior release based on what is being used
> > now. For example, find out how many users are using 7.4 and ask what
> > difficulties they would have in adopting 7.6. Try to get a sense of
> > what the first LTS release should be, recognizing that you won't get
> > unanimous agreement.
> >
> > I am an interested observer, not an active developer, so take my
> > comments with this in mind. I wonder if the release of 7.10 is being
> > rushed. Perhaps once a year releases are too frequent for everyone
> > except the bleeding edge, who may be satisfied with snapshots. Maybe
> > a reallocation of developer effort should be considered. This
> > question deserves to be considered even if it is ultimately
> > discarded.
>
> If organisations care then they should voice their thoughts *and*
> provide some developer effort to make the backports. Delaying new
> releases and pulling off volunteers to do soul-crushing fix backporting
> because it might, just might, make it easier for some business out there
> to achieve something is silly. No one wants to put their free time into
> porting stuff years back especially if it might not even matter.
>
> > The issue of Windows XP support should be considered using a similar
> > approach. If an LTS release is created with Windows XP support, this
> > should satisfy XP users for a period of time. It could then be
> > discussed when XP support would no longer be part of a later version.
> > I don't know what API differences there are between XP and Vista or
> > Window 7 that impact GHC. Do the newer APIs provide a significant
> > benefit that justifies dropping XP support? Could newer features be
> > used only where essential, so degraded XP support can be maintained
> > longer?
>
> XP came out in 2001. There's LTS and then there's 13 year old OS that's
> after EOL from its own developer.
>
> > I hope my perspective is of value to the developers.
> >
> > Regards,
> >
> > Howard Northridge, CA, USA
> >
> >
> >
> > ----- Original Message ----- From: Austin Seipp
> > <austin at well-typed.com> To: "ghc-devs at haskell.org"
> > <ghc-devs at haskell.org> Cc:
> >
> > Sent: Friday, November 7, 2014 2:07 PM Subject: GHC Weekly News -
> > 2014/11/07
> >
> >
> > [Excerpt] - Austin also opened a discussion about a possible LTS
> > branch for GHC, spawned off from a suggestion by John Lato a few
> > weeks email. This discussion has been brought up several times before
> > this, but for the most part has fizzled out a bit. But maybe with a
> > different focus - on a separate branch with a team of maintainers -
> > we can hash out a plan of action, and just give it a whirl.
> > https://www.haskell.org/pipermail/ghc-devs/2014-November/007207.html
> > - Austin Seipp brought up a question about Windows support: can we
> > officially drop support for XP, now that Microsoft has done the
> > same? And what minimum version requirements should we endorse? Vista
> > or Windows 7 would give improvements due to API improvements, with
> > Windows 7 offering even more. If you're a GHC on Windows user,
> > please let us know!
> > https://www.haskell.org/pipermail/ghc-devs/2014-November/007199.html
> > _______________________________________________ ghc-devs mailing
> > list ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
>
> --
> Mateusz K.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141108/e7363e44/attachment.html>

From lukexipd at gmail.com  Sun Nov  9 00:13:04 2014
From: lukexipd at gmail.com (Luke Iannini)
Date: Sun, 09 Nov 2014 00:13:04 +0000
Subject: 7.10 STABLE freeze date
References: <CAEs96n0g-nNfxuU-RPbruj7GTfKT3p2qwJ+1_UK2RLAZgBhH+Q@mail.gmail.com>
Message-ID: <CAGo83Ci6M3Qm8UQj3n8TJH1UL6qGCLNH+40iJ8XDQ50zrTDM2Q@mail.gmail.com>

Hello,

I've submitted a patch to finish the already-merged (but incomplete) ARM64
support that adds support for modern iOS devices

https://ghc.haskell.org/trac/ghc/ticket/7942

Best
Luke

(I've also submitted a patch to LLVM to add an ARM64 GHC calling convention
that is in review)
On Fri, Nov 7, 2014 at 1:35 PM Austin Seipp <austin at well-typed.com> wrote:

> Hi all,
>
> After some deliberation, we've decided that the STABLE freeze for 7.10
> will happen in approximately two weeks, on November 21st. We're hoping
> to stick to this date closely, but do read below.
>
> This is perhaps a short time to freeze, but right now, we've only got
> a couple things we're planning on focusing on for the next few weeks.
> And these are really the major things we're waiting for. See below:
>
>  - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1
>
> These are just:
>
>  - D155, LLVM 3.5 compatibility,
>  - D396 and D169, DWARF/source code note work. These are mostly in me
> and Simon's court to do another review round, but I think will be OK
> to get them in on time.
>  - D168, Partial type signatures. The ball is in Simon's court on this
> one, but he's had several good rounds of discussion with Thomas etc
> from what I understand.
>
> Based on our discussions earlier this week, I think these all will
> make it just in time for the freeze.
>
> Nota bene: if there is *any* delay, it will be for these, as we picked
> them as the highest priority in our own views. It is unlikely we will
> delay any so people can sneak in a few other things. So, if you want
> something of yours in, you better get me, Simon & Simon, Herbert,
> etc's attention pronto! That way we'll have time to get it in first.
>
> To make things easier, we'll also be pushing the lhs->hs conversion
> pretty soon so cherry picking/merges are easier, and do some other
> cleanups.
>
> And outside of that, we've still been having a healthy flow of bug
> fixes falling into the tree, which is great. So if you're just
> bugfixing, please keep doing so - we'll be pulling bugfixes into the
> tree continuously.
>
> We will also be pulling in submodule/library updates continuously,
> like we did for the 7.8 branch.
>
> Let me know if you have questions, objections, or really really really
> want something - but I won't be as nice as last time I'm afraid. ;)
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141109/ce476f52/attachment-0001.html>

From ezyang at mit.edu  Sun Nov  9 00:50:56 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Sat, 08 Nov 2014 16:50:56 -0800
Subject: Question about `validate` workflow
In-Reply-To: <CAD3WKgiifYk8L_KA4Ozvk_XrJrbUwzZ8hLcJWQGytGMyc_+Kyg@mail.gmail.com>
References: <CAGK9nupggcBHDe-bEcHMHbY0B=ge9wZAj_Wp3ZTUrLBxTtgqsg@mail.gmail.com>
 <CAD3WKgiifYk8L_KA4Ozvk_XrJrbUwzZ8hLcJWQGytGMyc_+Kyg@mail.gmail.com>
Message-ID: <1415494248-sup-1074@sabre>

It does work, and it's very useful.

Edward

Excerpts from Thomas Miedema's message of 2014-11-08 14:35:27 -0800:
> >
> > I was wondering how do other devs `validate` their tree?  In particular, I
> > just merged a whole bunch of stuff and am validating things.  However,
> > every time something goes wrong (e.g., unused import warning), the whole
> > process starts from the beginning, which is quite time consuming.
> >
> 
> 
> $ ./validate --help
> ...
> --no-clean        don't make clean first, just carry on from
>                      a previous interrupted validation run
> ...
> 
> I don't know if it works!

From eir at cis.upenn.edu  Sun Nov  9 02:46:59 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sat, 8 Nov 2014 21:46:59 -0500
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <alpine.DEB.2.10.1411090008180.2047@galaxy>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411090008180.2047@galaxy>
Message-ID: <DBF17F2A-3B01-4B54-B18F-8EE7C8E7CC74@cis.upenn.edu>


On Nov 8, 2014, at 11:23 AM, "Dr. ERDI Gergo" <gergo at erdi.hu> wrote:

> So we would need to add a way of parsing (T1, T2, ..., Tn; U1, U2, ..., Um)
> into a type, which would then require rejecting everywhere else where we really do mean a type... Sounds painful. Also painful: rewriting the whole context parsing code :/

I actually think this wouldn't be all that hard. The same parse-as-wrong-AST-node-and-then-fix-it-up-later trick happens in plenty of places, patterns (parsed as expressions) being one of the biggest. Harder than my proposal, probably, but I don't think it's terrible.

> 
> Richard's suggestion:
> 
>> pattern type forall a. Num a => P :: forall c. (Eq a, Ord Bool, Show c) =>
>>  c -> Bool -> T a Bool
> 
> has the nice property (unlike the current horrible syntax) that the foralls close left-to-right; also, it is very easy to parse :)

One slight infelicity of my syntax is that the `P` is buried.

I should also note that I intended the `forall`s to be optional. The universally-quantified variables would be those that appear in the result type. (I conjecture without proof that the free variables of the required constraints must be a subset of the free variables of the result type. I further conjecture that said proof is easy, but the neurons capable of producing said proof have the night off.) The existentially-quantified variables are the other ones.

Given that the `forall`s are optional and that required constraints are likely rare (I agree there), then the P does not get buried often.

My syntax has the felicity that, like Simon's, if we make a pattern synonym for a GADT constructor, without any funny business, the pattern type is the same as the GADT type. It also supports a reading that says, for the example P, "As long as we have Num a, then P has the type (...)", which is a correct reading of the type.

Richard


From eir at cis.upenn.edu  Sun Nov  9 03:33:16 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sat, 8 Nov 2014 22:33:16 -0500
Subject: Question about `validate` workflow
In-Reply-To: <1415494248-sup-1074@sabre>
References: <CAGK9nupggcBHDe-bEcHMHbY0B=ge9wZAj_Wp3ZTUrLBxTtgqsg@mail.gmail.com>
 <CAD3WKgiifYk8L_KA4Ozvk_XrJrbUwzZ8hLcJWQGytGMyc_+Kyg@mail.gmail.com>
 <1415494248-sup-1074@sabre>
Message-ID: <98551FA9-12CE-473C-8831-9EF4FEB0D26C@cis.upenn.edu>

I've stopped validating locally, allowing Travis to do it for me. If you use a `wip/...` branch and push to the main GHC repo, you can find build reports at travis-ci.org/ghc/ghc. Or, I'm sure if you clue Travis in, this can also work if you push to your own GitHub fork of GHC.

Admittedly, this is a bad workflow if you're expecting a bunch of extraneous-import failures (and such) during validation, but I just wanted to make sure you knew of this option.

Richard

On Nov 8, 2014, at 7:50 PM, "Edward Z. Yang" <ezyang at mit.edu> wrote:

> It does work, and it's very useful.
> 
> Edward
> 
> Excerpts from Thomas Miedema's message of 2014-11-08 14:35:27 -0800:
>>> 
>>> I was wondering how do other devs `validate` their tree?  In particular, I
>>> just merged a whole bunch of stuff and am validating things.  However,
>>> every time something goes wrong (e.g., unused import warning), the whole
>>> process starts from the beginning, which is quite time consuming.
>>> 
>> 
>> 
>> $ ./validate --help
>> ...
>> --no-clean        don't make clean first, just carry on from
>>                     a previous interrupted validation run
>> ...
>> 
>> I don't know if it works!
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From gergo at erdi.hu  Sun Nov  9 03:42:35 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Sun, 9 Nov 2014 11:42:35 +0800 (SGT)
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <DBF17F2A-3B01-4B54-B18F-8EE7C8E7CC74@cis.upenn.edu>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411090008180.2047@galaxy>
 <DBF17F2A-3B01-4B54-B18F-8EE7C8E7CC74@cis.upenn.edu>
Message-ID: <alpine.DEB.2.10.1411091139410.2047@galaxy>

On Sat, 8 Nov 2014, Richard Eisenberg wrote:

> On Nov 8, 2014, at 11:23 AM, "Dr. ERDI Gergo" <gergo at erdi.hu> wrote:
>
>> So we would need to add a way of parsing (T1, T2, ..., Tn; U1, U2, ..., 
>> Um) into a type, which would then require rejecting everywhere else 
>> where we really do mean a type... Sounds painful. Also painful: 
>> rewriting the whole context parsing code :/
>
> I actually think this wouldn't be all that hard. The same 
> parse-as-wrong-AST-node-and-then-fix-it-up-later trick happens in plenty 
> of places, patterns (parsed as expressions) being one of the biggest. 
> Harder than my proposal, probably, but I don't think it's terrible.

Right, but the issue in this case is if we add this artifical constructor 
to HsType just so we can fix it up into a pair of contexts, this 
constructor would permeate everything else that has to do with HsTypes; if 
nothing else, it'd need a `panic "foo: HsContextPair"` branch for all 
type-related renamer/typechecker functions.

Unless I'm missing some shortcut. I hope I do!

Bye,
 	Gergo

From eir at cis.upenn.edu  Sun Nov  9 04:02:43 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sat, 8 Nov 2014 23:02:43 -0500
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <alpine.DEB.2.10.1411091139410.2047@galaxy>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411090008180.2047@galaxy>
 <DBF17F2A-3B01-4B54-B18F-8EE7C8E7CC74@cis.upenn.edu>
 <alpine.DEB.2.10.1411091139410.2047@galaxy>
Message-ID: <49F6170A-CD48-4610-9F72-8E42C5B87A62@cis.upenn.edu>


On Nov 8, 2014, at 10:42 PM, "Dr. ERDI Gergo" <gergo at erdi.hu> wrote:

> Right, but the issue in this case is if we add this artifical constructor to HsType just so we can fix it up into a pair of contexts, this constructor would permeate everything else that has to do with HsTypes; if nothing else, it'd need a `panic "foo: HsContextPair"` branch for all type-related renamer/typechecker functions.
> 
> Unless I'm missing some shortcut. I hope I do!

No, you're right that you would have to do this, but this turns out to be the least of your worries -- takes 5 minutes. :) Now, if I could only predict what would be the *most* of your worries, I'd be a much more efficient programmer!

Richard

From gergo at erdi.hu  Sun Nov  9 04:30:49 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Sun, 9 Nov 2014 12:30:49 +0800 (SGT)
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <DBF17F2A-3B01-4B54-B18F-8EE7C8E7CC74@cis.upenn.edu>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411090008180.2047@galaxy>
 <DBF17F2A-3B01-4B54-B18F-8EE7C8E7CC74@cis.upenn.edu>
Message-ID: <alpine.DEB.2.10.1411091230250.2047@galaxy>

On Sat, 8 Nov 2014, Richard Eisenberg wrote:

> I should also note that I intended the `forall`s to be optional.

Of course, the forall binders are optional in all proposals.

From ml at isaac.cedarswampstudios.org  Sun Nov  9 05:03:55 2014
From: ml at isaac.cedarswampstudios.org (Isaac Dupree)
Date: Sun, 09 Nov 2014 00:03:55 -0500
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <545EF5BB.3050600@isaac.cedarswampstudios.org>

On 11/04/2014 05:32 AM, Simon Peyton Jones wrote:
> The "; match-required" part is optional, and the "match-provided" part might be empty.  So P1 and P2 would look like this:
> 
>   pattern P1 :: forall a. (; Num a) => b -> (a,b)
>   pattern P2 :: forall a. (; Num a, Ord a) => a -> a

How about marking the match-provided parts with a keyword, as so:

  pattern P2 :: (match_required Num a, match_required Ord a) => a -> a

Except with a better keyword. "if" might do in a pinch:

  pattern P2 :: forall a. (if Num a, if Ord a) => a -> a

or "pattern needed" (pattern being a keyword) or "pattern forall"

  pattern P2 :: (pattern needed Num a, pattern needed Ord a) => a -> a


From hvriedel at gmail.com  Sun Nov  9 07:11:58 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Sun, 09 Nov 2014 08:11:58 +0100
Subject: Fw: Long term support - in general and Windows XP specifically
In-Reply-To: <166829581.44041.1415475137332.JavaMail.yahoo@jws10065.mail.ne1.yahoo.com>
 (Howard B. Golden's message of "Sat, 8 Nov 2014 19:32:17 +0000 (UTC)")
References: <CAEs96n3oiuEpDipm22Zj0ZN6wXtipG9JLAqJ8UF+pC=UYAL6mQ@mail.gmail.com>
 <1352995615.41061.1415473015324.JavaMail.yahoo@jws10093.mail.ne1.yahoo.com>
 <166829581.44041.1415475137332.JavaMail.yahoo@jws10065.mail.ne1.yahoo.com>
Message-ID: <87ioioq24h.fsf@gmail.com>

On 2014-11-08 at 20:32:17 +0100, Howard B. Golden wrote:

[...]

> I am an interested observer, not an active developer, so take my
> comments with this in mind. I wonder if the release of 7.10 is being
> rushed. Perhaps once a year releases are too frequent for everyone
> except the bleeding edge, who may be satisfied with snapshots. Maybe a
> reallocation of developer effort should be considered. This question
> deserves to be considered even if it is ultimately discarded.

Fyi, last year there was already a discussion sub-thread debating a
change of GHC's yearly major release cycle over at

  http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/23425/focus=23451

IIRC, the conclusion was basically that a yearly cycle is a good
compromise balancing all needs/wishes involved.


IMO, since GHC gains so many new features/improvements every year
already, releasing less often would, for one, increase the amount of new
(potentially non-backward compatible changes) features contained in a
release, therefore increasing the work involved to update old code-bases
to a new GHC release[1], while at the same time give less opportunity to
get short release-feedback cycles (as Hackage developers probably only
take serious proper stable GHC releases (candidates), rather than
work-in-progress snapshots that are fast moving targets, potentially
exhibiting all sorts of transient bugs).

IOW, what I'm basically saying is that I'm a proponent of

 http://en.wikipedia.org/wiki/Release_early,_release_often




 [1]: An *extreme* example of what can happen if you accumulate too many
      changes into a new compiler/language release is the Python3
      situation, where it took ages for code-bases to get updated/ported
      from Python2 to Python3 (and it's still ongoing), as the upgrade
      path was too steep, while Python3 development was even slowed down
      for a few years by a self-imposed "Python Language Moratorium" to
      let Python3's adoption catch up.

Cheers,
  hvr

From gergo at erdi.hu  Sun Nov  9 07:56:24 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Sun, 9 Nov 2014 15:56:24 +0800 (SGT)
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <alpine.DEB.2.10.1411091554490.2047@galaxy>

On Tue, 4 Nov 2014, Simon Peyton Jones wrote:

>  pattern P :: forall tvs. (match-provided ; match-required) => tau
>
> The "; match-required" part is optional, and the "match-provided" part might be empty.  So P1 and P2 would look like this:
>
>  pattern P1 :: forall a. (; Num a) => b -> (a,b)
>  pattern P2 :: forall a. (; Num a, Ord a) => a -> a

Doesn't the ';' look a bit like something that could be incidentially 
introduced by some layout-aware syntax rule? Wouldn't, e.g., '|' be more 
explicit as a separator?

example:

pattern P :: forall tvs. (Eq b | Num a, Eq a) => b -> T a


From marlowsd at gmail.com  Sun Nov  9 08:40:16 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Sun, 09 Nov 2014 08:40:16 +0000
Subject: `arc` changes my commit messages
In-Reply-To: <CAK-tuPYV1_XxYZec-yGBLBPDmRbPVG85ioLOrT0uhFcPJGFqFQ@mail.gmail.com>
References: <3BD98820-35C9-42C1-9E2A-4666F394B68C@cis.upenn.edu>
 <CAK-tuPYV1_XxYZec-yGBLBPDmRbPVG85ioLOrT0uhFcPJGFqFQ@mail.gmail.com>
Message-ID: <545F2870.6040106@gmail.com>

A diff per commit is not that bad, this is my usual workflow.  Using 
'git rebase -i' and 'edit' you can amend individual commits in a stack. 
  The workflow is

  * git rebase -i <oldest commit in the stack>
  * 'edit' the commit you want to modify
  * modify away
  * arc diff
  * git commit --continue

Landing is a bit more tricky though.  'arc patch D1234 && arc land' is 
probably the easiest way, because you can't do arc land during a git rebase.

Cheers,
Simon

On 21/10/14 14:46, Johan Tibell wrote:
> This is probably the biggest shortcoming of Phab. If you don't want this
> merging behavior you need to make a separate Phab review *per commit*.
>
> When I use arc I usually use git to rewrite the message after the review
> to something less messy.
>
> On Tue, Oct 21, 2014 at 11:04 AM, Richard Eisenberg <eir at cis.upenn.edu
> <mailto:eir at cis.upenn.edu>> wrote:
>
>     Hi all,
>
>     Is there a way to put `arc` into a read-only mode?
>
>     Frequently while working on a patch, I make several commits,
>     preferring to separate out testing commits from productive work
>     commits and non-productive (whitespace, comments) commits. Sometimes
>     each of these categories are themselves broken into several commits.
>     These commits are *not* my internal workflow. They are intentionally
>     curated by rebasing as I'm ready to publish the patch, as I think
>     the patches are easy to read this way. (Tell me if I'm wrong, here!)
>     I've resolved myself not to use `arc land`, but instead to apply the
>     patch using git.
>
>     Yet, when I call `arc diff`, even if I haven't amended my patch
>     during the `arc diff`ing process, the commit message of the tip of
>     my branch is changed, and without telling me. I recently pushed my
>     (tiny, uninteresting) fix to #9692. Luckily, my last commit happened
>     to be the meat, so the amended commit message is still wholly
>     relevant. But, that won't always be the case, and I was surprised to
>     see a Phab-ified commit message appear in the Trac ticket after pushing.
>
>     I know I could use more git-ery to restore my old commit message.
>     But is there a way to stop `arc` from doing the message change in
>     the first place?
>
>     Thanks!
>     Richard
>     _______________________________________________
>     ghc-devs mailing list
>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>


From austin at well-typed.com  Sun Nov  9 13:50:32 2014
From: austin at well-typed.com (Austin Seipp)
Date: Sun, 9 Nov 2014 07:50:32 -0600
Subject: 7.10 STABLE freeze date
In-Reply-To: <1415397804-sup-4779@sabre>
References: <CAEs96n0g-nNfxuU-RPbruj7GTfKT3p2qwJ+1_UK2RLAZgBhH+Q@mail.gmail.com>
 <1415397804-sup-4779@sabre>
Message-ID: <CAEs96n0g3weJHg7NLMqPQoMqLJ960xxGKna8Tm41gYbrLwKYrA@mail.gmail.com>

(Sorry for the late reply, was away Saturday.)

This looks good to me. I'll try to review it on Monday.

I will be spending a lot of time in Differential this week...

On Fri, Nov 7, 2014 at 4:05 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> Hey Austin,
>
> Simon and I have been talking about fixing #8427
> (https://ghc.haskell.org/trac/ghc/ticket/8427), but our
> current plan of action will involve interface file changes
> at least and maybe some invasive changes. A heads up!
>
> Edward
>
> Excerpts from Austin Seipp's message of 2014-11-07 13:35:38 -0800:
>> Hi all,
>>
>> After some deliberation, we've decided that the STABLE freeze for 7.10
>> will happen in approximately two weeks, on November 21st. We're hoping
>> to stick to this date closely, but do read below.
>>
>> This is perhaps a short time to freeze, but right now, we've only got
>> a couple things we're planning on focusing on for the next few weeks.
>> And these are really the major things we're waiting for. See below:
>>
>>  - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1
>>
>> These are just:
>>
>>  - D155, LLVM 3.5 compatibility,
>>  - D396 and D169, DWARF/source code note work. These are mostly in me
>> and Simon's court to do another review round, but I think will be OK
>> to get them in on time.
>>  - D168, Partial type signatures. The ball is in Simon's court on this
>> one, but he's had several good rounds of discussion with Thomas etc
>> from what I understand.
>>
>> Based on our discussions earlier this week, I think these all will
>> make it just in time for the freeze.
>>
>> Nota bene: if there is *any* delay, it will be for these, as we picked
>> them as the highest priority in our own views. It is unlikely we will
>> delay any so people can sneak in a few other things. So, if you want
>> something of yours in, you better get me, Simon & Simon, Herbert,
>> etc's attention pronto! That way we'll have time to get it in first.
>>
>> To make things easier, we'll also be pushing the lhs->hs conversion
>> pretty soon so cherry picking/merges are easier, and do some other
>> cleanups.
>>
>> And outside of that, we've still been having a healthy flow of bug
>> fixes falling into the tree, which is great. So if you're just
>> bugfixing, please keep doing so - we'll be pulling bugfixes into the
>> tree continuously.
>>
>> We will also be pulling in submodule/library updates continuously,
>> like we did for the 7.8 branch.
>>
>> Let me know if you have questions, objections, or really really really
>> want something - but I won't be as nice as last time I'm afraid. ;)
>>
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From austin at well-typed.com  Sun Nov  9 13:51:11 2014
From: austin at well-typed.com (Austin Seipp)
Date: Sun, 9 Nov 2014 07:51:11 -0600
Subject: 7.10 STABLE freeze date
In-Reply-To: <CAGK9nuqPMrrtsPviR7UC6fT0prK0nWP-LTvgZgwxjZGi=WytPA@mail.gmail.com>
References: <CAEs96n0g-nNfxuU-RPbruj7GTfKT3p2qwJ+1_UK2RLAZgBhH+Q@mail.gmail.com>
 <alpine.DEB.2.10.1411081152300.2047@galaxy>
 <CAGK9nuqPMrrtsPviR7UC6fT0prK0nWP-LTvgZgwxjZGi=WytPA@mail.gmail.com>
Message-ID: <CAEs96n2XUoem1GpF_4KLahm9RQxAOJXz1x0mPUbXi9rSG0b_Og@mail.gmail.com>

Hi Iavor,

Yes, feel free. Simon's work landed on Thursday(?), so you should be
clear for landing.

On Fri, Nov 7, 2014 at 10:15 PM, Iavor Diatchki
<iavor.diatchki at gmail.com> wrote:
> Hello,
>
> I'd like to get the type-checker plugin code in 7.10.  I've been waiting for
> Simon PJ to merge in his constraint solver changes in HEAD, which I believe
> is very close to happening, and then I'll redo my work on top of that.
>
> -Iavor
>
> On Fri, Nov 7, 2014 at 8:10 PM, Dr. ERDI Gergo <gergo at erdi.hu> wrote:
>>
>> On Fri, 7 Nov 2014, Austin Seipp wrote:
>>
>>> And these are really the major things we're waiting for. See below:
>>>
>>> - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1
>>>
>>> These are just:
>>>
>>> - D155, LLVM 3.5 compatibility,
>>> - D396 and D169, DWARF/source code note work. These are mostly in me
>>> and Simon's court to do another review round, but I think will be OK
>>> to get them in on time.
>>> - D168, Partial type signatures. The ball is in Simon's court on this
>>> one, but he's had several good rounds of discussion with Thomas etc
>>> from what I understand.
>>
>>
>> Hi,
>>
>> I'm almost done with implementing pattern synonym signatures (#8584): I
>> have it fully working on my wip/T8584 branch, I just need to add some tests,
>> and also come up with an acceptable syntax.
>>
>> I also hope to finish fixing #9732 / #9783 over the next couple days.
>>
>> Please let me know ASAP if there's anything more I'll need to do to get
>> these into 7.10, because my schedule for working on GHC will be rather
>> spotty for the next couple weeks.
>>
>> Bye,
>>         Gergo
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From austin at well-typed.com  Sun Nov  9 13:52:49 2014
From: austin at well-typed.com (Austin Seipp)
Date: Sun, 9 Nov 2014 07:52:49 -0600
Subject: 7.10 STABLE freeze date
In-Reply-To: <alpine.DEB.2.10.1411081152300.2047@galaxy>
References: <CAEs96n0g-nNfxuU-RPbruj7GTfKT3p2qwJ+1_UK2RLAZgBhH+Q@mail.gmail.com>
 <alpine.DEB.2.10.1411081152300.2047@galaxy>
Message-ID: <CAEs96n0Ug_HV+eH3n6tWCRXoJU2ViuBamjkZtb6vU1NuRnnsWw@mail.gmail.com>

On Fri, Nov 7, 2014 at 10:10 PM, Dr. ERDI Gergo <gergo at erdi.hu> wrote:
> On Fri, 7 Nov 2014, Austin Seipp wrote:
>
>> And these are really the major things we're waiting for. See below:
>>
>> - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1
>>
>> These are just:
>>
>> - D155, LLVM 3.5 compatibility,
>> - D396 and D169, DWARF/source code note work. These are mostly in me
>> and Simon's court to do another review round, but I think will be OK
>> to get them in on time.
>> - D168, Partial type signatures. The ball is in Simon's court on this
>> one, but he's had several good rounds of discussion with Thomas etc
>> from what I understand.
>
>
> Hi,
>
> I'm almost done with implementing pattern synonym signatures (#8584): I have
> it fully working on my wip/T8584 branch, I just need to add some tests, and
> also come up with an acceptable syntax.
>
> I also hope to finish fixing #9732 / #9783 over the next couple days.

Great, thank you Gergo.

> Please let me know ASAP if there's anything more I'll need to do to get
> these into 7.10, because my schedule for working on GHC will be rather
> spotty for the next couple weeks.
>
> Bye,
>         Gergo
>

That's fine. Part of the reason the freeze period is so long this year
is due to the expectation people may have some spotty availability. It
is the holiday season, after all.

I'll be regularly merging bugfixes etc, so it should not be hard to
merge things later.

(Also, the 7.10 branch will be much easier to build this time; a lot
easier for everyone who might backport themselves.)

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From moritz at lichtzwerge.de  Sun Nov  9 14:13:29 2014
From: moritz at lichtzwerge.de (Moritz Angermann)
Date: Sun, 9 Nov 2014 15:13:29 +0100
Subject: 7.10 STABLE freeze date
In-Reply-To: <CAGo83Ci6M3Qm8UQj3n8TJH1UL6qGCLNH+40iJ8XDQ50zrTDM2Q@mail.gmail.com>
References: <CAEs96n0g-nNfxuU-RPbruj7GTfKT3p2qwJ+1_UK2RLAZgBhH+Q@mail.gmail.com>
 <CAGo83Ci6M3Qm8UQj3n8TJH1UL6qGCLNH+40iJ8XDQ50zrTDM2Q@mail.gmail.com>
Message-ID: <1E48B2E1-937C-4677-9900-10F8625960B8@lichtzwerge.de>

This is fantastic!

On the iOS front I have D206 (fixing dead-strip) hanging in phabricator on the
testsuite makefile, due do the libgmp.10 dependency. See https://phabricator.haskell.org/D206

I'd really like to have this get into 7.10 as well.  So we do not need to disable
deadstripping anymore for iOS targets.

Cheers,
 Moritz

> On Nov 9, 2014, at 1:13 AM, Luke Iannini <lukexipd at gmail.com> wrote:
> 
> Hello,
> 
> I've submitted a patch to finish the already-merged (but incomplete) ARM64 support that adds support for modern iOS devices
> 
> https://ghc.haskell.org/trac/ghc/ticket/7942
> 
> Best
> Luke
> 
> (I've also submitted a patch to LLVM to add an ARM64 GHC calling convention that is in review)
> On Fri, Nov 7, 2014 at 1:35 PM Austin Seipp <austin at well-typed.com> wrote:
> Hi all,
> 
> After some deliberation, we've decided that the STABLE freeze for 7.10
> will happen in approximately two weeks, on November 21st. We're hoping
> to stick to this date closely, but do read below.
> 
> This is perhaps a short time to freeze, but right now, we've only got
> a couple things we're planning on focusing on for the next few weeks.
> And these are really the major things we're waiting for. See below:
> 
>  - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1
> 
> These are just:
> 
>  - D155, LLVM 3.5 compatibility,
>  - D396 and D169, DWARF/source code note work. These are mostly in me
> and Simon's court to do another review round, but I think will be OK
> to get them in on time.
>  - D168, Partial type signatures. The ball is in Simon's court on this
> one, but he's had several good rounds of discussion with Thomas etc
> from what I understand.
> 
> Based on our discussions earlier this week, I think these all will
> make it just in time for the freeze.
> 
> Nota bene: if there is *any* delay, it will be for these, as we picked
> them as the highest priority in our own views. It is unlikely we will
> delay any so people can sneak in a few other things. So, if you want
> something of yours in, you better get me, Simon & Simon, Herbert,
> etc's attention pronto! That way we'll have time to get it in first.
> 
> To make things easier, we'll also be pushing the lhs->hs conversion
> pretty soon so cherry picking/merges are easier, and do some other
> cleanups.
> 
> And outside of that, we've still been having a healthy flow of bug
> fixes falling into the tree, which is great. So if you're just
> bugfixing, please keep doing so - we'll be pulling bugfixes into the
> tree continuously.
> 
> We will also be pulling in submodule/library updates continuously,
> like we did for the 7.8 branch.
> 
> Let me know if you have questions, objections, or really really really
> want something - but I won't be as nice as last time I'm afraid. ;)
> 
> --
> Regards,
> 
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

????????????????? 
Moritz Angermann
+49 170 54 33 0 74
moritz at lichtzwerge.de

lichtzwerge GmbH
Freisinger Landstr. 25
85748 Garching b. M?nchen

Amtsgericht M?nchen HRB 207882
Gesch?ftsf?hrung: Moritz Angermann, Ralf Sangl
USt-Id: DE291948767

Diese E-Mail enth?lt vertrauliche und/oder rechtlich gesch?tzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail
ist nicht gestattet.
This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material in
this e-mail is strictly forbidden.


From simonpj at microsoft.com  Sun Nov  9 17:42:16 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Sun, 9 Nov 2014 17:42:16 +0000
Subject: 7.10 STABLE freeze date
In-Reply-To: <CAGK9nuqPMrrtsPviR7UC6fT0prK0nWP-LTvgZgwxjZGi=WytPA@mail.gmail.com>
References: <CAEs96n0g-nNfxuU-RPbruj7GTfKT3p2qwJ+1_UK2RLAZgBhH+Q@mail.gmail.com>
 <alpine.DEB.2.10.1411081152300.2047@galaxy>
 <CAGK9nuqPMrrtsPviR7UC6fT0prK0nWP-LTvgZgwxjZGi=WytPA@mail.gmail.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F39DFAD@DB3PRD3001MB020.064d.mgd.msft.net>

I did this earlier this week.

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Iavor Diatchki
Sent: 08 November 2014 04:15
To: Dr. ERDI Gergo
Cc: ghc-devs at haskell.org
Subject: Re: 7.10 STABLE freeze date

Hello,

I'd like to get the type-checker plugin code in 7.10.  I've been waiting for Simon PJ to merge in his constraint solver changes in HEAD, which I believe is very close to happening, and then I'll redo my work on top of that.

-Iavor

On Fri, Nov 7, 2014 at 8:10 PM, Dr. ERDI Gergo <gergo at erdi.hu<mailto:gergo at erdi.hu>> wrote:
On Fri, 7 Nov 2014, Austin Seipp wrote:
And these are really the major things we're waiting for. See below:

- https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1

These are just:

- D155, LLVM 3.5 compatibility,
- D396 and D169, DWARF/source code note work. These are mostly in me
and Simon's court to do another review round, but I think will be OK
to get them in on time.
- D168, Partial type signatures. The ball is in Simon's court on this
one, but he's had several good rounds of discussion with Thomas etc
from what I understand.

Hi,

I'm almost done with implementing pattern synonym signatures (#8584): I have it fully working on my wip/T8584 branch, I just need to add some tests, and also come up with an acceptable syntax.

I also hope to finish fixing #9732 / #9783 over the next couple days.

Please let me know ASAP if there's anything more I'll need to do to get these into 7.10, because my schedule for working on GHC will be rather spotty for the next couple weeks.

Bye,
        Gergo

_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://www.haskell.org/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141109/1285dd86/attachment-0001.html>

From simonpj at microsoft.com  Sun Nov  9 19:11:32 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Sun, 9 Nov 2014 19:11:32 +0000
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <alpine.DEB.2.10.1411091554490.2047@galaxy>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411091554490.2047@galaxy>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F39E97A@DB3PRD3001MB020.064d.mgd.msft.net>

On this thread:

* I'm strongly of the opinion that pattern signatures should start
	pattern P :: ...blah...

  Just like value signatures, the pattern name comes first,
  then a double colon. 

* I really don't like syntax that puts the
  pattern name in the middle.

* It's vital that a GADT constructor should have a signature just
  like a GADT constructor.

* I'm not wedded to ";". I chose it just because it seemed like a 
  grouping operator that binds less tightly than ",".

  A vertical bar would be fine with me.  But:
  I'm a little worried that "(|" is a useful bracketing lexeme,
  already used for arrow syntax, so you might have to put a space
  between the paren and the bar.

* One other possibility would be two => thus
	pattern P :: (Eq b) => (Num a, Eq a) => ...blha...

  If you wanted something which had a "match-required" part but no
  "match-provided" part, you'd end up with
	patter P :: () => (Num a, Eq a) => ...blah...
  which is a little odd, but perhaps no odder than
	pattern P :: ( | Num a, Eq a ) => ...blah...

  This has the considerable merit of requiring no new syntax at all.
  There is the difficulty of remembering which way round the match-required
  and match-provided stuff is, but all versions have that problem.

* We don't need to disturb the syntax for HsType; we can just have
  a parser for this particular form; in effect a modified HsForAll,
  just for pattern type signatures, and probably flattened out into
  the pattern-signature constructor form itself.

Does that help?

Simon

| -----Original Message-----
| From: Dr. ERDI Gergo [mailto:gergo at erdi.hu]
| Sent: 09 November 2014 07:56
| To: Simon Peyton Jones
| Cc: GHC Devs
| Subject: RE: Concrete syntax for pattern synonym type signatures
| 
| On Tue, 4 Nov 2014, Simon Peyton Jones wrote:
| 
| >  pattern P :: forall tvs. (match-provided ; match-required) => tau
| >
| > The "; match-required" part is optional, and the "match-provided" part
| might be empty.  So P1 and P2 would look like this:
| >
| >  pattern P1 :: forall a. (; Num a) => b -> (a,b)
| >  pattern P2 :: forall a. (; Num a, Ord a) => a -> a
| 
| Doesn't the ';' look a bit like something that could be incidentially
| introduced by some layout-aware syntax rule? Wouldn't, e.g., '|' be more
| explicit as a separator?
| 
| example:
| 
| pattern P :: forall tvs. (Eq b | Num a, Eq a) => b -> T a


From mail at joachim-breitner.de  Sun Nov  9 19:42:08 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 09 Nov 2014 20:42:08 +0100
Subject: Question about `validate` workflow
In-Reply-To: <98551FA9-12CE-473C-8831-9EF4FEB0D26C@cis.upenn.edu>
References: <CAGK9nupggcBHDe-bEcHMHbY0B=ge9wZAj_Wp3ZTUrLBxTtgqsg@mail.gmail.com>
 <CAD3WKgiifYk8L_KA4Ozvk_XrJrbUwzZ8hLcJWQGytGMyc_+Kyg@mail.gmail.com>
 <1415494248-sup-1074@sabre>
 <98551FA9-12CE-473C-8831-9EF4FEB0D26C@cis.upenn.edu>
Message-ID: <1415562128.2434.3.camel@joachim-breitner.de>

Hi,


Am Samstag, den 08.11.2014, 22:33 -0500 schrieb Richard Eisenberg:
> I've stopped validating locally, allowing Travis to do it for me. If
> you use a `wip/...` branch and push to the main GHC repo, you can find
> build reports at travis-ci.org/ghc/ghc. Or, I'm sure if you clue
> Travis in, this can also work if you push to your own GitHub fork of
> GHC.

of course this spams ghc-commits quite a lot. So while I think it?s
reasonable to use this method to validate something that you expect to
pass, I would advice using your own GitHub fork if you do trial and
error. It?s just takes a few clicks or so to set it up, including
enabling Travis.

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141109/88f89b3e/attachment.sig>

From ekmett at gmail.com  Sun Nov  9 19:42:52 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 9 Nov 2014 14:42:52 -0500
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F39E97A@DB3PRD3001MB020.064d.mgd.msft.net>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411091554490.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F39E97A@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CAJumaK_mZ06G6FB1V_8x7WyZwYVpg1JeJy1F9VVu8anV6pS_sA@mail.gmail.com>

On Sun, Nov 9, 2014 at 2:11 PM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> On this thread:
>
> * I'm strongly of the opinion that pattern signatures should start
>         pattern P :: ...blah...


>
  Just like value signatures, the pattern name comes first,
>   then a double colon.
>

This has the benefit that it lets users logically continue exporting
'pattern Foo', which is a very nice syntax.

The only downside is that the error message when users forget to turn on
pattern synonyms is somewhat more baroque than it can be with the extra
keyword shoehorned in, but the keyword is pretty awful looking.


> * One other possibility would be two => thus
>         pattern P :: (Eq b) => (Num a, Eq a) => ...blha...
>
>   If you wanted something which had a "match-required" part but no
>   "match-provided" part, you'd end up with
>         patter P :: () => (Num a, Eq a) => ...blah...
>   which is a little odd, but perhaps no odder than
>         pattern P :: ( | Num a, Eq a ) => ...blah...
>

The nested (=>) version has a certain appeal to it.

It already parses. The trick is just in properly interpreting it, but users
already interpret (Foo a, Bar b) => .. differently in different contexts,
e.g. in class and instance declarations. They can adapt.

-Edward

>
> | -----Original Message-----
> | From: Dr. ERDI Gergo [mailto:gergo at erdi.hu]
> | Sent: 09 November 2014 07:56
> | To: Simon Peyton Jones
> | Cc: GHC Devs
> | Subject: RE: Concrete syntax for pattern synonym type signatures
> |
> | On Tue, 4 Nov 2014, Simon Peyton Jones wrote:
> |
> | >  pattern P :: forall tvs. (match-provided ; match-required) => tau
> | >
> | > The "; match-required" part is optional, and the "match-provided" part
> | might be empty.  So P1 and P2 would look like this:
> | >
> | >  pattern P1 :: forall a. (; Num a) => b -> (a,b)
> | >  pattern P2 :: forall a. (; Num a, Ord a) => a -> a
> |
> | Doesn't the ';' look a bit like something that could be incidentially
> | introduced by some layout-aware syntax rule? Wouldn't, e.g., '|' be more
> | explicit as a separator?
> |
> | example:
> |
> | pattern P :: forall tvs. (Eq b | Num a, Eq a) => b -> T a
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141109/6bc97a09/attachment.html>

From jwlato at gmail.com  Mon Nov 10 00:15:32 2014
From: jwlato at gmail.com (John Lato)
Date: Mon, 10 Nov 2014 00:15:32 +0000
Subject: Reviving the LTS Discussions (ALT: A separate LTS branch)
References: <CAMgWh9uz7CCEd78_JRRes2Xys6c0YbYz8uaHnLMtBBvdN71ncg@mail.gmail.com>
Message-ID: <CAJ727GhJxT_Qqggwubo3+e74dDDDZND-HhJtb8kX=2inWcs0jg@mail.gmail.com>

Austin, thanks for starting this thread.  I think David raises a lot of
very important points.  In particular, I don't think an LTS plan can be
successful unless there's significant demand (probably from commercial
Haskell users), and it would almost certainly require that those users make
a commitment to do some of the work themselves.

I think David's suggestion is probably a good place to start.  For that
matter, anyone who's interested could probably just fork the github repo,
pull in patches they want, and work away, but it does seem a bit nicer/more
efficient to be able to integrate with trac.

John

On Fri Nov 07 2014 at 11:45:34 PM David Feuer <david.feuer at gmail.com> wrote:

> GHC is an open source project. People work on it because
>
> 1. They enjoy it and find it interesting,
> 2. They need it to work well to support their own software,
> 3. They're trying to write a paper/get a degree/impress their peers, or,
> in very rare cases,
> 4. Someone pays them to do it.
> People are also willing to do some kinds of minor maintenance work because
> 5. They feel a sense of obligation to the community
> but this is not likely, on its own, to keep many people active.
>
> What does this have to do with LTS releases? The fact is that having
> people who want an LTS release does not necessarily mean that anyone else
> should do much of anything about it. If they don't really care, they're
> likely to half-build an LTS process and then get sidetracked.
>
> So what do I think should be done about this? I think "GHC headquarters"
> should make a standing offer to any person, group, or company interested in
> producing an LTS release: an offer of Trac, and Phabricator, and
> Harbormaster, and generally all the infrastructure that GHC already uses.
> Also an offer of advice on how to manage releases, deal with common issues,
> etc. But a promise of programming power seems likely to be an empty one,
> and I don't see the point of trying to push it. If someone wants an LTS
> release, they need to either make one themselves or pay someone to do the
> job.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141110/04dcc467/attachment.html>

From iavor.diatchki at gmail.com  Mon Nov 10 00:17:43 2014
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sun, 9 Nov 2014 16:17:43 -0800
Subject: Typechecker plugins: request for review and another workflow question
Message-ID: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>

Hello,

I just finished merging HEAD into the branch implementing constraint solver
plugins (`wip/tc-plugins`), so things should be fully up to date.  For ease
of review, I squashed everything into a single commit:

https://github.com/ghc/ghc/commit/31729d092c813edc4ef5682db2ee18b33aea6911

could interested folks (I know of SimonPJ, Richard, and Adam) have a look
and let me know if things look reasonable?

On a related note:  I know that we are using phabricator for code review,
but I don't know how to use it yet, so please let me know if I can do
something to make the review easier.

-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141109/b776036b/attachment-0001.html>

From eir at cis.upenn.edu  Mon Nov 10 02:53:41 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sun, 9 Nov 2014 21:53:41 -0500
Subject: Commit messages for WIP branches (Was: Question about `validate`
 workflow)
In-Reply-To: <1415562128.2434.3.camel@joachim-breitner.de>
References: <CAGK9nupggcBHDe-bEcHMHbY0B=ge9wZAj_Wp3ZTUrLBxTtgqsg@mail.gmail.com>
 <CAD3WKgiifYk8L_KA4Ozvk_XrJrbUwzZ8hLcJWQGytGMyc_+Kyg@mail.gmail.com>
 <1415494248-sup-1074@sabre>
 <98551FA9-12CE-473C-8831-9EF4FEB0D26C@cis.upenn.edu>
 <1415562128.2434.3.camel@joachim-breitner.de>
Message-ID: <4D8A1C49-A87F-48EC-A3D6-EEFB3A868B26@cis.upenn.edu>


On Nov 9, 2014, at 2:42 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:

> Am Samstag, den 08.11.2014, 22:33 -0500 schrieb Richard Eisenberg:
>> I've stopped validating locally, allowing Travis to do it for me. If
>> you use a `wip/...` branch and push to the main GHC repo, you can find
>> build reports at travis-ci.org/ghc/ghc. Or, I'm sure if you clue
>> Travis in, this can also work if you push to your own GitHub fork of
>> GHC.
> 
> of course this spams ghc-commits quite a lot. 

Which brings me to ask: why send email to ghc-commits for `wip/*` branch commits? I've personally gone back and forth between using the main GHC repo for my WIP because of precisely this issue. If there were no emails generated, I would surely always use the GHC repo -- it's easier for others to find my work, and tracking a branch in my head is easier than a separate remote and a branch. As it is, I'm always slightly embarrassed when I push to my `wip/rae` branch, causing other people to get emails about my internal GHC meanderings. But, I'm using GHC's repo now for better integration with Phab, for when Harbormaster pulls base commits.

So, I propose: Do not send commit emails for commits to `wip/*` branches.

What do we think?

Thanks,
Richard

From eir at cis.upenn.edu  Mon Nov 10 03:02:53 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sun, 9 Nov 2014 22:02:53 -0500
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F39E97A@DB3PRD3001MB020.064d.mgd.msft.net>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411091554490.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F39E97A@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <10755CED-C8A8-401D-A7C4-2C59274482F0@cis.upenn.edu>


On Nov 9, 2014, at 2:11 PM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> * One other possibility would be two => thus
> 	pattern P :: (Eq b) => (Num a, Eq a) => ...blha...
> 

I should note that I can say this in 7.8.3:

foo :: Show a => Eq a => a -> String
foo x = show x ++ show (x == x)

Note that I've separated the two constraints with a =>, not a comma. This syntax does what you might expect. (I actually believe that this is an improvement over the conventional syntax, but that's a story for another day.) For better or worse, this trick does not work for GADT constructors (which is a weird incongruence with function type signatures), so adding the extra arrow does not really steal syntax from GADT pattern synonyms.

Richard

From mail at joachim-breitner.de  Mon Nov 10 08:33:10 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 10 Nov 2014 09:33:10 +0100
Subject: Commit messages for WIP branches (Was: Question about
 `validate` workflow)
In-Reply-To: <4D8A1C49-A87F-48EC-A3D6-EEFB3A868B26@cis.upenn.edu>
References: <CAGK9nupggcBHDe-bEcHMHbY0B=ge9wZAj_Wp3ZTUrLBxTtgqsg@mail.gmail.com>
 <CAD3WKgiifYk8L_KA4Ozvk_XrJrbUwzZ8hLcJWQGytGMyc_+Kyg@mail.gmail.com>
 <1415494248-sup-1074@sabre>
 <98551FA9-12CE-473C-8831-9EF4FEB0D26C@cis.upenn.edu>
 <1415562128.2434.3.camel@joachim-breitner.de>
 <4D8A1C49-A87F-48EC-A3D6-EEFB3A868B26@cis.upenn.edu>
Message-ID: <1415608390.1517.6.camel@joachim-breitner.de>

Hi,


Am Sonntag, den 09.11.2014, 21:53 -0500 schrieb Richard Eisenberg:
> > Am Samstag, den 08.11.2014, 22:33 -0500 schrieb Richard Eisenberg:
> >> I've stopped validating locally, allowing Travis to do it for me. If
> >> you use a `wip/...` branch and push to the main GHC repo, you can find
> >> build reports at travis-ci.org/ghc/ghc. Or, I'm sure if you clue
> >> Travis in, this can also work if you push to your own GitHub fork of
> >> GHC.
> > 
> > of course this spams ghc-commits quite a lot. 
> 
> Which brings me to ask: why send email to ghc-commits for `wip/*`
> branch commits? I've personally gone back and forth between using the
> main GHC repo for my WIP because of precisely this issue. If there
> were no emails generated, I would surely always use the GHC repo --
> it's easier for others to find my work, and tracking a branch in my
> head is easier than a separate remote and a branch. As it is, I'm
> always slightly embarrassed when I push to my `wip/rae` branch,
> causing other people to get emails about my internal GHC meanderings.
> But, I'm using GHC's repo now for better integration with Phab, for
> when Harbormaster pulls base commits.
> 
> So, I propose: Do not send commit emails for commits to `wip/*`
> branches.
> 
> What do we think?

of course it is nice to know what others are working on, and someone
interested in your particular thing might have a look.

But especially due to rebasing the current commit message setup does not
work for wip branches.

We could experimenting with just sending those ?branch wip/foo's head
updated? mails, i.e. only one mail per push, listing the git commit
titles. That would greatly reduce the traffic, while still giving some
indication of action.

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141110/21900f15/attachment.sig>

From simonpj at microsoft.com  Mon Nov 10 08:37:47 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 10 Nov 2014 08:37:47 +0000
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <10755CED-C8A8-401D-A7C4-2C59274482F0@cis.upenn.edu>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411091554490.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F39E97A@DB3PRD3001MB020.064d.mgd.msft.net>
 <10755CED-C8A8-401D-A7C4-2C59274482F0@cis.upenn.edu>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F39F1EA@DB3PRD3001MB020.064d.mgd.msft.net>

|  I should note that I can say this in 7.8.3:
|  
|  foo :: Show a => Eq a => a -> String
|  foo x = show x ++ show (x == x)


Yes, that's right. SO using two arrows for pattern synonyms would be an abuse of notation.  But (a) the 'pattern' keyword signals that something different is coming up, (b) used in an expression, the type does have the same meaning (i.e. both contexts are required), (c) the alternatives seem worse!

Simon

|  -----Original Message-----
|  From: Richard Eisenberg [mailto:eir at cis.upenn.edu]
|  Sent: 10 November 2014 03:03
|  To: Simon Peyton Jones
|  Cc: Dr. ERDI Gergo; GHC Devs
|  Subject: Re: Concrete syntax for pattern synonym type signatures
|  
|  
|  On Nov 9, 2014, at 2:11 PM, Simon Peyton Jones <simonpj at microsoft.com>
|  wrote:
|  >
|  > * One other possibility would be two => thus
|  > 	pattern P :: (Eq b) => (Num a, Eq a) => ...blha...
|  >
|  
|  I should note that I can say this in 7.8.3:
|  
|  foo :: Show a => Eq a => a -> String
|  foo x = show x ++ show (x == x)
|  
|  Note that I've separated the two constraints with a =>, not a comma.
|  This syntax does what you might expect. (I actually believe that this
|  is an improvement over the conventional syntax, but that's a story for
|  another day.) For better or worse, this trick does not work for GADT
|  constructors (which is a weird incongruence with function type
|  signatures), so adding the extra arrow does not really steal syntax
|  from GADT pattern synonyms.
|  
|  Richard

From marlowsd at gmail.com  Mon Nov 10 09:22:14 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 10 Nov 2014 09:22:14 +0000
Subject: small `arc` victory -- commit message not changed
In-Reply-To: <217BB309-A9E2-494E-BBEC-D36407DB8A1C@cis.upenn.edu>
References: <217BB309-A9E2-494E-BBEC-D36407DB8A1C@cis.upenn.edu>
Message-ID: <546083C6.6000309@gmail.com>

I've never used --head, and it's not even documented in the help for the 
version of arc I have (which ought to be no more than a couple of months 
old).  Maybe it's a new feature.

So I'm hesitant to recommend this workflow.  I think the biggest problem 
in your description is the bit where you "de-Phabbed" the commit 
message, which meant that you had to tell Phabricator exactly which diff 
you wanted to update later.

When I have some time I'll write up the workflow I use for multiple 
dependent patches on the wiki.  But basically it amounts to

  - one Phab diff per git commit
  - use 'git rebase -i' to amend individual commits in the stack
  - use 'arc patch Dnnn && arc land' to land

I always avoid uploading multiple commits as a single diff to 
Phabricator, because it

  - make reviewing harder
  - concatenates the commit messages
  - is just confusing.

I don't know why Phab wants to do it this way, but you can just avoid it 
by using one diff per commit.  Depending on how your Phab config is set 
up this might be the default, or you might have to say "arc diff HEAD^" 
every time.

Cheers,
Simon

On 28/10/2014 12:39, Richard Eisenberg wrote:
> I just revised a Phab revision using `arc`, and it all worked swimmingly, doing exactly what I wanted, even though this was non-trivial. I describe the process below, and am happy to add to the Phab wiki page, but wanted to check here first to make sure I wasn't making an invisible dreadful mistake.
>
> Here's my story:
>
> - I had done a few edits in TcSplice and posted the (boring) revision D359.
>
> - Austin and Harbormaster both had good suggestions for me.
>
> - I spent a week completing other tasks.
>
> - I rebased my WIP branch against master. This worried me about what Phab might think.
>
> - I incorporated the suggestions. As is my usual workflow, I then rebased to integrate these changes into my original commits. As previously discussed, I think breaking a patch into separable commits is a Good Thing, and I curate these commits to be reader-friendly as I work. In the process, I de-Phabified my previous commit message, worried I was inviting demons, but determined to proceed.
>
> - I then updated my Phab revision with this:
>
> arc diff --allow-untracked --head HEAD --update D359
>
> Explanation: --allow-untracked is because I have testsuite garbage floating in my working directory, and I'm never confident enough to modify .gitignore to ignore this garbage. `--head HEAD`, I think, is the magic bit. It specifies the *end* of the commit range to be included in the Phab diff. (The beginning was inferred to be origin/master, but can be specified without flags on the command line.) According to `arc help`, "This [flag] disables many Arcanist/Phabricator features which depend on having access to the working copy." Indeed, it was this warning which made me think `--head` was my friend. Of course, specifying `--head HEAD` on the command line seems redundant, but it still effectively stopped `arc` from touching my commits, thinking that this would break my git-ness. So, `arc` did the best job it could without touching my git information, which is exactly what I wanted.
>
> Results: My new code is now viewable and reviewable at D359. Despite all of my rebasing, the diffs are clean. You can even ask for the differences between my two revisions, and Phab does the right thing -- even though there's a week's worth of other commits that were rebased in. I'm sure Harbormaster is hard at work right now checking my changes. Fellow devs can offer nice feedback. And, I have retained control over my git structure. Hooray!
>
> Question: Have I done anything wrong here? By "wrong", I mean both in a technical sense (e.g., is Harbormaster now deeply confused?) and in a project-management sense (e.g., would this be a bad pattern for others to follow?). Should I put this workflow on the wiki?
>
> If no one tells me otherwise, I plan on using `--head` every time.
>
> Thanks,
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From adam at well-typed.com  Mon Nov 10 09:31:51 2014
From: adam at well-typed.com (Adam Gundry)
Date: Mon, 10 Nov 2014 09:31:51 +0000
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
Message-ID: <54608607.2050400@well-typed.com>

Hi Iavor,


On 10/11/14 00:17, Iavor Diatchki wrote:
> Hello,
>
> I just finished merging HEAD into the branch implementing constraint
> solver plugins (`wip/tc-plugins`), so things should be fully up to
> date.  For ease of review, I squashed everything into a single commit:
>
> https://github.com/ghc/ghc/commit/31729d092c813edc4ef5682db2ee18b33aea6911
>
> could interested folks (I know of SimonPJ, Richard, and Adam) have a
> look and let me know if things look reasonable?

Thanks, this is fantastic work! It will be great to see this in HEAD and
7.10. I've been tracking your branch for a while to build my plugin for
units of measure, and I'm happy to report that it is nearly working...

On the subject of that "nearly", I'm interested to learn whether you
have a suggestion to deal with unflattening, because the interface still
works with flat constraints only. Simon's changes should make it more
practical to unflatten inside the plugin, but it would be far easier (at
least for my purposes) if it was simply given unflattened constraints. I
realise that this would require the plugin loop to be pushed further
out, however, which has other difficulties.

A few other issues, of lesser importance:

 * I still think it would be better to provide an escape hatch to the
TcS, not merely the TcM, alongside the nice TcPluginM wrapper. Notably,
Simon's new TcFlatten.unflatten needs TcS...

 * Is there a way for my plugin to "solve" a given constraint (e.g. to
discard the uninformative "a * 1 ~ a")?

 * It is unfortunately easy to create infinite loops by writing plugins
that emit wanteds but make no useful progress. Perhaps there should be a
limit on the number of times round the loop (like SubGoalDepth but for
all constraints)?

 * Perhaps runTcPlugin should skip invoking the plugin if there are no
wanteds?

 * The use of ctev_evar in runTcPlugin is partial, and fails with a
nasty error if the plugin returns a non-wanted in the solved constraints
list. Would it be worth catching this error and issuing a sensible
message that chastises the plugin author appropriately?

 * Finally, I presume the comment on runTcPlugin that "The plugin is
provided only with CTyEq and CFunEq constraints" is simply outdated and
should be removed?

Apologies for the deluge of questions - please take them as evidence of
my eagerness to use this feature!

All the best,

Adam


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From marlowsd at gmail.com  Mon Nov 10 09:33:05 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 10 Nov 2014 09:33:05 +0000
Subject: unexpected failure for scc001
In-Reply-To: <1414968683.6639.1.camel@joachim-breitner.de>
References: <1414968683.6639.1.camel@joachim-breitner.de>
Message-ID: <54608651.7050206@gmail.com>

The test is checking that the cost-centre stack looks right.  The 
difference appears to be in the original we have CAF->main->{g,h}, 
whereas in your version it is MAIN->main->{g,h}.  I don't remember all 
the details, but this looks like an innocuous change to me so just go 
ahead and accept the output change.

Cheers,
Simon

On 02/11/2014 22:51, Joachim Breitner wrote:
> Hi,
>
> it seems that adding the oneShot annotation to the interface causes
> scc001 to fail:
>
>
> Actual prof output differs from expected:
> --- ./profiling/should_run/scc001.prof.sample   2014-11-02 20:21:03.000000000 +0100
> +++ ./profiling/should_run/scc001.prof  2014-11-02 20:46:39.000000000 +0100
> @@ -1,28 +1,33 @@
> -       Fri Oct 14 16:27 2011 Time and Allocation Profiling Report  (Final)
> +       Sun Nov  2 20:46 2014 Time and Allocation Profiling Report  (Final)
>
>             scc001 +RTS -hc -p -RTS
>
> -       total time  =        0.00 secs   (0 ticks @ 20 ms)
> -       total alloc =      46,020 bytes  (excludes profiling overheads)
> +       total time  =        0.00 secs   (0 ticks @ 1000 us, 1 processor)
> +       total alloc =      51,344 bytes  (excludes profiling overheads)
>
>   COST CENTRE MODULE                %time %alloc
>
> -MAIN        MAIN                    0.0   23.0
> -CAF         GHC.IO.Encoding.Iconv   0.0    1.3
> -CAF         GHC.IO.Handle.FD        0.0   74.2
> +MAIN        MAIN               0.0    1.9
> +CAF         GHC.IO.Encoding    0.0    5.4
> +CAF         GHC.Conc.Signal    0.0    1.3
> +CAF         GHC.IO.Handle.FD   0.0   67.3
> +main        Main               0.0   22.8
>
>
>                                                         individual     inherited
>   COST CENTRE MODULE                  no.     entries  %time %alloc   %time %alloc
>
> -MAIN        MAIN                    101           0    0.0   23.0     0.0  100.0
> - CAF        GHC.Show                141           0    0.0    0.3     0.0    0.3
> - CAF        GHC.IO.Handle.FD        128           0    0.0   74.2     0.0   74.2
> - CAF        GHC.IO.Encoding.Iconv   120           0    0.0    1.3     0.0    1.3
> - CAF        GHC.Conc.Signal         110           0    0.0    0.7     0.0    0.7
> - CAF        Main                    107           0    0.0    0.4     0.0    0.4
> -  (...)     Main                    206           1    0.0    0.0     0.0    0.0
> -  h         Main                    205           1    0.0    0.0     0.0    0.0
> -  main      Main                    202           1    0.0    0.0     0.0    0.0
> -   g        Main                    204           1    0.0    0.0     0.0    0.0
> -   f        Main                    203           1    0.0    0.0     0.0    0.0
> +MAIN        MAIN                     44           0    0.0    1.9     0.0  100.0
> + main       Main                     89           0    0.0   22.8     0.0   22.8
> +  g         Main                     91           1    0.0    0.0     0.0    0.0
> +  f         Main                     90           1    0.0    0.0     0.0    0.0
> + CAF        Main                     87           0    0.0    0.1     0.0    0.1
> +  (...)     Main                     93           1    0.0    0.0     0.0    0.0
> +  h         Main                     92           1    0.0    0.0     0.0    0.0
> +  main      Main                     88           1    0.0    0.0     0.0    0.0
> + CAF        GHC.IO.Handle.Text       84           0    0.0    0.2     0.0    0.2
> + CAF        GHC.IO.Encoding.Iconv    80           0    0.0    0.5     0.0    0.5
> + CAF        GHC.IO.Handle.FD         79           0    0.0   67.3     0.0   67.3
> + CAF        GHC.Show                 77           0    0.0    0.6     0.0    0.6
> + CAF        GHC.Conc.Signal          74           0    0.0    1.3     0.0    1.3
> + CAF        GHC.IO.Encoding          72           0    0.0    5.4     0.0    5.4
> *** unexpected failure for scc001(profasm)
>
> Now after reading some of the code it seems that the output is
> normalized considerably before comparing.
>
> But I?m not fully sure what is being checked here. So things change: Is
> that change a regression? An improvement? Or just an a wobble that
> should not worry me?
>
> Greetings,
> Joachim
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From hvriedel at gmail.com  Mon Nov 10 09:40:42 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Mon, 10 Nov 2014 10:40:42 +0100
Subject: small `arc` victory -- commit message not changed
In-Reply-To: <546083C6.6000309@gmail.com>
References: <217BB309-A9E2-494E-BBEC-D36407DB8A1C@cis.upenn.edu>
 <546083C6.6000309@gmail.com>
Message-ID: <CAOFsArtmqs7fuMX_=GbgnUwqskV0WrEvSgsWPSwPVfefT80s8w@mail.gmail.com>

On Mon, Nov 10, 2014 at 10:22 AM, Simon Marlow <marlowsd at gmail.com> wrote:


> So I'm hesitant to recommend this workflow.  I think the biggest problem
> in your description is the bit where you "de-Phabbed" the commit message,
> which meant that you had to tell Phabricator exactly which diff you wanted
> to update later
> ?.
>

?The important thing when de-phabbing the commit message is to keep the

"Differential Revision: ..."

line intact; that way `arc` and Phabricator recognise what differential the
commit belongs to.

?
?I always de-phab the commit messages before landing manually (alas `arc
land` is useless here) because otherwise we end up with non-idiomatic
commit messages which look terrible everywhere else except in
Phabricator... :-/?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141110/9a2fd5a5/attachment.html>

From alexander at plaimi.net  Mon Nov 10 09:57:54 2014
From: alexander at plaimi.net (Alexander Berntsen)
Date: Mon, 10 Nov 2014 10:57:54 +0100
Subject: Abstracting over constraints: Can this be implemented in GHC?
In-Reply-To: <46BEE07D-DABA-44D0-BC11-FBDD3718ACF1@cis.upenn.edu>
References: <545B454A.9090504@plaimi.net>
 <46BEE07D-DABA-44D0-BC11-FBDD3718ACF1@cis.upenn.edu>
Message-ID: <54608C22.5000402@plaimi.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/11/14 16:36, Richard Eisenberg wrote:
> or an explicit type application, once those are available
Speaking of. Who's working on those? How are they progressing?

While this is a nightmare:
(f :: (Show x, Show y) => (forall a. Show a => a -> d) -> (x, y) ->
(d, d)) show (1.2, False)

Something like this would be acceptable:
(f @ Show) show (1,2, False)


But it's still the Wrong Thing, in my opinion.
- -- 
Alexander
alexander at plaimi.net
https://secure.plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlRgjCIACgkQRtClrXBQc7V+XQEApisF6PVFxa6j884A5pceaEX/
drUUvzh2SLPN5BC9lJoBAI4h9JdOvg0d33vKo9JU65O+44jD7C5RabU1vXRV218J
=RgSL
-----END PGP SIGNATURE-----

From dreixel at gmail.com  Mon Nov 10 10:45:38 2014
From: dreixel at gmail.com (=?UTF-8?Q?Jos=C3=A9_Pedro_Magalh=C3=A3es?=)
Date: Mon, 10 Nov 2014 10:45:38 +0000
Subject: 7.10 STABLE freeze date
In-Reply-To: <CAEs96n0g-nNfxuU-RPbruj7GTfKT3p2qwJ+1_UK2RLAZgBhH+Q@mail.gmail.com>
References: <CAEs96n0g-nNfxuU-RPbruj7GTfKT3p2qwJ+1_UK2RLAZgBhH+Q@mail.gmail.com>
Message-ID: <CA+ZFbn-UVh64b03d8CcdXjYCTLoQPOgdftgFm9VTwSeVLCvJig@mail.gmail.com>

I'd like to get both #5462 <https://ghc.haskell.org/trac/ghc/ticket/5462>
and #9766 <https://ghc.haskell.org/trac/ghc/ticket/9766> in 7.10. I'm
hoping to have them ready for review later this week.


Cheers,
Pedro

On Fri, Nov 7, 2014 at 9:35 PM, Austin Seipp <austin at well-typed.com> wrote:

> Hi all,
>
> After some deliberation, we've decided that the STABLE freeze for 7.10
> will happen in approximately two weeks, on November 21st. We're hoping
> to stick to this date closely, but do read below.
>
> This is perhaps a short time to freeze, but right now, we've only got
> a couple things we're planning on focusing on for the next few weeks.
> And these are really the major things we're waiting for. See below:
>
>  - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1
>
> These are just:
>
>  - D155, LLVM 3.5 compatibility,
>  - D396 and D169, DWARF/source code note work. These are mostly in me
> and Simon's court to do another review round, but I think will be OK
> to get them in on time.
>  - D168, Partial type signatures. The ball is in Simon's court on this
> one, but he's had several good rounds of discussion with Thomas etc
> from what I understand.
>
> Based on our discussions earlier this week, I think these all will
> make it just in time for the freeze.
>
> Nota bene: if there is *any* delay, it will be for these, as we picked
> them as the highest priority in our own views. It is unlikely we will
> delay any so people can sneak in a few other things. So, if you want
> something of yours in, you better get me, Simon & Simon, Herbert,
> etc's attention pronto! That way we'll have time to get it in first.
>
> To make things easier, we'll also be pushing the lhs->hs conversion
> pretty soon so cherry picking/merges are easier, and do some other
> cleanups.
>
> And outside of that, we've still been having a healthy flow of bug
> fixes falling into the tree, which is great. So if you're just
> bugfixing, please keep doing so - we'll be pulling bugfixes into the
> tree continuously.
>
> We will also be pulling in submodule/library updates continuously,
> like we did for the 7.8 branch.
>
> Let me know if you have questions, objections, or really really really
> want something - but I won't be as nice as last time I'm afraid. ;)
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141110/c3ab1b67/attachment.html>

From david.macek.0 at gmail.com  Mon Nov 10 11:24:44 2014
From: david.macek.0 at gmail.com (David Macek)
Date: Mon, 10 Nov 2014 12:24:44 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <CAFC_MejuO-P=0G4+uS=JUhrn9Zmif5gqHMTrPq9O17j00j6-ug@mail.gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
 <CAOYw7duty5OoX35NJq-mtc=MqyH6T7L9y2DfzHhWQxYAr1n2bg@mail.gmail.com>
 <5458CD34.6040600@gmail.com>
 <CAFC_Meg_UZATRAWKnf5daM5Qo0eCYp6CUPh1fovnC7gVATeQwg@mail.gmail.com>
 <5458EC7D.3080008@gmail.com>
 <CAFC_Meiy4REPCsKyYmZDSLsEZq-CY5RSTaPb4k1SL2EFH7Wzqw@mail.gmail.com>
 <54591E58.2060002@gmail.com>
 <CAFC_MehHXa2i2DeZLH_Oa2trFz+HWAh6ADoy1a9kb3fb8KT9=g@mail.gmail.com>
 <545951CB.8040604@gmail.com> <5459CB60.2080807@gmail.com>
 <5459FDBF.8070405@gmail.com>
 <CAFC_Meh+y9O1rdHWWjT8EDB0kWhFbDLSJT88kYBAEMbzh=ObdA@mail.gmail.com>
 <CAFC_MejuO-P=0G4+uS=JUhrn9Zmif5gqHMTrPq9O17j00j6-ug@mail.gmail.com>
Message-ID: <5460A07C.2070309@gmail.com>

On 5. 11. 2014 18:13, Gintautas Miliauskas wrote:
> 
> 
>     Thanks for pointing out that virus scanners could be an issue. I found that Microsoft Security Essentials realtime scanning was on. I'll try disabling it and see if that helps with the -j5 case.
> 
> 
> For what it's worth, I tried disabling the virus scanner, but it did not help, 4/8 validation runs segfaulted (-j5).

Can you dump your package versions here? Use pacman -Qe. I want to try the build with a replica of your environment.

Also, does 4/8 mean that some builds were without errors? Maybe I haven't done enough runs. Could you attach the script you use for running validate in a loop? (I'm sure it's simple enough for me to write it, but if I can avoid it...)

-- 
David Macek

From gergo at erdi.hu  Mon Nov 10 14:09:23 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Mon, 10 Nov 2014 22:09:23 +0800 (SGT)
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F39F1EA@DB3PRD3001MB020.064d.mgd.msft.net>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411091554490.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F39E97A@DB3PRD3001MB020.064d.mgd.msft.net>
 <10755CED-C8A8-401D-A7C4-2C59274482F0@cis.upenn.edu>
 <618BE556AADD624C9C918AA5D5911BEF3F39F1EA@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <alpine.DEB.2.10.1411102202290.2047@galaxy>

Good news, I've made the necessary parser breakthrough and I've now got

     pattern P :: pretty much anything after this point

to parse as a pattern synonym type signature on a local sub-branch of my 
branch. So no more annoying 'pattern type' nonsense.

As for the 'pretty much anything' part, I have SPJ's original proposal 
implemented as a proof-of-concept:

     pattern C :: forall b c. (; Eq b, Num b) => b -> c -> X Maybe (Maybe b)

But I see that the popular opinion now seems to be moving to

     pattern C :: () => (Eq b, Num b) => b -> c -> X Maybe (Maybe b)

which should be even easier to implement now, so I hope to finish the 
branch in a couple days (it probably doesn't need more than an evening's 
work now).

Thanks go out to everyone who contributed in this little syntax 
bikeshedding exercise.

Bye,
 	Gergo


-- 

   .--= ULLA! =-----------------.
    \     http://gergo.erdi.hu   \
     `---= gergo at erdi.hu =-------'
Define (n.)  De ting you get for breaking de law.

From eir at cis.upenn.edu  Mon Nov 10 15:31:26 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 10 Nov 2014 10:31:26 -0500
Subject: Commit messages for WIP branches (Was: Question about `validate`
 workflow)
In-Reply-To: <1415608390.1517.6.camel@joachim-breitner.de>
References: <CAGK9nupggcBHDe-bEcHMHbY0B=ge9wZAj_Wp3ZTUrLBxTtgqsg@mail.gmail.com>
 <CAD3WKgiifYk8L_KA4Ozvk_XrJrbUwzZ8hLcJWQGytGMyc_+Kyg@mail.gmail.com>
 <1415494248-sup-1074@sabre>
 <98551FA9-12CE-473C-8831-9EF4FEB0D26C@cis.upenn.edu>
 <1415562128.2434.3.camel@joachim-breitner.de>
 <4D8A1C49-A87F-48EC-A3D6-EEFB3A868B26@cis.upenn.edu>
 <1415608390.1517.6.camel@joachim-breitner.de>
Message-ID: <6D4AEF24-1685-4497-B3AF-8D0F75675787@cis.upenn.edu>


On Nov 10, 2014, at 3:33 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> We could experimenting with just sending those ?branch wip/foo's head
> updated? mails, i.e. only one mail per push, listing the git commit
> titles. That would greatly reduce the traffic, while still giving some
> indication of action.

I like this idea, as it still allows those who want to watch something closely to do so.

Thanks,
Richard

From alan.zimm at gmail.com  Mon Nov 10 15:33:21 2014
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Mon, 10 Nov 2014 17:33:21 +0200
Subject: 7.10 STABLE freeze date
In-Reply-To: <CA+ZFbn-UVh64b03d8CcdXjYCTLoQPOgdftgFm9VTwSeVLCvJig@mail.gmail.com>
References: <CAEs96n0g-nNfxuU-RPbruj7GTfKT3p2qwJ+1_UK2RLAZgBhH+Q@mail.gmail.com>
 <CA+ZFbn-UVh64b03d8CcdXjYCTLoQPOgdftgFm9VTwSeVLCvJig@mail.gmail.com>
Message-ID: <CANma=H-xtQiTKBwxqS9+d-q47ZxpxSRhmgcKunoCVdpVUdq4zA@mail.gmail.com>

To stake my claim, I would like to get #9628 (encompassing D426,D438 and
D412) in 7.10. And D445.

Alan

On Mon, Nov 10, 2014 at 12:45 PM, Jos? Pedro Magalh?es <dreixel at gmail.com>
wrote:

> I'd like to get both #5462 <https://ghc.haskell.org/trac/ghc/ticket/5462>
> and #9766 <https://ghc.haskell.org/trac/ghc/ticket/9766> in 7.10. I'm
> hoping to have them ready for review later this week.
>
>
> Cheers,
> Pedro
>
> On Fri, Nov 7, 2014 at 9:35 PM, Austin Seipp <austin at well-typed.com>
> wrote:
>
>> Hi all,
>>
>> After some deliberation, we've decided that the STABLE freeze for 7.10
>> will happen in approximately two weeks, on November 21st. We're hoping
>> to stick to this date closely, but do read below.
>>
>> This is perhaps a short time to freeze, but right now, we've only got
>> a couple things we're planning on focusing on for the next few weeks.
>> And these are really the major things we're waiting for. See below:
>>
>>  - https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1
>>
>> These are just:
>>
>>  - D155, LLVM 3.5 compatibility,
>>  - D396 and D169, DWARF/source code note work. These are mostly in me
>> and Simon's court to do another review round, but I think will be OK
>> to get them in on time.
>>  - D168, Partial type signatures. The ball is in Simon's court on this
>> one, but he's had several good rounds of discussion with Thomas etc
>> from what I understand.
>>
>> Based on our discussions earlier this week, I think these all will
>> make it just in time for the freeze.
>>
>> Nota bene: if there is *any* delay, it will be for these, as we picked
>> them as the highest priority in our own views. It is unlikely we will
>> delay any so people can sneak in a few other things. So, if you want
>> something of yours in, you better get me, Simon & Simon, Herbert,
>> etc's attention pronto! That way we'll have time to get it in first.
>>
>> To make things easier, we'll also be pushing the lhs->hs conversion
>> pretty soon so cherry picking/merges are easier, and do some other
>> cleanups.
>>
>> And outside of that, we've still been having a healthy flow of bug
>> fixes falling into the tree, which is great. So if you're just
>> bugfixing, please keep doing so - we'll be pulling bugfixes into the
>> tree continuously.
>>
>> We will also be pulling in submodule/library updates continuously,
>> like we did for the 7.8 branch.
>>
>> Let me know if you have questions, objections, or really really really
>> want something - but I won't be as nice as last time I'm afraid. ;)
>>
>> --
>> Regards,
>>
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141110/0fea8647/attachment.html>

From eir at cis.upenn.edu  Mon Nov 10 15:37:20 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 10 Nov 2014 10:37:20 -0500
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
Message-ID: <B21A8B7C-4709-448A-9F18-8E32B67F1641@cis.upenn.edu>

Hi Iavor,

Great!

For the workflow question: See https://ghc.haskell.org/trac/ghc/wiki/Phabricator, which contains all the details. The short version for your needs: install `arc` (see the wiki page) and then say `arc diff` on your branch. Note that `arc diff` will change your commit message. If you don't want this, say `arc diff --head HEAD`.

Is there a place with an up-to-date user-level interface written up? I'll look through the code as well, but my interest is more in the interface than the implementation. Furthermore, it's easy to change the implementation later, but not the interface, and I want to make sure this has the best possible interface before releasing to the greater GHC public.

Thanks!
Richard

On Nov 9, 2014, at 7:17 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:

> Hello,
> 
> I just finished merging HEAD into the branch implementing constraint solver plugins (`wip/tc-plugins`), so things should be fully up to date.  For ease of review, I squashed everything into a single commit:
> 
> https://github.com/ghc/ghc/commit/31729d092c813edc4ef5682db2ee18b33aea6911
> 
> could interested folks (I know of SimonPJ, Richard, and Adam) have a look and let me know if things look reasonable?
> 
> On a related note:  I know that we are using phabricator for code review, but I don't know how to use it yet, so please let me know if I can do something to make the review easier.
> 
> -Iavor
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141110/866d7c9e/attachment.html>

From ekmett at gmail.com  Mon Nov 10 15:45:58 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 10 Nov 2014 10:45:58 -0500
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <10755CED-C8A8-401D-A7C4-2C59274482F0@cis.upenn.edu>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411091554490.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F39E97A@DB3PRD3001MB020.064d.mgd.msft.net>
 <10755CED-C8A8-401D-A7C4-2C59274482F0@cis.upenn.edu>
Message-ID: <CAJumaK-GfC7Mi=+z2Prc+tcSUDuO7iRpgMAVDVzdqF9X3=iLfg@mail.gmail.com>

Note though, it doesn't mean the same thing to say (Foo a, Bar a b) => ...
as it does to say

Foo a => Bar a b => ...

The latter can use Foo a when working on Bar a b, but not Bar a b to
discharge Foo a, which makes a difference when you have functional
dependencies.

So in some sense the 'pattern requires/supplies' split is just that.



That said, Richard's other option

pattern Foo a => P :: Bar a => a

has the benefit that it looks a bit like the old datatype contexts (but
here applied to the constructor/pattern).

If we expect the left hand side or the right hand side to be most often
trivial then that may be worth considering.

You'd occasionally have things like

pattern (Num a, Eq a) => Foo :: a

for

pattern Foo = 8

but most of the time they'd wind up just looking like a GADT constructor.

-Edward

On Sun, Nov 9, 2014 at 10:02 PM, Richard Eisenberg <eir at cis.upenn.edu>
wrote:

>
> On Nov 9, 2014, at 2:11 PM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
> >
> > * One other possibility would be two => thus
> >       pattern P :: (Eq b) => (Num a, Eq a) => ...blha...
> >
>
> I should note that I can say this in 7.8.3:
>
> foo :: Show a => Eq a => a -> String
> foo x = show x ++ show (x == x)
>
> Note that I've separated the two constraints with a =>, not a comma. This
> syntax does what you might expect. (I actually believe that this is an
> improvement over the conventional syntax, but that's a story for another
> day.) For better or worse, this trick does not work for GADT constructors
> (which is a weird incongruence with function type signatures), so adding
> the extra arrow does not really steal syntax from GADT pattern synonyms.
>
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141110/76866fdb/attachment-0001.html>

From eir at cis.upenn.edu  Mon Nov 10 15:52:21 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 10 Nov 2014 10:52:21 -0500
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <alpine.DEB.2.10.1411102202290.2047@galaxy>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411091554490.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F39E97A@DB3PRD3001MB020.064d.mgd.msft.net>
 <10755CED-C8A8-401D-A7C4-2C59274482F0@cis.upenn.edu>
 <618BE556AADD624C9C918AA5D5911BEF3F39F1EA@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411102202290.2047@galaxy>
Message-ID: <CDF30C0A-FD6D-4C0E-A3BB-A26091618E7C@cis.upenn.edu>

While I'll admit I still like my bikeshed color choice over Simon's, I'm happy to go with the fact that there seems to be more momentum behind Simon's.

Instead, let me propose a slight change of shade: put the "required" constraints *first* and the "provided" ones *second*. Of course, we could leave out the required constraints.

So, continuing the examples from earlier, we have

> pattern P :: forall a. Num a => forall c. (Eq a, Ord Bool, Show c) => c -> Bool -> T a Bool
> pattern C :: (Eq b, Num b) => () => b -> c -> X Maybe (Maybe b)

Of course, you can drop the `forall`s in `P`'s type.

This has, I believe, several advantages over the other order:
- If you write the `forall`s in, the scope builds left to right. In the other order, the scoping is very bizarre.
- I think of the "provided" bits + arguments of the constraint as what is matched against. The order I propose keeps these pieces together. Consider a synonym for a GADT constructor, but with some of the arguments filled in. With the order I propose, you can straightforwardly do substitution over the original GADT constructor type, and perhaps prepend some new required constraints. In the other order, the original GADT constructor type must be broken up.

Whatever syntax we choose, I would highly recommend putting in a helpful link to more information in error messages. This will remain a tripping point, not because of poor syntax, but because this is tricky. I would love to see us start the habit of putting links to web pages (possibly from the manual) in error messages to give users a place to look when they need more information.

Richard

On Nov 10, 2014, at 9:09 AM, "Dr. ERDI Gergo" <gergo at erdi.hu> wrote:

> Good news, I've made the necessary parser breakthrough and I've now got
> 
>    pattern P :: pretty much anything after this point
> 
> to parse as a pattern synonym type signature on a local sub-branch of my branch. So no more annoying 'pattern type' nonsense.
> 
> As for the 'pretty much anything' part, I have SPJ's original proposal implemented as a proof-of-concept:
> 
>    pattern C :: forall b c. (; Eq b, Num b) => b -> c -> X Maybe (Maybe b)
> 
> But I see that the popular opinion now seems to be moving to
> 
>    pattern C :: () => (Eq b, Num b) => b -> c -> X Maybe (Maybe b)
> 
> which should be even easier to implement now, so I hope to finish the branch in a couple days (it probably doesn't need more than an evening's work now).
> 
> Thanks go out to everyone who contributed in this little syntax bikeshedding exercise.
> 
> Bye,
> 	Gergo
> 
> 
> -- 
> 
>  .--= ULLA! =-----------------.
>   \     http://gergo.erdi.hu   \
>    `---= gergo at erdi.hu =-------'
> Define (n.)  De ting you get for breaking de law.


From austin at well-typed.com  Mon Nov 10 15:58:00 2014
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 10 Nov 2014 09:58:00 -0600
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
Message-ID: <CAEs96n2fA95K_y=T8F3Lherf7vYjidMRGj_MHFPsN3JktJyPsA@mail.gmail.com>

Hi Iavor;

I took a very, very cursory glance. Naturally I am not a typechecker
guru, but I did look over the mechanical changes/extensions to thread
things around. Two things popped out to me:

 - 1) Ugh, a new .hs-boot file. I assume this wasn't added without
good reason, but ideally we would be eliminating them quicker than we
add them. :) I want to take a closer look at this; perhaps we can
refactor something for you to remove the need for this.

 - 2) I am kind of not a fan of having separate 'plugins for
core2core' and 'plugins for typechecking' flags, AKA -ftc-plugin and
-fplugin. Ideally I would think all plugins could be uniformly
specified by simply saying '-fplugin'. This mostly avoids the need for
duplication and a naming convention/slew of flags for each case (which
we have to catalog and document). There may be an easy way to make
this the case; I haven't looked closely yet (it has been some time
since I starred at the plugin code, even though Max wrote it and I
helped get it merged!)

I'll take a closer look sooner; thanks.

On Sun, Nov 9, 2014 at 6:17 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> Hello,
>
> I just finished merging HEAD into the branch implementing constraint solver
> plugins (`wip/tc-plugins`), so things should be fully up to date.  For ease
> of review, I squashed everything into a single commit:
>
> https://github.com/ghc/ghc/commit/31729d092c813edc4ef5682db2ee18b33aea6911
>
> could interested folks (I know of SimonPJ, Richard, and Adam) have a look
> and let me know if things look reasonable?
>
> On a related note:  I know that we are using phabricator for code review,
> but I don't know how to use it yet, so please let me know if I can do
> something to make the review easier.
>
> -Iavor
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From gergo at erdi.hu  Mon Nov 10 16:50:46 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Tue, 11 Nov 2014 00:50:46 +0800 (SGT)
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <CDF30C0A-FD6D-4C0E-A3BB-A26091618E7C@cis.upenn.edu>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411091554490.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F39E97A@DB3PRD3001MB020.064d.mgd.msft.net>
 <10755CED-C8A8-401D-A7C4-2C59274482F0@cis.upenn.edu>
 <618BE556AADD624C9C918AA5D5911BEF3F39F1EA@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411102202290.2047@galaxy>
 <CDF30C0A-FD6D-4C0E-A3BB-A26091618E7C@cis.upenn.edu>
Message-ID: <alpine.DEB.2.10.1411110049120.2047@galaxy>

On Mon, 10 Nov 2014, Richard Eisenberg wrote:

>> pattern P :: forall a. Num a => forall c. (Eq a, Ord Bool, Show c) => c -> Bool -> T a Bool
>> pattern C :: (Eq b, Num b) => () => b -> c -> X Maybe (Maybe b)
>
> Of course, you can drop the `forall`s in `P`'s type.
>
> This has, I believe, several advantages over the other order:
> - If you write the `forall`s in, the scope builds left to right. In the 
> other order, the scoping is very bizarre.

I am by now convinced that allowing two separate sets of `forall`s is 
overkill, we don't need the extra specificity. One `forall` with a mixed 
bag of type variables should be enough.

From adam at well-typed.com  Mon Nov 10 17:46:20 2014
From: adam at well-typed.com (Adam Gundry)
Date: Mon, 10 Nov 2014 17:46:20 +0000
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <CAEs96n2fA95K_y=T8F3Lherf7vYjidMRGj_MHFPsN3JktJyPsA@mail.gmail.com>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
 <CAEs96n2fA95K_y=T8F3Lherf7vYjidMRGj_MHFPsN3JktJyPsA@mail.gmail.com>
Message-ID: <5460F9EC.9050901@well-typed.com>

On 10/11/14 15:58, Austin Seipp wrote:
>  - 2) I am kind of not a fan of having separate 'plugins for
> core2core' and 'plugins for typechecking' flags, AKA -ftc-plugin and
> -fplugin. Ideally I would think all plugins could be uniformly
> specified by simply saying '-fplugin'. This mostly avoids the need for
> duplication and a naming convention/slew of flags for each case (which
> we have to catalog and document). There may be an easy way to make
> this the case; I haven't looked closely yet (it has been some time
> since I starred at the plugin code, even though Max wrote it and I
> helped get it merged!)

FWIW, I originally envisaged reusing the existing plugins machinery, and
I don't think there are any great problems in doing so (see
https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker). In fact, I
had an early implementation of typechecker plugins that did exactly this.

I have been wondering, however, about another possible approach. We could:

 1. make the constraint solver changes use a *hook*, instead of the
plugins directly, and

 2. make it possible for plugins to install/modify hooks at some
suitable point in the compilation pipeline.

I don't know the hooks machinery very well, but if this is feasible it
seems like it would provide more power (plugins could modify any part of
GHC for which a hook is available) and avoid having multiple overlapping
ways of extending GHC. In the future, I can imagine wanting plugins to
hook into other parts of GHC (e.g. error message postprocessing for
domain-specific error reporting), and this seems like a good way to
achieve that.

Adam


> On Sun, Nov 9, 2014 at 6:17 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
>> Hello,
>>
>> I just finished merging HEAD into the branch implementing constraint solver
>> plugins (`wip/tc-plugins`), so things should be fully up to date.  For ease
>> of review, I squashed everything into a single commit:
>>
>> https://github.com/ghc/ghc/commit/31729d092c813edc4ef5682db2ee18b33aea6911
>>
>> could interested folks (I know of SimonPJ, Richard, and Adam) have a look
>> and let me know if things look reasonable?
>>
>> On a related note:  I know that we are using phabricator for code review,
>> but I don't know how to use it yet, so please let me know if I can do
>> something to make the review easier.
>>
>> -Iavor


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From eric at seidel.io  Mon Nov 10 18:26:32 2014
From: eric at seidel.io (Eric Seidel)
Date: Mon, 10 Nov 2014 10:26:32 -0800
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <5460F9EC.9050901@well-typed.com>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
 <CAEs96n2fA95K_y=T8F3Lherf7vYjidMRGj_MHFPsN3JktJyPsA@mail.gmail.com>
 <5460F9EC.9050901@well-typed.com>
Message-ID: <78313ED5-B4B0-44C3-8371-DE693B60D856@seidel.io>


> On Nov 10, 2014, at 09:46, Adam Gundry <adam at well-typed.com> wrote:
> 
> On 10/11/14 15:58, Austin Seipp wrote:
>> - 2) I am kind of not a fan of having separate 'plugins for
>> core2core' and 'plugins for typechecking' flags, AKA -ftc-plugin and
>> -fplugin. Ideally I would think all plugins could be uniformly
>> specified by simply saying '-fplugin'. This mostly avoids the need for
>> duplication and a naming convention/slew of flags for each case (which
>> we have to catalog and document). There may be an easy way to make
>> this the case; I haven't looked closely yet (it has been some time
>> since I starred at the plugin code, even though Max wrote it and I
>> helped get it merged!)
> 
> FWIW, I originally envisaged reusing the existing plugins machinery, and
> I don't think there are any great problems in doing so (see
> https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker). In fact, I
> had an early implementation of typechecker plugins that did exactly this.
> 
> I have been wondering, however, about another possible approach. We could:
> 
> 1. make the constraint solver changes use a *hook*, instead of the
> plugins directly, and
> 
> 2. make it possible for plugins to install/modify hooks at some
> suitable point in the compilation pipeline.
> 
> I don't know the hooks machinery very well, but if this is feasible it
> seems like it would provide more power (plugins could modify any part of
> GHC for which a hook is available) and avoid having multiple overlapping
> ways of extending GHC. In the future, I can imagine wanting plugins to
> hook into other parts of GHC (e.g. error message postprocessing for
> domain-specific error reporting), and this seems like a good way to
> achieve that.

I think we could merge the TcPlugin type into the existing Plugin type without
much difficulty, but I also agree that combining both plugin types with
Hooks to present a more uniform interface would be nice.

Eric

From marlowsd at gmail.com  Mon Nov 10 18:35:35 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 10 Nov 2014 18:35:35 +0000
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <CAFC_Meg9dT1kxr7ohBvuLGk=envCnwqUixXwDO1ZpGHi7BTG1Q@mail.gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
 <CAOYw7duty5OoX35NJq-mtc=MqyH6T7L9y2DfzHhWQxYAr1n2bg@mail.gmail.com>
 <5458CD34.6040600@gmail.com>
 <CAFC_Meg_UZATRAWKnf5daM5Qo0eCYp6CUPh1fovnC7gVATeQwg@mail.gmail.com>
 <CAFC_Meg9dT1kxr7ohBvuLGk=envCnwqUixXwDO1ZpGHi7BTG1Q@mail.gmail.com>
Message-ID: <54610577.2040909@gmail.com>

On 04/11/2014 15:44, Gintautas Miliauskas wrote:
>
>     I think I have an idea of what's going wrong here. hvr@ was right in
>     pointing out that we need to be careful with the PATH. It seems that
>     the bundled gcc is picking up the system-wide DLLs, and bad things
>     happen because of version incompatibilities. That does not explain
>     why "rm" is crashing, but maybe that's fallout from cross-process
>     damage. I will do some more testing. If this is indeed the cause,
>     then hopefully debugging will not be needed anyway.
>
>
> Update: even after setting PATH to have the embedded gcc path in the
> first position to make sure that the right DLLs are, I still got a few
> segfaults, so this is probably not it.

Is it always GHC that segfaults, or one of the other programs it 
invokes, like gcc?

Have you tried to reproduce this on another machine, to rule out 
hardware problems?

Cheers,
Simon


From iavor.diatchki at gmail.com  Mon Nov 10 19:14:51 2014
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 10 Nov 2014 11:14:51 -0800
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <54608607.2050400@well-typed.com>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
 <54608607.2050400@well-typed.com>
Message-ID: <CAGK9nuozvmRGOm5h3mvo4u_6JuSsunAZpU35V7o-_dx9EofO2w@mail.gmail.com>

Hi,

On Mon, Nov 10, 2014 at 1:31 AM, Adam Gundry <adam at well-typed.com> wrote:

>
> On the subject of that "nearly", I'm interested to learn whether you
> have a suggestion to deal with unflattening, because the interface still
> works with flat constraints only. Simon's changes should make it more
> practical to unflatten inside the plugin, but it would be far easier (at
> least for my purposes) if it was simply given unflattened constraints. I
> realise that this would require the plugin loop to be pushed further
> out, however, which has other difficulties.
>

Not sure what to do about this.  With the current setup, I think either
way, the plugin would have to do some extract work.   Perhaps we should run
the plugins on the unflattened constraints, and leave to the plugins to
manually temporarily "flatten" terms from external theories?  For example,
if the type-nat plugin saw `2 * F a ~ 4`, it could temporarily work with `2
* x ~ 4`, and then when it figures out that `x ~ 2`, it could emit `F a ~
2` (non-canonical), which would go around again, and hopefully get fully
simplified.



> A few other issues, of lesser importance:
>
>  * I still think it would be better to provide an escape hatch to the
> TcS, not merely the TcM, alongside the nice TcPluginM wrapper. Notably,
> Simon's new TcFlatten.unflatten needs TcS...
>
> I don't mind that but, if I recall correctly, to do this without more
recursive modules, we had to split `TCSMonad` in two parts, one with the
types, and one with other stuff.  Eric and I did this once, but we didn't
commit it, because it seemed like an orthogonal change.



>  * Is there a way for my plugin to "solve" a given constraint (e.g. to
> discard the uninformative "a * 1 ~ a")?
>
> Yes, you'd say something like: `TcPluginOK [(evidence, "a * 1 ~ a")] []`

The first field of `TcPluginOK` are things that are solved, the second one
is new work.


>  * It is unfortunately easy to create infinite loops by writing plugins
> that emit wanteds but make no useful progress. Perhaps there should be a
> limit on the number of times round the loop (like SubGoalDepth but for
> all constraints)?
>
>
Indeed, if a plugin keeps generating new work, we could go in a loop, so
maybe a limit of some sort is useful.  However, note that if the plugin
generates things that are already in the inert set, GHC should notice this
and filter them, so we won't keep going.



>  * Perhaps runTcPlugin should skip invoking the plugin if there are no
> wanteds?
>

Oh, there is an important detail here that needs documentation!   GHC will
call the plugin twice: once to improve the givens, and once to solve the
wanteds.   The way to distinguish the two is exactly by the presence of the
wanteds.

Why might you want to improve the givens?  Suppose you had something like
`x * 2 ~ 4` as a given:  then you'd really want the plugin to generate
another given: `x ~ 2`, as this is likely to help the rest of the
constraint solving process.


>  * The use of ctev_evar in runTcPlugin is partial, and fails with a
> nasty error if the plugin returns a non-wanted in the solved constraints
> list. Would it be worth catching this error and issuing a sensible
> message that chastises the plugin author appropriately?
>

Aha, good idea. Bad plugin! :-)


 * Finally, I presume the comment on runTcPlugin that "The plugin is
> provided only with CTyEq and CFunEq constraints" is simply outdated and
> should be removed?
>
> Yep, thanks!


> Apologies for the deluge of questions - please take them as evidence of
> my eagerness to use this feature!
>

Thanks for your feedback!  Also, if you feel like doing some hacking please
do so---I am quite busy at the moment so I don't  have a ton of time to
work on it, so any help you be most appreciated.  I know Eric is also quite
keen on helping out so we can just coordinate over e-mail.

-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141110/217bd44c/attachment-0001.html>

From simonpj at microsoft.com  Mon Nov 10 21:07:58 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 10 Nov 2014 21:07:58 +0000
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <CDF30C0A-FD6D-4C0E-A3BB-A26091618E7C@cis.upenn.edu>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411091554490.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F39E97A@DB3PRD3001MB020.064d.mgd.msft.net>
 <10755CED-C8A8-401D-A7C4-2C59274482F0@cis.upenn.edu>
 <618BE556AADD624C9C918AA5D5911BEF3F39F1EA@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411102202290.2047@galaxy>
 <CDF30C0A-FD6D-4C0E-A3BB-A26091618E7C@cis.upenn.edu>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3A1DF6@DB3PRD3001MB020.064d.mgd.msft.net>

| Instead, let me propose a slight change of shade: put the "required"
| constraints *first* and the "provided" ones *second*. Of course, we could
| leave out the required constraints.

I'm agnostic about this choice at the moment, but I don't understand your points.

| So, continuing the examples from earlier, we have
| 
| > pattern P :: forall a. Num a => forall c. (Eq a, Ord Bool, Show c) => c
| -> Bool -> T a Bool
| > pattern C :: (Eq b, Num b) => () => b -> c -> X Maybe (Maybe b)

In these examples, can you just remind us of which are match-required and which are match-provided?

| - If you write the `forall`s in, the scope builds left to right. In the
| other order, the scoping is very bizarre.

Can you be more explicit?  I don't understand.

| - I think of the "provided" bits + arguments of the constraint as what is
| matched against. The order I propose keeps these pieces together.

Can you give a concrete example?  I don't understand.

| Whatever syntax we choose, I would highly recommend putting in a helpful
| link to more information in error messages.

In principle I like this very much, but I have always stumbled on 
- writing links that will remain stable for ever (and are hence release-specific)
- keeping them up to date when the version changes
- making them easy to test e.g. in my build tree

Separate question really, but would need some systematic attention to make it work properly in general.

Simon

From simonpj at microsoft.com  Mon Nov 10 21:07:55 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 10 Nov 2014 21:07:55 +0000
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <alpine.DEB.2.10.1411102202290.2047@galaxy>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411091554490.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F39E97A@DB3PRD3001MB020.064d.mgd.msft.net>
 <10755CED-C8A8-401D-A7C4-2C59274482F0@cis.upenn.edu>
 <618BE556AADD624C9C918AA5D5911BEF3F39F1EA@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411102202290.2047@galaxy>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3A1DAB@DB3PRD3001MB020.064d.mgd.msft.net>

Well done!  Thanks Gergo.

| -----Original Message-----
| From: Dr. ERDI Gergo [mailto:gergo at erdi.hu]
| Sent: 10 November 2014 14:09
| To: Simon Peyton Jones
| Cc: Richard Eisenberg; GHC Devs
| Subject: RE: Concrete syntax for pattern synonym type signatures
| 
| Good news, I've made the necessary parser breakthrough and I've now got
| 
|      pattern P :: pretty much anything after this point
| 
| to parse as a pattern synonym type signature on a local sub-branch of my
| branch. So no more annoying 'pattern type' nonsense.
| 
| As for the 'pretty much anything' part, I have SPJ's original proposal
| implemented as a proof-of-concept:
| 
|      pattern C :: forall b c. (; Eq b, Num b) => b -> c -> X Maybe (Maybe
| b)
| 
| But I see that the popular opinion now seems to be moving to
| 
|      pattern C :: () => (Eq b, Num b) => b -> c -> X Maybe (Maybe b)
| 
| which should be even easier to implement now, so I hope to finish the
| branch in a couple days (it probably doesn't need more than an evening's
| work now).
| 
| Thanks go out to everyone who contributed in this little syntax
| bikeshedding exercise.
| 
| Bye,
|  	Gergo
| 
| 
| --
| 
|    .--= ULLA! =-----------------.
|     \     http://gergo.erdi.hu   \
|      `---= gergo at erdi.hu =-------'
| Define (n.)  De ting you get for breaking de law.

From simonpj at microsoft.com  Mon Nov 10 21:07:56 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 10 Nov 2014 21:07:56 +0000
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <CAJumaK-GfC7Mi=+z2Prc+tcSUDuO7iRpgMAVDVzdqF9X3=iLfg@mail.gmail.com>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411091554490.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F39E97A@DB3PRD3001MB020.064d.mgd.msft.net>
 <10755CED-C8A8-401D-A7C4-2C59274482F0@cis.upenn.edu>
 <CAJumaK-GfC7Mi=+z2Prc+tcSUDuO7iRpgMAVDVzdqF9X3=iLfg@mail.gmail.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3A1DC1@DB3PRD3001MB020.064d.mgd.msft.net>

Note though, it doesn't mean the same thing to say (Foo a, Bar a b) => ... as it does to say
Foo a => Bar a b => ...
The latter can use Foo a when working on Bar a b, but not Bar a b to discharge Foo a, which makes a difference when you have functional dependencies.

I disagree.  Can you offer a concrete example, and show that one typechecks when the other does not?

Simon

From: Edward Kmett [mailto:ekmett at gmail.com]
Sent: 10 November 2014 15:46
To: Richard Eisenberg
Cc: Simon Peyton Jones; GHC Devs
Subject: Re: Concrete syntax for pattern synonym type signatures

Note though, it doesn't mean the same thing to say (Foo a, Bar a b) => ... as it does to say

Foo a => Bar a b => ...

The latter can use Foo a when working on Bar a b, but not Bar a b to discharge Foo a, which makes a difference when you have functional dependencies.

So in some sense the 'pattern requires/supplies' split is just that.



That said, Richard's other option

pattern Foo a => P :: Bar a => a

has the benefit that it looks a bit like the old datatype contexts (but here applied to the constructor/pattern).

If we expect the left hand side or the right hand side to be most often trivial then that may be worth considering.

You'd occasionally have things like

pattern (Num a, Eq a) => Foo :: a

for

pattern Foo = 8

but most of the time they'd wind up just looking like a GADT constructor.

-Edward

On Sun, Nov 9, 2014 at 10:02 PM, Richard Eisenberg <eir at cis.upenn.edu<mailto:eir at cis.upenn.edu>> wrote:

On Nov 9, 2014, at 2:11 PM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
>
> * One other possibility would be two => thus
>       pattern P :: (Eq b) => (Num a, Eq a) => ...blha...
>

I should note that I can say this in 7.8.3:

foo :: Show a => Eq a => a -> String
foo x = show x ++ show (x == x)

Note that I've separated the two constraints with a =>, not a comma. This syntax does what you might expect. (I actually believe that this is an improvement over the conventional syntax, but that's a story for another day.) For better or worse, this trick does not work for GADT constructors (which is a weird incongruence with function type signatures), so adding the extra arrow does not really steal syntax from GADT pattern synonyms.

Richard
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://www.haskell.org/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141110/f272b31c/attachment-0001.html>

From gintautas.miliauskas at gmail.com  Mon Nov 10 22:59:33 2014
From: gintautas.miliauskas at gmail.com (Gintautas Miliauskas)
Date: Mon, 10 Nov 2014 23:59:33 +0100
Subject: [Msys2-users] Debugging undeterministic segfaults
In-Reply-To: <5460A07C.2070309@gmail.com>
References: <CAFC_Meh=ZxMJc52+j=KOJxqX0zEx-JZY418r8HWG8A9Z+9s-9w@mail.gmail.com>
 <CAOYw7dtrF4MwuRwA=36TmMaHVc0nqQ5HLLpJ8sOe==iBbQKUig@mail.gmail.com>
 <CAFC_MegFkoPYX5-sjifqMRUPuJbHKMy6rOAdVcSZLx7juvQZ1g@mail.gmail.com>
 <CAOYw7duty5OoX35NJq-mtc=MqyH6T7L9y2DfzHhWQxYAr1n2bg@mail.gmail.com>
 <5458CD34.6040600@gmail.com>
 <CAFC_Meg_UZATRAWKnf5daM5Qo0eCYp6CUPh1fovnC7gVATeQwg@mail.gmail.com>
 <5458EC7D.3080008@gmail.com>
 <CAFC_Meiy4REPCsKyYmZDSLsEZq-CY5RSTaPb4k1SL2EFH7Wzqw@mail.gmail.com>
 <54591E58.2060002@gmail.com>
 <CAFC_MehHXa2i2DeZLH_Oa2trFz+HWAh6ADoy1a9kb3fb8KT9=g@mail.gmail.com>
 <545951CB.8040604@gmail.com> <5459CB60.2080807@gmail.com>
 <5459FDBF.8070405@gmail.com>
 <CAFC_Meh+y9O1rdHWWjT8EDB0kWhFbDLSJT88kYBAEMbzh=ObdA@mail.gmail.com>
 <CAFC_MejuO-P=0G4+uS=JUhrn9Zmif5gqHMTrPq9O17j00j6-ug@mail.gmail.com>
 <5460A07C.2070309@gmail.com>
Message-ID: <CAFC_MegCA0EHpq3WBNmpHVsshDLrMr4cU4tAQzyQGSyDGL5wyA@mail.gmail.com>

Hey,

I'm on vacation right now without access to my workstation, I will be back
in a couple weeks.

I believe hvr@ was having some stability issues too, maybe he can help
reproduce the problem?

Thanks for looking into this.

-- 
Gintautas Miliauskas
On Nov 10, 2014 6:24 PM, "David Macek" <david.macek.0 at gmail.com> wrote:

> On 5. 11. 2014 18:13, Gintautas Miliauskas wrote:
> >
> >
> >     Thanks for pointing out that virus scanners could be an issue. I
> found that Microsoft Security Essentials realtime scanning was on. I'll try
> disabling it and see if that helps with the -j5 case.
> >
> >
> > For what it's worth, I tried disabling the virus scanner, but it did not
> help, 4/8 validation runs segfaulted (-j5).
>
> Can you dump your package versions here? Use pacman -Qe. I want to try the
> build with a replica of your environment.
>
> Also, does 4/8 mean that some builds were without errors? Maybe I haven't
> done enough runs. Could you attach the script you use for running validate
> in a loop? (I'm sure it's simple enough for me to write it, but if I can
> avoid it...)
>
> --
> David Macek
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141110/bce1214d/attachment.html>

From eric at seidel.io  Tue Nov 11 03:08:31 2014
From: eric at seidel.io (Eric Seidel)
Date: Mon, 10 Nov 2014 19:08:31 -0800
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <CAEs96n2fA95K_y=T8F3Lherf7vYjidMRGj_MHFPsN3JktJyPsA@mail.gmail.com>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
 <CAEs96n2fA95K_y=T8F3Lherf7vYjidMRGj_MHFPsN3JktJyPsA@mail.gmail.com>
Message-ID: <C4025F47-4D59-4070-9EC4-4CD97AC4C54E@seidel.io>


> On Nov 10, 2014, at 07:58, Austin Seipp <austin at well-typed.com> wrote:
> 
> Hi Iavor;
> 
> I took a very, very cursory glance. Naturally I am not a typechecker
> guru, but I did look over the mechanical changes/extensions to thread
> things around. Two things popped out to me:
> 
> - 1) Ugh, a new .hs-boot file. I assume this wasn't added without
> good reason, but ideally we would be eliminating them quicker than we
> add them. :) I want to take a closer look at this; perhaps we can
> refactor something for you to remove the need for this.
> 
> - 2) I am kind of not a fan of having separate 'plugins for
> core2core' and 'plugins for typechecking' flags, AKA -ftc-plugin and
> -fplugin. Ideally I would think all plugins could be uniformly
> specified by simply saying '-fplugin'. This mostly avoids the need for
> duplication and a naming convention/slew of flags for each case (which
> we have to catalog and document). There may be an easy way to make
> this the case; I haven't looked closely yet (it has been some time
> since I starred at the plugin code, even though Max wrote it and I
> helped get it merged!)

I looked into this again a bit today and recall now why we made a separate
Plugin type and flag; adding the TcPlugin to the existing Plugin type defined
in CoreMonad creates a circular dependency between CoreMonad and TcRnTypes.

We could (and perhaps should) move all of the plugin types into a separate
module, but that would require pulling other types (e.g. CoreToDo) out of
CoreMonad to break the circularity.

From marlowsd at gmail.com  Tue Nov 11 08:38:02 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 11 Nov 2014 08:38:02 +0000
Subject: [GHC] #9741: Interpreter stack checks are not quite right
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3972BF@DB3PRD3001MB020.064d.mgd.msft.net>
References: <046.3063371461063dd3b4b1c60903b205f1@haskell.org>
 <061.c9b25321d9587be7d727c9c3fb7b3660@haskell.org>
 <618BE556AADD624C9C918AA5D5911BEF3F3972BF@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <5461CAEA.3090500@gmail.com>

On 06/11/2014 09:56, Simon Peyton Jones wrote:
> |   Oh, and the reason you have the debug RTS in your compiler is because
> |  `-ticky` implies `-debug
>
> Interesting.  I didn't know that.  Is that a good idea? Wouldn't it be better to make them independent?

See #3439, as you'll note it was your idea too :)

The alternative is worse: if they were separate, then we have to 
multiply the number of variants of the RTS we currently have by two 
(non-ticky and ticky).  We currently build 6-8 versions of the RTS 
depending on whether you have profiling on, and if ticky were a separate 
option it would double that number.  You could choose not to build some 
of the combinations, but then you might be surprised when -ticky doesn't 
work with some other option.

The other part of the rationale is that if you're using -ticky then 
you're already taking a performance hit from the counters, so adding 
more overhead, in the form of the extra checks that -debug does, doesn't 
hurt.

Cheers,
Simon


> Simon
>
> |  -----Original Message-----
> |  From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf
> |  Of GHC
> |  Sent: 06 November 2014 08:37
> |  Cc: ghc-tickets at haskell.org
> |  Subject: Re: [GHC] #9741: Interpreter stack checks are not quite right
> |
> |  #9741: Interpreter stack checks are not quite right
> |  -------------------------------------+--------------------------------
> |  --
> |  -------------------------------------+---
> |                Reporter:  simonpj     |            Owner:  simonmar
> |                    Type:  bug         |           Status:  closed
> |                Priority:  highest     |        Milestone:  7.10.1
> |               Component:  Compiler    |          Version:  7.8.3
> |              Resolution:  fixed       |         Keywords:
> |        Operating System:              |     Architecture:
> |  Unknown/Multiple
> |    Unknown/Multiple                   |       Difficulty:  Unknown
> |         Type of failure:              |       Blocked By:
> |    None/Unknown                       |  Related Tickets:
> |               Test Case:              |
> |                Blocking:              |
> |  Differential Revisions:              |
> |  -------------------------------------+--------------------------------
> |  --
> |  -------------------------------------+---
> |
> |  Comment (by simonmar):
> |
> |   Oh, and the reason you have the debug RTS in your compiler is because
> |  `-ticky` implies `-debug`.  Incidentally this is probably slowing down
> |  your builds quite a lot, so you might want to turn it off.
> |
> |  --
> |  Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9741#comment:5>
> |  GHC <http://www.haskell.org/ghc/>
> |  The Glasgow Haskell Compiler
> |  _______________________________________________
> |  ghc-tickets mailing list
> |  ghc-tickets at haskell.org
> |  http://www.haskell.org/mailman/listinfo/ghc-tickets
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From ky3 at atamo.com  Tue Nov 11 08:56:12 2014
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Tue, 11 Nov 2014 15:56:12 +0700
Subject: [GHC] #9781: Make list monad operations fuse
Message-ID: <CAPY+ZdTjXnFU1x6UCA=5u5tmnMkAxsnLu_gycRp4wSG8ufCD7Q@mail.gmail.com>

>From the patch fragment at

https://phabricator.haskell.org/D455?id=1311#inline-3123

What's the justification for expanding out the definition of mapM from
"sequence . map f" into do-notation and duplicated code?

Observe how mapM now duplicates code from sequence.

The absence of benchmarks is bad enough. What's worse is that the given
excuse boils down to "Pity the poor compiler! Let's take over its work
instead. Like, just in case, you know."

This optimization work needs to take place at a higher level, with deep
understanding of existing compiler transformations. Otherwise, it's all a
code-muddying crapshoot in the dark.

-- Kim-Ee

On Tue, Nov 11, 2014 at 2:22 PM, GHC <ghc-devs at haskell.org> wrote:

> #9781: Make list monad operations fuse
> -------------------------------------+-------------------------------------
>               Reporter:  dfeuer      |            Owner:  dfeuer
>                   Type:  task        |           Status:  patch
>               Priority:  normal      |        Milestone:  7.10.1
>              Component:  Core        |          Version:  7.9
>   Libraries                          |         Keywords:
>             Resolution:              |     Architecture:  Unknown/Multiple
>       Operating System:              |       Difficulty:  Unknown
>   Unknown/Multiple                   |       Blocked By:
>        Type of failure:  Runtime     |  Related Tickets:
>   performance bug                    |
>              Test Case:              |
>               Blocking:              |
> Differential Revisions:  Phab:D455   |
> -------------------------------------+-------------------------------------
>
> Comment (by Herbert Valerio Riedel <hvr@?>):
>
>  In [changeset:"4923cea56345060faaf77e4c475eac6aa3c77506/ghc"]:
>  {{{
>  #!CommitTicketReference repository="ghc"
>  revision="4923cea56345060faaf77e4c475eac6aa3c77506"
>  Define list monad operations using comprehensions
>
>  Define list monad operations using list comprehensions. Code using monad
>  operations with lists did not fuse fully. Writing list code with `do`
>  notation or `(>>=)` and `(>>)` operations could allocate more than
>  equivalent code using list comprehensions.
>
>  Define `mapM` directly, instead of using `sequence` and `map`. This
>  leads to substantially less allocation in `cryptarithm2`.
>
>  Addresses #9781
>
>  Reviewed By: ekmett, nomeata
>
>  Differential Revision: https://phabricator.haskell.org/D455
>  }}}
>
> --
> Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9781#comment:4>
> GHC <http://www.haskell.org/ghc/>
> The Glasgow Haskell Compiler
> _______________________________________________
> ghc-tickets mailing list
> ghc-tickets at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-tickets
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141111/5a8d8399/attachment.html>

From david.feuer at gmail.com  Tue Nov 11 09:12:14 2014
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 11 Nov 2014 04:12:14 -0500
Subject: [GHC] #9781: Make list monad operations fuse
In-Reply-To: <CAPY+ZdTjXnFU1x6UCA=5u5tmnMkAxsnLu_gycRp4wSG8ufCD7Q@mail.gmail.com>
References: <CAPY+ZdTjXnFU1x6UCA=5u5tmnMkAxsnLu_gycRp4wSG8ufCD7Q@mail.gmail.com>
Message-ID: <CAMgWh9twO6QX6-eZQ-pBW8dt-BCto1qwrZ-D4fQ1MoSSq6jQwQ@mail.gmail.com>

On Nov 11, 2014 3:56 AM, "Kim-Ee Yeoh" <ky3 at atamo.com> wrote:
>
> From the patch fragment at
>
> https://phabricator.haskell.org/D455?id=1311#inline-3123
>
> What's the justification for expanding out the definition of mapM from
"sequence . map f" into do-notation and duplicated code?
>
> Observe how mapM now duplicates code from sequence.

One good option might be to redefine sequence in terms of mapM.

> The absence of benchmarks is bad enough. What's worse is that the given
excuse boils down to "Pity the poor compiler! Let's take over its work
instead. Like, just in case, you know."

The excuse is that it actually makes a big difference for nofib. Why? I
would have to guess it relates to what inlines when. The inliner is a
finicky beast. In response to your insults, I will say that although GHC
has beautiful ideas in it, a lot of the details of the optimization passes
and how they fit together *are* a bit of a crapshoot, chosen by benchmarks
rather than theory. Theory sometimes comes up behind and explains why the
benchmarks do what they do, but you can't expect every little change to be
backed up by some deep theoretical reason.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141111/bdf03ec9/attachment-0001.html>

From simonpj at microsoft.com  Tue Nov 11 10:45:02 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 11 Nov 2014 10:45:02 +0000
Subject: [commit: ghc] master: Define list monad operations using
 comprehensions (4923cea)
In-Reply-To: <20141111072237.C184F3A300@ghc.haskell.org>
References: <20141111072237.C184F3A300@ghc.haskell.org>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3A3491@DB3PRD3001MB020.064d.mgd.msft.net>

The "Note" doesn't mention one of the main points, which is (if I understand rightly) to improve fusion.

Would it be wotth making this point, and giving an example in the Note?

Simon

|  -----Original Message-----
|  From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf
|  Of git at git.haskell.org
|  Sent: 11 November 2014 07:23
|  To: ghc-commits at haskell.org
|  Subject: [commit: ghc] master: Define list monad operations using
|  comprehensions (4923cea)
|  
|  Repository : ssh://git at git.haskell.org/ghc
|  
|  On branch  : master
|  Link       :
|  http://ghc.haskell.org/trac/ghc/changeset/4923cea56345060faaf77e4c475e
|  ac6aa3c77506/ghc
|  
|  >---------------------------------------------------------------
|  
|  commit 4923cea56345060faaf77e4c475eac6aa3c77506
|  Author: David Feuer <David.Feuer at gmail.com>
|  Date:   Tue Nov 11 07:59:34 2014 +0100
|  
|      Define list monad operations using comprehensions
|  
|      Define list monad operations using list comprehensions. Code using
|  monad
|      operations with lists did not fuse fully. Writing list code with
|  `do`
|      notation or `(>>=)` and `(>>)` operations could allocate more than
|      equivalent code using list comprehensions.
|  
|      Define `mapM` directly, instead of using `sequence` and `map`.
|  This
|      leads to substantially less allocation in `cryptarithm2`.
|  
|      Addresses #9781
|  
|      Reviewed By: ekmett, nomeata
|  
|      Differential Revision: https://phabricator.haskell.org/D455
|  
|  
|  >---------------------------------------------------------------
|  
|  4923cea56345060faaf77e4c475eac6aa3c77506
|   libraries/base/GHC/Base.hs | 51
|  +++++++++++++++++++++++++++++++++++++++-------
|   1 file changed, 44 insertions(+), 7 deletions(-)
|  
|  diff --git a/libraries/base/GHC/Base.hs b/libraries/base/GHC/Base.hs
|  index 501a6d5..0d20e34 100644
|  --- a/libraries/base/GHC/Base.hs
|  +++ b/libraries/base/GHC/Base.hs
|  @@ -225,8 +225,32 @@ class Monoid a where
|           mconcat = foldr mappend mempty
|  
|   instance Monoid [a] where
|  +        {-# INLINE mempty #-}
|           mempty  = []
|  +        {-# INLINE mappend #-}
|           mappend = (++)
|  +        {-# INLINE mconcat #-}
|  +        mconcat xss = [x | xs <- xss, x <- xs]
|  +-- See Note: [List comprehensions and inlining]
|  +
|  +{-
|  +Note: [List comprehensions and inlining]
|  +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|  +The list monad operations are traditionally described in terms of
|  concatMap:
|  +
|  +xs >>= f = concatMap f xs
|  +
|  +Similarly, mconcat for lists is just concat. Here in Base, however,
|  we
|  +don't have concatMap, and we'll refrain from adding it here so it
|  won't
|  +have to be hidden in imports. Instead, we use GHC's list
|  comprehension
|  +desugaring mechanism to define mconcat and the Applicative and Monad
|  instances for lists.
|  +We mark them INLINE because the inliner is not generally too keen to
|  +inline build forms such as the ones these desugar to without our
|  +insistence.  Defining these using list comprehensions instead of
|  foldr
|  +has an additional potential benefit, as described in
|  +compiler/deSugar/DsListComp.lhs: if optimizations needed to make
|  +foldr/build forms efficient are turned off, we'll get reasonably
|  efficient translations anyway.
|  +-}
|  
|   instance Monoid b => Monoid (a -> b) where
|           mempty _ = mempty
|  @@ -501,7 +525,9 @@ sequence ms = foldr k (return []) ms
|   -- | @'mapM' f@ is equivalent to @'sequence' . 'map' f at .
|   mapM :: Monad m => (a -> m b) -> [a] -> m [b]  {-# INLINE mapM #-}
|  -mapM f as       =  sequence (map f as)
|  +mapM f as = foldr k (return []) as
|  +            where
|  +              k a r = do { x <- f a; xs <- r; return (x:xs) }
|  
|   -- | Promote a function to a monad.
|   liftM   :: (Monad m) => (a1 -> r) -> m a1 -> m r
|  @@ -667,16 +693,27 @@ instance MonadPlus Maybe
|   -- The list type
|  
|   instance Functor [] where
|  +    {-# INLINE fmap #-}
|       fmap = map
|  
|  +-- See Note: [List comprehensions and inlining]
|   instance Applicative [] where
|  -    pure = return
|  -    (<*>) = ap
|  -
|  -instance  Monad []  where
|  -    m >>= k             = foldr ((++) . k) [] m
|  -    m >> k              = foldr ((++) . (\ _ -> k)) [] m
|  +    {-# INLINE pure #-}
|  +    pure x    = [x]
|  +    {-# INLINE (<*>) #-}
|  +    fs <*> xs = [f x | f <- fs, x <- xs]
|  +    {-# INLINE (*>) #-}
|  +    xs *> ys  = [y | _ <- xs, y <- ys]
|  +
|  +-- See Note: [List comprehensions and inlining] instance Monad []
|  +where
|  +    {-# INLINE (>>=) #-}
|  +    xs >>= f             = [y | x <- xs, y <- f x]
|  +    {-# INLINE (>>) #-}
|  +    (>>) = (*>)
|  +    {-# INLINE return #-}
|       return x            = [x]
|  +    {-# INLINE fail #-}
|       fail _              = []
|  
|   instance Alternative [] where
|  
|  _______________________________________________
|  ghc-commits mailing list
|  ghc-commits at haskell.org
|  http://www.haskell.org/mailman/listinfo/ghc-commits

From simonpj at microsoft.com  Tue Nov 11 11:03:35 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 11 Nov 2014 11:03:35 +0000
Subject: [GHC] #9781: Make list monad operations fuse
In-Reply-To: <CAMgWh9twO6QX6-eZQ-pBW8dt-BCto1qwrZ-D4fQ1MoSSq6jQwQ@mail.gmail.com>
References: <CAPY+ZdTjXnFU1x6UCA=5u5tmnMkAxsnLu_gycRp4wSG8ufCD7Q@mail.gmail.com>
 <CAMgWh9twO6QX6-eZQ-pBW8dt-BCto1qwrZ-D4fQ1MoSSq6jQwQ@mail.gmail.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3A34FE@DB3PRD3001MB020.064d.mgd.msft.net>

The inliner is a finicky beast. In response to your insults, I will say that although GHC has beautiful ideas in it, a lot of the details of the optimization passes and how they fit together *are* a bit of a crapshoot, chosen by benchmarks rather than theory.

It?s true that, particularly for fusion, inlining can make a huge difference.  And GHC really does need help? it?s extremely hard for it to make the ?right? choice all the time.

I strongly agree with Kim-Ee that we should play the game of ?optimise by randomly mutating the program and pick the version that (today) happens to run faster?.  But I don?t think David is doing that.   There is, at least a Note: [List comprehensions and inlining].

What we should do is to

?         understand which the crucial inlining decisions are, and why

?         express that understanding in a Note, so that subsequent people looking at the code also understand

?         remove any un-necessary code cruft, which sometimes accumulates during a period of experimentation, leaving the minimum necessary to achieve the effect

I?m not quite certain that all these steps have been done here, and they can be tiresome to do.  But worth it!

Simon

From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of David Feuer
Sent: 11 November 2014 09:12
To: Kim-Ee Yeoh
Cc: Haskell Libraries; ghc-devs
Subject: Re: [GHC] #9781: Make list monad operations fuse


On Nov 11, 2014 3:56 AM, "Kim-Ee Yeoh" <ky3 at atamo.com<mailto:ky3 at atamo.com>> wrote:
>
> From the patch fragment at
>
> https://phabricator.haskell.org/D455?id=1311#inline-3123
>
> What's the justification for expanding out the definition of mapM from "sequence . map f" into do-notation and duplicated code?
>
> Observe how mapM now duplicates code from sequence.

One good option might be to redefine sequence in terms of mapM.

> The absence of benchmarks is bad enough. What's worse is that the given excuse boils down to "Pity the poor compiler! Let's take over its work instead. Like, just in case, you know."

The excuse is that it actually makes a big difference for nofib. Why? I would have to guess it relates to what inlines when. The inliner is a finicky beast. In response to your insults, I will say that although GHC has beautiful ideas in it, a lot of the details of the optimization passes and how they fit together *are* a bit of a crapshoot, chosen by benchmarks rather than theory. Theory sometimes comes up behind and explains why the benchmarks do what they do, but you can't expect every little change to be backed up by some deep theoretical reason.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141111/a05b3be2/attachment-0001.html>

From adam at well-typed.com  Tue Nov 11 12:19:03 2014
From: adam at well-typed.com (Adam Gundry)
Date: Tue, 11 Nov 2014 12:19:03 +0000
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <C4025F47-4D59-4070-9EC4-4CD97AC4C54E@seidel.io>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
 <CAEs96n2fA95K_y=T8F3Lherf7vYjidMRGj_MHFPsN3JktJyPsA@mail.gmail.com>
 <C4025F47-4D59-4070-9EC4-4CD97AC4C54E@seidel.io>
Message-ID: <5461FEB7.7080707@well-typed.com>

I've just pushed wip/tc-plugins-amg, in which I remove the hs-boot file
and unify the core2core and typechecker plugins under a single -fplugin
flag. This did involve making a separate module for plugins, which I
think is probably a good thing.

I looked at using a hook instead, with a plugin to modify hooks, but I'm
not sure exactly where such a plugin should be invoked. Ideally we want
the typechecker modifications to work on a per-module basis, but most of
the hooks seem to have a wider scope than that.

Adam


On 11/11/14 03:08, Eric Seidel wrote:
> 
>> On Nov 10, 2014, at 07:58, Austin Seipp <austin at well-typed.com> wrote:
>>
>> Hi Iavor;
>>
>> I took a very, very cursory glance. Naturally I am not a typechecker
>> guru, but I did look over the mechanical changes/extensions to thread
>> things around. Two things popped out to me:
>>
>> - 1) Ugh, a new .hs-boot file. I assume this wasn't added without
>> good reason, but ideally we would be eliminating them quicker than we
>> add them. :) I want to take a closer look at this; perhaps we can
>> refactor something for you to remove the need for this.
>>
>> - 2) I am kind of not a fan of having separate 'plugins for
>> core2core' and 'plugins for typechecking' flags, AKA -ftc-plugin and
>> -fplugin. Ideally I would think all plugins could be uniformly
>> specified by simply saying '-fplugin'. This mostly avoids the need for
>> duplication and a naming convention/slew of flags for each case (which
>> we have to catalog and document). There may be an easy way to make
>> this the case; I haven't looked closely yet (it has been some time
>> since I starred at the plugin code, even though Max wrote it and I
>> helped get it merged!)
> 
> I looked into this again a bit today and recall now why we made a separate
> Plugin type and flag; adding the TcPlugin to the existing Plugin type defined
> in CoreMonad creates a circular dependency between CoreMonad and TcRnTypes.
> 
> We could (and perhaps should) move all of the plugin types into a separate
> module, but that would require pulling other types (e.g. CoreToDo) out of
> CoreMonad to break the circularity.



-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From simonpj at microsoft.com  Tue Nov 11 14:13:03 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 11 Nov 2014 14:13:03 +0000
Subject: let/app invariant violated by code generated with mkCoreApp
In-Reply-To: <alpine.DEB.2.10.1411082154270.2047@galaxy>
References: <alpine.DEB.2.10.1411082154270.2047@galaxy>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3A3E7F@DB3PRD3001MB020.064d.mgd.msft.net>

Oh bother, that is _so_ tiresome. The desugarer establishes the let/app invariant, so we get

	I# x_help

but if x_help has a compulsory unfolding to (x void), returning an Int#, that violates the let/app invariant.  Sigh.  This is a ridiculous amount of work for a tiny corner (pattern synonyms for unboxed constants).

Harump.  Let's see.  We are talking only of things like this

	pattern P = 4#

correct?  Perhaps it may be simpler to make the psWrapper in PatSyn be
	psWrapper :: Either Id Literal
and treat such patterns specially from the moment we first see them?  That would eliminate all this void stuff entirely.

Pursuing the current line, though, I suppose that the desugarer could inline compulsory unfoldings during desugaring itself.  In this line, add a case for when var has a compulsory unfolding.

dsExpr (HsVar var)            = return (varToCoreExpr var)   -- See Note [Desugaring vars]

That would, I suppose, be the quickest pathc.

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Dr.
|  ERDI Gergo
|  Sent: 08 November 2014 14:03
|  To: GHC Devs
|  Subject: let/app invariant violated by code generated with mkCoreApp
|  
|  Hi,
|  
|  I'm trying to attach (f Void#) as a compulsory unfolding to an Id.
|  Here's what I tried originally:
|  
|       let unfolding = mkCoreApp (Var worker_id) (Var voidPrimId)
|           wrapper_id' = setIdUnfolding wrapper_id $
|  mkCompulsoryUnfolding unfolding
|  
|  However, when I try to use wrapper_id' in the desugarer, the Core
|  linter looks at me strange. This is the original Core:
|  
|  f :: Int
|  [LclIdX, Str=DmdType]
|  f = break<1>() GHC.Types.I# Main.$WPAT
|  
|  and this is the error message ($WPAT is the wrapper_id', PAT is the
|  worker_id in this example)
|  
|  <no location info>: Warning:
|       In the expression: I# (PAT void#)
|       This argument does not satisfy the let/app invariant: PAT void#
|  
|  Now, I thought I'd make sure mkCoreApp generated correct Core by
|  writing it out by hand:
|  
|       let unfolding = Case (Var voidPrimId) voidArgId pat_ty
|  [(DEFAULT,[],App (Var worker_id) (Var voidArgId))]
|  
|  however, bizarrely, this *still* results in *the same* error message,
|  as if something was transforming it back to a straight App.
|  
|  Anyone have any hints what I'm doing wrong here?
|  
|  Bye,
|   	Gergo
|  
|  --
|  
|     .--= ULLA! =-----------------.
|      \     http://gergo.erdi.hu   \
|       `---= gergo at erdi.hu =-------'
|  You are in a twisty maze of little install diskettes.
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  http://www.haskell.org/mailman/listinfo/ghc-devs

From eir at cis.upenn.edu  Tue Nov 11 15:44:25 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 11 Nov 2014 10:44:25 -0500
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3A1DF6@DB3PRD3001MB020.064d.mgd.msft.net>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411091554490.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F39E97A@DB3PRD3001MB020.064d.mgd.msft.net>
 <10755CED-C8A8-401D-A7C4-2C59274482F0@cis.upenn.edu>
 <618BE556AADD624C9C918AA5D5911BEF3F39F1EA@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411102202290.2047@galaxy>
 <CDF30C0A-FD6D-4C0E-A3BB-A26091618E7C@cis.upenn.edu>
 <618BE556AADD624C9C918AA5D5911BEF3F3A1DF6@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <46644962-C0B2-4333-A5E3-4FA34DF3630D@cis.upenn.edu>

Let me restate the proposals more concretely. Correct me if I'm wrong!

Suppose we have the following declarations:

   data T a b where
     MkT :: (Eq a, Ord b, Show c) => a -> (b, b) -> c -> T a b

   pattern P x y = MkT 5 (y, True) x

What is the type of P?

Simon's proposal:

> pattern P :: (Eq a, Ord Bool, Show c) => (Num a) => c -> Bool -> T a Bool

Or, more generally:

> pattern <pat> :: <provided constraints> => <required constraints> => <matched args> -> <result type>


My proposal:

> pattern P :: (Num a) => (Eq a, Ord Bool, Show c) => c -> Bool -> T a Bool

Or, more generally:

> pattern <pat> :: <required constraints> => <provided constraints> => <matched args> -> <result type>

The only difference is the order of required vs. provided constraints.


My previous comment about bizarre scoping is that the universal variables -- which (in my opinion) go with the required constraints -- scope over both sets of constraints. The existential variables go with the provided constraints and scope over only the provided constraints. So, Simon's ordering means that the scope of the second (lexically) listed constraints have a *smaller* scope than the first listed constraints. With my ordering, the size of the scope increases as you read to the right, as it normally does.

On Nov 10, 2014, at 4:07 PM, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> | Whatever syntax we choose, I would highly recommend putting in a helpful
> | link to more information in error messages.
> 
> In principle I like this very much, but I have always stumbled on 
> - writing links that will remain stable for ever (and are hence release-specific)
> - keeping them up to date when the version changes
> - making them easy to test e.g. in my build tree
> 
> Separate question really, but would need some systematic attention to make it work properly in general.

Is there a way of pulling the version from DynFlags? If so, it would be easy to include the version number in an SDoc. Then, we could make the link go to the user manual. It would be easy to write a function `userManualLink :: String -> SDoc` that takes the last bit of the link and produces a link to the manual for the version at hand. (It wouldn't work for non-released versions, but I'm OK with that.) 

Richard


From ekmett at gmail.com  Tue Nov 11 16:41:42 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 11 Nov 2014 11:41:42 -0500
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3A1DC1@DB3PRD3001MB020.064d.mgd.msft.net>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411091554490.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F39E97A@DB3PRD3001MB020.064d.mgd.msft.net>
 <10755CED-C8A8-401D-A7C4-2C59274482F0@cis.upenn.edu>
 <CAJumaK-GfC7Mi=+z2Prc+tcSUDuO7iRpgMAVDVzdqF9X3=iLfg@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3A1DC1@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CAJumaK8bfTanuqc67rBF6UUhC5_4L4Ex6AS0UfAoo6SgPvJN0w@mail.gmail.com>

Lamely, I can't seem to reconstruct the problem.

GHC seems to be more careful about gathering the constraints up into a
tuple even when I give an explicit type signature involving nested contexts
nowadays.

-Edward

On Mon, Nov 10, 2014 at 4:07 PM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

>   Note though, it doesn't mean the same thing to say (Foo a, Bar a b) =>
> ... as it does to say
>
> Foo a => Bar a b => ...
>
> The latter can use Foo a when working on Bar a b, but not Bar a b to
> discharge Foo a, which makes a difference when you have functional
> dependencies.
>
>
>
> I disagree.  Can you offer a concrete example, and show that one
> typechecks when the other does not?
>
>
>
> Simon
>
>
>
> *From:* Edward Kmett [mailto:ekmett at gmail.com]
> *Sent:* 10 November 2014 15:46
> *To:* Richard Eisenberg
> *Cc:* Simon Peyton Jones; GHC Devs
> *Subject:* Re: Concrete syntax for pattern synonym type signatures
>
>
>
> Note though, it doesn't mean the same thing to say (Foo a, Bar a b) => ...
> as it does to say
>
>
>
> Foo a => Bar a b => ...
>
>
>
> The latter can use Foo a when working on Bar a b, but not Bar a b to
> discharge Foo a, which makes a difference when you have functional
> dependencies.
>
>
>
> So in some sense the 'pattern requires/supplies' split is just that.
>
>
>
>
>
>
>
> That said, Richard's other option
>
>
>
> pattern Foo a => P :: Bar a => a
>
>
>
> has the benefit that it looks a bit like the old datatype contexts (but
> here applied to the constructor/pattern).
>
>
>
> If we expect the left hand side or the right hand side to be most often
> trivial then that may be worth considering.
>
>
>
> You'd occasionally have things like
>
>
>
> pattern (Num a, Eq a) => Foo :: a
>
>
>
> for
>
>
>
> pattern Foo = 8
>
>
>
> but most of the time they'd wind up just looking like a GADT constructor.
>
>
>
> -Edward
>
>
>
> On Sun, Nov 9, 2014 at 10:02 PM, Richard Eisenberg <eir at cis.upenn.edu>
> wrote:
>
>
> On Nov 9, 2014, at 2:11 PM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
> >
> > * One other possibility would be two => thus
> >       pattern P :: (Eq b) => (Num a, Eq a) => ...blha...
> >
>
> I should note that I can say this in 7.8.3:
>
> foo :: Show a => Eq a => a -> String
> foo x = show x ++ show (x == x)
>
> Note that I've separated the two constraints with a =>, not a comma. This
> syntax does what you might expect. (I actually believe that this is an
> improvement over the conventional syntax, but that's a story for another
> day.) For better or worse, this trick does not work for GADT constructors
> (which is a weird incongruence with function type signatures), so adding
> the extra arrow does not really steal syntax from GADT pattern synonyms.
>
> Richard
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141111/e5b28b0c/attachment-0001.html>

From david.feuer at gmail.com  Tue Nov 11 16:54:15 2014
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 11 Nov 2014 11:54:15 -0500
Subject: [GHC] #9781: Make list monad operations fuse
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3A34FE@DB3PRD3001MB020.064d.mgd.msft.net>
References: <CAPY+ZdTjXnFU1x6UCA=5u5tmnMkAxsnLu_gycRp4wSG8ufCD7Q@mail.gmail.com>
 <CAMgWh9twO6QX6-eZQ-pBW8dt-BCto1qwrZ-D4fQ1MoSSq6jQwQ@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3A34FE@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CAMgWh9tjixD0oNf8nnsRKhet56euGA20FUbaBA3Cven06uRWhw@mail.gmail.com>

On Nov 11, 2014 6:04 AM, "Simon Peyton Jones" <simonpj at microsoft.com> wrote:
> It?s true that, particularly for fusion, inlining can make a huge
difference.  And GHC really does need help? it?s extremely hard for it to
make the ?right? choice all the time.

The inliner does indeed do amazing things, and list fusion does indeed do
lovely things for user code. It's just not the most *reliable* optimization
in the compiler. I don't think there's anything wrong with admitting that
and trying to avoid relying on it too heavily in *library* code. Kim-Ee was
right that expanding out mapM by hand bloated the source. I've since
defined `sequence=mapM id` to resolve that problem, and doing so does not
hurt the benchmarks?it relies only on inlining id (which is quite reliable)
and beta-reducing (which is also quite reliable).

> I strongly agree with Kim-Ee that we should play the game of ?optimise by
randomly mutating the program and pick the version that (today) happens to
run faster?.  But I don?t think David is doing that.   There is, at least a
Note: [List comprehensions and inlining].

I've been trying to leave a trail of comments and notes as I go. I may need
to go further.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141111/28f6990c/attachment.html>

From simonpj at microsoft.com  Tue Nov 11 17:48:55 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 11 Nov 2014 17:48:55 +0000
Subject: Concrete syntax for pattern synonym type signatures
In-Reply-To: <46644962-C0B2-4333-A5E3-4FA34DF3630D@cis.upenn.edu>
References: <alpine.DEB.2.10.1411031812500.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F38F14E@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411091554490.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F39E97A@DB3PRD3001MB020.064d.mgd.msft.net>
 <10755CED-C8A8-401D-A7C4-2C59274482F0@cis.upenn.edu>
 <618BE556AADD624C9C918AA5D5911BEF3F39F1EA@DB3PRD3001MB020.064d.mgd.msft.net>
 <alpine.DEB.2.10.1411102202290.2047@galaxy>
 <CDF30C0A-FD6D-4C0E-A3BB-A26091618E7C@cis.upenn.edu>
 <618BE556AADD624C9C918AA5D5911BEF3F3A1DF6@DB3PRD3001MB020.064d.mgd.msft.net>
 <46644962-C0B2-4333-A5E3-4FA34DF3630D@cis.upenn.edu>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3A43F3@DB3PRD3001MB020.064d.mgd.msft.net>

|  My proposal:
|  
|  > pattern P :: (Num a) => (Eq a, Ord Bool, Show c) => c -> Bool -> T a
|  > Bool
|  
|  My previous comment about bizarre scoping is that the universal
|  variables -- which (in my opinion) go with the required constraints --
|  scope over both sets of constraints. The existential variables go with
|  the provided constraints and scope over only the provided constraints.
|  So, Simon's ordering means that the scope of the second (lexically)
|  listed constraints have a *smaller* scope than the first listed
|  constraints. With my ordering, the size of the scope increases as you
|  read to the right, as it normally does.

I _think_ you mean that you _could_ write P's type like this:

|  > pattern P :: forall a. (Num a) => 
                  forall c. (Eq a, Ord Bool, Show c) => 
                  c -> Bool -> T a

I'm not sure we really would give it that nested structure, but it would be reasonable to do so.

Richard's point is that the match-required constraints can *only* mention the universally quantified type variables.

So yes, I think Richard is probably right.  

Incidentally ote that 
	pattern P x = (3,x)
would have type
	pattern P :: Num a => () => b -> (a,b)

But since the "match-provided but no match-required" case must look simple, the "match-required but no match-provided" case is bound to look odd.

OK, Gergo, I think you are good to go now.

Simon

|  On Nov 10, 2014, at 4:07 PM, Simon Peyton Jones
|  <simonpj at microsoft.com> wrote:
|  
|  > | Whatever syntax we choose, I would highly recommend putting in a
|  > | helpful link to more information in error messages.
|  >
|  > In principle I like this very much, but I have always stumbled on
|  > - writing links that will remain stable for ever (and are hence
|  > release-specific)
|  > - keeping them up to date when the version changes
|  > - making them easy to test e.g. in my build tree
|  >
|  > Separate question really, but would need some systematic attention
|  to make it work properly in general.
|  
|  Is there a way of pulling the version from DynFlags? If so, it would
|  be easy to include the version number in an SDoc. Then, we could make
|  the link go to the user manual. It would be easy to write a function
|  `userManualLink :: String -> SDoc` that takes the last bit of the link
|  and produces a link to the manual for the version at hand. (It
|  wouldn't work for non-released versions, but I'm OK with that.)
|  
|  Richard


From eric at seidel.io  Tue Nov 11 17:49:45 2014
From: eric at seidel.io (Eric Seidel)
Date: Tue, 11 Nov 2014 09:49:45 -0800
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <5461FEB7.7080707@well-typed.com>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
 <CAEs96n2fA95K_y=T8F3Lherf7vYjidMRGj_MHFPsN3JktJyPsA@mail.gmail.com>
 <C4025F47-4D59-4070-9EC4-4CD97AC4C54E@seidel.io>
 <5461FEB7.7080707@well-typed.com>
Message-ID: <5EE9A708-4B36-440C-8DAF-0E3528F67356@seidel.io>


> On Nov 11, 2014, at 04:19, Adam Gundry <adam at well-typed.com> wrote:
> 
> I've just pushed wip/tc-plugins-amg, in which I remove the hs-boot file
> and unify the core2core and typechecker plugins under a single -fplugin
> flag. This did involve making a separate module for plugins, which I
> think is probably a good thing.

Thanks! I just checked out your branch, but had to add `Plugins` to the
list of exposed modules in ghc.cabal in order to actually use a plugin
though. Otherwise I get a horrible

  Symbol not found: _ghc_Plugins_Plugin_con_info

error from the linker when I try to compile a module with -fplugin=MyPlugin.

> I looked at using a hook instead, with a plugin to modify hooks, but I'm
> not sure exactly where such a plugin should be invoked. Ideally we want
> the typechecker modifications to work on a per-module basis, but most of
> the hooks seem to have a wider scope than that.

Well, I think we want the option to decide between per-module and global
invocation of plugins, e.g. if I pass -fplugin on the command-line then
I would expect ghc to use the plugin for *any* module it ends up compiling.

The list of plugins to enable is in the DynFlags, which suggests to me that
GHC must compile each module with a specific set of DynFlags, based on the
LANGUAGE and OPTIONS_GHC pragmas. The Hooks are also in the DynFlags, so
perhaps all we need to do is make -fplugin add a Hook, and let GHC's
existing machinery take care of the rest?

Eric

From iavor.diatchki at gmail.com  Tue Nov 11 18:31:02 2014
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 11 Nov 2014 10:31:02 -0800
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <5EE9A708-4B36-440C-8DAF-0E3528F67356@seidel.io>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
 <CAEs96n2fA95K_y=T8F3Lherf7vYjidMRGj_MHFPsN3JktJyPsA@mail.gmail.com>
 <C4025F47-4D59-4070-9EC4-4CD97AC4C54E@seidel.io>
 <5461FEB7.7080707@well-typed.com>
 <5EE9A708-4B36-440C-8DAF-0E3528F67356@seidel.io>
Message-ID: <CAGK9nuqLSOhdrbSPNOMXi=BY3U7cUsnzr8+wkpY4D3xyEVDg7A@mail.gmail.com>

Hi,

thanks Adam!   I merged your changes into `wip/tc-plugin` and updated the
type-nats plugin to work with the new plugin interface.

-Iavor
PS: It looks like `Plugins` was already in ghc.cabal.in and things worked
form me.  Maybe the problem was a stale ghc.cabal?





On Tue, Nov 11, 2014 at 9:49 AM, Eric Seidel <eric at seidel.io> wrote:

>
> > On Nov 11, 2014, at 04:19, Adam Gundry <adam at well-typed.com> wrote:
> >
> > I've just pushed wip/tc-plugins-amg, in which I remove the hs-boot file
> > and unify the core2core and typechecker plugins under a single -fplugin
> > flag. This did involve making a separate module for plugins, which I
> > think is probably a good thing.
>
> Thanks! I just checked out your branch, but had to add `Plugins` to the
> list of exposed modules in ghc.cabal in order to actually use a plugin
> though. Otherwise I get a horrible
>
>   Symbol not found: _ghc_Plugins_Plugin_con_info
>
> error from the linker when I try to compile a module with
> -fplugin=MyPlugin.
>
> > I looked at using a hook instead, with a plugin to modify hooks, but I'm
> > not sure exactly where such a plugin should be invoked. Ideally we want
> > the typechecker modifications to work on a per-module basis, but most of
> > the hooks seem to have a wider scope than that.
>
> Well, I think we want the option to decide between per-module and global
> invocation of plugins, e.g. if I pass -fplugin on the command-line then
> I would expect ghc to use the plugin for *any* module it ends up compiling.
>
> The list of plugins to enable is in the DynFlags, which suggests to me that
> GHC must compile each module with a specific set of DynFlags, based on the
> LANGUAGE and OPTIONS_GHC pragmas. The Hooks are also in the DynFlags, so
> perhaps all we need to do is make -fplugin add a Hook, and let GHC's
> existing machinery take care of the rest?
>
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141111/e875b4ff/attachment.html>

From dev at rodlogic.net  Tue Nov 11 19:34:02 2014
From: dev at rodlogic.net (RodLogic)
Date: Tue, 11 Nov 2014 17:34:02 -0200
Subject: Control.Exception.assert vs HsVersions.h's ASSERT?
Message-ID: <CA++tqLZNvd1y8idjNqLxzcK5hwTKjxBhy0d73sQrroFA2D_nww@mail.gmail.com>

Having spent a bit of time staring at GHC's sources, I noticed that there
are around 140 modules using a set of C macros for assertions, namely:

ASSERT
> ASSERT2
> MASSERT
> MASSERT2
> ASSERTM
> ASSERTM2


However, I see that Control.Exception already provides a first class
Haskell assertion function:

assert :: Bool -> a -> a


that is turned off automatically when optimizations are turned on, and
provides an error containing the filename and line number, which was why I
thought the above macros existed and were still in use.

My question is: is there any reason to keep using these macros instead of
*assert*?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141111/6cb4a93d/attachment.html>

From dev at rodlogic.net  Tue Nov 11 19:34:02 2014
From: dev at rodlogic.net (RodLogic)
Date: Tue, 11 Nov 2014 17:34:02 -0200
Subject: Control.Exception.assert vs HsVersions.h's ASSERT?
Message-ID: <CA++tqLZNvd1y8idjNqLxzcK5hwTKjxBhy0d73sQrroFA2D_nww@mail.gmail.com>

Having spent a bit of time staring at GHC's sources, I noticed that there
are around 140 modules using a set of C macros for assertions, namely:

ASSERT
> ASSERT2
> MASSERT
> MASSERT2
> ASSERTM
> ASSERTM2


However, I see that Control.Exception already provides a first class
Haskell assertion function:

assert :: Bool -> a -> a


that is turned off automatically when optimizations are turned on, and
provides an error containing the filename and line number, which was why I
thought the above macros existed and were still in use.

My question is: is there any reason to keep using these macros instead of
*assert*?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141111/6cb4a93d/attachment-0003.html>

From david.feuer at gmail.com  Tue Nov 11 20:00:09 2014
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 11 Nov 2014 15:00:09 -0500
Subject: [GHC] #9781: Make list monad operations fuse
In-Reply-To: <CAMgWh9tjixD0oNf8nnsRKhet56euGA20FUbaBA3Cven06uRWhw@mail.gmail.com>
References: <CAPY+ZdTjXnFU1x6UCA=5u5tmnMkAxsnLu_gycRp4wSG8ufCD7Q@mail.gmail.com>
 <CAMgWh9twO6QX6-eZQ-pBW8dt-BCto1qwrZ-D4fQ1MoSSq6jQwQ@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3A34FE@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAMgWh9tjixD0oNf8nnsRKhet56euGA20FUbaBA3Cven06uRWhw@mail.gmail.com>
Message-ID: <CAMgWh9s5DzSV=9QFb-c4_rVCijPGP6aiNU3PaNNDa598mj8tWQ@mail.gmail.com>

Note also that there are fairly clear reasons that fusion is flakier than
many other optimizations. In particular, it requires the compiler to do
things that seem *weird*, and that in most other cases are just *bad
ideas*. At least, it requires:

1. Inlining things that look large and/or expensive. This is done in the
hope that they will fuse with other things, producing a whole that is
smaller and cheaper than the sum of its parts. It is done with the
knowledge that these things will (in most cases) be written back to smaller
cheaper forms if they don't fuse. That is, *our* knowledge of that?the
compiler has absolutely no way to know what shenanigans we're up to.

2. Refraining from floating things that look like they should be floated.
GHC likes to pull constants and such out because doing so improves sharing
and also improves other analyses. But if it pulls our producer away from
our consumer, they will not fuse. I think Simon's simplifier changes a few
months ago helped with this issue, but I don't know that it is (or can ever
be) resolved completely.
On Nov 11, 2014 11:54 AM, "David Feuer" <david.feuer at gmail.com> wrote:

>
> On Nov 11, 2014 6:04 AM, "Simon Peyton Jones" <simonpj at microsoft.com>
> wrote:
> > It?s true that, particularly for fusion, inlining can make a huge
> difference.  And GHC really does need help? it?s extremely hard for it to
> make the ?right? choice all the time.
>
> The inliner does indeed do amazing things, and list fusion does indeed do
> lovely things for user code. It's just not the most *reliable* optimization
> in the compiler. I don't think there's anything wrong with admitting that
> and trying to avoid relying on it too heavily in *library* code. Kim-Ee was
> right that expanding out mapM by hand bloated the source. I've since
> defined `sequence=mapM id` to resolve that problem, and doing so does not
> hurt the benchmarks?it relies only on inlining id (which is quite reliable)
> and beta-reducing (which is also quite reliable).
>
> > I strongly agree with Kim-Ee that we should play the game of ?optimise
> by randomly mutating the program and pick the version that (today) happens
> to run faster?.  But I don?t think David is doing that.   There is, at
> least a Note: [List comprehensions and inlining].
>
> I've been trying to leave a trail of comments and notes as I go. I may
> need to go further.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141111/53c7dea8/attachment.html>

From gergo at erdi.hu  Wed Nov 12 02:23:47 2014
From: gergo at erdi.hu (=?UTF-8?B?RHIuIMOJUkRJIEdlcmfFkQ==?=)
Date: Wed, 12 Nov 2014 10:23:47 +0800
Subject: let/app invariant violated by code generated with mkCoreApp
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3A3E7F@DB3PRD3001MB020.064d.mgd.msft.net>
References: <alpine.DEB.2.10.1411082154270.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F3A3E7F@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CAO7EwMrnMxe2B5j4YWjeADSL_sdoLjszRDCkbPnPy_oJ+4Y0QA@mail.gmail.com>

Yep, that seems to work. I'll add a note explaining why we need unfoldings
here.
On Nov 11, 2014 10:14 PM, "Simon Peyton Jones" <simonpj at microsoft.com>
wrote:

> Oh bother, that is _so_ tiresome. The desugarer establishes the let/app
> invariant, so we get
>
>         I# x_help
>
> but if x_help has a compulsory unfolding to (x void), returning an Int#,
> that violates the let/app invariant.  Sigh.  This is a ridiculous amount of
> work for a tiny corner (pattern synonyms for unboxed constants).
>
> Harump.  Let's see.  We are talking only of things like this
>
>         pattern P = 4#
>
> correct?  Perhaps it may be simpler to make the psWrapper in PatSyn be
>         psWrapper :: Either Id Literal
> and treat such patterns specially from the moment we first see them?  That
> would eliminate all this void stuff entirely.
>
> Pursuing the current line, though, I suppose that the desugarer could
> inline compulsory unfoldings during desugaring itself.  In this line, add a
> case for when var has a compulsory unfolding.
>
> dsExpr (HsVar var)            = return (varToCoreExpr var)   -- See Note
> [Desugaring vars]
>
> That would, I suppose, be the quickest pathc.
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Dr.
> |  ERDI Gergo
> |  Sent: 08 November 2014 14:03
> |  To: GHC Devs
> |  Subject: let/app invariant violated by code generated with mkCoreApp
> |
> |  Hi,
> |
> |  I'm trying to attach (f Void#) as a compulsory unfolding to an Id.
> |  Here's what I tried originally:
> |
> |       let unfolding = mkCoreApp (Var worker_id) (Var voidPrimId)
> |           wrapper_id' = setIdUnfolding wrapper_id $
> |  mkCompulsoryUnfolding unfolding
> |
> |  However, when I try to use wrapper_id' in the desugarer, the Core
> |  linter looks at me strange. This is the original Core:
> |
> |  f :: Int
> |  [LclIdX, Str=DmdType]
> |  f = break<1>() GHC.Types.I# Main.$WPAT
> |
> |  and this is the error message ($WPAT is the wrapper_id', PAT is the
> |  worker_id in this example)
> |
> |  <no location info>: Warning:
> |       In the expression: I# (PAT void#)
> |       This argument does not satisfy the let/app invariant: PAT void#
> |
> |  Now, I thought I'd make sure mkCoreApp generated correct Core by
> |  writing it out by hand:
> |
> |       let unfolding = Case (Var voidPrimId) voidArgId pat_ty
> |  [(DEFAULT,[],App (Var worker_id) (Var voidArgId))]
> |
> |  however, bizarrely, this *still* results in *the same* error message,
> |  as if something was transforming it back to a straight App.
> |
> |  Anyone have any hints what I'm doing wrong here?
> |
> |  Bye,
> |       Gergo
> |
> |  --
> |
> |     .--= ULLA! =-----------------.
> |      \     http://gergo.erdi.hu   \
> |       `---= gergo at erdi.hu =-------'
> |  You are in a twisty maze of little install diskettes.
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141112/02f47722/attachment.html>

From hvriedel at gmail.com  Wed Nov 12 10:15:41 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Wed, 12 Nov 2014 11:15:41 +0100
Subject: HEADS-UP: integer-gmp2 landed!
Message-ID: <87tx24d8s2.fsf@gmail.com>

Hello GHC devs,

A few minutes ago, I landed `integer-gmp2` to master!

Ideally, you shouldn't notice any breakages (I've tried to make sure all
tier-1 platform configuration work...), but if you do have problems,
please report any issues/regressions you encounter to me!

Morever, should something break in a way that blocks you on your
platform, just add "INTEGER_LIBRARY=integer-gmp" to the end of your
mk/build.mk (or edit mk/config.mk.in locally), and you'll get the "old"
integer-gmp which worked previously, so you can continue hacking on GHC
HEAD while I figure out what's broken for you with `integer-gmp2`
(assuming you reported the issue to me...).

Cheers,
  hvr

 [1]: http://git.haskell.org/ghc.git/commitdiff/c774b28f76ee4c220f7c1c9fd81585e0e3af0e8a

From simonpj at microsoft.com  Wed Nov 12 10:22:25 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 12 Nov 2014 10:22:25 +0000
Subject: [commit: ghc] master: Implement new integer-gmp2 from scratch
 (re #9281) (c774b28)
In-Reply-To: <20141112100503.105203A300@ghc.haskell.org>
References: <20141112100503.105203A300@ghc.haskell.org>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3A7416@DB3PRD3001MB020.064d.mgd.msft.net>

Great stuff.  But why do primetest, rsa, and mandel allocate so much more?  You mention different accounting, but I've found that it is often worth really understanding what is happening because you discover "Oh, yes, that's egregiously bad, and easily fixed".

Simon 

|  -----Original Message-----
|  From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf
|  Of git at git.haskell.org
|  Sent: 12 November 2014 10:05
|  To: ghc-commits at haskell.org
|  Subject: [commit: ghc] master: Implement new integer-gmp2 from scratch
|  (re #9281) (c774b28)
|  
|  Repository : ssh://git at git.haskell.org/ghc
|  
|  On branch  : master
|  Link       :
|  http://ghc.haskell.org/trac/ghc/changeset/c774b28f76ee4c220f7c1c9fd815
|  85e0e3af0e8a/ghc
|  
|  >---------------------------------------------------------------
|  
|  commit c774b28f76ee4c220f7c1c9fd81585e0e3af0e8a
|  Author: Herbert Valerio Riedel <hvr at gnu.org>
|  Date:   Sun Oct 19 20:37:40 2014 +0200
|  
|      Implement new integer-gmp2 from scratch (re #9281)
|  
|      This is done as a separate `integer-gmp2` backend library because
|  it
|      turned out to become a complete rewrite from scratch.
|  
|      Due to the different (over)allocation scheme and potentially
|  different
|      accounting (via the new `{shrink,resize}MutableByteArray#`
|  primitives),
|      some of the nofib benchmarks actually results in increased
|  allocation
|      numbers (but not necessarily an increase in runtime!).  I believe
|  the
|      allocation numbers could improve if
|  `{resize,shrink}MutableByteArray#`
|      could be optimised to reallocate in-place more efficiently.
|  
|      Here are the more apparent changes in the latest nofib comparision
|      between `integer-gmp` and `integer-gmp2`:
|  
|        ----------------------------------------------------------------
|  --
|                Program     Size    Allocs   Runtime   Elapsed  TotalMem
|        ----------------------------------------------------------------
|  --
|                    ...
|             bernouilli    +1.6%    +15.3%     0.132     0.132      0.0%
|                    ...
|           cryptarithm1    -2.2%      0.0%     -9.7%     -9.7%      0.0%
|                    ...
|                  fasta    -0.7%     -0.0%    +10.9%    +10.9%      0.0%
|                    ...
|                  kahan    +0.6%    +38.9%     0.169     0.169      0.0%
|                    ...
|                   lcss    -0.7%     -0.0%     -6.4%     -6.4%      0.0%
|                    ...
|                 mandel    +1.6%    +33.6%     0.049     0.049      0.0%
|                    ...
|               pidigits    +0.8%     +8.5%     +3.9%     +3.9%      0.0%
|                  power    +1.4%    -23.8%    -18.6%    -18.6%    -16.7%
|                    ...
|              primetest    +1.3%    +50.1%     0.085     0.085      0.0%
|                    ...
|                    rsa    +1.6%    +53.4%     0.026     0.026      0.0%
|                    ...
|                    scs    +1.2%     +6.6%     +6.5%     +6.6%    +14.3%
|                    ...
|                 symalg    +1.0%     +9.5%     0.010     0.010      0.0%
|                    ...
|              transform    -0.6%     -0.0%     -5.9%     -5.9%      0.0%
|                    ...
|        ----------------------------------------------------------------
|  --
|                    Min    -2.3%    -23.8%    -18.6%    -18.6%    -16.7%
|                    Max    +1.6%    +53.4%    +10.9%    +10.9%    +14.3%
|         Geometric Mean    -0.3%     +1.9%     -0.8%     -0.8%     +0.0%
|  
|      (see P35 / https://phabricator.haskell.org/P35 for full report)
|  
|      By default, `INTEGER_LIBRARY=integer-gmp2` is active now, which
|  results
|      in the package `integer-gmp-1.0.0.0` being registered in the
|  package db.
|      The previous `integer-gmp-0.5.1.0` can be restored by setting
|      `INTEGER_LIBRARY=integer-gmp` (but will probably be removed
|  altogether
|      for GHC 7.12). In-tree GMP support has been stolen from the old
|      `integer-gmp` (while unpatching the custom memory-allocators, as
|  well as
|      forcing `-fPIC`)
|  
|      A minor hack to `ghc-cabal` was necessary in order to support two
|  different
|      `integer-gmp` packages (in different folders) with the same
|  package key.
|  
|      There will be a couple of follow-up commits re-implementing some
|  features
|      that were dropped to keep D82 minimal, as well as further
|      clean-ups/improvements.
|  
|      More information can be found via #9281 and
|      https://ghc.haskell.org/trac/ghc/wiki/Design/IntegerGmp2
|  
|      Reviewed By: austin, rwbarton, simonmar
|  
|      Differential Revision: https://phabricator.haskell.org/D82
|  
|  
|  >---------------------------------------------------------------
|  
|  c774b28f76ee4c220f7c1c9fd81585e0e3af0e8a
|   compiler/basicTypes/Module.lhs                     |    7 +-
|   compiler/coreSyn/CorePrep.lhs                      |    3 +-
|   compiler/ghc.mk                                    |    8 +-
|   compiler/prelude/PrelNames.lhs                     |    2 +
|   ghc.mk                                             |   11 +-
|   libraries/base/GHC/Real.hs                         |    4 +
|   libraries/base/base.cabal                          |   19 +-
|   libraries/{integer-gmp => integer-gmp2}/.gitignore |    5 +-
|   libraries/integer-gmp2/LICENSE                     |   30 +
|   libraries/{base => integer-gmp2}/Setup.hs          |    0
|   libraries/{integer-gmp => integer-gmp2}/aclocal.m4 |    0
|   libraries/integer-gmp2/cbits/wrappers.c            |  281 ++++
|   .../{integer-gmp => integer-gmp2}/changelog.md     |    7 +
|   .../integer-gmp2/config.guess                      |    0
|   config.sub => libraries/integer-gmp2/config.sub    |    0
|   .../{integer-gmp => integer-gmp2}/configure.ac     |    2 +-
|   .../{integer-gmp => integer-gmp2}/gmp/config.mk.in |    0
|   libraries/integer-gmp2/gmp/ghc.mk                  |  124 ++
|   libraries/integer-gmp2/gmp/gmpsrc.patch            |   37 +
|   {libffi => libraries/integer-gmp2/gmp}/ln          |    0
|   .../include/HsIntegerGmp.h.in                      |    0
|   .../integer-gmp.buildinfo.in                       |    0
|   libraries/integer-gmp2/integer-gmp.cabal           |   65 +
|   .../src/GHC/Integer.hs}                            |   49 +-
|   .../integer-gmp2/src/GHC/Integer/GMP/Internals.hs  |  126 ++
|   .../integer-gmp2/src/GHC/Integer/Logarithms.hs     |   73 +
|   .../src/GHC/Integer/Logarithms/Internals.hs        |  118 ++
|   libraries/integer-gmp2/src/GHC/Integer/Type.hs     | 1663
|  ++++++++++++++++++++
|   mk/config.mk.in                                    |    2 +-
|   rules/foreachLibrary.mk                            |    2 +
|   testsuite/tests/ghci/scripts/ghci025.stdout        |    6 +-
|   testsuite/tests/lib/integer/all.T                  |    3 +-
|   testsuite/tests/llvm/should_compile/all.T          |    2 +-
|   testsuite/tests/perf/should_run/all.T              |    3 +-
|   testsuite/tests/perf/space_leaks/all.T             |    6 +-
|   testsuite/tests/safeHaskell/check/pkg01/all.T      |    1 +
|   testsuite/tests/simplCore/should_run/T5603.hs      |    3 +-
|   testsuite/tests/typecheck/should_fail/T5095.stderr |    4 +-
|   .../tests/typecheck/should_fail/tcfail072.stderr   |    2 +-
|   utils/ghc-cabal/Main.hs                            |    4 +
|   40 files changed, 2628 insertions(+), 44 deletions(-)
|  
|  Diff suppressed because of size. To see it, use:
|  
|      git diff-tree --root --patch-with-stat --no-color --find-copies-
|  harder --ignore-space-at-eol --cc
|  c774b28f76ee4c220f7c1c9fd81585e0e3af0e8a
|  _______________________________________________
|  ghc-commits mailing list
|  ghc-commits at haskell.org
|  http://www.haskell.org/mailman/listinfo/ghc-commits

From hvriedel at gmail.com  Wed Nov 12 10:30:46 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Wed, 12 Nov 2014 11:30:46 +0100
Subject: [commit: ghc] master: Implement new integer-gmp2 from scratch (re
 #9281) (c774b28)
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3A7416@DB3PRD3001MB020.064d.mgd.msft.net>
 (Simon Peyton Jones's message of "Wed, 12 Nov 2014 10:22:25 +0000")
References: <20141112100503.105203A300@ghc.haskell.org>
 <618BE556AADD624C9C918AA5D5911BEF3F3A7416@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <87ioikd82x.fsf@gmail.com>

On 2014-11-12 at 11:22:25 +0100, Simon Peyton Jones wrote:
> Great stuff.  But why do primetest, rsa, and mandel allocate so much
> more?  You mention different accounting, but I've found that it is
> often worth really understanding what is happening because you
> discover "Oh, yes, that's egregiously bad, and easily fixed".

Oh, but I still plan to investigate those allocation numbers a bit more
to give a more exhaustive explaination (or even fix them)!

But I've already got a few ideas where to look: For instance,for the old
integer-gmp I did that trick to to avoid single-limb allocations (by
using a C stack-allocated temp buffer instead) so much as to avoid them
altogether, and I may have lost some of those opportunities due to the
different design.

Cheers,
  hvr

From simonpj at microsoft.com  Wed Nov 12 11:16:23 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 12 Nov 2014 11:16:23 +0000
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <CAGK9nuozvmRGOm5h3mvo4u_6JuSsunAZpU35V7o-_dx9EofO2w@mail.gmail.com>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
 <54608607.2050400@well-typed.com>
 <CAGK9nuozvmRGOm5h3mvo4u_6JuSsunAZpU35V7o-_dx9EofO2w@mail.gmail.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3A7722@DB3PRD3001MB020.064d.mgd.msft.net>

Iavor, Adam, Eric

I?m happy with the general direction of the plugins stuff, so I?m mostly going to leave it to you guys to plough ahead; but I am happy to respond to questions.

 * I still think it would be better to provide an escape hatch to the
TcS, not merely the TcM, alongside the nice TcPluginM wrapper. Notably,
Simon's new TcFlatten.unflatten needs TcS...

It think the only reason for this is that ?unflatten? needs to set evidence bindings, which in turn requires access to tcs_ev_binds.  I think that everything else is in TcM.  So I suppose you could carry around the EvBindsVar if you really didn?t want TcS.  (And I can see why you wouldn?t; TcS has a lot of stuff you don?t need.)

Simon


From: Iavor Diatchki [mailto:iavor.diatchki at gmail.com]
Sent: 10 November 2014 19:15
To: Adam Gundry
Cc: ghc-devs at haskell.org; Simon Peyton Jones
Subject: Re: Typechecker plugins: request for review and another workflow question

Hi,

On Mon, Nov 10, 2014 at 1:31 AM, Adam Gundry <adam at well-typed.com<mailto:adam at well-typed.com>> wrote:

On the subject of that "nearly", I'm interested to learn whether you
have a suggestion to deal with unflattening, because the interface still
works with flat constraints only. Simon's changes should make it more
practical to unflatten inside the plugin, but it would be far easier (at
least for my purposes) if it was simply given unflattened constraints. I
realise that this would require the plugin loop to be pushed further
out, however, which has other difficulties.

Not sure what to do about this.  With the current setup, I think either way, the plugin would have to do some extract work.   Perhaps we should run the plugins on the unflattened constraints, and leave to the plugins to manually temporarily "flatten" terms from external theories?  For example, if the type-nat plugin saw `2 * F a ~ 4`, it could temporarily work with `2 * x ~ 4`, and then when it figures out that `x ~ 2`, it could emit `F a ~ 2` (non-canonical), which would go around again, and hopefully get fully simplified.



A few other issues, of lesser importance:

 * I still think it would be better to provide an escape hatch to the
TcS, not merely the TcM, alongside the nice TcPluginM wrapper. Notably,
Simon's new TcFlatten.unflatten needs TcS...
I don't mind that but, if I recall correctly, to do this without more recursive modules, we had to split `TCSMonad` in two parts, one with the types, and one with other stuff.  Eric and I did this once, but we didn't commit it, because it seemed like an orthogonal change.


 * Is there a way for my plugin to "solve" a given constraint (e.g. to
discard the uninformative "a * 1 ~ a")?
Yes, you'd say something like: `TcPluginOK [(evidence, "a * 1 ~ a")] []`

The first field of `TcPluginOK` are things that are solved, the second one is new work.

 * It is unfortunately easy to create infinite loops by writing plugins
that emit wanteds but make no useful progress. Perhaps there should be a
limit on the number of times round the loop (like SubGoalDepth but for
all constraints)?

Indeed, if a plugin keeps generating new work, we could go in a loop, so maybe a limit of some sort is useful.  However, note that if the plugin generates things that are already in the inert set, GHC should notice this and filter them, so we won't keep going.


 * Perhaps runTcPlugin should skip invoking the plugin if there are no
wanteds?

Oh, there is an important detail here that needs documentation!   GHC will call the plugin twice: once to improve the givens, and once to solve the wanteds.   The way to distinguish the two is exactly by the presence of the wanteds.

Why might you want to improve the givens?  Suppose you had something like `x * 2 ~ 4` as a given:  then you'd really want the plugin to generate another given: `x ~ 2`, as this is likely to help the rest of the constraint solving process.


 * The use of ctev_evar in runTcPlugin is partial, and fails with a
nasty error if the plugin returns a non-wanted in the solved constraints
list. Would it be worth catching this error and issuing a sensible
message that chastises the plugin author appropriately?

Aha, good idea. Bad plugin! :-)


 * Finally, I presume the comment on runTcPlugin that "The plugin is
provided only with CTyEq and CFunEq constraints" is simply outdated and
should be removed?
Yep, thanks!

Apologies for the deluge of questions - please take them as evidence of
my eagerness to use this feature!

Thanks for your feedback!  Also, if you feel like doing some hacking please do so---I am quite busy at the moment so I don't  have a ton of time to work on it, so any help you be most appreciated.  I know Eric is also quite keen on helping out so we can just coordinate over e-mail.

-Iavor




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141112/95f9f349/attachment-0001.html>

From gergo at erdi.hu  Wed Nov 12 11:58:22 2014
From: gergo at erdi.hu (=?UTF-8?B?RHIuIMOJUkRJIEdlcmfFkQ==?=)
Date: Wed, 12 Nov 2014 19:58:22 +0800
Subject: let/app invariant violated by code generated with mkCoreApp
In-Reply-To: <CAO7EwMrnMxe2B5j4YWjeADSL_sdoLjszRDCkbPnPy_oJ+4Y0QA@mail.gmail.com>
References: <alpine.DEB.2.10.1411082154270.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F3A3E7F@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAO7EwMrnMxe2B5j4YWjeADSL_sdoLjszRDCkbPnPy_oJ+4Y0QA@mail.gmail.com>
Message-ID: <CAO7EwMpDvn6bdFUEtwUMfatuP6SJKqOxvC2Lsb3P314QkU50PQ@mail.gmail.com>

Unfortunately, now that I had the opportunity to try to validate my change,
it turns out it is *not* working, since it breaks
deSugar/should_run/dsrun014.

My code is pushed to the wip/desugar-unfold branch, but all it does is
change dsExpr from

dsExpr (HsVar var) = return (varToCoreExpr var)   -- See Note [Desugaring
vars]

to

dsExpr (HsVar var)            -- See Note [Unfolding while desugaring]
  | isCompulsoryUnfolding unfolding = return $ unfoldingTemplate unfolding
  | otherwise = return (varToCoreExpr var)   -- See Note [Desugaring vars]
  where
    unfolding = idUnfolding var


The important bit of the test in question is:

{-# NOINLINE f #-}
f :: a -> b -> (# a,b #)
f x y = x `seq` y `seq` (# x,y #)



Here's what it is desugared into with master:

f [InlPrag=NOINLINE]
  :: forall a_avA b_avB. a_avA -> b_avB -> (# a_avA, b_avB #)
[LclIdX, Str=DmdType]
f =
  \ (@ a_aAj) (@ b_aAk) ->
    letrec {
      f_aAl :: a_aAj -> b_aAk -> (# a_aAj, b_aAk #)
      [LclId, Str=DmdType]
      f_aAl =
        \ (x_avC :: a_aAj) (y_avD :: b_aAk) ->
          break<2>()
          break<1>(x_avC,y_avD)
          case x_avC of x_avC { __DEFAULT ->
          break<0>(x_avC,y_avD)
          case y_avD of y_avD { __DEFAULT -> (# x_avC, y_avD #) }
          }; } in
    f_aAl



and here is the desugaring with the above change to dsExpr:

f [InlPrag=NOINLINE]
  :: forall a_avA b_avB. a_avA -> b_avB -> (# a_avA, b_avB #)
[LclIdX, Str=DmdType]
f =
  \ (@ a_aAj) (@ b_aAk) ->
    letrec {
      f_aAl :: a_aAj -> b_aAk -> (# a_aAj, b_aAk #)
      [LclId, Str=DmdType]
      f_aAl =
        \ (x_avC :: a_aAj) (y_avD :: b_aAk) ->
          break<2>()
          break<1>(x_avC,y_avD)
          case break<0>(x_avC,y_avD)
               (\ (@ a_12)
                  (@ b_13)
                  (tpl_B1 [Occ=Once] :: a_12)
                  (tpl_B2 [Occ=Once] :: b_13) ->
                  case tpl_B1 of _ [Occ=Dead] { __DEFAULT -> tpl_B2 })
                 @ b_aAk @ (# a_aAj, b_aAk #) y_avD (# x_avC, y_avD #)
          of wild_00 { __DEFAULT ->
          (\ (@ a_12)
             (@ b_13)
             (tpl_B1 [Occ=Once] :: a_12)
             (tpl_B2 [Occ=Once] :: b_13) ->
             case tpl_B1 of _ [Occ=Dead] { __DEFAULT -> tpl_B2 })
            @ a_aAj @ (# a_aAj, b_aAk #) x_avC wild_00
          }; } in
    f_aAl


This trips up the core linter on the application of the inner lambda on the
unboxed tuple type:

    In the expression: (\ (@ a_12)
                          (@ b_13)
                          (tpl_B1 [Occ=Once] :: a_12)
                          (tpl_B2 [Occ=Once] :: b_13) ->
                          case tpl_B1 of _ [Occ=Dead] { __DEFAULT -> tpl_B2
})
                         @ b_aAk @ (# a_aAj, b_aAk #) y_avD (# x_avC, y_avD
#)
    Kinds don't match in type application:
    Type variable: b_13 :: *
    Arg type: (# a_aAj, b_aAk #) :: #
    xx #

So.... yeah. Is there a more narrow predicate than isCompulsoryUnfolding
that I should be checking for?

Bye,
    Gergo

On Wed, Nov 12, 2014 at 10:23 AM, Dr. ?RDI Gerg? <gergo at erdi.hu> wrote:

> Yep, that seems to work. I'll add a note explaining why we need unfoldings
> here.
> On Nov 11, 2014 10:14 PM, "Simon Peyton Jones" <simonpj at microsoft.com>
> wrote:
>
>> Oh bother, that is _so_ tiresome. The desugarer establishes the let/app
>> invariant, so we get
>>
>>         I# x_help
>>
>> but if x_help has a compulsory unfolding to (x void), returning an Int#,
>> that violates the let/app invariant.  Sigh.  This is a ridiculous amount of
>> work for a tiny corner (pattern synonyms for unboxed constants).
>>
>> Harump.  Let's see.  We are talking only of things like this
>>
>>         pattern P = 4#
>>
>> correct?  Perhaps it may be simpler to make the psWrapper in PatSyn be
>>         psWrapper :: Either Id Literal
>> and treat such patterns specially from the moment we first see them?
>> That would eliminate all this void stuff entirely.
>>
>> Pursuing the current line, though, I suppose that the desugarer could
>> inline compulsory unfoldings during desugaring itself.  In this line, add a
>> case for when var has a compulsory unfolding.
>>
>> dsExpr (HsVar var)            = return (varToCoreExpr var)   -- See Note
>> [Desugaring vars]
>>
>> That would, I suppose, be the quickest pathc.
>>
>> Simon
>>
>> |  -----Original Message-----
>> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Dr.
>> |  ERDI Gergo
>> |  Sent: 08 November 2014 14:03
>> |  To: GHC Devs
>> |  Subject: let/app invariant violated by code generated with mkCoreApp
>> |
>> |  Hi,
>> |
>> |  I'm trying to attach (f Void#) as a compulsory unfolding to an Id.
>> |  Here's what I tried originally:
>> |
>> |       let unfolding = mkCoreApp (Var worker_id) (Var voidPrimId)
>> |           wrapper_id' = setIdUnfolding wrapper_id $
>> |  mkCompulsoryUnfolding unfolding
>> |
>> |  However, when I try to use wrapper_id' in the desugarer, the Core
>> |  linter looks at me strange. This is the original Core:
>> |
>> |  f :: Int
>> |  [LclIdX, Str=DmdType]
>> |  f = break<1>() GHC.Types.I# Main.$WPAT
>> |
>> |  and this is the error message ($WPAT is the wrapper_id', PAT is the
>> |  worker_id in this example)
>> |
>> |  <no location info>: Warning:
>> |       In the expression: I# (PAT void#)
>> |       This argument does not satisfy the let/app invariant: PAT void#
>> |
>> |  Now, I thought I'd make sure mkCoreApp generated correct Core by
>> |  writing it out by hand:
>> |
>> |       let unfolding = Case (Var voidPrimId) voidArgId pat_ty
>> |  [(DEFAULT,[],App (Var worker_id) (Var voidArgId))]
>> |
>> |  however, bizarrely, this *still* results in *the same* error message,
>> |  as if something was transforming it back to a straight App.
>> |
>> |  Anyone have any hints what I'm doing wrong here?
>> |
>> |  Bye,
>> |       Gergo
>> |
>> |  --
>> |
>> |     .--= ULLA! =-----------------.
>> |      \     http://gergo.erdi.hu   \
>> |       `---= gergo at erdi.hu =-------'
>> |  You are in a twisty maze of little install diskettes.
>> |  _______________________________________________
>> |  ghc-devs mailing list
>> |  ghc-devs at haskell.org
>> |  http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141112/d6e37890/attachment.html>

From gergo at erdi.hu  Wed Nov 12 12:30:00 2014
From: gergo at erdi.hu (=?UTF-8?B?RHIuIMOJUkRJIEdlcmfFkQ==?=)
Date: Wed, 12 Nov 2014 20:30:00 +0800
Subject: let/app invariant violated by code generated with mkCoreApp
In-Reply-To: <CAO7EwMpDvn6bdFUEtwUMfatuP6SJKqOxvC2Lsb3P314QkU50PQ@mail.gmail.com>
References: <alpine.DEB.2.10.1411082154270.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F3A3E7F@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAO7EwMrnMxe2B5j4YWjeADSL_sdoLjszRDCkbPnPy_oJ+4Y0QA@mail.gmail.com>
 <CAO7EwMpDvn6bdFUEtwUMfatuP6SJKqOxvC2Lsb3P314QkU50PQ@mail.gmail.com>
Message-ID: <CAO7EwMoVRvSwUSLLo-F6GEhXpZwwJKtXjo7AwsMzjbTTijt3HQ@mail.gmail.com>

I was able to work around this by changing 'seq''s unfolding to '\@a @(b ::
?) x y. case x of { _DEFAULT -> y }' (the change is in the kind of 'b'),
but that just leads to exposing the *real* problem, which is that unfolding
'seq' in the desugarer leads to it getting optimized away by the simplifier.

Any ideas?



On Wed, Nov 12, 2014 at 7:58 PM, Dr. ?RDI Gerg? <gergo at erdi.hu> wrote:

> Unfortunately, now that I had the opportunity to try to validate my
> change, it turns out it is *not* working, since it breaks
> deSugar/should_run/dsrun014.
>
> My code is pushed to the wip/desugar-unfold branch, but all it does is
> change dsExpr from
>
> dsExpr (HsVar var) = return (varToCoreExpr var)   -- See Note [Desugaring
> vars]
>
> to
>
> dsExpr (HsVar var)            -- See Note [Unfolding while desugaring]
>   | isCompulsoryUnfolding unfolding = return $ unfoldingTemplate unfolding
>   | otherwise = return (varToCoreExpr var)   -- See Note [Desugaring vars]
>   where
>     unfolding = idUnfolding var
>
>
> The important bit of the test in question is:
>
> {-# NOINLINE f #-}
> f :: a -> b -> (# a,b #)
> f x y = x `seq` y `seq` (# x,y #)
>
>
>
> Here's what it is desugared into with master:
>
> f [InlPrag=NOINLINE]
>   :: forall a_avA b_avB. a_avA -> b_avB -> (# a_avA, b_avB #)
> [LclIdX, Str=DmdType]
> f =
>   \ (@ a_aAj) (@ b_aAk) ->
>     letrec {
>       f_aAl :: a_aAj -> b_aAk -> (# a_aAj, b_aAk #)
>       [LclId, Str=DmdType]
>       f_aAl =
>         \ (x_avC :: a_aAj) (y_avD :: b_aAk) ->
>           break<2>()
>           break<1>(x_avC,y_avD)
>           case x_avC of x_avC { __DEFAULT ->
>           break<0>(x_avC,y_avD)
>           case y_avD of y_avD { __DEFAULT -> (# x_avC, y_avD #) }
>           }; } in
>     f_aAl
>
>
>
> and here is the desugaring with the above change to dsExpr:
>
> f [InlPrag=NOINLINE]
>   :: forall a_avA b_avB. a_avA -> b_avB -> (# a_avA, b_avB #)
> [LclIdX, Str=DmdType]
> f =
>   \ (@ a_aAj) (@ b_aAk) ->
>     letrec {
>       f_aAl :: a_aAj -> b_aAk -> (# a_aAj, b_aAk #)
>       [LclId, Str=DmdType]
>       f_aAl =
>         \ (x_avC :: a_aAj) (y_avD :: b_aAk) ->
>           break<2>()
>           break<1>(x_avC,y_avD)
>           case break<0>(x_avC,y_avD)
>                (\ (@ a_12)
>                   (@ b_13)
>                   (tpl_B1 [Occ=Once] :: a_12)
>                   (tpl_B2 [Occ=Once] :: b_13) ->
>                   case tpl_B1 of _ [Occ=Dead] { __DEFAULT -> tpl_B2 })
>                  @ b_aAk @ (# a_aAj, b_aAk #) y_avD (# x_avC, y_avD #)
>           of wild_00 { __DEFAULT ->
>           (\ (@ a_12)
>              (@ b_13)
>              (tpl_B1 [Occ=Once] :: a_12)
>              (tpl_B2 [Occ=Once] :: b_13) ->
>              case tpl_B1 of _ [Occ=Dead] { __DEFAULT -> tpl_B2 })
>             @ a_aAj @ (# a_aAj, b_aAk #) x_avC wild_00
>           }; } in
>     f_aAl
>
>
> This trips up the core linter on the application of the inner lambda on
> the unboxed tuple type:
>
>     In the expression: (\ (@ a_12)
>                           (@ b_13)
>                           (tpl_B1 [Occ=Once] :: a_12)
>                           (tpl_B2 [Occ=Once] :: b_13) ->
>                           case tpl_B1 of _ [Occ=Dead] { __DEFAULT ->
> tpl_B2 })
>                          @ b_aAk @ (# a_aAj, b_aAk #) y_avD (# x_avC,
> y_avD #)
>     Kinds don't match in type application:
>     Type variable: b_13 :: *
>     Arg type: (# a_aAj, b_aAk #) :: #
>     xx #
>
> So.... yeah. Is there a more narrow predicate than isCompulsoryUnfolding
> that I should be checking for?
>
> Bye,
>     Gergo
>
> On Wed, Nov 12, 2014 at 10:23 AM, Dr. ?RDI Gerg? <gergo at erdi.hu> wrote:
>
>> Yep, that seems to work. I'll add a note explaining why we need
>> unfoldings here.
>> On Nov 11, 2014 10:14 PM, "Simon Peyton Jones" <simonpj at microsoft.com>
>> wrote:
>>
>>> Oh bother, that is _so_ tiresome. The desugarer establishes the let/app
>>> invariant, so we get
>>>
>>>         I# x_help
>>>
>>> but if x_help has a compulsory unfolding to (x void), returning an Int#,
>>> that violates the let/app invariant.  Sigh.  This is a ridiculous amount of
>>> work for a tiny corner (pattern synonyms for unboxed constants).
>>>
>>> Harump.  Let's see.  We are talking only of things like this
>>>
>>>         pattern P = 4#
>>>
>>> correct?  Perhaps it may be simpler to make the psWrapper in PatSyn be
>>>         psWrapper :: Either Id Literal
>>> and treat such patterns specially from the moment we first see them?
>>> That would eliminate all this void stuff entirely.
>>>
>>> Pursuing the current line, though, I suppose that the desugarer could
>>> inline compulsory unfoldings during desugaring itself.  In this line, add a
>>> case for when var has a compulsory unfolding.
>>>
>>> dsExpr (HsVar var)            = return (varToCoreExpr var)   -- See Note
>>> [Desugaring vars]
>>>
>>> That would, I suppose, be the quickest pathc.
>>>
>>> Simon
>>>
>>> |  -----Original Message-----
>>> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Dr.
>>> |  ERDI Gergo
>>> |  Sent: 08 November 2014 14:03
>>> |  To: GHC Devs
>>> |  Subject: let/app invariant violated by code generated with mkCoreApp
>>> |
>>> |  Hi,
>>> |
>>> |  I'm trying to attach (f Void#) as a compulsory unfolding to an Id.
>>> |  Here's what I tried originally:
>>> |
>>> |       let unfolding = mkCoreApp (Var worker_id) (Var voidPrimId)
>>> |           wrapper_id' = setIdUnfolding wrapper_id $
>>> |  mkCompulsoryUnfolding unfolding
>>> |
>>> |  However, when I try to use wrapper_id' in the desugarer, the Core
>>> |  linter looks at me strange. This is the original Core:
>>> |
>>> |  f :: Int
>>> |  [LclIdX, Str=DmdType]
>>> |  f = break<1>() GHC.Types.I# Main.$WPAT
>>> |
>>> |  and this is the error message ($WPAT is the wrapper_id', PAT is the
>>> |  worker_id in this example)
>>> |
>>> |  <no location info>: Warning:
>>> |       In the expression: I# (PAT void#)
>>> |       This argument does not satisfy the let/app invariant: PAT void#
>>> |
>>> |  Now, I thought I'd make sure mkCoreApp generated correct Core by
>>> |  writing it out by hand:
>>> |
>>> |       let unfolding = Case (Var voidPrimId) voidArgId pat_ty
>>> |  [(DEFAULT,[],App (Var worker_id) (Var voidArgId))]
>>> |
>>> |  however, bizarrely, this *still* results in *the same* error message,
>>> |  as if something was transforming it back to a straight App.
>>> |
>>> |  Anyone have any hints what I'm doing wrong here?
>>> |
>>> |  Bye,
>>> |       Gergo
>>> |
>>> |  --
>>> |
>>> |     .--= ULLA! =-----------------.
>>> |      \     http://gergo.erdi.hu   \
>>> |       `---= gergo at erdi.hu =-------'
>>> |  You are in a twisty maze of little install diskettes.
>>> |  _______________________________________________
>>> |  ghc-devs mailing list
>>> |  ghc-devs at haskell.org
>>> |  http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141112/69b3494d/attachment.html>

From moritz at lichtzwerge.de  Wed Nov 12 12:43:54 2014
From: moritz at lichtzwerge.de (Moritz Angermann)
Date: Wed, 12 Nov 2014 13:43:54 +0100
Subject: query ghc for the linkerflags for -staticlib?
Message-ID: <14E7F563-74BD-43A9-B125-3675AFFCAECD@lichtzwerge.de>

Hi,

when building a library with -staticlib, how can we query ghc to tell us the linker flags,
that would be needed to link the produced library. (e.g. -liconv and -lgmp)?

I tried --print-ld-linker-flags and --print-gcc-linker-flags and found they were broken, as
is specified in #9614.

Also --info does not provide the needed information.

Cheers,
 Moritz

From jan.stolarek at p.lodz.pl  Wed Nov 12 12:58:48 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Wed, 12 Nov 2014 13:58:48 +0100
Subject: Keeping the "Newcomers" wiki page alive
Message-ID: <201411121358.48239.jan.stolarek@p.lodz.pl>

Last year Richard created a wiki page for newcomers:

  https://ghc.haskell.org/trac/ghc/wiki/Newcomers

One of assumptions was to store a list of low hanging fruits that newcomers can tackle:

  https://ghc.haskell.org/trac/ghc/wiki/Newcomers#Fixingabug

But that list is far from exhaustive. Here's where your help is needed. Please remember that this 
page exists and whenever you report or encounter a simple bug or feature request please add it to 
the list on Newcomers page. Thanks.

Janek

From eir at cis.upenn.edu  Wed Nov 12 17:27:44 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 12 Nov 2014 12:27:44 -0500
Subject: expanded macros in parser?
Message-ID: <AED8BABC-E16C-4355-ACDF-B08A83361304@cis.upenn.edu>

Hi devs,

I just stumbled across commit 37d64a5, which (among other things) expands all the LL/L1/etc macros in Parser.y.pp and makes the go-to file Parser.y. Why was this done? I don't love macros, but I think the old format was easier to look at and edit.

I know I missed the train a bit on this by not noticing D411, but this surprised me today.

Thanks,
Richard

From austin at well-typed.com  Wed Nov 12 18:16:41 2014
From: austin at well-typed.com (Austin Seipp)
Date: Wed, 12 Nov 2014 12:16:41 -0600
Subject: expanded macros in parser?
In-Reply-To: <AED8BABC-E16C-4355-ACDF-B08A83361304@cis.upenn.edu>
References: <AED8BABC-E16C-4355-ACDF-B08A83361304@cis.upenn.edu>
Message-ID: <CAEs96n3Bgc-hFDesiPyGNr6xbU1AXjvPSVB=DCMbvXasBHhdzg@mail.gmail.com>

It was mostly just superfluous macros at least IMO, which is why I
accepted it. The double-preprocessing we do has been annoying in the
past as well (e.g. Clang's preprocessor had issues with it), and any
attempt to use macros that you want to persist *beyond* the first CPP
pass are annoying. For example, the double step makes it very annoying
to use something like __GLASGOW_HASKELL__ inside the parser, since we
want it to persist into Parser.y, past the first step - as opposed to
CPP gobbling it up in the first pass by itself when it sees the `#if`
part.

Another reason I wanted this done is because I eventually would like
to make the 'make sdist' target not depend on a full build. Right now
we depend on there being an inplace build before running `make sdist`
so we can bundle up the generated parser.

Instead it would be ideal if you could immediately './configure; make
sdist' for everything to work. The need for the double-step of
preprocessing is just another annoying component of having to deal
with this in the Makefile rules. It could be done, but it's more
annoying.

On Wed, Nov 12, 2014 at 11:27 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> Hi devs,
>
> I just stumbled across commit 37d64a5, which (among other things) expands all the LL/L1/etc macros in Parser.y.pp and makes the go-to file Parser.y. Why was this done? I don't love macros, but I think the old format was easier to look at and edit.
>
> I know I missed the train a bit on this by not noticing D411, but this surprised me today.
>
> Thanks,
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From eir at cis.upenn.edu  Wed Nov 12 18:24:55 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 12 Nov 2014 13:24:55 -0500
Subject: Travis validation on a GHC fork?
Message-ID: <9D78208C-8023-49F9-964B-E5D187EA7095@cis.upenn.edu>

Hi Joachim,

I just tried to use Travis for validation on my fork of GHC, to avoid sending out emails associated with a wip/... commit. But, Travis couldn't find the submodules. Here's the tail of my log:

> Submodule 'libraries/vector' (git://github.com/goldfirere/packages/vector.git) registered for path 'libraries/vector'
> Submodule 'libraries/xhtml' (git://github.com/goldfirere/packages/xhtml.git) registered for path 'libraries/xhtml'
> Submodule 'nofib' (git://github.com/goldfirere/nofib.git) registered for path 'nofib'
> Submodule 'utils/haddock' (git://github.com/goldfirere/haddock.git) registered for path 'utils/haddock'
> Submodule 'utils/hsc2hs' (git://github.com/goldfirere/hsc2hs.git) registered for path 'utils/hsc2hs'
> Cloning into 'libffi-tarballs'...
> fatal: remote error: 
>   Repository not found.
> Clone of 'git://github.com/goldfirere/libffi-tarballs.git' into submodule path 'libffi-tarballs' failed
> The command "git submodule update --init --recursive" failed and exited with 1 during .
> Your build has been stopped.

I could probably figure out the right commands to fix this, but then my local .travis.yml would be different than the proper one, and that can cause various headaches down the road.

Any advice?

Thanks,
Richard

From eir at cis.upenn.edu  Wed Nov 12 18:26:20 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 12 Nov 2014 13:26:20 -0500
Subject: expanded macros in parser?
In-Reply-To: <CAEs96n3Bgc-hFDesiPyGNr6xbU1AXjvPSVB=DCMbvXasBHhdzg@mail.gmail.com>
References: <AED8BABC-E16C-4355-ACDF-B08A83361304@cis.upenn.edu>
 <CAEs96n3Bgc-hFDesiPyGNr6xbU1AXjvPSVB=DCMbvXasBHhdzg@mail.gmail.com>
Message-ID: <95D65AEC-FAB9-45BB-8906-F0A9CFC84C44@cis.upenn.edu>

Ah -- makes perfect sense. Thanks. Indeed, this improvement is worth the annoyance of writing out the extra parameters.

Richard

On Nov 12, 2014, at 1:16 PM, Austin Seipp <austin at well-typed.com> wrote:

> It was mostly just superfluous macros at least IMO, which is why I
> accepted it. The double-preprocessing we do has been annoying in the
> past as well (e.g. Clang's preprocessor had issues with it), and any
> attempt to use macros that you want to persist *beyond* the first CPP
> pass are annoying. For example, the double step makes it very annoying
> to use something like __GLASGOW_HASKELL__ inside the parser, since we
> want it to persist into Parser.y, past the first step - as opposed to
> CPP gobbling it up in the first pass by itself when it sees the `#if`
> part.
> 
> Another reason I wanted this done is because I eventually would like
> to make the 'make sdist' target not depend on a full build. Right now
> we depend on there being an inplace build before running `make sdist`
> so we can bundle up the generated parser.
> 
> Instead it would be ideal if you could immediately './configure; make
> sdist' for everything to work. The need for the double-step of
> preprocessing is just another annoying component of having to deal
> with this in the Makefile rules. It could be done, but it's more
> annoying.
> 
> On Wed, Nov 12, 2014 at 11:27 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>> Hi devs,
>> 
>> I just stumbled across commit 37d64a5, which (among other things) expands all the LL/L1/etc macros in Parser.y.pp and makes the go-to file Parser.y. Why was this done? I don't love macros, but I think the old format was easier to look at and edit.
>> 
>> I know I missed the train a bit on this by not noticing D411, but this surprised me today.
>> 
>> Thanks,
>> Richard
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>> 
> 
> 
> 
> -- 
> Regards,
> 
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/


From mail at joachim-breitner.de  Wed Nov 12 22:19:14 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 12 Nov 2014 23:19:14 +0100
Subject: Travis validation on a GHC fork?
In-Reply-To: <9D78208C-8023-49F9-964B-E5D187EA7095@cis.upenn.edu>
References: <9D78208C-8023-49F9-964B-E5D187EA7095@cis.upenn.edu>
Message-ID: <1415830754.30167.1.camel@joachim-breitner.de>

Hi,



Am Mittwoch, den 12.11.2014, 13:24 -0500 schrieb Richard Eisenberg:
> Hi Joachim,
> 
> I just tried to use Travis for validation on my fork of GHC, to avoid
> sending out emails associated with a wip/... commit. But, Travis
> couldn't find the submodules. Here's the tail of my log:
>
>[..]
>
> I could probably figure out the right commands to fix this, but then
> my local .travis.yml would be different than the proper one, and that
> can cause various headaches down the road.
> 
we could change the official .travis.yml file to rewrite the urls to
point to github.com/ghc/. I don?t know of any more elegant solution, but
maybe our submodule experts know something?

Greetings
Joachim


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141112/41b75a0f/attachment.sig>

From ihmccreery at gmail.com  Wed Nov 12 22:20:02 2014
From: ihmccreery at gmail.com (Isaac Hollander McCreery)
Date: Wed, 12 Nov 2014 14:20:02 -0800
Subject: Keeping the "Newcomers" wiki page alive
In-Reply-To: <201411121358.48239.jan.stolarek@p.lodz.pl>
References: <201411121358.48239.jan.stolarek@p.lodz.pl>
Message-ID: <CAMLKBUGH6WqkZysxzLfV3ZsR=BJ+-iBOWpk8L5FXqKCu+kN-ow@mail.gmail.com>

As a newcomer myself, yes, this is an important resource for me!

Actually, when I first saw that list, I assumed it was dynamically updated
from Trac.  I've known other projects to track tickets with tags that
correspond to difficulty:


https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AE-easy

I'm not familiar enough with Trac to know if this is possible, but perhaps
this list could be dynamically updated, or at least link to Trac so that
someone like me could see an up-to-date full list?

Thanks y'all,
Ike

On Wed, Nov 12, 2014 at 4:58 AM, Jan Stolarek <jan.stolarek at p.lodz.pl>
wrote:

> Last year Richard created a wiki page for newcomers:
>
>   https://ghc.haskell.org/trac/ghc/wiki/Newcomers
>
> One of assumptions was to store a list of low hanging fruits that
> newcomers can tackle:
>
>   https://ghc.haskell.org/trac/ghc/wiki/Newcomers#Fixingabug
>
> But that list is far from exhaustive. Here's where your help is needed.
> Please remember that this
> page exists and whenever you report or encounter a simple bug or feature
> request please add it to
> the list on Newcomers page. Thanks.
>
> Janek
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141112/d5e53b4f/attachment.html>

From eir at cis.upenn.edu  Wed Nov 12 22:30:11 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 12 Nov 2014 17:30:11 -0500
Subject: Keeping the "Newcomers" wiki page alive
In-Reply-To: <CAMLKBUGH6WqkZysxzLfV3ZsR=BJ+-iBOWpk8L5FXqKCu+kN-ow@mail.gmail.com>
References: <201411121358.48239.jan.stolarek@p.lodz.pl>
 <CAMLKBUGH6WqkZysxzLfV3ZsR=BJ+-iBOWpk8L5FXqKCu+kN-ow@mail.gmail.com>
Message-ID: <7037FD8E-1E93-439A-9A92-CDD009E9A2EC@cis.upenn.edu>

I like this idea.

Would it be a good idea to add a new "difficulty" classification for bugs that could flag them as newcomer-appropriate? I don't think "Easy" is this classification, because there are many bugs that are easy if you know exactly where to look but nigh impossible otherwise. If it were as easy as choosing a pull-down option in Trac, we might do better at keeping this list up to date.

(Yes, I know I planned to maintain the list, but that just wasn't realistic of me. Sorry.)

Richard

On Nov 12, 2014, at 5:20 PM, Isaac Hollander McCreery <ihmccreery at gmail.com> wrote:

> As a newcomer myself, yes, this is an important resource for me!
> 
> Actually, when I first saw that list, I assumed it was dynamically updated from Trac.  I've known other projects to track tickets with tags that correspond to difficulty:
> 
>     https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AE-easy
> 
> I'm not familiar enough with Trac to know if this is possible, but perhaps this list could be dynamically updated, or at least link to Trac so that someone like me could see an up-to-date full list?
> 
> Thanks y'all,
> Ike
> 
> On Wed, Nov 12, 2014 at 4:58 AM, Jan Stolarek <jan.stolarek at p.lodz.pl> wrote:
> Last year Richard created a wiki page for newcomers:
> 
>   https://ghc.haskell.org/trac/ghc/wiki/Newcomers
> 
> One of assumptions was to store a list of low hanging fruits that newcomers can tackle:
> 
>   https://ghc.haskell.org/trac/ghc/wiki/Newcomers#Fixingabug
> 
> But that list is far from exhaustive. Here's where your help is needed. Please remember that this
> page exists and whenever you report or encounter a simple bug or feature request please add it to
> the list on Newcomers page. Thanks.
> 
> Janek
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141112/de6a163e/attachment.html>

From mail at joachim-breitner.de  Wed Nov 12 22:32:32 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 12 Nov 2014 23:32:32 +0100
Subject: Keeping the "Newcomers" wiki page alive
In-Reply-To: <CAMLKBUGH6WqkZysxzLfV3ZsR=BJ+-iBOWpk8L5FXqKCu+kN-ow@mail.gmail.com>
References: <201411121358.48239.jan.stolarek@p.lodz.pl>
 <CAMLKBUGH6WqkZysxzLfV3ZsR=BJ+-iBOWpk8L5FXqKCu+kN-ow@mail.gmail.com>
Message-ID: <1415831552.30167.3.camel@joachim-breitner.de>

Hi,

I was about to suggest the same thing. I also started my own list for
the last hackathon at
https://ghc.haskell.org/trac/ghc/wiki/ZuriHac2014#Possibletickets
but something like
https://ghc.haskell.org/trac/ghc/query?keywords=~newcomer
would be even nicer.

Of course there is the bike-shedding question of what the keyword should
be.

?easy? is obvious, but I don?t like it a lot: These tickets are not
necessary easy, and we don?t want new contributors to think that we only
trust them to do easy stuff.

The quality that we are looking for is ?tacklabe by a newcomer?, i.e.
not requiring too deep knowledge of GHC. Is there a nice word for that?
I found ?accessible?, ?welcoming?, ?appealing? ? anything that sounds
good in native English speaker?s ears? :-)


About filling the list: I suggest that if you see a new ticket on
ghc-tickets filed that you would recommend to a newcomer, simply set the
keyword. This has the side-effect that at least one developer get?s CCed
when a newcomer comes along and posts questions to the ticket.

Greetings,
Joachim



-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141112/84ae84ac/attachment.sig>

From alan.zimm at gmail.com  Wed Nov 12 22:33:20 2014
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Thu, 13 Nov 2014 00:33:20 +0200
Subject: TIL about arc diff
Message-ID: <CANma=H-yWFXuu8HsRrvN3zFdskvKoyAAk8gFZRQgAv6JNg04CA@mail.gmail.com>

I find if I get a timeout on upload at the end, it is time to rebase
against master.

Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141113/4c4e0202/attachment-0001.html>

From allbery.b at gmail.com  Wed Nov 12 22:34:30 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Wed, 12 Nov 2014 17:34:30 -0500
Subject: Keeping the "Newcomers" wiki page alive
In-Reply-To: <1415831552.30167.3.camel@joachim-breitner.de>
References: <201411121358.48239.jan.stolarek@p.lodz.pl>
 <CAMLKBUGH6WqkZysxzLfV3ZsR=BJ+-iBOWpk8L5FXqKCu+kN-ow@mail.gmail.com>
 <1415831552.30167.3.camel@joachim-breitner.de>
Message-ID: <CAKFCL4XF5C-EQR_e-zEoUUXpCB6C6uoMsZc3nwjHtwvX572oEg@mail.gmail.com>

On Wed, Nov 12, 2014 at 5:32 PM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> The quality that we are looking for is ?tacklabe by a newcomer?, i.e.
> not requiring too deep knowledge of GHC. Is there a nice word for that?
> I found ?accessible?, ?welcoming?, ?appealing? ? anything that sounds
> good in native English speaker?s ears? :-)
>

Various projects I'm involved with use

difficulty: beginner (or just "beginner")
babydev-bait (!)
newcomer (several use "newbie" but I do not recommend that label)

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141112/9c5dec1d/attachment.html>

From ihmccreery at gmail.com  Wed Nov 12 23:27:24 2014
From: ihmccreery at gmail.com (Isaac Hollander McCreery)
Date: Wed, 12 Nov 2014 15:27:24 -0800
Subject: Keeping the "Newcomers" wiki page alive
In-Reply-To: <CAKFCL4XF5C-EQR_e-zEoUUXpCB6C6uoMsZc3nwjHtwvX572oEg@mail.gmail.com>
References: <201411121358.48239.jan.stolarek@p.lodz.pl>
 <CAMLKBUGH6WqkZysxzLfV3ZsR=BJ+-iBOWpk8L5FXqKCu+kN-ow@mail.gmail.com>
 <1415831552.30167.3.camel@joachim-breitner.de>
 <CAKFCL4XF5C-EQR_e-zEoUUXpCB6C6uoMsZc3nwjHtwvX572oEg@mail.gmail.com>
Message-ID: <CAMLKBUF3A2eNgeULeSsLxfhLdY55DSjf1bj9vFv92mA4bUJd4Q@mail.gmail.com>

Glad people are excited about this,

I like "beginner/intermediate/advanced".  I think it's more accurate than
"easy/hard" and clearer than "accessible", "welcoming", etc.

I also want to call out the "mentor" label that the Rust team is using:
experienced devs nominate themselves as mentors on projects, then newcomers
can tackle them with some support.  As a newcomer, that's *extremely*
appealing to me.

Cheers,
Ike

On Wed, Nov 12, 2014 at 2:34 PM, Brandon Allbery <allbery.b at gmail.com>
wrote:

> On Wed, Nov 12, 2014 at 5:32 PM, Joachim Breitner <
> mail at joachim-breitner.de> wrote:
>
>> The quality that we are looking for is ?tacklabe by a newcomer?, i.e.
>> not requiring too deep knowledge of GHC. Is there a nice word for that?
>> I found ?accessible?, ?welcoming?, ?appealing? ? anything that sounds
>> good in native English speaker?s ears? :-)
>>
>
> Various projects I'm involved with use
>
> difficulty: beginner (or just "beginner")
> babydev-bait (!)
> newcomer (several use "newbie" but I do not recommend that label)
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141112/0cb68267/attachment.html>

From eir at cis.upenn.edu  Thu Nov 13 01:42:30 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 12 Nov 2014 20:42:30 -0500
Subject: Keeping the "Newcomers" wiki page alive
In-Reply-To: <CAMLKBUF3A2eNgeULeSsLxfhLdY55DSjf1bj9vFv92mA4bUJd4Q@mail.gmail.com>
References: <201411121358.48239.jan.stolarek@p.lodz.pl>
 <CAMLKBUGH6WqkZysxzLfV3ZsR=BJ+-iBOWpk8L5FXqKCu+kN-ow@mail.gmail.com>
 <1415831552.30167.3.camel@joachim-breitner.de>
 <CAKFCL4XF5C-EQR_e-zEoUUXpCB6C6uoMsZc3nwjHtwvX572oEg@mail.gmail.com>
 <CAMLKBUF3A2eNgeULeSsLxfhLdY55DSjf1bj9vFv92mA4bUJd4Q@mail.gmail.com>
Message-ID: <2B8AC8E6-1222-4BC2-99ED-60EB02EAC3E6@cis.upenn.edu>

Forgive me if I'm repeating others' comments, but the newcomer label, to me, is independent of level of difficulty -- it has much more to do with how "messy" the work is, I think.

I'll make a concrete proposal: Tag appropriate bugs/feature requests with "newcomer" and, if you want, mention that you'll mentor in a comment. I don't think there's a glaring need to be able to search by mentor, so I'm not proposing a Trac field for that.

If I see here that a few others will adopt this proposal, I'll start doing it -- I already have several tickets in mind.

Richard

On Nov 12, 2014, at 6:27 PM, Isaac Hollander McCreery <ihmccreery at gmail.com> wrote:

> Glad people are excited about this,
> 
> I like "beginner/intermediate/advanced".  I think it's more accurate than "easy/hard" and clearer than "accessible", "welcoming", etc.
> 
> I also want to call out the "mentor" label that the Rust team is using: experienced devs nominate themselves as mentors on projects, then newcomers can tackle them with some support.  As a newcomer, that's *extremely* appealing to me.
> 
> Cheers,
> Ike
> 
> On Wed, Nov 12, 2014 at 2:34 PM, Brandon Allbery <allbery.b at gmail.com> wrote:
> On Wed, Nov 12, 2014 at 5:32 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> The quality that we are looking for is ?tacklabe by a newcomer?, i.e.
> not requiring too deep knowledge of GHC. Is there a nice word for that?
> I found ?accessible?, ?welcoming?, ?appealing? ? anything that sounds
> good in native English speaker?s ears? :-)
> 
> Various projects I'm involved with use
> 
> difficulty: beginner (or just "beginner")
> babydev-bait (!)
> newcomer (several use "newbie" but I do not recommend that label)
> 
> -- 
> brandon s allbery kf8nh                               sine nomine associates
> allbery.b at gmail.com                                  ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141112/1b1750b8/attachment.html>

From jan.stolarek at p.lodz.pl  Thu Nov 13 07:43:59 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Thu, 13 Nov 2014 08:43:59 +0100
Subject: Keeping the "Newcomers" wiki page alive
In-Reply-To: <2B8AC8E6-1222-4BC2-99ED-60EB02EAC3E6@cis.upenn.edu>
References: <201411121358.48239.jan.stolarek@p.lodz.pl>
 <CAMLKBUF3A2eNgeULeSsLxfhLdY55DSjf1bj9vFv92mA4bUJd4Q@mail.gmail.com>
 <2B8AC8E6-1222-4BC2-99ED-60EB02EAC3E6@cis.upenn.edu>
Message-ID: <201411130844.00005.jan.stolarek@p.lodz.pl>

I believe that current difficulty field is intended to mean "the amount of time required by 
someone who already knows what to do". Obviously, that's not the metric that we want to use for 
labelling newcomer-friendly tasks. (I wonder if the difficulty field in its current form is even 
useful to us?) 

Obviously, the metric that we want is "the amount of code familiarity required to fix a bug". For 
newcommers we probably want tickets that require knowledge of <1000 lines of code.

I think the important questions are:

1. Do we find the current "difficulty" field useful?
2. Should we have a Trac field to label accessibility for newcomers?

My answers are:
1. No.
2. Yes, we should have a filed with accessibility levels like: 
newcomer/intermediate/advanced/rocket science.

If we have 2) then we can have a list of tickets in the Newcomers page generated dynamically.

Janek

Dnia czwartek, 13 listopada 2014, Richard Eisenberg napisa?:
> Forgive me if I'm repeating others' comments, but the newcomer label, to
> me, is independent of level of difficulty -- it has much more to do with
> how "messy" the work is, I think.
>
> I'll make a concrete proposal: Tag appropriate bugs/feature requests with
> "newcomer" and, if you want, mention that you'll mentor in a comment. I
> don't think there's a glaring need to be able to search by mentor, so I'm
> not proposing a Trac field for that.
>
> If I see here that a few others will adopt this proposal, I'll start doing
> it -- I already have several tickets in mind.
>
> Richard
>
> On Nov 12, 2014, at 6:27 PM, Isaac Hollander McCreery <ihmccreery at gmail.com> wrote:
> > Glad people are excited about this,
> >
> > I like "beginner/intermediate/advanced".  I think it's more accurate than
> > "easy/hard" and clearer than "accessible", "welcoming", etc.
> >
> > I also want to call out the "mentor" label that the Rust team is using:
> > experienced devs nominate themselves as mentors on projects, then
> > newcomers can tackle them with some support.  As a newcomer, that's
> > *extremely* appealing to me.
> >
> > Cheers,
> > Ike
> >
> > On Wed, Nov 12, 2014 at 2:34 PM, Brandon Allbery <allbery.b at gmail.com>
> > wrote: On Wed, Nov 12, 2014 at 5:32 PM, Joachim Breitner
> > <mail at joachim-breitner.de> wrote: The quality that we are looking for is
> > ?tacklabe by a newcomer?, i.e. not requiring too deep knowledge of GHC.
> > Is there a nice word for that? I found ?accessible?, ?welcoming?,
> > ?appealing? ? anything that sounds good in native English speaker?s ears?
> > :-)
> >
> > Various projects I'm involved with use
> >
> > difficulty: beginner (or just "beginner")
> > babydev-bait (!)
> > newcomer (several use "newbie" but I do not recommend that label)
> >
> > --
> > brandon s allbery kf8nh                               sine nomine
> > associates allbery.b at gmail.com                                 
> > ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad  
> >      http://sinenomine.net
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs



From mail at joachim-breitner.de  Thu Nov 13 08:27:17 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 13 Nov 2014 09:27:17 +0100
Subject: Keeping the "Newcomers" wiki page alive
In-Reply-To: <201411130844.00005.jan.stolarek@p.lodz.pl>
References: <201411121358.48239.jan.stolarek@p.lodz.pl>
 <CAMLKBUF3A2eNgeULeSsLxfhLdY55DSjf1bj9vFv92mA4bUJd4Q@mail.gmail.com>
 <2B8AC8E6-1222-4BC2-99ED-60EB02EAC3E6@cis.upenn.edu>
 <201411130844.00005.jan.stolarek@p.lodz.pl>
Message-ID: <1415867237.1441.1.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 13.11.2014, 08:43 +0100 schrieb Jan Stolarek:
> I think the important questions are:
> 
> 1. Do we find the current "difficulty" field useful?
> 2. Should we have a Trac field to label accessibility for newcomers?
> 
> My answers are:
> 1. No.
> 2. Yes, we should have a filed with accessibility levels like: 
> newcomer/intermediate/advanced/rocket science.

No need for a new field, simply use a keyword and it will show up on a
query like

https://ghc.haskell.org/trac/ghc/query?status=infoneeded&status=merge&status=new&status=patch&status=upstream&keywords=~newcomer&order=priority

which can also be turned into a table on a wiki page easyil.


So technically, nothing new is required. All we are doing is
bikeshedding and waiting for someone to plough ahead :-)

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141113/8c775589/attachment-0001.sig>

From jan.stolarek at p.lodz.pl  Thu Nov 13 09:26:38 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Thu, 13 Nov 2014 10:26:38 +0100
Subject: Error handling in the renamer
Message-ID: <201411131026.38989.jan.stolarek@p.lodz.pl>

I'm improving my patch for injective type families and I have a question about error handling in 
the renamer. If I write this incorrect definition:

  type family F a b = r | r -> c

I get these errors:

  T6018rnfail.hs:36:1: Not in scope: type variable ?c?

  T6018rnfail.hs:36:26:
    Unexpected type variable on the RHS of injectivity condition: ?c?
    All variables should be bound in type family head and appear at most once in exactly the same 
order as they were bound.

I don't want to report two errors here, just the first one. This means I have to first run the 
renaming using RnTypes.rnTyVar and check if it reports errors. If it does I don't report the 
extra error. The question is how do I check if this piece of code returns errors:

        injFrom' <- rnTyVar True injFrom
        injTo'   <- mapM (rnTyVar True) injTo

I found some combinators in TcRnMonad (tryTc and friends) but I don't know how to use them. 
Ideally I'd want `TcRn a -> TcRn (Messages, a)` + isEmptyMessages but the existing combinators 
return `TcRn a -> TcRn (Messages, Maybe a)`. I'm not at all happy with getting Nothing - even if 
renaming fails my function has to return a result.

Jan

From jan.stolarek at p.lodz.pl  Thu Nov 13 13:56:17 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Thu, 13 Nov 2014 14:56:17 +0100
Subject: HEADS UP: Keeping the "Newcomers" wiki page alive
In-Reply-To: <1415867237.1441.1.camel@joachim-breitner.de>
References: <201411121358.48239.jan.stolarek@p.lodz.pl>
 <201411130844.00005.jan.stolarek@p.lodz.pl>
 <1415867237.1441.1.camel@joachim-breitner.de>
Message-ID: <201411131456.17703.jan.stolarek@p.lodz.pl>

HEADS UP: if you see a ticket that is easy enough to be tackled by a newcomer please tag it 
using "newcomer" keyword.

I already added "newcomer" keyword to tickets that were listed on the Newcomers page and replaced 
the static list with dynamicaly generated one. I decided to filter out tickets that have an owner 
so that people are not redirected to tickets that are being worked on.

Janek

From bulat.ziganshin at gmail.com  Thu Nov 13 14:25:49 2014
From: bulat.ziganshin at gmail.com (Bulat Ziganshin)
Date: Thu, 13 Nov 2014 17:25:49 +0300
Subject: RFC: Dropping Windows XP support
In-Reply-To: <CAEs96n25Bf2eDCn+dNMHCgKHPQ03F6kZXFBfzEuAacR6rojpBw@mail.gmail.com>
References: <CAEs96n25Bf2eDCn+dNMHCgKHPQ03F6kZXFBfzEuAacR6rojpBw@mail.gmail.com>
Message-ID: <142458433.20141113172549@gmail.com>

Hello Austin,

Friday, November 7, 2014, 9:16:22 PM, you wrote:

> For one, Microsoft doesn't support XP anymore, so most people are
> moving off it anyway. 'Soon' even XP Embedded will be obsoleted.

at  the  end  of  http://freearc.org/Statistics.aspx page you can find
stats  about  OS  used  by  ysers  of my program - archiver written in
haskell.  these  are  14%  of  *geeks* using the l;atest alpha version
(stable version of my program ddoesn't report this parameter)

so  dropping  XP support means that newer GHC can't be used anymore to
compile general-purpose programs targeting large user audience

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com


From eir at cis.upenn.edu  Thu Nov 13 17:38:45 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 13 Nov 2014 12:38:45 -0500
Subject: Travis validation on a GHC fork?
In-Reply-To: <1415830754.30167.1.camel@joachim-breitner.de>
References: <9D78208C-8023-49F9-964B-E5D187EA7095@cis.upenn.edu>
 <1415830754.30167.1.camel@joachim-breitner.de>
Message-ID: <3B28D308-992F-46F5-98C2-550B842526B4@cis.upenn.edu>

I don't think this answer "scales" -- what if I've forked some submodules but not others? I think it should perhaps check to see if there is a forked submodule, and then go to GHC's if there isn't.

I suppose I could implement this myself, but I'm confident there is someone who could do it in roughly a quarter of the time this would take me...

Thanks,
Richard

On Nov 12, 2014, at 5:19 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:

> Hi,
> 
> 
> 
> Am Mittwoch, den 12.11.2014, 13:24 -0500 schrieb Richard Eisenberg:
>> Hi Joachim,
>> 
>> I just tried to use Travis for validation on my fork of GHC, to avoid
>> sending out emails associated with a wip/... commit. But, Travis
>> couldn't find the submodules. Here's the tail of my log:
>> 
>> [..]
>> 
>> I could probably figure out the right commands to fix this, but then
>> my local .travis.yml would be different than the proper one, and that
>> can cause various headaches down the road.
>> 
> we could change the official .travis.yml file to rewrite the urls to
> point to github.com/ghc/. I don?t know of any more elegant solution, but
> maybe our submodule experts know something?
> 
> Greetings
> Joachim
> 
> 
> -- 
> Joachim ?nomeata? Breitner
>  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>  Debian Developer: nomeata at debian.org
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From eir at cis.upenn.edu  Thu Nov 13 21:27:39 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 13 Nov 2014 16:27:39 -0500
Subject: Trac down?
Message-ID: <7F461FE8-0D4C-44A2-9809-AF0F55E87DD7@cis.upenn.edu>

Is it me, or is Trac taking the afternoon off? I haven't been able to access it for the last two hours or so.

Thanks,
Richard

From cma at bitemyapp.com  Thu Nov 13 21:30:28 2014
From: cma at bitemyapp.com (Christopher Allen)
Date: Thu, 13 Nov 2014 15:30:28 -0600
Subject: Trac down?
In-Reply-To: <7F461FE8-0D4C-44A2-9809-AF0F55E87DD7@cis.upenn.edu>
References: <7F461FE8-0D4C-44A2-9809-AF0F55E87DD7@cis.upenn.edu>
Message-ID: <CADnndOrMtkG+AZzBEhkwPCBxc9ZkuOM3dLiFjj2z1YH1TDsvDA@mail.gmail.com>

19:44 < thomie> maybe it's a know issue, but
https://ghc.haskell.org/trac/ghc is down
19:58 < hvr> phaskell: log "kicked Apache on ghc.h.o (had high load again,
causing Trac to hang)"
19:58 < phaskell> You got it!
20:00 < hvr> something's causing high load w/ Trac, but I have no time to
investigate right now :(

Misbehaving again I guess? :\

--- Chris Allen


On Thu, Nov 13, 2014 at 3:27 PM, Richard Eisenberg <eir at cis.upenn.edu>
wrote:

> Is it me, or is Trac taking the afternoon off? I haven't been able to
> access it for the last two hours or so.
>
> Thanks,
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141113/ec9dd4fa/attachment.html>

From eir at cis.upenn.edu  Thu Nov 13 21:32:15 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 13 Nov 2014 16:32:15 -0500
Subject: Trac down?
In-Reply-To: <CADnndOrMtkG+AZzBEhkwPCBxc9ZkuOM3dLiFjj2z1YH1TDsvDA@mail.gmail.com>
References: <7F461FE8-0D4C-44A2-9809-AF0F55E87DD7@cis.upenn.edu>
 <CADnndOrMtkG+AZzBEhkwPCBxc9ZkuOM3dLiFjj2z1YH1TDsvDA@mail.gmail.com>
Message-ID: <6583F964-0096-4883-B112-40A3574B2711@cis.upenn.edu>

It appears to be back now. That was fast, whoever fixed it! Thanks!

On Nov 13, 2014, at 4:30 PM, Christopher Allen <cma at bitemyapp.com> wrote:

> 19:44 < thomie> maybe it's a know issue, but https://ghc.haskell.org/trac/ghc is down
> 19:58 < hvr> phaskell: log "kicked Apache on ghc.h.o (had high load again, causing Trac to hang)"
> 19:58 < phaskell> You got it!
> 20:00 < hvr> something's causing high load w/ Trac, but I have no time to investigate right now :(
> 
> Misbehaving again I guess? :\
> 
> --- Chris Allen
> 
> 
> On Thu, Nov 13, 2014 at 3:27 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> Is it me, or is Trac taking the afternoon off? I haven't been able to access it for the last two hours or so.
> 
> Thanks,
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141113/a66bfdf8/attachment.html>

From merijn at inconsistent.nl  Fri Nov 14 04:22:11 2014
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Thu, 13 Nov 2014 20:22:11 -0800
Subject: More flexible literate Haskell extensions (Trac #9789),
 summary on wiki
Message-ID: <CD574F24-99A8-4276-BED2-8C3050E17332@inconsistent.nl>

As requested on my ticket I summarised the entire proposal on the wiki here: https://ghc.haskell.org/trac/ghc/wiki/FlexibleLiterateExtension

I don't expect a lot of disagreement on discussion, aside from minor bike shedding on the flavour of the extension. I've started implementing this already. I'm open to bikesheds on exact extension, as it shouldn't affect the implementation.

Unless there's any vehement objections, I'll produce a diff on fabricator asap.

Cheers,
Merijn

From sol at typeful.net  Fri Nov 14 06:46:10 2014
From: sol at typeful.net (Simon Hengel)
Date: Fri, 14 Nov 2014 14:46:10 +0800
Subject: More flexible literate Haskell extensions (Trac #9789), summary
 on wiki
In-Reply-To: <CD574F24-99A8-4276-BED2-8C3050E17332@inconsistent.nl>
References: <CD574F24-99A8-4276-BED2-8C3050E17332@inconsistent.nl>
Message-ID: <20141114064610.GA27317@x200>

> I don't expect a lot of disagreement on discussion, aside from minor
> bike shedding on the flavour of the extension. I've started
> implementing this already. I'm open to bikesheds on exact extension,
> as it shouldn't affect the implementation.

Joining the party late, my main use case for literate Haskell is
README.md files.  The solution I currently use is to have a symlink:

    README.lhs -> README.md

(see e.g. https://github.com/hspec/hspec-wai)

As I understand it the current proposal neither helps nor conflicts with
this use case/solution.

I leave this here as a comment mainly to indicated that:

 * the proposal as it stands does not solve my use case
 * there are other ways to solve this (namely: using symlinks)

Cheers,
Simon Hengel

From simonpj at microsoft.com  Fri Nov 14 10:29:30 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 14 Nov 2014 10:29:30 +0000
Subject: More flexible literate Haskell extensions (Trac #9789), summary
 on wiki
In-Reply-To: <CD574F24-99A8-4276-BED2-8C3050E17332@inconsistent.nl>
References: <CD574F24-99A8-4276-BED2-8C3050E17332@inconsistent.nl>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3BDD49@DB3PRD3001MB020.064d.mgd.msft.net>

Thanks.  I don't have strong opinions about any of this.  But I would love to have an actual specification of what is proposed.  The wiki page starts with "Proposal" but lists a set of alternatives.  Later "Concrete proposal" discusses only file suffixes, and has lots of discussion of alternatives.

Would it be possible to have a section
   a) describing a single alternative, as precisely as possible.
   b) saying what the effect or meaning of proposal is

For (a), is Foo.hs still ok?  Foo.lhs?  What if both exist and/or Foo.md.hs or whatever?

For (b) what does a suffix of Foo.hs.md mean?  Presumably there is some markdown in there.  But how is it delimited?  Is md the only one proposed or are there others? Is it meant to be extensible or is there a fixed set?

In short, a *specification* of what is proposed.  I think that would be helpful for people who come to this without having participated in the discussion that led up to it.

Simon

|  -----Original Message-----
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  bounces at haskell.org] On Behalf Of Merijn Verstraaten
|  Sent: 14 November 2014 04:22
|  To: ghc-devs at haskell.org; GHC Users Mailing List
|  Subject: More flexible literate Haskell extensions (Trac #9789),
|  summary on wiki
|  
|  As requested on my ticket I summarised the entire proposal on the wiki
|  here: https://ghc.haskell.org/trac/ghc/wiki/FlexibleLiterateExtension
|  
|  I don't expect a lot of disagreement on discussion, aside from minor
|  bike shedding on the flavour of the extension. I've started
|  implementing this already. I'm open to bikesheds on exact extension,
|  as it shouldn't affect the implementation.
|  
|  Unless there's any vehement objections, I'll produce a diff on
|  fabricator asap.
|  
|  Cheers,
|  Merijn
|  _______________________________________________
|  Glasgow-haskell-users mailing list
|  Glasgow-haskell-users at haskell.org
|  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

From hvriedel at gmail.com  Fri Nov 14 11:27:48 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Fri, 14 Nov 2014 12:27:48 +0100
Subject: More flexible literate Haskell extensions (Trac #9789),
 summary on wiki
In-Reply-To: <CD574F24-99A8-4276-BED2-8C3050E17332@inconsistent.nl> (Merijn
 Verstraaten's message of "Thu, 13 Nov 2014 20:22:11 -0800")
References: <CD574F24-99A8-4276-BED2-8C3050E17332@inconsistent.nl>
Message-ID: <878ujekonf.fsf@gmail.com>

Hello Merijn,

On 2014-11-14 at 05:22:11 +0100, Merijn Verstraaten wrote:
> As requested on my ticket I summarised the entire proposal on the wiki
> here: https://ghc.haskell.org/trac/ghc/wiki/FlexibleLiterateExtension

I don't see Cabal mentioned anywhere on that wiki page. Doesn't Cabal
need to be made aware of those new extensions?

Cheers,
  hvr

From jan.stolarek at p.lodz.pl  Fri Nov 14 12:00:49 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Fri, 14 Nov 2014 13:00:49 +0100
Subject: More flexible literate Haskell extensions (Trac #9789),
 summary on wiki
In-Reply-To: <878ujekonf.fsf@gmail.com>
References: <CD574F24-99A8-4276-BED2-8C3050E17332@inconsistent.nl>
 <878ujekonf.fsf@gmail.com>
Message-ID: <201411141300.49816.jan.stolarek@p.lodz.pl>

.lhs = Literate Haskell

So maybe .mhs = Markdown Haskell instead of .lhs+md?

Jan

From sol at typeful.net  Fri Nov 14 15:33:42 2014
From: sol at typeful.net (Simon Hengel)
Date: Fri, 14 Nov 2014 23:33:42 +0800
Subject: More flexible literate Haskell extensions (Trac #9789), summary
 on wiki
In-Reply-To: <20141114075313.GA8925@x200>
References: <CD574F24-99A8-4276-BED2-8C3050E17332@inconsistent.nl>
 <20141114064610.GA27317@x200>
 <3E964435-C2F8-4D0F-B7CA-31C5D2A7BC25@inconsistent.nl>
 <20141114075313.GA8925@x200>
Message-ID: <20141114153342.GA15607@x200>

On Fri, Nov 14, 2014 at 03:53:13PM +0800, Simon Hengel wrote:
> > Can you explain why this would not solve your usecase? i.e., why would
> > README.lhs.md not suffice?
> 
> I haven't tried, but my assumption was that this is not picked up by
> GitHub.

I just verified, GitHub dose not pick up README.lhs.md files as READMEs,
meaning that a README.lhs.md file will not be rendered as a projects
README file on GitHub.

Cheers,
Simon

From simonpj at microsoft.com  Fri Nov 14 16:51:21 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 14 Nov 2014 16:51:21 +0000
Subject: Windows breakage
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3BFF8F@DB3PRD3001MB020.064d.mgd.msft.net>

This breakage didn't use to happen.   Might someone fix it?  Thanks.  For now I'm going through changing a dozen "Trustworthy" to "Safe".  Is that right?
Simon

librariesWin32SystemWin32Console.hsc:2:14: Warning:

    'System.Win32.Console' is marked as Trustworthy but has been inferred as safe!



<no location info>:

Failing due to -Werror.

libraries/Win32/ghc.mk:4: recipe for target 'libraries/Win32/dist-install/build/System/Win32/Console.o' failed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141114/516b9741/attachment.html>

From adam at well-typed.com  Fri Nov 14 17:14:56 2014
From: adam at well-typed.com (Adam Gundry)
Date: Fri, 14 Nov 2014 17:14:56 +0000
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3A7722@DB3PRD3001MB020.064d.mgd.msft.net>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>	<54608607.2050400@well-typed.com>
 <CAGK9nuozvmRGOm5h3mvo4u_6JuSsunAZpU35V7o-_dx9EofO2w@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3A7722@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <54663890.4060005@well-typed.com>

Thanks, Simon! I've been convinced that TcS is more than we need, and I
think the right thing to do is to (optionally) invoke the plugin after
the constraints have been unflattened anyway. I've just pushed a commit
to wip/tc-plugins-amg that does this. Iavor, Eric, your views on how
convenient this alternative is would be most welcome. I'm also wondering
if the plugin should be told how many times it has been called, to make
it easier to prevent infinite loops.

I'm very keen to get this into 7.10, appropriately branded as a very
experimental feature. Austin, have I sufficiently addressed your
concerns about the hs-boot file and multiple flags? Is there anything
else we need, apart perhaps from tests and documentation, which I'll put
together next week?

Thanks,

Adam


On 12/11/14 11:16, Simon Peyton Jones wrote:
> Iavor, Adam, Eric
> 
>  
> 
> I?m happy with the general direction of the plugins stuff, so I?m mostly
> going to leave it to you guys to plough ahead; but I am happy to respond
> to questions.
> 
>  
> 
>  * I still think it would be better to provide an escape hatch to the
> TcS, not merely the TcM, alongside the nice TcPluginM wrapper. Notably,
> Simon's new TcFlatten.unflatten needs TcS...
> 
>  
> 
> It think the only reason for this is that ?unflatten? needs to set
> evidence bindings, which in turn requires access to tcs_ev_binds.  I
> think that everything else is in TcM.  So I suppose you could carry
> around the EvBindsVar if you really didn?t want TcS.  (And I can see why
> you wouldn?t; TcS has a lot of stuff you don?t need.)
> 
>  
> 
> Simon
> 
>  
> 
>  
> 
> *From:*Iavor Diatchki [mailto:iavor.diatchki at gmail.com]
> *Sent:* 10 November 2014 19:15
> *To:* Adam Gundry
> *Cc:* ghc-devs at haskell.org; Simon Peyton Jones
> *Subject:* Re: Typechecker plugins: request for review and another
> workflow question
> 
>  
> 
> Hi,
> 
>  
> 
> On Mon, Nov 10, 2014 at 1:31 AM, Adam Gundry <adam at well-typed.com
> <mailto:adam at well-typed.com>> wrote:
> 
> 
>     On the subject of that "nearly", I'm interested to learn whether you
>     have a suggestion to deal with unflattening, because the interface still
>     works with flat constraints only. Simon's changes should make it more
>     practical to unflatten inside the plugin, but it would be far easier (at
>     least for my purposes) if it was simply given unflattened constraints. I
>     realise that this would require the plugin loop to be pushed further
>     out, however, which has other difficulties.
> 
>  
> 
> Not sure what to do about this.  With the current setup, I think either
> way, the plugin would have to do some extract work.   Perhaps we should
> run the plugins on the unflattened constraints, and leave to the plugins
> to manually temporarily "flatten" terms from external theories?  For
> example, if the type-nat plugin saw `2 * F a ~ 4`, it could temporarily
> work with `2 * x ~ 4`, and then when it figures out that `x ~ 2`, it
> could emit `F a ~ 2` (non-canonical), which would go around again, and
> hopefully get fully simplified.
> 
>  
> 
>  
> 
> 
>     A few other issues, of lesser importance:
> 
>      * I still think it would be better to provide an escape hatch to the
>     TcS, not merely the TcM, alongside the nice TcPluginM wrapper. Notably,
>     Simon's new TcFlatten.unflatten needs TcS...
> 
> I don't mind that but, if I recall correctly, to do this without more
> recursive modules, we had to split `TCSMonad` in two parts, one with the
> types, and one with other stuff.  Eric and I did this once, but we
> didn't commit it, because it seemed like an orthogonal change.
> 
>  
> 
>  
> 
>      * Is there a way for my plugin to "solve" a given constraint (e.g. to
>     discard the uninformative "a * 1 ~ a")?
> 
> Yes, you'd say something like: `TcPluginOK [(evidence, "a * 1 ~ a")] []`
> 
>  
> 
> The first field of `TcPluginOK` are things that are solved, the second
> one is new work.
> 
>  
> 
>      * It is unfortunately easy to create infinite loops by writing plugins
>     that emit wanteds but make no useful progress. Perhaps there should be a
>     limit on the number of times round the loop (like SubGoalDepth but for
>     all constraints)?
> 
>  
> 
> Indeed, if a plugin keeps generating new work, we could go in a loop, so
> maybe a limit of some sort is useful.  However, note that if the plugin
> generates things that are already in the inert set, GHC should notice
> this and filter them, so we won't keep going.
> 
>  
> 
>  
> 
>      * Perhaps runTcPlugin should skip invoking the plugin if there are no
>     wanteds?
> 
>  
> 
> Oh, there is an important detail here that needs documentation!   GHC
> will call the plugin twice: once to improve the givens, and once to
> solve the wanteds.   The way to distinguish the two is exactly by the
> presence of the wanteds.
> 
>  
> 
> Why might you want to improve the givens?  Suppose you had something
> like `x * 2 ~ 4` as a given:  then you'd really want the plugin to
> generate another given: `x ~ 2`, as this is likely to help the rest of
> the constraint solving process.
> 
>  
> 
> 
>      * The use of ctev_evar in runTcPlugin is partial, and fails with a
>     nasty error if the plugin returns a non-wanted in the solved constraints
>     list. Would it be worth catching this error and issuing a sensible
>     message that chastises the plugin author appropriately?
> 
>  
> 
> Aha, good idea. Bad plugin! :-)
> 
>  
> 
>  
> 
>      * Finally, I presume the comment on runTcPlugin that "The plugin is
>     provided only with CTyEq and CFunEq constraints" is simply outdated and
>     should be removed?
> 
> Yep, thanks!
> 
>  
> 
>     Apologies for the deluge of questions - please take them as evidence of
>     my eagerness to use this feature!
> 
>  
> 
> Thanks for your feedback!  Also, if you feel like doing some hacking
> please do so---I am quite busy at the moment so I don't  have a ton of
> time to work on it, so any help you be most appreciated.  I know Eric is
> also quite keen on helping out so we can just coordinate over e-mail.
> 
>  
> 
> -Iavor


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From simonpj at microsoft.com  Fri Nov 14 17:40:50 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 14 Nov 2014 17:40:50 +0000
Subject: Windows breakage
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3C0121@DB3PRD3001MB020.064d.mgd.msft.net>

Hmm.  When I got this

libraries\hpc\Trace\Hpc\Mix.hs:3:14: Warning:

    'Trace.Hpc.Mix' is marked as Trustworthy but has been inferred as safe!
I changed "Trustworthy" to "Safe".  But then I got

libraries\hpc\Trace\Hpc\Mix.hs:24:1:

    Data.Time: Can't be safely imported! The module itself isn't safe.
This seems unhelpful. After all it's been "inferred as safe".  What should I do?
Thanks.
Simon
From: Simon Peyton Jones
Sent: 14 November 2014 16:51
To: ghc-devs at haskell.org
Subject: Windows breakage

This breakage didn't use to happen.   Might someone fix it?  Thanks.  For now I'm going through changing a dozen "Trustworthy" to "Safe".  Is that right?
Simon

librariesWin32SystemWin32Console.hsc:2:14: Warning:

    'System.Win32.Console' is marked as Trustworthy but has been inferred as safe!



<no location info>:

Failing due to -Werror.

libraries/Win32/ghc.mk:4: recipe for target 'libraries/Win32/dist-install/build/System/Win32/Console.o' failed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141114/7b8be6c5/attachment-0001.html>

From f at mazzo.li  Fri Nov 14 17:45:48 2014
From: f at mazzo.li (Francesco Mazzoli)
Date: Fri, 14 Nov 2014 18:45:48 +0100
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <54663890.4060005@well-typed.com>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
 <54608607.2050400@well-typed.com>
 <CAGK9nuozvmRGOm5h3mvo4u_6JuSsunAZpU35V7o-_dx9EofO2w@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3A7722@DB3PRD3001MB020.064d.mgd.msft.net>
 <54663890.4060005@well-typed.com>
Message-ID: <CAPB=P5xs16aYPE08X4VBkN0J=wuemhPNOGGp+98Tz09dWzMECA@mail.gmail.com>

For what it's worth, I'd be very excited to have that feature in 7.10.

Iavor, is there anywhere I can read on how to try your solver for
type-level naturals?

Francesco

On 14 November 2014 18:14, Adam Gundry <adam at well-typed.com> wrote:
> Thanks, Simon! I've been convinced that TcS is more than we need, and I
> think the right thing to do is to (optionally) invoke the plugin after
> the constraints have been unflattened anyway. I've just pushed a commit
> to wip/tc-plugins-amg that does this. Iavor, Eric, your views on how
> convenient this alternative is would be most welcome. I'm also wondering
> if the plugin should be told how many times it has been called, to make
> it easier to prevent infinite loops.
>
> I'm very keen to get this into 7.10, appropriately branded as a very
> experimental feature. Austin, have I sufficiently addressed your
> concerns about the hs-boot file and multiple flags? Is there anything
> else we need, apart perhaps from tests and documentation, which I'll put
> together next week?
>
> Thanks,
>
> Adam
>
>
> On 12/11/14 11:16, Simon Peyton Jones wrote:
>> Iavor, Adam, Eric
>>
>>
>>
>> I?m happy with the general direction of the plugins stuff, so I?m mostly
>> going to leave it to you guys to plough ahead; but I am happy to respond
>> to questions.
>>
>>
>>
>>  * I still think it would be better to provide an escape hatch to the
>> TcS, not merely the TcM, alongside the nice TcPluginM wrapper. Notably,
>> Simon's new TcFlatten.unflatten needs TcS...
>>
>>
>>
>> It think the only reason for this is that ?unflatten? needs to set
>> evidence bindings, which in turn requires access to tcs_ev_binds.  I
>> think that everything else is in TcM.  So I suppose you could carry
>> around the EvBindsVar if you really didn?t want TcS.  (And I can see why
>> you wouldn?t; TcS has a lot of stuff you don?t need.)
>>
>>
>>
>> Simon
>>
>>
>>
>>
>>
>> *From:*Iavor Diatchki [mailto:iavor.diatchki at gmail.com]
>> *Sent:* 10 November 2014 19:15
>> *To:* Adam Gundry
>> *Cc:* ghc-devs at haskell.org; Simon Peyton Jones
>> *Subject:* Re: Typechecker plugins: request for review and another
>> workflow question
>>
>>
>>
>> Hi,
>>
>>
>>
>> On Mon, Nov 10, 2014 at 1:31 AM, Adam Gundry <adam at well-typed.com
>> <mailto:adam at well-typed.com>> wrote:
>>
>>
>>     On the subject of that "nearly", I'm interested to learn whether you
>>     have a suggestion to deal with unflattening, because the interface still
>>     works with flat constraints only. Simon's changes should make it more
>>     practical to unflatten inside the plugin, but it would be far easier (at
>>     least for my purposes) if it was simply given unflattened constraints. I
>>     realise that this would require the plugin loop to be pushed further
>>     out, however, which has other difficulties.
>>
>>
>>
>> Not sure what to do about this.  With the current setup, I think either
>> way, the plugin would have to do some extract work.   Perhaps we should
>> run the plugins on the unflattened constraints, and leave to the plugins
>> to manually temporarily "flatten" terms from external theories?  For
>> example, if the type-nat plugin saw `2 * F a ~ 4`, it could temporarily
>> work with `2 * x ~ 4`, and then when it figures out that `x ~ 2`, it
>> could emit `F a ~ 2` (non-canonical), which would go around again, and
>> hopefully get fully simplified.
>>
>>
>>
>>
>>
>>
>>     A few other issues, of lesser importance:
>>
>>      * I still think it would be better to provide an escape hatch to the
>>     TcS, not merely the TcM, alongside the nice TcPluginM wrapper. Notably,
>>     Simon's new TcFlatten.unflatten needs TcS...
>>
>> I don't mind that but, if I recall correctly, to do this without more
>> recursive modules, we had to split `TCSMonad` in two parts, one with the
>> types, and one with other stuff.  Eric and I did this once, but we
>> didn't commit it, because it seemed like an orthogonal change.
>>
>>
>>
>>
>>
>>      * Is there a way for my plugin to "solve" a given constraint (e.g. to
>>     discard the uninformative "a * 1 ~ a")?
>>
>> Yes, you'd say something like: `TcPluginOK [(evidence, "a * 1 ~ a")] []`
>>
>>
>>
>> The first field of `TcPluginOK` are things that are solved, the second
>> one is new work.
>>
>>
>>
>>      * It is unfortunately easy to create infinite loops by writing plugins
>>     that emit wanteds but make no useful progress. Perhaps there should be a
>>     limit on the number of times round the loop (like SubGoalDepth but for
>>     all constraints)?
>>
>>
>>
>> Indeed, if a plugin keeps generating new work, we could go in a loop, so
>> maybe a limit of some sort is useful.  However, note that if the plugin
>> generates things that are already in the inert set, GHC should notice
>> this and filter them, so we won't keep going.
>>
>>
>>
>>
>>
>>      * Perhaps runTcPlugin should skip invoking the plugin if there are no
>>     wanteds?
>>
>>
>>
>> Oh, there is an important detail here that needs documentation!   GHC
>> will call the plugin twice: once to improve the givens, and once to
>> solve the wanteds.   The way to distinguish the two is exactly by the
>> presence of the wanteds.
>>
>>
>>
>> Why might you want to improve the givens?  Suppose you had something
>> like `x * 2 ~ 4` as a given:  then you'd really want the plugin to
>> generate another given: `x ~ 2`, as this is likely to help the rest of
>> the constraint solving process.
>>
>>
>>
>>
>>      * The use of ctev_evar in runTcPlugin is partial, and fails with a
>>     nasty error if the plugin returns a non-wanted in the solved constraints
>>     list. Would it be worth catching this error and issuing a sensible
>>     message that chastises the plugin author appropriately?
>>
>>
>>
>> Aha, good idea. Bad plugin! :-)
>>
>>
>>
>>
>>
>>      * Finally, I presume the comment on runTcPlugin that "The plugin is
>>     provided only with CTyEq and CFunEq constraints" is simply outdated and
>>     should be removed?
>>
>> Yep, thanks!
>>
>>
>>
>>     Apologies for the deluge of questions - please take them as evidence of
>>     my eagerness to use this feature!
>>
>>
>>
>> Thanks for your feedback!  Also, if you feel like doing some hacking
>> please do so---I am quite busy at the moment so I don't  have a ton of
>> time to work on it, so any help you be most appreciated.  I know Eric is
>> also quite keen on helping out so we can just coordinate over e-mail.
>>
>>
>>
>> -Iavor
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

From austin at well-typed.com  Fri Nov 14 17:50:21 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 14 Nov 2014 11:50:21 -0600
Subject: Windows breakage
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3C0121@DB3PRD3001MB020.064d.mgd.msft.net>
References: <618BE556AADD624C9C918AA5D5911BEF3F3C0121@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CAEs96n2TfTqCWXGtbu5ny1d4sZrvG6rX2k-8XX=Zx7+QNSZYRg@mail.gmail.com>

Looks like fallout from a new -Wall warning:
475dd93efa5158a0f9516f6819a24edfc30c1a76, pushed on Wednesday. Perhaps
in the mean time we should just take it out of minusWallOpts so it
doesn't trip validate.

I think I'll do this for the time being.

On Fri, Nov 14, 2014 at 11:40 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> Hmm.  When I got this
>
> libraries\hpc\Trace\Hpc\Mix.hs:3:14: Warning:
>
>     ?Trace.Hpc.Mix? is marked as Trustworthy but has been inferred as safe!
>
> I changed ?Trustworthy? to ?Safe?.  But then I got
>
> libraries\hpc\Trace\Hpc\Mix.hs:24:1:
>
>     Data.Time: Can't be safely imported! The module itself isn't safe.
>
> This seems unhelpful. After all it?s been ?inferred as safe?.  What should I
> do?
>
> Thanks.
>
> Simon
>
> From: Simon Peyton Jones
> Sent: 14 November 2014 16:51
> To: ghc-devs at haskell.org
> Subject: Windows breakage
>
>
>
> This breakage didn?t use to happen.   Might someone fix it?  Thanks.  For
> now I?m going through changing a dozen ?Trustworthy? to ?Safe?.  Is that
> right?
>
> Simon
>
> librariesWin32SystemWin32Console.hsc:2:14: Warning:
>
>     ?System.Win32.Console? is marked as Trustworthy but has been inferred as
> safe!
>
>
>
> <no location info>:
>
> Failing due to -Werror.
>
> libraries/Win32/ghc.mk:4: recipe for target
> 'libraries/Win32/dist-install/build/System/Win32/Console.o' failed
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From ekmett at gmail.com  Fri Nov 14 17:56:20 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Fri, 14 Nov 2014 12:56:20 -0500
Subject: Windows breakage
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3C0121@DB3PRD3001MB020.064d.mgd.msft.net>
References: <618BE556AADD624C9C918AA5D5911BEF3F3C0121@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CAJumaK_WpaC-UZOHBi5gffFTtSAGm0rHY=b_eimLMtEoM-er5A@mail.gmail.com>

David recently added a new -Wall flag for Trustworthiness.

The reasoning is if it is in -Wall, it can actually get seen and will be
used by folks to improve more things from 'Trustworthy' to 'Safe'. After
all, everything that is merely `Trustworthy` needs to live in the trusted
computing base.

The status quo is that you pretty much have no way to know what you _don't_
need Trustworthy on, and efforts in the past to take large libraries and
convert them to SafeHaskell have been fraught with long rebuild cycles,
because the only way to see was to build, haddock, and look.

What you are running when you go to _fix_ the error appears to be an actual
bug in the safety inference code, though, and definitely needs to be looked
at.

It probably does belong in -Wall in the long term, and -Werror is
notoriously fickle, but we should look at what is causing it to go wrong
here and do a bit more due diligence.

-Edward


On Fri, Nov 14, 2014 at 12:40 PM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

>  Hmm.  When I got this
>
> libraries\hpc\Trace\Hpc\Mix.hs:3:14: Warning:
>
>     ?Trace.Hpc.Mix? is marked as Trustworthy but has been inferred as safe!
>
> I changed ?Trustworthy? to ?Safe?.  But then I got
>
> libraries\hpc\Trace\Hpc\Mix.hs:24:1:
>
>     Data.Time: Can't be safely imported! The module itself isn't safe.
>
> This seems unhelpful. After all it?s been ?inferred as safe?.  What should
> I do?
>
> Thanks.
>
> Simon
>
> *From:* Simon Peyton Jones
> *Sent:* 14 November 2014 16:51
> *To:* ghc-devs at haskell.org
> *Subject:* Windows breakage
>
>
>
> This breakage didn?t use to happen.   Might someone fix it?  Thanks.  For
> now I?m going through changing a dozen ?Trustworthy? to ?Safe?.  Is that
> right?
>
> Simon
>
> librariesWin32SystemWin32Console.hsc:2:14: Warning:
>
>     ?System.Win32.Console? is marked as Trustworthy but has been inferred
> as safe!
>
>
>
> <no location info>:
>
> Failing due to -Werror.
>
> libraries/Win32/ghc.mk:4: recipe for target
> 'libraries/Win32/dist-install/build/System/Win32/Console.o' failed
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141114/a1f42db7/attachment.html>

From austin at well-typed.com  Fri Nov 14 17:59:15 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 14 Nov 2014 11:59:15 -0600
Subject: Windows breakage
In-Reply-To: <CAJumaK_WpaC-UZOHBi5gffFTtSAGm0rHY=b_eimLMtEoM-er5A@mail.gmail.com>
References: <618BE556AADD624C9C918AA5D5911BEF3F3C0121@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAJumaK_WpaC-UZOHBi5gffFTtSAGm0rHY=b_eimLMtEoM-er5A@mail.gmail.com>
Message-ID: <CAEs96n25CAAJjBXAPc06+0iaY8f6A6dVwD9ZkM+C9DjPLCFFZQ@mail.gmail.com>

I've reverted the change in the mean time:
452d6aa95b754a08e1e61800680ccbf6f968aef0 - this doesn't revert the
actual code, just the addition of the new flag to -Wall.

This way, at least ./validate isn't broken for Windows in the mean time.

On Fri, Nov 14, 2014 at 11:56 AM, Edward Kmett <ekmett at gmail.com> wrote:
> David recently added a new -Wall flag for Trustworthiness.
>
> The reasoning is if it is in -Wall, it can actually get seen and will be
> used by folks to improve more things from 'Trustworthy' to 'Safe'. After
> all, everything that is merely `Trustworthy` needs to live in the trusted
> computing base.
>
> The status quo is that you pretty much have no way to know what you _don't_
> need Trustworthy on, and efforts in the past to take large libraries and
> convert them to SafeHaskell have been fraught with long rebuild cycles,
> because the only way to see was to build, haddock, and look.
>
> What you are running when you go to _fix_ the error appears to be an actual
> bug in the safety inference code, though, and definitely needs to be looked
> at.
>
> It probably does belong in -Wall in the long term, and -Werror is
> notoriously fickle, but we should look at what is causing it to go wrong
> here and do a bit more due diligence.
>
> -Edward
>
>
> On Fri, Nov 14, 2014 at 12:40 PM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>>
>> Hmm.  When I got this
>>
>> libraries\hpc\Trace\Hpc\Mix.hs:3:14: Warning:
>>
>>     ?Trace.Hpc.Mix? is marked as Trustworthy but has been inferred as
>> safe!
>>
>> I changed ?Trustworthy? to ?Safe?.  But then I got
>>
>> libraries\hpc\Trace\Hpc\Mix.hs:24:1:
>>
>>     Data.Time: Can't be safely imported! The module itself isn't safe.
>>
>> This seems unhelpful. After all it?s been ?inferred as safe?.  What should
>> I do?
>>
>> Thanks.
>>
>> Simon
>>
>> From: Simon Peyton Jones
>> Sent: 14 November 2014 16:51
>> To: ghc-devs at haskell.org
>> Subject: Windows breakage
>>
>>
>>
>> This breakage didn?t use to happen.   Might someone fix it?  Thanks.  For
>> now I?m going through changing a dozen ?Trustworthy? to ?Safe?.  Is that
>> right?
>>
>> Simon
>>
>> librariesWin32SystemWin32Console.hsc:2:14: Warning:
>>
>>     ?System.Win32.Console? is marked as Trustworthy but has been inferred
>> as safe!
>>
>>
>>
>> <no location info>:
>>
>> Failing due to -Werror.
>>
>> libraries/Win32/ghc.mk:4: recipe for target
>> 'libraries/Win32/dist-install/build/System/Win32/Console.o' failed
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From eric at seidel.io  Fri Nov 14 18:09:05 2014
From: eric at seidel.io (Eric Seidel)
Date: Fri, 14 Nov 2014 10:09:05 -0800
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <54663890.4060005@well-typed.com>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
 <54608607.2050400@well-typed.com>
 <CAGK9nuozvmRGOm5h3mvo4u_6JuSsunAZpU35V7o-_dx9EofO2w@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3A7722@DB3PRD3001MB020.064d.mgd.msft.net>
 <54663890.4060005@well-typed.com>
Message-ID: <888BC9A3-AFDC-4FE7-9DC6-F7FC8E46C716@seidel.io>


> On Nov 14, 2014, at 09:14, Adam Gundry <adam at well-typed.com> wrote:
> 
> Thanks, Simon! I've been convinced that TcS is more than we need, and I
> think the right thing to do is to (optionally) invoke the plugin after
> the constraints have been unflattened anyway. I've just pushed a commit
> to wip/tc-plugins-amg that does this. Iavor, Eric, your views on how
> convenient this alternative is would be most welcome. I'm also wondering
> if the plugin should be told how many times it has been called, to make
> it easier to prevent infinite loops.

Thanks, I was just sitting down to figure out how to call the plugins
with the unflattened constraints. Is there really a point though in
calling the plugins with flattened and unflattened versions of the same
constraints? Perhaps we should just settle on one or the other? I think
Iavor and I are fine with only passing unflattened constraints to the
plugins. It means a bit more work for the type-nat plugin, but shouldn't
be a huge issue (I'll confirm this before next week).

I don't think the plugins should be told how often they're being called,
I'd prefer for GHC to track that and break the loop, if anything. I'm
generally unconvinced that tracking the invocations is necessary at all
though. The only way I can see an infinite loop occurring is if the plugins
keep emitting *new* facts. Disregarding the possibility of a malicious
plugin, that should mean that we're making progress towards a solution,
right?

Eric

From iavor.diatchki at gmail.com  Fri Nov 14 18:50:27 2014
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 14 Nov 2014 10:50:27 -0800
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <888BC9A3-AFDC-4FE7-9DC6-F7FC8E46C716@seidel.io>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
 <54608607.2050400@well-typed.com>
 <CAGK9nuozvmRGOm5h3mvo4u_6JuSsunAZpU35V7o-_dx9EofO2w@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3A7722@DB3PRD3001MB020.064d.mgd.msft.net>
 <54663890.4060005@well-typed.com>
 <888BC9A3-AFDC-4FE7-9DC6-F7FC8E46C716@seidel.io>
Message-ID: <CAGK9nuo+npnrbVJX6ExXXu824TD1dUiZrtBtfak4UcL=55evGQ@mail.gmail.com>

Hi,

depending on what the plugin does, it is not too hard to get into a loop.
For example, the plugin could keep generating things like:  x > 5, x + 1 >
5, x + 2 > 5, x + 3 > 5.   Of course, this is not a good plan, but one has
to be careful to avoid doing it accidentally.   I think that a good general
guideline for plugin behavior is like this:

   - Avoid generating new variables
   - Only generate constrains of the form: `x = y` or `x = K`: these always
make things more defined and could help another solver to make progress
   - These two ensure that eventually you will run out of new things to
generate.
   - It is occasionally useful to also generate more complex equations:
 (e.g. x = y + 1), but then one needs to be careful to ensure progress.

Despite this, I also don't think that plugins need to be told how many
times they've been called: it seems hard for a plugin author to know what
to do with this number.  Besides, a buggy plugin could also get stuck in
loops in other ways (e.g., get stuck in some internal loop, without going
back to GHC).


-Iavor













On Fri, Nov 14, 2014 at 10:09 AM, Eric Seidel <eric at seidel.io> wrote:

>
> > On Nov 14, 2014, at 09:14, Adam Gundry <adam at well-typed.com> wrote:
> >
> > Thanks, Simon! I've been convinced that TcS is more than we need, and I
> > think the right thing to do is to (optionally) invoke the plugin after
> > the constraints have been unflattened anyway. I've just pushed a commit
> > to wip/tc-plugins-amg that does this. Iavor, Eric, your views on how
> > convenient this alternative is would be most welcome. I'm also wondering
> > if the plugin should be told how many times it has been called, to make
> > it easier to prevent infinite loops.
>
> Thanks, I was just sitting down to figure out how to call the plugins
> with the unflattened constraints. Is there really a point though in
> calling the plugins with flattened and unflattened versions of the same
> constraints? Perhaps we should just settle on one or the other? I think
> Iavor and I are fine with only passing unflattened constraints to the
> plugins. It means a bit more work for the type-nat plugin, but shouldn't
> be a huge issue (I'll confirm this before next week).
>
> I don't think the plugins should be told how often they're being called,
> I'd prefer for GHC to track that and break the loop, if anything. I'm
> generally unconvinced that tracking the invocations is necessary at all
> though. The only way I can see an infinite loop occurring is if the plugins
> keep emitting *new* facts. Disregarding the possibility of a malicious
> plugin, that should mean that we're making progress towards a solution,
> right?
>
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141114/0817543b/attachment.html>

From iavor.diatchki at gmail.com  Fri Nov 14 18:53:31 2014
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 14 Nov 2014 10:53:31 -0800
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <CAPB=P5xs16aYPE08X4VBkN0J=wuemhPNOGGp+98Tz09dWzMECA@mail.gmail.com>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
 <54608607.2050400@well-typed.com>
 <CAGK9nuozvmRGOm5h3mvo4u_6JuSsunAZpU35V7o-_dx9EofO2w@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3A7722@DB3PRD3001MB020.064d.mgd.msft.net>
 <54663890.4060005@well-typed.com>
 <CAPB=P5xs16aYPE08X4VBkN0J=wuemhPNOGGp+98Tz09dWzMECA@mail.gmail.com>
Message-ID: <CAGK9nupHQvH2T+jiKM4gDm6L1K=iBCHVqsH88MEsxCHBX8_tbw@mail.gmail.com>

Hi,

The source code is here: https://github.com/yav/type-nat-solver
There is an example of a module using a plugin in `examples/A.hs`.

Things may be a bit broken at the moment though, as we've been changing
things a bit, to work with the new constraint solver, and plugin system.

-Iavor




On Fri, Nov 14, 2014 at 9:45 AM, Francesco Mazzoli <f at mazzo.li> wrote:

> For what it's worth, I'd be very excited to have that feature in 7.10.
>
> Iavor, is there anywhere I can read on how to try your solver for
> type-level naturals?
>
> Francesco
>
> On 14 November 2014 18:14, Adam Gundry <adam at well-typed.com> wrote:
> > Thanks, Simon! I've been convinced that TcS is more than we need, and I
> > think the right thing to do is to (optionally) invoke the plugin after
> > the constraints have been unflattened anyway. I've just pushed a commit
> > to wip/tc-plugins-amg that does this. Iavor, Eric, your views on how
> > convenient this alternative is would be most welcome. I'm also wondering
> > if the plugin should be told how many times it has been called, to make
> > it easier to prevent infinite loops.
> >
> > I'm very keen to get this into 7.10, appropriately branded as a very
> > experimental feature. Austin, have I sufficiently addressed your
> > concerns about the hs-boot file and multiple flags? Is there anything
> > else we need, apart perhaps from tests and documentation, which I'll put
> > together next week?
> >
> > Thanks,
> >
> > Adam
> >
> >
> > On 12/11/14 11:16, Simon Peyton Jones wrote:
> >> Iavor, Adam, Eric
> >>
> >>
> >>
> >> I?m happy with the general direction of the plugins stuff, so I?m mostly
> >> going to leave it to you guys to plough ahead; but I am happy to respond
> >> to questions.
> >>
> >>
> >>
> >>  * I still think it would be better to provide an escape hatch to the
> >> TcS, not merely the TcM, alongside the nice TcPluginM wrapper. Notably,
> >> Simon's new TcFlatten.unflatten needs TcS...
> >>
> >>
> >>
> >> It think the only reason for this is that ?unflatten? needs to set
> >> evidence bindings, which in turn requires access to tcs_ev_binds.  I
> >> think that everything else is in TcM.  So I suppose you could carry
> >> around the EvBindsVar if you really didn?t want TcS.  (And I can see why
> >> you wouldn?t; TcS has a lot of stuff you don?t need.)
> >>
> >>
> >>
> >> Simon
> >>
> >>
> >>
> >>
> >>
> >> *From:*Iavor Diatchki [mailto:iavor.diatchki at gmail.com]
> >> *Sent:* 10 November 2014 19:15
> >> *To:* Adam Gundry
> >> *Cc:* ghc-devs at haskell.org; Simon Peyton Jones
> >> *Subject:* Re: Typechecker plugins: request for review and another
> >> workflow question
> >>
> >>
> >>
> >> Hi,
> >>
> >>
> >>
> >> On Mon, Nov 10, 2014 at 1:31 AM, Adam Gundry <adam at well-typed.com
> >> <mailto:adam at well-typed.com>> wrote:
> >>
> >>
> >>     On the subject of that "nearly", I'm interested to learn whether you
> >>     have a suggestion to deal with unflattening, because the interface
> still
> >>     works with flat constraints only. Simon's changes should make it
> more
> >>     practical to unflatten inside the plugin, but it would be far
> easier (at
> >>     least for my purposes) if it was simply given unflattened
> constraints. I
> >>     realise that this would require the plugin loop to be pushed further
> >>     out, however, which has other difficulties.
> >>
> >>
> >>
> >> Not sure what to do about this.  With the current setup, I think either
> >> way, the plugin would have to do some extract work.   Perhaps we should
> >> run the plugins on the unflattened constraints, and leave to the plugins
> >> to manually temporarily "flatten" terms from external theories?  For
> >> example, if the type-nat plugin saw `2 * F a ~ 4`, it could temporarily
> >> work with `2 * x ~ 4`, and then when it figures out that `x ~ 2`, it
> >> could emit `F a ~ 2` (non-canonical), which would go around again, and
> >> hopefully get fully simplified.
> >>
> >>
> >>
> >>
> >>
> >>
> >>     A few other issues, of lesser importance:
> >>
> >>      * I still think it would be better to provide an escape hatch to
> the
> >>     TcS, not merely the TcM, alongside the nice TcPluginM wrapper.
> Notably,
> >>     Simon's new TcFlatten.unflatten needs TcS...
> >>
> >> I don't mind that but, if I recall correctly, to do this without more
> >> recursive modules, we had to split `TCSMonad` in two parts, one with the
> >> types, and one with other stuff.  Eric and I did this once, but we
> >> didn't commit it, because it seemed like an orthogonal change.
> >>
> >>
> >>
> >>
> >>
> >>      * Is there a way for my plugin to "solve" a given constraint (e.g.
> to
> >>     discard the uninformative "a * 1 ~ a")?
> >>
> >> Yes, you'd say something like: `TcPluginOK [(evidence, "a * 1 ~ a")] []`
> >>
> >>
> >>
> >> The first field of `TcPluginOK` are things that are solved, the second
> >> one is new work.
> >>
> >>
> >>
> >>      * It is unfortunately easy to create infinite loops by writing
> plugins
> >>     that emit wanteds but make no useful progress. Perhaps there should
> be a
> >>     limit on the number of times round the loop (like SubGoalDepth but
> for
> >>     all constraints)?
> >>
> >>
> >>
> >> Indeed, if a plugin keeps generating new work, we could go in a loop, so
> >> maybe a limit of some sort is useful.  However, note that if the plugin
> >> generates things that are already in the inert set, GHC should notice
> >> this and filter them, so we won't keep going.
> >>
> >>
> >>
> >>
> >>
> >>      * Perhaps runTcPlugin should skip invoking the plugin if there are
> no
> >>     wanteds?
> >>
> >>
> >>
> >> Oh, there is an important detail here that needs documentation!   GHC
> >> will call the plugin twice: once to improve the givens, and once to
> >> solve the wanteds.   The way to distinguish the two is exactly by the
> >> presence of the wanteds.
> >>
> >>
> >>
> >> Why might you want to improve the givens?  Suppose you had something
> >> like `x * 2 ~ 4` as a given:  then you'd really want the plugin to
> >> generate another given: `x ~ 2`, as this is likely to help the rest of
> >> the constraint solving process.
> >>
> >>
> >>
> >>
> >>      * The use of ctev_evar in runTcPlugin is partial, and fails with a
> >>     nasty error if the plugin returns a non-wanted in the solved
> constraints
> >>     list. Would it be worth catching this error and issuing a sensible
> >>     message that chastises the plugin author appropriately?
> >>
> >>
> >>
> >> Aha, good idea. Bad plugin! :-)
> >>
> >>
> >>
> >>
> >>
> >>      * Finally, I presume the comment on runTcPlugin that "The plugin is
> >>     provided only with CTyEq and CFunEq constraints" is simply outdated
> and
> >>     should be removed?
> >>
> >> Yep, thanks!
> >>
> >>
> >>
> >>     Apologies for the deluge of questions - please take them as
> evidence of
> >>     my eagerness to use this feature!
> >>
> >>
> >>
> >> Thanks for your feedback!  Also, if you feel like doing some hacking
> >> please do so---I am quite busy at the moment so I don't  have a ton of
> >> time to work on it, so any help you be most appreciated.  I know Eric is
> >> also quite keen on helping out so we can just coordinate over e-mail.
> >>
> >>
> >>
> >> -Iavor
> >
> >
> > --
> > Adam Gundry, Haskell Consultant
> > Well-Typed LLP, http://www.well-typed.com/
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141114/b26d7f4a/attachment.html>

From eric at seidel.io  Fri Nov 14 18:59:42 2014
From: eric at seidel.io (Eric Seidel)
Date: Fri, 14 Nov 2014 10:59:42 -0800
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <CAGK9nuo+npnrbVJX6ExXXu824TD1dUiZrtBtfak4UcL=55evGQ@mail.gmail.com>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
 <54608607.2050400@well-typed.com>
 <CAGK9nuozvmRGOm5h3mvo4u_6JuSsunAZpU35V7o-_dx9EofO2w@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3A7722@DB3PRD3001MB020.064d.mgd.msft.net>
 <54663890.4060005@well-typed.com>
 <888BC9A3-AFDC-4FE7-9DC6-F7FC8E46C716@seidel.io>
 <CAGK9nuo+npnrbVJX6ExXXu824TD1dUiZrtBtfak4UcL=55evGQ@mail.gmail.com>
Message-ID: <68EF1939-1B0E-4D34-BE5D-E88153CD0566@seidel.io>

Indeed, I spoke too soon. The type-nat plugin in fact causes an infinite loop when run on the unflattened constraints for one of our examples..

I think it would be reasonable for TcM to track how many times it has called the plugins and disable them after N iterations. But I don't know what would be a sensible default for N :/


> On Nov 14, 2014, at 10:50, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> Hi,
> 
> depending on what the plugin does, it is not too hard to get into a loop.  For example, the plugin could keep generating things like:  x > 5, x + 1 > 5, x + 2 > 5, x + 3 > 5.   Of course, this is not a good plan, but one has to be careful to avoid doing it accidentally.   I think that a good general guideline for plugin behavior is like this:
> 
>    - Avoid generating new variables
>    - Only generate constrains of the form: `x = y` or `x = K`: these always make things more defined and could help another solver to make progress
>    - These two ensure that eventually you will run out of new things to generate.
>    - It is occasionally useful to also generate more complex equations:  (e.g. x = y + 1), but then one needs to be careful to ensure progress.
> 
> Despite this, I also don't think that plugins need to be told how many times they've been called: it seems hard for a plugin author to know what to do with this number.  Besides, a buggy plugin could also get stuck in loops in other ways (e.g., get stuck in some internal loop, without going back to GHC).
> 
> 
> -Iavor
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Fri, Nov 14, 2014 at 10:09 AM, Eric Seidel <eric at seidel.io> wrote:
> 
> > On Nov 14, 2014, at 09:14, Adam Gundry <adam at well-typed.com> wrote:
> >
> > Thanks, Simon! I've been convinced that TcS is more than we need, and I
> > think the right thing to do is to (optionally) invoke the plugin after
> > the constraints have been unflattened anyway. I've just pushed a commit
> > to wip/tc-plugins-amg that does this. Iavor, Eric, your views on how
> > convenient this alternative is would be most welcome. I'm also wondering
> > if the plugin should be told how many times it has been called, to make
> > it easier to prevent infinite loops.
> 
> Thanks, I was just sitting down to figure out how to call the plugins
> with the unflattened constraints. Is there really a point though in
> calling the plugins with flattened and unflattened versions of the same
> constraints? Perhaps we should just settle on one or the other? I think
> Iavor and I are fine with only passing unflattened constraints to the
> plugins. It means a bit more work for the type-nat plugin, but shouldn't
> be a huge issue (I'll confirm this before next week).
> 
> I don't think the plugins should be told how often they're being called,
> I'd prefer for GHC to track that and break the loop, if anything. I'm
> generally unconvinced that tracking the invocations is necessary at all
> though. The only way I can see an infinite loop occurring is if the plugins
> keep emitting *new* facts. Disregarding the possibility of a malicious
> plugin, that should mean that we're making progress towards a solution,
> right?
> 
> Eric
> 


From shumovichy at gmail.com  Fri Nov 14 21:23:04 2014
From: shumovichy at gmail.com (Yuras Shumovich)
Date: Sat, 15 Nov 2014 00:23:04 +0300
Subject: mask in waitQSem
Message-ID: <1416000184.2762.1.camel@gmail.com>


Hello,

I was reviewing some exception handling code in base library, and I
found this line:
https://phabricator.haskell.org/diffusion/GHC/browse/master/libraries/base/Control/Concurrent/QSem.hs;165072b334ebb2ccbef38a963ac4d126f1e08c96$74

Here mask is used, but I looks completely useless for me. waitQSem
itself should be called with async exceptions masked, otherwise there is
no way to prevent resource leak.

Do anyone know why mask is used here?

I wonder whether an author of the code tried to do something different,
so there actually can be a bug hidden here. Probably
uninterruptibleMask_ should be used here? (I don't think so though.)

Thanks,
Yuras



From allbery.b at gmail.com  Fri Nov 14 21:30:11 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Fri, 14 Nov 2014 16:30:11 -0500
Subject: mask in waitQSem
In-Reply-To: <1416000184.2762.1.camel@gmail.com>
References: <1416000184.2762.1.camel@gmail.com>
Message-ID: <CAKFCL4UmwQ=Jiefa6660ERWgHzMyD35Vy+CJpe0wz_70Z53j4w@mail.gmail.com>

On Fri, Nov 14, 2014 at 4:23 PM, Yuras Shumovich <shumovichy at gmail.com>
wrote:

> Here mask is used, but I looks completely useless for me. waitQSem
> itself should be called with async exceptions masked, otherwise there is
> no way to prevent resource leak.
>
> Do anyone know why mask is used here?
>

I thought QSem was known to be completely unsafe and
http://hackage.haskell.org/package/SafeSemaphore was recommended instead,
with QSem and friends slated for removal?

In any case, there are probably leftover attempts to make it safe, yes.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141114/ed439e8d/attachment.html>

From shumovichy at gmail.com  Fri Nov 14 21:38:48 2014
From: shumovichy at gmail.com (Yuras Shumovich)
Date: Sat, 15 Nov 2014 00:38:48 +0300
Subject: mask in waitQSem
In-Reply-To: <CAKFCL4UmwQ=Jiefa6660ERWgHzMyD35Vy+CJpe0wz_70Z53j4w@mail.gmail.com>
References: <1416000184.2762.1.camel@gmail.com>
 <CAKFCL4UmwQ=Jiefa6660ERWgHzMyD35Vy+CJpe0wz_70Z53j4w@mail.gmail.com>
Message-ID: <1416001128.2762.2.camel@gmail.com>

On Fri, 2014-11-14 at 16:30 -0500, Brandon Allbery wrote:
> On Fri, Nov 14, 2014 at 4:23 PM, Yuras Shumovich <shumovichy at gmail.com>
> wrote:
> 
> > Here mask is used, but I looks completely useless for me. waitQSem
> > itself should be called with async exceptions masked, otherwise there is
> > no way to prevent resource leak.
> >
> > Do anyone know why mask is used here?
> >
> 
> I thought QSem was known to be completely unsafe and
> http://hackage.haskell.org/package/SafeSemaphore was recommended instead,
> with QSem and friends slated for removal?
> 
> In any case, there are probably leftover attempts to make it safe, yes.
> 

Oh, that explains it. Thank you a lot.

Yuras




From eric at seidel.io  Sun Nov 16 19:33:58 2014
From: eric at seidel.io (Eric Seidel)
Date: Sun, 16 Nov 2014 11:33:58 -0800
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <54663890.4060005@well-typed.com>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
 <54608607.2050400@well-typed.com>
 <CAGK9nuozvmRGOm5h3mvo4u_6JuSsunAZpU35V7o-_dx9EofO2w@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3A7722@DB3PRD3001MB020.064d.mgd.msft.net>
 <54663890.4060005@well-typed.com>
Message-ID: <191C554B-CA66-45AA-B41E-7D56FBDD6E84@seidel.io>

Hi Adam,

I've made a few changes based on your branch. Specifically I've removed
the call to runTcPlugins inside solveFlats, and have replaced it with
a specific runTcPluginsGiven that runs in a loop inside solveFlatsGiven
much like your runTcPluginsFinal runs inside solveFlatsWanted. I think
this is a bit cleaner given that you've split the wanteds-solving out
already.

The changes are at https://github.com/gridaphobe/ghc/tree/wip/tc-plugins-els
since I don't have commit access to GHC :)

Iavor and I also have a question about your change to the last statement
in solveFlatWanteds. You're putting the unsolved wanteds in a field
called wc_flat, which suggests that they ought to be flattened. But
the unsolved wanteds were just unflattened a few lines above! Is this
a problem, or is the wc_flat field in need of a new name? :)

Eric


> On Nov 14, 2014, at 09:14, Adam Gundry <adam at well-typed.com> wrote:
> 
> Thanks, Simon! I've been convinced that TcS is more than we need, and I
> think the right thing to do is to (optionally) invoke the plugin after
> the constraints have been unflattened anyway. I've just pushed a commit
> to wip/tc-plugins-amg that does this. Iavor, Eric, your views on how
> convenient this alternative is would be most welcome. I'm also wondering
> if the plugin should be told how many times it has been called, to make
> it easier to prevent infinite loops.
> 
> I'm very keen to get this into 7.10, appropriately branded as a very
> experimental feature. Austin, have I sufficiently addressed your
> concerns about the hs-boot file and multiple flags? Is there anything
> else we need, apart perhaps from tests and documentation, which I'll put
> together next week?
> 
> Thanks,
> 
> Adam
> 
> 
> On 12/11/14 11:16, Simon Peyton Jones wrote:
>> Iavor, Adam, Eric
>> 
>> 
>> 
>> I?m happy with the general direction of the plugins stuff, so I?m mostly
>> going to leave it to you guys to plough ahead; but I am happy to respond
>> to questions.
>> 
>> 
>> 
>> * I still think it would be better to provide an escape hatch to the
>> TcS, not merely the TcM, alongside the nice TcPluginM wrapper. Notably,
>> Simon's new TcFlatten.unflatten needs TcS...
>> 
>> 
>> 
>> It think the only reason for this is that ?unflatten? needs to set
>> evidence bindings, which in turn requires access to tcs_ev_binds.  I
>> think that everything else is in TcM.  So I suppose you could carry
>> around the EvBindsVar if you really didn?t want TcS.  (And I can see why
>> you wouldn?t; TcS has a lot of stuff you don?t need.)
>> 
>> 
>> 
>> Simon
>> 
>> 
>> 
>> 
>> 
>> *From:*Iavor Diatchki [mailto:iavor.diatchki at gmail.com]
>> *Sent:* 10 November 2014 19:15
>> *To:* Adam Gundry
>> *Cc:* ghc-devs at haskell.org; Simon Peyton Jones
>> *Subject:* Re: Typechecker plugins: request for review and another
>> workflow question
>> 
>> 
>> 
>> Hi,
>> 
>> 
>> 
>> On Mon, Nov 10, 2014 at 1:31 AM, Adam Gundry <adam at well-typed.com
>> <mailto:adam at well-typed.com>> wrote:
>> 
>> 
>>    On the subject of that "nearly", I'm interested to learn whether you
>>    have a suggestion to deal with unflattening, because the interface still
>>    works with flat constraints only. Simon's changes should make it more
>>    practical to unflatten inside the plugin, but it would be far easier (at
>>    least for my purposes) if it was simply given unflattened constraints. I
>>    realise that this would require the plugin loop to be pushed further
>>    out, however, which has other difficulties.
>> 
>> 
>> 
>> Not sure what to do about this.  With the current setup, I think either
>> way, the plugin would have to do some extract work.   Perhaps we should
>> run the plugins on the unflattened constraints, and leave to the plugins
>> to manually temporarily "flatten" terms from external theories?  For
>> example, if the type-nat plugin saw `2 * F a ~ 4`, it could temporarily
>> work with `2 * x ~ 4`, and then when it figures out that `x ~ 2`, it
>> could emit `F a ~ 2` (non-canonical), which would go around again, and
>> hopefully get fully simplified.
>> 
>> 
>> 
>> 
>> 
>> 
>>    A few other issues, of lesser importance:
>> 
>>     * I still think it would be better to provide an escape hatch to the
>>    TcS, not merely the TcM, alongside the nice TcPluginM wrapper. Notably,
>>    Simon's new TcFlatten.unflatten needs TcS...
>> 
>> I don't mind that but, if I recall correctly, to do this without more
>> recursive modules, we had to split `TCSMonad` in two parts, one with the
>> types, and one with other stuff.  Eric and I did this once, but we
>> didn't commit it, because it seemed like an orthogonal change.
>> 
>> 
>> 
>> 
>> 
>>     * Is there a way for my plugin to "solve" a given constraint (e.g. to
>>    discard the uninformative "a * 1 ~ a")?
>> 
>> Yes, you'd say something like: `TcPluginOK [(evidence, "a * 1 ~ a")] []`
>> 
>> 
>> 
>> The first field of `TcPluginOK` are things that are solved, the second
>> one is new work.
>> 
>> 
>> 
>>     * It is unfortunately easy to create infinite loops by writing plugins
>>    that emit wanteds but make no useful progress. Perhaps there should be a
>>    limit on the number of times round the loop (like SubGoalDepth but for
>>    all constraints)?
>> 
>> 
>> 
>> Indeed, if a plugin keeps generating new work, we could go in a loop, so
>> maybe a limit of some sort is useful.  However, note that if the plugin
>> generates things that are already in the inert set, GHC should notice
>> this and filter them, so we won't keep going.
>> 
>> 
>> 
>> 
>> 
>>     * Perhaps runTcPlugin should skip invoking the plugin if there are no
>>    wanteds?
>> 
>> 
>> 
>> Oh, there is an important detail here that needs documentation!   GHC
>> will call the plugin twice: once to improve the givens, and once to
>> solve the wanteds.   The way to distinguish the two is exactly by the
>> presence of the wanteds.
>> 
>> 
>> 
>> Why might you want to improve the givens?  Suppose you had something
>> like `x * 2 ~ 4` as a given:  then you'd really want the plugin to
>> generate another given: `x ~ 2`, as this is likely to help the rest of
>> the constraint solving process.
>> 
>> 
>> 
>> 
>>     * The use of ctev_evar in runTcPlugin is partial, and fails with a
>>    nasty error if the plugin returns a non-wanted in the solved constraints
>>    list. Would it be worth catching this error and issuing a sensible
>>    message that chastises the plugin author appropriately?
>> 
>> 
>> 
>> Aha, good idea. Bad plugin! :-)
>> 
>> 
>> 
>> 
>> 
>>     * Finally, I presume the comment on runTcPlugin that "The plugin is
>>    provided only with CTyEq and CFunEq constraints" is simply outdated and
>>    should be removed?
>> 
>> Yep, thanks!
>> 
>> 
>> 
>>    Apologies for the deluge of questions - please take them as evidence of
>>    my eagerness to use this feature!
>> 
>> 
>> 
>> Thanks for your feedback!  Also, if you feel like doing some hacking
>> please do so---I am quite busy at the moment so I don't  have a ton of
>> time to work on it, so any help you be most appreciated.  I know Eric is
>> also quite keen on helping out so we can just coordinate over e-mail.
>> 
>> 
>> 
>> -Iavor
> 
> 
> -- 
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/


From merijn at inconsistent.nl  Sun Nov 16 21:42:12 2014
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Sun, 16 Nov 2014 13:42:12 -0800
Subject: More flexible literate Haskell extensions (Trac #9789),
 summary on wiki
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3BDD49@DB3PRD3001MB020.064d.mgd.msft.net>
References: <CD574F24-99A8-4276-BED2-8C3050E17332@inconsistent.nl>
 <618BE556AADD624C9C918AA5D5911BEF3F3BDD49@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <13F0D94D-E770-43C2-87FE-169E3A5ED1EA@inconsistent.nl>

Hi Simon,

Thanks for the comments. I think most of the confusion stems from people overthinking the scope of what I was proposing. I'll clear up the page a bit as it's currently conflating implementation details with semantics.

> On 14 Nov 2014, at 2:29, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> Would it be possible to have a section
>   a) describing a single alternative, as precisely as possible.

The single alternative would simply be:
If GHC tries to find the source for a module Foo and none of "Foo.hs", "Foo.lhs", "Foo.hsig" or "Foo.lhsig" are found, it will accept any file with a "Foo.lhs.*" extension, i.e., "Foo.lhs.md", "Foo.lhs.tex", etc.

>   b) saying what the effect or meaning of proposal is

The proposal does NOT modify the way GHC treats the contents of files or unlits literate haskell in anyway. While I'm in favour of supporting more literate formats, that's orthogonal to this proposal.

> For (a), is Foo.hs still ok?  Foo.lhs?  What if both exist and/or Foo.md.hs or whatever?

Yes, both "Foo.hs" and "Foo.lhs" are still ok. I don't think the manual specifies what GHC does in the case "Foo.hs" AND "Foo.lhs" both exist. But the implementation prefers extensions in the following order: "hs", "lhs", "hsig" and "lhsig". I would just add the new allowed extension behind that as lower priority than the current ones.

> For (b) what does a suffix of Foo.hs.md mean?  Presumably there is some markdown in there.  But how is it delimited?  Is md the only one proposed or are there others? Is it meant to be extensible or is there a fixed set?

See my earlier point, I do *not* intend to affect the way GHC interprets/unlits the contents of files. Pandoc is already perfectly happy to work with literate files, it just currently lacks a way to determine what the content type of the non-literate bits is. Which is what I hope to deal with here.

Cheers,
Merijn

From simonpj at microsoft.com  Sun Nov 16 22:09:53 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Sun, 16 Nov 2014 22:09:53 +0000
Subject: More flexible literate Haskell extensions (Trac #9789), summary
 on wiki
In-Reply-To: <13F0D94D-E770-43C2-87FE-169E3A5ED1EA@inconsistent.nl>
References: <CD574F24-99A8-4276-BED2-8C3050E17332@inconsistent.nl>
 <618BE556AADD624C9C918AA5D5911BEF3F3BDD49@DB3PRD3001MB020.064d.mgd.msft.net>
 <13F0D94D-E770-43C2-87FE-169E3A5ED1EA@inconsistent.nl>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3C181F@DB3PRD3001MB020.064d.mgd.msft.net>

Marijn,

Thanks.  Can you make sure that you update the wiki page to reflect what you say here?  Email is transitory; the wiki page gives the *specification* of the feature, and says unambiguously what you intend.  Misunderstandings expressed in email are simply tell you how to improve the wiki page!

thanks

Simon

| -----Original Message-----
| From: Merijn Verstraaten [mailto:merijn at inconsistent.nl]
| Sent: 16 November 2014 21:42
| To: Simon Peyton Jones
| Cc: ghc-devs at haskell.org; GHC Users Mailing List
| Subject: Re: More flexible literate Haskell extensions (Trac #9789),
| summary on wiki
| 
| Hi Simon,
| 
| Thanks for the comments. I think most of the confusion stems from people
| overthinking the scope of what I was proposing. I'll clear up the page a
| bit as it's currently conflating implementation details with semantics.
| 
| > On 14 Nov 2014, at 2:29, Simon Peyton Jones <simonpj at microsoft.com>
| wrote:
| > Would it be possible to have a section
| >   a) describing a single alternative, as precisely as possible.
| 
| The single alternative would simply be:
| If GHC tries to find the source for a module Foo and none of "Foo.hs",
| "Foo.lhs", "Foo.hsig" or "Foo.lhsig" are found, it will accept any file
| with a "Foo.lhs.*" extension, i.e., "Foo.lhs.md", "Foo.lhs.tex", etc.
| 
| >   b) saying what the effect or meaning of proposal is
| 
| The proposal does NOT modify the way GHC treats the contents of files or
| unlits literate haskell in anyway. While I'm in favour of supporting more
| literate formats, that's orthogonal to this proposal.
| 
| > For (a), is Foo.hs still ok?  Foo.lhs?  What if both exist and/or
| Foo.md.hs or whatever?
| 
| Yes, both "Foo.hs" and "Foo.lhs" are still ok. I don't think the manual
| specifies what GHC does in the case "Foo.hs" AND "Foo.lhs" both exist.
| But the implementation prefers extensions in the following order: "hs",
| "lhs", "hsig" and "lhsig". I would just add the new allowed extension
| behind that as lower priority than the current ones.
| 
| > For (b) what does a suffix of Foo.hs.md mean?  Presumably there is some
| markdown in there.  But how is it delimited?  Is md the only one proposed
| or are there others? Is it meant to be extensible or is there a fixed
| set?
| 
| See my earlier point, I do *not* intend to affect the way GHC
| interprets/unlits the contents of files. Pandoc is already perfectly
| happy to work with literate files, it just currently lacks a way to
| determine what the content type of the non-literate bits is. Which is
| what I hope to deal with here.
| 
| Cheers,
| Merijn

From merijn at inconsistent.nl  Sun Nov 16 22:57:24 2014
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Sun, 16 Nov 2014 14:57:24 -0800
Subject: More flexible literate Haskell extensions (Trac #9789),
 summary on wiki
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3C181F@DB3PRD3001MB020.064d.mgd.msft.net>
References: <CD574F24-99A8-4276-BED2-8C3050E17332@inconsistent.nl>
 <618BE556AADD624C9C918AA5D5911BEF3F3BDD49@DB3PRD3001MB020.064d.mgd.msft.net>
 <13F0D94D-E770-43C2-87FE-169E3A5ED1EA@inconsistent.nl>
 <618BE556AADD624C9C918AA5D5911BEF3F3C181F@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <01F8A9A8-C7CC-401C-959F-46DEB7EF07A2@inconsistent.nl>

On 16 Nov 2014, at 14:09, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> Thanks.  Can you make sure that you update the wiki page to reflect what you say here?  Email is transitory; the wiki page gives the *specification* of the feature, and says unambiguously what you intend.  Misunderstandings expressed in email are simply tell you how to improve the wiki page!

I had already updated the wiki with the relevant notes before replying, but apparently I forgot to mention this!

Cheers,
Merijn

From mail at joachim-breitner.de  Mon Nov 17 09:31:40 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 17 Nov 2014 10:31:40 +0100
Subject: HEADS UP: Keeping the "Newcomers" wiki page alive
In-Reply-To: <201411131456.17703.jan.stolarek@p.lodz.pl>
References: <201411121358.48239.jan.stolarek@p.lodz.pl>
 <201411130844.00005.jan.stolarek@p.lodz.pl>
 <1415867237.1441.1.camel@joachim-breitner.de>
 <201411131456.17703.jan.stolarek@p.lodz.pl>
Message-ID: <1416216700.4660.7.camel@joachim-breitner.de>

Hi,


Am Donnerstag, den 13.11.2014, 14:56 +0100 schrieb Jan Stolarek:
> HEADS UP: if you see a ticket that is easy enough to be tackled by a newcomer please tag it 
> using "newcomer" keyword.
> 
> I already added "newcomer" keyword to tickets that were listed on the Newcomers page and replaced 
> the static list with dynamicaly generated one. I decided to filter out tickets that have an owner 
> so that people are not redirected to tickets that are being worked on.

incidentally, Debian started to use the same tag "newcomer" to tag its
bugs of the same nature:
http://www.donarmstrong.com/posts/newcomer_bts_tag/

So our choice of tag was a good one :-)

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141117/86367107/attachment.sig>

From mikolaj at well-typed.com  Mon Nov 17 11:34:20 2014
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Mon, 17 Nov 2014 12:34:20 +0100
Subject: Can't compile GHC-7.8.3 from git, fails on haskell98 library
In-Reply-To: <87a949oak7.fsf@gmail.com>
References: <alpine.DEB.2.10.1411021415170.2047@galaxy>
 <alpine.DEB.2.10.1411022127230.2047@galaxy>
 <87a949oak7.fsf@gmail.com>
Message-ID: <CAHFo2uoH18DDA2DP-oGj3TFQPQHDcNf7woJ55GGPLTeqXKayng@mail.gmail.com>

I've brought back the old section about fingerprint.py for 7.8.*
to the GettingTheSources wiki page, updated it, to the best
of my knowledge, and added the info from the email below.
Please correct the section if I mixed up anything. I think,
for as long as 7.8.* is in widespread use, the section has to stay,
even though it's irrelevant for 7.10.

https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#Trackingthefullrepositorystatepre-March2014e.g.the7.8.branches

On Sun, Nov 2, 2014 at 5:02 PM, Herbert Valerio Riedel
<hvriedel at gmail.com> wrote:
> Hello Gergo,
>
> On 2014-11-02 at 14:29:06 +0100, Dr. ERDI Gergo wrote:
>> On Sun, 2 Nov 2014, Dr. ERDI Gergo wrote:
>>
>>> On a completely clean clone, I've checked out the tag
>>> ghc-7.8.3-release, ran sync-all get, boot, and configure, but the
>>> build fails on haskell98. Any ideas what I could be doing wrong?
>>
>> I've worked around this by manually checking out the 'ghc-7.8' branch
>> of various submodules until I got it to work (I think the ones I
>> needed to change were dph, haskell98, haskell2010, template-haskell,
>> and haddock, but I'm not sure). It seems the `ghc-7.8.3-release` tag
>> is in a horrible shape in terms of reproducable building of imported
>> repos. Is anyone looking into fixing this?
>
> Starting with GHC 7.8.x, fingerprints are written into
> annotated & gpg-signed release tags:
>
>   http://git.haskell.org/ghc.git/tag/refs/tags/ghc-7.8.3-release
>
> That way you're able to restore via the fingerprint for a given release
> via:
>
>  ./utils/fingerprint/fingerprint.py restore -f <(git show ghc-7.8.3-release | grep -F '|')
>
> I'm just surprised I couldn't find that described anywhere in the wiki,
> I was sure it was written down somewhere...
>
> hth,
>   hvr
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From austin at well-typed.com  Mon Nov 17 15:45:39 2014
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 17 Nov 2014 09:45:39 -0600
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <191C554B-CA66-45AA-B41E-7D56FBDD6E84@seidel.io>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
 <54608607.2050400@well-typed.com>
 <CAGK9nuozvmRGOm5h3mvo4u_6JuSsunAZpU35V7o-_dx9EofO2w@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3A7722@DB3PRD3001MB020.064d.mgd.msft.net>
 <54663890.4060005@well-typed.com>
 <191C554B-CA66-45AA-B41E-7D56FBDD6E84@seidel.io>
Message-ID: <CAEs96n1WqU0MzdC=xO7fENmGgzzooy9yNa3fXmatT7B+_sga7w@mail.gmail.com>

This looks excellent! Thank you Adam and Eric for helping Iavor with this.

But I'm slightly confused by the git history since it seems to be
cluttered with a few merges, and it seems like Eric has pushed the
latest changes to all this. The branch is also a little bit behind
master too.

Iavor, would you like to:

  1) Incorporate all of the changes from Eric and Adam,
  2) Rebase your work on HEAD so we can read it in a digestible way?

I still need to read over all the changes since my first review, since
Adam addressed them. The 7.10 branch is at the end of this week, but
this would be a really cool feature to have.

Thanks!

The branch for 7.10 is now the end of this week! It would be nice to get this in

On Sun, Nov 16, 2014 at 1:33 PM, Eric Seidel <eric at seidel.io> wrote:
> Hi Adam,
>
> I've made a few changes based on your branch. Specifically I've removed
> the call to runTcPlugins inside solveFlats, and have replaced it with
> a specific runTcPluginsGiven that runs in a loop inside solveFlatsGiven
> much like your runTcPluginsFinal runs inside solveFlatsWanted. I think
> this is a bit cleaner given that you've split the wanteds-solving out
> already.
>
> The changes are at https://github.com/gridaphobe/ghc/tree/wip/tc-plugins-els
> since I don't have commit access to GHC :)
>
> Iavor and I also have a question about your change to the last statement
> in solveFlatWanteds. You're putting the unsolved wanteds in a field
> called wc_flat, which suggests that they ought to be flattened. But
> the unsolved wanteds were just unflattened a few lines above! Is this
> a problem, or is the wc_flat field in need of a new name? :)
>
> Eric
>
>
>> On Nov 14, 2014, at 09:14, Adam Gundry <adam at well-typed.com> wrote:
>>
>> Thanks, Simon! I've been convinced that TcS is more than we need, and I
>> think the right thing to do is to (optionally) invoke the plugin after
>> the constraints have been unflattened anyway. I've just pushed a commit
>> to wip/tc-plugins-amg that does this. Iavor, Eric, your views on how
>> convenient this alternative is would be most welcome. I'm also wondering
>> if the plugin should be told how many times it has been called, to make
>> it easier to prevent infinite loops.
>>
>> I'm very keen to get this into 7.10, appropriately branded as a very
>> experimental feature. Austin, have I sufficiently addressed your
>> concerns about the hs-boot file and multiple flags? Is there anything
>> else we need, apart perhaps from tests and documentation, which I'll put
>> together next week?
>>
>> Thanks,
>>
>> Adam
>>
>>
>> On 12/11/14 11:16, Simon Peyton Jones wrote:
>>> Iavor, Adam, Eric
>>>
>>>
>>>
>>> I?m happy with the general direction of the plugins stuff, so I?m mostly
>>> going to leave it to you guys to plough ahead; but I am happy to respond
>>> to questions.
>>>
>>>
>>>
>>> * I still think it would be better to provide an escape hatch to the
>>> TcS, not merely the TcM, alongside the nice TcPluginM wrapper. Notably,
>>> Simon's new TcFlatten.unflatten needs TcS...
>>>
>>>
>>>
>>> It think the only reason for this is that ?unflatten? needs to set
>>> evidence bindings, which in turn requires access to tcs_ev_binds.  I
>>> think that everything else is in TcM.  So I suppose you could carry
>>> around the EvBindsVar if you really didn?t want TcS.  (And I can see why
>>> you wouldn?t; TcS has a lot of stuff you don?t need.)
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>>
>>>
>>> *From:*Iavor Diatchki [mailto:iavor.diatchki at gmail.com]
>>> *Sent:* 10 November 2014 19:15
>>> *To:* Adam Gundry
>>> *Cc:* ghc-devs at haskell.org; Simon Peyton Jones
>>> *Subject:* Re: Typechecker plugins: request for review and another
>>> workflow question
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> On Mon, Nov 10, 2014 at 1:31 AM, Adam Gundry <adam at well-typed.com
>>> <mailto:adam at well-typed.com>> wrote:
>>>
>>>
>>>    On the subject of that "nearly", I'm interested to learn whether you
>>>    have a suggestion to deal with unflattening, because the interface still
>>>    works with flat constraints only. Simon's changes should make it more
>>>    practical to unflatten inside the plugin, but it would be far easier (at
>>>    least for my purposes) if it was simply given unflattened constraints. I
>>>    realise that this would require the plugin loop to be pushed further
>>>    out, however, which has other difficulties.
>>>
>>>
>>>
>>> Not sure what to do about this.  With the current setup, I think either
>>> way, the plugin would have to do some extract work.   Perhaps we should
>>> run the plugins on the unflattened constraints, and leave to the plugins
>>> to manually temporarily "flatten" terms from external theories?  For
>>> example, if the type-nat plugin saw `2 * F a ~ 4`, it could temporarily
>>> work with `2 * x ~ 4`, and then when it figures out that `x ~ 2`, it
>>> could emit `F a ~ 2` (non-canonical), which would go around again, and
>>> hopefully get fully simplified.
>>>
>>>
>>>
>>>
>>>
>>>
>>>    A few other issues, of lesser importance:
>>>
>>>     * I still think it would be better to provide an escape hatch to the
>>>    TcS, not merely the TcM, alongside the nice TcPluginM wrapper. Notably,
>>>    Simon's new TcFlatten.unflatten needs TcS...
>>>
>>> I don't mind that but, if I recall correctly, to do this without more
>>> recursive modules, we had to split `TCSMonad` in two parts, one with the
>>> types, and one with other stuff.  Eric and I did this once, but we
>>> didn't commit it, because it seemed like an orthogonal change.
>>>
>>>
>>>
>>>
>>>
>>>     * Is there a way for my plugin to "solve" a given constraint (e.g. to
>>>    discard the uninformative "a * 1 ~ a")?
>>>
>>> Yes, you'd say something like: `TcPluginOK [(evidence, "a * 1 ~ a")] []`
>>>
>>>
>>>
>>> The first field of `TcPluginOK` are things that are solved, the second
>>> one is new work.
>>>
>>>
>>>
>>>     * It is unfortunately easy to create infinite loops by writing plugins
>>>    that emit wanteds but make no useful progress. Perhaps there should be a
>>>    limit on the number of times round the loop (like SubGoalDepth but for
>>>    all constraints)?
>>>
>>>
>>>
>>> Indeed, if a plugin keeps generating new work, we could go in a loop, so
>>> maybe a limit of some sort is useful.  However, note that if the plugin
>>> generates things that are already in the inert set, GHC should notice
>>> this and filter them, so we won't keep going.
>>>
>>>
>>>
>>>
>>>
>>>     * Perhaps runTcPlugin should skip invoking the plugin if there are no
>>>    wanteds?
>>>
>>>
>>>
>>> Oh, there is an important detail here that needs documentation!   GHC
>>> will call the plugin twice: once to improve the givens, and once to
>>> solve the wanteds.   The way to distinguish the two is exactly by the
>>> presence of the wanteds.
>>>
>>>
>>>
>>> Why might you want to improve the givens?  Suppose you had something
>>> like `x * 2 ~ 4` as a given:  then you'd really want the plugin to
>>> generate another given: `x ~ 2`, as this is likely to help the rest of
>>> the constraint solving process.
>>>
>>>
>>>
>>>
>>>     * The use of ctev_evar in runTcPlugin is partial, and fails with a
>>>    nasty error if the plugin returns a non-wanted in the solved constraints
>>>    list. Would it be worth catching this error and issuing a sensible
>>>    message that chastises the plugin author appropriately?
>>>
>>>
>>>
>>> Aha, good idea. Bad plugin! :-)
>>>
>>>
>>>
>>>
>>>
>>>     * Finally, I presume the comment on runTcPlugin that "The plugin is
>>>    provided only with CTyEq and CFunEq constraints" is simply outdated and
>>>    should be removed?
>>>
>>> Yep, thanks!
>>>
>>>
>>>
>>>    Apologies for the deluge of questions - please take them as evidence of
>>>    my eagerness to use this feature!
>>>
>>>
>>>
>>> Thanks for your feedback!  Also, if you feel like doing some hacking
>>> please do so---I am quite busy at the moment so I don't  have a ton of
>>> time to work on it, so any help you be most appreciated.  I know Eric is
>>> also quite keen on helping out so we can just coordinate over e-mail.
>>>
>>>
>>>
>>> -Iavor
>>
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From mail at joachim-breitner.de  Mon Nov 17 15:46:29 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 17 Nov 2014 16:46:29 +0100
Subject: [commit: ghc] master: Fix a bug introduced with allocation
 counters (2a6f193)
In-Reply-To: <20141117131348.D90DB3A300@ghc.haskell.org>
References: <20141117131348.D90DB3A300@ghc.haskell.org>
Message-ID: <1416239189.4660.10.camel@joachim-breitner.de>

Hi Simon,


Am Montag, den 17.11.2014, 13:13 +0000 schrieb git at git.haskell.org:
> commit 2a6f193bb82f88e8dcb919ee7affc13feae56e98
> Author: Simon Marlow <marlowsd at gmail.com>
> Date:   Mon Nov 17 13:03:56 2014 +0000
> 
>     Fix a bug introduced with allocation counters

I think you forgot to add a file:

=====> ffi023(normal) 3093 of 4195 [0, 0, 0] 
cd ./ffi/should_run && '/home/travis/build/ghc/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history -o ffi023 ffi023.hs  ffi023_c.c  >ffi023.comp.stderr 2>&1
Compile failed (status 256) errors were:

ffi023_c.c:1:25:
     fatal error: ffi023_stub.h: No such file or directory
compilation terminated.

*** unexpected failure for ffi023(normal)


Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141117/d4c7a904/attachment.sig>

From austin at well-typed.com  Mon Nov 17 15:50:27 2014
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 17 Nov 2014 09:50:27 -0600
Subject: HEADS UP: Keeping the "Newcomers" wiki page alive
In-Reply-To: <1416216700.4660.7.camel@joachim-breitner.de>
References: <201411121358.48239.jan.stolarek@p.lodz.pl>
 <201411130844.00005.jan.stolarek@p.lodz.pl>
 <1415867237.1441.1.camel@joachim-breitner.de>
 <201411131456.17703.jan.stolarek@p.lodz.pl>
 <1416216700.4660.7.camel@joachim-breitner.de>
Message-ID: <CAEs96n0Pqk3x0pUFFhd_7aLGWiT4FQg-7Y5_j4iE1pFj8Gj6VA@mail.gmail.com>

Thanks for doing this Jan. I think a ticket category works a lot
better than just a page alone.

Simon and I talked about this once, and another good point is that by
having a category, it's a lot easier for regular, more experienced
developers to sweep the 'newcomers' list and fix anything that needs
it, perhaps for a pending release that may be soon.

But these days we seem to have a somewhat healthy influx of developers
and patches, so maybe these tickets can just get fixed the natural
way. :)

On Mon, Nov 17, 2014 at 3:31 AM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Hi,
>
>
> Am Donnerstag, den 13.11.2014, 14:56 +0100 schrieb Jan Stolarek:
>> HEADS UP: if you see a ticket that is easy enough to be tackled by a newcomer please tag it
>> using "newcomer" keyword.
>>
>> I already added "newcomer" keyword to tickets that were listed on the Newcomers page and replaced
>> the static list with dynamicaly generated one. I decided to filter out tickets that have an owner
>> so that people are not redirected to tickets that are being worked on.
>
> incidentally, Debian started to use the same tag "newcomer" to tag its
> bugs of the same nature:
> http://www.donarmstrong.com/posts/newcomer_bts_tag/
>
> So our choice of tag was a good one :-)
>
> Greetings,
> Joachim
>
> --
> Joachim ?nomeata? Breitner
>   mail at joachim-breitner.de ? http://www.joachim-breitner.de/
>   Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From eric at seidel.io  Mon Nov 17 15:54:07 2014
From: eric at seidel.io (Eric Seidel)
Date: Mon, 17 Nov 2014 07:54:07 -0800
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <CAEs96n1WqU0MzdC=xO7fENmGgzzooy9yNa3fXmatT7B+_sga7w@mail.gmail.com>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
 <54608607.2050400@well-typed.com>
 <CAGK9nuozvmRGOm5h3mvo4u_6JuSsunAZpU35V7o-_dx9EofO2w@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3A7722@DB3PRD3001MB020.064d.mgd.msft.net>
 <54663890.4060005@well-typed.com>
 <191C554B-CA66-45AA-B41E-7D56FBDD6E84@seidel.io>
 <CAEs96n1WqU0MzdC=xO7fENmGgzzooy9yNa3fXmatT7B+_sga7w@mail.gmail.com>
Message-ID: <1416239647.3721140.191986293.5D78BBF2@webmail.messagingengine.com>

Would it easier to send the diff to Phab? I don't think the git history
will be particularly illuminating. 

On Mon, Nov 17, 2014, at 07:45, Austin Seipp wrote:
> This looks excellent! Thank you Adam and Eric for helping Iavor with
> this.
> 
> But I'm slightly confused by the git history since it seems to be
> cluttered with a few merges, and it seems like Eric has pushed the
> latest changes to all this. The branch is also a little bit behind
> master too.
> 
> Iavor, would you like to:
> 
>   1) Incorporate all of the changes from Eric and Adam,
>   2) Rebase your work on HEAD so we can read it in a digestible way?
> 
> I still need to read over all the changes since my first review, since
> Adam addressed them. The 7.10 branch is at the end of this week, but
> this would be a really cool feature to have.
> 
> Thanks!
> 
> The branch for 7.10 is now the end of this week! It would be nice to get
> this in
> 
> On Sun, Nov 16, 2014 at 1:33 PM, Eric Seidel <eric at seidel.io> wrote:
> > Hi Adam,
> >
> > I've made a few changes based on your branch. Specifically I've removed
> > the call to runTcPlugins inside solveFlats, and have replaced it with
> > a specific runTcPluginsGiven that runs in a loop inside solveFlatsGiven
> > much like your runTcPluginsFinal runs inside solveFlatsWanted. I think
> > this is a bit cleaner given that you've split the wanteds-solving out
> > already.
> >
> > The changes are at https://github.com/gridaphobe/ghc/tree/wip/tc-plugins-els
> > since I don't have commit access to GHC :)
> >
> > Iavor and I also have a question about your change to the last statement
> > in solveFlatWanteds. You're putting the unsolved wanteds in a field
> > called wc_flat, which suggests that they ought to be flattened. But
> > the unsolved wanteds were just unflattened a few lines above! Is this
> > a problem, or is the wc_flat field in need of a new name? :)
> >
> > Eric
> >
> >
> >> On Nov 14, 2014, at 09:14, Adam Gundry <adam at well-typed.com> wrote:
> >>
> >> Thanks, Simon! I've been convinced that TcS is more than we need, and I
> >> think the right thing to do is to (optionally) invoke the plugin after
> >> the constraints have been unflattened anyway. I've just pushed a commit
> >> to wip/tc-plugins-amg that does this. Iavor, Eric, your views on how
> >> convenient this alternative is would be most welcome. I'm also wondering
> >> if the plugin should be told how many times it has been called, to make
> >> it easier to prevent infinite loops.
> >>
> >> I'm very keen to get this into 7.10, appropriately branded as a very
> >> experimental feature. Austin, have I sufficiently addressed your
> >> concerns about the hs-boot file and multiple flags? Is there anything
> >> else we need, apart perhaps from tests and documentation, which I'll put
> >> together next week?
> >>
> >> Thanks,
> >>
> >> Adam
> >>
> >>
> >> On 12/11/14 11:16, Simon Peyton Jones wrote:
> >>> Iavor, Adam, Eric
> >>>
> >>>
> >>>
> >>> I?m happy with the general direction of the plugins stuff, so I?m mostly
> >>> going to leave it to you guys to plough ahead; but I am happy to respond
> >>> to questions.
> >>>
> >>>
> >>>
> >>> * I still think it would be better to provide an escape hatch to the
> >>> TcS, not merely the TcM, alongside the nice TcPluginM wrapper. Notably,
> >>> Simon's new TcFlatten.unflatten needs TcS...
> >>>
> >>>
> >>>
> >>> It think the only reason for this is that ?unflatten? needs to set
> >>> evidence bindings, which in turn requires access to tcs_ev_binds.  I
> >>> think that everything else is in TcM.  So I suppose you could carry
> >>> around the EvBindsVar if you really didn?t want TcS.  (And I can see why
> >>> you wouldn?t; TcS has a lot of stuff you don?t need.)
> >>>
> >>>
> >>>
> >>> Simon
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> *From:*Iavor Diatchki [mailto:iavor.diatchki at gmail.com]
> >>> *Sent:* 10 November 2014 19:15
> >>> *To:* Adam Gundry
> >>> *Cc:* ghc-devs at haskell.org; Simon Peyton Jones
> >>> *Subject:* Re: Typechecker plugins: request for review and another
> >>> workflow question
> >>>
> >>>
> >>>
> >>> Hi,
> >>>
> >>>
> >>>
> >>> On Mon, Nov 10, 2014 at 1:31 AM, Adam Gundry <adam at well-typed.com
> >>> <mailto:adam at well-typed.com>> wrote:
> >>>
> >>>
> >>>    On the subject of that "nearly", I'm interested to learn whether you
> >>>    have a suggestion to deal with unflattening, because the interface still
> >>>    works with flat constraints only. Simon's changes should make it more
> >>>    practical to unflatten inside the plugin, but it would be far easier (at
> >>>    least for my purposes) if it was simply given unflattened constraints. I
> >>>    realise that this would require the plugin loop to be pushed further
> >>>    out, however, which has other difficulties.
> >>>
> >>>
> >>>
> >>> Not sure what to do about this.  With the current setup, I think either
> >>> way, the plugin would have to do some extract work.   Perhaps we should
> >>> run the plugins on the unflattened constraints, and leave to the plugins
> >>> to manually temporarily "flatten" terms from external theories?  For
> >>> example, if the type-nat plugin saw `2 * F a ~ 4`, it could temporarily
> >>> work with `2 * x ~ 4`, and then when it figures out that `x ~ 2`, it
> >>> could emit `F a ~ 2` (non-canonical), which would go around again, and
> >>> hopefully get fully simplified.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>    A few other issues, of lesser importance:
> >>>
> >>>     * I still think it would be better to provide an escape hatch to the
> >>>    TcS, not merely the TcM, alongside the nice TcPluginM wrapper. Notably,
> >>>    Simon's new TcFlatten.unflatten needs TcS...
> >>>
> >>> I don't mind that but, if I recall correctly, to do this without more
> >>> recursive modules, we had to split `TCSMonad` in two parts, one with the
> >>> types, and one with other stuff.  Eric and I did this once, but we
> >>> didn't commit it, because it seemed like an orthogonal change.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Is there a way for my plugin to "solve" a given constraint (e.g. to
> >>>    discard the uninformative "a * 1 ~ a")?
> >>>
> >>> Yes, you'd say something like: `TcPluginOK [(evidence, "a * 1 ~ a")] []`
> >>>
> >>>
> >>>
> >>> The first field of `TcPluginOK` are things that are solved, the second
> >>> one is new work.
> >>>
> >>>
> >>>
> >>>     * It is unfortunately easy to create infinite loops by writing plugins
> >>>    that emit wanteds but make no useful progress. Perhaps there should be a
> >>>    limit on the number of times round the loop (like SubGoalDepth but for
> >>>    all constraints)?
> >>>
> >>>
> >>>
> >>> Indeed, if a plugin keeps generating new work, we could go in a loop, so
> >>> maybe a limit of some sort is useful.  However, note that if the plugin
> >>> generates things that are already in the inert set, GHC should notice
> >>> this and filter them, so we won't keep going.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Perhaps runTcPlugin should skip invoking the plugin if there are no
> >>>    wanteds?
> >>>
> >>>
> >>>
> >>> Oh, there is an important detail here that needs documentation!   GHC
> >>> will call the plugin twice: once to improve the givens, and once to
> >>> solve the wanteds.   The way to distinguish the two is exactly by the
> >>> presence of the wanteds.
> >>>
> >>>
> >>>
> >>> Why might you want to improve the givens?  Suppose you had something
> >>> like `x * 2 ~ 4` as a given:  then you'd really want the plugin to
> >>> generate another given: `x ~ 2`, as this is likely to help the rest of
> >>> the constraint solving process.
> >>>
> >>>
> >>>
> >>>
> >>>     * The use of ctev_evar in runTcPlugin is partial, and fails with a
> >>>    nasty error if the plugin returns a non-wanted in the solved constraints
> >>>    list. Would it be worth catching this error and issuing a sensible
> >>>    message that chastises the plugin author appropriately?
> >>>
> >>>
> >>>
> >>> Aha, good idea. Bad plugin! :-)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>     * Finally, I presume the comment on runTcPlugin that "The plugin is
> >>>    provided only with CTyEq and CFunEq constraints" is simply outdated and
> >>>    should be removed?
> >>>
> >>> Yep, thanks!
> >>>
> >>>
> >>>
> >>>    Apologies for the deluge of questions - please take them as evidence of
> >>>    my eagerness to use this feature!
> >>>
> >>>
> >>>
> >>> Thanks for your feedback!  Also, if you feel like doing some hacking
> >>> please do so---I am quite busy at the moment so I don't  have a ton of
> >>> time to work on it, so any help you be most appreciated.  I know Eric is
> >>> also quite keen on helping out so we can just coordinate over e-mail.
> >>>
> >>>
> >>>
> >>> -Iavor
> >>
> >>
> >> --
> >> Adam Gundry, Haskell Consultant
> >> Well-Typed LLP, http://www.well-typed.com/
> >
> 
> 
> 
> -- 
> Regards,
> 
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/

From austin at well-typed.com  Mon Nov 17 15:59:38 2014
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 17 Nov 2014 09:59:38 -0600
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <1416239647.3721140.191986293.5D78BBF2@webmail.messagingengine.com>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
 <54608607.2050400@well-typed.com>
 <CAGK9nuozvmRGOm5h3mvo4u_6JuSsunAZpU35V7o-_dx9EofO2w@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3A7722@DB3PRD3001MB020.064d.mgd.msft.net>
 <54663890.4060005@well-typed.com>
 <191C554B-CA66-45AA-B41E-7D56FBDD6E84@seidel.io>
 <CAEs96n1WqU0MzdC=xO7fENmGgzzooy9yNa3fXmatT7B+_sga7w@mail.gmail.com>
 <1416239647.3721140.191986293.5D78BBF2@webmail.messagingengine.com>
Message-ID: <CAEs96n0k8_MMkALy7-SyuUURsosm9RQPAaaP5pGSWNLHShN5Gg@mail.gmail.com>

Yes, that would be ideal, and it can built/test it for you.

This is all enough for one patch I imagine, which should be pretty
easy to rebase locally, then submit with `arc diff`.

On Mon, Nov 17, 2014 at 9:54 AM, Eric Seidel <eric at seidel.io> wrote:
> Would it easier to send the diff to Phab? I don't think the git history
> will be particularly illuminating.
>
> On Mon, Nov 17, 2014, at 07:45, Austin Seipp wrote:
>> This looks excellent! Thank you Adam and Eric for helping Iavor with
>> this.
>>
>> But I'm slightly confused by the git history since it seems to be
>> cluttered with a few merges, and it seems like Eric has pushed the
>> latest changes to all this. The branch is also a little bit behind
>> master too.
>>
>> Iavor, would you like to:
>>
>>   1) Incorporate all of the changes from Eric and Adam,
>>   2) Rebase your work on HEAD so we can read it in a digestible way?
>>
>> I still need to read over all the changes since my first review, since
>> Adam addressed them. The 7.10 branch is at the end of this week, but
>> this would be a really cool feature to have.
>>
>> Thanks!
>>
>> The branch for 7.10 is now the end of this week! It would be nice to get
>> this in
>>
>> On Sun, Nov 16, 2014 at 1:33 PM, Eric Seidel <eric at seidel.io> wrote:
>> > Hi Adam,
>> >
>> > I've made a few changes based on your branch. Specifically I've removed
>> > the call to runTcPlugins inside solveFlats, and have replaced it with
>> > a specific runTcPluginsGiven that runs in a loop inside solveFlatsGiven
>> > much like your runTcPluginsFinal runs inside solveFlatsWanted. I think
>> > this is a bit cleaner given that you've split the wanteds-solving out
>> > already.
>> >
>> > The changes are at https://github.com/gridaphobe/ghc/tree/wip/tc-plugins-els
>> > since I don't have commit access to GHC :)
>> >
>> > Iavor and I also have a question about your change to the last statement
>> > in solveFlatWanteds. You're putting the unsolved wanteds in a field
>> > called wc_flat, which suggests that they ought to be flattened. But
>> > the unsolved wanteds were just unflattened a few lines above! Is this
>> > a problem, or is the wc_flat field in need of a new name? :)
>> >
>> > Eric
>> >
>> >
>> >> On Nov 14, 2014, at 09:14, Adam Gundry <adam at well-typed.com> wrote:
>> >>
>> >> Thanks, Simon! I've been convinced that TcS is more than we need, and I
>> >> think the right thing to do is to (optionally) invoke the plugin after
>> >> the constraints have been unflattened anyway. I've just pushed a commit
>> >> to wip/tc-plugins-amg that does this. Iavor, Eric, your views on how
>> >> convenient this alternative is would be most welcome. I'm also wondering
>> >> if the plugin should be told how many times it has been called, to make
>> >> it easier to prevent infinite loops.
>> >>
>> >> I'm very keen to get this into 7.10, appropriately branded as a very
>> >> experimental feature. Austin, have I sufficiently addressed your
>> >> concerns about the hs-boot file and multiple flags? Is there anything
>> >> else we need, apart perhaps from tests and documentation, which I'll put
>> >> together next week?
>> >>
>> >> Thanks,
>> >>
>> >> Adam
>> >>
>> >>
>> >> On 12/11/14 11:16, Simon Peyton Jones wrote:
>> >>> Iavor, Adam, Eric
>> >>>
>> >>>
>> >>>
>> >>> I?m happy with the general direction of the plugins stuff, so I?m mostly
>> >>> going to leave it to you guys to plough ahead; but I am happy to respond
>> >>> to questions.
>> >>>
>> >>>
>> >>>
>> >>> * I still think it would be better to provide an escape hatch to the
>> >>> TcS, not merely the TcM, alongside the nice TcPluginM wrapper. Notably,
>> >>> Simon's new TcFlatten.unflatten needs TcS...
>> >>>
>> >>>
>> >>>
>> >>> It think the only reason for this is that ?unflatten? needs to set
>> >>> evidence bindings, which in turn requires access to tcs_ev_binds.  I
>> >>> think that everything else is in TcM.  So I suppose you could carry
>> >>> around the EvBindsVar if you really didn?t want TcS.  (And I can see why
>> >>> you wouldn?t; TcS has a lot of stuff you don?t need.)
>> >>>
>> >>>
>> >>>
>> >>> Simon
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> *From:*Iavor Diatchki [mailto:iavor.diatchki at gmail.com]
>> >>> *Sent:* 10 November 2014 19:15
>> >>> *To:* Adam Gundry
>> >>> *Cc:* ghc-devs at haskell.org; Simon Peyton Jones
>> >>> *Subject:* Re: Typechecker plugins: request for review and another
>> >>> workflow question
>> >>>
>> >>>
>> >>>
>> >>> Hi,
>> >>>
>> >>>
>> >>>
>> >>> On Mon, Nov 10, 2014 at 1:31 AM, Adam Gundry <adam at well-typed.com
>> >>> <mailto:adam at well-typed.com>> wrote:
>> >>>
>> >>>
>> >>>    On the subject of that "nearly", I'm interested to learn whether you
>> >>>    have a suggestion to deal with unflattening, because the interface still
>> >>>    works with flat constraints only. Simon's changes should make it more
>> >>>    practical to unflatten inside the plugin, but it would be far easier (at
>> >>>    least for my purposes) if it was simply given unflattened constraints. I
>> >>>    realise that this would require the plugin loop to be pushed further
>> >>>    out, however, which has other difficulties.
>> >>>
>> >>>
>> >>>
>> >>> Not sure what to do about this.  With the current setup, I think either
>> >>> way, the plugin would have to do some extract work.   Perhaps we should
>> >>> run the plugins on the unflattened constraints, and leave to the plugins
>> >>> to manually temporarily "flatten" terms from external theories?  For
>> >>> example, if the type-nat plugin saw `2 * F a ~ 4`, it could temporarily
>> >>> work with `2 * x ~ 4`, and then when it figures out that `x ~ 2`, it
>> >>> could emit `F a ~ 2` (non-canonical), which would go around again, and
>> >>> hopefully get fully simplified.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>    A few other issues, of lesser importance:
>> >>>
>> >>>     * I still think it would be better to provide an escape hatch to the
>> >>>    TcS, not merely the TcM, alongside the nice TcPluginM wrapper. Notably,
>> >>>    Simon's new TcFlatten.unflatten needs TcS...
>> >>>
>> >>> I don't mind that but, if I recall correctly, to do this without more
>> >>> recursive modules, we had to split `TCSMonad` in two parts, one with the
>> >>> types, and one with other stuff.  Eric and I did this once, but we
>> >>> didn't commit it, because it seemed like an orthogonal change.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>     * Is there a way for my plugin to "solve" a given constraint (e.g. to
>> >>>    discard the uninformative "a * 1 ~ a")?
>> >>>
>> >>> Yes, you'd say something like: `TcPluginOK [(evidence, "a * 1 ~ a")] []`
>> >>>
>> >>>
>> >>>
>> >>> The first field of `TcPluginOK` are things that are solved, the second
>> >>> one is new work.
>> >>>
>> >>>
>> >>>
>> >>>     * It is unfortunately easy to create infinite loops by writing plugins
>> >>>    that emit wanteds but make no useful progress. Perhaps there should be a
>> >>>    limit on the number of times round the loop (like SubGoalDepth but for
>> >>>    all constraints)?
>> >>>
>> >>>
>> >>>
>> >>> Indeed, if a plugin keeps generating new work, we could go in a loop, so
>> >>> maybe a limit of some sort is useful.  However, note that if the plugin
>> >>> generates things that are already in the inert set, GHC should notice
>> >>> this and filter them, so we won't keep going.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>     * Perhaps runTcPlugin should skip invoking the plugin if there are no
>> >>>    wanteds?
>> >>>
>> >>>
>> >>>
>> >>> Oh, there is an important detail here that needs documentation!   GHC
>> >>> will call the plugin twice: once to improve the givens, and once to
>> >>> solve the wanteds.   The way to distinguish the two is exactly by the
>> >>> presence of the wanteds.
>> >>>
>> >>>
>> >>>
>> >>> Why might you want to improve the givens?  Suppose you had something
>> >>> like `x * 2 ~ 4` as a given:  then you'd really want the plugin to
>> >>> generate another given: `x ~ 2`, as this is likely to help the rest of
>> >>> the constraint solving process.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>     * The use of ctev_evar in runTcPlugin is partial, and fails with a
>> >>>    nasty error if the plugin returns a non-wanted in the solved constraints
>> >>>    list. Would it be worth catching this error and issuing a sensible
>> >>>    message that chastises the plugin author appropriately?
>> >>>
>> >>>
>> >>>
>> >>> Aha, good idea. Bad plugin! :-)
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>     * Finally, I presume the comment on runTcPlugin that "The plugin is
>> >>>    provided only with CTyEq and CFunEq constraints" is simply outdated and
>> >>>    should be removed?
>> >>>
>> >>> Yep, thanks!
>> >>>
>> >>>
>> >>>
>> >>>    Apologies for the deluge of questions - please take them as evidence of
>> >>>    my eagerness to use this feature!
>> >>>
>> >>>
>> >>>
>> >>> Thanks for your feedback!  Also, if you feel like doing some hacking
>> >>> please do so---I am quite busy at the moment so I don't  have a ton of
>> >>> time to work on it, so any help you be most appreciated.  I know Eric is
>> >>> also quite keen on helping out so we can just coordinate over e-mail.
>> >>>
>> >>>
>> >>>
>> >>> -Iavor
>> >>
>> >>
>> >> --
>> >> Adam Gundry, Haskell Consultant
>> >> Well-Typed LLP, http://www.well-typed.com/
>> >
>>
>>
>>
>> --
>> Regards,
>>
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From adam at well-typed.com  Mon Nov 17 16:36:31 2014
From: adam at well-typed.com (Adam Gundry)
Date: Mon, 17 Nov 2014 16:36:31 +0000
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <191C554B-CA66-45AA-B41E-7D56FBDD6E84@seidel.io>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
 <54608607.2050400@well-typed.com>
 <CAGK9nuozvmRGOm5h3mvo4u_6JuSsunAZpU35V7o-_dx9EofO2w@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3A7722@DB3PRD3001MB020.064d.mgd.msft.net>
 <54663890.4060005@well-typed.com>
 <191C554B-CA66-45AA-B41E-7D56FBDD6E84@seidel.io>
Message-ID: <546A240F.4020602@well-typed.com>

Thanks Eric!


On 16/11/14 19:33, Eric Seidel wrote:
> I've made a few changes based on your branch. Specifically I've
> removed the call to runTcPlugins inside solveFlats, and have replaced
> it with a specific runTcPluginsGiven that runs in a loop inside
> solveFlatsGiven much like your runTcPluginsFinal runs inside
> solveFlatsWanted. I think this is a bit cleaner given that you've
> split the wanteds-solving out already.
>
> The changes are at
https://github.com/gridaphobe/ghc/tree/wip/tc-plugins-els
> since I don't have commit access to GHC

I agree that it's better to split these out separately, if you and Iavor
are happy to work with only the unflattened constraints. I'm not
completely convinced by how solveFlatGivens/runTcPluginsGiven work now
though. It seems slightly odd that solveFlatGivens calls solveFlats and
runTcPluginsGiven with the same set of givens, even though solveFlats
might have simplified/discarded some.

Also, if I understand correctly, when a plugin generates new facts,
those will be added to the worklist directly, but also passed back in
the result Cts to be added to the worklist again. In the
solveFlatWanteds case, new facts are added to the worklist but not the
result Cts, which is fine.

Finally, I think the plugin should be allowed to "solve" given
constraints, just by discarding them (e.g. if the constraint is
something like "1 * x ~ x"). It's slightly odd that the interface
requires the plugin to provide an evidence term in this case, but the
evidence associated with the CtGiven (ctev_evtm) will do.

I'll put some commits together shortly to address these fine details.


> Iavor and I also have a question about your change to the last
> statement in solveFlatWanteds. You're putting the unsolved wanteds in
> a field called wc_flat, which suggests that they ought to be
> flattened. But the unsolved wanteds were just unflattened a few lines
> above! Is this a problem, or is the wc_flat field in need of a new
> name? :)

This is a slightly unfortunate clash of terminology. I believe wc_flat
is so named because the constraints are flat in the sense of "not
implications" rather than "contain no type family applications". This is
also the reason for the name "solveFlats".

Adam


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From eric at seidel.io  Mon Nov 17 17:11:27 2014
From: eric at seidel.io (Eric Seidel)
Date: Mon, 17 Nov 2014 09:11:27 -0800
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <546A240F.4020602@well-typed.com>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
 <54608607.2050400@well-typed.com>
 <CAGK9nuozvmRGOm5h3mvo4u_6JuSsunAZpU35V7o-_dx9EofO2w@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3A7722@DB3PRD3001MB020.064d.mgd.msft.net>
 <54663890.4060005@well-typed.com>
 <191C554B-CA66-45AA-B41E-7D56FBDD6E84@seidel.io>
 <546A240F.4020602@well-typed.com>
Message-ID: <1416244287.3868739.192018553.64B788AC@webmail.messagingengine.com>

Ah, good catch on both accounts, thanks!

Re "solving" givens: although the interface requires the plugins to
provide an evidence term, the end result would be that the given is
discarded entirely, correct? If so, we should probably caution plugin
authors not to solve any givens they can't easily re-derive later, but
perhaps this is obvious.. Apart from that concern, it seems reasonable,
and could potentially reduce the amount of work GHC has to do. 

Ping me if you want to offload any work, I'm also very keen to get this
landed before the 7.10 branch!

On Mon, Nov 17, 2014, at 08:36, Adam Gundry wrote:
> Thanks Eric!
> 
> 
> On 16/11/14 19:33, Eric Seidel wrote:
> > I've made a few changes based on your branch. Specifically I've
> > removed the call to runTcPlugins inside solveFlats, and have replaced
> > it with a specific runTcPluginsGiven that runs in a loop inside
> > solveFlatsGiven much like your runTcPluginsFinal runs inside
> > solveFlatsWanted. I think this is a bit cleaner given that you've
> > split the wanteds-solving out already.
> >
> > The changes are at
> https://github.com/gridaphobe/ghc/tree/wip/tc-plugins-els
> > since I don't have commit access to GHC
> 
> I agree that it's better to split these out separately, if you and Iavor
> are happy to work with only the unflattened constraints. I'm not
> completely convinced by how solveFlatGivens/runTcPluginsGiven work now
> though. It seems slightly odd that solveFlatGivens calls solveFlats and
> runTcPluginsGiven with the same set of givens, even though solveFlats
> might have simplified/discarded some.
> 
> Also, if I understand correctly, when a plugin generates new facts,
> those will be added to the worklist directly, but also passed back in
> the result Cts to be added to the worklist again. In the
> solveFlatWanteds case, new facts are added to the worklist but not the
> result Cts, which is fine.
> 
> Finally, I think the plugin should be allowed to "solve" given
> constraints, just by discarding them (e.g. if the constraint is
> something like "1 * x ~ x"). It's slightly odd that the interface
> requires the plugin to provide an evidence term in this case, but the
> evidence associated with the CtGiven (ctev_evtm) will do.
> 
> I'll put some commits together shortly to address these fine details.
> 
> 
> > Iavor and I also have a question about your change to the last
> > statement in solveFlatWanteds. You're putting the unsolved wanteds in
> > a field called wc_flat, which suggests that they ought to be
> > flattened. But the unsolved wanteds were just unflattened a few lines
> > above! Is this a problem, or is the wc_flat field in need of a new
> > name? :)
> 
> This is a slightly unfortunate clash of terminology. I believe wc_flat
> is so named because the constraints are flat in the sense of "not
> implications" rather than "contain no type family applications". This is
> also the reason for the name "solveFlats".
> 
> Adam
> 
> 
> -- 
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/

From adam at well-typed.com  Mon Nov 17 17:58:19 2014
From: adam at well-typed.com (Adam Gundry)
Date: Mon, 17 Nov 2014 17:58:19 +0000
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <1416244287.3868739.192018553.64B788AC@webmail.messagingengine.com>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>
 <54608607.2050400@well-typed.com>
 <CAGK9nuozvmRGOm5h3mvo4u_6JuSsunAZpU35V7o-_dx9EofO2w@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3A7722@DB3PRD3001MB020.064d.mgd.msft.net>
 <54663890.4060005@well-typed.com>
 <191C554B-CA66-45AA-B41E-7D56FBDD6E84@seidel.io>
 <546A240F.4020602@well-typed.com>
 <1416244287.3868739.192018553.64B788AC@webmail.messagingengine.com>
Message-ID: <546A373B.1010609@well-typed.com>

I think we're converging on a reasonable story about the way to call
plugins for givens and for wanteds; it's a shame they don't quite match
up, but I think that is probably unavoidable and relatively harmless.

On 17/11/14 17:11, Eric Seidel wrote:
> Ah, good catch on both accounts, thanks!
> 
> Re "solving" givens: although the interface requires the plugins to
> provide an evidence term, the end result would be that the given is
> discarded entirely, correct? If so, we should probably caution plugin
> authors not to solve any givens they can't easily re-derive later, but
> perhaps this is obvious.. Apart from that concern, it seems reasonable,
> and could potentially reduce the amount of work GHC has to do. 

Yes, that's right, it makes sense to discard a given only if it can be
re-derived (and hence is providing no new information). This happens in
the vanilla constraint solver, for example reflexive given equations are
discarded. When reporting errors, it's nice to omit obviously boring
constraints!

> Ping me if you want to offload any work, I'm also very keen to get this
> landed before the 7.10 branch!

I'd be very grateful if you could try out my latest commit to
wip/tc-plugins-amg and tell me if it makes sense or if I'm doing
something silly. The code could do with a bit of tidying up, including
cleaning up the diff to master, which I'll try to get done tomorrow,
unless you want to jump in first. ;-)

Cheers,

Adam


> On Mon, Nov 17, 2014, at 08:36, Adam Gundry wrote:
>> Thanks Eric!
>>
>>
>> On 16/11/14 19:33, Eric Seidel wrote:
>>> I've made a few changes based on your branch. Specifically I've
>>> removed the call to runTcPlugins inside solveFlats, and have replaced
>>> it with a specific runTcPluginsGiven that runs in a loop inside
>>> solveFlatsGiven much like your runTcPluginsFinal runs inside
>>> solveFlatsWanted. I think this is a bit cleaner given that you've
>>> split the wanteds-solving out already.
>>>
>>> The changes are at
>> https://github.com/gridaphobe/ghc/tree/wip/tc-plugins-els
>>> since I don't have commit access to GHC
>>
>> I agree that it's better to split these out separately, if you and Iavor
>> are happy to work with only the unflattened constraints. I'm not
>> completely convinced by how solveFlatGivens/runTcPluginsGiven work now
>> though. It seems slightly odd that solveFlatGivens calls solveFlats and
>> runTcPluginsGiven with the same set of givens, even though solveFlats
>> might have simplified/discarded some.
>>
>> Also, if I understand correctly, when a plugin generates new facts,
>> those will be added to the worklist directly, but also passed back in
>> the result Cts to be added to the worklist again. In the
>> solveFlatWanteds case, new facts are added to the worklist but not the
>> result Cts, which is fine.
>>
>> Finally, I think the plugin should be allowed to "solve" given
>> constraints, just by discarding them (e.g. if the constraint is
>> something like "1 * x ~ x"). It's slightly odd that the interface
>> requires the plugin to provide an evidence term in this case, but the
>> evidence associated with the CtGiven (ctev_evtm) will do.
>>
>> I'll put some commits together shortly to address these fine details.
>>
>>
>>> Iavor and I also have a question about your change to the last
>>> statement in solveFlatWanteds. You're putting the unsolved wanteds in
>>> a field called wc_flat, which suggests that they ought to be
>>> flattened. But the unsolved wanteds were just unflattened a few lines
>>> above! Is this a problem, or is the wc_flat field in need of a new
>>> name? :)
>>
>> This is a slightly unfortunate clash of terminology. I believe wc_flat
>> is so named because the constraints are flat in the sense of "not
>> implications" rather than "contain no type family applications". This is
>> also the reason for the name "solveFlats".
>>
>> Adam


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From facundo.dominguez at tweag.io  Tue Nov 18 00:43:58 2014
From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=)
Date: Mon, 17 Nov 2014 22:43:58 -0200
Subject: Fwd: Garbage collection
In-Reply-To: <CA+Q==SCJpCB-7DsBfj8Ey071yV80JJubsmfTAEHWU4703hJRyw@mail.gmail.com>
References: <CA+Q==SCJpCB-7DsBfj8Ey071yV80JJubsmfTAEHWU4703hJRyw@mail.gmail.com>
Message-ID: <CA+Q==SBUUManYctGBpEjUNxJ2Bk3PvtaEDKK5mLLDZsV6FhCQg@mail.gmail.com>

Hello,
   While working in the StaticPointers language extension [1], we
found we have some unusual CAFs which can be accessed after some
periods of time where there is no reference to them.

   For instance, the following program when compiled contains no
reference to `g`. `g` is actually looked up at runtime in symbol
tables via the call to `deRefStaticPtr`.

g :: String
g = "hello"

main =
  deRefStaticPtr (static g) >>= putStrLn

Desugars to:

g :: String
g = "hello"

main =
  deRefStaticPtr (StaticPtr (StaticName "" "Main" "g")) >>= putStrLn

In principle, there is nothing stopping the garbage collector from
reclaiming the closure of `g` before it is dynamically looked up.

We are considering using StablePtrs to preserve `g`. So the code
desugars instead to:

g :: String
g = "hello"

main =
  deRefStaticPtr (let x = StaticPtr (StaticName "" "Main" "g")
                         in unsafePerformIO $ newStablePtr g >> return x
                        ) >>= putStrLn

This solution could be temporal though, until we implement the so
called static pointer table, which would keep the values alive.

Would you have any comments about such a solution or maybe would you
advice some other alternative?

Thanks,
Facundo

[1] https://ghc.haskell.org/trac/ghc/wiki/StaticPointers

From adam at well-typed.com  Tue Nov 18 13:01:30 2014
From: adam at well-typed.com (Adam Gundry)
Date: Tue, 18 Nov 2014 13:01:30 +0000
Subject: Typechecker plugins: request for review and another workflow
 question
In-Reply-To: <CAEs96n1WqU0MzdC=xO7fENmGgzzooy9yNa3fXmatT7B+_sga7w@mail.gmail.com>
References: <CAGK9nurornY6DiBYn-ymCRWPLyda_P-iTN=g8jc7OfgRhVMY+w@mail.gmail.com>	<54608607.2050400@well-typed.com>	<CAGK9nuozvmRGOm5h3mvo4u_6JuSsunAZpU35V7o-_dx9EofO2w@mail.gmail.com>	<618BE556AADD624C9C918AA5D5911BEF3F3A7722@DB3PRD3001MB020.064d.mgd.msft.net>	<54663890.4060005@well-typed.com>	<191C554B-CA66-45AA-B41E-7D56FBDD6E84@seidel.io>
 <CAEs96n1WqU0MzdC=xO7fENmGgzzooy9yNa3fXmatT7B+_sga7w@mail.gmail.com>
Message-ID: <546B432A.1050302@well-typed.com>

I hope Iavor will forgive me for stealing his thunder, but given the
looming 7.10 branch I thought I'd pick this up.  I've created a Phab
revision (https://phabricator.haskell.org/D489) with the latest
typechecker plugins implementation, and updated the wiki page
(https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker).

Adam


On 17/11/14 15:45, Austin Seipp wrote:
> This looks excellent! Thank you Adam and Eric for helping Iavor with this.
> 
> But I'm slightly confused by the git history since it seems to be
> cluttered with a few merges, and it seems like Eric has pushed the
> latest changes to all this. The branch is also a little bit behind
> master too.
> 
> Iavor, would you like to:
> 
>   1) Incorporate all of the changes from Eric and Adam,
>   2) Rebase your work on HEAD so we can read it in a digestible way?
> 
> I still need to read over all the changes since my first review, since
> Adam addressed them. The 7.10 branch is at the end of this week, but
> this would be a really cool feature to have.
> 
> Thanks!
> 
> The branch for 7.10 is now the end of this week! It would be nice to get this in


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From berthold at Mathematik.Uni-Marburg.de  Tue Nov 18 15:20:57 2014
From: berthold at Mathematik.Uni-Marburg.de (Jost Berthold)
Date: Tue, 18 Nov 2014 16:20:57 +0100
Subject: Fwd: Garbage collection
In-Reply-To: <CA+Q==SBUUManYctGBpEjUNxJ2Bk3PvtaEDKK5mLLDZsV6FhCQg@mail.gmail.com>
References: <CA+Q==SBUUManYctGBpEjUNxJ2Bk3PvtaEDKK5mLLDZsV6FhCQg@mail.gmail.com>
Message-ID: <546B63D9.6010600@mathematik.uni-marburg.de>

Hi Facundo,

You are completely right, the CAF named "g" might be accessed at any 
time during the program execution. Parallel Haskell systems with 
distributed heap (and runtime-supported serialisation) need to keep all 
CAFS alive for this reason.

Some comments inline along your mail:

>   While working in the StaticPointers language extension [1], we
> found we have some unusual CAFs which can be accessed after some
> periods of time where there is no reference to them.
>
>   For instance, the following program when compiled contains no
> reference to `g`. `g` is actually looked up at runtime in symbol
> tables via the call to `deRefStaticPtr`.
> g :: String
> g = "hello"
>
> main =
>   deRefStaticPtr (static g) >>= putStrLn

The bad scenario is certainly one where CAF g (a static thunk) is 
evaluated during execution (i.e. turned into an indirection into the 
heap), and then garbage-collected, as it might not be referenced by any 
(runnable) thread.
This GC does not revert the indirection into a thunk. Why should it, 
there are no references to it, right? ;-)

So technically, your example might need to involve using g (and forceful 
GC at a certain point during execution):

main = putStrLn g >> performGC >>
        deRefStaticPtr (static g) >>= putStrLn
	
> Desugars to:
>
> g :: String
> g = "hello"
>
> main =
     putStrLn g >> performGC >>
>   deRefStaticPtr (StaticPtr (StaticName "" "Main" "g")) >>= putStrLn

During performGC, there would be no reference to g from any thread's stack.
I am of course assuming that g is indeed a thunk, and not statically 
evaluated to a string during compilation (I am unsure whether GHC would 
do that).

> In principle, there is nothing stopping the garbage collector from
> reclaiming the closure of `g` before it is dynamically looked up.

Maybe a stupid question, sorry: The RemoteTable generated using 
template-haskell in CH without XStaticPointers would keep CAFs alive. So 
the XStaticPointers extension does not entail using such a table?

> We are considering using StablePtrs to preserve `g`. So the code
> desugars instead to:
>
> g :: String
> g = "hello"
>
> main =
>   deRefStaticPtr (let x = StaticPtr (StaticName "" "Main" "g")
>                          in unsafePerformIO $ newStablePtr g >> return x
>                         ) >>= putStrLn
>

Another question: Would it be sufficient to desugar "static g" to
	g `seq` StaticPtr(StaticName "" "Main" "g")
instead of introducing a stable ptr and all that?
AFter all, g is a CAF, so it is anyway "stable" in some sense, as long 
as it is alive.

However, I conjecture that this only fixes the one-node test, not the 
actual use case (sending "static" stuff over the wire).

Finally, there is a flag keepCAFs in the runtime which you can set to 
secure the CAFs for the entire run. The parallel runtimes for Eden and 
GUM (as well as my "packman" serialisation) do this.

Yes, obviously, this opens a memory leak. It would be nice to not "keep" 
but "revert" the CAFs (ghci does that) but on a "by-need" basis when a 
simple GC cannot reclaim enough space; this would plug the mem.leak. 
This requires a modification to the GHC runtime system, and it is 
unclear _which_ CAFs to prefer when starting to revert. But I think it 
would be a more generally useful feature.
However, this discussion (runtime/GC features) leads us straight out of 
the design goals of "-XStaticPointers", I guess...

Best regards,
Jost

From simonpj at microsoft.com  Tue Nov 18 15:59:29 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 18 Nov 2014 15:59:29 +0000
Subject: Garbage collection
In-Reply-To: <CA+Q==SBUUManYctGBpEjUNxJ2Bk3PvtaEDKK5mLLDZsV6FhCQg@mail.gmail.com>
References: <CA+Q==SCJpCB-7DsBfj8Ey071yV80JJubsmfTAEHWU4703hJRyw@mail.gmail.com>
 <CA+Q==SBUUManYctGBpEjUNxJ2Bk3PvtaEDKK5mLLDZsV6FhCQg@mail.gmail.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3C8C05@DB3PRD3001MB020.064d.mgd.msft.net>

Isn't it this simple: the Static Pointer Table must be a source of roots for the garbage collector.  Of course!  An item in the SPT may be looked up at any time.

Easy.  What am I missing?

I'm deeply suspicious of any solution that involves a call to performGC. That smells wrong.

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Facundo Dom?nguez
|  Sent: 18 November 2014 00:44
|  To: ghc-devs at haskell.org
|  Subject: Fwd: Garbage collection
|  
|  Hello,
|     While working in the StaticPointers language extension [1], we
|  found we have some unusual CAFs which can be accessed after some
|  periods of time where there is no reference to them.
|  
|     For instance, the following program when compiled contains no
|  reference to `g`. `g` is actually looked up at runtime in symbol
|  tables via the call to `deRefStaticPtr`.
|  
|  g :: String
|  g = "hello"
|  
|  main =
|    deRefStaticPtr (static g) >>= putStrLn
|  
|  Desugars to:
|  
|  g :: String
|  g = "hello"
|  
|  main =
|    deRefStaticPtr (StaticPtr (StaticName "" "Main" "g")) >>= putStrLn
|  
|  In principle, there is nothing stopping the garbage collector from
|  reclaiming the closure of `g` before it is dynamically looked up.
|  
|  We are considering using StablePtrs to preserve `g`. So the code
|  desugars instead to:
|  
|  g :: String
|  g = "hello"
|  
|  main =
|    deRefStaticPtr (let x = StaticPtr (StaticName "" "Main" "g")
|                           in unsafePerformIO $ newStablePtr g >> return
|  x
|                          ) >>= putStrLn
|  
|  This solution could be temporal though, until we implement the so
|  called static pointer table, which would keep the values alive.
|  
|  Would you have any comments about such a solution or maybe would you
|  advice some other alternative?
|  
|  Thanks,
|  Facundo
|  
|  [1] https://ghc.haskell.org/trac/ghc/wiki/StaticPointers
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  http://www.haskell.org/mailman/listinfo/ghc-devs

From austin at well-typed.com  Tue Nov 18 16:07:43 2014
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 18 Nov 2014 10:07:43 -0600
Subject: The future of the Haskell98 and Haskell2010 packages
Message-ID: <CAEs96n0gfc8UUsgakA2E+DXSzwgrNXWWAOjX5f9mu8iRpFo1tg@mail.gmail.com>

Hello all,

A few weeks ago, I opened up a discussion about a particular GHC bug, #9590.

This bug is concerned with the future of the Haskell98 and Haskell2010
packages, which try to embody their two respective Haskell standards.
They do this by shipping the 'exact library specification' that the
standards have.

In our discussion this past week between me, SimonM, SPJ, Herbert and
Mikolaj, we came to this discussion again since the 7.10 STABLE freeze
is almost here, and it seems to have puttered out.

In this discussion, we came to the conclusion we think these packages
should be removed from GHC for the 7.10 release. To be clear, this was
not a 100% unanimous decision or formal vote; SimonM and I supported
removal, while everyone else seemed to be rather undecided or
ambivalent.

Most of the proposed alternative solutions seemed somewhat one-off.
Furthermore, we didn't find a solution that wouldn't either A) require
some amount of GHC modifications (possibly indefinitely into the
future) to support these packages, or B) changing the definitions in
these packages to deviate from the standard.

Instead, we proposed that we instead overhaul part of the GHC users
manual, and clearly outline our deviations from the Haskell 2010
standard library.

To be clear: GHC can still typecheck, compile, and efficiently execute
Haskell 2010 code. It is merely the distribution of compatible
packages that has put us in something of a bind.

Furthermore, we aren't aware of any other compilers/platforms like
ours that try to maintain such stringent separation of these packages,
and furthermore, both of the haskell{98,2010} packages have a fairly
small number of reverse dependencies.

I'd like to hear what people think about this. It seems likely I will
move forward on this by the end of the week unless we face very strong
opposition to this idea, or someone is willing to fix #9590 somehow
for us.

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From eir at cis.upenn.edu  Tue Nov 18 16:44:55 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 18 Nov 2014 11:44:55 -0500
Subject: The future of the Haskell98 and Haskell2010 packages
In-Reply-To: <CAEs96n0gfc8UUsgakA2E+DXSzwgrNXWWAOjX5f9mu8iRpFo1tg@mail.gmail.com>
References: <CAEs96n0gfc8UUsgakA2E+DXSzwgrNXWWAOjX5f9mu8iRpFo1tg@mail.gmail.com>
Message-ID: <09109797-E902-4723-BB8C-A73DDA4F1D7F@cis.upenn.edu>

I support this direction. But I disagree with one statement you've made:

On Nov 18, 2014, at 11:07 AM, Austin Seipp <austin at well-typed.com> wrote:
> To be clear: GHC can still typecheck, compile, and efficiently execute
> Haskell 2010 code. It is merely the distribution of compatible
> packages that has put us in something of a bind.

GHC 7.10 will not be able to compile a Haskell2010-compliant Monad instance. In fact, as far as I can see, there is no way to write a Monad instance that is both portable to other Haskell compilers and acceptable to GHC 7.10. I think this point should be included in the manual (if I'm right).

This makes me a little sad, but I don't disagree with any of the decisions we've made along the way.

Richard

From austin at well-typed.com  Tue Nov 18 16:57:59 2014
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 18 Nov 2014 10:57:59 -0600
Subject: The future of the Haskell98 and Haskell2010 packages
In-Reply-To: <09109797-E902-4723-BB8C-A73DDA4F1D7F@cis.upenn.edu>
References: <CAEs96n0gfc8UUsgakA2E+DXSzwgrNXWWAOjX5f9mu8iRpFo1tg@mail.gmail.com>
 <09109797-E902-4723-BB8C-A73DDA4F1D7F@cis.upenn.edu>
Message-ID: <CAEs96n3pF9=xjD0REkM2dyRaPft-i3DJvxGhmgKEOZLaS3CEZA@mail.gmail.com>

You're right, and something like that would be included. (I actually
meant GHC can still literally accept perfectly valid Haskell2010 code
in a syntactical sense; instances are part what I was referring to as
'compatible packages')

Actually, this reminds me of something SimonPJ mentioned yesterday
during this call, which may be able to fix this one bug, at least:

We could have -XHaskell2010 (or whatever it is) imply a subset of
RebindableSyntax, which only takes place for 'do' syntax. Then we
would also have the compiler import the haskell{98,2010} package as it
does today, with its own Monad (which does not have an Applicative
superclass constraint) and things would work.

This probably would not be a lot of work, but my main reservation I
suppose is that I don't think it's a very 'scalable' fix with the way
we seem to be going. If any other kind of similar change ever happened
again, we'd be stuck here once more since the same quick fix won't
apply. But if someone did the work for this, I'm not sure I would say
"no" to it.

Relatedly, I also wonder how long we should hold on to old standards.
It has been four years since a prior revision of the standard, and
almost 16 since Haskell 98. If Haskell 2015 happens soon, will we want
to have three standards packages for 7.12 if we don't remove them now?

On Tue, Nov 18, 2014 at 10:44 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> I support this direction. But I disagree with one statement you've made:
>
> On Nov 18, 2014, at 11:07 AM, Austin Seipp <austin at well-typed.com> wrote:
>> To be clear: GHC can still typecheck, compile, and efficiently execute
>> Haskell 2010 code. It is merely the distribution of compatible
>> packages that has put us in something of a bind.
>
> GHC 7.10 will not be able to compile a Haskell2010-compliant Monad instance. In fact, as far as I can see, there is no way to write a Monad instance that is both portable to other Haskell compilers and acceptable to GHC 7.10. I think this point should be included in the manual (if I'm right).
>
> This makes me a little sad, but I don't disagree with any of the decisions we've made along the way.
>
> Richard



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From david.feuer at gmail.com  Tue Nov 18 17:02:08 2014
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 18 Nov 2014 12:02:08 -0500
Subject: The future of the Haskell98 and Haskell2010 packages
In-Reply-To: <09109797-E902-4723-BB8C-A73DDA4F1D7F@cis.upenn.edu>
References: <CAEs96n0gfc8UUsgakA2E+DXSzwgrNXWWAOjX5f9mu8iRpFo1tg@mail.gmail.com>
 <09109797-E902-4723-BB8C-A73DDA4F1D7F@cis.upenn.edu>
Message-ID: <CAMgWh9vZzf9XumdQw1DKR0S8pmhuH3GtY_=LsH4H=umok2C4Vw@mail.gmail.com>

I think you're right, and that's a strong reason to come up with an update
to the Haskell Report. Include in it, at least:

-- Big-ticket items
0. Monoid
1. Foldable, Traversable
2. Applicative
3. Applicative => Monad
-- side notes
4. inits = map reverse . scanl (flip (:)) []  -- efficiency?not optimal but
not hilariously bad
5. unwords = intercalate " "  -- increased, more intuitive laziness

On Tue, Nov 18, 2014 at 11:44 AM, Richard Eisenberg <eir at cis.upenn.edu>
wrote:

> I support this direction. But I disagree with one statement you've made:
>
> On Nov 18, 2014, at 11:07 AM, Austin Seipp <austin at well-typed.com> wrote:
> > To be clear: GHC can still typecheck, compile, and efficiently execute
> > Haskell 2010 code. It is merely the distribution of compatible
> > packages that has put us in something of a bind.
>
> GHC 7.10 will not be able to compile a Haskell2010-compliant Monad
> instance. In fact, as far as I can see, there is no way to write a Monad
> instance that is both portable to other Haskell compilers and acceptable to
> GHC 7.10. I think this point should be included in the manual (if I'm
> right).
>
> This makes me a little sad, but I don't disagree with any of the decisions
> we've made along the way.
>
> Richard
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141118/8b932272/attachment.html>

From simonpj at microsoft.com  Tue Nov 18 17:06:39 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 18 Nov 2014 17:06:39 +0000
Subject: Windows breakage agein
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3C9CCA@DB3PRD3001MB020.064d.mgd.msft.net>

On Windows (sigh).  Seems to be due to Simon Marlow's 2a6f193b

rts\Schedule.c: In function 'suspendThread':



rts\Schedule.c:2239:3:

     error: expected ';' before 'EnterCriticalSection'

rts/ghc.mk:236: recipe for target 'rts/dist/build/Schedule.thr_o' failed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141118/4ed0a4af/attachment-0001.html>

From singpolyma at singpolyma.net  Tue Nov 18 17:10:07 2014
From: singpolyma at singpolyma.net (Stephen Paul Weber)
Date: Tue, 18 Nov 2014 12:10:07 -0500
Subject: The future of the Haskell98 and Haskell2010 packages
In-Reply-To: <CAEs96n3pF9=xjD0REkM2dyRaPft-i3DJvxGhmgKEOZLaS3CEZA@mail.gmail.com>
References: <CAEs96n0gfc8UUsgakA2E+DXSzwgrNXWWAOjX5f9mu8iRpFo1tg@mail.gmail.com>
 <09109797-E902-4723-BB8C-A73DDA4F1D7F@cis.upenn.edu>
 <CAEs96n3pF9=xjD0REkM2dyRaPft-i3DJvxGhmgKEOZLaS3CEZA@mail.gmail.com>
Message-ID: <20141118171007.GF2811@singpolyma-liberty>

>RebindableSyntax

I thought this would work, but people seemed pretty sure we would need to do 
more work than RebindableSyntax to get everything in place.

-- 
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141118/fa0a8f54/attachment.sig>

From mboes at tweag.net  Tue Nov 18 18:03:19 2014
From: mboes at tweag.net (Mathieu Boespflug)
Date: Tue, 18 Nov 2014 19:03:19 +0100
Subject: Garbage collection
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3C8C05@DB3PRD3001MB020.064d.mgd.msft.net>
References: <CA+Q==SCJpCB-7DsBfj8Ey071yV80JJubsmfTAEHWU4703hJRyw@mail.gmail.com>
 <CA+Q==SBUUManYctGBpEjUNxJ2Bk3PvtaEDKK5mLLDZsV6FhCQg@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3C8C05@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CAC0Lnfv3fsrkwNhytQnOjHEt+t_Y_r9125-cyWh3vNAOzQZ_MA@mail.gmail.com>

On 18 November 2014 16:59, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> Isn't it this simple: the Static Pointer Table must be a source of roots for the garbage collector.  Of course!  An item in the SPT may be looked up at any time.

As Facundo says, the existence of the SPT would solve everything. But
we haven't quite figured out how to create a simple SPT yet, so were
wondering whether there is an existing generic mechanism to register
new GC roots.

I guess there is no better solution but to just create an SPT, even if
we don't yet have TypeRep's to put in it.

With an SPT, and under the assumption of everyone sharing the same
binary in the distributed system, there will be no need to hold on to
*all* CAF's - just the ones that are known to have a StaticPointer
created for them at compile time.

From austin at well-typed.com  Tue Nov 18 19:31:01 2014
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 18 Nov 2014 13:31:01 -0600
Subject: NOTE: the primary webserver is going down for immediate maintenance.
Message-ID: <CAEs96n0zvExnfWC0GCNdkcjjfo6N8yac7bYpkE3ip3iEWGrodg@mail.gmail.com>

Hello *,

The primary haskell.org domain, www.haskell.org, is hosted on a system
which seems to have lost one of its RAID disks completely.

We were planning on moving this machine in the next few weeks to new
infrastructure, but we are now expediting this plan and will be doing
it ASAP.

As we move this server, both the webserver and the mailing system will
be going down. Please don't be alarmed if your emails aren't delivered
or things go quiet. Many services will continue to work, but we do
realize this will be upsetting for many.

You can follow the progress on #haskell-infrastructure on Freenode,
and see updates on https://status.haskell.org

If you need to download something like a GHC binary or Haskell
Platform package, you can use https://downloads.haskell.org in the
mean time, which is a new service we were hoping to announce more
officially soon, but is already working today.

Unfortunately we cannot give an expected time of completion for the
move, but we'll try to keep people well informed through IRC or
something like Reddit.

Thanks

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From davean at xkcd.com  Wed Nov 19 05:47:25 2014
From: davean at xkcd.com (davean)
Date: Wed, 19 Nov 2014 00:47:25 -0500
Subject: NOTE: the primary webserver is going down for immediate
 maintenance.
In-Reply-To: <CAEs96n0zvExnfWC0GCNdkcjjfo6N8yac7bYpkE3ip3iEWGrodg@mail.gmail.com>
References: <CAEs96n0zvExnfWC0GCNdkcjjfo6N8yac7bYpkE3ip3iEWGrodg@mail.gmail.com>
Message-ID: <CABFs2VjmL83+daMEFNGKGwnjtCvzs+PrpnstYBreXhwvODkTyA@mail.gmail.com>

At this time services are starting to come back.

The site is very slow due to a temporary patch while we improve the
connection to the database server.
Please report issues other then slowness to the #haskell-infrastructure on
Freenode.

Apologies for the interruption you were forced to experience.

On Tue, Nov 18, 2014 at 2:31 PM, Austin Seipp <austin at well-typed.com> wrote:

> Hello *,
>
> The primary haskell.org domain, www.haskell.org, is hosted on a system
> which seems to have lost one of its RAID disks completely.
>
> We were planning on moving this machine in the next few weeks to new
> infrastructure, but we are now expediting this plan and will be doing
> it ASAP.
>
> As we move this server, both the webserver and the mailing system will
> be going down. Please don't be alarmed if your emails aren't delivered
> or things go quiet. Many services will continue to work, but we do
> realize this will be upsetting for many.
>
> You can follow the progress on #haskell-infrastructure on Freenode,
> and see updates on https://status.haskell.org
>
> If you need to download something like a GHC binary or Haskell
> Platform package, you can use https://downloads.haskell.org in the
> mean time, which is a new service we were hoping to announce more
> officially soon, but is already working today.
>
> Unfortunately we cannot give an expected time of completion for the
> move, but we'll try to keep people well informed through IRC or
> something like Reddit.
>
> Thanks
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141119/ed69fc34/attachment.html>

From simonpj at microsoft.com  Wed Nov 19 13:06:42 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 19 Nov 2014 13:06:42 +0000
Subject: Garbage collection
In-Reply-To: <CAC0Lnfv3fsrkwNhytQnOjHEt+t_Y_r9125-cyWh3vNAOzQZ_MA@mail.gmail.com>
References: <CA+Q==SCJpCB-7DsBfj8Ey071yV80JJubsmfTAEHWU4703hJRyw@mail.gmail.com>
 <CA+Q==SBUUManYctGBpEjUNxJ2Bk3PvtaEDKK5mLLDZsV6FhCQg@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3C8C05@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAC0Lnfv3fsrkwNhytQnOjHEt+t_Y_r9125-cyWh3vNAOzQZ_MA@mail.gmail.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3CD936@DB3PRD3001MB020.064d.mgd.msft.net>

I'm reluctant to invest much effort in a hack, when we know we are going to create an SPT anyway.  Let's just go for it!  Even if there are no TypeReps in it yet.

Actually, I think that each entry in the SPT should have just two fields: something like
	
    Key, Value

where "Key" is whatever we use as the "stable name" for the static value: a string, or something like that.


The "Value" is a full Haskell value, just a pointer into the heap (these are the new GC roots).  The value has type Dynamic, or something very like it:

  data Dynamic where
     MkDyn :: TTypeRep a -> a -> Dynamic

Maybe the library Dynamic isn't quite what we need; e.g we may want to include the Key too:

   data SptEntry where
     SPT :: String -> TTypeRep a -> a -> SptEntry

But regardless, the SPT itself is a simple key/value table, and all the interesting structure in in the Values in Haskell-land.

Now all we need is
- To build top-level bindings for the SPT Entries.
  These bindings are presumably created by the desugarer,
  as it desugars uses of 'static'

- To collect them in an SPT
  This is presumably done in a similar way to the mkModuleInit stuff
  in StgCmm.codeGen

Simon



| -----Original Message-----
| From: 0xbadcode at gmail.com [mailto:0xbadcode at gmail.com] On Behalf Of
| Mathieu Boespflug
| Sent: 18 November 2014 18:03
| To: Simon Peyton Jones
| Cc: Facundo Dom?nguez; ghc-devs at haskell.org; Mathieu Boespflug
| Subject: Re: Garbage collection
| 
| On 18 November 2014 16:59, Simon Peyton Jones <simonpj at microsoft.com>
| wrote:
| > Isn't it this simple: the Static Pointer Table must be a source of
| roots for the garbage collector.  Of course!  An item in the SPT may be
| looked up at any time.
| 
| As Facundo says, the existence of the SPT would solve everything. But
| we haven't quite figured out how to create a simple SPT yet, so were
| wondering whether there is an existing generic mechanism to register
| new GC roots.
| 
| I guess there is no better solution but to just create an SPT, even if
| we don't yet have TypeRep's to put in it.
| 
| With an SPT, and under the assumption of everyone sharing the same
| binary in the distributed system, there will be no need to hold on to
| *all* CAF's - just the ones that are known to have a StaticPointer
| created for them at compile time.

From simonpj at microsoft.com  Wed Nov 19 13:09:19 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 19 Nov 2014 13:09:19 +0000
Subject: [commit: ghc] wip/T8584: Add support for pattern synonym type
 signatures. Syntax is of the form (34acc90)
In-Reply-To: <20141119111712.B97003A300@ghc.haskell.org>
References: <20141119111712.B97003A300@ghc.haskell.org>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3CD986@DB3PRD3001MB020.064d.mgd.msft.net>

Gergo

I've lost track.  Is this ready to commit?

Simon

| -----Original Message-----
| From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of
| git at git.haskell.org
| Sent: 19 November 2014 11:17
| To: ghc-commits at haskell.org
| Subject: [commit: ghc] wip/T8584: Add support for pattern synonym type
| signatures. Syntax is of the form (34acc90)
| 
| Repository : ssh://git at git.haskell.org/ghc
| 
| On branch  : wip/T8584
| Link       :
| http://ghc.haskell.org/trac/ghc/changeset/34acc90ccef765ca6a55b69437a7218
| 28a7fba6c/ghc
| 
| >---------------------------------------------------------------
| 
| commit 34acc90ccef765ca6a55b69437a721828a7fba6c
| Author: Dr. ERDI Gergo <gergo at erdi.hu>
| Date:   Fri Nov 7 19:29:06 2014 +0800
| 
|     Add support for pattern synonym type signatures.
|     Syntax is of the form
| 
|         pattern P :: (Prov b) => (Req a) => a -> b -> Int -> T a
| 
|     which declares a pattern synonym called `P`, with argument types `a`,
| `b`,
|     and `Int`, and result type `T a`, with provided context `(Prov b)`
| and required
|     context `(Req a)`.
| 
| 
| >---------------------------------------------------------------
| 
| 34acc90ccef765ca6a55b69437a721828a7fba6c
|  compiler/hsSyn/HsBinds.lhs                       |  51 +++---
|  compiler/hsSyn/HsTypes.lhs                       |  16 +-
|  compiler/iface/IfaceSyn.lhs                      |  25 ++-
|  compiler/iface/IfaceType.lhs                     |  15 +-
|  compiler/parser/Parser.y                         |  51 ++++--
|  compiler/parser/RdrHsSyn.hs                      |  27 +---
|  compiler/rename/RnBinds.lhs                      |  42 ++---
|  compiler/typecheck/TcBinds.lhs                   |  50 +++++-
|  compiler/typecheck/TcClassDcl.lhs                |   4 +-
|  compiler/typecheck/TcPat.lhs                     |  23 ++-
|  compiler/typecheck/TcPatSyn.lhs                  | 195
| +++++++++++++++++------
|  compiler/typecheck/TcPatSyn.lhs-boot             |   9 +-
|  testsuite/tests/ghci/scripts/T8776.stdout        |   2 +-
|  testsuite/tests/patsyn/should_compile/T8584-1.hs |   8 +
|  testsuite/tests/patsyn/should_compile/T8968-1.hs |   8 +
|  testsuite/tests/patsyn/should_compile/all.T      |   2 +
|  16 files changed, 351 insertions(+), 177 deletions(-)
| 
| Diff suppressed because of size. To see it, use:
| 
|     git diff-tree --root --patch-with-stat --no-color --find-copies-
| harder --ignore-space-at-eol --cc
| 34acc90ccef765ca6a55b69437a721828a7fba6c
| _______________________________________________
| ghc-commits mailing list
| ghc-commits at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-commits

From gergo at erdi.hu  Wed Nov 19 13:42:41 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Wed, 19 Nov 2014 21:42:41 +0800 (SGT)
Subject: [commit: ghc] wip/T8584: Add support for pattern synonym type
 signatures. Syntax is of the form (34acc90)
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3CD986@DB3PRD3001MB020.064d.mgd.msft.net>
References: <20141119111712.B97003A300@ghc.haskell.org>
 <618BE556AADD624C9C918AA5D5911BEF3F3CD986@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <alpine.DEB.2.10.1411192141070.2047@galaxy>

On Wed, 19 Nov 2014, Simon Peyton Jones wrote:

> I've lost track.  Is this ready to commit?

I have just today finished it completely, implementation-wise. It 
validates and contains Haddock updates as well, to use the same syntax as 
the frontend.

I will be updating the documentation tomorrow and then merging it.

I'll send an email to ghc-devs about it, to make sure it makes it in 
before the feature freeze.

Bye,
 	Gergo

From gergo at erdi.hu  Wed Nov 19 13:48:55 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Wed, 19 Nov 2014 21:48:55 +0800 (SGT)
Subject: Pattern synonym type signatures
Message-ID: <alpine.DEB.2.10.1411192142420.2047@galaxy>

Hi,

I have finished the implementation of type signature support for pattern 
synonyms. In the end, I went with the following syntax:

     pattern P :: (Prov b) => (Req a) => a -> b -> Int -> T a

which declares a pattern synonym called `P`, with argument types `a`, `b`,
and `Int`, and result type `T a`, with provided context `(Prov b)` and 
required context `(Req a)`.

This has the advantage that it doesn't require new syntax at all (no 
funky `;` business in the contexts), and avoids the 'pattern type' 
monstrosity that Edward Kmett rightfully hated.

I plan to finish up the branch tomorrow (by updating the documentation), 
and then merging it into master. That is still within the feature freeze 
window, right? Also, if anything comes up tomorrow and I cannot finish it 
after all, it'd be a real bummer not to get this into GHC 7.10. So the 
reason I'm sending this email now is to just make sure that it will make 
its way into 7.10.

Thanks,
 	Gergo

From jan.stolarek at p.lodz.pl  Wed Nov 19 16:31:50 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Wed, 19 Nov 2014 17:31:50 +0100
Subject: Daily documentation build?
In-Reply-To: <CAHnG2CzHeg1gWOUgntiYTkwr-x3V8c=w42e4AQ=+1FG25a9-6A@mail.gmail.com>
References: <1415276873.1392.7.camel@joachim-breitner.de>
 <CAD3WKgj8GQbi7Uk1GsXoMZ6a5gVToZzLi6tOf4u7YfnNR82J+g@mail.gmail.com>
 <CAHnG2CzHeg1gWOUgntiYTkwr-x3V8c=w42e4AQ=+1FG25a9-6A@mail.gmail.com>
Message-ID: <201411191731.50248.jan.stolarek@p.lodz.pl>

Looks like something is broken again :-( Builds from the last two days are missing.

Janek

From pali.gabor at gmail.com  Wed Nov 19 18:28:03 2014
From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=)
Date: Wed, 19 Nov 2014 19:28:03 +0100
Subject: Daily documentation build?
In-Reply-To: <201411191731.50248.jan.stolarek@p.lodz.pl>
References: <1415276873.1392.7.camel@joachim-breitner.de>
 <CAD3WKgj8GQbi7Uk1GsXoMZ6a5gVToZzLi6tOf4u7YfnNR82J+g@mail.gmail.com>
 <CAHnG2CzHeg1gWOUgntiYTkwr-x3V8c=w42e4AQ=+1FG25a9-6A@mail.gmail.com>
 <201411191731.50248.jan.stolarek@p.lodz.pl>
Message-ID: <CAHnG2CwyGu1Jzu68OQdXxDE9FZtZLVER7AQXPaSqePQnDQzBhg@mail.gmail.com>

2014-11-19 17:31 GMT+01:00 Jan Stolarek <jan.stolarek at p.lodz.pl>:
> Looks like something is broken again :-( Builds from the last two days are
> missing.

There is a tiny bug in the script that does the generation which is
only triggered when running as a cron job. Due to this, the tarballs
are created as empty ones.  Now I fixed all the missing builds up by
manually running it.

From mikolaj at well-typed.com  Wed Nov 19 18:56:20 2014
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Wed, 19 Nov 2014 19:56:20 +0100
Subject: GHC Weekly News - 2014/11/18
Message-ID: <CAHFo2urEjX2nV6C9_q_X5DpumGLeAFakr-RLRhzf=OfVCM6Csw@mail.gmail.com>

Austin got caught in a rescue operation (which seems to have
succeeded, given that haskell.org is up again), so I'm posting
his writeup for the GHC Weekly News, straight from the blog post:

https://ghc.haskell.org/trac/ghc/blog/weekly20141118

-----------


Hello *,

Once more we have the GHC Weekly news! This one is a bit late due to
Austin being in limbo unexpectedly for a few days last week. (The next
one will of course come again on Friday to keep things straight.)

With that out of the way, let's see what exactly is going on:

The STABLE freeze is happening at the end of this week! That means if
you have something you want to get in, try to get people aware of it!
Austin (yours truly) has a backed up review queue it would seem, but
hopes to clear a bunch of it out before then.

Simon and Gergo started a whole bunch of discussion about type
signatures for pattern synonyms. There is a surprising amount of
content to talk about here for something that might seem simple:
https://www.haskell.org/pipermail/ghc-devs/2014-November/007066.html

Herbert Valerio Riedel has finally landed integer-gmp2, AKA Phab:D86,
which implements a complete overhaul of the integer-gmp library. This
library will be switched on by default in GHC 7.10.1, which means the
integer-gmp library version will have a super-major bump (version
1.0.0.0). This is the beginning of a longer-term vision for more
flexible Integer support in GHC, as described by Herbert on the design
page: https://ghc.haskell.org/trac/ghc/wiki/Design/IntegerGmp2 This
implementation also fixes a long standing pain point where GHC would
hook GMP allocations to exist on the GHC heap. Now GMP is just called
to like any FFI library.

Jan Stolarek made a heads up to help out GHC newcomers: if you see a
ticket that should be easy, please tag it with the newcomer keyword!
This will let us have a live search of bugs that new developers can
take over. (Incidentally, Joachim mentions this is the same thing
Debian is doing in their bug tracker):
https://www.haskell.org/pipermail/ghc-devs/2014-November/007313.html

Merijn Verstraaten has put forward a proposal for more flexible
literate style Haskell file extensions. There doesn't seem to be any
major opposition, just some questions about the actual specification
and some other ramifications:
https://www.haskell.org/pipermail/ghc-devs/2014-November/007319.html

Facundo Dom?nguez posed a question about CAFs in the GC, which Jost
Berthold was fairly quick to reply to:
https://www.haskell.org/pipermail/ghc-devs/2014-November/007353.html

Adam Gundry, Eric Seidel, and Iavor Diatchki have grouped together to
get a new, unexpected feature into 7.10: type checking plugins. Now,
GHC will be able to load a regular Haskell package as a plugin during
the compilation process. Iavor has a work-in-progress plugin that
solves constraints for type-level natural numbers using a SMT solver.
The code review from everyone was published in Phab:D489.

Austin opened up a discussion about the future of the Haskell98 and
Haskell2010 packages, and the unfortunate conclusion is it looks like
we're going to drop them for 7.10. Austin has some rationale, and
there was some followup in the mailing list thread too:
https://www.haskell.org/pipermail/ghc-devs/2014-November/007357.html

Closed tickets this week include: #9785, #9053, #9513, #9073, #9077,
#9683, #9662, #9646, #9787, #8672, #9791, #9781, #9621, #9594, #9066,
#9527, #8100, #9064, #9204, #9788, #9794, #9608, #9442, #9428, #9763,
#9664, #8750, #9796, #9341, #9330, #9323, #9322, #9749, #7381, #8701,
#9286, #9802, #9800, #9302, #9174, #9171, #9141, #9100, #9134, #8798,
#8756, #8716, #8688, #8680, #8664, #8647, #9804, #8620, #9801, #8559,
#8559, #8545, #8528, #8544, #8558


--
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From mail at joachim-breitner.de  Thu Nov 20 08:36:23 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 20 Nov 2014 09:36:23 +0100
Subject: More flexible literate Haskell extensions (Trac #9789), summary
 on wiki
In-Reply-To: <CD574F24-99A8-4276-BED2-8C3050E17332@inconsistent.nl>
References: <CD574F24-99A8-4276-BED2-8C3050E17332@inconsistent.nl>
Message-ID: <1416472583.1442.1.camel@joachim-breitner.de>

Hi Merjin,

there is one possible problem with this approach. Currently, the
compiler never has to read the contents of the directory (or at least
that?s what I assume; is that correct?) but only has to probe the
existence of a fixed finite set of files.

With your extensions it will have to read the directory contents. In
most situations, that should be fine, but it might cause minor
inconveniences with very large directories, many search paths (-i flags)
and/or very weird file systems (compiling from a FUSE-mounted
HTTP-Server that does not support directory listing? Would work now...)

A fixed set of extensions (e.g. just "md" and "tex") would avoid this
problem, but goes against the spirit of the proposal.

This is not an objection against the proposal, just a minor point to be
considered.

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141120/b40cd65d/attachment.sig>

From gergo at erdi.hu  Thu Nov 20 10:26:25 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Thu, 20 Nov 2014 18:26:25 +0800 (SGT)
Subject: optllvm broken on master?
Message-ID: <alpine.DEB.2.10.1411201824370.2047@galaxy>

Hi,

Tests fail on master when run the optllvm way, e.g.:

/usr/bin/opt: /tmp/ghc16190_0/ghc16190_2.ll:611:25: error: expected 'global' or 'constant'
@newCAF$alias = private alias i8* @newCAF

I think it's the change in d87fa34:

index 7307725..cdc407c 100644
--- a/compiler/llvmGen/Llvm/PpLlvm.hs
+++ b/compiler/llvmGen/Llvm/PpLlvm.hs
@@ -80,7 +80,7 @@ ppLlvmGlobal (LMGlobal var@(LMGlobalVar _ _ link x a c) 
dat) =
          const_link = case c of
            Global   -> ppr link <+> text "global"
            Constant -> ppr link <+> text "constant"
-          Alias    -> text "alias" <+> ppr link
+          Alias    -> ppr link <+> text "alias"

      in ppAssignment var $ const_link <+> rhs <> sect <> align
         $+$ newLine



-- 

   .--= ULLA! =-----------------.
    \     http://gergo.erdi.hu   \
     `---= gergo at erdi.hu =-------'
If it ain't broke, I can fix it.

From svenpanne at gmail.com  Thu Nov 20 10:40:22 2014
From: svenpanne at gmail.com (Sven Panne)
Date: Thu, 20 Nov 2014 11:40:22 +0100
Subject: More flexible literate Haskell extensions (Trac #9789), summary
 on wiki
In-Reply-To: <1416472583.1442.1.camel@joachim-breitner.de>
References: <CD574F24-99A8-4276-BED2-8C3050E17332@inconsistent.nl>
 <1416472583.1442.1.camel@joachim-breitner.de>
Message-ID: <CANBN=muVOYGNbC-+vSoSmCyczZ-vPOXs+xPjTof_ystaEQzrcw@mail.gmail.com>

2014-11-20 9:36 GMT+01:00 Joachim Breitner <mail at joachim-breitner.de>:
> [...] With your extensions it will have to read the directory contents. In
> most situations, that should be fine, but it might cause minor
> inconveniences with very large directories, many search paths (-i flags)
> and/or very weird file systems (compiling from a FUSE-mounted
> HTTP-Server that does not support directory listing? Would work now...)

Hmmm, IMHO reading directory contents is not a good idea for a
compiler, for just the reasons you mentioned.

> A fixed set of extensions (e.g. just "md" and "tex") would avoid this
> problem, but goes against the spirit of the proposal.

I think we can get the best of both worlds by adding a compiler flag,
e.g. --literate-extensions=md,tex. This way the compiler still has to
probe only a finite set of filenames *and* we are still flexible.

Cheers,
   S.

From pali.gabor at gmail.com  Thu Nov 20 11:56:56 2014
From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=)
Date: Thu, 20 Nov 2014 12:56:56 +0100
Subject: Daily documentation build?
In-Reply-To: <CAHnG2CwyGu1Jzu68OQdXxDE9FZtZLVER7AQXPaSqePQnDQzBhg@mail.gmail.com>
References: <1415276873.1392.7.camel@joachim-breitner.de>
 <CAD3WKgj8GQbi7Uk1GsXoMZ6a5gVToZzLi6tOf4u7YfnNR82J+g@mail.gmail.com>
 <CAHnG2CzHeg1gWOUgntiYTkwr-x3V8c=w42e4AQ=+1FG25a9-6A@mail.gmail.com>
 <201411191731.50248.jan.stolarek@p.lodz.pl>
 <CAHnG2CwyGu1Jzu68OQdXxDE9FZtZLVER7AQXPaSqePQnDQzBhg@mail.gmail.com>
Message-ID: <CAHnG2Czy=je00=6uLbW8Akv_-M2r2sHEXaQC-rb3jKBr=a2wHw@mail.gmail.com>

2014-11-19 19:28 GMT+01:00 P?li G?bor J?nos <pali.gabor at gmail.com>:
> 2014-11-19 17:31 GMT+01:00 Jan Stolarek <jan.stolarek at p.lodz.pl>:
>> Looks like something is broken again :-( Builds from the last two days are
>> missing.
>
> There is a tiny bug in the script that does the generation which is
> only triggered when running as a cron job.

Yay, I have managed to fix the problem with the cron job -- now the
documentation can be generated without manual intervention.

From jan.stolarek at p.lodz.pl  Thu Nov 20 14:14:03 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Thu, 20 Nov 2014 15:14:03 +0100
Subject: Phab + submodules
Message-ID: <201411201514.03461.jan.stolarek@p.lodz.pl>

I made changes to a submodule but `arc diff` did not pick these up. This means that:
a) Harbormaster build fails
b) revision cannot be landed using `arc land`
Is there a way around these?

Janek


From merijn at inconsistent.nl  Thu Nov 20 17:52:18 2014
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Thu, 20 Nov 2014 09:52:18 -0800
Subject: More flexible literate Haskell extensions (Trac #9789),
 summary on wiki
In-Reply-To: <CANBN=muVOYGNbC-+vSoSmCyczZ-vPOXs+xPjTof_ystaEQzrcw@mail.gmail.com>
References: <CD574F24-99A8-4276-BED2-8C3050E17332@inconsistent.nl>
 <1416472583.1442.1.camel@joachim-breitner.de>
 <CANBN=muVOYGNbC-+vSoSmCyczZ-vPOXs+xPjTof_ystaEQzrcw@mail.gmail.com>
Message-ID: <60C6C401-5469-40BD-B111-ACF9656F52FD@inconsistent.nl>

Hey,

I'm not really happy with an explicit extension list passed through flags, as it seems far to manual. It doesn't strike me as a very significant problem as my current work-in-progress patch only resorts to scanning the directory listing if none of the existing extensions are found.

It seems unlikely that extremely large directories are in the search path. I don't think we're expecting anyone to have thousands of files in their module directories (and even thousands would take 0 time to scan...). We already try all search paths during probing so the extra overhead from large number of search paths shouldn't be substantially more than we have now.

As for the weird FS support, I really don't think it's GHC's job to support people doing ridiculous things like "compiling on a filesystem that doesn't support directory listings", I mean, come on!

To be honest, I consider both directories with huge numbers of files (keep in mind, we'd only scan the actual module sub-directory AND that we'd need to run into directories with tens if not hundreds of thousands files to notice any real slowdown) and weird filesystems that don't support directory listing cases of "so don't do that, then". Especially since these are only problems for users using non-standard module extensions.

Cheers,
Merijn

> On 20 Nov 2014, at 2:40, Sven Panne <svenpanne at gmail.com> wrote:
> 2014-11-20 9:36 GMT+01:00 Joachim Breitner <mail at joachim-breitner.de>:
>> [...] With your extensions it will have to read the directory contents. In
>> most situations, that should be fine, but it might cause minor
>> inconveniences with very large directories, many search paths (-i flags)
>> and/or very weird file systems (compiling from a FUSE-mounted
>> HTTP-Server that does not support directory listing? Would work now...)
> 
> Hmmm, IMHO reading directory contents is not a good idea for a
> compiler, for just the reasons you mentioned.
> 
>> A fixed set of extensions (e.g. just "md" and "tex") would avoid this
>> problem, but goes against the spirit of the proposal.
> 
> I think we can get the best of both worlds by adding a compiler flag,
> e.g. --literate-extensions=md,tex. This way the compiler still has to
> probe only a finite set of filenames *and* we are still flexible.

From jan.stolarek at p.lodz.pl  Thu Nov 20 19:32:52 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Thu, 20 Nov 2014 20:32:52 +0100
Subject: HEADS UP: Interface file format change
Message-ID: <201411202032.52762.jan.stolarek@p.lodz.pl>

I just pushed a large commit that changes format of interface files. This means doing a full 
rebuild once you pull it.

Janek

From lukexipd at gmail.com  Thu Nov 20 21:43:48 2014
From: lukexipd at gmail.com (Luke Iannini)
Date: Thu, 20 Nov 2014 13:43:48 -0800
Subject: optllvm broken on master?
In-Reply-To: <alpine.DEB.2.10.1411201824370.2047@galaxy>
References: <alpine.DEB.2.10.1411201824370.2047@galaxy>
Message-ID: <CAGo83CgJ9hFyZj-Zka=boz9nvVKvm6Rmw4uz3hH5i1Rqy8fhng@mail.gmail.com>

Whoops, that's my fault; it shouldn't have slipped into the patch -- this is
required for LLVM 3.6 (which I was using to work on my ARM64 patch), but
clearly isn't backwards compatible.

I wonder what's best to do for this? Would it be correct to switch on LLVM
versions or should this be considered a bug in LLVM? (it was the only
change needed for 3.6)

I will submit a ticket to revert that line in the meantime.

Thanks!
Luke

On Thu, Nov 20, 2014 at 2:26 AM, Dr. ERDI Gergo <gergo at erdi.hu> wrote:

> Hi,
>
> Tests fail on master when run the optllvm way, e.g.:
>
> /usr/bin/opt: /tmp/ghc16190_0/ghc16190_2.ll:611:25: error: expected
> 'global' or 'constant'
> @newCAF$alias = private alias i8* @newCAF
>
> I think it's the change in d87fa34:
>
> index 7307725..cdc407c 100644
> --- a/compiler/llvmGen/Llvm/PpLlvm.hs
> +++ b/compiler/llvmGen/Llvm/PpLlvm.hs
> @@ -80,7 +80,7 @@ ppLlvmGlobal (LMGlobal var@(LMGlobalVar _ _ link x a c)
> dat) =
>          const_link = case c of
>            Global   -> ppr link <+> text "global"
>            Constant -> ppr link <+> text "constant"
> -          Alias    -> text "alias" <+> ppr link
> +          Alias    -> ppr link <+> text "alias"
>
>      in ppAssignment var $ const_link <+> rhs <> sect <> align
>         $+$ newLine
>
>
>
> --
>
>   .--= ULLA! =-----------------.
>    \     http://gergo.erdi.hu   \
>     `---= gergo at erdi.hu =-------'
> If it ain't broke, I can fix it.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141120/21950b6f/attachment.html>

From lukexipd at gmail.com  Thu Nov 20 21:49:25 2014
From: lukexipd at gmail.com (Luke Iannini)
Date: Thu, 20 Nov 2014 13:49:25 -0800
Subject: optllvm broken on master?
In-Reply-To: <CAGo83CgJ9hFyZj-Zka=boz9nvVKvm6Rmw4uz3hH5i1Rqy8fhng@mail.gmail.com>
References: <alpine.DEB.2.10.1411201824370.2047@galaxy>
 <CAGo83CgJ9hFyZj-Zka=boz9nvVKvm6Rmw4uz3hH5i1Rqy8fhng@mail.gmail.com>
Message-ID: <CAGo83CjPDSO+tqzyH+GMPU-i9jo4k4pSr2_zxq5BDq7a_Jexrg@mail.gmail.com>

On Thu, Nov 20, 2014 at 1:43 PM, Luke Iannini <lukexipd at gmail.com> wrote:

> Whoops, that's my fault; it shouldn't have slipped into the patch -- this
> is required for LLVM 3.6 (which I was using to work on my ARM64 patch), but
> clearly isn't backwards compatible.
>
> I wonder what's best to do for this? Would it be correct to switch on LLVM
> versions or should this be considered a bug in LLVM? (it was the only
> change needed for 3.6)
>
(I mean to say, it was the only change needed atop Ben's work on 3.5
support in https://phabricator.haskell.org/D155)


>
> I will submit a ticket to revert that line in the meantime.
>
> Thanks!
> Luke
>
> On Thu, Nov 20, 2014 at 2:26 AM, Dr. ERDI Gergo <gergo at erdi.hu> wrote:
>
>> Hi,
>>
>> Tests fail on master when run the optllvm way, e.g.:
>>
>> /usr/bin/opt: /tmp/ghc16190_0/ghc16190_2.ll:611:25: error: expected
>> 'global' or 'constant'
>> @newCAF$alias = private alias i8* @newCAF
>>
>> I think it's the change in d87fa34:
>>
>> index 7307725..cdc407c 100644
>> --- a/compiler/llvmGen/Llvm/PpLlvm.hs
>> +++ b/compiler/llvmGen/Llvm/PpLlvm.hs
>> @@ -80,7 +80,7 @@ ppLlvmGlobal (LMGlobal var@(LMGlobalVar _ _ link x a
>> c) dat) =
>>          const_link = case c of
>>            Global   -> ppr link <+> text "global"
>>            Constant -> ppr link <+> text "constant"
>> -          Alias    -> text "alias" <+> ppr link
>> +          Alias    -> ppr link <+> text "alias"
>>
>>      in ppAssignment var $ const_link <+> rhs <> sect <> align
>>         $+$ newLine
>>
>>
>>
>> --
>>
>>   .--= ULLA! =-----------------.
>>    \     http://gergo.erdi.hu   \
>>     `---= gergo at erdi.hu =-------'
>> If it ain't broke, I can fix it.
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141120/1ea39323/attachment.html>

From austin at well-typed.com  Fri Nov 21 03:26:31 2014
From: austin at well-typed.com (Austin Seipp)
Date: Thu, 20 Nov 2014 21:26:31 -0600
Subject: optllvm broken on master?
In-Reply-To: <CAGo83CjPDSO+tqzyH+GMPU-i9jo4k4pSr2_zxq5BDq7a_Jexrg@mail.gmail.com>
References: <alpine.DEB.2.10.1411201824370.2047@galaxy>
 <CAGo83CgJ9hFyZj-Zka=boz9nvVKvm6Rmw4uz3hH5i1Rqy8fhng@mail.gmail.com>
 <CAGo83CjPDSO+tqzyH+GMPU-i9jo4k4pSr2_zxq5BDq7a_Jexrg@mail.gmail.com>
Message-ID: <CAEs96n24VB+PSXu0b3c6f4tJX2WOeO1CoWKYrKSsi33oLucY_g@mail.gmail.com>

(Resending to list)

Yes, switching on the version would be preferable since we detect the
tool version in a few places already if it's possible. Or at least we
should back out the regressing change right now until we ship LLVM
with GHC as I proposed.

On Thu, Nov 20, 2014 at 3:49 PM, Luke Iannini <lukexipd at gmail.com> wrote:
>
>
> On Thu, Nov 20, 2014 at 1:43 PM, Luke Iannini <lukexipd at gmail.com> wrote:
>>
>> Whoops, that's my fault; it shouldn't have slipped into the patch ? this
>> is required for LLVM 3.6 (which I was using to work on my ARM64 patch), but
>> clearly isn't backwards compatible.
>>
>> I wonder what's best to do for this? Would it be correct to switch on LLVM
>> versions or should this be considered a bug in LLVM? (it was the only change
>> needed for 3.6)
>
> (I mean to say, it was the only change needed atop Ben's work on 3.5 support
> in https://phabricator.haskell.org/D155)
>
>>
>>
>> I will submit a ticket to revert that line in the meantime.
>>
>> Thanks!
>> Luke
>>
>> On Thu, Nov 20, 2014 at 2:26 AM, Dr. ERDI Gergo <gergo at erdi.hu> wrote:
>>>
>>> Hi,
>>>
>>> Tests fail on master when run the optllvm way, e.g.:
>>>
>>> /usr/bin/opt: /tmp/ghc16190_0/ghc16190_2.ll:611:25: error: expected
>>> 'global' or 'constant'
>>> @newCAF$alias = private alias i8* @newCAF
>>>
>>> I think it's the change in d87fa34:
>>>
>>> index 7307725..cdc407c 100644
>>> --- a/compiler/llvmGen/Llvm/PpLlvm.hs
>>> +++ b/compiler/llvmGen/Llvm/PpLlvm.hs
>>> @@ -80,7 +80,7 @@ ppLlvmGlobal (LMGlobal var@(LMGlobalVar _ _ link x a c)
>>> dat) =
>>>          const_link = case c of
>>>            Global   -> ppr link <+> text "global"
>>>            Constant -> ppr link <+> text "constant"
>>> -          Alias    -> text "alias" <+> ppr link
>>> +          Alias    -> ppr link <+> text "alias"
>>>
>>>      in ppAssignment var $ const_link <+> rhs <> sect <> align
>>>         $+$ newLine
>>>
>>>
>>>
>>> --
>>>
>>>   .--= ULLA! =-----------------.
>>>    \     http://gergo.erdi.hu   \
>>>     `---= gergo at erdi.hu =-------'
>>> If it ain't broke, I can fix it.
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From austin at well-typed.com  Fri Nov 21 03:35:48 2014
From: austin at well-typed.com (Austin Seipp)
Date: Thu, 20 Nov 2014 21:35:48 -0600
Subject: HEADS UP: haskell{98,2010} and old-{time,locale} deleted
Message-ID: <CAEs96n2ggztmuhRwzM=06bbhcLHUS3aJobJk0U8mAynaR2iBKA@mail.gmail.com>

Hi all,

When you update your trees, I'll have pushed D510 and D511, which
remove the aforementioned libraries.

After updating, you can just delete the repositories since git status
will alert you about them now:

$ rm -rf libraries/old-time libraries/old-locale libraries/haskell98
libraries/haskell2010

I'll be updating the users manual soon as I mentioned earlier this week.

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From spam at scientician.net  Fri Nov 21 05:09:06 2014
From: spam at scientician.net (Bardur Arantsson)
Date: Fri, 21 Nov 2014 06:09:06 +0100
Subject: HEADS UP: haskell{98,2010} and old-{time,locale} deleted
In-Reply-To: <CAEs96n2ggztmuhRwzM=06bbhcLHUS3aJobJk0U8mAynaR2iBKA@mail.gmail.com>
References: <CAEs96n2ggztmuhRwzM=06bbhcLHUS3aJobJk0U8mAynaR2iBKA@mail.gmail.com>
Message-ID: <m4mhdi$ppm$1@ger.gmane.org>

On 2014-11-21 04:35, Austin Seipp wrote:
> Hi all,
> 
> When you update your trees, I'll have pushed D510 and D511, which
> remove the aforementioned libraries.
> 
> After updating, you can just delete the repositories since git status
> will alert you about them now:
> 
> $ rm -rf libraries/old-time libraries/old-locale libraries/haskell98
> libraries/haskell2010
> 
> I'll be updating the users manual soon as I mentioned earlier this week.
> 

Does this mean that any code compiling against the current release of
old-locale (1.0.0.6) will fail to compile with GHC 7.10.x? I ask because
I note that old-locale (1.0.0.6) depends on

  base >= 4.2 && < 4.8

and presumably GHC 7.10.x will have a new "base" version? (Which will
exclude old-locale 1.0.0.6 from any Cabal install plan.)

If so, then this could be a problem. According to
http://packdeps.haskellers.com/reverse/:

   old-locale: 367 reverse deps (1 outdated)
   old-time: 244 reverse deps (15 outdated)

This would represent massive breakage AFAICT?

Regards,



From lukexipd at gmail.com  Fri Nov 21 05:19:32 2014
From: lukexipd at gmail.com (Luke Iannini)
Date: Thu, 20 Nov 2014 21:19:32 -0800
Subject: optllvm broken on master?
In-Reply-To: <CAEs96n24VB+PSXu0b3c6f4tJX2WOeO1CoWKYrKSsi33oLucY_g@mail.gmail.com>
References: <alpine.DEB.2.10.1411201824370.2047@galaxy>
 <CAGo83CgJ9hFyZj-Zka=boz9nvVKvm6Rmw4uz3hH5i1Rqy8fhng@mail.gmail.com>
 <CAGo83CjPDSO+tqzyH+GMPU-i9jo4k4pSr2_zxq5BDq7a_Jexrg@mail.gmail.com>
 <CAEs96n24VB+PSXu0b3c6f4tJX2WOeO1CoWKYrKSsi33oLucY_g@mail.gmail.com>
Message-ID: <CAGo83CgQf+1yNu4w5vq+FhA9HS55mrYMoTvDYF0Y8cAJbQsQ1Q@mail.gmail.com>

OK, that sounds great. Here's the patch to revert the offending line:
https://ghc.haskell.org/trac/ghc/ticket/7942#comment:54

And I'll prepare another patch to implement switching on 3.6 shortly.

I'm definitely in support of the LLVM-with-GHC plan!
Cheers
Luke

On Thu, Nov 20, 2014 at 7:26 PM, Austin Seipp <austin at well-typed.com> wrote:

> (Resending to list)
>
> Yes, switching on the version would be preferable since we detect the
> tool version in a few places already if it's possible. Or at least we
> should back out the regressing change right now until we ship LLVM
> with GHC as I proposed.
>
> On Thu, Nov 20, 2014 at 3:49 PM, Luke Iannini <lukexipd at gmail.com> wrote:
> >
> >
> > On Thu, Nov 20, 2014 at 1:43 PM, Luke Iannini <lukexipd at gmail.com>
> wrote:
> >>
> >> Whoops, that's my fault; it shouldn't have slipped into the patch -- this
> >> is required for LLVM 3.6 (which I was using to work on my ARM64 patch),
> but
> >> clearly isn't backwards compatible.
> >>
> >> I wonder what's best to do for this? Would it be correct to switch on
> LLVM
> >> versions or should this be considered a bug in LLVM? (it was the only
> change
> >> needed for 3.6)
> >
> > (I mean to say, it was the only change needed atop Ben's work on 3.5
> support
> > in https://phabricator.haskell.org/D155)
> >
> >>
> >>
> >> I will submit a ticket to revert that line in the meantime.
> >>
> >> Thanks!
> >> Luke
> >>
> >> On Thu, Nov 20, 2014 at 2:26 AM, Dr. ERDI Gergo <gergo at erdi.hu> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Tests fail on master when run the optllvm way, e.g.:
> >>>
> >>> /usr/bin/opt: /tmp/ghc16190_0/ghc16190_2.ll:611:25: error: expected
> >>> 'global' or 'constant'
> >>> @newCAF$alias = private alias i8* @newCAF
> >>>
> >>> I think it's the change in d87fa34:
> >>>
> >>> index 7307725..cdc407c 100644
> >>> --- a/compiler/llvmGen/Llvm/PpLlvm.hs
> >>> +++ b/compiler/llvmGen/Llvm/PpLlvm.hs
> >>> @@ -80,7 +80,7 @@ ppLlvmGlobal (LMGlobal var@(LMGlobalVar _ _ link x
> a c)
> >>> dat) =
> >>>          const_link = case c of
> >>>            Global   -> ppr link <+> text "global"
> >>>            Constant -> ppr link <+> text "constant"
> >>> -          Alias    -> text "alias" <+> ppr link
> >>> +          Alias    -> ppr link <+> text "alias"
> >>>
> >>>      in ppAssignment var $ const_link <+> rhs <> sect <> align
> >>>         $+$ newLine
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>>   .--= ULLA! =-----------------.
> >>>    \     http://gergo.erdi.hu   \
> >>>     `---= gergo at erdi.hu =-------'
> >>> If it ain't broke, I can fix it.
> >>> _______________________________________________
> >>> ghc-devs mailing list
> >>> ghc-devs at haskell.org
> >>> http://www.haskell.org/mailman/listinfo/ghc-devs
> >>
> >>
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141120/f232a43d/attachment.html>

From hvriedel at gmail.com  Fri Nov 21 07:41:21 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Fri, 21 Nov 2014 08:41:21 +0100
Subject: HEADS UP: haskell{98,2010} and old-{time,locale} deleted
In-Reply-To: <m4mhdi$ppm$1@ger.gmane.org> (Bardur Arantsson's message of "Fri, 
 21 Nov 2014 06:09:06 +0100")
References: <CAEs96n2ggztmuhRwzM=06bbhcLHUS3aJobJk0U8mAynaR2iBKA@mail.gmail.com>
 <m4mhdi$ppm$1@ger.gmane.org>
Message-ID: <8761e9yp9a.fsf@gmail.com>

On 2014-11-21 at 06:09:06 +0100, Bardur Arantsson wrote:

[...]

> Does this mean that any code compiling against the current release of
> old-locale (1.0.0.6) will fail to compile with GHC 7.10.x? I ask because
> I note that old-locale (1.0.0.6) depends on
>
>   base >= 4.2 && < 4.8
>
> and presumably GHC 7.10.x will have a new "base" version? (Which will
> exclude old-locale 1.0.0.6 from any Cabal install plan.)

Oh it's quite simple, old-{time,locale} will continue to live on via
Hackage; We'll upload GHC 7.10 compatible versions of those two packages
to Hackage soon.


From simonpj at microsoft.com  Fri Nov 21 13:06:21 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 21 Nov 2014 13:06:21 +0000
Subject: [commit: ghc] master: Rejig builders for pattern synonyms,
 especially unlifted ones (e876208)
In-Reply-To: <20141121130257.F1BBC3A300@ghc.haskell.org>
References: <20141121130257.F1BBC3A300@ghc.haskell.org>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3D928D@DB3PRD3001MB020.064d.mgd.msft.net>

Heads up: this commit means you need to blow away all your .hi files.

Simon

|  -----Original Message-----
|  From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf
|  Of git at git.haskell.org
|  Sent: 21 November 2014 13:03
|  To: ghc-commits at haskell.org
|  Subject: [commit: ghc] master: Rejig builders for pattern synonyms,
|  especially unlifted ones (e876208)
|  
|  Repository : ssh://git at git.haskell.org/ghc
|  
|  On branch  : master
|  Link       :
|  http://ghc.haskell.org/trac/ghc/changeset/e876208117a34fb58f7f1e470de2
|  f954b3ca303d/ghc
|  
|  >---------------------------------------------------------------
|  
|  commit e876208117a34fb58f7f1e470de2f954b3ca303d
|  Author: Simon Peyton Jones <simonpj at microsoft.com>
|  Date:   Fri Nov 21 10:04:09 2014 +0000
|  
|      Rejig builders for pattern synonyms, especially unlifted ones
|  
|      When a pattern synonym is for an unlifted pattern, its "builder"
|  would
|      naturally be a top-level unlifted binding, which isn't allowed.
|  So we
|      give it an extra Void# argument.
|  
|      Our Plan A involved then making *two* Ids for these builders, with
|      some consequential fuss in the desugarer.  This was more pain than
|  I
|      liked, so I've re-jigged it.
|  
|       * There is just one builder for a pattern synonym.
|  
|       * It may have an extra Void# arg, but this decision is signalled
|         by the Bool in the psBuilder field.
|  
|         I did the same for the psMatcher field.
|  
|         Both Bools are serialised into interface files, so there is
|         absolutely no doubt whether that extra Void# argument is
|  required.
|  
|       * I renamed "wrapper" to "builder".  We have too may "wrappers"
|  
|       * In order to deal with typecchecking occurrences of P in
|  expressions,
|         I refactored the tcInferId code in TcExpr.
|  
|      All of this allowed me to revert 5fe872
|         "Apply compulsory unfoldings during desugaring, except for
|  `seq` which is special."
|      which turned out to be a rather messy hack in DsBinds
|  
|  
|  >---------------------------------------------------------------
|  
|  e876208117a34fb58f7f1e470de2f954b3ca303d
|   compiler/basicTypes/PatSyn.lhs       | 207 +++++++++++++++-----------
|  ----
|   compiler/deSugar/DsExpr.lhs          |  22 +---
|   compiler/deSugar/DsUtils.lhs         |  10 +-
|   compiler/iface/BuildTyCl.lhs         |   8 +-
|   compiler/iface/IfaceSyn.lhs          |  12 +-
|   compiler/iface/MkIface.lhs           |   9 +-
|   compiler/iface/TcIface.lhs           |  65 ++--------
|   compiler/typecheck/TcBinds.lhs       |  14 +--
|   compiler/typecheck/TcExpr.lhs        | 162 ++++++++----------------
|   compiler/typecheck/TcPatSyn.lhs      | 237 +++++++++++++++++++++-----
|  ---------
|   compiler/typecheck/TcPatSyn.lhs-boot |   4 +-
|   compiler/typecheck/TcRnMonad.lhs     |   5 +
|   12 files changed, 338 insertions(+), 417 deletions(-)
|  
|  Diff suppressed because of size. To see it, use:
|  
|      git diff-tree --root --patch-with-stat --no-color --find-copies-
|  harder --ignore-space-at-eol --cc
|  e876208117a34fb58f7f1e470de2f954b3ca303d
|  _______________________________________________
|  ghc-commits mailing list
|  ghc-commits at haskell.org
|  http://www.haskell.org/mailman/listinfo/ghc-commits

From simonpj at microsoft.com  Fri Nov 21 13:51:55 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 21 Nov 2014 13:51:55 +0000
Subject: linker_unload
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3D93CE@DB3PRD3001MB020.064d.mgd.msft.net>

I'm getting this for test linker_unload on Linux. I'm sure it's not my fault!

But it makes validate fail

Simon

Wrong exit code (expected 0 , actual 2 )
Stdout:

Stderr:
linker_unload: /5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist-install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a: unknown symbol `__gmpn_rshift'
linker_unload: resolveObjs failed
make[3]: *** [linker_unload] Error 1

*** unexpected failure for linker_unload(normal)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141121/bc8d52ed/attachment.html>

From mail at joachim-breitner.de  Fri Nov 21 14:43:08 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 21 Nov 2014 15:43:08 +0100
Subject: T7220a failing
Message-ID: <1416580988.1611.8.camel@joachim-breitner.de>

Hi,

I observe

--- /dev/null	2014-11-21 13:30:25.126538446 +0000
+++ ./typecheck/should_compile/T7220a.comp.stderr	2014-11-21 13:58:27.078240760 +0000
@@ -0,0 +1,14 @@
+
+T7220a.hs:17:6:
+    Could not deduce (C a b)
+    from the context (C a0 b, TF b ~ Y)
+      bound by the type signature for f :: (C a0 b, TF b ~ Y) => b
+      at T7220a.hs:17:6-44
+    Possible fix:
+      add (C a b) to the context of
+        the type signature for f :: (C a0 b, TF b ~ Y) => b
+    In the ambiguity check for the type signature for ???f???:
+      f :: forall a. (forall b. (C a b, TF b ~ Y) => b) -> X
+    To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
+    In the type signature for ???f???:
+      f :: (forall b. (C a b, TF b ~ Y) => b) -> X
*** unexpected failure for T7220a(normal)

https://s3.amazonaws.com/archive.travis-ci.org/jobs/41712832/log.txt


probably caused by one of the commits pushed by SPJ in the range
b0dd34756613...c5a39389ea06

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141121/d06a09fd/attachment.sig>

From hvriedel at gmail.com  Fri Nov 21 15:38:46 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Fri, 21 Nov 2014 16:38:46 +0100
Subject: HEADS UP: haskell{98,2010} and old-{time,locale} deleted
In-Reply-To: <8761e9yp9a.fsf@gmail.com> (Herbert Valerio Riedel's message of
 "Fri, 21 Nov 2014 08:41:21 +0100")
References: <CAEs96n2ggztmuhRwzM=06bbhcLHUS3aJobJk0U8mAynaR2iBKA@mail.gmail.com>
 <m4mhdi$ppm$1@ger.gmane.org> <8761e9yp9a.fsf@gmail.com>
Message-ID: <87sihcy35l.fsf@gmail.com>

On 2014-11-21 at 08:41:21 +0100, Herbert Valerio Riedel wrote:

[...]

> Oh it's quite simple, old-{time,locale} will continue to live on via
> Hackage; We'll upload GHC 7.10 compatible versions of those two packages
> to Hackage soon.

PS: I've already uploaded new {base-4.8,GHC-7.10}-compatible versions:

 - http://hackage.haskell.org/package/old-locale-1.0.0.7

 - http://hackage.haskell.org/package/old-time-1.1.0.3

Cheers,
  hvr

From austin at well-typed.com  Fri Nov 21 15:45:23 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 21 Nov 2014 09:45:23 -0600
Subject: HEADS UP: haskell{98,2010} and old-{time,locale} deleted
In-Reply-To: <87sihcy35l.fsf@gmail.com>
References: <CAEs96n2ggztmuhRwzM=06bbhcLHUS3aJobJk0U8mAynaR2iBKA@mail.gmail.com>
 <m4mhdi$ppm$1@ger.gmane.org> <8761e9yp9a.fsf@gmail.com>
 <87sihcy35l.fsf@gmail.com>
Message-ID: <CAEs96n0P840tM_ZS03wrW7i7f_QyB=A_SdH64f+3QQANHn66kQ@mail.gmail.com>

Great. Thank you Herbert!

On Fri, Nov 21, 2014 at 9:38 AM, Herbert Valerio Riedel
<hvriedel at gmail.com> wrote:
> On 2014-11-21 at 08:41:21 +0100, Herbert Valerio Riedel wrote:
>
> [...]
>
>> Oh it's quite simple, old-{time,locale} will continue to live on via
>> Hackage; We'll upload GHC 7.10 compatible versions of those two packages
>> to Hackage soon.
>
> PS: I've already uploaded new {base-4.8,GHC-7.10}-compatible versions:
>
>  - http://hackage.haskell.org/package/old-locale-1.0.0.7
>
>  - http://hackage.haskell.org/package/old-time-1.1.0.3
>
> Cheers,
>   hvr
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From austin at well-typed.com  Fri Nov 21 15:57:50 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 21 Nov 2014 09:57:50 -0600
Subject: NOTE: The STABLE freeze is scheduled to occur TODAY.
Message-ID: <CAEs96n397St05bhyW0QvkWdEsri2BVKCvY9Y_Jse6gzBYVw+Hg@mail.gmail.com>

Hi friends,

Today, I'm planning on trying to cut a new `ghc-7.10` branch for the
stable freeze. That means I'm going to spend a lot of time merging
patches and other things with several other developers because
everything is crazy and so many things wow.

If you have things you want me to review, then please:

  - Talk to me on IRC, #ghc on Freenode (I am 'thoughtpolice')
  - Ping me on some medium like Skype (search for me). We can schedule
a chat for a short time to figure things out.
  - I can also do something like G+ or whatnot.
  - I will of course be reading my email.

Please note I would actually prefer to stay *away* from email I think,
since it's a larger context switch for me, but I'll actively check it
still just in case you want something and need to explain it.

I'll likely be doing this most of the day, so let me know what happens.

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From ndmitchell at gmail.com  Fri Nov 21 17:13:16 2014
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Fri, 21 Nov 2014 17:13:16 +0000
Subject: GHC filepath sync
Message-ID: <CAKcFpm+4ax0yKtxbAM1_89O5P+YUO1gxM8Ms5SCyHBaFVcD=6A@mail.gmail.com>

Hi,

As part of the forthcoming GHC release, I assume the filepath library
will be sync'd to the latest version in the GitHub repo? When will
that sync happen? Who will do the sync? When is the last time I can
make changes that go into GHC 7.10? What should I be doing to help? As
this is my first time, any details would be most appreciated.

When the library is next sync'd, the filepath library will need to be
removed from the GHC test suite. The reason is mostly pragmatic - I
have good coverage of a library which is entirely pure list
manipulations, and the GHC test infrastructure slowed down improving
the tests, while gaining nothing. In particular, GHC has been testing
the library for years, but the tests got turned off about 4 years ago,
so there were (non-critical) test failures that went unspotted for
years.

Thanks, Neil

From hvriedel at gmail.com  Fri Nov 21 18:14:11 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Fri, 21 Nov 2014 19:14:11 +0100
Subject: GHC filepath sync
In-Reply-To: <CAKcFpm+4ax0yKtxbAM1_89O5P+YUO1gxM8Ms5SCyHBaFVcD=6A@mail.gmail.com>
 (Neil Mitchell's message of "Fri, 21 Nov 2014 17:13:16 +0000")
References: <CAKcFpm+4ax0yKtxbAM1_89O5P+YUO1gxM8Ms5SCyHBaFVcD=6A@mail.gmail.com>
Message-ID: <87mw7kxvyk.fsf@gnu.org>

On 2014-11-21 at 18:13:16 +0100, Neil Mitchell wrote:
> As part of the forthcoming GHC release, I assume the filepath library
> will be sync'd to the latest version in the GitHub repo? When will
> that sync happen? 

We'll probably try to sync up w/ filepath's current master-tip for the
upcoming freeze to make sure it still builds. And then shortly before
the first GHC 7.10.1 RC is cut sometime around mid-december (if nothing
changes).

> Who will do the sync? 

It'll be probably me, or Austin

> When is the last time I can make changes that go into GHC 7.10?

*Ideally* we'd want to have the libraries in a frozen RC-ish state
before we cut the GHC 7.10.1 RC

> What should I be doing to help? As this is my first time, any details
> would be most appreciated.

If you can time it so that `filepath` is in a releasable state (i.e. you
don't need to actually upload it to Hackage) shortly before the first
RC, it'd be great. 

Then, if during the public GHC 7.10.1 RC test-phase serious issues with
the filepath package are found, it would very desirable for those to be
fixed upstream in `filepath` in a timely manner in order to ship the
final GHC 7.10.1 with a final bug-free `filepath` package.


...does that make any sense so far? :-)

Cheers,
  hvr

From ndmitchell at gmail.com  Fri Nov 21 18:46:37 2014
From: ndmitchell at gmail.com (Neil Mitchell)
Date: Fri, 21 Nov 2014 18:46:37 +0000
Subject: GHC filepath sync
In-Reply-To: <87mw7kxvyk.fsf@gnu.org>
References: <CAKcFpm+4ax0yKtxbAM1_89O5P+YUO1gxM8Ms5SCyHBaFVcD=6A@mail.gmail.com>
 <87mw7kxvyk.fsf@gnu.org>
Message-ID: <CAKcFpmJS3jJ-SOg16f7P-dbo8TPnFf6Z+=KZP=sNrkhS5POfEA@mail.gmail.com>

Thanks, that all sounds great.

I always keep it in a buildable state anyway, I'll do any changes in
the next couple of weeks (I don't have anything too major planned),
and if any issues come up after that I'll fix them quickly.

Thanks, Neil


On Fri, Nov 21, 2014 at 6:14 PM, Herbert Valerio Riedel
<hvriedel at gmail.com> wrote:
> On 2014-11-21 at 18:13:16 +0100, Neil Mitchell wrote:
>> As part of the forthcoming GHC release, I assume the filepath library
>> will be sync'd to the latest version in the GitHub repo? When will
>> that sync happen?
>
> We'll probably try to sync up w/ filepath's current master-tip for the
> upcoming freeze to make sure it still builds. And then shortly before
> the first GHC 7.10.1 RC is cut sometime around mid-december (if nothing
> changes).
>
>> Who will do the sync?
>
> It'll be probably me, or Austin
>
>> When is the last time I can make changes that go into GHC 7.10?
>
> *Ideally* we'd want to have the libraries in a frozen RC-ish state
> before we cut the GHC 7.10.1 RC
>
>> What should I be doing to help? As this is my first time, any details
>> would be most appreciated.
>
> If you can time it so that `filepath` is in a releasable state (i.e. you
> don't need to actually upload it to Hackage) shortly before the first
> RC, it'd be great.
>
> Then, if during the public GHC 7.10.1 RC test-phase serious issues with
> the filepath package are found, it would very desirable for those to be
> fixed upstream in `filepath` in a timely manner in order to ship the
> final GHC 7.10.1 with a final bug-free `filepath` package.
>
>
> ...does that make any sense so far? :-)
>
> Cheers,
>   hvr

From carter.schonwald at gmail.com  Fri Nov 21 19:20:53 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 21 Nov 2014 14:20:53 -0500
Subject: NOTE: The STABLE freeze is scheduled to occur TODAY.
In-Reply-To: <CAEs96n397St05bhyW0QvkWdEsri2BVKCvY9Y_Jse6gzBYVw+Hg@mail.gmail.com>
References: <CAEs96n397St05bhyW0QvkWdEsri2BVKCvY9Y_Jse6gzBYVw+Hg@mail.gmail.com>
Message-ID: <CAHYVw0yp+ZG6tBhXU+sbRNJZ7+F=yEnphaOYgVn-m9agZ-6X-Q@mail.gmail.com>

I'll be getting the storable  ratio and complex patches onto phab later
today.

May also want to discuss the prefetch api later, but I'll bring that up on
irc/ on the mailing list
On Nov 21, 2014 10:57 AM, "Austin Seipp" <austin at well-typed.com> wrote:

> Hi friends,
>
> Today, I'm planning on trying to cut a new `ghc-7.10` branch for the
> stable freeze. That means I'm going to spend a lot of time merging
> patches and other things with several other developers because
> everything is crazy and so many things wow.
>
> If you have things you want me to review, then please:
>
>   - Talk to me on IRC, #ghc on Freenode (I am 'thoughtpolice')
>   - Ping me on some medium like Skype (search for me). We can schedule
> a chat for a short time to figure things out.
>   - I can also do something like G+ or whatnot.
>   - I will of course be reading my email.
>
> Please note I would actually prefer to stay *away* from email I think,
> since it's a larger context switch for me, but I'll actively check it
> still just in case you want something and need to explain it.
>
> I'll likely be doing this most of the day, so let me know what happens.
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141121/9ae8f20a/attachment.html>

From d at davidterei.com  Fri Nov 21 19:29:05 2014
From: d at davidterei.com (David Terei)
Date: Fri, 21 Nov 2014 11:29:05 -0800
Subject: Windows breakage
In-Reply-To: <CAEs96n25CAAJjBXAPc06+0iaY8f6A6dVwD9ZkM+C9DjPLCFFZQ@mail.gmail.com>
References: <618BE556AADD624C9C918AA5D5911BEF3F3C0121@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAJumaK_WpaC-UZOHBi5gffFTtSAGm0rHY=b_eimLMtEoM-er5A@mail.gmail.com>
 <CAEs96n25CAAJjBXAPc06+0iaY8f6A6dVwD9ZkM+C9DjPLCFFZQ@mail.gmail.com>
Message-ID: <CACHt1w_adqtLAA2JyYCfiPZyGVGMz4VSpr5OowS6vM06PfDxvw@mail.gmail.com>

I'll spin up a windows VM to fix this. Although, do we have any better
approaches these days? Are there Travis machines I can push to or
anything that will validate on windows?

Simon, I suspect there is a stage ordering issue here, that ghc-stage0
has a time library that isn't safe, but stage-1's time library is
safe. That, or I've got a bug in safe-inferring.

Cheers,
David

On 14 November 2014 09:59, Austin Seipp <austin at well-typed.com> wrote:
> I've reverted the change in the mean time:
> 452d6aa95b754a08e1e61800680ccbf6f968aef0 - this doesn't revert the
> actual code, just the addition of the new flag to -Wall.
>
> This way, at least ./validate isn't broken for Windows in the mean time.
>
> On Fri, Nov 14, 2014 at 11:56 AM, Edward Kmett <ekmett at gmail.com> wrote:
>> David recently added a new -Wall flag for Trustworthiness.
>>
>> The reasoning is if it is in -Wall, it can actually get seen and will be
>> used by folks to improve more things from 'Trustworthy' to 'Safe'. After
>> all, everything that is merely `Trustworthy` needs to live in the trusted
>> computing base.
>>
>> The status quo is that you pretty much have no way to know what you _don't_
>> need Trustworthy on, and efforts in the past to take large libraries and
>> convert them to SafeHaskell have been fraught with long rebuild cycles,
>> because the only way to see was to build, haddock, and look.
>>
>> What you are running when you go to _fix_ the error appears to be an actual
>> bug in the safety inference code, though, and definitely needs to be looked
>> at.
>>
>> It probably does belong in -Wall in the long term, and -Werror is
>> notoriously fickle, but we should look at what is causing it to go wrong
>> here and do a bit more due diligence.
>>
>> -Edward
>>
>>
>> On Fri, Nov 14, 2014 at 12:40 PM, Simon Peyton Jones <simonpj at microsoft.com>
>> wrote:
>>>
>>> Hmm.  When I got this
>>>
>>> libraries\hpc\Trace\Hpc\Mix.hs:3:14: Warning:
>>>
>>>     ?Trace.Hpc.Mix? is marked as Trustworthy but has been inferred as
>>> safe!
>>>
>>> I changed ?Trustworthy? to ?Safe?.  But then I got
>>>
>>> libraries\hpc\Trace\Hpc\Mix.hs:24:1:
>>>
>>>     Data.Time: Can't be safely imported! The module itself isn't safe.
>>>
>>> This seems unhelpful. After all it?s been ?inferred as safe?.  What should
>>> I do?
>>>
>>> Thanks.
>>>
>>> Simon
>>>
>>> From: Simon Peyton Jones
>>> Sent: 14 November 2014 16:51
>>> To: ghc-devs at haskell.org
>>> Subject: Windows breakage
>>>
>>>
>>>
>>> This breakage didn?t use to happen.   Might someone fix it?  Thanks.  For
>>> now I?m going through changing a dozen ?Trustworthy? to ?Safe?.  Is that
>>> right?
>>>
>>> Simon
>>>
>>> librariesWin32SystemWin32Console.hsc:2:14: Warning:
>>>
>>>     ?System.Win32.Console? is marked as Trustworthy but has been inferred
>>> as safe!
>>>
>>>
>>>
>>> <no location info>:
>>>
>>> Failing due to -Werror.
>>>
>>> libraries/Win32/ghc.mk:4: recipe for target
>>> 'libraries/Win32/dist-install/build/System/Win32/Console.o' failed
>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>

From hvr at gnu.org  Fri Nov 21 21:30:16 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Fri, 21 Nov 2014 22:30:16 +0100
Subject: [commit: ghc] master: Be consistent with placement of Safe
 Haskell mode at top of file (2a523eb)
In-Reply-To: <20141121210323.ACD743A300@ghc.haskell.org> (git-4Dsf34iY's
 message of "Fri, 21 Nov 2014 21:03:23 +0000 (UTC)")
References: <20141121210323.ACD743A300@ghc.haskell.org>
Message-ID: <87ioi8xmvr.fsf@gnu.org>

Hello David,

On 2014-11-21 at 22:03:23 +0100, git-4Dsf34iY/NkouOHNgZ69ag at public.gmane.org wrote:

[...]

> commit 2a523ebf091478aea39deef28073320bed628434
> Author: David Terei <code-A0igW9AEfH2M2ScGVVA7yQ at public.gmane.org>
> Date:   Wed Nov 19 18:29:51 2014 -0800
>
>     Be consistent with placement of Safe Haskell mode at top of file

Why is that necessary?

Fwiw, I'm afraid that's gonna be hard to retain; it's more
obvious/easier to keep all LANGUAGE pragmas in alphabetic order (I've
probably done that a couple of times in `base` deliberately myself) than
to introduce such an artificial ordering on the language pragmas.

The reason is, you can instruct an editor to select the first paragraph
which comprises the block of one-per-line language-pragmas is, and have
it sorted it alphabetically. That's just a few keystrokes. But it's
rather difficult to teach the editor to use an ordering relation other
than the usual alphabetic/lexicographic ordering.

Cheers,
  hvr

From d at davidterei.com  Fri Nov 21 21:37:24 2014
From: d at davidterei.com (David Terei)
Date: Fri, 21 Nov 2014 13:37:24 -0800
Subject: [commit: ghc] master: Be consistent with placement of Safe
 Haskell mode at top of file (2a523eb)
In-Reply-To: <87ioi8xmvr.fsf@gnu.org>
References: <20141121210323.ACD743A300@ghc.haskell.org>
 <87ioi8xmvr.fsf@gnu.org>
Message-ID: <CACHt1w_oi5qrqUObAE1MBSmJ4wtk8Fh+5sv=RqLssYWfyp09bw@mail.gmail.com>

Necessary is a strong statement, it's obviously not as it's style.

I personally think it's better to have Safe Haskell pragmas at the top
as they aren't like other pragmas, they don't just turn something on
but make a hard statement about the module in question. As such it
seems better to me to keep them at the top to retain this distinction
from other pragmas.

If you feel or others a different style is better, that's fine. There
isn't any consistent style with pragmas so I introduced one. If
considering my argument above you prefer alphabetical then feel free
to revert the patch. It would be nice if we had a consistent style
though with pragmas. I don't care strongly what it is, just that it
exists.

Cheers,
David

On 21 November 2014 13:30, Herbert Valerio Riedel <hvr at gnu.org> wrote:
> Hello David,
>
> On 2014-11-21 at 22:03:23 +0100, git-4Dsf34iY/NkouOHNgZ69ag at public.gmane.org wrote:
>
> [...]
>
>> commit 2a523ebf091478aea39deef28073320bed628434
>> Author: David Terei <code-A0igW9AEfH2M2ScGVVA7yQ at public.gmane.org>
>> Date:   Wed Nov 19 18:29:51 2014 -0800
>>
>>     Be consistent with placement of Safe Haskell mode at top of file
>
> Why is that necessary?
>
> Fwiw, I'm afraid that's gonna be hard to retain; it's more
> obvious/easier to keep all LANGUAGE pragmas in alphabetic order (I've
> probably done that a couple of times in `base` deliberately myself) than
> to introduce such an artificial ordering on the language pragmas.
>
> The reason is, you can instruct an editor to select the first paragraph
> which comprises the block of one-per-line language-pragmas is, and have
> it sorted it alphabetically. That's just a few keystrokes. But it's
> rather difficult to teach the editor to use an ordering relation other
> than the usual alphabetic/lexicographic ordering.
>
> Cheers,
>   hvr
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

From simonpj at microsoft.com  Fri Nov 21 22:04:16 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 21 Nov 2014 22:04:16 +0000
Subject: [commit: ghc] master: Add T7220a.stderr (6265f1c)
In-Reply-To: <20141121205542.0C1743A300@ghc.haskell.org>
References: <20141121205542.0C1743A300@ghc.haskell.org>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3DBA27@DB3PRD3001MB020.064d.mgd.msft.net>

Thanks Joachim.

Simon

| -----Original Message-----
| From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of
| git at git.haskell.org
| Sent: 21 November 2014 20:56
| To: ghc-commits at haskell.org
| Subject: [commit: ghc] master: Add T7220a.stderr (6265f1c)
| 
| Repository : ssh://git at git.haskell.org/ghc
| 
| On branch  : master
| Link       :
| http://ghc.haskell.org/trac/ghc/changeset/6265f1c3162a192220ec03d888e1c1e
| f686b2732/ghc
| 
| >---------------------------------------------------------------
| 
| commit 6265f1c3162a192220ec03d888e1c1ef686b2732
| Author: Joachim Breitner <mail at joachim-breitner.de>
| Date:   Fri Nov 21 21:55:37 2014 +0100
| 
|     Add T7220a.stderr
| 
|     which presumably was just forgotten when creating the testcase in
|     commit 7b1a856.
| 
| 
| >---------------------------------------------------------------
| 
| 6265f1c3162a192220ec03d888e1c1ef686b2732
|  testsuite/tests/typecheck/should_compile/T7220a.stderr | 14
| ++++++++++++++
|  1 file changed, 14 insertions(+)
| 
| diff --git a/testsuite/tests/typecheck/should_compile/T7220a.stderr
| b/testsuite/tests/typecheck/should_compile/T7220a.stderr
| new file mode 100644
| index 0000000..4be503d
| --- /dev/null
| +++ b/testsuite/tests/typecheck/should_compile/T7220a.stderr
| @@ -0,0 +1,14 @@
| +
| +T7220a.hs:17:6:
| +    Could not deduce (C a b)
| +    from the context (C a0 b, TF b ~ Y)
| +      bound by the type signature for f :: (C a0 b, TF b ~ Y) => b
| +      at T7220a.hs:17:6-44
| +    Possible fix:
| +      add (C a b) to the context of
| +        the type signature for f :: (C a0 b, TF b ~ Y) => b
| +    In the ambiguity check for the type signature for ?f?:
| +      f :: forall a. (forall b. (C a b, TF b ~ Y) => b) -> X
| +    To defer the ambiguity check to use sites, enable
| AllowAmbiguousTypes
| +    In the type signature for ?f?:
| +      f :: (forall b. (C a b, TF b ~ Y) => b) -> X
| 
| _______________________________________________
| ghc-commits mailing list
| ghc-commits at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-commits

From austin at well-typed.com  Sat Nov 22 00:37:39 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 21 Nov 2014 18:37:39 -0600
Subject: GHC Weekly News - 2014/11/21
Message-ID: <CAEs96n0PoqJbO5t=+Wjf=+SthpmDFed1M_7DsT=e-fvf8qojLQ@mail.gmail.com>

Hi *,

To get things back on track, we have a short post following up the
earlier one this week. It's been busy today so I'll keep it short:

  - The STABLE freeze Austin announced two weeks ago is happening now,
although at this point a few things we wanted to ship are just 98%
ready. So it may wait until Monday.

  - HEAD has been very busy the past two days as many things are now
trying to merge as closely to the window as possible. Some notes
follow.

  - Gergo Erdi merged the implementation of pattern synonym type
signatures: https://www.haskell.org/pipermail/ghc-devs/2014-November/007369.html

  - HEAD now has support for using the 'deriving' clause for arbitrary
classes (see #5462).

  - HEAD now has a new flag `-fwarn-missing-exported-sigs`, which
fixes #2526. See https://phabricator.haskell.org/D482

  - HEAD now has 64bit iOS and SMP support for ARM64, thanks to Luke
Iannini. See #7942.

  - HEAD no longer ships `haskell98`, `haskell2010`, `old-locale` or
`old-time`, per our decision to drop support for `haskell98` and
`haskell2010`. GHC 7.10 compatible releases of `old-locale` and
`old-time` have been released on hackage. See
https://www.haskell.org/pipermail/ghc-devs/2014-November/007357.html
and https://www.haskell.org/pipermail/ghc-devs/2014-November/007383.html

  - `base` now exports a new module for Natural numbers called
`Numeric.Natural` following Herbert Valerio Riedel's recent proposal.

  - HEAD should finally be compatible with LLVM 3.5, AKA #9142. The
patch from Ben Gamari is at https://phabricator.haskell.org/D155

  - Your author has been busy and delayed due to some bad travel
experiences the past week, so the 7.8.4 RC1 hasn't landed this past
week. Hopefully it will be out by the end of this week still.

Since the last update was only a few days ago, you'd think we haven't
closed a lot of tickets, but we have! Thomas Miedema has been very
very persistent about closing tickets and cleaning them up, which is
greatly appreciated: #9810, #8324, #8310, #9396, #9626, #9776, #9807,
#9698, #7942, #9703, #8584, #8968, #8174, #9812, #9209, #9220, #9151,
#9201, #9318, #9109, #9126, #8406, #8102, #8093, #8085, #8068, #8094,
#9590, #9368, #2526, #9569, #8149, #9815, #5462, #9647, #8568, #9293,
#7484, #1476, #9824, #9628, #7942

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From carter.schonwald at gmail.com  Sat Nov 22 05:43:34 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 22 Nov 2014 00:43:34 -0500
Subject: help wrt semantics / primops for pure prefetches
Message-ID: <CAHYVw0x=ouGBv0x=d-Rz7X0ZmxE+55obCwUjyWPwjWuEvoeo4g@mail.gmail.com>

Hey Everyone,
in
https://ghc.haskell.org/trac/ghc/ticket/9353
and
https://phabricator.haskell.org/D350

is some preliminary work to fix up how the pure versions of the prefetch
primops work is laid out and prototyped.

However, while it nominally fixes up some of the problems with how the
current pure prefetch apis are fundamentally borken,  the simple design in
D350 isn't quite ideal, and i sketch out some other ideas in the associated
ticket #9353

I'd like to make sure  pure prefetch in 7.10 is slightly less broken than
in 7.8, but either way, its pretty clear that working out the right fixed
up design wont happen till 7.12. Ie, whatever makes 7.10, there WILL have
to be breaking changes to fix those primops for 7.12

thanks and any feedback / thoughts appreciated
-Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141122/246f72cb/attachment.html>

From mail at joachim-breitner.de  Sat Nov 22 10:35:15 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 22 Nov 2014 11:35:15 +0100
Subject: Failing tests: literals T5681 annotations
Message-ID: <1416652515.1406.1.camel@joachim-breitner.de>

Hi,

the CI weather is bad these days. Maybe a broken-window-effect?

I currently observe

Unexpected results from:
TEST="literals T5681 annotations"


Details:

Compile failed (status 256) errors were:
/tmp/ghc13786_0/ghc13786_5.s: Assembler messages:

/tmp/ghc13786_0/ghc13786_5.s:26:0:
     Error: can't resolve `.rodata' {.rodata section} - `Main_zdwwork_info$def' {.text section}

/tmp/ghc13786_0/ghc13786_5.s:46:0:
     Error: can't resolve `.rodata' {.rodata section} - `Main_work_info$def' {.text section}

/tmp/ghc13786_0/ghc13786_5.s:66:0:
     Error: can't resolve `.rodata' {.rodata section} - `Main_main1_info$def' {.text section}

/tmp/ghc13786_0/ghc13786_5.s:86:0:
     Error: can't resolve `.rodata' {.rodata section} - `Main_main_info$def' {.text section}

/tmp/ghc13786_0/ghc13786_5.s:106:0:
     Error: can't resolve `.rodata' {.rodata section} - `Main_main2_info$def' {.text section}

/tmp/ghc13786_0/ghc13786_5.s:126:0:
     Error: can't resolve `.rodata' {.rodata section} - `ZCMain_main_info$def' {.text section}

*** unexpected failure for T5681(optllvm)
=====> T8131(optllvm) 1496 of 4230 [0, 1, 0] 

Wrong exit code (expected 0 , actual 2 )
Stdout:

Stderr:
/usr/bin/ld: reopening annotations.o: No such file or directory

/usr/bin/ld:annotations.o: bfd_stat failed: No such file or directory
/usr/bin/ld: reopening annotations.o: No such file or directory

/usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.22 internal error, aborting at ../../bfd/merge.c line 873 in _bfd_merged_section_offset

/usr/bin/ld: Please report this bug.

collect2: ld returned 1 exit status
make[3]: *** [annotations] Error 1

*** unexpected failure for annotations(normal)

Wrong exit code (expected 0 , actual 2 )
Stdout:

Stderr:
/usr/bin/ld: reopening literals.o: No such file or directory

/usr/bin/ld:literals.o: bfd_stat failed: No such file or directory
/usr/bin/ld: reopening literals.o: No such file or directory

/usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.22 internal error, aborting at ../../bfd/merge.c line 873 in _bfd_merged_section_offset

/usr/bin/ld: Please report this bug.

collect2: ld returned 1 exit status
make[3]: *** [literals] Error 1

*** unexpected failure for literals(normal)


Does anyone feel responsible?

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141122/c94d268d/attachment.sig>

From alan.zimm at gmail.com  Sat Nov 22 13:58:20 2014
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Sat, 22 Nov 2014 15:58:20 +0200
Subject: Diff grouping question
Message-ID: <CANma=H8jAPujUWaOWaV7sseVtbdP+iXGmYU+U0_SOtgH8WpUgA@mail.gmail.com>

I am picking up some minor updates required for the API annotations,
relating to documentation inaccuracies, and some missing annotations
needing to be captured in the parser.

Should these go into separate Phab diffs, or can I just put them all in one?

Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141122/af757470/attachment.html>

From carter.schonwald at gmail.com  Sun Nov 23 04:33:38 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 22 Nov 2014 23:33:38 -0500
Subject: ghc HEAD can't validate with xcode 6 clang on OS X
Message-ID: <CAHYVw0y0D0iGq9c=N-n6v9_xadMnuvX5c94qx0rBFu1vY-EwTA@mail.gmail.com>

Hey all,

on OS X 10.9
if i do
git clone --recursive git://git.haskell.org/ghc.git ghc-valifail
cd ghc-valifail
perl boot
./configure --with-gcc=clang # the with gcc bit isnt needed, but making it
clearly pick up clang is the point
./validate --fast


then within a minute or two i get

error: unknown warning option '-Werror=unused-but-set-variable'; did you
mean '-Werror=unused-const-variable'?
      [-Werror,-Wunknown-warning-option]


which makes me think that the clang warning flags have changed in that
release (which corresponds with clang Apple LLVM version 6.0
(clang-600.0.54) (based on LLVM 3.5svn)). SO maybe clang 3.5 / 3.6 will
also fail when used in validate builds?



s/hpc/dist-boot/build/autogen/cabal_macros.h
libraries/hpc/./Trace/Hpc/Reflect.hsc -o
libraries/hpc/dist-boot/build/Trace/Hpc/Reflect.hs
error: unknown warning option '-Werror=unused-but-set-variable'; did you
mean '-Werror=unused-const-variable'?
      [-Werror,-Wunknown-warning-option]
compiling compiler/stage1/build/Fingerprint_hsc_make.c failed (exit code 1)
command was: clang -c compiler/stage1/build/Fingerprint_hsc_make.c -o
compiler/stage1/build/Fingerprint_hsc_make.o -Werror -Wall -m64
-fno-stack-protector -m64 -Dx86_64_HOST_ARCH=1 -Ddarwin_HOST_OS=1
-D__GLASGOW_HASKELL__=708 -m64 -fno-stack-protector -error: unknown warning
option '-Werror=unused-but-set-variable'; did you mean
'-Werror=unused-const-variable'?
      [-Werror,-Wunknown-warning-option]
Werror -Wall -Icompiler/. -Icompiler/parser -Icompiler/utils
-Icompiler/stage1 -isystem/usr/local/lib/ghc-7.8.3/process-1.2.0.0/include
-isystem/usr/local/lib/ghc-7.8.3/directory-1.2.1.0/include
-isystem/usr/local/lib/ghc-7.8.3/unix-2.7.0.1/include
-isystem/usr/local/lib/ghc-7.8.3/time-1.4.2/include
-isystem/usr/loccalo/mlpiibl/ignhgc
-l7i.b8r.a3r/ibeyst/ehsptc/dist-boot/build/Trace/Hpc/Reflect_hsc_make.c
fring-0.10.4.0/include -isystemailed (exit c/usr/local/liode 1)
commab/ghc-7.8.3/band was: clanse-4.7.0.1/ing -c librariclude
-isystees/hpc/dist-m/usr/localboot/build/T/lib/ghc-7.8race/Hpc/Ref.3/inlteecgte_rh-sgcm_pm-a0k.e5.1.0/include
-isys.c -o
libraries/hpc/dist-boott/bueiml/du/sTrr/acel/Hopcca/l/lib/ghc-7.8.3/include
-Werror=unused-but-sReet-variabflel e-Wcnto_-hesrcr_omra=kien.loi n-eW
e-rIrcoorm p-iWlaelrl/ s-tma6g4e 1-/fbnuoi-lsdt/aacukt-opgreont e-citnocrl
u-dme6 4c o-mDpxi8l6e_r6/4s_tHaOgSeT1_/AbRuCiHl=d1/
a-uDtdoagrewni/nc_aHbOaSlT__mOaSc=r1o s-.Dh_
_-GIL/AUSsGeOrWs_/HcAaSrKtEeLrL/_D_e=s7k0t8o p-/mr6e4p
o-Sfcnor-asttcahcekr-/pgrhoct-evcatloirf a-iWle/rirnoprl a-cWea/llli
b-/Iilnicblrudaer/i
es/hpc/. -isystem/usr/local/lib/ghc-7.8.3/directory-1.2.1.0/include
-isystem/usr/local/lib/ghc-7.8.3/unix-2.7.0.1/include
-isystem/usr/local/lib/ghc-7.8.3/time-1.4.2/include
-isystem/usr/local/lib/ghc-7.8.3/bytestring-0.10.4.0/include
-isystem/usr/local/lib/ghc-7.8.3/base-4.7.0.1/include
-isystem/usr/local/lib/ghc-7.8.3/integer-gmp-0.5.1.0/include
-isystem/usr/local/lib/ghc-7.8.3/include -Werror=unused-but-set-variable
-Wno-error=inline -Ilibraries/hpc/dist-boot/build/autogen -include
libraries/hpc/dist-boot/build/amake[1]: ***
[compiler/stage1/build/Fingerprint.hs] Error 1
make[1]: *** Waiting for unfinished jobs....
utogen/cabal_macros.h
-I/Users/carter/Desktop/repoScratcher/ghc-valifail/inplace/lib/include/
make[1]: *** [libraries/hpc/dist-boot/build/Trace/Hpc/Reflect.hs] Error 1
make: *** [all] Error 2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141122/adeea093/attachment.html>

From merijn at inconsistent.nl  Sun Nov 23 05:50:21 2014
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Sat, 22 Nov 2014 21:50:21 -0800
Subject: OS X breakage: make -j and 4 unexpected failures
Message-ID: <C5F18371-DA31-4890-B564-FDB6F7F013A1@inconsistent.nl>

Carter was having difficulty compiling on OS X 10.9 with Xcode 6.0, so I tried building head and ran into some issues.

1) I used to build using make -j, but this fails with cryptic errors now. ./validate (which uses -j) and "make" seem to work. The specific error (appearing somewhere during stage 2 build) is:

Couldn't figure out C compiler information!
Warning:             Make sure you're using GNU gcc, or clang

Furthermore, when trying to run ./validate --fast I run into 4 unexpected failures. If anyone can tell me how I can get the test suite to report the exact difference in output I will send those along.

Unexpected results from:
TEST="cabal01 T5435_dyn_asm subsections_via_symbols cabal06 T4801"

OVERALL SUMMARY for test run started at Sat Nov 22 21:35:31 2014 PST
 0:07:30 spent to go through
    4230 total tests, which gave rise to
   13843 test cases, of which
    9956 were skipped

      53 had missing libraries
    3763 expected passes
      66 expected failures

       0 caused framework failures
       0 unexpected passes
       4 unexpected failures
       1 unexpected stat failures

Unexpected failures:
   cabal/cabal01                            cabal01 [bad exit code] (normal)
   cabal/cabal06                            cabal06 [bad stdout] (normal)
   llvm/should_run/subsections_via_symbols  subsections_via_symbols [bad exit code] (normal)
   rts                                      T5435_dyn_asm [bad stdout] (normal)

Unexpected stat failures:
   perf/compiler  T4801 [stat too good] (normal)

Cheers,
Merijn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141122/33dcc4f2/attachment.sig>

From carter.schonwald at gmail.com  Sun Nov 23 06:42:49 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 23 Nov 2014 01:42:49 -0500
Subject: help wrt semantics / primops for pure prefetches
In-Reply-To: <CAHYVw0x=ouGBv0x=d-Rz7X0ZmxE+55obCwUjyWPwjWuEvoeo4g@mail.gmail.com>
References: <CAHYVw0x=ouGBv0x=d-Rz7X0ZmxE+55obCwUjyWPwjWuEvoeo4g@mail.gmail.com>
Message-ID: <CAHYVw0zMVF1wL8QPZTQGE2aYAA-ZbpD5+SB03k6XZcQ0hqJUdA@mail.gmail.com>

I've gotten some feedback and suggestions on IRC from Edwardk,
i'm currently massaging the new  (useful!) form through validate,
feedback on https://phabricator.haskell.org/D350 would be appreciated!

On Sat, Nov 22, 2014 at 12:43 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> Hey Everyone,
> in
> https://ghc.haskell.org/trac/ghc/ticket/9353
> and
> https://phabricator.haskell.org/D350
>
> is some preliminary work to fix up how the pure versions of the prefetch
> primops work is laid out and prototyped.
>
> However, while it nominally fixes up some of the problems with how the
> current pure prefetch apis are fundamentally borken,  the simple design in
> D350 isn't quite ideal, and i sketch out some other ideas in the associated
> ticket #9353
>
> I'd like to make sure  pure prefetch in 7.10 is slightly less broken than
> in 7.8, but either way, its pretty clear that working out the right fixed
> up design wont happen till 7.12. Ie, whatever makes 7.10, there WILL have
> to be breaking changes to fix those primops for 7.12
>
> thanks and any feedback / thoughts appreciated
> -Carter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141123/50331e9d/attachment.html>

From thomasmiedema at gmail.com  Sun Nov 23 14:11:46 2014
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Sun, 23 Nov 2014 15:11:46 +0100
Subject: OS X breakage: make -j and 4 unexpected failures
In-Reply-To: <C5F18371-DA31-4890-B564-FDB6F7F013A1@inconsistent.nl>
References: <C5F18371-DA31-4890-B564-FDB6F7F013A1@inconsistent.nl>
Message-ID: <CAD3WKgg=6ru1GmHv+RQoEWPg_T3Li-5jRe=fZGazV98=4ciObg@mail.gmail.com>

>
> Unexpected failures:
>    cabal/cabal01                            cabal01 [bad exit code]
> (normal)
>    cabal/cabal06                            cabal06 [bad stdout] (normal)
>    llvm/should_run/subsections_via_symbols  subsections_via_symbols [bad
> exit code] (normal)
>    rts                                      T5435_dyn_asm [bad stdout]
> (normal)
>
> Unexpected stat failures:
>    perf/compiler  T4801 [stat too good] (normal)
>

Some are new, some have been reported before by Trac user 'jrp'. Please add
your results to this ticket: https://ghc.haskell.org/trac/ghc/ticket/9389
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141123/02c54e20/attachment.html>

From dreixel at gmail.com  Sun Nov 23 17:30:30 2014
From: dreixel at gmail.com (=?UTF-8?Q?Jos=C3=A9_Pedro_Magalh=C3=A3es?=)
Date: Sun, 23 Nov 2014 18:30:30 +0100
Subject: NOTE: The STABLE freeze is scheduled to occur TODAY.
In-Reply-To: <CAEs96n397St05bhyW0QvkWdEsri2BVKCvY9Y_Jse6gzBYVw+Hg@mail.gmail.com>
References: <CAEs96n397St05bhyW0QvkWdEsri2BVKCvY9Y_Jse6gzBYVw+Hg@mail.gmail.com>
Message-ID: <CA+ZFbn_5bDMnAYWwJ+yTpd7hZy8fHhuk1_YzNY5gZGpZ2Pn1Vg@mail.gmail.com>

Hello Austin,

Any change D493 <https://phabricator.haskell.org/D493> can be merged too?


Thanks,
Pedro


On Fri, Nov 21, 2014 at 4:57 PM, Austin Seipp <austin at well-typed.com> wrote:

> Hi friends,
>
> Today, I'm planning on trying to cut a new `ghc-7.10` branch for the
> stable freeze. That means I'm going to spend a lot of time merging
> patches and other things with several other developers because
> everything is crazy and so many things wow.
>
> If you have things you want me to review, then please:
>
>   - Talk to me on IRC, #ghc on Freenode (I am 'thoughtpolice')
>   - Ping me on some medium like Skype (search for me). We can schedule
> a chat for a short time to figure things out.
>   - I can also do something like G+ or whatnot.
>   - I will of course be reading my email.
>
> Please note I would actually prefer to stay *away* from email I think,
> since it's a larger context switch for me, but I'll actively check it
> still just in case you want something and need to explain it.
>
> I'll likely be doing this most of the day, so let me know what happens.
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141123/b7cd5ad8/attachment.html>

From carter.schonwald at gmail.com  Sun Nov 23 19:04:13 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 23 Nov 2014 14:04:13 -0500
Subject: how to write a ghc primop that acts on an unevaluated argument?
Message-ID: <CAHYVw0xX5zrD-BPTcQLViN8usJCzqSg_T=G-bcWE4=ZD5R6DBQ@mail.gmail.com>

Hey All,
as part of trying to get some fixups for how prefetch works into 7.10,
i'm adding a "prefetchValue" primop that prefetchs the memory location of a
lifted heap value

namely

several operations of the following form

primop PrefetchValueOp1 "prefetchValue1#" GenPrimOp
   a -> State# s -> State# s
   with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd]
topRes }

I'd like some feedback on the strictness information design by someone
who's familiar with how that piece of GHC. the idea being that
prefetchValue is lazy in its polymorphic argument (it doesn't force it, it
just does a prefetch on the heap location, which may or may not be
evaluated).

https://phabricator.haskell.org/D350

is the code in question. And i *believe* i'm testing for being lazy in that
argument correctly.

thoughts?

many thanks!
-Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141123/8fd61215/attachment.html>

From carter.schonwald at gmail.com  Sun Nov 23 19:29:32 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 23 Nov 2014 14:29:32 -0500
Subject: NOTE: The STABLE freeze is scheduled to occur TODAY.
In-Reply-To: <CAHYVw0yp+ZG6tBhXU+sbRNJZ7+F=yEnphaOYgVn-m9agZ-6X-Q@mail.gmail.com>
References: <CAEs96n397St05bhyW0QvkWdEsri2BVKCvY9Y_Jse6gzBYVw+Hg@mail.gmail.com>
 <CAHYVw0yp+ZG6tBhXU+sbRNJZ7+F=yEnphaOYgVn-m9agZ-6X-Q@mail.gmail.com>
Message-ID: <CAHYVw0yhUVjgNZ0cxkto5Uvo=rvfWF_6xtLmqQZu-ts2ZmZjHw@mail.gmail.com>

ok, i have D350 and D519 validated and in progress of getting reviews

On Fri, Nov 21, 2014 at 2:20 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> I'll be getting the storable  ratio and complex patches onto phab later
> today.
>
> May also want to discuss the prefetch api later, but I'll bring that up on
> irc/ on the mailing list
> On Nov 21, 2014 10:57 AM, "Austin Seipp" <austin at well-typed.com> wrote:
>
>> Hi friends,
>>
>> Today, I'm planning on trying to cut a new `ghc-7.10` branch for the
>> stable freeze. That means I'm going to spend a lot of time merging
>> patches and other things with several other developers because
>> everything is crazy and so many things wow.
>>
>> If you have things you want me to review, then please:
>>
>>   - Talk to me on IRC, #ghc on Freenode (I am 'thoughtpolice')
>>   - Ping me on some medium like Skype (search for me). We can schedule
>> a chat for a short time to figure things out.
>>   - I can also do something like G+ or whatnot.
>>   - I will of course be reading my email.
>>
>> Please note I would actually prefer to stay *away* from email I think,
>> since it's a larger context switch for me, but I'll actively check it
>> still just in case you want something and need to explain it.
>>
>> I'll likely be doing this most of the day, so let me know what happens.
>>
>> --
>> Regards,
>>
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141123/dbe93f13/attachment.html>

From ekmett at gmail.com  Sun Nov 23 20:53:02 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 23 Nov 2014 15:53:02 -0500
Subject: how to write a ghc primop that acts on an unevaluated argument?
In-Reply-To: <CAHYVw0xX5zrD-BPTcQLViN8usJCzqSg_T=G-bcWE4=ZD5R6DBQ@mail.gmail.com>
References: <CAHYVw0xX5zrD-BPTcQLViN8usJCzqSg_T=G-bcWE4=ZD5R6DBQ@mail.gmail.com>
Message-ID: <CAJumaK_4Jde+guZH_=2a6k4KcW7P+ZJxuHeByoiycX9qAxjiXQ@mail.gmail.com>

Maybe test for laziness in the argument by just putting something in that
goes boom when forced, e.g. 'undefined'?


On Sun, Nov 23, 2014 at 2:04 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> Hey All,
> as part of trying to get some fixups for how prefetch works into 7.10,
> i'm adding a "prefetchValue" primop that prefetchs the memory location of
> a lifted heap value
>
> namely
>
> several operations of the following form
>
> primop PrefetchValueOp1 "prefetchValue1#" GenPrimOp
>    a -> State# s -> State# s
>    with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd]
> topRes }
>
> I'd like some feedback on the strictness information design by someone
> who's familiar with how that piece of GHC. the idea being that
> prefetchValue is lazy in its polymorphic argument (it doesn't force it, it
> just does a prefetch on the heap location, which may or may not be
> evaluated).
>
> https://phabricator.haskell.org/D350
>
> is the code in question. And i *believe* i'm testing for being lazy in
> that argument correctly.
>
> thoughts?
>
> many thanks!
> -Carter
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141123/68a6f914/attachment.html>

From carter.schonwald at gmail.com  Sun Nov 23 21:13:07 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 23 Nov 2014 16:13:07 -0500
Subject: how to write a ghc primop that acts on an unevaluated argument?
In-Reply-To: <CAJumaK_4Jde+guZH_=2a6k4KcW7P+ZJxuHeByoiycX9qAxjiXQ@mail.gmail.com>
References: <CAHYVw0xX5zrD-BPTcQLViN8usJCzqSg_T=G-bcWE4=ZD5R6DBQ@mail.gmail.com>
 <CAJumaK_4Jde+guZH_=2a6k4KcW7P+ZJxuHeByoiycX9qAxjiXQ@mail.gmail.com>
Message-ID: <CAHYVw0weMLeWGF7mJL8Q-_SPfQY91ecrTCiJaFj43eftQYTOHg@mail.gmail.com>

yup, i have that!

    wrapFetch prefetchValue0# (error "this shouldn't get evaluated")

in the test suite!

in contrast
    wrapFetch prefetchValue0# $! (error "this shouldn't get evaluated")
does explode

shall I add a "should fail" test with the latter? (it doesn't seem
worthwhile)

On Sun, Nov 23, 2014 at 3:53 PM, Edward Kmett <ekmett at gmail.com> wrote:

> Maybe test for laziness in the argument by just putting something in that
> goes boom when forced, e.g. 'undefined'?
>
>
> On Sun, Nov 23, 2014 at 2:04 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> Hey All,
>> as part of trying to get some fixups for how prefetch works into 7.10,
>> i'm adding a "prefetchValue" primop that prefetchs the memory location of
>> a lifted heap value
>>
>> namely
>>
>> several operations of the following form
>>
>> primop PrefetchValueOp1 "prefetchValue1#" GenPrimOp
>>    a -> State# s -> State# s
>>    with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd]
>> topRes }
>>
>> I'd like some feedback on the strictness information design by someone
>> who's familiar with how that piece of GHC. the idea being that
>> prefetchValue is lazy in its polymorphic argument (it doesn't force it, it
>> just does a prefetch on the heap location, which may or may not be
>> evaluated).
>>
>> https://phabricator.haskell.org/D350
>>
>> is the code in question. And i *believe* i'm testing for being lazy in
>> that argument correctly.
>>
>> thoughts?
>>
>> many thanks!
>> -Carter
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141123/15d0d631/attachment-0001.html>

From carter.schonwald at gmail.com  Sun Nov 23 21:26:32 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 23 Nov 2014 16:26:32 -0500
Subject: let app invariant failure, HALP Re: how to write a ghc primop that
 acts on an unevaluated argument?
Message-ID: <CAHYVw0yNm+2TRv=8v0ngqrLdSQycWgDQiYNay0F6ky6p-3gJUw@mail.gmail.com>

ok, i'm getting a let/app invariant failure when i build my test case with
O1 or O2 but not without

http://lpaste.net/114881

any help would be appreciated on how to address that

On Sun, Nov 23, 2014 at 4:13 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> yup, i have that!
>
>     wrapFetch prefetchValue0# (error "this shouldn't get evaluated")
>
> in the test suite!
>
> in contrast
>     wrapFetch prefetchValue0# $! (error "this shouldn't get evaluated")
> does explode
>
> shall I add a "should fail" test with the latter? (it doesn't seem
> worthwhile)
>
> On Sun, Nov 23, 2014 at 3:53 PM, Edward Kmett <ekmett at gmail.com> wrote:
>
>> Maybe test for laziness in the argument by just putting something in that
>> goes boom when forced, e.g. 'undefined'?
>>
>>
>> On Sun, Nov 23, 2014 at 2:04 PM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> Hey All,
>>> as part of trying to get some fixups for how prefetch works into 7.10,
>>> i'm adding a "prefetchValue" primop that prefetchs the memory location
>>> of a lifted heap value
>>>
>>> namely
>>>
>>> several operations of the following form
>>>
>>> primop PrefetchValueOp1 "prefetchValue1#" GenPrimOp
>>>    a -> State# s -> State# s
>>>    with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd]
>>> topRes }
>>>
>>> I'd like some feedback on the strictness information design by someone
>>> who's familiar with how that piece of GHC. the idea being that
>>> prefetchValue is lazy in its polymorphic argument (it doesn't force it, it
>>> just does a prefetch on the heap location, which may or may not be
>>> evaluated).
>>>
>>> https://phabricator.haskell.org/D350
>>>
>>> is the code in question. And i *believe* i'm testing for being lazy in
>>> that argument correctly.
>>>
>>> thoughts?
>>>
>>> many thanks!
>>> -Carter
>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141123/18d30211/attachment.html>

From carter.schonwald at gmail.com  Mon Nov 24 00:53:48 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 23 Nov 2014 19:53:48 -0500
Subject: let app invariant failure, HALP Re: how to write a ghc primop
 that acts on an unevaluated argument?
In-Reply-To: <CAHYVw0yNm+2TRv=8v0ngqrLdSQycWgDQiYNay0F6ky6p-3gJUw@mail.gmail.com>
References: <CAHYVw0yNm+2TRv=8v0ngqrLdSQycWgDQiYNay0F6ky6p-3gJUw@mail.gmail.com>
Message-ID: <CAHYVw0zHaW6R=txyZzoPWkNq8t2RDZ_rSg6N0PHzMHz=nnTGrw@mail.gmail.com>

woot, solved it, at least in a way thats OK for now.

if I mark the prefetchValue operations as has_side_effects=True, the core
lint failure goes away! I'm not sure if thats the right semantics in the
long term, but it does give me a simple way to make sure it works safely
for 7.10

pardon all the noise
-Carter

On Sun, Nov 23, 2014 at 4:26 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> ok, i'm getting a let/app invariant failure when i build my test case with
> O1 or O2 but not without
>
> http://lpaste.net/114881
>
> any help would be appreciated on how to address that
>
> On Sun, Nov 23, 2014 at 4:13 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> yup, i have that!
>>
>>     wrapFetch prefetchValue0# (error "this shouldn't get evaluated")
>>
>> in the test suite!
>>
>> in contrast
>>     wrapFetch prefetchValue0# $! (error "this shouldn't get evaluated")
>> does explode
>>
>> shall I add a "should fail" test with the latter? (it doesn't seem
>> worthwhile)
>>
>> On Sun, Nov 23, 2014 at 3:53 PM, Edward Kmett <ekmett at gmail.com> wrote:
>>
>>> Maybe test for laziness in the argument by just putting something in
>>> that goes boom when forced, e.g. 'undefined'?
>>>
>>>
>>> On Sun, Nov 23, 2014 at 2:04 PM, Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>> Hey All,
>>>> as part of trying to get some fixups for how prefetch works into 7.10,
>>>> i'm adding a "prefetchValue" primop that prefetchs the memory location
>>>> of a lifted heap value
>>>>
>>>> namely
>>>>
>>>> several operations of the following form
>>>>
>>>> primop PrefetchValueOp1 "prefetchValue1#" GenPrimOp
>>>>    a -> State# s -> State# s
>>>>    with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd]
>>>> topRes }
>>>>
>>>> I'd like some feedback on the strictness information design by someone
>>>> who's familiar with how that piece of GHC. the idea being that
>>>> prefetchValue is lazy in its polymorphic argument (it doesn't force it, it
>>>> just does a prefetch on the heap location, which may or may not be
>>>> evaluated).
>>>>
>>>> https://phabricator.haskell.org/D350
>>>>
>>>> is the code in question. And i *believe* i'm testing for being lazy in
>>>> that argument correctly.
>>>>
>>>> thoughts?
>>>>
>>>> many thanks!
>>>> -Carter
>>>>
>>>>
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141123/1df45782/attachment.html>

From marlowsd at gmail.com  Mon Nov 24 10:09:44 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 24 Nov 2014 10:09:44 +0000
Subject: mask in waitQSem
In-Reply-To: <1416000184.2762.1.camel@gmail.com>
References: <1416000184.2762.1.camel@gmail.com>
Message-ID: <547303E8.5040603@gmail.com>

On 14/11/2014 21:23, Yuras Shumovich wrote:
>
> I was reviewing some exception handling code in base library, and I
> found this line:
> https://phabricator.haskell.org/diffusion/GHC/browse/master/libraries/base/Control/Concurrent/QSem.hs;165072b334ebb2ccbef38a963ac4d126f1e08c96$74
>
> Here mask is used, but I looks completely useless for me. waitQSem
> itself should be called with async exceptions masked, otherwise there is
> no way to prevent resource leak.
>
> Do anyone know why mask is used here?

I wrote that code.  It looks like mask_ is important, otherwise an async 
exception might leave the MVar empty, no?  We can't assume that waitQSem 
is always called inside a mask_, so it does its own mask_.

Cheers,
Simon


> I wonder whether an author of the code tried to do something different,
> so there actually can be a bug hidden here. Probably
> uninterruptibleMask_ should be used here? (I don't think so though.)
>
> Thanks,
> Yuras
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From marlowsd at gmail.com  Mon Nov 24 10:12:13 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 24 Nov 2014 10:12:13 +0000
Subject: mask in waitQSem
In-Reply-To: <CAKFCL4UmwQ=Jiefa6660ERWgHzMyD35Vy+CJpe0wz_70Z53j4w@mail.gmail.com>
References: <1416000184.2762.1.camel@gmail.com>
 <CAKFCL4UmwQ=Jiefa6660ERWgHzMyD35Vy+CJpe0wz_70Z53j4w@mail.gmail.com>
Message-ID: <5473047D.4000707@gmail.com>

On 14/11/2014 21:30, Brandon Allbery wrote:
> On Fri, Nov 14, 2014 at 4:23 PM, Yuras Shumovich <shumovichy at gmail.com
> <mailto:shumovichy at gmail.com>> wrote:
>
>     Here mask is used, but I looks completely useless for me. waitQSem
>     itself should be called with async exceptions masked, otherwise there is
>     no way to prevent resource leak.
>
>     Do anyone know why mask is used here?
>
>
> I thought QSem was known to be completely unsafe and
> http://hackage.haskell.org/package/SafeSemaphore was recommended
> instead, with QSem and friends slated for removal?

FUD! :)

I revamped it for 7.6 rather than remove it, it's safe and fast now.

Cheers,
Simon


> In any case, there are probably leftover attempts to make it safe, yes.
>
> --
> brandon s allbery kf8nh                               sine nomine associates
> allbery.b at gmail.com <mailto:allbery.b at gmail.com> ballbery at sinenomine.net
> <mailto:ballbery at sinenomine.net>
> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From marlowsd at gmail.com  Mon Nov 24 10:17:40 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 24 Nov 2014 10:17:40 +0000
Subject: Garbage collection
In-Reply-To: <CAC0Lnfv3fsrkwNhytQnOjHEt+t_Y_r9125-cyWh3vNAOzQZ_MA@mail.gmail.com>
References: <CA+Q==SCJpCB-7DsBfj8Ey071yV80JJubsmfTAEHWU4703hJRyw@mail.gmail.com>
 <CA+Q==SBUUManYctGBpEjUNxJ2Bk3PvtaEDKK5mLLDZsV6FhCQg@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3C8C05@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAC0Lnfv3fsrkwNhytQnOjHEt+t_Y_r9125-cyWh3vNAOzQZ_MA@mail.gmail.com>
Message-ID: <547305C4.8020100@gmail.com>

On 18/11/2014 18:03, Mathieu Boespflug wrote:
> On 18 November 2014 16:59, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>> Isn't it this simple: the Static Pointer Table must be a source of roots for the garbage collector.  Of course!  An item in the SPT may be looked up at any time.
>
> As Facundo says, the existence of the SPT would solve everything. But
> we haven't quite figured out how to create a simple SPT yet, so were
> wondering whether there is an existing generic mechanism to register
> new GC roots.

Yes - the generic mechanism is StablePtrs, so you're on the right lines. 
  Even when you have an SPT you'll probably need to make a StablePtr to 
it (though I haven't been following the discussion so just ignore me if 
I'm wrong here).

Cheers,
Simon


> I guess there is no better solution but to just create an SPT, even if
> we don't yet have TypeRep's to put in it.
>
> With an SPT, and under the assumption of everyone sharing the same
> binary in the distributed system, there will be no need to hold on to
> *all* CAF's - just the ones that are known to have a StaticPointer
> created for them at compile time.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From marlowsd at gmail.com  Mon Nov 24 10:19:43 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 24 Nov 2014 10:19:43 +0000
Subject: linker_unload
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3D93CE@DB3PRD3001MB020.064d.mgd.msft.net>
References: <618BE556AADD624C9C918AA5D5911BEF3F3D93CE@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <5473063F.5080101@gmail.com>

Herbert, perhaps this is integer-gmp2 breakage?

On 21/11/2014 13:51, Simon Peyton Jones wrote:
> I?m getting this for test linker_unload on Linux. I?m sure it?s not my
> fault!
>
> But it makes validate fail
>
> Simon
>
> Wrong exit code (expected 0 , actual 2 )
>
> Stdout:
>
> Stderr:
>
> linker_unload:
> /5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist-install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a:
> unknown symbol `__gmpn_rshift'
>
> linker_unload: resolveObjs failed
>
> make[3]: *** [linker_unload] Error 1
>
> *** unexpected failure for linker_unload(normal)
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From shumovichy at gmail.com  Mon Nov 24 11:12:43 2014
From: shumovichy at gmail.com (Yuras Shumovich)
Date: Mon, 24 Nov 2014 14:12:43 +0300
Subject: mask in waitQSem
In-Reply-To: <547303E8.5040603@gmail.com>
References: <1416000184.2762.1.camel@gmail.com> <547303E8.5040603@gmail.com>
Message-ID: <1416827563.2712.1.camel@gmail.com>

On Mon, 2014-11-24 at 10:09 +0000, Simon Marlow wrote:
> On 14/11/2014 21:23, Yuras Shumovich wrote:
> >
> > I was reviewing some exception handling code in base library, and I
> > found this line:
> > https://phabricator.haskell.org/diffusion/GHC/browse/master/libraries/base/Control/Concurrent/QSem.hs;165072b334ebb2ccbef38a963ac4d126f1e08c96$74
> >
> > Here mask is used, but I looks completely useless for me. waitQSem
> > itself should be called with async exceptions masked, otherwise there is
> > no way to prevent resource leak.
> >
> > Do anyone know why mask is used here?
> 
> I wrote that code.  It looks like mask_ is important, otherwise an async 
> exception might leave the MVar empty, no?  We can't assume that waitQSem 
> is always called inside a mask_, so it does its own mask_.

Hmm, yes, you are right.

Note, that in case of failure (and without external `mask`) it is not
possible to determine, whether a unit of resource was reserved or not.
It makes the particular instance of `QSem` unusable anymore, and we have
to create other one. Probably there are situations where it is OK
though.

Thanks,
Yuras

> 
> Cheers,
> Simon
> 
> 
> > I wonder whether an author of the code tried to do something different,
> > so there actually can be a bug hidden here. Probably
> > uninterruptibleMask_ should be used here? (I don't think so though.)
> >
> > Thanks,
> > Yuras
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> >



From hvriedel at gmail.com  Mon Nov 24 12:50:52 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Mon, 24 Nov 2014 13:50:52 +0100
Subject: linker_unload
In-Reply-To: <5473063F.5080101@gmail.com> (Simon Marlow's message of "Mon, 24
 Nov 2014 10:19:43 +0000")
References: <618BE556AADD624C9C918AA5D5911BEF3F3D93CE@DB3PRD3001MB020.064d.mgd.msft.net>
 <5473063F.5080101@gmail.com>
Message-ID: <87d28cpxsj.fsf@gmail.com>

On 2014-11-24 at 11:19:43 +0100, Simon Marlow wrote:
>> linker_unload:
>> /5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist-install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a:
>> unknown symbol `__gmpn_rshift'

> Herbert, perhaps this is integer-gmp2 breakage?

...can't rule it out, but I haven't seen that failure anywhere else so
far (including http://haskell.inf.elte.hu/builders/) and can't reproduce
it myself either :-/

Cheers,
  hvr

From karel.gardas at centrum.cz  Mon Nov 24 13:16:10 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Mon, 24 Nov 2014 14:16:10 +0100
Subject: linker_unload
In-Reply-To: <87d28cpxsj.fsf@gmail.com>
References: <618BE556AADD624C9C918AA5D5911BEF3F3D93CE@DB3PRD3001MB020.064d.mgd.msft.net>
 <5473063F.5080101@gmail.com> <87d28cpxsj.fsf@gmail.com>
Message-ID: <54732F9A.20805@centrum.cz>

On 11/24/14 01:50 PM, Herbert Valerio Riedel wrote:
> On 2014-11-24 at 11:19:43 +0100, Simon Marlow wrote:
>>> linker_unload:
>>> /5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist-install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a:
>>> unknown symbol `__gmpn_rshift'
>
>> Herbert, perhaps this is integer-gmp2 breakage?
>
> ...can't rule it out, but I haven't seen that failure anywhere else so
> far (including http://haskell.inf.elte.hu/builders/) and can't reproduce
> it myself either :-/

Have you tested RHEL 6.x? IIRC it is also using older GMP like 
Solaris... Also this is probably not tested on any builder...

Karel

From simonpj at microsoft.com  Mon Nov 24 15:23:08 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 24 Nov 2014 15:23:08 +0000
Subject: let app invariant failure, HALP Re: how to write a ghc primop
 that acts on an unevaluated argument?
In-Reply-To: <CAHYVw0zHaW6R=txyZzoPWkNq8t2RDZ_rSg6N0PHzMHz=nnTGrw@mail.gmail.com>
References: <CAHYVw0yNm+2TRv=8v0ngqrLdSQycWgDQiYNay0F6ky6p-3gJUw@mail.gmail.com>
 <CAHYVw0zHaW6R=txyZzoPWkNq8t2RDZ_rSg6N0PHzMHz=nnTGrw@mail.gmail.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3DE67E@DB3PRD3001MB020.064d.mgd.msft.net>

Carter

That smells wrong to me.  These flags have a very carefully defined meaning; see
            Note [PrimOp can_fail and has_side_effects]
in PrimOp.lhs

If you say it has side effects when it doesn?t, you?ll confuse your successor reading the code in five years time.

Better to find out what is going on and why.  Might you do that? What transformation invalidates the let/app invariant?  Make a small test case, use ?dverbose-core2core ?ddump-occur-anal ?ddump-inlinings.  I would far rather that than install a land-mine in the code.

Simon

From: Carter Schonwald [mailto:carter.schonwald at gmail.com]
Sent: 24 November 2014 00:54
To: Edward Kmett
Cc: ghc-devs at haskell.org; Simon Peyton Jones; Joachim Breitner
Subject: Re: let app invariant failure, HALP Re: how to write a ghc primop that acts on an unevaluated argument?

woot, solved it, at least in a way thats OK for now.

if I mark the prefetchValue operations as has_side_effects=True, the core lint failure goes away! I'm not sure if thats the right semantics in the long term, but it does give me a simple way to make sure it works safely for 7.10

pardon all the noise
-Carter

On Sun, Nov 23, 2014 at 4:26 PM, Carter Schonwald <carter.schonwald at gmail.com<mailto:carter.schonwald at gmail.com>> wrote:
ok, i'm getting a let/app invariant failure when i build my test case with O1 or O2 but not without

http://lpaste.net/114881

any help would be appreciated on how to address that

On Sun, Nov 23, 2014 at 4:13 PM, Carter Schonwald <carter.schonwald at gmail.com<mailto:carter.schonwald at gmail.com>> wrote:
yup, i have that!

    wrapFetch prefetchValue0# (error "this shouldn't get evaluated")

in the test suite!

in contrast
    wrapFetch prefetchValue0# $! (error "this shouldn't get evaluated") does explode

shall I add a "should fail" test with the latter? (it doesn't seem worthwhile)

On Sun, Nov 23, 2014 at 3:53 PM, Edward Kmett <ekmett at gmail.com<mailto:ekmett at gmail.com>> wrote:
Maybe test for laziness in the argument by just putting something in that goes boom when forced, e.g. 'undefined'?


On Sun, Nov 23, 2014 at 2:04 PM, Carter Schonwald <carter.schonwald at gmail.com<mailto:carter.schonwald at gmail.com>> wrote:
Hey All,
as part of trying to get some fixups for how prefetch works into 7.10,
i'm adding a "prefetchValue" primop that prefetchs the memory location of a lifted heap value

namely

several operations of the following form

primop PrefetchValueOp1 "prefetchValue1#" GenPrimOp
   a -> State# s -> State# s
   with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd] topRes }

I'd like some feedback on the strictness information design by someone who's familiar with how that piece of GHC. the idea being that prefetchValue is lazy in its polymorphic argument (it doesn't force it, it just does a prefetch on the heap location, which may or may not be evaluated).

https://phabricator.haskell.org/D350

is the code in question. And i *believe* i'm testing for being lazy in that argument correctly.

thoughts?

many thanks!
-Carter


_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://www.haskell.org/mailman/listinfo/ghc-devs




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141124/a39e9abb/attachment-0001.html>

From simonpj at microsoft.com  Mon Nov 24 17:50:37 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 24 Nov 2014 17:50:37 +0000
Subject: Diff grouping question
In-Reply-To: <CANma=H8jAPujUWaOWaV7sseVtbdP+iXGmYU+U0_SOtgH8WpUgA@mail.gmail.com>
References: <CANma=H8jAPujUWaOWaV7sseVtbdP+iXGmYU+U0_SOtgH8WpUgA@mail.gmail.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3DEBD5@DB3PRD3001MB020.064d.mgd.msft.net>

I?d put them all in one

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman
Sent: 22 November 2014 13:58
To: ghc-devs at haskell.org
Subject: Diff grouping question

I am picking up some minor updates required for the API annotations, relating to documentation inaccuracies, and some missing annotations needing to be captured in the parser.
Should these go into separate Phab diffs, or can I just put them all in one?
Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141124/e4aa2008/attachment.html>

From carter.schonwald at gmail.com  Tue Nov 25 03:37:12 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 24 Nov 2014 22:37:12 -0500
Subject: let app invariant failure, HALP Re: how to write a ghc primop
 that acts on an unevaluated argument?
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3DE67E@DB3PRD3001MB020.064d.mgd.msft.net>
References: <CAHYVw0yNm+2TRv=8v0ngqrLdSQycWgDQiYNay0F6ky6p-3gJUw@mail.gmail.com>
 <CAHYVw0zHaW6R=txyZzoPWkNq8t2RDZ_rSg6N0PHzMHz=nnTGrw@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3DE67E@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CAHYVw0xF0Wv8FVAZQ3AbAkax=Htyhv68RX6D4NMsn7j+tvSwBQ@mail.gmail.com>

when i run
./inplace/bin/ghc-stage2 codetester.hs  -O2 -dcore-lint -S  -fforce-recomp
-ddump-simpl -ddump-to-file ?dverbose-core2core ?ddump-occur-anal
?ddump-inlinings
i get
target ??dverbose-core2core? is not a module name or a source file

what am I doing wrong in this CLI invocation?

On Mon, Nov 24, 2014 at 10:23 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

>  Carter
>
>
>
> That smells wrong to me.  These flags have a very carefully defined
> meaning; see
>
>             Note [PrimOp can_fail and has_side_effects]
>
> in PrimOp.lhs
>
>
>
> If you say it has side effects when it doesn?t, you?ll confuse your
> successor reading the code in five years time.
>
>
>
> Better to find out what is going on and why.  Might you do that? What
> transformation invalidates the let/app invariant?  Make a small test case,
> use ?dverbose-core2core ?ddump-occur-anal ?ddump-inlinings.  I would far
> rather that than install a land-mine in the code.
>
>
>
> Simon
>
>
>
> *From:* Carter Schonwald [mailto:carter.schonwald at gmail.com]
> *Sent:* 24 November 2014 00:54
> *To:* Edward Kmett
> *Cc:* ghc-devs at haskell.org; Simon Peyton Jones; Joachim Breitner
> *Subject:* Re: let app invariant failure, HALP Re: how to write a ghc
> primop that acts on an unevaluated argument?
>
>
>
> woot, solved it, at least in a way thats OK for now.
>
>
>
> if I mark the prefetchValue operations as has_side_effects=True, the core
> lint failure goes away! I'm not sure if thats the right semantics in the
> long term, but it does give me a simple way to make sure it works safely
> for 7.10
>
>
>
> pardon all the noise
>
> -Carter
>
>
>
> On Sun, Nov 23, 2014 at 4:26 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>  ok, i'm getting a let/app invariant failure when i build my test case
> with O1 or O2 but not without
>
>
>
> http://lpaste.net/114881
>
>
>
> any help would be appreciated on how to address that
>
>
>
> On Sun, Nov 23, 2014 at 4:13 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>  yup, i have that!
>
>
>
>     wrapFetch prefetchValue0# (error "this shouldn't get evaluated")
>
>
>
> in the test suite!
>
>
>
> in contrast
>
>     wrapFetch prefetchValue0# $! (error "this shouldn't get evaluated")
> does explode
>
>
>
> shall I add a "should fail" test with the latter? (it doesn't seem
> worthwhile)
>
>
>
> On Sun, Nov 23, 2014 at 3:53 PM, Edward Kmett <ekmett at gmail.com> wrote:
>
>  Maybe test for laziness in the argument by just putting something in
> that goes boom when forced, e.g. 'undefined'?
>
>
>
>
>
> On Sun, Nov 23, 2014 at 2:04 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>   Hey All,
>
> as part of trying to get some fixups for how prefetch works into 7.10,
>
> i'm adding a "prefetchValue" primop that prefetchs the memory location of
> a lifted heap value
>
>
>
> namely
>
>
>
> several operations of the following form
>
>
>
> primop PrefetchValueOp1 "prefetchValue1#" GenPrimOp
>
>    a -> State# s -> State# s
>
>    with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd]
> topRes }
>
>
>
> I'd like some feedback on the strictness information design by someone
> who's familiar with how that piece of GHC. the idea being that
> prefetchValue is lazy in its polymorphic argument (it doesn't force it, it
> just does a prefetch on the heap location, which may or may not be
> evaluated).
>
>
>
> https://phabricator.haskell.org/D350
>
>
>
> is the code in question. And i *believe* i'm testing for being lazy in
> that argument correctly.
>
>
>
> thoughts?
>
>
>
> many thanks!
>
> -Carter
>
>
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141124/3d81b768/attachment-0001.html>

From carter.schonwald at gmail.com  Tue Nov 25 03:43:55 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 24 Nov 2014 22:43:55 -0500
Subject: let app invariant failure, HALP Re: how to write a ghc primop
 that acts on an unevaluated argument?
In-Reply-To: <CAHYVw0xF0Wv8FVAZQ3AbAkax=Htyhv68RX6D4NMsn7j+tvSwBQ@mail.gmail.com>
References: <CAHYVw0yNm+2TRv=8v0ngqrLdSQycWgDQiYNay0F6ky6p-3gJUw@mail.gmail.com>
 <CAHYVw0zHaW6R=txyZzoPWkNq8t2RDZ_rSg6N0PHzMHz=nnTGrw@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3DE67E@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAHYVw0xF0Wv8FVAZQ3AbAkax=Htyhv68RX6D4NMsn7j+tvSwBQ@mail.gmail.com>
Message-ID: <CAHYVw0wzQxATm2XmZ1mLCx3rc-rsiLuv4BAiGVqCEWUv424Qug@mail.gmail.com>

huh, apparently i was mixing up '-' and some other similar dash character,
time to let my rebuild of ghc go through then try gain :)

On Mon, Nov 24, 2014 at 10:37 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> when i run
> ./inplace/bin/ghc-stage2 codetester.hs  -O2 -dcore-lint -S  -fforce-recomp
> -ddump-simpl -ddump-to-file ?dverbose-core2core ?ddump-occur-anal
> ?ddump-inlinings
> i get
> target ??dverbose-core2core? is not a module name or a source file
>
> what am I doing wrong in this CLI invocation?
>
> On Mon, Nov 24, 2014 at 10:23 AM, Simon Peyton Jones <
> simonpj at microsoft.com> wrote:
>
>>  Carter
>>
>>
>>
>> That smells wrong to me.  These flags have a very carefully defined
>> meaning; see
>>
>>             Note [PrimOp can_fail and has_side_effects]
>>
>> in PrimOp.lhs
>>
>>
>>
>> If you say it has side effects when it doesn?t, you?ll confuse your
>> successor reading the code in five years time.
>>
>>
>>
>> Better to find out what is going on and why.  Might you do that? What
>> transformation invalidates the let/app invariant?  Make a small test case,
>> use ?dverbose-core2core ?ddump-occur-anal ?ddump-inlinings.  I would far
>> rather that than install a land-mine in the code.
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* Carter Schonwald [mailto:carter.schonwald at gmail.com]
>> *Sent:* 24 November 2014 00:54
>> *To:* Edward Kmett
>> *Cc:* ghc-devs at haskell.org; Simon Peyton Jones; Joachim Breitner
>> *Subject:* Re: let app invariant failure, HALP Re: how to write a ghc
>> primop that acts on an unevaluated argument?
>>
>>
>>
>> woot, solved it, at least in a way thats OK for now.
>>
>>
>>
>> if I mark the prefetchValue operations as has_side_effects=True, the core
>> lint failure goes away! I'm not sure if thats the right semantics in the
>> long term, but it does give me a simple way to make sure it works safely
>> for 7.10
>>
>>
>>
>> pardon all the noise
>>
>> -Carter
>>
>>
>>
>> On Sun, Nov 23, 2014 at 4:26 PM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>  ok, i'm getting a let/app invariant failure when i build my test case
>> with O1 or O2 but not without
>>
>>
>>
>> http://lpaste.net/114881
>>
>>
>>
>> any help would be appreciated on how to address that
>>
>>
>>
>> On Sun, Nov 23, 2014 at 4:13 PM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>  yup, i have that!
>>
>>
>>
>>     wrapFetch prefetchValue0# (error "this shouldn't get evaluated")
>>
>>
>>
>> in the test suite!
>>
>>
>>
>> in contrast
>>
>>     wrapFetch prefetchValue0# $! (error "this shouldn't get evaluated")
>> does explode
>>
>>
>>
>> shall I add a "should fail" test with the latter? (it doesn't seem
>> worthwhile)
>>
>>
>>
>> On Sun, Nov 23, 2014 at 3:53 PM, Edward Kmett <ekmett at gmail.com> wrote:
>>
>>  Maybe test for laziness in the argument by just putting something in
>> that goes boom when forced, e.g. 'undefined'?
>>
>>
>>
>>
>>
>> On Sun, Nov 23, 2014 at 2:04 PM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>   Hey All,
>>
>> as part of trying to get some fixups for how prefetch works into 7.10,
>>
>> i'm adding a "prefetchValue" primop that prefetchs the memory location of
>> a lifted heap value
>>
>>
>>
>> namely
>>
>>
>>
>> several operations of the following form
>>
>>
>>
>> primop PrefetchValueOp1 "prefetchValue1#" GenPrimOp
>>
>>    a -> State# s -> State# s
>>
>>    with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd]
>> topRes }
>>
>>
>>
>> I'd like some feedback on the strictness information design by someone
>> who's familiar with how that piece of GHC. the idea being that
>> prefetchValue is lazy in its polymorphic argument (it doesn't force it, it
>> just does a prefetch on the heap location, which may or may not be
>> evaluated).
>>
>>
>>
>> https://phabricator.haskell.org/D350
>>
>>
>>
>> is the code in question. And i *believe* i'm testing for being lazy in
>> that argument correctly.
>>
>>
>>
>> thoughts?
>>
>>
>>
>> many thanks!
>>
>> -Carter
>>
>>
>>
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141124/bb3bb143/attachment.html>

From carter.schonwald at gmail.com  Tue Nov 25 06:47:13 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 25 Nov 2014 01:47:13 -0500
Subject: let app invariant failure, HALP Re: how to write a ghc primop
 that acts on an unevaluated argument?
In-Reply-To: <CAHYVw0wzQxATm2XmZ1mLCx3rc-rsiLuv4BAiGVqCEWUv424Qug@mail.gmail.com>
References: <CAHYVw0yNm+2TRv=8v0ngqrLdSQycWgDQiYNay0F6ky6p-3gJUw@mail.gmail.com>
 <CAHYVw0zHaW6R=txyZzoPWkNq8t2RDZ_rSg6N0PHzMHz=nnTGrw@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3DE67E@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAHYVw0xF0Wv8FVAZQ3AbAkax=Htyhv68RX6D4NMsn7j+tvSwBQ@mail.gmail.com>
 <CAHYVw0wzQxATm2XmZ1mLCx3rc-rsiLuv4BAiGVqCEWUv424Qug@mail.gmail.com>
Message-ID: <CAHYVw0zTi63QGMQBsLKJYpOEtoPWver4K2xXBfXu7A5gyBCUtw@mail.gmail.com>

ok attached is the log of
./inplace/bin/ghc-stage2 codetester.hs  -O2 -dcore-lint  -fforce-recomp
-ddump-simpl -ddump-to-file -dverbose-core2core -ddump-occur-anal
-ddump-inlinings  > output ^&1


the relevant snippet is bellow.

It looks like the Float-Out transformation is what tripping it.


That said, reading through what the semantics are implied by
has_side_effects = True, the prefetch* family of operations ARE side
effectful with respect the fact that they DO modify the CPU cache in a way
that changes what memory locations are in various levels of CPU cache, so
despite seeming read-like, they are modifying the state of the system, just
in a way that is ONLY visible wrt the performance characteristics/runtime
 of the resulting program.

specifically, Duplication, Floating out, and Specultive evaluation all
change *when* the prefetch runs and changes the CPU state, and Discard
means this "mutation" of the CPU cache state would not happen.

if prefetch was pure semantically (ie equiv to a -> ()  ) , they'd just be
no op, they're exclusively a tool for performance engineering, and
accordingly when and where they appear in code matters!

i'm more than happy to write out a more detailed version of this
explanation somewhere if you like.

-Carter

""""

*** Core Linted result of Simplifier:
*** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}):
*** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True,
OverSatApps = True}):
*** Core Lint errors : in result of Float out(FOS {Lam = Just 0,
                                                   Consts = True,
                                                   OverSatApps = True}) ***
<no location info>: Warning:
    In the expression: prefetchValue2#
                         @ [Char]
                         @ RealWorld
                         lvl_s3Oi
                         (prefetchValue1#
                            @ Int
                            @ RealWorld
                            lvl_s3Oj
                            (prefetchAddr3# @ RealWorld ds1_a3zg 0 ds_a3zf))
    This argument does not satisfy the let/app invariant:
      prefetchValue1#
        @ Int
        @ RealWorld
        lvl_s3Oj


"""



On Mon, Nov 24, 2014 at 10:43 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> huh, apparently i was mixing up '-' and some other similar dash character,
> time to let my rebuild of ghc go through then try gain :)
>
> On Mon, Nov 24, 2014 at 10:37 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> when i run
>> ./inplace/bin/ghc-stage2 codetester.hs  -O2 -dcore-lint -S
>>  -fforce-recomp -ddump-simpl -ddump-to-file ?dverbose-core2core
>> ?ddump-occur-anal ?ddump-inlinings
>> i get
>> target ??dverbose-core2core? is not a module name or a source file
>>
>> what am I doing wrong in this CLI invocation?
>>
>> On Mon, Nov 24, 2014 at 10:23 AM, Simon Peyton Jones <
>> simonpj at microsoft.com> wrote:
>>
>>>  Carter
>>>
>>>
>>>
>>> That smells wrong to me.  These flags have a very carefully defined
>>> meaning; see
>>>
>>>             Note [PrimOp can_fail and has_side_effects]
>>>
>>> in PrimOp.lhs
>>>
>>>
>>>
>>> If you say it has side effects when it doesn?t, you?ll confuse your
>>> successor reading the code in five years time.
>>>
>>>
>>>
>>> Better to find out what is going on and why.  Might you do that? What
>>> transformation invalidates the let/app invariant?  Make a small test case,
>>> use ?dverbose-core2core ?ddump-occur-anal ?ddump-inlinings.  I would far
>>> rather that than install a land-mine in the code.
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* Carter Schonwald [mailto:carter.schonwald at gmail.com]
>>> *Sent:* 24 November 2014 00:54
>>> *To:* Edward Kmett
>>> *Cc:* ghc-devs at haskell.org; Simon Peyton Jones; Joachim Breitner
>>> *Subject:* Re: let app invariant failure, HALP Re: how to write a ghc
>>> primop that acts on an unevaluated argument?
>>>
>>>
>>>
>>> woot, solved it, at least in a way thats OK for now.
>>>
>>>
>>>
>>> if I mark the prefetchValue operations as has_side_effects=True, the
>>> core lint failure goes away! I'm not sure if thats the right semantics in
>>> the long term, but it does give me a simple way to make sure it works
>>> safely for 7.10
>>>
>>>
>>>
>>> pardon all the noise
>>>
>>> -Carter
>>>
>>>
>>>
>>> On Sun, Nov 23, 2014 at 4:26 PM, Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>  ok, i'm getting a let/app invariant failure when i build my test case
>>> with O1 or O2 but not without
>>>
>>>
>>>
>>> http://lpaste.net/114881
>>>
>>>
>>>
>>> any help would be appreciated on how to address that
>>>
>>>
>>>
>>> On Sun, Nov 23, 2014 at 4:13 PM, Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>  yup, i have that!
>>>
>>>
>>>
>>>     wrapFetch prefetchValue0# (error "this shouldn't get evaluated")
>>>
>>>
>>>
>>> in the test suite!
>>>
>>>
>>>
>>> in contrast
>>>
>>>     wrapFetch prefetchValue0# $! (error "this shouldn't get evaluated")
>>> does explode
>>>
>>>
>>>
>>> shall I add a "should fail" test with the latter? (it doesn't seem
>>> worthwhile)
>>>
>>>
>>>
>>> On Sun, Nov 23, 2014 at 3:53 PM, Edward Kmett <ekmett at gmail.com> wrote:
>>>
>>>  Maybe test for laziness in the argument by just putting something in
>>> that goes boom when forced, e.g. 'undefined'?
>>>
>>>
>>>
>>>
>>>
>>> On Sun, Nov 23, 2014 at 2:04 PM, Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>   Hey All,
>>>
>>> as part of trying to get some fixups for how prefetch works into 7.10,
>>>
>>> i'm adding a "prefetchValue" primop that prefetchs the memory location
>>> of a lifted heap value
>>>
>>>
>>>
>>> namely
>>>
>>>
>>>
>>> several operations of the following form
>>>
>>>
>>>
>>> primop PrefetchValueOp1 "prefetchValue1#" GenPrimOp
>>>
>>>    a -> State# s -> State# s
>>>
>>>    with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd]
>>> topRes }
>>>
>>>
>>>
>>> I'd like some feedback on the strictness information design by someone
>>> who's familiar with how that piece of GHC. the idea being that
>>> prefetchValue is lazy in its polymorphic argument (it doesn't force it, it
>>> just does a prefetch on the heap location, which may or may not be
>>> evaluated).
>>>
>>>
>>>
>>> https://phabricator.haskell.org/D350
>>>
>>>
>>>
>>> is the code in question. And i *believe* i'm testing for being lazy in
>>> that argument correctly.
>>>
>>>
>>>
>>> thoughts?
>>>
>>>
>>>
>>> many thanks!
>>>
>>> -Carter
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141125/da2b38ba/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: output
Type: application/octet-stream
Size: 115111 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141125/da2b38ba/attachment-0001.obj>

From hvriedel at gmail.com  Tue Nov 25 07:18:53 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Tue, 25 Nov 2014 08:18:53 +0100
Subject: linker_unload
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3D93CE@DB3PRD3001MB020.064d.mgd.msft.net>
 (Simon Peyton Jones's message of "Fri, 21 Nov 2014 13:51:55 +0000")
References: <618BE556AADD624C9C918AA5D5911BEF3F3D93CE@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <87r3wr6942.fsf@gmail.com>

Hello Simon,

On 2014-11-21 at 14:51:55 +0100, Simon Peyton Jones wrote:
> I'm getting this for test linker_unload on Linux. I'm sure it's not my fault!
>
> But it makes validate fail

[...]

> linker_unload:
> /5playpen/simonpj/HEAD-2/libraries/integer-gmp2/dist-install/build/libHSinteg_2MbWUstH60IEgCAexOk3v3.a:
> unknown symbol `__gmpn_rshift'
> linker_unload: resolveObjs failed
> make[3]: *** [linker_unload] Error 1

I've tried this in an Ubuntu 12.04.5 LTS/x86_64 environment, but
couldn't reproduce it.

I'm quite confident that '__gmpn_rshift' is in fact not missing,
otherwise you'd get much more failures (and GHC probably wouldn't even
build). I also don't think that Ubuntu 12.04's is too old, as it's a GMP
5.0.2 version afaik.

Does `TEST=linker_unload` fail deterministically?

Would it be possible to update your `sudo apt-get update` & `sudo
apt-get dist-upgrade` your Linux environment with the latest bugfixes to
Ubuntu 12.04.5? That way we can be sure it's not a subtle bug already
fixed upstream...


Finally, if that also doesn't help, can you try cloning a fresh tree via

   git clone --recursive git://ghc.haskell.org/ghc.git <new-folder-name>

and invoke ./validate inside <new-folder-name>?


HTH,
  hvr

From karel.gardas at centrum.cz  Tue Nov 25 07:23:04 2014
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Tue, 25 Nov 2014 08:23:04 +0100
Subject: linker_unload
In-Reply-To: <87r3wr6942.fsf@gmail.com>
References: <618BE556AADD624C9C918AA5D5911BEF3F3D93CE@DB3PRD3001MB020.064d.mgd.msft.net>
 <87r3wr6942.fsf@gmail.com>
Message-ID: <54742E58.4040306@centrum.cz>

On 11/25/14 08:18 AM, Herbert Valerio Riedel wrote:
> Would it be possible to update your `sudo apt-get update`&  `sudo
> apt-get dist-upgrade` your Linux environment with the latest bugfixes to
> Ubuntu 12.04.5? That way we can be sure it's not a subtle bug already
> fixed upstream...

I'm not sure, but IMHO this will lead to upgrade to 14.04.1. What you 
should use is probably
`sudo apt-get update` &  `sudo apt-get upgrade`

Karel

From hvriedel at gmail.com  Tue Nov 25 07:38:38 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Tue, 25 Nov 2014 08:38:38 +0100
Subject: linker_unload
In-Reply-To: <54742E58.4040306@centrum.cz> (Karel Gardas's message of "Tue, 25
 Nov 2014 08:23:04 +0100")
References: <618BE556AADD624C9C918AA5D5911BEF3F3D93CE@DB3PRD3001MB020.064d.mgd.msft.net>
 <87r3wr6942.fsf@gmail.com> <54742E58.4040306@centrum.cz>
Message-ID: <87mw7f6875.fsf@gmail.com>

On 2014-11-25 at 08:23:04 +0100, Karel Gardas wrote:
> On 11/25/14 08:18 AM, Herbert Valerio Riedel wrote:
>> Would it be possible to update your `sudo apt-get update`&  `sudo
>> apt-get dist-upgrade` your Linux environment with the latest bugfixes to
>> Ubuntu 12.04.5? That way we can be sure it's not a subtle bug already
>> fixed upstream...
>
> I'm not sure, but IMHO this will lead to upgrade to 14.04.1. What you
> should use is probably
> `sudo apt-get update` &  `sudo apt-get upgrade`

http://askubuntu.com/questions/215267/will-apt-get-dist-upgrade-upgrade-my-system-to-newer-version

TLDR: no, `apt-get dist-upgrade` will not ugrade away from the 12.04.x branch

From marlowsd at gmail.com  Tue Nov 25 13:53:56 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 25 Nov 2014 13:53:56 +0000
Subject: mask in waitQSem
In-Reply-To: <1416827563.2712.1.camel@gmail.com>
References: <1416000184.2762.1.camel@gmail.com> <547303E8.5040603@gmail.com>
 <1416827563.2712.1.camel@gmail.com>
Message-ID: <547489F4.9080809@gmail.com>

On 24/11/2014 11:12, Yuras Shumovich wrote:
> On Mon, 2014-11-24 at 10:09 +0000, Simon Marlow wrote:
>> On 14/11/2014 21:23, Yuras Shumovich wrote:
>>>
>>> I was reviewing some exception handling code in base library, and I
>>> found this line:
>>> https://phabricator.haskell.org/diffusion/GHC/browse/master/libraries/base/Control/Concurrent/QSem.hs;165072b334ebb2ccbef38a963ac4d126f1e08c96$74
>>>
>>> Here mask is used, but I looks completely useless for me. waitQSem
>>> itself should be called with async exceptions masked, otherwise there is
>>> no way to prevent resource leak.
>>>
>>> Do anyone know why mask is used here?
>>
>> I wrote that code.  It looks like mask_ is important, otherwise an async
>> exception might leave the MVar empty, no?  We can't assume that waitQSem
>> is always called inside a mask_, so it does its own mask_.
>
> Hmm, yes, you are right.
>
> Note, that in case of failure (and without external `mask`) it is not
> possible to determine, whether a unit of resource was reserved or not.
> It makes the particular instance of `QSem` unusable anymore, and we have
> to create other one. Probably there are situations where it is OK
> though.

I don't think that's true: if waitQSem fails, then the semaphore has not 
been acquired.  This guarantee is important for "bracket waitQSem 
signalSQem" to work.  I just peered at the code again and I believe this 
is true - have you spotted a case where it might be false?  If so that's 
a bug.

Cheers,
Simon


>
> Thanks,
> Yuras
>
>>
>> Cheers,
>> Simon
>>
>>
>>> I wonder whether an author of the code tried to do something different,
>>> so there actually can be a bug hidden here. Probably
>>> uninterruptibleMask_ should be used here? (I don't think so though.)
>>>
>>> Thanks,
>>> Yuras
>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>
>

From shumovichy at gmail.com  Tue Nov 25 14:03:25 2014
From: shumovichy at gmail.com (Yuras Shumovich)
Date: Tue, 25 Nov 2014 17:03:25 +0300
Subject: mask in waitQSem
In-Reply-To: <547489F4.9080809@gmail.com>
References: <1416000184.2762.1.camel@gmail.com> <547303E8.5040603@gmail.com>
 <1416827563.2712.1.camel@gmail.com> <547489F4.9080809@gmail.com>
Message-ID: <1416924205.2679.1.camel@gmail.com>

On Tue, 2014-11-25 at 13:53 +0000, Simon Marlow wrote:
> On 24/11/2014 11:12, Yuras Shumovich wrote:
> > On Mon, 2014-11-24 at 10:09 +0000, Simon Marlow wrote:
> >> On 14/11/2014 21:23, Yuras Shumovich wrote:
> >>>
> >>> I was reviewing some exception handling code in base library, and I
> >>> found this line:
> >>> https://phabricator.haskell.org/diffusion/GHC/browse/master/libraries/base/Control/Concurrent/QSem.hs;165072b334ebb2ccbef38a963ac4d126f1e08c96$74
> >>>
> >>> Here mask is used, but I looks completely useless for me. waitQSem
> >>> itself should be called with async exceptions masked, otherwise there is
> >>> no way to prevent resource leak.
> >>>
> >>> Do anyone know why mask is used here?
> >>
> >> I wrote that code.  It looks like mask_ is important, otherwise an async
> >> exception might leave the MVar empty, no?  We can't assume that waitQSem
> >> is always called inside a mask_, so it does its own mask_.
> >
> > Hmm, yes, you are right.
> >
> > Note, that in case of failure (and without external `mask`) it is not
> > possible to determine, whether a unit of resource was reserved or not.
> > It makes the particular instance of `QSem` unusable anymore, and we have
> > to create other one. Probably there are situations where it is OK
> > though.
> 
> I don't think that's true: if waitQSem fails, then the semaphore has not 
> been acquired.  This guarantee is important for "bracket waitQSem 
> signalSQem" to work.  I just peered at the code again and I believe this 
> is true - have you spotted a case where it might be false?  If so that's 
> a bug.

The note was about the case when waitQSem is *not* called inside mask
(as you said we can't assume that). In that case it can be interrupted
by async exception either before entering mask_ or after leaving it. Is
it true? That makes waitQSem not very useful outside bracket.

When used inside bracket, it seems to be safe.

> 
> Cheers,
> Simon
> 
> 
> >
> > Thanks,
> > Yuras
> >
> >>
> >> Cheers,
> >> Simon
> >>
> >>
> >>> I wonder whether an author of the code tried to do something different,
> >>> so there actually can be a bug hidden here. Probably
> >>> uninterruptibleMask_ should be used here? (I don't think so though.)
> >>>
> >>> Thanks,
> >>> Yuras
> >>>
> >>>
> >>> _______________________________________________
> >>> ghc-devs mailing list
> >>> ghc-devs at haskell.org
> >>> http://www.haskell.org/mailman/listinfo/ghc-devs
> >>>
> >
> >



From marlowsd at gmail.com  Tue Nov 25 15:15:54 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 25 Nov 2014 15:15:54 +0000
Subject: mask in waitQSem
In-Reply-To: <1416924205.2679.1.camel@gmail.com>
References: <1416000184.2762.1.camel@gmail.com> <547303E8.5040603@gmail.com>	
 <1416827563.2712.1.camel@gmail.com> <547489F4.9080809@gmail.com>
 <1416924205.2679.1.camel@gmail.com>
Message-ID: <54749D2A.2070804@gmail.com>

On 25/11/2014 14:03, Yuras Shumovich wrote:
> On Tue, 2014-11-25 at 13:53 +0000, Simon Marlow wrote:
>> On 24/11/2014 11:12, Yuras Shumovich wrote:
>>> On Mon, 2014-11-24 at 10:09 +0000, Simon Marlow wrote:
>>>> On 14/11/2014 21:23, Yuras Shumovich wrote:
>>>>>
>>>>> I was reviewing some exception handling code in base library, and I
>>>>> found this line:
>>>>> https://phabricator.haskell.org/diffusion/GHC/browse/master/libraries/base/Control/Concurrent/QSem.hs;165072b334ebb2ccbef38a963ac4d126f1e08c96$74
>>>>>
>>>>> Here mask is used, but I looks completely useless for me. waitQSem
>>>>> itself should be called with async exceptions masked, otherwise there is
>>>>> no way to prevent resource leak.
>>>>>
>>>>> Do anyone know why mask is used here?
>>>>
>>>> I wrote that code.  It looks like mask_ is important, otherwise an async
>>>> exception might leave the MVar empty, no?  We can't assume that waitQSem
>>>> is always called inside a mask_, so it does its own mask_.
>>>
>>> Hmm, yes, you are right.
>>>
>>> Note, that in case of failure (and without external `mask`) it is not
>>> possible to determine, whether a unit of resource was reserved or not.
>>> It makes the particular instance of `QSem` unusable anymore, and we have
>>> to create other one. Probably there are situations where it is OK
>>> though.
>>
>> I don't think that's true: if waitQSem fails, then the semaphore has not
>> been acquired.  This guarantee is important for "bracket waitQSem
>> signalSQem" to work.  I just peered at the code again and I believe this
>> is true - have you spotted a case where it might be false?  If so that's
>> a bug.
>
> The note was about the case when waitQSem is *not* called inside mask
> (as you said we can't assume that). In that case it can be interrupted
> by async exception either before entering mask_ or after leaving it. Is
> it true? That makes waitQSem not very useful outside bracket.

Well, that's the case for *any* side-effecting operation outside of 
mask: when an exception is raised, you have no idea whether the effect 
took place or not.  That's why we have mask.

It might still be useful outside mask, if the QSem is being used locally 
and it's ok to discard it along with the computation.

Cheers,
Simon


> When used inside bracket, it seems to be safe.
>
>>
>> Cheers,
>> Simon
>>
>>
>>>
>>> Thanks,
>>> Yuras
>>>
>>>>
>>>> Cheers,
>>>> Simon
>>>>
>>>>
>>>>> I wonder whether an author of the code tried to do something different,
>>>>> so there actually can be a bug hidden here. Probably
>>>>> uninterruptibleMask_ should be used here? (I don't think so though.)
>>>>>
>>>>> Thanks,
>>>>> Yuras
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ghc-devs mailing list
>>>>> ghc-devs at haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>
>>>
>>>
>
>

From mail at joachim-breitner.de  Tue Nov 25 15:48:13 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 25 Nov 2014 16:48:13 +0100
Subject: Failing tests: literals T5681 annotations
In-Reply-To: <1416652515.1406.1.camel@joachim-breitner.de>
References: <1416652515.1406.1.camel@joachim-breitner.de>
Message-ID: <1416930493.21627.3.camel@joachim-breitner.de>

Hi,


Am Samstag, den 22.11.2014, 11:35 +0100 schrieb Joachim Breitner:
> I currently observe
> 
> Unexpected results from:
> TEST="literals T5681 annotations"

this has improved to just
        TEST="T5681 annotations"

but still this needs some investigation. Maybe a problem with parallel
test runs and temporary files cleaned out too quickly?

> 
> Details:
> 
> Compile failed (status 256) errors were:
> /tmp/ghc13786_0/ghc13786_5.s: Assembler messages:
> 
> /tmp/ghc13786_0/ghc13786_5.s:26:0:
>      Error: can't resolve `.rodata' {.rodata section} - `Main_zdwwork_info$def' {.text section}
> 
> /tmp/ghc13786_0/ghc13786_5.s:46:0:
>      Error: can't resolve `.rodata' {.rodata section} - `Main_work_info$def' {.text section}
> 
> /tmp/ghc13786_0/ghc13786_5.s:66:0:
>      Error: can't resolve `.rodata' {.rodata section} - `Main_main1_info$def' {.text section}
> 
> /tmp/ghc13786_0/ghc13786_5.s:86:0:
>      Error: can't resolve `.rodata' {.rodata section} - `Main_main_info$def' {.text section}
> 
> /tmp/ghc13786_0/ghc13786_5.s:106:0:
>      Error: can't resolve `.rodata' {.rodata section} - `Main_main2_info$def' {.text section}
> 
> /tmp/ghc13786_0/ghc13786_5.s:126:0:
>      Error: can't resolve `.rodata' {.rodata section} - `ZCMain_main_info$def' {.text section}
> 
> *** unexpected failure for T5681(optllvm)



> *** unexpected failure for annotations(normal)
> 
> Wrong exit code (expected 0 , actual 2 )
> Stdout:
> 
> Stderr:
> /usr/bin/ld: reopening literals.o: No such file or directory
> 
> /usr/bin/ld:literals.o: bfd_stat failed: No such file or directory
> /usr/bin/ld: reopening literals.o: No such file or directory
> 
> /usr/bin/ld: BFD (GNU Binutils for Ubuntu) 2.22 internal error, aborting at ../../bfd/merge.c line 873 in _bfd_merged_section_offset
> 
> /usr/bin/ld: Please report this bug.
> 
> collect2: ld returned 1 exit status
> make[3]: *** [literals] Error 1
> 
> *** unexpected failure for literals(normal)

Thanks,
Joachim
-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141125/c0723f83/attachment.sig>

From carter.schonwald at gmail.com  Tue Nov 25 17:36:26 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 25 Nov 2014 12:36:26 -0500
Subject: let app invariant failure, HALP Re: how to write a ghc primop
 that acts on an unevaluated argument?
In-Reply-To: <CAHYVw0zTi63QGMQBsLKJYpOEtoPWver4K2xXBfXu7A5gyBCUtw@mail.gmail.com>
References: <CAHYVw0yNm+2TRv=8v0ngqrLdSQycWgDQiYNay0F6ky6p-3gJUw@mail.gmail.com>
 <CAHYVw0zHaW6R=txyZzoPWkNq8t2RDZ_rSg6N0PHzMHz=nnTGrw@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3DE67E@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAHYVw0xF0Wv8FVAZQ3AbAkax=Htyhv68RX6D4NMsn7j+tvSwBQ@mail.gmail.com>
 <CAHYVw0wzQxATm2XmZ1mLCx3rc-rsiLuv4BAiGVqCEWUv424Qug@mail.gmail.com>
 <CAHYVw0zTi63QGMQBsLKJYpOEtoPWver4K2xXBfXu7A5gyBCUtw@mail.gmail.com>
Message-ID: <CAHYVw0zpnm0DaxkYy6_OmKU0xg5ZPB9nkWHCukxNbYAfQ5f_JQ@mail.gmail.com>

i'm doing a bit of benchmarking today, and it may very well be that youre
absolutely correct about all of this in practice, at least the way things
are trending.

On Tue, Nov 25, 2014 at 1:47 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> ok attached is the log of
> ./inplace/bin/ghc-stage2 codetester.hs  -O2 -dcore-lint  -fforce-recomp
> -ddump-simpl -ddump-to-file -dverbose-core2core -ddump-occur-anal
> -ddump-inlinings  > output ^&1
>
>
> the relevant snippet is bellow.
>
> It looks like the Float-Out transformation is what tripping it.
>
>
> That said, reading through what the semantics are implied by
> has_side_effects = True, the prefetch* family of operations ARE side
> effectful with respect the fact that they DO modify the CPU cache in a way
> that changes what memory locations are in various levels of CPU cache, so
> despite seeming read-like, they are modifying the state of the system, just
> in a way that is ONLY visible wrt the performance characteristics/runtime
>  of the resulting program.
>
> specifically, Duplication, Floating out, and Specultive evaluation all
> change *when* the prefetch runs and changes the CPU state, and Discard
> means this "mutation" of the CPU cache state would not happen.
>
> if prefetch was pure semantically (ie equiv to a -> ()  ) , they'd just be
> no op, they're exclusively a tool for performance engineering, and
> accordingly when and where they appear in code matters!
>
> i'm more than happy to write out a more detailed version of this
> explanation somewhere if you like.
>
> -Carter
>
> """"
>
> *** Core Linted result of Simplifier:
> *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}):
> *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True,
> OverSatApps = True}):
> *** Core Lint errors : in result of Float out(FOS {Lam = Just 0,
>                                                    Consts = True,
>                                                    OverSatApps = True}) ***
> <no location info>: Warning:
>     In the expression: prefetchValue2#
>                          @ [Char]
>                          @ RealWorld
>                          lvl_s3Oi
>                          (prefetchValue1#
>                             @ Int
>                             @ RealWorld
>                             lvl_s3Oj
>                             (prefetchAddr3# @ RealWorld ds1_a3zg 0
> ds_a3zf))
>     This argument does not satisfy the let/app invariant:
>       prefetchValue1#
>         @ Int
>         @ RealWorld
>         lvl_s3Oj
>
>
> """
>
>
>
> On Mon, Nov 24, 2014 at 10:43 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> huh, apparently i was mixing up '-' and some other similar dash
>> character, time to let my rebuild of ghc go through then try gain :)
>>
>> On Mon, Nov 24, 2014 at 10:37 PM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> when i run
>>> ./inplace/bin/ghc-stage2 codetester.hs  -O2 -dcore-lint -S
>>>  -fforce-recomp -ddump-simpl -ddump-to-file ?dverbose-core2core
>>> ?ddump-occur-anal ?ddump-inlinings
>>> i get
>>> target ??dverbose-core2core? is not a module name or a source file
>>>
>>> what am I doing wrong in this CLI invocation?
>>>
>>> On Mon, Nov 24, 2014 at 10:23 AM, Simon Peyton Jones <
>>> simonpj at microsoft.com> wrote:
>>>
>>>>  Carter
>>>>
>>>>
>>>>
>>>> That smells wrong to me.  These flags have a very carefully defined
>>>> meaning; see
>>>>
>>>>             Note [PrimOp can_fail and has_side_effects]
>>>>
>>>> in PrimOp.lhs
>>>>
>>>>
>>>>
>>>> If you say it has side effects when it doesn?t, you?ll confuse your
>>>> successor reading the code in five years time.
>>>>
>>>>
>>>>
>>>> Better to find out what is going on and why.  Might you do that? What
>>>> transformation invalidates the let/app invariant?  Make a small test case,
>>>> use ?dverbose-core2core ?ddump-occur-anal ?ddump-inlinings.  I would far
>>>> rather that than install a land-mine in the code.
>>>>
>>>>
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>> *From:* Carter Schonwald [mailto:carter.schonwald at gmail.com]
>>>> *Sent:* 24 November 2014 00:54
>>>> *To:* Edward Kmett
>>>> *Cc:* ghc-devs at haskell.org; Simon Peyton Jones; Joachim Breitner
>>>> *Subject:* Re: let app invariant failure, HALP Re: how to write a ghc
>>>> primop that acts on an unevaluated argument?
>>>>
>>>>
>>>>
>>>> woot, solved it, at least in a way thats OK for now.
>>>>
>>>>
>>>>
>>>> if I mark the prefetchValue operations as has_side_effects=True, the
>>>> core lint failure goes away! I'm not sure if thats the right semantics in
>>>> the long term, but it does give me a simple way to make sure it works
>>>> safely for 7.10
>>>>
>>>>
>>>>
>>>> pardon all the noise
>>>>
>>>> -Carter
>>>>
>>>>
>>>>
>>>> On Sun, Nov 23, 2014 at 4:26 PM, Carter Schonwald <
>>>> carter.schonwald at gmail.com> wrote:
>>>>
>>>>  ok, i'm getting a let/app invariant failure when i build my test case
>>>> with O1 or O2 but not without
>>>>
>>>>
>>>>
>>>> http://lpaste.net/114881
>>>>
>>>>
>>>>
>>>> any help would be appreciated on how to address that
>>>>
>>>>
>>>>
>>>> On Sun, Nov 23, 2014 at 4:13 PM, Carter Schonwald <
>>>> carter.schonwald at gmail.com> wrote:
>>>>
>>>>  yup, i have that!
>>>>
>>>>
>>>>
>>>>     wrapFetch prefetchValue0# (error "this shouldn't get evaluated")
>>>>
>>>>
>>>>
>>>> in the test suite!
>>>>
>>>>
>>>>
>>>> in contrast
>>>>
>>>>     wrapFetch prefetchValue0# $! (error "this shouldn't get evaluated")
>>>> does explode
>>>>
>>>>
>>>>
>>>> shall I add a "should fail" test with the latter? (it doesn't seem
>>>> worthwhile)
>>>>
>>>>
>>>>
>>>> On Sun, Nov 23, 2014 at 3:53 PM, Edward Kmett <ekmett at gmail.com> wrote:
>>>>
>>>>  Maybe test for laziness in the argument by just putting something in
>>>> that goes boom when forced, e.g. 'undefined'?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Nov 23, 2014 at 2:04 PM, Carter Schonwald <
>>>> carter.schonwald at gmail.com> wrote:
>>>>
>>>>   Hey All,
>>>>
>>>> as part of trying to get some fixups for how prefetch works into 7.10,
>>>>
>>>> i'm adding a "prefetchValue" primop that prefetchs the memory location
>>>> of a lifted heap value
>>>>
>>>>
>>>>
>>>> namely
>>>>
>>>>
>>>>
>>>> several operations of the following form
>>>>
>>>>
>>>>
>>>> primop PrefetchValueOp1 "prefetchValue1#" GenPrimOp
>>>>
>>>>    a -> State# s -> State# s
>>>>
>>>>    with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd]
>>>> topRes }
>>>>
>>>>
>>>>
>>>> I'd like some feedback on the strictness information design by someone
>>>> who's familiar with how that piece of GHC. the idea being that
>>>> prefetchValue is lazy in its polymorphic argument (it doesn't force it, it
>>>> just does a prefetch on the heap location, which may or may not be
>>>> evaluated).
>>>>
>>>>
>>>>
>>>> https://phabricator.haskell.org/D350
>>>>
>>>>
>>>>
>>>> is the code in question. And i *believe* i'm testing for being lazy in
>>>> that argument correctly.
>>>>
>>>>
>>>>
>>>> thoughts?
>>>>
>>>>
>>>>
>>>> many thanks!
>>>>
>>>> -Carter
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141125/fce97ee4/attachment-0001.html>

From carter.schonwald at gmail.com  Tue Nov 25 18:29:26 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 25 Nov 2014 13:29:26 -0500
Subject: has anyone tested the llvm backend changes on OS X yet?
Message-ID: <CAHYVw0xY7tiG6Vi8PY1q7N8_8zQBM3k_e-7NFOEgNADZZGBrnw@mail.gmail.com>

i'm trying to test out the llvm backend on OS X with ghc head plus llvm 3.5

and i'm seeing stuff like  the following.
Could someone help me undestand whats going on?!


2 <http://lpaste.net/115021#line2>3 <http://lpaste.net/115021#line3>4
<http://lpaste.net/115021#line4>5 <http://lpaste.net/115021#line5>6
<http://lpaste.net/115021#line6>7 <http://lpaste.net/115021#line7>8
<http://lpaste.net/115021#line8>9 <http://lpaste.net/115021#line9>10
<http://lpaste.net/115021#line10>11 <http://lpaste.net/115021#line11>

*** Clang (Assembler):clang -m64 -fno-stack-protector
-DTABLES_NEXT_TO_CODE -I. -fno-common -U__PIC__ -D__PIC__
-Qunused-arguments -x assembler -c
/var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc89553_0/ghc89553_7.s
-o TestFetch.o
/var/folders/py/wgp_hj9d2rl3cx48yym_ynj00000gn/T/ghc89553_0/ghc89553_7.s:3:2:
     error: unknown directive
            .macosx_version_min 10, 0
            ^
<no location info>:
    Error running clang! you need clang installed to use theLLVM backend
    (or GHC tried to execute clang incorrectly)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141125/146c055f/attachment.html>

From austin at well-typed.com  Tue Nov 25 19:32:03 2014
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 25 Nov 2014 13:32:03 -0600
Subject: NOTE: The STABLE freeze is scheduled to occur TODAY.
In-Reply-To: <CAEs96n397St05bhyW0QvkWdEsri2BVKCvY9Y_Jse6gzBYVw+Hg@mail.gmail.com>
References: <CAEs96n397St05bhyW0QvkWdEsri2BVKCvY9Y_Jse6gzBYVw+Hg@mail.gmail.com>
Message-ID: <CAEs96n2n8=uPv_tJwu8eU0+N6NrJk8J4LMNx7T9x-0sXjMnXug@mail.gmail.com>

Hi all,

As an update to this schedule, since we missed some of the things we
were going to ship on Friday, we've delayed the creation of the
ghc-7.10 branch a bit.

We're hoping to get it done by this Friday. I need to merge the
Partial Type Signatures work, and I believe we need to give a once
over on the DWARF stuff, which SimonM will take care of.

I'll send some follow up emails to specific requests shortly.

On Fri, Nov 21, 2014 at 9:57 AM, Austin Seipp <austin at well-typed.com> wrote:
> Hi friends,
>
> Today, I'm planning on trying to cut a new `ghc-7.10` branch for the
> stable freeze. That means I'm going to spend a lot of time merging
> patches and other things with several other developers because
> everything is crazy and so many things wow.
>
> If you have things you want me to review, then please:
>
>   - Talk to me on IRC, #ghc on Freenode (I am 'thoughtpolice')
>   - Ping me on some medium like Skype (search for me). We can schedule
> a chat for a short time to figure things out.
>   - I can also do something like G+ or whatnot.
>   - I will of course be reading my email.
>
> Please note I would actually prefer to stay *away* from email I think,
> since it's a larger context switch for me, but I'll actively check it
> still just in case you want something and need to explain it.
>
> I'll likely be doing this most of the day, so let me know what happens.
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From austin at well-typed.com  Tue Nov 25 19:46:40 2014
From: austin at well-typed.com (Austin Seipp)
Date: Tue, 25 Nov 2014 13:46:40 -0600
Subject: ANNOUNCE: GHC 7.8.4 Release Candidate 1
Message-ID: <CAEs96n0xY4p+fknvPL_y+6S5=XukbWmPs+VyTnam4+qH+ESYtQ@mail.gmail.com>

We are pleased to announce the first release candidate for GHC 7.8.4:

    https://downloads.haskell.org/~ghc/7.8.4-rc1/

This includes the source tarball and bindists for 64bit Linux. Binary
builds for other platforms will be available shortly. These binaries
and tarballs have an accompanying SHA256SUMS file signed by my GPG key
id (0x3B58D86F).

We plan to make the 7.8.4 release sometime in the next few weeks.

Please test as much as possible; bugs are much cheaper if we find them
before the release!

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From carter.schonwald at gmail.com  Tue Nov 25 22:20:31 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 25 Nov 2014 17:20:31 -0500
Subject: More flexible literate Haskell extensions (Trac #9789), summary
 on wiki
In-Reply-To: <60C6C401-5469-40BD-B111-ACF9656F52FD@inconsistent.nl>
References: <CD574F24-99A8-4276-BED2-8C3050E17332@inconsistent.nl>
 <1416472583.1442.1.camel@joachim-breitner.de>
 <CANBN=muVOYGNbC-+vSoSmCyczZ-vPOXs+xPjTof_ystaEQzrcw@mail.gmail.com>
 <60C6C401-5469-40BD-B111-ACF9656F52FD@inconsistent.nl>
Message-ID: <CAHYVw0zZh=DTDB32mXuxYX0qSONLU3v7KoM9SH6r3uy+gWMLCw@mail.gmail.com>

Did you try measuring on eg, edwardk's gl package?

On Thu, Nov 20, 2014 at 12:52 PM, Merijn Verstraaten <merijn at inconsistent.nl
> wrote:

> Hey,
>
> I'm not really happy with an explicit extension list passed through flags,
> as it seems far to manual. It doesn't strike me as a very significant
> problem as my current work-in-progress patch only resorts to scanning the
> directory listing if none of the existing extensions are found.
>
> It seems unlikely that extremely large directories are in the search path.
> I don't think we're expecting anyone to have thousands of files in their
> module directories (and even thousands would take 0 time to scan...). We
> already try all search paths during probing so the extra overhead from
> large number of search paths shouldn't be substantially more than we have
> now.
>
> As for the weird FS support, I really don't think it's GHC's job to
> support people doing ridiculous things like "compiling on a filesystem that
> doesn't support directory listings", I mean, come on!
>
> To be honest, I consider both directories with huge numbers of files (keep
> in mind, we'd only scan the actual module sub-directory AND that we'd need
> to run into directories with tens if not hundreds of thousands files to
> notice any real slowdown) and weird filesystems that don't support
> directory listing cases of "so don't do that, then". Especially since these
> are only problems for users using non-standard module extensions.
>
> Cheers,
> Merijn
>
> > On 20 Nov 2014, at 2:40, Sven Panne <svenpanne at gmail.com> wrote:
> > 2014-11-20 9:36 GMT+01:00 Joachim Breitner <mail at joachim-breitner.de>:
> >> [...] With your extensions it will have to read the directory contents.
> In
> >> most situations, that should be fine, but it might cause minor
> >> inconveniences with very large directories, many search paths (-i flags)
> >> and/or very weird file systems (compiling from a FUSE-mounted
> >> HTTP-Server that does not support directory listing? Would work now...)
> >
> > Hmmm, IMHO reading directory contents is not a good idea for a
> > compiler, for just the reasons you mentioned.
> >
> >> A fixed set of extensions (e.g. just "md" and "tex") would avoid this
> >> problem, but goes against the spirit of the proposal.
> >
> > I think we can get the best of both worlds by adding a compiler flag,
> > e.g. --literate-extensions=md,tex. This way the compiler still has to
> > probe only a finite set of filenames *and* we are still flexible.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141125/a2f7050f/attachment.html>

From gergo at erdi.hu  Wed Nov 26 00:59:16 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Wed, 26 Nov 2014 08:59:16 +0800 (SGT)
Subject: Back-porting pattern synonym type signature syntax for GHC 7.8.4
 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]
In-Reply-To: <CAEs96n0xY4p+fknvPL_y+6S5=XukbWmPs+VyTnam4+qH+ESYtQ@mail.gmail.com>
References: <CAEs96n0xY4p+fknvPL_y+6S5=XukbWmPs+VyTnam4+qH+ESYtQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.10.1411260856200.2047@galaxy>

Hi,

Now that we know what the syntax of pattern synonym type signatures is 
going to be for GHC 7.10, would it make sense / is it not too late to 
backport that same syntax to 7.8.4?

To recap, 7.8 doesn't support adding type signatures to pattern synonyms, 
but GHCi's ":i" and Haddock both need to produce output which has them. 
There's a horrible hacked-together syntax in 7.8 which is very much *not* 
the syntax that will be used in 7.10.

Thanks,
 	Gergo

-- 
   .--= ULLA! =-----------------.
    \     http://gergo.erdi.hu   \
     `---= gergo at erdi.hu =-------'
A toj?sok csirk?kkel szaporodnak.

From kazu at iij.ad.jp  Wed Nov 26 07:10:51 2014
From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=))
Date: Wed, 26 Nov 2014 16:10:51 +0900 (JST)
Subject: ghc HEAD can't validate with xcode 6 clang on OS X
In-Reply-To: <CAHYVw0y0D0iGq9c=N-n6v9_xadMnuvX5c94qx0rBFu1vY-EwTA@mail.gmail.com>
References: <CAHYVw0y0D0iGq9c=N-n6v9_xadMnuvX5c94qx0rBFu1vY-EwTA@mail.gmail.com>
Message-ID: <20141126.161051.946905451805868981.kazu@iij.ad.jp>

Hi Carter,

> on OS X 10.9
> if i do
> git clone --recursive git://git.haskell.org/ghc.git ghc-valifail
> cd ghc-valifail
> perl boot
> ./configure --with-gcc=clang # the with gcc bit isnt needed, but making it
> clearly pick up clang is the point
> ./validate --fast

No problem on my OS X 10.9. The result of "CPUS=10 sh validate" today:

OVERALL SUMMARY for test run started at Wed Nov 26 13:50:48 2014 JST
 0:04:28 spent to go through
    4235 total tests, which gave rise to
   16491 test cases, of which
   12593 were skipped

      56 had missing libraries
    3768 expected passes
      67 expected failures

       0 caused framework failures
       0 unexpected passes
       6 unexpected failures
       1 unexpected stat failures

Unexpected failures:
   cabal/cabal01                            cabal01 [bad exit code] (normal)
   cabal/cabal06                            cabal06 [bad stdout] (normal)
   llvm/should_compile                      T5681 [exit code non-0] (optllvm)
   llvm/should_compile                      T7571 [exit code non-0] (optllvm)
   llvm/should_run/subsections_via_symbols  subsections_via_symbols [bad exit code] (normal)
   rts                                      T5435_dyn_asm [bad stdout] (normal)

Unexpected stat failures:
   perf/compiler  T4801 [stat too good] (normal)


--Kazu

From michael at snoyman.com  Wed Nov 26 08:54:07 2014
From: michael at snoyman.com (Michael Snoyman)
Date: Wed, 26 Nov 2014 08:54:07 +0000
Subject: ANNOUNCE: GHC 7.8.4 Release Candidate 1
References: <CAEs96n0xY4p+fknvPL_y+6S5=XukbWmPs+VyTnam4+qH+ESYtQ@mail.gmail.com>
Message-ID: <CAKA2JgJhJoDXKZ7k_0qZx3KG74nfgZk7z+qDp17iWFnyJw7-ZQ@mail.gmail.com>

On Tue Nov 25 2014 at 9:46:46 PM Austin Seipp <austin at well-typed.com> wrote:

> We are pleased to announce the first release candidate for GHC 7.8.4:
>
>     https://downloads.haskell.org/~ghc/7.8.4-rc1/
>
> This includes the source tarball and bindists for 64bit Linux. Binary
> builds for other platforms will be available shortly. These binaries
> and tarballs have an accompanying SHA256SUMS file signed by my GPG key
> id (0x3B58D86F).
>
> We plan to make the 7.8.4 release sometime in the next few weeks.
>
> Please test as much as possible; bugs are much cheaper if we find them
> before the release!
>
>
>
Just wanted to report: I ran a full Stackage build + test suite using the
release candidate, and everything passed. This build consisted of ~750
packages. You can find the list of packages at:

http://lpaste.net/115090

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141126/fd219587/attachment.html>

From simonpj at microsoft.com  Wed Nov 26 09:49:34 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 26 Nov 2014 09:49:34 +0000
Subject: Back-porting pattern synonym type signature syntax for GHC
 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]
In-Reply-To: <alpine.DEB.2.10.1411260856200.2047@galaxy>
References: <CAEs96n0xY4p+fknvPL_y+6S5=XukbWmPs+VyTnam4+qH+ESYtQ@mail.gmail.com>
 <alpine.DEB.2.10.1411260856200.2047@galaxy>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3E4948@DB3PRD3001MB020.064d.mgd.msft.net>

Harump.  

a) We do not generally make user-visible changes in a patch-level
   release, so we would not normally do this in 7.8.2, let alone 7.8.4

b) The 7.8.4 release candidate is out already

c) It would take a little care to back-port the syntax changes to 7.8
   without pattern signature (which we definitely don't want).  And
   there would be a knock on effect in Haddock perhaps?

d) BUT pattern synonyms are a brand new feature in 7.8
   and minimising differences between 7.8 and 7.10 would be good.

My instinct is that (a)-(c) overwhelm (d); i.e. let sleeping dogs lie.  But what do others think?

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Dr.
|  ERDI Gergo
|  Sent: 26 November 2014 00:59
|  To: Austin Seipp
|  Cc: ghc-devs at haskell.org
|  Subject: Back-porting pattern synonym type signature syntax for GHC
|  7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]
|  
|  Hi,
|  
|  Now that we know what the syntax of pattern synonym type signatures is
|  going to be for GHC 7.10, would it make sense / is it not too late to
|  backport that same syntax to 7.8.4?
|  
|  To recap, 7.8 doesn't support adding type signatures to pattern
|  synonyms, but GHCi's ":i" and Haddock both need to produce output
|  which has them.
|  There's a horrible hacked-together syntax in 7.8 which is very much
|  *not* the syntax that will be used in 7.10.
|  
|  Thanks,
|   	Gergo
|  
|  --
|     .--= ULLA! =-----------------.
|      \     http://gergo.erdi.hu   \
|       `---= gergo at erdi.hu =-------'
|  A toj?sok csirk?kkel szaporodnak.

From jan.stolarek at p.lodz.pl  Wed Nov 26 10:29:02 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Wed, 26 Nov 2014 11:29:02 +0100
Subject: Back-porting pattern synonym type signature syntax for GHC 7.8.4
 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3E4948@DB3PRD3001MB020.064d.mgd.msft.net>
References: <CAEs96n0xY4p+fknvPL_y+6S5=XukbWmPs+VyTnam4+qH+ESYtQ@mail.gmail.com>
 <alpine.DEB.2.10.1411260856200.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F3E4948@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <201411261129.02937.jan.stolarek@p.lodz.pl>

> My instinct is that (a)-(c) overwhelm (d); i.e. let sleeping dogs lie.
These arguments look convincing. I suppose the relevant section in the User's Guide should inform 
about changes planned for 7.10? To a limited extent this would address (d).

Janek

From simonpj at microsoft.com  Wed Nov 26 11:22:25 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 26 Nov 2014 11:22:25 +0000
Subject: T5462Yes1
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3E4FCA@DB3PRD3001MB020.064d.mgd.msft.net>

I'm getting this on Linux:

Unexpected failures:

   generics  T5462Yes1 [exit code non-0] (normal)



Linking T5462Yes1 ...

gcc: error: GEq/GEq1A.o: No such file or directory

gcc: error: GFunctor/GFunctor.o: No such file or directory



*** unexpected failure for T5462Yes1(normal)


But it doesn't happen if I say "make TEST=T5462Yes1".

Could this be a multi-thread file deletion thing?  make TEST=T5462Yes1 runs the test 8 different ways

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141126/618d3235/attachment.html>

From dreixel at gmail.com  Wed Nov 26 11:26:56 2014
From: dreixel at gmail.com (=?UTF-8?Q?Jos=C3=A9_Pedro_Magalh=C3=A3es?=)
Date: Wed, 26 Nov 2014 12:26:56 +0100
Subject: T5462Yes1
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3E4FCA@DB3PRD3001MB020.064d.mgd.msft.net>
References: <618BE556AADD624C9C918AA5D5911BEF3F3E4FCA@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CA+ZFbn8dOGGCuJ8teVinAZ0XAR+KEHkToWrtokKGE4NPLVZAPA@mail.gmail.com>

I thought I had solved that by removing the extra-clean for GFunctor.o from
another test, but apparently the file is still being deleted at some point.
Note that T56462Yes1, T5462Yes2, and T5462No all use GFunctor:

test('T5462Yes1', normal, multimod_compile_and_run, ['T5462Yes1', '-iGEq
-iGEnum -iGFunctor'])
test('T5462Yes2', normal, multimod_compile_and_run, ['T5462Yes2',
'-iGFunctor'])
test('T5462No1', normal, multimod_compile_fail, ['T5462No1', '-iGFunctor'])

On Wed, Nov 26, 2014 at 12:22 PM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

>  I?m getting this on Linux:
>
> Unexpected failures:
>
>    generics  T5462Yes1 [exit code non-0] (normal)
>
>
>
> Linking T5462Yes1 ...
>
> gcc: error: GEq/GEq1A.o: No such file or directory
>
> gcc: error: GFunctor/GFunctor.o: No such file or directory
>
>
>
> *** unexpected failure for T5462Yes1(normal)
>
>
>
> But it doesn?t happen if I say ?make TEST=T5462Yes1?.
>
>
>
> Could this be a multi-thread file deletion thing?  make TEST=T5462Yes1
> runs the test 8 different ways
>
>
>
> Simon
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141126/c4aa7dee/attachment.html>

From svenpanne at gmail.com  Wed Nov 26 11:40:37 2014
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 26 Nov 2014 12:40:37 +0100
Subject: ANNOUNCE: GHC 7.8.4 Release Candidate 1
In-Reply-To: <CAEs96n0xY4p+fknvPL_y+6S5=XukbWmPs+VyTnam4+qH+ESYtQ@mail.gmail.com>
References: <CAEs96n0xY4p+fknvPL_y+6S5=XukbWmPs+VyTnam4+qH+ESYtQ@mail.gmail.com>
Message-ID: <CANBN=mtuKsEPbiH_7VMBvLJNFnZpYDVLt7jC7GV=NHPHr-nDuw@mail.gmail.com>

2014-11-25 20:46 GMT+01:00 Austin Seipp <austin at well-typed.com>:
> We are pleased to announce the first release candidate for GHC 7.8.4:
>
>     https://downloads.haskell.org/~ghc/7.8.4-rc1/ [...]

Would it be possible to get the RC on
https://launchpad.net/~hvr/+archive/ubuntu/ghc? This way one could
easily test things on Travis CI.

From simonpj at microsoft.com  Wed Nov 26 12:37:32 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 26 Nov 2014 12:37:32 +0000
Subject: T5462Yes1
In-Reply-To: <CA+ZFbn8dOGGCuJ8teVinAZ0XAR+KEHkToWrtokKGE4NPLVZAPA@mail.gmail.com>
References: <618BE556AADD624C9C918AA5D5911BEF3F3E4FCA@DB3PRD3001MB020.064d.mgd.msft.net>
 <CA+ZFbn8dOGGCuJ8teVinAZ0XAR+KEHkToWrtokKGE4NPLVZAPA@mail.gmail.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3E5143@DB3PRD3001MB020.064d.mgd.msft.net>

Oh, if you did that in the last day or two, I might have missed it.  I?ll try again

From: josepedromagalhaes at gmail.com [mailto:josepedromagalhaes at gmail.com] On Behalf Of Jos? Pedro Magalh?es
Sent: 26 November 2014 11:27
To: Simon Peyton Jones
Cc: ghc-devs at haskell.org
Subject: Re: T5462Yes1

I thought I had solved that by removing the extra-clean for GFunctor.o from another test, but apparently the file is still being deleted at some point. Note that T56462Yes1, T5462Yes2, and T5462No all use GFunctor:

test('T5462Yes1', normal, multimod_compile_and_run, ['T5462Yes1', '-iGEq -iGEnum -iGFunctor'])
test('T5462Yes2', normal, multimod_compile_and_run, ['T5462Yes2', '-iGFunctor'])
test('T5462No1', normal, multimod_compile_fail, ['T5462No1', '-iGFunctor'])

On Wed, Nov 26, 2014 at 12:22 PM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
I?m getting this on Linux:

Unexpected failures:

   generics  T5462Yes1 [exit code non-0] (normal)



Linking T5462Yes1 ...

gcc: error: GEq/GEq1A.o: No such file or directory

gcc: error: GFunctor/GFunctor.o: No such file or directory



*** unexpected failure for T5462Yes1(normal)


But it doesn?t happen if I say ?make TEST=T5462Yes1?.

Could this be a multi-thread file deletion thing?  make TEST=T5462Yes1 runs the test 8 different ways

Simon

_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://www.haskell.org/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141126/8aa43f54/attachment.html>

From dreixel at gmail.com  Wed Nov 26 12:48:01 2014
From: dreixel at gmail.com (=?UTF-8?Q?Jos=C3=A9_Pedro_Magalh=C3=A3es?=)
Date: Wed, 26 Nov 2014 13:48:01 +0100
Subject: T5462Yes1
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3E5143@DB3PRD3001MB020.064d.mgd.msft.net>
References: <618BE556AADD624C9C918AA5D5911BEF3F3E4FCA@DB3PRD3001MB020.064d.mgd.msft.net>
 <CA+ZFbn8dOGGCuJ8teVinAZ0XAR+KEHkToWrtokKGE4NPLVZAPA@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3E5143@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CA+ZFbn8pRtxgDUQpFwQW=j7EF1ZB=jAO_AiZ6T_e2baA7xLA=Q@mail.gmail.com>

No, that was all together in one patch, 5 days ago:
https://github.com/ghc/ghc/commit/7ed482d909556c1b969185921e27e3fe30c2fe86

On Wed, Nov 26, 2014 at 1:37 PM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

>  Oh, if you did that in the last day or two, I might have missed it.
> I?ll try again
>
>
>
> *From:* josepedromagalhaes at gmail.com [mailto:josepedromagalhaes at gmail.com]
> *On Behalf Of *Jos? Pedro Magalh?es
> *Sent:* 26 November 2014 11:27
> *To:* Simon Peyton Jones
> *Cc:* ghc-devs at haskell.org
> *Subject:* Re: T5462Yes1
>
>
>
> I thought I had solved that by removing the extra-clean for GFunctor.o
> from another test, but apparently the file is still being deleted at some
> point. Note that T56462Yes1, T5462Yes2, and T5462No all use GFunctor:
>
>
>
> test('T5462Yes1', normal, multimod_compile_and_run, ['T5462Yes1', '-iGEq
> -iGEnum -iGFunctor'])
>
> test('T5462Yes2', normal, multimod_compile_and_run, ['T5462Yes2',
> '-iGFunctor'])
>
> test('T5462No1', normal, multimod_compile_fail, ['T5462No1', '-iGFunctor'])
>
>
>
> On Wed, Nov 26, 2014 at 12:22 PM, Simon Peyton Jones <
> simonpj at microsoft.com> wrote:
>
>  I?m getting this on Linux:
>
> Unexpected failures:
>
>    generics  T5462Yes1 [exit code non-0] (normal)
>
>
>
> Linking T5462Yes1 ...
>
> gcc: error: GEq/GEq1A.o: No such file or directory
>
> gcc: error: GFunctor/GFunctor.o: No such file or directory
>
>
>
> *** unexpected failure for T5462Yes1(normal)
>
>
>
> But it doesn?t happen if I say ?make TEST=T5462Yes1?.
>
>
>
> Could this be a multi-thread file deletion thing?  make TEST=T5462Yes1
> runs the test 8 different ways
>
>
>
> Simon
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141126/643ea98a/attachment.html>

From simonpj at microsoft.com  Wed Nov 26 13:18:25 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 26 Nov 2014 13:18:25 +0000
Subject: T5462Yes1
In-Reply-To: <CA+ZFbn8pRtxgDUQpFwQW=j7EF1ZB=jAO_AiZ6T_e2baA7xLA=Q@mail.gmail.com>
References: <618BE556AADD624C9C918AA5D5911BEF3F3E4FCA@DB3PRD3001MB020.064d.mgd.msft.net>
 <CA+ZFbn8dOGGCuJ8teVinAZ0XAR+KEHkToWrtokKGE4NPLVZAPA@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3E5143@DB3PRD3001MB020.064d.mgd.msft.net>
 <CA+ZFbn8pRtxgDUQpFwQW=j7EF1ZB=jAO_AiZ6T_e2baA7xLA=Q@mail.gmail.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3E6888@DB3PRD3001MB020.064d.mgd.msft.net>

OK, I?ve tried again and indeed the same thing happens. I?m not sure what to do.  For now I?m just ignoring it

Simon

From: josepedromagalhaes at gmail.com [mailto:josepedromagalhaes at gmail.com] On Behalf Of Jos? Pedro Magalh?es
Sent: 26 November 2014 12:48
To: Simon Peyton Jones
Cc: ghc-devs at haskell.org
Subject: Re: T5462Yes1

No, that was all together in one patch, 5 days ago: https://github.com/ghc/ghc/commit/7ed482d909556c1b969185921e27e3fe30c2fe86

On Wed, Nov 26, 2014 at 1:37 PM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Oh, if you did that in the last day or two, I might have missed it.  I?ll try again

From: josepedromagalhaes at gmail.com<mailto:josepedromagalhaes at gmail.com> [mailto:josepedromagalhaes at gmail.com<mailto:josepedromagalhaes at gmail.com>] On Behalf Of Jos? Pedro Magalh?es
Sent: 26 November 2014 11:27
To: Simon Peyton Jones
Cc: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Re: T5462Yes1

I thought I had solved that by removing the extra-clean for GFunctor.o from another test, but apparently the file is still being deleted at some point. Note that T56462Yes1, T5462Yes2, and T5462No all use GFunctor:

test('T5462Yes1', normal, multimod_compile_and_run, ['T5462Yes1', '-iGEq -iGEnum -iGFunctor'])
test('T5462Yes2', normal, multimod_compile_and_run, ['T5462Yes2', '-iGFunctor'])
test('T5462No1', normal, multimod_compile_fail, ['T5462No1', '-iGFunctor'])

On Wed, Nov 26, 2014 at 12:22 PM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
I?m getting this on Linux:

Unexpected failures:

   generics  T5462Yes1 [exit code non-0] (normal)



Linking T5462Yes1 ...

gcc: error: GEq/GEq1A.o: No such file or directory

gcc: error: GFunctor/GFunctor.o: No such file or directory



*** unexpected failure for T5462Yes1(normal)


But it doesn?t happen if I say ?make TEST=T5462Yes1?.

Could this be a multi-thread file deletion thing?  make TEST=T5462Yes1 runs the test 8 different ways

Simon

_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://www.haskell.org/mailman/listinfo/ghc-devs


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141126/a2e78aa0/attachment-0001.html>

From hvr at gnu.org  Wed Nov 26 14:31:15 2014
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Wed, 26 Nov 2014 15:31:15 +0100
Subject: ANNOUNCE: GHC 7.8.4 Release Candidate 1
In-Reply-To: <CANBN=mtuKsEPbiH_7VMBvLJNFnZpYDVLt7jC7GV=NHPHr-nDuw@mail.gmail.com>
 (Sven Panne's message of "Wed, 26 Nov 2014 12:40:37 +0100")
References: <CAEs96n0xY4p+fknvPL_y+6S5=XukbWmPs+VyTnam4+qH+ESYtQ@mail.gmail.com>
 <CANBN=mtuKsEPbiH_7VMBvLJNFnZpYDVLt7jC7GV=NHPHr-nDuw@mail.gmail.com>
Message-ID: <87bnnu3ufg.fsf@gnu.org>

On 2014-11-26 at 12:40:37 +0100, Sven Panne wrote:
> 2014-11-25 20:46 GMT+01:00 Austin Seipp <austin at well-typed.com>:
>> We are pleased to announce the first release candidate for GHC 7.8.4:
>>
>>     https://downloads.haskell.org/~ghc/7.8.4-rc1/ [...]
>
> Would it be possible to get the RC on
> https://launchpad.net/~hvr/+archive/ubuntu/ghc? This way one could
> easily test things on Travis CI.

I'll put a 7.8.4rc .deb up soon (probably right after the GHC 7.10
branch has been created)

From tuncer.ayaz at gmail.com  Wed Nov 26 15:52:13 2014
From: tuncer.ayaz at gmail.com (Tuncer Ayaz)
Date: Wed, 26 Nov 2014 16:52:13 +0100
Subject: Uploading a patch (without arcanist)
Message-ID: <CAOvwQ4jEegC=6KozRZyrsK8nWS1MXtONqoMQ2b3eg4wCRGuYiw@mail.gmail.com>

When trying to upload a diff with Differential's web interface,
all I see is the following error message:

--------snip--------
Unhandled Exception ("PhabricatorApplicationTransactionNoEffectException")

Transactions have no effect:
- This Revision already has that view policy.
--------snip--------

Any idea what I might have done wrong?

From austin at well-typed.com  Wed Nov 26 15:54:58 2014
From: austin at well-typed.com (Austin Seipp)
Date: Wed, 26 Nov 2014 09:54:58 -0600
Subject: Uploading a patch (without arcanist)
In-Reply-To: <CAOvwQ4jEegC=6KozRZyrsK8nWS1MXtONqoMQ2b3eg4wCRGuYiw@mail.gmail.com>
References: <CAOvwQ4jEegC=6KozRZyrsK8nWS1MXtONqoMQ2b3eg4wCRGuYiw@mail.gmail.com>
Message-ID: <CAEs96n2-J4wVbqgZBHFsnFE5AgmHJ7W8-AazRkBd3e8sG5YwSQ@mail.gmail.com>

This might be an upstream bug (we occasionally uncover them and send
them upstream). I'll ask the developers about it.

On Wed, Nov 26, 2014 at 9:52 AM, Tuncer Ayaz <tuncer.ayaz at gmail.com> wrote:
> When trying to upload a diff with Differential's web interface,
> all I see is the following error message:
>
> --------snip--------
> Unhandled Exception ("PhabricatorApplicationTransactionNoEffectException")
>
> Transactions have no effect:
> - This Revision already has that view policy.
> --------snip--------
>
> Any idea what I might have done wrong?
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From marlowsd at gmail.com  Thu Nov 27 09:36:41 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 27 Nov 2014 09:36:41 +0000
Subject: help wrt semantics / primops for pure prefetches
In-Reply-To: <CAHYVw0x=ouGBv0x=d-Rz7X0ZmxE+55obCwUjyWPwjWuEvoeo4g@mail.gmail.com>
References: <CAHYVw0x=ouGBv0x=d-Rz7X0ZmxE+55obCwUjyWPwjWuEvoeo4g@mail.gmail.com>
Message-ID: <5476F0A9.7080208@gmail.com>

I haven't been watching this, but I have one question: does prefetching 
actually *work*?  Do you have benchmarks (or better still, actual 
library/application code) that show some improvement?  I admit to being 
slightly sceptical - when I've tried using prefetching in the GC it has 
always been a struggle to get something that shows an improvement, and 
even when I get things tuned on one machine it typically makes things 
slower on a different processor.  And that's in the GC, doing it at the 
Haskell level should be even harder.

Cheers,
Simon

On 22/11/2014 05:43, Carter Schonwald wrote:
> Hey Everyone,
> in
> https://ghc.haskell.org/trac/ghc/ticket/9353
> and
> https://phabricator.haskell.org/D350
>
> is some preliminary work to fix up how the pure versions of the prefetch
> primops work is laid out and prototyped.
>
> However, while it nominally fixes up some of the problems with how the
> current pure prefetch apis are fundamentally borken,  the simple design
> in D350 isn't quite ideal, and i sketch out some other ideas in the
> associated ticket #9353
>
> I'd like to make sure  pure prefetch in 7.10 is slightly less broken
> than in 7.8, but either way, its pretty clear that working out the right
> fixed up design wont happen till 7.12. Ie, whatever makes 7.10, there
> WILL have to be breaking changes to fix those primops for 7.12
>
> thanks and any feedback / thoughts appreciated
> -Carter
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From marlowsd at gmail.com  Thu Nov 27 08:54:25 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 27 Nov 2014 08:54:25 +0000
Subject: Keeping the "Newcomers" wiki page alive
In-Reply-To: <201411130844.00005.jan.stolarek@p.lodz.pl>
References: <201411121358.48239.jan.stolarek@p.lodz.pl>
 <CAMLKBUF3A2eNgeULeSsLxfhLdY55DSjf1bj9vFv92mA4bUJd4Q@mail.gmail.com>
 <2B8AC8E6-1222-4BC2-99ED-60EB02EAC3E6@cis.upenn.edu>
 <201411130844.00005.jan.stolarek@p.lodz.pl>
Message-ID: <5476E6C1.1020702@gmail.com>

On 13/11/2014 07:43, Jan Stolarek wrote:
> I believe that current difficulty field is intended to mean "the amount of time required by
> someone who already knows what to do". Obviously, that's not the metric that we want to use for
> labelling newcomer-friendly tasks. (I wonder if the difficulty field in its current form is even
> useful to us?)
>
> Obviously, the metric that we want is "the amount of code familiarity required to fix a bug". For
> newcommers we probably want tickets that require knowledge of <1000 lines of code.
>
> I think the important questions are:
>
> 1. Do we find the current "difficulty" field useful?
> 2. Should we have a Trac field to label accessibility for newcomers?
>
> My answers are:
> 1. No.

We could remove the Difficulty field, given that it hasn't really been 
useful and it can be subsumed by the keywords field for the things we 
want it for.  It was originally intended to help (a) new developers find 
tickets to work on, and (b) help us find good projects for the GSoc. 
Both of which can be keywords, so I'd be happy to get rid of Difficulty.

Cheers,
Simon



> 2. Yes, we should have a filed with accessibility levels like:
> newcomer/intermediate/advanced/rocket science.
>
> If we have 2) then we can have a list of tickets in the Newcomers page generated dynamically.
>
> Janek
>
> Dnia czwartek, 13 listopada 2014, Richard Eisenberg napisa?:
>> Forgive me if I'm repeating others' comments, but the newcomer label, to
>> me, is independent of level of difficulty -- it has much more to do with
>> how "messy" the work is, I think.
>>
>> I'll make a concrete proposal: Tag appropriate bugs/feature requests with
>> "newcomer" and, if you want, mention that you'll mentor in a comment. I
>> don't think there's a glaring need to be able to search by mentor, so I'm
>> not proposing a Trac field for that.
>>
>> If I see here that a few others will adopt this proposal, I'll start doing
>> it -- I already have several tickets in mind.
>>
>> Richard
>>
>> On Nov 12, 2014, at 6:27 PM, Isaac Hollander McCreery <ihmccreery at gmail.com> wrote:
>>> Glad people are excited about this,
>>>
>>> I like "beginner/intermediate/advanced".  I think it's more accurate than
>>> "easy/hard" and clearer than "accessible", "welcoming", etc.
>>>
>>> I also want to call out the "mentor" label that the Rust team is using:
>>> experienced devs nominate themselves as mentors on projects, then
>>> newcomers can tackle them with some support.  As a newcomer, that's
>>> *extremely* appealing to me.
>>>
>>> Cheers,
>>> Ike
>>>
>>> On Wed, Nov 12, 2014 at 2:34 PM, Brandon Allbery <allbery.b at gmail.com>
>>> wrote: On Wed, Nov 12, 2014 at 5:32 PM, Joachim Breitner
>>> <mail at joachim-breitner.de> wrote: The quality that we are looking for is
>>> ?tacklabe by a newcomer?, i.e. not requiring too deep knowledge of GHC.
>>> Is there a nice word for that? I found ?accessible?, ?welcoming?,
>>> ?appealing? ? anything that sounds good in native English speaker?s ears?
>>> :-)
>>>
>>> Various projects I'm involved with use
>>>
>>> difficulty: beginner (or just "beginner")
>>> babydev-bait (!)
>>> newcomer (several use "newbie" but I do not recommend that label)
>>>
>>> --
>>> brandon s allbery kf8nh                               sine nomine
>>> associates allbery.b at gmail.com
>>> ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad
>>>       http://sinenomine.net
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

From ekmett at gmail.com  Thu Nov 27 10:20:49 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 27 Nov 2014 05:20:49 -0500
Subject: help wrt semantics / primops for pure prefetches
In-Reply-To: <5476F0A9.7080208@gmail.com>
References: <CAHYVw0x=ouGBv0x=d-Rz7X0ZmxE+55obCwUjyWPwjWuEvoeo4g@mail.gmail.com>
 <5476F0A9.7080208@gmail.com>
Message-ID: <CAJumaK8KFOYCasw0XwRiL_fexWacNHOjOXaU3jNRjwO2d-+hxw@mail.gmail.com>

My general experience with prefetching is that it is almost never a win
when done just on trees, as in the usual mark-sweep or copy-collection
garbage collector walk. Why? Because the time from the time you prefetch to
the time you use the data is too variable. Stack disciplines and prefetch
don't mix nicely.

If you want to see a win out of it you have to free up some of the ordering
of your walk, and tweak your whole application to support it. e.g. if you
want to use prefetching in garbage collection, the way to do it is to
switch from a strict stack discipline to using a small fixed-sized queue on
the output of the stack, then feed prefetch on the way into the queue
rather than as you walk the stack. That paid out for me as a 10-15% speedup
last time I used it after factoring in the overhead of the extra queue. Not
too bad for a weekend project. =)

Without that sort of known lead-in time, it works out that prefetching is
usually a net loss or vanishes into the noise.

As for the array ops, davean has a couple of cases w/ those for which the
prefetching operations are a 20-25% speedup, which is what motivated Carter
to start playing around with these again. I don't know off hand how easily
those can be turned into public test cases though.

-Edward

On Thu, Nov 27, 2014 at 4:36 AM, Simon Marlow <marlowsd at gmail.com> wrote:

> I haven't been watching this, but I have one question: does prefetching
> actually *work*?  Do you have benchmarks (or better still, actual
> library/application code) that show some improvement?  I admit to being
> slightly sceptical - when I've tried using prefetching in the GC it has
> always been a struggle to get something that shows an improvement, and even
> when I get things tuned on one machine it typically makes things slower on
> a different processor.  And that's in the GC, doing it at the Haskell level
> should be even harder.
>
> Cheers,
> Simon
>
>
> On 22/11/2014 05:43, Carter Schonwald wrote:
>
>> Hey Everyone,
>> in
>> https://ghc.haskell.org/trac/ghc/ticket/9353
>> and
>> https://phabricator.haskell.org/D350
>>
>> is some preliminary work to fix up how the pure versions of the prefetch
>> primops work is laid out and prototyped.
>>
>> However, while it nominally fixes up some of the problems with how the
>> current pure prefetch apis are fundamentally borken,  the simple design
>> in D350 isn't quite ideal, and i sketch out some other ideas in the
>> associated ticket #9353
>>
>> I'd like to make sure  pure prefetch in 7.10 is slightly less broken
>> than in 7.8, but either way, its pretty clear that working out the right
>> fixed up design wont happen till 7.12. Ie, whatever makes 7.10, there
>> WILL have to be breaking changes to fix those primops for 7.12
>>
>> thanks and any feedback / thoughts appreciated
>> -Carter
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>  _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141127/64ba0ba0/attachment.html>

From simonpj at microsoft.com  Thu Nov 27 17:03:22 2014
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 27 Nov 2014 17:03:22 +0000
Subject: let app invariant failure, HALP Re: how to write a ghc primop
 that acts on an unevaluated argument?
In-Reply-To: <CAHYVw0zTi63QGMQBsLKJYpOEtoPWver4K2xXBfXu7A5gyBCUtw@mail.gmail.com>
References: <CAHYVw0yNm+2TRv=8v0ngqrLdSQycWgDQiYNay0F6ky6p-3gJUw@mail.gmail.com>
 <CAHYVw0zHaW6R=txyZzoPWkNq8t2RDZ_rSg6N0PHzMHz=nnTGrw@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3DE67E@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAHYVw0xF0Wv8FVAZQ3AbAkax=Htyhv68RX6D4NMsn7j+tvSwBQ@mail.gmail.com>
 <CAHYVw0wzQxATm2XmZ1mLCx3rc-rsiLuv4BAiGVqCEWUv424Qug@mail.gmail.com>
 <CAHYVw0zTi63QGMQBsLKJYpOEtoPWver4K2xXBfXu7A5gyBCUtw@mail.gmail.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F3ED08A@DB3PRD3001MB020.064d.mgd.msft.net>

are you quite sure you did ?dverbose-core2core ?ddump-occur-anal?   I see none of that output in the file.

Regardless of  the flags you set for the primop, I?m surprised that the invariant is invalidated.  Should not happen.

As well as the revised output, could you enclose a snippet of primops.txt.pp for prefetchValue1,2,3#

S

From: Carter Schonwald [mailto:carter.schonwald at gmail.com]
Sent: 25 November 2014 06:47
To: Simon Peyton Jones
Cc: Edward Kmett; ghc-devs at haskell.org; Joachim Breitner
Subject: Re: let app invariant failure, HALP Re: how to write a ghc primop that acts on an unevaluated argument?

ok attached is the log of
./inplace/bin/ghc-stage2 codetester.hs  -O2 -dcore-lint  -fforce-recomp -ddump-simpl -ddump-to-file -dverbose-core2core -ddump-occur-anal -ddump-inlinings  > output ^&1


the relevant snippet is bellow.

It looks like the Float-Out transformation is what tripping it.


That said, reading through what the semantics are implied by has_side_effects = True, the prefetch* family of operations ARE side effectful with respect the fact that they DO modify the CPU cache in a way that changes what memory locations are in various levels of CPU cache, so despite seeming read-like, they are modifying the state of the system, just in a way that is ONLY visible wrt the performance characteristics/runtime  of the resulting program.

specifically, Duplication, Floating out, and Specultive evaluation all change *when* the prefetch runs and changes the CPU state, and Discard means this "mutation" of the CPU cache state would not happen.

if prefetch was pure semantically (ie equiv to a -> ()  ) , they'd just be no op, they're exclusively a tool for performance engineering, and accordingly when and where they appear in code matters!

i'm more than happy to write out a more detailed version of this explanation somewhere if you like.

-Carter

""""

*** Core Linted result of Simplifier:
*** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}):
*** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}):
*** Core Lint errors : in result of Float out(FOS {Lam = Just 0,
                                                   Consts = True,
                                                   OverSatApps = True}) ***
<no location info>: Warning:
    In the expression: prefetchValue2#
                         @ [Char]
                         @ RealWorld
                         lvl_s3Oi
                         (prefetchValue1#
                            @ Int
                            @ RealWorld
                            lvl_s3Oj
                            (prefetchAddr3# @ RealWorld ds1_a3zg 0 ds_a3zf))
    This argument does not satisfy the let/app invariant:
      prefetchValue1#
        @ Int
        @ RealWorld
        lvl_s3Oj


"""



On Mon, Nov 24, 2014 at 10:43 PM, Carter Schonwald <carter.schonwald at gmail.com<mailto:carter.schonwald at gmail.com>> wrote:
huh, apparently i was mixing up '-' and some other similar dash character, time to let my rebuild of ghc go through then try gain :)

On Mon, Nov 24, 2014 at 10:37 PM, Carter Schonwald <carter.schonwald at gmail.com<mailto:carter.schonwald at gmail.com>> wrote:
when i run
./inplace/bin/ghc-stage2 codetester.hs  -O2 -dcore-lint -S  -fforce-recomp -ddump-simpl -ddump-to-file ?dverbose-core2core ?ddump-occur-anal ?ddump-inlinings
i get
target ??dverbose-core2core? is not a module name or a source file

what am I doing wrong in this CLI invocation?

On Mon, Nov 24, 2014 at 10:23 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Carter

That smells wrong to me.  These flags have a very carefully defined meaning; see
            Note [PrimOp can_fail and has_side_effects]
in PrimOp.lhs

If you say it has side effects when it doesn?t, you?ll confuse your successor reading the code in five years time.

Better to find out what is going on and why.  Might you do that? What transformation invalidates the let/app invariant?  Make a small test case, use ?dverbose-core2core ?ddump-occur-anal ?ddump-inlinings.  I would far rather that than install a land-mine in the code.

Simon

From: Carter Schonwald [mailto:carter.schonwald at gmail.com<mailto:carter.schonwald at gmail.com>]
Sent: 24 November 2014 00:54
To: Edward Kmett
Cc: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>; Simon Peyton Jones; Joachim Breitner
Subject: Re: let app invariant failure, HALP Re: how to write a ghc primop that acts on an unevaluated argument?

woot, solved it, at least in a way thats OK for now.

if I mark the prefetchValue operations as has_side_effects=True, the core lint failure goes away! I'm not sure if thats the right semantics in the long term, but it does give me a simple way to make sure it works safely for 7.10

pardon all the noise
-Carter

On Sun, Nov 23, 2014 at 4:26 PM, Carter Schonwald <carter.schonwald at gmail.com<mailto:carter.schonwald at gmail.com>> wrote:
ok, i'm getting a let/app invariant failure when i build my test case with O1 or O2 but not without

http://lpaste.net/114881

any help would be appreciated on how to address that

On Sun, Nov 23, 2014 at 4:13 PM, Carter Schonwald <carter.schonwald at gmail.com<mailto:carter.schonwald at gmail.com>> wrote:
yup, i have that!

    wrapFetch prefetchValue0# (error "this shouldn't get evaluated")

in the test suite!

in contrast
    wrapFetch prefetchValue0# $! (error "this shouldn't get evaluated") does explode

shall I add a "should fail" test with the latter? (it doesn't seem worthwhile)

On Sun, Nov 23, 2014 at 3:53 PM, Edward Kmett <ekmett at gmail.com<mailto:ekmett at gmail.com>> wrote:
Maybe test for laziness in the argument by just putting something in that goes boom when forced, e.g. 'undefined'?


On Sun, Nov 23, 2014 at 2:04 PM, Carter Schonwald <carter.schonwald at gmail.com<mailto:carter.schonwald at gmail.com>> wrote:
Hey All,
as part of trying to get some fixups for how prefetch works into 7.10,
i'm adding a "prefetchValue" primop that prefetchs the memory location of a lifted heap value

namely

several operations of the following form

primop PrefetchValueOp1 "prefetchValue1#" GenPrimOp
   a -> State# s -> State# s
   with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd] topRes }

I'd like some feedback on the strictness information design by someone who's familiar with how that piece of GHC. the idea being that prefetchValue is lazy in its polymorphic argument (it doesn't force it, it just does a prefetch on the heap location, which may or may not be evaluated).

https://phabricator.haskell.org/D350

is the code in question. And i *believe* i'm testing for being lazy in that argument correctly.

thoughts?

many thanks!
-Carter


_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://www.haskell.org/mailman/listinfo/ghc-devs







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141127/4cd19e6b/attachment-0001.html>

From davean at xkcd.com  Thu Nov 27 17:07:32 2014
From: davean at xkcd.com (davean)
Date: Thu, 27 Nov 2014 12:07:32 -0500
Subject: help wrt semantics / primops for pure prefetches
In-Reply-To: <CAJumaK8KFOYCasw0XwRiL_fexWacNHOjOXaU3jNRjwO2d-+hxw@mail.gmail.com>
References: <CAHYVw0x=ouGBv0x=d-Rz7X0ZmxE+55obCwUjyWPwjWuEvoeo4g@mail.gmail.com>
 <5476F0A9.7080208@gmail.com>
 <CAJumaK8KFOYCasw0XwRiL_fexWacNHOjOXaU3jNRjwO2d-+hxw@mail.gmail.com>
Message-ID: <CABFs2VjewSUV9mtuNBe9pXKtR8-oOwgL_RM67GkgkU85H6ufCA@mail.gmail.com>

Actually, he was already working on them. I just joined him because I've
wanted to have them for a while too.

I don't have a real example using the prefetch (we just got it working!)
but I do have the test case we used to make sure they were implemented
correctly.

The code is http://lpaste.net/4551930812748005376 (I recommend using llvm
when testing this but it shows the improvement either way) and, two
separate runs of 5 times each:

http://lpaste.net/5476270150657245184
http://lpaste.net/1229927210207412224

The first prefetches the location we're just about to look at, the second
prefetches 10 lookups ahead. Its completely untunned, the GC seems to throw
a bunch of garbage into the nursery but the prefetch version is notably
faster.
We were just using this to make sure the implementation worked so we didn't
put too much effort into it. Originally we were working with binary search
and speculative look-ahead, but that was far harder to maintain as the
prefetch ops changed. (A bundled binary search is a lot easier of course)
Sadly the early binary search results are of no use because in their early
form using them created massive nursery garbage pressure when in pure code.
We had one (very briefly) in IO I believe but I lack any information on it.

Yes - using prefetch well is hard. Yes - the optimal use of prefetch
depends on the exact CPU and memory you have.
The best way to deal with this is of course to plan for it and that can be
warranted with some code. Code that does a lot of random access but doesn't
use too much memory bandwidth can be fairly tolerant to prefetch distance
though. For example the demo should drop to near-optimal quickly and its
performance should take quite a while to start dropping again. I believe on
my system the "nearly optimal" range was around 5 untill around 40.
One nice version of a prefetch that I talked to Carter about was "stick the
prefetch approximately the right number of instructions ahead of here" I
expect that is too complicated to implement though.

As we don't have thunk prefetchers currently (sad), I can't give you a demo
showing a speed up in the containers package, but I could write the bundled
binary search demo for you if you like.

On Thu, Nov 27, 2014 at 5:20 AM, Edward Kmett <ekmett at gmail.com> wrote:

> My general experience with prefetching is that it is almost never a win
> when done just on trees, as in the usual mark-sweep or copy-collection
> garbage collector walk. Why? Because the time from the time you prefetch to
> the time you use the data is too variable. Stack disciplines and prefetch
> don't mix nicely.
>
> If you want to see a win out of it you have to free up some of the
> ordering of your walk, and tweak your whole application to support it. e.g.
> if you want to use prefetching in garbage collection, the way to do it is
> to switch from a strict stack discipline to using a small fixed-sized queue
> on the output of the stack, then feed prefetch on the way into the queue
> rather than as you walk the stack. That paid out for me as a 10-15% speedup
> last time I used it after factoring in the overhead of the extra queue. Not
> too bad for a weekend project. =)
>
> Without that sort of known lead-in time, it works out that prefetching is
> usually a net loss or vanishes into the noise.
>
> As for the array ops, davean has a couple of cases w/ those for which the
> prefetching operations are a 20-25% speedup, which is what motivated Carter
> to start playing around with these again. I don't know off hand how easily
> those can be turned into public test cases though.
>
> -Edward
>
> On Thu, Nov 27, 2014 at 4:36 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> I haven't been watching this, but I have one question: does prefetching
>> actually *work*?  Do you have benchmarks (or better still, actual
>> library/application code) that show some improvement?  I admit to being
>> slightly sceptical - when I've tried using prefetching in the GC it has
>> always been a struggle to get something that shows an improvement, and even
>> when I get things tuned on one machine it typically makes things slower on
>> a different processor.  And that's in the GC, doing it at the Haskell level
>> should be even harder.
>>
>> Cheers,
>> Simon
>>
>>
>> On 22/11/2014 05:43, Carter Schonwald wrote:
>>
>>> Hey Everyone,
>>> in
>>> https://ghc.haskell.org/trac/ghc/ticket/9353
>>> and
>>> https://phabricator.haskell.org/D350
>>>
>>> is some preliminary work to fix up how the pure versions of the prefetch
>>> primops work is laid out and prototyped.
>>>
>>> However, while it nominally fixes up some of the problems with how the
>>> current pure prefetch apis are fundamentally borken,  the simple design
>>> in D350 isn't quite ideal, and i sketch out some other ideas in the
>>> associated ticket #9353
>>>
>>> I'd like to make sure  pure prefetch in 7.10 is slightly less broken
>>> than in 7.8, but either way, its pretty clear that working out the right
>>> fixed up design wont happen till 7.12. Ie, whatever makes 7.10, there
>>> WILL have to be breaking changes to fix those primops for 7.12
>>>
>>> thanks and any feedback / thoughts appreciated
>>> -Carter
>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>  _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141127/9706d302/attachment.html>

From tuncer.ayaz at gmail.com  Thu Nov 27 17:32:47 2014
From: tuncer.ayaz at gmail.com (Tuncer Ayaz)
Date: Thu, 27 Nov 2014 18:32:47 +0100
Subject: superfluous ghc --make log?
Message-ID: <CAOvwQ4hhyyADAA4-FjxKT9weEKB-swBOw_QFxsyDm8q0G9EdTA@mail.gmail.com>

This is a very minor "issue", but I've been wondering if there's
a rationale behind ghc --make pretty much printing the same thing
thrice.

Say you're building Cabal, you'll see (line wrapped for email):
[ 1 of 75] Compiling Distribution.Compat.CreatePipe
( Distribution/Compat/CreatePipe.hs, Distribution/Compat/CreatePipe.o )

So, why not print
[ 1 of 75] Compiling Distribution.Compat.CreatePipe
instead?

I'm assuming there's a good reason for the current behavior, but
if there's none, are there any objections to changing what's
printed? Of course, the old behavior could be re-enabled via -v.

From hvriedel at gmail.com  Thu Nov 27 18:01:34 2014
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Thu, 27 Nov 2014 19:01:34 +0100
Subject: superfluous ghc --make log?
In-Reply-To: <CAOvwQ4hhyyADAA4-FjxKT9weEKB-swBOw_QFxsyDm8q0G9EdTA@mail.gmail.com>
 (Tuncer Ayaz's message of "Thu, 27 Nov 2014 18:32:47 +0100")
References: <CAOvwQ4hhyyADAA4-FjxKT9weEKB-swBOw_QFxsyDm8q0G9EdTA@mail.gmail.com>
Message-ID: <87bnnsa5fl.fsf@gmail.com>

On 2014-11-27 at 18:32:47 +0100, Tuncer Ayaz wrote:
> This is a very minor "issue", but I've been wondering if there's
> a rationale behind ghc --make pretty much printing the same thing
> thrice.

IMO it isn't the "same" thing that's printed thrice. If you
e.g. compile `transformers`, you'd get the following output:

Preprocessing library transformers-0.4.2.0...
[ 1 of 28] Compiling Data.Functor.Identity ( oldsrc/Data/Functor/Identity.hs, dist/build/Data/Functor/Identity.o )
[ 2 of 28] Compiling Control.Monad.Trans.Class ( Control/Monad/Trans/Class.hs, dist/build/Control/Monad/Trans/Class.o )
[ 3 of 28] Compiling Control.Monad.Signatures ( Control/Monad/Signatures.hs, dist/build/Control/Monad/Signatures.o )
...

there you'd see the two pathnames are not necessarily directly derivable
from the module name, but depend on additional flags given to `ghc`...

So it does indeed provide additional information about what GHC is
doing. Btw, this also tells you whether a .hs file or a .lhs file was
picked up.

As to whether it's too noisy for the default verbosity level, I have no
opinion (yet)...

Cheers,
  hvr

From carter.schonwald at gmail.com  Thu Nov 27 18:25:58 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 27 Nov 2014 13:25:58 -0500
Subject: let app invariant failure, HALP Re: how to write a ghc primop
 that acts on an unevaluated argument?
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3ED08A@DB3PRD3001MB020.064d.mgd.msft.net>
References: <CAHYVw0yNm+2TRv=8v0ngqrLdSQycWgDQiYNay0F6ky6p-3gJUw@mail.gmail.com>
 <CAHYVw0zHaW6R=txyZzoPWkNq8t2RDZ_rSg6N0PHzMHz=nnTGrw@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3DE67E@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAHYVw0xF0Wv8FVAZQ3AbAkax=Htyhv68RX6D4NMsn7j+tvSwBQ@mail.gmail.com>
 <CAHYVw0wzQxATm2XmZ1mLCx3rc-rsiLuv4BAiGVqCEWUv424Qug@mail.gmail.com>
 <CAHYVw0zTi63QGMQBsLKJYpOEtoPWver4K2xXBfXu7A5gyBCUtw@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3ED08A@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CAHYVw0zGx7WeM3hOGSOYRtBz_0jV=g99rxGo0eqBGEP7W6R3ig@mail.gmail.com>

ok,
the attached "output" file was made  using the following command
./inplace/bin/ghc-stage2 T8256.hs   -O2 -dcore-lint  -fforce-recomp
-ddump-simpl  -dverbose-core2core -ddump-occur-anal -ddump-inlinings  >
output ^&1

i've also attached the test hs file i used

the primop definitions i used were :

primop PrefetchValueOp0 "prefetchValue0#" GenPrimOp
   a -> State# s -> State# s
   with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd]
topRes }


primop PrefetchValueOp1 "prefetchValue1#" GenPrimOp
   a -> State# s -> State# s
   with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd]
topRes }


primop PrefetchValueOp2 "prefetchValue2#" GenPrimOp
   a ->  State# s -> State# s
   with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd]
topRes }


primop PrefetchValueOp3 "prefetchValue3#" GenPrimOp
   a -> State# s -> State# s
   with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd]
topRes }



(the idea of those strictness attributes is that the operations should be
lazy in their value arg)

thanks!
-Carter


On Thu, Nov 27, 2014 at 12:03 PM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

>  are you quite sure you did ?dverbose-core2core ?ddump-occur-anal?   I
> see none of that output in the file.
>
>
>
> Regardless of  the flags you set for the primop, I?m surprised that the
> invariant is invalidated.  Should not happen.
>
>
>
> As well as the revised output, could you enclose a snippet of
> primops.txt.pp for prefetchValue1,2,3#
>
>
>
> S
>
>
>
> *From:* Carter Schonwald [mailto:carter.schonwald at gmail.com]
> *Sent:* 25 November 2014 06:47
> *To:* Simon Peyton Jones
> *Cc:* Edward Kmett; ghc-devs at haskell.org; Joachim Breitner
>
> *Subject:* Re: let app invariant failure, HALP Re: how to write a ghc
> primop that acts on an unevaluated argument?
>
>
>
> ok attached is the log of
>
> ./inplace/bin/ghc-stage2 codetester.hs  -O2 -dcore-lint  -fforce-recomp
> -ddump-simpl -ddump-to-file -dverbose-core2core -ddump-occur-anal
> -ddump-inlinings  > output ^&1
>
>
>
>
>
> the relevant snippet is bellow.
>
>
>
> It looks like the Float-Out transformation is what tripping it.
>
>
>
>
>
> That said, reading through what the semantics are implied by
> has_side_effects = True, the prefetch* family of operations ARE side
> effectful with respect the fact that they DO modify the CPU cache in a way
> that changes what memory locations are in various levels of CPU cache, so
> despite seeming read-like, they are modifying the state of the system, just
> in a way that is ONLY visible wrt the performance characteristics/runtime
>  of the resulting program.
>
>
>
> specifically, Duplication, Floating out, and Specultive evaluation all
> change *when* the prefetch runs and changes the CPU state, and Discard
> means this "mutation" of the CPU cache state would not happen.
>
>
>
> if prefetch was pure semantically (ie equiv to a -> ()  ) , they'd just be
> no op, they're exclusively a tool for performance engineering, and
> accordingly when and where they appear in code matters!
>
>
>
> i'm more than happy to write out a more detailed version of this
> explanation somewhere if you like.
>
>
>
> -Carter
>
>
>
> """"
>
>
>
> *** Core Linted result of Simplifier:
>
> *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}):
>
> *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True,
> OverSatApps = True}):
>
> *** Core Lint errors : in result of Float out(FOS {Lam = Just 0,
>
>                                                    Consts = True,
>
>                                                    OverSatApps = True}) ***
>
> <no location info>: Warning:
>
>     In the expression: prefetchValue2#
>
>                          @ [Char]
>
>                          @ RealWorld
>
>                          lvl_s3Oi
>
>                          (prefetchValue1#
>
>                             @ Int
>
>                             @ RealWorld
>
>                             lvl_s3Oj
>
>                             (prefetchAddr3# @ RealWorld ds1_a3zg 0
> ds_a3zf))
>
>     This argument does not satisfy the let/app invariant:
>
>       prefetchValue1#
>
>         @ Int
>
>         @ RealWorld
>
>         lvl_s3Oj
>
>
>
>
>
> """
>
>
>
>
>
>
>
> On Mon, Nov 24, 2014 at 10:43 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>  huh, apparently i was mixing up '-' and some other similar dash
> character, time to let my rebuild of ghc go through then try gain :)
>
>
>
> On Mon, Nov 24, 2014 at 10:37 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>  when i run
>
> ./inplace/bin/ghc-stage2 codetester.hs  -O2 -dcore-lint -S  -fforce-recomp
> -ddump-simpl -ddump-to-file ?dverbose-core2core ?ddump-occur-anal
> ?ddump-inlinings
>
> i get
>
> target ??dverbose-core2core? is not a module name or a source file
>
>
>
> what am I doing wrong in this CLI invocation?
>
>
>
> On Mon, Nov 24, 2014 at 10:23 AM, Simon Peyton Jones <
> simonpj at microsoft.com> wrote:
>
>  Carter
>
>
>
> That smells wrong to me.  These flags have a very carefully defined
> meaning; see
>
>             Note [PrimOp can_fail and has_side_effects]
>
> in PrimOp.lhs
>
>
>
> If you say it has side effects when it doesn?t, you?ll confuse your
> successor reading the code in five years time.
>
>
>
> Better to find out what is going on and why.  Might you do that? What
> transformation invalidates the let/app invariant?  Make a small test case,
> use ?dverbose-core2core ?ddump-occur-anal ?ddump-inlinings.  I would far
> rather that than install a land-mine in the code.
>
>
>
> Simon
>
>
>
> *From:* Carter Schonwald [mailto:carter.schonwald at gmail.com]
> *Sent:* 24 November 2014 00:54
> *To:* Edward Kmett
> *Cc:* ghc-devs at haskell.org; Simon Peyton Jones; Joachim Breitner
> *Subject:* Re: let app invariant failure, HALP Re: how to write a ghc
> primop that acts on an unevaluated argument?
>
>
>
> woot, solved it, at least in a way thats OK for now.
>
>
>
> if I mark the prefetchValue operations as has_side_effects=True, the core
> lint failure goes away! I'm not sure if thats the right semantics in the
> long term, but it does give me a simple way to make sure it works safely
> for 7.10
>
>
>
> pardon all the noise
>
> -Carter
>
>
>
> On Sun, Nov 23, 2014 at 4:26 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>  ok, i'm getting a let/app invariant failure when i build my test case
> with O1 or O2 but not without
>
>
>
> http://lpaste.net/114881
>
>
>
> any help would be appreciated on how to address that
>
>
>
> On Sun, Nov 23, 2014 at 4:13 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>  yup, i have that!
>
>
>
>     wrapFetch prefetchValue0# (error "this shouldn't get evaluated")
>
>
>
> in the test suite!
>
>
>
> in contrast
>
>     wrapFetch prefetchValue0# $! (error "this shouldn't get evaluated")
> does explode
>
>
>
> shall I add a "should fail" test with the latter? (it doesn't seem
> worthwhile)
>
>
>
> On Sun, Nov 23, 2014 at 3:53 PM, Edward Kmett <ekmett at gmail.com> wrote:
>
>  Maybe test for laziness in the argument by just putting something in
> that goes boom when forced, e.g. 'undefined'?
>
>
>
>
>
> On Sun, Nov 23, 2014 at 2:04 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>   Hey All,
>
> as part of trying to get some fixups for how prefetch works into 7.10,
>
> i'm adding a "prefetchValue" primop that prefetchs the memory location of
> a lifted heap value
>
>
>
> namely
>
>
>
> several operations of the following form
>
>
>
> primop PrefetchValueOp1 "prefetchValue1#" GenPrimOp
>
>    a -> State# s -> State# s
>
>    with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd]
> topRes }
>
>
>
> I'd like some feedback on the strictness information design by someone
> who's familiar with how that piece of GHC. the idea being that
> prefetchValue is lazy in its polymorphic argument (it doesn't force it, it
> just does a prefetch on the heap location, which may or may not be
> evaluated).
>
>
>
> https://phabricator.haskell.org/D350
>
>
>
> is the code in question. And i *believe* i'm testing for being lazy in
> that argument correctly.
>
>
>
> thoughts?
>
>
>
> many thanks!
>
> -Carter
>
>
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141127/ea4b9e8a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: output
Type: application/octet-stream
Size: 279598 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141127/ea4b9e8a/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: T8256.hs
Type: application/octet-stream
Size: 953 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141127/ea4b9e8a/attachment-0003.obj>

From carter.schonwald at gmail.com  Thu Nov 27 22:37:45 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 27 Nov 2014 17:37:45 -0500
Subject: let app invariant failure, HALP Re: how to write a ghc primop
 that acts on an unevaluated argument?
In-Reply-To: <CAHYVw0zGx7WeM3hOGSOYRtBz_0jV=g99rxGo0eqBGEP7W6R3ig@mail.gmail.com>
References: <CAHYVw0yNm+2TRv=8v0ngqrLdSQycWgDQiYNay0F6ky6p-3gJUw@mail.gmail.com>
 <CAHYVw0zHaW6R=txyZzoPWkNq8t2RDZ_rSg6N0PHzMHz=nnTGrw@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3DE67E@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAHYVw0xF0Wv8FVAZQ3AbAkax=Htyhv68RX6D4NMsn7j+tvSwBQ@mail.gmail.com>
 <CAHYVw0wzQxATm2XmZ1mLCx3rc-rsiLuv4BAiGVqCEWUv424Qug@mail.gmail.com>
 <CAHYVw0zTi63QGMQBsLKJYpOEtoPWver4K2xXBfXu7A5gyBCUtw@mail.gmail.com>
 <618BE556AADD624C9C918AA5D5911BEF3F3ED08A@DB3PRD3001MB020.064d.mgd.msft.net>
 <CAHYVw0zGx7WeM3hOGSOYRtBz_0jV=g99rxGo0eqBGEP7W6R3ig@mail.gmail.com>
Message-ID: <CAHYVw0zGh4J8ZWyPufj9FdBJ2h5v2c2+xmcFWrBMkmkvnc7iig@mail.gmail.com>

The version of the test hs file I attached might include the use of a
prefetch byte array primop. If so, commenting it out might suffice for
using it as a test case.  I'll re email a corrected version later tonight
of need be. Currently amidst family travel.
On Nov 27, 2014 1:25 PM, "Carter Schonwald" <carter.schonwald at gmail.com>
wrote:

> ok,
> the attached "output" file was made  using the following command
> ./inplace/bin/ghc-stage2 T8256.hs   -O2 -dcore-lint  -fforce-recomp
> -ddump-simpl  -dverbose-core2core -ddump-occur-anal -ddump-inlinings  >
> output ^&1
>
> i've also attached the test hs file i used
>
> the primop definitions i used were :
>
> primop PrefetchValueOp0 "prefetchValue0#" GenPrimOp
>    a -> State# s -> State# s
>    with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd]
> topRes }
>
>
> primop PrefetchValueOp1 "prefetchValue1#" GenPrimOp
>    a -> State# s -> State# s
>    with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd]
> topRes }
>
>
> primop PrefetchValueOp2 "prefetchValue2#" GenPrimOp
>    a ->  State# s -> State# s
>    with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd]
> topRes }
>
>
> primop PrefetchValueOp3 "prefetchValue3#" GenPrimOp
>    a -> State# s -> State# s
>    with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd]
> topRes }
>
>
>
> (the idea of those strictness attributes is that the operations should be
> lazy in their value arg)
>
> thanks!
> -Carter
>
>
> On Thu, Nov 27, 2014 at 12:03 PM, Simon Peyton Jones <
> simonpj at microsoft.com> wrote:
>
>>  are you quite sure you did ?dverbose-core2core ?ddump-occur-anal?   I
>> see none of that output in the file.
>>
>>
>>
>> Regardless of  the flags you set for the primop, I?m surprised that the
>> invariant is invalidated.  Should not happen.
>>
>>
>>
>> As well as the revised output, could you enclose a snippet of
>> primops.txt.pp for prefetchValue1,2,3#
>>
>>
>>
>> S
>>
>>
>>
>> *From:* Carter Schonwald [mailto:carter.schonwald at gmail.com]
>> *Sent:* 25 November 2014 06:47
>> *To:* Simon Peyton Jones
>> *Cc:* Edward Kmett; ghc-devs at haskell.org; Joachim Breitner
>>
>> *Subject:* Re: let app invariant failure, HALP Re: how to write a ghc
>> primop that acts on an unevaluated argument?
>>
>>
>>
>> ok attached is the log of
>>
>> ./inplace/bin/ghc-stage2 codetester.hs  -O2 -dcore-lint  -fforce-recomp
>> -ddump-simpl -ddump-to-file -dverbose-core2core -ddump-occur-anal
>> -ddump-inlinings  > output ^&1
>>
>>
>>
>>
>>
>> the relevant snippet is bellow.
>>
>>
>>
>> It looks like the Float-Out transformation is what tripping it.
>>
>>
>>
>>
>>
>> That said, reading through what the semantics are implied by
>> has_side_effects = True, the prefetch* family of operations ARE side
>> effectful with respect the fact that they DO modify the CPU cache in a way
>> that changes what memory locations are in various levels of CPU cache, so
>> despite seeming read-like, they are modifying the state of the system, just
>> in a way that is ONLY visible wrt the performance characteristics/runtime
>>  of the resulting program.
>>
>>
>>
>> specifically, Duplication, Floating out, and Specultive evaluation all
>> change *when* the prefetch runs and changes the CPU state, and Discard
>> means this "mutation" of the CPU cache state would not happen.
>>
>>
>>
>> if prefetch was pure semantically (ie equiv to a -> ()  ) , they'd just
>> be no op, they're exclusively a tool for performance engineering, and
>> accordingly when and where they appear in code matters!
>>
>>
>>
>> i'm more than happy to write out a more detailed version of this
>> explanation somewhere if you like.
>>
>>
>>
>> -Carter
>>
>>
>>
>> """"
>>
>>
>>
>> *** Core Linted result of Simplifier:
>>
>> *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}):
>>
>> *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True,
>> OverSatApps = True}):
>>
>> *** Core Lint errors : in result of Float out(FOS {Lam = Just 0,
>>
>>                                                    Consts = True,
>>
>>                                                    OverSatApps = True})
>> ***
>>
>> <no location info>: Warning:
>>
>>     In the expression: prefetchValue2#
>>
>>                          @ [Char]
>>
>>                          @ RealWorld
>>
>>                          lvl_s3Oi
>>
>>                          (prefetchValue1#
>>
>>                             @ Int
>>
>>                             @ RealWorld
>>
>>                             lvl_s3Oj
>>
>>                             (prefetchAddr3# @ RealWorld ds1_a3zg 0
>> ds_a3zf))
>>
>>     This argument does not satisfy the let/app invariant:
>>
>>       prefetchValue1#
>>
>>         @ Int
>>
>>         @ RealWorld
>>
>>         lvl_s3Oj
>>
>>
>>
>>
>>
>> """
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Nov 24, 2014 at 10:43 PM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>  huh, apparently i was mixing up '-' and some other similar dash
>> character, time to let my rebuild of ghc go through then try gain :)
>>
>>
>>
>> On Mon, Nov 24, 2014 at 10:37 PM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>  when i run
>>
>> ./inplace/bin/ghc-stage2 codetester.hs  -O2 -dcore-lint -S
>>  -fforce-recomp -ddump-simpl -ddump-to-file ?dverbose-core2core
>> ?ddump-occur-anal ?ddump-inlinings
>>
>> i get
>>
>> target ??dverbose-core2core? is not a module name or a source file
>>
>>
>>
>> what am I doing wrong in this CLI invocation?
>>
>>
>>
>> On Mon, Nov 24, 2014 at 10:23 AM, Simon Peyton Jones <
>> simonpj at microsoft.com> wrote:
>>
>>  Carter
>>
>>
>>
>> That smells wrong to me.  These flags have a very carefully defined
>> meaning; see
>>
>>             Note [PrimOp can_fail and has_side_effects]
>>
>> in PrimOp.lhs
>>
>>
>>
>> If you say it has side effects when it doesn?t, you?ll confuse your
>> successor reading the code in five years time.
>>
>>
>>
>> Better to find out what is going on and why.  Might you do that? What
>> transformation invalidates the let/app invariant?  Make a small test case,
>> use ?dverbose-core2core ?ddump-occur-anal ?ddump-inlinings.  I would far
>> rather that than install a land-mine in the code.
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* Carter Schonwald [mailto:carter.schonwald at gmail.com]
>> *Sent:* 24 November 2014 00:54
>> *To:* Edward Kmett
>> *Cc:* ghc-devs at haskell.org; Simon Peyton Jones; Joachim Breitner
>> *Subject:* Re: let app invariant failure, HALP Re: how to write a ghc
>> primop that acts on an unevaluated argument?
>>
>>
>>
>> woot, solved it, at least in a way thats OK for now.
>>
>>
>>
>> if I mark the prefetchValue operations as has_side_effects=True, the core
>> lint failure goes away! I'm not sure if thats the right semantics in the
>> long term, but it does give me a simple way to make sure it works safely
>> for 7.10
>>
>>
>>
>> pardon all the noise
>>
>> -Carter
>>
>>
>>
>> On Sun, Nov 23, 2014 at 4:26 PM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>  ok, i'm getting a let/app invariant failure when i build my test case
>> with O1 or O2 but not without
>>
>>
>>
>> http://lpaste.net/114881
>>
>>
>>
>> any help would be appreciated on how to address that
>>
>>
>>
>> On Sun, Nov 23, 2014 at 4:13 PM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>  yup, i have that!
>>
>>
>>
>>     wrapFetch prefetchValue0# (error "this shouldn't get evaluated")
>>
>>
>>
>> in the test suite!
>>
>>
>>
>> in contrast
>>
>>     wrapFetch prefetchValue0# $! (error "this shouldn't get evaluated")
>> does explode
>>
>>
>>
>> shall I add a "should fail" test with the latter? (it doesn't seem
>> worthwhile)
>>
>>
>>
>> On Sun, Nov 23, 2014 at 3:53 PM, Edward Kmett <ekmett at gmail.com> wrote:
>>
>>  Maybe test for laziness in the argument by just putting something in
>> that goes boom when forced, e.g. 'undefined'?
>>
>>
>>
>>
>>
>> On Sun, Nov 23, 2014 at 2:04 PM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>   Hey All,
>>
>> as part of trying to get some fixups for how prefetch works into 7.10,
>>
>> i'm adding a "prefetchValue" primop that prefetchs the memory location of
>> a lifted heap value
>>
>>
>>
>> namely
>>
>>
>>
>> several operations of the following form
>>
>>
>>
>> primop PrefetchValueOp1 "prefetchValue1#" GenPrimOp
>>
>>    a -> State# s -> State# s
>>
>>    with strictness  = { \ _arity -> mkClosedStrictSig [botDmd, topDmd]
>> topRes }
>>
>>
>>
>> I'd like some feedback on the strictness information design by someone
>> who's familiar with how that piece of GHC. the idea being that
>> prefetchValue is lazy in its polymorphic argument (it doesn't force it, it
>> just does a prefetch on the heap location, which may or may not be
>> evaluated).
>>
>>
>>
>> https://phabricator.haskell.org/D350
>>
>>
>>
>> is the code in question. And i *believe* i'm testing for being lazy in
>> that argument correctly.
>>
>>
>>
>> thoughts?
>>
>>
>>
>> many thanks!
>>
>> -Carter
>>
>>
>>
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141127/6001001e/attachment-0001.html>

From bgamari.foss at gmail.com  Fri Nov 28 01:37:11 2014
From: bgamari.foss at gmail.com (Ben Gamari)
Date: Thu, 27 Nov 2014 20:37:11 -0500
Subject: Proposal: Improving the LLVM backend by packaging it
In-Reply-To: <CAEs96n3CrBJT1893q8QvmfRd_WOYTFG6vvEEs2kEt9BMKaUdfQ@mail.gmail.com>
References: <CAEs96n3CrBJT1893q8QvmfRd_WOYTFG6vvEEs2kEt9BMKaUdfQ@mail.gmail.com>
Message-ID: <87k32ggl6g.fsf@gmail.com>

Austin Seipp <austin at well-typed.com> writes:

> Hi *,
>
> A few days ago a discussion on IRC occurred about the LLVM backend,
> its current status, and what we could do to make it a rock solid part
> of GHC for all our users.
>
As if we needed another reason to do this, it seems that LLVM 3.6 will
backwards incompatibly change the alias grammar [1]. This would be quite
nasty to treat properly in the backend's current pretty-printing
framework so I think we are quickly approaching the point where tighter
constraints on acceptable LLVM versions is the only path to sanity.

That being said, I'm hopeful that LLVM 3.6 might finally allow us to
clean up the LLVM backend. Today I finally sat down and churned out
a refactoring of LLVM's prefix data [2]. This should enable a rewrite of
tables-next-to-code support which will allow us to severely cut down on
the size of the mangler (although sadly I suspect that some mangling
will still be necessary on some platforms). I'm going to try to put
together a first cut of a TNTC rework tonight.

Lastly, as it turns out the LLVM 3.5 rework revealed [3] some
optimization opportunties to LLVM which in turn revealed a long-hidden
bug in LLVM's implementation of the GHC calling convention (at least on
ARM). I've submitted a fix [4] for this as well which will hopefully
make it in to LLVM 3.6.

Unfortunately, the timing surrounding all of this is relatively
terrible. Carter has told me that LLVM 3.6 release might happen around
the time of our 7.10 release. As I mentioned above, the grammar change
could make supporting both >= 3.6 and <3.6 quite painful. However, given
that LLVM 3.5 chokes on our code on ARM, this leaves two options for
7.10,

  a. Support only LLVM <= 3.4

  b. Support only LLVM 3.6, assuming that 3.6 is actually released in
     time

In my opinion both of these options are pretty bad as we are left either
supporting a 12-month old, buggy release or a potentially non-existent
release. At the moment I'm leaning towards the latter but it's all quite
unfortunate.

Cheers,

- Ben


[1] https://github.com/bgamari/ghc/commit/6d80a4925bf6f0221076db9c691d23dd0d83eba9
[2] http://reviews.llvm.org/D6444
[3] https://phabricator.haskell.org/D155#14307
[4] http://reviews.llvm.org/D6445
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141127/52f41685/attachment.sig>

From d at davidterei.com  Fri Nov 28 06:32:06 2014
From: d at davidterei.com (David Terei)
Date: Fri, 28 Nov 2014 01:32:06 -0500
Subject: Proposal: Improving the LLVM backend by packaging it
In-Reply-To: <CAEs96n3CrBJT1893q8QvmfRd_WOYTFG6vvEEs2kEt9BMKaUdfQ@mail.gmail.com>
References: <CAEs96n3CrBJT1893q8QvmfRd_WOYTFG6vvEEs2kEt9BMKaUdfQ@mail.gmail.com>
Message-ID: <3C8A1D8B-C458-4E4F-A151-42CAD7BBE810@davidterei.com>

Late to the conversation sorry.

I think this sounds like a good plan. Given we are planning to stick with a vanilla LLVM but just fix the version, it seems it should make it reasonable to have distro?s support this. We can provide binaries easily, but also just a declaration that llvm-3.4 is the current supported version, so please package that and tell GHC where to find it.

We already do this in a weak way by checking which version of LLVM the user is using and issuing a warning when it?s one we don?t support.

The other aspect that would be very useful is if all the build machines tested with LLVM as well. It?s a lot of work to support LLVM across all the platforms we support and to track changes across both communities. Automated testing of the currently supported LLVM version and LLVM-HEAD would be great.

Cheers,
David

From marlowsd at gmail.com  Fri Nov 28 08:42:14 2014
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 28 Nov 2014 08:42:14 +0000
Subject: help wrt semantics / primops for pure prefetches
In-Reply-To: <CAJumaK8KFOYCasw0XwRiL_fexWacNHOjOXaU3jNRjwO2d-+hxw@mail.gmail.com>
References: <CAHYVw0x=ouGBv0x=d-Rz7X0ZmxE+55obCwUjyWPwjWuEvoeo4g@mail.gmail.com>	<5476F0A9.7080208@gmail.com>
 <CAJumaK8KFOYCasw0XwRiL_fexWacNHOjOXaU3jNRjwO2d-+hxw@mail.gmail.com>
Message-ID: <54783566.10005@gmail.com>

Thanks for this.  In the copying GC I was using prefetching during the 
scan phase, where you do have a pretty good tunable knob for how far 
ahead you want to prefetch.  The only variable is the size of the 
objects being copied, but most tend to be in the 2-4 words range.  I did 
manage to get 10-15% speedups with optimal tuning, but it was a slowdown 
on a different machine or with wrong tuning, which is why GHC doesn't 
have any of this right now.

Glad to hear this can actually be used to get real speedups in Haskell, 
I will be less sceptical from now on :)

Cheers,
Simon

On 27/11/2014 10:20, Edward Kmett wrote:
> My general experience with prefetching is that it is almost never a win
> when done just on trees, as in the usual mark-sweep or copy-collection
> garbage collector walk. Why? Because the time from the time you prefetch
> to the time you use the data is too variable. Stack disciplines and
> prefetch don't mix nicely.
>
> If you want to see a win out of it you have to free up some of the
> ordering of your walk, and tweak your whole application to support it.
> e.g. if you want to use prefetching in garbage collection, the way to do
> it is to switch from a strict stack discipline to using a small
> fixed-sized queue on the output of the stack, then feed prefetch on the
> way into the queue rather than as you walk the stack. That paid out for
> me as a 10-15% speedup last time I used it after factoring in the
> overhead of the extra queue. Not too bad for a weekend project. =)
>
> Without that sort of known lead-in time, it works out that prefetching
> is usually a net loss or vanishes into the noise.
>
> As for the array ops, davean has a couple of cases w/ those for which
> the prefetching operations are a 20-25% speedup, which is what motivated
> Carter to start playing around with these again. I don't know off hand
> how easily those can be turned into public test cases though.
>
> -Edward
>
> On Thu, Nov 27, 2014 at 4:36 AM, Simon Marlow <marlowsd at gmail.com
> <mailto:marlowsd at gmail.com>> wrote:
>
>     I haven't been watching this, but I have one question: does
>     prefetching actually *work*?  Do you have benchmarks (or better
>     still, actual library/application code) that show some improvement?
>     I admit to being slightly sceptical - when I've tried using
>     prefetching in the GC it has always been a struggle to get something
>     that shows an improvement, and even when I get things tuned on one
>     machine it typically makes things slower on a different processor.
>     And that's in the GC, doing it at the Haskell level should be even
>     harder.
>
>     Cheers,
>     Simon
>
>
>     On 22/11/2014 05:43, Carter Schonwald wrote:
>
>         Hey Everyone,
>         in
>         https://ghc.haskell.org/trac/__ghc/ticket/9353
>         <https://ghc.haskell.org/trac/ghc/ticket/9353>
>         and
>         https://phabricator.haskell.__org/D350
>         <https://phabricator.haskell.org/D350>
>
>         is some preliminary work to fix up how the pure versions of the
>         prefetch
>         primops work is laid out and prototyped.
>
>         However, while it nominally fixes up some of the problems with
>         how the
>         current pure prefetch apis are fundamentally borken,  the simple
>         design
>         in D350 isn't quite ideal, and i sketch out some other ideas in the
>         associated ticket #9353
>
>         I'd like to make sure  pure prefetch in 7.10 is slightly less broken
>         than in 7.8, but either way, its pretty clear that working out
>         the right
>         fixed up design wont happen till 7.12. Ie, whatever makes 7.10,
>         there
>         WILL have to be breaking changes to fix those primops for 7.12
>
>         thanks and any feedback / thoughts appreciated
>         -Carter
>
>
>         _________________________________________________
>         ghc-devs mailing list
>         ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>         http://www.haskell.org/__mailman/listinfo/ghc-devs
>         <http://www.haskell.org/mailman/listinfo/ghc-devs>
>
>     _________________________________________________
>     ghc-devs mailing list
>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     http://www.haskell.org/__mailman/listinfo/ghc-devs
>     <http://www.haskell.org/mailman/listinfo/ghc-devs>
>
>

From bgamari.foss at gmail.com  Fri Nov 28 15:52:57 2014
From: bgamari.foss at gmail.com (Ben Gamari)
Date: Fri, 28 Nov 2014 10:52:57 -0500
Subject: Proposal: Improving the LLVM backend by packaging it
In-Reply-To: <3C8A1D8B-C458-4E4F-A151-42CAD7BBE810@davidterei.com>
References: <CAEs96n3CrBJT1893q8QvmfRd_WOYTFG6vvEEs2kEt9BMKaUdfQ@mail.gmail.com>
 <3C8A1D8B-C458-4E4F-A151-42CAD7BBE810@davidterei.com>
Message-ID: <87bnnrgw4m.fsf@gmail.com>

David Terei <d at davidterei.com> writes:

> Late to the conversation sorry.
>
> I think this sounds like a good plan. Given we are planning to stick
> with a vanilla LLVM but just fix the version, it seems it should make
> it reasonable to have distro?s support this. We can provide binaries
> easily, but also just a declaration that llvm-3.4 is the current
> supported version, so please package that and tell GHC where to find
> it.

Agreed.

> We already do this in a weak way by checking which version of LLVM the
> user is using and issuing a warning when it?s one we don?t support.
>
> The other aspect that would be very useful is if all the build
> machines tested with LLVM as well. It?s a lot of work to support LLVM
> across all the platforms we support and to track changes across both
> communities. Automated testing of the currently supported LLVM version
> and LLVM-HEAD would be great.

Absolutely, this would be amazing. I generally don't find out
about regressions due to LLVM until I have time to build and test a
snapshot which doesn't happen nearly as often as I would like.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141128/cd20d9c1/attachment.sig>

From ekmett at gmail.com  Fri Nov 28 16:39:20 2014
From: ekmett at gmail.com (Edward Kmett)
Date: Fri, 28 Nov 2014 11:39:20 -0500
Subject: help wrt semantics / primops for pure prefetches
In-Reply-To: <54783566.10005@gmail.com>
References: <CAHYVw0x=ouGBv0x=d-Rz7X0ZmxE+55obCwUjyWPwjWuEvoeo4g@mail.gmail.com>
 <5476F0A9.7080208@gmail.com>
 <CAJumaK8KFOYCasw0XwRiL_fexWacNHOjOXaU3jNRjwO2d-+hxw@mail.gmail.com>
 <54783566.10005@gmail.com>
Message-ID: <CAJumaK-kdN4BZ5aDdEkmCD9VU21-u5FD4DmDDh9nRn68ZrbMwg@mail.gmail.com>

The main takeaway I had from my work with prefetching was that if you can
shove things into a fixed-sized queue and prefetch on the way into the
queue instead of doing it just to sort of kickstart the next element during
a tree traversal that is going to be demanded too fast to take full
advantage of the latency, then you can smooth out a lot of the cross system
variance.

It is just incredibly invasive. =(

Re: doing prefetching in the mark phase, I just skimmed and found
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.93.9090&rep=rep1&type=pdf
takes which appears to take a similar approach.

-Edward

On Fri, Nov 28, 2014 at 3:42 AM, Simon Marlow <marlowsd at gmail.com> wrote:

> Thanks for this.  In the copying GC I was using prefetching during the
> scan phase, where you do have a pretty good tunable knob for how far ahead
> you want to prefetch.  The only variable is the size of the objects being
> copied, but most tend to be in the 2-4 words range.  I did manage to get
> 10-15% speedups with optimal tuning, but it was a slowdown on a different
> machine or with wrong tuning, which is why GHC doesn't have any of this
> right now.
>
> Glad to hear this can actually be used to get real speedups in Haskell, I
> will be less sceptical from now on :)
>
> Cheers,
> Simon
>
> On 27/11/2014 10:20, Edward Kmett wrote:
>
>> My general experience with prefetching is that it is almost never a win
>> when done just on trees, as in the usual mark-sweep or copy-collection
>> garbage collector walk. Why? Because the time from the time you prefetch
>> to the time you use the data is too variable. Stack disciplines and
>> prefetch don't mix nicely.
>>
>> If you want to see a win out of it you have to free up some of the
>> ordering of your walk, and tweak your whole application to support it.
>> e.g. if you want to use prefetching in garbage collection, the way to do
>> it is to switch from a strict stack discipline to using a small
>> fixed-sized queue on the output of the stack, then feed prefetch on the
>> way into the queue rather than as you walk the stack. That paid out for
>> me as a 10-15% speedup last time I used it after factoring in the
>> overhead of the extra queue. Not too bad for a weekend project. =)
>>
>> Without that sort of known lead-in time, it works out that prefetching
>> is usually a net loss or vanishes into the noise.
>>
>> As for the array ops, davean has a couple of cases w/ those for which
>> the prefetching operations are a 20-25% speedup, which is what motivated
>> Carter to start playing around with these again. I don't know off hand
>> how easily those can be turned into public test cases though.
>>
>> -Edward
>>
>> On Thu, Nov 27, 2014 at 4:36 AM, Simon Marlow <marlowsd at gmail.com
>> <mailto:marlowsd at gmail.com>> wrote:
>>
>>     I haven't been watching this, but I have one question: does
>>     prefetching actually *work*?  Do you have benchmarks (or better
>>     still, actual library/application code) that show some improvement?
>>     I admit to being slightly sceptical - when I've tried using
>>     prefetching in the GC it has always been a struggle to get something
>>     that shows an improvement, and even when I get things tuned on one
>>     machine it typically makes things slower on a different processor.
>>     And that's in the GC, doing it at the Haskell level should be even
>>     harder.
>>
>>     Cheers,
>>     Simon
>>
>>
>>     On 22/11/2014 05:43, Carter Schonwald wrote:
>>
>>         Hey Everyone,
>>         in
>>         https://ghc.haskell.org/trac/__ghc/ticket/9353
>>         <https://ghc.haskell.org/trac/ghc/ticket/9353>
>>         and
>>         https://phabricator.haskell.__org/D350
>>         <https://phabricator.haskell.org/D350>
>>
>>         is some preliminary work to fix up how the pure versions of the
>>         prefetch
>>         primops work is laid out and prototyped.
>>
>>         However, while it nominally fixes up some of the problems with
>>         how the
>>         current pure prefetch apis are fundamentally borken,  the simple
>>         design
>>         in D350 isn't quite ideal, and i sketch out some other ideas in
>> the
>>         associated ticket #9353
>>
>>         I'd like to make sure  pure prefetch in 7.10 is slightly less
>> broken
>>         than in 7.8, but either way, its pretty clear that working out
>>         the right
>>         fixed up design wont happen till 7.12. Ie, whatever makes 7.10,
>>         there
>>         WILL have to be breaking changes to fix those primops for 7.12
>>
>>         thanks and any feedback / thoughts appreciated
>>         -Carter
>>
>>
>>         _________________________________________________
>>         ghc-devs mailing list
>>         ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>>         http://www.haskell.org/__mailman/listinfo/ghc-devs
>>         <http://www.haskell.org/mailman/listinfo/ghc-devs>
>>
>>     _________________________________________________
>>     ghc-devs mailing list
>>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>>     http://www.haskell.org/__mailman/listinfo/ghc-devs
>>     <http://www.haskell.org/mailman/listinfo/ghc-devs>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141128/962eab26/attachment.html>

From austin at well-typed.com  Fri Nov 28 20:38:33 2014
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 28 Nov 2014 14:38:33 -0600
Subject: Proposal: Improving the LLVM backend by packaging it
In-Reply-To: <87bnnrgw4m.fsf@gmail.com>
References: <CAEs96n3CrBJT1893q8QvmfRd_WOYTFG6vvEEs2kEt9BMKaUdfQ@mail.gmail.com>
 <3C8A1D8B-C458-4E4F-A151-42CAD7BBE810@davidterei.com>
 <87bnnrgw4m.fsf@gmail.com>
Message-ID: <CAEs96n1N7rbLCBXZyjGM8idtyTU+ENPd4K0tp6r0Xrz8GaWHig@mail.gmail.com>

Perhaps we could have ./validate also imply the 'llvm' WAY for tests
and not just the 'fast' way (which tests the NCG). But that would
double the amount of time needed for the testsuite by itself (actually
slightly more than that, since the LLVM backend is normally slower
than the NCG). But anyway, there are opportunities for speed ups
anyway I imagine, and future Harbormaster improvements mean we could
do the llvm WAY concurrently on a separate machine.

On Fri, Nov 28, 2014 at 9:52 AM, Ben Gamari <bgamari.foss at gmail.com> wrote:
> David Terei <d at davidterei.com> writes:
>
>> Late to the conversation sorry.
>>
>> I think this sounds like a good plan. Given we are planning to stick
>> with a vanilla LLVM but just fix the version, it seems it should make
>> it reasonable to have distro?s support this. We can provide binaries
>> easily, but also just a declaration that llvm-3.4 is the current
>> supported version, so please package that and tell GHC where to find
>> it.
>
> Agreed.
>
>> We already do this in a weak way by checking which version of LLVM the
>> user is using and issuing a warning when it?s one we don?t support.
>>
>> The other aspect that would be very useful is if all the build
>> machines tested with LLVM as well. It?s a lot of work to support LLVM
>> across all the platforms we support and to track changes across both
>> communities. Automated testing of the currently supported LLVM version
>> and LLVM-HEAD would be great.
>
> Absolutely, this would be amazing. I generally don't find out
> about regressions due to LLVM until I have time to build and test a
> snapshot which doesn't happen nearly as often as I would like.
>
> Cheers,
>
> - Ben



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From bgamari.foss at gmail.com  Fri Nov 28 23:27:19 2014
From: bgamari.foss at gmail.com (Ben Gamari)
Date: Fri, 28 Nov 2014 18:27:19 -0500
Subject: Status and future of the LLVM backend
Message-ID: <878uiuhpns.fsf@gmail.com>


I've written down some thoughts on the current status and future
direction of the LLVM backend here [1]. Have a look when you get a chance.

To summarize,

  * it seems like LLVM 3.4 chokes on the code produced by my 3.5 rework
    when the `$def` symbols are marked as internal

  * ARM is broken (again) due to a bug in the GHC calling convention
    implementation; an LLVM fix is waiting to be merged

  * I have code reworking TNTC for LLVM 3.6; unfortunately LLVM 3.6
    support will likely need to wait until 7.12

  * Austin's LLVM packaging proposal seems very much like the right way
    forward
    
  * Anticipating this proposal, I have started collecting [2]
    optimization passes

Cheers,

- Ben


[1]: http://smart-cactus.org/~ben/posts/2014-11-28-state-of-llvm-backend.html
[2]: https://github.com/bgamari/ghc-llvm-analyses
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141128/6cdd58ac/attachment.sig>

From ezyang at mit.edu  Sat Nov 29 05:21:05 2014
From: ezyang at mit.edu (Edward Z. Yang)
Date: Fri, 28 Nov 2014 21:21:05 -0800
Subject: Partial type signatures validate failures
Message-ID: <1417238447-sup-419@sabre>

I get these fails:

TEST="overloadedlistsfail03 overloadedlistsfail05 sigof02dt sigof02dmt annfail07 FD3 T5689 T7696 T5978 FDsFromGivens tcfail178 tcfail014 T8603 tcfail143 tcfail200 T9612 tcfail159 T7368 T5570 T6069 T5691 T7368a T8262 T7851 T8392a T5246 tcfail123 tcfail122 tcfail090 mc24 mc25 mc22 mc23 T3950 tcfail165 T8142 T5462Yes1 T5462Yes2 T3169 SimpleFail5b T3330c T5439 T7729 T7354a T7354 T7729a T7786"

Mostly stderr changes.

Edward

From gergo at erdi.hu  Sat Nov 29 06:51:57 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Sat, 29 Nov 2014 14:51:57 +0800 (SGT)
Subject: Back-porting pattern synonym type signature syntax for GHC 7.8.4
 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF3F3E4948@DB3PRD3001MB020.064d.mgd.msft.net>
References: <CAEs96n0xY4p+fknvPL_y+6S5=XukbWmPs+VyTnam4+qH+ESYtQ@mail.gmail.com>
 <alpine.DEB.2.10.1411260856200.2047@galaxy>
 <618BE556AADD624C9C918AA5D5911BEF3F3E4948@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <alpine.DEB.2.10.1411291449030.13716@galaxy>

On Wed, 26 Nov 2014, Simon Peyton Jones wrote:

> My instinct is that (a)-(c) overwhelm (d); i.e. let sleeping dogs lie. 
> But what do others think?

Just to give an idea of how limited the scope of this change would be, 
I've went and implemented it, on the 'wip/pattern-synonym-sig-backport'
branch (of both GHC and Haddock).

From gergo at erdi.hu  Sat Nov 29 10:17:30 2014
From: gergo at erdi.hu (Dr. ERDI Gergo)
Date: Sat, 29 Nov 2014 18:17:30 +0800 (SGT)
Subject: Performance regression on typechecking type families?
Message-ID: <alpine.DEB.2.10.1411291757390.13716@galaxy>

Hi,

Prompted by this question: 
http://stackoverflow.com/questions/26538595/more-efficient-type-level-computations-using-type-families
I wrote some code today using closed type families and datakinds. Also, as 
a baseline, I typechecked the code using open type families from 
the original question.

The two files are here:

https://gist.github.com/gergoerdi/727f028e4c1ed158ac9a
https://gist.github.com/gergoerdi/f96d1a9a58f5e3dccc18

On GHC 7.8.3, typechecking took about 45 seconds for each. However, on a 
'perf' build of GHC 7.9 d8c437b3, with ghc-stage2, the first one took 1m3s 
and the second one 1m12s. A 40% and 60% increase in typechecking time, 
respectively!

Is this some known regression, something surprising, or is 'perf' simply 
not the right build flavour for this kind of comparison?

Bye,
 	Gergo

From greg at gregorycollins.net  Sun Nov 30 02:15:58 2014
From: greg at gregorycollins.net (Gregory Collins)
Date: Sat, 29 Nov 2014 18:15:58 -0800
Subject: help wrt semantics / primops for pure prefetches
In-Reply-To: <5476F0A9.7080208@gmail.com>
References: <CAHYVw0x=ouGBv0x=d-Rz7X0ZmxE+55obCwUjyWPwjWuEvoeo4g@mail.gmail.com>
 <5476F0A9.7080208@gmail.com>
Message-ID: <CAHZrzdr0NxZjjEni4pGEUeKZP-phG6mfbAjPzE5B9x4WTeyUQA@mail.gmail.com>

On Thu, Nov 27, 2014 at 1:36 AM, Simon Marlow <marlowsd at gmail.com> wrote:

> I haven't been watching this, but I have one question: does prefetching
> actually *work*?  Do you have benchmarks (or better still, actual
> library/application code) that show some improvement?  I admit to being
> slightly sceptical - when I've tried using prefetching in the GC it has
> always been a struggle to get something that shows an improvement, and even
> when I get things tuned on one machine it typically makes things slower on
> a different processor.  And that's in the GC, doing it at the Haskell level
> should be even harder.
>

I've gotten some speedups (for some operations) from speculative prefetch
for hash tables -- e.g. for cuckoo hash where you know the key can be in
one of two buckets with p=0.5. Prefetching one while you search the other
lets you squeeze out some instruction-level parallelism, at the expense of
cache thrashing.

The cache thrashing issue means that whether prefetching works for you
depends a lot on your inputs: it can help if your program can handle some
additional cache pressure, and it might hurt you otherwise.

G
-- 
Gregory Collins <greg at gregorycollins.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141129/2afa5836/attachment.html>

From carter.schonwald at gmail.com  Sun Nov 30 02:33:55 2014
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 29 Nov 2014 21:33:55 -0500
Subject: help wrt semantics / primops for pure prefetches
In-Reply-To: <CAHZrzdr0NxZjjEni4pGEUeKZP-phG6mfbAjPzE5B9x4WTeyUQA@mail.gmail.com>
References: <CAHYVw0x=ouGBv0x=d-Rz7X0ZmxE+55obCwUjyWPwjWuEvoeo4g@mail.gmail.com>
 <5476F0A9.7080208@gmail.com>
 <CAHZrzdr0NxZjjEni4pGEUeKZP-phG6mfbAjPzE5B9x4WTeyUQA@mail.gmail.com>
Message-ID: <CAHYVw0w0bxhpytaro+ykRiV-6=AKouuA08_QnA5+DhXUB8tu7w@mail.gmail.com>

indeed, its a *tool* that cut both ways, and needs to pay for itself with
benchmarks!
part of why i'm pushing for the has_side_effects=True attribute in
https://phabricator.haskell.org/D350
is because it'll help make it more predictable when the instruction will
exactly fire, because using it effectively requires pretty precise
understanding of application level memory pressure!

@greg, i'd love more code review if you dont mind :)

On Sat, Nov 29, 2014 at 9:15 PM, Gregory Collins <greg at gregorycollins.net>
wrote:

> On Thu, Nov 27, 2014 at 1:36 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> I haven't been watching this, but I have one question: does prefetching
>> actually *work*?  Do you have benchmarks (or better still, actual
>> library/application code) that show some improvement?  I admit to being
>> slightly sceptical - when I've tried using prefetching in the GC it has
>> always been a struggle to get something that shows an improvement, and even
>> when I get things tuned on one machine it typically makes things slower on
>> a different processor.  And that's in the GC, doing it at the Haskell level
>> should be even harder.
>>
>
> I've gotten some speedups (for some operations) from speculative prefetch
> for hash tables -- e.g. for cuckoo hash where you know the key can be in
> one of two buckets with p=0.5. Prefetching one while you search the other
> lets you squeeze out some instruction-level parallelism, at the expense of
> cache thrashing.
>
> The cache thrashing issue means that whether prefetching works for you
> depends a lot on your inputs: it can help if your program can handle some
> additional cache pressure, and it might hurt you otherwise.
>
> G
> --
> Gregory Collins <greg at gregorycollins.net>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141129/56a6a138/attachment.html>

From jan.stolarek at p.lodz.pl  Sun Nov 30 10:14:34 2014
From: jan.stolarek at p.lodz.pl (Jan Stolarek)
Date: Sun, 30 Nov 2014 11:14:34 +0100
Subject: Performance regression on typechecking type families?
In-Reply-To: <alpine.DEB.2.10.1411291757390.13716@galaxy>
References: <alpine.DEB.2.10.1411291757390.13716@galaxy>
Message-ID: <201411301114.34585.jan.stolarek@p.lodz.pl>

I personally have run into exponential compile times with type families. Unfortunately I have not 
had the time yet to reduce my test case to something tractable.

Janek

Dnia sobota, 29 listopada 2014, Dr. ERDI Gergo napisa?:
> Hi,
>
> Prompted by this question:
> http://stackoverflow.com/questions/26538595/more-efficient-type-level-compu
>tations-using-type-families I wrote some code today using closed type
> families and datakinds. Also, as a baseline, I typechecked the code using
> open type families from
> the original question.
>
> The two files are here:
>
> https://gist.github.com/gergoerdi/727f028e4c1ed158ac9a
> https://gist.github.com/gergoerdi/f96d1a9a58f5e3dccc18
>
> On GHC 7.8.3, typechecking took about 45 seconds for each. However, on a
> 'perf' build of GHC 7.9 d8c437b3, with ghc-stage2, the first one took 1m3s
> and the second one 1m12s. A 40% and 60% increase in typechecking time,
> respectively!
>
> Is this some known regression, something surprising, or is 'perf' simply
> not the right build flavour for this kind of comparison?
>
> Bye,
>  	Gergo
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs



From mail at joachim-breitner.de  Sun Nov 30 13:26:19 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 30 Nov 2014 14:26:19 +0100
Subject: Status and future of the LLVM backend
In-Reply-To: <878uiuhpns.fsf@gmail.com>
References: <878uiuhpns.fsf@gmail.com>
Message-ID: <1417353979.1415.3.camel@joachim-breitner.de>

Hi Ben,


Am Freitag, den 28.11.2014, 18:27 -0500 schrieb Ben Gamari:
> I've written down some thoughts on the current status and future
> direction of the LLVM backend here [1].

thanks. I tried to build ghc-7.8.4-rc1 on Debian, and it failed on arm*.
First, because it picked llvm-3.5. After I tightened the dependencies to
use llvm-3.4, it failed with 
        dll-split: internal error: evacuate(static): strange closure
        type 0
            (GHC version 7.8.3.20141119 for arm_unknown_linux)
I then followed your advice from somewhere else and passed
"--with-ld=ld.gold" to ./configure, but with the same effect:
https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armel&ver=7.8.20141119-4&stamp=1417223811

Any other tricks that could make GHC 7.8.4-rc1 compile on arm?
(Including applying some not-yet-merged-patched, if necessary.)

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141130/23f03695/attachment.sig>

From bgamari.foss at gmail.com  Sun Nov 30 15:56:20 2014
From: bgamari.foss at gmail.com (Ben Gamari)
Date: Sun, 30 Nov 2014 10:56:20 -0500
Subject: Status and future of the LLVM backend
In-Reply-To: <1417353979.1415.3.camel@joachim-breitner.de>
References: <878uiuhpns.fsf@gmail.com>
 <1417353979.1415.3.camel@joachim-breitner.de>
Message-ID: <874mtghecb.fsf@gmail.com>

Joachim Breitner <mail at joachim-breitner.de> writes:

> Hi Ben,
>
>
> Am Freitag, den 28.11.2014, 18:27 -0500 schrieb Ben Gamari:
>> I've written down some thoughts on the current status and future
>> direction of the LLVM backend here [1].
>
> thanks. I tried to build ghc-7.8.4-rc1 on Debian, and it failed on arm*.
> First, because it picked llvm-3.5. After I tightened the dependencies to
> use llvm-3.4, it failed with 
>         dll-split: internal error: evacuate(static): strange closure
>         type 0
>             (GHC version 7.8.3.20141119 for arm_unknown_linux)

Indeed this looks like ld.bfd is being used.

> I then followed your advice from somewhere else and passed
> "--with-ld=ld.gold" to ./configure, but with the same effect:

Unfortunately I don't think this will be sufficient. I believe this
will only set the `LD` variable in the build system, which as far qas I
know is never used. We always call gcc to do our linking for us;
gcc will in turn just use whatever `ld` it finds in `PATH`. For this
reason I have resorted to simply adding a directory containing a symlink
to `ld.gold` to `PATH`. This is what this script[1] does.

Unfortunately it's also a bit more subtle than this; it's very likely
that the ghc you are bootstrapping from contains relocations that aren't
supported by gold. For this reason you'll likely need to build some of
the utilities with `ld.bfd` the continue the build with `ld.gold`. The
above script implements this fairly reliably.

Cheers,

- Ben


[1] https://gist.github.com/bgamari/9399430

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141130/544ae29d/attachment.sig>

From mail at joachim-breitner.de  Sun Nov 30 17:56:36 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 30 Nov 2014 18:56:36 +0100
Subject: Status and future of the LLVM backend
In-Reply-To: <874mtghecb.fsf@gmail.com>
References: <878uiuhpns.fsf@gmail.com>
 <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com>
Message-ID: <1417370196.3101.5.camel@joachim-breitner.de>

[Resent, as ghc-dev does not like my other address. Sorry Ben]

Hi,


Am Sonntag, den 30.11.2014, 10:56 -0500 schrieb Ben Gamari:
> > thanks. I tried to build ghc-7.8.4-rc1 on Debian, and it failed on arm*.
> > First, because it picked llvm-3.5. After I tightened the dependencies to
> > use llvm-3.4, it failed with 
> >         dll-split: internal error: evacuate(static): strange closure
> >         type 0
> >             (GHC version 7.8.3.20141119 for arm_unknown_linux)
> 
> Indeed this looks like ld.bfd is being used.

hmm, that?s annoying that --with-ld does not do the right thing. Is
there a bug reported about this?

> > I then followed your advice from somewhere else and passed
> > "--with-ld=ld.gold" to ./configure, but with the same effect:
> 
> Unfortunately I don't think this will be sufficient. I believe this
> will only set the `LD` variable in the build system, which as far qas I
> know is never used. We always call gcc to do our linking for us;
> gcc will in turn just use whatever `ld` it finds in `PATH`. For this
> reason I have resorted to simply adding a directory containing a symlink
> to `ld.gold` to `PATH`. This is what this script[1] does.

hmm, I?ll need to port that somehow to how the Debian package is built.
But it seems to be cleaner to use the -B flag to gcc, available at least
on Debian, according to
https://gcc.gnu.org/ml/gcc/2010-10/msg00147.html.

What would be a reliable way to make the build system pass
-B/usr/bin/ld.gold to gcc? Is
SRC_HC_OPTS     += -optc-B/usr/bin/ld.gold
in mk/build.mk a good idea?

> Unfortunately it's also a bit more subtle than this; it's very likely
> that the ghc you are bootstrapping from contains relocations that aren't
> supported by gold. For this reason you'll likely need to build some of
> the utilities with `ld.bfd` the continue the build with `ld.gold`. The
> above script implements this fairly reliably.

What would be the symptoms of that problem?

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141130/197e3b96/attachment.sig>

From alan.zimm at gmail.com  Sun Nov 30 18:18:51 2014
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Sun, 30 Nov 2014 20:18:51 +0200
Subject: Possible error with strict_mark in Parser.y
Message-ID: <CANma=H9EWaV+Qb8HC1wtsEAfQVfUH4b37q85SK=Q91i9fZAx0g@mail.gmail.com>

If I look at the production for strict_mark in the parser

https://github.com/ghc/ghc/blob/master/compiler/parser/Parser.y#L1355

strict_mark :: { Located ([AddAnn],HsBang) }
        : '!'                        { sL1 $1 ([],HsUserBang Nothing
True) }
        | '{-# UNPACK' '#-}'         { sLL $1 $> ([mo $1,mc $2],HsUserBang
(Just True)  False) }
        | '{-# NOUNPACK' '#-}'       { sLL $1 $> ([mo $1,mc $2],HsUserBang
(Just False) True) } -- ***Correct?
        | '{-# UNPACK' '#-}' '!'     { sLL $1 $> ([mo $1,mc $2],HsUserBang
(Just True)  True) }
        | '{-# NOUNPACK' '#-}' '!'   { sLL $1 $> ([mo $1,mc $2],HsUserBang
(Just False) True) }

I would expect the final True or False value to reflect the presence of the
'!' mark.

But the second line has no '!' but returns True.

I suspect this is an error.

Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141130/4069ab40/attachment.html>

From mail at joachim-breitner.de  Sun Nov 30 19:01:13 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 30 Nov 2014 20:01:13 +0100
Subject: Failing tests: literals T5681 annotations
In-Reply-To: <1416930493.21627.3.camel@joachim-breitner.de>
References: <1416652515.1406.1.camel@joachim-breitner.de>
 <1416930493.21627.3.camel@joachim-breitner.de>
Message-ID: <1417374073.3101.10.camel@joachim-breitner.de>

Hi,

I?m still seeing this failure:

Compile failed (status 256) errors were:
/tmp/ghc16123_0/ghc16123_5.s: Assembler messages:

/tmp/ghc16123_0/ghc16123_5.s:26:0:
     Error: can't resolve `.rodata' {.rodata section} - `Main_zdwwork_info$def' {.text section}

/tmp/ghc16123_0/ghc16123_5.s:46:0:
     Error: can't resolve `.rodata' {.rodata section} - `Main_work_info$def' {.text section}

/tmp/ghc16123_0/ghc16123_5.s:66:0:
     Error: can't resolve `.rodata' {.rodata section} - `Main_main1_info$def' {.text section}

/tmp/ghc16123_0/ghc16123_5.s:86:0:
     Error: can't resolve `.rodata' {.rodata section} - `Main_main_info$def' {.text section}

/tmp/ghc16123_0/ghc16123_5.s:106:0:
     Error: can't resolve `.rodata' {.rodata section} - `Main_main2_info$def' {.text section}

/tmp/ghc16123_0/ghc16123_5.s:126:0:
     Error: can't resolve `.rodata' {.rodata section} - `ZCMain_main_info$def' {.text section}

*** unexpected failure for T5681(optllvm)


https://s3.amazonaws.com/archive.travis-ci.org/jobs/42557559/log.txt

Any ideas?

Greetings,
Joachim
-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141130/f4ac23a3/attachment.sig>

From mail at joachim-breitner.de  Sun Nov 30 19:35:07 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 30 Nov 2014 20:35:07 +0100
Subject: [commit: ghc] master: compiler: fix trac issue #8815 (780b061)
In-Reply-To: <20141130191755.5FA2A3A300@ghc.haskell.org>
References: <20141130191755.5FA2A3A300@ghc.haskell.org>
Message-ID: <1417376107.3101.12.camel@joachim-breitner.de>

Hi,

just a quick note:

This commit message is rather unhelpful. In this case it is not a big
deal (the patch is quite self-explanatory), but I recommend you to
manually clean up arc-generated commit messages before pushing.

Also remember when creating a Phab DR that whatever you put in the
summary will be part of the default commit message.

Greetings,
Joachim
(who does more complaining than actual contributing these days...)

Am Sonntag, den 30.11.2014, 19:17 +0000 schrieb git at git.haskell.org:
> Repository : ssh://git at git.haskell.org/ghc
> 
> On branch  : master
> Link       : http://ghc.haskell.org/trac/ghc/changeset/780b061ce2aea4722d1a5d0e46fd4ed8ee2641d6/ghc
> 
> >---------------------------------------------------------------
> 
> commit 780b061ce2aea4722d1a5d0e46fd4ed8ee2641d6
> Author: Sivaram Balakrishnan <sivaram1992 at gmail.com>
> Date:   Sun Nov 30 13:05:56 2014 -0600
> 
>     compiler: fix trac issue #8815
>     
>     Summary: This patch changes the error message as suggested in trac issue #8815 comments.
>     
>     Reviewers: jstolarek, austin
>     
>     Reviewed By: jstolarek, austin
>     
>     Subscribers: jstolarek, thomie, carter
>     
>     Differential Revision: https://phabricator.haskell.org/D533
>     
>     GHC Trac Issues: #8815
> 
> 
> >---------------------------------------------------------------
> 
> 780b061ce2aea4722d1a5d0e46fd4ed8ee2641d6
>  compiler/typecheck/TcPat.lhs | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/compiler/typecheck/TcPat.lhs b/compiler/typecheck/TcPat.lhs
> index 3b7b5df..58e8bae 100644
> --- a/compiler/typecheck/TcPat.lhs
> +++ b/compiler/typecheck/TcPat.lhs
> @@ -796,7 +796,8 @@ tcDataConPat penv (L con_span con_name) data_con pat_ty arg_pats thing_inside
>          ; gadts_on    <- xoptM Opt_GADTs
>          ; families_on <- xoptM Opt_TypeFamilies
>          ; checkTc (no_equalities || gadts_on || families_on)
> -                  (ptext (sLit "A pattern match on a GADT requires GADTs or TypeFamilies"))
> +                  (text "A pattern match on a GADT requires the" <+>
> +                   text "GADTs or TypeFamilies language extension")
>                    -- Trac #2905 decided that a *pattern-match* of a GADT
>                    -- should require the GADT language flag.
>                    -- Re TypeFamilies see also #7156
> 
> _______________________________________________
> ghc-commits mailing list
> ghc-commits at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits
> 

-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141130/1e92a3df/attachment.sig>

From eir at cis.upenn.edu  Sun Nov 30 20:38:54 2014
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sun, 30 Nov 2014 15:38:54 -0500
Subject: Performance regression on typechecking type families?
In-Reply-To: <alpine.DEB.2.10.1411291757390.13716@galaxy>
References: <alpine.DEB.2.10.1411291757390.13716@galaxy>
Message-ID: <E491B42B-9942-41B8-961B-C26B4C0CE095@cis.upenn.edu>

I'm certainly unaware of any reason this should be expected. I would report as a bug, and, personally, would label it "High" priority. I think there is plenty of room for GHC to be more efficient around type families.

Thanks for putting together a test!

Richard

On Nov 29, 2014, at 5:17 AM, "Dr. ERDI Gergo" <gergo at erdi.hu> wrote:

> Hi,
> 
> Prompted by this question: http://stackoverflow.com/questions/26538595/more-efficient-type-level-computations-using-type-families
> I wrote some code today using closed type families and datakinds. Also, as a baseline, I typechecked the code using open type families from the original question.
> 
> The two files are here:
> 
> https://gist.github.com/gergoerdi/727f028e4c1ed158ac9a
> https://gist.github.com/gergoerdi/f96d1a9a58f5e3dccc18
> 
> On GHC 7.8.3, typechecking took about 45 seconds for each. However, on a 'perf' build of GHC 7.9 d8c437b3, with ghc-stage2, the first one took 1m3s and the second one 1m12s. A 40% and 60% increase in typechecking time, respectively!
> 
> Is this some known regression, something surprising, or is 'perf' simply not the right build flavour for this kind of comparison?
> 
> Bye,
> 	Gergo
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


From bgamari.foss at gmail.com  Sun Nov 30 21:48:05 2014
From: bgamari.foss at gmail.com (Ben Gamari)
Date: Sun, 30 Nov 2014 16:48:05 -0500
Subject: Status and future of the LLVM backend
In-Reply-To: <1417370196.3101.5.camel@joachim-breitner.de>
References: <878uiuhpns.fsf@gmail.com>
 <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com>
 <1417370196.3101.5.camel@joachim-breitner.de>
Message-ID: <871tokgy22.fsf@gmail.com>

Joachim Breitner <mail at joachim-breitner.de> writes:

> [Resent, as ghc-dev does not like my other address. Sorry Ben]
>
> Hi,
>
>
> Am Sonntag, den 30.11.2014, 10:56 -0500 schrieb Ben Gamari:
>> > thanks. I tried to build ghc-7.8.4-rc1 on Debian, and it failed on arm*.
>> > First, because it picked llvm-3.5. After I tightened the dependencies to
>> > use llvm-3.4, it failed with 
>> >         dll-split: internal error: evacuate(static): strange closure
>> >         type 0
>> >             (GHC version 7.8.3.20141119 for arm_unknown_linux)
>> 
>> Indeed this looks like ld.bfd is being used.
>
> hmm, that?s annoying that --with-ld does not do the right thing. Is
> there a bug reported about this?
>
Not that I know of. It would be good if it did the right
thing although I'm afraid that the gold issue described below means that
it wouldn't make much difference in practice; I don't think we want to
be in the business of building in hacks working around linker quirks
into our build system.

>> > I then followed your advice from somewhere else and passed
>> > "--with-ld=ld.gold" to ./configure, but with the same effect:
>> 
>> Unfortunately I don't think this will be sufficient. I believe this
>> will only set the `LD` variable in the build system, which as far qas I
>> know is never used. We always call gcc to do our linking for us;
>> gcc will in turn just use whatever `ld` it finds in `PATH`. For this
>> reason I have resorted to simply adding a directory containing a symlink
>> to `ld.gold` to `PATH`. This is what this script[1] does.
>
> hmm, I?ll need to port that somehow to how the Debian package is built.
> But it seems to be cleaner to use the -B flag to gcc, available at least
> on Debian, according to
> https://gcc.gnu.org/ml/gcc/2010-10/msg00147.html.
>
> What would be a reliable way to make the build system pass
> -B/usr/bin/ld.gold to gcc? Is
> SRC_HC_OPTS     += -optc-B/usr/bin/ld.gold
> in mk/build.mk a good idea?
>
Indeed this is much cleaner. I just wanted a way to accomplish this
without editing build.mk.

>> Unfortunately it's also a bit more subtle than this; it's very likely
>> that the ghc you are bootstrapping from contains relocations that aren't
>> supported by gold. For this reason you'll likely need to build some of
>> the utilities with `ld.bfd` the continue the build with `ld.gold`. The
>> above script implements this fairly reliably.
>
> What would be the symptoms of that problem?
>
You'll see an error message of the form,

    /usr/bin/ld.gold: error: /usr/lib/ghc/libHSrts.a(GetTime.o): requires unsupported dynamic reloc R_ARM_THM_MOVW_ABS_NC; recompile with -fPIC
    
I'm tempted to just try implementing this relocation type but sadly
these sorts of patches always take longer to get right than I expect.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141130/a4a74f44/attachment.sig>

From mail at joachim-breitner.de  Sun Nov 30 21:54:56 2014
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 30 Nov 2014 22:54:56 +0100
Subject: Status and future of the LLVM backend
In-Reply-To: <871tokgy22.fsf@gmail.com>
References: <878uiuhpns.fsf@gmail.com>
 <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com>
 <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com>
Message-ID: <1417384496.3101.21.camel@joachim-breitner.de>

Hi,


Am Sonntag, den 30.11.2014, 16:48 -0500 schrieb Ben Gamari:
> >> > I then followed your advice from somewhere else and passed
> >> > "--with-ld=ld.gold" to ./configure, but with the same effect:
> >> 
> >> Unfortunately I don't think this will be sufficient. I believe this
> >> will only set the `LD` variable in the build system, which as far qas I
> >> know is never used. We always call gcc to do our linking for us;
> >> gcc will in turn just use whatever `ld` it finds in `PATH`. For this
> >> reason I have resorted to simply adding a directory containing a symlink
> >> to `ld.gold` to `PATH`. This is what this script[1] does.
> >
> > hmm, I?ll need to port that somehow to how the Debian package is built.
> > But it seems to be cleaner to use the -B flag to gcc, available at least
> > on Debian, according to
> > https://gcc.gnu.org/ml/gcc/2010-10/msg00147.html.
> >
> > What would be a reliable way to make the build system pass
> > -B/usr/bin/ld.gold to gcc? Is
> > SRC_HC_OPTS     += -optc-B/usr/bin/ld.gold
> > in mk/build.mk a good idea?
> >
> Indeed this is much cleaner. I just wanted a way to accomplish this
> without editing build.mk.

Cleaner maybe, but it was not picked up either. Or maybe we are looking
at a different issue, not solved by using ld.gold?

        "inplace/bin/ghc-stage1" -o
        utils/dll-split/dist-install/build/tmp/dll-split -hisuf dyn_hi
        -osuf  dyn_o -hcsuf dyn_hc -fPIC -dynamic  -H32m -O -lffi
        -optl-pthread -optc-mlong-calls -optc-B/usr/bin/ld.gold
        -hide-all-packages -i -iutils/dll-split/.
        -iutils/dll-split/dist-install/build
        -iutils/dll-split/dist-install/build/autogen
        -Iutils/dll-split/dist-install/build
        -Iutils/dll-split/dist-install/build/autogen     -optP-include
        -optPutils/dll-split/dist-install/build/autogen/cabal_macros.h
        -package base-4.7.0.2 -package containers-0.5.5.1 -package
        filepath-1.3.0.2 -XHaskell98  -no-user-package-db -rtsopts
        -odir utils/dll-split/dist-install/build -hidir
        utils/dll-split/dist-install/build -stubdir
        utils/dll-split/dist-install/build
        -optl-L'/?PKGBUILDDIR?/libraries/filepath/dist-install/build'
        -optl-L'/?PKGBUILDDIR?/libraries/containers/dist-install/build'
        -optl-L'/?PKGBUILDDIR?/libraries/deepseq/dist-install/build'
        -optl-L'/?PKGBUILDDIR?/libraries/array/dist-install/build'
        -optl-L'/?PKGBUILDDIR?/libraries/base/dist-install/build'
        -optl-L'/?PKGBUILDDIR?/libraries/integer-gmp/dist-install/build'
        -optl-L'/?PKGBUILDDIR?/libraries/ghc-prim/dist-install/build'
        -optl-L'/?PKGBUILDDIR?/rts/dist/build' -optl-lgmp -optl-lm
        -optl-lrt -optl-ldl -optl-lffi -fPIC -dynamic  -H32m -O -lffi
        -optl-pthread -optc-mlong-calls -optc-B/usr/bin/ld.gold
        -hide-all-packages -i -iutils/dll-split/.
        -iutils/dll-split/dist-install/build
        -iutils/dll-split/dist-install/build/autogen
        -Iutils/dll-split/dist-install/build
        -Iutils/dll-split/dist-install/build/autogen     -optP-include
        -optPutils/dll-split/dist-install/build/autogen/cabal_macros.h
        -package base-4.7.0.2 -package containers-0.5.5.1 -package
        filepath-1.3.0.2 -XHaskell98  -no-user-package-db -rtsopts
        -fno-use-rpaths -optl-Wl,-rpath
        -optl-Wl,'$ORIGIN/../filepath-1.3.0.2' -optl-Wl,-rpath
        -optl-Wl,'$ORIGIN/../containers-0.5.5.1' -optl-Wl,-rpath
        -optl-Wl,'$ORIGIN/../deepseq-1.3.0.2' -optl-Wl,-rpath
        -optl-Wl,'$ORIGIN/../array-0.5.0.0' -optl-Wl,-rpath
        -optl-Wl,'$ORIGIN/../base-4.7.0.2' -optl-Wl,-rpath
        -optl-Wl,'$ORIGIN/../integer-gmp-0.5.1.0' -optl-Wl,-rpath
        -optl-Wl,'$ORIGIN/../ghc-prim-0.3.1.0' -optl-Wl,-rpath
        -optl-Wl,'$ORIGIN/../rts-1.0' -optl-Wl,-zorigin
        utils/dll-split/dist-install/build/Main.dyn_o    
        [..]
        "cp" -p utils/dll-split/dist-install/build/tmp/dll-split
        inplace/lib/bin/dll-split
        dll-split: internal error: evacuate(static): strange closure
        type 0
            (GHC version 7.8.3.20141119 for arm_unknown_linux)
        
https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armel&ver=7.8.20141119-5&stamp=1417383951


Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141130/b3dad151/attachment.sig>

From mz.bremerhaven at gmail.com  Sun Nov 30 23:43:29 2014
From: mz.bremerhaven at gmail.com (Xandaros)
Date: Mon, 01 Dec 2014 00:43:29 +0100
Subject: Cross-compiling GHC for ARM (RPi)
Message-ID: <547BABA1.4080907@gmail.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I'm having some trouble cross-compiling GHC (or just making a
cross-compiler, which is what I am trying to do for now).

I got my toolchain through crosstool-ng. I just took the
arm-unknown-linux-gnueabi sample and disabled the "render the toolchain
read-only" option.

Unfortunately nt-ng does not come with ncurses, so I also compiled and
installed that. I set the prefix to
~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot,
where ~/x-tools/arm-unknown-linux-gnueabi is where my toolchain is located.

I copied the mk/build.mk.sample file to mk/build.mk and uncommented the
quick-cross option. I left everything else as-is.

After configuring I executed make, which runs for quite a while but
eventually it complains about not being able to find the curses headers.

What do I do to fix this? I wouldn't mind using a different toolchain if
I can get it to work, so I am open for anything.

Configure summary of ncurses and last lines of output of make:
http://hastebin.com/uwuwenucux.txt

I hope you can help me resolve this, I've been trying to do this for a
long time now :/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJUe6uhAAoJEGBf7SEXmH6sIMkH/3eK500hnjjN3+hv/7P0YmY2
QVcDWJxRMgnFCyFA9oxAeJYqKeIps2H3555NSLdB19DK7QCG1x4TJpUBGCz09PfX
mH8ZN2qIirHIYUHOZa5JdE8cqvWd3hI1syr22PsxqyI4tkDuIfKsAp8IbJOd/vSX
9oqKjHe0OYHKIoUUlHST1AI2lElMby69nxBMprhU8yugIyEFSmQg+nuxG2Hq5GA4
SgOExWeuJHrxIAW0WZ8vipw7PG3IfJTzDSCMzIAPfri8TVhy2UNNVpjg4aaq//X0
TXXweFS1O/EpDSuRkU/2b5nGlxbaNObLI5eAJ0Lot7Pl5Oa1afK5l5ZWYipx+Fk=
=ol51
-----END PGP SIGNATURE-----


From bgamari.foss at gmail.com  Sun Nov 30 23:49:02 2014
From: bgamari.foss at gmail.com (Ben Gamari)
Date: Sun, 30 Nov 2014 18:49:02 -0500
Subject: Status and future of the LLVM backend
In-Reply-To: <1417384496.3101.21.camel@joachim-breitner.de>
References: <878uiuhpns.fsf@gmail.com>
 <1417353979.1415.3.camel@joachim-breitner.de> <874mtghecb.fsf@gmail.com>
 <1417370196.3101.5.camel@joachim-breitner.de> <871tokgy22.fsf@gmail.com>
 <1417384496.3101.21.camel@joachim-breitner.de>
Message-ID: <87y4qsfdw1.fsf@gmail.com>

Joachim Breitner <mail at joachim-breitner.de> writes:

> Hi,
>
>
> Am Sonntag, den 30.11.2014, 16:48 -0500 schrieb Ben Gamari:
>> > What would be a reliable way to make the build system pass
>> > -B/usr/bin/ld.gold to gcc? Is
>> > SRC_HC_OPTS     += -optc-B/usr/bin/ld.gold
>> > in mk/build.mk a good idea?
>> >
>> Indeed this is much cleaner. I just wanted a way to accomplish this
>> without editing build.mk.
>
> Cleaner maybe, but it was not picked up either. Or maybe we are looking
> at a different issue, not solved by using ld.gold?
>
I suspect that it this is the gold issue. I should have looked at your
command line a bit more carefully; I suspect you want 

    SRC_HC_OPTS     += -optl-B/usr/bin/ld.gold
    
Hopefully this will do it; at least the option appears to make it to the
right phase now.

Is the Debian packaging tracked in version control somewhere? All I can
find is the packaging tarball [1].

Cheers,

- Ben


[1] https://packages.debian.org/sid/ghc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141130/6867e02d/attachment.sig>