From manpacket at gmail.com  Sun Oct  1 01:49:24 2017
From: manpacket at gmail.com (Michael Baikov)
Date: Sun, 1 Oct 2017 09:49:24 +0800
Subject: GHC Threads affinity
In-Reply-To: <d54702ba-5cdd-8747-501f-21c948df4af8@nh2.me>
References: <CA+DUct+39tL=ymk-iieUPBt1Ox=rnBR9nyR32H9MMjXrjDATfQ@mail.gmail.com>
 <CANsrgPLW_w8pQgzR0SsZCW+KbO_Sz-JDcWOevEfZBfODSX0orQ@mail.gmail.com>
 <CA+DUctLb2qnhSvGHyk1zKtsg34Z_6wwRXHQp7uhpvhzVm5CtCw@mail.gmail.com>
 <d54702ba-5cdd-8747-501f-21c948df4af8@nh2.me>
Message-ID: <CA+DUct+sT+K0WENh4FnU_Z84_EK1Fa_sbh31JmvAix2iVyOFAg@mail.gmail.com>

Hi Niklas

This is indeed looks interesting and I think I saw behavior similar to
this one. At the moment I'm working through ghc-events code to get
myself a better understanding on what is going on in threads scheduler
and get a tool that can handle event stream incrementally, once I'm
done with that - I'll see what can be done about that ticket.

On Sun, Oct 1, 2017 at 7:51 AM, Niklas Hambüchen <mail at nh2.me> wrote:
> Hey Michael, greetings!
>
> Here's a little side issue that may also be of interest to you in case
> you've got HyperThreading on:
>
>   https://ghc.haskell.org/trac/ghc/ticket/10229
>
> Niklas

From ben at well-typed.com  Sun Oct  1 11:17:55 2017
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 01 Oct 2017 07:17:55 -0400
Subject: [ANNOUNCE] GHC 8.2.2 release candidate 1
References: <87lgr8zztf.fsf@ben-laptop.smart-cactus.org>
Message-ID: <8760bzruak.fsf@ben-laptop.smart-cactus.org>


Hello everyone,

The GHC team is very pleased to announce the first candidate of the
8.2.2 release of the Glasgow Haskell Compiler. Source and binary
distributions are available at

    https://downloads.haskell.org/~ghc/8.2.2-rc1/

Currently there is a slightly reduced set of binary distributions
available; do let me know if there is a missing platform you would like
to see built.

This is the first of two release candidates leading up the final 8.2.2
release. This release fixes approximately fifty bugs present in 8.2.1.
See [1] for the full list.

As always, please report any issues you encounter.

Happy testing,

- Ben


[1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.2.2&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171001/9b73de93/attachment.sig>

From m at tweag.io  Sun Oct  1 12:09:03 2017
From: m at tweag.io (Boespflug, Mathieu)
Date: Sun, 1 Oct 2017 14:09:03 +0200
Subject: GHC Threads affinity
In-Reply-To: <CA+DUct+sT+K0WENh4FnU_Z84_EK1Fa_sbh31JmvAix2iVyOFAg@mail.gmail.com>
References: <CA+DUct+39tL=ymk-iieUPBt1Ox=rnBR9nyR32H9MMjXrjDATfQ@mail.gmail.com>
 <CANsrgPLW_w8pQgzR0SsZCW+KbO_Sz-JDcWOevEfZBfODSX0orQ@mail.gmail.com>
 <CA+DUctLb2qnhSvGHyk1zKtsg34Z_6wwRXHQp7uhpvhzVm5CtCw@mail.gmail.com>
 <d54702ba-5cdd-8747-501f-21c948df4af8@nh2.me>
 <CA+DUct+sT+K0WENh4FnU_Z84_EK1Fa_sbh31JmvAix2iVyOFAg@mail.gmail.com>
Message-ID: <CAJ0eudqHm1mZa03J-yrVKd6WrsihME6ZoWn5YNUmmPKhxVRisQ@mail.gmail.com>

Note that the (AFAIK unreleased) version of ghc-events on the master
branch of the upstream repo can parse event streams incrementally, if
that's what you meant.
--
Mathieu Boespflug
Founder at http://tweag.io.


On 1 October 2017 at 03:49, Michael Baikov <manpacket at gmail.com> wrote:
> Hi Niklas
>
> This is indeed looks interesting and I think I saw behavior similar to
> this one. At the moment I'm working through ghc-events code to get
> myself a better understanding on what is going on in threads scheduler
> and get a tool that can handle event stream incrementally, once I'm
> done with that - I'll see what can be done about that ticket.
>
> On Sun, Oct 1, 2017 at 7:51 AM, Niklas Hambüchen <mail at nh2.me> wrote:
>> Hey Michael, greetings!
>>
>> Here's a little side issue that may also be of interest to you in case
>> you've got HyperThreading on:
>>
>>   https://ghc.haskell.org/trac/ghc/ticket/10229
>>
>> Niklas
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From manpacket at gmail.com  Sun Oct  1 12:34:56 2017
From: manpacket at gmail.com (Michael Baikov)
Date: Sun, 1 Oct 2017 20:34:56 +0800
Subject: GHC Threads affinity
In-Reply-To: <CAJ0eudqHm1mZa03J-yrVKd6WrsihME6ZoWn5YNUmmPKhxVRisQ@mail.gmail.com>
References: <CA+DUct+39tL=ymk-iieUPBt1Ox=rnBR9nyR32H9MMjXrjDATfQ@mail.gmail.com>
 <CANsrgPLW_w8pQgzR0SsZCW+KbO_Sz-JDcWOevEfZBfODSX0orQ@mail.gmail.com>
 <CA+DUctLb2qnhSvGHyk1zKtsg34Z_6wwRXHQp7uhpvhzVm5CtCw@mail.gmail.com>
 <d54702ba-5cdd-8747-501f-21c948df4af8@nh2.me>
 <CA+DUct+sT+K0WENh4FnU_Z84_EK1Fa_sbh31JmvAix2iVyOFAg@mail.gmail.com>
 <CAJ0eudqHm1mZa03J-yrVKd6WrsihME6ZoWn5YNUmmPKhxVRisQ@mail.gmail.com>
Message-ID: <CA+DUctLTH+Vwb9pto0K8xRwMdgodjQsM_Q2Ec9w9nKYg5w6-0g@mail.gmail.com>

On Sun, Oct 1, 2017 at 8:09 PM, Boespflug, Mathieu <m at tweag.io> wrote:
> Note that the (AFAIK unreleased) version of ghc-events on the master
> branch of the upstream repo can parse event streams incrementally, if
> that's what you meant.

It can but it got some problems. For one the only thing incremental
parser can do is to print the output - for everything else old parser
will be used and output of that incremental is partially out of order
due to the way event blocks are stored. Anyway, I already have my own
version that does proper incremental parsing, provides interface with
a streaming library and collects some info that wasn't available in
the original version. How it's more about shuffling stuff around,
cleaning and testing.

From m at tweag.io  Sun Oct  1 12:42:59 2017
From: m at tweag.io (Boespflug, Mathieu)
Date: Sun, 1 Oct 2017 14:42:59 +0200
Subject: GHC Threads affinity
In-Reply-To: <CA+DUctLTH+Vwb9pto0K8xRwMdgodjQsM_Q2Ec9w9nKYg5w6-0g@mail.gmail.com>
References: <CA+DUct+39tL=ymk-iieUPBt1Ox=rnBR9nyR32H9MMjXrjDATfQ@mail.gmail.com>
 <CANsrgPLW_w8pQgzR0SsZCW+KbO_Sz-JDcWOevEfZBfODSX0orQ@mail.gmail.com>
 <CA+DUctLb2qnhSvGHyk1zKtsg34Z_6wwRXHQp7uhpvhzVm5CtCw@mail.gmail.com>
 <d54702ba-5cdd-8747-501f-21c948df4af8@nh2.me>
 <CA+DUct+sT+K0WENh4FnU_Z84_EK1Fa_sbh31JmvAix2iVyOFAg@mail.gmail.com>
 <CAJ0eudqHm1mZa03J-yrVKd6WrsihME6ZoWn5YNUmmPKhxVRisQ@mail.gmail.com>
 <CA+DUctLTH+Vwb9pto0K8xRwMdgodjQsM_Q2Ec9w9nKYg5w6-0g@mail.gmail.com>
Message-ID: <CAJ0eudoExzQpn=H9ofc=uhvF0ye-VST8zSycSzduezAn8cBi5Q@mail.gmail.com>

You might want to have a look at
https://github.com/mboes/ghc-events/tree/streaming. Similar to what
you mention, it uses the "streaming" package for the incremental
parsing. I ran into an issue with binary that I wasn't able to track
down: even medium sized buffers make the parsing slower (significantly
so) rather than faster (my suspicion: something somewhere that should
be constant time is actually linear).
--
Mathieu Boespflug
Founder at http://tweag.io.


On 1 October 2017 at 14:34, Michael Baikov <manpacket at gmail.com> wrote:
> On Sun, Oct 1, 2017 at 8:09 PM, Boespflug, Mathieu <m at tweag.io> wrote:
>> Note that the (AFAIK unreleased) version of ghc-events on the master
>> branch of the upstream repo can parse event streams incrementally, if
>> that's what you meant.
>
> It can but it got some problems. For one the only thing incremental
> parser can do is to print the output - for everything else old parser
> will be used and output of that incremental is partially out of order
> due to the way event blocks are stored. Anyway, I already have my own
> version that does proper incremental parsing, provides interface with
> a streaming library and collects some info that wasn't available in
> the original version. How it's more about shuffling stuff around,
> cleaning and testing.

From manpacket at gmail.com  Sun Oct  1 13:14:47 2017
From: manpacket at gmail.com (Michael Baikov)
Date: Sun, 1 Oct 2017 21:14:47 +0800
Subject: GHC Threads affinity
In-Reply-To: <CAJ0eudoExzQpn=H9ofc=uhvF0ye-VST8zSycSzduezAn8cBi5Q@mail.gmail.com>
References: <CA+DUct+39tL=ymk-iieUPBt1Ox=rnBR9nyR32H9MMjXrjDATfQ@mail.gmail.com>
 <CANsrgPLW_w8pQgzR0SsZCW+KbO_Sz-JDcWOevEfZBfODSX0orQ@mail.gmail.com>
 <CA+DUctLb2qnhSvGHyk1zKtsg34Z_6wwRXHQp7uhpvhzVm5CtCw@mail.gmail.com>
 <d54702ba-5cdd-8747-501f-21c948df4af8@nh2.me>
 <CA+DUct+sT+K0WENh4FnU_Z84_EK1Fa_sbh31JmvAix2iVyOFAg@mail.gmail.com>
 <CAJ0eudqHm1mZa03J-yrVKd6WrsihME6ZoWn5YNUmmPKhxVRisQ@mail.gmail.com>
 <CA+DUctLTH+Vwb9pto0K8xRwMdgodjQsM_Q2Ec9w9nKYg5w6-0g@mail.gmail.com>
 <CAJ0eudoExzQpn=H9ofc=uhvF0ye-VST8zSycSzduezAn8cBi5Q@mail.gmail.com>
Message-ID: <CA+DUct+g6XOOb7eeUPb8J4Nr9LNN8bUT6_CAZojXW_HFn2e0-g@mail.gmail.com>

Hmmm.... I'll take a look, but from what I see - it uses the same code as
ghc-events for decoding and all the streaming done in a short single commit
- it must suffer the same bug then. It is not a single stream of events,
it's several of them per capability mixed due to caching done by RTS so you
need to decode several streams at once and merge the results.

On Oct 1, 2017 20:43, "Boespflug, Mathieu" <m at tweag.io> wrote:

> You might want to have a look at
> https://github.com/mboes/ghc-events/tree/streaming. Similar to what
> you mention, it uses the "streaming" package for the incremental
> parsing. I ran into an issue with binary that I wasn't able to track
> down: even medium sized buffers make the parsing slower (significantly
> so) rather than faster (my suspicion: something somewhere that should
> be constant time is actually linear).
> --
> Mathieu Boespflug
> Founder at http://tweag.io.
>
>
> On 1 October 2017 at 14:34, Michael Baikov <manpacket at gmail.com> wrote:
> > On Sun, Oct 1, 2017 at 8:09 PM, Boespflug, Mathieu <m at tweag.io> wrote:
> >> Note that the (AFAIK unreleased) version of ghc-events on the master
> >> branch of the upstream repo can parse event streams incrementally, if
> >> that's what you meant.
> >
> > It can but it got some problems. For one the only thing incremental
> > parser can do is to print the output - for everything else old parser
> > will be used and output of that incremental is partially out of order
> > due to the way event blocks are stored. Anyway, I already have my own
> > version that does proper incremental parsing, provides interface with
> > a streaming library and collects some info that wasn't available in
> > the original version. How it's more about shuffling stuff around,
> > cleaning and testing.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171001/f9578588/attachment.html>

From george.colpitts at gmail.com  Sun Oct  1 15:50:17 2017
From: george.colpitts at gmail.com (George Colpitts)
Date: Sun, 01 Oct 2017 15:50:17 +0000
Subject: [ANNOUNCE] GHC 8.2.2 release candidate 1
In-Reply-To: <8760bzruak.fsf@ben-laptop.smart-cactus.org>
References: <87lgr8zztf.fsf@ben-laptop.smart-cactus.org>
 <8760bzruak.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CAB-d4A46HtU2zqsma1v-yT42sWdPYKytX8JF=vMfk_6dE4tCvA@mail.gmail.com>

installed fine on mac os 10.12.6 with Xcode 9.

I then installed vector, hlint, criterion and threadscope and did a smoke
test of hlint

On Sun, Oct 1, 2017 at 8:18 AM Ben Gamari <ben at well-typed.com> wrote:

>
> Hello everyone,
>
> The GHC team is very pleased to announce the first candidate of the
> 8.2.2 release of the Glasgow Haskell Compiler. Source and binary
> distributions are available at
>
>     https://downloads.haskell.org/~ghc/8.2.2-rc1/
>
> Currently there is a slightly reduced set of binary distributions
> available; do let me know if there is a missing platform you would like
> to see built.
>
> This is the first of two release candidates leading up the final 8.2.2
> release. This release fixes approximately fifty bugs present in 8.2.1.
> See [1] for the full list.
>
> As always, please report any issues you encounter.
>
> Happy testing,
>
> - Ben
>
>
> [1]
> https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.2.2&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171001/4134cf21/attachment.html>

From ryan.gl.scott at gmail.com  Sun Oct  1 18:15:21 2017
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Sun, 1 Oct 2017 14:15:21 -0400
Subject: [ANNOUNCE] GHC 8.2.2 release candidate 1
Message-ID: <CADdQpRB02u6W6WgxmiBtnhkneoZipdyHXi-iS8SDcDVm3BQ+2g@mail.gmail.com>

I did a smoke test of Stackage Nightly's libraries [1] this afternoon using
GHC 8.2.2. Only two libraries failed to build: extensible-0.4.5 and
protolude-0.2, due to a change where type signatures like `foo :: forall k.
forall (a :: k). ...` no longer compile without enabling TypeInType.

I only mention this because the migration guide for 8.4 [2] currently gives
the impression that this TypeInType change won't land until GHC 8.4. This
doesn't appear to be case, though!

Ryan S.
-----
[1] https://www.stackage.org/nightly-2017-09-29
[2]
https://ghc.haskell.org/trac/ghc/wiki/Migration/8.4?version=7#TypeInTypeispickier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171001/d0fd03be/attachment.html>

From ryan.gl.scott at gmail.com  Sun Oct  1 22:33:10 2017
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Sun, 1 Oct 2017 18:33:10 -0400
Subject: GHC HEAD now needs extra tools to build libffi?
Message-ID: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>

Trying to build a fresh copy of GHC HEAD (at commit [1]) today failed
for me with this error: [2]

    /u/rgscott/Software/ghc4/libffi/build/missing: line 81: makeinfo:
command not found
    WARNING: 'makeinfo' is missing on your system.
             You should only need it if you modified a '.texi' file, or
             any other file indirectly affecting the aspect of the manual.
             You might want to install the Texinfo package:
             <http://www.gnu.org/software/texinfo/>
             The spurious makeinfo call might also be the consequence of
             using a buggy 'make' (AIX, DU, IRIX), in which case you might
             want to install GNU make:
             <http://www.gnu.org/software/make/>

On my Ubuntu machine, I was able to work around the issue by running:

    apt-get install texinfo

But I'm not sure if the texinfo requirement was expected or an
unintended side effect of recent libffi changes. Do you know what's
happening here Moritz?

Best,
Ryan S.
-----
[1] http://git.haskell.org/ghc.git/commit/e515c7f37be97e1c2ccc497ddd0a730e63ddfa82
[2] http://lpaste.net/6716863452582772736

From moritz at lichtzwerge.de  Sun Oct  1 23:09:18 2017
From: moritz at lichtzwerge.de (Moritz Angermann)
Date: Mon, 2 Oct 2017 07:09:18 +0800
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
Message-ID: <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>

I hope this will be fixed with:
https://phabricator.haskell.org/D4053 and https://phabricator.haskell.org/D4054

Sent from my iPhone

> On 2 Oct 2017, at 6:33 AM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
> 
> Trying to build a fresh copy of GHC HEAD (at commit [1]) today failed
> for me with this error: [2]
> 
>    /u/rgscott/Software/ghc4/libffi/build/missing: line 81: makeinfo:
> command not found
>    WARNING: 'makeinfo' is missing on your system.
>             You should only need it if you modified a '.texi' file, or
>             any other file indirectly affecting the aspect of the manual.
>             You might want to install the Texinfo package:
>             <http://www.gnu.org/software/texinfo/>
>             The spurious makeinfo call might also be the consequence of
>             using a buggy 'make' (AIX, DU, IRIX), in which case you might
>             want to install GNU make:
>             <http://www.gnu.org/software/make/>
> 
> On my Ubuntu machine, I was able to work around the issue by running:
> 
>    apt-get install texinfo
> 
> But I'm not sure if the texinfo requirement was expected or an
> unintended side effect of recent libffi changes. Do you know what's
> happening here Moritz?
> 
> Best,
> Ryan S.
> -----
> [1] http://git.haskell.org/ghc.git/commit/e515c7f37be97e1c2ccc497ddd0a730e63ddfa82
> [2] http://lpaste.net/6716863452582772736
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171002/e6bc4a00/attachment.html>

From ben at smart-cactus.org  Mon Oct  2 01:19:41 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Sun, 01 Oct 2017 21:19:41 -0400
Subject: [ANNOUNCE] GHC 8.2.2 release candidate 1
In-Reply-To: <CADdQpRB02u6W6WgxmiBtnhkneoZipdyHXi-iS8SDcDVm3BQ+2g@mail.gmail.com>
References: <CADdQpRB02u6W6WgxmiBtnhkneoZipdyHXi-iS8SDcDVm3BQ+2g@mail.gmail.com>
Message-ID: <873772s5w2.fsf@ben-laptop.smart-cactus.org>

Ryan Scott <ryan.gl.scott at gmail.com> writes:

> I did a smoke test of Stackage Nightly's libraries [1] this afternoon using
> GHC 8.2.2. Only two libraries failed to build: extensible-0.4.5 and
> protolude-0.2, due to a change where type signatures like `foo :: forall k.
> forall (a :: k). ...` no longer compile without enabling TypeInType.
>
> I only mention this because the migration guide for 8.4 [2] currently gives
> the impression that this TypeInType change won't land until GHC 8.4. This
> doesn't appear to be case, though!
>
It sounds like you are describing #13391. If this is the case then I'm
rather confused since I didn't merge the associated patch. Something
else must be going on here. Perhaps some other patch made the checks a
bit more strict inadvertently?

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171001/4594e4ff/attachment.sig>

From ryan.gl.scott at gmail.com  Mon Oct  2 01:29:16 2017
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Sun, 1 Oct 2017 21:29:16 -0400
Subject: [ANNOUNCE] GHC 8.2.2 release candidate 1
In-Reply-To: <873772s5w2.fsf@ben-laptop.smart-cactus.org>
References: <CADdQpRB02u6W6WgxmiBtnhkneoZipdyHXi-iS8SDcDVm3BQ+2g@mail.gmail.com>
 <873772s5w2.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CADdQpRCi-CxJvybGkz9QzvTLsh-kEttpK1sk6VSZQO_PEC7Giw@mail.gmail.com>

I would have guessed that it's actually due to #11963 [1], and
consequently, this [2] backported patch.

Ryan S.
-----
[1] https://ghc.haskell.org/trac/ghc/ticket/11963
[2]
http://git.haskell.org/ghc.git/commit/18dee8912f6afdcf13073d3d95d85513c14180e3

On Oct 1, 2017 21:19, "Ben Gamari" <ben at smart-cactus.org> wrote:

> Ryan Scott <ryan.gl.scott at gmail.com> writes:
>
> > I did a smoke test of Stackage Nightly's libraries [1] this afternoon
> using
> > GHC 8.2.2. Only two libraries failed to build: extensible-0.4.5 and
> > protolude-0.2, due to a change where type signatures like `foo :: forall
> k.
> > forall (a :: k). ...` no longer compile without enabling TypeInType.
> >
> > I only mention this because the migration guide for 8.4 [2] currently
> gives
> > the impression that this TypeInType change won't land until GHC 8.4. This
> > doesn't appear to be case, though!
> >
> It sounds like you are describing #13391. If this is the case then I'm
> rather confused since I didn't merge the associated patch. Something
> else must be going on here. Perhaps some other patch made the checks a
> bit more strict inadvertently?
>
> Cheers,
>
> - Ben
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171001/f6bb3e6f/attachment.html>

From ben at smart-cactus.org  Mon Oct  2 02:08:53 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Sun, 01 Oct 2017 22:08:53 -0400
Subject: [ANNOUNCE] GHC 8.2.2 release candidate 1
In-Reply-To: <CADdQpRCi-CxJvybGkz9QzvTLsh-kEttpK1sk6VSZQO_PEC7Giw@mail.gmail.com>
References: <CADdQpRB02u6W6WgxmiBtnhkneoZipdyHXi-iS8SDcDVm3BQ+2g@mail.gmail.com>
 <873772s5w2.fsf@ben-laptop.smart-cactus.org>
 <CADdQpRCi-CxJvybGkz9QzvTLsh-kEttpK1sk6VSZQO_PEC7Giw@mail.gmail.com>
Message-ID: <EA5D87B0-C41F-4B37-A165-794E01760BE5@smart-cactus.org>

On October 1, 2017 9:29:16 PM EDT, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
>I would have guessed that it's actually due to #11963 [1], and
>consequently, this [2] backported patch.
>
>Ryan S.
>-----
>[1] https://ghc.haskell.org/trac/ghc/ticket/11963
>[2]
>http://git.haskell.org/ghc.git/commit/18dee8912f6afdcf13073d3d95d85513c14180e3
>
>On Oct 1, 2017 21:19, "Ben Gamari" <ben at smart-cactus.org> wrote:
>
>> Ryan Scott <ryan.gl.scott at gmail.com> writes:
>>
>> > I did a smoke test of Stackage Nightly's libraries [1] this
>afternoon
>> using
>> > GHC 8.2.2. Only two libraries failed to build: extensible-0.4.5 and
>> > protolude-0.2, due to a change where type signatures like `foo ::
>forall
>> k.
>> > forall (a :: k). ...` no longer compile without enabling
>TypeInType.
>> >
>> > I only mention this because the migration guide for 8.4 [2]
>currently
>> gives
>> > the impression that this TypeInType change won't land until GHC
>8.4. This
>> > doesn't appear to be case, though!
>> >
>> It sounds like you are describing #13391. If this is the case then
>I'm
>> rather confused since I didn't merge the associated patch. Something
>> else must be going on here. Perhaps some other patch made the checks
>a
>> bit more strict inadvertently?
>>
>> Cheers,
>>
>> - Ben
>>
>>

Ahh, good catch. Perhaps we should revert in this case.

Cheers,

- Ben 

From captaintrunky at gmail.com  Mon Oct  2 10:53:18 2017
From: captaintrunky at gmail.com (Sergey Bykov)
Date: Mon, 2 Oct 2017 18:53:18 +0800
Subject: Unifying verbosity flags (ticket #12822)
Message-ID: <7c8dd3df-387d-30b6-8f7e-ac0e0bb4bc5f@gmail.com>

Hi, I'm working with the #12822 task, which is a refactoring for the 
verbosity flag. It should be reimplemented in a way, similar to the 
'optimization' flag. After studying the codebase, specifically 
*optLevelFlags*, I'm stuck with the following questions:

 1. Should I add a new data 'VerbosityFlag' similar to GeneralFlag,
    DumpFlag, etc or should I extend any of existing data types?
 2. How to determine a set of verbosity options to implement? Is
    grepping through all the codebase and adding corresponding options a
    good approach?


Thanks!

-- 
Best regards,
Sergey Bykov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171002/362c5159/attachment.html>

From ben at smart-cactus.org  Mon Oct  2 14:32:58 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 02 Oct 2017 10:32:58 -0400
Subject: [ANNOUNCE] GHC 8.2.2 release candidate 1
In-Reply-To: <EA5D87B0-C41F-4B37-A165-794E01760BE5@smart-cactus.org>
References: <CADdQpRB02u6W6WgxmiBtnhkneoZipdyHXi-iS8SDcDVm3BQ+2g@mail.gmail.com>
 <873772s5w2.fsf@ben-laptop.smart-cactus.org>
 <CADdQpRCi-CxJvybGkz9QzvTLsh-kEttpK1sk6VSZQO_PEC7Giw@mail.gmail.com>
 <EA5D87B0-C41F-4B37-A165-794E01760BE5@smart-cactus.org>
Message-ID: <87lgktr55x.fsf@ben-laptop.smart-cactus.org>

Ben Gamari <ben at smart-cactus.org> writes:
>
> Ahh, good catch. Perhaps we should revert in this case.
>
I've reverted this on the ghc-8.2 branch.

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171002/4474df4d/attachment.sig>

From ben at smart-cactus.org  Mon Oct  2 14:51:16 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 02 Oct 2017 10:51:16 -0400
Subject: Unifying verbosity flags (ticket #12822)
In-Reply-To: <7c8dd3df-387d-30b6-8f7e-ac0e0bb4bc5f@gmail.com>
References: <7c8dd3df-387d-30b6-8f7e-ac0e0bb4bc5f@gmail.com>
Message-ID: <87infxr4bf.fsf@ben-laptop.smart-cactus.org>

Sergey Bykov <captaintrunky at gmail.com> writes:

> Hi, I'm working with the #12822 task, which is a refactoring for the 
> verbosity flag. It should be reimplemented in a way, similar to the 
> 'optimization' flag. After studying the codebase, specifically 
> *optLevelFlags*, I'm stuck with the following questions:
>
>  1. Should I add a new data 'VerbosityFlag' similar to GeneralFlag,
>     DumpFlag, etc or should I extend any of existing data types?
>  2. How to determine a set of verbosity options to implement? Is
>     grepping through all the codebase and adding corresponding options a
>     good approach?
>
As I understand it, the task is to split up the current -v<n> flags into
distinct flags. The current role of -v is described roughly in
Note [Verbosity levels] (although it references -ddump-most and
-ddump-all, which don't exist anymore).

Grepping the source tree (e.g. for "verbosity dflags") would indeed be a
good way to find the various places it's used. For now let's just add
the new flags to GeneralFlag. If there are enough that GeneralFlags
becomes bloated we can refactor later.

Thanks for looking at this.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171002/87df21b3/attachment.sig>

From ben at smart-cactus.org  Mon Oct  2 14:56:24 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 02 Oct 2017 10:56:24 -0400
Subject: Unifying verbosity flags (ticket #12822)
In-Reply-To: <87infxr4bf.fsf@ben-laptop.smart-cactus.org>
References: <7c8dd3df-387d-30b6-8f7e-ac0e0bb4bc5f@gmail.com>
 <87infxr4bf.fsf@ben-laptop.smart-cactus.org>
Message-ID: <87fub1r42v.fsf@ben-laptop.smart-cactus.org>

Ben Gamari <ben at smart-cactus.org> writes:

> Sergey Bykov <captaintrunky at gmail.com> writes:
>
>> Hi, I'm working with the #12822 task, which is a refactoring for the 
>> verbosity flag. It should be reimplemented in a way, similar to the 
>> 'optimization' flag. After studying the codebase, specifically 
>> *optLevelFlags*, I'm stuck with the following questions:
>>
>>  1. Should I add a new data 'VerbosityFlag' similar to GeneralFlag,
>>     DumpFlag, etc or should I extend any of existing data types?
>>  2. How to determine a set of verbosity options to implement? Is
>>     grepping through all the codebase and adding corresponding options a
>>     good approach?
>>
> As I understand it, the task is to split up the current -v<n> flags into
> distinct flags. The current role of -v is described roughly in
> Note [Verbosity levels] (although it references -ddump-most and
> -ddump-all, which don't exist anymore).
>
> Grepping the source tree (e.g. for "verbosity dflags") would indeed be a
> good way to find the various places it's used. For now let's just add
> the new flags to GeneralFlag. If there are enough that GeneralFlags
> becomes bloated we can refactor later.
>
> Thanks for looking at this.
>
I also left a comment on the ticket listing the relevant uses of
verbosity.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171002/ee3b2cf9/attachment.sig>

From ben at smart-cactus.org  Mon Oct  2 15:02:35 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 02 Oct 2017 11:02:35 -0400
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
Message-ID: <87d165r3sk.fsf@ben-laptop.smart-cactus.org>

Moritz Angermann <moritz at lichtzwerge.de> writes:

> I hope this will be fixed with:
> https://phabricator.haskell.org/D4053 and https://phabricator.haskell.org/D4054
>
This should be fixed as of 9968aa3631bdee7b3215dcaf7b513d8ffe6fff4c.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171002/179af68e/attachment.sig>

From mail at joachim-breitner.de  Mon Oct  2 17:15:29 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 02 Oct 2017 13:15:29 -0400
Subject: CircleCI (Was: Disable Travis?)
In-Reply-To: <E908AF28-EC3E-468A-A492-2A1ADFA286C0@cs.brynmawr.edu>
References: <1503245493.4020.2.camel@joachim-breitner.de>
 <7920340D-2B0B-426E-8960-8A391AA46689@cs.brynmawr.edu>
 <1503302065.29178.1.camel@joachim-breitner.de>
 <2E2A20F3-7185-4ABA-8AD8-EDA2A4DE036B@cs.brynmawr.edu>
 <1504428949.11527.2.camel@joachim-breitner.de>
 <95F2B586-B24A-4E51-AF27-473AF66E3B3E@cs.brynmawr.edu>
 <CAJ0eudr-FfDW6g5JPVr4fBG005ZdAes_qQZP68_qfSXZce4AZA@mail.gmail.com>
 <1506002151.973.17.camel@joachim-breitner.de>
 <CAJ0eudr0RwUMT09hHSe_PRW2GW2dpiYKkMtd+oaRDY4fC_EVcA@mail.gmail.com>
 <1506367822.1913.2.camel@joachim-breitner.de>
 <CAJ0eudqud06ee9VwP7X25J2Hm7G240Y08gBNVAF91AwgRVPH+Q@mail.gmail.com>
 <E908AF28-EC3E-468A-A492-2A1ADFA286C0@cs.brynmawr.edu>
Message-ID: <1506964529.1122.6.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 28.09.2017, 17:46 -0400 schrieb Richard Eisenberg:
> I just tried to get on board this new train. But I can't seem to
> figure out how to "follow" ghc. I signed up through my GitHub
> account, but CircleCI doesn't seem to want me to follow an open-
> source project with which I have no formal association in GitHub.
> Joachim, it seemed you unlocked this capability. How? It'd be lovely
> to get notifications of builds on ghc's wip/rae branch, in
> particular.

it seems that one cannot simply make CircleCI notify the committer that
 broke something:
https://discuss.circleci.com/t/automatic-email-notifications-to-the-author-of-a-broken-commit/519/12

The summary seems to be:
 * only CircleCI users can sign up for notifications, and they have to
   so actively (and it’s non trivial, judging from Richard’s struggle)
 * Even then, the only options are:
   “Send me a personalized email for every build in my projects.”
   which certainly too much spam and
   “Send me a personalized email every time a build on a branch I've 
   pushed to fails; also once they're fixed.”
   which might be what most people want.
   It is not clear how I can get a mail when someone else broke master…

Well, eventually we will have Jenkins and All Is Well™.

Greetings,
Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171002/f08933d1/attachment.sig>

From rae at cs.brynmawr.edu  Mon Oct  2 17:56:35 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 2 Oct 2017 13:56:35 -0400
Subject: CircleCI (Was: Disable Travis?)
In-Reply-To: <1506964529.1122.6.camel@joachim-breitner.de>
References: <1503245493.4020.2.camel@joachim-breitner.de>
 <7920340D-2B0B-426E-8960-8A391AA46689@cs.brynmawr.edu>
 <1503302065.29178.1.camel@joachim-breitner.de>
 <2E2A20F3-7185-4ABA-8AD8-EDA2A4DE036B@cs.brynmawr.edu>
 <1504428949.11527.2.camel@joachim-breitner.de>
 <95F2B586-B24A-4E51-AF27-473AF66E3B3E@cs.brynmawr.edu>
 <CAJ0eudr-FfDW6g5JPVr4fBG005ZdAes_qQZP68_qfSXZce4AZA@mail.gmail.com>
 <1506002151.973.17.camel@joachim-breitner.de>
 <CAJ0eudr0RwUMT09hHSe_PRW2GW2dpiYKkMtd+oaRDY4fC_EVcA@mail.gmail.com>
 <1506367822.1913.2.camel@joachim-breitner.de>
 <CAJ0eudqud06ee9VwP7X25J2Hm7G240Y08gBNVAF91AwgRVPH+Q@mail.gmail.com>
 <E908AF28-EC3E-468A-A492-2A1ADFA286C0@cs.brynmawr.edu>
 <1506964529.1122.6.camel@joachim-breitner.de>
Message-ID: <68D5CD5F-01B2-4F93-A48E-5D06C1D43EEA@cs.brynmawr.edu>


> On Oct 2, 2017, at 1:15 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Well, eventually we will have Jenkins and All Is Well™.

But in the meantime, I can push to my branch and then manually check CircleCI a little while later and get meaningful results, which is much better than we've had in some time. Email would just be icing on the cake -- I'm quite happy as is.

Thanks!

Richard

From m at tweag.io  Mon Oct  2 20:45:28 2017
From: m at tweag.io (Boespflug, Mathieu)
Date: Mon, 2 Oct 2017 22:45:28 +0200
Subject: [ANNOUNCE] GHC 8.2.2 release candidate 1
In-Reply-To: <87lgktr55x.fsf@ben-laptop.smart-cactus.org>
References: <CADdQpRB02u6W6WgxmiBtnhkneoZipdyHXi-iS8SDcDVm3BQ+2g@mail.gmail.com>
 <873772s5w2.fsf@ben-laptop.smart-cactus.org>
 <CADdQpRCi-CxJvybGkz9QzvTLsh-kEttpK1sk6VSZQO_PEC7Giw@mail.gmail.com>
 <EA5D87B0-C41F-4B37-A165-794E01760BE5@smart-cactus.org>
 <87lgktr55x.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CAJ0eudq2aBOGxUEW=4eZfRoX8-zQaMBa4Qz4bBGEC-db_ju8Nw@mail.gmail.com>

Hi Ben,

https://ghc.haskell.org/trac/ghc/ticket/13702 break projects like
sparkle and others, since they crucially rely on PIE, in this case to
dynamically load executables in the JVM. It looks like you committed a
fix for this in HEAD. Any chance you could backport this to the GHC
8.2 branch?

Thanks,
--
Mathieu Boespflug
Founder at http://tweag.io.


On 2 October 2017 at 16:32, Ben Gamari <ben at smart-cactus.org> wrote:
> Ben Gamari <ben at smart-cactus.org> writes:
>>
>> Ahh, good catch. Perhaps we should revert in this case.
>>
> I've reverted this on the ghc-8.2 branch.
>
> - Ben
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From m at tweag.io  Mon Oct  2 20:56:45 2017
From: m at tweag.io (Boespflug, Mathieu)
Date: Mon, 2 Oct 2017 22:56:45 +0200
Subject: [ANNOUNCE] GHC 8.2.2 release candidate 1
In-Reply-To: <CAJ0eudq2aBOGxUEW=4eZfRoX8-zQaMBa4Qz4bBGEC-db_ju8Nw@mail.gmail.com>
References: <CADdQpRB02u6W6WgxmiBtnhkneoZipdyHXi-iS8SDcDVm3BQ+2g@mail.gmail.com>
 <873772s5w2.fsf@ben-laptop.smart-cactus.org>
 <CADdQpRCi-CxJvybGkz9QzvTLsh-kEttpK1sk6VSZQO_PEC7Giw@mail.gmail.com>
 <EA5D87B0-C41F-4B37-A165-794E01760BE5@smart-cactus.org>
 <87lgktr55x.fsf@ben-laptop.smart-cactus.org>
 <CAJ0eudq2aBOGxUEW=4eZfRoX8-zQaMBa4Qz4bBGEC-db_ju8Nw@mail.gmail.com>
Message-ID: <CAJ0eudprt6JbwsiCazk0iGRhYaqAGEtADYuBzHptZZEhUwRZxA@mail.gmail.com>

BTW, I hadn't spotted that this patch was only in HEAD since the
documentation says:

.. ghc-flag:: -pie
    :shortdesc: Instruct the linker to produce a position-independent
executable.
    :type: dynamic
    :category: linking

    :since: 8.2.1

I guess it was originally slated for that release? Should say at least 8.2.2.
--
Mathieu Boespflug
Founder at http://tweag.io.


On 2 October 2017 at 22:45, Boespflug, Mathieu <m at tweag.io> wrote:
> Hi Ben,
>
> https://ghc.haskell.org/trac/ghc/ticket/13702 break projects like
> sparkle and others, since they crucially rely on PIE, in this case to
> dynamically load executables in the JVM. It looks like you committed a
> fix for this in HEAD. Any chance you could backport this to the GHC
> 8.2 branch?
>
> Thanks,
> --
> Mathieu Boespflug
> Founder at http://tweag.io.
>
>
> On 2 October 2017 at 16:32, Ben Gamari <ben at smart-cactus.org> wrote:
>> Ben Gamari <ben at smart-cactus.org> writes:
>>>
>>> Ahh, good catch. Perhaps we should revert in this case.
>>>
>> I've reverted this on the ghc-8.2 branch.
>>
>> - Ben
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>

From ben at smart-cactus.org  Mon Oct  2 21:36:56 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 02 Oct 2017 17:36:56 -0400
Subject: [ANNOUNCE] GHC 8.2.2 release candidate 1
In-Reply-To: <CAJ0eudprt6JbwsiCazk0iGRhYaqAGEtADYuBzHptZZEhUwRZxA@mail.gmail.com>
References: <CADdQpRB02u6W6WgxmiBtnhkneoZipdyHXi-iS8SDcDVm3BQ+2g@mail.gmail.com>
 <873772s5w2.fsf@ben-laptop.smart-cactus.org>
 <CADdQpRCi-CxJvybGkz9QzvTLsh-kEttpK1sk6VSZQO_PEC7Giw@mail.gmail.com>
 <EA5D87B0-C41F-4B37-A165-794E01760BE5@smart-cactus.org>
 <87lgktr55x.fsf@ben-laptop.smart-cactus.org>
 <CAJ0eudq2aBOGxUEW=4eZfRoX8-zQaMBa4Qz4bBGEC-db_ju8Nw@mail.gmail.com>
 <CAJ0eudprt6JbwsiCazk0iGRhYaqAGEtADYuBzHptZZEhUwRZxA@mail.gmail.com>
Message-ID: <87a819qljb.fsf@ben-laptop.smart-cactus.org>

"Boespflug, Mathieu" <m at tweag.io> writes:

> BTW, I hadn't spotted that this patch was only in HEAD since the
> documentation says:
>
> .. ghc-flag:: -pie
>     :shortdesc: Instruct the linker to produce a position-independent
> executable.
>     :type: dynamic
>     :category: linking
>
>     :since: 8.2.1
>
> I guess it was originally slated for that release? Should say at least
> 8.2.2.

Good catch, thanks for noticing this. I originally had intended this for
8.2.1 but it took longer to get the patch into shape than I anticipated
so I deferred it. It looks like I forgot to update the documentation
when I merged. I'll fix this right now.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171002/a4363b88/attachment.sig>

From ben at smart-cactus.org  Mon Oct  2 22:01:49 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 02 Oct 2017 18:01:49 -0400
Subject: [ANNOUNCE] GHC 8.2.2 release candidate 1
In-Reply-To: <CAJ0eudq2aBOGxUEW=4eZfRoX8-zQaMBa4Qz4bBGEC-db_ju8Nw@mail.gmail.com>
References: <CADdQpRB02u6W6WgxmiBtnhkneoZipdyHXi-iS8SDcDVm3BQ+2g@mail.gmail.com>
 <873772s5w2.fsf@ben-laptop.smart-cactus.org>
 <CADdQpRCi-CxJvybGkz9QzvTLsh-kEttpK1sk6VSZQO_PEC7Giw@mail.gmail.com>
 <EA5D87B0-C41F-4B37-A165-794E01760BE5@smart-cactus.org>
 <87lgktr55x.fsf@ben-laptop.smart-cactus.org>
 <CAJ0eudq2aBOGxUEW=4eZfRoX8-zQaMBa4Qz4bBGEC-db_ju8Nw@mail.gmail.com>
Message-ID: <877ewdqkdu.fsf@ben-laptop.smart-cactus.org>

"Boespflug, Mathieu" <m at tweag.io> writes:

> Hi Ben,
>
> https://ghc.haskell.org/trac/ghc/ticket/13702 break projects like
> sparkle and others, since they crucially rely on PIE, in this case to
> dynamically load executables in the JVM. It looks like you committed a
> fix for this in HEAD. Any chance you could backport this to the GHC
> 8.2 branch?
>
Sorry for the delay; I had to mull this over as I'm a bit weary since
this is not a strict regression over 8.0. However, I'm sympathetic since
this is a rather recent regression (introduced in 8.0.2) and the patch
is quite low-risk. I'll merge.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171002/a632d75e/attachment.sig>

From m at tweag.io  Mon Oct  2 22:08:09 2017
From: m at tweag.io (Boespflug, Mathieu)
Date: Tue, 3 Oct 2017 00:08:09 +0200
Subject: CircleCI (Was: Disable Travis?)
In-Reply-To: <68D5CD5F-01B2-4F93-A48E-5D06C1D43EEA@cs.brynmawr.edu>
References: <1503245493.4020.2.camel@joachim-breitner.de>
 <7920340D-2B0B-426E-8960-8A391AA46689@cs.brynmawr.edu>
 <1503302065.29178.1.camel@joachim-breitner.de>
 <2E2A20F3-7185-4ABA-8AD8-EDA2A4DE036B@cs.brynmawr.edu>
 <1504428949.11527.2.camel@joachim-breitner.de>
 <95F2B586-B24A-4E51-AF27-473AF66E3B3E@cs.brynmawr.edu>
 <CAJ0eudr-FfDW6g5JPVr4fBG005ZdAes_qQZP68_qfSXZce4AZA@mail.gmail.com>
 <1506002151.973.17.camel@joachim-breitner.de>
 <CAJ0eudr0RwUMT09hHSe_PRW2GW2dpiYKkMtd+oaRDY4fC_EVcA@mail.gmail.com>
 <1506367822.1913.2.camel@joachim-breitner.de>
 <CAJ0eudqud06ee9VwP7X25J2Hm7G240Y08gBNVAF91AwgRVPH+Q@mail.gmail.com>
 <E908AF28-EC3E-468A-A492-2A1ADFA286C0@cs.brynmawr.edu>
 <1506964529.1122.6.camel@joachim-breitner.de>
 <68D5CD5F-01B2-4F93-A48E-5D06C1D43EEA@cs.brynmawr.edu>
Message-ID: <CAJ0eudo61a6Sp2jtObDQ_5TEg_zDTLS2hick3Qze0o6Qg65FwA@mail.gmail.com>

And the solution to get email notifications is quite simple in fact:
just add Richard to the ghc GitHub org! Or just as simple: Richard
(and indeed anyone else on the Internet) can fork the ghc/ghc repo on
GitHub and just needs to click one button at
https://circleci.com/projects/gh/goldfirere (the "Projects" tab) to
add the forked ghc repo and get CircleCI email notifications on push.

For users publishing PR's via GitHub, as-is CircleCI already annotates
PR's with the outcome of the build.

Once again, it took me all of two hours to set this up. It would take
me another two hours to add macOS to the mix. CircleCI or Travis CI
(and Appveyor for Windows) is what most of our clients use, including
those with very large codebases comparable in size to GHC. I submit
that development resources on GHC are too scarce to "eventually have
Jenkins".
--
Mathieu Boespflug
Founder at http://tweag.io.


On 2 October 2017 at 19:56, Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
>
>> On Oct 2, 2017, at 1:15 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
>>
>> Well, eventually we will have Jenkins and All Is Well™.
>
> But in the meantime, I can push to my branch and then manually check CircleCI a little while later and get meaningful results, which is much better than we've had in some time. Email would just be icing on the cake -- I'm quite happy as is.
>
> Thanks!
>
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From m at tweag.io  Mon Oct  2 22:13:10 2017
From: m at tweag.io (Boespflug, Mathieu)
Date: Tue, 3 Oct 2017 00:13:10 +0200
Subject: [ANNOUNCE] GHC 8.2.2 release candidate 1
In-Reply-To: <877ewdqkdu.fsf@ben-laptop.smart-cactus.org>
References: <CADdQpRB02u6W6WgxmiBtnhkneoZipdyHXi-iS8SDcDVm3BQ+2g@mail.gmail.com>
 <873772s5w2.fsf@ben-laptop.smart-cactus.org>
 <CADdQpRCi-CxJvybGkz9QzvTLsh-kEttpK1sk6VSZQO_PEC7Giw@mail.gmail.com>
 <EA5D87B0-C41F-4B37-A165-794E01760BE5@smart-cactus.org>
 <87lgktr55x.fsf@ben-laptop.smart-cactus.org>
 <CAJ0eudq2aBOGxUEW=4eZfRoX8-zQaMBa4Qz4bBGEC-db_ju8Nw@mail.gmail.com>
 <877ewdqkdu.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CAJ0eudqmgXj8iK+HshgkQJtu1MBb=j8CcWT9s6YkVwW9dLQ1+A@mail.gmail.com>

Thanks! As you say - not a regression over 8.0.2, but is a regression
over 8.0.1 (albeit a very conscious one).
--
Mathieu Boespflug
Founder at http://tweag.io.


On 3 October 2017 at 00:01, Ben Gamari <ben at smart-cactus.org> wrote:
> "Boespflug, Mathieu" <m at tweag.io> writes:
>
>> Hi Ben,
>>
>> https://ghc.haskell.org/trac/ghc/ticket/13702 break projects like
>> sparkle and others, since they crucially rely on PIE, in this case to
>> dynamically load executables in the JVM. It looks like you committed a
>> fix for this in HEAD. Any chance you could backport this to the GHC
>> 8.2 branch?
>>
> Sorry for the delay; I had to mull this over as I'm a bit weary since
> this is not a strict regression over 8.0. However, I'm sympathetic since
> this is a rather recent regression (introduced in 8.0.2) and the patch
> is quite low-risk. I'll merge.
>
> Cheers,
>
> - Ben

From alec.theriault at gmail.com  Tue Oct  3 03:58:18 2017
From: alec.theriault at gmail.com (Alec Theriault)
Date: Mon, 2 Oct 2017 20:58:18 -0700
Subject: Proposal: Allow passing in linkable files from TH
Message-ID: <CAFYDutGtiNQohZX73aaSQCAU=xatVtFVc_z7zAut7c3S6r9xSQ@mail.gmail.com>

Hello,

I have a TH feature request and I'd like to hear what people have to say
about it. Here is the [Trac ticket][0].
I'm new to this, so if anything here sounds completely wrong, it probably
is.

TH currently lets you add in arbitrary C (and other languages usually
supported by C compilers).
That code is compiled for you and then linked in automatically. This is
what makes the
[`inline-c`][1] package possible.

I'm proposing to extend this so that TH lets you pass in something that is
already compiled and
ready to be linked. The idea is that this would allow TH-level FFI to any
language that can
produce object files or libraries that have the C ABI. My immediate
use-case is to make an
`inline-rust` package where one can write Rust code straight into a Haskell
quasiquote.

In terms of a concrete API change, it would suffice to

  1. add a `LangLinkable` constructor to the `ForeignSrcLang` data type
  2. add a `qAddForeignFilePath :: ForeignSrcLang -> FilePath -> m ()`
method to `Quasi`

The code change is pretty small too (60 additions, 30 deletions) since the
`addForeignFile`
machinery is fully reusable (we just have to skip past the phase of calling
the C compiler).

# Pros:

  * Better TH FFI support
  * Simple to implement

# Cons:

  * The proposed API is suboptimal: it allows for `qAddForeignFile
LangLinkable "..."` although that
 that pretty much never makes sense since the thing being linked is not
subject to `String`  encoding

Any thoughts?

Alec

  [0]: https://ghc.haskell.org/trac/ghc/ticket/14298
  [1]: https://hackage.haskell.org/package/inline-c
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171002/4f8e71fc/attachment.html>

From moritz at lichtzwerge.de  Tue Oct  3 04:22:47 2017
From: moritz at lichtzwerge.de (Moritz Angermann)
Date: Tue, 3 Oct 2017 12:22:47 +0800
Subject: Proposal: Allow passing in linkable files from TH
In-Reply-To: <CAFYDutGtiNQohZX73aaSQCAU=xatVtFVc_z7zAut7c3S6r9xSQ@mail.gmail.com>
References: <CAFYDutGtiNQohZX73aaSQCAU=xatVtFVc_z7zAut7c3S6r9xSQ@mail.gmail.com>
Message-ID: <E95F268F-C66D-4817-8068-849E290AC483@lichtzwerge.de>

Hi Alec,

I think this would be great to have.  Here are few other discussions that have
similar needs but do not necessarily have TH as a direct dependency:

- https://mail.haskell.org/pipermail/haskell-cafe/2017-September/127877.html
  in which aditya siram (deech) asks about linking non-c build objects.
- https://github.com/haskell/cabal/issues/4677
  in which Trevor McDonell describes his troubles linking non-c built object
  files.
- https://twitter.com/deech/status/910309231785660418
  a follow up by deech again, on how to hack this with a custom Setup.hs

Now this is mostly cabal related. But the point I'd like to make is that a
complete solution that includes generating and linking object files from TH
should see if there is a way that this would play nice with cabal as well
(by possibly extending cabal a bit here). This might also tie in with bens
comment[1].

If you could upload your diff to Phabricator, I'd be happy to take a look and
give feedback wrt. to potential cross compilation implications (See also: D3608[2])

If you have trouble with phabricator, feel free to ask on irc.freenode.net/#ghc
or via email. I'm happy to help out.

-- 
[1]: https://ghc.haskell.org/trac/ghc/ticket/14298#comment:4
[2]: https://phabricator.haskell.org/D3608

> On Oct 3, 2017, at 11:58 AM, Alec Theriault <alec.theriault at gmail.com> wrote:
> 
> Hello,
> 
> I have a TH feature request and I'd like to hear what people have to say about it. Here is the [Trac ticket][0].
> I'm new to this, so if anything here sounds completely wrong, it probably is.
> 
> TH currently lets you add in arbitrary C (and other languages usually supported by C compilers).
> That code is compiled for you and then linked in automatically. This is what makes the
> [`inline-c`][1] package possible.
> 
> I'm proposing to extend this so that TH lets you pass in something that is already compiled and
> ready to be linked. The idea is that this would allow TH-level FFI to any language that can
> produce object files or libraries that have the C ABI. My immediate use-case is to make an
> `inline-rust` package where one can write Rust code straight into a Haskell quasiquote.
> 
> In terms of a concrete API change, it would suffice to
> 
>   1. add a `LangLinkable` constructor to the `ForeignSrcLang` data type
>   2. add a `qAddForeignFilePath :: ForeignSrcLang -> FilePath -> m ()` method to `Quasi`
> 
> The code change is pretty small too (60 additions, 30 deletions) since the `addForeignFile`
> machinery is fully reusable (we just have to skip past the phase of calling the C compiler).
> 
> # Pros:
> 
>   * Better TH FFI support
>   * Simple to implement
> 
> # Cons:
> 
>   * The proposed API is suboptimal: it allows for `qAddForeignFile LangLinkable "..."` although that 
>  that pretty much never makes sense since the thing being linked is not subject to `String`  encoding
> 
> Any thoughts?
> 
> Alec
> 
>   [0]: https://ghc.haskell.org/trac/ghc/ticket/14298
>   [1]: https://hackage.haskell.org/package/inline-c
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From takenobu.hs at gmail.com  Tue Oct  3 12:07:33 2017
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Tue, 3 Oct 2017 21:07:33 +0900
Subject: [ANNOUNCE] GHC 8.2.2 release candidate 1
In-Reply-To: <8760bzruak.fsf@ben-laptop.smart-cactus.org>
References: <87lgr8zztf.fsf@ben-laptop.smart-cactus.org>
 <8760bzruak.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CAPB_NvwzH=mUnwc9=63Th25T7mPX6B534erfUeY2upct5EJeEA@mail.gmail.com>

Hi Ben, devs,

Thanks for your hard work!

Could you also include the following commits?
These are about user's guide.

  * https://phabricator.haskell.org/D3850
  * https://phabricator.haskell.org/D3852

Regards,
Takenobu



2017-10-01 20:17 GMT+09:00 Ben Gamari <ben at well-typed.com>:

>
> Hello everyone,
>
> The GHC team is very pleased to announce the first candidate of the
> 8.2.2 release of the Glasgow Haskell Compiler. Source and binary
> distributions are available at
>
>     https://downloads.haskell.org/~ghc/8.2.2-rc1/
>
> Currently there is a slightly reduced set of binary distributions
> available; do let me know if there is a missing platform you would like
> to see built.
>
> This is the first of two release candidates leading up the final 8.2.2
> release. This release fixes approximately fifty bugs present in 8.2.1.
> See [1] for the full list.
>
> As always, please report any issues you encounter.
>
> Happy testing,
>
> - Ben
>
>
> [1] https://ghc.haskell.org/trac/ghc/query?status=closed&
> milestone=8.2.2&col=id&col=summary&col=status&col=type&
> col=priority&col=milestone&col=component&order=priority
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171003/e3c67980/attachment-0001.html>

From ben at smart-cactus.org  Tue Oct  3 14:25:38 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 03 Oct 2017 10:25:38 -0400
Subject: GHC Threads affinity
In-Reply-To: <CAJ0eudoExzQpn=H9ofc=uhvF0ye-VST8zSycSzduezAn8cBi5Q@mail.gmail.com>
References: <CA+DUct+39tL=ymk-iieUPBt1Ox=rnBR9nyR32H9MMjXrjDATfQ@mail.gmail.com>
 <CANsrgPLW_w8pQgzR0SsZCW+KbO_Sz-JDcWOevEfZBfODSX0orQ@mail.gmail.com>
 <CA+DUctLb2qnhSvGHyk1zKtsg34Z_6wwRXHQp7uhpvhzVm5CtCw@mail.gmail.com>
 <d54702ba-5cdd-8747-501f-21c948df4af8@nh2.me>
 <CA+DUct+sT+K0WENh4FnU_Z84_EK1Fa_sbh31JmvAix2iVyOFAg@mail.gmail.com>
 <CAJ0eudqHm1mZa03J-yrVKd6WrsihME6ZoWn5YNUmmPKhxVRisQ@mail.gmail.com>
 <CA+DUctLTH+Vwb9pto0K8xRwMdgodjQsM_Q2Ec9w9nKYg5w6-0g@mail.gmail.com>
 <CAJ0eudoExzQpn=H9ofc=uhvF0ye-VST8zSycSzduezAn8cBi5Q@mail.gmail.com>
Message-ID: <874lrgqpel.fsf@ben-laptop.smart-cactus.org>

"Boespflug, Mathieu" <m at tweag.io> writes:

> You might want to have a look at
> https://github.com/mboes/ghc-events/tree/streaming. Similar to what
> you mention, it uses the "streaming" package for the incremental
> parsing. I ran into an issue with binary that I wasn't able to track
> down: even medium sized buffers make the parsing slower (significantly
> so) rather than faster (my suspicion: something somewhere that should
> be constant time is actually linear).

Indeed there was a rather terrible bug potentially leading to
unexpected asymptotic performance issues present in `binary` versions
prior to 0.8.4 IIRC. See https://github.com/kolmodin/binary/pull/115.
Perhaps this is what you are hitting?

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171003/22dd8bd0/attachment.sig>

From ben at well-typed.com  Tue Oct  3 14:47:50 2017
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 03 Oct 2017 10:47:50 -0400
Subject: [ANNOUNCE] GHC 8.2.2 release candidate 1
In-Reply-To: <CAPB_NvwzH=mUnwc9=63Th25T7mPX6B534erfUeY2upct5EJeEA@mail.gmail.com>
References: <87lgr8zztf.fsf@ben-laptop.smart-cactus.org>
 <8760bzruak.fsf@ben-laptop.smart-cactus.org>
 <CAPB_NvwzH=mUnwc9=63Th25T7mPX6B534erfUeY2upct5EJeEA@mail.gmail.com>
Message-ID: <871smkqodl.fsf@ben-laptop.smart-cactus.org>

Takenobu Tani <takenobu.hs at gmail.com> writes:

> Hi Ben, devs,
>
> Thanks for your hard work!
>
> Could you also include the following commits?
> These are about user's guide.
>
>   * https://phabricator.haskell.org/D3850
>   * https://phabricator.haskell.org/D3852
>
Of course, thanks!

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171003/36b252d1/attachment.sig>

From simonpj at microsoft.com  Tue Oct  3 15:01:44 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 3 Oct 2017 15:01:44 +0000
Subject: GHC rewrite rule type-checking failure
In-Reply-To: <CAD6SzRLk08aWNqK+_5K=vAVj6Vi37bPQJWnS9yky8PPQ9gw4MQ@mail.gmail.com>
References: <CAD6SzRKj2Kz044CkbXA2FAzAY0oRMftxvb-QeAZ8o0zCSW1WNg@mail.gmail.com>
 <1506984729.1122.11.camel@joachim-breitner.de>
 <CAD6SzRLUsAqCkcXWEZde-VptDyWtQtJrCrOOwdVwvLaBL619ww@mail.gmail.com>
 <AM4PR83MB0033AA97DAEE401F72650ADDAD720@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CAD6SzRLk08aWNqK+_5K=vAVj6Vi37bPQJWnS9yky8PPQ9gw4MQ@mail.gmail.com>
Message-ID: <AM4PR83MB0033D000E03DBAE2A56FFF3FAD720@AM4PR83MB0033.EURPRD83.prod.outlook.com>

But synthesising from what?

And currently no: there is no type-class dictionary synthesis after the type checker.  Not impossible I suppose, but one more fragility: a rule does not fire because some synthesis thing didn’t happen.    Maybe give an as-simple-as-poss example of what you have in mind, now you understand the situation better?   With all the type and dictionary abstractions written explicitly…

S

From: conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] On Behalf Of Conal Elliott
Sent: 03 October 2017 15:56
To: Simon Peyton Jones <simonpj at microsoft.com>
Subject: Re: GHC rewrite rule type-checking failure

Thanks, Simon. Your explanation make sense to me. Do you think that the rewrite rule mechanism could be enhanced to try synthesizing the needed dictionaries after LHS matching and before RHS instantiation? I'm doing as much now in my compiling-to-categories plugin, but without the convenience of using concrete syntax for the rules.

Regard, - Conal


On Tue, Oct 3, 2017 at 12:27 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
*   Is it feasible for GHC to combine the constraints needed LHS and RHS to form an applicability condition?
I don’t think so.

Remember that a rewrite rule literally rewrites LHS to RHS.  It does not conjure up any new dictionaries out of thin air.  In your example, (D k b) is needed in the result of the rewrite.  Where can it come from?  Only from something matched on the left.

So GHC treats any dictionaries matched on the left as “givens” and tries to solve the ones matched on the left.  If it fails you get the sort of error you see.

One way to see this is to write out the rewrite rule you want, complete with all its dictionary arguments. Can you do that?

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org<mailto:glasgow-haskell-users-bounces at haskell.org>] On Behalf Of Conal Elliott
Sent: 03 October 2017 01:03
To: Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>>
Cc: glasgow-haskell-users at haskell.org<mailto:glasgow-haskell-users at haskell.org>
Subject: Re: GHC rewrite rule type-checking failure

Thanks very much for the reply, Joachim.

Oops! I flubbed the example. I really `morph` to distribute over an application of `comp`. New code below (and attached). You're right that I wouldn't want to restrict the type of `morph`, since each `morph` *rule* imposes its own restrictions.

My questions:

*   Is it feasible for GHC to combine the constraints needed LHS and RHS to form an applicability condition?
*   Is there any way I can make the needed constraints explicit in my rewrite rules?
*   Are there any other work-arounds that would enable writing such RHS-constrained rules?

Regards, -- Conal

``` haskell
{-# OPTIONS_GHC -Wall #-}
-- Demonstrate a type checking failure with rewrite rules

module RuleFail where

class C k where comp' :: k b c -> k a b -> k a c

instance C (->) where comp' = (.)

-- Late-inlining version to enable rewriting.
comp :: C k => k b c -> k a b -> k a c
comp = comp'
{-# INLINE [0] comp #-}

morph :: (a -> b) -> k a b
morph = error "morph: undefined"

{-# RULES "morph/(.)" forall f g. morph (g `comp` f) = morph g `comp` morph f #-}

-- • Could not deduce (C k) arising from a use of ‘comp’
--   from the context: C (->)
--     bound by the RULE "morph/(.)"
```


On Mon, Oct 2, 2017 at 3:52 PM, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Hi Conal,

The difference is that the LHS of the first rule is mentions the `C k`
constraint (probably unintentionally):

*RuleFail> :t morph comp
morph comp :: C k => k1 (k b c) (k a b -> k a c)

but the LHS of the second rule side does not:

*RuleFail> :t morph addC
morph addC :: Num b => k (b, b) b



A work-around is to add the constraint to `morph`:

    morph :: D k b => (a -> b) -> k a b
    morph = error "morph: undefined"

    but I fear that this work-around is not acceptable to you.

    Joachim

    Am Montag, den 02.10.2017, 14:25 -0700 schrieb Conal Elliott:
    > -- Demonstrate a type checking failure with rewrite rules
>
> module RuleFail where
>
> class C k where comp' :: k b c -> k a b -> k a c
>
> instance C (->) where comp' = (.)
>
> -- Late-inlining version to enable rewriting.
> comp :: C k => k b c -> k a b -> k a c
> comp = comp'
> {-# INLINE [0] comp #-}
>
> morph :: (a -> b) -> k a b
> morph = error "morph: undefined"
>
> {-# RULES "morph/(.)" morph comp = comp #-}  -- Fine



> class D k a where addC' :: k (a,a) a
>
> instance Num a => D (->) a where addC' = uncurry (+)
>
> -- Late-inlining version to enable rewriting.
> addC :: D k a => k (a,a) a
> addC = addC'
> {-# INLINE [0] addC #-}
>
> {-# RULES "morph/addC" morph addC = addC #-}  -- Fail
>
> -- • Could not deduce (D k b) arising from a use of ‘addC’
> --   from the context: D (->) b
>
> -- Why does GHC infer the (C k) constraint for the first rule but not (D k b)
> -- for the second rule?
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org<mailto:Glasgow-haskell-users at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users&data=02%7C01%7Csimonpj%40microsoft.com%7C3da5c75572694bab31aa08d509f25936%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636425858847457302&sdata=6dcqjyAYmKXKwZzQQExmWl1cJlCySmP1EvdjA03O19M%3D&reserved=0>
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C3da5c75572694bab31aa08d509f25936%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636425858847457302&sdata=Uoe%2Bw8T3VMFLRsFY%2B8nacXIV0pUQOyCe4iHz%2FS5kGrA%3D&reserved=0>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171003/230aceee/attachment-0001.html>

From conal at conal.net  Tue Oct  3 15:45:04 2017
From: conal at conal.net (Conal Elliott)
Date: Tue, 3 Oct 2017 08:45:04 -0700
Subject: GHC rewrite rule type-checking failure
In-Reply-To: <AM4PR83MB0033D000E03DBAE2A56FFF3FAD720@AM4PR83MB0033.EURPRD83.prod.outlook.com>
References: <CAD6SzRKj2Kz044CkbXA2FAzAY0oRMftxvb-QeAZ8o0zCSW1WNg@mail.gmail.com>
 <1506984729.1122.11.camel@joachim-breitner.de>
 <CAD6SzRLUsAqCkcXWEZde-VptDyWtQtJrCrOOwdVwvLaBL619ww@mail.gmail.com>
 <AM4PR83MB0033AA97DAEE401F72650ADDAD720@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CAD6SzRLk08aWNqK+_5K=vAVj6Vi37bPQJWnS9yky8PPQ9gw4MQ@mail.gmail.com>
 <AM4PR83MB0033D000E03DBAE2A56FFF3FAD720@AM4PR83MB0033.EURPRD83.prod.outlook.com>
Message-ID: <CAD6SzR+bd=WsTTD1HAQ4LQVrjk-DrxxttLKhkNKFnAm1jPryaA@mail.gmail.com>

The revised example I gave earlier in the thread:

``` haskell
class C k where comp' :: k b c -> k a b -> k a c

instance C (->) where comp' = (.)

-- Late-inlining version to enable rewriting.
comp :: C k => k b c -> k a b -> k a c
comp = comp'
{-# INLINE [0] comp #-}

morph :: (a -> b) -> k a b
morph = error "morph: undefined"

{-# RULES "morph/(.)" forall f g. morph (g `comp` f) = morph g `comp` morph
f #-}

-- • Could not deduce (C k) arising from a use of ‘comp’
--   from the context: C (->)
--     bound by the RULE "morph/(.)"
```

A hypothetical generated Core rule (tweaked slightly from Joachim's note):

``` haskell
forall (@ k) (@ b) (@ c) (@ a)
       ($dC :: C (->))
       (f :: a -> b) (g :: b -> c).
  morph @ k @ a @ c (comp @ (->) @ b @ c @ a $dC g f)
  = comp @ k @ b @ c @ a
      $dC'
      (morph @ k @ b @ c g)
      (morph @ k @ a @ b f)
 where
   $dC' :: C k
```

The new bit here is that `$dC'` is not found via matching in the LHS, but
rather by instance resolution from `k`, which does appear explicitly in the
LHS. If `C k` cannot be solved, the rule fails. The "where" clause here
lists the dictionary variables to be instantiated by instance resolution
rather than matching.

-- Conal


On Tue, Oct 3, 2017 at 8:01 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> But synthesising from what?
>
>
>
> And currently no: there is no type-class dictionary synthesis after the
> type checker.  Not impossible I suppose, but one more fragility: a rule
> does not fire because some synthesis thing didn’t happen.    Maybe give an
> as-simple-as-poss example of what you have in mind, now you understand the
> situation better?   With all the type and dictionary abstractions written
> explicitly…
>
>
>
> S
>
>
>
> *From:* conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] *On
> Behalf Of *Conal Elliott
> *Sent:* 03 October 2017 15:56
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>
> *Subject:* Re: GHC rewrite rule type-checking failure
>
>
>
> Thanks, Simon. Your explanation make sense to me. Do you think that the
> rewrite rule mechanism could be enhanced to try synthesizing the needed
> dictionaries after LHS matching and before RHS instantiation? I'm doing as
> much now in my compiling-to-categories plugin, but without the convenience
> of using concrete syntax for the rules.
>
>
>
> Regard, - Conal
>
>
>
>
>
> On Tue, Oct 3, 2017 at 12:27 AM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> *   Is it feasible for GHC to combine the constraints needed LHS and RHS
> to form an applicability condition?
>
> I don’t think so.
>
>
>
> Remember that a rewrite rule literally rewrites LHS to RHS.  It does not
> conjure up any new dictionaries out of thin air.  In your example, (D k b)
> is needed in the result of the rewrite.  Where can it come from?  Only from
> something matched on the left.
>
>
>
> So GHC treats any dictionaries matched on the left as “givens” and tries
> to solve the ones matched on the left.  If it fails you get the sort of
> error you see.
>
>
>
> One way to see this is to write out the rewrite rule you want, complete
> with all its dictionary arguments. Can you do that?
>
>
>
> Simon
>
>
>
> *From:* Glasgow-haskell-users [mailto:glasgow-haskell-users-
> bounces at haskell.org] *On Behalf Of *Conal Elliott
> *Sent:* 03 October 2017 01:03
> *To:* Joachim Breitner <mail at joachim-breitner.de>
> *Cc:* glasgow-haskell-users at haskell.org
> *Subject:* Re: GHC rewrite rule type-checking failure
>
>
>
> Thanks very much for the reply, Joachim.
>
>
>
> Oops! I flubbed the example. I really `morph` to distribute over an
> application of `comp`. New code below (and attached). You're right that I
> wouldn't want to restrict the type of `morph`, since each `morph` *rule*
> imposes its own restrictions.
>
>
>
> My questions:
>
>
>
> *   Is it feasible for GHC to combine the constraints needed LHS and RHS
> to form an applicability condition?
>
> *   Is there any way I can make the needed constraints explicit in my
> rewrite rules?
>
> *   Are there any other work-arounds that would enable writing such
> RHS-constrained rules?
>
>
>
> Regards, -- Conal
>
>
>
> ``` haskell
>
> {-# OPTIONS_GHC -Wall #-}
>
> -- Demonstrate a type checking failure with rewrite rules
>
>
>
> module RuleFail where
>
>
>
> class C k where comp' :: k b c -> k a b -> k a c
>
>
>
> instance C (->) where comp' = (.)
>
>
>
> -- Late-inlining version to enable rewriting.
>
> comp :: C k => k b c -> k a b -> k a c
>
> comp = comp'
>
> {-# INLINE [0] comp #-}
>
>
>
> morph :: (a -> b) -> k a b
>
> morph = error "morph: undefined"
>
>
>
> {-# RULES "morph/(.)" forall f g. morph (g `comp` f) = morph g `comp`
> morph f #-}
>
>
>
> -- • Could not deduce (C k) arising from a use of ‘comp’
>
> --   from the context: C (->)
>
> --     bound by the RULE "morph/(.)"
>
> ```
>
>
>
>
>
> On Mon, Oct 2, 2017 at 3:52 PM, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
> Hi Conal,
>
> The difference is that the LHS of the first rule is mentions the `C k`
> constraint (probably unintentionally):
>
> *RuleFail> :t morph comp
> morph comp :: C k => k1 (k b c) (k a b -> k a c)
>
> but the LHS of the second rule side does not:
>
> *RuleFail> :t morph addC
> morph addC :: Num b => k (b, b) b
>
>
>
> A work-around is to add the constraint to `morph`:
>
>     morph :: D k b => (a -> b) -> k a b
>     morph = error "morph: undefined"
>
>     but I fear that this work-around is not acceptable to you.
>
>     Joachim
>
>     Am Montag, den 02.10.2017, 14:25 -0700 schrieb Conal Elliott:
>     > -- Demonstrate a type checking failure with rewrite rules
> >
> > module RuleFail where
> >
> > class C k where comp' :: k b c -> k a b -> k a c
> >
> > instance C (->) where comp' = (.)
> >
> > -- Late-inlining version to enable rewriting.
> > comp :: C k => k b c -> k a b -> k a c
> > comp = comp'
> > {-# INLINE [0] comp #-}
> >
> > morph :: (a -> b) -> k a b
> > morph = error "morph: undefined"
> >
> > {-# RULES "morph/(.)" morph comp = comp #-}  -- Fine
>
>
>
> > class D k a where addC' :: k (a,a) a
> >
> > instance Num a => D (->) a where addC' = uncurry (+)
> >
> > -- Late-inlining version to enable rewriting.
> > addC :: D k a => k (a,a) a
> > addC = addC'
> > {-# INLINE [0] addC #-}
> >
> > {-# RULES "morph/addC" morph addC = addC #-}  -- Fail
> >
> > -- • Could not deduce (D k b) arising from a use of ‘addC’
> > --   from the context: D (->) b
> >
> > -- Why does GHC infer the (C k) constraint for the first rule but not (D
> k b)
> > -- for the second rule?
> >
> > _______________________________________________
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users&data=02%7C01%7Csimonpj%40microsoft.com%7C3da5c75572694bab31aa08d509f25936%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636425858847457302&sdata=6dcqjyAYmKXKwZzQQExmWl1cJlCySmP1EvdjA03O19M%3D&reserved=0>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C3da5c75572694bab31aa08d509f25936%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636425858847457302&sdata=Uoe%2Bw8T3VMFLRsFY%2B8nacXIV0pUQOyCe4iHz%2FS5kGrA%3D&reserved=0>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171003/4013c71e/attachment.html>

From tjakway at nyu.edu  Tue Oct  3 17:55:29 2017
From: tjakway at nyu.edu (Thomas Jakway)
Date: Tue, 3 Oct 2017 13:55:29 -0400
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
Message-ID: <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>

Anyone else getting linker errors?

/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
20171003.so: error: undefined reference to 'ffi_type_uint64'
chmod +x inplace/bin/runghc
/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
20171003.so: error: undefined reference to 'ffi_type_uint32'
/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
20171003.so: error: undefined reference to 'ffi_type_uint16'
/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
20171003.so: error: undefined reference to 'ffi_type_uint8'
/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
20171003.so: error: undefined reference to 'ffi_type_sint64'
/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
20171003.so: error: undefined reference to 'ffi_type_sint32'
/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
20171003.so: error: undefined reference to 'ffi_type_sint16'
/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
20171003.so: error: undefined reference to 'ffi_type_sint8'
/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
20171003.so: error: undefined reference to 'ffi_type_double'
/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
20171003.so: error: undefined reference to 'ffi_type_float'
/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
20171003.so: error: undefined reference to 'ffi_type_pointer'
/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
20171003.so: error: undefined reference to 'ffi_type_void'
/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
20171003.so: error: undefined reference to 'ffi_prep_cif'
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)
iserv/ghc.mk:108: recipe for target 
'iserv/stage2_dyn/build/tmp/ghc-iserv-dyn' f
ailed
make[1]: *** [iserv/stage2_dyn/build/tmp/ghc-iserv-dyn] Error 1
make[1]: *** Waiting for unfinished jobs....
<<ghc: 2235737040 bytes, 225 GCs, 21703308/57027464 avg/max bytes 
residency (8 s
amples), 150M in use, 0.000 INIT (0.000 elapsed), 1.432 MUT (1.681 
elapsed), 0.5
76 GC (0.651 elapsed) :ghc>>
Makefile:122: recipe for target 'all' failed
make: *** [all] Error 2


This is after running

make clean && make distclean && find . -name "*.o" -type f -delete && 
find . -name "*.hi" -type f -delete

then

./boot && ./configure && make -j5

(ghc-new is not a new checkout, this error is happening on a branch I'm 
working on, but one that doesn't touch the FFI)

On 10/01/2017 07:09 PM, Moritz Angermann wrote:
> I hope this will be fixed with:
> https://phabricator.haskell.org/D4053 and 
> https://phabricator.haskell.org/D4054
>
> Sent from my iPhone
>
> On 2 Oct 2017, at 6:33 AM, Ryan Scott <ryan.gl.scott at gmail.com 
> <mailto:ryan.gl.scott at gmail.com>> wrote:
>
>> Trying to build a fresh copy of GHC HEAD (at commit [1]) today failed
>> for me with this error: [2]
>>
>>    /u/rgscott/Software/ghc4/libffi/build/missing: line 81: makeinfo:
>> command not found
>>    WARNING: 'makeinfo' is missing on your system.
>>             You should only need it if you modified a '.texi' file, or
>>             any other file indirectly affecting the aspect of the manual.
>>             You might want to install the Texinfo package:
>>             <http://www.gnu.org/software/texinfo/>
>>             The spurious makeinfo call might also be the consequence of
>>             using a buggy 'make' (AIX, DU, IRIX), in which case you might
>>             want to install GNU make:
>>             <http://www.gnu.org/software/make/>
>>
>> On my Ubuntu machine, I was able to work around the issue by running:
>>
>>    apt-get install texinfo
>>
>> But I'm not sure if the texinfo requirement was expected or an
>> unintended side effect of recent libffi changes. Do you know what's
>> happening here Moritz?
>>
>> Best,
>> Ryan S.
>> -----
>> [1] 
>> http://git.haskell.org/ghc.git/commit/e515c7f37be97e1c2ccc497ddd0a730e63ddfa82
>> [2] http://lpaste.net/6716863452582772736
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171003/331f2a26/attachment-0001.html>

From leo at halfaya.org  Tue Oct  3 18:17:23 2017
From: leo at halfaya.org (John Leo)
Date: Tue, 3 Oct 2017 11:17:23 -0700
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
Message-ID: <CAHYM_Vmj10ekRejPMiw4jqoPwUmfukGRub0n+6u7e2VTMYpxMw@mail.gmail.com>

I pulled head this morning and built with no problems on a Mac.  I wonder
if you need to pull submodules as well (which I did) or if you're missing
some newly required dependency.

John

On Tue, Oct 3, 2017 at 10:55 AM, Thomas Jakway <tjakway at nyu.edu> wrote:

> Anyone else getting linker errors?
>
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_uint64'
> chmod +x
> inplace/bin/runghc
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_uint32'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_uint16'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_uint8'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_sint64'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_sint32'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_sint16'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_sint8'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_double'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_float'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_pointer'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_void'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_prep_cif'
> collect2: error: ld returned 1 exit status
> `gcc' failed in phase `Linker'. (Exit code: 1)
> iserv/ghc.mk:108: recipe for target 'iserv/stage2_dyn/build/tmp/ghc-iserv-dyn'
> f
> ailed
> make[1]: *** [iserv/stage2_dyn/build/tmp/ghc-iserv-dyn] Error 1
> make[1]: *** Waiting for unfinished jobs....
> <<ghc: 2235737040 <(223)%20573-7040> bytes, 225 GCs, 21703308/57027464
> avg/max bytes residency (8 s
> amples), 150M in use, 0.000 INIT (0.000 elapsed), 1.432 MUT (1.681
> elapsed), 0.5
> 76 GC (0.651 elapsed) :ghc>>
> Makefile:122: recipe for target 'all' failed
> make: *** [all] Error 2
>
>
> This is after running
>
> make clean && make distclean && find . -name "*.o" -type f -delete && find
> . -name "*.hi" -type f -delete
>
> then
>
> ./boot && ./configure && make -j5
>
> (ghc-new is not a new checkout, this error is happening on a branch I'm
> working on, but one that doesn't touch the FFI)
>
> On 10/01/2017 07:09 PM, Moritz Angermann wrote:
>
> I hope this will be fixed with:
> https://phabricator.haskell.org/D4053 and https://
> phabricator.haskell.org/D4054
>
> Sent from my iPhone
>
> On 2 Oct 2017, at 6:33 AM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
>
> Trying to build a fresh copy of GHC HEAD (at commit [1]) today failed
> for me with this error: [2]
>
>    /u/rgscott/Software/ghc4/libffi/build/missing: line 81: makeinfo:
> command not found
>    WARNING: 'makeinfo' is missing on your system.
>             You should only need it if you modified a '.texi' file, or
>             any other file indirectly affecting the aspect of the manual.
>             You might want to install the Texinfo package:
>             <http://www.gnu.org/software/texinfo/>
>             The spurious makeinfo call might also be the consequence of
>             using a buggy 'make' (AIX, DU, IRIX), in which case you might
>             want to install GNU make:
>             <http://www.gnu.org/software/make/>
>
> On my Ubuntu machine, I was able to work around the issue by running:
>
>    apt-get install texinfo
>
> But I'm not sure if the texinfo requirement was expected or an
> unintended side effect of recent libffi changes. Do you know what's
> happening here Moritz?
>
> Best,
> Ryan S.
> -----
> [1] http://git.haskell.org/ghc.git/commit/e515c7f37be97e1c2ccc497ddd0a73
> 0e63ddfa82
> [2] http://lpaste.net/6716863452582772736
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> _______________________________________________
> ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171003/52a1d3f1/attachment.html>

From tjakway at nyu.edu  Tue Oct  3 20:36:48 2017
From: tjakway at nyu.edu (Thomas Jakway)
Date: Tue, 3 Oct 2017 16:36:48 -0400
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <CAHYM_Vmj10ekRejPMiw4jqoPwUmfukGRub0n+6u7e2VTMYpxMw@mail.gmail.com>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
 <CAHYM_Vmj10ekRejPMiw4jqoPwUmfukGRub0n+6u7e2VTMYpxMw@mail.gmail.com>
Message-ID: <9d4a14bf-d1bd-9fcb-69ad-03019d8948da@nyu.edu>

Not sure.  I ran `git submodule update --init --recursive` and git 
status says everything's up to date.  I'm on Ubuntu 16.10.


On 10/03/2017 02:17 PM, John Leo wrote:
> I pulled head this morning and built with no problems on a Mac.  I 
> wonder if you need to pull submodules as well (which I did) or if 
> you're missing some newly required dependency.
>
> John
>
> On Tue, Oct 3, 2017 at 10:55 AM, Thomas Jakway <tjakway at nyu.edu 
> <mailto:tjakway at nyu.edu>> wrote:
>
>     Anyone else getting linker errors?
>
>     /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>     20171003.so: error: undefined reference to 'ffi_type_uint64'
>     chmod +x inplace/bin/runghc
>     /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>     20171003.so: error: undefined reference to 'ffi_type_uint32'
>     /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>     20171003.so: error: undefined reference to 'ffi_type_uint16'
>     /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>     20171003.so: error: undefined reference to 'ffi_type_uint8'
>     /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>     20171003.so: error: undefined reference to 'ffi_type_sint64'
>     /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>     20171003.so: error: undefined reference to 'ffi_type_sint32'
>     /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>     20171003.so: error: undefined reference to 'ffi_type_sint16'
>     /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>     20171003.so: error: undefined reference to 'ffi_type_sint8'
>     /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>     20171003.so: error: undefined reference to 'ffi_type_double'
>     /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>     20171003.so: error: undefined reference to 'ffi_type_float'
>     /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>     20171003.so: error: undefined reference to 'ffi_type_pointer'
>     /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>     20171003.so: error: undefined reference to 'ffi_type_void'
>     /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>     20171003.so: error: undefined reference to 'ffi_prep_cif'
>     collect2: error: ld returned 1 exit status
>     `gcc' failed in phase `Linker'. (Exit code: 1)
>     iserv/ghc.mk:108 <http://ghc.mk:108>: recipe for target
>     'iserv/stage2_dyn/build/tmp/ghc-iserv-dyn' f
>     ailed
>     make[1]: *** [iserv/stage2_dyn/build/tmp/ghc-iserv-dyn] Error 1
>     make[1]: *** Waiting for unfinished jobs....
>     <<ghc: 2235737040 <tel:%28223%29%20573-7040> bytes, 225 GCs,
>     21703308/57027464 avg/max bytes residency (8 s
>     amples), 150M in use, 0.000 INIT (0.000 elapsed), 1.432 MUT (1.681
>     elapsed), 0.5
>     76 GC (0.651 elapsed) :ghc>>
>     Makefile:122: recipe for target 'all' failed
>     make: *** [all] Error 2
>
>
>     This is after running
>
>     make clean && make distclean && find . -name "*.o" -type f -delete
>     && find . -name "*.hi" -type f -delete
>
>     then
>
>     ./boot && ./configure && make -j5
>
>     (ghc-new is not a new checkout, this error is happening on a
>     branch I'm working on, but one that doesn't touch the FFI)
>
>     On 10/01/2017 07:09 PM, Moritz Angermann wrote:
>>     I hope this will be fixed with:
>>     https://phabricator.haskell.org/D4053
>>     <https://phabricator.haskell.org/D4053> and
>>     https://phabricator.haskell.org/D4054
>>     <https://phabricator.haskell.org/D4054>
>>
>>     Sent from my iPhone
>>
>>     On 2 Oct 2017, at 6:33 AM, Ryan Scott <ryan.gl.scott at gmail.com
>>     <mailto:ryan.gl.scott at gmail.com>> wrote:
>>
>>>     Trying to build a fresh copy of GHC HEAD (at commit [1]) today
>>>     failed
>>>     for me with this error: [2]
>>>
>>>        /u/rgscott/Software/ghc4/libffi/build/missing: line 81: makeinfo:
>>>     command not found
>>>        WARNING: 'makeinfo' is missing on your system.
>>>                 You should only need it if you modified a '.texi'
>>>     file, or
>>>                 any other file indirectly affecting the aspect of
>>>     the manual.
>>>                 You might want to install the Texinfo package:
>>>                 <http://www.gnu.org/software/texinfo/
>>>     <http://www.gnu.org/software/texinfo/>>
>>>                 The spurious makeinfo call might also be the
>>>     consequence of
>>>                 using a buggy 'make' (AIX, DU, IRIX), in which case
>>>     you might
>>>                 want to install GNU make:
>>>                 <http://www.gnu.org/software/make/
>>>     <http://www.gnu.org/software/make/>>
>>>
>>>     On my Ubuntu machine, I was able to work around the issue by
>>>     running:
>>>
>>>        apt-get install texinfo
>>>
>>>     But I'm not sure if the texinfo requirement was expected or an
>>>     unintended side effect of recent libffi changes. Do you know what's
>>>     happening here Moritz?
>>>
>>>     Best,
>>>     Ryan S.
>>>     -----
>>>     [1]
>>>     http://git.haskell.org/ghc.git/commit/e515c7f37be97e1c2ccc497ddd0a730e63ddfa82
>>>     <http://git.haskell.org/ghc.git/commit/e515c7f37be97e1c2ccc497ddd0a730e63ddfa82>
>>>     [2] http://lpaste.net/6716863452582772736
>>>     <http://lpaste.net/6716863452582772736>
>>>     _______________________________________________
>>>     ghc-devs mailing list
>>>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>>>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>>
>>
>>     _______________________________________________
>>     ghc-devs mailing list
>>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>
>
>     _______________________________________________
>     ghc-devs mailing list
>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171003/db61994d/attachment-0001.html>

From ben at smart-cactus.org  Tue Oct  3 20:42:08 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 03 Oct 2017 16:42:08 -0400
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <9d4a14bf-d1bd-9fcb-69ad-03019d8948da@nyu.edu>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
 <CAHYM_Vmj10ekRejPMiw4jqoPwUmfukGRub0n+6u7e2VTMYpxMw@mail.gmail.com>
 <9d4a14bf-d1bd-9fcb-69ad-03019d8948da@nyu.edu>
Message-ID: <3D354A76-98BB-44F8-8A2F-3D7FCF714C8A@smart-cactus.org>

Can you confirm which commit you are on?

On October 3, 2017 4:36:48 PM EDT, Thomas Jakway <tjakway at nyu.edu> wrote:
>Not sure.  I ran `git submodule update --init --recursive` and git 
>status says everything's up to date.  I'm on Ubuntu 16.10.
>
>
>On 10/03/2017 02:17 PM, John Leo wrote:
>> I pulled head this morning and built with no problems on a Mac.  I 
>> wonder if you need to pull submodules as well (which I did) or if 
>> you're missing some newly required dependency.
>>
>> John
>>
>> On Tue, Oct 3, 2017 at 10:55 AM, Thomas Jakway <tjakway at nyu.edu 
>> <mailto:tjakway at nyu.edu>> wrote:
>>
>>     Anyone else getting linker errors?
>>
>>    
>/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>     20171003.so: error: undefined reference to 'ffi_type_uint64'
>>     chmod +x inplace/bin/runghc
>>    
>/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>     20171003.so: error: undefined reference to 'ffi_type_uint32'
>>    
>/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>     20171003.so: error: undefined reference to 'ffi_type_uint16'
>>    
>/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>     20171003.so: error: undefined reference to 'ffi_type_uint8'
>>    
>/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>     20171003.so: error: undefined reference to 'ffi_type_sint64'
>>    
>/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>     20171003.so: error: undefined reference to 'ffi_type_sint32'
>>    
>/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>     20171003.so: error: undefined reference to 'ffi_type_sint16'
>>    
>/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>     20171003.so: error: undefined reference to 'ffi_type_sint8'
>>    
>/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>     20171003.so: error: undefined reference to 'ffi_type_double'
>>    
>/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>     20171003.so: error: undefined reference to 'ffi_type_float'
>>    
>/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>     20171003.so: error: undefined reference to 'ffi_type_pointer'
>>    
>/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>     20171003.so: error: undefined reference to 'ffi_type_void'
>>    
>/home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>     20171003.so: error: undefined reference to 'ffi_prep_cif'
>>     collect2: error: ld returned 1 exit status
>>     `gcc' failed in phase `Linker'. (Exit code: 1)
>>     iserv/ghc.mk:108 <http://ghc.mk:108>: recipe for target
>>     'iserv/stage2_dyn/build/tmp/ghc-iserv-dyn' f
>>     ailed
>>     make[1]: *** [iserv/stage2_dyn/build/tmp/ghc-iserv-dyn] Error 1
>>     make[1]: *** Waiting for unfinished jobs....
>>     <<ghc: 2235737040 <tel:%28223%29%20573-7040> bytes, 225 GCs,
>>     21703308/57027464 avg/max bytes residency (8 s
>>     amples), 150M in use, 0.000 INIT (0.000 elapsed), 1.432 MUT
>(1.681
>>     elapsed), 0.5
>>     76 GC (0.651 elapsed) :ghc>>
>>     Makefile:122: recipe for target 'all' failed
>>     make: *** [all] Error 2
>>
>>
>>     This is after running
>>
>>     make clean && make distclean && find . -name "*.o" -type f
>-delete
>>     && find . -name "*.hi" -type f -delete
>>
>>     then
>>
>>     ./boot && ./configure && make -j5
>>
>>     (ghc-new is not a new checkout, this error is happening on a
>>     branch I'm working on, but one that doesn't touch the FFI)
>>
>>     On 10/01/2017 07:09 PM, Moritz Angermann wrote:
>>>     I hope this will be fixed with:
>>>     https://phabricator.haskell.org/D4053
>>>     <https://phabricator.haskell.org/D4053> and
>>>     https://phabricator.haskell.org/D4054
>>>     <https://phabricator.haskell.org/D4054>
>>>
>>>     Sent from my iPhone
>>>
>>>     On 2 Oct 2017, at 6:33 AM, Ryan Scott <ryan.gl.scott at gmail.com
>>>     <mailto:ryan.gl.scott at gmail.com>> wrote:
>>>
>>>>     Trying to build a fresh copy of GHC HEAD (at commit [1]) today
>>>>     failed
>>>>     for me with this error: [2]
>>>>
>>>>        /u/rgscott/Software/ghc4/libffi/build/missing: line 81:
>makeinfo:
>>>>     command not found
>>>>        WARNING: 'makeinfo' is missing on your system.
>>>>                 You should only need it if you modified a '.texi'
>>>>     file, or
>>>>                 any other file indirectly affecting the aspect of
>>>>     the manual.
>>>>                 You might want to install the Texinfo package:
>>>>                 <http://www.gnu.org/software/texinfo/
>>>>     <http://www.gnu.org/software/texinfo/>>
>>>>                 The spurious makeinfo call might also be the
>>>>     consequence of
>>>>                 using a buggy 'make' (AIX, DU, IRIX), in which case
>>>>     you might
>>>>                 want to install GNU make:
>>>>                 <http://www.gnu.org/software/make/
>>>>     <http://www.gnu.org/software/make/>>
>>>>
>>>>     On my Ubuntu machine, I was able to work around the issue by
>>>>     running:
>>>>
>>>>        apt-get install texinfo
>>>>
>>>>     But I'm not sure if the texinfo requirement was expected or an
>>>>     unintended side effect of recent libffi changes. Do you know
>what's
>>>>     happening here Moritz?
>>>>
>>>>     Best,
>>>>     Ryan S.
>>>>     -----
>>>>     [1]
>>>>    
>http://git.haskell.org/ghc.git/commit/e515c7f37be97e1c2ccc497ddd0a730e63ddfa82
>>>>    
><http://git.haskell.org/ghc.git/commit/e515c7f37be97e1c2ccc497ddd0a730e63ddfa82>
>>>>     [2] http://lpaste.net/6716863452582772736
>>>>     <http://lpaste.net/6716863452582772736>
>>>>     _______________________________________________
>>>>     ghc-devs mailing list
>>>>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>>>>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>>>
>>>
>>>     _______________________________________________
>>>     ghc-devs mailing list
>>>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>>>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>>
>>
>>     _______________________________________________
>>     ghc-devs mailing list
>>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>>
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171003/66581e2d/attachment.html>

From simonpj at microsoft.com  Wed Oct  4 09:08:05 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 4 Oct 2017 09:08:05 +0000
Subject: GHC rewrite rule type-checking failure
In-Reply-To: <CAD6SzRJj_J-RMzYa0bjG_5LmcxHSzXLo01NbJZWWaF5SH+JKxA@mail.gmail.com>
References: <CAD6SzRKj2Kz044CkbXA2FAzAY0oRMftxvb-QeAZ8o0zCSW1WNg@mail.gmail.com>
 <1506984729.1122.11.camel@joachim-breitner.de>
 <CAD6SzRLUsAqCkcXWEZde-VptDyWtQtJrCrOOwdVwvLaBL619ww@mail.gmail.com>
 <AM4PR83MB0033AA97DAEE401F72650ADDAD720@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CAD6SzRLk08aWNqK+_5K=vAVj6Vi37bPQJWnS9yky8PPQ9gw4MQ@mail.gmail.com>
 <AM4PR83MB0033D000E03DBAE2A56FFF3FAD720@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CAD6SzRJj_J-RMzYa0bjG_5LmcxHSzXLo01NbJZWWaF5SH+JKxA@mail.gmail.com>
Message-ID: <AM4PR83MB00330DEA1ADBE69E8312EDB7AD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>

The new bit here is that `$dC'` is not found via matching in the LHS, but rather by instance resolution from `k`, which does appear explicitly in the LHS

Well this would be something qualitatively new.  We don’t that ability in rules; and it’s far from clear to me what it would mean anyway.  I suppose that if k was instantiated to a ground type then you might hope to solve it, but what if it was instantiated to some in-scope type variable t, and some variable of type (C t) was in scope.  Should that work too?

I’m highly dubious.

Happily it sounds as if you are making progress with help from Joachim.

Simon

From: conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] On Behalf Of Conal Elliott
Sent: 03 October 2017 16:30
To: Simon Peyton Jones <simonpj at microsoft.com>
Subject: Re: GHC rewrite rule type-checking failure


The revised example I gave earlier in the thread:

``` haskell
class C k where comp' :: k b c -> k a b -> k a c

instance C (->) where comp' = (.)

-- Late-inlining version to enable rewriting.
comp :: C k => k b c -> k a b -> k a c
comp = comp'
{-# INLINE [0] comp #-}

morph :: (a -> b) -> k a b
morph = error "morph: undefined"

{-# RULES "morph/(.)" forall f g. morph (g `comp` f) = morph g `comp` morph f #-}

-- • Could not deduce (C k) arising from a use of ‘comp’
--   from the context: C (->)
--     bound by the RULE "morph/(.)"
```

A hypothetical generated Core rule (tweaked slightly from Joachim's note):

``` haskell
forall (@ k) (@ b) (@ c) (@ a)
       ($dC :: C (->))
       (f :: a -> b) (g :: b -> c).
  morph @ k @ a @ c (comp @ (->) @ b @ c @ a $dC g f)
  = comp @ k @ b @ c @ a
      $dC'
      (morph @ k @ b @ c g)
      (morph @ k @ a @ b f)
 where
   $dC' :: C k
```

The new bit here is that `$dC'` is not found via matching in the LHS, but rather by instance resolution from `k`, which does appear explicitly in the LHS. If `C k` cannot be solved, the rule fails. The "where" clause here lists the dictionary variables to be instantiated by instance resolution rather than matching.

-- Conal


On Tue, Oct 3, 2017 at 8:01 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
But synthesising from what?

And currently no: there is no type-class dictionary synthesis after the type checker.  Not impossible I suppose, but one more fragility: a rule does not fire because some synthesis thing didn’t happen.    Maybe give an as-simple-as-poss example of what you have in mind, now you understand the situation better?   With all the type and dictionary abstractions written explicitly…

S

From: conal.elliott at gmail.com<mailto:conal.elliott at gmail.com> [mailto:conal.elliott at gmail.com<mailto:conal.elliott at gmail.com>] On Behalf Of Conal Elliott
Sent: 03 October 2017 15:56
To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>

Subject: Re: GHC rewrite rule type-checking failure

Thanks, Simon. Your explanation make sense to me. Do you think that the rewrite rule mechanism could be enhanced to try synthesizing the needed dictionaries after LHS matching and before RHS instantiation? I'm doing as much now in my compiling-to-categories plugin, but without the convenience of using concrete syntax for the rules.

Regard, - Conal


On Tue, Oct 3, 2017 at 12:27 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
*   Is it feasible for GHC to combine the constraints needed LHS and RHS to form an applicability condition?
I don’t think so.

Remember that a rewrite rule literally rewrites LHS to RHS.  It does not conjure up any new dictionaries out of thin air.  In your example, (D k b) is needed in the result of the rewrite.  Where can it come from?  Only from something matched on the left.

So GHC treats any dictionaries matched on the left as “givens” and tries to solve the ones matched on the left.  If it fails you get the sort of error you see.

One way to see this is to write out the rewrite rule you want, complete with all its dictionary arguments. Can you do that?

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org<mailto:glasgow-haskell-users-bounces at haskell.org>] On Behalf Of Conal Elliott
Sent: 03 October 2017 01:03
To: Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>>
Cc: glasgow-haskell-users at haskell.org<mailto:glasgow-haskell-users at haskell.org>
Subject: Re: GHC rewrite rule type-checking failure

Thanks very much for the reply, Joachim.

Oops! I flubbed the example. I really `morph` to distribute over an application of `comp`. New code below (and attached). You're right that I wouldn't want to restrict the type of `morph`, since each `morph` *rule* imposes its own restrictions.

My questions:

*   Is it feasible for GHC to combine the constraints needed LHS and RHS to form an applicability condition?
*   Is there any way I can make the needed constraints explicit in my rewrite rules?
*   Are there any other work-arounds that would enable writing such RHS-constrained rules?

Regards, -- Conal

``` haskell
{-# OPTIONS_GHC -Wall #-}
-- Demonstrate a type checking failure with rewrite rules

module RuleFail where

class C k where comp' :: k b c -> k a b -> k a c

instance C (->) where comp' = (.)

-- Late-inlining version to enable rewriting.
comp :: C k => k b c -> k a b -> k a c
comp = comp'
{-# INLINE [0] comp #-}

morph :: (a -> b) -> k a b
morph = error "morph: undefined"

{-# RULES "morph/(.)" forall f g. morph (g `comp` f) = morph g `comp` morph f #-}

-- • Could not deduce (C k) arising from a use of ‘comp’
--   from the context: C (->)
--     bound by the RULE "morph/(.)"
```


On Mon, Oct 2, 2017 at 3:52 PM, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Hi Conal,

The difference is that the LHS of the first rule is mentions the `C k`
constraint (probably unintentionally):

*RuleFail> :t morph comp
morph comp :: C k => k1 (k b c) (k a b -> k a c)

but the LHS of the second rule side does not:

*RuleFail> :t morph addC
morph addC :: Num b => k (b, b) b



A work-around is to add the constraint to `morph`:

    morph :: D k b => (a -> b) -> k a b
    morph = error "morph: undefined"

    but I fear that this work-around is not acceptable to you.

    Joachim

    Am Montag, den 02.10.2017, 14:25 -0700 schrieb Conal Elliott:
    > -- Demonstrate a type checking failure with rewrite rules
>
> module RuleFail where
>
> class C k where comp' :: k b c -> k a b -> k a c
>
> instance C (->) where comp' = (.)
>
> -- Late-inlining version to enable rewriting.
> comp :: C k => k b c -> k a b -> k a c
> comp = comp'
> {-# INLINE [0] comp #-}
>
> morph :: (a -> b) -> k a b
> morph = error "morph: undefined"
>
> {-# RULES "morph/(.)" morph comp = comp #-}  -- Fine



> class D k a where addC' :: k (a,a) a
>
> instance Num a => D (->) a where addC' = uncurry (+)
>
> -- Late-inlining version to enable rewriting.
> addC :: D k a => k (a,a) a
> addC = addC'
> {-# INLINE [0] addC #-}
>
> {-# RULES "morph/addC" morph addC = addC #-}  -- Fail
>
> -- • Could not deduce (D k b) arising from a use of ‘addC’
> --   from the context: D (->) b
>
> -- Why does GHC infer the (C k) constraint for the first rule but not (D k b)
> -- for the second rule?
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org<mailto:Glasgow-haskell-users at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users&data=02%7C01%7Csimonpj%40microsoft.com%7C3da5c75572694bab31aa08d509f25936%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636425858847457302&sdata=6dcqjyAYmKXKwZzQQExmWl1cJlCySmP1EvdjA03O19M%3D&reserved=0>
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C3da5c75572694bab31aa08d509f25936%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636425858847457302&sdata=Uoe%2Bw8T3VMFLRsFY%2B8nacXIV0pUQOyCe4iHz%2FS5kGrA%3D&reserved=0>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171004/887eea3c/attachment-0001.html>

From simonpj at microsoft.com  Wed Oct  4 10:17:41 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 4 Oct 2017 10:17:41 +0000
Subject: Windows build broken
Message-ID: <AM4PR83MB00332D873CE6BE469E5FE85BAD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>

My Windows build is broken again.  With a clean checkout, I get ""

Target platform inferred as: x86_64-unknown-mingw32

Unknown OS msys
How can I get past this?  Full log below.
Simon




make[1]: Leaving directory '/c/code/HEAD/testsuite'

['libraries/array/', 'libraries/base/', 'libraries/binary/', 'libraries/bytestring/', 'libraries/Cabal/Cabal', 'libraries/Cabal/', 'libraries/compact/', 'libraries/containers/', 'libraries/deepseq/', 'libraries/directory/', 'libraries/doc/', 'libraries/dph/dph-base', 'libraries/dph/dph-prim-interface', 'libraries/dph/dph-prim-seq', 'libraries/dph/dph-prim-par', 'libraries/dph/dph-lifted-base', 'libraries/dph/dph-lifted-boxed', 'libraries/dph/dph-lifted-copy', 'libraries/dph/dph-lifted-vseg', 'libraries/dph/', 'libraries/dph/', 'libraries/filepath/', 'libraries/ghc-boot/', 'libraries/ghc-boot-th/', 'libraries/ghc-compact/', 'libraries/ghc-prim/', 'libraries/ghci/', 'libraries/haskeline/', 'libraries/hoopl/', 'libraries/hpc/', 'libraries/integer-gmp/', 'libraries/integer-simple/', 'libraries/mtl/', 'libraries/parallel/', 'libraries/parsec/', 'libraries/pretty/', 'libraries/primitive/', 'libraries/process/', 'libraries/random/', 'libraries/stm/', 'libraries/template-haskell/', 'libraries/terminfo/', 'libraries/text/', 'libraries/time/', 'libraries/transformers/', 'libraries/unix/', 'libraries/vector/', 'libraries/Win32/', 'libraries/xhtml/']

Creating libraries/array/ghc.mk

Creating libraries/base/ghc.mk

Creating libraries/binary/ghc.mk

Creating libraries/bytestring/ghc.mk

Creating libraries/Cabal/Cabal/ghc.mk

Creating libraries/containers/ghc.mk

Creating libraries/deepseq/ghc.mk

Creating libraries/directory/ghc.mk

Creating libraries/dph/dph-base/ghc.mk

Creating libraries/dph/dph-prim-interface/ghc.mk

Creating libraries/dph/dph-prim-seq/ghc.mk

Creating libraries/dph/dph-prim-par/ghc.mk

Creating libraries/dph/dph-lifted-base/ghc.mk

Creating libraries/dph/dph-lifted-boxed/ghc.mk

Creating libraries/dph/dph-lifted-copy/ghc.mk

Creating libraries/dph/dph-lifted-vseg/ghc.mk

Creating libraries/filepath/ghc.mk

Creating libraries/ghc-boot/ghc.mk

Creating libraries/ghc-boot-th/ghc.mk

Creating libraries/ghc-compact/ghc.mk

Creating libraries/ghc-prim/ghc.mk

Creating libraries/ghci/ghc.mk

Creating libraries/haskeline/ghc.mk

Creating libraries/hoopl/ghc.mk

Creating libraries/hpc/ghc.mk

Creating libraries/integer-gmp/ghc.mk

Creating libraries/integer-simple/ghc.mk

Creating libraries/mtl/ghc.mk

Creating libraries/parallel/ghc.mk

Creating libraries/parsec/ghc.mk

Creating libraries/pretty/ghc.mk

Creating libraries/primitive/ghc.mk

Creating libraries/process/ghc.mk

Creating libraries/random/ghc.mk

Creating libraries/stm/ghc.mk

Creating libraries/template-haskell/ghc.mk

Creating libraries/terminfo/ghc.mk

Creating libraries/text/ghc.mk

Creating libraries/time/ghc.mk

Creating libraries/transformers/ghc.mk

Creating libraries/unix/ghc.mk

Creating libraries/vector/ghc.mk

Creating libraries/Win32/ghc.mk

Creating libraries/xhtml/ghc.mk

Booting .

Booting libraries/base/

Booting libraries/directory/

Booting libraries/integer-gmp/

Booting libraries/process/

Booting libraries/terminfo/

Booting libraries/time/

Booting libraries/unix/

checking for gfind... no

checking for find... /usr/bin/find

checking for sort... /usr/bin/sort

checking for GHC version date... inferred 8.3.20171004

checking for GHC Git commit id... inferred 3030eee24c9d538f7ae2c854fd86129563b6ddf3

checking for ghc... /c/fp/ghc-8.0.2/bin/ghc

checking version of ghc... 8.0.2

GHC path canonicalised to: c:/fp/ghc-8.0.2/bin/ghc

checking build system type... x86_64-pc-msys

checking host system type... x86_64-pc-msys

checking target system type... x86_64-pc-msys

Build platform inferred as: x86_64-unknown-mingw32

Host platform inferred as: x86_64-unknown-mingw32

Target platform inferred as: x86_64-unknown-mingw32

Unknown OS msys

/c/code/HEAD$ git pull

Already up-to-date.

/c/code/HEAD$ git submodule update

/c/code/HEAD$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171004/0ba40a0b/attachment.html>

From lonetiger at gmail.com  Wed Oct  4 12:29:51 2017
From: lonetiger at gmail.com (Phyx)
Date: Wed, 04 Oct 2017 12:29:51 +0000
Subject: Windows build broken
In-Reply-To: <AM4PR83MB00332D873CE6BE469E5FE85BAD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
References: <AM4PR83MB00332D873CE6BE469E5FE85BAD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
Message-ID: <CABHktDWiFoOBkmKg2dMON0Zay3DcvsdLYaC_9RWkzqY34Z=wXg@mail.gmail.com>

Hi Simon,

You seem to be in an msys shell instead of a mingw-64 shell (they have
different startup shortcuts). We don't support the msys shell as we only
want to compile for native windows.

You should use the shortcut marked mingw-64.

Alternatively to get you going in aclocal.m4 remove line 112.

Or

run 'export MSYSTEM=MINGW64' to change subsystem.


The recent llvm changes now force the host validation on all targets, I'll
add msys when I get home.

Kind regards,

Tamar

On Wed, Oct 4, 2017, 11:19 Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org> wrote:

> My Windows build is broken again.  With a clean checkout, I get “”
>
> Target platform inferred as: x86_64-unknown-mingw32
>
> Unknown OS msys
>
> How can I get past this?  Full log below.
>
> Simon
>
>
>
>
>
> make[1]: Leaving directory '/c/code/HEAD/testsuite'
>
> ['libraries/array/', 'libraries/base/', 'libraries/binary/',
> 'libraries/bytestring/', 'libraries/Cabal/Cabal', 'libraries/Cabal/',
> 'libraries/compact/', 'libraries/containers/', 'libraries/deepseq/',
> 'libraries/directory/', 'libraries/doc/', 'libraries/dph/dph-base',
> 'libraries/dph/dph-prim-interface', 'libraries/dph/dph-prim-seq',
> 'libraries/dph/dph-prim-par', 'libraries/dph/dph-lifted-base',
> 'libraries/dph/dph-lifted-boxed', 'libraries/dph/dph-lifted-copy',
> 'libraries/dph/dph-lifted-vseg', 'libraries/dph/', 'libraries/dph/',
> 'libraries/filepath/', 'libraries/ghc-boot/', 'libraries/ghc-boot-th/',
> 'libraries/ghc-compact/', 'libraries/ghc-prim/', 'libraries/ghci/',
> 'libraries/haskeline/', 'libraries/hoopl/', 'libraries/hpc/',
> 'libraries/integer-gmp/', 'libraries/integer-simple/', 'libraries/mtl/',
> 'libraries/parallel/', 'libraries/parsec/', 'libraries/pretty/',
> 'libraries/primitive/', 'libraries/process/', 'libraries/random/',
> 'libraries/stm/', 'libraries/template-haskell/', 'libraries/terminfo/',
> 'libraries/text/', 'libraries/time/', 'libraries/transformers/',
> 'libraries/unix/', 'libraries/vector/', 'libraries/Win32/',
> 'libraries/xhtml/']
>
> Creating libraries/array/ghc.mk
>
> Creating libraries/base/ghc.mk
>
> Creating libraries/binary/ghc.mk
>
> Creating libraries/bytestring/ghc.mk
>
> Creating libraries/Cabal/Cabal/ghc.mk
>
> Creating libraries/containers/ghc.mk
>
> Creating libraries/deepseq/ghc.mk
>
> Creating libraries/directory/ghc.mk
>
> Creating libraries/dph/dph-base/ghc.mk
>
> Creating libraries/dph/dph-prim-interface/ghc.mk
>
> Creating libraries/dph/dph-prim-seq/ghc.mk
>
> Creating libraries/dph/dph-prim-par/ghc.mk
>
> Creating libraries/dph/dph-lifted-base/ghc.mk
>
> Creating libraries/dph/dph-lifted-boxed/ghc.mk
>
> Creating libraries/dph/dph-lifted-copy/ghc.mk
>
> Creating libraries/dph/dph-lifted-vseg/ghc.mk
>
> Creating libraries/filepath/ghc.mk
>
> Creating libraries/ghc-boot/ghc.mk
>
> Creating libraries/ghc-boot-th/ghc.mk
>
> Creating libraries/ghc-compact/ghc.mk
>
> Creating libraries/ghc-prim/ghc.mk
>
> Creating libraries/ghci/ghc.mk
>
> Creating libraries/haskeline/ghc.mk
>
> Creating libraries/hoopl/ghc.mk
>
> Creating libraries/hpc/ghc.mk
>
> Creating libraries/integer-gmp/ghc.mk
>
> Creating libraries/integer-simple/ghc.mk
>
> Creating libraries/mtl/ghc.mk
>
> Creating libraries/parallel/ghc.mk
>
> Creating libraries/parsec/ghc.mk
>
> Creating libraries/pretty/ghc.mk
>
> Creating libraries/primitive/ghc.mk
>
> Creating libraries/process/ghc.mk
>
> Creating libraries/random/ghc.mk
>
> Creating libraries/stm/ghc.mk
>
> Creating libraries/template-haskell/ghc.mk
>
> Creating libraries/terminfo/ghc.mk
>
> Creating libraries/text/ghc.mk
>
> Creating libraries/time/ghc.mk
>
> Creating libraries/transformers/ghc.mk
>
> Creating libraries/unix/ghc.mk
>
> Creating libraries/vector/ghc.mk
>
> Creating libraries/Win32/ghc.mk
>
> Creating libraries/xhtml/ghc.mk
>
> Booting .
>
> Booting libraries/base/
>
> Booting libraries/directory/
>
> Booting libraries/integer-gmp/
>
> Booting libraries/process/
>
> Booting libraries/terminfo/
>
> Booting libraries/time/
>
> Booting libraries/unix/
>
> checking for gfind... no
>
> checking for find... /usr/bin/find
>
> checking for sort... /usr/bin/sort
>
> checking for GHC version date... inferred 8.3.20171004
>
> checking for GHC Git commit id... inferred
> 3030eee24c9d538f7ae2c854fd86129563b6ddf3
>
> checking for ghc... /c/fp/ghc-8.0.2/bin/ghc
>
> checking version of ghc... 8.0.2
>
> GHC path canonicalised to: c:/fp/ghc-8.0.2/bin/ghc
>
> checking build system type... x86_64-pc-msys
>
> checking host system type... x86_64-pc-msys
>
> checking target system type... x86_64-pc-msys
>
> Build platform inferred as: x86_64-unknown-mingw32
>
> Host platform inferred as: x86_64-unknown-mingw32
>
> Target platform inferred as: x86_64-unknown-mingw32
>
> Unknown OS msys
>
> /c/code/HEAD$ git pull
>
> Already up-to-date.
>
> /c/code/HEAD$ git submodule update
>
> /c/code/HEAD$
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171004/1f74c3c1/attachment.html>

From ben at smart-cactus.org  Wed Oct  4 12:39:41 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 04 Oct 2017 08:39:41 -0400
Subject: Windows build broken
In-Reply-To: <CABHktDWiFoOBkmKg2dMON0Zay3DcvsdLYaC_9RWkzqY34Z=wXg@mail.gmail.com>
References: <AM4PR83MB00332D873CE6BE469E5FE85BAD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CABHktDWiFoOBkmKg2dMON0Zay3DcvsdLYaC_9RWkzqY34Z=wXg@mail.gmail.com>
Message-ID: <87wp4bozn6.fsf@ben-laptop.smart-cactus.org>

Phyx <lonetiger at gmail.com> writes:

> Hi Simon,
>
> You seem to be in an msys shell instead of a mingw-64 shell (they have
> different startup shortcuts). We don't support the msys shell as we only
> want to compile for native windows.
>
> You should use the shortcut marked mingw-64.
>
> Alternatively to get you going in aclocal.m4 remove line 112.
>
> Or
>
> run 'export MSYSTEM=MINGW64' to change subsystem.
>
>
> The recent llvm changes now force the host validation on all targets, I'll
> add msys when I get home.
>
I've gone ahead and added msys.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171004/bddbfec6/attachment.sig>

From simonpj at microsoft.com  Wed Oct  4 12:41:01 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 4 Oct 2017 12:41:01 +0000
Subject: Windows build broken
In-Reply-To: <CABHktDWiFoOBkmKg2dMON0Zay3DcvsdLYaC_9RWkzqY34Z=wXg@mail.gmail.com>
References: <AM4PR83MB00332D873CE6BE469E5FE85BAD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CABHktDWiFoOBkmKg2dMON0Zay3DcvsdLYaC_9RWkzqY34Z=wXg@mail.gmail.com>
Message-ID: <AM4PR83MB0033C05D4B6AEDF1DFBFE2DDAD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>

I’m in a shell inside emacs.
My $SHELL variable (which emacs uses to invoke it) is
            c:/msys64/usr/bin/bash.exe

Should it be something else?

run 'export MSYSTEM=MINGW64' to change subsystem.

That worked.  Should I add it to my .bashrc, or are you going to do something else?

Thanks


From: Phyx [mailto:lonetiger at gmail.com]
Sent: 04 October 2017 13:30
To: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs at haskell.org
Subject: Re: Windows build broken

Hi Simon,

You seem to be in an msys shell instead of a mingw-64 shell (they have different startup shortcuts). We don't support the msys shell as we only want to compile for native windows.

You should use the shortcut marked mingw-64.

Alternatively to get you going in aclocal.m4 remove line 112.

Or

run 'export MSYSTEM=MINGW64' to change subsystem.



The recent llvm changes now force the host validation on all targets, I'll add msys when I get home.

Kind regards,

Tamar

On Wed, Oct 4, 2017, 11:19 Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>> wrote:
My Windows build is broken again.  With a clean checkout, I get “”

Target platform inferred as: x86_64-unknown-mingw32

Unknown OS msys
How can I get past this?  Full log below.
Simon




make[1]: Leaving directory '/c/code/HEAD/testsuite'

['libraries/array/', 'libraries/base/', 'libraries/binary/', 'libraries/bytestring/', 'libraries/Cabal/Cabal', 'libraries/Cabal/', 'libraries/compact/', 'libraries/containers/', 'libraries/deepseq/', 'libraries/directory/', 'libraries/doc/', 'libraries/dph/dph-base', 'libraries/dph/dph-prim-interface', 'libraries/dph/dph-prim-seq', 'libraries/dph/dph-prim-par', 'libraries/dph/dph-lifted-base', 'libraries/dph/dph-lifted-boxed', 'libraries/dph/dph-lifted-copy', 'libraries/dph/dph-lifted-vseg', 'libraries/dph/', 'libraries/dph/', 'libraries/filepath/', 'libraries/ghc-boot/', 'libraries/ghc-boot-th/', 'libraries/ghc-compact/', 'libraries/ghc-prim/', 'libraries/ghci/', 'libraries/haskeline/', 'libraries/hoopl/', 'libraries/hpc/', 'libraries/integer-gmp/', 'libraries/integer-simple/', 'libraries/mtl/', 'libraries/parallel/', 'libraries/parsec/', 'libraries/pretty/', 'libraries/primitive/', 'libraries/process/', 'libraries/random/', 'libraries/stm/', 'libraries/template-haskell/', 'libraries/terminfo/', 'libraries/text/', 'libraries/time/', 'libraries/transformers/', 'libraries/unix/', 'libraries/vector/', 'libraries/Win32/', 'libraries/xhtml/']

Creating libraries/array/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/base/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/binary/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/bytestring/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/Cabal/Cabal/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/containers/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/deepseq/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/directory/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/dph/dph-base/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/dph/dph-prim-interface/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/dph/dph-prim-seq/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/dph/dph-prim-par/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/dph/dph-lifted-base/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/dph/dph-lifted-boxed/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/dph/dph-lifted-copy/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/dph/dph-lifted-vseg/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/filepath/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/ghc-boot/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/ghc-boot-th/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/ghc-compact/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/ghc-prim/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/ghci/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/haskeline/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/hoopl/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/hpc/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/integer-gmp/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/integer-simple/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/mtl/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/parallel/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/parsec/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/pretty/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/primitive/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/process/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/random/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/stm/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/template-haskell/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/terminfo/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/text/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/time/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/transformers/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/unix/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/vector/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/Win32/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Creating libraries/xhtml/ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=lmAzM4n0Tv2BEY7Lg3tDJ61iXsBgtEPhqxxo5vACpsg%3D&reserved=0>

Booting .

Booting libraries/base/

Booting libraries/directory/

Booting libraries/integer-gmp/

Booting libraries/process/

Booting libraries/terminfo/

Booting libraries/time/

Booting libraries/unix/

checking for gfind... no

checking for find... /usr/bin/find

checking for sort... /usr/bin/sort

checking for GHC version date... inferred 8.3.20171004

checking for GHC Git commit id... inferred 3030eee24c9d538f7ae2c854fd86129563b6ddf3

checking for ghc... /c/fp/ghc-8.0.2/bin/ghc

checking version of ghc... 8.0.2

GHC path canonicalised to: c:/fp/ghc-8.0.2/bin/ghc

checking build system type... x86_64-pc-msys

checking host system type... x86_64-pc-msys

checking target system type... x86_64-pc-msys

Build platform inferred as: x86_64-unknown-mingw32

Host platform inferred as: x86_64-unknown-mingw32

Target platform inferred as: x86_64-unknown-mingw32

Unknown OS msys

/c/code/HEAD$ git pull

Already up-to-date.

/c/code/HEAD$ git submodule update

/c/code/HEAD$
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7C5ced6932c9594ac82e6108d50b23a333%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427170048887704&sdata=9YnBlXzt8RksPcEPk0wbDQu0qfBkk63G0CPf44nI2wI%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171004/a6bf56c5/attachment-0001.html>

From simonpj at microsoft.com  Wed Oct  4 12:54:52 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 4 Oct 2017 12:54:52 +0000
Subject: More windows
Message-ID: <AM4PR83MB0033115CEDF01DB5AF3CC0E8AD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>

Now in my Windows build, staring with "sh validate -fast -no-clean" I get

[230 of 232] Compiling Distribution.PackageDescription.Parsec ( libraries\Cabal\Cabal\Distribution\PackageDescription\Parsec.hs, bootstrapping\Distribution\PackageDescription\Parsec.o )

[231 of 232] Compiling Distribution.Simple ( libraries\Cabal\Cabal\Distribution\Simple.hs, bootstrapping\Distribution\Simple.o )

[232 of 232] Compiling Main             ( utils\ghc-cabal\Main.hs, bootstrapping\Main.o )

Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

utils/genprimopcode/ghc.mk:19: utils/genprimopcode/dist/package-data.mk: No such file or directory

make[1]: *** [utils/ghc-cabal/ghc.mk:57: utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1

make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'

make: *** [Makefile:123: all] Error 2

Simply repeating, thus "sh validate -fast", I then get the same error

/c/code/HEAD$ ls -l utils/ghc-cabal/dist/build/tmp/

total 0

/c/code/HEAD$ sh validate --fast --no-clean

using THREADS=5

make: Entering directory '/c/code/HEAD/utils/checkUniques'

./check-uniques.py ../..

make: Leaving directory '/c/code/HEAD/utils/checkUniques'

===--- building phase 0

make --no-print-directory -f ghc.mk phase=0 phase_0_builds

"c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \

       -optc-Wall -optc-Werror -optc-fno-stack-protector \

        \

       -hide-all-packages \

       -package ghc-prim -package base -package array -package transformers -package time -package containers -package bytestring -package deepseq -package process -package pretty -package directory -package Win32 \

       --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \

       -no-user-package-db \

       -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \

       -DCABAL_VERSION=2,0,0,2 \

       -DCABAL_PARSEC \

       -DBOOTSTRAPPING \

       -odir  bootstrapping \

       -hidir bootstrapping \

       bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \

       -ilibraries/Cabal/Cabal \

       -ilibraries/binary/src \

       -ilibraries/filepath \

       -ilibraries/hpc \

       -ilibraries/mtl \

       -ilibraries/text \

       libraries/text/cbits/cbits.c \

       -Ilibraries/text/include \

       -ilibraries/parsec \

        \



Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

make[1]: *** [utils/ghc-cabal/ghc.mk:57: utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1

make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'

make: *** [Makefile:123: all] Error 2

But trying "sh validate -fast" once more succeeds:

/c/code/HEAD$ sh validate --fast --no-clean

using THREADS=5

make: Entering directory '/c/code/HEAD/utils/checkUniques'

./check-uniques.py ../..

make: Leaving directory '/c/code/HEAD/utils/checkUniques'

===--- building phase 0

make --no-print-directory -f ghc.mk phase=0 phase_0_builds

"c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \

       -optc-Wall -optc-Werror -optc-fno-stack-protector \

        \

       -hide-all-packages \

       -package ghc-prim -package base -package array -package transformers -package time -package containers -package bytestring -package deepseq -package process -package pretty -package directory -package Win32 \

       --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \

       -no-user-package-db \

       -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \

       -DCABAL_VERSION=2,0,0,2 \

       -DCABAL_PARSEC \

       -DBOOTSTRAPPING \

       -odir  bootstrapping \

       -hidir bootstrapping \

       bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \

       -ilibraries/Cabal/Cabal \

       -ilibraries/binary/src \

       -ilibraries/filepath \

       -ilibraries/hpc \

       -ilibraries/mtl \

       -ilibraries/text \

       libraries/text/cbits/cbits.c \

       -Ilibraries/text/include \

       -ilibraries/parsec \

        \



Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

"cp" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe inplace/bin/ghc-cabal.exe

"inplace/bin/ghc-cabal.exe" configure libraries/binary dist-boot --with-ghc="c:/fp/ghc-8.0.2/bin/ghc.exe" --with-ghc-pkg="c:/fp/ghc-8.0.2/bin/ghc-pkg"  --package-db=C:/code/HEAD/libraries/bootstrapping.conf --disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci --disable-library-profiling --disable-shared --with-hscolour="/c/fp/HP-8.0.1/lib/extralibs/bin/HsColour" --configure-option=CFLAGS="-Wall -fno-stack-protector    -Wno-error=inline" --configure-option=LDFLAGS="  " --configure-option=CPPFLAGS="   " --gcc-options="-Wall -fno-stack-protector    -Wno-error=inline   "   --constraint "binary == 0.8.5.1"   --constraint "text == 1.2.3.0"   --constraint "transformers == 0.5.4.0"   --constraint "mtl == 2.2.2"   --constraint "parsec == 3.1.12"   --constraint "Cabal == 2.0.0.2"   --constraint "hpc == 0.6.0.3"   --constraint "ghc-boot-th == 8.3"   --constraint "ghc-boot == 8.3"   --constraint "template-haskell == 2.13.0.0"   --constraint "ghci == 8.3" --with-gcc="C:/fp/ghc-8.0.2/lib/../mingw/bin/gcc.exe" --with-ld="C:/fp/ghc-8.0.2/lib/../mingw/bin/ld.exe" --with-ar="C:/fp/ghc-8.0.2/lib/../mingw/bin/ar.exe" --with-alex="/c/fp/HP-8.0.1/lib/extralibs/bin/alex" --with-happy="/c/fp/HP-8.0.1/lib/extralibs/bin/happy"
...etc etc

I'm stumped.

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171004/8c789953/attachment.html>

From lonetiger at gmail.com  Wed Oct  4 13:17:07 2017
From: lonetiger at gmail.com (Phyx)
Date: Wed, 04 Oct 2017 13:17:07 +0000
Subject: More windows
In-Reply-To: <AM4PR83MB0033115CEDF01DB5AF3CC0E8AD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
References: <AM4PR83MB0033115CEDF01DB5AF3CC0E8AD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
Message-ID: <CABHktDXQHijJbxur2LdksQmLxMHQD72Pp69Ubig++++48fgvWg@mail.gmail.com>

This looks like a file lock issue. Just to double check, but do you have
the build folder excluded from the antivirus scanner?

On Wed, Oct 4, 2017, 13:57 Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org> wrote:

> Now in my Windows build, staring with “sh validate –fast –no-clean” I get
>
> [230 of 232] Compiling Distribution.PackageDescription.Parsec (
> libraries\Cabal\Cabal\Distribution\PackageDescription\Parsec.hs,
> bootstrapping\Distribution\PackageDescription\Parsec.o )
>
> [231 of 232] Compiling Distribution.Simple (
> libraries\Cabal\Cabal\Distribution\Simple.hs,
> bootstrapping\Distribution\Simple.o )
>
> [232 of 232] Compiling Main             ( utils\ghc-cabal\Main.hs,
> bootstrapping\Main.o )
>
> Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...
>
> "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
>
> Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
>
> utils/genprimopcode/ghc.mk:19: utils/genprimopcode/dist/package-data.mk:
> No such file or directory
>
> make[1]: *** [utils/ghc-cabal/ghc.mk:57:
> utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1
>
> make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'
>
> make: *** [Makefile:123: all] Error 2
>
>
>
> Simply repeating, thus “sh validate –fast”, I then get the same error
>
> /c/code/HEAD$ ls -l utils/ghc-cabal/dist/build/tmp/
>
> total 0
>
> /c/code/HEAD$ sh validate --fast --no-clean
>
> using THREADS=5
>
> make: Entering directory '/c/code/HEAD/utils/checkUniques'
>
> ./check-uniques.py ../..
>
> make: Leaving directory '/c/code/HEAD/utils/checkUniques'
>
> ===--- building phase 0
>
> make --no-print-directory -f ghc.mk phase=0 phase_0_builds
>
> "c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \
>
>        -optc-Wall -optc-Werror -optc-fno-stack-protector \
>
>         \
>
>        -hide-all-packages \
>
>        -package ghc-prim -package base -package array -package
> transformers -package time -package containers -package bytestring -package
> deepseq -package process -package pretty -package directory -package Win32 \
>
>        --make utils/ghc-cabal/Main.hs -o
> utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \
>
>        -no-user-package-db \
>
>        -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \
>
>        -DCABAL_VERSION=2,0,0,2 \
>
>        -DCABAL_PARSEC \
>
>        -DBOOTSTRAPPING \
>
>        -odir  bootstrapping \
>
>        -hidir bootstrapping \
>
>        bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \
>
>        -ilibraries/Cabal/Cabal \
>
>        -ilibraries/binary/src \
>
>        -ilibraries/filepath \
>
>        -ilibraries/hpc \
>
>        -ilibraries/mtl \
>
>        -ilibraries/text \
>
>        libraries/text/cbits/cbits.c \
>
>        -Ilibraries/text/include \
>
>        -ilibraries/parsec \
>
>         \
>
>
>
> Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...
>
> "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
>
> Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
>
> make[1]: *** [utils/ghc-cabal/ghc.mk:57:
> utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1
>
> make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'
>
> make: *** [Makefile:123: all] Error 2
>
>
>
> But trying “sh validate –fast” once more succeeds:
>
> /c/code/HEAD$ sh validate --fast --no-clean
>
> using THREADS=5
>
> make: Entering directory '/c/code/HEAD/utils/checkUniques'
>
> ./check-uniques.py ../..
>
> make: Leaving directory '/c/code/HEAD/utils/checkUniques'
>
> ===--- building phase 0
>
> make --no-print-directory -f ghc.mk phase=0 phase_0_builds
>
> "c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \
>
>        -optc-Wall -optc-Werror -optc-fno-stack-protector \
>
>         \
>
>        -hide-all-packages \
>
>        -package ghc-prim -package base -package array -package
> transformers -package time -package containers -package bytestring -package
> deepseq -package process -package pretty -package directory -package Win32 \
>
>        --make utils/ghc-cabal/Main.hs -o
> utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \
>
>        -no-user-package-db \
>
>        -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \
>
>        -DCABAL_VERSION=2,0,0,2 \
>
>        -DCABAL_PARSEC \
>
>        -DBOOTSTRAPPING \
>
>        -odir  bootstrapping \
>
>        -hidir bootstrapping \
>
>        bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \
>
>        -ilibraries/Cabal/Cabal \
>
>        -ilibraries/binary/src \
>
>        -ilibraries/filepath \
>
>        -ilibraries/hpc \
>
>        -ilibraries/mtl \
>
>        -ilibraries/text \
>
>        libraries/text/cbits/cbits.c \
>
>        -Ilibraries/text/include \
>
>        -ilibraries/parsec \
>
>         \
>
>
>
> Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...
>
> "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
>
> "cp" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe inplace/bin/ghc-cabal.exe
>
> "inplace/bin/ghc-cabal.exe" configure libraries/binary dist-boot
> --with-ghc="c:/fp/ghc-8.0.2/bin/ghc.exe"
> --with-ghc-pkg="c:/fp/ghc-8.0.2/bin/ghc-pkg"
> --package-db=C:/code/HEAD/libraries/bootstrapping.conf
> --disable-library-for-ghci --enable-library-vanilla
> --enable-library-for-ghci --disable-library-profiling --disable-shared
> --with-hscolour="/c/fp/HP-8.0.1/lib/extralibs/bin/HsColour"
> --configure-option=CFLAGS="-Wall -fno-stack-protector    -Wno-error=inline"
> --configure-option=LDFLAGS="  " --configure-option=CPPFLAGS="   "
> --gcc-options="-Wall -fno-stack-protector    -Wno-error=inline   "
> --constraint "binary == 0.8.5.1"   --constraint "text == 1.2.3.0"
> --constraint "transformers == 0.5.4.0"   --constraint "mtl == 2.2.2"
> --constraint "parsec == 3.1.12"   --constraint "Cabal == 2.0.0.2"
> --constraint "hpc == 0.6.0.3"   --constraint "ghc-boot-th == 8.3"
> --constraint "ghc-boot == 8.3"   --constraint "template-haskell ==
> 2.13.0.0"   --constraint "ghci == 8.3"
> --with-gcc="C:/fp/ghc-8.0.2/lib/../mingw/bin/gcc.exe"
> --with-ld="C:/fp/ghc-8.0.2/lib/../mingw/bin/ld.exe"
> --with-ar="C:/fp/ghc-8.0.2/lib/../mingw/bin/ar.exe"
> --with-alex="/c/fp/HP-8.0.1/lib/extralibs/bin/alex"
> --with-happy="/c/fp/HP-8.0.1/lib/extralibs/bin/happy"
>
> …etc etc
>
>
>
> I’m stumped.
>
>
>
> Simon
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171004/f0375152/attachment-0001.html>

From simonpj at microsoft.com  Wed Oct  4 16:24:49 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 4 Oct 2017 16:24:49 +0000
Subject: More windows
In-Reply-To: <CABHktDXQHijJbxur2LdksQmLxMHQD72Pp69Ubig++++48fgvWg@mail.gmail.com>
References: <AM4PR83MB0033115CEDF01DB5AF3CC0E8AD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CABHktDXQHijJbxur2LdksQmLxMHQD72Pp69Ubig++++48fgvWg@mail.gmail.com>
Message-ID: <AM4PR83MB00336B5A5BD670551F54F59BAD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>

As you’ll see the directory is empty when the crash happens.  And yes the folder is excluded.

Also this behaviour is new.

Simon

From: Phyx [mailto:lonetiger at gmail.com]
Sent: 04 October 2017 14:17
To: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs at haskell.org
Subject: Re: More windows


This looks like a file lock issue. Just to double check, but do you have the build folder excluded from the antivirus scanner?

On Wed, Oct 4, 2017, 13:57 Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>> wrote:
Now in my Windows build, staring with “sh validate –fast –no-clean” I get

[230 of 232] Compiling Distribution.PackageDescription.Parsec ( libraries\Cabal\Cabal\Distribution\PackageDescription\Parsec.hs, bootstrapping\Distribution\PackageDescription\Parsec.o )

[231 of 232] Compiling Distribution.Simple ( libraries\Cabal\Cabal\Distribution\Simple.hs, bootstrapping\Distribution\Simple.o )

[232 of 232] Compiling Main             ( utils\ghc-cabal\Main.hs, bootstrapping\Main.o )

Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

utils/genprimopcode/ghc.mk:19<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A19&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=RBB0ZLl%2FEYwO7EfcTXr%2FKugBfnr1ecN%2Febs0rAKu1VE%3D&reserved=0>: utils/genprimopcode/dist/package-data.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpackage-data.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=QeEhyXBxi5n%2FhisTO6hX309ZFk47ek5NtGVDBNKbWLY%3D&reserved=0>: No such file or directory

make[1]: *** [utils/ghc-cabal/ghc.mk:57<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A57&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=8qZlM0TvQvcySuregiRG5Ip%2FOR%2BVDAM6Dad1hUNEB%2FQ%3D&reserved=0>: utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1

make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'

make: *** [Makefile:123: all] Error 2

Simply repeating, thus “sh validate –fast”, I then get the same error

/c/code/HEAD$ ls -l utils/ghc-cabal/dist/build/tmp/

total 0

/c/code/HEAD$ sh validate --fast --no-clean

using THREADS=5

make: Entering directory '/c/code/HEAD/utils/checkUniques'

./check-uniques.py ../..

make: Leaving directory '/c/code/HEAD/utils/checkUniques'

===--- building phase 0

make --no-print-directory -f ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=npxwtvhNnwLposvw%2B3k6rdhcQHEW7erd10hWCi5bvjg%3D&reserved=0> phase=0 phase_0_builds

"c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \

       -optc-Wall -optc-Werror -optc-fno-stack-protector \

        \

       -hide-all-packages \

       -package ghc-prim -package base -package array -package transformers -package time -package containers -package bytestring -package deepseq -package process -package pretty -package directory -package Win32 \

       --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \

       -no-user-package-db \

       -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \

       -DCABAL_VERSION=2,0,0,2 \

       -DCABAL_PARSEC \

       -DBOOTSTRAPPING \

       -odir  bootstrapping \

       -hidir bootstrapping \

       bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \

       -ilibraries/Cabal/Cabal \

       -ilibraries/binary/src \

       -ilibraries/filepath \

       -ilibraries/hpc \

       -ilibraries/mtl \

       -ilibraries/text \

       libraries/text/cbits/cbits.c \

       -Ilibraries/text/include \

       -ilibraries/parsec \

        \



Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

make[1]: *** [utils/ghc-cabal/ghc.mk:57<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A57&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=8qZlM0TvQvcySuregiRG5Ip%2FOR%2BVDAM6Dad1hUNEB%2FQ%3D&reserved=0>: utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1

make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'

make: *** [Makefile:123: all] Error 2

But trying “sh validate –fast” once more succeeds:

/c/code/HEAD$ sh validate --fast --no-clean

using THREADS=5

make: Entering directory '/c/code/HEAD/utils/checkUniques'

./check-uniques.py ../..

make: Leaving directory '/c/code/HEAD/utils/checkUniques'

===--- building phase 0

make --no-print-directory -f ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=npxwtvhNnwLposvw%2B3k6rdhcQHEW7erd10hWCi5bvjg%3D&reserved=0> phase=0 phase_0_builds

"c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \

       -optc-Wall -optc-Werror -optc-fno-stack-protector \

        \

       -hide-all-packages \

       -package ghc-prim -package base -package array -package transformers -package time -package containers -package bytestring -package deepseq -package process -package pretty -package directory -package Win32 \

       --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \

       -no-user-package-db \

       -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \

       -DCABAL_VERSION=2,0,0,2 \

       -DCABAL_PARSEC \

       -DBOOTSTRAPPING \

       -odir  bootstrapping \

       -hidir bootstrapping \

       bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \

       -ilibraries/Cabal/Cabal \

       -ilibraries/binary/src \

       -ilibraries/filepath \

       -ilibraries/hpc \

       -ilibraries/mtl \

       -ilibraries/text \

       libraries/text/cbits/cbits.c \

       -Ilibraries/text/include \

       -ilibraries/parsec \

        \



Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

"cp" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe inplace/bin/ghc-cabal.exe

"inplace/bin/ghc-cabal.exe" configure libraries/binary dist-boot --with-ghc="c:/fp/ghc-8.0.2/bin/ghc.exe" --with-ghc-pkg="c:/fp/ghc-8.0.2/bin/ghc-pkg"  --package-db=C:/code/HEAD/libraries/bootstrapping.conf --disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci --disable-library-profiling --disable-shared --with-hscolour="/c/fp/HP-8.0.1/lib/extralibs/bin/HsColour" --configure-option=CFLAGS="-Wall -fno-stack-protector    -Wno-error=inline" --configure-option=LDFLAGS="  " --configure-option=CPPFLAGS="   " --gcc-options="-Wall -fno-stack-protector    -Wno-error=inline   "   --constraint "binary == 0.8.5.1"   --constraint "text == 1.2.3.0"   --constraint "transformers == 0.5.4.0"   --constraint "mtl == 2.2.2"   --constraint "parsec == 3.1.12"   --constraint "Cabal == 2.0.0.2"   --constraint "hpc == 0.6.0.3"   --constraint "ghc-boot-th == 8.3"   --constraint "ghc-boot == 8.3"   --constraint "template-haskell == 2.13.0.0"   --constraint "ghci == 8.3" --with-gcc="C:/fp/ghc-8.0.2/lib/../mingw/bin/gcc.exe" --with-ld="C:/fp/ghc-8.0.2/lib/../mingw/bin/ld.exe" --with-ar="C:/fp/ghc-8.0.2/lib/../mingw/bin/ar.exe" --with-alex="/c/fp/HP-8.0.1/lib/extralibs/bin/alex" --with-happy="/c/fp/HP-8.0.1/lib/extralibs/bin/happy"
…etc etc

I’m stumped.

Simon
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=HPj0gcQlqItY7XC0CON1Fv5clpmEINCnYSqLHgsr06U%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171004/f6043d37/attachment-0001.html>

From lonetiger at gmail.com  Wed Oct  4 16:42:51 2017
From: lonetiger at gmail.com (Phyx)
Date: Wed, 4 Oct 2017 17:42:51 +0100
Subject: More windows
In-Reply-To: <AM4PR83MB00336B5A5BD670551F54F59BAD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
References: <AM4PR83MB0033115CEDF01DB5AF3CC0E8AD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CABHktDXQHijJbxur2LdksQmLxMHQD72Pp69Ubig++++48fgvWg@mail.gmail.com>
 <AM4PR83MB00336B5A5BD670551F54F59BAD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
Message-ID: <CABHktDXhSh8MSJd6y0JOtYrx8YsTwcD=rUzYiKxL4bu9bMCGJg@mail.gmail.com>

Oh sorry, I missed the ls line, I'll try building master.

On Wed, Oct 4, 2017 at 5:24 PM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> As you’ll see the directory is empty when the crash happens.  And yes the
> folder is excluded.
>
>
>
> Also this behaviour is new.
>
>
>
> Simon
>
>
>
> *From:* Phyx [mailto:lonetiger at gmail.com]
> *Sent:* 04 October 2017 14:17
> *To:* Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs at haskell.org
> *Subject:* Re: More windows
>
>
>
> This looks like a file lock issue. Just to double check, but do you have
> the build folder excluded from the antivirus scanner?
>
>
>
> On Wed, Oct 4, 2017, 13:57 Simon Peyton Jones via ghc-devs <
> ghc-devs at haskell.org> wrote:
>
> Now in my Windows build, staring with “sh validate –fast –no-clean” I get
>
> [230 of 232] Compiling Distribution.PackageDescription.Parsec (
> libraries\Cabal\Cabal\Distribution\PackageDescription\Parsec.hs,
> bootstrapping\Distribution\PackageDescription\Parsec.o )
>
> [231 of 232] Compiling Distribution.Simple ( libraries\Cabal\Cabal\Distribution\Simple.hs,
> bootstrapping\Distribution\Simple.o )
>
> [232 of 232] Compiling Main             ( utils\ghc-cabal\Main.hs,
> bootstrapping\Main.o )
>
> Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...
>
> "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
>
> Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
>
> utils/genprimopcode/ghc.mk:19
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A19&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=RBB0ZLl%2FEYwO7EfcTXr%2FKugBfnr1ecN%2Febs0rAKu1VE%3D&reserved=0>:
> utils/genprimopcode/dist/package-data.mk
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpackage-data.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=QeEhyXBxi5n%2FhisTO6hX309ZFk47ek5NtGVDBNKbWLY%3D&reserved=0>:
> No such file or directory
>
> make[1]: *** [utils/ghc-cabal/ghc.mk:57
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A57&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=8qZlM0TvQvcySuregiRG5Ip%2FOR%2BVDAM6Dad1hUNEB%2FQ%3D&reserved=0>:
> utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1
>
> make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'
>
> make: *** [Makefile:123: all] Error 2
>
>
>
> Simply repeating, thus “sh validate –fast”, I then get the same error
>
> /c/code/HEAD$ ls -l utils/ghc-cabal/dist/build/tmp/
>
> total 0
>
> /c/code/HEAD$ sh validate --fast --no-clean
>
> using THREADS=5
>
> make: Entering directory '/c/code/HEAD/utils/checkUniques'
>
> ./check-uniques.py ../..
>
> make: Leaving directory '/c/code/HEAD/utils/checkUniques'
>
> ===--- building phase 0
>
> make --no-print-directory -f ghc.mk
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=npxwtvhNnwLposvw%2B3k6rdhcQHEW7erd10hWCi5bvjg%3D&reserved=0>
> phase=0 phase_0_builds
>
> "c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \
>
>        -optc-Wall -optc-Werror -optc-fno-stack-protector \
>
>         \
>
>        -hide-all-packages \
>
>        -package ghc-prim -package base -package array -package
> transformers -package time -package containers -package bytestring -package
> deepseq -package process -package pretty -package directory -package Win32 \
>
>        --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
> \
>
>        -no-user-package-db \
>
>        -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \
>
>        -DCABAL_VERSION=2,0,0,2 \
>
>        -DCABAL_PARSEC \
>
>        -DBOOTSTRAPPING \
>
>        -odir  bootstrapping \
>
>        -hidir bootstrapping \
>
>        bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \
>
>        -ilibraries/Cabal/Cabal \
>
>        -ilibraries/binary/src \
>
>        -ilibraries/filepath \
>
>        -ilibraries/hpc \
>
>        -ilibraries/mtl \
>
>        -ilibraries/text \
>
>        libraries/text/cbits/cbits.c \
>
>        -Ilibraries/text/include \
>
>        -ilibraries/parsec \
>
>         \
>
>
>
> Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...
>
> "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
>
> Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
>
> make[1]: *** [utils/ghc-cabal/ghc.mk:57
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A57&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=8qZlM0TvQvcySuregiRG5Ip%2FOR%2BVDAM6Dad1hUNEB%2FQ%3D&reserved=0>:
> utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1
>
> make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'
>
> make: *** [Makefile:123: all] Error 2
>
>
>
> But trying “sh validate –fast” once more succeeds:
>
> /c/code/HEAD$ sh validate --fast --no-clean
>
> using THREADS=5
>
> make: Entering directory '/c/code/HEAD/utils/checkUniques'
>
> ./check-uniques.py ../..
>
> make: Leaving directory '/c/code/HEAD/utils/checkUniques'
>
> ===--- building phase 0
>
> make --no-print-directory -f ghc.mk
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=npxwtvhNnwLposvw%2B3k6rdhcQHEW7erd10hWCi5bvjg%3D&reserved=0>
> phase=0 phase_0_builds
>
> "c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \
>
>        -optc-Wall -optc-Werror -optc-fno-stack-protector \
>
>         \
>
>        -hide-all-packages \
>
>        -package ghc-prim -package base -package array -package
> transformers -package time -package containers -package bytestring -package
> deepseq -package process -package pretty -package directory -package Win32 \
>
>        --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
> \
>
>        -no-user-package-db \
>
>        -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \
>
>        -DCABAL_VERSION=2,0,0,2 \
>
>        -DCABAL_PARSEC \
>
>        -DBOOTSTRAPPING \
>
>        -odir  bootstrapping \
>
>        -hidir bootstrapping \
>
>        bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \
>
>        -ilibraries/Cabal/Cabal \
>
>        -ilibraries/binary/src \
>
>        -ilibraries/filepath \
>
>        -ilibraries/hpc \
>
>        -ilibraries/mtl \
>
>        -ilibraries/text \
>
>        libraries/text/cbits/cbits.c \
>
>        -Ilibraries/text/include \
>
>        -ilibraries/parsec \
>
>         \
>
>
>
> Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...
>
> "inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
>
> "cp" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
> inplace/bin/ghc-cabal.exe
>
> "inplace/bin/ghc-cabal.exe" configure libraries/binary dist-boot
> --with-ghc="c:/fp/ghc-8.0.2/bin/ghc.exe" --with-ghc-pkg="c:/fp/ghc-8.0.2/bin/ghc-pkg"
> --package-db=C:/code/HEAD/libraries/bootstrapping.conf
> --disable-library-for-ghci --enable-library-vanilla
> --enable-library-for-ghci --disable-library-profiling --disable-shared
> --with-hscolour="/c/fp/HP-8.0.1/lib/extralibs/bin/HsColour"
> --configure-option=CFLAGS="-Wall -fno-stack-protector
> -Wno-error=inline" --configure-option=LDFLAGS="  "
> --configure-option=CPPFLAGS="   " --gcc-options="-Wall
> -fno-stack-protector    -Wno-error=inline   "   --constraint "binary ==
> 0.8.5.1"   --constraint "text == 1.2.3.0"   --constraint "transformers ==
> 0.5.4.0"   --constraint "mtl == 2.2.2"   --constraint "parsec == 3.1.12"
> --constraint "Cabal == 2.0.0.2"   --constraint "hpc == 0.6.0.3"
> --constraint "ghc-boot-th == 8.3"   --constraint "ghc-boot == 8.3"
> --constraint "template-haskell == 2.13.0.0"   --constraint "ghci == 8.3"
> --with-gcc="C:/fp/ghc-8.0.2/lib/../mingw/bin/gcc.exe"
> --with-ld="C:/fp/ghc-8.0.2/lib/../mingw/bin/ld.exe"
> --with-ar="C:/fp/ghc-8.0.2/lib/../mingw/bin/ar.exe"
> --with-alex="/c/fp/HP-8.0.1/lib/extralibs/bin/alex"
> --with-happy="/c/fp/HP-8.0.1/lib/extralibs/bin/happy"
>
> …etc etc
>
>
>
> I’m stumped.
>
>
>
> Simon
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=HPj0gcQlqItY7XC0CON1Fv5clpmEINCnYSqLHgsr06U%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171004/4a6bc952/attachment-0001.html>

From tjakway at nyu.edu  Wed Oct  4 18:59:40 2017
From: tjakway at nyu.edu (Thomas Jakway)
Date: Wed, 4 Oct 2017 14:59:40 -0400
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <3D354A76-98BB-44F8-8A2F-3D7FCF714C8A@smart-cactus.org>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
 <CAHYM_Vmj10ekRejPMiw4jqoPwUmfukGRub0n+6u7e2VTMYpxMw@mail.gmail.com>
 <9d4a14bf-d1bd-9fcb-69ad-03019d8948da@nyu.edu>
 <3D354A76-98BB-44F8-8A2F-3D7FCF714C8A@smart-cactus.org>
Message-ID: <7156e76e-132a-77d1-7ec3-91356bc92564@nyu.edu>

Hm, so it's definitely not anything I changed.  I just cloned and built 
it and got the same problem (7109fa8157f3258912c947f28dab7617b5e5d281).


On 10/03/2017 04:42 PM, Ben Gamari wrote:
> Can you confirm which commit you are on?
>
> On October 3, 2017 4:36:48 PM EDT, Thomas Jakway <tjakway at nyu.edu> wrote:
>
>     Not sure.  I ran `git submodule update --init --recursive` and git
>     status says everything's up to date.  I'm on Ubuntu 16.10.
>
>
>     On 10/03/2017 02:17 PM, John Leo wrote:
>>     I pulled head this morning and built with no problems on a Mac. 
>>     I wonder if you need to pull submodules as well (which I did) or
>>     if you're missing some newly required dependency.
>>
>>     John
>>
>>     On Tue, Oct 3, 2017 at 10:55 AM, Thomas Jakway <tjakway at nyu.edu
>>     <mailto:tjakway at nyu.edu>> wrote:
>>
>>         Anyone else getting linker errors?
>>
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_uint64'
>>         chmod +x inplace/bin/runghc
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_uint32'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_uint16'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_uint8'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_sint64'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_sint32'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_sint16'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_sint8'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_double'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_float'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_pointer'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_void'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_prep_cif'
>>         collect2: error: ld returned 1 exit status
>>         `gcc' failed in phase `Linker'. (Exit code: 1)
>>         iserv/ghc.mk:108 <http://ghc.mk:108>: recipe for target
>>         'iserv/stage2_dyn/build/tmp/ghc-iserv-dyn' f
>>         ailed
>>         make[1]: *** [iserv/stage2_dyn/build/tmp/ghc-iserv-dyn] Error 1
>>         make[1]: *** Waiting for unfinished jobs....
>>         <<ghc: 2235737040 <tel:%28223%29%20573-7040> bytes, 225 GCs,
>>         21703308/57027464 avg/max bytes residency (8 s
>>         amples), 150M in use, 0.000 INIT (0.000 elapsed), 1.432 MUT
>>         (1.681 elapsed), 0.5
>>         76 GC (0.651 elapsed) :ghc>>
>>         Makefile:122: recipe for target 'all' failed
>>         make: *** [all] Error 2
>>
>>
>>         This is after running
>>
>>         make clean && make distclean && find . -name "*.o" -type f
>>         -delete && find . -name "*.hi" -type f -delete
>>
>>         then
>>
>>         ./boot && ./configure && make -j5
>>
>>         (ghc-new is not a new checkout, this error is happening on a
>>         branch I'm working on, but one that doesn't touch the FFI)
>>
>>         On 10/01/2017 07:09 PM, Moritz Angermann wrote:
>>>         I hope this will be fixed with:
>>>         https://phabricator.haskell.org/D4053
>>>         <https://phabricator.haskell.org/D4053> and
>>>         https://phabricator.haskell.org/D4054
>>>         <https://phabricator.haskell.org/D4054>
>>>
>>>         Sent from my iPhone
>>>
>>>         On 2 Oct 2017, at 6:33 AM, Ryan Scott
>>>         <ryan.gl.scott at gmail.com <mailto:ryan.gl.scott at gmail.com>>
>>>         wrote:
>>>
>>>>         Trying to build a fresh copy of GHC HEAD (at commit [1])
>>>>         today failed
>>>>         for me with this error: [2]
>>>>
>>>>            /u/rgscott/Software/ghc4/libffi/build/missing: line 81:
>>>>         makeinfo:
>>>>         command not found
>>>>            WARNING: 'makeinfo' is missing on your system.
>>>>                     You should only need it if you modified a
>>>>         '.texi' file, or
>>>>                     any other file indirectly affecting the aspect
>>>>         of the manual.
>>>>                     You might want to install the Texinfo package:
>>>>                     <http://www.gnu.org/software/texinfo/
>>>>         <http://www.gnu.org/software/texinfo/>>
>>>>                     The spurious makeinfo call might also be the
>>>>         consequence of
>>>>                     using a buggy 'make' (AIX, DU, IRIX), in which
>>>>         case you might
>>>>                     want to install GNU make:
>>>>                     <http://www.gnu.org/software/make/
>>>>         <http://www.gnu.org/software/make/>>
>>>>
>>>>         On my Ubuntu machine, I was able to work around the issue
>>>>         by running:
>>>>
>>>>            apt-get install texinfo
>>>>
>>>>         But I'm not sure if the texinfo requirement was expected or an
>>>>         unintended side effect of recent libffi changes. Do you
>>>>         know what's
>>>>         happening here Moritz?
>>>>
>>>>         Best,
>>>>         Ryan S.
>>>>         -----
>>>>         [1]
>>>>         http://git.haskell.org/ghc.git/commit/e515c7f37be97e1c2ccc497ddd0a730e63ddfa82
>>>>         <http://git.haskell.org/ghc.git/commit/e515c7f37be97e1c2ccc497ddd0a730e63ddfa82>
>>>>         [2] http://lpaste.net/6716863452582772736
>>>>         <http://lpaste.net/6716863452582772736>
>>>>         _______________________________________________
>>>>         ghc-devs mailing list
>>>>         ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>>>>         http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>         <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>>>
>>>
>>>         _______________________________________________
>>>         ghc-devs mailing list
>>>         ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>>>         http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>         <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>>
>>
>>         _______________________________________________
>>         ghc-devs mailing list
>>         ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>>         http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>         <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>>
>>
>
>
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171004/2ae88c97/attachment.html>

From tjakway at nyu.edu  Wed Oct  4 19:00:08 2017
From: tjakway at nyu.edu (Thomas Jakway)
Date: Wed, 4 Oct 2017 15:00:08 -0400
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <3D354A76-98BB-44F8-8A2F-3D7FCF714C8A@smart-cactus.org>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
 <CAHYM_Vmj10ekRejPMiw4jqoPwUmfukGRub0n+6u7e2VTMYpxMw@mail.gmail.com>
 <9d4a14bf-d1bd-9fcb-69ad-03019d8948da@nyu.edu>
 <3D354A76-98BB-44F8-8A2F-3D7FCF714C8A@smart-cactus.org>
Message-ID: <93cec21f-a86a-6996-648c-d23642bcb6da@nyu.edu>

Build flavor is devel2, of course.


On 10/03/2017 04:42 PM, Ben Gamari wrote:
> Can you confirm which commit you are on?
>
> On October 3, 2017 4:36:48 PM EDT, Thomas Jakway <tjakway at nyu.edu> wrote:
>
>     Not sure.  I ran `git submodule update --init --recursive` and git
>     status says everything's up to date.  I'm on Ubuntu 16.10.
>
>
>     On 10/03/2017 02:17 PM, John Leo wrote:
>>     I pulled head this morning and built with no problems on a Mac. 
>>     I wonder if you need to pull submodules as well (which I did) or
>>     if you're missing some newly required dependency.
>>
>>     John
>>
>>     On Tue, Oct 3, 2017 at 10:55 AM, Thomas Jakway <tjakway at nyu.edu
>>     <mailto:tjakway at nyu.edu>> wrote:
>>
>>         Anyone else getting linker errors?
>>
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_uint64'
>>         chmod +x inplace/bin/runghc
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_uint32'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_uint16'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_uint8'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_sint64'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_sint32'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_sint16'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_sint8'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_double'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_float'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_pointer'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_type_void'
>>         /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>         20171003.so: error: undefined reference to 'ffi_prep_cif'
>>         collect2: error: ld returned 1 exit status
>>         `gcc' failed in phase `Linker'. (Exit code: 1)
>>         iserv/ghc.mk:108 <http://ghc.mk:108>: recipe for target
>>         'iserv/stage2_dyn/build/tmp/ghc-iserv-dyn' f
>>         ailed
>>         make[1]: *** [iserv/stage2_dyn/build/tmp/ghc-iserv-dyn] Error 1
>>         make[1]: *** Waiting for unfinished jobs....
>>         <<ghc: 2235737040 <tel:%28223%29%20573-7040> bytes, 225 GCs,
>>         21703308/57027464 avg/max bytes residency (8 s
>>         amples), 150M in use, 0.000 INIT (0.000 elapsed), 1.432 MUT
>>         (1.681 elapsed), 0.5
>>         76 GC (0.651 elapsed) :ghc>>
>>         Makefile:122: recipe for target 'all' failed
>>         make: *** [all] Error 2
>>
>>
>>         This is after running
>>
>>         make clean && make distclean && find . -name "*.o" -type f
>>         -delete && find . -name "*.hi" -type f -delete
>>
>>         then
>>
>>         ./boot && ./configure && make -j5
>>
>>         (ghc-new is not a new checkout, this error is happening on a
>>         branch I'm working on, but one that doesn't touch the FFI)
>>
>>         On 10/01/2017 07:09 PM, Moritz Angermann wrote:
>>>         I hope this will be fixed with:
>>>         https://phabricator.haskell.org/D4053
>>>         <https://phabricator.haskell.org/D4053> and
>>>         https://phabricator.haskell.org/D4054
>>>         <https://phabricator.haskell.org/D4054>
>>>
>>>         Sent from my iPhone
>>>
>>>         On 2 Oct 2017, at 6:33 AM, Ryan Scott
>>>         <ryan.gl.scott at gmail.com <mailto:ryan.gl.scott at gmail.com>>
>>>         wrote:
>>>
>>>>         Trying to build a fresh copy of GHC HEAD (at commit [1])
>>>>         today failed
>>>>         for me with this error: [2]
>>>>
>>>>            /u/rgscott/Software/ghc4/libffi/build/missing: line 81:
>>>>         makeinfo:
>>>>         command not found
>>>>            WARNING: 'makeinfo' is missing on your system.
>>>>                     You should only need it if you modified a
>>>>         '.texi' file, or
>>>>                     any other file indirectly affecting the aspect
>>>>         of the manual.
>>>>                     You might want to install the Texinfo package:
>>>>                     <http://www.gnu.org/software/texinfo/
>>>>         <http://www.gnu.org/software/texinfo/>>
>>>>                     The spurious makeinfo call might also be the
>>>>         consequence of
>>>>                     using a buggy 'make' (AIX, DU, IRIX), in which
>>>>         case you might
>>>>                     want to install GNU make:
>>>>                     <http://www.gnu.org/software/make/
>>>>         <http://www.gnu.org/software/make/>>
>>>>
>>>>         On my Ubuntu machine, I was able to work around the issue
>>>>         by running:
>>>>
>>>>            apt-get install texinfo
>>>>
>>>>         But I'm not sure if the texinfo requirement was expected or an
>>>>         unintended side effect of recent libffi changes. Do you
>>>>         know what's
>>>>         happening here Moritz?
>>>>
>>>>         Best,
>>>>         Ryan S.
>>>>         -----
>>>>         [1]
>>>>         http://git.haskell.org/ghc.git/commit/e515c7f37be97e1c2ccc497ddd0a730e63ddfa82
>>>>         <http://git.haskell.org/ghc.git/commit/e515c7f37be97e1c2ccc497ddd0a730e63ddfa82>
>>>>         [2] http://lpaste.net/6716863452582772736
>>>>         <http://lpaste.net/6716863452582772736>
>>>>         _______________________________________________
>>>>         ghc-devs mailing list
>>>>         ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>>>>         http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>         <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>>>
>>>
>>>         _______________________________________________
>>>         ghc-devs mailing list
>>>         ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>>>         http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>         <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>>
>>
>>         _______________________________________________
>>         ghc-devs mailing list
>>         ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>>         http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>         <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>>
>>
>
>
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171004/6469baa1/attachment-0001.html>

From ben at smart-cactus.org  Wed Oct  4 20:38:07 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 04 Oct 2017 16:38:07 -0400
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <7156e76e-132a-77d1-7ec3-91356bc92564@nyu.edu>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
 <CAHYM_Vmj10ekRejPMiw4jqoPwUmfukGRub0n+6u7e2VTMYpxMw@mail.gmail.com>
 <9d4a14bf-d1bd-9fcb-69ad-03019d8948da@nyu.edu>
 <3D354A76-98BB-44F8-8A2F-3D7FCF714C8A@smart-cactus.org>
 <7156e76e-132a-77d1-7ec3-91356bc92564@nyu.edu>
Message-ID: <878tgqr6mo.fsf@ben-laptop.smart-cactus.org>

Thomas Jakway <tjakway at nyu.edu> writes:

> Hm, so it's definitely not anything I changed.  I just cloned and built 
> it and got the same problem (7109fa8157f3258912c947f28dab7617b5e5d281).
>
Alright, I'm trying to replicate.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171004/3e55ba03/attachment.sig>

From ben at smart-cactus.org  Wed Oct  4 21:17:48 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 04 Oct 2017 17:17:48 -0400
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
Message-ID: <8760bur4sj.fsf@ben-laptop.smart-cactus.org>

Thomas Jakway <tjakway at nyu.edu> writes:

> Anyone else getting linker errors?
>

>
> This is after running
>
> make clean && make distclean && find . -name "*.o" -type f -delete && 
> find . -name "*.hi" -type f -delete
>
> then
>
> ./boot && ./configure && make -j5
>
> (ghc-new is not a new checkout, this error is happening on a branch I'm 
> working on, but one that doesn't touch the FFI)
>
I'm afraid I can't reproduce this. What platform/operating system is
this on?

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171004/cd4d05b8/attachment.sig>

From simonpj at microsoft.com  Thu Oct  5 09:58:00 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 5 Oct 2017 09:58:00 +0000
Subject: Determine instance method from class method callsite
In-Reply-To: <CANiLjA1=mPF7BacBphWO2LN3erA_654qW1btkwGUgDp2tjjjng@mail.gmail.com>
References: <CANiLjA1=mPF7BacBphWO2LN3erA_654qW1btkwGUgDp2tjjjng@mail.gmail.com>
Message-ID: <AM4PR83MB003388E5B45912CBD4C6B013AD700@AM4PR83MB0033.EURPRD83.prod.outlook.com>

Did you get a reply?

I’m not 100% certain of your question, but consider the

    bar = show <expr>
for some expression e.   In the input to the type type checker the syntax tree for the RHS will be something like
            HsApp (HsVar “show”) <syntax tree for expr>

(The “show” isn’t really a string, it’s the Name for the class method.)

After typechecking the syntax tree is augmented (or “elaborated”) with type and dictionary application.  So in concrete form it might look like
            bar = show @Foo dShowFoo <expr>

Because show :: forall a. Show a => a -> String, so show is apply to the type of its argument, and then to the dictionary.

In HsSyn this part is done with a HsWrapper See TcEvidence.HsWrapper.  The elaborated syntax tree look like

            HsApp (HsWrap <wrapper> (HsVar “show”))
                          <syntax tree for elaborated expr>

The <wrapper> part expresses the type and dictionary application. In this case it’ll look like
            WpEvApp dShowFoo (WpTyApp Foo WpHole)

See the notes with `HsWrapper` in TcEvidence.

Does that help?

It would be great to augment the https://ghc.haskell.org/trac/ghc/wiki/Commentary with this sort of info (insofar as it doesn’t have it already).  If you augment I can review.  Email is quickly lost.

Simon
From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Robin Palotai
Sent: 19 September 2017 06:39
To: GHC developers <ghc-devs at haskell.org>; haskell <haskell-cafe at haskell.org>
Subject: Determine instance method from class method callsite

Sorry, I messed up subject and mailing list. Copying to both list now after the mistake (wanted only ghc-devs for specificity).

Thanks!

2017-09-19 7:36 GMT+02:00 Robin Palotai <palotai.robin at gmail.com<mailto:palotai.robin at gmail.com>>:
Hello GHC devs,

Before inventing the wheel, want to check if there is a GHC API way to look up the (fully) resolved instance method from a class method.

For example, given a code

    data Foo Int deriving Show

    bar = show (Foo 3)

when inspecting the Typechecked AST for bar's show call, I would like to get to the Name / Id of 'show' of the 'Show' typeclass.

I believe I could use splitHsSigmaTy on the HsType of the function call to get the context, and then evaluate the HsWrapper somehow to find out what instance dictionary is applied to the class restriction in the context, and then look up the instance method from the dictionary..

Two questions:

1) Is there maybe functionality for this?

2) If not, is there any guarantee about the constraint order in the context, at the method call? So I could more easily determine which constraint's application to look for..

Any hints welcome && Thank you!
Robin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171005/72bf477e/attachment-0001.html>

From simonpj at microsoft.com  Thu Oct  5 09:59:34 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 5 Oct 2017 09:59:34 +0000
Subject: In C--: should CmmCall and CmmProc agree on their live registers?
In-Reply-To: <38053934-5C91-4921-8B3D-A5F03CF86CA4@gmail.com>
References: <38053934-5C91-4921-8B3D-A5F03CF86CA4@gmail.com>
Message-ID: <AM4PR83MB00339639B2E520A0ACB8DD9CAD700@AM4PR83MB0033.EURPRD83.prod.outlook.com>

Did you ever get a reply to this?

In the output of the codegen, CmmProcs should have no live registers apart from those used to pass args, and the standard ones.

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Moritz
|  Angermann
|  Sent: 22 September 2017 07:33
|  To: GHC developers <ghc-devs at haskell.org>
|  Subject: In C--: should CmmCall and CmmProc agree on their live registers?
|  
|  Hi,
|  
|  apologies for writing so many emails recently. This is a minor spinoff from
|  the "The Curious Case of T6084" email.
|  
|  While digging into it, I keep asking myself if CmmProc’s live registers
|  should match those of the CmmCall that is calling it?
|  
|  Is there any invariant we try to enforce or would want to enforce?
|  
|  - Can the CmmProcs live registers be a strict superset of
|    the corresponding CmmCalls?
|  
|    From the source comments in `compiler/cmm/Cmm.hs`:
|    > Registers live on entry. Note that the set of live
|    > registers will be correct in generated C-- code, but
|    > not in hand-written C-- code. However,
|    > splitAtProcPoints calculates correct liveness
|    > information for CmmProcs.
|  
|    I would assume that this is an invalid case?
|  
|  - Can the CmmProcs live registers be a strict subset of
|    the corresponding CmmCalls?
|  
|    This case however seems to be valid case.  However, this
|    makes me wonder if we can, and should(?) propagate the
|    live register info from the CmmProc to the CmmCall so
|    that they match up, and the registers are not kept live
|    at the origin of the CmmCall if they aren’t needed?  And
|    as such potentially compute anything to put into the
|    registers the CmmCall considers live, but the CmmProc
|    would ignore anyway?
|  
|  Cheers,
|   Moritz
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell
|  .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&data=02%7C01%7Csimonpj%40microsoft.com%7C6009bb0f47a447a4217708d50183ce
|  fa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636416587981602708&sdata=vII
|  rlKVJa6E%2FBvVz5Sod1c544nw6gsGp54Mlhr7bQ8g%3D&reserved=0

From palotai.robin at gmail.com  Thu Oct  5 10:16:58 2017
From: palotai.robin at gmail.com (Robin Palotai)
Date: Thu, 5 Oct 2017 12:16:58 +0200
Subject: Determine instance method from class method callsite
In-Reply-To: <AM4PR83MB003388E5B45912CBD4C6B013AD700@AM4PR83MB0033.EURPRD83.prod.outlook.com>
References: <CANiLjA1=mPF7BacBphWO2LN3erA_654qW1btkwGUgDp2tjjjng@mail.gmail.com>
 <AM4PR83MB003388E5B45912CBD4C6B013AD700@AM4PR83MB0033.EURPRD83.prod.outlook.com>
Message-ID: <CANiLjA2sfLYbU56LwW+df9wQKvOJXkXvz=kB-TGv6M84F6t9dw@mail.gmail.com>

Hello Simon - I outlined the approach in
https://github.com/google/haskell-indexer/issues/73.
TLDR is
1) at callsite, indeed the HsWrapper needs to be analysed to get the
instance DFunId
2) at instance declaration site, we need to again take note of the DFunId.

It is slightly more complicated than I expected the API. I would have
expected that from having the Var of a class method, and the <something> of
the instance (here DFunId), it would be easy to resolve the Var of the
instance method.

But it seems there's no direct way, one has to build a lookup table from
the instance methods' (DFunId + plain stringy method name), and look that
up from the callsite.

Or I might have missed a way to deconstruct / query a DFunId for the method
Vars.

I'll put augmenting the commentary on my mental TODO list :)

2017-10-05 11:58 GMT+02:00 Simon Peyton Jones <simonpj at microsoft.com>:

> Did you get a reply?
>
>
>
> I’m not 100% certain of your question, but consider the
>
>
>
>     bar = show <expr>
>
> for some expression e.   In the input to the type type checker the syntax
> tree for the RHS will be something like
>
>             HsApp (HsVar “show”) <syntax tree for expr>
>
>
>
> (The “show” isn’t really a string, it’s the Name for the class method.)
>
>
>
> After typechecking the syntax tree is augmented (or “elaborated”) with
> type and dictionary application.  So in concrete form it might look like
>
>             bar = show @Foo dShowFoo <expr>
>
>
>
> Because show :: forall a. Show a => a -> String, so show is apply to the
> type of its argument, and then to the dictionary.
>
>
>
> In HsSyn this part is done with a HsWrapper See TcEvidence.HsWrapper.  The
> elaborated syntax tree look like
>
>
>
>             HsApp (HsWrap <wrapper> (HsVar “show”))
>
>                           <syntax tree for elaborated expr>
>
>
>
> The <wrapper> part expresses the type and dictionary application. In this
> case it’ll look like
>
>             WpEvApp dShowFoo (WpTyApp Foo WpHole)
>
>
>
> See the notes with `HsWrapper` in TcEvidence.
>
>
>
> Does that help?
>
>
>
> It would be great to augment the https://ghc.haskell.org/trac/
> ghc/wiki/Commentary with this sort of info (insofar as it doesn’t have it
> already).  If you augment I can review.  Email is quickly lost.
>
>
>
> Simon
>
> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Robin
> Palotai
> *Sent:* 19 September 2017 06:39
> *To:* GHC developers <ghc-devs at haskell.org>; haskell <
> haskell-cafe at haskell.org>
> *Subject:* Determine instance method from class method callsite
>
>
>
> Sorry, I messed up subject and mailing list. Copying to both list now
> after the mistake (wanted only ghc-devs for specificity).
>
>
>
> Thanks!
>
>
>
> 2017-09-19 7:36 GMT+02:00 Robin Palotai <palotai.robin at gmail.com>:
>
> Hello GHC devs,
>
>
>
> Before inventing the wheel, want to check if there is a GHC API way to
> look up the (fully) resolved instance method from a class method.
>
>
>
> For example, given a code
>
>
>
>     data Foo Int deriving Show
>
>
>
>     bar = show (Foo 3)
>
>
>
> when inspecting the Typechecked AST for bar's show call, I would like to
> get to the Name / Id of 'show' of the 'Show' typeclass.
>
>
>
> I believe I could use splitHsSigmaTy on the HsType of the function call to
> get the context, and then evaluate the HsWrapper somehow to find out what
> instance dictionary is applied to the class restriction in the context, and
> then look up the instance method from the dictionary..
>
>
>
> Two questions:
>
>
>
> 1) Is there maybe functionality for this?
>
>
>
> 2) If not, is there any guarantee about the constraint order in the
> context, at the method call? So I could more easily determine which
> constraint's application to look for..
>
>
>
> Any hints welcome && Thank you!
>
> Robin
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171005/4e7ce079/attachment.html>

From simonpj at microsoft.com  Thu Oct  5 16:00:08 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 5 Oct 2017 16:00:08 +0000
Subject: Determine instance method from class method callsite
In-Reply-To: <CANiLjA2sfLYbU56LwW+df9wQKvOJXkXvz=kB-TGv6M84F6t9dw@mail.gmail.com>
References: <CANiLjA1=mPF7BacBphWO2LN3erA_654qW1btkwGUgDp2tjjjng@mail.gmail.com>
 <AM4PR83MB003388E5B45912CBD4C6B013AD700@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CANiLjA2sfLYbU56LwW+df9wQKvOJXkXvz=kB-TGv6M84F6t9dw@mail.gmail.com>
Message-ID: <AM4PR83MB00333B11694447A6E45AD26EAD700@AM4PR83MB0033.EURPRD83.prod.outlook.com>

well the HsWrapper might have something much more complicated than a DFunId.  It might need to construct the dictionary for Eq [a] from the DFun for Eq [a] and a dictionary for Eq a.

it would be easy to resolve the Var of the instance method.
I don't know what "the var of the instance method" is.

I feel I'm missing the point.  maybe others can help?

Simon

From: Robin Palotai [mailto:palotai.robin at gmail.com]
Sent: 05 October 2017 11:17
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: GHC developers <ghc-devs at haskell.org>; haskell <haskell-cafe at haskell.org>
Subject: Re: Determine instance method from class method callsite

Hello Simon - I outlined the approach in https://github.com/google/haskell-indexer/issues/73<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fhaskell-indexer%2Fissues%2F73&data=02%7C01%7Csimonpj%40microsoft.com%7C6798607dd45a4865d5ef08d50bda3727%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427954212256346&sdata=HkxeXUYlbyGJnHu2%2BM17Z5aE7XXAZCWCnWwGLMV1%2BEQ%3D&reserved=0>.
TLDR is
1) at callsite, indeed the HsWrapper needs to be analysed to get the instance DFunId
2) at instance declaration site, we need to again take note of the DFunId.
It is slightly more complicated than I expected the API. I would have expected that from having the Var of a class method, and the <something> of the instance (here DFunId), it would be easy to resolve the Var of the instance method.
But it seems there's no direct way, one has to build a lookup table from the instance methods' (DFunId + plain stringy method name), and look that up from the callsite.
Or I might have missed a way to deconstruct / query a DFunId for the method Vars.
I'll put augmenting the commentary on my mental TODO list :)

2017-10-05 11:58 GMT+02:00 Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>:
Did you get a reply?

I'm not 100% certain of your question, but consider the

    bar = show <expr>
for some expression e.   In the input to the type type checker the syntax tree for the RHS will be something like
            HsApp (HsVar "show") <syntax tree for expr>

(The "show" isn't really a string, it's the Name for the class method.)

After typechecking the syntax tree is augmented (or "elaborated") with type and dictionary application.  So in concrete form it might look like
            bar = show @Foo dShowFoo <expr>

Because show :: forall a. Show a => a -> String, so show is apply to the type of its argument, and then to the dictionary.

In HsSyn this part is done with a HsWrapper See TcEvidence.HsWrapper.  The elaborated syntax tree look like

            HsApp (HsWrap <wrapper> (HsVar "show"))
                          <syntax tree for elaborated expr>

The <wrapper> part expresses the type and dictionary application. In this case it'll look like
            WpEvApp dShowFoo (WpTyApp Foo WpHole)

See the notes with `HsWrapper` in TcEvidence.

Does that help?

It would be great to augment the https://ghc.haskell.org/trac/ghc/wiki/Commentary with this sort of info (insofar as it doesn't have it already).  If you augment I can review.  Email is quickly lost.

Simon
From: ghc-devs [mailto:ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>] On Behalf Of Robin Palotai
Sent: 19 September 2017 06:39
To: GHC developers <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>>; haskell <haskell-cafe at haskell.org<mailto:haskell-cafe at haskell.org>>
Subject: Determine instance method from class method callsite

Sorry, I messed up subject and mailing list. Copying to both list now after the mistake (wanted only ghc-devs for specificity).

Thanks!

2017-09-19 7:36 GMT+02:00 Robin Palotai <palotai.robin at gmail.com<mailto:palotai.robin at gmail.com>>:
Hello GHC devs,

Before inventing the wheel, want to check if there is a GHC API way to look up the (fully) resolved instance method from a class method.

For example, given a code

    data Foo Int deriving Show

    bar = show (Foo 3)

when inspecting the Typechecked AST for bar's show call, I would like to get to the Name / Id of 'show' of the 'Show' typeclass.

I believe I could use splitHsSigmaTy on the HsType of the function call to get the context, and then evaluate the HsWrapper somehow to find out what instance dictionary is applied to the class restriction in the context, and then look up the instance method from the dictionary..

Two questions:

1) Is there maybe functionality for this?

2) If not, is there any guarantee about the constraint order in the context, at the method call? So I could more easily determine which constraint's application to look for..

Any hints welcome && Thank you!
Robin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171005/ce83ec2b/attachment-0001.html>

From ben at well-typed.com  Thu Oct  5 23:02:25 2017
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 05 Oct 2017 19:02:25 -0400
Subject: Deprecating STM invariant mechanism
Message-ID: <87wp49p5a6.fsf@ben-laptop.smart-cactus.org>

tl;dr. Do you use Control.Monad.STM.always? If so say so on
       this [1] proposal otherwise the interface may be removed.


Hello everyone,

GHC's STM subsystem has long had the ability to run user-specified
invariant checks when committing transactions, embodied by the
Control.Monad.STM.always and alwaysSucceeds functions.

However, if Hackage is any indication this feature has seen very little
use of the past ten years. In fact, it has very likely been quite broken
(#14310) for this entire duration. 

Consequently, I suggest that we begin deprecating the mechanism. See
the deprecation Proposal [1] for full details. Please leave a comment if
you object.

Cheers,

- Ben


[1] https://github.com/ghc-proposals/ghc-proposals/pull/77
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171005/58b35e35/attachment.sig>

From moritz.angermann at gmail.com  Fri Oct  6 03:36:42 2017
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Fri, 6 Oct 2017 11:36:42 +0800
Subject: In C--: should CmmCall and CmmProc agree on their live registers?
In-Reply-To: <AM4PR83MB00339639B2E520A0ACB8DD9CAD700@AM4PR83MB0033.EURPRD83.prod.outlook.com>
References: <38053934-5C91-4921-8B3D-A5F03CF86CA4@gmail.com>
 <AM4PR83MB00339639B2E520A0ACB8DD9CAD700@AM4PR83MB0033.EURPRD83.prod.outlook.com>
Message-ID: <AC84639D-00C2-48D6-B6F5-934DA7CE3D31@gmail.com>

Hi Simon,

no, I did not until now. Thank you! As such it is acceptable that the CmmCalls
set of live registers is a superset of the CmmProcs live registers that is called.

Say we shrink the set of live registers of the CmmProc, as we determine that some of the
arguments passed in registers are not used in the graph at all.  Would we want to
propagate this information to the CmmCall if possible?

Cheers,
 Moritz


> On Oct 5, 2017, at 5:59 PM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> Did you ever get a reply to this?
> 
> In the output of the codegen, CmmProcs should have no live registers apart from those used to pass args, and the standard ones.
> 
> Simon
> 
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Moritz
> |  Angermann
> |  Sent: 22 September 2017 07:33
> |  To: GHC developers <ghc-devs at haskell.org>
> |  Subject: In C--: should CmmCall and CmmProc agree on their live registers?
> |  
> |  Hi,
> |  
> |  apologies for writing so many emails recently. This is a minor spinoff from
> |  the "The Curious Case of T6084" email.
> |  
> |  While digging into it, I keep asking myself if CmmProc’s live registers
> |  should match those of the CmmCall that is calling it?
> |  
> |  Is there any invariant we try to enforce or would want to enforce?
> |  
> |  - Can the CmmProcs live registers be a strict superset of
> |    the corresponding CmmCalls?
> |  
> |    From the source comments in `compiler/cmm/Cmm.hs`:
> |    > Registers live on entry. Note that the set of live
> |    > registers will be correct in generated C-- code, but
> |    > not in hand-written C-- code. However,
> |    > splitAtProcPoints calculates correct liveness
> |    > information for CmmProcs.
> |  
> |    I would assume that this is an invalid case?
> |  
> |  - Can the CmmProcs live registers be a strict subset of
> |    the corresponding CmmCalls?
> |  
> |    This case however seems to be valid case.  However, this
> |    makes me wonder if we can, and should(?) propagate the
> |    live register info from the CmmProc to the CmmCall so
> |    that they match up, and the registers are not kept live
> |    at the origin of the CmmCall if they aren’t needed?  And
> |    as such potentially compute anything to put into the
> |    registers the CmmCall considers live, but the CmmProc
> |    would ignore anyway?
> |  
> |  Cheers,
> |   Moritz
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell
> |  .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> |  devs&data=02%7C01%7Csimonpj%40microsoft.com%7C6009bb0f47a447a4217708d50183ce
> |  fa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636416587981602708&sdata=vII
> |  rlKVJa6E%2FBvVz5Sod1c544nw6gsGp54Mlhr7bQ8g%3D&reserved=0


From palotai.robin at gmail.com  Fri Oct  6 05:20:05 2017
From: palotai.robin at gmail.com (Robin Palotai)
Date: Fri, 6 Oct 2017 07:20:05 +0200
Subject: Determine instance method from class method callsite
In-Reply-To: <AM4PR83MB00333B11694447A6E45AD26EAD700@AM4PR83MB0033.EURPRD83.prod.outlook.com>
References: <CANiLjA1=mPF7BacBphWO2LN3erA_654qW1btkwGUgDp2tjjjng@mail.gmail.com>
 <AM4PR83MB003388E5B45912CBD4C6B013AD700@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CANiLjA2sfLYbU56LwW+df9wQKvOJXkXvz=kB-TGv6M84F6t9dw@mail.gmail.com>
 <AM4PR83MB00333B11694447A6E45AD26EAD700@AM4PR83MB0033.EURPRD83.prod.outlook.com>
Message-ID: <CANiLjA21kw-RKrRo5dZX0yrWye9CeHpQ1W0m8_32q-Ut=17oiw@mail.gmail.com>

About "Var" - that is just a Name with additional info, but happens in the
typechecked tree (according to API docs).

2017-10-05 18:00 GMT+02:00 Simon Peyton Jones <simonpj at microsoft.com>:

> well the HsWrapper might have something much more complicated than a
> DFunId.  It might need to construct the dictionary for Eq [a] from the DFun
> for Eq [a] and a dictionary for Eq a.
>
>
>
> it would be easy to resolve the Var of the instance method.
>
> I don’t know what “the var of the instance method” is.
>
>
>
> I feel I’m missing the point.  maybe others can help?
>
>
>
> Simon
>
>
>
> *From:* Robin Palotai [mailto:palotai.robin at gmail.com]
> *Sent:* 05 October 2017 11:17
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* GHC developers <ghc-devs at haskell.org>; haskell <
> haskell-cafe at haskell.org>
> *Subject:* Re: Determine instance method from class method callsite
>
>
>
> Hello Simon - I outlined the approach in https://github.com/google/
> haskell-indexer/issues/73
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoogle%2Fhaskell-indexer%2Fissues%2F73&data=02%7C01%7Csimonpj%40microsoft.com%7C6798607dd45a4865d5ef08d50bda3727%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427954212256346&sdata=HkxeXUYlbyGJnHu2%2BM17Z5aE7XXAZCWCnWwGLMV1%2BEQ%3D&reserved=0>
> .
> TLDR is
> 1) at callsite, indeed the HsWrapper needs to be analysed to get the
> instance DFunId
>
> 2) at instance declaration site, we need to again take note of the DFunId.
>
> It is slightly more complicated than I expected the API. I would have
> expected that from having the Var of a class method, and the <something> of
> the instance (here DFunId), it would be easy to resolve the Var of the
> instance method.
>
> But it seems there's no direct way, one has to build a lookup table from
> the instance methods' (DFunId + plain stringy method name), and look that
> up from the callsite.
>
> Or I might have missed a way to deconstruct / query a DFunId for the
> method Vars.
>
> I'll put augmenting the commentary on my mental TODO list :)
>
>
>
> 2017-10-05 11:58 GMT+02:00 Simon Peyton Jones <simonpj at microsoft.com>:
>
> Did you get a reply?
>
>
>
> I’m not 100% certain of your question, but consider the
>
>
>
>     bar = show <expr>
>
> for some expression e.   In the input to the type type checker the syntax
> tree for the RHS will be something like
>
>             HsApp (HsVar “show”) <syntax tree for expr>
>
>
>
> (The “show” isn’t really a string, it’s the Name for the class method.)
>
>
>
> After typechecking the syntax tree is augmented (or “elaborated”) with
> type and dictionary application.  So in concrete form it might look like
>
>             bar = show @Foo dShowFoo <expr>
>
>
>
> Because show :: forall a. Show a => a -> String, so show is apply to the
> type of its argument, and then to the dictionary.
>
>
>
> In HsSyn this part is done with a HsWrapper See TcEvidence.HsWrapper.  The
> elaborated syntax tree look like
>
>
>
>             HsApp (HsWrap <wrapper> (HsVar “show”))
>
>                           <syntax tree for elaborated expr>
>
>
>
> The <wrapper> part expresses the type and dictionary application. In this
> case it’ll look like
>
>             WpEvApp dShowFoo (WpTyApp Foo WpHole)
>
>
>
> See the notes with `HsWrapper` in TcEvidence.
>
>
>
> Does that help?
>
>
>
> It would be great to augment the https://ghc.haskell.org/trac/
> ghc/wiki/Commentary with this sort of info (insofar as it doesn’t have it
> already).  If you augment I can review.  Email is quickly lost.
>
>
>
> Simon
>
> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Robin
> Palotai
> *Sent:* 19 September 2017 06:39
> *To:* GHC developers <ghc-devs at haskell.org>; haskell <
> haskell-cafe at haskell.org>
> *Subject:* Determine instance method from class method callsite
>
>
>
> Sorry, I messed up subject and mailing list. Copying to both list now
> after the mistake (wanted only ghc-devs for specificity).
>
>
>
> Thanks!
>
>
>
> 2017-09-19 7:36 GMT+02:00 Robin Palotai <palotai.robin at gmail.com>:
>
> Hello GHC devs,
>
>
>
> Before inventing the wheel, want to check if there is a GHC API way to
> look up the (fully) resolved instance method from a class method.
>
>
>
> For example, given a code
>
>
>
>     data Foo Int deriving Show
>
>
>
>     bar = show (Foo 3)
>
>
>
> when inspecting the Typechecked AST for bar's show call, I would like to
> get to the Name / Id of 'show' of the 'Show' typeclass.
>
>
>
> I believe I could use splitHsSigmaTy on the HsType of the function call to
> get the context, and then evaluate the HsWrapper somehow to find out what
> instance dictionary is applied to the class restriction in the context, and
> then look up the instance method from the dictionary..
>
>
>
> Two questions:
>
>
>
> 1) Is there maybe functionality for this?
>
>
>
> 2) If not, is there any guarantee about the constraint order in the
> context, at the method call? So I could more easily determine which
> constraint's application to look for..
>
>
>
> Any hints welcome && Thank you!
>
> Robin
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171006/b3b253ba/attachment-0001.html>

From ben at well-typed.com  Fri Oct  6 13:04:07 2017
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 06 Oct 2017 09:04:07 -0400
Subject: Segmentation faults of bootstrap compiler?
Message-ID: <87fuawpgvs.fsf@ben-laptop.smart-cactus.org>

Hello everyone,

Earlier this week there was a commit (perhaps
ef26182e2014b0a2a029ae466a4b121bf235e4e4) which appears to trigger
segmentation faults of the stage 0 compiler (GHC 8.2.1) during
validation on Harbormaster (e.g. [1]). Unfortunately I've been unable to
reproduce this reliably. Has anyone else observed this in their own
environment?

Cheers,

- Ben


[1] https://phabricator.haskell.org/harbormaster/build/35554/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171006/37c116e3/attachment.sig>

From ben at well-typed.com  Fri Oct  6 13:25:41 2017
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 06 Oct 2017 09:25:41 -0400
Subject: Segmentation faults of bootstrap compiler?
In-Reply-To: <87fuawpgvs.fsf@ben-laptop.smart-cactus.org>
References: <87fuawpgvs.fsf@ben-laptop.smart-cactus.org>
Message-ID: <87a814pfvu.fsf@ben-laptop.smart-cactus.org>

Ben Gamari <ben at well-typed.com> writes:

> Hello everyone,
>
> Earlier this week there was a commit (perhaps
> ef26182e2014b0a2a029ae466a4b121bf235e4e4) which appears to trigger
> segmentation faults of the stage 0 compiler (GHC 8.2.1) during
> validation on Harbormaster (e.g. [1]). Unfortunately I've been unable to
> reproduce this reliably. Has anyone else observed this in their own
> environment?
>
I have been able to collect a core dump of the crashing compiler and
have opened #14329 to track the issue.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171006/65956c78/attachment.sig>

From simonpj at microsoft.com  Fri Oct  6 14:44:47 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 6 Oct 2017 14:44:47 +0000
Subject: In C--: should CmmCall and CmmProc agree on their live registers?
In-Reply-To: <AC84639D-00C2-48D6-B6F5-934DA7CE3D31@gmail.com>
References: <38053934-5C91-4921-8B3D-A5F03CF86CA4@gmail.com>
 <AM4PR83MB00339639B2E520A0ACB8DD9CAD700@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <AC84639D-00C2-48D6-B6F5-934DA7CE3D31@gmail.com>
Message-ID: <AM4PR83MB003367E439CDC06036E24D74AD710@AM4PR83MB0033.EURPRD83.prod.outlook.com>

Moritz

I have this stuff all paged out.  Would you like to give a couple of concrete examples of what you have in mind, with any design alternatives?  And illustrate your suggestion about propagation, which I don't yet grok.

Thanks

Simon

|  -----Original Message-----
|  From: Moritz Angermann [mailto:moritz.angermann at gmail.com]
|  Sent: 06 October 2017 04:37
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: GHC developers <ghc-devs at haskell.org>
|  Subject: Re: In C--: should CmmCall and CmmProc agree on their live
|  registers?
|  
|  Hi Simon,
|  
|  no, I did not until now. Thank you! As such it is acceptable that the
|  CmmCalls set of live registers is a superset of the CmmProcs live registers
|  that is called.
|  
|  Say we shrink the set of live registers of the CmmProc, as we determine that
|  some of the arguments passed in registers are not used in the graph at all.
|  Would we want to propagate this information to the CmmCall if possible?
|  
|  Cheers,
|   Moritz
|  
|  
|  > On Oct 5, 2017, at 5:59 PM, Simon Peyton Jones <simonpj at microsoft.com>
|  wrote:
|  >
|  > Did you ever get a reply to this?
|  >
|  > In the output of the codegen, CmmProcs should have no live registers apart
|  from those used to pass args, and the standard ones.
|  >
|  > Simon
|  >
|  > |  -----Original Message-----
|  > |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  > | Moritz  Angermann
|  > |  Sent: 22 September 2017 07:33
|  > |  To: GHC developers <ghc-devs at haskell.org>
|  > |  Subject: In C--: should CmmCall and CmmProc agree on their live
|  registers?
|  > |
|  > |  Hi,
|  > |
|  > |  apologies for writing so many emails recently. This is a minor
|  > | spinoff from  the "The Curious Case of T6084" email.
|  > |
|  > |  While digging into it, I keep asking myself if CmmProc’s live
|  > | registers  should match those of the CmmCall that is calling it?
|  > |
|  > |  Is there any invariant we try to enforce or would want to enforce?
|  > |
|  > |  - Can the CmmProcs live registers be a strict superset of
|  > |    the corresponding CmmCalls?
|  > |
|  > |    From the source comments in `compiler/cmm/Cmm.hs`:
|  > |    > Registers live on entry. Note that the set of live
|  > |    > registers will be correct in generated C-- code, but
|  > |    > not in hand-written C-- code. However,
|  > |    > splitAtProcPoints calculates correct liveness
|  > |    > information for CmmProcs.
|  > |
|  > |    I would assume that this is an invalid case?
|  > |
|  > |  - Can the CmmProcs live registers be a strict subset of
|  > |    the corresponding CmmCalls?
|  > |
|  > |    This case however seems to be valid case.  However, this
|  > |    makes me wonder if we can, and should(?) propagate the
|  > |    live register info from the CmmProc to the CmmCall so
|  > |    that they match up, and the registers are not kept live
|  > |    at the origin of the CmmCall if they aren’t needed?  And
|  > |    as such potentially compute anything to put into the
|  > |    registers the CmmCall considers live, but the CmmProc
|  > |    would ignore anyway?
|  > |
|  > |  Cheers,
|  > |   Moritz
|  > |  _______________________________________________
|  > |  ghc-devs mailing list
|  > |  ghc-devs at haskell.org
|  > |
|  > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail
|  > | .haskell
|  > |  .org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  > |
|  > | devs&data=02%7C01%7Csimonpj%40microsoft.com%7C6009bb0f47a447a4217708
|  > | d50183ce
|  > | fa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636416587981602708&s
|  > | data=vII
|  > |  rlKVJa6E%2FBvVz5Sod1c544nw6gsGp54Mlhr7bQ8g%3D&reserved=0


From nicolas.frisby at gmail.com  Sun Oct  8 00:19:01 2017
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Sun, 08 Oct 2017 00:19:01 +0000
Subject: Invariants about UnivCo?
In-Reply-To: <HE1PR83MB004261F48AD1973CF3E55529AD660@HE1PR83MB0042.EURPRD83.prod.outlook.com>
References: <CADfHYo7k_m2XP4RkH24rGkq-cKT2Vqm03sk1pC9PF3mpQrEObQ@mail.gmail.com>
 <HE1PR83MB004261F48AD1973CF3E55529AD660@HE1PR83MB0042.EURPRD83.prod.outlook.com>
Message-ID: <CADfHYo60Szute917RteC-DZTu+Lj4_iJitU1ams4c_e--YnXWw@mail.gmail.com>

I can happily report some progress: I'm seeing no more Core lint errors!

1) Thank you both Richard and Simon for your pointers --
-fprint-typechecker-elaboration in particular was a revelation.

2) Simon, I intend to match the spirit of the favor you requested, but not
to the letter. My goal with this project is to write a typechecker plugin
for achieving row types _without_ editing GHC's source code. I'm keeping an
annotated bibliography of things I've studied (papers, guide/wiki/blog,
source Notes, etc). (It's nice to put a bunch of related notes in the same
text file!) I'm also logging my epiphanies, which I do intend to write-up
in some kind of document (probably on the dev wiki). I'm planning a section
for suggesting which Notes should be adjusted/expanded, but I don't
anticipate feeling comfortable enough to actually edit the Notes myself.
This is unfortunately just a hobby project. My intent is to offer you,
Richard, and other experts the details of what wasn't clear to me.

3) I confirmed that the lack of cobox uniques in the dump output was indeed
due to `ppr_co' deferring to `ppr @IfaceType'; it does that (at least) for
every coercion with a head of `TyConAppCo'. With a tiny kludgy patch I was
able to persist those uniques just for debugging purposes.

4) My top-level error is an "out of scope cobox" Lint error, but (once I
patched the dumper) the output of -fprint-typechecker-elaboration showed
sufficient bindings for all of the cobox occurrences, even the one that the
Lint error was flagging! Stymied, I finally did a -DDEBUG build of the
ghc-8.2.2-rc1 tag and used that. It ultimately lead to me finding my
mistakes. (New wisdom: always use a DEBUG build when authoring a plugin.
(... Duh.))

4a) ASSERT failures showed that I was invoking `substTy' without correctly
initializing the `InScopeSet'. I also was ignorant that I should be using
`extendTvSubstAndInScope' instead of just `extendTvSubst'. I don't think
this was relevant to my particular Lint error, but I fixed it if only to
see further ASSERT failures.

4b) Fixing my `InScopeSet's ASSERT failure revealed another:
`extendIdSubst' was being called with a CoVar! That's something that my
plugin code absolutely does not do, so at that point I knew that some
higher-level operation I was doing was knocking the rest of GHC's pipeline
off the rails. (In particular, I traced this ASSERT callstack to
extendIdSubst called from simpleOptExpr called from
mkInlineUnfoldingWithArity called from DsBinds. I stopped there.)

5) The first suspect turned out to be the culprit: I was using my plugin's
by-fiat coercions in the most naive possible way, always simply `EvCast ev
(fiatCoercion ty0 ty1)`. In particular, I was even doing that to create new
Given unlifted equality witnesses from existing Given unlifted equality
witnesses when simplifying Given constraints (e.g. for example reducing a
plugin-specific type family application on one side of an unlifted equality
type ~#).

In summary, I see no more ASSERT failures or Lint errors having now changed
my plugin to prefer `EvCoercion (TransCo U (TransCo co U))` to `EvCast
(EvCoercion co) U`. The actual diff excerpt is here:
https://github.com/nfrisby/coxswain/issues/3#issuecomment-334972227

I have not figured out exactly why that change matters, but it does seem a
reasonable preference to require. In particular, Note [Coercion evidence
terms] in TcEvidence.hs explicitly says that `EvCast (EvCoercion co1) co2`
is a valid form of evidence for ~#. So perhaps that Note deserves
elaboration --- I'm guessing the missing part may be specific to Givens?

-Nick

On Thu, Sep 21, 2017 at 2:59 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Some thoughts
>
>
>
>    - Read Note [Coercion holes] in TyCoRep.
>
>
>
>    - As you’ll see, generally we don’t create value-bindings for
>    (unboxed) coercions of type t1 ~# t2.  (yes for boxed ones t1 ~ t2).
>    Reasons in the Note.  Exception: for superclasses of Givens we do create
>    (co :: a ~# b) = sc_sel1 d
>
> where d is some dictionary with a superclass of type (a ~# b).
>
>
>
> Side note: the use of “cobox” is wildly unhelpful.  These Ids are
> specifically *unboxed*!  I’m going to change it to just “co”.
>
>
>
>    - You appear to have bindings like[G]  cobox_a67J = CO Sym
>    cobox_a654.  That is suspicious.  Who is creating them?  It may not
>    actually be wrong but it’s suspicious.  The time it’d be outright wrong is
>    if you dropped the ev-binds on the floor.
>
>
>
> Ha!  runTcSEqualites makes up an ev_binds_var, and solves the equalities –
> but it should be the case that no value bindings end up in the
> ev_binds_var.  (reason: we are solving equalities in a type signature, so
> there is no place to put the evidence bindigns)   I suggest you add a
> DEBUG-only assertion to check this.
>
>
>
>    - Do -ddump-tc -fprint-typechecker-elaboration; that should show you
>    the evidence binds.
>
>
>
> Can I ask you a favour?  Separately from your branch, can you start a
> branch of small patches to GHC that include
>
>    - Extra assertions, such as that above
>    - *Notes* that explain things you wish you’d known earlier, with
>    references to those Notes from the places you were studying when you that
>    information would have been useful
>
>
>
> Richard and I know too much! – your learning curve is very valuable and I
> don’t want to lose it.
>
>
>
> Keeping this separate from your branch is useful : you can commit (via
> Phab) these updates right away, so they aren’t predicated on adding row
> types to GHC.
>
>
>
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Nicolas
> Frisby
> *Sent:* 19 September 2017 16:51
> *To:* ghc-devs at haskell.org
> *Subject:* Invariants about UnivCo?
>
>
>
> [I summarize with some direct questions at the bottom of this email.]
>
>
>
> I spent time last night trying to eliminate -dcore-lint errors from my
> record and variant library using the coxswain row types plugin. I made some
> progress, but I'm currently stuck, as discussed on this github Issue.
>
>
>
> https://github.com/nfrisby/coxswain/issues/3#issuecomment-330577609
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfrisby%2Fcoxswain%2Fissues%2F3%23issuecomment-330577609&data=02%7C01%7Csimonpj%40microsoft.com%7Cde0675bbb584495a2f8008d4ff764c72%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636414330952932223&sdata=lPLcpIlb%2BhivQdCUoVOPUgYDHeEDaMX660NQS%2BQyyBw%3D&reserved=0>
>
>
>
> Here's the relevant bit:
>
>
>
> The latest unresolved -dcore-lint error is an out-of-scope cobox co var.
> I'm certainly not creating it *directly* (there are no
> U(plugin:coxswain,... in the Core Lint warning), but I have to wonder if
> my somewhat loose use of UnivCo is violating some assumptions somewhere
> that's causing GHC to drop the co var binding or overlook this occurrence
> of it on a renaming/subst pass. I checked UnivCo for source comments
> looking for anything it should *not* be used for, but I didn't find an
> obvious explanation along those lines.
>
>
>
> I haven't yet been able to effectively distill the test case.
>
>
>
> I'm doing this all at -O0.
>
>
>
> With `-ddump-tc-trace`, I can see the offending cobox (cobox_a67M) is
> present in an "implication evbinds" listing after a "solveImplication end
> }" delimiter, but that's the last obvious binding of it.
>
>
>
>                          [G] cobox_a67J = CO Sym cobox_a654,
>
>                          [G] cobox_a67M
>
>                            = cobox_a67J `cast` U(plugin:coxswain,...)
>
>
>
> cobox_a654 is introduced by a GADT pattern match.
>
>
>
> I'm also not seeing obvious occurrences of cobox_a67M, but I think the
> reason is that I'm seeing several (Sym cobox) with no uniques printed (even
> with `-dppr-debug`). Those are probably the cobox in question, but I can't
> confirm.
>
>
>
> Questions:
>
>
>
> 1) Is there a robust way to ensure that covar's uniques are always
> printed? (Is the pprIface reuse  with a free cobox part of the issue here?)
>
>
>
> 2) Is my plugin asking for this kind of trouble by using UnivCo to cast
> coboxes?
>
>
>
> 3) If I spent the effort to create non-UnivCo coercions where possible,
> would that likely help? This is currently an "eventually" task, but I
> haven't seen an urgency for it yet. I could bump its priority if it might
> help. E.G. I'm using UnivCo to cast entire givens when all I'm doing is
> reducing a type family application somewhere "deep" within the given's
> predtype. I could, with considerable effort, instead wrap a single,
> localized UnivCo within a bunch of non-UnivCo "lifting" coercion
> constructors. Would that likely help?
>
>
>
> 3) Is there a usual suspect for this kind of situation where a cobox
> binding is seemingly dropped (by the typechecker) even though there's an
> occurrence of it?
>
>
>
> Thank you for your time. -Nick
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171008/52d6f9b7/attachment.html>

From tjakway at nyu.edu  Sun Oct  8 21:31:26 2017
From: tjakway at nyu.edu (Thomas Jakway)
Date: Sun, 8 Oct 2017 14:31:26 -0700
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <8760bur4sj.fsf@ben-laptop.smart-cactus.org>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
 <8760bur4sj.fsf@ben-laptop.smart-cactus.org>
Message-ID: <afafc3d6-253e-980f-2176-39ae5e734858@nyu.edu>

I'm on Ubuntu 16.10.

I ran git bisect:

----------------------

e515c7f37be97e1c2ccc497ddd0a730e63ddfa82 is the first bad commit
commit e515c7f37be97e1c2ccc497ddd0a730e63ddfa82
Author: Moritz Angermann <moritz.angermann at gmail.com>
Date:   Sat Sep 30 09:31:12 2017 -0400

Allow libffi snapshots

This is rather annoying. I'd prefer to have a stable release to
use. However libffi-3.2.1 has been released November 12, 2014, and
libffi-4 is TBD. See also https://github.com/libffi/libffi/issues/296

The core reason for this change is that llvm changed the supported
assembly to unified syntax, which libffi-3.2.1 does not use, and hence
fails to compile for arm with llvm. For refence, see the following
issue: https://github.com/libffi/libffi/issues/191.

This diff contains a script to generate a tarball for the
`libffi-tarballs` repository from the libffi GitHub repository; as well
as the necessary changes to the build system.

Updates libffi-tarballs submodule.

Reviewers: austin, bgamari, hvr

Subscribers: hvr, erikd, rwbarton, thomie

Differential Revision: https://phabricator.haskell.org/D3574

----------------------

I can't reproduce it on my other linux computers though.


On 10/04/2017 02:17 PM, Ben Gamari wrote:
> Thomas Jakway <tjakway at nyu.edu> writes:
>
>> Anyone else getting linker errors?
>>
>> This is after running
>>
>> make clean && make distclean && find . -name "*.o" -type f -delete &&
>> find . -name "*.hi" -type f -delete
>>
>> then
>>
>> ./boot && ./configure && make -j5
>>
>> (ghc-new is not a new checkout, this error is happening on a branch I'm
>> working on, but one that doesn't touch the FFI)
>>
> I'm afraid I can't reproduce this. What platform/operating system is
> this on?
>
> Cheers,
>
> - Ben


From rae at cs.brynmawr.edu  Mon Oct  9 01:53:50 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sun, 8 Oct 2017 21:53:50 -0400
Subject: Invariants about UnivCo?
In-Reply-To: <CADfHYo60Szute917RteC-DZTu+Lj4_iJitU1ams4c_e--YnXWw@mail.gmail.com>
References: <CADfHYo7k_m2XP4RkH24rGkq-cKT2Vqm03sk1pC9PF3mpQrEObQ@mail.gmail.com>
 <HE1PR83MB004261F48AD1973CF3E55529AD660@HE1PR83MB0042.EURPRD83.prod.outlook.com>
 <CADfHYo60Szute917RteC-DZTu+Lj4_iJitU1ams4c_e--YnXWw@mail.gmail.com>
Message-ID: <53074143-DCCC-4C03-B176-47278AA41E79@cs.brynmawr.edu>

Thanks for this status report. If I'm to boil it down to the question you seem to be asking: What does changing EvCast ... to EvCoercion ... fix the problem? I'm not sure of the answer at this point, but I want to make sure I understand the question before I go digging for an answer. It's always possible a Note is wrong!

Thanks for this!

Richard

> On Oct 7, 2017, at 8:19 PM, Nicolas Frisby <nicolas.frisby at gmail.com> wrote:
> 
> I can happily report some progress: I'm seeing no more Core lint errors!
> 
> 1) Thank you both Richard and Simon for your pointers -- -fprint-typechecker-elaboration in particular was a revelation.
> 
> 2) Simon, I intend to match the spirit of the favor you requested, but not to the letter. My goal with this project is to write a typechecker plugin for achieving row types _without_ editing GHC's source code. I'm keeping an annotated bibliography of things I've studied (papers, guide/wiki/blog, source Notes, etc). (It's nice to put a bunch of related notes in the same text file!) I'm also logging my epiphanies, which I do intend to write-up in some kind of document (probably on the dev wiki). I'm planning a section for suggesting which Notes should be adjusted/expanded, but I don't anticipate feeling comfortable enough to actually edit the Notes myself. This is unfortunately just a hobby project. My intent is to offer you, Richard, and other experts the details of what wasn't clear to me.
> 
> 3) I confirmed that the lack of cobox uniques in the dump output was indeed due to `ppr_co' deferring to `ppr @IfaceType'; it does that (at least) for every coercion with a head of `TyConAppCo'. With a tiny kludgy patch I was able to persist those uniques just for debugging purposes.
> 
> 4) My top-level error is an "out of scope cobox" Lint error, but (once I patched the dumper) the output of -fprint-typechecker-elaboration showed sufficient bindings for all of the cobox occurrences, even the one that the Lint error was flagging! Stymied, I finally did a -DDEBUG build of the ghc-8.2.2-rc1 tag and used that. It ultimately lead to me finding my mistakes. (New wisdom: always use a DEBUG build when authoring a plugin. (... Duh.))
> 
> 4a) ASSERT failures showed that I was invoking `substTy' without correctly initializing the `InScopeSet'. I also was ignorant that I should be using `extendTvSubstAndInScope' instead of just `extendTvSubst'. I don't think this was relevant to my particular Lint error, but I fixed it if only to see further ASSERT failures.
> 
> 4b) Fixing my `InScopeSet's ASSERT failure revealed another: `extendIdSubst' was being called with a CoVar! That's something that my plugin code absolutely does not do, so at that point I knew that some higher-level operation I was doing was knocking the rest of GHC's pipeline off the rails. (In particular, I traced this ASSERT callstack to extendIdSubst called from simpleOptExpr called from mkInlineUnfoldingWithArity called from DsBinds. I stopped there.)
> 
> 5) The first suspect turned out to be the culprit: I was using my plugin's by-fiat coercions in the most naive possible way, always simply `EvCast ev (fiatCoercion ty0 ty1)`. In particular, I was even doing that to create new Given unlifted equality witnesses from existing Given unlifted equality witnesses when simplifying Given constraints (e.g. for example reducing a plugin-specific type family application on one side of an unlifted equality type ~#).
> 
> In summary, I see no more ASSERT failures or Lint errors having now changed my plugin to prefer `EvCoercion (TransCo U (TransCo co U))` to `EvCast (EvCoercion co) U`. The actual diff excerpt is here: https://github.com/nfrisby/coxswain/issues/3#issuecomment-334972227 <https://github.com/nfrisby/coxswain/issues/3#issuecomment-334972227>
> 
> I have not figured out exactly why that change matters, but it does seem a reasonable preference to require. In particular, Note [Coercion evidence terms] in TcEvidence.hs explicitly says that `EvCast (EvCoercion co1) co2` is a valid form of evidence for ~#. So perhaps that Note deserves elaboration --- I'm guessing the missing part may be specific to Givens?
> 
> -Nick
> 
> On Thu, Sep 21, 2017 at 2:59 AM Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
> Some thoughts
> 
>  
> 
> Read Note [Coercion holes] in TyCoRep.
>  
> 
> As you’ll see, generally we don’t create value-bindings for (unboxed) coercions of type t1 ~# t2.  (yes for boxed ones t1 ~ t2).     Reasons in the Note.  Exception: for superclasses of Givens we do create    (co :: a ~# b) = sc_sel1 d
> where d is some dictionary with a superclass of type (a ~# b).
> 
>  
> 
> Side note: the use of “cobox” is wildly unhelpful.  These Ids are specifically unboxed!  I’m going to change it to just “co”.
> 
>  
> 
> You appear to have bindings like[G]  cobox_a67J = CO Sym cobox_a654.  That is suspicious.  Who is creating them?  It may not actually be wrong but it’s suspicious.  The time it’d be outright wrong is if you dropped the ev-binds on the floor.
>  
> 
> Ha!  runTcSEqualites makes up an ev_binds_var, and solves the equalities – but it should be the case that no value bindings end up in the ev_binds_var.  (reason: we are solving equalities in a type signature, so there is no place to put the evidence bindigns)   I suggest you add a DEBUG-only assertion to check this.
> 
>  
> 
> Do -ddump-tc -fprint-typechecker-elaboration; that should show you the evidence binds.
>  
> 
> Can I ask you a favour?  Separately from your branch, can you start a branch of small patches to GHC that include
> 
> Extra assertions, such as that above
> Notes that explain things you wish you’d known earlier, with references to those Notes from the places you were studying when you that information would have been useful
>  
> 
> Richard and I know too much! – your learning curve is very valuable and I don’t want to lose it.
> 
>  
> 
> Keeping this separate from your branch is useful : you can commit (via Phab) these updates right away, so they aren’t predicated on adding row types to GHC.
> 
>  
> 
> Simon
> 
>  
> 
> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org <mailto:ghc-devs-bounces at haskell.org>] On Behalf Of Nicolas Frisby
> Sent: 19 September 2017 16:51
> To: ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> Subject: Invariants about UnivCo?
> 
>  
> 
> [I summarize with some direct questions at the bottom of this email.]
> 
>  
> 
> I spent time last night trying to eliminate -dcore-lint errors from my record and variant library using the coxswain row types plugin. I made some progress, but I'm currently stuck, as discussed on this github Issue.
> 
>  
> 
> https://github.com/nfrisby/coxswain/issues/3#issuecomment-330577609 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfrisby%2Fcoxswain%2Fissues%2F3%23issuecomment-330577609&data=02%7C01%7Csimonpj%40microsoft.com%7Cde0675bbb584495a2f8008d4ff764c72%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636414330952932223&sdata=lPLcpIlb%2BhivQdCUoVOPUgYDHeEDaMX660NQS%2BQyyBw%3D&reserved=0>
>  
> 
> Here's the relevant bit:
> 
>  
> 
> The latest unresolved -dcore-lint error is an out-of-scope cobox co var. I'm certainly not creating it directly (there are no U(plugin:coxswain,... in the Core Lint warning), but I have to wonder if my somewhat loose use of UnivCo is violating some assumptions somewhere that's causing GHC to drop the co var binding or overlook this occurrence of it on a renaming/subst pass. I checked UnivCo for source comments looking for anything it should not be used for, but I didn't find an obvious explanation along those lines.  
> 
>  
> 
> I haven't yet been able to effectively distill the test case.
> 
>  
> 
> I'm doing this all at -O0.
> 
>  
> 
> With `-ddump-tc-trace`, I can see the offending cobox (cobox_a67M) is present in an "implication evbinds" listing after a "solveImplication end }" delimiter, but that's the last obvious binding of it.
> 
>  
> 
>                          [G] cobox_a67J = CO Sym cobox_a654,
> 
>                          [G] cobox_a67M
> 
>                            = cobox_a67J `cast` U(plugin:coxswain,...)
> 
>  
> 
> cobox_a654 is introduced by a GADT pattern match. 
> 
>  
> 
> I'm also not seeing obvious occurrences of cobox_a67M, but I think the reason is that I'm seeing several (Sym cobox) with no uniques printed (even with `-dppr-debug`). Those are probably the cobox in question, but I can't confirm.
> 
>  
> 
> Questions:
> 
>  
> 
> 1) Is there a robust way to ensure that covar's uniques are always printed? (Is the pprIface reuse  with a free cobox part of the issue here?)
> 
>  
> 
> 2) Is my plugin asking for this kind of trouble by using UnivCo to cast coboxes?
> 
>  
> 
> 3) If I spent the effort to create non-UnivCo coercions where possible, would that likely help? This is currently an "eventually" task, but I haven't seen an urgency for it yet. I could bump its priority if it might help. E.G. I'm using UnivCo to cast entire givens when all I'm doing is reducing a type family application somewhere "deep" within the given's predtype. I could, with considerable effort, instead wrap a single, localized UnivCo within a bunch of non-UnivCo "lifting" coercion constructors. Would that likely help?
> 
>  
> 
> 3) Is there a usual suspect for this kind of situation where a cobox binding is seemingly dropped (by the typechecker) even though there's an occurrence of it?
> 
>  
> 
> Thank you for your time. -Nick
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171008/3775da4f/attachment-0001.html>

From nicolas.frisby at gmail.com  Mon Oct  9 02:50:16 2017
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Mon, 09 Oct 2017 02:50:16 +0000
Subject: Invariants about UnivCo?
In-Reply-To: <53074143-DCCC-4C03-B176-47278AA41E79@cs.brynmawr.edu>
References: <CADfHYo7k_m2XP4RkH24rGkq-cKT2Vqm03sk1pC9PF3mpQrEObQ@mail.gmail.com>
 <HE1PR83MB004261F48AD1973CF3E55529AD660@HE1PR83MB0042.EURPRD83.prod.outlook.com>
 <CADfHYo60Szute917RteC-DZTu+Lj4_iJitU1ams4c_e--YnXWw@mail.gmail.com>
 <53074143-DCCC-4C03-B176-47278AA41E79@cs.brynmawr.edu>
Message-ID: <CADfHYo57DAZ_jXdCx=bSQCeJ-a3A+9MOK9mhQsz9bif8x4ZYrQ@mail.gmail.com>

Yep, that's the current question: why does preferring `EvCoercion (TransCo
UnivCo (TransCo co UnivCo))` to `EvCast (EvCoercion co) UnivCo` seem to
matter? In my scenario, `co` is the evidence for a Given equality type. And
the coercion I'm building is also a Given constraint's evidence -- I'm
simplifying Givens.

The only hard indication I currently have of what "goes wrong" is the
ASSERT failure described in the previous email.

I'm planning to spend some time investigating. I would appreciate any
cycles you spend on it!

On Sun, Oct 8, 2017, 18:53 Richard Eisenberg <rae at cs.brynmawr.edu> wrote:

> Thanks for this status report. If I'm to boil it down to the question you
> seem to be asking: What does changing EvCast ... to EvCoercion ... fix the
> problem? I'm not sure of the answer at this point, but I want to make sure
> I understand the question before I go digging for an answer. It's always
> possible a Note is wrong!
>
> Thanks for this!
>
> Richard
>
> On Oct 7, 2017, at 8:19 PM, Nicolas Frisby <nicolas.frisby at gmail.com>
> wrote:
>
> I can happily report some progress: I'm seeing no more Core lint errors!
>
> 1) Thank you both Richard and Simon for your pointers --
> -fprint-typechecker-elaboration in particular was a revelation.
>
> 2) Simon, I intend to match the spirit of the favor you requested, but not
> to the letter. My goal with this project is to write a typechecker plugin
> for achieving row types _without_ editing GHC's source code. I'm keeping an
> annotated bibliography of things I've studied (papers, guide/wiki/blog,
> source Notes, etc). (It's nice to put a bunch of related notes in the same
> text file!) I'm also logging my epiphanies, which I do intend to write-up
> in some kind of document (probably on the dev wiki). I'm planning a section
> for suggesting which Notes should be adjusted/expanded, but I don't
> anticipate feeling comfortable enough to actually edit the Notes myself.
> This is unfortunately just a hobby project. My intent is to offer you,
> Richard, and other experts the details of what wasn't clear to me.
>
> 3) I confirmed that the lack of cobox uniques in the dump output was
> indeed due to `ppr_co' deferring to `ppr @IfaceType'; it does that (at
> least) for every coercion with a head of `TyConAppCo'. With a tiny kludgy
> patch I was able to persist those uniques just for debugging purposes.
>
> 4) My top-level error is an "out of scope cobox" Lint error, but (once I
> patched the dumper) the output of -fprint-typechecker-elaboration showed
> sufficient bindings for all of the cobox occurrences, even the one that the
> Lint error was flagging! Stymied, I finally did a -DDEBUG build of the
> ghc-8.2.2-rc1 tag and used that. It ultimately lead to me finding my
> mistakes. (New wisdom: always use a DEBUG build when authoring a plugin.
> (... Duh.))
>
> 4a) ASSERT failures showed that I was invoking `substTy' without correctly
> initializing the `InScopeSet'. I also was ignorant that I should be using
> `extendTvSubstAndInScope' instead of just `extendTvSubst'. I don't think
> this was relevant to my particular Lint error, but I fixed it if only to
> see further ASSERT failures.
>
> 4b) Fixing my `InScopeSet's ASSERT failure revealed another:
> `extendIdSubst' was being called with a CoVar! That's something that my
> plugin code absolutely does not do, so at that point I knew that some
> higher-level operation I was doing was knocking the rest of GHC's pipeline
> off the rails. (In particular, I traced this ASSERT callstack to
> extendIdSubst called from simpleOptExpr called from
> mkInlineUnfoldingWithArity called from DsBinds. I stopped there.)
>
> 5) The first suspect turned out to be the culprit: I was using my plugin's
> by-fiat coercions in the most naive possible way, always simply `EvCast ev
> (fiatCoercion ty0 ty1)`. In particular, I was even doing that to create new
> Given unlifted equality witnesses from existing Given unlifted equality
> witnesses when simplifying Given constraints (e.g. for example reducing a
> plugin-specific type family application on one side of an unlifted equality
> type ~#).
>
> In summary, I see no more ASSERT failures or Lint errors having now
> changed my plugin to prefer `EvCoercion (TransCo U (TransCo co U))` to
> `EvCast (EvCoercion co) U`. The actual diff excerpt is here:
> https://github.com/nfrisby/coxswain/issues/3#issuecomment-334972227
>
> I have not figured out exactly why that change matters, but it does seem a
> reasonable preference to require. In particular, Note [Coercion evidence
> terms] in TcEvidence.hs explicitly says that `EvCast (EvCoercion co1) co2`
> is a valid form of evidence for ~#. So perhaps that Note deserves
> elaboration --- I'm guessing the missing part may be specific to Givens?
>
> -Nick
>
> On Thu, Sep 21, 2017 at 2:59 AM Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
>> Some thoughts
>>
>>
>>
>>    - Read Note [Coercion holes] in TyCoRep.
>>
>>
>>
>>    - As you’ll see, generally we don’t create value-bindings for
>>    (unboxed) coercions of type t1 ~# t2.  (yes for boxed ones t1 ~ t2).
>>    Reasons in the Note.  Exception: for superclasses of Givens we do create
>>    (co :: a ~# b) = sc_sel1 d
>>
>> where d is some dictionary with a superclass of type (a ~# b).
>>
>>
>>
>> Side note: the use of “cobox” is wildly unhelpful.  These Ids are
>> specifically *unboxed*!  I’m going to change it to just “co”.
>>
>>
>>
>>    - You appear to have bindings like[G]  cobox_a67J = CO Sym
>>    cobox_a654.  That is suspicious.  Who is creating them?  It may not
>>    actually be wrong but it’s suspicious.  The time it’d be outright wrong is
>>    if you dropped the ev-binds on the floor.
>>
>>
>>
>> Ha!  runTcSEqualites makes up an ev_binds_var, and solves the equalities
>> – but it should be the case that no value bindings end up in the
>> ev_binds_var.  (reason: we are solving equalities in a type signature, so
>> there is no place to put the evidence bindigns)   I suggest you add a
>> DEBUG-only assertion to check this.
>>
>>
>>
>>    - Do -ddump-tc -fprint-typechecker-elaboration; that should show you
>>    the evidence binds.
>>
>>
>>
>> Can I ask you a favour?  Separately from your branch, can you start a
>> branch of small patches to GHC that include
>>
>>    - Extra assertions, such as that above
>>    - *Notes* that explain things you wish you’d known earlier, with
>>    references to those Notes from the places you were studying when you that
>>    information would have been useful
>>
>>
>>
>> Richard and I know too much! – your learning curve is very valuable and I
>> don’t want to lose it.
>>
>>
>>
>> Keeping this separate from your branch is useful : you can commit (via
>> Phab) these updates right away, so they aren’t predicated on adding row
>> types to GHC.
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Nicolas
>> Frisby
>> *Sent:* 19 September 2017 16:51
>> *To:* ghc-devs at haskell.org
>> *Subject:* Invariants about UnivCo?
>>
>>
>>
>> [I summarize with some direct questions at the bottom of this email.]
>>
>>
>>
>> I spent time last night trying to eliminate -dcore-lint errors from my
>> record and variant library using the coxswain row types plugin. I made some
>> progress, but I'm currently stuck, as discussed on this github Issue.
>>
>>
>>
>> https://github.com/nfrisby/coxswain/issues/3#issuecomment-330577609
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfrisby%2Fcoxswain%2Fissues%2F3%23issuecomment-330577609&data=02%7C01%7Csimonpj%40microsoft.com%7Cde0675bbb584495a2f8008d4ff764c72%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636414330952932223&sdata=lPLcpIlb%2BhivQdCUoVOPUgYDHeEDaMX660NQS%2BQyyBw%3D&reserved=0>
>>
>>
>>
>> Here's the relevant bit:
>>
>>
>>
>> The latest unresolved -dcore-lint error is an out-of-scope cobox co var.
>> I'm certainly not creating it *directly* (there are no
>> U(plugin:coxswain,... in the Core Lint warning), but I have to wonder if
>> my somewhat loose use of UnivCo is violating some assumptions somewhere
>> that's causing GHC to drop the co var binding or overlook this occurrence
>> of it on a renaming/subst pass. I checked UnivCo for source comments
>> looking for anything it should *not* be used for, but I didn't find an
>> obvious explanation along those lines.
>>
>>
>>
>> I haven't yet been able to effectively distill the test case.
>>
>>
>>
>> I'm doing this all at -O0.
>>
>>
>>
>> With `-ddump-tc-trace`, I can see the offending cobox (cobox_a67M) is
>> present in an "implication evbinds" listing after a "solveImplication end
>> }" delimiter, but that's the last obvious binding of it.
>>
>>
>>
>>                          [G] cobox_a67J = CO Sym cobox_a654,
>>
>>                          [G] cobox_a67M
>>
>>                            = cobox_a67J `cast` U(plugin:coxswain,...)
>>
>>
>>
>> cobox_a654 is introduced by a GADT pattern match.
>>
>>
>>
>> I'm also not seeing obvious occurrences of cobox_a67M, but I think the
>> reason is that I'm seeing several (Sym cobox) with no uniques printed (even
>> with `-dppr-debug`). Those are probably the cobox in question, but I can't
>> confirm.
>>
>>
>>
>> Questions:
>>
>>
>>
>> 1) Is there a robust way to ensure that covar's uniques are always
>> printed? (Is the pprIface reuse  with a free cobox part of the issue here?)
>>
>>
>>
>> 2) Is my plugin asking for this kind of trouble by using UnivCo to cast
>> coboxes?
>>
>>
>>
>> 3) If I spent the effort to create non-UnivCo coercions where possible,
>> would that likely help? This is currently an "eventually" task, but I
>> haven't seen an urgency for it yet. I could bump its priority if it might
>> help. E.G. I'm using UnivCo to cast entire givens when all I'm doing is
>> reducing a type family application somewhere "deep" within the given's
>> predtype. I could, with considerable effort, instead wrap a single,
>> localized UnivCo within a bunch of non-UnivCo "lifting" coercion
>> constructors. Would that likely help?
>>
>>
>>
>> 3) Is there a usual suspect for this kind of situation where a cobox
>> binding is seemingly dropped (by the typechecker) even though there's an
>> occurrence of it?
>>
>>
>>
>> Thank you for your time. -Nick
>>
> _______________________________________________
>
>
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171009/3c05b33d/attachment-0001.html>

From ekmett at gmail.com  Mon Oct  9 03:33:23 2017
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 8 Oct 2017 23:33:23 -0400
Subject: Deprecating STM invariant mechanism
In-Reply-To: <87wp49p5a6.fsf@ben-laptop.smart-cactus.org>
References: <87wp49p5a6.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CAJumaK8zFAgVtkSnzxYoCui9KPG2sBzXeSnvHekc1pYm74prww@mail.gmail.com>

I only have two uses of it at present and come to think of it I'm now
dubious about if they were doing anything, so I can pretty readily work
around its removal!

+1

No objection here.

-Edward

On Thu, Oct 5, 2017 at 7:02 PM, Ben Gamari <ben at well-typed.com> wrote:

> tl;dr. Do you use Control.Monad.STM.always? If so say so on
>        this [1] proposal otherwise the interface may be removed.
>
>
> Hello everyone,
>
> GHC's STM subsystem has long had the ability to run user-specified
> invariant checks when committing transactions, embodied by the
> Control.Monad.STM.always and alwaysSucceeds functions.
>
> However, if Hackage is any indication this feature has seen very little
> use of the past ten years. In fact, it has very likely been quite broken
> (#14310) for this entire duration.
>
> Consequently, I suggest that we begin deprecating the mechanism. See
> the deprecation Proposal [1] for full details. Please leave a comment if
> you object.
>
> Cheers,
>
> - Ben
>
>
> [1] https://github.com/ghc-proposals/ghc-proposals/pull/77
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171008/f483cbe4/attachment.html>

From moritz at lichtzwerge.de  Mon Oct  9 06:40:15 2017
From: moritz at lichtzwerge.de (Moritz Angermann)
Date: Mon, 9 Oct 2017 13:40:15 +0700
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <afafc3d6-253e-980f-2176-39ae5e734858@nyu.edu>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
 <8760bur4sj.fsf@ben-laptop.smart-cactus.org>
 <afafc3d6-253e-980f-2176-39ae5e734858@nyu.edu>
Message-ID: <A18C8C4B-E72B-47CC-9B1E-B3896EB106EC@lichtzwerge.de>

Yes, this commit indeed introduced the need for makeinfo, however after some debugging and improved packaging of the external libffi library, this dependency was removed again, and should not be required with the latest head anymore.

Then again this should not result in link issues but rather in build time issues.

The key to libffi is the libffi-tarballs git submodule, which contains the packaged libffi-tarballs. Make sure all your submodules are also updated.

I usually use `git -x -f -d` (read the documentation first) to ensure a clean working tree. Especially as you say you can’t reproduce it on other machines, maybe there is a file in your tree that the cleaning did not catch?

Sent from my iPhone

> On 9 Oct 2017, at 4:31 AM, Thomas Jakway <tjakway at nyu.edu> wrote:
> 
> I'm on Ubuntu 16.10.
> 
> I ran git bisect:
> 
> ----------------------
> 
> e515c7f37be97e1c2ccc497ddd0a730e63ddfa82 is the first bad commit
> commit e515c7f37be97e1c2ccc497ddd0a730e63ddfa82
> Author: Moritz Angermann <moritz.angermann at gmail.com>
> Date:   Sat Sep 30 09:31:12 2017 -0400
> 
> Allow libffi snapshots
> 
> This is rather annoying. I'd prefer to have a stable release to
> use. However libffi-3.2.1 has been released November 12, 2014, and
> libffi-4 is TBD. See also https://github.com/libffi/libffi/issues/296
> 
> The core reason for this change is that llvm changed the supported
> assembly to unified syntax, which libffi-3.2.1 does not use, and hence
> fails to compile for arm with llvm. For refence, see the following
> issue: https://github.com/libffi/libffi/issues/191.
> 
> This diff contains a script to generate a tarball for the
> `libffi-tarballs` repository from the libffi GitHub repository; as well
> as the necessary changes to the build system.
> 
> Updates libffi-tarballs submodule.
> 
> Reviewers: austin, bgamari, hvr
> 
> Subscribers: hvr, erikd, rwbarton, thomie
> 
> Differential Revision: https://phabricator.haskell.org/D3574
> 
> ----------------------
> 
> I can't reproduce it on my other linux computers though.
> 
> 
>> On 10/04/2017 02:17 PM, Ben Gamari wrote:
>> Thomas Jakway <tjakway at nyu.edu> writes:
>> 
>>> Anyone else getting linker errors?
>>> 
>>> This is after running
>>> 
>>> make clean && make distclean && find . -name "*.o" -type f -delete &&
>>> find . -name "*.hi" -type f -delete
>>> 
>>> then
>>> 
>>> ./boot && ./configure && make -j5
>>> 
>>> (ghc-new is not a new checkout, this error is happening on a branch I'm
>>> working on, but one that doesn't touch the FFI)
>>> 
>> I'm afraid I can't reproduce this. What platform/operating system is
>> this on?
>> 
>> Cheers,
>> 
>> - Ben
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From ben at well-typed.com  Mon Oct  9 16:15:41 2017
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 09 Oct 2017 12:15:41 -0400
Subject: Call for features for GHC 8.4
Message-ID: <87efqcnvpu.fsf@ben-laptop.smart-cactus.org>

Hello everyone,

The release of GHC 8.4 is quickly approaching, with a release targetted
for February 2018. To allow plenty of time for stabilization, we would
like to cut the ghc-8.4 branch sometime in November. Currently there are
relatively few items on the 8.4 status page [1]. If you have a feature
which you would like to see in 8.4 but is not listed there please do
add it soon.

Also note that if things go according to plan, 8.6 will come a mere six
months after 8.4 so if you have a large feature which won't make it for
8.4, do not fret; another release will be just around the corner.

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.4.1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171009/71c8e7bd/attachment.sig>

From qdunkan at gmail.com  Mon Oct  9 18:45:33 2017
From: qdunkan at gmail.com (Evan Laforge)
Date: Mon, 9 Oct 2017 11:45:33 -0700
Subject: Call for features for GHC 8.4
In-Reply-To: <87efqcnvpu.fsf@ben-laptop.smart-cactus.org>
References: <87efqcnvpu.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CACbaDy7W6zu8brfSun4NP_uVZo8ULa47bm4Z=jfpSBWABLN8CQ@mail.gmail.com>

I'd like to see this fixed: https://ghc.haskell.org/trac/ghc/ticket/13604

It's a show stopper that prevented me from being able to use 8.2 at all.

Once again, if no one has time to address it, I'd be happy to take a
look myself.

On Mon, Oct 9, 2017 at 9:15 AM, Ben Gamari <ben at well-typed.com> wrote:
> Hello everyone,
>
> The release of GHC 8.4 is quickly approaching, with a release targetted
> for February 2018. To allow plenty of time for stabilization, we would
> like to cut the ghc-8.4 branch sometime in November. Currently there are
> relatively few items on the 8.4 status page [1]. If you have a feature
> which you would like to see in 8.4 but is not listed there please do
> add it soon.
>
> Also note that if things go according to plan, 8.6 will come a mere six
> months after 8.4 so if you have a large feature which won't make it for
> 8.4, do not fret; another release will be just around the corner.
>
> Cheers,
>
> - Ben
>
>
> [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.4.1
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From ben at well-typed.com  Mon Oct  9 19:10:34 2017
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 09 Oct 2017 15:10:34 -0400
Subject: Call for features for GHC 8.4
In-Reply-To: <CACbaDy7W6zu8brfSun4NP_uVZo8ULa47bm4Z=jfpSBWABLN8CQ@mail.gmail.com>
References: <87efqcnvpu.fsf@ben-laptop.smart-cactus.org>
 <CACbaDy7W6zu8brfSun4NP_uVZo8ULa47bm4Z=jfpSBWABLN8CQ@mail.gmail.com>
Message-ID: <8760bonnmd.fsf@ben-laptop.smart-cactus.org>

Evan Laforge <qdunkan at gmail.com> writes:

> I'd like to see this fixed: https://ghc.haskell.org/trac/ghc/ticket/13604
>
> It's a show stopper that prevented me from being able to use 8.2 at all.

David, could you see to it that something happens on this front?

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171009/94edd263/attachment.sig>

From moritz.angermann at gmail.com  Tue Oct 10 07:15:25 2017
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 10 Oct 2017 14:15:25 +0700
Subject: Call for features for GHC 8.4
In-Reply-To: <87efqcnvpu.fsf@ben-laptop.smart-cactus.org>
References: <87efqcnvpu.fsf@ben-laptop.smart-cactus.org>
Message-ID: <B0821946-7E7C-4893-B746-8B112023BAC0@gmail.com>

I’ll try to update the page when I’m back from VN.

8.4
- aarch64/arm linker for mach-o/elf
- staticlib
- iserv over the network
- extended Q monad? (I really think we should try to iron this out for 8.4)
- various iOS/Android/Raspberry Pi/... cross compilation fixes
- llvm5

8.6
- llvmng? I’m afraid this will be ready for 8.4.

Which release will be Hadrian first?

Sent from my iPhone

> On 9 Oct 2017, at 11:15 PM, Ben Gamari <ben at well-typed.com> wrote:
> 
> Hello everyone,
> 
> The release of GHC 8.4 is quickly approaching, with a release targetted
> for February 2018. To allow plenty of time for stabilization, we would
> like to cut the ghc-8.4 branch sometime in November. Currently there are
> relatively few items on the 8.4 status page [1]. If you have a feature
> which you would like to see in 8.4 but is not listed there please do
> add it soon.
> 
> Also note that if things go according to plan, 8.6 will come a mere six
> months after 8.4 so if you have a large feature which won't make it for
> 8.4, do not fret; another release will be just around the corner.
> 
> Cheers,
> 
> - Ben
> 
> 
> [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.4.1
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From ben at well-typed.com  Tue Oct 10 17:17:09 2017
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 10 Oct 2017 13:17:09 -0400
Subject: Call for features for GHC 8.4
In-Reply-To: <B0821946-7E7C-4893-B746-8B112023BAC0@gmail.com>
References: <87efqcnvpu.fsf@ben-laptop.smart-cactus.org>
 <B0821946-7E7C-4893-B746-8B112023BAC0@gmail.com>
Message-ID: <8760bmncru.fsf@ben-laptop.smart-cactus.org>

Moritz Angermann <moritz.angermann at gmail.com> writes:

> I’ll try to update the page when I’m back from VN.
>
> 8.4
> - aarch64/arm linker for mach-o/elf
> - staticlib
> - iserv over the network
> - extended Q monad? (I really think we should try to iron this out for 8.4)
> - various iOS/Android/Raspberry Pi/... cross compilation fixes
> - llvm5
>
Great; do update the status page when you get a chance (although there
is already an entry for general improvement of cross-compilation).

> 8.6
> - llvmng? I’m afraid this will be ready for 8.4.
>
> Which release will be Hadrian first?
>
We very much hope to have Hadrian in 8.4.

Enjoy your vacation!

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171010/ca410caa/attachment.sig>

From tjakway at nyu.edu  Tue Oct 10 17:43:52 2017
From: tjakway at nyu.edu (Thomas Jakway)
Date: Tue, 10 Oct 2017 13:43:52 -0400
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <A18C8C4B-E72B-47CC-9B1E-B3896EB106EC@lichtzwerge.de>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
 <8760bur4sj.fsf@ben-laptop.smart-cactus.org>
 <afafc3d6-253e-980f-2176-39ae5e734858@nyu.edu>
 <A18C8C4B-E72B-47CC-9B1E-B3896EB106EC@lichtzwerge.de>
Message-ID: <239c9cd9-94f4-5179-e53e-17c1542fd0f4@nyu.edu>

Thanks for getting back to me.

(I think you mean `git clean -x -f -d`): I usually omit -x but I'll give 
it a go and report back.

Before I got the issue on a clean checkout I thought it was something I 
did to the build files.

I also tried building the latest release of libffi (v3.2.1) and using it 
in configure with --with-ffi-includes and --with-ffi-libraries but got 
the same error.


On 10/09/2017 02:40 AM, Moritz Angermann wrote:
> Yes, this commit indeed introduced the need for makeinfo, however after some debugging and improved packaging of the external libffi library, this dependency was removed again, and should not be required with the latest head anymore.
>
> Then again this should not result in link issues but rather in build time issues.
>
> The key to libffi is the libffi-tarballs git submodule, which contains the packaged libffi-tarballs. Make sure all your submodules are also updated.
>
> I usually use `git -x -f -d` (read the documentation first) to ensure a clean working tree. Especially as you say you can’t reproduce it on other machines, maybe there is a file in your tree that the cleaning did not catch?
>
> Sent from my iPhone
>
>> On 9 Oct 2017, at 4:31 AM, Thomas Jakway <tjakway at nyu.edu> wrote:
>>
>> I'm on Ubuntu 16.10.
>>
>> I ran git bisect:
>>
>> ----------------------
>>
>> e515c7f37be97e1c2ccc497ddd0a730e63ddfa82 is the first bad commit
>> commit e515c7f37be97e1c2ccc497ddd0a730e63ddfa82
>> Author: Moritz Angermann <moritz.angermann at gmail.com>
>> Date:   Sat Sep 30 09:31:12 2017 -0400
>>
>> Allow libffi snapshots
>>
>> This is rather annoying. I'd prefer to have a stable release to
>> use. However libffi-3.2.1 has been released November 12, 2014, and
>> libffi-4 is TBD. See also https://github.com/libffi/libffi/issues/296
>>
>> The core reason for this change is that llvm changed the supported
>> assembly to unified syntax, which libffi-3.2.1 does not use, and hence
>> fails to compile for arm with llvm. For refence, see the following
>> issue: https://github.com/libffi/libffi/issues/191.
>>
>> This diff contains a script to generate a tarball for the
>> `libffi-tarballs` repository from the libffi GitHub repository; as well
>> as the necessary changes to the build system.
>>
>> Updates libffi-tarballs submodule.
>>
>> Reviewers: austin, bgamari, hvr
>>
>> Subscribers: hvr, erikd, rwbarton, thomie
>>
>> Differential Revision: https://phabricator.haskell.org/D3574
>>
>> ----------------------
>>
>> I can't reproduce it on my other linux computers though.
>>
>>
>>> On 10/04/2017 02:17 PM, Ben Gamari wrote:
>>> Thomas Jakway <tjakway at nyu.edu> writes:
>>>
>>>> Anyone else getting linker errors?
>>>>
>>>> This is after running
>>>>
>>>> make clean && make distclean && find . -name "*.o" -type f -delete &&
>>>> find . -name "*.hi" -type f -delete
>>>>
>>>> then
>>>>
>>>> ./boot && ./configure && make -j5
>>>>
>>>> (ghc-new is not a new checkout, this error is happening on a branch I'm
>>>> working on, but one that doesn't touch the FFI)
>>>>
>>> I'm afraid I can't reproduce this. What platform/operating system is
>>> this on?
>>>
>>> Cheers,
>>>
>>> - Ben
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From simonpj at microsoft.com  Tue Oct 10 22:09:18 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 10 Oct 2017 22:09:18 +0000
Subject: More windows
In-Reply-To: <AM4PR83MB00336B5A5BD670551F54F59BAD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
References: <AM4PR83MB0033115CEDF01DB5AF3CC0E8AD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CABHktDXQHijJbxur2LdksQmLxMHQD72Pp69Ubig++++48fgvWg@mail.gmail.com>
 <AM4PR83MB00336B5A5BD670551F54F59BAD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
Message-ID: <AM4PR83MB0033A9427C6E6088D707878DAD750@AM4PR83MB0033.EURPRD83.prod.outlook.com>

Any ideas anyone?   When I restart the build, it gets past the blockage (which seems highly specific).  But it’s jolly annoying.

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Simon Peyton Jones via ghc-devs
Sent: 04 October 2017 17:25
To: Phyx <lonetiger at gmail.com>; ghc-devs at haskell.org
Subject: RE: More windows

As you’ll see the directory is empty when the crash happens.  And yes the folder is excluded (from virus checking).

Also this behaviour is new.

Simon

From: Phyx [mailto:lonetiger at gmail.com]
Sent: 04 October 2017 14:17
To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>; ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Re: More windows


This looks like a file lock issue. Just to double check, but do you have the build folder excluded from the antivirus scanner?

On Wed, Oct 4, 2017, 13:57 Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>> wrote:
Now in my Windows build, staring with “sh validate –fast –no-clean” I get

[230 of 232] Compiling Distribution.PackageDescription.Parsec ( libraries\Cabal\Cabal\Distribution\PackageDescription\Parsec.hs, bootstrapping\Distribution\PackageDescription\Parsec.o )

[231 of 232] Compiling Distribution.Simple ( libraries\Cabal\Cabal\Distribution\Simple.hs, bootstrapping\Distribution\Simple.o )

[232 of 232] Compiling Main             ( utils\ghc-cabal\Main.hs, bootstrapping\Main.o )

Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

utils/genprimopcode/ghc.mk:19<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A19&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=RBB0ZLl%2FEYwO7EfcTXr%2FKugBfnr1ecN%2Febs0rAKu1VE%3D&reserved=0>: utils/genprimopcode/dist/package-data.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpackage-data.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=QeEhyXBxi5n%2FhisTO6hX309ZFk47ek5NtGVDBNKbWLY%3D&reserved=0>: No such file or directory

make[1]: *** [utils/ghc-cabal/ghc.mk:57<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A57&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=8qZlM0TvQvcySuregiRG5Ip%2FOR%2BVDAM6Dad1hUNEB%2FQ%3D&reserved=0>: utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1

make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'

make: *** [Makefile:123: all] Error 2

Simply repeating, thus “sh validate –fast”, I then get the same error

/c/code/HEAD$ ls -l utils/ghc-cabal/dist/build/tmp/

total 0

/c/code/HEAD$ sh validate --fast --no-clean

using THREADS=5

make: Entering directory '/c/code/HEAD/utils/checkUniques'

./check-uniques.py ../..

make: Leaving directory '/c/code/HEAD/utils/checkUniques'

===--- building phase 0

make --no-print-directory -f ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=npxwtvhNnwLposvw%2B3k6rdhcQHEW7erd10hWCi5bvjg%3D&reserved=0> phase=0 phase_0_builds

"c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \

       -optc-Wall -optc-Werror -optc-fno-stack-protector \

        \

       -hide-all-packages \

       -package ghc-prim -package base -package array -package transformers -package time -package containers -package bytestring -package deepseq -package process -package pretty -package directory -package Win32 \

       --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \

       -no-user-package-db \

       -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \

       -DCABAL_VERSION=2,0,0,2 \

       -DCABAL_PARSEC \

       -DBOOTSTRAPPING \

       -odir  bootstrapping \

       -hidir bootstrapping \

       bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \

       -ilibraries/Cabal/Cabal \

       -ilibraries/binary/src \

       -ilibraries/filepath \

       -ilibraries/hpc \

       -ilibraries/mtl \

       -ilibraries/text \

       libraries/text/cbits/cbits.c \

       -Ilibraries/text/include \

       -ilibraries/parsec \

        \



Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

Unable to open utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

make[1]: *** [utils/ghc-cabal/ghc.mk:57<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk%3A57&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=8qZlM0TvQvcySuregiRG5Ip%2FOR%2BVDAM6Dad1hUNEB%2FQ%3D&reserved=0>: utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe] Error 1

make[1]: *** Deleting file 'utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe'

make: *** [Makefile:123: all] Error 2

But trying “sh validate –fast” once more succeeds:

/c/code/HEAD$ sh validate --fast --no-clean

using THREADS=5

make: Entering directory '/c/code/HEAD/utils/checkUniques'

./check-uniques.py ../..

make: Leaving directory '/c/code/HEAD/utils/checkUniques'

===--- building phase 0

make --no-print-directory -f ghc.mk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.mk&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=npxwtvhNnwLposvw%2B3k6rdhcQHEW7erd10hWCi5bvjg%3D&reserved=0> phase=0 phase_0_builds

"c:/fp/ghc-8.0.2/bin/ghc.exe" -O0 -H64m -Wall \

       -optc-Wall -optc-Werror -optc-fno-stack-protector \

        \

       -hide-all-packages \

       -package ghc-prim -package base -package array -package transformers -package time -package containers -package bytestring -package deepseq -package process -package pretty -package directory -package Win32 \

       --make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe \

       -no-user-package-db \

       -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \

       -DCABAL_VERSION=2,0,0,2 \

       -DCABAL_PARSEC \

       -DBOOTSTRAPPING \

       -odir  bootstrapping \

       -hidir bootstrapping \

       bootstrapping/Cabal/Distribution/Parsec/Lexer.hs \

       -ilibraries/Cabal/Cabal \

       -ilibraries/binary/src \

       -ilibraries/filepath \

       -ilibraries/hpc \

       -ilibraries/mtl \

       -ilibraries/text \

       libraries/text/cbits/cbits.c \

       -Ilibraries/text/include \

       -ilibraries/parsec \

        \



Linking utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe ...

"inplace/lib/bin/touchy.exe" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe

"cp" utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe inplace/bin/ghc-cabal.exe

"inplace/bin/ghc-cabal.exe" configure libraries/binary dist-boot --with-ghc="c:/fp/ghc-8.0.2/bin/ghc.exe" --with-ghc-pkg="c:/fp/ghc-8.0.2/bin/ghc-pkg"  --package-db=C:/code/HEAD/libraries/bootstrapping.conf --disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci --disable-library-profiling --disable-shared --with-hscolour="/c/fp/HP-8.0.1/lib/extralibs/bin/HsColour" --configure-option=CFLAGS="-Wall -fno-stack-protector    -Wno-error=inline" --configure-option=LDFLAGS="  " --configure-option=CPPFLAGS="   " --gcc-options="-Wall -fno-stack-protector    -Wno-error=inline   "   --constraint "binary == 0.8.5.1"   --constraint "text == 1.2.3.0"   --constraint "transformers == 0.5.4.0"   --constraint "mtl == 2.2.2"   --constraint "parsec == 3.1.12"   --constraint "Cabal == 2.0.0.2"   --constraint "hpc == 0.6.0.3"   --constraint "ghc-boot-th == 8.3"   --constraint "ghc-boot == 8.3"   --constraint "template-haskell == 2.13.0.0"   --constraint "ghci == 8.3" --with-gcc="C:/fp/ghc-8.0.2/lib/../mingw/bin/gcc.exe" --with-ld="C:/fp/ghc-8.0.2/lib/../mingw/bin/ld.exe" --with-ar="C:/fp/ghc-8.0.2/lib/../mingw/bin/ar.exe" --with-alex="/c/fp/HP-8.0.1/lib/extralibs/bin/alex" --with-happy="/c/fp/HP-8.0.1/lib/extralibs/bin/happy"
…etc etc

I’m stumped.

Simon
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7C8b77247501d641a1542908d50b2a3dc8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427198412189281&sdata=HPj0gcQlqItY7XC0CON1Fv5clpmEINCnYSqLHgsr06U%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171010/a44da774/attachment-0001.html>

From chak at justtesting.org  Wed Oct 11 00:37:47 2017
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Wed, 11 Oct 2017 11:37:47 +1100
Subject: Call for features for GHC 8.4
In-Reply-To: <87efqcnvpu.fsf@ben-laptop.smart-cactus.org>
References: <87efqcnvpu.fsf@ben-laptop.smart-cactus.org>
Message-ID: <96FB1C56-3111-4EBD-8FD8-0CDD58FFEDF7@justtesting.org>

Just as a general note, with the push towards regular releases at 6 month intervals whose final release doesn’t drag out 2-3 month after the expected release date, I think, having few items on the status page is a Good Thing. So, let’s not cram too much in, as Ben wrote, 8.6 will not be that much further of.

Cheers,
Manuel

> Ben Gamari <ben at well-typed.com>:
> 
> Hello everyone,
> 
> The release of GHC 8.4 is quickly approaching, with a release targetted
> for February 2018. To allow plenty of time for stabilization, we would
> like to cut the ghc-8.4 branch sometime in November. Currently there are
> relatively few items on the 8.4 status page [1]. If you have a feature
> which you would like to see in 8.4 but is not listed there please do
> add it soon.
> 
> Also note that if things go according to plan, 8.6 will come a mere six
> months after 8.4 so if you have a large feature which won't make it for
> 8.4, do not fret; another release will be just around the corner.
> 
> Cheers,
> 
> - Ben
> 
> 
> [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.4.1
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From simonpj at microsoft.com  Wed Oct 11 08:21:32 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 11 Oct 2017 08:21:32 +0000
Subject: Invariants about UnivCo?
In-Reply-To: <CADfHYo57DAZ_jXdCx=bSQCeJ-a3A+9MOK9mhQsz9bif8x4ZYrQ@mail.gmail.com>
References: <CADfHYo7k_m2XP4RkH24rGkq-cKT2Vqm03sk1pC9PF3mpQrEObQ@mail.gmail.com>
 <HE1PR83MB004261F48AD1973CF3E55529AD660@HE1PR83MB0042.EURPRD83.prod.outlook.com>
 <CADfHYo60Szute917RteC-DZTu+Lj4_iJitU1ams4c_e--YnXWw@mail.gmail.com>
 <53074143-DCCC-4C03-B176-47278AA41E79@cs.brynmawr.edu>
 <CADfHYo57DAZ_jXdCx=bSQCeJ-a3A+9MOK9mhQsz9bif8x4ZYrQ@mail.gmail.com>
Message-ID: <AM4PR83MB00336166F3EB12473B31F6FFAD4A0@AM4PR83MB0033.EURPRD83.prod.outlook.com>

3) I confirmed that the lack of cobox uniques in the dump output was indeed due to `ppr_co' deferring to `ppr @IfaceType'; it does that (at least) for every coercion with a head of `TyConAppCo'. With a tiny kludgy patch I was able to persist those uniques just for debugging purposes.

Would you like to offer a patch?

I eventually gave up on the via-iface-type route for debug printing.  See TyCoRep.pprPrecType, which checks for debugStyle and if so calls a simple but direct debug_ppr_ty.  Not beautiful, but very direct.  For debugging it’s terrible if tidying and other stuff goes on.

Maybe we want the same for coercions?

Simon

From: Nicolas Frisby [mailto:nicolas.frisby at gmail.com]
Sent: 09 October 2017 03:50
To: Richard Eisenberg <rae at cs.brynmawr.edu>
Cc: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs at haskell.org
Subject: Re: Invariants about UnivCo?


Yep, that's the current question: why does preferring `EvCoercion (TransCo UnivCo (TransCo co UnivCo))` to `EvCast (EvCoercion co) UnivCo` seem to matter? In my scenario, `co` is the evidence for a Given equality type. And the coercion I'm building is also a Given constraint's evidence -- I'm simplifying Givens.

The only hard indication I currently have of what "goes wrong" is the ASSERT failure described in the previous email.

I'm planning to spend some time investigating. I would appreciate any cycles you spend on it!

On Sun, Oct 8, 2017, 18:53 Richard Eisenberg <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>> wrote:
Thanks for this status report. If I'm to boil it down to the question you seem to be asking: What does changing EvCast ... to EvCoercion ... fix the problem? I'm not sure of the answer at this point, but I want to make sure I understand the question before I go digging for an answer. It's always possible a Note is wrong!

Thanks for this!

Richard

On Oct 7, 2017, at 8:19 PM, Nicolas Frisby <nicolas.frisby at gmail.com<mailto:nicolas.frisby at gmail.com>> wrote:

I can happily report some progress: I'm seeing no more Core lint errors!

1) Thank you both Richard and Simon for your pointers -- -fprint-typechecker-elaboration in particular was a revelation.

2) Simon, I intend to match the spirit of the favor you requested, but not to the letter. My goal with this project is to write a typechecker plugin for achieving row types _without_ editing GHC's source code. I'm keeping an annotated bibliography of things I've studied (papers, guide/wiki/blog, source Notes, etc). (It's nice to put a bunch of related notes in the same text file!) I'm also logging my epiphanies, which I do intend to write-up in some kind of document (probably on the dev wiki). I'm planning a section for suggesting which Notes should be adjusted/expanded, but I don't anticipate feeling comfortable enough to actually edit the Notes myself. This is unfortunately just a hobby project. My intent is to offer you, Richard, and other experts the details of what wasn't clear to me.

3) I confirmed that the lack of cobox uniques in the dump output was indeed due to `ppr_co' deferring to `ppr @IfaceType'; it does that (at least) for every coercion with a head of `TyConAppCo'. With a tiny kludgy patch I was able to persist those uniques just for debugging purposes.

4) My top-level error is an "out of scope cobox" Lint error, but (once I patched the dumper) the output of -fprint-typechecker-elaboration showed sufficient bindings for all of the cobox occurrences, even the one that the Lint error was flagging! Stymied, I finally did a -DDEBUG build of the ghc-8.2.2-rc1 tag and used that. It ultimately lead to me finding my mistakes. (New wisdom: always use a DEBUG build when authoring a plugin. (... Duh.))

4a) ASSERT failures showed that I was invoking `substTy' without correctly initializing the `InScopeSet'. I also was ignorant that I should be using `extendTvSubstAndInScope' instead of just `extendTvSubst'. I don't think this was relevant to my particular Lint error, but I fixed it if only to see further ASSERT failures.

4b) Fixing my `InScopeSet's ASSERT failure revealed another: `extendIdSubst' was being called with a CoVar! That's something that my plugin code absolutely does not do, so at that point I knew that some higher-level operation I was doing was knocking the rest of GHC's pipeline off the rails. (In particular, I traced this ASSERT callstack to extendIdSubst called from simpleOptExpr called from mkInlineUnfoldingWithArity called from DsBinds. I stopped there.)

5) The first suspect turned out to be the culprit: I was using my plugin's by-fiat coercions in the most naive possible way, always simply `EvCast ev (fiatCoercion ty0 ty1)`. In particular, I was even doing that to create new Given unlifted equality witnesses from existing Given unlifted equality witnesses when simplifying Given constraints (e.g. for example reducing a plugin-specific type family application on one side of an unlifted equality type ~#).

In summary, I see no more ASSERT failures or Lint errors having now changed my plugin to prefer `EvCoercion (TransCo U (TransCo co U))` to `EvCast (EvCoercion co) U`. The actual diff excerpt is here: https://github.com/nfrisby/coxswain/issues/3#issuecomment-334972227<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfrisby%2Fcoxswain%2Fissues%2F3%23issuecomment-334972227&data=02%7C01%7Csimonpj%40microsoft.com%7C2b0edffd514b4da49abc08d50ec07ff9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636431142301735979&sdata=Ng6o4ODbLXNJVlngL0qnBv1EQ5Sn9TJMPK79M99zGTg%3D&reserved=0>

I have not figured out exactly why that change matters, but it does seem a reasonable preference to require. In particular, Note [Coercion evidence terms] in TcEvidence.hs explicitly says that `EvCast (EvCoercion co1) co2` is a valid form of evidence for ~#. So perhaps that Note deserves elaboration --- I'm guessing the missing part may be specific to Givens?

-Nick

On Thu, Sep 21, 2017 at 2:59 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Some thoughts


  *   Read Note [Coercion holes] in TyCoRep.



  *   As you’ll see, generally we don’t create value-bindings for (unboxed) coercions of type t1 ~# t2.  (yes for boxed ones t1 ~ t2).     Reasons in the Note.  Exception: for superclasses of Givens we do create    (co :: a ~# b) = sc_sel1 d

where d is some dictionary with a superclass of type (a ~# b).

Side note: the use of “cobox” is wildly unhelpful.  These Ids are specifically unboxed!  I’m going to change it to just “co”.


  *   You appear to have bindings like[G]  cobox_a67J = CO Sym cobox_a654.  That is suspicious.  Who is creating them?  It may not actually be wrong but it’s suspicious.  The time it’d be outright wrong is if you dropped the ev-binds on the floor.

Ha!  runTcSEqualites makes up an ev_binds_var, and solves the equalities – but it should be the case that no value bindings end up in the ev_binds_var.  (reason: we are solving equalities in a type signature, so there is no place to put the evidence bindigns)   I suggest you add a DEBUG-only assertion to check this.


  *   Do -ddump-tc -fprint-typechecker-elaboration; that should show you the evidence binds.

Can I ask you a favour?  Separately from your branch, can you start a branch of small patches to GHC that include

  *   Extra assertions, such as that above
  *   Notes that explain things you wish you’d known earlier, with references to those Notes from the places you were studying when you that information would have been useful

Richard and I know too much! – your learning curve is very valuable and I don’t want to lose it.

Keeping this separate from your branch is useful : you can commit (via Phab) these updates right away, so they aren’t predicated on adding row types to GHC.

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>] On Behalf Of Nicolas Frisby
Sent: 19 September 2017 16:51
To: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Invariants about UnivCo?

[I summarize with some direct questions at the bottom of this email.]

I spent time last night trying to eliminate -dcore-lint errors from my record and variant library using the coxswain row types plugin. I made some progress, but I'm currently stuck, as discussed on this github Issue.

https://github.com/nfrisby/coxswain/issues/3#issuecomment-330577609<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfrisby%2Fcoxswain%2Fissues%2F3%23issuecomment-330577609&data=02%7C01%7Csimonpj%40microsoft.com%7Cde0675bbb584495a2f8008d4ff764c72%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636414330952932223&sdata=lPLcpIlb%2BhivQdCUoVOPUgYDHeEDaMX660NQS%2BQyyBw%3D&reserved=0>

Here's the relevant bit:

The latest unresolved -dcore-lint error is an out-of-scope cobox co var. I'm certainly not creating it directly (there are no U(plugin:coxswain,... in the Core Lint warning), but I have to wonder if my somewhat loose use of UnivCo is violating some assumptions somewhere that's causing GHC to drop the co var binding or overlook this occurrence of it on a renaming/subst pass. I checked UnivCo for source comments looking for anything it should not be used for, but I didn't find an obvious explanation along those lines.

I haven't yet been able to effectively distill the test case.

I'm doing this all at -O0.

With `-ddump-tc-trace`, I can see the offending cobox (cobox_a67M) is present in an "implication evbinds" listing after a "solveImplication end }" delimiter, but that's the last obvious binding of it.

                         [G] cobox_a67J = CO Sym cobox_a654,
                         [G] cobox_a67M
                           = cobox_a67J `cast` U(plugin:coxswain,...)

cobox_a654 is introduced by a GADT pattern match.

I'm also not seeing obvious occurrences of cobox_a67M, but I think the reason is that I'm seeing several (Sym cobox) with no uniques printed (even with `-dppr-debug`). Those are probably the cobox in question, but I can't confirm.

Questions:

1) Is there a robust way to ensure that covar's uniques are always printed? (Is the pprIface reuse  with a free cobox part of the issue here?)

2) Is my plugin asking for this kind of trouble by using UnivCo to cast coboxes?

3) If I spent the effort to create non-UnivCo coercions where possible, would that likely help? This is currently an "eventually" task, but I haven't seen an urgency for it yet. I could bump its priority if it might help. E.G. I'm using UnivCo to cast entire givens when all I'm doing is reducing a type family application somewhere "deep" within the given's predtype. I could, with considerable effort, instead wrap a single, localized UnivCo within a bunch of non-UnivCo "lifting" coercion constructors. Would that likely help?

3) Is there a usual suspect for this kind of situation where a cobox binding is seemingly dropped (by the typechecker) even though there's an occurrence of it?

Thank you for your time. -Nick
_______________________________________________

ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7C2b0edffd514b4da49abc08d50ec07ff9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636431142301735979&sdata=cwFHlK9YaeaZqNxGvRuHRDeMKMCs0NsDi3lq5UZDZ1g%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171011/bbdfcbea/attachment-0001.html>

From simonpj at microsoft.com  Wed Oct 11 08:23:19 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 11 Oct 2017 08:23:19 +0000
Subject: Invariants about UnivCo?
In-Reply-To: <CADfHYo57DAZ_jXdCx=bSQCeJ-a3A+9MOK9mhQsz9bif8x4ZYrQ@mail.gmail.com>
References: <CADfHYo7k_m2XP4RkH24rGkq-cKT2Vqm03sk1pC9PF3mpQrEObQ@mail.gmail.com>
 <HE1PR83MB004261F48AD1973CF3E55529AD660@HE1PR83MB0042.EURPRD83.prod.outlook.com>
 <CADfHYo60Szute917RteC-DZTu+Lj4_iJitU1ams4c_e--YnXWw@mail.gmail.com>
 <53074143-DCCC-4C03-B176-47278AA41E79@cs.brynmawr.edu>
 <CADfHYo57DAZ_jXdCx=bSQCeJ-a3A+9MOK9mhQsz9bif8x4ZYrQ@mail.gmail.com>
Message-ID: <AM4PR83MB00334DBC134312AFF40FE058AD4A0@AM4PR83MB0033.EURPRD83.prod.outlook.com>

5) The first suspect turned out to be the culprit: I was using my plugin's by-fiat coercions in the most naive possible way, always simply `EvCast ev (fiatCoercion ty0 ty1)`. In particular, I was even doing that to create new Given unlifted equality witnesses from existing Given unlifted equality witnesses when simplifying Given constraints (e.g. for example reducing a plugin-specific type family application on one side of an unlifted equality type ~#).

I don’t understand the issue here at all. Can you give a concrete example?

Simon
From: Nicolas Frisby [mailto:nicolas.frisby at gmail.com]
Sent: 09 October 2017 03:50
To: Richard Eisenberg <rae at cs.brynmawr.edu>
Cc: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs at haskell.org
Subject: Re: Invariants about UnivCo?


Yep, that's the current question: why does preferring `EvCoercion (TransCo UnivCo (TransCo co UnivCo))` to `EvCast (EvCoercion co) UnivCo` seem to matter? In my scenario, `co` is the evidence for a Given equality type. And the coercion I'm building is also a Given constraint's evidence -- I'm simplifying Givens.

The only hard indication I currently have of what "goes wrong" is the ASSERT failure described in the previous email.

I'm planning to spend some time investigating. I would appreciate any cycles you spend on it!

On Sun, Oct 8, 2017, 18:53 Richard Eisenberg <rae at cs.brynmawr.edu<mailto:rae at cs.brynmawr.edu>> wrote:
Thanks for this status report. If I'm to boil it down to the question you seem to be asking: What does changing EvCast ... to EvCoercion ... fix the problem? I'm not sure of the answer at this point, but I want to make sure I understand the question before I go digging for an answer. It's always possible a Note is wrong!

Thanks for this!

Richard

On Oct 7, 2017, at 8:19 PM, Nicolas Frisby <nicolas.frisby at gmail.com<mailto:nicolas.frisby at gmail.com>> wrote:

I can happily report some progress: I'm seeing no more Core lint errors!

1) Thank you both Richard and Simon for your pointers -- -fprint-typechecker-elaboration in particular was a revelation.

2) Simon, I intend to match the spirit of the favor you requested, but not to the letter. My goal with this project is to write a typechecker plugin for achieving row types _without_ editing GHC's source code. I'm keeping an annotated bibliography of things I've studied (papers, guide/wiki/blog, source Notes, etc). (It's nice to put a bunch of related notes in the same text file!) I'm also logging my epiphanies, which I do intend to write-up in some kind of document (probably on the dev wiki). I'm planning a section for suggesting which Notes should be adjusted/expanded, but I don't anticipate feeling comfortable enough to actually edit the Notes myself. This is unfortunately just a hobby project. My intent is to offer you, Richard, and other experts the details of what wasn't clear to me.

3) I confirmed that the lack of cobox uniques in the dump output was indeed due to `ppr_co' deferring to `ppr @IfaceType'; it does that (at least) for every coercion with a head of `TyConAppCo'. With a tiny kludgy patch I was able to persist those uniques just for debugging purposes.

4) My top-level error is an "out of scope cobox" Lint error, but (once I patched the dumper) the output of -fprint-typechecker-elaboration showed sufficient bindings for all of the cobox occurrences, even the one that the Lint error was flagging! Stymied, I finally did a -DDEBUG build of the ghc-8.2.2-rc1 tag and used that. It ultimately lead to me finding my mistakes. (New wisdom: always use a DEBUG build when authoring a plugin. (... Duh.))

4a) ASSERT failures showed that I was invoking `substTy' without correctly initializing the `InScopeSet'. I also was ignorant that I should be using `extendTvSubstAndInScope' instead of just `extendTvSubst'. I don't think this was relevant to my particular Lint error, but I fixed it if only to see further ASSERT failures.

4b) Fixing my `InScopeSet's ASSERT failure revealed another: `extendIdSubst' was being called with a CoVar! That's something that my plugin code absolutely does not do, so at that point I knew that some higher-level operation I was doing was knocking the rest of GHC's pipeline off the rails. (In particular, I traced this ASSERT callstack to extendIdSubst called from simpleOptExpr called from mkInlineUnfoldingWithArity called from DsBinds. I stopped there.)

5) The first suspect turned out to be the culprit: I was using my plugin's by-fiat coercions in the most naive possible way, always simply `EvCast ev (fiatCoercion ty0 ty1)`. In particular, I was even doing that to create new Given unlifted equality witnesses from existing Given unlifted equality witnesses when simplifying Given constraints (e.g. for example reducing a plugin-specific type family application on one side of an unlifted equality type ~#).

In summary, I see no more ASSERT failures or Lint errors having now changed my plugin to prefer `EvCoercion (TransCo U (TransCo co U))` to `EvCast (EvCoercion co) U`. The actual diff excerpt is here: https://github.com/nfrisby/coxswain/issues/3#issuecomment-334972227<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfrisby%2Fcoxswain%2Fissues%2F3%23issuecomment-334972227&data=02%7C01%7Csimonpj%40microsoft.com%7C2b0edffd514b4da49abc08d50ec07ff9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636431142301735979&sdata=Ng6o4ODbLXNJVlngL0qnBv1EQ5Sn9TJMPK79M99zGTg%3D&reserved=0>

I have not figured out exactly why that change matters, but it does seem a reasonable preference to require. In particular, Note [Coercion evidence terms] in TcEvidence.hs explicitly says that `EvCast (EvCoercion co1) co2` is a valid form of evidence for ~#. So perhaps that Note deserves elaboration --- I'm guessing the missing part may be specific to Givens?

-Nick

On Thu, Sep 21, 2017 at 2:59 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Some thoughts


  *   Read Note [Coercion holes] in TyCoRep.



  *   As you’ll see, generally we don’t create value-bindings for (unboxed) coercions of type t1 ~# t2.  (yes for boxed ones t1 ~ t2).     Reasons in the Note.  Exception: for superclasses of Givens we do create    (co :: a ~# b) = sc_sel1 d

where d is some dictionary with a superclass of type (a ~# b).

Side note: the use of “cobox” is wildly unhelpful.  These Ids are specifically unboxed!  I’m going to change it to just “co”.


  *   You appear to have bindings like[G]  cobox_a67J = CO Sym cobox_a654.  That is suspicious.  Who is creating them?  It may not actually be wrong but it’s suspicious.  The time it’d be outright wrong is if you dropped the ev-binds on the floor.

Ha!  runTcSEqualites makes up an ev_binds_var, and solves the equalities – but it should be the case that no value bindings end up in the ev_binds_var.  (reason: we are solving equalities in a type signature, so there is no place to put the evidence bindigns)   I suggest you add a DEBUG-only assertion to check this.


  *   Do -ddump-tc -fprint-typechecker-elaboration; that should show you the evidence binds.

Can I ask you a favour?  Separately from your branch, can you start a branch of small patches to GHC that include

  *   Extra assertions, such as that above
  *   Notes that explain things you wish you’d known earlier, with references to those Notes from the places you were studying when you that information would have been useful

Richard and I know too much! – your learning curve is very valuable and I don’t want to lose it.

Keeping this separate from your branch is useful : you can commit (via Phab) these updates right away, so they aren’t predicated on adding row types to GHC.

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>] On Behalf Of Nicolas Frisby
Sent: 19 September 2017 16:51
To: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Invariants about UnivCo?

[I summarize with some direct questions at the bottom of this email.]

I spent time last night trying to eliminate -dcore-lint errors from my record and variant library using the coxswain row types plugin. I made some progress, but I'm currently stuck, as discussed on this github Issue.

https://github.com/nfrisby/coxswain/issues/3#issuecomment-330577609<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnfrisby%2Fcoxswain%2Fissues%2F3%23issuecomment-330577609&data=02%7C01%7Csimonpj%40microsoft.com%7Cde0675bbb584495a2f8008d4ff764c72%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636414330952932223&sdata=lPLcpIlb%2BhivQdCUoVOPUgYDHeEDaMX660NQS%2BQyyBw%3D&reserved=0>

Here's the relevant bit:

The latest unresolved -dcore-lint error is an out-of-scope cobox co var. I'm certainly not creating it directly (there are no U(plugin:coxswain,... in the Core Lint warning), but I have to wonder if my somewhat loose use of UnivCo is violating some assumptions somewhere that's causing GHC to drop the co var binding or overlook this occurrence of it on a renaming/subst pass. I checked UnivCo for source comments looking for anything it should not be used for, but I didn't find an obvious explanation along those lines.

I haven't yet been able to effectively distill the test case.

I'm doing this all at -O0.

With `-ddump-tc-trace`, I can see the offending cobox (cobox_a67M) is present in an "implication evbinds" listing after a "solveImplication end }" delimiter, but that's the last obvious binding of it.

                         [G] cobox_a67J = CO Sym cobox_a654,
                         [G] cobox_a67M
                           = cobox_a67J `cast` U(plugin:coxswain,...)

cobox_a654 is introduced by a GADT pattern match.

I'm also not seeing obvious occurrences of cobox_a67M, but I think the reason is that I'm seeing several (Sym cobox) with no uniques printed (even with `-dppr-debug`). Those are probably the cobox in question, but I can't confirm.

Questions:

1) Is there a robust way to ensure that covar's uniques are always printed? (Is the pprIface reuse  with a free cobox part of the issue here?)

2) Is my plugin asking for this kind of trouble by using UnivCo to cast coboxes?

3) If I spent the effort to create non-UnivCo coercions where possible, would that likely help? This is currently an "eventually" task, but I haven't seen an urgency for it yet. I could bump its priority if it might help. E.G. I'm using UnivCo to cast entire givens when all I'm doing is reducing a type family application somewhere "deep" within the given's predtype. I could, with considerable effort, instead wrap a single, localized UnivCo within a bunch of non-UnivCo "lifting" coercion constructors. Would that likely help?

3) Is there a usual suspect for this kind of situation where a cobox binding is seemingly dropped (by the typechecker) even though there's an occurrence of it?

Thank you for your time. -Nick
_______________________________________________

ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7C2b0edffd514b4da49abc08d50ec07ff9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636431142301735979&sdata=cwFHlK9YaeaZqNxGvRuHRDeMKMCs0NsDi3lq5UZDZ1g%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171011/4d19a0db/attachment-0001.html>

From ben at well-typed.com  Wed Oct 11 13:10:36 2017
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 11 Oct 2017 09:10:36 -0400
Subject: More windows
In-Reply-To: <AM4PR83MB0033A9427C6E6088D707878DAD750@AM4PR83MB0033.EURPRD83.prod.outlook.com>
References: <AM4PR83MB0033115CEDF01DB5AF3CC0E8AD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CABHktDXQHijJbxur2LdksQmLxMHQD72Pp69Ubig++++48fgvWg@mail.gmail.com>
 <AM4PR83MB00336B5A5BD670551F54F59BAD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <AM4PR83MB0033A9427C6E6088D707878DAD750@AM4PR83MB0033.EURPRD83.prod.outlook.com>
Message-ID: <87po9tltir.fsf@ben-laptop.smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:

> Any ideas anyone? When I restart the build, it gets past the blockage
> (which seems highly specific). But it’s jolly annoying.
>
Hi Simon,

Perhaps let's try this,

 1. download and run the procmon tool from [1]
 2. from the "Filter" menu select the "Filter..." option
 3. select "Path" in the first drop-down
 4. select "contains" in the second drop-down
 5. enter "ghc-cabal.exe" in the third text box
 6. select "Include in the fourth drop-down
 8. click the "Add" button
 7. click the "Ok" button

Now you should be logging events pertaining to the file in question. Now
simply run `./validate` to try to reproduce the issue.

With luck this will produce a handful of events, some of which ought to
point to the process that it responsible for meddling with the GHC
build.

Now export this log,

 1. select "Save" from the "File" menu
 2. select the "Events displayed using current filter" option
 3. select the "CSV" format, select a path that will be easy to file
 4. return this file to me (perhaps via GitHub Gist [2]?)

Hopefully this will give us some insight into what is happening.

Cheers,

- Ben


[1] https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
[2] https://gist.github.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171011/b1cff808/attachment.sig>

From conal at conal.net  Thu Oct 12 18:07:01 2017
From: conal at conal.net (Conal Elliott)
Date: Thu, 12 Oct 2017 11:07:01 -0700
Subject: GHC rewrite rule type-checking failure
In-Reply-To: <AM4PR83MB00330DEA1ADBE69E8312EDB7AD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
References: <CAD6SzRKj2Kz044CkbXA2FAzAY0oRMftxvb-QeAZ8o0zCSW1WNg@mail.gmail.com>
 <1506984729.1122.11.camel@joachim-breitner.de>
 <CAD6SzRLUsAqCkcXWEZde-VptDyWtQtJrCrOOwdVwvLaBL619ww@mail.gmail.com>
 <AM4PR83MB0033AA97DAEE401F72650ADDAD720@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CAD6SzRLk08aWNqK+_5K=vAVj6Vi37bPQJWnS9yky8PPQ9gw4MQ@mail.gmail.com>
 <AM4PR83MB0033D000E03DBAE2A56FFF3FAD720@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CAD6SzRJj_J-RMzYa0bjG_5LmcxHSzXLo01NbJZWWaF5SH+JKxA@mail.gmail.com>
 <AM4PR83MB00330DEA1ADBE69E8312EDB7AD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
Message-ID: <CAD6SzR+i1KNTNyFO2q_z=7v=VPWi-EDzTSuamAmqHTGC9CerGA@mail.gmail.com>

Thanks for the helpful reply, Simon!

> > The new bit here is that `$dC'` is not found via matching in the LHS,
but
> > rather by instance resolution from `k`, which does appear explicitly in
> > the LHS

> Well this would be something qualitatively new. We don’t that ability in
> rules; and it’s far from clear to me what it would mean anyway. I suppose
> that if k was instantiated to a ground type then you might hope to solve
it,
> but what if it was instantiated to some in-scope type variable t, and some
> variable of type (C t) was in scope. Should that work too?

Yes, we'd want to use in-scope dictionary variables to help solve the needed
constraints in the presence of polymorphism. I've run into exactly this need
in my own manually programmed ("built-in") rewrite rules. Would it be
possible
to do so (without deep/pervasive changes to GHC)?

> Happily it sounds as if you are making progress with help from Joachim.

No, I think Joachim agrees that it's impractical to write all of the needed
rule specializations, and that generating then programmatically would be
less
convenient than the implementing the built-in rules as I do now.

Cheers, -- Conal

On Wed, Oct 4, 2017 at 2:08 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> The new bit here is that `$dC'` is not found via matching in the LHS, but
> rather by instance resolution from `k`, which does appear explicitly in the
> LHS
>
>
>
> Well this would be something qualitatively new.  We don’t that ability in
> rules; and it’s far from clear to me what it would mean anyway.  I suppose
> that if k was instantiated to a ground type then you might hope to solve
> it, but what if it was instantiated to some in-scope type variable t, and
> some variable of type (C t) was in scope.  Should that work too?
>
>
>
> I’m highly dubious.
>
>
>
> Happily it sounds as if you are making progress with help from Joachim.
>
>
>
> Simon
>
>
>
> *From:* conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] *On
> Behalf Of *Conal Elliott
> *Sent:* 03 October 2017 16:30
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Subject:* Re: GHC rewrite rule type-checking failure
>
>
>
>
>
> The revised example I gave earlier in the thread:
>
>
>
> ``` haskell
>
> class C k where comp' :: k b c -> k a b -> k a c
>
>
>
> instance C (->) where comp' = (.)
>
>
>
> -- Late-inlining version to enable rewriting.
>
> comp :: C k => k b c -> k a b -> k a c
>
> comp = comp'
>
> {-# INLINE [0] comp #-}
>
>
>
> morph :: (a -> b) -> k a b
>
> morph = error "morph: undefined"
>
>
>
> {-# RULES "morph/(.)" forall f g. morph (g `comp` f) = morph g `comp`
> morph f #-}
>
>
>
> -- • Could not deduce (C k) arising from a use of ‘comp’
>
> --   from the context: C (->)
>
> --     bound by the RULE "morph/(.)"
>
> ```
>
>
>
> A hypothetical generated Core rule (tweaked slightly from Joachim's note):
>
>
>
> ``` haskell
>
> forall (@ k) (@ b) (@ c) (@ a)
>
>        ($dC :: C (->))
>
>        (f :: a -> b) (g :: b -> c).
>
>   morph @ k @ a @ c (comp @ (->) @ b @ c @ a $dC g f)
>
>   = comp @ k @ b @ c @ a
>
>       $dC'
>
>       (morph @ k @ b @ c g)
>
>       (morph @ k @ a @ b f)
>
>  where
>
>    $dC' :: C k
>
> ```
>
>
>
> The new bit here is that `$dC'` is not found via matching in the LHS, but
> rather by instance resolution from `k`, which does appear explicitly in the
> LHS. If `C k` cannot be solved, the rule fails. The "where" clause here
> lists the dictionary variables to be instantiated by instance resolution
> rather than matching.
>
>
>
> -- Conal
>
>
>
>
>
> On Tue, Oct 3, 2017 at 8:01 AM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> But synthesising from what?
>
>
>
> And currently no: there is no type-class dictionary synthesis after the
> type checker.  Not impossible I suppose, but one more fragility: a rule
> does not fire because some synthesis thing didn’t happen.    Maybe give an
> as-simple-as-poss example of what you have in mind, now you understand the
> situation better?   With all the type and dictionary abstractions written
> explicitly…
>
>
>
> S
>
>
>
> *From:* conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] *On
> Behalf Of *Conal Elliott
> *Sent:* 03 October 2017 15:56
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>
>
> *Subject:* Re: GHC rewrite rule type-checking failure
>
>
>
> Thanks, Simon. Your explanation make sense to me. Do you think that the
> rewrite rule mechanism could be enhanced to try synthesizing the needed
> dictionaries after LHS matching and before RHS instantiation? I'm doing as
> much now in my compiling-to-categories plugin, but without the convenience
> of using concrete syntax for the rules.
>
>
>
> Regard, - Conal
>
>
>
>
>
> On Tue, Oct 3, 2017 at 12:27 AM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> *   Is it feasible for GHC to combine the constraints needed LHS and RHS
> to form an applicability condition?
>
> I don’t think so.
>
>
>
> Remember that a rewrite rule literally rewrites LHS to RHS.  It does not
> conjure up any new dictionaries out of thin air.  In your example, (D k b)
> is needed in the result of the rewrite.  Where can it come from?  Only from
> something matched on the left.
>
>
>
> So GHC treats any dictionaries matched on the left as “givens” and tries
> to solve the ones matched on the left.  If it fails you get the sort of
> error you see.
>
>
>
> One way to see this is to write out the rewrite rule you want, complete
> with all its dictionary arguments. Can you do that?
>
>
>
> Simon
>
>
>
> *From:* Glasgow-haskell-users [mailto:glasgow-haskell-users-
> bounces at haskell.org] *On Behalf Of *Conal Elliott
> *Sent:* 03 October 2017 01:03
> *To:* Joachim Breitner <mail at joachim-breitner.de>
> *Cc:* glasgow-haskell-users at haskell.org
> *Subject:* Re: GHC rewrite rule type-checking failure
>
>
>
> Thanks very much for the reply, Joachim.
>
>
>
> Oops! I flubbed the example. I really `morph` to distribute over an
> application of `comp`. New code below (and attached). You're right that I
> wouldn't want to restrict the type of `morph`, since each `morph` *rule*
> imposes its own restrictions.
>
>
>
> My questions:
>
>
>
> *   Is it feasible for GHC to combine the constraints needed LHS and RHS
> to form an applicability condition?
>
> *   Is there any way I can make the needed constraints explicit in my
> rewrite rules?
>
> *   Are there any other work-arounds that would enable writing such
> RHS-constrained rules?
>
>
>
> Regards, -- Conal
>
>
>
> ``` haskell
>
> {-# OPTIONS_GHC -Wall #-}
>
> -- Demonstrate a type checking failure with rewrite rules
>
>
>
> module RuleFail where
>
>
>
> class C k where comp' :: k b c -> k a b -> k a c
>
>
>
> instance C (->) where comp' = (.)
>
>
>
> -- Late-inlining version to enable rewriting.
>
> comp :: C k => k b c -> k a b -> k a c
>
> comp = comp'
>
> {-# INLINE [0] comp #-}
>
>
>
> morph :: (a -> b) -> k a b
>
> morph = error "morph: undefined"
>
>
>
> {-# RULES "morph/(.)" forall f g. morph (g `comp` f) = morph g `comp`
> morph f #-}
>
>
>
> -- • Could not deduce (C k) arising from a use of ‘comp’
>
> --   from the context: C (->)
>
> --     bound by the RULE "morph/(.)"
>
> ```
>
>
>
>
>
> On Mon, Oct 2, 2017 at 3:52 PM, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
> Hi Conal,
>
> The difference is that the LHS of the first rule is mentions the `C k`
> constraint (probably unintentionally):
>
> *RuleFail> :t morph comp
> morph comp :: C k => k1 (k b c) (k a b -> k a c)
>
> but the LHS of the second rule side does not:
>
> *RuleFail> :t morph addC
> morph addC :: Num b => k (b, b) b
>
>
>
> A work-around is to add the constraint to `morph`:
>
>     morph :: D k b => (a -> b) -> k a b
>     morph = error "morph: undefined"
>
>     but I fear that this work-around is not acceptable to you.
>
>     Joachim
>
>     Am Montag, den 02.10.2017, 14:25 -0700 schrieb Conal Elliott:
>     > -- Demonstrate a type checking failure with rewrite rules
> >
> > module RuleFail where
> >
> > class C k where comp' :: k b c -> k a b -> k a c
> >
> > instance C (->) where comp' = (.)
> >
> > -- Late-inlining version to enable rewriting.
> > comp :: C k => k b c -> k a b -> k a c
> > comp = comp'
> > {-# INLINE [0] comp #-}
> >
> > morph :: (a -> b) -> k a b
> > morph = error "morph: undefined"
> >
> > {-# RULES "morph/(.)" morph comp = comp #-}  -- Fine
>
>
>
> > class D k a where addC' :: k (a,a) a
> >
> > instance Num a => D (->) a where addC' = uncurry (+)
> >
> > -- Late-inlining version to enable rewriting.
> > addC :: D k a => k (a,a) a
> > addC = addC'
> > {-# INLINE [0] addC #-}
> >
> > {-# RULES "morph/addC" morph addC = addC #-}  -- Fail
> >
> > -- • Could not deduce (D k b) arising from a use of ‘addC’
> > --   from the context: D (->) b
> >
> > -- Why does GHC infer the (C k) constraint for the first rule but not (D
> k b)
> > -- for the second rule?
> >
> > _______________________________________________
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users&data=02%7C01%7Csimonpj%40microsoft.com%7C3da5c75572694bab31aa08d509f25936%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636425858847457302&sdata=6dcqjyAYmKXKwZzQQExmWl1cJlCySmP1EvdjA03O19M%3D&reserved=0>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C3da5c75572694bab31aa08d509f25936%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636425858847457302&sdata=Uoe%2Bw8T3VMFLRsFY%2B8nacXIV0pUQOyCe4iHz%2FS5kGrA%3D&reserved=0>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171012/53e78477/attachment-0001.html>

From conal at conal.net  Thu Oct 12 19:02:16 2017
From: conal at conal.net (Conal Elliott)
Date: Thu, 12 Oct 2017 12:02:16 -0700
Subject: GHC rewrite rule type-checking failure
In-Reply-To: <CAD6SzR+i1KNTNyFO2q_z=7v=VPWi-EDzTSuamAmqHTGC9CerGA@mail.gmail.com>
References: <CAD6SzRKj2Kz044CkbXA2FAzAY0oRMftxvb-QeAZ8o0zCSW1WNg@mail.gmail.com>
 <1506984729.1122.11.camel@joachim-breitner.de>
 <CAD6SzRLUsAqCkcXWEZde-VptDyWtQtJrCrOOwdVwvLaBL619ww@mail.gmail.com>
 <AM4PR83MB0033AA97DAEE401F72650ADDAD720@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CAD6SzRLk08aWNqK+_5K=vAVj6Vi37bPQJWnS9yky8PPQ9gw4MQ@mail.gmail.com>
 <AM4PR83MB0033D000E03DBAE2A56FFF3FAD720@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CAD6SzRJj_J-RMzYa0bjG_5LmcxHSzXLo01NbJZWWaF5SH+JKxA@mail.gmail.com>
 <AM4PR83MB00330DEA1ADBE69E8312EDB7AD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CAD6SzR+i1KNTNyFO2q_z=7v=VPWi-EDzTSuamAmqHTGC9CerGA@mail.gmail.com>
Message-ID: <CAD6SzRLqPukA6K35SwbQsP=CwFOYPfn6+Q88GVQc8d+dqac4Lw@mail.gmail.com>

For now, I'm trying to determine whether it possible to use the in-scope
dictionary variables for constraint solving from a built-in rewrite rule. I
guess (unsure) my question is how to set up a call to `solveWanteds` to
take those variables into account when solving a given constraint/predicate.

On Thu, Oct 12, 2017 at 11:07 AM, Conal Elliott <conal at conal.net> wrote:

> Thanks for the helpful reply, Simon!
>
> > > The new bit here is that `$dC'` is not found via matching in the LHS,
> but
> > > rather by instance resolution from `k`, which does appear explicitly in
> > > the LHS
>
> > Well this would be something qualitatively new. We don’t that ability in
> > rules; and it’s far from clear to me what it would mean anyway. I suppose
> > that if k was instantiated to a ground type then you might hope to solve
> it,
> > but what if it was instantiated to some in-scope type variable t, and
> some
> > variable of type (C t) was in scope. Should that work too?
>
> Yes, we'd want to use in-scope dictionary variables to help solve the
> needed
> constraints in the presence of polymorphism. I've run into exactly this
> need
> in my own manually programmed ("built-in") rewrite rules. Would it be
> possible
> to do so (without deep/pervasive changes to GHC)?
>
> > Happily it sounds as if you are making progress with help from Joachim.
>
> No, I think Joachim agrees that it's impractical to write all of the needed
> rule specializations, and that generating then programmatically would be
> less
> convenient than the implementing the built-in rules as I do now.
>
> Cheers, -- Conal
>
> On Wed, Oct 4, 2017 at 2:08 AM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
>> The new bit here is that `$dC'` is not found via matching in the LHS, but
>> rather by instance resolution from `k`, which does appear explicitly in the
>> LHS
>>
>>
>>
>> Well this would be something qualitatively new.  We don’t that ability in
>> rules; and it’s far from clear to me what it would mean anyway.  I suppose
>> that if k was instantiated to a ground type then you might hope to solve
>> it, but what if it was instantiated to some in-scope type variable t, and
>> some variable of type (C t) was in scope.  Should that work too?
>>
>>
>>
>> I’m highly dubious.
>>
>>
>>
>> Happily it sounds as if you are making progress with help from Joachim.
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] *On
>> Behalf Of *Conal Elliott
>> *Sent:* 03 October 2017 16:30
>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>> *Subject:* Re: GHC rewrite rule type-checking failure
>>
>>
>>
>>
>>
>> The revised example I gave earlier in the thread:
>>
>>
>>
>> ``` haskell
>>
>> class C k where comp' :: k b c -> k a b -> k a c
>>
>>
>>
>> instance C (->) where comp' = (.)
>>
>>
>>
>> -- Late-inlining version to enable rewriting.
>>
>> comp :: C k => k b c -> k a b -> k a c
>>
>> comp = comp'
>>
>> {-# INLINE [0] comp #-}
>>
>>
>>
>> morph :: (a -> b) -> k a b
>>
>> morph = error "morph: undefined"
>>
>>
>>
>> {-# RULES "morph/(.)" forall f g. morph (g `comp` f) = morph g `comp`
>> morph f #-}
>>
>>
>>
>> -- • Could not deduce (C k) arising from a use of ‘comp’
>>
>> --   from the context: C (->)
>>
>> --     bound by the RULE "morph/(.)"
>>
>> ```
>>
>>
>>
>> A hypothetical generated Core rule (tweaked slightly from Joachim's note):
>>
>>
>>
>> ``` haskell
>>
>> forall (@ k) (@ b) (@ c) (@ a)
>>
>>        ($dC :: C (->))
>>
>>        (f :: a -> b) (g :: b -> c).
>>
>>   morph @ k @ a @ c (comp @ (->) @ b @ c @ a $dC g f)
>>
>>   = comp @ k @ b @ c @ a
>>
>>       $dC'
>>
>>       (morph @ k @ b @ c g)
>>
>>       (morph @ k @ a @ b f)
>>
>>  where
>>
>>    $dC' :: C k
>>
>> ```
>>
>>
>>
>> The new bit here is that `$dC'` is not found via matching in the LHS, but
>> rather by instance resolution from `k`, which does appear explicitly in the
>> LHS. If `C k` cannot be solved, the rule fails. The "where" clause here
>> lists the dictionary variables to be instantiated by instance resolution
>> rather than matching.
>>
>>
>>
>> -- Conal
>>
>>
>>
>>
>>
>> On Tue, Oct 3, 2017 at 8:01 AM, Simon Peyton Jones <simonpj at microsoft.com>
>> wrote:
>>
>> But synthesising from what?
>>
>>
>>
>> And currently no: there is no type-class dictionary synthesis after the
>> type checker.  Not impossible I suppose, but one more fragility: a rule
>> does not fire because some synthesis thing didn’t happen.    Maybe give an
>> as-simple-as-poss example of what you have in mind, now you understand the
>> situation better?   With all the type and dictionary abstractions written
>> explicitly…
>>
>>
>>
>> S
>>
>>
>>
>> *From:* conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] *On
>> Behalf Of *Conal Elliott
>> *Sent:* 03 October 2017 15:56
>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>
>>
>> *Subject:* Re: GHC rewrite rule type-checking failure
>>
>>
>>
>> Thanks, Simon. Your explanation make sense to me. Do you think that the
>> rewrite rule mechanism could be enhanced to try synthesizing the needed
>> dictionaries after LHS matching and before RHS instantiation? I'm doing as
>> much now in my compiling-to-categories plugin, but without the convenience
>> of using concrete syntax for the rules.
>>
>>
>>
>> Regard, - Conal
>>
>>
>>
>>
>>
>> On Tue, Oct 3, 2017 at 12:27 AM, Simon Peyton Jones <
>> simonpj at microsoft.com> wrote:
>>
>> *   Is it feasible for GHC to combine the constraints needed LHS and RHS
>> to form an applicability condition?
>>
>> I don’t think so.
>>
>>
>>
>> Remember that a rewrite rule literally rewrites LHS to RHS.  It does not
>> conjure up any new dictionaries out of thin air.  In your example, (D k b)
>> is needed in the result of the rewrite.  Where can it come from?  Only from
>> something matched on the left.
>>
>>
>>
>> So GHC treats any dictionaries matched on the left as “givens” and tries
>> to solve the ones matched on the left.  If it fails you get the sort of
>> error you see.
>>
>>
>>
>> One way to see this is to write out the rewrite rule you want, complete
>> with all its dictionary arguments. Can you do that?
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* Glasgow-haskell-users [mailto:glasgow-haskell-users-
>> bounces at haskell.org] *On Behalf Of *Conal Elliott
>> *Sent:* 03 October 2017 01:03
>> *To:* Joachim Breitner <mail at joachim-breitner.de>
>> *Cc:* glasgow-haskell-users at haskell.org
>> *Subject:* Re: GHC rewrite rule type-checking failure
>>
>>
>>
>> Thanks very much for the reply, Joachim.
>>
>>
>>
>> Oops! I flubbed the example. I really `morph` to distribute over an
>> application of `comp`. New code below (and attached). You're right that I
>> wouldn't want to restrict the type of `morph`, since each `morph` *rule*
>> imposes its own restrictions.
>>
>>
>>
>> My questions:
>>
>>
>>
>> *   Is it feasible for GHC to combine the constraints needed LHS and RHS
>> to form an applicability condition?
>>
>> *   Is there any way I can make the needed constraints explicit in my
>> rewrite rules?
>>
>> *   Are there any other work-arounds that would enable writing such
>> RHS-constrained rules?
>>
>>
>>
>> Regards, -- Conal
>>
>>
>>
>> ``` haskell
>>
>> {-# OPTIONS_GHC -Wall #-}
>>
>> -- Demonstrate a type checking failure with rewrite rules
>>
>>
>>
>> module RuleFail where
>>
>>
>>
>> class C k where comp' :: k b c -> k a b -> k a c
>>
>>
>>
>> instance C (->) where comp' = (.)
>>
>>
>>
>> -- Late-inlining version to enable rewriting.
>>
>> comp :: C k => k b c -> k a b -> k a c
>>
>> comp = comp'
>>
>> {-# INLINE [0] comp #-}
>>
>>
>>
>> morph :: (a -> b) -> k a b
>>
>> morph = error "morph: undefined"
>>
>>
>>
>> {-# RULES "morph/(.)" forall f g. morph (g `comp` f) = morph g `comp`
>> morph f #-}
>>
>>
>>
>> -- • Could not deduce (C k) arising from a use of ‘comp’
>>
>> --   from the context: C (->)
>>
>> --     bound by the RULE "morph/(.)"
>>
>> ```
>>
>>
>>
>>
>>
>> On Mon, Oct 2, 2017 at 3:52 PM, Joachim Breitner <
>> mail at joachim-breitner.de> wrote:
>>
>> Hi Conal,
>>
>> The difference is that the LHS of the first rule is mentions the `C k`
>> constraint (probably unintentionally):
>>
>> *RuleFail> :t morph comp
>> morph comp :: C k => k1 (k b c) (k a b -> k a c)
>>
>> but the LHS of the second rule side does not:
>>
>> *RuleFail> :t morph addC
>> morph addC :: Num b => k (b, b) b
>>
>>
>>
>> A work-around is to add the constraint to `morph`:
>>
>>     morph :: D k b => (a -> b) -> k a b
>>     morph = error "morph: undefined"
>>
>>     but I fear that this work-around is not acceptable to you.
>>
>>     Joachim
>>
>>     Am Montag, den 02.10.2017, 14:25 -0700 schrieb Conal Elliott:
>>     > -- Demonstrate a type checking failure with rewrite rules
>> >
>> > module RuleFail where
>> >
>> > class C k where comp' :: k b c -> k a b -> k a c
>> >
>> > instance C (->) where comp' = (.)
>> >
>> > -- Late-inlining version to enable rewriting.
>> > comp :: C k => k b c -> k a b -> k a c
>> > comp = comp'
>> > {-# INLINE [0] comp #-}
>> >
>> > morph :: (a -> b) -> k a b
>> > morph = error "morph: undefined"
>> >
>> > {-# RULES "morph/(.)" morph comp = comp #-}  -- Fine
>>
>>
>>
>> > class D k a where addC' :: k (a,a) a
>> >
>> > instance Num a => D (->) a where addC' = uncurry (+)
>> >
>> > -- Late-inlining version to enable rewriting.
>> > addC :: D k a => k (a,a) a
>> > addC = addC'
>> > {-# INLINE [0] addC #-}
>> >
>> > {-# RULES "morph/addC" morph addC = addC #-}  -- Fail
>> >
>> > -- • Could not deduce (D k b) arising from a use of ‘addC’
>> > --   from the context: D (->) b
>> >
>> > -- Why does GHC infer the (C k) constraint for the first rule but not
>> (D k b)
>> > -- for the second rule?
>> >
>> > _______________________________________________
>> > Glasgow-haskell-users mailing list
>> > Glasgow-haskell-users at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users&data=02%7C01%7Csimonpj%40microsoft.com%7C3da5c75572694bab31aa08d509f25936%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636425858847457302&sdata=6dcqjyAYmKXKwZzQQExmWl1cJlCySmP1EvdjA03O19M%3D&reserved=0>
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C3da5c75572694bab31aa08d509f25936%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636425858847457302&sdata=Uoe%2Bw8T3VMFLRsFY%2B8nacXIV0pUQOyCe4iHz%2FS5kGrA%3D&reserved=0>
>>
>>
>>
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171012/0fcd1a8d/attachment-0001.html>

From simonpj at microsoft.com  Fri Oct 13 10:54:00 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 13 Oct 2017 10:54:00 +0000
Subject: GHC rewrite rule type-checking failure
In-Reply-To: <CAD6SzRLqPukA6K35SwbQsP=CwFOYPfn6+Q88GVQc8d+dqac4Lw@mail.gmail.com>
References: <CAD6SzRKj2Kz044CkbXA2FAzAY0oRMftxvb-QeAZ8o0zCSW1WNg@mail.gmail.com>
 <1506984729.1122.11.camel@joachim-breitner.de>
 <CAD6SzRLUsAqCkcXWEZde-VptDyWtQtJrCrOOwdVwvLaBL619ww@mail.gmail.com>
 <AM4PR83MB0033AA97DAEE401F72650ADDAD720@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CAD6SzRLk08aWNqK+_5K=vAVj6Vi37bPQJWnS9yky8PPQ9gw4MQ@mail.gmail.com>
 <AM4PR83MB0033D000E03DBAE2A56FFF3FAD720@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CAD6SzRJj_J-RMzYa0bjG_5LmcxHSzXLo01NbJZWWaF5SH+JKxA@mail.gmail.com>
 <AM4PR83MB00330DEA1ADBE69E8312EDB7AD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CAD6SzR+i1KNTNyFO2q_z=7v=VPWi-EDzTSuamAmqHTGC9CerGA@mail.gmail.com>
 <CAD6SzRLqPukA6K35SwbQsP=CwFOYPfn6+Q88GVQc8d+dqac4Lw@mail.gmail.com>
Message-ID: <AM4PR83MB00335B20C6A07AE10F7D045DAD480@AM4PR83MB0033.EURPRD83.prod.outlook.com>

For now, I'm trying to determine whether it possible to use the in-scope dictionary variables for constraint solving from a built-in rewrite rule.

It would not take deep, pervasive changes.

I suggest that you do /not/ call solveWanteds, but instead make a custom constraint solver.  The constraint solver in the type checker is profoundly influenced by

  *   The need to discover suitable instantiations for unification variables
  *   The need to generate good error messages
  *   The need for nested implication constraints to handle GADTs, skolem escape checks etc
The type checker’s monad is full of junk that you don’t need or want in this simpler context.  Just look at TcRnTypes.TcGblEnv and TcLclEnv.


I think you don’t need either of those things here.    I think you probably only want type-class constraints, not equalities (which add a great deal of complexity).

You just want to say

  *   I’m trying to solve Eq [a].  Ah I have an instance for that.
  *   I’m trying to solve Eq a.  Ah, I have an in-scope Id with that type.
In fact, we already have something a bit like this, for ground class constraints.  See TcInteract.shortCutSolver, and Note [Shortcut solving] in that file.  So it’s not hard.   [Mumble mumble: instance decls with variables not bound in the head might be a problem.  But I doubt that’s what you want.]

Other thoughts

  *   To make this work you’d need access to the top-level class instances in rules.  That’s a change but not a difficult one.  The simplifier already carries around the top-level type-family instances, so you could add the class instances in a similar way..
  *   I’m more concerned about how you’d express all this in the concrete syntax of a RULE.  Maybe you don’t need to do that?  It’s all generated thorough the API?
  *   Even if you don’t need concrete syntax, you’d still need abstract syntax, some change to the CoreRule data type.  And I’m not sure what exactly that is.

I’m unlikely to do all of this myself, but I’m happy advise; but without making a prior commitment to incorporating the result in GHC.  We’d have to see how it goes.

Simon

From: conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] On Behalf Of Conal Elliott
Sent: 12 October 2017 20:02
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: ghc-devs at haskell.org
Subject: Re: GHC rewrite rule type-checking failure

For now, I'm trying to determine whether it possible to use the in-scope dictionary variables for constraint solving from a built-in rewrite rule. I guess (unsure) my question is how to set up a call to `solveWanteds` to take those variables into account when solving a given constraint/predicate.

On Thu, Oct 12, 2017 at 11:07 AM, Conal Elliott <conal at conal.net<mailto:conal at conal.net>> wrote:
Thanks for the helpful reply, Simon!

> > The new bit here is that `$dC'` is not found via matching in the LHS, but
> > rather by instance resolution from `k`, which does appear explicitly in
> > the LHS

> Well this would be something qualitatively new. We don’t that ability in
> rules; and it’s far from clear to me what it would mean anyway. I suppose
> that if k was instantiated to a ground type then you might hope to solve it,
> but what if it was instantiated to some in-scope type variable t, and some
> variable of type (C t) was in scope. Should that work too?

Yes, we'd want to use in-scope dictionary variables to help solve the needed
constraints in the presence of polymorphism. I've run into exactly this need
in my own manually programmed ("built-in") rewrite rules. Would it be possible
to do so (without deep/pervasive changes to GHC)?

> Happily it sounds as if you are making progress with help from Joachim.

No, I think Joachim agrees that it's impractical to write all of the needed
rule specializations, and that generating then programmatically would be less
convenient than the implementing the built-in rules as I do now.

Cheers, -- Conal

On Wed, Oct 4, 2017 at 2:08 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
The new bit here is that `$dC'` is not found via matching in the LHS, but rather by instance resolution from `k`, which does appear explicitly in the LHS

Well this would be something qualitatively new.  We don’t that ability in rules; and it’s far from clear to me what it would mean anyway.  I suppose that if k was instantiated to a ground type then you might hope to solve it, but what if it was instantiated to some in-scope type variable t, and some variable of type (C t) was in scope.  Should that work too?

I’m highly dubious.

Happily it sounds as if you are making progress with help from Joachim.

Simon

From: conal.elliott at gmail.com<mailto:conal.elliott at gmail.com> [mailto:conal.elliott at gmail.com<mailto:conal.elliott at gmail.com>] On Behalf Of Conal Elliott
Sent: 03 October 2017 16:30
To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
Subject: Re: GHC rewrite rule type-checking failure


The revised example I gave earlier in the thread:

``` haskell
class C k where comp' :: k b c -> k a b -> k a c

instance C (->) where comp' = (.)

-- Late-inlining version to enable rewriting.
comp :: C k => k b c -> k a b -> k a c
comp = comp'
{-# INLINE [0] comp #-}

morph :: (a -> b) -> k a b
morph = error "morph: undefined"

{-# RULES "morph/(.)" forall f g. morph (g `comp` f) = morph g `comp` morph f #-}

-- • Could not deduce (C k) arising from a use of ‘comp’
--   from the context: C (->)
--     bound by the RULE "morph/(.)"
```

A hypothetical generated Core rule (tweaked slightly from Joachim's note):

``` haskell
forall (@ k) (@ b) (@ c) (@ a)
       ($dC :: C (->))
       (f :: a -> b) (g :: b -> c).
  morph @ k @ a @ c (comp @ (->) @ b @ c @ a $dC g f)
  = comp @ k @ b @ c @ a
      $dC'
      (morph @ k @ b @ c g)
      (morph @ k @ a @ b f)
 where
   $dC' :: C k
```

The new bit here is that `$dC'` is not found via matching in the LHS, but rather by instance resolution from `k`, which does appear explicitly in the LHS. If `C k` cannot be solved, the rule fails. The "where" clause here lists the dictionary variables to be instantiated by instance resolution rather than matching.

-- Conal


On Tue, Oct 3, 2017 at 8:01 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
But synthesising from what?

And currently no: there is no type-class dictionary synthesis after the type checker.  Not impossible I suppose, but one more fragility: a rule does not fire because some synthesis thing didn’t happen.    Maybe give an as-simple-as-poss example of what you have in mind, now you understand the situation better?   With all the type and dictionary abstractions written explicitly…

S

From: conal.elliott at gmail.com<mailto:conal.elliott at gmail.com> [mailto:conal.elliott at gmail.com<mailto:conal.elliott at gmail.com>] On Behalf Of Conal Elliott
Sent: 03 October 2017 15:56
To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>

Subject: Re: GHC rewrite rule type-checking failure

Thanks, Simon. Your explanation make sense to me. Do you think that the rewrite rule mechanism could be enhanced to try synthesizing the needed dictionaries after LHS matching and before RHS instantiation? I'm doing as much now in my compiling-to-categories plugin, but without the convenience of using concrete syntax for the rules.

Regard, - Conal


On Tue, Oct 3, 2017 at 12:27 AM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
*   Is it feasible for GHC to combine the constraints needed LHS and RHS to form an applicability condition?
I don’t think so.

Remember that a rewrite rule literally rewrites LHS to RHS.  It does not conjure up any new dictionaries out of thin air.  In your example, (D k b) is needed in the result of the rewrite.  Where can it come from?  Only from something matched on the left.

So GHC treats any dictionaries matched on the left as “givens” and tries to solve the ones matched on the left.  If it fails you get the sort of error you see.

One way to see this is to write out the rewrite rule you want, complete with all its dictionary arguments. Can you do that?

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org<mailto:glasgow-haskell-users-bounces at haskell.org>] On Behalf Of Conal Elliott
Sent: 03 October 2017 01:03
To: Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>>
Cc: glasgow-haskell-users at haskell.org<mailto:glasgow-haskell-users at haskell.org>
Subject: Re: GHC rewrite rule type-checking failure

Thanks very much for the reply, Joachim.

Oops! I flubbed the example. I really `morph` to distribute over an application of `comp`. New code below (and attached). You're right that I wouldn't want to restrict the type of `morph`, since each `morph` *rule* imposes its own restrictions.

My questions:

*   Is it feasible for GHC to combine the constraints needed LHS and RHS to form an applicability condition?
*   Is there any way I can make the needed constraints explicit in my rewrite rules?
*   Are there any other work-arounds that would enable writing such RHS-constrained rules?

Regards, -- Conal

``` haskell
{-# OPTIONS_GHC -Wall #-}
-- Demonstrate a type checking failure with rewrite rules

module RuleFail where

class C k where comp' :: k b c -> k a b -> k a c

instance C (->) where comp' = (.)

-- Late-inlining version to enable rewriting.
comp :: C k => k b c -> k a b -> k a c
comp = comp'
{-# INLINE [0] comp #-}

morph :: (a -> b) -> k a b
morph = error "morph: undefined"

{-# RULES "morph/(.)" forall f g. morph (g `comp` f) = morph g `comp` morph f #-}

-- • Could not deduce (C k) arising from a use of ‘comp’
--   from the context: C (->)
--     bound by the RULE "morph/(.)"
```


On Mon, Oct 2, 2017 at 3:52 PM, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Hi Conal,

The difference is that the LHS of the first rule is mentions the `C k`
constraint (probably unintentionally):

*RuleFail> :t morph comp
morph comp :: C k => k1 (k b c) (k a b -> k a c)

but the LHS of the second rule side does not:

*RuleFail> :t morph addC
morph addC :: Num b => k (b, b) b



A work-around is to add the constraint to `morph`:

    morph :: D k b => (a -> b) -> k a b
    morph = error "morph: undefined"

    but I fear that this work-around is not acceptable to you.

    Joachim

    Am Montag, den 02.10.2017, 14:25 -0700 schrieb Conal Elliott:
    > -- Demonstrate a type checking failure with rewrite rules
>
> module RuleFail where
>
> class C k where comp' :: k b c -> k a b -> k a c
>
> instance C (->) where comp' = (.)
>
> -- Late-inlining version to enable rewriting.
> comp :: C k => k b c -> k a b -> k a c
> comp = comp'
> {-# INLINE [0] comp #-}
>
> morph :: (a -> b) -> k a b
> morph = error "morph: undefined"
>
> {-# RULES "morph/(.)" morph comp = comp #-}  -- Fine



> class D k a where addC' :: k (a,a) a
>
> instance Num a => D (->) a where addC' = uncurry (+)
>
> -- Late-inlining version to enable rewriting.
> addC :: D k a => k (a,a) a
> addC = addC'
> {-# INLINE [0] addC #-}
>
> {-# RULES "morph/addC" morph addC = addC #-}  -- Fail
>
> -- • Could not deduce (D k b) arising from a use of ‘addC’
> --   from the context: D (->) b
>
> -- Why does GHC infer the (C k) constraint for the first rule but not (D k b)
> -- for the second rule?
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org<mailto:Glasgow-haskell-users at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users&data=02%7C01%7Csimonpj%40microsoft.com%7C3da5c75572694bab31aa08d509f25936%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636425858847457302&sdata=6dcqjyAYmKXKwZzQQExmWl1cJlCySmP1EvdjA03O19M%3D&reserved=0>
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C3da5c75572694bab31aa08d509f25936%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636425858847457302&sdata=Uoe%2Bw8T3VMFLRsFY%2B8nacXIV0pUQOyCe4iHz%2FS5kGrA%3D&reserved=0>





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171013/9e7cee65/attachment-0001.html>

From monkleyon at gmail.com  Sat Oct 14 15:35:28 2017
From: monkleyon at gmail.com (MarLinn)
Date: Sat, 14 Oct 2017 17:35:28 +0200
Subject: Can I get the internal name of a package at runtime?
Message-ID: <8121d465-3270-acb8-19ff-b8f440d2bb30@gmail.com>

Hi.

I'm experimenting with plug-ins right now. I did manage to dynamically 
load functions at runtime. The caveat: Something (cabal? ghc?) mangles 
the package names. For example, to load a function called "theFunction" 
from a module called "Callee" in a package "Plugin", I had to address it 
via the name 
"Pluginzm0zi0zi0zi0zm2QaFQQzzYhnKJSPRXA7VtPe_Callee_theFunction_closure". 
O…K. Most parts of that are clear, and thanks for making my package 
cooler by appending a "z", but who is this Ozi guy and why is he rapping 
about modems? Without knowing Ozi, the only way I found to get at this 
magic string is to manually look at the actual ELF-header of the 
compiled module. While that might be a robust way, it seems neither 
portable nor elegant.

The "plugins" library failed too, probably for the same reason. (Or it's 
under-documented. Probably both.) The "dynamic-loader" library does 
something via c, therefore no.

Which brings me to the question: Is there any way for a module to get at 
its own internal package name? Or even at the internal name of an 
external package? If not, can I somehow recreate the magic mangling at 
runtime? At first I thought the functions in the "Module", "Name" etc 
modules of GHC might help – but it seems I either need an existing Name 
(that I have no idea how to get) or I have to create one (with no idea 
what magic mangler to call).

I'm asking this question here rather than on café as I feel that if 
there is a solution, it's probably buried in the details of GHC.

Thanks for any suggestions,
MarLinn


From ezyang at mit.edu  Sat Oct 14 16:01:42 2017
From: ezyang at mit.edu (Edward Z. Yang)
Date: Sat, 14 Oct 2017 12:01:42 -0400
Subject: Can I get the internal name of a package at runtime?
In-Reply-To: <8121d465-3270-acb8-19ff-b8f440d2bb30@gmail.com>
References: <8121d465-3270-acb8-19ff-b8f440d2bb30@gmail.com>
Message-ID: <1507996866-sup-5442@sabre>

Hi MarLinn,

The mangling name is "z-encoded".  It is documented here:
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/SymbolNames

Edward

Excerpts from MarLinn's message of 2017-10-14 17:35:28 +0200:
> Hi.
> 
> I'm experimenting with plug-ins right now. I did manage to dynamically 
> load functions at runtime. The caveat: Something (cabal? ghc?) mangles 
> the package names. For example, to load a function called "theFunction" 
> from a module called "Callee" in a package "Plugin", I had to address it 
> via the name 
> "Pluginzm0zi0zi0zi0zm2QaFQQzzYhnKJSPRXA7VtPe_Callee_theFunction_closure". 
> O…K. Most parts of that are clear, and thanks for making my package 
> cooler by appending a "z", but who is this Ozi guy and why is he rapping 
> about modems? Without knowing Ozi, the only way I found to get at this 
> magic string is to manually look at the actual ELF-header of the 
> compiled module. While that might be a robust way, it seems neither 
> portable nor elegant.
> 
> The "plugins" library failed too, probably for the same reason. (Or it's 
> under-documented. Probably both.) The "dynamic-loader" library does 
> something via c, therefore no.
> 
> Which brings me to the question: Is there any way for a module to get at 
> its own internal package name? Or even at the internal name of an 
> external package? If not, can I somehow recreate the magic mangling at 
> runtime? At first I thought the functions in the "Module", "Name" etc 
> modules of GHC might help – but it seems I either need an existing Name 
> (that I have no idea how to get) or I have to create one (with no idea 
> what magic mangler to call).
> 
> I'm asking this question here rather than on café as I feel that if 
> there is a solution, it's probably buried in the details of GHC.
> 
> Thanks for any suggestions,
> MarLinn
> 

From monkleyon at gmail.com  Sat Oct 14 16:48:43 2017
From: monkleyon at gmail.com (MarLinn)
Date: Sat, 14 Oct 2017 18:48:43 +0200
Subject: Can I get the internal name of a package at runtime?
In-Reply-To: <1507996866-sup-5442@sabre>
References: <8121d465-3270-acb8-19ff-b8f440d2bb30@gmail.com>
 <1507996866-sup-5442@sabre>
Message-ID: <1b58a78b-61d2-a117-314e-07bb64580ea5@gmail.com>

Hi Edward,

thank you.
That knowledge revealed that the "Ozi" part was actually the version number.

So the "actual" package name seems to be 
"Plugin-0.0.0.0-2QaFQQzYhnKJSPRXA7VtPe".
That leaves the random(?) characters behind the version number to be 
explained.
But at least now I can exploit the fact that a 
"libHSPlugin-0.0.0.0-2QaFQQzYhnKJSPRXA7VtPe.a" file is generated. So if 
I don't find the complete answer I still have a more portable way for 
discovery than inspecting headers.

That's quite useful.

Cheers,
MarLinn


On 2017-10-14 18:01, Edward Z. Yang wrote:
> Hi MarLinn,
>
> The mangling name is "z-encoded".  It is documented here:
> https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/SymbolNames
>
> Edward
>
> Excerpts from MarLinn's message of 2017-10-14 17:35:28 +0200:
>> Hi.
>>
>> I'm experimenting with plug-ins right now. I did manage to dynamically
>> load functions at runtime. The caveat: Something (cabal? ghc?) mangles
>> the package names. For example, to load a function called "theFunction"
>> from a module called "Callee" in a package "Plugin", I had to address it
>> via the name
>> "Pluginzm0zi0zi0zi0zm2QaFQQzzYhnKJSPRXA7VtPe_Callee_theFunction_closure".
>> O…K. Most parts of that are clear, and thanks for making my package
>> cooler by appending a "z", but who is this Ozi guy and why is he rapping
>> about modems? Without knowing Ozi, the only way I found to get at this
>> magic string is to manually look at the actual ELF-header of the
>> compiled module. While that might be a robust way, it seems neither
>> portable nor elegant.
>>
>> The "plugins" library failed too, probably for the same reason. (Or it's
>> under-documented. Probably both.) The "dynamic-loader" library does
>> something via c, therefore no.
>>
>> Which brings me to the question: Is there any way for a module to get at
>> its own internal package name? Or even at the internal name of an
>> external package? If not, can I somehow recreate the magic mangling at
>> runtime? At first I thought the functions in the "Module", "Name" etc
>> modules of GHC might help – but it seems I either need an existing Name
>> (that I have no idea how to get) or I have to create one (with no idea
>> what magic mangler to call).
>>
>> I'm asking this question here rather than on café as I feel that if
>> there is a solution, it's probably buried in the details of GHC.
>>
>> Thanks for any suggestions,
>> MarLinn
>>


From allbery.b at gmail.com  Sat Oct 14 18:11:16 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 14 Oct 2017 14:11:16 -0400
Subject: Can I get the internal name of a package at runtime?
In-Reply-To: <1b58a78b-61d2-a117-314e-07bb64580ea5@gmail.com>
References: <8121d465-3270-acb8-19ff-b8f440d2bb30@gmail.com>
 <1507996866-sup-5442@sabre> <1b58a78b-61d2-a117-314e-07bb64580ea5@gmail.com>
Message-ID: <CAKFCL4Wyw9byr+WR--ZB4dA07NMTgPgxpJmhrsEq-iC2nBBSgg@mail.gmail.com>

On Sat, Oct 14, 2017 at 12:48 PM, MarLinn <monkleyon at gmail.com> wrote:

> So the "actual" package name seems to be "Plugin-0.0.0.0-2QaFQQzYhnKJSP
> RXA7VtPe".
> That leaves the random(?) characters behind the version number to be
> explained.
>

ABI hash of that specific package build, which is needed because compiling
with different optimization levels etc. will change what part of the
internals gets exposed in the .hi file for inlining into other modules;
mismatches there lead to *really* weird behavior. (If you're lucky, it'll
"just" be a type mismatch in code you didn't write, because it came from
the .hi file. If unlucky, it compiles but dumps core at runtime.)

-- 
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://mail.haskell.org/pipermail/ghc-devs/attachments/20171014/9d1d9dc1/attachment.html>

From monkleyon at gmail.com  Sat Oct 14 19:59:03 2017
From: monkleyon at gmail.com (MarLinn)
Date: Sat, 14 Oct 2017 21:59:03 +0200
Subject: Can I get the internal name of a package at runtime?
In-Reply-To: <CAKFCL4Wyw9byr+WR--ZB4dA07NMTgPgxpJmhrsEq-iC2nBBSgg@mail.gmail.com>
References: <8121d465-3270-acb8-19ff-b8f440d2bb30@gmail.com>
 <1507996866-sup-5442@sabre> <1b58a78b-61d2-a117-314e-07bb64580ea5@gmail.com>
 <CAKFCL4Wyw9byr+WR--ZB4dA07NMTgPgxpJmhrsEq-iC2nBBSgg@mail.gmail.com>
Message-ID: <f2f11e8f-2f59-4677-6db4-53841898df87@gmail.com>

That sounds reasonable, but also like there *can not be* a way to obtain 
that hash at runtime. And therefore, no way to discover the true package 
name.

Which in turn makes discovery and loading of plug-ins a bit harder. 
Well, I guess it's for a good reason so I'll have to work around it. 
Good to know.

Thanks for helping out!

Cheers,
MarLinn


On 2017-10-14 20:11, Brandon Allbery wrote:
> On Sat, Oct 14, 2017 at 12:48 PM, MarLinn <monkleyon at gmail.com 
> <mailto:monkleyon at gmail.com>> wrote:
>
>     So the "actual" package name seems to be
>     "Plugin-0.0.0.0-2QaFQQzYhnKJSPRXA7VtPe".
>     That leaves the random(?) characters behind the version number to
>     be explained.
>
>
> ABI hash of that specific package build, which is needed because 
> compiling with different optimization levels etc. will change what 
> part of the internals gets exposed in the .hi file for inlining into 
> other modules; mismatches there lead to *really* weird behavior. (If 
> you're lucky, it'll "just" be a type mismatch in code you didn't 
> write, because it came from the .hi file. If unlucky, it compiles but 
> dumps core at runtime.)
>
> -- 
> 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


From allbery.b at gmail.com  Sat Oct 14 20:19:32 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 14 Oct 2017 16:19:32 -0400
Subject: Can I get the internal name of a package at runtime?
In-Reply-To: <f2f11e8f-2f59-4677-6db4-53841898df87@gmail.com>
References: <8121d465-3270-acb8-19ff-b8f440d2bb30@gmail.com>
 <1507996866-sup-5442@sabre> <1b58a78b-61d2-a117-314e-07bb64580ea5@gmail.com>
 <CAKFCL4Wyw9byr+WR--ZB4dA07NMTgPgxpJmhrsEq-iC2nBBSgg@mail.gmail.com>
 <f2f11e8f-2f59-4677-6db4-53841898df87@gmail.com>
Message-ID: <CAKFCL4XxNU2M0rFwn7SHrk21ryhcmk1w=GA2e0xmmVxPVqRoDQ@mail.gmail.com>

On Sat, Oct 14, 2017 at 3:59 PM, MarLinn <monkleyon at gmail.com> wrote:

> That sounds reasonable, but also like there *can not be* a way to obtain
> that hash at runtime. And therefore, no way to discover the true package
> name.
>

I can think of a hacky way: make sure the symbol table is still present in
the executable and that you can find said executable, z-encode the part of
the package+version you know and a symbol you know, and look for symbols
that start with one and end with the other; the hash will be in between.

-- 
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://mail.haskell.org/pipermail/ghc-devs/attachments/20171014/e4e358bc/attachment-0001.html>

From allbery.b at gmail.com  Sat Oct 14 20:22:15 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 14 Oct 2017 16:22:15 -0400
Subject: Can I get the internal name of a package at runtime?
In-Reply-To: <CAKFCL4XxNU2M0rFwn7SHrk21ryhcmk1w=GA2e0xmmVxPVqRoDQ@mail.gmail.com>
References: <8121d465-3270-acb8-19ff-b8f440d2bb30@gmail.com>
 <1507996866-sup-5442@sabre> <1b58a78b-61d2-a117-314e-07bb64580ea5@gmail.com>
 <CAKFCL4Wyw9byr+WR--ZB4dA07NMTgPgxpJmhrsEq-iC2nBBSgg@mail.gmail.com>
 <f2f11e8f-2f59-4677-6db4-53841898df87@gmail.com>
 <CAKFCL4XxNU2M0rFwn7SHrk21ryhcmk1w=GA2e0xmmVxPVqRoDQ@mail.gmail.com>
Message-ID: <CAKFCL4XBPQdZzB2re0ZWf5yKcR1QjEfNJYQywHKNr8SvG8FO6g@mail.gmail.com>

Oh, wait, that won;t work because you're trying to find the name of
something to load at runtime. But you can still z-encode the known parts of
the name and look for files starting and ending with those components; the
ABI hash won't matter because a dynamically loaded plugin can't use the
inlinings from the .hi file anyway. If you get multiple matches, you could
warn about it but because you can't use the .hi inlinings in that context
it won't matter which one you load.

On Sat, Oct 14, 2017 at 4:19 PM, Brandon Allbery <allbery.b at gmail.com>
wrote:

> On Sat, Oct 14, 2017 at 3:59 PM, MarLinn <monkleyon at gmail.com> wrote:
>
>> That sounds reasonable, but also like there *can not be* a way to obtain
>> that hash at runtime. And therefore, no way to discover the true package
>> name.
>>
>
> I can think of a hacky way: make sure the symbol table is still present in
> the executable and that you can find said executable, z-encode the part of
> the package+version you know and a symbol you know, and look for symbols
> that start with one and end with the other; the hash will be in between.
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>



-- 
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://mail.haskell.org/pipermail/ghc-devs/attachments/20171014/f16ad88d/attachment.html>

From mail at joachim-breitner.de  Sat Oct 14 21:16:55 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 14 Oct 2017 17:16:55 -0400
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
Message-ID: <1508015815.990.8.camel@joachim-breitner.de>

Hi,


Am Dienstag, den 03.10.2017, 13:55 -0400 schrieb Thomas Jakway:
> Anyone else getting linker errors?
> 
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_uint64'
> chmod +x                                                     inplace/bin/runghc
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_uint32'

…

I can confirm these. Looks like perf.haskell.org is stuck on that
problem.


Thomas, did you resolve that issue?

Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171014/48273006/attachment.sig>

From ben at smart-cactus.org  Sat Oct 14 22:41:09 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Sat, 14 Oct 2017 18:41:09 -0400
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <1508015815.990.8.camel@joachim-breitner.de>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
 <1508015815.990.8.camel@joachim-breitner.de>
Message-ID: <87k1zxs67u.fsf@ben-laptop.smart-cactus.org>

Joachim Breitner <mail at joachim-breitner.de> writes:

> Hi,
>
>
> Am Dienstag, den 03.10.2017, 13:55 -0400 schrieb Thomas Jakway:
>> Anyone else getting linker errors?
>> 
>> /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>> 20171003.so: error: undefined reference to 'ffi_type_uint64'
>> chmod +x                                                     inplace/bin/runghc
>> /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>> 20171003.so: error: undefined reference to 'ffi_type_uint32'
>
> …
>
> I can confirm these. Looks like perf.haskell.org is stuck on that
> problem.
>
Very odd. I don't understand why I'm not seeing this myself. Does
reverting e462b657daa003d365440afdad14c5756898b5e0 and
e515c7f37be97e1c2ccc497ddd0a730e63ddfa82 allow things to build?

If so I say we revert until we can figure out what is going on.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171014/8175f15e/attachment.sig>

From dxld at darkboxed.org  Sun Oct 15 00:30:59 2017
From: dxld at darkboxed.org (Daniel =?iso-8859-1?Q?Gr=F6ber?=)
Date: Sun, 15 Oct 2017 02:30:59 +0200
Subject: Can I get the internal name of a package at runtime?
In-Reply-To: <f2f11e8f-2f59-4677-6db4-53841898df87@gmail.com>
References: <8121d465-3270-acb8-19ff-b8f440d2bb30@gmail.com>
 <1507996866-sup-5442@sabre>
 <1b58a78b-61d2-a117-314e-07bb64580ea5@gmail.com>
 <CAKFCL4Wyw9byr+WR--ZB4dA07NMTgPgxpJmhrsEq-iC2nBBSgg@mail.gmail.com>
 <f2f11e8f-2f59-4677-6db4-53841898df87@gmail.com>
Message-ID: <20171015003058.4fto52pvvlaue5e3@Eli>

Hi,

I think you might be interrested in my rts-loader package,
particularly the [mkSymbol function](https://github.com/DanielG/rts-loader/blob/master/System/Loader/RTS.hs#L275).

It should demonstrate how you can construct the symbol names for
dynamic loading and how to coax the information needed out of Cabal,
see the README and the rest of the source.

--Daniel

On Sat, Oct 14, 2017 at 09:59:03PM +0200, MarLinn wrote:
> That sounds reasonable, but also like there *can not be* a way to obtain
> that hash at runtime. And therefore, no way to discover the true package
> name.
> 
> Which in turn makes discovery and loading of plug-ins a bit harder. Well, I
> guess it's for a good reason so I'll have to work around it. Good to know.
> 
> Thanks for helping out!
> 
> Cheers,
> MarLinn
> 
> 
> On 2017-10-14 20:11, Brandon Allbery wrote:
> > On Sat, Oct 14, 2017 at 12:48 PM, MarLinn <monkleyon at gmail.com
> > <mailto:monkleyon at gmail.com>> wrote:
> > 
> >     So the "actual" package name seems to be
> >     "Plugin-0.0.0.0-2QaFQQzYhnKJSPRXA7VtPe".
> >     That leaves the random(?) characters behind the version number to
> >     be explained.
> > 
> > 
> > ABI hash of that specific package build, which is needed because
> > compiling with different optimization levels etc. will change what part
> > of the internals gets exposed in the .hi file for inlining into other
> > modules; mismatches there lead to *really* weird behavior. (If you're
> > lucky, it'll "just" be a type mismatch in code you didn't write, because
> > it came from the .hi file. If unlucky, it compiles but dumps core at
> > runtime.)
> > 
> > -- 
> > 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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171015/bbdd198b/attachment.sig>

From moritz at lichtzwerge.de  Sun Oct 15 01:26:43 2017
From: moritz at lichtzwerge.de (Moritz Angermann)
Date: Sun, 15 Oct 2017 08:26:43 +0700
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <87k1zxs67u.fsf@ben-laptop.smart-cactus.org>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
 <1508015815.990.8.camel@joachim-breitner.de>
 <87k1zxs67u.fsf@ben-laptop.smart-cactus.org>
Message-ID: <248D9F62-2423-40E5-ABCA-F4F7E3C1633F@lichtzwerge.de>

I’ll try to dig into this in three days when I’m back in SG. Joachim, thanks for providing the full build log.

Sent from my iPhone

> On 15 Oct 2017, at 5:41 AM, Ben Gamari <ben at smart-cactus.org> wrote:
> 
> Joachim Breitner <mail at joachim-breitner.de> writes:
> 
>> Hi,
>> 
>> 
>> Am Dienstag, den 03.10.2017, 13:55 -0400 schrieb Thomas Jakway:
>>> Anyone else getting linker errors?
>>> 
>>> /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>> 20171003.so: error: undefined reference to 'ffi_type_uint64'
>>> chmod +x                                                     inplace/bin/runghc
>>> /home/thomas/git/ghc-new/libraries/ghci/dist-install/build/libHSghci-8.3-ghc8.3.
>>> 20171003.so: error: undefined reference to 'ffi_type_uint32'
>> 
>> …
>> 
>> I can confirm these. Looks like perf.haskell.org is stuck on that
>> problem.
>> 
> Very odd. I don't understand why I'm not seeing this myself. Does
> reverting e462b657daa003d365440afdad14c5756898b5e0 and
> e515c7f37be97e1c2ccc497ddd0a730e63ddfa82 allow things to build?
> 
> If so I say we revert until we can figure out what is going on.
> 
> Cheers,
> 
> - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From monkleyon at gmail.com  Sun Oct 15 14:37:17 2017
From: monkleyon at gmail.com (MarLinn)
Date: Sun, 15 Oct 2017 16:37:17 +0200
Subject: Can I get the internal name of a package at runtime?
In-Reply-To: <20171015003058.4fto52pvvlaue5e3@Eli>
References: <8121d465-3270-acb8-19ff-b8f440d2bb30@gmail.com>
 <1507996866-sup-5442@sabre> <1b58a78b-61d2-a117-314e-07bb64580ea5@gmail.com>
 <CAKFCL4Wyw9byr+WR--ZB4dA07NMTgPgxpJmhrsEq-iC2nBBSgg@mail.gmail.com>
 <f2f11e8f-2f59-4677-6db4-53841898df87@gmail.com>
 <20171015003058.4fto52pvvlaue5e3@Eli>
Message-ID: <5394b741-6df8-f30a-bab5-bae53bd4bb8f@gmail.com>

Hi Daniel,

that looks very interesting. I think it'll take some time to understand 
what's going on, but I already got some good parts. And even if I won't 
end up using it, this seems like a good way to learn some stuff. So 
thanks a lot!

For now I don't need the full power, so I think I'll take what I learned 
here and stick to a simple, hacky solution along the lines of Brandon's 
suggestions. Like enumerating object files in some specified directory, 
then mapping

     readCreateProcessWithExitCode (shell $ "readelf --symbols --wide " ++ path ++ " | grep closure | tr --squeeze-repeat ' ' | cut --delimiter=' ' --fields=9") ""

over them and z-encoding back and forth to discover what the heck I'm 
actually loading.
Elegant? No. Secure? No. Portable? …sufficiently. Works? …hopefully.

I got the feeling there is no good non-hacky way. Somewhere there's 
always some extra c code or something. I'm just glad my current goal is 
to just load object files, not compile user-supplied "scripts" into a 
running project or something.

So thanks again to you all!

Cheers,
MarLinn

On 2017-10-15 02:30, Daniel Gröber wrote:
> Hi,
>
> I think you might be interrested in my rts-loader package,
> particularly the [mkSymbol function](https://github.com/DanielG/rts-loader/blob/master/System/Loader/RTS.hs#L275).
>
> It should demonstrate how you can construct the symbol names for
> dynamic loading and how to coax the information needed out of Cabal,
> see the README and the rest of the source.
>
> --Daniel
>
> On Sat, Oct 14, 2017 at 09:59:03PM +0200, MarLinn wrote:
>> That sounds reasonable, but also like there *can not be* a way to obtain
>> that hash at runtime. And therefore, no way to discover the true package
>> name.
>>
>> Which in turn makes discovery and loading of plug-ins a bit harder. Well, I
>> guess it's for a good reason so I'll have to work around it. Good to know.
>>
>> Thanks for helping out!
>>
>> Cheers,
>> MarLinn
>>
>>
>> On 2017-10-14 20:11, Brandon Allbery wrote:
>>> On Sat, Oct 14, 2017 at 12:48 PM, MarLinn <monkleyon at gmail.com
>>> <mailto:monkleyon at gmail.com>> wrote:
>>>
>>>      So the "actual" package name seems to be
>>>      "Plugin-0.0.0.0-2QaFQQzYhnKJSPRXA7VtPe".
>>>      That leaves the random(?) characters behind the version number to
>>>      be explained.
>>>
>>>
>>> ABI hash of that specific package build, which is needed because
>>> compiling with different optimization levels etc. will change what part
>>> of the internals gets exposed in the .hi file for inlining into other
>>> modules; mismatches there lead to *really* weird behavior. (If you're
>>> lucky, it'll "just" be a type mismatch in code you didn't write, because
>>> it came from the .hi file. If unlucky, it compiles but dumps core at
>>> runtime.)
>>>
>>> -- 
>>> 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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From shiftag at nanotek.info  Mon Oct 16 05:50:57 2017
From: shiftag at nanotek.info (shiftag at nanotek.info)
Date: Mon, 16 Oct 2017 05:50:57 +0000
Subject: Compiling natively GHC for ARMv7l softabi
Message-ID: <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>

Hi List,

I would like to install GHC for my CPU which is an ARMv7L Soft-ABI NEON FPU. I read some stuff on ARM and GHC related. So it appears that an installation is possible but with a RPi. The problem is the stack binary which has been compiled for Hard-Float target. So it should not be difficult to make it work for my architecture.

I checked for stack sources (stack-1.5.1.tar.gz) but I have any clue about how to compile it. Can you give me an hand ?

Cheers,

PS: For info, usually I compiled natively that way : "-march=armv7-a -mfpu=neon -mtune=cortex-a9"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171016/367a8ed6/attachment.html>

From ben at smart-cactus.org  Mon Oct 16 16:19:57 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 16 Oct 2017 12:19:57 -0400
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
References: <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
Message-ID: <874lqzrro2.fsf@ben-laptop.smart-cactus.org>

shiftag at nanotek.info writes:

> Hi List,
>
> I would like to install GHC for my CPU which is an ARMv7L Soft-ABI
> NEON FPU. I read some stuff on ARM and GHC related. So it appears that
> an installation is possible but with a RPi. The problem is the stack
> binary which has been compiled for Hard-Float target. So it should not
> be difficult to make it work for my architecture.
>
Indeed I suspect you are right; it should be fairly straightforward to
build GHC for your platform. 

> I checked for stack sources (stack-1.5.1.tar.gz) but I have any clue
> about how to compile it. Can you give me an hand ?
>
First you will need to build GHC itself. This will be a two-step
process:

 1. First build a cross-compiler [1] for your ARMv7L target on a machine
    with a working GHC (e.g. an amd64 machine).

 2. Transfer this compiler to your target and use it to build a native
    GHC

Let us know if you have any trouble.

Cheers,

- Ben



[1] https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171016/48abc205/attachment.sig>

From conal at conal.net  Tue Oct 17 02:47:49 2017
From: conal at conal.net (Conal Elliott)
Date: Mon, 16 Oct 2017 19:47:49 -0700
Subject: GHC rewrite rule type-checking failure
In-Reply-To: <AM4PR83MB00335B20C6A07AE10F7D045DAD480@AM4PR83MB0033.EURPRD83.prod.outlook.com>
References: <CAD6SzRKj2Kz044CkbXA2FAzAY0oRMftxvb-QeAZ8o0zCSW1WNg@mail.gmail.com>
 <1506984729.1122.11.camel@joachim-breitner.de>
 <CAD6SzRLUsAqCkcXWEZde-VptDyWtQtJrCrOOwdVwvLaBL619ww@mail.gmail.com>
 <AM4PR83MB0033AA97DAEE401F72650ADDAD720@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CAD6SzRLk08aWNqK+_5K=vAVj6Vi37bPQJWnS9yky8PPQ9gw4MQ@mail.gmail.com>
 <AM4PR83MB0033D000E03DBAE2A56FFF3FAD720@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CAD6SzRJj_J-RMzYa0bjG_5LmcxHSzXLo01NbJZWWaF5SH+JKxA@mail.gmail.com>
 <AM4PR83MB00330DEA1ADBE69E8312EDB7AD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CAD6SzR+i1KNTNyFO2q_z=7v=VPWi-EDzTSuamAmqHTGC9CerGA@mail.gmail.com>
 <CAD6SzRLqPukA6K35SwbQsP=CwFOYPfn6+Q88GVQc8d+dqac4Lw@mail.gmail.com>
 <AM4PR83MB00335B20C6A07AE10F7D045DAD480@AM4PR83MB0033.EURPRD83.prod.outlook.com>
Message-ID: <CAD6SzRLPd01yRkcXJZQfBPDC2wXwNDb5v4PL_UXRbqjJALM+Rg@mail.gmail.com>

Thanks for the tips, Simon! I'll first try without extending concrete
syntax (for a BuiltinRule). Regards, - Conal

On Fri, Oct 13, 2017 at 3:54 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> For now, I'm trying to determine whether it possible to use the in-scope
> dictionary variables for constraint solving from a built-in rewrite rule.
>
>
>
> It would not take deep, pervasive changes.
>
>
>
> I suggest that you do /not/ call solveWanteds, but instead make a custom
> constraint solver.  The constraint solver in the type checker is profoundly
> influenced by
>
>    - The need to discover suitable instantiations for unification
>    variables
>    - The need to generate good error messages
>    - The need for nested implication constraints to handle GADTs, skolem
>    escape checks etc
>
> The type checker’s monad is full of junk that you don’t need or want in
> this simpler context.  Just look at TcRnTypes.TcGblEnv and TcLclEnv.
>
>
>
> I think you don’t need either of those things here.    I think you
> probably only want type-class constraints, not equalities (which add a
> great deal of complexity).
>
>
>
> You just want to say
>
>    - I’m trying to solve Eq [a].  Ah I have an instance for that.
>    - I’m trying to solve Eq a.  Ah, I have an in-scope Id with that type.
>
> In fact, we already have something a bit like this, for ground class
> constraints.  See TcInteract.shortCutSolver, and Note [Shortcut solving] in
> that file.  So it’s not hard.   [Mumble mumble: instance decls with
> variables not bound in the head might be a problem.  But I doubt that’s
> what you want.]
>
>
>
> Other thoughts
>
>    - To make this work you’d need access to the top-level class instances
>    in rules.  That’s a change but not a difficult one.  The simplifier already
>    carries around the top-level type-family instances, so you could add the
>    class instances in a similar way..
>    - I’m more concerned about how you’d express all this in the concrete
>    syntax of a RULE.  Maybe you don’t need to do that?  It’s all generated
>    thorough the API?
>    - Even if you don’t need concrete syntax, you’d still need abstract
>    syntax, some change to the CoreRule data type.  And I’m not sure what
>    exactly that is.
>
>
>
> I’m unlikely to do all of this myself, but I’m happy advise; but without
> making a prior commitment to incorporating the result in GHC.  We’d have to
> see how it goes.
>
>
>
> Simon
>
>
>
> *From:* conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] *On
> Behalf Of *Conal Elliott
> *Sent:* 12 October 2017 20:02
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* ghc-devs at haskell.org
>
> *Subject:* Re: GHC rewrite rule type-checking failure
>
>
>
> For now, I'm trying to determine whether it possible to use the in-scope
> dictionary variables for constraint solving from a built-in rewrite rule. I
> guess (unsure) my question is how to set up a call to `solveWanteds` to
> take those variables into account when solving a given constraint/predicate.
>
>
>
> On Thu, Oct 12, 2017 at 11:07 AM, Conal Elliott <conal at conal.net> wrote:
>
> Thanks for the helpful reply, Simon!
>
>
>
> > > The new bit here is that `$dC'` is not found via matching in the LHS,
> but
>
> > > rather by instance resolution from `k`, which does appear explicitly in
>
> > > the LHS
>
>
>
> > Well this would be something qualitatively new. We don’t that ability in
>
> > rules; and it’s far from clear to me what it would mean anyway. I suppose
>
> > that if k was instantiated to a ground type then you might hope to solve
> it,
>
> > but what if it was instantiated to some in-scope type variable t, and
> some
>
> > variable of type (C t) was in scope. Should that work too?
>
>
>
> Yes, we'd want to use in-scope dictionary variables to help solve the
> needed
>
> constraints in the presence of polymorphism. I've run into exactly this
> need
>
> in my own manually programmed ("built-in") rewrite rules. Would it be
> possible
>
> to do so (without deep/pervasive changes to GHC)?
>
>
>
> > Happily it sounds as if you are making progress with help from Joachim.
>
>
>
> No, I think Joachim agrees that it's impractical to write all of the needed
>
> rule specializations, and that generating then programmatically would be
> less
>
> convenient than the implementing the built-in rules as I do now.
>
>
>
> Cheers, -- Conal
>
>
>
> On Wed, Oct 4, 2017 at 2:08 AM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> The new bit here is that `$dC'` is not found via matching in the LHS, but
> rather by instance resolution from `k`, which does appear explicitly in the
> LHS
>
>
>
> Well this would be something qualitatively new.  We don’t that ability in
> rules; and it’s far from clear to me what it would mean anyway.  I suppose
> that if k was instantiated to a ground type then you might hope to solve
> it, but what if it was instantiated to some in-scope type variable t, and
> some variable of type (C t) was in scope.  Should that work too?
>
>
>
> I’m highly dubious.
>
>
>
> Happily it sounds as if you are making progress with help from Joachim.
>
>
>
> Simon
>
>
>
> *From:* conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] *On
> Behalf Of *Conal Elliott
> *Sent:* 03 October 2017 16:30
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Subject:* Re: GHC rewrite rule type-checking failure
>
>
>
>
>
> The revised example I gave earlier in the thread:
>
>
>
> ``` haskell
>
> class C k where comp' :: k b c -> k a b -> k a c
>
>
>
> instance C (->) where comp' = (.)
>
>
>
> -- Late-inlining version to enable rewriting.
>
> comp :: C k => k b c -> k a b -> k a c
>
> comp = comp'
>
> {-# INLINE [0] comp #-}
>
>
>
> morph :: (a -> b) -> k a b
>
> morph = error "morph: undefined"
>
>
>
> {-# RULES "morph/(.)" forall f g. morph (g `comp` f) = morph g `comp`
> morph f #-}
>
>
>
> -- • Could not deduce (C k) arising from a use of ‘comp’
>
> --   from the context: C (->)
>
> --     bound by the RULE "morph/(.)"
>
> ```
>
>
>
> A hypothetical generated Core rule (tweaked slightly from Joachim's note):
>
>
>
> ``` haskell
>
> forall (@ k) (@ b) (@ c) (@ a)
>
>        ($dC :: C (->))
>
>        (f :: a -> b) (g :: b -> c).
>
>   morph @ k @ a @ c (comp @ (->) @ b @ c @ a $dC g f)
>
>   = comp @ k @ b @ c @ a
>
>       $dC'
>
>       (morph @ k @ b @ c g)
>
>       (morph @ k @ a @ b f)
>
>  where
>
>    $dC' :: C k
>
> ```
>
>
>
> The new bit here is that `$dC'` is not found via matching in the LHS, but
> rather by instance resolution from `k`, which does appear explicitly in the
> LHS. If `C k` cannot be solved, the rule fails. The "where" clause here
> lists the dictionary variables to be instantiated by instance resolution
> rather than matching.
>
>
>
> -- Conal
>
>
>
>
>
> On Tue, Oct 3, 2017 at 8:01 AM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> But synthesising from what?
>
>
>
> And currently no: there is no type-class dictionary synthesis after the
> type checker.  Not impossible I suppose, but one more fragility: a rule
> does not fire because some synthesis thing didn’t happen.    Maybe give an
> as-simple-as-poss example of what you have in mind, now you understand the
> situation better?   With all the type and dictionary abstractions written
> explicitly…
>
>
>
> S
>
>
>
> *From:* conal.elliott at gmail.com [mailto:conal.elliott at gmail.com] *On
> Behalf Of *Conal Elliott
> *Sent:* 03 October 2017 15:56
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>
>
> *Subject:* Re: GHC rewrite rule type-checking failure
>
>
>
> Thanks, Simon. Your explanation make sense to me. Do you think that the
> rewrite rule mechanism could be enhanced to try synthesizing the needed
> dictionaries after LHS matching and before RHS instantiation? I'm doing as
> much now in my compiling-to-categories plugin, but without the convenience
> of using concrete syntax for the rules.
>
>
>
> Regard, - Conal
>
>
>
>
>
> On Tue, Oct 3, 2017 at 12:27 AM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> *   Is it feasible for GHC to combine the constraints needed LHS and RHS
> to form an applicability condition?
>
> I don’t think so.
>
>
>
> Remember that a rewrite rule literally rewrites LHS to RHS.  It does not
> conjure up any new dictionaries out of thin air.  In your example, (D k b)
> is needed in the result of the rewrite.  Where can it come from?  Only from
> something matched on the left.
>
>
>
> So GHC treats any dictionaries matched on the left as “givens” and tries
> to solve the ones matched on the left.  If it fails you get the sort of
> error you see.
>
>
>
> One way to see this is to write out the rewrite rule you want, complete
> with all its dictionary arguments. Can you do that?
>
>
>
> Simon
>
>
>
> *From:* Glasgow-haskell-users [mailto:glasgow-haskell-users-
> bounces at haskell.org] *On Behalf Of *Conal Elliott
> *Sent:* 03 October 2017 01:03
> *To:* Joachim Breitner <mail at joachim-breitner.de>
> *Cc:* glasgow-haskell-users at haskell.org
> *Subject:* Re: GHC rewrite rule type-checking failure
>
>
>
> Thanks very much for the reply, Joachim.
>
>
>
> Oops! I flubbed the example. I really `morph` to distribute over an
> application of `comp`. New code below (and attached). You're right that I
> wouldn't want to restrict the type of `morph`, since each `morph` *rule*
> imposes its own restrictions.
>
>
>
> My questions:
>
>
>
> *   Is it feasible for GHC to combine the constraints needed LHS and RHS
> to form an applicability condition?
>
> *   Is there any way I can make the needed constraints explicit in my
> rewrite rules?
>
> *   Are there any other work-arounds that would enable writing such
> RHS-constrained rules?
>
>
>
> Regards, -- Conal
>
>
>
> ``` haskell
>
> {-# OPTIONS_GHC -Wall #-}
>
> -- Demonstrate a type checking failure with rewrite rules
>
>
>
> module RuleFail where
>
>
>
> class C k where comp' :: k b c -> k a b -> k a c
>
>
>
> instance C (->) where comp' = (.)
>
>
>
> -- Late-inlining version to enable rewriting.
>
> comp :: C k => k b c -> k a b -> k a c
>
> comp = comp'
>
> {-# INLINE [0] comp #-}
>
>
>
> morph :: (a -> b) -> k a b
>
> morph = error "morph: undefined"
>
>
>
> {-# RULES "morph/(.)" forall f g. morph (g `comp` f) = morph g `comp`
> morph f #-}
>
>
>
> -- • Could not deduce (C k) arising from a use of ‘comp’
>
> --   from the context: C (->)
>
> --     bound by the RULE "morph/(.)"
>
> ```
>
>
>
>
>
> On Mon, Oct 2, 2017 at 3:52 PM, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
> Hi Conal,
>
> The difference is that the LHS of the first rule is mentions the `C k`
> constraint (probably unintentionally):
>
> *RuleFail> :t morph comp
> morph comp :: C k => k1 (k b c) (k a b -> k a c)
>
> but the LHS of the second rule side does not:
>
> *RuleFail> :t morph addC
> morph addC :: Num b => k (b, b) b
>
>
>
> A work-around is to add the constraint to `morph`:
>
>     morph :: D k b => (a -> b) -> k a b
>     morph = error "morph: undefined"
>
>     but I fear that this work-around is not acceptable to you.
>
>     Joachim
>
>     Am Montag, den 02.10.2017, 14:25 -0700 schrieb Conal Elliott:
>     > -- Demonstrate a type checking failure with rewrite rules
> >
> > module RuleFail where
> >
> > class C k where comp' :: k b c -> k a b -> k a c
> >
> > instance C (->) where comp' = (.)
> >
> > -- Late-inlining version to enable rewriting.
> > comp :: C k => k b c -> k a b -> k a c
> > comp = comp'
> > {-# INLINE [0] comp #-}
> >
> > morph :: (a -> b) -> k a b
> > morph = error "morph: undefined"
> >
> > {-# RULES "morph/(.)" morph comp = comp #-}  -- Fine
>
>
>
> > class D k a where addC' :: k (a,a) a
> >
> > instance Num a => D (->) a where addC' = uncurry (+)
> >
> > -- Late-inlining version to enable rewriting.
> > addC :: D k a => k (a,a) a
> > addC = addC'
> > {-# INLINE [0] addC #-}
> >
> > {-# RULES "morph/addC" morph addC = addC #-}  -- Fail
> >
> > -- • Could not deduce (D k b) arising from a use of ‘addC’
> > --   from the context: D (->) b
> >
> > -- Why does GHC infer the (C k) constraint for the first rule but not (D
> k b)
> > -- for the second rule?
> >
> > _______________________________________________
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users&data=02%7C01%7Csimonpj%40microsoft.com%7C3da5c75572694bab31aa08d509f25936%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636425858847457302&sdata=6dcqjyAYmKXKwZzQQExmWl1cJlCySmP1EvdjA03O19M%3D&reserved=0>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C3da5c75572694bab31aa08d509f25936%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636425858847457302&sdata=Uoe%2Bw8T3VMFLRsFY%2B8nacXIV0pUQOyCe4iHz%2FS5kGrA%3D&reserved=0>
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171016/dde841d0/attachment-0001.html>

From shiftag at nanotek.info  Tue Oct 17 04:41:47 2017
From: shiftag at nanotek.info (shiftag at nanotek.info)
Date: Tue, 17 Oct 2017 04:41:47 +0000
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
References: <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
 <874lqzrro2.fsf@ben-laptop.smart-cactus.org>
 <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
Message-ID: <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>

> shiftag at nanotek.info writes:
> 
>> Hi List,
>> 
>> I would like to install GHC for my CPU which is an ARMv7L Soft-ABI
>> NEON FPU. I read some stuff on ARM and GHC related. So it appears that
>> an installation is possible but with a RPi. The problem is the stack
>> binary which has been compiled for Hard-Float target. So it should not
>> be difficult to make it work for my architecture.
> 
> Indeed I suspect you are right; it should be fairly straightforward to
> build GHC for your platform.
> 
>> I checked for stack sources (stack-1.5.1.tar.gz) but I have any clue
>> about how to compile it. Can you give me an hand ?
> 
> First you will need to build GHC itself. This will be a two-step
> process:
> 
> 1. First build a cross-compiler [1] for your ARMv7L target on a machine
> with a working GHC (e.g. an amd64 machine).
> 
> 2. Transfer this compiler to your target and use it to build a native
> GHC
> 
> Let us know if you have any trouble.
> 
> Cheers,
> 
> - Ben
> 
> [1] https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling


Thank you.

So, I succeed to install GHC on x64 GNU/Linux machine. However, I have an issue at Stage1 while
cross-compiling. I have the following error :

# make
===--- building phase 0
make --no-print-directory -f ghc.mk phase=0 phase_0_builds
utils/genprimopcode/ghc.mk:19: utils/genprimopcode/dist/package-data.mk: No such file or directory
utils/deriveConstants/ghc.mk:19: utils/deriveConstants/dist/package-data.mk: No such file or
directory
utils/genapply/ghc.mk:23: utils/genapply/dist/package-data.mk: No such file or directory
libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/package-data.mk: No such file or directory
libraries/binary/ghc.mk:3: libraries/binary/dist-boot/package-data.mk: No such file or directory
libraries/Cabal/Cabal/ghc.mk:3: libraries/Cabal/Cabal/dist-boot/package-data.mk: No such file or
directory
libraries/ghc-boot-th/ghc.mk:3: libraries/ghc-boot-th/dist-boot/package-data.mk: No such file or
directory
libraries/ghc-boot/ghc.mk:3: libraries/ghc-boot/dist-boot/package-data.mk: No such file or
directory
libraries/template-haskell/ghc.mk:3: libraries/template-haskell/dist-boot/package-data.mk: No such
file or directory
libraries/hoopl/ghc.mk:3: libraries/hoopl/dist-boot/package-data.mk: No such file or directory
libraries/transformers/ghc.mk:3: libraries/transformers/dist-boot/package-data.mk: No such file or
directory
libraries/terminfo/ghc.mk:3: libraries/terminfo/dist-boot/package-data.mk: No such file or
directory
compiler/ghc.mk:584: compiler/stage1/package-data.mk: No such file or directory
utils/hsc2hs/ghc.mk:15: utils/hsc2hs/dist/package-data.mk: No such file or directory
utils/ghc-pkg/ghc.mk:60: utils/ghc-pkg/dist/package-data.mk: No such file or directory
utils/dll-split/ghc.mk:23: utils/dll-split/dist-install/package-data.mk: No such file or directory
ghc/ghc.mk:111: ghc/stage1/package-data.mk: No such file or directory
"/usr/bin/ghc" -H32m -O -Wall \
-optc-Wall -optc-fno-stack-protector \
\
-hide-all-packages \
-package base -package array -package time -package containers -package bytestring -package deepseq
-package process -package pretty -package directory -package unix \
--make utils/ghc-cabal/Main.hs -o utils/ghc-cabal/dist/build/tmp/ghc-cabal \
-no-user-package-db \
-Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \
-DCABAL_VERSION=1,24,2,0 \
-DMIN_VERSION_binary_0_8_0 \
-DBOOTSTRAPPING \
-optP-include -optPutils/ghc-cabal/cabal_macros_boot.h \
-odir bootstrapping \
-hidir bootstrapping \
-ilibraries/Cabal/Cabal \
-ilibraries/binary/src -DGENERICS \
-ilibraries/filepath \
-ilibraries/hpc \

[53 of 95] Compiling Distribution.PackageDescription (
libraries/Cabal/Cabal/Distribution/PackageDescription.hs,
bootstrapping/Distribution/PackageDescription.o )
utils/ghc-cabal/ghc.mk:48: recipe for target 'utils/ghc-cabal/dist/build/tmp/ghc-cabal' failed
make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Killed
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2

I checked Google and I found the following patch :
https://ghc.haskell.org/trac/ghc/ticket/8709

But it didn't work. Do you have an idea to fix it ?

Cheers

From allbery.b at gmail.com  Tue Oct 17 15:26:41 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 17 Oct 2017 11:26:41 -0400
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>
References: <874lqzrro2.fsf@ben-laptop.smart-cactus.org>
 <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
 <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
 <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>
Message-ID: <CAKFCL4WD4ZovhDBhkEcUFTgU6hUgXFdC9O+8sqxNpd+uSf6KvQ@mail.gmail.com>

On Tue, Oct 17, 2017 at 12:41 AM, <shiftag at nanotek.info> wrote:

> utils/ghc-cabal/ghc.mk:48: recipe for target 'utils/ghc-cabal/dist/build/tmp/ghc-cabal'
> failed
> make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Killed
>

The OOM killer got you. Add swap if you can.

-- 
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://mail.haskell.org/pipermail/ghc-devs/attachments/20171017/8b875784/attachment.html>

From ben at smart-cactus.org  Tue Oct 17 18:45:23 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 17 Oct 2017 14:45:23 -0400
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <CAKFCL4WD4ZovhDBhkEcUFTgU6hUgXFdC9O+8sqxNpd+uSf6KvQ@mail.gmail.com>
References: <874lqzrro2.fsf@ben-laptop.smart-cactus.org>
 <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
 <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
 <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>
 <CAKFCL4WD4ZovhDBhkEcUFTgU6hUgXFdC9O+8sqxNpd+uSf6KvQ@mail.gmail.com>
Message-ID: <87h8uxr4u4.fsf@ben-laptop.smart-cactus.org>

Brandon Allbery <allbery.b at gmail.com> writes:

> On Tue, Oct 17, 2017 at 12:41 AM, <shiftag at nanotek.info> wrote:
>
>> utils/ghc-cabal/ghc.mk:48: recipe for target 'utils/ghc-cabal/dist/build/tmp/ghc-cabal'
>> failed
>> make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Killed
>>
>
> The OOM killer got you. Add swap if you can.
>
Exactly.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171017/08299ca9/attachment.sig>

From shiftag at nanotek.info  Wed Oct 18 05:58:35 2017
From: shiftag at nanotek.info (shiftag at nanotek.info)
Date: Wed, 18 Oct 2017 05:58:35 +0000
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <87h8uxr4u4.fsf@ben-laptop.smart-cactus.org>
References: <87h8uxr4u4.fsf@ben-laptop.smart-cactus.org>
 <874lqzrro2.fsf@ben-laptop.smart-cactus.org>
 <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
 <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
 <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>
 <CAKFCL4WD4ZovhDBhkEcUFTgU6hUgXFdC9O+8sqxNpd+uSf6KvQ@mail.gmail.com>
Message-ID: <57f2ac6fc4480efd6930251d44c5deb6@webmail.nanotek.info>

October 17, 2017 10:45 PM, "Ben Gamari" <ben at smart-cactus.org> wrote:

> Brandon Allbery <allbery.b at gmail.com> writes:
> 
>> On Tue, Oct 17, 2017 at 12:41 AM, <shiftag at nanotek.info> wrote:
>> 
>>> utils/ghc-cabal/ghc.mk:48: recipe for target 'utils/ghc-cabal/dist/build/tmp/ghc-cabal'
>>> failed
>>> make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Killed
>> 
>> The OOM killer got you. Add swap if you can.
> 
> Exactly.
> 
> Cheers,
> 
> - Ben


Hi Guys,

Thanks a mil !!!


Well, add a swap if I can ? Yes, we can :)

$ dd if=/dev/zero of=/tmp/swap bs=1M count=4096
$ chmod 600 /tmp/swap
$ mkswap /tmp/swap
$ swapon /tmp/swap
$ swapon -s

Here we go, now it's fixed. I have an other issue but I can figure it out myself.

Cheers,
  Shiftag

From moritz at lichtzwerge.de  Wed Oct 18 14:02:46 2017
From: moritz at lichtzwerge.de (Moritz Angermann)
Date: Wed, 18 Oct 2017 22:02:46 +0800
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <239c9cd9-94f4-5179-e53e-17c1542fd0f4@nyu.edu>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
 <8760bur4sj.fsf@ben-laptop.smart-cactus.org>
 <afafc3d6-253e-980f-2176-39ae5e734858@nyu.edu>
 <A18C8C4B-E72B-47CC-9B1E-B3896EB106EC@lichtzwerge.de>
 <239c9cd9-94f4-5179-e53e-17c1542fd0f4@nyu.edu>
Message-ID: <9F3CBB9B-1885-4A4C-B412-05B5D9B70DCE@lichtzwerge.de>

Hi,

so this somehow looks like for a not yet absolutely clear reason to me,
when building ghci, we fail to link in libffi, for some configurations.

Joachim, as far as I could see, you are using ghc 8.0.1 to boostrap the
compiler. Thomas are you by any chance bootstrapping with 8.0.1 as well?
I assume Ben bootstraps wit 8.2.1.

I'll set up a Ubuntu 16.10 machine tomorrow and try to reproduce this.

Joachim, is perf.haskell.org running Ubuntu as well?

Cheers,
 Moritz

> On Oct 11, 2017, at 1:43 AM, Thomas Jakway <tjakway at nyu.edu> wrote:
> 
> Thanks for getting back to me.
> 
> (I think you mean `git clean -x -f -d`): I usually omit -x but I'll give it a go and report back.
> 
> Before I got the issue on a clean checkout I thought it was something I did to the build files.
> 
> I also tried building the latest release of libffi (v3.2.1) and using it in configure with --with-ffi-includes and --with-ffi-libraries but got the same error.
> 
> 
> On 10/09/2017 02:40 AM, Moritz Angermann wrote:
>> Yes, this commit indeed introduced the need for makeinfo, however after some debugging and improved packaging of the external libffi library, this dependency was removed again, and should not be required with the latest head anymore.
>> 
>> Then again this should not result in link issues but rather in build time issues.
>> 
>> The key to libffi is the libffi-tarballs git submodule, which contains the packaged libffi-tarballs. Make sure all your submodules are also updated.
>> 
>> I usually use `git -x -f -d` (read the documentation first) to ensure a clean working tree. Especially as you say you can’t reproduce it on other machines, maybe there is a file in your tree that the cleaning did not catch?
>> 
>> Sent from my iPhone
>> 
>>> On 9 Oct 2017, at 4:31 AM, Thomas Jakway <tjakway at nyu.edu> wrote:
>>> 
>>> I'm on Ubuntu 16.10.
>>> 
>>> I ran git bisect:
>>> 
>>> ----------------------
>>> 
>>> e515c7f37be97e1c2ccc497ddd0a730e63ddfa82 is the first bad commit
>>> commit e515c7f37be97e1c2ccc497ddd0a730e63ddfa82
>>> Author: Moritz Angermann <moritz.angermann at gmail.com>
>>> Date:   Sat Sep 30 09:31:12 2017 -0400
>>> 
>>> Allow libffi snapshots
>>> 
>>> This is rather annoying. I'd prefer to have a stable release to
>>> use. However libffi-3.2.1 has been released November 12, 2014, and
>>> libffi-4 is TBD. See also https://github.com/libffi/libffi/issues/296
>>> 
>>> The core reason for this change is that llvm changed the supported
>>> assembly to unified syntax, which libffi-3.2.1 does not use, and hence
>>> fails to compile for arm with llvm. For refence, see the following
>>> issue: https://github.com/libffi/libffi/issues/191.
>>> 
>>> This diff contains a script to generate a tarball for the
>>> `libffi-tarballs` repository from the libffi GitHub repository; as well
>>> as the necessary changes to the build system.
>>> 
>>> Updates libffi-tarballs submodule.
>>> 
>>> Reviewers: austin, bgamari, hvr
>>> 
>>> Subscribers: hvr, erikd, rwbarton, thomie
>>> 
>>> Differential Revision: https://phabricator.haskell.org/D3574
>>> 
>>> ----------------------
>>> 
>>> I can't reproduce it on my other linux computers though.
>>> 
>>> 
>>>> On 10/04/2017 02:17 PM, Ben Gamari wrote:
>>>> Thomas Jakway <tjakway at nyu.edu> writes:
>>>> 
>>>>> Anyone else getting linker errors?
>>>>> 
>>>>> This is after running
>>>>> 
>>>>> make clean && make distclean && find . -name "*.o" -type f -delete &&
>>>>> find . -name "*.hi" -type f -delete
>>>>> 
>>>>> then
>>>>> 
>>>>> ./boot && ./configure && make -j5
>>>>> 
>>>>> (ghc-new is not a new checkout, this error is happening on a branch I'm
>>>>> working on, but one that doesn't touch the FFI)
>>>>> 
>>>> I'm afraid I can't reproduce this. What platform/operating system is
>>>> this on?
>>>> 
>>>> Cheers,
>>>> 
>>>> - Ben
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From ben at smart-cactus.org  Wed Oct 18 14:51:08 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 18 Oct 2017 10:51:08 -0400
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <57f2ac6fc4480efd6930251d44c5deb6@webmail.nanotek.info>
References: <87h8uxr4u4.fsf@ben-laptop.smart-cactus.org>
 <874lqzrro2.fsf@ben-laptop.smart-cactus.org>
 <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
 <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
 <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>
 <CAKFCL4WD4ZovhDBhkEcUFTgU6hUgXFdC9O+8sqxNpd+uSf6KvQ@mail.gmail.com>
 <57f2ac6fc4480efd6930251d44c5deb6@webmail.nanotek.info>
Message-ID: <87efq0qzkz.fsf@ben-laptop.smart-cactus.org>

shiftag at nanotek.info writes:

> October 17, 2017 10:45 PM, "Ben Gamari" <ben at smart-cactus.org> wrote:
>
> Hi Guys,
>
> Thanks a mil !!!
>
Great!

Do let us know if anything else goes boom.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171018/1641447f/attachment.sig>

From mail at joachim-breitner.de  Wed Oct 18 15:38:14 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 18 Oct 2017 11:38:14 -0400
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <9F3CBB9B-1885-4A4C-B412-05B5D9B70DCE@lichtzwerge.de>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
 <8760bur4sj.fsf@ben-laptop.smart-cactus.org>
 <afafc3d6-253e-980f-2176-39ae5e734858@nyu.edu>
 <A18C8C4B-E72B-47CC-9B1E-B3896EB106EC@lichtzwerge.de>
 <239c9cd9-94f4-5179-e53e-17c1542fd0f4@nyu.edu>
 <9F3CBB9B-1885-4A4C-B412-05B5D9B70DCE@lichtzwerge.de>
Message-ID: <1508341094.24214.1.camel@joachim-breitner.de>

Hi,

it’s an Arch linux (generously sponsored by Richard’s university). I
have not idea how to give more precise information about the distro
release version or such :-)

Greetings,
Joachim

Am Mittwoch, den 18.10.2017, 22:02 +0800 schrieb Moritz Angermann:
> Hi,
> 
> so this somehow looks like for a not yet absolutely clear reason to me,
> when building ghci, we fail to link in libffi, for some configurations.
> 
> Joachim, as far as I could see, you are using ghc 8.0.1 to boostrap the
> compiler. Thomas are you by any chance bootstrapping with 8.0.1 as well?
> I assume Ben bootstraps wit 8.2.1.
> 
> I'll set up a Ubuntu 16.10 machine tomorrow and try to reproduce this.
> 
> Joachim, is perf.haskell.org running Ubuntu as well?
> 
> Cheers,
>  Moritz
> 
> > On Oct 11, 2017, at 1:43 AM, Thomas Jakway <tjakway at nyu.edu> wrote:
> > 
> > Thanks for getting back to me.
> > 
> > (I think you mean `git clean -x -f -d`): I usually omit -x but I'll give it a go and report back.
> > 
> > Before I got the issue on a clean checkout I thought it was something I did to the build files.
> > 
> > I also tried building the latest release of libffi (v3.2.1) and using it in configure with --with-ffi-includes and --with-ffi-libraries but got the same error.
> > 
> > 
> > On 10/09/2017 02:40 AM, Moritz Angermann wrote:
> > > Yes, this commit indeed introduced the need for makeinfo, however after some debugging and improved packaging of the external libffi library, this dependency was removed again, and should not be required with the latest head anymore.
> > > 
> > > Then again this should not result in link issues but rather in build time issues.
> > > 
> > > The key to libffi is the libffi-tarballs git submodule, which contains the packaged libffi-tarballs. Make sure all your submodules are also updated.
> > > 
> > > I usually use `git -x -f -d` (read the documentation first) to ensure a clean working tree. Especially as you say you can’t reproduce it on other machines, maybe there is a file in your tree that the cleaning did not catch?
> > > 
> > > Sent from my iPhone
> > > 
> > > > On 9 Oct 2017, at 4:31 AM, Thomas Jakway <tjakway at nyu.edu> wrote:
> > > > 
> > > > I'm on Ubuntu 16.10.
> > > > 
> > > > I ran git bisect:
> > > > 
> > > > ----------------------
> > > > 
> > > > e515c7f37be97e1c2ccc497ddd0a730e63ddfa82 is the first bad commit
> > > > commit e515c7f37be97e1c2ccc497ddd0a730e63ddfa82
> > > > Author: Moritz Angermann <moritz.angermann at gmail.com>
> > > > Date:   Sat Sep 30 09:31:12 2017 -0400
> > > > 
> > > > Allow libffi snapshots
> > > > 
> > > > This is rather annoying. I'd prefer to have a stable release to
> > > > use. However libffi-3.2.1 has been released November 12, 2014, and
> > > > libffi-4 is TBD. See also https://github.com/libffi/libffi/issues/296
> > > > 
> > > > The core reason for this change is that llvm changed the supported
> > > > assembly to unified syntax, which libffi-3.2.1 does not use, and hence
> > > > fails to compile for arm with llvm. For refence, see the following
> > > > issue: https://github.com/libffi/libffi/issues/191.
> > > > 
> > > > This diff contains a script to generate a tarball for the
> > > > `libffi-tarballs` repository from the libffi GitHub repository; as well
> > > > as the necessary changes to the build system.
> > > > 
> > > > Updates libffi-tarballs submodule.
> > > > 
> > > > Reviewers: austin, bgamari, hvr
> > > > 
> > > > Subscribers: hvr, erikd, rwbarton, thomie
> > > > 
> > > > Differential Revision: https://phabricator.haskell.org/D3574
> > > > 
> > > > ----------------------
> > > > 
> > > > I can't reproduce it on my other linux computers though.
> > > > 
> > > > 
> > > > > On 10/04/2017 02:17 PM, Ben Gamari wrote:
> > > > > Thomas Jakway <tjakway at nyu.edu> writes:
> > > > > 
> > > > > > Anyone else getting linker errors?
> > > > > > 
> > > > > > This is after running
> > > > > > 
> > > > > > make clean && make distclean && find . -name "*.o" -type f -delete &&
> > > > > > find . -name "*.hi" -type f -delete
> > > > > > 
> > > > > > then
> > > > > > 
> > > > > > ./boot && ./configure && make -j5
> > > > > > 
> > > > > > (ghc-new is not a new checkout, this error is happening on a branch I'm
> > > > > > working on, but one that doesn't touch the FFI)
> > > > > > 
> > > > > 
> > > > > I'm afraid I can't reproduce this. What platform/operating system is
> > > > > this on?
> > > > > 
> > > > > Cheers,
> > > > > 
> > > > > - Ben
> > > > 
> > > > _______________________________________________
> > > > ghc-devs mailing list
> > > > ghc-devs at haskell.org
> > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> > 
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
> 
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171018/05be04b7/attachment.sig>

From moritz at lichtzwerge.de  Thu Oct 19 04:33:31 2017
From: moritz at lichtzwerge.de (Moritz Angermann)
Date: Thu, 19 Oct 2017 12:33:31 +0800
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <1508341094.24214.1.camel@joachim-breitner.de>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
 <8760bur4sj.fsf@ben-laptop.smart-cactus.org>
 <afafc3d6-253e-980f-2176-39ae5e734858@nyu.edu>
 <A18C8C4B-E72B-47CC-9B1E-B3896EB106EC@lichtzwerge.de>
 <239c9cd9-94f4-5179-e53e-17c1542fd0f4@nyu.edu>
 <9F3CBB9B-1885-4A4C-B412-05B5D9B70DCE@lichtzwerge.de>
 <1508341094.24214.1.camel@joachim-breitner.de>
Message-ID: <EC1643E1-60D9-4EC9-BDA4-6DF4EEB45AA1@lichtzwerge.de>

Hi,

I was able to reproduce this with:
Ubuntu 16.10 (YakketyYak), stack's ghc (8.0.2) (via stack setup).

I'll try to figure out what's going wrong here.

Cheers,
 Moritz

> On Oct 18, 2017, at 11:38 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> it’s an Arch linux (generously sponsored by Richard’s university). I
> have not idea how to give more precise information about the distro
> release version or such :-)
> 
> Greetings,
> Joachim
> 
> Am Mittwoch, den 18.10.2017, 22:02 +0800 schrieb Moritz Angermann:
>> Hi,
>> 
>> so this somehow looks like for a not yet absolutely clear reason to me,
>> when building ghci, we fail to link in libffi, for some configurations.
>> 
>> Joachim, as far as I could see, you are using ghc 8.0.1 to boostrap the
>> compiler. Thomas are you by any chance bootstrapping with 8.0.1 as well?
>> I assume Ben bootstraps wit 8.2.1.
>> 
>> I'll set up a Ubuntu 16.10 machine tomorrow and try to reproduce this.
>> 
>> Joachim, is perf.haskell.org running Ubuntu as well?
>> 
>> Cheers,
>> Moritz
>> 
>>> On Oct 11, 2017, at 1:43 AM, Thomas Jakway <tjakway at nyu.edu> wrote:
>>> 
>>> Thanks for getting back to me.
>>> 
>>> (I think you mean `git clean -x -f -d`): I usually omit -x but I'll give it a go and report back.
>>> 
>>> Before I got the issue on a clean checkout I thought it was something I did to the build files.
>>> 
>>> I also tried building the latest release of libffi (v3.2.1) and using it in configure with --with-ffi-includes and --with-ffi-libraries but got the same error.
>>> 
>>> 
>>> On 10/09/2017 02:40 AM, Moritz Angermann wrote:
>>>> Yes, this commit indeed introduced the need for makeinfo, however after some debugging and improved packaging of the external libffi library, this dependency was removed again, and should not be required with the latest head anymore.
>>>> 
>>>> Then again this should not result in link issues but rather in build time issues.
>>>> 
>>>> The key to libffi is the libffi-tarballs git submodule, which contains the packaged libffi-tarballs. Make sure all your submodules are also updated.
>>>> 
>>>> I usually use `git -x -f -d` (read the documentation first) to ensure a clean working tree. Especially as you say you can’t reproduce it on other machines, maybe there is a file in your tree that the cleaning did not catch?
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On 9 Oct 2017, at 4:31 AM, Thomas Jakway <tjakway at nyu.edu> wrote:
>>>>> 
>>>>> I'm on Ubuntu 16.10.
>>>>> 
>>>>> I ran git bisect:
>>>>> 
>>>>> ----------------------
>>>>> 
>>>>> e515c7f37be97e1c2ccc497ddd0a730e63ddfa82 is the first bad commit
>>>>> commit e515c7f37be97e1c2ccc497ddd0a730e63ddfa82
>>>>> Author: Moritz Angermann <moritz.angermann at gmail.com>
>>>>> Date:   Sat Sep 30 09:31:12 2017 -0400
>>>>> 
>>>>> Allow libffi snapshots
>>>>> 
>>>>> This is rather annoying. I'd prefer to have a stable release to
>>>>> use. However libffi-3.2.1 has been released November 12, 2014, and
>>>>> libffi-4 is TBD. See also https://github.com/libffi/libffi/issues/296
>>>>> 
>>>>> The core reason for this change is that llvm changed the supported
>>>>> assembly to unified syntax, which libffi-3.2.1 does not use, and hence
>>>>> fails to compile for arm with llvm. For refence, see the following
>>>>> issue: https://github.com/libffi/libffi/issues/191.
>>>>> 
>>>>> This diff contains a script to generate a tarball for the
>>>>> `libffi-tarballs` repository from the libffi GitHub repository; as well
>>>>> as the necessary changes to the build system.
>>>>> 
>>>>> Updates libffi-tarballs submodule.
>>>>> 
>>>>> Reviewers: austin, bgamari, hvr
>>>>> 
>>>>> Subscribers: hvr, erikd, rwbarton, thomie
>>>>> 
>>>>> Differential Revision: https://phabricator.haskell.org/D3574
>>>>> 
>>>>> ----------------------
>>>>> 
>>>>> I can't reproduce it on my other linux computers though.
>>>>> 
>>>>> 
>>>>>> On 10/04/2017 02:17 PM, Ben Gamari wrote:
>>>>>> Thomas Jakway <tjakway at nyu.edu> writes:
>>>>>> 
>>>>>>> Anyone else getting linker errors?
>>>>>>> 
>>>>>>> This is after running
>>>>>>> 
>>>>>>> make clean && make distclean && find . -name "*.o" -type f -delete &&
>>>>>>> find . -name "*.hi" -type f -delete
>>>>>>> 
>>>>>>> then
>>>>>>> 
>>>>>>> ./boot && ./configure && make -j5
>>>>>>> 
>>>>>>> (ghc-new is not a new checkout, this error is happening on a branch I'm
>>>>>>> working on, but one that doesn't touch the FFI)
>>>>>>> 
>>>>>> 
>>>>>> I'm afraid I can't reproduce this. What platform/operating system is
>>>>>> this on?
>>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>>> - Ben
>>>>> 
>>>>> _______________________________________________
>>>>> ghc-devs mailing list
>>>>> ghc-devs at haskell.org
>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> 
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> 
>> 
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

————————————————— 
Moritz Angermann
+49 170 54 33 0 74
moritz at lichtzwerge.de

lichtzwerge GmbH
Raiffeisenstr. 8
93185 Michelsneukirchen

Amtsgericht Regensburg HRB 14723
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 shiftag at nanotek.info  Thu Oct 19 06:23:10 2017
From: shiftag at nanotek.info (shiftag at nanotek.info)
Date: Thu, 19 Oct 2017 06:23:10 +0000
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <87efq0qzkz.fsf@ben-laptop.smart-cactus.org>
References: <87efq0qzkz.fsf@ben-laptop.smart-cactus.org>
 <87h8uxr4u4.fsf@ben-laptop.smart-cactus.org>
 <874lqzrro2.fsf@ben-laptop.smart-cactus.org>
 <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
 <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
 <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>
 <CAKFCL4WD4ZovhDBhkEcUFTgU6hUgXFdC9O+8sqxNpd+uSf6KvQ@mail.gmail.com>
 <57f2ac6fc4480efd6930251d44c5deb6@webmail.nanotek.info>
Message-ID: <99e66bc4be7e42298f23158304106f22@webmail.nanotek.info>

October 18, 2017 6:51 PM, "Ben Gamari" <ben at smart-cactus.org> wrote:

> shiftag at nanotek.info writes:
> 
>> October 17, 2017 10:45 PM, "Ben Gamari" <ben at smart-cactus.org> wrote:
>> 
>> Hi Guys,
>> 
>> Thanks a mil !!!
> 
> Great!
> 
> Do let us know if anything else goes boom.
> 
> Cheers,
> 
> - Ben


Hi,

I'm afraid I have a very bad news. So it goes boom again and it's like a nuclear bomb :(. So I'm still cross-compiling version 8.0.2 on GNU/Linux with arm-linux-gnueabi compiling suite. As reminders, my target architecture is armv7l soft-abi with neon FPU.

I have the following error at make step :


===--- building final phase
make --no-print-directory -f ghc.mk phase=final all
"inplace/bin/ghc-stage1" -static  -H32m -O -Wall  -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint      -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen           -O2     -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o
/tmp/ghc24064_0/ghc_8.s: Assembler messages:

/tmp/ghc24064_0/ghc_8.s:38:0: error:
  
/tmp/ghc24064_0/ghc_8.s:42:0: error:
     Error: selected processor does not support `strd r0,r1,[r7,#64]' in ARM mode

/tmp/ghc24064_0/ghc_8.s:131:0: error:
     Error: selected processor does not support `ldrd r0,r1,[r3,#64]' in ARM mode

/tmp/ghc24064_0/ghc_8.s:134:0: error:
     Error: selected processor does not support `strd r0,r1,[r3,#64]' in ARM mode
     `arm-linux-gnueabi-gcc' failed in phase `Assembler'. (Exit code: 1)
     rts/ghc.mk:255: recipe for target 'rts/dist/build/StgStartup.o' failed
     make[1]: *** [rts/dist/build/StgStartup.o] Error 1
     Makefile:129: recipe for target 'all' failed
     make: *** [all] Error 2


So I checked on Google and I found this:

   https://ghc.haskell.org/trac/ghc/ticket/11058

Hmm...do I have some hope ?

Cheers
  Shiftag

From moritz.angermann at gmail.com  Thu Oct 19 06:34:37 2017
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 19 Oct 2017 14:34:37 +0800
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <99e66bc4be7e42298f23158304106f22@webmail.nanotek.info>
References: <87efq0qzkz.fsf@ben-laptop.smart-cactus.org>
 <87h8uxr4u4.fsf@ben-laptop.smart-cactus.org>
 <874lqzrro2.fsf@ben-laptop.smart-cactus.org>
 <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
 <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
 <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>
 <CAKFCL4WD4ZovhDBhkEcUFTgU6hUgXFdC9O+8sqxNpd+uSf6KvQ@mail.gmail.com>
 <57f2ac6fc4480efd6930251d44c5deb6@webmail.nanotek.info>
 <99e66bc4be7e42298f23158304106f22@webmail.nanotek.info>
Message-ID: <9906A55A-FACD-4EE2-9623-BD59A3491B08@gmail.com>

> 
> "inplace/bin/ghc-stage1" -static  -H32m -O -Wall  -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint      -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen           -O2     -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o

run this with `-v`, to check the invorcations. I'm pretty certain some flags to opt/llc are missing/wrong here.


From shiftag at nanotek.info  Thu Oct 19 07:32:32 2017
From: shiftag at nanotek.info (shiftag at nanotek.info)
Date: Thu, 19 Oct 2017 07:32:32 +0000
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <9906A55A-FACD-4EE2-9623-BD59A3491B08@gmail.com>
References: <9906A55A-FACD-4EE2-9623-BD59A3491B08@gmail.com>
 <87efq0qzkz.fsf@ben-laptop.smart-cactus.org>
 <87h8uxr4u4.fsf@ben-laptop.smart-cactus.org>
 <874lqzrro2.fsf@ben-laptop.smart-cactus.org>
 <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
 <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
 <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>
 <CAKFCL4WD4ZovhDBhkEcUFTgU6hUgXFdC9O+8sqxNpd+uSf6KvQ@mail.gmail.com>
 <57f2ac6fc4480efd6930251d44c5deb6@webmail.nanotek.info>
 <99e66bc4be7e42298f23158304106f22@webmail.nanotek.info>
Message-ID: <d60b9e203dc3c49f9c0cbced968ad0b6@webmail.nanotek.info>

October 19, 2017 10:34 AM, "Moritz Angermann" <moritz.angermann at gmail.com> wrote:

>> "inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist
>> -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build
>> -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build
>> -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/StgStartup.cmm -o
>> rts/dist/build/StgStartup.o
> 
> run this with `-v`, to check the invorcations. I'm pretty certain some flags to opt/llc are
> missing/wrong here.


Ok :)

Please see below :

$ inplace/bin/ghc-stage1 -v -static  -H32m -O -Wall  -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint      -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen           -O2     -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o
Glasgow Haskell Compiler, Version 8.0.2, stage 1 booted by GHC version 8.0.2
Using binary package database: /tmp/ghc-8.0.2/inplace/lib/package.conf.d/package.cache
loading package database /tmp/ghc-8.0.2/inplace/lib/package.conf.d
wired-in package ghc-prim mapped to ghc-prim-0.5.0.0
wired-in package integer-gmp mapped to integer-gmp-1.0.0.1
wired-in package base mapped to base-4.9.1.0
wired-in package rts mapped to rts
wired-in package template-haskell mapped to template-haskell-2.11.1.0
wired-in package ghc mapped to ghc-8.0.2
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags:
Created temporary directory: /tmp/ghc25166_0
*** C Compiler:
/usr/bin/arm-linux-gnueabi-gcc -marm -fno-stack-protector -DTABLES_NEXT_TO_CODE -DNOSMP -E -I includes -I includes/dist -I includes/dist-derivedconstants/header -I includes/dist-ghcconstants/header -I rts -I rts/dist/build -I rts/dist/build -I rts/dist/build/autogen -I /tmp/ghc-8.0.2/libraries/base/include -I /tmp/ghc-8.0.2/libraries/integer-gmp/include -I /tmp/ghc-8.0.2/rts/dist/build -I /tmp/ghc-8.0.2/includes -I /tmp/ghc-8.0.2/includes/dist-derivedconstants/header '-D__GLASGOW_HASKELL__=800' -include /tmp/ghc-8.0.2/includes/ghcversion.h '-Dlinux_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dlinux_HOST_OS=1' '-Darm_HOST_ARCH=1' '-D__GLASGOW_HASKELL_LLVM__=307' '-D__GLASGOW_HASKELL_TH__=0' -include/tmp/ghc25166_0/ghc_2.h -x assembler-with-cpp rts/StgStartup.cmm -o /tmp/ghc25166_0/ghc_1.cmmcpp
*** ParseCmm [/tmp/ghc25166_0/ghc_1.cmmcpp]:
!!! ParseCmm [/tmp/ghc25166_0/ghc_1.cmmcpp]: finished in 4.00 milliseconds, allocated 2.082 megabytes
*** LLVM CodeGen:
*** LLVM CodeGen:
Using LLVM version: (3,7)
*** Deleting temp files:
Deleting: /tmp/ghc25166_0/ghc_5.c /tmp/ghc25166_0/ghc_4.ll /tmp/ghc25166_0/ghc_3.rsp /tmp/ghc25166_0/ghc_2.h /tmp/ghc25166_0/ghc_1.cmmcpp
Warning: deleting non-existent /tmp/ghc25166_0/ghc_5.c
*** Deleting temp dirs:
Deleting: /tmp/ghc25166_0
ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 8.0.2 for arm-unknown-linux):
       hscCmmFile: no_mod

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

From moritz.angermann at gmail.com  Thu Oct 19 07:52:09 2017
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 19 Oct 2017 15:52:09 +0800
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <d60b9e203dc3c49f9c0cbced968ad0b6@webmail.nanotek.info>
References: <9906A55A-FACD-4EE2-9623-BD59A3491B08@gmail.com>
 <87efq0qzkz.fsf@ben-laptop.smart-cactus.org>
 <87h8uxr4u4.fsf@ben-laptop.smart-cactus.org>
 <874lqzrro2.fsf@ben-laptop.smart-cactus.org>
 <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
 <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
 <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>
 <CAKFCL4WD4ZovhDBhkEcUFTgU6hUgXFdC9O+8sqxNpd+uSf6KvQ@mail.gmail.com>
 <57f2ac6fc4480efd6930251d44c5deb6@webmail.nanotek.info>
 <99e66bc4be7e42298f23158304106f22@webmail.nanotek.info>
 <d60b9e203dc3c49f9c0cbced968ad0b6@webmail.nanotek.info>
Message-ID: <BFB9B6DF-997A-46C7-8B26-AC57E2B98F1D@gmail.com>

Ugh! This looks even worse. I'm a bit at a loss here, why this didn't even make it to the assembly stage...

> On Oct 19, 2017, at 3:32 PM, shiftag at nanotek.info wrote:
> 
> October 19, 2017 10:34 AM, "Moritz Angermann" <moritz.angermann at gmail.com> wrote:
> 
>>> "inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist
>>> -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build
>>> -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build
>>> -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/StgStartup.cmm -o
>>> rts/dist/build/StgStartup.o
>> 
>> run this with `-v`, to check the invorcations. I'm pretty certain some flags to opt/llc are
>> missing/wrong here.
> 
> 
> Ok :)
> 
> Please see below :
> 
> $ inplace/bin/ghc-stage1 -v -static  -H32m -O -Wall  -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint      -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen           -O2     -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o
> Glasgow Haskell Compiler, Version 8.0.2, stage 1 booted by GHC version 8.0.2
> Using binary package database: /tmp/ghc-8.0.2/inplace/lib/package.conf.d/package.cache
> loading package database /tmp/ghc-8.0.2/inplace/lib/package.conf.d
> wired-in package ghc-prim mapped to ghc-prim-0.5.0.0
> wired-in package integer-gmp mapped to integer-gmp-1.0.0.1
> wired-in package base mapped to base-4.9.1.0
> wired-in package rts mapped to rts
> wired-in package template-haskell mapped to template-haskell-2.11.1.0
> wired-in package ghc mapped to ghc-8.0.2
> wired-in package dph-seq not found.
> wired-in package dph-par not found.
> Hsc static flags:
> Created temporary directory: /tmp/ghc25166_0
> *** C Compiler:
> /usr/bin/arm-linux-gnueabi-gcc -marm -fno-stack-protector -DTABLES_NEXT_TO_CODE -DNOSMP -E -I includes -I includes/dist -I includes/dist-derivedconstants/header -I includes/dist-ghcconstants/header -I rts -I rts/dist/build -I rts/dist/build -I rts/dist/build/autogen -I /tmp/ghc-8.0.2/libraries/base/include -I /tmp/ghc-8.0.2/libraries/integer-gmp/include -I /tmp/ghc-8.0.2/rts/dist/build -I /tmp/ghc-8.0.2/includes -I /tmp/ghc-8.0.2/includes/dist-derivedconstants/header '-D__GLASGOW_HASKELL__=800' -include /tmp/ghc-8.0.2/includes/ghcversion.h '-Dlinux_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dlinux_HOST_OS=1' '-Darm_HOST_ARCH=1' '-D__GLASGOW_HASKELL_LLVM__=307' '-D__GLASGOW_HASKELL_TH__=0' -include/tmp/ghc25166_0/ghc_2.h -x assembler-with-cpp rts/StgStartup.cmm -o /tmp/ghc25166_0/ghc_1.cmmcpp
> *** ParseCmm [/tmp/ghc25166_0/ghc_1.cmmcpp]:
> !!! ParseCmm [/tmp/ghc25166_0/ghc_1.cmmcpp]: finished in 4.00 milliseconds, allocated 2.082 megabytes
> *** LLVM CodeGen:
> *** LLVM CodeGen:
> Using LLVM version: (3,7)
> *** Deleting temp files:
> Deleting: /tmp/ghc25166_0/ghc_5.c /tmp/ghc25166_0/ghc_4.ll /tmp/ghc25166_0/ghc_3.rsp /tmp/ghc25166_0/ghc_2.h /tmp/ghc25166_0/ghc_1.cmmcpp
> Warning: deleting non-existent /tmp/ghc25166_0/ghc_5.c
> *** Deleting temp dirs:
> Deleting: /tmp/ghc25166_0
> ghc-stage1: panic! (the 'impossible' happened)
>  (GHC version 8.0.2 for arm-unknown-linux):
>       hscCmmFile: no_mod
> 
> Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug


From moritz at lichtzwerge.de  Thu Oct 19 08:28:48 2017
From: moritz at lichtzwerge.de (Moritz Angermann)
Date: Thu, 19 Oct 2017 16:28:48 +0800
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <1508341094.24214.1.camel@joachim-breitner.de>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
 <8760bur4sj.fsf@ben-laptop.smart-cactus.org>
 <afafc3d6-253e-980f-2176-39ae5e734858@nyu.edu>
 <A18C8C4B-E72B-47CC-9B1E-B3896EB106EC@lichtzwerge.de>
 <239c9cd9-94f4-5179-e53e-17c1542fd0f4@nyu.edu>
 <9F3CBB9B-1885-4A4C-B412-05B5D9B70DCE@lichtzwerge.de>
 <1508341094.24214.1.camel@joachim-breitner.de>
Message-ID: <8E8FA99F-66D5-4804-BDAE-819C333D20B0@lichtzwerge.de>

Hi,

As it turns out this might be linker madness. I do not yet understand why this did work with
the "old" libffi though.

The command that fails is a rather long gcc invocation asking it to link a bunch of libraries together.

$ gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-fuse-ld=gold' [...] -lHSghci-8.3-ghc8.3.20171018 [...] -lffi [...]

From the error message, we know taht ghci depends on libffi. E.g.

> libHSghci-8.3-ghc8.3.20171018.so: error: undefined reference to 'ffi_prep_cif'

Now there are two possible configurations that do (successfully) link on my test machine:

1.) Droppping `-fuse-ld=gold`.
2.) Moving `-lffi` prior to `-lHSghci-8.3-ghc8.3.20171018`.

I guess we could also add the libffi symbols the the other -Wl,-u,... symbols.

Obviously I would not see this on macOS, as there is no go.ld on macOS. On my ubuntu system, gold is
> GNU gold (GNU Binutils for Ubuntu 2.27) 1.12

Again, as I stated in the beginning, I fail to understand why this should related to the new libffi version.

As such running `LD=ld ./configure && make -j` does indeed complete successfully on my machine.

If someone has any idea what the core issue between the libffi update and these build failures is, I'd be happy
to know!

Cheers,
 Moritz

> On Oct 18, 2017, at 11:38 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> it’s an Arch linux (generously sponsored by Richard’s university). I
> have not idea how to give more precise information about the distro
> release version or such :-)
> 
> Greetings,
> Joachim
> 
> Am Mittwoch, den 18.10.2017, 22:02 +0800 schrieb Moritz Angermann:
>> Hi,
>> 
>> so this somehow looks like for a not yet absolutely clear reason to me,
>> when building ghci, we fail to link in libffi, for some configurations.
>> 
>> Joachim, as far as I could see, you are using ghc 8.0.1 to boostrap the
>> compiler. Thomas are you by any chance bootstrapping with 8.0.1 as well?
>> I assume Ben bootstraps wit 8.2.1.
>> 
>> I'll set up a Ubuntu 16.10 machine tomorrow and try to reproduce this.
>> 
>> Joachim, is perf.haskell.org running Ubuntu as well?
>> 
>> Cheers,
>> Moritz
>> 
>>> On Oct 11, 2017, at 1:43 AM, Thomas Jakway <tjakway at nyu.edu> wrote:
>>> 
>>> Thanks for getting back to me.
>>> 
>>> (I think you mean `git clean -x -f -d`): I usually omit -x but I'll give it a go and report back.
>>> 
>>> Before I got the issue on a clean checkout I thought it was something I did to the build files.
>>> 
>>> I also tried building the latest release of libffi (v3.2.1) and using it in configure with --with-ffi-includes and --with-ffi-libraries but got the same error.
>>> 
>>> 
>>> On 10/09/2017 02:40 AM, Moritz Angermann wrote:
>>>> Yes, this commit indeed introduced the need for makeinfo, however after some debugging and improved packaging of the external libffi library, this dependency was removed again, and should not be required with the latest head anymore.
>>>> 
>>>> Then again this should not result in link issues but rather in build time issues.
>>>> 
>>>> The key to libffi is the libffi-tarballs git submodule, which contains the packaged libffi-tarballs. Make sure all your submodules are also updated.
>>>> 
>>>> I usually use `git -x -f -d` (read the documentation first) to ensure a clean working tree. Especially as you say you can’t reproduce it on other machines, maybe there is a file in your tree that the cleaning did not catch?
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On 9 Oct 2017, at 4:31 AM, Thomas Jakway <tjakway at nyu.edu> wrote:
>>>>> 
>>>>> I'm on Ubuntu 16.10.
>>>>> 
>>>>> I ran git bisect:
>>>>> 
>>>>> ----------------------
>>>>> 
>>>>> e515c7f37be97e1c2ccc497ddd0a730e63ddfa82 is the first bad commit
>>>>> commit e515c7f37be97e1c2ccc497ddd0a730e63ddfa82
>>>>> Author: Moritz Angermann <moritz.angermann at gmail.com>
>>>>> Date:   Sat Sep 30 09:31:12 2017 -0400
>>>>> 
>>>>> Allow libffi snapshots
>>>>> 
>>>>> This is rather annoying. I'd prefer to have a stable release to
>>>>> use. However libffi-3.2.1 has been released November 12, 2014, and
>>>>> libffi-4 is TBD. See also https://github.com/libffi/libffi/issues/296
>>>>> 
>>>>> The core reason for this change is that llvm changed the supported
>>>>> assembly to unified syntax, which libffi-3.2.1 does not use, and hence
>>>>> fails to compile for arm with llvm. For refence, see the following
>>>>> issue: https://github.com/libffi/libffi/issues/191.
>>>>> 
>>>>> This diff contains a script to generate a tarball for the
>>>>> `libffi-tarballs` repository from the libffi GitHub repository; as well
>>>>> as the necessary changes to the build system.
>>>>> 
>>>>> Updates libffi-tarballs submodule.
>>>>> 
>>>>> Reviewers: austin, bgamari, hvr
>>>>> 
>>>>> Subscribers: hvr, erikd, rwbarton, thomie
>>>>> 
>>>>> Differential Revision: https://phabricator.haskell.org/D3574
>>>>> 
>>>>> ----------------------
>>>>> 
>>>>> I can't reproduce it on my other linux computers though.
>>>>> 
>>>>> 
>>>>>> On 10/04/2017 02:17 PM, Ben Gamari wrote:
>>>>>> Thomas Jakway <tjakway at nyu.edu> writes:
>>>>>> 
>>>>>>> Anyone else getting linker errors?
>>>>>>> 
>>>>>>> This is after running
>>>>>>> 
>>>>>>> make clean && make distclean && find . -name "*.o" -type f -delete &&
>>>>>>> find . -name "*.hi" -type f -delete
>>>>>>> 
>>>>>>> then
>>>>>>> 
>>>>>>> ./boot && ./configure && make -j5
>>>>>>> 
>>>>>>> (ghc-new is not a new checkout, this error is happening on a branch I'm
>>>>>>> working on, but one that doesn't touch the FFI)
>>>>>>> 
>>>>>> 
>>>>>> I'm afraid I can't reproduce this. What platform/operating system is
>>>>>> this on?
>>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>>> - Ben
>>>>> 
>>>>> _______________________________________________
>>>>> ghc-devs mailing list
>>>>> ghc-devs at haskell.org
>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> 
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> 
>> 
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

————————————————— 
Moritz Angermann
+49 170 54 33 0 74
moritz at lichtzwerge.de

lichtzwerge GmbH
Raiffeisenstr. 8
93185 Michelsneukirchen

Amtsgericht Regensburg HRB 14723
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 chak at justtesting.org  Thu Oct 19 09:56:00 2017
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Thu, 19 Oct 2017 20:56:00 +1100
Subject: [ANN] GHC DevOps Group
Message-ID: <F96D127B-2212-443E-919F-B8BB2F4AA932@justtesting.org>

We announced the GHC DevOps Group at the Haskell Implementors’ Workshop in Oxford earlier this year in Simon PJ’s ”Progress on GHC” session. (The videos are unfortunately not yet online.) To finally announce it more broadly, I wrote a blog post:

  http://www.tweag.io/posts/2017-10-19-ghc-devops-group.html

Cheers,
Manuel


From shiftag at nanotek.info  Thu Oct 19 12:35:05 2017
From: shiftag at nanotek.info (shiftag at nanotek.info)
Date: Thu, 19 Oct 2017 12:35:05 +0000
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <BFB9B6DF-997A-46C7-8B26-AC57E2B98F1D@gmail.com>
References: <BFB9B6DF-997A-46C7-8B26-AC57E2B98F1D@gmail.com>
 <9906A55A-FACD-4EE2-9623-BD59A3491B08@gmail.com>
 <87efq0qzkz.fsf@ben-laptop.smart-cactus.org>
 <87h8uxr4u4.fsf@ben-laptop.smart-cactus.org>
 <874lqzrro2.fsf@ben-laptop.smart-cactus.org>
 <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
 <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
 <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>
 <CAKFCL4WD4ZovhDBhkEcUFTgU6hUgXFdC9O+8sqxNpd+uSf6KvQ@mail.gmail.com>
 <57f2ac6fc4480efd6930251d44c5deb6@webmail.nanotek.info>
 <99e66bc4be7e42298f23158304106f22@webmail.nanotek.info>
 <d60b9e203dc3c49f9c0cbced968ad0b6@webmail.nanotek.info>
Message-ID: <51475a6c74d1f35ca4b0dc6fdec13b25@webmail.nanotek.info>

October 19, 2017 11:52 AM, "Moritz Angermann" <moritz.angermann at gmail.com> wrote:

> Ugh! This looks even worse. I'm a bit at a loss here, why this didn't even make it to the assembly
> stage...
> 
>> On Oct 19, 2017, at 3:32 PM, shiftag at nanotek.info wrote:
>> 
>> October 19, 2017 10:34 AM, "Moritz Angermann" <moritz.angermann at gmail.com> wrote:
>> 
>> "inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist
>> -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build
>> -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build
>> -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/StgStartup.cmm -o
>> rts/dist/build/StgStartup.o
>>> run this with `-v`, to check the invorcations. I'm pretty certain some flags to opt/llc are
>>> missing/wrong here.
>> 
>> Ok :)
>> 
>> Please see below :
>> 
>> $ inplace/bin/ghc-stage1 -v -static -H32m -O -Wall -Iincludes -Iincludes/dist
>> -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build
>> -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build
>> -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/StgStartup.cmm -o
>> rts/dist/build/StgStartup.o
>> Glasgow Haskell Compiler, Version 8.0.2, stage 1 booted by GHC version 8.0.2
>> Using binary package database: /tmp/ghc-8.0.2/inplace/lib/package.conf.d/package.cache
>> loading package database /tmp/ghc-8.0.2/inplace/lib/package.conf.d
>> wired-in package ghc-prim mapped to ghc-prim-0.5.0.0
>> wired-in package integer-gmp mapped to integer-gmp-1.0.0.1
>> wired-in package base mapped to base-4.9.1.0
>> wired-in package rts mapped to rts
>> wired-in package template-haskell mapped to template-haskell-2.11.1.0
>> wired-in package ghc mapped to ghc-8.0.2
>> wired-in package dph-seq not found.
>> wired-in package dph-par not found.
>> Hsc static flags:
>> Created temporary directory: /tmp/ghc25166_0
>> *** C Compiler:
>> /usr/bin/arm-linux-gnueabi-gcc -marm -fno-stack-protector -DTABLES_NEXT_TO_CODE -DNOSMP -E -I
>> includes -I includes/dist -I includes/dist-derivedconstants/header -I
>> includes/dist-ghcconstants/header -I rts -I rts/dist/build -I rts/dist/build -I
>> rts/dist/build/autogen -I /tmp/ghc-8.0.2/libraries/base/include -I
>> /tmp/ghc-8.0.2/libraries/integer-gmp/include -I /tmp/ghc-8.0.2/rts/dist/build -I
>> /tmp/ghc-8.0.2/includes -I /tmp/ghc-8.0.2/includes/dist-derivedconstants/header
>> '-D__GLASGOW_HASKELL__=800' -include /tmp/ghc-8.0.2/includes/ghcversion.h '-Dlinux_BUILD_OS=1'
>> '-Dx86_64_BUILD_ARCH=1' '-Dlinux_HOST_OS=1' '-Darm_HOST_ARCH=1' '-D__GLASGOW_HASKELL_LLVM__=307'
>> '-D__GLASGOW_HASKELL_TH__=0' -include/tmp/ghc25166_0/ghc_2.h -x assembler-with-cpp
>> rts/StgStartup.cmm -o /tmp/ghc25166_0/ghc_1.cmmcpp
>> *** ParseCmm [/tmp/ghc25166_0/ghc_1.cmmcpp]:
>> !!! ParseCmm [/tmp/ghc25166_0/ghc_1.cmmcpp]: finished in 4.00 milliseconds, allocated 2.082
>> megabytes
>> *** LLVM CodeGen:
>> *** LLVM CodeGen:
>> Using LLVM version: (3,7)
>> *** Deleting temp files:
>> Deleting: /tmp/ghc25166_0/ghc_5.c /tmp/ghc25166_0/ghc_4.ll /tmp/ghc25166_0/ghc_3.rsp
>> /tmp/ghc25166_0/ghc_2.h /tmp/ghc25166_0/ghc_1.cmmcpp
>> Warning: deleting non-existent /tmp/ghc25166_0/ghc_5.c
>> *** Deleting temp dirs:
>> Deleting: /tmp/ghc25166_0
>> ghc-stage1: panic! (the 'impossible' happened)
>> (GHC version 8.0.2 for arm-unknown-linux):
>> hscCmmFile: no_mod
>> 
>> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug


For your information :

# ./configure --target=arm-linux-gnueabi --with-ld=arm-linux-gnueabi
[...]
----------------------------------------------------------------------
Configure completed successfully.

   Building GHC version  : 8.0.2
          Git commit id  : 8c7250379d0d2bad1d07dfd556812ff7aa2c42e8

   Build platform        : x86_64-unknown-linux
   Host platform         : x86_64-unknown-linux
   Target platform       : arm-unknown-linux

   Bootstrapping using   : /usr/bin/ghc
      which is version   : 8.0.2

   Using gcc                 : /usr/bin/arm-linux-gnueabi-gcc
      which is version       : 7.2.0
   Building a cross compiler : YES
   hs-cpp       : /usr/bin/arm-linux-gnueabi-gcc
   hs-cpp-flags : -E -undef -traditional
   ld           : /usr/bin/arm-linux-gnueabi-ld.gold
   nm           : /usr/bin/arm-linux-gnueabi-nm
   objdump      : /usr/bin/arm-linux-gnueabi-objdump
   Happy        : /usr/bin/happy (1.19.7)
   Alex         : /usr/bin/alex (3.2.3)
   Perl         : /usr/bin/perl
   sphinx-build : /usr/bin/sphinx-build
   xelatex      : 

   Using LLVM tools
      llc   : /usr/bin/llc
      opt   : /usr/bin/opt
   HsColour : /usr/bin/HsColour

   Tools to build Sphinx HTML documentation available: YES
   Tools to build Sphinx PDF documentation available: NO
----------------------------------------------------------------------

# grep -v '#' build.mk  | sed '/^$/d'
ifneq "$(BuildFlavour)" ""
include mk/flavours/$(BuildFlavour).mk
endif
STRIP_CMD = :
Stage1Only=YES
HADDOCK_DOCS=NO
BUILD_SPHINX_PDF=NO
BUILD_SPHINX_HTML=NO

# make
[and you know the rest...]

From ben at smart-cactus.org  Thu Oct 19 13:56:59 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 19 Oct 2017 09:56:59 -0400
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <BFB9B6DF-997A-46C7-8B26-AC57E2B98F1D@gmail.com>
References: <9906A55A-FACD-4EE2-9623-BD59A3491B08@gmail.com>
 <87efq0qzkz.fsf@ben-laptop.smart-cactus.org>
 <87h8uxr4u4.fsf@ben-laptop.smart-cactus.org>
 <874lqzrro2.fsf@ben-laptop.smart-cactus.org>
 <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
 <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
 <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>
 <CAKFCL4WD4ZovhDBhkEcUFTgU6hUgXFdC9O+8sqxNpd+uSf6KvQ@mail.gmail.com>
 <57f2ac6fc4480efd6930251d44c5deb6@webmail.nanotek.info>
 <99e66bc4be7e42298f23158304106f22@webmail.nanotek.info>
 <d60b9e203dc3c49f9c0cbced968ad0b6@webmail.nanotek.info>
 <BFB9B6DF-997A-46C7-8B26-AC57E2B98F1D@gmail.com>
Message-ID: <87tvyvp7f8.fsf@ben-laptop.smart-cactus.org>

Moritz Angermann <moritz.angermann at gmail.com> writes:

> Ugh! This looks even worse. I'm a bit at a loss here, why this didn't even make it to the assembly stage...
>
This was a known bug in 8.0. See #11784. IIRC I fixed it for 8.2.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171019/a6de02f5/attachment.sig>

From moritz.angermann at gmail.com  Thu Oct 19 14:08:20 2017
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 19 Oct 2017 22:08:20 +0800
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <87tvyvp7f8.fsf@ben-laptop.smart-cactus.org>
References: <9906A55A-FACD-4EE2-9623-BD59A3491B08@gmail.com>
 <87efq0qzkz.fsf@ben-laptop.smart-cactus.org>
 <87h8uxr4u4.fsf@ben-laptop.smart-cactus.org>
 <874lqzrro2.fsf@ben-laptop.smart-cactus.org>
 <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
 <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
 <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>
 <CAKFCL4WD4ZovhDBhkEcUFTgU6hUgXFdC9O+8sqxNpd+uSf6KvQ@mail.gmail.com>
 <57f2ac6fc4480efd6930251d44c5deb6@webmail.nanotek.info>
 <99e66bc4be7e42298f23158304106f22@webmail.nanotek.info>
 <d60b9e203dc3c49f9c0cbced968ad0b6@webmail.nanotek.info>
 <BFB9B6DF-997A-46C7-8B26-AC57E2B98F1D@gmail.com>
 <87tvyvp7f8.fsf@ben-laptop.smart-cactus.org>
Message-ID: <57A4A430-4F5F-43AC-8C29-E69E7C8DD2E2@gmail.com>

Shiftag,

any chance you could try this with 8.2 again then?

Cheers,
 Moritz

> On Oct 19, 2017, at 9:56 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> 
> Moritz Angermann <moritz.angermann at gmail.com> writes:
> 
>> Ugh! This looks even worse. I'm a bit at a loss here, why this didn't even make it to the assembly stage...
>> 
> This was a known bug in 8.0. See #11784. IIRC I fixed it for 8.2.
> 
> Cheers,
> 
> - Ben
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From shiftag at nanotek.info  Thu Oct 19 15:33:50 2017
From: shiftag at nanotek.info (shiftag at nanotek.info)
Date: Thu, 19 Oct 2017 15:33:50 +0000
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <57A4A430-4F5F-43AC-8C29-E69E7C8DD2E2@gmail.com>
References: <57A4A430-4F5F-43AC-8C29-E69E7C8DD2E2@gmail.com>
 <9906A55A-FACD-4EE2-9623-BD59A3491B08@gmail.com>
 <87efq0qzkz.fsf@ben-laptop.smart-cactus.org>
 <87h8uxr4u4.fsf@ben-laptop.smart-cactus.org>
 <874lqzrro2.fsf@ben-laptop.smart-cactus.org>
 <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
 <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
 <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>
 <CAKFCL4WD4ZovhDBhkEcUFTgU6hUgXFdC9O+8sqxNpd+uSf6KvQ@mail.gmail.com>
 <57f2ac6fc4480efd6930251d44c5deb6@webmail.nanotek.info>
 <99e66bc4be7e42298f23158304106f22@webmail.nanotek.info>
 <d60b9e203dc3c49f9c0cbced968ad0b6@webmail.nanotek.info>
 <BFB9B6DF-997A-46C7-8B26-AC57E2B98F1D@gmail.com>
 <87tvyvp7f8.fsf@ben-laptop.smart-cactus.org>
Message-ID: <78ec0450a4ec73600c555d6e538f3a40@webmail.nanotek.info>

October 19, .0000000000000000000000000000000000000000000000000000000000000000000000µ2017
6:.0000000000000000000000000000000000000000000000000000000000000000000000ÿ8 PM, "Moritz Angermann"
<moritz.angermann at gmail.com> wrote:

> Shiftag,
> 
> any chance you could try this with 8.2 again then?
> 


Hi,

I'm going to try that and I will let you know ;)

Thanks guys.

From tillk.vogt at googlemail.com  Thu Oct 19 17:13:25 2017
From: tillk.vogt at googlemail.com (Tillmann Vogt)
Date: Thu, 19 Oct 2017 19:13:25 +0200
Subject: Determine instance method from class method callsite
Message-ID: <743881b0-05f9-e57e-9e24-d77e69c7cb3d@gmail.com>

I have the same problem  with a compiler plugin that I am writing.

In GHC Core I need to get from a dict-fun identifier (e.g. 
$fMyClassDouble to the type class instance bindr (starting with $c).

lookupInstEnv from the InstEnv module seemed to do it, but it seems to 
look up the matching key from a set of instEnv keys and not anything 
that contains the instance bindr. Not sure.

Where is the dictionary lookup that gives me the bindr?

What I did so far:

evalExpr :: DynFlags -> ModGuts -> CoreExpr -> Var ->  CoreM NodeType
evalExpr dflags guts (Var iD) v = do

   hsc_env <- getHscEnv
   eps <- liftIO (hscEPS hsc_env)
   let instEnvs = InstEnvs (eps_inst_env     eps)
                           (mg_inst_env     guts)
                           (mkModuleSet (dep_orphs (mg_deps guts)))
   let ty = tyConAppTyCon_maybe (idType iD)
   let cl = fromJust (tyConClass_maybe (fromJust ty))
   let tys = snd (splitTyConApp (idType iD))
   let (matches,_,_) | isDictId iD = lookupInstEnv False instEnvs cl tys
                     | otherwise = ([],[],[])

   let inst = map (nameStableString . varName . is_dfun . fst) matches

   liftIO $ B.appendFile ("debug.txt") (B.pack (show inst))

From m at tweag.io  Thu Oct 19 18:21:18 2017
From: m at tweag.io (Boespflug, Mathieu)
Date: Thu, 19 Oct 2017 20:21:18 +0200
Subject: Hadrian
In-Reply-To: <WM!40cb2e014e07f6550f3c8c5f10479866652ad41ac6ba2333f4913362e27f61eb5fe41e0cb082b2a3f6f14f196f940550!@mailhub-mx2.ncl.ac.uk>
References: <934D286F-94B2-4680-BFBF-D32AAD41F2C7@tweag.io>
 <87r2tzp6wf.fsf@ben-laptop.smart-cactus.org>
 <DB6PR07MB327271FE78DA50F638A71D8DA5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!0aaa5dc0feb00696997f8b8e77a546115a480a222a4f8c8c3d2bb14632a09efc3c69166fc834a238c16a2f5a5316d1a0!@mailhub-mx4.ncl.ac.uk>
 <WM!40cb2e014e07f6550f3c8c5f10479866652ad41ac6ba2333f4913362e27f61eb5fe41e0cb082b2a3f6f14f196f940550!@mailhub-mx2.ncl.ac.uk>
Message-ID: <CAJ0eudp4rZxyFRQqbvqN+zkC0xHs=edjv5MTicWW72yR84FXaw@mail.gmail.com>

Hi all,

As a user who tried to be an early adopter of Hadrian, I can attest to
Andrey's remarks about GHC progress sometimes (frequently?) breaking
Hadrian.

Ben, Andrey - how about this strawman proposal:

we merge Hadrian into GHC *now*, not because ./validate with Hadrian
works (it doesn't yet), but because the build of GHC succeeds with
Hadrian. The resulting compiler might well be garbage. But that's fine
- we can iterate in the official ghc repo, all the while knowing that
CI has our back if ever some change makes Hadrian no longer even build
a compiler. Once ./validate passes with Hadrian, the guarantee that CI
gives will become stronger still: we'll know if any change would make
the Hadrian-produced compiler garbage again.

Maybe that does sound totally bonkers to you? :) Maybe it's radical,
but sounds to me like the best way to get the benefit *now* of
ensuring Make and Hadrian move forward in lock step thanks to CI.

The above all assumes that we're committed to Hadrian being the future
of GHC's build system. But I take it that's a given by now.

Best,

Mathieu


On 19 October 2017 at 19:05, Andrey Mokhov
<andrey.mokhov at newcastle.ac.uk> wrote:
> Hi Ben, Manuel and all,
>
> Ben has already covered most questions in his answer, but let me add a couple of comments.
>
>> So, Mathieu had the clever idea that having the two build system in
>> GHC side-by-side and then build in CI both ways might be a good way of
>> making sure that keep constant tabs on Hadian and get a clear (and
>> continuous picture) of where it is and what is missing.
>
> It would be great to build every GHC commit both by Make and Hadrian. Not only this would allow to monitor the readiness of Hadrian, it would also make it easier for us to catch up with changes in GHC and the Make build system. At the moment, Hadrian is frequently broken by changes in GHC/Make and we need to do detective work of figuring out which commit broke what and fix Hadrian accordingly. These fixes are trivial in many cases (e.g. adding a new flag to one of the builders) so GHC developers would probably be able to easily mirror these changes in Hadrian if only their commits were marked as Hadrian-breaking by the common CI.
>
>> In other words, why can’t we have Hadrian *today*?
>
> I'd say the biggest issue is #299 -- i.e. making sure that the GHC built by Hadrian passes validation. At the moment we still have 100-200 unexpected failures, most of which probably have to do with outdated command line flags (GHC's build system continuously evolves and it wasn't possible to keep track of all flag changes over time, so there are certainly some differences in Hadrian that lead to validation failures). This is where help is currently needed.
>
> Cheers,
> Andrey
>
> -----Original Message-----
> From: Ben Gamari [mailto:ben at well-typed.com]
> Sent: 19 October 2017 15:08
> To: Manuel M T Chakravarty <manuel.chakravarty at tweag.io>
> Cc: Mathieu Boespflug <m at tweag.io>; Moritz Angermann <moritz.angermann at gmail.com>; Jonas Pfenniger Chevalier <jonas.chevalier at tweag.io>; Andrey Mokhov <andrey.mokhov at newcastle.ac.uk>
> Subject: Re: Hadrian
>
> CCing Andrey and Zhen, who are the principle authors of Hadrian.
>
> Manuel M T Chakravarty <manuel.chakravarty at tweag.io> writes:
>
>> Hi Ben,
>>
>> I our exploration of cross-compilation for GHC and the CI integration,
>> we talked with Moritz and got to the topic of Hadrian. It seems that
>> there are few interdependent issues here, and I am really interested
>> in getting your take on them.
>>
>> * Hadrian is slated for inclusion for 8.4, but I couldn’t find any
>> tickets except #12599. Is this because Hadrian has its own issue
>> tracker on GitHub? How can I get an overview over what’s missing in
>> getting Hadrian into GHC?
>>
> Right, Hadrian tickets are currently tracked in its own issue tracker.
>
>> * For Moritz’ work on ARM and also for CI cross-compiling is
>> important, but Moritz pointed out rightly that it seems wasteful put
>> much time into improving this in the make-based build system if that
>> is going to go soon anyway. However, because Hadrian is not in yet,
>> doing the work on Hadrian now also doesn’t really make sense.
>>
> Indeed. Hadrian is one of the things I am currently working on for
> precisely this reason.
>
>> * Obviously, one issue with Hadrian is stability and feature
>> completeness. This has ramifications on our desire to really get 8.4
>> out of the door in February and not delay the release and also get the
>> CI done, because good CI is the best way of making sure the Hadrian
>> integration goes smoothly. (There is obviously a cyclic dependence
>> between this point and the previous.)
>>
>> So, Mathieu had the clever idea that having the two build system in
>> GHC side-by-side and then build in CI both ways might be a good way of
>> making sure that keep constant tabs on Hadian and get a clear (and
>> continuous picture) of where it is and what is missing. It would also
>> allow Moritz to do cross-compilation work right there on Hadrian.
>>
>> In other words, why can’t we have Hadrian *today*?
>>
> At this point the plan is for Hadrian and the Make-based build system to
> coexist in 8.4, with the make system serving as a backup.
>
> Well, we could (and potentially should) merge Hadrian
>
>> If the limiting factor is resources, maybe we can do something about
>> that, but it would require a good solid plan that we can execute
>> perfectly when given the opportunity.
>>
> The blocking issues in Hadrian are tagged with the "GHC Merge" project
> in the issue tracker. The overall themes currently are,
>
>  * Fixing validation support (finishing #187)
>
>  * Support the remaining test targets (#360)
>
>  * Documentation, so we don't overwhelm Andrey with questions when
>    things break. (#308)
>
>  * Finish and test install rules (#318, #373, #379)
>
>  * bindist install (the last part of #219). I started working on this,
>    although for the moment bugs and 8.2.2 have taken priority.
>
> Andrey, do correct me if I've missed something.
>
> Help is of course always welcome!
>
> Cheers,
>
> - Ben
>

From andrey.mokhov at newcastle.ac.uk  Thu Oct 19 19:08:20 2017
From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov)
Date: Thu, 19 Oct 2017 19:08:20 +0000
Subject: Hadrian
In-Reply-To: <WM!6fd32fd91c7b792358448335a67e70000dc6ea5527a174cf8dbc0997efc5f86bd50120a6cf23b3238a6441c92870c55f!@mailhub-mx5.ncl.ac.uk>
References: <934D286F-94B2-4680-BFBF-D32AAD41F2C7@tweag.io>
 <87r2tzp6wf.fsf@ben-laptop.smart-cactus.org>
 <DB6PR07MB327271FE78DA50F638A71D8DA5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!0aaa5dc0feb00696997f8b8e77a546115a480a222a4f8c8c3d2bb14632a09efc3c69166fc834a238c16a2f5a5316d1a0!@mailhub-mx4.ncl.ac.uk>
 <WM!40cb2e014e07f6550f3c8c5f10479866652ad41ac6ba2333f4913362e27f61eb5fe41e0cb082b2a3f6f14f196f940550!@mailhub-mx2.ncl.ac.uk>
 <CAJ0eudp4rZxyFRQqbvqN+zkC0xHs=edjv5MTicWW72yR84FXaw@mail.gmail.com>
 <WM!6fd32fd91c7b792358448335a67e70000dc6ea5527a174cf8dbc0997efc5f86bd50120a6cf23b3238a6441c92870c55f!@mailhub-mx5.ncl.ac.uk>
 <DB6PR07MB32721FE19812BF7519F08550A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
Message-ID: <WM!ed42b2f0f5a5e9d3d18eab10748e1e0090cf70cdba31a5645f4f7a9a407a4ab381523ce41cd1daac0095f68c7502509f!@mailhub-mx5.ncl.ac.uk>

Hi Mathieu,

Yes, in principle we can merge right now, as long as it's clear that Hadrian still requires more work before taking over.

My only concern is that merging will make it more difficult for us to quickly iterate on Hadrian: the GitHub workflow is more convenient (at least for me) than the Phabricator one. Perhaps, we can keep Hadrian on GitHub as a submodule? This also has the advantage that we can keep all existing references to GitHub issues/PRs without migrating everything to GHC Trac. It would be very unfortunate to lose all history during the merge.

Cheers,
Andrey

-----Original Message-----
From: Boespflug, Mathieu [mailto:m at tweag.io] 
Sent: 19 October 2017 19:21
To: Andrey Mokhov <andrey.mokhov at newcastle.ac.uk>
Cc: Ben Gamari <ben at well-typed.com>; Manuel M T Chakravarty <manuel.chakravarty at tweag.io>; Moritz Angermann <moritz.angermann at gmail.com>; Jonas Pfenniger Chevalier <jonas.chevalier at tweag.io>; ghc-devs <ghc-devs at haskell.org>
Subject: Re: Hadrian

Hi all,

As a user who tried to be an early adopter of Hadrian, I can attest to
Andrey's remarks about GHC progress sometimes (frequently?) breaking
Hadrian.

Ben, Andrey - how about this strawman proposal:

we merge Hadrian into GHC *now*, not because ./validate with Hadrian
works (it doesn't yet), but because the build of GHC succeeds with
Hadrian. The resulting compiler might well be garbage. But that's fine
- we can iterate in the official ghc repo, all the while knowing that
CI has our back if ever some change makes Hadrian no longer even build
a compiler. Once ./validate passes with Hadrian, the guarantee that CI
gives will become stronger still: we'll know if any change would make
the Hadrian-produced compiler garbage again.

Maybe that does sound totally bonkers to you? :) Maybe it's radical,
but sounds to me like the best way to get the benefit *now* of
ensuring Make and Hadrian move forward in lock step thanks to CI.

The above all assumes that we're committed to Hadrian being the future
of GHC's build system. But I take it that's a given by now.

Best,

Mathieu


On 19 October 2017 at 19:05, Andrey Mokhov
<andrey.mokhov at newcastle.ac.uk> wrote:
> Hi Ben, Manuel and all,
>
> Ben has already covered most questions in his answer, but let me add a couple of comments.
>
>> So, Mathieu had the clever idea that having the two build system in
>> GHC side-by-side and then build in CI both ways might be a good way of
>> making sure that keep constant tabs on Hadian and get a clear (and
>> continuous picture) of where it is and what is missing.
>
> It would be great to build every GHC commit both by Make and Hadrian. Not only this would allow to monitor the readiness of Hadrian, it would also make it easier for us to catch up with changes in GHC and the Make build system. At the moment, Hadrian is frequently broken by changes in GHC/Make and we need to do detective work of figuring out which commit broke what and fix Hadrian accordingly. These fixes are trivial in many cases (e.g. adding a new flag to one of the builders) so GHC developers would probably be able to easily mirror these changes in Hadrian if only their commits were marked as Hadrian-breaking by the common CI.
>
>> In other words, why can’t we have Hadrian *today*?
>
> I'd say the biggest issue is #299 -- i.e. making sure that the GHC built by Hadrian passes validation. At the moment we still have 100-200 unexpected failures, most of which probably have to do with outdated command line flags (GHC's build system continuously evolves and it wasn't possible to keep track of all flag changes over time, so there are certainly some differences in Hadrian that lead to validation failures). This is where help is currently needed.
>
> Cheers,
> Andrey
>
> -----Original Message-----
> From: Ben Gamari [mailto:ben at well-typed.com]
> Sent: 19 October 2017 15:08
> To: Manuel M T Chakravarty <manuel.chakravarty at tweag.io>
> Cc: Mathieu Boespflug <m at tweag.io>; Moritz Angermann <moritz.angermann at gmail.com>; Jonas Pfenniger Chevalier <jonas.chevalier at tweag.io>; Andrey Mokhov <andrey.mokhov at newcastle.ac.uk>
> Subject: Re: Hadrian
>
> CCing Andrey and Zhen, who are the principle authors of Hadrian.
>
> Manuel M T Chakravarty <manuel.chakravarty at tweag.io> writes:
>
>> Hi Ben,
>>
>> I our exploration of cross-compilation for GHC and the CI integration,
>> we talked with Moritz and got to the topic of Hadrian. It seems that
>> there are few interdependent issues here, and I am really interested
>> in getting your take on them.
>>
>> * Hadrian is slated for inclusion for 8.4, but I couldn’t find any
>> tickets except #12599. Is this because Hadrian has its own issue
>> tracker on GitHub? How can I get an overview over what’s missing in
>> getting Hadrian into GHC?
>>
> Right, Hadrian tickets are currently tracked in its own issue tracker.
>
>> * For Moritz’ work on ARM and also for CI cross-compiling is
>> important, but Moritz pointed out rightly that it seems wasteful put
>> much time into improving this in the make-based build system if that
>> is going to go soon anyway. However, because Hadrian is not in yet,
>> doing the work on Hadrian now also doesn’t really make sense.
>>
> Indeed. Hadrian is one of the things I am currently working on for
> precisely this reason.
>
>> * Obviously, one issue with Hadrian is stability and feature
>> completeness. This has ramifications on our desire to really get 8.4
>> out of the door in February and not delay the release and also get the
>> CI done, because good CI is the best way of making sure the Hadrian
>> integration goes smoothly. (There is obviously a cyclic dependence
>> between this point and the previous.)
>>
>> So, Mathieu had the clever idea that having the two build system in
>> GHC side-by-side and then build in CI both ways might be a good way of
>> making sure that keep constant tabs on Hadian and get a clear (and
>> continuous picture) of where it is and what is missing. It would also
>> allow Moritz to do cross-compilation work right there on Hadrian.
>>
>> In other words, why can’t we have Hadrian *today*?
>>
> At this point the plan is for Hadrian and the Make-based build system to
> coexist in 8.4, with the make system serving as a backup.
>
> Well, we could (and potentially should) merge Hadrian
>
>> If the limiting factor is resources, maybe we can do something about
>> that, but it would require a good solid plan that we can execute
>> perfectly when given the opportunity.
>>
> The blocking issues in Hadrian are tagged with the "GHC Merge" project
> in the issue tracker. The overall themes currently are,
>
>  * Fixing validation support (finishing #187)
>
>  * Support the remaining test targets (#360)
>
>  * Documentation, so we don't overwhelm Andrey with questions when
>    things break. (#308)
>
>  * Finish and test install rules (#318, #373, #379)
>
>  * bindist install (the last part of #219). I started working on this,
>    although for the moment bugs and 8.2.2 have taken priority.
>
> Andrey, do correct me if I've missed something.
>
> Help is of course always welcome!
>
> Cheers,
>
> - Ben
>

From ben at smart-cactus.org  Thu Oct 19 19:11:50 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 19 Oct 2017 15:11:50 -0400
Subject: Hadrian
In-Reply-To: <CAJ0eudp4rZxyFRQqbvqN+zkC0xHs=edjv5MTicWW72yR84FXaw@mail.gmail.com>
References: <934D286F-94B2-4680-BFBF-D32AAD41F2C7@tweag.io>
 <87r2tzp6wf.fsf@ben-laptop.smart-cactus.org>
 <DB6PR07MB327271FE78DA50F638A71D8DA5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!0aaa5dc0feb00696997f8b8e77a546115a480a222a4f8c8c3d2bb14632a09efc3c69166fc834a238c16a2f5a5316d1a0!@mailhub-mx4.ncl.ac.uk>
 <WM!40cb2e014e07f6550f3c8c5f10479866652ad41ac6ba2333f4913362e27f61eb5fe41e0cb082b2a3f6f14f196f940550!@mailhub-mx2.ncl.ac.uk>
 <CAJ0eudp4rZxyFRQqbvqN+zkC0xHs=edjv5MTicWW72yR84FXaw@mail.gmail.com>
Message-ID: <87o9p3osuh.fsf@ben-laptop.smart-cactus.org>

"Boespflug, Mathieu" <m at tweag.io> writes:

> Hi all,
>
> As a user who tried to be an early adopter of Hadrian, I can attest to
> Andrey's remarks about GHC progress sometimes (frequently?) breaking
> Hadrian.
>
> Ben, Andrey - how about this strawman proposal:
>
> we merge Hadrian into GHC *now*, not because ./validate with Hadrian
> works (it doesn't yet), but because the build of GHC succeeds with
> Hadrian. The resulting compiler might well be garbage. But that's fine
> - we can iterate in the official ghc repo, all the while knowing that
> CI has our back if ever some change makes Hadrian no longer even build
> a compiler. Once ./validate passes with Hadrian, the guarantee that CI
> gives will become stronger still: we'll know if any change would make
> the Hadrian-produced compiler garbage again.
>
> Maybe that does sound totally bonkers to you? :) Maybe it's radical,
> but sounds to me like the best way to get the benefit *now* of
> ensuring Make and Hadrian move forward in lock step thanks to CI.
>
> The above all assumes that we're committed to Hadrian being the future
> of GHC's build system. But I take it that's a given by now.
>
That's not so different from my existing plan, which is to import
Hadrian after 8.2.2.

That being said, if it's okay with Andrey to import now then it is also
okay with me. There are, of course some details to be worked out: do we
import hadrian as a git subtree, retaining history, or simply squash a
snapshot? Where should tickets now be filed from now on? Should we move
the scripts in the top-level of the hadrian repo to the top-level of the
GHC repo?

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171019/6d130408/attachment.sig>

From ben at well-typed.com  Thu Oct 19 19:49:48 2017
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 19 Oct 2017 15:49:48 -0400
Subject: Hadrian
In-Reply-To: <WM!253cf6ed6c41c94fc7395ffada2a7327e62a36ea7e400abbfc58f37d5e4a33f3198f9302ade085a5cff11626941104df!@mailhub-mx4.ncl.ac.uk>
References: <934D286F-94B2-4680-BFBF-D32AAD41F2C7@tweag.io>
 <87r2tzp6wf.fsf@ben-laptop.smart-cactus.org>
 <DB6PR07MB327271FE78DA50F638A71D8DA5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!0aaa5dc0feb00696997f8b8e77a546115a480a222a4f8c8c3d2bb14632a09efc3c69166fc834a238c16a2f5a5316d1a0!@mailhub-mx4.ncl.ac.uk>
 <WM!40cb2e014e07f6550f3c8c5f10479866652ad41ac6ba2333f4913362e27f61eb5fe41e0cb082b2a3f6f14f196f940550!@mailhub-mx2.ncl.ac.uk>
 <CAJ0eudp4rZxyFRQqbvqN+zkC0xHs=edjv5MTicWW72yR84FXaw@mail.gmail.com>
 <WM!6fd32fd91c7b792358448335a67e70000dc6ea5527a174cf8dbc0997efc5f86bd50120a6cf23b3238a6441c92870c55f!@mailhub-mx5.ncl.ac.uk>
 <DB6PR07MB32721FE19812BF7519F08550A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!253cf6ed6c41c94fc7395ffada2a7327e62a36ea7e400abbfc58f37d5e4a33f3198f9302ade085a5cff11626941104df!@mailhub-mx4.ncl.ac.uk>
Message-ID: <87lgk6q5nn.fsf@ben-laptop.smart-cactus.org>

Andrey Mokhov <andrey.mokhov at newcastle.ac.uk> writes:

> Hi Mathieu,
>
> Yes, in principle we can merge right now, as long as it's clear that Hadrian still requires more work before taking over.
>
> My only concern is that merging will make it more difficult for us to
> quickly iterate on Hadrian: the GitHub workflow is more convenient (at
> least for me) than the Phabricator one. Perhaps, we can keep Hadrian
> on GitHub as a submodule? This also has the advantage that we can keep
> all existing references to GitHub issues/PRs without migrating
> everything to GHC Trac. It would be very unfortunate to lose all
> history during the merge.
>
Okay, so if we want to preserve history then I would suggest that we go
the subtree route. That is pretty much precisely the use-case which
git subtree was designed to address. This will allow us to have Hadrian,
with history, in the GHC tree and you can continue to develop it on
GitHub until things have stabilized. The only question is how to ensure
that the subtree remains up-to-date.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171019/5ab6625e/attachment.sig>

From andrey.mokhov at newcastle.ac.uk  Thu Oct 19 20:01:01 2017
From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov)
Date: Thu, 19 Oct 2017 20:01:01 +0000
Subject: Hadrian
In-Reply-To: <WM!583df3cf63acfbcae9033b06ade9021cde1dfbd3325ac787f71d841edbc36cda82ef286ae9b471b84820eadf6ea4e292!@mailhub-mx2.ncl.ac.uk>
References: <934D286F-94B2-4680-BFBF-D32AAD41F2C7@tweag.io>
 <87r2tzp6wf.fsf@ben-laptop.smart-cactus.org>
 <DB6PR07MB327271FE78DA50F638A71D8DA5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!0aaa5dc0feb00696997f8b8e77a546115a480a222a4f8c8c3d2bb14632a09efc3c69166fc834a238c16a2f5a5316d1a0!@mailhub-mx4.ncl.ac.uk>
 <WM!40cb2e014e07f6550f3c8c5f10479866652ad41ac6ba2333f4913362e27f61eb5fe41e0cb082b2a3f6f14f196f940550!@mailhub-mx2.ncl.ac.uk>
 <CAJ0eudp4rZxyFRQqbvqN+zkC0xHs=edjv5MTicWW72yR84FXaw@mail.gmail.com>
 <WM!6fd32fd91c7b792358448335a67e70000dc6ea5527a174cf8dbc0997efc5f86bd50120a6cf23b3238a6441c92870c55f!@mailhub-mx5.ncl.ac.uk>
 <DB6PR07MB32721FE19812BF7519F08550A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!253cf6ed6c41c94fc7395ffada2a7327e62a36ea7e400abbfc58f37d5e4a33f3198f9302ade085a5cff11626941104df!@mailhub-mx4.ncl.ac.uk>
 <87lgk6q5nn.fsf@ben-laptop.smart-cactus.org>
 <WM!583df3cf63acfbcae9033b06ade9021cde1dfbd3325ac787f71d841edbc36cda82ef286ae9b471b84820eadf6ea4e292!@mailhub-mx2.ncl.ac.uk>
 <DB6PR07MB3272BD0A5C88640F2119CE49A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
Message-ID: <WM!38af6b1a9bf4ef69781f5bb98d0a86743bc8265bc9c5a566aae1b11b9bbef06dd466a05debd921411d6b217722a4b0e8!@mailhub-mx4.ncl.ac.uk>

Thanks Ben,

Just to clarify: By history I mean not just commits, but GitHub issues and PRs as well -- together they contain a lot of valuable interlinked information for GHC/Hadrian developers. 

> That is pretty much precisely the use-case which
> git subtree was designed to address. This will allow us to have Hadrian,
> with history, in the GHC tree and you can continue to develop it on
> GitHub until things have stabilized.

Sounds great. I haven't used git subtrees before, so I'll need to do some reading, but if everyone is happy with merging Hadrian as is, I can prepare a patch over the weekend!

Cheers,
Andrey

-----Original Message-----
From: Ben Gamari [mailto:ben at well-typed.com] 
Sent: 19 October 2017 20:50
To: Andrey Mokhov <andrey.mokhov at newcastle.ac.uk>; Boespflug, Mathieu <m at tweag.io>
Cc: Manuel M T Chakravarty <manuel.chakravarty at tweag.io>; Moritz Angermann <moritz.angermann at gmail.com>; Jonas Pfenniger Chevalier <jonas.chevalier at tweag.io>; ghc-devs <ghc-devs at haskell.org>
Subject: RE: Hadrian

Andrey Mokhov <andrey.mokhov at newcastle.ac.uk> writes:

> Hi Mathieu,
>
> Yes, in principle we can merge right now, as long as it's clear that Hadrian still requires more work before taking over.
>
> My only concern is that merging will make it more difficult for us to
> quickly iterate on Hadrian: the GitHub workflow is more convenient (at
> least for me) than the Phabricator one. Perhaps, we can keep Hadrian
> on GitHub as a submodule? This also has the advantage that we can keep
> all existing references to GitHub issues/PRs without migrating
> everything to GHC Trac. It would be very unfortunate to lose all
> history during the merge.
>
Okay, so if we want to preserve history then I would suggest that we go
the subtree route. That is pretty much precisely the use-case which
git subtree was designed to address. This will allow us to have Hadrian,
with history, in the GHC tree and you can continue to develop it on
GitHub until things have stabilized. The only question is how to ensure
that the subtree remains up-to-date.

Cheers,

- Ben

From ben at well-typed.com  Thu Oct 19 20:49:50 2017
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 19 Oct 2017 16:49:50 -0400
Subject: Hadrian
In-Reply-To: <WM!38af6b1a9bf4ef69781f5bb98d0a86743bc8265bc9c5a566aae1b11b9bbef06dd466a05debd921411d6b217722a4b0e8!@mailhub-mx4.ncl.ac.uk>
References: <934D286F-94B2-4680-BFBF-D32AAD41F2C7@tweag.io>
 <87r2tzp6wf.fsf@ben-laptop.smart-cactus.org>
 <DB6PR07MB327271FE78DA50F638A71D8DA5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!0aaa5dc0feb00696997f8b8e77a546115a480a222a4f8c8c3d2bb14632a09efc3c69166fc834a238c16a2f5a5316d1a0!@mailhub-mx4.ncl.ac.uk>
 <WM!40cb2e014e07f6550f3c8c5f10479866652ad41ac6ba2333f4913362e27f61eb5fe41e0cb082b2a3f6f14f196f940550!@mailhub-mx2.ncl.ac.uk>
 <CAJ0eudp4rZxyFRQqbvqN+zkC0xHs=edjv5MTicWW72yR84FXaw@mail.gmail.com>
 <WM!6fd32fd91c7b792358448335a67e70000dc6ea5527a174cf8dbc0997efc5f86bd50120a6cf23b3238a6441c92870c55f!@mailhub-mx5.ncl.ac.uk>
 <DB6PR07MB32721FE19812BF7519F08550A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!253cf6ed6c41c94fc7395ffada2a7327e62a36ea7e400abbfc58f37d5e4a33f3198f9302ade085a5cff11626941104df!@mailhub-mx4.ncl.ac.uk>
 <87lgk6q5nn.fsf@ben-laptop.smart-cactus.org>
 <WM!583df3cf63acfbcae9033b06ade9021cde1dfbd3325ac787f71d841edbc36cda82ef286ae9b471b84820eadf6ea4e292!@mailhub-mx2.ncl.ac.uk>
 <DB6PR07MB3272BD0A5C88640F2119CE49A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!38af6b1a9bf4ef69781f5bb98d0a86743bc8265bc9c5a566aae1b11b9bbef06dd466a05debd921411d6b217722a4b0e8!@mailhub-mx4.ncl.ac.uk>
Message-ID: <87infaq2vl.fsf@ben-laptop.smart-cactus.org>

Andrey Mokhov <andrey.mokhov at newcastle.ac.uk> writes:

> Thanks Ben,
>
> Just to clarify: By history I mean not just commits, but GitHub issues
> and PRs as well -- together they contain a lot of valuable interlinked
> information for GHC/Hadrian developers.
>
Well, the GitHub repo will still exist. Is that enough?

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171019/c64d2325/attachment.sig>

From andrey.mokhov at newcastle.ac.uk  Thu Oct 19 23:06:21 2017
From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov)
Date: Thu, 19 Oct 2017 23:06:21 +0000
Subject: Hadrian
In-Reply-To: <WM!b894c406bbe585b86a5917214c8d931ae8b5aabc271b72cd7dc6d32dc287d3bb67174185883dba9175c97595df840fff!@mailhub-mx3.ncl.ac.uk>
References: <934D286F-94B2-4680-BFBF-D32AAD41F2C7@tweag.io>
 <87r2tzp6wf.fsf@ben-laptop.smart-cactus.org>
 <DB6PR07MB327271FE78DA50F638A71D8DA5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!0aaa5dc0feb00696997f8b8e77a546115a480a222a4f8c8c3d2bb14632a09efc3c69166fc834a238c16a2f5a5316d1a0!@mailhub-mx4.ncl.ac.uk>
 <WM!40cb2e014e07f6550f3c8c5f10479866652ad41ac6ba2333f4913362e27f61eb5fe41e0cb082b2a3f6f14f196f940550!@mailhub-mx2.ncl.ac.uk>
 <CAJ0eudp4rZxyFRQqbvqN+zkC0xHs=edjv5MTicWW72yR84FXaw@mail.gmail.com>
 <WM!6fd32fd91c7b792358448335a67e70000dc6ea5527a174cf8dbc0997efc5f86bd50120a6cf23b3238a6441c92870c55f!@mailhub-mx5.ncl.ac.uk>
 <DB6PR07MB32721FE19812BF7519F08550A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!253cf6ed6c41c94fc7395ffada2a7327e62a36ea7e400abbfc58f37d5e4a33f3198f9302ade085a5cff11626941104df!@mailhub-mx4.ncl.ac.uk>
 <87lgk6q5nn.fsf@ben-laptop.smart-cactus.org>
 <WM!583df3cf63acfbcae9033b06ade9021cde1dfbd3325ac787f71d841edbc36cda82ef286ae9b471b84820eadf6ea4e292!@mailhub-mx2.ncl.ac.uk>
 <DB6PR07MB3272BD0A5C88640F2119CE49A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!38af6b1a9bf4ef69781f5bb98d0a86743bc8265bc9c5a566aae1b11b9bbef06dd466a05debd921411d6b217722a4b0e8!@mailhub-mx4.ncl.ac.uk>
 <87infaq2vl.fsf@ben-laptop.smart-cactus.org>
 <WM!b894c406bbe585b86a5917214c8d931ae8b5aabc271b72cd7dc6d32dc287d3bb67174185883dba9175c97595df840fff!@mailhub-mx3.ncl.ac.uk>
 <DB6PR07MB327264363A00B81A0E86F915A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
Message-ID: <WM!e2ab8cbd20f7037ad6301d027c70b167ead3a570088d6a50b8a22ef8d392d7b82515a62456c0f16f142797f5e85e13b6!@mailhub-mx5.ncl.ac.uk>

Hi Ben,

> Well, the GitHub repo will still exist. Is that enough?

Yes, but I think I'll need to do some clean up in the code so that it's obvious where to look for answers. For example, here is a random comment from a Hadrian source file:

-- Objdump is only required on OpenBSD and AIX, as mentioned in #211.

The reader might confuse this with GHC ticket #211, so I guess this should be replaced with a full link https://github.com/snowleopard/hadrian/issues/211. There may be other potential pitfalls, but hopefully nothing difficult to handle.

I've created an issue to discuss and prepare for the merge: https://github.com/snowleopard/hadrian/issues/440. 

Cheers,
Andrey

-----Original Message-----
From: Ben Gamari [mailto:ben at well-typed.com] 
Sent: 19 October 2017 21:50
To: Andrey Mokhov <andrey.mokhov at newcastle.ac.uk>; Boespflug, Mathieu <m at tweag.io>
Cc: Jonas Pfenniger Chevalier <jonas.chevalier at tweag.io>; Manuel M T Chakravarty <manuel.chakravarty at tweag.io>; ghc-devs <ghc-devs at haskell.org>
Subject: RE: Hadrian

Andrey Mokhov <andrey.mokhov at newcastle.ac.uk> writes:

> Thanks Ben,
>
> Just to clarify: By history I mean not just commits, but GitHub issues
> and PRs as well -- together they contain a lot of valuable interlinked
> information for GHC/Hadrian developers.
>
Well, the GitHub repo will still exist. Is that enough?

Cheers,

- Ben


From moritz at lichtzwerge.de  Fri Oct 20 01:32:29 2017
From: moritz at lichtzwerge.de (Moritz Angermann)
Date: Fri, 20 Oct 2017 09:32:29 +0800
Subject: Hadrian
In-Reply-To: <WM!e2ab8cbd20f7037ad6301d027c70b167ead3a570088d6a50b8a22ef8d392d7b82515a62456c0f16f142797f5e85e13b6!@mailhub-mx5.ncl.ac.uk>
References: <934D286F-94B2-4680-BFBF-D32AAD41F2C7@tweag.io>
 <87r2tzp6wf.fsf@ben-laptop.smart-cactus.org>
 <DB6PR07MB327271FE78DA50F638A71D8DA5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!0aaa5dc0feb00696997f8b8e77a546115a480a222a4f8c8c3d2bb14632a09efc3c69166fc834a238c16a2f5a5316d1a0!@mailhub-mx4.ncl.ac.uk>
 <WM!40cb2e014e07f6550f3c8c5f10479866652ad41ac6ba2333f4913362e27f61eb5fe41e0cb082b2a3f6f14f196f940550!@mailhub-mx2.ncl.ac.uk>
 <CAJ0eudp4rZxyFRQqbvqN+zkC0xHs=edjv5MTicWW72yR84FXaw@mail.gmail.com>
 <WM!6fd32fd91c7b792358448335a67e70000dc6ea5527a174cf8dbc0997efc5f86bd50120a6cf23b3238a6441c92870c55f!@mailhub-mx5.ncl.ac.uk>
 <DB6PR07MB32721FE19812BF7519F08550A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!253cf6ed6c41c94fc7395ffada2a7327e62a36ea7e400abbfc58f37d5e4a33f3198f9302ade085a5cff11626941104df!@mailhub-mx4.ncl.ac.uk>
 <87lgk6q5nn.fsf@ben-laptop.smart-cactus.org>
 <WM!583df3cf63acfbcae9033b06ade9021cde1dfbd3325ac787f71d841edbc36cda82ef286ae9b471b84820eadf6ea4e292!@mailhub-mx2.ncl.ac.uk>
 <DB6PR07MB3272BD0A5C88640F2119CE49A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!38af6b1a9bf4ef69781f5bb98d0a86743bc8265bc9c5a566aae1b11b9bbef06dd466a05debd921411d6b217722a4b0e8!@mailhub-mx4.ncl.ac.uk>
 <87infaq2vl.fsf@ben-laptop.smart-cactus.org>
 <WM!b894c406bbe585b86a5917214c8d931ae8b5aabc271b72cd7dc6d32dc287d3bb67174185883dba9175c97595df840fff!@mailhub-mx3.ncl.ac.uk>
 <DB6PR07MB327264363A00B81A0E86F915A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!e2ab8cbd20f7037ad6301d027c70b167ead3a570088d6a50b8a22ef8d392d7b82515a62456c0f16f142797f5e85e13b6!@mailhub-mx5.ncl.ac.uk>
Message-ID: <B07481BA-9089-4BAD-AD49-1A6510676B8A@lichtzwerge.de>

Hi,

two things.

a) why a git subtree if we keep working on github with hadrian, wouldn't that imply using a submodule? We use submodules for 
   all the other ghc boot libs that are not part of the tree and are developed on github as well, no? As far as I understand
   a subtree, it's essentially integrating everything into the main tree.  So this looks more like the submodule to subtree
   conversion, when hadrian development is switched over to phabricator?
b) should we really hardcode the full url to hadrian tickets? wouldn't hadrian/#xxx suffice? Assuming for a moment hadrian
   would move into the github.com/haskell org or something, while the linkes would likely (due to githubs url redirection)
   keep on working, until someone recreates a snowleopard/hardian repo, but not necessarily correct anymore.

Anyway, let's do this now rather than later. 

Cheers,
 moritz

> On Oct 20, 2017, at 7:06 AM, Andrey Mokhov <andrey.mokhov at newcastle.ac.uk> wrote:
> 
> Hi Ben,
> 
>> Well, the GitHub repo will still exist. Is that enough?
> 
> Yes, but I think I'll need to do some clean up in the code so that it's obvious where to look for answers. For example, here is a random comment from a Hadrian source file:
> 
> -- Objdump is only required on OpenBSD and AIX, as mentioned in #211.
> 
> The reader might confuse this with GHC ticket #211, so I guess this should be replaced with a full link https://github.com/snowleopard/hadrian/issues/211. There may be other potential pitfalls, but hopefully nothing difficult to handle.
> 
> I've created an issue to discuss and prepare for the merge: https://github.com/snowleopard/hadrian/issues/440. 
> 
> Cheers,
> Andrey
> 
> -----Original Message-----
> From: Ben Gamari [mailto:ben at well-typed.com] 
> Sent: 19 October 2017 21:50
> To: Andrey Mokhov <andrey.mokhov at newcastle.ac.uk>; Boespflug, Mathieu <m at tweag.io>
> Cc: Jonas Pfenniger Chevalier <jonas.chevalier at tweag.io>; Manuel M T Chakravarty <manuel.chakravarty at tweag.io>; ghc-devs <ghc-devs at haskell.org>
> Subject: RE: Hadrian
> 
> Andrey Mokhov <andrey.mokhov at newcastle.ac.uk> writes:
> 
>> Thanks Ben,
>> 
>> Just to clarify: By history I mean not just commits, but GitHub issues
>> and PRs as well -- together they contain a lot of valuable interlinked
>> information for GHC/Hadrian developers.
>> 
> Well, the GitHub repo will still exist. Is that enough?
> 
> Cheers,
> 
> - Ben
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From hvriedel at gmail.com  Fri Oct 20 10:24:29 2017
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Fri, 20 Oct 2017 12:24:29 +0200
Subject: Hadrian
In-Reply-To: <B07481BA-9089-4BAD-AD49-1A6510676B8A@lichtzwerge.de> (Moritz
 Angermann's message of "Fri, 20 Oct 2017 09:32:29 +0800")
References: <934D286F-94B2-4680-BFBF-D32AAD41F2C7@tweag.io>
 <87r2tzp6wf.fsf@ben-laptop.smart-cactus.org>
 <DB6PR07MB327271FE78DA50F638A71D8DA5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!0aaa5dc0feb00696997f8b8e77a546115a480a222a4f8c8c3d2bb14632a09efc3c69166fc834a238c16a2f5a5316d1a0!@mailhub-mx4.ncl.ac.uk>
 <WM!40cb2e014e07f6550f3c8c5f10479866652ad41ac6ba2333f4913362e27f61eb5fe41e0cb082b2a3f6f14f196f940550!@mailhub-mx2.ncl.ac.uk>
 <CAJ0eudp4rZxyFRQqbvqN+zkC0xHs=edjv5MTicWW72yR84FXaw@mail.gmail.com>
 <WM!6fd32fd91c7b792358448335a67e70000dc6ea5527a174cf8dbc0997efc5f86bd50120a6cf23b3238a6441c92870c55f!@mailhub-mx5.ncl.ac.uk>
 <DB6PR07MB32721FE19812BF7519F08550A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!253cf6ed6c41c94fc7395ffada2a7327e62a36ea7e400abbfc58f37d5e4a33f3198f9302ade085a5cff11626941104df!@mailhub-mx4.ncl.ac.uk>
 <87lgk6q5nn.fsf@ben-laptop.smart-cactus.org>
 <WM!583df3cf63acfbcae9033b06ade9021cde1dfbd3325ac787f71d841edbc36cda82ef286ae9b471b84820eadf6ea4e292!@mailhub-mx2.ncl.ac.uk>
 <DB6PR07MB3272BD0A5C88640F2119CE49A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!38af6b1a9bf4ef69781f5bb98d0a86743bc8265bc9c5a566aae1b11b9bbef06dd466a05debd921411d6b217722a4b0e8!@mailhub-mx4.ncl.ac.uk>
 <87infaq2vl.fsf@ben-laptop.smart-cactus.org>
 <WM!b894c406bbe585b86a5917214c8d931ae8b5aabc271b72cd7dc6d32dc287d3bb67174185883dba9175c97595df840fff!@mailhub-mx3.ncl.ac.uk>
 <DB6PR07MB327264363A00B81A0E86F915A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!e2ab8cbd20f7037ad6301d027c70b167ead3a570088d6a50b8a22ef8d392d7b82515a62456c0f16f142797f5e85e13b6!@mailhub-mx5.ncl.ac.uk>
 <B07481BA-9089-4BAD-AD49-1A6510676B8A@lichtzwerge.de>
Message-ID: <87tvyunmle.fsf@gmail.com>

Hi Moritz (et al.),

On 2017-10-20 at 09:32:29 +0800, Moritz Angermann wrote:

> a) why a git subtree if we keep working on github with hadrian, wouldn't that imply using a submodule? We use submodules for 
>    all the other ghc boot libs that are not part of the tree and are developed on github as well, no? As far as I understand
>    a subtree, it's essentially integrating everything into the main tree.  So this looks more like the submodule to subtree
>    conversion, when hadrian development is switched over to phabricator?

Fwiw, using a submodule makes sense imho if hadrian is supposed to
remain a submodule on the long-term; as transitioning from submodule <->
non-submodule is something Git doesn't handle to well automatically
(we've had fun with that when we restructured ghc.git into the current
structure...)

Also, a submodule has the benefit of ticket references clearly referring
to a different numbering namespace w/o having to rewrite all ticket &
commit-hash references (which is often overlooked; I for one tend to
refer quite often to other commit shas in my commits, and they also
result when you 'git cherry-pick -x')

So, what's the long-term plan for Hadrian repo-wise? Is it going to
remain externally maintained on GitHub, or will it be integrated into
GHC HQ's infrastucture which means using Phabricator (which may pose its
own challenge, as Phabricator, like Trac, uses globally unique ticket
numbers, rather than per-project numbering)?

If it is to be a submodule, we (and by that I mean myself; it doesn't
take long) also need to setup mirroring from snowleopard/hardian to
git://git.haskell.org, and from there to to github.com/ghc/hadrian for
technical reasons.

> b) should we really hardcode the full url to hadrian tickets? wouldn't hadrian/#xxx suffice? Assuming for a moment hadrian
>    would move into the github.com/haskell org or something, while the linkes would likely (due to githubs url redirection)
>    keep on working, until someone recreates a snowleopard/hardian
>    repo, but not necessarily correct anymore.

Note that GitHub doesn't support the abbreviated hadrian#xxx syntax; you
*have* to prefix it by the organization/user, in order for GitHub to
recognize a ticket reference; i.e. you *have* to use one of


- https://github.com/snowleopard/hadrian/issues/123  (or possibly .../pull/123)

- snowleopard/hadrian#123

- #123

- GH-123

for GitHub to recognize the issue reference.

anything else won't be recognized.

Moreover, github.com/haskell/ is not a good place for Hadrian since it's
a too GHC-specific tooling; if anywhere, it would rather end up together
with the other GHC repos in the /ghc/ org at
https://github.com/ghc/hadrian (or something slightly different; we need
reconcile this with our GHC mirroring scheme; that's may be a bit
tricky).

-- hvr

From moritz at lichtzwerge.de  Fri Oct 20 10:59:34 2017
From: moritz at lichtzwerge.de (Moritz Angermann)
Date: Fri, 20 Oct 2017 18:59:34 +0800
Subject: Hadrian
In-Reply-To: <87tvyunmle.fsf@gmail.com>
References: <934D286F-94B2-4680-BFBF-D32AAD41F2C7@tweag.io>
 <87r2tzp6wf.fsf@ben-laptop.smart-cactus.org>
 <DB6PR07MB327271FE78DA50F638A71D8DA5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!0aaa5dc0feb00696997f8b8e77a546115a480a222a4f8c8c3d2bb14632a09efc3c69166fc834a238c16a2f5a5316d1a0!@mailhub-mx4.ncl.ac.uk>
 <WM!40cb2e014e07f6550f3c8c5f10479866652ad41ac6ba2333f4913362e27f61eb5fe41e0cb082b2a3f6f14f196f940550!@mailhub-mx2.ncl.ac.uk>
 <CAJ0eudp4rZxyFRQqbvqN+zkC0xHs=edjv5MTicWW72yR84FXaw@mail.gmail.com>
 <WM!6fd32fd91c7b792358448335a67e70000dc6ea5527a174cf8dbc0997efc5f86bd50120a6cf23b3238a6441c92870c55f!@mailhub-mx5.ncl.ac.uk>
 <DB6PR07MB32721FE19812BF7519F08550A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!253cf6ed6c41c94fc7395ffada2a7327e62a36ea7e400abbfc58f37d5e4a33f3198f9302ade085a5cff11626941104df!@mailhub-mx4.ncl.ac.uk>
 <87lgk6q5nn.fsf@ben-laptop.smart-cactus.org>
 <WM!583df3cf63acfbcae9033b06ade9021cde1dfbd3325ac787f71d841edbc36cda82ef286ae9b471b84820eadf6ea4e292!@mailhub-mx2.ncl.ac.uk>
 <DB6PR07MB3272BD0A5C88640F2119CE49A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!38af6b1a9bf4ef69781f5bb98d0a86743bc8265bc9c5a566aae1b11b9bbef06dd466a05debd921411d6b217722a4b0e8!@mailhub-mx4.ncl.ac.uk>
 <87infaq2vl.fsf@ben-laptop.smart-cactus.org>
 <WM!b894c406bbe585b86a5917214c8d931ae8b5aabc271b72cd7dc6d32dc287d3bb67174185883dba9175c97595df840fff!@mailhub-mx3.ncl.ac.uk>
 <DB6PR07MB327264363A00B81A0E86F915A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!e2ab8cbd20f7037ad6301d027c70b167ead3a570088d6a50b8a22ef8d392d7b82515a62456c0f16f142797f5e85e13b6!@mailhub-mx5.ncl.ac.uk>
 <B07481BA-9089-4BAD-AD49-1A6510676B8A@lichtzwerge.de>
 <87tvyunmle.fsf@gmail.com>
Message-ID: <66C67108-7ECF-40B9-B9C3-C4F7A607F33F@lichtzwerge.de>


> On Oct 20, 2017, at 6:24 PM, Herbert Valerio Riedel <hvriedel at gmail.com> wrote:
> 
> Hi Moritz (et al.),
> 
> On 2017-10-20 at 09:32:29 +0800, Moritz Angermann wrote:
> 
>> a) why a git subtree if we keep working on github with hadrian, wouldn't that imply using a submodule? We use submodules for 
>>   all the other ghc boot libs that are not part of the tree and are developed on github as well, no? As far as I understand
>>   a subtree, it's essentially integrating everything into the main tree.  So this looks more like the submodule to subtree
>>   conversion, when hadrian development is switched over to phabricator?
> 
> Fwiw, using a submodule makes sense imho if hadrian is supposed to
> remain a submodule on the long-term; as transitioning from submodule <->
> non-submodule is something Git doesn't handle to well automatically
> (we've had fun with that when we restructured ghc.git into the current
> structure...)
> 
> Also, a submodule has the benefit of ticket references clearly referring
> to a different numbering namespace w/o having to rewrite all ticket &
> commit-hash references (which is often overlooked; I for one tend to
> refer quite often to other commit shas in my commits, and they also
> result when you 'git cherry-pick -x')
> 
> So, what's the long-term plan for Hadrian repo-wise? Is it going to
> remain externally maintained on GitHub, or will it be integrated into
> GHC HQ's infrastucture which means using Phabricator (which may pose its
> own challenge, as Phabricator, like Trac, uses globally unique ticket
> numbers, rather than per-project numbering)?
> 
> If it is to be a submodule, we (and by that I mean myself; it doesn't
> take long) also need to setup mirroring from snowleopard/hardian to
> git://git.haskell.org, and from there to to github.com/ghc/hadrian for
> technical reasons.

I would assume that hadrian will be developed on github for a while, to not
disturb the current workflow. But I'm happy to be corrected, when wrong here. 
After reading up on git-subtree[1][2], which sounds to me like subsuming one
repo in another one and requiring a set of different commands to handle it.
Maybe I'm just too used to git submodules. But as all the other externals in
the ghc tree are submodules, I'd prefer the consistency.  Knowing myself, I'd
probably screw up pushing changes back upstream into hadrian if its workflow
is different from e.g. the libraries, ... libffi-tarballs with the orphan
branches is already something that needs to be taken special care of...

>> b) should we really hardcode the full url to hadrian tickets? wouldn't hadrian/#xxx suffice? Assuming for a moment hadrian
>>   would move into the github.com/haskell org or something, while the linkes would likely (due to githubs url redirection)
>>   keep on working, until someone recreates a snowleopard/hardian
>>   repo, but not necessarily correct anymore.
> 
> Note that GitHub doesn't support the abbreviated hadrian#xxx syntax; you
> *have* to prefix it by the organization/user, in order for GitHub to
> recognize a ticket reference; i.e. you *have* to use one of
> 
> 
> - https://github.com/snowleopard/hadrian/issues/123  (or possibly .../pull/123)
> 
> - snowleopard/hadrian#123
> 
> - #123
> 
> - GH-123
> 
> for GitHub to recognize the issue reference.
> 
> anything else won't be recognized.
> 
> Moreover, github.com/haskell/ is not a good place for Hadrian since it's
> a too GHC-specific tooling; if anywhere, it would rather end up together
> with the other GHC repos in the /ghc/ org at
> https://github.com/ghc/hadrian (or something slightly different; we need
> reconcile this with our GHC mirroring scheme; that's may be a bit
> tricky).

I didn't specifically care about github auto-linking features here. Primarily
about giving tickets a prefix. And not necessarily hardcoding some github url
into ticket numbers.

Cheers,
 Moritz

--
[1]: https://www.atlassian.com/blog/git/alternatives-to-git-submodule-git-subtree
[2]: http://alistra.ghost.io/2014/11/30/git-subtree-a-better-alternative-to-git-submodule/


From andrey.mokhov at newcastle.ac.uk  Fri Oct 20 11:36:37 2017
From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov)
Date: Fri, 20 Oct 2017 11:36:37 +0000
Subject: Hadrian
In-Reply-To: <WM!de24770c0626a67556fed6f71dc817a2abd35f433c12d9fbc75f1c60d8e7be95896cf6a64c5ec65d0ca4bf2c7cf2dc02!@mailhub-mx4.ncl.ac.uk>
References: <934D286F-94B2-4680-BFBF-D32AAD41F2C7@tweag.io>
 <87r2tzp6wf.fsf@ben-laptop.smart-cactus.org>
 <DB6PR07MB327271FE78DA50F638A71D8DA5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!0aaa5dc0feb00696997f8b8e77a546115a480a222a4f8c8c3d2bb14632a09efc3c69166fc834a238c16a2f5a5316d1a0!@mailhub-mx4.ncl.ac.uk>
 <WM!40cb2e014e07f6550f3c8c5f10479866652ad41ac6ba2333f4913362e27f61eb5fe41e0cb082b2a3f6f14f196f940550!@mailhub-mx2.ncl.ac.uk>
 <CAJ0eudp4rZxyFRQqbvqN+zkC0xHs=edjv5MTicWW72yR84FXaw@mail.gmail.com>
 <WM!6fd32fd91c7b792358448335a67e70000dc6ea5527a174cf8dbc0997efc5f86bd50120a6cf23b3238a6441c92870c55f!@mailhub-mx5.ncl.ac.uk>
 <DB6PR07MB32721FE19812BF7519F08550A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!253cf6ed6c41c94fc7395ffada2a7327e62a36ea7e400abbfc58f37d5e4a33f3198f9302ade085a5cff11626941104df!@mailhub-mx4.ncl.ac.uk>
 <87lgk6q5nn.fsf@ben-laptop.smart-cactus.org>
 <WM!583df3cf63acfbcae9033b06ade9021cde1dfbd3325ac787f71d841edbc36cda82ef286ae9b471b84820eadf6ea4e292!@mailhub-mx2.ncl.ac.uk>
 <DB6PR07MB3272BD0A5C88640F2119CE49A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!38af6b1a9bf4ef69781f5bb98d0a86743bc8265bc9c5a566aae1b11b9bbef06dd466a05debd921411d6b217722a4b0e8!@mailhub-mx4.ncl.ac.uk>
 <87infaq2vl.fsf@ben-laptop.smart-cactus.org>
 <WM!b894c406bbe585b86a5917214c8d931ae8b5aabc271b72cd7dc6d32dc287d3bb67174185883dba9175c97595df840fff!@mailhub-mx3.ncl.ac.uk>
 <DB6PR07MB327264363A00B81A0E86F915A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!e2ab8cbd20f7037ad6301d027c70b167ead3a570088d6a50b8a22ef8d392d7b82515a62456c0f16f142797f5e85e13b6!@mailhub-mx5.ncl.ac.uk>
 <B07481BA-9089-4BAD-AD49-1A6510676B8A@lichtzwerge.de>
 <87tvyunmle.fsf@gmail.com>
 <66C67108-7ECF-40B9-B9C3-C4F7A607F33F@lichtzwerge.de>
 <WM!de24770c0626a67556fed6f71dc817a2abd35f433c12d9fbc75f1c60d8e7be95896cf6a64c5ec65d0ca4bf2c7cf2dc02!@mailhub-mx4.ncl.ac.uk>
 <HE1PR07MB33562AD670C576F857451CA3A5430@HE1PR07MB3356.eurprd07.prod.outlook.com>
Message-ID: <WM!3af28740e150b0f664e4c81d6b0053b10a3de7e436d1c1eb0ae18bbb46567dfdfa6c72315cc7aef0b90d63af9fa5b219!@mailhub-mx5.ncl.ac.uk>

Hi Moritz and Herbert,

Thank you for detailed comments! We clearly need to carefully think through our options for merging Hadrian.

Can I invite you both and everyone else to continue the discussion in https://github.com/snowleopard/hadrian/issues/440? Long email threads tend to become hard to read/follow and get lost. 

In my view, the two most important requirements in the long term are:

1) Preserving the commit/issue/pull-request history. A GHC developer fighting a strange build failure should be able to find a relevant discussion not only now but in 5 years from now. This may be solved via documentation, i.e. gradually moving all discussions from GitHub to docs/comments. That's a lot of hard work.

2) Making it convenient for GHC developers to work on Hadrian. To me, git submodules are not convenient at all, but maybe there is just no other option given the requirement (1). Is git subtree a solution? 

Cheers,
Andrey


From simonpj at microsoft.com  Fri Oct 20 13:42:38 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 20 Oct 2017 13:42:38 +0000
Subject: Determine instance method from class method callsite
In-Reply-To: <743881b0-05f9-e57e-9e24-d77e69c7cb3d@gmail.com>
References: <743881b0-05f9-e57e-9e24-d77e69c7cb3d@gmail.com>
Message-ID: <AM4PR83MB003356F9701AFAE554A1E4EAAD430@AM4PR83MB0033.EURPRD83.prod.outlook.com>

|  lookupInstEnv from the InstEnv module seemed to do it, but it seems to
|  look up the matching key from a set of instEnv keys and not anything
|  that contains the instance bindr. Not sure.

I couldn't understand this.  lookupInstEnv is probably what you want.  It returns a ClsInstLookupResult

type InstMatch = (ClsInst, [DFunInstType])

type ClsInstLookupResult
     = ( [InstMatch]     -- Successful matches
       , [ClsInst]       -- These don't match but do unify
       , [InstMatch] )   -- Unsafe overlapped instances under Safe Haskell
                         -- (see Note [Safe Haskell Overlapping Instances] in
                         -- TcSimplify).

Inside the ClsInst of the InstMatches you'll find a DFunId, which is (I think) what you are after.

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Tillmann Vogt via ghc-devs
|  Sent: 19 October 2017 18:13
|  To: ghc-devs at haskell.org
|  Subject: Re: Determine instance method from class method callsite
|  
|  I have the same problem  with a compiler plugin that I am writing.
|  
|  In GHC Core I need to get from a dict-fun identifier (e.g.
|  $fMyClassDouble to the type class instance bindr (starting with $c).
|  
|  lookupInstEnv from the InstEnv module seemed to do it, but it seems to
|  look up the matching key from a set of instEnv keys and not anything
|  that contains the instance bindr. Not sure.
|  
|  Where is the dictionary lookup that gives me the bindr?
|  
|  What I did so far:
|  
|  evalExpr :: DynFlags -> ModGuts -> CoreExpr -> Var ->  CoreM NodeType
|  evalExpr dflags guts (Var iD) v = do
|  
|     hsc_env <- getHscEnv
|     eps <- liftIO (hscEPS hsc_env)
|     let instEnvs = InstEnvs (eps_inst_env     eps)
|                             (mg_inst_env     guts)
|                             (mkModuleSet (dep_orphs (mg_deps guts)))
|     let ty = tyConAppTyCon_maybe (idType iD)
|     let cl = fromJust (tyConClass_maybe (fromJust ty))
|     let tys = snd (splitTyConApp (idType iD))
|     let (matches,_,_) | isDictId iD = lookupInstEnv False instEnvs cl
|  tys
|                       | otherwise = ([],[],[])
|  
|     let inst = map (nameStableString . varName . is_dfun . fst) matches
|  
|     liftIO $ B.appendFile ("debug.txt") (B.pack (show inst))
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&data=02%7C01%7Csimonpj%40microsoft.com%7Caa82860ef55a428ab1e908d5
|  1714eb63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364403011206865
|  53&sdata=lpbVMttf5W7p%2FGIs3e5pTd6ZS0w4i%2BHwUr9ysRnuCBE%3D&reserved=0

From alan.zimm at gmail.com  Fri Oct 20 17:33:29 2017
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Fri, 20 Oct 2017 19:33:29 +0200
Subject: haddock specializeInstHead
Message-ID: <CANma=H8wuY9np-xUkEei-JrJvSAWouXQsZ3PaH97Adx2WpaD1Q@mail.gmail.com>

I am working the next stage of Trees that Grow into GHC [1], and need to
update Haddock.

The `Specialize` module[2] exports a single function, `specializeInstHead`
which is called once, specialised to `GhcRn`.

So all it needs to be for haddock use is

specializeInstHead :: InstHead GhcRn -> InstHead GhcRn

But the entire module is polymorphic in the AST parameter, so it has the
following instead

specializeInstHead :: (Ord (IdP name), DataId name, SetName (IdP name),
                                NamedThing (IdP name))
                       => InstHead name -> InstHead name

Question: does it need to be so polymorphic?

I am hitting issues getting the type parameter change worked through, and
it seems a bit pointless to slog on with it if it is unnecessary.

Alan

[1] https://github.com/ghc/ghc/tree/wip/ttg-2017-10-13
[2]
https://github.com/haskell/haddock/blob/a5bdb46185b7c0b3fced9a7fac9a62883d9d57b7/haddock-api/src/Haddock/Interface/Specialize.hs#L87
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171020/2aa302f6/attachment.html>

From ben at smart-cactus.org  Fri Oct 20 18:10:28 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Fri, 20 Oct 2017 14:10:28 -0400
Subject: Hadrian
In-Reply-To: <WM!3af28740e150b0f664e4c81d6b0053b10a3de7e436d1c1eb0ae18bbb46567dfdfa6c72315cc7aef0b90d63af9fa5b219!@mailhub-mx5.ncl.ac.uk>
References: <934D286F-94B2-4680-BFBF-D32AAD41F2C7@tweag.io>
 <WM!0aaa5dc0feb00696997f8b8e77a546115a480a222a4f8c8c3d2bb14632a09efc3c69166fc834a238c16a2f5a5316d1a0!@mailhub-mx4.ncl.ac.uk>
 <WM!40cb2e014e07f6550f3c8c5f10479866652ad41ac6ba2333f4913362e27f61eb5fe41e0cb082b2a3f6f14f196f940550!@mailhub-mx2.ncl.ac.uk>
 <CAJ0eudp4rZxyFRQqbvqN+zkC0xHs=edjv5MTicWW72yR84FXaw@mail.gmail.com>
 <WM!6fd32fd91c7b792358448335a67e70000dc6ea5527a174cf8dbc0997efc5f86bd50120a6cf23b3238a6441c92870c55f!@mailhub-mx5.ncl.ac.uk>
 <DB6PR07MB32721FE19812BF7519F08550A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!253cf6ed6c41c94fc7395ffada2a7327e62a36ea7e400abbfc58f37d5e4a33f3198f9302ade085a5cff11626941104df!@mailhub-mx4.ncl.ac.uk>
 <87lgk6q5nn.fsf@ben-laptop.smart-cactus.org>
 <WM!583df3cf63acfbcae9033b06ade9021cde1dfbd3325ac787f71d841edbc36cda82ef286ae9b471b84820eadf6ea4e292!@mailhub-mx2.ncl.ac.uk>
 <DB6PR07MB3272BD0A5C88640F2119CE49A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!38af6b1a9bf4ef69781f5bb98d0a86743bc8265bc9c5a566aae1b11b9bbef06dd466a05debd921411d6b217722a4b0e8!@mailhub-mx4.ncl.ac.uk>
 <87infaq2vl.fsf@ben-laptop.smart-cactus.org>
 <WM!b894c406bbe585b86a5917214c8d931ae8b5aabc271b72cd7dc6d32dc287d3bb67174185883dba9175c97595df840fff!@mailhub-mx3.ncl.ac.uk>
 <DB6PR07MB327264363A00B81A0E86F915A5420@DB6PR07MB3272.eurprd07.prod.outlook.com>
 <WM!e2ab8cbd20f7037ad6301d027c70b167ead3a570088d6a50b8a22ef8d392d7b82515a62456c0f16f142797f5e85e13b6!@mailhub-mx5.ncl.ac.uk>
 <B07481BA-9089-4BAD-AD49-1A6510676B8A@lichtzwerge.de>
 <87tvyunmle.fsf@gmail.com>
 <66C67108-7ECF-40B9-B9C3-C4F7A607F33F@lichtzwerge.de>
 <WM!de24770c0626a67556fed6f71dc817a2abd35f433c12d9fbc75f1c60d8e7be95896cf6a64c5ec65d0ca4bf2c7cf2dc02!@mailhub-mx4.ncl.ac.uk>
 <HE1PR07MB33562AD670C576F857451CA3A5430@HE1PR07MB3356.eurprd07.prod.outlook.com>
 <WM!3af28740e150b0f664e4c81d6b0053b10a3de7e436d1c1eb0ae18bbb46567dfdfa6c72315cc7aef0b90d63af9fa5b219!@mailhub-mx5.ncl.ac.uk>
Message-ID: <8760b9pu5n.fsf@ben-laptop.smart-cactus.org>

Andrey Mokhov <andrey.mokhov at newcastle.ac.uk> writes:

> Hi Moritz and Herbert,
>
> Thank you for detailed comments! We clearly need to carefully think through our options for merging Hadrian.
>
> Can I invite you both and everyone else to continue the discussion in
> https://github.com/snowleopard/hadrian/issues/440? Long email threads
> tend to become hard to read/follow and get lost.
>
Yes, let's pick this up on the ticket.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171020/dd1c2106/attachment.sig>

From simonpj at microsoft.com  Fri Oct 20 20:43:19 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 20 Oct 2017 20:43:19 +0000
Subject: More windows
In-Reply-To: <87po9tltir.fsf@ben-laptop.smart-cactus.org>
References: <AM4PR83MB0033115CEDF01DB5AF3CC0E8AD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CABHktDXQHijJbxur2LdksQmLxMHQD72Pp69Ubig++++48fgvWg@mail.gmail.com>
 <AM4PR83MB00336B5A5BD670551F54F59BAD730@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <AM4PR83MB0033A9427C6E6088D707878DAD750@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <87po9tltir.fsf@ben-laptop.smart-cactus.org>
Message-ID: <AM4PR83MB00334C024C1E54A193FF9973AD430@AM4PR83MB0033.EURPRD83.prod.outlook.com>

Oddly it's started working.   I have no idea why.  I'll yell if it breaks again.

Simon

| -----Original Message-----
| From: Ben Gamari [mailto:ben at well-typed.com]
| Sent: 11 October 2017 14:11
| To: Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org>; Simon Peyton
| Jones <simonpj at microsoft.com>; GHC developers <ghc-devs at haskell.org>
| Subject: RE: More windows
| 
| Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:
| 
| > Any ideas anyone? When I restart the build, it gets past the blockage
| > (which seems highly specific). But it’s jolly annoying.
| >
| Hi Simon,
| 
| Perhaps let's try this,
| 
|  1. download and run the procmon tool from [1]
|  2. from the "Filter" menu select the "Filter..." option
|  3. select "Path" in the first drop-down
|  4. select "contains" in the second drop-down
|  5. enter "ghc-cabal.exe" in the third text box
|  6. select "Include in the fourth drop-down
|  8. click the "Add" button
|  7. click the "Ok" button
| 
| Now you should be logging events pertaining to the file in question. Now
| simply run `./validate` to try to reproduce the issue.
| 
| With luck this will produce a handful of events, some of which ought to
| point to the process that it responsible for meddling with the GHC
| build.
| 
| Now export this log,
| 
|  1. select "Save" from the "File" menu
|  2. select the "Events displayed using current filter" option
|  3. select the "CSV" format, select a path that will be easy to file
|  4. return this file to me (perhaps via GitHub Gist [2]?)
| 
| Hopefully this will give us some insight into what is happening.
| 
| Cheers,
| 
| - Ben
| 
| 
| [1] https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
| [2] https://gist.github.com/

From rae at cs.brynmawr.edu  Fri Oct 20 21:43:38 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 20 Oct 2017 17:43:38 -0400
Subject: splitting metavariables
Message-ID: <B30CDF34-06EA-4DEC-81F6-E8D80178CD81@cs.brynmawr.edu>

Hi Simon,

I just commented (https://ghc.haskell.org/trac/ghc/ticket/14331#comment:35) about a situation where we call splitFunTys on a type that might be a metavariable. (You don't have to read the comment -- that's just to set the context.) Now that I think of it, we should never call the splitXXX functions on metavariables -- any time we do so is wrong. I suppose it's OK if we, say, call splitTyConApp_maybe on (T alpha beta gamma), because we never look through the metavariables there. But it can't possible be write to call splitTyConApp_maybe on alpha.

Do you agree? Should we ASSERT that we don't do this?

The tcXXX variants are no different in this regard.

Actually, I wonder if we can put the check in just one spot: coreView. Whenever we use coreView, we're about to inspect a type. And we should never be inspecting a metavariable in this way.

Richard

From shiftag at nanotek.info  Sat Oct 21 10:02:24 2017
From: shiftag at nanotek.info (shiftag at nanotek.info)
Date: Sat, 21 Oct 2017 10:02:24 +0000
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <78ec0450a4ec73600c555d6e538f3a40@webmail.nanotek.info>
References: <78ec0450a4ec73600c555d6e538f3a40@webmail.nanotek.info>
 <57A4A430-4F5F-43AC-8C29-E69E7C8DD2E2@gmail.com>
 <9906A55A-FACD-4EE2-9623-BD59A3491B08@gmail.com>
 <87efq0qzkz.fsf@ben-laptop.smart-cactus.org>
 <87h8uxr4u4.fsf@ben-laptop.smart-cactus.org>
 <874lqzrro2.fsf@ben-laptop.smart-cactus.org>
 <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
 <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
 <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>
 <CAKFCL4WD4ZovhDBhkEcUFTgU6hUgXFdC9O+8sqxNpd+uSf6KvQ@mail.gmail.com>
 <57f2ac6fc4480efd6930251d44c5deb6@webmail.nanotek.info>
 <99e66bc4be7e42298f23158304106f22@webmail.nanotek.info>
 <d60b9e203dc3c49f9c0cbced968ad0b6@webmail.nanotek.info>
 <BFB9B6DF-997A-46C7-8B26-AC57E2B98F1D@gmail.com>
 <87tvyvp7f8.fsf@ben-laptop.smart-cactus.org>
Message-ID: <3c4df30f0b8e92ddc0d6fab809dc62f9@webmail.nanotek.info>

October 19, .0000000000000000000000000000000000000000000000000000000000000000000000µ2017
7:.0000000000000000000000000000000000000000000000000000000000000000000000µ34 PM,
shiftag at nanotek.info wrote:

> October 19, .0000000000000000000000000000000000000000000000000000000000000000000000µ2017
> 6:.0000000000000000000000000000000000000000000000000000000000000000000000ÿ8 PM, "Moritz Angermann"
> <moritz.angermann at gmail.com> wrote:
> 
>> Shiftag,
>> 
>> any chance you could try this with 8.2 again then?
> 
> Hi,
> 
> I'm going to try that and I will let you know ;)
> 
> Thanks guys.



Hi,

So I installed GHC-8.2.1 and then I tried to cross-compiling it. The ./configure went fine but the make :

# make
Run "make install" to install
Makefile:46: recipe for target 'default' failed
make: *** [default] Error 1


Hmm...did I forgot something ?

From saurabhnanda at gmail.com  Sat Oct 21 12:36:19 2017
From: saurabhnanda at gmail.com (Saurabh Nanda)
Date: Sat, 21 Oct 2017 18:06:19 +0530
Subject: Building on limited memory environments (or does -M really work?)
Message-ID: <CAPz=2oGF0Zvfb2fc7JBiyy3=dZOZkj1qH4hKzt419iNYJSNUPQ@mail.gmail.com>

Hi,

We're struggling to get our build pipeline working on CircleCI, which has a
4GB RAM limit. Here are some project stats to set the context:

- 1,200+ modules
- 36,315 LoC of Haskell
- On the local machine with -O1 -j the build takes approx 5.2 GB of RAM [1]

Trying to build on CircleCI with -O1 -j fails consistently, as expected.
However, the behaviour of -M -j -O1 is erratic, at best. Sometimes it
magically works, sometimes it fails. A number of times we've seen GHC take
3.5 GB (as reported by `top`), even though the limit was set to 2.5GB. Here
are flags that we've tried in various combinations we've tried. None of
them is consistent in building / failing:

* -O1
* -j
* +RTS -M2621440000 -RTS
* +RTS -A32m -RTS
* +RTS -n2m -RTS

What is the **real** behaviour of the -M option? How does it interact with
-j and -A?

[1] If I'm reading this correctly -
https://gist.github.com/saurabhnanda/c8f8654a7f29c1adb753b357b897b5f3#file-building-library-01-txt-L8-L12

-- Saurabh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171021/2abfa4e8/attachment.html>

From alan.zimm at gmail.com  Sat Oct 21 15:59:54 2017
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Sat, 21 Oct 2017 17:59:54 +0200
Subject: Wildcards in HsTypes
Message-ID: <CANma=H-xpKVQho2NHUetqGbb-xbEAS+OKzLNGFJ9YK9aE_yZpQ@mail.gmail.com>

It seems to me that HsWildCardInfo is unnecessary.

It is defined as

newtype HsWildCardInfo pass      -- See Note [The wildcard story for types]
    = AnonWildCard (PostRn pass (Located Name))
      -- A anonymous wild card ('_'). A fresh Name is generated for
      -- each individual anonymous wildcard during renaming

And only ever used in

data HsType pass
  ...
  | HsWildCardTy (HsWildCardInfo pass)

Why not just do

  | HsWildCardTy  (PostRn pass (Located Name))

?

Am I missing something?

Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171021/e340823f/attachment.html>

From shiftag at nanotek.info  Sat Oct 21 17:20:56 2017
From: shiftag at nanotek.info (shiftag at nanotek.info)
Date: Sat, 21 Oct 2017 17:20:56 +0000
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <3c4df30f0b8e92ddc0d6fab809dc62f9@webmail.nanotek.info>
References: <3c4df30f0b8e92ddc0d6fab809dc62f9@webmail.nanotek.info>
 <78ec0450a4ec73600c555d6e538f3a40@webmail.nanotek.info>
 <57A4A430-4F5F-43AC-8C29-E69E7C8DD2E2@gmail.com>
 <9906A55A-FACD-4EE2-9623-BD59A3491B08@gmail.com>
 <87efq0qzkz.fsf@ben-laptop.smart-cactus.org>
 <87h8uxr4u4.fsf@ben-laptop.smart-cactus.org>
 <874lqzrro2.fsf@ben-laptop.smart-cactus.org>
 <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
 <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
 <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>
 <CAKFCL4WD4ZovhDBhkEcUFTgU6hUgXFdC9O+8sqxNpd+uSf6KvQ@mail.gmail.com>
 <57f2ac6fc4480efd6930251d44c5deb6@webmail.nanotek.info>
 <99e66bc4be7e42298f23158304106f22@webmail.nanotek.info>
 <d60b9e203dc3c49f9c0cbced968ad0b6@webmail.nanotek.info>
 <BFB9B6DF-997A-46C7-8B26-AC57E2B98F1D@gmail.com>
 <87tvyvp7f8.fsf@ben-laptop.smart-cactus.org>
Message-ID: <999bf15c157a483563b8377377669d2a@webmail.nanotek.info>

October 21, .0000000000000000000000000000000000000000000000000000000000000000000000µ2017
2:.0000000000000000000000000000000000000000000000000000000000000000000000ÿ3 PM,
shiftag at nanotek.info wrote:

> October 19, .0000000000000000000000000000000000000000000000000000000000000000000000µ2017
> 7:.0000000000000000000000000000000000000000000000000000000000000000000000µ34 PM,
> shiftag at nanotek.info wrote:
> 
>> October 19, .0000000000000000000000000000000000000000000000000000000000000000000000µ2017
>> 6:.0000000000000000000000000000000000000000000000000000000000000000000000ÿ8 PM, "Moritz Angermann"
>> <moritz.angermann at gmail.com> wrote:
>> 
>>> Shiftag,
>>> 
>>> any chance you could try this with 8.2 again then?
>> 
>> Hi,
>> 
>> I'm going to try that and I will let you know ;)
>> 
>> Thanks guys.
> 
> Hi,
> 
> So I installed GHC-8.2.1 and then I tried to cross-compiling it. The ./configure went fine but the
> make :
> 
> # make
> Run "make install" to install
> Makefile:46: recipe for target 'default' failed
> make: *** [default] Error 1
> 
> Hmm...did I forgot something ?


Sorry my bad, I downloaded the wrong archive. Now its compiling, it should work.

From shiftag at nanotek.info  Sun Oct 22 06:33:45 2017
From: shiftag at nanotek.info (shiftag at nanotek.info)
Date: Sun, 22 Oct 2017 06:33:45 +0000
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <999bf15c157a483563b8377377669d2a@webmail.nanotek.info>
References: <999bf15c157a483563b8377377669d2a@webmail.nanotek.info>
 <3c4df30f0b8e92ddc0d6fab809dc62f9@webmail.nanotek.info>
 <78ec0450a4ec73600c555d6e538f3a40@webmail.nanotek.info>
 <57A4A430-4F5F-43AC-8C29-E69E7C8DD2E2@gmail.com>
 <9906A55A-FACD-4EE2-9623-BD59A3491B08@gmail.com>
 <87efq0qzkz.fsf@ben-laptop.smart-cactus.org>
 <87h8uxr4u4.fsf@ben-laptop.smart-cactus.org>
 <874lqzrro2.fsf@ben-laptop.smart-cactus.org>
 <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
 <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
 <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>
 <CAKFCL4WD4ZovhDBhkEcUFTgU6hUgXFdC9O+8sqxNpd+uSf6KvQ@mail.gmail.com>
 <57f2ac6fc4480efd6930251d44c5deb6@webmail.nanotek.info>
 <99e66bc4be7e42298f23158304106f22@webmail.nanotek.info>
 <d60b9e203dc3c49f9c0cbced968ad0b6@webmail.nanotek.info>
 <BFB9B6DF-997A-46C7-8B26-AC57E2B98F1D@gmail.com>
 <87tvyvp7f8.fsf@ben-laptop.smart-cactus.org>
Message-ID: <07f9c86c35bdc84fb584eeafe1e33b1d@webmail.nanotek.info>

October 21, 2017 9:21 PM, shiftag at nanotek.info wrote:

> October 21, .0000000000000000000000000000000000000000000000000000000000000000000000µ2017
> 2:.0000000000000000000000000000000000000000000000000000000000000000000000ÿ3 PM,
> shiftag at nanotek.info wrote:
> 
>> October 19, .0000000000000000000000000000000000000000000000000000000000000000000000µ2017
>> 7:.0000000000000000000000000000000000000000000000000000000000000000000000µ34 PM,
>> shiftag at nanotek.info wrote:
>> 
>>> October 19, .0000000000000000000000000000000000000000000000000000000000000000000000µ2017
>>> 6:.0000000000000000000000000000000000000000000000000000000000000000000000ÿ8 PM, "Moritz Angermann"
>>> <moritz.angermann at gmail.com> wrote:
>> 
>> Shiftag,
>> 
>> any chance you could try this with 8.2 again then?
>>> Hi,
>>> 
>>> I'm going to try that and I will let you know ;)
>>> 
>>> Thanks guys.
>> 
>> Hi,
>> 
>> So I installed GHC-8.2.1 and then I tried to cross-compiling it. The ./configure went fine but the
>> make :
>> 
>> # make
>> Run "make install" to install
>> Makefile:46: recipe for target 'default' failed
>> make: *** [default] Error 1
>> 
>> Hmm...did I forgot something ?
> 
> Sorry my bad, I downloaded the wrong archive. Now its compiling, it should work.
>

Hi Guys,

I hope you have a great Sunday.

I'm sorry, it still buggy. So I tried GHC-8.2.1 and I did the following stuff :

$ ./configure --target=arm-linux-gnueabi
[...]
----------------------------------------------------------------------
Configure completed successfully.

   Building GHC version  : 8.2.1
             Git commit id  : 0cee25253f9f2cb4f19f021fd974bdad3c26a80b

   Build platform        : x86_64-unknown-linux
   Host platform         : x86_64-unknown-linux
   Target platform       : arm-unknown-linux

   Bootstrapping using   : /usr/bin/ghc
      which is version   : 8.2.1

   Using (for bootstrapping) : gcc
   Using gcc                 : arm-linux-gnueabi-gcc
      which is version       : 7.2.0
   Building a cross compiler : YES
   Unregisterised            : NO
   hs-cpp       : arm-linux-gnueabi-gcc
   hs-cpp-flags : -E -undef -traditional
   ar           : /usr/bin/arm-linux-gnueabi-ar
   ld           : arm-linux-gnueabi-ld.gold
   nm           : /usr/bin/arm-linux-gnueabi-nm
   objdump      : /usr/bin/arm-linux-gnueabi-objdump
   ranlib       : /usr/bin/arm-linux-gnueabi-ranlib
   windres      :
   dllwrap      :
   Happy        : /usr/bin/happy (1.19.7)
   Alex         : /usr/bin/alex (3.2.3)
   Perl         : /usr/bin/perl
   sphinx-build : /usr/bin/sphinx-build
   xelatex      :

   Using LLVM tools
         llc   : /usr/bin/llc-3.9
         opt   : /usr/bin/opt-3.9
      HsColour : /usr/bin/HsColour

   Tools to build Sphinx HTML documentation available: YES
      Tools to build Sphinx PDF documentation available: NO
----------------------------------------------------------------------
      

# grep -v '#' mk/build.mk  | sed '/^$/d'
BuildFlavour = perf-cross
ifneq "$(BuildFlavour)" ""
include mk/flavours/$(BuildFlavour).mk
endif
HADDOCK_DOCS = NO
STRIP_CMD = :
WITH_TERMINFO = NO


# make
"inplace/bin/ghc-stage1" -optc-marm -optc-fno-stack-protector -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-noret
urn -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-DNOSMP -optc-DUSE_LIBFF
I_FOR_ADJUSTORS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-ffunction-sections -optc-fdata-
sections -static  -O -H64m -Wall   -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint      -i -irts -irts/dist/build -Irts
/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen           -O2    -Wnoncanonical-monad-instances  -c rts/posix/GetEnv.c -o rts/dist/build/posix/GetEnv.o
"inplace/bin/ghc-stage1" -static  -O -H64m -Wall   -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint      -i -irts -irts/
dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen           -O2    -Wnoncanonical-monad-instances  -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o
/tmp/ghc22858_0/ghc_8.s: Assembler messages:

/tmp/ghc22858_0/ghc_8.s:41:0: error:
     Error: selected processor does not support `ldrd r0,r1,[r3,#64]' in ARM mode
    |
 41 |         ldrd    r0, r1, [r3, #64]
    | ^

/tmp/ghc22858_0/ghc_8.s:46:0: error:
     Error: selected processor does not support `strd r0,r1,[r3,#64]' in ARM mode
    |
 46 |         strd    r0, r1, [r3, #64]
    | ^

/tmp/ghc22858_0/ghc_8.s:108:0: error:
     Error: selected processor does not support `ldrd r0,r1,[r2,#64]' in ARM mode
    |
108 |         ldrd    r0, r1, [r2, #64]
    | ^

/tmp/ghc22858_0/ghc_8.s:111:0: error:
     Error: selected processor does not support `strd r0,r1,[r2,#64]' in ARM mode
    |
111 |         strd    r0, r1, [r2, #64]
    | ^

/tmp/ghc22858_0/ghc_8.s:137:0: error:
     Error: selected processor does not support `ldrd r0,r1,[r2,#64]' in ARM mode
    |
137 |         ldrd    r0, r1, [r2, #64]
    | ^

/tmp/ghc22858_0/ghc_8.s:140:0: error:
     Error: selected processor does not support `strd r0,r1,[r2,#64]' in ARM mode
    |
140 |         strd    r0, r1, [r2, #64]
    | ^

/tmp/ghc22858_0/ghc_8.s:163:0: error:
     Error: selected processor does not support `ldrd r0,r1,[r2,#64]' in ARM mode
    |
163 |         ldrd    r0, r1, [r2, #64]
    | ^

/tmp/ghc22858_0/ghc_8.s:166:0: error:
     Error: selected processor does not support `strd r0,r1,[r2,#64]' in ARM mode
    |
166 |         strd    r0, r1, [r2, #64]
    | ^
`arm-linux-gnueabi-gcc' failed in phase `Assembler'. (Exit code: 1)
rts/ghc.mk:248: recipe for target 'rts/dist/build/StgStartup.o' failed
make[1]: *** [rts/dist/build/StgStartup.o] Error 1
Makefile:122: recipe for target 'all' failed
make: *** [all] Error 2%                                                     


Well that issue persist. An idea ?

Cheers

From moritz.angermann at gmail.com  Sun Oct 22 06:37:17 2017
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sun, 22 Oct 2017 14:37:17 +0800
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <07f9c86c35bdc84fb584eeafe1e33b1d@webmail.nanotek.info>
References: <999bf15c157a483563b8377377669d2a@webmail.nanotek.info>
 <3c4df30f0b8e92ddc0d6fab809dc62f9@webmail.nanotek.info>
 <78ec0450a4ec73600c555d6e538f3a40@webmail.nanotek.info>
 <57A4A430-4F5F-43AC-8C29-E69E7C8DD2E2@gmail.com>
 <9906A55A-FACD-4EE2-9623-BD59A3491B08@gmail.com>
 <87efq0qzkz.fsf@ben-laptop.smart-cactus.org>
 <87h8uxr4u4.fsf@ben-laptop.smart-cactus.org>
 <874lqzrro2.fsf@ben-laptop.smart-cactus.org>
 <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
 <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
 <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>
 <CAKFCL4WD4ZovhDBhkEcUFTgU6hUgXFdC9O+8sqxNpd+uSf6KvQ@mail.gmail.com>
 <57f2ac6fc4480efd6930251d44c5deb6@webmail.nanotek.info>
 <99e66bc4be7e42298f23158304106f22@webmail.nanotek.info>
 <d60b9e203dc3c49f9c0cbced968ad0b6@webmail.nanotek.info>
 <BFB9B6DF-997A-46C7-8B26-AC57E2B98F1D@gmail.com>
 <87tvyvp7f8.fsf@ben-laptop.smart-cactus.org>
 <07f9c86c35bdc84fb584eeafe1e33b1d@webmail.nanotek.info>
Message-ID: <CF56AD7A-D83C-4BD3-95AD-D6F48C1487CF@gmail.com>

Could you try running this with `-v`? Hopefully, this time will will not 
stop somewhere in the middle, but rather give us the full output, and
also reproduce the errors.


> On Oct 22, 2017, at 2:33 PM, shiftag at nanotek.info wrote:
> 
> "inplace/bin/ghc-stage1" -static  -O -H64m -Wall   -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint      -i -irts -irts/
> dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen           -O2    -Wnoncanonical-monad-instances  -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.


From shiftag at nanotek.info  Sun Oct 22 07:06:40 2017
From: shiftag at nanotek.info (shiftag at nanotek.info)
Date: Sun, 22 Oct 2017 07:06:40 +0000
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <CF56AD7A-D83C-4BD3-95AD-D6F48C1487CF@gmail.com>
References: <CF56AD7A-D83C-4BD3-95AD-D6F48C1487CF@gmail.com>
 <999bf15c157a483563b8377377669d2a@webmail.nanotek.info>
 <3c4df30f0b8e92ddc0d6fab809dc62f9@webmail.nanotek.info>
 <78ec0450a4ec73600c555d6e538f3a40@webmail.nanotek.info>
 <57A4A430-4F5F-43AC-8C29-E69E7C8DD2E2@gmail.com>
 <9906A55A-FACD-4EE2-9623-BD59A3491B08@gmail.com>
 <87efq0qzkz.fsf@ben-laptop.smart-cactus.org>
 <87h8uxr4u4.fsf@ben-laptop.smart-cactus.org>
 <874lqzrro2.fsf@ben-laptop.smart-cactus.org>
 <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
 <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
 <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>
 <CAKFCL4WD4ZovhDBhkEcUFTgU6hUgXFdC9O+8sqxNpd+uSf6KvQ@mail.gmail.com>
 <57f2ac6fc4480efd6930251d44c5deb6@webmail.nanotek.info>
 <99e66bc4be7e42298f23158304106f22@webmail.nanotek.info>
 <d60b9e203dc3c49f9c0cbced968ad0b6@webmail.nanotek.info>
 <BFB9B6DF-997A-46C7-8B26-AC57E2B98F1D@gmail.com>
 <87tvyvp7f8.fsf@ben-laptop.smart-cactus.org>
 <07f9c86c35bdc84fb584eeafe1e33b1d@webmail.nanotek.info>
Message-ID: <e09b3a9e762c80debf6eaf0136a39f1f@webmail.nanotek.info>

October 22, 2017 10:37 AM, "Moritz Angermann" <moritz.angermann at gmail.com> wrote:

> Could you try running this with `-v`? Hopefully, this time will will not 
> stop somewhere in the middle, but rather give us the full output, and
> also reproduce the errors.
> 


Understood.

# inplace/bin/ghc-stage1 -v -static  -O -H64m -Wall   -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint  -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen           -O2    -Wnoncanonical-monad-instances  -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o
Glasgow Haskell Compiler, Version 8.2.1, stage 1 booted by GHC version 8.2.1
Using binary package database: /tmp/ghc-8.2.1/inplace/lib/package.conf.d/package.cache
package flags []
loading package database /tmp/ghc-8.2.1/inplace/lib/package.conf.d
wired-in package ghc-prim mapped to ghc-prim-0.5.1.0
wired-in package integer-simple mapped to integer-simple-0.1.1.1
wired-in package base mapped to base-4.10.0.0
wired-in package rts mapped to rts
wired-in package template-haskell mapped to template-haskell-2.12.0.0
wired-in package ghc mapped to ghc-8.2.1
wired-in package dph-seq not found.
wired-in package dph-par not found.
Created temporary directory: /tmp/ghc32190_0
*** C Compiler:
arm-linux-gnueabi-gcc -marm -fno-stack-protector -DTABLES_NEXT_TO_CODE -DNOSMP -E -I includes -I includes/dist -I includes/dist-derivedconstants/header -I includes/dist-ghcconstants/header -I rts -I rts/dist/build -I rts/dist/build -I rts/dist/build/./autogen -I /tmp/ghc-8.2.1/libraries/base/include -I /tmp/ghc-8.2.1/rts/dist/build -I /tmp/ghc-8.2.1/includes -I /tmp/ghc-8.2.1/includes/dist-derivedconstants/header -include /tmp/ghc-8.2.1/includes/ghcversion.h -Dlinux_BUILD_OS -Dx86_64_BUILD_ARCH -Dlinux_HOST_OS -Darm_HOST_ARCH '-D__GLASGOW_HASKELL_LLVM__=309' -D__GLASGOW_HASKELL_TH__ -include/tmp/ghc32190_0/ghc_2.h -x assembler-with-cpp rts/StgStartup.cmm -o /tmp/ghc32190_0/ghc_1.cmmcpp
*** ParseCmm [/tmp/ghc32190_0/ghc_1.cmmcpp]:
!!! ParseCmm [/tmp/ghc32190_0/ghc_1.cmmcpp]: finished in 2.50 milliseconds, allocated 1.737 megabytes
*** LLVM CodeGen:
*** LLVM CodeGen:
Using LLVM version: (3,9)
*** CmmLint [Cmm$ghc_1.cmmcpp]:
!!! CmmLint [Cmm$ghc_1.cmmcpp]: finished in 0.35 milliseconds, allocated 0.082 megabytes
!!! LLVM CodeGen: finished in 9.53 milliseconds, allocated 5.082 megabytes
*** LLVM Optimiser:
/usr/bin/opt-3.9 /tmp/ghc32190_0/ghc_4.ll -o /tmp/ghc32190_0/ghc_6.bc -O2 '--enable-tbaa=true'
*** LLVM Compiler:
/usr/bin/llc-3.9 -O3 '-relocation-model=static' /tmp/ghc32190_0/ghc_6.bc -o /tmp/ghc32190_0/ghc_7.lm_s '--enable-tbaa=true'
*** LLVM Mangler:
!!! LLVM Mangler: finished in 0.81 milliseconds, allocated 0.369 megabytes
*** Assembler:
arm-linux-gnueabi-gcc -marm -fno-stack-protector -DTABLES_NEXT_TO_CODE -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -Irts/dist/build -Irts/dist/build/./autogen -x assembler -c /tmp/ghc32190_0/ghc_8.s -o rts/dist/build/StgStartup.o
/tmp/ghc32190_0/ghc_8.s: Assembler messages:

/tmp/ghc32190_0/ghc_8.s:41:0: error:
     Error: selected processor does not support `ldrd r0,r1,[r3,#64]' in ARM mode
   |
41 |         ldrd    r0, r1, [r3, #64]
   | ^

/tmp/ghc32190_0/ghc_8.s:46:0: error:
     Error: selected processor does not support `strd r0,r1,[r3,#64]' in ARM mode
   |
46 |         strd    r0, r1, [r3, #64]
   | ^

/tmp/ghc32190_0/ghc_8.s:108:0: error:
     Error: selected processor does not support `ldrd r0,r1,[r2,#64]' in ARM mode
    |
108 |         ldrd    r0, r1, [r2, #64]
    | ^

/tmp/ghc32190_0/ghc_8.s:111:0: error:
     Error: selected processor does not support `strd r0,r1,[r2,#64]' in ARM mode
    |
111 |         strd    r0, r1, [r2, #64]
    | ^

/tmp/ghc32190_0/ghc_8.s:137:0: error:
     Error: selected processor does not support `ldrd r0,r1,[r2,#64]' in ARM mode
    |
137 |         ldrd    r0, r1, [r2, #64]
    | ^

/tmp/ghc32190_0/ghc_8.s:140:0: error:
     Error: selected processor does not support `strd r0,r1,[r2,#64]' in ARM mode
    |
140 |         strd    r0, r1, [r2, #64]
    | ^

/tmp/ghc32190_0/ghc_8.s:163:0: error:
     Error: selected processor does not support `ldrd r0,r1,[r2,#64]' in ARM mode
    |
163 |         ldrd    r0, r1, [r2, #64]
    | ^

/tmp/ghc32190_0/ghc_8.s:166:0: error:
     Error: selected processor does not support `strd r0,r1,[r2,#64]' in ARM mode
    |
166 |         strd    r0, r1, [r2, #64]
    | ^
*** Deleting temp files:
Deleting: /tmp/ghc32190_0/ghc_8.s /tmp/ghc32190_0/ghc_7.lm_s /tmp/ghc32190_0/ghc_6.bc /tmp/ghc32190_0/ghc_5.c /tmp/ghc32190_0/ghc_4.ll /tmp/ghc32190_0/ghc_3.rsp /tmp/ghc32190_0/ghc_2.h /tmp/ghc32190_0/ghc_1.cmmcpp
Warning: deleting non-existent /tmp/ghc32190_0/ghc_5.c
*** Deleting temp dirs:
Deleting: /tmp/ghc32190_0
`arm-linux-gnueabi-gcc' failed in phase `Assembler'. (Exit code: 1)

From moritz.angermann at gmail.com  Sun Oct 22 07:51:15 2017
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sun, 22 Oct 2017 15:51:15 +0800
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <e09b3a9e762c80debf6eaf0136a39f1f@webmail.nanotek.info>
References: <CF56AD7A-D83C-4BD3-95AD-D6F48C1487CF@gmail.com>
 <999bf15c157a483563b8377377669d2a@webmail.nanotek.info>
 <3c4df30f0b8e92ddc0d6fab809dc62f9@webmail.nanotek.info>
 <78ec0450a4ec73600c555d6e538f3a40@webmail.nanotek.info>
 <57A4A430-4F5F-43AC-8C29-E69E7C8DD2E2@gmail.com>
 <9906A55A-FACD-4EE2-9623-BD59A3491B08@gmail.com>
 <87efq0qzkz.fsf@ben-laptop.smart-cactus.org>
 <87h8uxr4u4.fsf@ben-laptop.smart-cactus.org>
 <874lqzrro2.fsf@ben-laptop.smart-cactus.org>
 <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
 <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
 <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>
 <CAKFCL4WD4ZovhDBhkEcUFTgU6hUgXFdC9O+8sqxNpd+uSf6KvQ@mail.gmail.com>
 <57f2ac6fc4480efd6930251d44c5deb6@webmail.nanotek.info>
 <99e66bc4be7e42298f23158304106f22@webmail.nanotek.info>
 <d60b9e203dc3c49f9c0cbced968ad0b6@webmail.nanotek.info>
 <BFB9B6DF-997A-46C7-8B26-AC57E2B98F1D@gmail.com>
 <87tvyvp7f8.fsf@ben-laptop.smart-cactus.org>
 <07f9c86c35bdc84fb584eeafe1e33b1d@webmail.nanotek.info>
 <e09b3a9e762c80debf6eaf0136a39f1f@webmail.nanotek.info>
Message-ID: <A6213A84-7FD3-425D-BB60-F7D2D585452E@gmail.com>

Can you rerun that command with -keep-llvm-files and attach the generated .ll file?

Cheers,
 Moritz

Sent from my iPhone

> On 22 Oct 2017, at 3:06 PM, shiftag at nanotek.info wrote:
> 
> October 22, 2017 10:37 AM, "Moritz Angermann" <moritz.angermann at gmail.com> wrote:
> 
>> Could you try running this with `-v`? Hopefully, this time will will not 
>> stop somewhere in the middle, but rather give us the full output, and
>> also reproduce the errors.
>> 
> 
> 
> Understood.
> 
> # inplace/bin/ghc-stage1 -v -static  -O -H64m -Wall   -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint  -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen           -O2    -Wnoncanonical-monad-instances  -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o
> Glasgow Haskell Compiler, Version 8.2.1, stage 1 booted by GHC version 8.2.1
> Using binary package database: /tmp/ghc-8.2.1/inplace/lib/package.conf.d/package.cache
> package flags []
> loading package database /tmp/ghc-8.2.1/inplace/lib/package.conf.d
> wired-in package ghc-prim mapped to ghc-prim-0.5.1.0
> wired-in package integer-simple mapped to integer-simple-0.1.1.1
> wired-in package base mapped to base-4.10.0.0
> wired-in package rts mapped to rts
> wired-in package template-haskell mapped to template-haskell-2.12.0.0
> wired-in package ghc mapped to ghc-8.2.1
> wired-in package dph-seq not found.
> wired-in package dph-par not found.
> Created temporary directory: /tmp/ghc32190_0
> *** C Compiler:
> arm-linux-gnueabi-gcc -marm -fno-stack-protector -DTABLES_NEXT_TO_CODE -DNOSMP -E -I includes -I includes/dist -I includes/dist-derivedconstants/header -I includes/dist-ghcconstants/header -I rts -I rts/dist/build -I rts/dist/build -I rts/dist/build/./autogen -I /tmp/ghc-8.2.1/libraries/base/include -I /tmp/ghc-8.2.1/rts/dist/build -I /tmp/ghc-8.2.1/includes -I /tmp/ghc-8.2.1/includes/dist-derivedconstants/header -include /tmp/ghc-8.2.1/includes/ghcversion.h -Dlinux_BUILD_OS -Dx86_64_BUILD_ARCH -Dlinux_HOST_OS -Darm_HOST_ARCH '-D__GLASGOW_HASKELL_LLVM__=309' -D__GLASGOW_HASKELL_TH__ -include/tmp/ghc32190_0/ghc_2.h -x assembler-with-cpp rts/StgStartup.cmm -o /tmp/ghc32190_0/ghc_1.cmmcpp
> *** ParseCmm [/tmp/ghc32190_0/ghc_1.cmmcpp]:
> !!! ParseCmm [/tmp/ghc32190_0/ghc_1.cmmcpp]: finished in 2.50 milliseconds, allocated 1.737 megabytes
> *** LLVM CodeGen:
> *** LLVM CodeGen:
> Using LLVM version: (3,9)
> *** CmmLint [Cmm$ghc_1.cmmcpp]:
> !!! CmmLint [Cmm$ghc_1.cmmcpp]: finished in 0.35 milliseconds, allocated 0.082 megabytes
> !!! LLVM CodeGen: finished in 9.53 milliseconds, allocated 5.082 megabytes
> *** LLVM Optimiser:
> /usr/bin/opt-3.9 /tmp/ghc32190_0/ghc_4.ll -o /tmp/ghc32190_0/ghc_6.bc -O2 '--enable-tbaa=true'
> *** LLVM Compiler:
> /usr/bin/llc-3.9 -O3 '-relocation-model=static' /tmp/ghc32190_0/ghc_6.bc -o /tmp/ghc32190_0/ghc_7.lm_s '--enable-tbaa=true'
> *** LLVM Mangler:
> !!! LLVM Mangler: finished in 0.81 milliseconds, allocated 0.369 megabytes
> *** Assembler:
> arm-linux-gnueabi-gcc -marm -fno-stack-protector -DTABLES_NEXT_TO_CODE -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -Irts/dist/build -Irts/dist/build/./autogen -x assembler -c /tmp/ghc32190_0/ghc_8.s -o rts/dist/build/StgStartup.o
> /tmp/ghc32190_0/ghc_8.s: Assembler messages:
> 
> /tmp/ghc32190_0/ghc_8.s:41:0: error:
>     Error: selected processor does not support `ldrd r0,r1,[r3,#64]' in ARM mode
>   |
> 41 |         ldrd    r0, r1, [r3, #64]
>   | ^
> 
> /tmp/ghc32190_0/ghc_8.s:46:0: error:
>     Error: selected processor does not support `strd r0,r1,[r3,#64]' in ARM mode
>   |
> 46 |         strd    r0, r1, [r3, #64]
>   | ^
> 
> /tmp/ghc32190_0/ghc_8.s:108:0: error:
>     Error: selected processor does not support `ldrd r0,r1,[r2,#64]' in ARM mode
>    |
> 108 |         ldrd    r0, r1, [r2, #64]
>    | ^
> 
> /tmp/ghc32190_0/ghc_8.s:111:0: error:
>     Error: selected processor does not support `strd r0,r1,[r2,#64]' in ARM mode
>    |
> 111 |         strd    r0, r1, [r2, #64]
>    | ^
> 
> /tmp/ghc32190_0/ghc_8.s:137:0: error:
>     Error: selected processor does not support `ldrd r0,r1,[r2,#64]' in ARM mode
>    |
> 137 |         ldrd    r0, r1, [r2, #64]
>    | ^
> 
> /tmp/ghc32190_0/ghc_8.s:140:0: error:
>     Error: selected processor does not support `strd r0,r1,[r2,#64]' in ARM mode
>    |
> 140 |         strd    r0, r1, [r2, #64]
>    | ^
> 
> /tmp/ghc32190_0/ghc_8.s:163:0: error:
>     Error: selected processor does not support `ldrd r0,r1,[r2,#64]' in ARM mode
>    |
> 163 |         ldrd    r0, r1, [r2, #64]
>    | ^
> 
> /tmp/ghc32190_0/ghc_8.s:166:0: error:
>     Error: selected processor does not support `strd r0,r1,[r2,#64]' in ARM mode
>    |
> 166 |         strd    r0, r1, [r2, #64]
>    | ^
> *** Deleting temp files:
> Deleting: /tmp/ghc32190_0/ghc_8.s /tmp/ghc32190_0/ghc_7.lm_s /tmp/ghc32190_0/ghc_6.bc /tmp/ghc32190_0/ghc_5.c /tmp/ghc32190_0/ghc_4.ll /tmp/ghc32190_0/ghc_3.rsp /tmp/ghc32190_0/ghc_2.h /tmp/ghc32190_0/ghc_1.cmmcpp
> Warning: deleting non-existent /tmp/ghc32190_0/ghc_5.c
> *** Deleting temp dirs:
> Deleting: /tmp/ghc32190_0
> `arm-linux-gnueabi-gcc' failed in phase `Assembler'. (Exit code: 1)

From shiftag at nanotek.info  Sun Oct 22 08:05:34 2017
From: shiftag at nanotek.info (shiftag at nanotek.info)
Date: Sun, 22 Oct 2017 08:05:34 +0000
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <A6213A84-7FD3-425D-BB60-F7D2D585452E@gmail.com>
References: <A6213A84-7FD3-425D-BB60-F7D2D585452E@gmail.com>
 <CF56AD7A-D83C-4BD3-95AD-D6F48C1487CF@gmail.com>
 <999bf15c157a483563b8377377669d2a@webmail.nanotek.info>
 <3c4df30f0b8e92ddc0d6fab809dc62f9@webmail.nanotek.info>
 <78ec0450a4ec73600c555d6e538f3a40@webmail.nanotek.info>
 <57A4A430-4F5F-43AC-8C29-E69E7C8DD2E2@gmail.com>
 <9906A55A-FACD-4EE2-9623-BD59A3491B08@gmail.com>
 <87efq0qzkz.fsf@ben-laptop.smart-cactus.org>
 <87h8uxr4u4.fsf@ben-laptop.smart-cactus.org>
 <874lqzrro2.fsf@ben-laptop.smart-cactus.org>
 <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
 <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
 <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>
 <CAKFCL4WD4ZovhDBhkEcUFTgU6hUgXFdC9O+8sqxNpd+uSf6KvQ@mail.gmail.com>
 <57f2ac6fc4480efd6930251d44c5deb6@webmail.nanotek.info>
 <99e66bc4be7e42298f23158304106f22@webmail.nanotek.info>
 <d60b9e203dc3c49f9c0cbced968ad0b6@webmail.nanotek.info>
 <BFB9B6DF-997A-46C7-8B26-AC57E2B98F1D@gmail.com>
 <87tvyvp7f8.fsf@ben-laptop.smart-cactus.org>
 <07f9c86c35bdc84fb584eeafe1e33b1d@webmail.nanotek.info>
 <e09b3a9e762c80debf6eaf0136a39f1f@webmail.nanotek.info>
Message-ID: <8f957317a0bef0bdf95c49c95319b3db@webmail.nanotek.info>

October 22, 2017 11:51 AM, "Moritz Angermann" <moritz.angermann at gmail.com> wrote:

> Can you rerun that command with -keep-llvm-files and attach the generated .ll file?
> 

I rerun the same command by adding -keep-llvm-files and the file "./rts/StgStartup.ll" has been created. Please find it attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: StgStartup.ll
Type: application/octet-stream
Size: 21856 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171022/a55177f6/attachment-0001.obj>

From moritz.angermann at gmail.com  Sun Oct 22 10:38:43 2017
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sun, 22 Oct 2017 18:38:43 +0800
Subject: Compiling natively GHC for ARMv7l softabi
In-Reply-To: <8f957317a0bef0bdf95c49c95319b3db@webmail.nanotek.info>
References: <A6213A84-7FD3-425D-BB60-F7D2D585452E@gmail.com>
 <CF56AD7A-D83C-4BD3-95AD-D6F48C1487CF@gmail.com>
 <999bf15c157a483563b8377377669d2a@webmail.nanotek.info>
 <3c4df30f0b8e92ddc0d6fab809dc62f9@webmail.nanotek.info>
 <78ec0450a4ec73600c555d6e538f3a40@webmail.nanotek.info>
 <57A4A430-4F5F-43AC-8C29-E69E7C8DD2E2@gmail.com>
 <9906A55A-FACD-4EE2-9623-BD59A3491B08@gmail.com>
 <87efq0qzkz.fsf@ben-laptop.smart-cactus.org>
 <87h8uxr4u4.fsf@ben-laptop.smart-cactus.org>
 <874lqzrro2.fsf@ben-laptop.smart-cactus.org>
 <4c733ac956f6e82e0e8e4a8d0b4b1329@webmail.nanotek.info>
 <9cf2c0fc125edd058d27a798f4194117@webmail.nanotek.info>
 <dd2f5b33ed607639f785ff5a0630c61f@webmail.nanotek.info>
 <CAKFCL4WD4ZovhDBhkEcUFTgU6hUgXFdC9O+8sqxNpd+uSf6KvQ@mail.gmail.com>
 <57f2ac6fc4480efd6930251d44c5deb6@webmail.nanotek.info>
 <99e66bc4be7e42298f23158304106f22@webmail.nanotek.info>
 <d60b9e203dc3c49f9c0cbced968ad0b6@webmail.nanotek.info>
 <BFB9B6DF-997A-46C7-8B26-AC57E2B98F1D@gmail.com>
 <87tvyvp7f8.fsf@ben-laptop.smart-cactus.org>
 <07f9c86c35bdc84fb584eeafe1e33b1d@webmail.nanotek.info>
 <e09b3a9e762c80debf6eaf0136a39f1f@webmail.nanotek.info>
 <8f957317a0bef0bdf95c49c95319b3db@webmail.nanotek.info>
Message-ID: <2F6BA0DD-CC4E-44F7-8482-2B397991B9CD@gmail.com>

Thanks! Looking at the llvm ir file, we find:

target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32"
target triple = "armv6-unknown-linux-gnueabihf"

that does looks incorrect for armv7l softabi. We have the hardfloat gnueabi, AND armv6. However, I don't know if this influences
the generated IR to the point where it's unusable.

Looking at https://github.com/ghc/ghc/blob/95c1feeb9ce9b2d6a9453dc4da148b80a5ddce3d/compiler/llvmGen/LlvmCodeGen/Ppr.hs#L35-L86
I don't see a proper configuration for it yet though.

Now again we mix the llvm and gcc toolchain, and I don't have gcc on my system right now.

We can do the following though:
$ llc -O3 StgStartup.ll -o StgStartup.s
$ clang --target=arm-unknown-linux-gnueabihf -c StgStartup.s -v

and have this successfully produce an object file. As such I don't think the target triple given above is at fault here (apart from
potentially generating hard-float fp).

I would as such conclude that the issue is the argument passed to gcc as assembler here.  I'm a bit at a loss how to solve this here
right now.  GHC HEAD has seen especially in this area quite a bit of churn as well.

On top of my head, I've two suggestions:

- Try configuring with a LLVM toolchain. E.g. CC=arm-linux-gnueabi-clang
- Try GHC HEAD. If this still fails, you could try to sidestep the mangling and assembly logic, by adding -fast-llvm to the
  mk/flavour/<your-flavour>.mk (e.g. quick-cross, perf-cross).

Cheers,
 Moritz


> On Oct 22, 2017, at 4:05 PM, shiftag at nanotek.info wrote:
> 
> October 22, 2017 11:51 AM, "Moritz Angermann" <moritz.angermann at gmail.com> wrote:
> 
>> Can you rerun that command with -keep-llvm-files and attach the generated .ll file?
>> 
> 
> I rerun the same command by adding -keep-llvm-files and the file "./rts/StgStartup.ll" has been created. Please find it attached.
> <StgStartup.ll>_______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From mail at joachim-breitner.de  Mon Oct 23 02:19:03 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 22 Oct 2017 22:19:03 -0400
Subject: Is stage-1 sufficient to run nofib
Message-ID: <1508725143.6650.15.camel@joachim-breitner.de>

Hi,

I guess I could just try it, but maybe someone knows it, or knows what
would go wrong…

    If I run nofib with ghc-stage1 instead of ghc-stage2, I should get
    the same results, right? (ignoring compilation times here)

My hope is that it can speed up perf.haskell.org some more.

Greetings,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171022/e46f9358/attachment.sig>

From ezyang at mit.edu  Mon Oct 23 02:23:14 2017
From: ezyang at mit.edu (Edward Z. Yang)
Date: Sun, 22 Oct 2017 22:23:14 -0400
Subject: Is stage-1 sufficient to run nofib
In-Reply-To: <1508725143.6650.15.camel@joachim-breitner.de>
References: <1508725143.6650.15.camel@joachim-breitner.de>
Message-ID: <1508725365-sup-657@sabre>

Yes, but you still need to build the libraries, so the speed up
will not be as much as you might hope.

Excerpts from Joachim Breitner's message of 2017-10-22 22:19:03 -0400:
> Hi,
> 
> I guess I could just try it, but maybe someone knows it, or knows what
> would go wrong…
> 
>     If I run nofib with ghc-stage1 instead of ghc-stage2, I should get
>     the same results, right? (ignoring compilation times here)
> 
> My hope is that it can speed up perf.haskell.org some more.
> 
> Greetings,
> Joachim
> 

From mail at joachim-breitner.de  Mon Oct 23 03:14:18 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 22 Oct 2017 23:14:18 -0400
Subject: Is stage-1 sufficient to run nofib
In-Reply-To: <1508725365-sup-657@sabre>
References: <1508725143.6650.15.camel@joachim-breitner.de>
 <1508725365-sup-657@sabre>
Message-ID: <1508728458.6650.18.camel@joachim-breitner.de>

Hi Edward,

Am Sonntag, den 22.10.2017, 22:23 -0400 schrieb Edward Z. Yang:
> Yes, but you still need to build the libraries, so the speed up
> will not be as much as you might hope.

sure, but when you build every GHC commit, then even a small
improvement is nice.

Do you know the proper way of building only libraries + ghc-stage1?

Greetings,
Joachim



-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de
  https://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171022/7c6c4703/attachment.sig>

From moritz.angermann at gmail.com  Mon Oct 23 06:04:34 2017
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Mon, 23 Oct 2017 14:04:34 +0800
Subject: Relocatable dist
Message-ID: <9B67B24A-F81C-44EA-B9A7-B7CDA76EBA76@gmail.com>

Hi,

while trying to make the binary-distribution logic work for
cross compilers.  I've come wonder, how hard it could be to
make GHC relocatable. (e.g. just unpack the distribution, 
and use the compiler from the `bin` folder within).

Right now this does not work due to the need for the path to
package.conf, and this is hardcoded in the wrapper script to
provide the proper libdir to ghc via -B[1]. Supposedly this
is not an issue on Windows, as a relative path is common on
windows and finding the location of the executable can be done
safely. Or that's at least how I understand[1].

For macOS there is the haskell-platform, and ghc-dot-app[2]

From [3], it sounds like automake is a build, and not a packaging
system, and the binary dist usecase with configure is not
really a standard use case.

So why do I bring this up NOW? Apart from me trying to make
cross compiler binary distributions working?  The reason is
that we are also trying to move towards hadrian, and by "starting
from scratch", maybe we have a chance to reconsider how we
do things?

I must admit, I'm quite happy to use packages like llvm, by
just downloading a package and adding the `bin` path to my
$PATH.

There is however one thing that the current configure appraoch
does, which I think is quite noteworthy (apart from setting
$prefix).  That is, it does check for compilers and sets them
accordingly, which might be desirable.

Cheers,
 Moritz

--
[1]: https://ghc.haskell.org/trac/ghc/wiki/Building/Installing
[2]: https://ghc.haskell.org/trac/ghc/wiki/Building/MacOSX/Installer
[3]: https://lists.gnu.org/archive/html/automake/2006-10/msg00005.html

From simonpj at microsoft.com  Mon Oct 23 08:05:51 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 23 Oct 2017 08:05:51 +0000
Subject: splitting metavariables
In-Reply-To: <B30CDF34-06EA-4DEC-81F6-E8D80178CD81@cs.brynmawr.edu>
References: <B30CDF34-06EA-4DEC-81F6-E8D80178CD81@cs.brynmawr.edu>
Message-ID: <AM4PR83MB003388635E13288B260ECD84AD460@AM4PR83MB0033.EURPRD83.prod.outlook.com>

|  Actually, I wonder if we can put the check in just one spot: coreView.
|  Whenever we use coreView, we're about to inspect a type. And we should
|  never be inspecting a metavariable in this way.

Yes, that's right. Maybe that makes a useful distinction between coreView and tcView; the former should never see a meta-variable.

I'm not sure we are fully consistent on when we call each, but it'd be a good start.

Go for it

Simon

|  -----Original Message-----
|  From: Richard Eisenberg [mailto:rae at cs.brynmawr.edu]
|  Sent: 20 October 2017 22:44
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: ghc-devs <ghc-devs at haskell.org>
|  Subject: splitting metavariables
|  
|  Hi Simon,
|  
|  I just commented
|  (https://ghc.haskell.org/trac/ghc/ticket/14331#comment:35) about a
|  situation where we call splitFunTys on a type that might be a
|  metavariable. (You don't have to read the comment -- that's just to
|  set the context.) Now that I think of it, we should never call the
|  splitXXX functions on metavariables -- any time we do so is wrong. I
|  suppose it's OK if we, say, call splitTyConApp_maybe on (T alpha beta
|  gamma), because we never look through the metavariables there. But it
|  can't possible be write to call splitTyConApp_maybe on alpha.
|  
|  Do you agree? Should we ASSERT that we don't do this?
|  
|  The tcXXX variants are no different in this regard.
|  
|  Actually, I wonder if we can put the check in just one spot: coreView.
|  Whenever we use coreView, we're about to inspect a type. And we should
|  never be inspecting a metavariable in this way.
|  
|  Richard

From mail at joachim-breitner.de  Mon Oct 23 12:43:53 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 23 Oct 2017 08:43:53 -0400
Subject: Relocatable dist
In-Reply-To: <9B67B24A-F81C-44EA-B9A7-B7CDA76EBA76@gmail.com>
References: <9B67B24A-F81C-44EA-B9A7-B7CDA76EBA76@gmail.com>
Message-ID: <1508762633.5323.0.camel@joachim-breitner.de>

Hi,

Am Montag, den 23.10.2017, 14:04 +0800 schrieb Moritz Angermann:
> I've come wonder, how hard it could be to
> make GHC relocatable. (e.g. just unpack the distribution, 
> and use the compiler from the `bin` folder within).

Yes yes yes please!

(Sorry for not contributing anything but motivation.)

Joachim


-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171023/a0d35439/attachment.sig>

From mail at joachim-breitner.de  Mon Oct 23 12:44:32 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 23 Oct 2017 08:44:32 -0400
Subject: Is stage-1 sufficient to run nofib
In-Reply-To: <1508728458.6650.18.camel@joachim-breitner.de>
References: <1508725143.6650.15.camel@joachim-breitner.de>
 <1508725365-sup-657@sabre> <1508728458.6650.18.camel@joachim-breitner.de>
Message-ID: <1508762672.5323.2.camel@joachim-breitner.de>

Hi,

Am Sonntag, den 22.10.2017, 23:14 -0400 schrieb Joachim Breitner:
> Am Sonntag, den 22.10.2017, 22:23 -0400 schrieb Edward Z. Yang:
> > Yes, but you still need to build the libraries, so the speed up
> > will not be as much as you might hope.
> 
> sure, but when you build every GHC commit, then even a small
> improvement is nice.
> 
> Do you know the proper way of building only libraries + ghc-stage1?

nevermind, perf.haskell.org also measures compiler performances (in the
test suite), so I need stage2.

Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171023/4ca55acc/attachment.sig>

From mail at joachim-breitner.de  Mon Oct 23 12:45:36 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 23 Oct 2017 08:45:36 -0400
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <8E8FA99F-66D5-4804-BDAE-819C333D20B0@lichtzwerge.de>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
 <8760bur4sj.fsf@ben-laptop.smart-cactus.org>
 <afafc3d6-253e-980f-2176-39ae5e734858@nyu.edu>
 <A18C8C4B-E72B-47CC-9B1E-B3896EB106EC@lichtzwerge.de>
 <239c9cd9-94f4-5179-e53e-17c1542fd0f4@nyu.edu>
 <9F3CBB9B-1885-4A4C-B412-05B5D9B70DCE@lichtzwerge.de>
 <1508341094.24214.1.camel@joachim-breitner.de>
 <8E8FA99F-66D5-4804-BDAE-819C333D20B0@lichtzwerge.de>
Message-ID: <1508762736.5323.3.camel@joachim-breitner.de>

Hi,

JFTR, upgrading the Arch installation, including ghc to 8.2.1, fixes
the issue for perf.haskell.org.

Greetings,
Joachim

Am Donnerstag, den 19.10.2017, 16:28 +0800 schrieb Moritz Angermann:
> Hi,
> 
> As it turns out this might be linker madness. I do not yet understand why this did work with
> the "old" libffi though.
> 
> The command that fails is a rather long gcc invocation asking it to link a bunch of libraries together.
> 
> $ gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-fuse-ld=gold' [...] -lHSghci-8.3-ghc8.3.20171018 [...] -lffi [...]
> 
> From the error message, we know taht ghci depends on libffi. E.g.
> 
> > libHSghci-8.3-ghc8.3.20171018.so: error: undefined reference to 'ffi_prep_cif'
> 
> Now there are two possible configurations that do (successfully) link on my test machine:
> 
> 1.) Droppping `-fuse-ld=gold`.
> 2.) Moving `-lffi` prior to `-lHSghci-8.3-ghc8.3.20171018`.
> 
> I guess we could also add the libffi symbols the the other -Wl,-u,... symbols.
> 
> Obviously I would not see this on macOS, as there is no go.ld on macOS. On my ubuntu system, gold is
> > GNU gold (GNU Binutils for Ubuntu 2.27) 1.12
> 
> Again, as I stated in the beginning, I fail to understand why this should related to the new libffi version.
> 
> As such running `LD=ld ./configure && make -j` does indeed complete successfully on my machine.
> 
> If someone has any idea what the core issue between the libffi update and these build failures is, I'd be happy
> to know!
> 
> Cheers,
>  Moritz
> 
> > On Oct 18, 2017, at 11:38 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > 
> > Hi,
> > 
> > it’s an Arch linux (generously sponsored by Richard’s university). I
> > have not idea how to give more precise information about the distro
> > release version or such :-)
> > 
> > Greetings,
> > Joachim
> > 
> > Am Mittwoch, den 18.10.2017, 22:02 +0800 schrieb Moritz Angermann:
> > > Hi,
> > > 
> > > so this somehow looks like for a not yet absolutely clear reason to me,
> > > when building ghci, we fail to link in libffi, for some configurations.
> > > 
> > > Joachim, as far as I could see, you are using ghc 8.0.1 to boostrap the
> > > compiler. Thomas are you by any chance bootstrapping with 8.0.1 as well?
> > > I assume Ben bootstraps wit 8.2.1.
> > > 
> > > I'll set up a Ubuntu 16.10 machine tomorrow and try to reproduce this.
> > > 
> > > Joachim, is perf.haskell.org running Ubuntu as well?
> > > 
> > > Cheers,
> > > Moritz
> > > 
> > > > On Oct 11, 2017, at 1:43 AM, Thomas Jakway <tjakway at nyu.edu> wrote:
> > > > 
> > > > Thanks for getting back to me.
> > > > 
> > > > (I think you mean `git clean -x -f -d`): I usually omit -x but I'll give it a go and report back.
> > > > 
> > > > Before I got the issue on a clean checkout I thought it was something I did to the build files.
> > > > 
> > > > I also tried building the latest release of libffi (v3.2.1) and using it in configure with --with-ffi-includes and --with-ffi-libraries but got the same error.
> > > > 
> > > > 
> > > > On 10/09/2017 02:40 AM, Moritz Angermann wrote:
> > > > > Yes, this commit indeed introduced the need for makeinfo, however after some debugging and improved packaging of the external libffi library, this dependency was removed again, and should not be required with the latest head anymore.
> > > > > 
> > > > > Then again this should not result in link issues but rather in build time issues.
> > > > > 
> > > > > The key to libffi is the libffi-tarballs git submodule, which contains the packaged libffi-tarballs. Make sure all your submodules are also updated.
> > > > > 
> > > > > I usually use `git -x -f -d` (read the documentation first) to ensure a clean working tree. Especially as you say you can’t reproduce it on other machines, maybe there is a file in your tree that the cleaning did not catch?
> > > > > 
> > > > > Sent from my iPhone
> > > > > 
> > > > > > On 9 Oct 2017, at 4:31 AM, Thomas Jakway <tjakway at nyu.edu> wrote:
> > > > > > 
> > > > > > I'm on Ubuntu 16.10.
> > > > > > 
> > > > > > I ran git bisect:
> > > > > > 
> > > > > > ----------------------
> > > > > > 
> > > > > > e515c7f37be97e1c2ccc497ddd0a730e63ddfa82 is the first bad commit
> > > > > > commit e515c7f37be97e1c2ccc497ddd0a730e63ddfa82
> > > > > > Author: Moritz Angermann <moritz.angermann at gmail.com>
> > > > > > Date:   Sat Sep 30 09:31:12 2017 -0400
> > > > > > 
> > > > > > Allow libffi snapshots
> > > > > > 
> > > > > > This is rather annoying. I'd prefer to have a stable release to
> > > > > > use. However libffi-3.2.1 has been released November 12, 2014, and
> > > > > > libffi-4 is TBD. See also https://github.com/libffi/libffi/issues/296
> > > > > > 
> > > > > > The core reason for this change is that llvm changed the supported
> > > > > > assembly to unified syntax, which libffi-3.2.1 does not use, and hence
> > > > > > fails to compile for arm with llvm. For refence, see the following
> > > > > > issue: https://github.com/libffi/libffi/issues/191.
> > > > > > 
> > > > > > This diff contains a script to generate a tarball for the
> > > > > > `libffi-tarballs` repository from the libffi GitHub repository; as well
> > > > > > as the necessary changes to the build system.
> > > > > > 
> > > > > > Updates libffi-tarballs submodule.
> > > > > > 
> > > > > > Reviewers: austin, bgamari, hvr
> > > > > > 
> > > > > > Subscribers: hvr, erikd, rwbarton, thomie
> > > > > > 
> > > > > > Differential Revision: https://phabricator.haskell.org/D3574
> > > > > > 
> > > > > > ----------------------
> > > > > > 
> > > > > > I can't reproduce it on my other linux computers though.
> > > > > > 
> > > > > > 
> > > > > > > On 10/04/2017 02:17 PM, Ben Gamari wrote:
> > > > > > > Thomas Jakway <tjakway at nyu.edu> writes:
> > > > > > > 
> > > > > > > > Anyone else getting linker errors?
> > > > > > > > 
> > > > > > > > This is after running
> > > > > > > > 
> > > > > > > > make clean && make distclean && find . -name "*.o" -type f -delete &&
> > > > > > > > find . -name "*.hi" -type f -delete
> > > > > > > > 
> > > > > > > > then
> > > > > > > > 
> > > > > > > > ./boot && ./configure && make -j5
> > > > > > > > 
> > > > > > > > (ghc-new is not a new checkout, this error is happening on a branch I'm
> > > > > > > > working on, but one that doesn't touch the FFI)
> > > > > > > > 
> > > > > > > 
> > > > > > > I'm afraid I can't reproduce this. What platform/operating system is
> > > > > > > this on?
> > > > > > > 
> > > > > > > Cheers,
> > > > > > > 
> > > > > > > - Ben
> > > > > > 
> > > > > > _______________________________________________
> > > > > > ghc-devs mailing list
> > > > > > ghc-devs at haskell.org
> > > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> > > > 
> > > > _______________________________________________
> > > > ghc-devs mailing list
> > > > ghc-devs at haskell.org
> > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> > > 
> > > 
> > 
> > -- 
> > Joachim Breitner
> >  mail at joachim-breitner.de
> >  http://www.joachim-breitner.de/
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
> ————————————————— 
> Moritz Angermann
> +49 170 54 33 0 74
> moritz at lichtzwerge.de
> 
> lichtzwerge GmbH
> Raiffeisenstr. 8
> 93185 Michelsneukirchen
> 
> Amtsgericht Regensburg HRB 14723
> 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.
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de
  https://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171023/ffd4bbe1/attachment.sig>

From moritz.angermann at gmail.com  Mon Oct 23 12:49:58 2017
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Mon, 23 Oct 2017 20:49:58 +0800
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <1508762736.5323.3.camel@joachim-breitner.de>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
 <8760bur4sj.fsf@ben-laptop.smart-cactus.org>
 <afafc3d6-253e-980f-2176-39ae5e734858@nyu.edu>
 <A18C8C4B-E72B-47CC-9B1E-B3896EB106EC@lichtzwerge.de>
 <239c9cd9-94f4-5179-e53e-17c1542fd0f4@nyu.edu>
 <9F3CBB9B-1885-4A4C-B412-05B5D9B70DCE@lichtzwerge.de>
 <1508341094.24214.1.camel@joachim-breitner.de>
 <8E8FA99F-66D5-4804-BDAE-819C333D20B0@lichtzwerge.de>
 <1508762736.5323.3.camel@joachim-breitner.de>
Message-ID: <DF074BAD-9153-4B23-AF80-B7ED5535DE5B@gmail.com>

I still can’t make sense of this. Is your gold a different version now as well?

Sent from my iPhone

> On 23 Oct 2017, at 8:45 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> JFTR, upgrading the Arch installation, including ghc to 8.2.1, fixes
> the issue for perf.haskell.org.
> 
> Greetings,
> Joachim
> 
> Am Donnerstag, den 19.10.2017, 16:28 +0800 schrieb Moritz Angermann:
>> Hi,
>> 
>> As it turns out this might be linker madness. I do not yet understand why this did work with
>> the "old" libffi though.
>> 
>> The command that fails is a rather long gcc invocation asking it to link a bunch of libraries together.
>> 
>> $ gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-fuse-ld=gold' [...] -lHSghci-8.3-ghc8.3.20171018 [...] -lffi [...]
>> 
>> From the error message, we know taht ghci depends on libffi. E.g.
>> 
>>> libHSghci-8.3-ghc8.3.20171018.so: error: undefined reference to 'ffi_prep_cif'
>> 
>> Now there are two possible configurations that do (successfully) link on my test machine:
>> 
>> 1.) Droppping `-fuse-ld=gold`.
>> 2.) Moving `-lffi` prior to `-lHSghci-8.3-ghc8.3.20171018`.
>> 
>> I guess we could also add the libffi symbols the the other -Wl,-u,... symbols.
>> 
>> Obviously I would not see this on macOS, as there is no go.ld on macOS. On my ubuntu system, gold is
>>> GNU gold (GNU Binutils for Ubuntu 2.27) 1.12
>> 
>> Again, as I stated in the beginning, I fail to understand why this should related to the new libffi version.
>> 
>> As such running `LD=ld ./configure && make -j` does indeed complete successfully on my machine.
>> 
>> If someone has any idea what the core issue between the libffi update and these build failures is, I'd be happy
>> to know!
>> 
>> Cheers,
>> Moritz
>> 
>>> On Oct 18, 2017, at 11:38 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
>>> 
>>> Hi,
>>> 
>>> it’s an Arch linux (generously sponsored by Richard’s university). I
>>> have not idea how to give more precise information about the distro
>>> release version or such :-)
>>> 
>>> Greetings,
>>> Joachim
>>> 
>>> Am Mittwoch, den 18.10.2017, 22:02 +0800 schrieb Moritz Angermann:
>>>> Hi,
>>>> 
>>>> so this somehow looks like for a not yet absolutely clear reason to me,
>>>> when building ghci, we fail to link in libffi, for some configurations.
>>>> 
>>>> Joachim, as far as I could see, you are using ghc 8.0.1 to boostrap the
>>>> compiler. Thomas are you by any chance bootstrapping with 8.0.1 as well?
>>>> I assume Ben bootstraps wit 8.2.1.
>>>> 
>>>> I'll set up a Ubuntu 16.10 machine tomorrow and try to reproduce this.
>>>> 
>>>> Joachim, is perf.haskell.org running Ubuntu as well?
>>>> 
>>>> Cheers,
>>>> Moritz
>>>> 
>>>>> On Oct 11, 2017, at 1:43 AM, Thomas Jakway <tjakway at nyu.edu> wrote:
>>>>> 
>>>>> Thanks for getting back to me.
>>>>> 
>>>>> (I think you mean `git clean -x -f -d`): I usually omit -x but I'll give it a go and report back.
>>>>> 
>>>>> Before I got the issue on a clean checkout I thought it was something I did to the build files.
>>>>> 
>>>>> I also tried building the latest release of libffi (v3.2.1) and using it in configure with --with-ffi-includes and --with-ffi-libraries but got the same error.
>>>>> 
>>>>> 
>>>>>> On 10/09/2017 02:40 AM, Moritz Angermann wrote:
>>>>>> Yes, this commit indeed introduced the need for makeinfo, however after some debugging and improved packaging of the external libffi library, this dependency was removed again, and should not be required with the latest head anymore.
>>>>>> 
>>>>>> Then again this should not result in link issues but rather in build time issues.
>>>>>> 
>>>>>> The key to libffi is the libffi-tarballs git submodule, which contains the packaged libffi-tarballs. Make sure all your submodules are also updated.
>>>>>> 
>>>>>> I usually use `git -x -f -d` (read the documentation first) to ensure a clean working tree. Especially as you say you can’t reproduce it on other machines, maybe there is a file in your tree that the cleaning did not catch?
>>>>>> 
>>>>>> Sent from my iPhone
>>>>>> 
>>>>>>> On 9 Oct 2017, at 4:31 AM, Thomas Jakway <tjakway at nyu.edu> wrote:
>>>>>>> 
>>>>>>> I'm on Ubuntu 16.10.
>>>>>>> 
>>>>>>> I ran git bisect:
>>>>>>> 
>>>>>>> ----------------------
>>>>>>> 
>>>>>>> e515c7f37be97e1c2ccc497ddd0a730e63ddfa82 is the first bad commit
>>>>>>> commit e515c7f37be97e1c2ccc497ddd0a730e63ddfa82
>>>>>>> Author: Moritz Angermann <moritz.angermann at gmail.com>
>>>>>>> Date:   Sat Sep 30 09:31:12 2017 -0400
>>>>>>> 
>>>>>>> Allow libffi snapshots
>>>>>>> 
>>>>>>> This is rather annoying. I'd prefer to have a stable release to
>>>>>>> use. However libffi-3.2.1 has been released November 12, 2014, and
>>>>>>> libffi-4 is TBD. See also https://github.com/libffi/libffi/issues/296
>>>>>>> 
>>>>>>> The core reason for this change is that llvm changed the supported
>>>>>>> assembly to unified syntax, which libffi-3.2.1 does not use, and hence
>>>>>>> fails to compile for arm with llvm. For refence, see the following
>>>>>>> issue: https://github.com/libffi/libffi/issues/191.
>>>>>>> 
>>>>>>> This diff contains a script to generate a tarball for the
>>>>>>> `libffi-tarballs` repository from the libffi GitHub repository; as well
>>>>>>> as the necessary changes to the build system.
>>>>>>> 
>>>>>>> Updates libffi-tarballs submodule.
>>>>>>> 
>>>>>>> Reviewers: austin, bgamari, hvr
>>>>>>> 
>>>>>>> Subscribers: hvr, erikd, rwbarton, thomie
>>>>>>> 
>>>>>>> Differential Revision: https://phabricator.haskell.org/D3574
>>>>>>> 
>>>>>>> ----------------------
>>>>>>> 
>>>>>>> I can't reproduce it on my other linux computers though.
>>>>>>> 
>>>>>>> 
>>>>>>>> On 10/04/2017 02:17 PM, Ben Gamari wrote:
>>>>>>>> Thomas Jakway <tjakway at nyu.edu> writes:
>>>>>>>> 
>>>>>>>>> Anyone else getting linker errors?
>>>>>>>>> 
>>>>>>>>> This is after running
>>>>>>>>> 
>>>>>>>>> make clean && make distclean && find . -name "*.o" -type f -delete &&
>>>>>>>>> find . -name "*.hi" -type f -delete
>>>>>>>>> 
>>>>>>>>> then
>>>>>>>>> 
>>>>>>>>> ./boot && ./configure && make -j5
>>>>>>>>> 
>>>>>>>>> (ghc-new is not a new checkout, this error is happening on a branch I'm
>>>>>>>>> working on, but one that doesn't touch the FFI)
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> I'm afraid I can't reproduce this. What platform/operating system is
>>>>>>>> this on?
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> 
>>>>>>>> - Ben
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> ghc-devs mailing list
>>>>>>> ghc-devs at haskell.org
>>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>> 
>>>>> _______________________________________________
>>>>> ghc-devs mailing list
>>>>> ghc-devs at haskell.org
>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>> 
>>>> 
>>> 
>>> -- 
>>> Joachim Breitner
>>> mail at joachim-breitner.de
>>> http://www.joachim-breitner.de/
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> 
>> ————————————————— 
>> Moritz Angermann
>> +49 170 54 33 0 74
>> moritz at lichtzwerge.de
>> 
>> lichtzwerge GmbH
>> Raiffeisenstr. 8
>> 93185 Michelsneukirchen
>> 
>> Amtsgericht Regensburg HRB 14723
>> 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.
>> 
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> -- 
> Joachim “nomeata” Breitner
>  mail at joachim-breitner.de
>  https://www.joachim-breitner.de/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From mail at joachim-breitner.de  Mon Oct 23 12:57:14 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 23 Oct 2017 08:57:14 -0400
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <DF074BAD-9153-4B23-AF80-B7ED5535DE5B@gmail.com>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
 <8760bur4sj.fsf@ben-laptop.smart-cactus.org>
 <afafc3d6-253e-980f-2176-39ae5e734858@nyu.edu>
 <A18C8C4B-E72B-47CC-9B1E-B3896EB106EC@lichtzwerge.de>
 <239c9cd9-94f4-5179-e53e-17c1542fd0f4@nyu.edu>
 <9F3CBB9B-1885-4A4C-B412-05B5D9B70DCE@lichtzwerge.de>
 <1508341094.24214.1.camel@joachim-breitner.de>
 <8E8FA99F-66D5-4804-BDAE-819C333D20B0@lichtzwerge.de>
 <1508762736.5323.3.camel@joachim-breitner.de>
 <DF074BAD-9153-4B23-AF80-B7ED5535DE5B@gmail.com>
Message-ID: <1508763434.5323.7.camel@joachim-breitner.de>

Hi,

Am Montag, den 23.10.2017, 20:49 +0800 schrieb Moritz Angermann:
> I still can’t make sense of this. Is your gold a different version now as well?

It is “GNU gold (GNU Binutils 2.29.1) 1.14” now, and it seems it was
upgraded:
[2017-10-22 16:58] [ALPM] upgraded binutils (2.27-1 -> 2.29.1-1)

Here is the full build log:
https://raw.githubusercontent.com/nomeata/ghc-speed-logs/master/052ec24412e285aa34911d6187cc2227fc7d86d9.log

Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171023/d247127a/attachment.sig>

From sylvain at haskus.fr  Mon Oct 23 13:07:46 2017
From: sylvain at haskus.fr (Sylvain Henry)
Date: Mon, 23 Oct 2017 15:07:46 +0200
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <1508763434.5323.7.camel@joachim-breitner.de>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
 <8760bur4sj.fsf@ben-laptop.smart-cactus.org>
 <afafc3d6-253e-980f-2176-39ae5e734858@nyu.edu>
 <A18C8C4B-E72B-47CC-9B1E-B3896EB106EC@lichtzwerge.de>
 <239c9cd9-94f4-5179-e53e-17c1542fd0f4@nyu.edu>
 <9F3CBB9B-1885-4A4C-B412-05B5D9B70DCE@lichtzwerge.de>
 <1508341094.24214.1.camel@joachim-breitner.de>
 <8E8FA99F-66D5-4804-BDAE-819C333D20B0@lichtzwerge.de>
 <1508762736.5323.3.camel@joachim-breitner.de>
 <DF074BAD-9153-4B23-AF80-B7ED5535DE5B@gmail.com>
 <1508763434.5323.7.camel@joachim-breitner.de>
Message-ID: <e88e7ee4-e955-302c-b024-6fde7a347986@haskus.fr>

I don't know if it helps, but upgrading my ArchLinux installation 
yesterday broke my builds because of linker issues with stack. I now 
have to specify "ghc-build: nopie" in stack.yaml file. (cf 
https://github.com/commercialhaskell/stack/issues/2712)

Could your error be related to PIE too?


On 23/10/2017 14:57, Joachim Breitner wrote:
> Hi,
>
> Am Montag, den 23.10.2017, 20:49 +0800 schrieb Moritz Angermann:
>> I still can’t make sense of this. Is your gold a different version now as well?
> It is “GNU gold (GNU Binutils 2.29.1) 1.14” now, and it seems it was
> upgraded:
> [2017-10-22 16:58] [ALPM] upgraded binutils (2.27-1 -> 2.29.1-1)
>
> Here is the full build log:
> https://raw.githubusercontent.com/nomeata/ghc-speed-logs/master/052ec24412e285aa34911d6187cc2227fc7d86d9.log
>
> Joachim
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171023/1e3ef30b/attachment.html>

From simonpj at microsoft.com  Mon Oct 23 13:13:49 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 23 Oct 2017 13:13:49 +0000
Subject: Can't build docs
Message-ID: <AM4PR83MB0033515DEDA8E361C833AF84AD460@AM4PR83MB0033.EURPRD83.prod.outlook.com>

On Linux I can't build the docs.  Log below
Simon


"inplace/bin/ghc-stage1" -this-unit-id rts -shared -dynamic -dynload deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath -optl-Wl,'$ORIGIN' -optl-Wl,-zorigin `cat rts/dist/libs.depend` rts/dist/build/Adjustor.l_dyn_o rts/dist/build/Arena.l_dyn_o rts/dist/build/Capability.l_dyn_o rts/dist/build/CheckUnload.l_dyn_o rts/dist/build/ClosureFlags.l_dyn_o rts/dist/build/Disassembler.l_dyn_o rts/dist/build/FileLock.l_dyn_o rts/dist/build/Globals.l_dyn_o rts/dist/build/Hash.l_dyn_o rts/dist/build/Hpc.l_dyn_o rts/dist/build/HsFFI.l_dyn_o rts/dist/build/Inlines.l_dyn_o rts/dist/build/Interpreter.l_dyn_o rts/dist/build/LdvProfile.l_dyn_o rts/dist/build/Libdw.l_dyn_o rts/dist/build/LibdwPool.l_dyn_o rts/dist/build/Linker.l_dyn_o rts/dist/build/Messages.l_dyn_o rts/dist/build/OldARMAtomic.l_dyn_o rts/dist/build/PathUtils.l_dyn_o rts/dist/build/Pool.l_dyn_o rts/dist/build/Printer.l_dyn_o rts/dist/build/ProfHeap.l_dyn_o rts/dist/build/ProfilerReport.l_dyn_o rts/dist/build/ProfilerReportJson.l_dyn_o rts/dist/build/Profiling.l_dyn_o rts/dist/build/Proftimer.l_dyn_o rts/dist/build/RaiseAsync.l_dyn_o rts/dist/build/RetainerProfile.l_dyn_o rts/dist/build/RetainerSet.l_dyn_o rts/dist/build/RtsAPI.l_dyn_o rts/dist/build/RtsDllMain.l_dyn_o rts/dist/build/RtsFlags.l_dyn_o rts/dist/build/RtsMain.l_dyn_o rts/dist/build/RtsMessages.l_dyn_o rts/dist/build/RtsStartup.l_dyn_o rts/dist/build/RtsSymbolInfo.l_dyn_o rts/dist/build/RtsSymbols.l_dyn_o rts/dist/build/RtsUtils.l_dyn_o rts/dist/build/Schedule.l_dyn_o rts/dist/build/Sparks.l_dyn_o rts/dist/build/Stable.l_dyn_o rts/dist/build/StaticPtrTable.l_dyn_o rts/dist/build/Stats.l_dyn_o rts/dist/build/StgCRun.l_dyn_o rts/dist/build/StgPrimFloat.l_dyn_o rts/dist/build/STM.l_dyn_o rts/dist/build/Task.l_dyn_o rts/dist/build/ThreadLabels.l_dyn_o rts/dist/build/ThreadPaused.l_dyn_o rts/dist/build/Threads.l_dyn_o rts/dist/build/Ticky.l_dyn_o rts/dist/build/Timer.l_dyn_o rts/dist/build/TopHandler.l_dyn_o rts/dist/build/Trace.l_dyn_o rts/dist/build/Weak.l_dyn_o rts/dist/build/WSDeque.l_dyn_o rts/dist/build/xxhash.l_dyn_o rts/dist/build/hooks/FlagDefaults.l_dyn_o rts/dist/build/hooks/MallocFail.l_dyn_o rts/dist/build/hooks/OnExit.l_dyn_o rts/dist/build/hooks/OutOfHeap.l_dyn_o rts/dist/build/hooks/StackOverflow.l_dyn_o rts/dist/build/sm/BlockAlloc.l_dyn_o rts/dist/build/sm/CNF.l_dyn_o rts/dist/build/sm/Compact.l_dyn_o rts/dist/build/sm/Evac.l_dyn_o rts/dist/build/sm/Evac_thr.l_dyn_o rts/dist/build/sm/GCAux.l_dyn_o rts/dist/build/sm/GC.l_dyn_o rts/dist/build/sm/GCUtils.l_dyn_o rts/dist/build/sm/MarkWeak.l_dyn_o rts/dist/build/sm/MBlock.l_dyn_o rts/dist/build/sm/Sanity.l_dyn_o rts/dist/build/sm/Scav.l_dyn_o rts/dist/build/sm/Scav_thr.l_dyn_o rts/dist/build/sm/Storage.l_dyn_o rts/dist/build/sm/Sweep.l_dyn_o rts/dist/build/eventlog/EventLog.l_dyn_o rts/dist/build/eventlog/EventLogWriter.l_dyn_o rts/dist/build/linker/CacheFlush.l_dyn_o rts/dist/build/linker/Elf.l_dyn_o rts/dist/build/linker/elf_got.l_dyn_o rts/dist/build/linker/elf_plt_aarch64.l_dyn_o rts/dist/build/linker/elf_plt_arm.l_dyn_o rts/dist/build/linker/elf_plt.l_dyn_o rts/dist/build/linker/elf_reloc_aarch64.l_dyn_o rts/dist/build/linker/elf_reloc.l_dyn_o rts/dist/build/linker/elf_util.l_dyn_o rts/dist/build/linker/LoadArchive.l_dyn_o rts/dist/build/linker/M32Alloc.l_dyn_o rts/dist/build/linker/MachO.l_dyn_o rts/dist/build/linker/PEi386.l_dyn_o rts/dist/build/linker/SymbolExtras.l_dyn_o rts/dist/build/posix/GetEnv.l_dyn_o rts/dist/build/posix/GetTime.l_dyn_o rts/dist/build/posix/Itimer.l_dyn_o rts/dist/build/posix/OSMem.l_dyn_o rts/dist/build/posix/OSThreads.l_dyn_o rts/dist/build/posix/Select.l_dyn_o rts/dist/build/posix/Signals.l_dyn_o rts/dist/build/posix/TTY.l_dyn_o   rts/dist/build/Apply.l_dyn_o rts/dist/build/Compact.l_dyn_o rts/dist/build/Exception.l_dyn_o rts/dist/build/HeapStackCheck.l_dyn_o rts/dist/build/PrimOps.l_dyn_o rts/dist/build/StgMiscClosures.l_dyn_o rts/dist/build/StgStartup.l_dyn_o rts/dist/build/StgStdThunks.l_dyn_o rts/dist/build/Updates.l_dyn_o rts/dist/build/AutoApply.l_dyn_o  -fPIC -dynamic -eventlog  -O0 -H64m -Wall -fllvm-fill-undef-with-garbage    -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint      -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen            -O2 -Wcpp-undef    -Wnoncanonical-monad-instances   -o rts/dist/build/libHSrts_l-ghc8.3.20171020.so
"inplace/bin/ghc-stage1" -this-unit-id rts -shared -dynamic -dynload deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath -optl-Wl,'$ORIGIN' -optl-Wl,-zorigin `cat rts/dist/libs.depend` rts/dist/build/Adjustor.thr_l_dyn_o rts/dist/build/Arena.thr_l_dyn_o rts/dist/build/Capability.thr_l_dyn_o rts/dist/build/CheckUnload.thr_l_dyn_o rts/dist/build/ClosureFlags.thr_l_dyn_o rts/dist/build/Disassembler.thr_l_dyn_o rts/dist/build/FileLock.thr_l_dyn_o rts/dist/build/Globals.thr_l_dyn_o rts/dist/build/Hash.thr_l_dyn_o rts/dist/build/Hpc.thr_l_dyn_o rts/dist/build/HsFFI.thr_l_dyn_o rts/dist/build/Inlines.thr_l_dyn_o rts/dist/build/Interpreter.thr_l_dyn_o rts/dist/build/LdvProfile.thr_l_dyn_o rts/dist/build/Libdw.thr_l_dyn_o rts/dist/build/LibdwPool.thr_l_dyn_o rts/dist/build/Linker.thr_l_dyn_o rts/dist/build/Messages.thr_l_dyn_o rts/dist/build/OldARMAtomic.thr_l_dyn_o rts/dist/build/PathUtils.thr_l_dyn_o rts/dist/build/Pool.thr_l_dyn_o rts/dist/build/Printer.thr_l_dyn_o rts/dist/build/ProfHeap.thr_l_dyn_o rts/dist/build/ProfilerReport.thr_l_dyn_o rts/dist/build/ProfilerReportJson.thr_l_dyn_o rts/dist/build/Profiling.thr_l_dyn_o rts/dist/build/Proftimer.thr_l_dyn_o rts/dist/build/RaiseAsync.thr_l_dyn_o rts/dist/build/RetainerProfile.thr_l_dyn_o rts/dist/build/RetainerSet.thr_l_dyn_o rts/dist/build/RtsAPI.thr_l_dyn_o rts/dist/build/RtsDllMain.thr_l_dyn_o rts/dist/build/RtsFlags.thr_l_dyn_o rts/dist/build/RtsMain.thr_l_dyn_o rts/dist/build/RtsMessages.thr_l_dyn_o rts/dist/build/RtsStartup.thr_l_dyn_o rts/dist/build/RtsSymbolInfo.thr_l_dyn_o rts/dist/build/RtsSymbols.thr_l_dyn_o rts/dist/build/RtsUtils.thr_l_dyn_o rts/dist/build/Schedule.thr_l_dyn_o rts/dist/build/Sparks.thr_l_dyn_o rts/dist/build/Stable.thr_l_dyn_o rts/dist/build/StaticPtrTable.thr_l_dyn_o rts/dist/build/Stats.thr_l_dyn_o rts/dist/build/StgCRun.thr_l_dyn_o rts/dist/build/StgPrimFloat.thr_l_dyn_o rts/dist/build/STM.thr_l_dyn_o rts/dist/build/Task.thr_l_dyn_o rts/dist/build/ThreadLabels.thr_l_dyn_o rts/dist/build/ThreadPaused.thr_l_dyn_o rts/dist/build/Threads.thr_l_dyn_o rts/dist/build/Ticky.thr_l_dyn_o rts/dist/build/Timer.thr_l_dyn_o rts/dist/build/TopHandler.thr_l_dyn_o rts/dist/build/Trace.thr_l_dyn_o rts/dist/build/Weak.thr_l_dyn_o rts/dist/build/WSDeque.thr_l_dyn_o rts/dist/build/xxhash.thr_l_dyn_o rts/dist/build/hooks/FlagDefaults.thr_l_dyn_o rts/dist/build/hooks/MallocFail.thr_l_dyn_o rts/dist/build/hooks/OnExit.thr_l_dyn_o rts/dist/build/hooks/OutOfHeap.thr_l_dyn_o rts/dist/build/hooks/StackOverflow.thr_l_dyn_o rts/dist/build/sm/BlockAlloc.thr_l_dyn_o rts/dist/build/sm/CNF.thr_l_dyn_o rts/dist/build/sm/Compact.thr_l_dyn_o rts/dist/build/sm/Evac.thr_l_dyn_o rts/dist/build/sm/Evac_thr.thr_l_dyn_o rts/dist/build/sm/GCAux.thr_l_dyn_o rts/dist/build/sm/GC.thr_l_dyn_o rts/dist/build/sm/GCUtils.thr_l_dyn_o rts/dist/build/sm/MarkWeak.thr_l_dyn_o rts/dist/build/sm/MBlock.thr_l_dyn_o rts/dist/build/sm/Sanity.thr_l_dyn_o rts/dist/build/sm/Scav.thr_l_dyn_o rts/dist/build/sm/Scav_thr.thr_l_dyn_o rts/dist/build/sm/Storage.thr_l_dyn_o rts/dist/build/sm/Sweep.thr_l_dyn_o rts/dist/build/eventlog/EventLog.thr_l_dyn_o rts/dist/build/eventlog/EventLogWriter.thr_l_dyn_o rts/dist/build/linker/CacheFlush.thr_l_dyn_o rts/dist/build/linker/Elf.thr_l_dyn_o rts/dist/build/linker/elf_got.thr_l_dyn_o rts/dist/build/linker/elf_plt_aarch64.thr_l_dyn_o rts/dist/build/linker/elf_plt_arm.thr_l_dyn_o rts/dist/build/linker/elf_plt.thr_l_dyn_o rts/dist/build/linker/elf_reloc_aarch64.thr_l_dyn_o rts/dist/build/linker/elf_reloc.thr_l_dyn_o rts/dist/build/linker/elf_util.thr_l_dyn_o rts/dist/build/linker/LoadArchive.thr_l_dyn_o rts/dist/build/linker/M32Alloc.thr_l_dyn_o rts/dist/build/linker/MachO.thr_l_dyn_o rts/dist/build/linker/PEi386.thr_l_dyn_o rts/dist/build/linker/SymbolExtras.thr_l_dyn_o rts/dist/build/posix/GetEnv.thr_l_dyn_o rts/dist/build/posix/GetTime.thr_l_dyn_o rts/dist/build/posix/Itimer.thr_l_dyn_o rts/dist/build/posix/OSMem.thr_l_dyn_o rts/dist/build/posix/OSThreads.thr_l_dyn_o rts/dist/build/posix/Select.thr_l_dyn_o rts/dist/build/posix/Signals.thr_l_dyn_o rts/dist/build/posix/TTY.thr_l_dyn_o   rts/dist/build/Apply.thr_l_dyn_o rts/dist/build/Compact.thr_l_dyn_o rts/dist/build/Exception.thr_l_dyn_o rts/dist/build/HeapStackCheck.thr_l_dyn_o rts/dist/build/PrimOps.thr_l_dyn_o rts/dist/build/StgMiscClosures.thr_l_dyn_o rts/dist/build/StgStartup.thr_l_dyn_o rts/dist/build/StgStdThunks.thr_l_dyn_o rts/dist/build/Updates.thr_l_dyn_o rts/dist/build/AutoApply.thr_l_dyn_o  -fPIC -dynamic -optc-DTHREADED_RTS -eventlog  -O0 -H64m -Wall -fllvm-fill-undef-with-garbage    -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint      -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen            -O2 -Wcpp-undef    -Wnoncanonical-monad-instances   -o rts/dist/build/libHSrts_thr_l-ghc8.3.20171020.so
Running Sphinx v1.1.3
Running Sphinx v1.1.3
Running Sphinx v1.1.3
loading pickled environment... loading pickled environment... loading pickled environment... done
done
done
building [latex]: all documents
building [man]: all manpages
updating environment: updating environment: 0 added, 2 changed, 0 removed
reading sources... [ 50%] 8.4.1-notes
0 added, 2 changed, 0 removed
reading sources... [ 50%] 8.4.1-notes
reading sources... [100%] runtime_control
reading sources... [100%] runtime_control

looking for now-outdated files...
looking for now-outdated files... none found
pickling environment... none found
pickling environment... done
checking consistency... /5playpen/simonpj/HEAD/docs/users_guide/what_glasgow_exts_does.rst:: WARNING: document isn't included in any toctree
done
writing... ghc.1 { } done
checking consistency... /5playpen/simonpj/HEAD/docs/users_guide/what_glasgow_exts_does.rst:: WARNING: document isn't included in any toctree
done
processing users_guide.tex... index license intro 8.2.1-notes 8.4.1-notes ghci runghc usage using using-warnings using-optimisation
Exception occurred:
  File "/usr/lib/python2.7/dist-packages/docutils/writers/__init__.py", line 77, in write
    self.translate()
  File "/usr/lib/python2.7/dist-packages/sphinx/writers/manpage.py", line 35, in translate
    self.document.walkabout(visitor)
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in walkabout
    if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in walkabout
    if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in walkabout
    if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in walkabout
    if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in walkabout
    if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 165, in walkabout
    visitor.dispatch_visit(self)
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 1604, in dispatch_visit
    return method(node)
  File "/usr/lib/python2.7/dist-packages/sphinx/writers/manpage.py", line 345, in unknown_visit
    raise NotImplementedError('Unknown node: ' + node.__class__.__name__)
NotImplementedError: Unknown node: inline
The full traceback has been saved in /tmp/sphinx-err-hAgScz.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
Either send bugs to the mailing list at <http://groups.google.com/group/sphinx-dev/>,
or report them in the tracker at <http://bitbucket.org/birkenfeld/sphinx/issues/>. Thanks!
using-concurrent flags make[1]: *** [docs/users_guide/build-man/ghc.1] Error 1
make[1]: *** Waiting for unfinished jobs....
runtime_control separate_compilation packages codegens phases shared_libs debugging profiling sooner lang glasgow_exts parallel safe_haskell ffi-chap extending_ghc gone_wrong debug-info utils win32-dlls bugs eventlog-formats editing-guide
resolving references...
writing... /5playpen/simonpj/HEAD/docs/users_guide/8.2.1-notes.rst:: WARNING: unusable reference target found: ../libraries/ghc-compact-0.1.0.0/GHC-Compact.html
building [html]: targets for 37 source files that are out of date
updating environment: /5playpen/simonpj/HEAD/docs/users_guide/ghci.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/Control-Exception.html
0 added, 2 changed, 0 removed
reading sources... [ 50%] 8.4.1-notes
reading sources... [100%] runtime_control
/5playpen/simonpj/HEAD/docs/users_guide/using-concurrent.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/Control-Concurrent.html
/5playpen/simonpj/HEAD/docs/users_guide/using-concurrent.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/Control-Concurrent.html#v:setNumCapabilities
/5playpen/simonpj/HEAD/docs/users_guide/using-concurrent.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/Control-Concurrent.html#v:forkOn

looking for now-outdated files... none found
pickling environment... /5playpen/simonpj/HEAD/docs/users_guide/runtime_control.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/GHC-Conc.html#v:enableAllocationLimit
/5playpen/simonpj/HEAD/docs/users_guide/runtime_control.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/GHC-Conc.html#v:par
/5playpen/simonpj/HEAD/docs/users_guide/runtime_control.rst:: WARNING: unusable reference target found: ../libraries/base-4.11.0.0/GHC-Stats.html
done
checking consistency... /5playpen/simonpj/HEAD/docs/users_guide/what_glasgow_exts_does.rst:: WARNING: document isn't included in any toctree
done
preparing documents...
Exception occurred:
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in walkabout
    if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in walkabout
    if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in walkabout
    if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in walkabout
    if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in walkabout
    if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in walkabout
    if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in walkabout
    if child.walkabout(visitor):
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 165, in walkabout
    visitor.dispatch_visit(self)
  File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 1604, in dispatch_visit
    return method(node)
  File "/usr/lib/python2.7/dist-packages/sphinx/writers/latex.py", line 1176, in visit_reference
    self.in_productionlist:
AttributeError: LaTeXTranslator instance has no attribute 'in_productionlist'
The full traceback has been saved in /tmp/sphinx-err-WghQBt.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
Either send bugs to the mailing list at <http://groups.google.com/group/sphinx-dev/>,
or report them in the tracker at <http://bitbucket.org/birkenfeld/sphinx/issues/>. Thanks!
done
writing output... [  2%] 8.2.1-notes
make[1]: *** [docs/users_guide/users_guide.pdf] Error 1
writing output... [  5%] 8.4.1-notes
writing output... [  8%] bugs
writing output... [ 10%] codegens
writing output... [ 13%] debug-info
writing output... [ 16%] debugging
writing output... [ 18%] editing-guide
writing output... [ 21%] eventlog-formats
writing output... [ 24%] extending_ghc
writing output... [ 27%] ffi-chap
writing output... [ 29%] flags
writing output... [ 32%] ghc
writing output... [ 35%] ghci
writing output... [ 37%] glasgow_exts
writing output... [ 40%] gone_wrong
writing output... [ 43%] index
writing output... [ 45%] intro
writing output... [ 48%] lang
writing output... [ 51%] license
writing output... [ 54%] packages
writing output... [ 56%] parallel
writing output... [ 59%] phases
writing output... [ 62%] profiling
/5playpen/simonpj/HEAD/docs/users_guide/profiling.rst:557: WARNING: Pygments lexer name u'json' is not known
writing output... [ 64%] runghc
writing output... [ 67%] runtime_control
writing output... [ 70%] safe_haskell
writing output... [ 72%] separate_compilation
writing output... [ 75%] shared_libs
writing output... [ 78%] sooner
writing output... [ 81%] usage
writing output... [ 83%] using
writing output... [ 86%] using-concurrent
writing output... [ 89%] using-optimisation
writing output... [ 91%] using-warnings
writing output... [ 94%] utils
writing output... [ 97%] what_glasgow_exts_does
writing output... [100%] win32-dlls

writing additional files... genindex search opensearch
copying images... [100%] images/prof_scc.svg

copying static files... done
dumping search index... done
dumping object inventory... done
build succeeded, 2 warnings.
make: *** [all] Error 2
simonpj at cam-05-unx:~/5builds/HEAD$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171023/de45bf91/attachment-0001.html>

From simonpj at microsoft.com  Mon Oct 23 13:32:51 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 23 Oct 2017 13:32:51 +0000
Subject: haddock specializeInstHead
In-Reply-To: <CANma=H8wuY9np-xUkEei-JrJvSAWouXQsZ3PaH97Adx2WpaD1Q@mail.gmail.com>
References: <CANma=H8wuY9np-xUkEei-JrJvSAWouXQsZ3PaH97Adx2WpaD1Q@mail.gmail.com>
Message-ID: <AM4PR83MB00334B96D92BD3E070C7B8E0AD460@AM4PR83MB0033.EURPRD83.prod.outlook.com>

I don’t know, but my instinct is to stick to the monomorphic version for now, it that’s all you need.

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman
Sent: 20 October 2017 18:33
To: ghc-devs at haskell.org
Subject: haddock specializeInstHead

I am working the next stage of Trees that Grow into GHC [1], and need to update Haddock.
The `Specialize` module[2] exports a single function, `specializeInstHead` which is called once, specialised to `GhcRn`.
So all it needs to be for haddock use is

specializeInstHead :: InstHead GhcRn -> InstHead GhcRn
But the entire module is polymorphic in the AST parameter, so it has the following instead

specializeInstHead :: (Ord (IdP name), DataId name, SetName (IdP name),
                                NamedThing (IdP name))
                       => InstHead name -> InstHead name

Question: does it need to be so polymorphic?

I am hitting issues getting the type parameter change worked through, and it seems a bit pointless to slog on with it if it is unnecessary.

Alan

[1] https://github.com/ghc/ghc/tree/wip/ttg-2017-10-13<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc%2Fghc%2Ftree%2Fwip%2Fttg-2017-10-13&data=02%7C01%7Csimonpj%40microsoft.com%7C26b5b86e96f145f964ce08d517e0cc6e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636441176634035520&sdata=EU40hO%2FHQ70tAYkU1djv8e5wYNyHhw%2BTQImO3wzUer0%3D&reserved=0>
[2] https://github.com/haskell/haddock/blob/a5bdb46185b7c0b3fced9a7fac9a62883d9d57b7/haddock-api/src/Haddock/Interface/Specialize.hs#L87<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhaskell%2Fhaddock%2Fblob%2Fa5bdb46185b7c0b3fced9a7fac9a62883d9d57b7%2Fhaddock-api%2Fsrc%2FHaddock%2FInterface%2FSpecialize.hs%23L87&data=02%7C01%7Csimonpj%40microsoft.com%7C26b5b86e96f145f964ce08d517e0cc6e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636441176634035520&sdata=zgUxljZMi2uml5nHRrtj%2B3mcoQq7%2BFUFxbJzEqpHC5Y%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171023/4721d636/attachment.html>

From ben at smart-cactus.org  Mon Oct 23 14:42:03 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 23 Oct 2017 10:42:03 -0400
Subject: GHC HEAD now needs extra tools to build libffi?
In-Reply-To: <e88e7ee4-e955-302c-b024-6fde7a347986@haskus.fr>
References: <CADdQpRBRP=NUBxMXNShk6utZyHz3DEtJ6ykiM_OBKhb8ATtCMA@mail.gmail.com>
 <9B85C460-18A2-4E1F-9473-A9A582198A26@lichtzwerge.de>
 <69d67810-9bac-ac1e-85f9-6db9a987dcc3@nyu.edu>
 <8760bur4sj.fsf@ben-laptop.smart-cactus.org>
 <afafc3d6-253e-980f-2176-39ae5e734858@nyu.edu>
 <A18C8C4B-E72B-47CC-9B1E-B3896EB106EC@lichtzwerge.de>
 <239c9cd9-94f4-5179-e53e-17c1542fd0f4@nyu.edu>
 <9F3CBB9B-1885-4A4C-B412-05B5D9B70DCE@lichtzwerge.de>
 <1508341094.24214.1.camel@joachim-breitner.de>
 <8E8FA99F-66D5-4804-BDAE-819C333D20B0@lichtzwerge.de>
 <1508762736.5323.3.camel@joachim-breitner.de>
 <DF074BAD-9153-4B23-AF80-B7ED5535DE5B@gmail.com>
 <1508763434.5323.7.camel@joachim-breitner.de>
 <e88e7ee4-e955-302c-b024-6fde7a347986@haskus.fr>
Message-ID: <877evmgc3o.fsf@ben-laptop.smart-cactus.org>

Sylvain Henry <sylvain at haskus.fr> writes:

> I don't know if it helps, but upgrading my ArchLinux installation 
> yesterday broke my builds because of linker issues with stack. I now 
> have to specify "ghc-build: nopie" in stack.yaml file. (cf 
> https://github.com/commercialhaskell/stack/issues/2712)
>
> Could your error be related to PIE too?
>
Note that this (Trac #12759) was worked around in GHC 8.0.2 via a
autoconf check. Consequently, upgrading the your C toolchain may
require that you reinstall GHC.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171023/378e86df/attachment.sig>

From ben at smart-cactus.org  Mon Oct 23 14:44:22 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 23 Oct 2017 10:44:22 -0400
Subject: Can't build docs
In-Reply-To: <AM4PR83MB0033515DEDA8E361C833AF84AD460@AM4PR83MB0033.EURPRD83.prod.outlook.com>
References: <AM4PR83MB0033515DEDA8E361C833AF84AD460@AM4PR83MB0033.EURPRD83.prod.outlook.com>
Message-ID: <874lqphqk9.fsf@ben-laptop.smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:

> On Linux I can't build the docs.  Log below
> Simon
>

[snip]

> processing users_guide.tex... index license intro 8.2.1-notes 8.4.1-notes ghci runghc usage using using-warnings using-optimisation
> Exception occurred:
>   File "/usr/lib/python2.7/dist-packages/docutils/writers/__init__.py", line 77, in write
>     self.translate()
>   File "/usr/lib/python2.7/dist-packages/sphinx/writers/manpage.py", line 35, in translate
>     self.document.walkabout(visitor)
>   File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in walkabout
>     if child.walkabout(visitor):
>   File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in walkabout
>     if child.walkabout(visitor):
>   File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in walkabout
>     if child.walkabout(visitor):
>   File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in walkabout
>     if child.walkabout(visitor):
>   File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in walkabout
>     if child.walkabout(visitor):
>   File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 165, in walkabout
>     visitor.dispatch_visit(self)
>   File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 1604, in dispatch_visit
>     return method(node)
>   File "/usr/lib/python2.7/dist-packages/sphinx/writers/manpage.py", line 345, in unknown_visit
>     raise NotImplementedError('Unknown node: ' + node.__class__.__name__)
> NotImplementedError: Unknown node: inline

Hmm, it sounds like this might be a real version incompatibility.
Perhaps we should have autoconf do a more strict version check of sphinx
and disable BUILD_SPHINX_{PDF,HTML} if too old a version is found.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171023/c96b97fa/attachment.sig>

From alan.zimm at gmail.com  Mon Oct 23 15:06:57 2017
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Mon, 23 Oct 2017 17:06:57 +0200
Subject: forall in constraint
Message-ID: <CANma=H951cD8aO5fs_OacaCxeFiX2ZkFbHMvksfYaO78fU4M+w@mail.gmail.com>

I am working on the Trees that Grow stuff, and hit a small problem

I have

type family XIB               x thing
type family XNewImplicitBndrs x thing

type ForallXImplicitBndrs (c :: * -> Constraint) (x :: *) (thing :: *) =
       ( c (XIB               x thing)
       , c (XNewImplicitBndrs x thing)
       )

and I want to extend the DataId constraint

type DataId p =
  ( Data p

  , ForallXImplicitBndrs Data p thing
  )

But the problem is I do not have `thing` at this point, and to get it in
the code will involve some hs-boot nastiness.

Is there any way to require "forall thing. Data thing" inside the DataId
constraint?

Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171023/77c963b5/attachment-0001.html>

From lysxia at gmail.com  Mon Oct 23 15:54:28 2017
From: lysxia at gmail.com (Li-yao Xia)
Date: Mon, 23 Oct 2017 11:54:28 -0400
Subject: forall in constraint
In-Reply-To: <CANma=H951cD8aO5fs_OacaCxeFiX2ZkFbHMvksfYaO78fU4M+w@mail.gmail.com>
References: <mailman.151717.1508769498.19672.ghc-devs@haskell.org>
 <mailman.151717.1508769498.19672.ghc-devs.{e4a70ef9-3e41-4b64-ab03-9fbc222a484f}.0@haskell.org>
 <CANma=H951cD8aO5fs_OacaCxeFiX2ZkFbHMvksfYaO78fU4M+w@mail.gmail.com>
Message-ID: <1928bdba-c12a-0bf5-2dd8-ebab8381eb59@gmail.com>

Hi Alan,

One way is to define a new typeclass.


type ImplicitBndrs c x thing
   = (c (XIB x thing), c (XNewImplicitBndrs x thing))

class ForallImplicitBndrs c x where
   withImplicitBndrs
     :: forall thing. (ImplicitBndrs c x thing => t) -> t


Although that requires you to write one instance for every combination 
of (c, x).
The "universal instance" of ImplicitBndrs can also be wrapped in the 
Dict type in the constraints library. In fact, constraints has an even 
more general mechanism for all of this in Data.Constraint.Forall. Pro: 
no extra instances are necessary, so it is more easily extensible. Con: 
internally relies heavily on unsafeCoerce, although the above is already 
stretching the language a lot.

We start by defining a "class synonym" instead of a type synonym, to 
enable partial application.


class (c (XIB x thing), c (XNewImplicitBndrs x thing))
   => ImplicitBndrs c x thing
instance (c (XIB x thing), c (XNewImplicitBndrs x thing))
   => ImplicitBndrs c x thing


-- "forall thing. ImplicitBndrs c x thing"
type ForallImplicitBndrs c x = Forall (ImplicitBndrs c x)

withImplicitBndrs
   :: forall c x thing
   .  ForallImplicitBndrs c x
   => (ImplicitBndrs c x thing => t) -> t
withImplicitBndrs t = case inst @(ImplicitBndrs c x) @thing of
   Sub Dict -> t


I think the ICFP paper "Quantified class constraints" talks about a more 
principled future solution, and there is an old GHC ticket or two about it.

Cheers,
Li-yao


On 10/23/2017 11:06 AM, Alan & Kim Zimmerman wrote:
> I am working on the Trees that Grow stuff, and hit a small problem
> 
> I have
> 
> type family XIB               x thing
> type family XNewImplicitBndrs x thing
> 
> type ForallXImplicitBndrs (c :: * -> Constraint) (x :: *) (thing :: *) =
>         ( c (XIB               x thing)
>         , c (XNewImplicitBndrs x thing)
>         )
> 
> and I want to extend the DataId constraint
> 
> type DataId p =
>    ( Data p
> 
>    , ForallXImplicitBndrs Data p thing
>    )
> 
> But the problem is I do not have `thing` at this point, and to get it in
> the code will involve some hs-boot nastiness.
> 
> Is there any way to require "forall thing. Data thing" inside the DataId
> constraint?
> 
> Alan
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171023/77c963b5/attachment.html>
> 

From simonpj at microsoft.com  Mon Oct 23 21:04:36 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 23 Oct 2017 21:04:36 +0000
Subject: forall in constraint
In-Reply-To: <CANma=H951cD8aO5fs_OacaCxeFiX2ZkFbHMvksfYaO78fU4M+w@mail.gmail.com>
References: <CANma=H951cD8aO5fs_OacaCxeFiX2ZkFbHMvksfYaO78fU4M+w@mail.gmail.com>
Message-ID: <AM4PR83MB0033249C8E117C0F48CEBFDAAD460@AM4PR83MB0033.EURPRD83.prod.outlook.com>

I’m lost. Could you give me a bit more context?

I’m deeply suspicious about that ForallXImplicitBndrs thing with strange higher kinded parameters.   Smells all wrong to me.

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan & Kim Zimmerman
Sent: 23 October 2017 16:07
To: ghc-devs at haskell.org
Subject: forall in constraint

I am working on the Trees that Grow stuff, and hit a small problem
I have

type family XIB               x thing
type family XNewImplicitBndrs x thing

type ForallXImplicitBndrs (c :: * -> Constraint) (x :: *) (thing :: *) =
       ( c (XIB               x thing)
       , c (XNewImplicitBndrs x thing)
       )
and I want to extend the DataId constraint

type DataId p =
  ( Data p

  , ForallXImplicitBndrs Data p thing
  )
But the problem is I do not have `thing` at this point, and to get it in the code will involve some hs-boot nastiness.
Is there any way to require "forall thing. Data thing" inside the DataId constraint?
Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171023/7c71cf13/attachment.html>

From alan.zimm at gmail.com  Mon Oct 23 21:35:57 2017
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Mon, 23 Oct 2017 23:35:57 +0200
Subject: forall in constraint
In-Reply-To: <AM4PR83MB0033249C8E117C0F48CEBFDAAD460@AM4PR83MB0033.EURPRD83.prod.outlook.com>
References: <CANma=H951cD8aO5fs_OacaCxeFiX2ZkFbHMvksfYaO78fU4M+w@mail.gmail.com>
 <AM4PR83MB0033249C8E117C0F48CEBFDAAD460@AM4PR83MB0033.EURPRD83.prod.outlook.com>
Message-ID: <CANma=H-57nPC9=bU0NVWR8SmLOa==m3UATt65hiRN7U-f8fJvQ@mail.gmail.com>

In Shayan's implementation he has [1]

data ImplicitBndrs x thing
  = IB
      (XIB x thing)
      thing

  | NewImplicitBndrs
      (XNewImplicitBndrs x thing)

type family XIB               x thing
type family XNewImplicitBndrs x thing

type ForallXImplicitBndrs c x thing =
       ( c (XIB               x thing)
       , c (XNewImplicitBndrs x thing)
       )

This gets used, in the same file as

type LSigType   x = ImplicitBndrs x (LType x)

where `thing` is resolved to a specific type.

Because it is all in the same file, there is no problem making a
constraint on anything using LSigType, that mentions LHsType.



But in the approach I am taking[2], the type families are defined in
HsExtension, which is compiled early in the cycle, and imported by
HsTypes, HsBinds, HsDecl etc.

In order to derive a Data instance for anything using `LSigType x`, we
need to be able to specify that a Data instance exists for `LHsType x`.

So we can either do that directly in HsBinds, or try to add it to the
existing
DataId constraint in HsExtension.

The first approach leads to a spread of the constraint throughout the AST,
which gets very messy.

The second approach requires being able to specify a
`forall thing. Data thing` constraint in HsExtension.


I tried an intermediate approach, introducing a constraint in HsDecls[3] to
capture this,
but it eventually runs into needing it in the HsExpr.hs-boot file, which
means I need
LHsType in that file.

Perhaps the simplest way forward is to get rid of the `thing` parameter
completely,
and introduce the three or so ImplicitBinders variants that are used.

I hope this does not just confuse things even more.

Alan

[1]
https://github.com/ghc/ghc/blob/wip/GrowableAST/compiler/hsSyn/AST.hs#L475
[2] https://github.com/ghc/ghc/tree/wip/ttg/2017-10-21
[3]
https://github.com/ghc/ghc/commit/22812296818fe955752fa4762cf72250abd09bf9#diff-7cfa6eef12e44d312aca9ef4af0081b3R1439



On 23 October 2017 at 23:04, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> I’m lost. Could you give me a bit more context?
>
>
>
> I’m deeply suspicious about that ForallXImplicitBndrs thing with strange
> higher kinded parameters.   Smells all wrong to me.
>
>
>
> Simon
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171023/a9fd63fc/attachment-0001.html>

From simonpj at microsoft.com  Mon Oct 23 22:08:33 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 23 Oct 2017 22:08:33 +0000
Subject: forall in constraint
In-Reply-To: <CANma=H-57nPC9=bU0NVWR8SmLOa==m3UATt65hiRN7U-f8fJvQ@mail.gmail.com>
References: <CANma=H951cD8aO5fs_OacaCxeFiX2ZkFbHMvksfYaO78fU4M+w@mail.gmail.com>
 <AM4PR83MB0033249C8E117C0F48CEBFDAAD460@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <CANma=H-57nPC9=bU0NVWR8SmLOa==m3UATt65hiRN7U-f8fJvQ@mail.gmail.com>
Message-ID: <AM4PR83MB0033D4F462491B07217B304EAD460@AM4PR83MB0033.EURPRD83.prod.outlook.com>

  *   Like I say I am DEEPLY suspicious of ForallXImplicitBndrs.  I can’t make head or tail of it.  Is see in you patch you define



type ForallXPat (c :: * -> Constraint) (x :: *) =…

               What is this?  Why do we need it? What goes wrong if we remove it altogether?



  *   Likewise `forall thing. Data thing` makes no sense to me as a constraint,  even with quantified context. Shayan and I discussed this at ICFP and agreed it made no sense.  The hoped-for quantified-context extension is NOT a solution.

Overall I’ve lost track of these enormous constraint tuples that seem to be associated with Data instances. Can you give a small artificial (ie not full GHC) example of why they are necessary?   Perhaps it’s this

data T p = T1 (XT1 p) Int
                | T1 (XT2 p) (IdP p)

I suppose that a Data instance would need to have
               instance (Data (XT1 p), Data (XT2p), Data (IdP p)) => Data IT p) where…
Is that right?  In which case why do you have all this PostRn stuff in the DataId type?  (And why is it called DataId?)


  *   “The first approach leads to a spread of the constraint throughout the AST, which gets very messy.”  I don’t understand what the first approach is, or why it gets messy.  Could you be more concrete?
  *   “Perhaps the simplest way forward is to get rid of the `thing` parameter completely, and introduce the three or so ImplicitBinders variants that are used.”   I don’t’ think it could possibly make anything simpler to have three separate data types.   Can you illustrate concretely?
It’d be great to explore these issues with small, concrete examples, rather than the full glory of GHC, both for our own benefit and the benefit of those who will review the patch and (in future) understand the code.

Sorry to be slow

Simon


From: Alan & Kim Zimmerman [mailto:alan.zimm at gmail.com]
Sent: 23 October 2017 22:36
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: ghc-devs at haskell.org
Subject: Re: forall in constraint

In Shayan's implementation he has [1]

data ImplicitBndrs x thing
  = IB
      (XIB x thing)
      thing

  | NewImplicitBndrs
      (XNewImplicitBndrs x thing)

type family XIB               x thing
type family XNewImplicitBndrs x thing

type ForallXImplicitBndrs c x thing =
       ( c (XIB               x thing)
       , c (XNewImplicitBndrs x thing)
       )
This gets used, in the same file as

type LSigType   x = ImplicitBndrs x (LType x)
where `thing` is resolved to a specific type.

Because it is all in the same file, there is no problem making a
constraint on anything using LSigType, that mentions LHsType.



But in the approach I am taking[2], the type families are defined in
HsExtension, which is compiled early in the cycle, and imported by
HsTypes, HsBinds, HsDecl etc.

In order to derive a Data instance for anything using `LSigType x`, we
need to be able to specify that a Data instance exists for `LHsType x`.

So we can either do that directly in HsBinds, or try to add it to the existing
DataId constraint in HsExtension.

The first approach leads to a spread of the constraint throughout the AST,
which gets very messy.

The second approach requires being able to specify a
`forall thing. Data thing` constraint in HsExtension.


I tried an intermediate approach, introducing a constraint in HsDecls[3] to capture this,
but it eventually runs into needing it in the HsExpr.hs-boot file, which means I need
LHsType in that file.

Perhaps the simplest way forward is to get rid of the `thing` parameter completely,
and introduce the three or so ImplicitBinders variants that are used.

I hope this does not just confuse things even more.

Alan

[1] https://github.com/ghc/ghc/blob/wip/GrowableAST/compiler/hsSyn/AST.hs#L475<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc%2Fghc%2Fblob%2Fwip%2FGrowableAST%2Fcompiler%2FhsSyn%2FAST.hs%23L475&data=02%7C01%7Csimonpj%40microsoft.com%7Cd950b40099a34322c49a08d51a5e1892%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636443913792981424&sdata=ZGS3PmcI2nIw%2FRQLDs%2FKWk51LPR4Gmtv9rQHzY1Jre8%3D&reserved=0>
[2] https://github.com/ghc/ghc/tree/wip/ttg/2017-10-21<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc%2Fghc%2Ftree%2Fwip%2Fttg%2F2017-10-21&data=02%7C01%7Csimonpj%40microsoft.com%7Cd950b40099a34322c49a08d51a5e1892%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636443913792981424&sdata=WyNfWykERAEKvhfXdSacyvEukkLtEuwvHNgwrbPnkEw%3D&reserved=0>
[3] https://github.com/ghc/ghc/commit/22812296818fe955752fa4762cf72250abd09bf9#diff-7cfa6eef12e44d312aca9ef4af0081b3R1439<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc%2Fghc%2Fcommit%2F22812296818fe955752fa4762cf72250abd09bf9%23diff-7cfa6eef12e44d312aca9ef4af0081b3R1439&data=02%7C01%7Csimonpj%40microsoft.com%7Cd950b40099a34322c49a08d51a5e1892%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636443913792981424&sdata=S7kXIL7P5drGmbjcS%2Bd2kNhhHCoCTQStV%2FWqu8CK7i8%3D&reserved=0>



On 23 October 2017 at 23:04, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
I’m lost. Could you give me a bit more context?

I’m deeply suspicious about that ForallXImplicitBndrs thing with strange higher kinded parameters.   Smells all wrong to me.

Simon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171023/7c069d71/attachment-0001.html>

From mail at joachim-breitner.de  Tue Oct 24 00:02:49 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 23 Oct 2017 20:02:49 -0400
Subject: perf.haskell.org functional again
Message-ID: <2C073EBF-8019-4734-9617-BE9A577EEEA9@joachim-breitner.de>

Hi,

after a system upgrade to avoid weird linker errors, and after some fixes in the nofib submodule, http://perf.haskell.org/ghc is running again.

I am collecting instruction counts instead of runtime, because the latter was just too often varying too wildly. I hope this will yield less false alarms.

I am also running nofib with mode=fast. This way, building GHC, running the testsuite and nofib takes a bit over one hour. I hope this can keep up with y'all's commits (when it took 2h it couldn't).

Now nothing of the setup requires a quiet dedicated machine, so if there is a need, we could move these builds into the cloud or into some CI infrastructure - but no changes are immediately planned.

Enjoy, Joachim 

From moritz.angermann at gmail.com  Tue Oct 24 00:05:27 2017
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 24 Oct 2017 08:05:27 +0800
Subject: perf.haskell.org functional again
In-Reply-To: <2C073EBF-8019-4734-9617-BE9A577EEEA9@joachim-breitner.de>
References: <2C073EBF-8019-4734-9617-BE9A577EEEA9@joachim-breitner.de>
Message-ID: <548E3031-C8D0-4E6B-939F-FACB3711CC50@gmail.com>

Hooray! Thanks for doing this!

Sent from my iPhone

> On 24 Oct 2017, at 8:02 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> after a system upgrade to avoid weird linker errors, and after some fixes in the nofib submodule, http://perf.haskell.org/ghc is running again.
> 
> I am collecting instruction counts instead of runtime, because the latter was just too often varying too wildly. I hope this will yield less false alarms.
> 
> I am also running nofib with mode=fast. This way, building GHC, running the testsuite and nofib takes a bit over one hour. I hope this can keep up with y'all's commits (when it took 2h it couldn't).
> 
> Now nothing of the setup requires a quiet dedicated machine, so if there is a need, we could move these builds into the cloud or into some CI infrastructure - but no changes are immediately planned.
> 
> Enjoy, Joachim 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From chak at justtesting.org  Tue Oct 24 01:18:55 2017
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Tue, 24 Oct 2017 12:18:55 +1100
Subject: perf.haskell.org functional again
In-Reply-To: <2C073EBF-8019-4734-9617-BE9A577EEEA9@joachim-breitner.de>
References: <2C073EBF-8019-4734-9617-BE9A577EEEA9@joachim-breitner.de>
Message-ID: <C4A2809F-E388-4CD5-A908-D6CCD11F97DB@justtesting.org>

Hi Joachim,

Great! Just because you mention CI infrastructure and our effort around GHC CI at the moment, do you think, it would make sense to move this to CircleCI eventually?

Cheers,
Manuel

> Am 24.10.2017 um 11:02 schrieb Joachim Breitner <mail at joachim-breitner.de>:
> 
> Hi,
> 
> after a system upgrade to avoid weird linker errors, and after some fixes in the nofib submodule, http://perf.haskell.org/ghc is running again.
> 
> I am collecting instruction counts instead of runtime, because the latter was just too often varying too wildly. I hope this will yield less false alarms.
> 
> I am also running nofib with mode=fast. This way, building GHC, running the testsuite and nofib takes a bit over one hour. I hope this can keep up with y'all's commits (when it took 2h it couldn't).
> 
> Now nothing of the setup requires a quiet dedicated machine, so if there is a need, we could move these builds into the cloud or into some CI infrastructure - but no changes are immediately planned.
> 
> Enjoy, Joachim 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From chak at justtesting.org  Tue Oct 24 01:45:33 2017
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Tue, 24 Oct 2017 12:45:33 +1100
Subject: Relocatable dist
In-Reply-To: <9B67B24A-F81C-44EA-B9A7-B7CDA76EBA76@gmail.com>
References: <9B67B24A-F81C-44EA-B9A7-B7CDA76EBA76@gmail.com>
Message-ID: <713426E0-A01A-433B-81E9-8D96BB97EB5F@justtesting.org>

Hi Moritz,

Haskell for Mac is fully relocatable (as every Mac users expects this of a Mac app).

Unfortunately, it is not just the libdir in the wrapper scripts that’s in the way of a relocatable GHC. Additional problems are (1) the (at least, as of 8.0) still not macOS-friendly RPATHs in dynamic libraries and (2) the absolute paths in package .conf files.

In Haskell for Mac, I use two arguably hacky solutions to those two issues. I rewrite all RPATHs in .dylibs to be relative and I have got a little tool that relocates .conf files. I’d certainly prefer a cleaner solution!

Those aspects of Haskell for Mac are actually in a separate framework (GHC.framework) that wraps GHC and some other tools. This is all in a public repo if you like to have a look

  https://github.com/haskellformac/GHCframework <https://github.com/haskellformac/GHCframework>

I haven’t put a license on it, but I’d be happy to make it all BSD3. It is of course all highly Mac specific and requires Xcode to build for all the code signing, sandboxing, etc.

Cheers,
Manuel

> Am 23.10.2017 um 17:04 schrieb Moritz Angermann <moritz.angermann at gmail.com>:
> 
> Hi,
> 
> while trying to make the binary-distribution logic work for
> cross compilers.  I've come wonder, how hard it could be to
> make GHC relocatable. (e.g. just unpack the distribution, 
> and use the compiler from the `bin` folder within).
> 
> Right now this does not work due to the need for the path to
> package.conf, and this is hardcoded in the wrapper script to
> provide the proper libdir to ghc via -B[1]. Supposedly this
> is not an issue on Windows, as a relative path is common on
> windows and finding the location of the executable can be done
> safely. Or that's at least how I understand[1].
> 
> For macOS there is the haskell-platform, and ghc-dot-app[2]
> 
> From [3], it sounds like automake is a build, and not a packaging
> system, and the binary dist usecase with configure is not
> really a standard use case.
> 
> So why do I bring this up NOW? Apart from me trying to make
> cross compiler binary distributions working?  The reason is
> that we are also trying to move towards hadrian, and by "starting
> from scratch", maybe we have a chance to reconsider how we
> do things?
> 
> I must admit, I'm quite happy to use packages like llvm, by
> just downloading a package and adding the `bin` path to my
> $PATH.
> 
> There is however one thing that the current configure appraoch
> does, which I think is quite noteworthy (apart from setting
> $prefix).  That is, it does check for compilers and sets them
> accordingly, which might be desirable.
> 
> Cheers,
> Moritz
> 
> --
> [1]: https://ghc.haskell.org/trac/ghc/wiki/Building/Installing
> [2]: https://ghc.haskell.org/trac/ghc/wiki/Building/MacOSX/Installer
> [3]: https://lists.gnu.org/archive/html/automake/2006-10/msg00005.html
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171024/477bb5a6/attachment.html>

From moritz.angermann at gmail.com  Tue Oct 24 01:54:01 2017
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 24 Oct 2017 09:54:01 +0800
Subject: Relocatable dist
In-Reply-To: <713426E0-A01A-433B-81E9-8D96BB97EB5F@justtesting.org>
References: <9B67B24A-F81C-44EA-B9A7-B7CDA76EBA76@gmail.com>
 <713426E0-A01A-433B-81E9-8D96BB97EB5F@justtesting.org>
Message-ID: <7AC681B4-0B1F-40BF-8137-5537CE127BFE@gmail.com>

Hi Manuel,

thanks for the link!  Ahh yes lovely RPATH (this reminds me, I should look
to verify if I can make GHC link recursively.)  The conf files came up on
#ghc yesterday as well. Maybe we need some $home, $sysroot or similar marker
to make them relocatable.

I'll probably take a crack at this today.  Not sure how far I get though.
The primary motivation is that packaging the cross compilers in a neat
way looks like layering patched upon patches onto the configure script. And
in light of Hadrian, we might just want to package up a directory and not
deal with the binary-dist logic where we can?

Cheers,
 Moritz

> On Oct 24, 2017, at 9:45 AM, Manuel M T Chakravarty <chak at justtesting.org> wrote:
> 
> Hi Moritz,
> 
> Haskell for Mac is fully relocatable (as every Mac users expects this of a Mac app).
> 
> Unfortunately, it is not just the libdir in the wrapper scripts that’s in the way of a relocatable GHC. Additional problems are (1) the (at least, as of 8.0) still not macOS-friendly RPATHs in dynamic libraries and (2) the absolute paths in package .conf files.
> 
> In Haskell for Mac, I use two arguably hacky solutions to those two issues. I rewrite all RPATHs in .dylibs to be relative and I have got a little tool that relocates .conf files. I’d certainly prefer a cleaner solution!
> 
> Those aspects of Haskell for Mac are actually in a separate framework (GHC.framework) that wraps GHC and some other tools. This is all in a public repo if you like to have a look
> 
>   https://github.com/haskellformac/GHCframework
> 
> I haven’t put a license on it, but I’d be happy to make it all BSD3. It is of course all highly Mac specific and requires Xcode to build for all the code signing, sandboxing, etc.
> 
> Cheers,
> Manuel
> 
>> Am 23.10.2017 um 17:04 schrieb Moritz Angermann <moritz.angermann at gmail.com>:
>> 
>> Hi,
>> 
>> while trying to make the binary-distribution logic work for
>> cross compilers.  I've come wonder, how hard it could be to
>> make GHC relocatable. (e.g. just unpack the distribution, 
>> and use the compiler from the `bin` folder within).
>> 
>> Right now this does not work due to the need for the path to
>> package.conf, and this is hardcoded in the wrapper script to
>> provide the proper libdir to ghc via -B[1]. Supposedly this
>> is not an issue on Windows, as a relative path is common on
>> windows and finding the location of the executable can be done
>> safely. Or that's at least how I understand[1].
>> 
>> For macOS there is the haskell-platform, and ghc-dot-app[2]
>> 
>> From [3], it sounds like automake is a build, and not a packaging
>> system, and the binary dist usecase with configure is not
>> really a standard use case.
>> 
>> So why do I bring this up NOW? Apart from me trying to make
>> cross compiler binary distributions working?  The reason is
>> that we are also trying to move towards hadrian, and by "starting
>> from scratch", maybe we have a chance to reconsider how we
>> do things?
>> 
>> I must admit, I'm quite happy to use packages like llvm, by
>> just downloading a package and adding the `bin` path to my
>> $PATH.
>> 
>> There is however one thing that the current configure appraoch
>> does, which I think is quite noteworthy (apart from setting
>> $prefix).  That is, it does check for compilers and sets them
>> accordingly, which might be desirable.
>> 
>> Cheers,
>> Moritz
>> 
>> --
>> [1]: https://ghc.haskell.org/trac/ghc/wiki/Building/Installing
>> [2]: https://ghc.haskell.org/trac/ghc/wiki/Building/MacOSX/Installer
>> [3]: https://lists.gnu.org/archive/html/automake/2006-10/msg00005.html
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 


From mail at joachim-breitner.de  Tue Oct 24 03:46:13 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 23 Oct 2017 23:46:13 -0400
Subject: perf.haskell.org functional again
In-Reply-To: <C4A2809F-E388-4CD5-A908-D6CCD11F97DB@justtesting.org>
References: <2C073EBF-8019-4734-9617-BE9A577EEEA9@joachim-breitner.de>
 <C4A2809F-E388-4CD5-A908-D6CCD11F97DB@justtesting.org>
Message-ID: <1508816773.31327.5.camel@joachim-breitner.de>

Hi,

Is CircleCI the future now?

In general, yes. But it’s running fine for now, so I would not
prematurely throw it over.

My requirements are: 

 * needs to run on every commit (not just every push), including 
   branches.
 * needs to be able to push to a repository¹, so it needs access to 
   some secret token for depolyment.
   Alternatively, the CI could simply keep track of the build log
   and the perf.haskell.org dashboard scrapes it from there.
 * Occasionally, I find that I want to rebuild a fair number of commits
   that are already in the repository. So a good way to trigger
   rebuilds would be nice.

Greetings,
Joachim

¹ https://github.com/nomeata/ghc-speed-logs/commits/master

Am Dienstag, den 24.10.2017, 12:18 +1100 schrieb Manuel M T
Chakravarty:
> Hi Joachim,
> 
> Great! Just because you mention CI infrastructure and our effort around GHC CI at the moment, do you think, it would make sense to move this to CircleCI eventually?
> 
> Cheers,
> Manuel
> 
> > Am 24.10.2017 um 11:02 schrieb Joachim Breitner <mail at joachim-breitner.de>:
> > 
> > Hi,
> > 
> > after a system upgrade to avoid weird linker errors, and after some fixes in the nofib submodule, http://perf.haskell.org/ghc is running again.
> > 
> > I am collecting instruction counts instead of runtime, because the latter was just too often varying too wildly. I hope this will yield less false alarms.
> > 
> > I am also running nofib with mode=fast. This way, building GHC, running the testsuite and nofib takes a bit over one hour. I hope this can keep up with y'all's commits (when it took 2h it couldn't).
> > 
> > Now nothing of the setup requires a quiet dedicated machine, so if there is a need, we could move these builds into the cloud or into some CI infrastructure - but no changes are immediately planned.
> > 
> > Enjoy, Joachim 
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171023/5a3d2419/attachment-0001.sig>

From m at tweag.io  Tue Oct 24 07:57:21 2017
From: m at tweag.io (Boespflug, Mathieu)
Date: Tue, 24 Oct 2017 09:57:21 +0200
Subject: perf.haskell.org functional again
In-Reply-To: <1508816773.31327.5.camel@joachim-breitner.de>
References: <2C073EBF-8019-4734-9617-BE9A577EEEA9@joachim-breitner.de>
 <C4A2809F-E388-4CD5-A908-D6CCD11F97DB@justtesting.org>
 <1508816773.31327.5.camel@joachim-breitner.de>
Message-ID: <CAJ0eudqxqLgGW8PYf+Oi24C_e_K2XtD1N_ownDuqZeYut4_D0g@mail.gmail.com>

Hi Joachim,

what kind of machine is this running on at the moment? A dedicated
instance or some colocated VM in the cloud? I ask because for perf
results something CircleCI might *not* be suitable here because
execution time on CircleCI varies quite substantially depending on
load from other users of the same physical machine. This is not a
problem for most types of jobs, but perf measurement is one of the few
for which it is, depending on which metrics are tracked.

Of course, we could always have TravisCI/CircleCI drive a dedicated
machine, but it's not clear to me that these services would be the
best fit for this particular use case.

Best,
--
Mathieu Boespflug
Founder at http://tweag.io.


On 24 October 2017 at 05:46, Joachim Breitner <mail at joachim-breitner.de> wrote:
> Hi,
>
> Is CircleCI the future now?
>
> In general, yes. But it’s running fine for now, so I would not
> prematurely throw it over.
>
> My requirements are:
>
>  * needs to run on every commit (not just every push), including
>    branches.
>  * needs to be able to push to a repository¹, so it needs access to
>    some secret token for depolyment.
>    Alternatively, the CI could simply keep track of the build log
>    and the perf.haskell.org dashboard scrapes it from there.
>  * Occasionally, I find that I want to rebuild a fair number of commits
>    that are already in the repository. So a good way to trigger
>    rebuilds would be nice.
>
> Greetings,
> Joachim
>
> ¹ https://github.com/nomeata/ghc-speed-logs/commits/master
>
> Am Dienstag, den 24.10.2017, 12:18 +1100 schrieb Manuel M T
> Chakravarty:
>> Hi Joachim,
>>
>> Great! Just because you mention CI infrastructure and our effort around GHC CI at the moment, do you think, it would make sense to move this to CircleCI eventually?
>>
>> Cheers,
>> Manuel
>>
>> > Am 24.10.2017 um 11:02 schrieb Joachim Breitner <mail at joachim-breitner.de>:
>> >
>> > Hi,
>> >
>> > after a system upgrade to avoid weird linker errors, and after some fixes in the nofib submodule, http://perf.haskell.org/ghc is running again.
>> >
>> > I am collecting instruction counts instead of runtime, because the latter was just too often varying too wildly. I hope this will yield less false alarms.
>> >
>> > I am also running nofib with mode=fast. This way, building GHC, running the testsuite and nofib takes a bit over one hour. I hope this can keep up with y'all's commits (when it took 2h it couldn't).
>> >
>> > Now nothing of the setup requires a quiet dedicated machine, so if there is a need, we could move these builds into the cloud or into some CI infrastructure - but no changes are immediately planned.
>> >
>> > Enjoy, Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From moritz.angermann at gmail.com  Tue Oct 24 09:02:11 2017
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 24 Oct 2017 17:02:11 +0800
Subject: Relocatable dist
In-Reply-To: <7AC681B4-0B1F-40BF-8137-5537CE127BFE@gmail.com>
References: <9B67B24A-F81C-44EA-B9A7-B7CDA76EBA76@gmail.com>
 <713426E0-A01A-433B-81E9-8D96BB97EB5F@justtesting.org>
 <7AC681B4-0B1F-40BF-8137-5537CE127BFE@gmail.com>
Message-ID: <01C6EAF5-F683-47D2-B62D-EFFB2EB9137A@gmail.com>

Hi *,

so I've given this a stab[1].  While getting the wrapper requirement,
and the .conf files sorted was rather easy. (We already have getExecutablePath,
and the relocatable logic for windows.  As well as $topdir and ${pkgroot} 
support for paths in .conf files.)

Now as Manuel laid out the dynamic libraries situation is a bit annoying.
Specifically as the ghc-stage2 we build *in-tree*, and the libraries have
a completely different layout from the final install location.  And as such
setting @rpath, and @loader_path, is quite tricky, as essentially the
installation is not a relocation of the stage1 or stage2 compiler.

However, I am now again at the point where I start hacking on the build
system, while Hadrian is imminent.  And this is quite depressing.

Cheers,
 Moritz

--
[1]: https://phabricator.haskell.org/D4121
> On Oct 24, 2017, at 9:54 AM, Moritz Angermann <moritz.angermann at gmail.com> wrote:
> 
> Hi Manuel,
> 
> thanks for the link!  Ahh yes lovely RPATH (this reminds me, I should look
> to verify if I can make GHC link recursively.)  The conf files came up on
> #ghc yesterday as well. Maybe we need some $home, $sysroot or similar marker
> to make them relocatable.
> 
> I'll probably take a crack at this today.  Not sure how far I get though.
> The primary motivation is that packaging the cross compilers in a neat
> way looks like layering patched upon patches onto the configure script. And
> in light of Hadrian, we might just want to package up a directory and not
> deal with the binary-dist logic where we can?
> 
> Cheers,
> Moritz
> 
>> On Oct 24, 2017, at 9:45 AM, Manuel M T Chakravarty <chak at justtesting.org> wrote:
>> 
>> Hi Moritz,
>> 
>> Haskell for Mac is fully relocatable (as every Mac users expects this of a Mac app).
>> 
>> Unfortunately, it is not just the libdir in the wrapper scripts that’s in the way of a relocatable GHC. Additional problems are (1) the (at least, as of 8.0) still not macOS-friendly RPATHs in dynamic libraries and (2) the absolute paths in package .conf files.
>> 
>> In Haskell for Mac, I use two arguably hacky solutions to those two issues. I rewrite all RPATHs in .dylibs to be relative and I have got a little tool that relocates .conf files. I’d certainly prefer a cleaner solution!
>> 
>> Those aspects of Haskell for Mac are actually in a separate framework (GHC.framework) that wraps GHC and some other tools. This is all in a public repo if you like to have a look
>> 
>>  https://github.com/haskellformac/GHCframework
>> 
>> I haven’t put a license on it, but I’d be happy to make it all BSD3. It is of course all highly Mac specific and requires Xcode to build for all the code signing, sandboxing, etc.
>> 
>> Cheers,
>> Manuel
>> 
>>> Am 23.10.2017 um 17:04 schrieb Moritz Angermann <moritz.angermann at gmail.com>:
>>> 
>>> Hi,
>>> 
>>> while trying to make the binary-distribution logic work for
>>> cross compilers.  I've come wonder, how hard it could be to
>>> make GHC relocatable. (e.g. just unpack the distribution, 
>>> and use the compiler from the `bin` folder within).
>>> 
>>> Right now this does not work due to the need for the path to
>>> package.conf, and this is hardcoded in the wrapper script to
>>> provide the proper libdir to ghc via -B[1]. Supposedly this
>>> is not an issue on Windows, as a relative path is common on
>>> windows and finding the location of the executable can be done
>>> safely. Or that's at least how I understand[1].
>>> 
>>> For macOS there is the haskell-platform, and ghc-dot-app[2]
>>> 
>>> From [3], it sounds like automake is a build, and not a packaging
>>> system, and the binary dist usecase with configure is not
>>> really a standard use case.
>>> 
>>> So why do I bring this up NOW? Apart from me trying to make
>>> cross compiler binary distributions working?  The reason is
>>> that we are also trying to move towards hadrian, and by "starting
>>> from scratch", maybe we have a chance to reconsider how we
>>> do things?
>>> 
>>> I must admit, I'm quite happy to use packages like llvm, by
>>> just downloading a package and adding the `bin` path to my
>>> $PATH.
>>> 
>>> There is however one thing that the current configure appraoch
>>> does, which I think is quite noteworthy (apart from setting
>>> $prefix).  That is, it does check for compilers and sets them
>>> accordingly, which might be desirable.
>>> 
>>> Cheers,
>>> Moritz
>>> 
>>> --
>>> [1]: https://ghc.haskell.org/trac/ghc/wiki/Building/Installing
>>> [2]: https://ghc.haskell.org/trac/ghc/wiki/Building/MacOSX/Installer
>>> [3]: https://lists.gnu.org/archive/html/automake/2006-10/msg00005.html
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From mail at joachim-breitner.de  Tue Oct 24 13:35:28 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 24 Oct 2017 09:35:28 -0400
Subject: perf.haskell.org functional again
In-Reply-To: <CAJ0eudqxqLgGW8PYf+Oi24C_e_K2XtD1N_ownDuqZeYut4_D0g@mail.gmail.com>
References: <2C073EBF-8019-4734-9617-BE9A577EEEA9@joachim-breitner.de>
 <C4A2809F-E388-4CD5-A908-D6CCD11F97DB@justtesting.org>
 <1508816773.31327.5.camel@joachim-breitner.de>
 <CAJ0eudqxqLgGW8PYf+Oi24C_e_K2XtD1N_ownDuqZeYut4_D0g@mail.gmail.com>
Message-ID: <1508852128.7658.1.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 24.10.2017, 09:57 +0200 schrieb Boespflug, Mathieu:
> what kind of machine is this running on at the moment? A dedicated
> instance or some colocated VM in the cloud?

A physical box sponsored by Bryn Mawr.
8GB RAM, 8 Core Intel(R) Core(TM) i7 CPU 930  @ 2.80GHz


> I ask because for perf
> results something CircleCI might *not* be suitable here because
> execution time on CircleCI varies quite substantially depending on
> load from other users of the same physical machine. This is not a
> problem for most types of jobs, but perf measurement is one of the few
> for which it is, depending on which metrics are tracked.

But that’s what I am saying: By measuring dynamic instructions (using
cachegrind), the execution time is no longer relevant.

Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171024/33d705e2/attachment.sig>

From m at tweag.io  Tue Oct 24 14:59:39 2017
From: m at tweag.io (Boespflug, Mathieu)
Date: Tue, 24 Oct 2017 16:59:39 +0200
Subject: perf.haskell.org functional again
In-Reply-To: <1508852128.7658.1.camel@joachim-breitner.de>
References: <2C073EBF-8019-4734-9617-BE9A577EEEA9@joachim-breitner.de>
 <C4A2809F-E388-4CD5-A908-D6CCD11F97DB@justtesting.org>
 <1508816773.31327.5.camel@joachim-breitner.de>
 <CAJ0eudqxqLgGW8PYf+Oi24C_e_K2XtD1N_ownDuqZeYut4_D0g@mail.gmail.com>
 <1508852128.7658.1.camel@joachim-breitner.de>
Message-ID: <CAJ0eudrSjE7XZESEH3pJLxLJYgZZGd2Jd7wwHA1LFHw-vzYE3A@mail.gmail.com>

Hi Joachim,

> But that’s what I am saying: By measuring dynamic instructions (using
> cachegrind), the execution time is no longer relevant.

I'm skeptical that this metric is a reliable enough proxy for actual
runtime of user programs to make tracking it and only it sufficient.
For the reasons Sven Panne gave in a previous email. But I'll be very
interested to hear your experience report over time.

From mail at joachim-breitner.de  Tue Oct 24 15:14:44 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 24 Oct 2017 11:14:44 -0400
Subject: perf.haskell.org functional again
In-Reply-To: <CAJ0eudrSjE7XZESEH3pJLxLJYgZZGd2Jd7wwHA1LFHw-vzYE3A@mail.gmail.com>
References: <2C073EBF-8019-4734-9617-BE9A577EEEA9@joachim-breitner.de>
 <C4A2809F-E388-4CD5-A908-D6CCD11F97DB@justtesting.org>
 <1508816773.31327.5.camel@joachim-breitner.de>
 <CAJ0eudqxqLgGW8PYf+Oi24C_e_K2XtD1N_ownDuqZeYut4_D0g@mail.gmail.com>
 <1508852128.7658.1.camel@joachim-breitner.de>
 <CAJ0eudrSjE7XZESEH3pJLxLJYgZZGd2Jd7wwHA1LFHw-vzYE3A@mail.gmail.com>
Message-ID: <1508858084.7658.7.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 24.10.2017, 16:59 +0200 schrieb Boespflug, Mathieu:
> Hi Joachim,
> 
> > But that’s what I am saying: By measuring dynamic instructions (using
> > cachegrind), the execution time is no longer relevant.
> 
> I'm skeptical that this metric is a reliable enough proxy for actual
> runtime of user programs to make tracking it and only it sufficient.
> For the reasons Sven Panne gave in a previous email. But I'll be very
> interested to hear your experience report over time.

Sure, it’s a crutch. But we have been working for decades with
“allocations go down, so this must be a win”, which is even more
distant from runtime.

If someone builds me a system where the runtime measurements are
actually reliable (and not drowned in the noise of modern CPU
architectures with sensitivity to layout and alignment), maybe using a
tool like this http://plasma.cs.umass.edu/emery/stabilizer.html
then I’ll happily ditch instruction counts and use that!

But at the current state, working with nofib results is just too
frustrating: You see a change, but you don't know, is it a measurement
error? Did you push something over a performance cliff? Is it really
related to your change to Core? I find it just not viable.

Joachim


-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171024/5d17067d/attachment.sig>

From mail at joachim-breitner.de  Tue Oct 24 15:40:29 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 24 Oct 2017 11:40:29 -0400
Subject: Simplify.hs depends on typechecker
Message-ID: <1508859629.7658.15.camel@joachim-breitner.de>

Hi,

while rebuilding Simplify.o only I noticed that all of the type
checker, and HsSyn stuff, and renamer stuff, and so needed to be
rebuilt, which I found strange.

After a little investigation, it seems that the simplifier depends on
CoreMonad, and that pulls some very few type-checker related things:

1.
    import TcRnMonad        ( initTcForLookup )
    import {-# SOURCE #-} TcSplice ( lookupThName_maybe )

for 

    thNameToGhcName :: TH.Name -> CoreM (Maybe Name)
    thNameToGhcName th_name = do
        hsc_env <- getHscEnv
        liftIO $ initTcForLookup hsc_env (lookupThName_maybe th_name)

which is not even used in GHC, but only in GHC Plugins, so this could
probably be moved to a separate module pulled in by GhcPlugins.hs

2.

    import TcEnv            ( lookupGlobal )

for

    instance MonadThings CoreM where
        lookupThing name = do { hsc_env <- getHscEnv
                              ; liftIO $ lookupGlobal hsc_env name }

This might be a bit harder to disentangle. But if successful, it would
probably make building GHC in parallel quite a bit faster. And it just
seems strange to me that the Core-to-Core code should depend on the
type checker…


I’m sending this out there in case someone has dug in that direction
before and has insights to share.


Greetings,
Joachim

(Attached is a transitively reduced dependency graph of Simplify.hs,
created using Iavor’s https://github.com/yav/graphmod/wiki).


-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de
  https://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.pdf
Type: application/pdf
Size: 50924 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171024/c8ad5596/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171024/c8ad5596/attachment-0001.sig>

From allbery.b at gmail.com  Tue Oct 24 18:45:16 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 24 Oct 2017 14:45:16 -0400
Subject: Relocatable dist
In-Reply-To: <01C6EAF5-F683-47D2-B62D-EFFB2EB9137A@gmail.com>
References: <9B67B24A-F81C-44EA-B9A7-B7CDA76EBA76@gmail.com>
 <713426E0-A01A-433B-81E9-8D96BB97EB5F@justtesting.org>
 <7AC681B4-0B1F-40BF-8137-5537CE127BFE@gmail.com>
 <01C6EAF5-F683-47D2-B62D-EFFB2EB9137A@gmail.com>
Message-ID: <CAKFCL4UYbBJxgXLhj3ySsogVEjz3A__oCH7uptb+Ci24cGVOsA@mail.gmail.com>

On Tue, Oct 24, 2017 at 5:02 AM, Moritz Angermann <
moritz.angermann at gmail.com> wrote:

> However, I am now again at the point where I start hacking on the build
> system, while Hadrian is imminent.  And this is quite depressing
>

Realistically, while Hadrian going into the tree may be imminent, as I
understand it Hadrian becoming the primary build system --- or even a
viable alternative build system --- is not. It's more of a repo logistics
speed bump. Just let it go for now.

-- 
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://mail.haskell.org/pipermail/ghc-devs/attachments/20171024/15ed6bff/attachment.html>

From mail at nh2.me  Tue Oct 24 22:01:42 2017
From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=)
Date: Wed, 25 Oct 2017 00:01:42 +0200
Subject: Bringing back #ghc IRC logging
In-Reply-To: <87d195u10j.fsf@ben-laptop.smart-cactus.org>
References: <d56a2d98-d75c-066e-c877-a2d50487bf56@nh2.me>
 <87d195u10j.fsf@ben-laptop.smart-cactus.org>
Message-ID: <5b8c4f5c-3dfd-6f48-e2d6-8bc27eda7cfd@nh2.me>

Hey Ben,

I haven't heard of a single concern of enabling botbot.me over the last
3 months.

Can we go ahead and enable it?

All we need is a channel op to fill out https://botbot.me/request/.

On 12/07/17 17:29, Ben Gamari wrote:
> I am very much in favor of doing something about this. Unfortunately,
> Chris Done stepped back from ircbrowse.net around the time that #ghc
> started using it for logging. Moving to a third-party service like
> botbot.me sounds quite reasonable to m.e

From chak at justtesting.org  Wed Oct 25 00:00:43 2017
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Wed, 25 Oct 2017 11:00:43 +1100
Subject: Relocatable dist
In-Reply-To: <01C6EAF5-F683-47D2-B62D-EFFB2EB9137A@gmail.com>
References: <9B67B24A-F81C-44EA-B9A7-B7CDA76EBA76@gmail.com>
 <713426E0-A01A-433B-81E9-8D96BB97EB5F@justtesting.org>
 <7AC681B4-0B1F-40BF-8137-5537CE127BFE@gmail.com>
 <01C6EAF5-F683-47D2-B62D-EFFB2EB9137A@gmail.com>
Message-ID: <D182EC62-ACE2-4CB7-B425-863D1FE5B2DB@justtesting.org>

> Am 24.10.2017 um 20:02 schrieb Moritz Angermann <moritz.angermann at gmail.com>:
> 
> Hi *,
> 
> so I've given this a stab[1].  While getting the wrapper requirement,
> and the .conf files sorted was rather easy. (We already have getExecutablePath,
> and the relocatable logic for windows.  As well as $topdir and ${pkgroot} 
> support for paths in .conf files.)

Awesome!

> Now as Manuel laid out the dynamic libraries situation is a bit annoying.
> Specifically as the ghc-stage2 we build *in-tree*, and the libraries have
> a completely different layout from the final install location.  And as such
> setting @rpath, and @loader_path, is quite tricky, as essentially the
> installation is not a relocation of the stage1 or stage2 compiler.

Yes, that’s why I took the hacky short-cut of running the normal install procedure and then patching the libs up in place with ’install_name_tool’. (BTW, a not too widely known tool that makes messing with dylibs, RPATHs, and signatures way nicer than otool is <http://newosxbook.com/tools/jtool.html <http://newosxbook.com/tools/jtool.html>> — the output is so much more readable.)

> However, I am now again at the point where I start hacking on the build
> system, while Hadrian is imminent.  And this is quite depressing.

I hear you.

Cheers,
Manuel

> Cheers,
> Moritz
> 
> --
> [1]: https://phabricator.haskell.org/D4121
>> On Oct 24, 2017, at 9:54 AM, Moritz Angermann <moritz.angermann at gmail.com> wrote:
>> 
>> Hi Manuel,
>> 
>> thanks for the link!  Ahh yes lovely RPATH (this reminds me, I should look
>> to verify if I can make GHC link recursively.)  The conf files came up on
>> #ghc yesterday as well. Maybe we need some $home, $sysroot or similar marker
>> to make them relocatable.
>> 
>> I'll probably take a crack at this today.  Not sure how far I get though.
>> The primary motivation is that packaging the cross compilers in a neat
>> way looks like layering patched upon patches onto the configure script. And
>> in light of Hadrian, we might just want to package up a directory and not
>> deal with the binary-dist logic where we can?
>> 
>> Cheers,
>> Moritz
>> 
>>> On Oct 24, 2017, at 9:45 AM, Manuel M T Chakravarty <chak at justtesting.org> wrote:
>>> 
>>> Hi Moritz,
>>> 
>>> Haskell for Mac is fully relocatable (as every Mac users expects this of a Mac app).
>>> 
>>> Unfortunately, it is not just the libdir in the wrapper scripts that’s in the way of a relocatable GHC. Additional problems are (1) the (at least, as of 8.0) still not macOS-friendly RPATHs in dynamic libraries and (2) the absolute paths in package .conf files.
>>> 
>>> In Haskell for Mac, I use two arguably hacky solutions to those two issues. I rewrite all RPATHs in .dylibs to be relative and I have got a little tool that relocates .conf files. I’d certainly prefer a cleaner solution!
>>> 
>>> Those aspects of Haskell for Mac are actually in a separate framework (GHC.framework) that wraps GHC and some other tools. This is all in a public repo if you like to have a look
>>> 
>>> https://github.com/haskellformac/GHCframework
>>> 
>>> I haven’t put a license on it, but I’d be happy to make it all BSD3. It is of course all highly Mac specific and requires Xcode to build for all the code signing, sandboxing, etc.
>>> 
>>> Cheers,
>>> Manuel
>>> 
>>>> Am 23.10.2017 um 17:04 schrieb Moritz Angermann <moritz.angermann at gmail.com>:
>>>> 
>>>> Hi,
>>>> 
>>>> while trying to make the binary-distribution logic work for
>>>> cross compilers.  I've come wonder, how hard it could be to
>>>> make GHC relocatable. (e.g. just unpack the distribution, 
>>>> and use the compiler from the `bin` folder within).
>>>> 
>>>> Right now this does not work due to the need for the path to
>>>> package.conf, and this is hardcoded in the wrapper script to
>>>> provide the proper libdir to ghc via -B[1]. Supposedly this
>>>> is not an issue on Windows, as a relative path is common on
>>>> windows and finding the location of the executable can be done
>>>> safely. Or that's at least how I understand[1].
>>>> 
>>>> For macOS there is the haskell-platform, and ghc-dot-app[2]
>>>> 
>>>> From [3], it sounds like automake is a build, and not a packaging
>>>> system, and the binary dist usecase with configure is not
>>>> really a standard use case.
>>>> 
>>>> So why do I bring this up NOW? Apart from me trying to make
>>>> cross compiler binary distributions working?  The reason is
>>>> that we are also trying to move towards hadrian, and by "starting
>>>> from scratch", maybe we have a chance to reconsider how we
>>>> do things?
>>>> 
>>>> I must admit, I'm quite happy to use packages like llvm, by
>>>> just downloading a package and adding the `bin` path to my
>>>> $PATH.
>>>> 
>>>> There is however one thing that the current configure appraoch
>>>> does, which I think is quite noteworthy (apart from setting
>>>> $prefix).  That is, it does check for compilers and sets them
>>>> accordingly, which might be desirable.
>>>> 
>>>> Cheers,
>>>> Moritz
>>>> 
>>>> --
>>>> [1]: https://ghc.haskell.org/trac/ghc/wiki/Building/Installing
>>>> [2]: https://ghc.haskell.org/trac/ghc/wiki/Building/MacOSX/Installer
>>>> [3]: https://lists.gnu.org/archive/html/automake/2006-10/msg00005.html
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> 
>> 
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171025/72cc14f1/attachment.html>

From chak at justtesting.org  Wed Oct 25 00:02:36 2017
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Wed, 25 Oct 2017 11:02:36 +1100
Subject: Relocatable dist
In-Reply-To: <CAKFCL4UYbBJxgXLhj3ySsogVEjz3A__oCH7uptb+Ci24cGVOsA@mail.gmail.com>
References: <9B67B24A-F81C-44EA-B9A7-B7CDA76EBA76@gmail.com>
 <713426E0-A01A-433B-81E9-8D96BB97EB5F@justtesting.org>
 <7AC681B4-0B1F-40BF-8137-5537CE127BFE@gmail.com>
 <01C6EAF5-F683-47D2-B62D-EFFB2EB9137A@gmail.com>
 <CAKFCL4UYbBJxgXLhj3ySsogVEjz3A__oCH7uptb+Ci24cGVOsA@mail.gmail.com>
Message-ID: <9563EEDA-5A86-45D6-B427-D043756D0171@justtesting.org>

Why are you saying that? 

I think, Moritz is right. Hadrian is supposed to be the build system for 8.4. Adding new functionality for cross-compilation to the old build system is frustrating.

Manuel

> Brandon Allbery <allbery.b at gmail.com>:
> 
> On Tue, Oct 24, 2017 at 5:02 AM, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
> However, I am now again at the point where I start hacking on the build
> system, while Hadrian is imminent.  And this is quite depressing
> 
> Realistically, while Hadrian going into the tree may be imminent, as I understand it Hadrian becoming the primary build system --- or even a viable alternative build system --- is not. It's more of a repo logistics speed bump. Just let it go for now.
> 
> -- 
> 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 <http://sinenomine.net/>_______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171025/ffd81985/attachment-0001.html>

From allbery.b at gmail.com  Wed Oct 25 00:06:26 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 24 Oct 2017 20:06:26 -0400
Subject: Relocatable dist
In-Reply-To: <9563EEDA-5A86-45D6-B427-D043756D0171@justtesting.org>
References: <9B67B24A-F81C-44EA-B9A7-B7CDA76EBA76@gmail.com>
 <713426E0-A01A-433B-81E9-8D96BB97EB5F@justtesting.org>
 <7AC681B4-0B1F-40BF-8137-5537CE127BFE@gmail.com>
 <01C6EAF5-F683-47D2-B62D-EFFB2EB9137A@gmail.com>
 <CAKFCL4UYbBJxgXLhj3ySsogVEjz3A__oCH7uptb+Ci24cGVOsA@mail.gmail.com>
 <9563EEDA-5A86-45D6-B427-D043756D0171@justtesting.org>
Message-ID: <CAKFCL4XSDNfANprp1E9owqxOjz+XSL7XtaoTGEpwSgV_AUUVBA@mail.gmail.com>

Discussion I've been seeing is Hadrian will not be ready for production use
for 8.4. Pulling it in tree is scheduled for 8.4 mostly to make it easier
to keep up to date with other changes and to make it easier to work on and
test the various missing pieces: as I understand it, Hadrian can't yet deal
with all of the various platform special cases, etc. that an actual release
requires.

On Tue, Oct 24, 2017 at 8:02 PM, Manuel M T Chakravarty <
chak at justtesting.org> wrote:

> Why are you saying that?
>
> I think, Moritz is right. Hadrian is supposed to be the build system for
> 8.4. Adding new functionality for cross-compilation to the old build system
> is frustrating.
>
> Manuel
>
> Brandon Allbery <allbery.b at gmail.com>:
>
> On Tue, Oct 24, 2017 at 5:02 AM, Moritz Angermann <
> moritz.angermann at gmail.com> wrote:
>
>> However, I am now again at the point where I start hacking on the build
>> system, while Hadrian is imminent.  And this is quite depressing
>>
>
> Realistically, while Hadrian going into the tree may be imminent, as I
> understand it Hadrian becoming the primary build system --- or even a
> viable alternative build system --- is not. It's more of a repo logistics
> speed bump. Just let it go for now.
>
> --
> 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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>


-- 
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://mail.haskell.org/pipermail/ghc-devs/attachments/20171024/1a329844/attachment.html>

From chak at justtesting.org  Wed Oct 25 00:12:20 2017
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Wed, 25 Oct 2017 11:12:20 +1100
Subject: Relocatable dist
In-Reply-To: <CAKFCL4XSDNfANprp1E9owqxOjz+XSL7XtaoTGEpwSgV_AUUVBA@mail.gmail.com>
References: <9B67B24A-F81C-44EA-B9A7-B7CDA76EBA76@gmail.com>
 <713426E0-A01A-433B-81E9-8D96BB97EB5F@justtesting.org>
 <7AC681B4-0B1F-40BF-8137-5537CE127BFE@gmail.com>
 <01C6EAF5-F683-47D2-B62D-EFFB2EB9137A@gmail.com>
 <CAKFCL4UYbBJxgXLhj3ySsogVEjz3A__oCH7uptb+Ci24cGVOsA@mail.gmail.com>
 <9563EEDA-5A86-45D6-B427-D043756D0171@justtesting.org>
 <CAKFCL4XSDNfANprp1E9owqxOjz+XSL7XtaoTGEpwSgV_AUUVBA@mail.gmail.com>
Message-ID: <4DE2C615-F058-4A29-8512-66B57F3FB6B7@justtesting.org>

That doesn’t mean it can’t be used for cross-compilation once it is in the tree.

> Am 25.10.2017 um 11:06 schrieb Brandon Allbery <allbery.b at gmail.com>:
> 
> Discussion I've been seeing is Hadrian will not be ready for production use for 8.4. Pulling it in tree is scheduled for 8.4 mostly to make it easier to keep up to date with other changes and to make it easier to work on and test the various missing pieces: as I understand it, Hadrian can't yet deal with all of the various platform special cases, etc. that an actual release requires. 
> 
> On Tue, Oct 24, 2017 at 8:02 PM, Manuel M T Chakravarty <chak at justtesting.org <mailto:chak at justtesting.org>> wrote:
> Why are you saying that? 
> 
> I think, Moritz is right. Hadrian is supposed to be the build system for 8.4. Adding new functionality for cross-compilation to the old build system is frustrating.
> 
> Manuel
> 
>> Brandon Allbery <allbery.b at gmail.com <mailto:allbery.b at gmail.com>>:
>> 
>> On Tue, Oct 24, 2017 at 5:02 AM, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>> However, I am now again at the point where I start hacking on the build
>> system, while Hadrian is imminent.  And this is quite depressing
>> 
>> Realistically, while Hadrian going into the tree may be imminent, as I understand it Hadrian becoming the primary build system --- or even a viable alternative build system --- is not. It's more of a repo logistics speed bump. Just let it go for now.
>> 
>> -- 
>> 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 <http://sinenomine.net/>_______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
> 
> 
> 
> 
> -- 
> 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 <http://sinenomine.net/>_______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171025/dea7733b/attachment.html>

From chak at justtesting.org  Wed Oct 25 00:13:40 2017
From: chak at justtesting.org (Manuel M T Chakravarty)
Date: Wed, 25 Oct 2017 11:13:40 +1100
Subject: perf.haskell.org functional again
In-Reply-To: <1508816773.31327.5.camel@joachim-breitner.de>
References: <2C073EBF-8019-4734-9617-BE9A577EEEA9@joachim-breitner.de>
 <C4A2809F-E388-4CD5-A908-D6CCD11F97DB@justtesting.org>
 <1508816773.31327.5.camel@joachim-breitner.de>
Message-ID: <C206E644-6731-423B-8928-7B086ECF3C17@justtesting.org>

> Am 24.10.2017 um 14:46 schrieb Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>:
> 
> Is CircleCI the future now?

Yes, as per

  https://ghc.haskell.org/trac/ghc/wiki/ContinuousIntegration <https://ghc.haskell.org/trac/ghc/wiki/ContinuousIntegration>

> In general, yes. But it’s running fine for now, so I would not
> prematurely throw it over.
> 
> My requirements are: 
> 
> * needs to run on every commit (not just every push), including 
>   branches.
> * needs to be able to push to a repository¹, so it needs access to 
>   some secret token for depolyment.
>   Alternatively, the CI could simply keep track of the build log
>   and the perf.haskell.org <http://perf.haskell.org/> dashboard scrapes it from there.
> * Occasionally, I find that I want to rebuild a fair number of commits
>   that are already in the repository. So a good way to trigger
>   rebuilds would be nice.

No need to mess with a working system, but as long as performance counters are the basis, I think, these constraints can all be met. In particular, CircleCI has facilities to allow deployments including managing of secrets. (That is a pretty common requirements for CIs.)

Cheers,
Manuel

> 
> Greetings,
> Joachim
> 
> ¹ https://github.com/nomeata/ghc-speed-logs/commits/master <https://github.com/nomeata/ghc-speed-logs/commits/master>
> 
> Am Dienstag, den 24.10.2017, 12:18 +1100 schrieb Manuel M T
> Chakravarty:
>> Hi Joachim,
>> 
>> Great! Just because you mention CI infrastructure and our effort around GHC CI at the moment, do you think, it would make sense to move this to CircleCI eventually?
>> 
>> Cheers,
>> Manuel
>> 
>>> Am 24.10.2017 um 11:02 schrieb Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>:
>>> 
>>> Hi,
>>> 
>>> after a system upgrade to avoid weird linker errors, and after some fixes in the nofib submodule, http://perf.haskell.org/ghc <http://perf.haskell.org/ghc> is running again.
>>> 
>>> I am collecting instruction counts instead of runtime, because the latter was just too often varying too wildly. I hope this will yield less false alarms.
>>> 
>>> I am also running nofib with mode=fast. This way, building GHC, running the testsuite and nofib takes a bit over one hour. I hope this can keep up with y'all's commits (when it took 2h it couldn't).
>>> 
>>> Now nothing of the setup requires a quiet dedicated machine, so if there is a need, we could move these builds into the cloud or into some CI infrastructure - but no changes are immediately planned.
>>> 
>>> Enjoy, Joachim 
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>  http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171025/28325e1e/attachment-0001.html>

From moritz.angermann at gmail.com  Wed Oct 25 01:43:34 2017
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Wed, 25 Oct 2017 09:43:34 +0800
Subject: Relocatable dist
In-Reply-To: <4DE2C615-F058-4A29-8512-66B57F3FB6B7@justtesting.org>
References: <9B67B24A-F81C-44EA-B9A7-B7CDA76EBA76@gmail.com>
 <713426E0-A01A-433B-81E9-8D96BB97EB5F@justtesting.org>
 <7AC681B4-0B1F-40BF-8137-5537CE127BFE@gmail.com>
 <01C6EAF5-F683-47D2-B62D-EFFB2EB9137A@gmail.com>
 <CAKFCL4UYbBJxgXLhj3ySsogVEjz3A__oCH7uptb+Ci24cGVOsA@mail.gmail.com>
 <9563EEDA-5A86-45D6-B427-D043756D0171@justtesting.org>
 <CAKFCL4XSDNfANprp1E9owqxOjz+XSL7XtaoTGEpwSgV_AUUVBA@mail.gmail.com>
 <4DE2C615-F058-4A29-8512-66B57F3FB6B7@justtesting.org>
Message-ID: <102FC91E-9562-4B81-A2E5-196E5BD00510@gmail.com>

Hi,

just to elaborate a bit.  We *can* build cross compiler, and cross compile ghc with
the current make based build system.  I'm not certain how well packaging binary
distributions of cross compiled ghc's work.  I've only run into several when trying
to build binary distributions for cross compilers (compiler host != compiler target).

This is also where the relocatable topic came up. If the build system would build ghc
in such a way that I could just take the stage1/stage2/stageN folder and relocate it
into it's final place.  Building binary distributions would be a simple as packaging
up that folder.  If we want to do some additional configuration on the install host,
we could add an automake script, but it wouldn't be strictly necessary.  For the case
of cross compilers, I'm pretty much sure, I do want almost none of the current 
distrib configure script. My toolchain is locked down pretty hard, so I know the tools
I *need* to use.  Anything that the configure script at install time could mess up
is just going to result in more issues down the line.

Now as mentioned I was able to get most of the relocatable logic sorted by dropping
the wrapper script, and have ghc determine it's topdir on it's own (for mac and linux)
by reusing the codepaths already in place for windows.  The package db *does* understand
$topdir and ${pkgroot}.  Again reusing the $topdir logic, present for windows, allows
relocatable package databases.

Now the final issue that came up is dynamic libraries, which on macOS to some degree
encode their location.  However at build time the layout of libraries is sufficiently
different from the layout of libraries once installed.  Which would require to do
some additional path manipulation with the insall_name_tool at install time.

To make this easier, it would be preferable to have the same layout at build time as
it will be at install time.

Another issue I have with the current build system is, that everything is built *in
tree*.  This means that a) if cleaning doesn't work properly, I might have some
stale data lurking around and b) I am unable to build multiple configurations from
the same source tree (or modifications thereof) without resorting to some commit/push/pull
on local copies of the source tree, or wiping out the source tree for each build.

Therefore, after trying to relocate build artifacts in the current build system such
that build and install layouts are more similar.  I hereby declare defeat.  Not only
would this change the way the current build system works quite a bit, it's als pretty
hard to refactor the current aged build system in that way, and I believe it would
result in a number of additional bugs.  And finally, even if that change would make
it into GHC, Hadrian would have to be adapted to it as well.

I have now started trying to graft this different layout ontop of Hadrian.  If this
works out as I hope.  I believe it would drastically simplify the installation rules
as well as binary distribution rules in Hadrian.  It might also provide me with some
knowledge about Hadrian, and how much I like/dislike it over the current make system.

Maybe this is the direction we need to take to make Hadrian a viable option for the
build system.  Otherwise I fear Hadrian will never make it into ghc, if the current
build system keeps evolving and Hadrian fails to keep up.  Ideally we'd probably have
features in Hadrian that the current build system is lacking, which make Hadrian the
attractive alternative. E.g. moving Hadrian to "can do X better" instead of "can also
build GHC, but doesn't have all the features that the current build system has".

Cheers,
 Moritz
 
> On Oct 25, 2017, at 8:12 AM, Manuel M T Chakravarty <chak at justtesting.org> wrote:
> 
> That doesn’t mean it can’t be used for cross-compilation once it is in the tree.
> 
>> Am 25.10.2017 um 11:06 schrieb Brandon Allbery <allbery.b at gmail.com>:
>> 
>> Discussion I've been seeing is Hadrian will not be ready for production use for 8.4. Pulling it in tree is scheduled for 8.4 mostly to make it easier to keep up to date with other changes and to make it easier to work on and test the various missing pieces: as I understand it, Hadrian can't yet deal with all of the various platform special cases, etc. that an actual release requires. 
>> 
>> On Tue, Oct 24, 2017 at 8:02 PM, Manuel M T Chakravarty <chak at justtesting.org> wrote:
>> Why are you saying that? 
>> 
>> I think, Moritz is right. Hadrian is supposed to be the build system for 8.4. Adding new functionality for cross-compilation to the old build system is frustrating.
>> 
>> Manuel
>> 
>>> Brandon Allbery <allbery.b at gmail.com>:
>>> 
>>> On Tue, Oct 24, 2017 at 5:02 AM, Moritz Angermann <moritz.angermann at gmail.com> wrote:
>>> However, I am now again at the point where I start hacking on the build
>>> system, while Hadrian is imminent.  And this is quite depressing
>>> 
>>> Realistically, while Hadrian going into the tree may be imminent, as I understand it Hadrian becoming the primary build system --- or even a viable alternative build system --- is not. It's more of a repo logistics speed bump. Just let it go for now.
>>> 
>>> -- 
>>> 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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> 
>> 
>> 
>> 
>> -- 
>> 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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From ben at smart-cactus.org  Wed Oct 25 01:55:04 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 24 Oct 2017 21:55:04 -0400
Subject: Bringing back #ghc IRC logging
In-Reply-To: <5b8c4f5c-3dfd-6f48-e2d6-8bc27eda7cfd@nh2.me>
References: <d56a2d98-d75c-066e-c877-a2d50487bf56@nh2.me>
 <87d195u10j.fsf@ben-laptop.smart-cactus.org>
 <5b8c4f5c-3dfd-6f48-e2d6-8bc27eda7cfd@nh2.me>
Message-ID: <87wp3kyosn.fsf@ben-laptop.smart-cactus.org>

Niklas Hambüchen <mail at nh2.me> writes:

> Hey Ben,
>
> I haven't heard of a single concern of enabling botbot.me over the last
> 3 months.
>
> Can we go ahead and enable it?
>
> All we need is a channel op to fill out https://botbot.me/request/.
>
Yep, let's do it. Thanks for following up on this!

Herbert, can you complete the request?

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171024/c97c3723/attachment.sig>

From moritz.angermann at gmail.com  Wed Oct 25 01:59:15 2017
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Wed, 25 Oct 2017 09:59:15 +0800
Subject: Bringing back #ghc IRC logging
In-Reply-To: <87wp3kyosn.fsf@ben-laptop.smart-cactus.org>
References: <d56a2d98-d75c-066e-c877-a2d50487bf56@nh2.me>
 <87d195u10j.fsf@ben-laptop.smart-cactus.org>
 <5b8c4f5c-3dfd-6f48-e2d6-8bc27eda7cfd@nh2.me>
 <87wp3kyosn.fsf@ben-laptop.smart-cactus.org>
Message-ID: <2415ECB4-30F0-4BB4-B394-256F7558C1A8@gmail.com>

Just the other day, someone said logging *did* work again...
and indeed, it seems like it does:

http://ircbrowse.net/browse/ghc?id=202340&timestamp=1508883548#t1508883548

Cheers,
 Moritz

> On Oct 25, 2017, at 9:55 AM, Ben Gamari <ben at smart-cactus.org> wrote:
> 
> Niklas Hambüchen <mail at nh2.me> writes:
> 
>> Hey Ben,
>> 
>> I haven't heard of a single concern of enabling botbot.me over the last
>> 3 months.
>> 
>> Can we go ahead and enable it?
>> 
>> All we need is a channel op to fill out https://botbot.me/request/.
>> 
> Yep, let's do it. Thanks for following up on this!
> 
> Herbert, can you complete the request?
> 
> Cheers,
> 
> - Ben
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From mail at joachim-breitner.de  Wed Oct 25 02:07:21 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 24 Oct 2017 22:07:21 -0400
Subject: Relocatable dist
In-Reply-To: <102FC91E-9562-4B81-A2E5-196E5BD00510@gmail.com>
References: <9B67B24A-F81C-44EA-B9A7-B7CDA76EBA76@gmail.com>
 <713426E0-A01A-433B-81E9-8D96BB97EB5F@justtesting.org>
 <7AC681B4-0B1F-40BF-8137-5537CE127BFE@gmail.com>
 <01C6EAF5-F683-47D2-B62D-EFFB2EB9137A@gmail.com>
 <CAKFCL4UYbBJxgXLhj3ySsogVEjz3A__oCH7uptb+Ci24cGVOsA@mail.gmail.com>
 <9563EEDA-5A86-45D6-B427-D043756D0171@justtesting.org>
 <CAKFCL4XSDNfANprp1E9owqxOjz+XSL7XtaoTGEpwSgV_AUUVBA@mail.gmail.com>
 <4DE2C615-F058-4A29-8512-66B57F3FB6B7@justtesting.org>
 <102FC91E-9562-4B81-A2E5-196E5BD00510@gmail.com>
Message-ID: <1508897241.4268.3.camel@joachim-breitner.de>

Hi,

right now I’d like to compare the compiler at my feature branch with
and without the last commit on that branch. I have a working copy at
the end of my feature branch. If the worktree was relocatable, I could
now simply `cp -r` the whole worktree, pop the top commit, run
`make -C ghc 2` and would be good to go.

This would be much more pleasant that the current thing where I have to
 create a new work tree and rebuild everything from scratch…

(Again, nothing constructive in this mail, it's just motivational.
Or maybe someone can enlighten me with a better workflow.)

Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171024/c49c9895/attachment.sig>

From lonetiger at gmail.com  Wed Oct 25 18:49:58 2017
From: lonetiger at gmail.com (Phyx)
Date: Wed, 25 Oct 2017 18:49:58 +0000
Subject: Bringing back #ghc IRC logging
In-Reply-To: <87wp3kyosn.fsf@ben-laptop.smart-cactus.org>
References: <d56a2d98-d75c-066e-c877-a2d50487bf56@nh2.me>
 <87d195u10j.fsf@ben-laptop.smart-cactus.org>
 <5b8c4f5c-3dfd-6f48-e2d6-8bc27eda7cfd@nh2.me>
 <87wp3kyosn.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CABHktDUoY_0w1wjf+iTjYLVjBHiejB76_u_JFLXsJfGUSuugAA@mail.gmail.com>

Herbert said he submitted the request months ago.

As botbot.me site says they don't honor every request, so I guess we
weren't selected.

I'd still prefer botbot.me as it seems more stable than ircbrowse.net which
also doesn't seem to work on mobile (Android, get a server error)

On Wed, Oct 25, 2017, 02:55 Ben Gamari <ben at smart-cactus.org> wrote:

> Niklas Hambüchen <mail at nh2.me> writes:
>
> > Hey Ben,
> >
> > I haven't heard of a single concern of enabling botbot.me over the last
> > 3 months.
> >
> > Can we go ahead and enable it?
> >
> > All we need is a channel op to fill out https://botbot.me/request/.
> >
> Yep, let's do it. Thanks for following up on this!
>
> Herbert, can you complete the request?
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171025/7524637b/attachment.html>

From simonpj at microsoft.com  Thu Oct 26 11:21:18 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 26 Oct 2017 11:21:18 +0000
Subject: Simplify.hs depends on typechecker
In-Reply-To: <1508859629.7658.15.camel@joachim-breitner.de>
References: <1508859629.7658.15.camel@joachim-breitner.de>
Message-ID: <AM4PR83MB00331B12438F2FC423399CEAAD450@AM4PR83MB0033.EURPRD83.prod.outlook.com>

I agree.

Both of these code paths go through initTcForLookup which is massive overkill, as the comment with `TcEnv.lookupGlobal` says.  There's clearly a ToDo here to strip off the redundant stuff and do a minimal lookup.

Would you like to make a ticket?

Simon


|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Joachim Breitner
|  Sent: 24 October 2017 16:40
|  To: ghc-devs at haskell.org
|  Subject: Simplify.hs depends on typechecker
|  
|  Hi,
|  
|  while rebuilding Simplify.o only I noticed that all of the type
|  checker, and HsSyn stuff, and renamer stuff, and so needed to be
|  rebuilt, which I found strange.
|  
|  After a little investigation, it seems that the simplifier depends on
|  CoreMonad, and that pulls some very few type-checker related things:
|  
|  1.
|      import TcRnMonad        ( initTcForLookup )
|      import {-# SOURCE #-} TcSplice ( lookupThName_maybe )
|  
|  for
|  
|      thNameToGhcName :: TH.Name -> CoreM (Maybe Name)
|      thNameToGhcName th_name = do
|          hsc_env <- getHscEnv
|          liftIO $ initTcForLookup hsc_env (lookupThName_maybe th_name)
|  
|  which is not even used in GHC, but only in GHC Plugins, so this could
|  probably be moved to a separate module pulled in by GhcPlugins.hs
|  
|  2.
|  
|      import TcEnv            ( lookupGlobal )
|  
|  for
|  
|      instance MonadThings CoreM where
|          lookupThing name = do { hsc_env <- getHscEnv
|                                ; liftIO $ lookupGlobal hsc_env name }
|  
|  This might be a bit harder to disentangle. But if successful, it would
|  probably make building GHC in parallel quite a bit faster. And it just
|  seems strange to me that the Core-to-Core code should depend on the
|  type checker…
|  
|  
|  I’m sending this out there in case someone has dug in that direction
|  before and has insights to share.
|  
|  
|  Greetings,
|  Joachim
|  
|  (Attached is a transitively reduced dependency graph of Simplify.hs,
|  created using Iavor’s
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub
|  .com%2Fyav%2Fgraphmod%2Fwiki&data=02%7C01%7Csimonpj%40microsoft.com%7Cb
|  16c817556de4d55d74c08d51af5a8cd%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  7C0%7C636444565247573129&sdata=oHpA%2F%2BHGyc0mHv%2FWj3nzGBiJCM2ufriryF
|  oZYNHSjqk%3D&reserved=0).
|  
|  
|  --
|  Joachim “nomeata” Breitner
|    mail at joachim-breitner.de
|  
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jo
|  achim-
|  breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cb16c817556de4d5
|  5d74c08d51af5a8cd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63644456
|  5247583137&sdata=wO14DxiOaXUOx59N22YoS%2FoC2%2Bi4IEp3bNnB4Dli12U%3D&res
|  erved=0

From rae at cs.brynmawr.edu  Thu Oct 26 22:11:59 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 26 Oct 2017 18:11:59 -0400
Subject: tcSubsumes
Message-ID: <66EEFF7E-040D-45AE-874F-81D8F4AF5F64@cs.brynmawr.edu>

Hi Simon,

Could you take a look at TcSimplify.tcSubsumes? This relatively new function pushes the TcLevel when calling tcSubType, but then doesn't set the TcLevel when calling the solver. Inexplicably, this sometimes works -- even passing the testsuite. Somehow, my work caused this to fail. I fixed it by setting the TcLevel before calling the solver.

Two questions:

1. Is this a reasonable fix?

2. (optional) How is it possible that this didn't fail drastically often?

Note (to author / reviewers of this function): my astonishment isn't that this error crept into the codebase -- I've done similar many many times. My astonishment is how the testsuite didn't find this error forthwith.

Thanks,
Richard

From rae at cs.brynmawr.edu  Fri Oct 27 01:43:18 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 26 Oct 2017 21:43:18 -0400
Subject: valid substitutions for holes
Message-ID: <DF30A40B-2621-4472-AFE6-184F35D7A14D@cs.brynmawr.edu>

Hi all,

GHC HEAD currently suggests valid in-scope single-identifier substitutions for typed holes (underscores in terms). Some unrelated work somehow changed the output, and I'm wondering if this is a change for the better or for the worse.

The test case is this:

> f :: Int -> Int -> Int
> f x y = _ x y

With my patch, GHC now suggests `pure` and `return` as replacements for _ (along with the other top contenders of (-), asTypeOf, and const). (You can also increase the number of suggestions, which will then include (+) and (*) among others.) It's true that `pure` and `return` fit the bill, noting that ((->) Int) is an Applicative. But I doubt these suggestions will help the user.

I'm not keen to make fixing this "valid suggestions" feature (which I do really like) a dependency of finishing my patch, but I also don't want the change to output to go unnoticed. So, I'm asking: when I merge my patch, should I post a bug asking for perhaps a priority ordering of suggestions?

Thanks,
Richard

From simonpj at microsoft.com  Fri Oct 27 08:06:45 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 27 Oct 2017 08:06:45 +0000
Subject: FW: [commit: ghc] wip/nfs-locking: Use conventional whitespacing for
 @. (31515fa)
In-Reply-To: <20171027000540.A4F1F3A5EA@ghc.haskell.org>
References: <20171027000540.A4F1F3A5EA@ghc.haskell.org>
Message-ID: <AM4PR83MB00339256C600D61B21EA9178AD5A0@AM4PR83MB0033.EURPRD83.prod.outlook.com>

I've received 1500 of these commit messages overnight, and another arrives every few seconds.  Are they likely to stop soon?

Simon

-----Original Message-----
From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of git at git.haskell.org
Sent: 27 October 2017 01:06
To: ghc-commits at haskell.org
Subject: [commit: ghc] wip/nfs-locking: Use conventional whitespacing for @. (31515fa)

Repository : ssh://git at git.haskell.org/ghc

On branch  : wip/nfs-locking
Link       : https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haskell.org%2Ftrac%2Fghc%2Fchangeset%2F31515fad107d28f83b47d6249dd7b8c1eeb3bc70%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7Cebc410b60526437cbb3708d51d115271%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636446882594775349&sdata=KueMNn9bjSn8cimiE1IS1JZSRN0arIrgcpD%2FBeMJ%2FGk%3D&reserved=0

>---------------------------------------------------------------

commit 31515fad107d28f83b47d6249dd7b8c1eeb3bc70
Author: Andrey Mokhov <andrey.mokhov at gmail.com>
Date:   Fri Feb 26 11:37:47 2016 +0000

    Use conventional whitespacing for @.
    
    See #210.


>---------------------------------------------------------------

31515fad107d28f83b47d6249dd7b8c1eeb3bc70
 src/GHC.hs                 |  2 +-
 src/Rules/Actions.hs       |  2 +-
 src/Rules/Compile.hs       |  2 +-
 src/Rules/Data.hs          |  4 ++--
 src/Rules/Dependencies.hs  |  2 +-
 src/Rules/Documentation.hs |  2 +-
 src/Rules/Generate.hs      |  2 +-
 src/Rules/Library.hs       |  4 ++--
 src/Rules/Program.hs       |  6 +++---
 src/Rules/Register.hs      |  2 +-
 src/Settings/Paths.hs      | 10 +++++-----
 src/Way.hs                 |  2 +-
 12 files changed, 20 insertions(+), 20 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 31515fad107d28f83b47d6249dd7b8c1eeb3bc70
_______________________________________________
ghc-commits mailing list
ghc-commits at haskell.org
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-commits&data=02%7C01%7Csimonpj%40microsoft.com%7Cebc410b60526437cbb3708d51d115271%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636446882594785357&sdata=%2BWAgDLBOd5wU3M3bH2Sc6CqEzZM9RpEKUES3H8BU534%3D&reserved=0

From simonpj at microsoft.com  Fri Oct 27 15:36:56 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 27 Oct 2017 15:36:56 +0000
Subject: wip/nfsl-locking
Message-ID: <AM4PR83MB003345F83B79F6317B0DA632AD5A0@AM4PR83MB0033.EURPRD83.prod.outlook.com>

Can anyone switch off this torrent of commit messages for wip/nfs-locking?  I'm submerged in junk.
I'm about to write a junk-mail rule
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171027/caf6c451/attachment.html>

From ben at smart-cactus.org  Fri Oct 27 18:44:23 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Fri, 27 Oct 2017 14:44:23 -0400
Subject: FW: [commit: ghc] wip/nfs-locking: Use conventional whitespacing
 for @. (31515fa)
In-Reply-To: <AM4PR83MB00339256C600D61B21EA9178AD5A0@AM4PR83MB0033.EURPRD83.prod.outlook.com>
References: <20171027000540.A4F1F3A5EA@ghc.haskell.org>
 <AM4PR83MB00339256C600D61B21EA9178AD5A0@AM4PR83MB0033.EURPRD83.prod.outlook.com>
Message-ID: <8760b0xwfs.fsf@ben-laptop.smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:

> I've received 1500 of these commit messages overnight, and another arrives every few seconds.  Are they likely to stop soon?
>
Oh dear, this looks like an unfortunate consequence of my pushing a
branch with the Hadrian history. Have they stopped yet?

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171027/afdff347/attachment.sig>

From ben at well-typed.com  Fri Oct 27 19:31:07 2017
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 27 Oct 2017 15:31:07 -0400
Subject: Please add your HCAR submissions
Message-ID: <873764xu9w.fsf@ben-laptop.smart-cactus.org>

Hello everyone,

I am currently putting together the GHC's HCAR submission for the coming
publication. If you have a something that you would like mentioned
(compiler feature or otherwise) please do add it here [1] sometime
before Sunday, 5 November. Alternatively, feel free to mention it to me
via email or IRC.

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/wiki/Status/Oct17

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171027/f9fa6112/attachment.sig>

From mail at joachim-breitner.de  Fri Oct 27 19:58:15 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 27 Oct 2017 15:58:15 -0400
Subject: wip/nfsl-locking
In-Reply-To: <AM4PR83MB003345F83B79F6317B0DA632AD5A0@AM4PR83MB0033.EURPRD83.prod.outlook.com>
References: <AM4PR83MB003345F83B79F6317B0DA632AD5A0@AM4PR83MB0033.EURPRD83.prod.outlook.com>
Message-ID: <1509134295.13861.1.camel@joachim-breitner.de>

Hi,

Am Freitag, den 27.10.2017, 15:36 +0000 schrieb Simon Peyton Jones via
ghc-devs:
> Can anyone switch off this torrent of commit messages for wip/nfs-locking?  I’m submerged in junk.
> I’m about to write a junk-mail rule

I assume that some mailserver has all those mails and is now unerringly
working it off, so I am not sure anybody can stop it at this time.

Anyways, I have already added a rule to drop these mails…

Joachim
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171027/ca22d531/attachment.sig>

From mail at joachim-breitner.de  Fri Oct 27 20:06:01 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 27 Oct 2017 16:06:01 -0400
Subject: [commit: ghc] wip/float-join-points: Wip on floating join
 points (128e4c1)
In-Reply-To: <20171027152434.5181F3A5EA@ghc.haskell.org>
References: <20171027152434.5181F3A5EA@ghc.haskell.org>
Message-ID: <1509134761.13861.8.camel@joachim-breitner.de>

Hi Simon,

Am Freitag, den 27.10.2017, 15:24 +0000 schrieb git at git.haskell.org:
> commit 128e4c1ffa29f3dfade7128152c143cd601aaa3a
> Author: Simon Peyton Jones <simonpj at microsoft.com>
> Date:   Fri Oct 27 16:20:24 2017 +0100
> 
>     Wip on floating join points

do you expect to merge that soon, or can I land Exitification before
that? (I’m worried that I have to re-do a lot of performance analysis
if the Simplifier suddenly does new things to join points).

Blocking for Exitification is:
 * https://phabricator.haskell.org/D4130 needs to land

   Or rather, I’d prefer if someone who understands the Simplifier
   better than I fixes it properly. See
   https://phabricator.haskell.org/D4130#inline-32243
   for bits that I am puzzled about.

 * I need to understand better why inlining join points in the final 
   simplifier run regresses things.

   Unless you permit merging Exitification without final inlining
   even before we completely solve this mystery, on the grounds that
     - the nofib results say it’s the right thing to do and
     - there is a plausible theory (exit join points in unfolding 
       enable optimizations in later modules in earlier phases).

Greetings,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171027/43f1162d/attachment.sig>

From simonpj at microsoft.com  Fri Oct 27 21:58:30 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 27 Oct 2017 21:58:30 +0000
Subject: FW: [commit: ghc] wip/nfs-locking: Use conventional whitespacing
 for @. (31515fa)
In-Reply-To: <8760b0xwfs.fsf@ben-laptop.smart-cactus.org>
References: <20171027000540.A4F1F3A5EA@ghc.haskell.org>
 <AM4PR83MB00339256C600D61B21EA9178AD5A0@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <8760b0xwfs.fsf@ben-laptop.smart-cactus.org>
Message-ID: <HE1PR83MB00426D72E82EC45A5496BF5BAD5A0@HE1PR83MB0042.EURPRD83.prod.outlook.com>

yes I think it's stopped.  I'' remove my junk-mail rule

| -----Original Message-----
| From: Ben Gamari [mailto:ben at smart-cactus.org]
| Sent: 27 October 2017 19:44
| To: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs at haskell.org
| Subject: Re: FW: [commit: ghc] wip/nfs-locking: Use conventional
| whitespacing for @. (31515fa)
| 
| Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:
| 
| > I've received 1500 of these commit messages overnight, and another
| arrives every few seconds.  Are they likely to stop soon?
| >
| Oh dear, this looks like an unfortunate consequence of my pushing a
| branch with the Hadrian history. Have they stopped yet?
| 
| Cheers,
| 
| - Ben

From simonpj at microsoft.com  Fri Oct 27 22:06:58 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 27 Oct 2017 22:06:58 +0000
Subject: [commit: ghc] master: Make tagForCon non-linear (faf60e8)
In-Reply-To: <20171027220325.2898F3A5EA@ghc.haskell.org>
References: <20171027220325.2898F3A5EA@ghc.haskell.org>
Message-ID: <HE1PR83MB0042E25E85376EDA978DE9EDAD5A0@HE1PR83MB0042.EURPRD83.prod.outlook.com>

Bartosz

Why not just cache the #datacons in the TyCon (in the DataTyCon constructor).  That seems simple, direct, and fast.  

And simpler than the stuff you are forced into here.

Simon

| -----Original Message-----
| From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of
| git at git.haskell.org
| Sent: 27 October 2017 23:03
| To: ghc-commits at haskell.org
| Subject: [commit: ghc] master: Make tagForCon non-linear (faf60e8)
| 
| Repository : ssh://git at git.haskell.org/ghc
| 
| On branch  : master
| Link       :
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske
| ll.org%2Ftrac%2Fghc%2Fchangeset%2Ffaf60e858a293affca463043c830e1edb568500
| 3%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C677da6a867674476306508d5
| 1d869247%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636447386176303711&
| sdata=tp4PTSkN5iBwKkWgZdT%2BcHKK8EKz8NQZeE%2FegVdx%2FIM%3D&reserved=0
| 
| >---------------------------------------------------------------
| 
| commit faf60e858a293affca463043c830e1edb5685003
| Author: Bartosz Nitka <bnitka at fb.com>
| Date:   Fri Oct 20 20:30:52 2017 +0100
| 
|     Make tagForCon non-linear
| 
|     Computing the number of constructors for TyCon is linear
|     in the number of constructors.
|     That's wasteful if all you want to check is if that
|     number is smaller than what fits in tag bits
|     (usually 8 things).
| 
|     What this change does is to use a function that can
|     determine the ineqaulity without computing the size.
| 
|     This improves compile time on a module with a
|     data type that has 10k constructors.
|     The variance in total time is (suspiciously) high,
|     but going by the best of 3 the numbers are 8.186s vs 7.511s.
|     For 1000 constructors the difference isn't noticeable:
|     0.646s vs 0.624s.
|     The hot spots were cgDataCon and cgEnumerationTyCon
|     where tagForCon is called in a loop.
| 
|     One alternative would be to pass down the size.
| 
|     Test Plan: harbormaster
| 
|     Reviewers: bgamari, simonmar, austin
| 
|     Reviewed By: simonmar
| 
|     Subscribers: rwbarton, thomie
| 
|     Differential Revision: https://phabricator.haskell.org/D4116
| 
| 
| >---------------------------------------------------------------
| 
| faf60e858a293affca463043c830e1edb5685003
|  compiler/codeGen/StgCmmClosure.hs | 11 ++++++++---
|  compiler/types/TyCon.hs           | 16 +++++++++++++++-
|  2 files changed, 23 insertions(+), 4 deletions(-)
| 
| diff --git a/compiler/codeGen/StgCmmClosure.hs
| b/compiler/codeGen/StgCmmClosure.hs
| index 1da1f70..2501ec9 100644
| --- a/compiler/codeGen/StgCmmClosure.hs
| +++ b/compiler/codeGen/StgCmmClosure.hs
| @@ -361,13 +361,18 @@ type DynTag = Int       -- The tag on a *pointer*
|  isSmallFamily :: DynFlags -> Int -> Bool  isSmallFamily dflags fam_size
| = fam_size <= mAX_PTR_TAG dflags
| 
| +-- | Faster version of isSmallFamily if you haven't computed the size
| yet.
| +isSmallFamilyTyCon :: DynFlags -> TyCon -> Bool isSmallFamilyTyCon
| +dflags tycon =
| +  tyConFamilySizeAtMost tycon (mAX_PTR_TAG dflags)
| +
|  tagForCon :: DynFlags -> DataCon -> DynTag  tagForCon dflags con
| -  | isSmallFamily dflags fam_size = con_tag
| -  | otherwise                     = 1
| +  | isSmallFamilyTyCon dflags tycon = con_tag
| +  | otherwise                       = 1
|    where
|      con_tag  = dataConTag con -- NB: 1-indexed
| -    fam_size = tyConFamilySize (dataConTyCon con)
| +    tycon = dataConTyCon con
| 
|  tagForArity :: DynFlags -> RepArity -> DynTag  tagForArity dflags arity
| diff --git a/compiler/types/TyCon.hs b/compiler/types/TyCon.hs index
| 39d2e9b..103c824 100644
| --- a/compiler/types/TyCon.hs
| +++ b/compiler/types/TyCon.hs
| @@ -78,7 +78,7 @@ module TyCon(
|          tyConDataCons, tyConDataCons_maybe,
|          tyConSingleDataCon_maybe, tyConSingleDataCon,
|          tyConSingleAlgDataCon_maybe,
| -        tyConFamilySize,
| +        tyConFamilySize, tyConFamilySizeAtMost,
|          tyConStupidTheta,
|          tyConArity,
|          tyConRoles,
| @@ -2205,6 +2205,20 @@ tyConFamilySize tc@(AlgTyCon { algTcRhs = rhs })
|        _                              -> pprPanic "tyConFamilySize 1"
| (ppr tc)
|  tyConFamilySize tc = pprPanic "tyConFamilySize 2" (ppr tc)
| 
| +-- | Determine if number of value constructors a 'TyCon' has is smaller
| +-- than n. Faster than tyConFamilySize tc <= n.
| +-- Panics if the 'TyCon' is not algebraic or a tuple
| +tyConFamilySizeAtMost  :: TyCon -> Int -> Bool tyConFamilySizeAtMost
| +tc@(AlgTyCon { algTcRhs = rhs }) n
| +  = case rhs of
| +      DataTyCon { data_cons = cons } -> lengthAtMost cons n
| +      NewTyCon {}                    -> 1 <= n
| +      TupleTyCon {}                  -> 1 <= n
| +      SumTyCon { data_cons = cons }  -> lengthAtMost cons n
| +      _                              -> pprPanic "tyConFamilySizeAtMost
| 1"
| +                                          (ppr tc)
| +tyConFamilySizeAtMost tc _ = pprPanic "tyConFamilySizeAtMost 2" (ppr
| +tc)
| +
|  -- | Extract an 'AlgTyConRhs' with information about data constructors
| from an
|  -- algebraic or tuple 'TyCon'. Panics for any other sort of 'TyCon'
|  algTyConRhs :: TyCon -> AlgTyConRhs
| 
| _______________________________________________
| ghc-commits mailing list
| ghc-commits at haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| commits&data=02%7C01%7Csimonpj%40microsoft.com%7C677da6a867674476306508d5
| 1d869247%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636447386176313720&
| sdata=NfTqei3XryWnCiNRgOZDT6XfMRMfAST7EKFBSi%2FCXa8%3D&reserved=0

From niteria at gmail.com  Fri Oct 27 22:40:56 2017
From: niteria at gmail.com (Bartosz Nitka)
Date: Fri, 27 Oct 2017 15:40:56 -0700
Subject: [commit: ghc] master: Make tagForCon non-linear (faf60e8)
In-Reply-To: <HE1PR83MB0042E25E85376EDA978DE9EDAD5A0@HE1PR83MB0042.EURPRD83.prod.outlook.com>
References: <20171027220325.2898F3A5EA@ghc.haskell.org>
 <HE1PR83MB0042E25E85376EDA978DE9EDAD5A0@HE1PR83MB0042.EURPRD83.prod.outlook.com>
Message-ID: <CAOSxnRjfUq-yWLcoqNBQMbtxj9zNFVxkmT5Xf_LFRYi9GVB3wA@mail.gmail.com>

Hi Simon,

I considered that, but I'm shy at changing data types. Especially for
caching, because sometimes keeping the data in sync can be difficult.
This was a safer way to approach the problem, and I believe this part
of the code is no longer the problem.
I can try the caching approach, but I have limited time and if I run
into problems (I'm thinking performance, technically caching should
increase allocations) I will have to abort.

Let me piggy-back a question for a follow-up diff on this.

Another bottleneck is in mkDataCon. For each data constructor we do [1]:

  tag = assoc "mkDataCon" (tyConDataCons rep_tycon `zip` [fIRST_TAG..]) con

The easiest way to fix this was to cache the tag allocation (using
UniqFM) in DataTyCon and SumTyCon.
This is all in a knot, but it works out in this case.

Does that sound like a sound approach?
An alternative would be to refactor the code to pass the tags down,
but that looked harder.

Unfortunately going this route doesn't help with determining the size,
because checking the size of UniqFM is linear.


[1] https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/basicTypes/DataCon.hs;faf60e858a293affca463043c830e1edb5685003$921

Thanks,
Bartosz

2017-10-27 15:06 GMT-07:00 Simon Peyton Jones <simonpj at microsoft.com>:
> Bartosz
>
> Why not just cache the #datacons in the TyCon (in the DataTyCon constructor).  That seems simple, direct, and fast.
>
> And simpler than the stuff you are forced into here.
>
> Simon
>
> | -----Original Message-----
> | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of
> | git at git.haskell.org
> | Sent: 27 October 2017 23:03
> | To: ghc-commits at haskell.org
> | Subject: [commit: ghc] master: Make tagForCon non-linear (faf60e8)
> |
> | Repository : ssh://git at git.haskell.org/ghc
> |
> | On branch  : master
> | Link       :
> | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske
> | ll.org%2Ftrac%2Fghc%2Fchangeset%2Ffaf60e858a293affca463043c830e1edb568500
> | 3%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C677da6a867674476306508d5
> | 1d869247%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636447386176303711&
> | sdata=tp4PTSkN5iBwKkWgZdT%2BcHKK8EKz8NQZeE%2FegVdx%2FIM%3D&reserved=0
> |
> | >---------------------------------------------------------------
> |
> | commit faf60e858a293affca463043c830e1edb5685003
> | Author: Bartosz Nitka <bnitka at fb.com>
> | Date:   Fri Oct 20 20:30:52 2017 +0100
> |
> |     Make tagForCon non-linear
> |
> |     Computing the number of constructors for TyCon is linear
> |     in the number of constructors.
> |     That's wasteful if all you want to check is if that
> |     number is smaller than what fits in tag bits
> |     (usually 8 things).
> |
> |     What this change does is to use a function that can
> |     determine the ineqaulity without computing the size.
> |
> |     This improves compile time on a module with a
> |     data type that has 10k constructors.
> |     The variance in total time is (suspiciously) high,
> |     but going by the best of 3 the numbers are 8.186s vs 7.511s.
> |     For 1000 constructors the difference isn't noticeable:
> |     0.646s vs 0.624s.
> |     The hot spots were cgDataCon and cgEnumerationTyCon
> |     where tagForCon is called in a loop.
> |
> |     One alternative would be to pass down the size.
> |
> |     Test Plan: harbormaster
> |
> |     Reviewers: bgamari, simonmar, austin
> |
> |     Reviewed By: simonmar
> |
> |     Subscribers: rwbarton, thomie
> |
> |     Differential Revision: https://phabricator.haskell.org/D4116
> |
> |
> | >---------------------------------------------------------------
> |
> | faf60e858a293affca463043c830e1edb5685003
> |  compiler/codeGen/StgCmmClosure.hs | 11 ++++++++---
> |  compiler/types/TyCon.hs           | 16 +++++++++++++++-
> |  2 files changed, 23 insertions(+), 4 deletions(-)
> |
> | diff --git a/compiler/codeGen/StgCmmClosure.hs
> | b/compiler/codeGen/StgCmmClosure.hs
> | index 1da1f70..2501ec9 100644
> | --- a/compiler/codeGen/StgCmmClosure.hs
> | +++ b/compiler/codeGen/StgCmmClosure.hs
> | @@ -361,13 +361,18 @@ type DynTag = Int       -- The tag on a *pointer*
> |  isSmallFamily :: DynFlags -> Int -> Bool  isSmallFamily dflags fam_size
> | = fam_size <= mAX_PTR_TAG dflags
> |
> | +-- | Faster version of isSmallFamily if you haven't computed the size
> | yet.
> | +isSmallFamilyTyCon :: DynFlags -> TyCon -> Bool isSmallFamilyTyCon
> | +dflags tycon =
> | +  tyConFamilySizeAtMost tycon (mAX_PTR_TAG dflags)
> | +
> |  tagForCon :: DynFlags -> DataCon -> DynTag  tagForCon dflags con
> | -  | isSmallFamily dflags fam_size = con_tag
> | -  | otherwise                     = 1
> | +  | isSmallFamilyTyCon dflags tycon = con_tag
> | +  | otherwise                       = 1
> |    where
> |      con_tag  = dataConTag con -- NB: 1-indexed
> | -    fam_size = tyConFamilySize (dataConTyCon con)
> | +    tycon = dataConTyCon con
> |
> |  tagForArity :: DynFlags -> RepArity -> DynTag  tagForArity dflags arity
> | diff --git a/compiler/types/TyCon.hs b/compiler/types/TyCon.hs index
> | 39d2e9b..103c824 100644
> | --- a/compiler/types/TyCon.hs
> | +++ b/compiler/types/TyCon.hs
> | @@ -78,7 +78,7 @@ module TyCon(
> |          tyConDataCons, tyConDataCons_maybe,
> |          tyConSingleDataCon_maybe, tyConSingleDataCon,
> |          tyConSingleAlgDataCon_maybe,
> | -        tyConFamilySize,
> | +        tyConFamilySize, tyConFamilySizeAtMost,
> |          tyConStupidTheta,
> |          tyConArity,
> |          tyConRoles,
> | @@ -2205,6 +2205,20 @@ tyConFamilySize tc@(AlgTyCon { algTcRhs = rhs })
> |        _                              -> pprPanic "tyConFamilySize 1"
> | (ppr tc)
> |  tyConFamilySize tc = pprPanic "tyConFamilySize 2" (ppr tc)
> |
> | +-- | Determine if number of value constructors a 'TyCon' has is smaller
> | +-- than n. Faster than tyConFamilySize tc <= n.
> | +-- Panics if the 'TyCon' is not algebraic or a tuple
> | +tyConFamilySizeAtMost  :: TyCon -> Int -> Bool tyConFamilySizeAtMost
> | +tc@(AlgTyCon { algTcRhs = rhs }) n
> | +  = case rhs of
> | +      DataTyCon { data_cons = cons } -> lengthAtMost cons n
> | +      NewTyCon {}                    -> 1 <= n
> | +      TupleTyCon {}                  -> 1 <= n
> | +      SumTyCon { data_cons = cons }  -> lengthAtMost cons n
> | +      _                              -> pprPanic "tyConFamilySizeAtMost
> | 1"
> | +                                          (ppr tc)
> | +tyConFamilySizeAtMost tc _ = pprPanic "tyConFamilySizeAtMost 2" (ppr
> | +tc)
> | +
> |  -- | Extract an 'AlgTyConRhs' with information about data constructors
> | from an
> |  -- algebraic or tuple 'TyCon'. Panics for any other sort of 'TyCon'
> |  algTyConRhs :: TyCon -> AlgTyConRhs
> |
> | _______________________________________________
> | ghc-commits mailing list
> | ghc-commits at haskell.org
> | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
> | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C677da6a867674476306508d5
> | 1d869247%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636447386176313720&
> | sdata=NfTqei3XryWnCiNRgOZDT6XfMRMfAST7EKFBSi%2FCXa8%3D&reserved=0

From me at ara.io  Fri Oct 27 22:43:25 2017
From: me at ara.io (Ara Adkins)
Date: Fri, 27 Oct 2017 23:43:25 +0100
Subject: [commit: ghc] wip/nfs-locking: Use conventional whitespacing for
 @. (31515fa)
In-Reply-To: <HE1PR83MB00426D72E82EC45A5496BF5BAD5A0@HE1PR83MB0042.EURPRD83.prod.outlook.com>
References: <20171027000540.A4F1F3A5EA@ghc.haskell.org>
 <AM4PR83MB00339256C600D61B21EA9178AD5A0@AM4PR83MB0033.EURPRD83.prod.outlook.com>
 <8760b0xwfs.fsf@ben-laptop.smart-cactus.org>
 <HE1PR83MB00426D72E82EC45A5496BF5BAD5A0@HE1PR83MB0042.EURPRD83.prod.outlook.com>
Message-ID: <A21C8B06-7F98-49B7-80B9-0D41BC50A5D0@ara.io>

It’s been one heck of a day with these coming in. It does seem to have stopped now. 

_ara

> On 27 Oct 2017, at 22:58, Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> wrote:
> 
> yes I think it's stopped.  I'' remove my junk-mail rule
> 
> | -----Original Message-----
> | From: Ben Gamari [mailto:ben at smart-cactus.org]
> | Sent: 27 October 2017 19:44
> | To: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs at haskell.org
> | Subject: Re: FW: [commit: ghc] wip/nfs-locking: Use conventional
> | whitespacing for @. (31515fa)
> | 
> | Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:
> | 
> | > I've received 1500 of these commit messages overnight, and another
> | arrives every few seconds.  Are they likely to stop soon?
> | >
> | Oh dear, this looks like an unfortunate consequence of my pushing a
> | branch with the Hadrian history. Have they stopped yet?
> | 
> | Cheers,
> | 
> | - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From simonpj at microsoft.com  Fri Oct 27 23:14:13 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 27 Oct 2017 23:14:13 +0000
Subject: Family instance consistency
Message-ID: <HE1PR83MB00422D7F00A200331F533124AD5A0@HE1PR83MB0042.EURPRD83.prod.outlook.com>

Edward
Could you possibly take a look at #14396?   It's going to bite us soon, as Alan's Trees That Grow patch lands (see the branch mentioned on the ticket).
(In fact, Alan, I don't know how you build that branch ; I can't build it.)
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171027/fb77f9bd/attachment-0001.html>

From simonpj at microsoft.com  Fri Oct 27 23:30:42 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 27 Oct 2017 23:30:42 +0000
Subject: [commit: ghc] master: Make tagForCon non-linear (faf60e8)
In-Reply-To: <CAOSxnRjfUq-yWLcoqNBQMbtxj9zNFVxkmT5Xf_LFRYi9GVB3wA@mail.gmail.com>
References: <20171027220325.2898F3A5EA@ghc.haskell.org>
 <HE1PR83MB0042E25E85376EDA978DE9EDAD5A0@HE1PR83MB0042.EURPRD83.prod.outlook.com>
 <CAOSxnRjfUq-yWLcoqNBQMbtxj9zNFVxkmT5Xf_LFRYi9GVB3wA@mail.gmail.com>
Message-ID: <HE1PR83MB004268036032090F28735D61AD5A0@HE1PR83MB0042.EURPRD83.prod.outlook.com>

| I considered that, but I'm shy at changing data types. Especially for
| caching, because sometimes keeping the data in sync can be difficult.

In this case, not so.  Just make a smart contructor for DataTyCon and use it.  There are very few calls to it anyway!

As to the storage cost this is one word per data type.  There aren't that many data types!  (Compared to how many of everything else there is.)

Performance should be better -- no need to count the list repeatedly.

| Let me piggy-back a question for a follow-up diff on this.
| 
| Another bottleneck is in mkDataCon. For each data constructor we do [1]:
| 
|   tag = assoc "mkDataCon" (tyConDataCons rep_tycon `zip` [fIRST_TAG..])
| con
| 
| The easiest way to fix this was to cache the tag allocation (using
| UniqFM) in DataTyCon and SumTyCon.

I don’t like this.  Unlike the family size, the tag-map would be used in just one place, when building the data constructors.  Yes it'd be an extra argument to pass, but it's a local temporary thing, just during data type construction, whereas adding a field in DataTyCon stays forever.

To pass it around
* TcTyClsDecls.tcConDecls constructs a tag-map (NameEnv Tag) from the
  knot-tied tycoon
* Passes the tag-map to tcConDecl
* Which passes it to buildDataCon
* Which looks up the tag and passes it to mkDataCon

Not hard.

For the family size though, just cache it in DataTyCon.

Simon

| This is all in a knot, but it works out in this case.
| 
| Does that sound like a sound approach?
| An alternative would be to refactor the code to pass the tags down, but
| that looked harder.
| 
| Unfortunately going this route doesn't help with determining the size,
| because checking the size of UniqFM is linear.
| 
| 
| [1]
| https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/basi
| cTypes/DataCon.hs;faf60e858a293affca463043c830e1edb5685003$921
| 
| Thanks,
| Bartosz
| 
| 2017-10-27 15:06 GMT-07:00 Simon Peyton Jones <simonpj at microsoft.com>:
| > Bartosz
| >
| > Why not just cache the #datacons in the TyCon (in the DataTyCon
| constructor).  That seems simple, direct, and fast.
| >
| > And simpler than the stuff you are forced into here.
| >
| > Simon
| >
| > | -----Original Message-----
| > | From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf
| > | Of git at git.haskell.org
| > | Sent: 27 October 2017 23:03
| > | To: ghc-commits at haskell.org
| > | Subject: [commit: ghc] master: Make tagForCon non-linear (faf60e8)
| > |
| > | Repository : ssh://git at git.haskell.org/ghc
| > |
| > | On branch  : master
| > | Link       :
| > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.
| > | haske
| > | ll.org%2Ftrac%2Fghc%2Fchangeset%2Ffaf60e858a293affca463043c830e1edb5
| > | 68500
| > | 3%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C677da6a867674476306
| > | 508d5
| > | 1d869247%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63644738617630
| > | 3711&
| > | sdata=tp4PTSkN5iBwKkWgZdT%2BcHKK8EKz8NQZeE%2FegVdx%2FIM%3D&reserved=
| > | 0
| > |
| > | >---------------------------------------------------------------
| > |
| > | commit faf60e858a293affca463043c830e1edb5685003
| > | Author: Bartosz Nitka <bnitka at fb.com>
| > | Date:   Fri Oct 20 20:30:52 2017 +0100
| > |
| > |     Make tagForCon non-linear
| > |
| > |     Computing the number of constructors for TyCon is linear
| > |     in the number of constructors.
| > |     That's wasteful if all you want to check is if that
| > |     number is smaller than what fits in tag bits
| > |     (usually 8 things).
| > |
| > |     What this change does is to use a function that can
| > |     determine the ineqaulity without computing the size.
| > |
| > |     This improves compile time on a module with a
| > |     data type that has 10k constructors.
| > |     The variance in total time is (suspiciously) high,
| > |     but going by the best of 3 the numbers are 8.186s vs 7.511s.
| > |     For 1000 constructors the difference isn't noticeable:
| > |     0.646s vs 0.624s.
| > |     The hot spots were cgDataCon and cgEnumerationTyCon
| > |     where tagForCon is called in a loop.
| > |
| > |     One alternative would be to pass down the size.
| > |
| > |     Test Plan: harbormaster
| > |
| > |     Reviewers: bgamari, simonmar, austin
| > |
| > |     Reviewed By: simonmar
| > |
| > |     Subscribers: rwbarton, thomie
| > |
| > |     Differential Revision: https://phabricator.haskell.org/D4116
| > |
| > |
| > | >---------------------------------------------------------------
| > |
| > | faf60e858a293affca463043c830e1edb5685003
| > |  compiler/codeGen/StgCmmClosure.hs | 11 ++++++++---
| > |  compiler/types/TyCon.hs           | 16 +++++++++++++++-
| > |  2 files changed, 23 insertions(+), 4 deletions(-)
| > |
| > | diff --git a/compiler/codeGen/StgCmmClosure.hs
| > | b/compiler/codeGen/StgCmmClosure.hs
| > | index 1da1f70..2501ec9 100644
| > | --- a/compiler/codeGen/StgCmmClosure.hs
| > | +++ b/compiler/codeGen/StgCmmClosure.hs
| > | @@ -361,13 +361,18 @@ type DynTag = Int       -- The tag on a
| *pointer*
| > |  isSmallFamily :: DynFlags -> Int -> Bool  isSmallFamily dflags
| > | fam_size = fam_size <= mAX_PTR_TAG dflags
| > |
| > | +-- | Faster version of isSmallFamily if you haven't computed the
| > | +size
| > | yet.
| > | +isSmallFamilyTyCon :: DynFlags -> TyCon -> Bool isSmallFamilyTyCon
| > | +dflags tycon =
| > | +  tyConFamilySizeAtMost tycon (mAX_PTR_TAG dflags)
| > | +
| > |  tagForCon :: DynFlags -> DataCon -> DynTag  tagForCon dflags con
| > | -  | isSmallFamily dflags fam_size = con_tag
| > | -  | otherwise                     = 1
| > | +  | isSmallFamilyTyCon dflags tycon = con_tag
| > | +  | otherwise                       = 1
| > |    where
| > |      con_tag  = dataConTag con -- NB: 1-indexed
| > | -    fam_size = tyConFamilySize (dataConTyCon con)
| > | +    tycon = dataConTyCon con
| > |
| > |  tagForArity :: DynFlags -> RepArity -> DynTag  tagForArity dflags
| > | arity diff --git a/compiler/types/TyCon.hs b/compiler/types/TyCon.hs
| > | index
| > | 39d2e9b..103c824 100644
| > | --- a/compiler/types/TyCon.hs
| > | +++ b/compiler/types/TyCon.hs
| > | @@ -78,7 +78,7 @@ module TyCon(
| > |          tyConDataCons, tyConDataCons_maybe,
| > |          tyConSingleDataCon_maybe, tyConSingleDataCon,
| > |          tyConSingleAlgDataCon_maybe,
| > | -        tyConFamilySize,
| > | +        tyConFamilySize, tyConFamilySizeAtMost,
| > |          tyConStupidTheta,
| > |          tyConArity,
| > |          tyConRoles,
| > | @@ -2205,6 +2205,20 @@ tyConFamilySize tc@(AlgTyCon { algTcRhs = rhs
| })
| > |        _                              -> pprPanic "tyConFamilySize 1"
| > | (ppr tc)
| > |  tyConFamilySize tc = pprPanic "tyConFamilySize 2" (ppr tc)
| > |
| > | +-- | Determine if number of value constructors a 'TyCon' has is
| > | +smaller
| > | +-- than n. Faster than tyConFamilySize tc <= n.
| > | +-- Panics if the 'TyCon' is not algebraic or a tuple
| > | +tyConFamilySizeAtMost  :: TyCon -> Int -> Bool
| > | +tyConFamilySizeAtMost tc@(AlgTyCon { algTcRhs = rhs }) n
| > | +  = case rhs of
| > | +      DataTyCon { data_cons = cons } -> lengthAtMost cons n
| > | +      NewTyCon {}                    -> 1 <= n
| > | +      TupleTyCon {}                  -> 1 <= n
| > | +      SumTyCon { data_cons = cons }  -> lengthAtMost cons n
| > | +      _                              -> pprPanic
| "tyConFamilySizeAtMost
| > | 1"
| > | +                                          (ppr tc)
| > | +tyConFamilySizeAtMost tc _ = pprPanic "tyConFamilySizeAtMost 2"
| > | +(ppr
| > | +tc)
| > | +
| > |  -- | Extract an 'AlgTyConRhs' with information about data
| > | constructors from an
| > |  -- algebraic or tuple 'TyCon'. Panics for any other sort of 'TyCon'
| > |  algTyConRhs :: TyCon -> AlgTyConRhs
| > |
| > | _______________________________________________
| > | ghc-commits mailing list
| > | ghc-commits at haskell.org
| > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail
| > | .hask
| > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| > | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C677da6a867674476306
| > | 508d5
| > | 1d869247%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63644738617631
| > | 3720&
| > | sdata=NfTqei3XryWnCiNRgOZDT6XfMRMfAST7EKFBSi%2FCXa8%3D&reserved=0

From ezyang at mit.edu  Sun Oct 29 02:47:15 2017
From: ezyang at mit.edu (Edward Z. Yang)
Date: Sat, 28 Oct 2017 22:47:15 -0400
Subject: Family instance consistency
In-Reply-To: <HE1PR83MB00422D7F00A200331F533124AD5A0@HE1PR83MB0042.EURPRD83.prod.outlook.com>
References: <HE1PR83MB00422D7F00A200331F533124AD5A0@HE1PR83MB0042.EURPRD83.prod.outlook.com>
Message-ID: <1509245225-sup-6699@sabre>

Thanks for bringing this to my attention; I'll take a look.

Excerpts from GHCindex 3a6a4070d2..0fad1da50b 100644's message of 2017-10-27 23:14:13 +0000:
> Edward
> Could you possibly take a look at #14396?   It's going to bite us soon, as Alan's Trees That Grow patch lands (see the branch mentioned on the ticket).
> (In fact, Alan, I don't know how you build that branch ; I can't build it.)
> Simon

From ggreif at gmail.com  Sun Oct 29 17:42:53 2017
From: ggreif at gmail.com (Gabor Greif)
Date: Sun, 29 Oct 2017 18:42:53 +0100
Subject: Q: Types in GADT pattern match
Message-ID: <CAK-hX0nzxiaxnCdJhoRJ74ishEK6DzDQc9rd2Fmib3Ou00K_Pw@mail.gmail.com>

Hi Devs!

I encountered a curious restriction with type signatures (tyvar bindings)
in GADT pattern matches.

GHC won't let me directly capture the refined type structure of GADT
constructors like this:


{-# Language GADTs, ScopedTypeVariables #-}

data Foo a where
  Bar :: Foo [a]

foo :: Foo a -> ()
foo b@(Bar :: Foo [a]) = quux b
  where quux :: Foo [b] -> ()
        quux Bar = ()


I get:


*test.hs:7:8: **error:*

*    • Couldn't match type ‘a1’ with ‘[a]’*

*      ‘a1’ is a rigid type variable bound by*

*        the type signature for:*

*          foo :: forall a1. Foo a1 -> ()*

*        at test.hs:6:1-18*

*      Expected type: Foo a1*

*        Actual type: Foo [a]*


To me it appears that the type refinement established by the GADT pattern
match is not accounted for.

Of course I can write:

foo :: Foo a -> ()
foo b at Bar | (c :: Foo [a]) <- b = quux c
  where quux :: Foo [b] -> ()
        quux Bar = ()

but it feels like a complicated way to do it...

My question is whether this is generally seen as the way to go or whether
ScopedTypeVariables coming from a GADT pattern match should be able to
capture the refined type. To me the latter seems more useful.

Just wanted to feel the waters before writing a ticket about this.

Cheers and thanks,

    Gabor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171029/012e0a06/attachment.html>

From oleg.grenrus at iki.fi  Sun Oct 29 20:28:30 2017
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Sun, 29 Oct 2017 22:28:30 +0200
Subject: Q: Types in GADT pattern match
In-Reply-To: <CAK-hX0nzxiaxnCdJhoRJ74ishEK6DzDQc9rd2Fmib3Ou00K_Pw@mail.gmail.com>
References: <CAK-hX0nzxiaxnCdJhoRJ74ishEK6DzDQc9rd2Fmib3Ou00K_Pw@mail.gmail.com>
Message-ID: <b9d751a8-641a-7c31-9176-060f96e603e8@iki.fi>

The problem is scoping. The problem is more obvious if you don't reuse
type-variables:

    {-# Language GADTs, ScopedTypeVariables #-}

    data Foo a where
      Bar :: Foo [x]

    foo :: Foo a -> ()
    foo b@(Bar :: Foo [c]) = quux b
      where quux :: Foo [b] -> ()
            quux Bar = ()

Then you'll get an:

   Couldn't match type ‘a’ with ‘[c]’

error.

I.e. GHC tries to match `foo`s type signatures, with annotation on
variable `b`.
But you don't need it. If you remove it, everything works fine:


    {-# Language GADTs, ScopedTypeVariables #-}

    data Foo a where
        Bar :: Foo [x]

    foo :: Foo a -> ()
    foo b at Bar = quux b
      where quux :: Foo [b] -> ()
            quux Bar = ()

Cheers, Oleg.

On 29.10.2017 19:42, Gabor Greif wrote:
> Hi Devs!
>
> I encountered a curious restriction with type signatures (tyvar
> bindings) in GADT pattern matches.
>
> GHC won't let me directly capture the refined type structure of GADT
> constructors like this:
>
>
> {-# Language GADTs, ScopedTypeVariables #-}
>
> data Foo a where
>   Bar :: Foo [a]
>
> foo :: Foo a -> ()
> foo b@(Bar :: Foo [a]) = quux b
>   where quux :: Foo [b] -> ()
>         quux Bar = ()
>
>
> I get:
>
>
> *test.hs:7:8: **error:*
>
> *    • Couldn't match type ‘a1’ with ‘[a]’*
>
> *      ‘a1’ is a rigid type variable bound by*
>
> *        the type signature for:*
>
> *          foo :: forall a1. Foo a1 -> ()*
>
> *        at test.hs:6:1-18*
>
> *      Expected type: Foo a1*
>
> *        Actual type: Foo [a]*
>
> *
> *
>
> To me it appears that the type refinement established by the GADT
> pattern match is not accounted for.
>
> Of course I can write:
>
> foo :: Foo a -> ()
> foo b at Bar | (c :: Foo [a]) <- b = quux c
>   where quux :: Foo [b] -> ()
>         quux Bar = ()
>
> but it feels like a complicated way to do it...
>
> My question is whether this is generally seen as the way to go or
> whether ScopedTypeVariables coming from a GADT pattern match should be
> able to capture the refined type. To me the latter seems more useful.
>
> Just wanted to feel the waters before writing a ticket about this.
>
> Cheers and thanks,
>
>     Gabor
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171029/ba0258d8/attachment.sig>

From david.feuer at gmail.com  Sun Oct 29 20:40:53 2017
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 29 Oct 2017 16:40:53 -0400
Subject: Bringing some observable sharing to GHCi
Message-ID: <CAMgWh9vJ7wF33pw94WGkwGA8yfHOG9FqtgqJv7vj-8cnbcdvjw@mail.gmail.com>

The :sprint, :print, and :force commands in GHCi fall into infinite
loops when confronted by cyclical data. This bit me hard in
https://phabricator.haskell.org/D4085 because that produces cyclical
TypeReps, which is trouble for (e.g.) the test break011 which tries to
:force a SomeException (which wraps an Exception dictionary, which has
a Typeable constraint). I could try coming up with a fix myself, but
I'm rather curious whether some of the work you (or others) have
already done on observing GHC data graphs could be yanked into GHCi
itself for this purpose. We want

1. To be able to display cyclical data in some sensible way.

> x = "hi" : x
> x `seq` ()
> :print x

should print some useful representation of x.

2. To be able to force cyclical data without looping.

> x = "hi" : x
> :force x

should print a useful representation of x.

From sgraf1337 at gmail.com  Sun Oct 29 21:06:49 2017
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Sun, 29 Oct 2017 22:06:49 +0100
Subject: When does GHC produce unlifted `let` bindings?
Message-ID: <CAAS+=P9GBgpeE5X4p0SQO47_NKuFgLnXeXa0MHGYshic38jwZA@mail.gmail.com>

Hi folks,

I was debugging a Core-to-Core transform for TEST=spec-inline
<https://github.com/ghc/ghc/blob/fe04f3783b662c52c4a0ff36b2d62a7a575998a5/testsuite/tests/simplCore/should_compile/spec-inline.hs>
and
was wondering (yet again) why GHC produces unlifted `let` bindings in Core
like it seems supposed to be doing
<https://github.com/ghc/ghc/blob/fe04f3783b662c52c4a0ff36b2d62a7a575998a5/testsuite/tests/simplCore/should_compile/spec-inline.stderr#L68-L76>
.

   - Why doesn't this use `case` instead?
   - Is there a semantic difference?
   - Can `case` be used with unlifted types?
   - And if not, why can `let`?

Unlifted `let` seems much close to `case` than to `let`. Some GHC passes
seem to agree.
<https://github.com/ghc/ghc/search?l=Haskell&q=%22strict+let%22&type=&utf8=%E2%9C%93>

Cheers,
Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171029/bcf22388/attachment.html>

From mail at joachim-breitner.de  Sun Oct 29 22:10:58 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 29 Oct 2017 18:10:58 -0400
Subject: Bringing some observable sharing to GHCi
In-Reply-To: <CAMgWh9vJ7wF33pw94WGkwGA8yfHOG9FqtgqJv7vj-8cnbcdvjw@mail.gmail.com>
References: <CAMgWh9vJ7wF33pw94WGkwGA8yfHOG9FqtgqJv7vj-8cnbcdvjw@mail.gmail.com>
Message-ID: <1509315058.9503.3.camel@joachim-breitner.de>

Hi,



Am Sonntag, den 29.10.2017, 16:40 -0400 schrieb David Feuer:
> 1. To be able to display cyclical data in some sensible way.
> 
> > x = "hi" : x
> > x `seq` ()
> > :print x
> 
> should print some useful representation of x.

the best that I know for this is the hack that calls itself ghc-heap-
view:

~ $ cabal install ghc-heap-view 
~ $ ghci
GHCi, version 8.0.2: http://www.haskell.org/ghc/  :? for help
Prelude> :script .cabal/share/x86_64-linux-ghc-8.0.2/ghc-heap-view-0.5.10/ghci
Prelude> x = "hi" : x
Prelude> take 2 x
["hi","hi"]
Prelude> :printHeap x
let x1 = _bh (C# 'h' : _bh (C# 'i' : _bh [])) : _bh x1
in x1
Prelude> System.Mem.performGC
Prelude> :printHeap x
let x1 = "hi" : x1
in x1

A graphical front-end is ghc-vis:
http://felsin9.de/nnis/ghc-vis/

But it is mostly a hack and you should not expect a lot of reliability
of it. I’d love to see it supported by GHC proper. Erik de Castro Lopo
tried to merge it into GHC, but it seems to be very hard.

> 2. To be able to force cyclical data without looping.
> 
> > x = "hi" : x
> > :force x
> 

That could be implemented on top of ghc-heap-view.

Greetings,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171029/a7d8e53f/attachment-0001.sig>

From sgraf1337 at gmail.com  Sun Oct 29 22:58:15 2017
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Sun, 29 Oct 2017 23:58:15 +0100
Subject: perf.haskell.org functional again
In-Reply-To: <C206E644-6731-423B-8928-7B086ECF3C17@justtesting.org>
References: <2C073EBF-8019-4734-9617-BE9A577EEEA9@joachim-breitner.de>
 <C4A2809F-E388-4CD5-A908-D6CCD11F97DB@justtesting.org>
 <1508816773.31327.5.camel@joachim-breitner.de>
 <C206E644-6731-423B-8928-7B086ECF3C17@justtesting.org>
Message-ID: <CAAS+=P_2dO+AZBLxE69Z=O21rLOCxxTNJxKFnshXmd2qXE5kLw@mail.gmail.com>

Hi,

just wanted to throw in the idea of parallelising the benchmark suite
(hurts to even write that, but cachegrind) to speed up the build, if ever
need be.

Cheers,
Sebastian

On Wed, Oct 25, 2017 at 2:13 AM, Manuel M T Chakravarty <
chak at justtesting.org> wrote:

> Am 24.10.2017 um 14:46 schrieb Joachim Breitner <mail at joachim-breitner.de
> >:
>
> Is CircleCI the future now?
>
>
> Yes, as per
>
>   https://ghc.haskell.org/trac/ghc/wiki/ContinuousIntegration
>
> In general, yes. But it’s running fine for now, so I would not
> prematurely throw it over.
>
> My requirements are:
>
> * needs to run on every commit (not just every push), including
>   branches.
> * needs to be able to push to a repository¹, so it needs access to
>   some secret token for depolyment.
>   Alternatively, the CI could simply keep track of the build log
>   and the perf.haskell.org dashboard scrapes it from there.
> * Occasionally, I find that I want to rebuild a fair number of commits
>   that are already in the repository. So a good way to trigger
>   rebuilds would be nice.
>
>
> No need to mess with a working system, but as long as performance counters
> are the basis, I think, these constraints can all be met. In particular,
> CircleCI has facilities to allow deployments including managing of secrets.
> (That is a pretty common requirements for CIs.)
>
> Cheers,
> Manuel
>
>
> Greetings,
> Joachim
>
> ¹ https://github.com/nomeata/ghc-speed-logs/commits/master
>
> Am Dienstag, den 24.10.2017, 12:18 +1100 schrieb Manuel M T
> Chakravarty:
>
> Hi Joachim,
>
> Great! Just because you mention CI infrastructure and our effort around
> GHC CI at the moment, do you think, it would make sense to move this to
> CircleCI eventually?
>
> Cheers,
> Manuel
>
> Am 24.10.2017 um 11:02 schrieb Joachim Breitner <mail at joachim-breitner.de
> >:
>
> Hi,
>
> after a system upgrade to avoid weird linker errors, and after some fixes
> in the nofib submodule, http://perf.haskell.org/ghc is running again.
>
> I am collecting instruction counts instead of runtime, because the latter
> was just too often varying too wildly. I hope this will yield less false
> alarms.
>
> I am also running nofib with mode=fast. This way, building GHC, running
> the testsuite and nofib takes a bit over one hour. I hope this can keep up
> with y'all's commits (when it took 2h it couldn't).
>
> Now nothing of the setup requires a quiet dedicated machine, so if there
> is a need, we could move these builds into the cloud or into some CI
> infrastructure - but no changes are immediately planned.
>
> Enjoy, Joachim
>
> --
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171029/854e7690/attachment.html>

From mail at joachim-breitner.de  Sun Oct 29 23:13:53 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 29 Oct 2017 19:13:53 -0400
Subject: perf.haskell.org functional again
In-Reply-To: <CAAS+=P_2dO+AZBLxE69Z=O21rLOCxxTNJxKFnshXmd2qXE5kLw@mail.gmail.com>
References: <2C073EBF-8019-4734-9617-BE9A577EEEA9@joachim-breitner.de>
 <C4A2809F-E388-4CD5-A908-D6CCD11F97DB@justtesting.org>
 <1508816773.31327.5.camel@joachim-breitner.de>
 <C206E644-6731-423B-8928-7B086ECF3C17@justtesting.org>
 <CAAS+=P_2dO+AZBLxE69Z=O21rLOCxxTNJxKFnshXmd2qXE5kLw@mail.gmail.com>
Message-ID: <1509318833.9503.4.camel@joachim-breitner.de>

Hi,

Am Sonntag, den 29.10.2017, 23:58 +0100 schrieb Sebastian Graf:
> Hi,
> 
> just wanted to throw in the idea of parallelising the benchmark suite
> (hurts to even write that, but cachegrind) to speed up the build, if
> ever need be.

https://github.com/nomeata/gipeda/blob/master/ghc/run-speed.sh#L143

good idea indeed – I’ve been doing that since I started running
cachegrind ;-)


Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171029/b40394b0/attachment-0001.sig>

From rae at cs.brynmawr.edu  Sun Oct 29 23:32:17 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sun, 29 Oct 2017 19:32:17 -0400
Subject: Q: Types in GADT pattern match
In-Reply-To: <CAK-hX0nzxiaxnCdJhoRJ74ishEK6DzDQc9rd2Fmib3Ou00K_Pw@mail.gmail.com>
References: <CAK-hX0nzxiaxnCdJhoRJ74ishEK6DzDQc9rd2Fmib3Ou00K_Pw@mail.gmail.com>
Message-ID: <374C13C0-1247-411E-AEBC-3F402B5E81FD@cs.brynmawr.edu>

Hi Gabor,

Oleg is right that the re-use of type variables obscures the error, but it's not quite a scoping error under the hood. The problem is that GHC type-checks type signatures on patterns *before* type-checking the pattern itself. That means that when GHC checks your `Foo [a]` type signature, we haven't yet learned that `a1` (the type variable used in the type signature of foo) equals `[a]`. This makes it hard to bind a variable to `a`. Here's what I've done:

> foo :: Foo a -> ()
> foo b at Bar = case b of
>   (_ :: Foo [c]) -> quux b
>     where
>       quux :: Foo [c] -> ()
>       quux Bar = ()

It's gross, but it works, and I don't think there's a better way at the moment. A collaborator of mine is working on a proposal (and implementation) of binding existentials in patterns (using similar syntax to visible type application), but that's still a few months off, at best.

Richard

> On Oct 29, 2017, at 1:42 PM, Gabor Greif <ggreif at gmail.com> wrote:
> 
> Hi Devs!
> 
> I encountered a curious restriction with type signatures (tyvar bindings) in GADT pattern matches.
> 
> GHC won't let me directly capture the refined type structure of GADT constructors like this:
> 
> 
> {-# Language GADTs, ScopedTypeVariables #-}
> 
> data Foo a where
>   Bar :: Foo [a]
> 
> foo :: Foo a -> ()
> foo b@(Bar :: Foo [a]) = quux b
>   where quux :: Foo [b] -> ()
>         quux Bar = ()
> 
> 
> I get:
> 
> 
> test.hs:7:8: error:
>     • Couldn't match type ‘a1’ with ‘[a]’
>       ‘a1’ is a rigid type variable bound by
>         the type signature for:
>           foo :: forall a1. Foo a1 -> ()
>         at test.hs:6:1-18
>       Expected type: Foo a1
>         Actual type: Foo [a]
> 
> 
> To me it appears that the type refinement established by the GADT pattern match is not accounted for.
> 
> Of course I can write:
> 
> foo :: Foo a -> ()
> foo b at Bar | (c :: Foo [a]) <- b = quux c
>   where quux :: Foo [b] -> ()
>         quux Bar = ()
> 
> but it feels like a complicated way to do it...
> 
> My question is whether this is generally seen as the way to go or whether ScopedTypeVariables coming from a GADT pattern match should be able to capture the refined type. To me the latter seems more useful.
> 
> Just wanted to feel the waters before writing a ticket about this.
> 
> Cheers and thanks,
> 
>     Gabor
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171029/6a41f081/attachment.html>

From ben at smart-cactus.org  Mon Oct 30 04:55:52 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 30 Oct 2017 00:55:52 -0400
Subject: When does GHC produce unlifted `let` bindings?
In-Reply-To: <CAAS+=P9GBgpeE5X4p0SQO47_NKuFgLnXeXa0MHGYshic38jwZA@mail.gmail.com>
References: <CAAS+=P9GBgpeE5X4p0SQO47_NKuFgLnXeXa0MHGYshic38jwZA@mail.gmail.com>
Message-ID: <87inexw7xj.fsf@ben-laptop.smart-cactus.org>



Sebastian Graf <sgraf1337 at gmail.com> writes:

> Hi folks,
>
> I was debugging a Core-to-Core transform for TEST=spec-inline
> <https://github.com/ghc/ghc/blob/fe04f3783b662c52c4a0ff36b2d62a7a575998a5/testsuite/tests/simplCore/should_compile/spec-inline.hs>
> and
> was wondering (yet again) why GHC produces unlifted `let` bindings in Core
> like it seems supposed to be doing
> <https://github.com/ghc/ghc/blob/fe04f3783b662c52c4a0ff36b2d62a7a575998a5/testsuite/tests/simplCore/should_compile/spec-inline.stderr#L68-L76>
> .
>
>    - Why doesn't this use `case` instead?
>    - Is there a semantic difference?

My understanding is that we use `case` in this case since there is no
thunk evaluation necessary. Recall that operationally (under STG) `case`
is what drives evaluation whereas `let` is simply allocation. In a
sense, bringing an unlifted binding into scope is closer to the latter
than the former, being a simple register assignment.

>    - Can `case` be used with unlifted types?

I'm honestly not sure what would happen in this case. It may work fine
or something may explode. I suspect CoreToStg will lower a case with an
unlifted scrutinee to a let, but perhaps not. If not then things likely
will blow up since, according to Note [Types in StgConApp], unlifted
values can't be let-bound in STG.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171030/f6d35a77/attachment.sig>

From ggreif at gmail.com  Mon Oct 30 09:14:49 2017
From: ggreif at gmail.com (Gabor Greif)
Date: Mon, 30 Oct 2017 10:14:49 +0100
Subject: Q: Types in GADT pattern match
In-Reply-To: <374C13C0-1247-411E-AEBC-3F402B5E81FD@cs.brynmawr.edu>
References: <CAK-hX0nzxiaxnCdJhoRJ74ishEK6DzDQc9rd2Fmib3Ou00K_Pw@mail.gmail.com>
 <374C13C0-1247-411E-AEBC-3F402B5E81FD@cs.brynmawr.edu>
Message-ID: <CAK-hX0=-Da612n9djZZcy5NOXsVNyJCsjGLXGxVzmmcbTF7Fng@mail.gmail.com>

Hi Oleg, Richard,

thanks for your answers! Seems like my original diagnosis is correct and
GADT type refinement is done *after* the checking of the pattern type signature.

My workaround

  >  foo b at Bar | (c :: Foo [x]) <- b = ... @x ...

works perfectly well and is essentially the same what Richard
suggests, while being
a little less gross.

My original question, though, is not answered yet, namely why not to
detect that we are about to pattern match on a GADT constructor and
allow the programmer to capture the *refined* type with her type
annotation. Sure this would necessitate a change to the type checker,
but would also increase the expressive power a bit.

Is there some fundamental problem with this? Or simply nobody wanted
to do this yet? Would it be hard to implement type checking *after*
refinement on GADT(-like) patterns?

Cheers and thanks,

    Gabor


On 10/30/17, Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
> Hi Gabor,
>
> Oleg is right that the re-use of type variables obscures the error, but it's
> not quite a scoping error under the hood. The problem is that GHC
> type-checks type signatures on patterns *before* type-checking the pattern
> itself. That means that when GHC checks your `Foo [a]` type signature, we
> haven't yet learned that `a1` (the type variable used in the type signature
> of foo) equals `[a]`. This makes it hard to bind a variable to `a`. Here's
> what I've done:
>
>> foo :: Foo a -> ()
>> foo b at Bar = case b of
>>   (_ :: Foo [c]) -> quux b
>>     where
>>       quux :: Foo [c] -> ()
>>       quux Bar = ()
>
> It's gross, but it works, and I don't think there's a better way at the
> moment. A collaborator of mine is working on a proposal (and implementation)
> of binding existentials in patterns (using similar syntax to visible type
> application), but that's still a few months off, at best.
>
> Richard
>
>> On Oct 29, 2017, at 1:42 PM, Gabor Greif <ggreif at gmail.com> wrote:
>>
>> Hi Devs!
>>
>> I encountered a curious restriction with type signatures (tyvar bindings)
>> in GADT pattern matches.
>>
>> GHC won't let me directly capture the refined type structure of GADT
>> constructors like this:
>>
>>
>> {-# Language GADTs, ScopedTypeVariables #-}
>>
>> data Foo a where
>>   Bar :: Foo [a]
>>
>> foo :: Foo a -> ()
>> foo b@(Bar :: Foo [a]) = quux b
>>   where quux :: Foo [b] -> ()
>>         quux Bar = ()
>>
>>
>> I get:
>>
>>
>> test.hs:7:8: error:
>>     • Couldn't match type ‘a1’ with ‘[a]’
>>       ‘a1’ is a rigid type variable bound by
>>         the type signature for:
>>           foo :: forall a1. Foo a1 -> ()
>>         at test.hs:6:1-18
>>       Expected type: Foo a1
>>         Actual type: Foo [a]
>>
>>
>> To me it appears that the type refinement established by the GADT pattern
>> match is not accounted for.
>>
>> Of course I can write:
>>
>> foo :: Foo a -> ()
>> foo b at Bar | (c :: Foo [a]) <- b = quux c
>>   where quux :: Foo [b] -> ()
>>         quux Bar = ()
>>
>> but it feels like a complicated way to do it...
>>
>> My question is whether this is generally seen as the way to go or whether
>> ScopedTypeVariables coming from a GADT pattern match should be able to
>> capture the refined type. To me the latter seems more useful.
>>
>> Just wanted to feel the waters before writing a ticket about this.
>>
>> Cheers and thanks,
>>
>>     Gabor
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>

From simonpj at microsoft.com  Mon Oct 30 09:56:01 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 30 Oct 2017 09:56:01 +0000
Subject: When does GHC produce unlifted `let` bindings?
In-Reply-To: <CAAS+=P9GBgpeE5X4p0SQO47_NKuFgLnXeXa0MHGYshic38jwZA@mail.gmail.com>
References: <CAAS+=P9GBgpeE5X4p0SQO47_NKuFgLnXeXa0MHGYshic38jwZA@mail.gmail.com>
Message-ID: <AM4PR83MB0033F806C3BF64E43E608D98AD590@AM4PR83MB0033.EURPRD83.prod.outlook.com>

See Note [CoreSyn let/app invariant] in CoreSyn.

Briefly, you can write
            let x::Int# = e in …
if e is “ok-for-speculation”.  See extensive comments in CoreUtils on what that means.

You could also use case, but let-bindings “float” more easily than cases, because they are not worried about preserving exception behaviour.

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Sebastian Graf
Sent: 29 October 2017 21:07
To: ghc-devs <ghc-devs at haskell.org>
Subject: When does GHC produce unlifted `let` bindings?

Hi folks,

I was debugging a Core-to-Core transform for TEST=spec-inline<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc%2Fghc%2Fblob%2Ffe04f3783b662c52c4a0ff36b2d62a7a575998a5%2Ftestsuite%2Ftests%2FsimplCore%2Fshould_compile%2Fspec-inline.hs&data=02%7C01%7Csimonpj%40microsoft.com%7C77699e26801a4d458b9a08d51f11085f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636449080385955811&sdata=t%2BAXQszqKfFRYNjjLJtMHpLsS2RzwTaBFA42JuLBN4o%3D&reserved=0> and was wondering (yet again) why GHC produces unlifted `let` bindings in Core like it seems supposed to be doing<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc%2Fghc%2Fblob%2Ffe04f3783b662c52c4a0ff36b2d62a7a575998a5%2Ftestsuite%2Ftests%2FsimplCore%2Fshould_compile%2Fspec-inline.stderr%23L68-L76&data=02%7C01%7Csimonpj%40microsoft.com%7C77699e26801a4d458b9a08d51f11085f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636449080385955811&sdata=pVNrzDY%2ByfK%2FVl%2Fk8B5P0HuGC6PG5kD7mHiwa0Vck9o%3D&reserved=0>.

  *   Why doesn't this use `case` instead?
  *   Is there a semantic difference?
  *   Can `case` be used with unlifted types?
  *   And if not, why can `let`?
Unlifted `let` seems much close to `case` than to `let`. Some GHC passes seem to agree.<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc%2Fghc%2Fsearch%3Fl%3DHaskell%26q%3D%2522strict%2Blet%2522%26type%3D%26utf8%3D%25E2%259C%2593&data=02%7C01%7Csimonpj%40microsoft.com%7C77699e26801a4d458b9a08d51f11085f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636449080385955811&sdata=ksdZGbGyw6%2FLEIMiJpCaHlDh4iipdkKcSCEDdTySExk%3D&reserved=0>

Cheers,
Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171030/6026fcb9/attachment-0001.html>

From simonpj at microsoft.com  Mon Oct 30 10:04:24 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 30 Oct 2017 10:04:24 +0000
Subject: Types in GADT pattern match
In-Reply-To: <CAK-hX0nzxiaxnCdJhoRJ74ishEK6DzDQc9rd2Fmib3Ou00K_Pw@mail.gmail.com>
References: <CAK-hX0nzxiaxnCdJhoRJ74ishEK6DzDQc9rd2Fmib3Ou00K_Pw@mail.gmail.com>
Message-ID: <AM4PR83MB0033E893EB605F50ED560B17AD590@AM4PR83MB0033.EURPRD83.prod.outlook.com>

foo b@(Bar :: Foo [a]) = quux b
The pattern (p :: ty) checks that the thing being matched has type ‘ty’ and THEN matches ‘p’.  You expected it to FIRST match ‘p’, and THEN check that the thing being matched has type ‘ty’.  But that’s not the way it works.

e.g what about this

            rats ([Just (Bar, True)] :: [Maybe (Foo [a], Bool)]) = …

Here the pattern to be matched is deep, with the Bar part deep inside.  Do you still expect it to work?

This would be hard to change.  And I’m not sure it’d be an improvement.

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Gabor Greif
Sent: 29 October 2017 17:43
To: ghc-devs <ghc-devs at haskell.org>
Subject: Q: Types in GADT pattern match

Hi Devs!

I encountered a curious restriction with type signatures (tyvar bindings) in GADT pattern matches.

GHC won't let me directly capture the refined type structure of GADT constructors like this:


{-# Language GADTs, ScopedTypeVariables #-}

data Foo a where
  Bar :: Foo [a]

foo :: Foo a -> ()
foo b@(Bar :: Foo [a]) = quux b
  where quux :: Foo [b] -> ()
        quux Bar = ()


I get:



test.hs:7:8: error:

    • Couldn't match type ‘a1’ with ‘[a]’

      ‘a1’ is a rigid type variable bound by

        the type signature for:

          foo :: forall a1. Foo a1 -> ()

        at test.hs:6:1-18

      Expected type: Foo a1

        Actual type: Foo [a]


To me it appears that the type refinement established by the GADT pattern match is not accounted for.

Of course I can write:

foo :: Foo a -> ()
foo b at Bar | (c :: Foo [a]) <- b = quux c
  where quux :: Foo [b] -> ()
        quux Bar = ()

but it feels like a complicated way to do it...

My question is whether this is generally seen as the way to go or whether ScopedTypeVariables coming from a GADT pattern match should be able to capture the refined type. To me the latter seems more useful.

Just wanted to feel the waters before writing a ticket about this.

Cheers and thanks,

    Gabor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171030/c0fcdc98/attachment.html>

From allbery.b at gmail.com  Mon Oct 30 12:12:40 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 30 Oct 2017 08:12:40 -0400
Subject: Q: Types in GADT pattern match
In-Reply-To: <CAK-hX0=-Da612n9djZZcy5NOXsVNyJCsjGLXGxVzmmcbTF7Fng@mail.gmail.com>
References: <CAK-hX0nzxiaxnCdJhoRJ74ishEK6DzDQc9rd2Fmib3Ou00K_Pw@mail.gmail.com>
 <374C13C0-1247-411E-AEBC-3F402B5E81FD@cs.brynmawr.edu>
 <CAK-hX0=-Da612n9djZZcy5NOXsVNyJCsjGLXGxVzmmcbTF7Fng@mail.gmail.com>
Message-ID: <CAKFCL4UDAqWq-yDOdD+x3dUZ6=mSpk9-9ZaNp+ty66FP1UFKtQ@mail.gmail.com>

On Mon, Oct 30, 2017 at 5:14 AM, Gabor Greif <ggreif at gmail.com> wrote:

> My original question, though, is not answered yet, namely why not to
> detect that we are about to pattern match on a GADT constructor and
> allow the programmer to capture the *refined* type with her type
> annotation. Sure this would necessitate a change to the type checker,
> but would also increase the expressive power a bit.
>
> Is there some fundamental problem with this? Or simply nobody wanted
> to do this yet? Would it be hard to implement type checking *after*
> refinement on GADT(-like) patterns?
>

I wouldn't be surprised if type checking is precisely what enables
refinement, making this a bit chicken-and-egg.

-- 
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://mail.haskell.org/pipermail/ghc-devs/attachments/20171030/49622156/attachment-0001.html>

From kiss.csongor.kiss at gmail.com  Mon Oct 30 12:39:39 2017
From: kiss.csongor.kiss at gmail.com (Csongor Kiss)
Date: Mon, 30 Oct 2017 12:39:39 +0000
Subject: Q: Types in GADT pattern match
In-Reply-To: <CAKFCL4UDAqWq-yDOdD+x3dUZ6=mSpk9-9ZaNp+ty66FP1UFKtQ@mail.gmail.com>
References: <CAK-hX0nzxiaxnCdJhoRJ74ishEK6DzDQc9rd2Fmib3Ou00K_Pw@mail.gmail.com>
 <374C13C0-1247-411E-AEBC-3F402B5E81FD@cs.brynmawr.edu>
 <CAK-hX0=-Da612n9djZZcy5NOXsVNyJCsjGLXGxVzmmcbTF7Fng@mail.gmail.com>
 <CAKFCL4UDAqWq-yDOdD+x3dUZ6=mSpk9-9ZaNp+ty66FP1UFKtQ@mail.gmail.com>
Message-ID: <96f89c95-61f5-43d1-8f1d-ee47e3c0fbea@Spark>

Right, but I think Gabor's suggestion here is for type checking of the pattern to be done first, and then capturing the coercions
that were brought into scope by the pattern match.

data Foo a where
  Bar :: Foo [a]

foo :: Foo a -> ()
foo Bar = <body> -- we know (a ~ [b]) here, for some b

The pattern match on Bar in foo gives us the equality assumption on the right hand side, but
we don't have an easy way of capturing 'b' - which we might want to do for, say, visible type application inside <body>.

foo' :: Foo a -> ()
foo' (Bar :: Foo a) = <body>

of course works, but it only gives us access to 'a' in <body>.

foo'' :: Foo a -> ()
foo'' (Bar :: Foo [c]) = <body>

This would mean that in addition to (a ~ [b]), for some b, we would get (a ~ [c]), for our new c. This then gives (b ~ c),
essentially giving us access to the existential b. Of course we would need to check that our scoped type signature
doesn't introduce bogus coercions, like

foo''' :: Foo a -> ()
foo''' (Bar :: Foo [[c]]) = <body>

is clearly invalid, because (a ~ [b]) and (a ~ [[c]]) would need (b ~ [c]), which we can't prove from the given assumptions.


Cheers,
Csongor

On 30 Oct 2017, 12:13 +0000, Brandon Allbery <allbery.b at gmail.com>, wrote:
> > On Mon, Oct 30, 2017 at 5:14 AM, Gabor Greif <ggreif at gmail.com> wrote:
> > > My original question, though, is not answered yet, namely why not to
> > > detect that we are about to pattern match on a GADT constructor and
> > > allow the programmer to capture the *refined* type with her type
> > > annotation. Sure this would necessitate a change to the type checker,
> > > but would also increase the expressive power a bit.
> > >
> > > Is there some fundamental problem with this? Or simply nobody wanted
> > > to do this yet? Would it be hard to implement type checking *after*
> > > refinement on GADT(-like) patterns?
>
> I wouldn't be surprised if type checking is precisely what enables refinement, making this a bit chicken-and-egg.
>
> --
> 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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171030/5184d07a/attachment.html>

From simonpj at microsoft.com  Mon Oct 30 17:13:14 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 30 Oct 2017 17:13:14 +0000
Subject: FW: How does GHC's testsuite work?
In-Reply-To: <20171030151738.tcn7d2gjgz3bkhcp@pl-59055.rocqadm.inria.fr>
References: <20171030151738.tcn7d2gjgz3bkhcp@pl-59055.rocqadm.inria.fr>
Message-ID: <AM4PR83MB0033323DB2558D6736FBA256AD590@AM4PR83MB0033.EURPRD83.prod.outlook.com>

Forwarding to ghc-devs, a better list for this question.

Simon 

-----Original Message-----
From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Sébastien Hinderer
Sent: 30 October 2017 15:18
To: glasgow-haskell-users at haskell.org
Subject: How does GHC's testsuite work?

Dear all,

I am a member of OCaml's developement team. More specifically, I am working on a test-driver for the OCaml compiler, which will be part of OCaml's 4.06 release.

I am currently writing an article to describe the tool and its principles. In this article, I would like to also talk about how other compilers' testsuites are handled and loking how things are done in GHC is natural.

In OCaml, our testsuite essentially consist in whole programs that we compile and run, checking that the compilation and execution results match the expected ones.

From what I could see from GHC's testsuite, it seemed to me that it uses Python to drive the tests. I also understood that the testsuite has tests that are more kind of unit-tests, in the .T file. Am I correct here? Or do you guys also have whole program tests?
If you do, how do you compile and run them?

Any comment / hint on this aspect of the test harness' design would be really helpful.

Many thanks in advance,

Sébastien.





_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users at haskell.org
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users&data=02%7C01%7Csimonpj%40microsoft.com%7C293aac933ae143b8690308d51fa9681f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636449734850370955&sdata=SY4ABziBhV4MxLwTpJ5bFyS8GJfHLL%2FZrTxQc90EGDs%3D&reserved=0

From ggreif at gmail.com  Mon Oct 30 20:52:27 2017
From: ggreif at gmail.com (Gabor Greif)
Date: Mon, 30 Oct 2017 21:52:27 +0100
Subject: Types in GADT pattern match
In-Reply-To: <AM4PR83MB0033E893EB605F50ED560B17AD590@AM4PR83MB0033.EURPRD83.prod.outlook.com>
References: <CAK-hX0nzxiaxnCdJhoRJ74ishEK6DzDQc9rd2Fmib3Ou00K_Pw@mail.gmail.com>
 <AM4PR83MB0033E893EB605F50ED560B17AD590@AM4PR83MB0033.EURPRD83.prod.outlook.com>
Message-ID: <CAK-hX0=KeZtr=LJiZDBMZtim58J=7aV4=Bs-i0Oc6CqzNJYk=w@mail.gmail.com>

On 10/30/17, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> foo b@(Bar :: Foo [a]) = quux b
> The pattern (p :: ty) checks that the thing being matched has type ‘ty’ and
> THEN matches ‘p’.  You expected it to FIRST match ‘p’, and THEN check that
> the thing being matched has type ‘ty’.  But that’s not the way it works.

Yep. Understood. I was just hoping that one could annotate the
"insider view" of GADT pattern matches (considering the equality
constraints of the constructor) as well as the "outsider view", namely
'foo's external signature.

>
> e.g what about this
>
>             rats ([Just (Bar, True)] :: [Maybe (Foo [a], Bool)]) = …
>
> Here the pattern to be matched is deep, with the Bar part deep inside.  Do
> you still expect it to work?

Well, it reflects a truth, so I'd expect it to work, yes :-)

>
> This would be hard to change.  And I’m not sure it’d be an improvement.

Hmmm, sure. There are probably better areas to invest effort into.

Thanks,

    Gabor

>
> Simon
>
> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Gabor
> Greif
> Sent: 29 October 2017 17:43
> To: ghc-devs <ghc-devs at haskell.org>
> Subject: Q: Types in GADT pattern match
>
> Hi Devs!
>
> I encountered a curious restriction with type signatures (tyvar bindings) in
> GADT pattern matches.
>
> GHC won't let me directly capture the refined type structure of GADT
> constructors like this:
>
>
> {-# Language GADTs, ScopedTypeVariables #-}
>
> data Foo a where
>   Bar :: Foo [a]
>
> foo :: Foo a -> ()
> foo b@(Bar :: Foo [a]) = quux b
>   where quux :: Foo [b] -> ()
>         quux Bar = ()
>
>
> I get:
>
>
>
> test.hs:7:8: error:
>
>     • Couldn't match type ‘a1’ with ‘[a]’
>
>       ‘a1’ is a rigid type variable bound by
>
>         the type signature for:
>
>           foo :: forall a1. Foo a1 -> ()
>
>         at test.hs:6:1-18
>
>       Expected type: Foo a1
>
>         Actual type: Foo [a]
>
>
> To me it appears that the type refinement established by the GADT pattern
> match is not accounted for.
>
> Of course I can write:
>
> foo :: Foo a -> ()
> foo b at Bar | (c :: Foo [a]) <- b = quux c
>   where quux :: Foo [b] -> ()
>         quux Bar = ()
>
> but it feels like a complicated way to do it...
>
> My question is whether this is generally seen as the way to go or whether
> ScopedTypeVariables coming from a GADT pattern match should be able to
> capture the refined type. To me the latter seems more useful.
>
> Just wanted to feel the waters before writing a ticket about this.
>
> Cheers and thanks,
>
>     Gabor
>

From ggreif at gmail.com  Mon Oct 30 20:58:25 2017
From: ggreif at gmail.com (Gabor Greif)
Date: Mon, 30 Oct 2017 21:58:25 +0100
Subject: Q: Types in GADT pattern match
In-Reply-To: <96f89c95-61f5-43d1-8f1d-ee47e3c0fbea@Spark>
References: <CAK-hX0nzxiaxnCdJhoRJ74ishEK6DzDQc9rd2Fmib3Ou00K_Pw@mail.gmail.com>
 <374C13C0-1247-411E-AEBC-3F402B5E81FD@cs.brynmawr.edu>
 <CAK-hX0=-Da612n9djZZcy5NOXsVNyJCsjGLXGxVzmmcbTF7Fng@mail.gmail.com>
 <CAKFCL4UDAqWq-yDOdD+x3dUZ6=mSpk9-9ZaNp+ty66FP1UFKtQ@mail.gmail.com>
 <96f89c95-61f5-43d1-8f1d-ee47e3c0fbea@Spark>
Message-ID: <CAK-hX0mE97rT4uN_z0z9M=kufSDfaYSQaANfhzCs1qMr3rt8rQ@mail.gmail.com>

On 10/30/17, Csongor Kiss <kiss.csongor.kiss at gmail.com> wrote:
> Right, but I think Gabor's suggestion here is for type checking of the
> pattern to be done first, and then capturing the coercions
> that were brought into scope by the pattern match.
>
> data Foo a where
>   Bar :: Foo [a]
>
> foo :: Foo a -> ()
> foo Bar = <body> -- we know (a ~ [b]) here, for some b
>
> The pattern match on Bar in foo gives us the equality assumption on the
> right hand side, but
> we don't have an easy way of capturing 'b' - which we might want to do for,
> say, visible type application inside <body>.


Yep. Visible type application on the RHS is what I am after. It is
just user-unfriendly that one has to doubly pattern match on the same
object in order to bring the GADT constructor's type equality into
play.

Thanks Csongor for the expanded reasoning!

    Gabor


>
> foo' :: Foo a -> ()
> foo' (Bar :: Foo a) = <body>
>
> of course works, but it only gives us access to 'a' in <body>.
>
> foo'' :: Foo a -> ()
> foo'' (Bar :: Foo [c]) = <body>
>
> This would mean that in addition to (a ~ [b]), for some b, we would get (a ~
> [c]), for our new c. This then gives (b ~ c),
> essentially giving us access to the existential b. Of course we would need
> to check that our scoped type signature
> doesn't introduce bogus coercions, like
>
> foo''' :: Foo a -> ()
> foo''' (Bar :: Foo [[c]]) = <body>
>
> is clearly invalid, because (a ~ [b]) and (a ~ [[c]]) would need (b ~ [c]),
> which we can't prove from the given assumptions.
>
>
> Cheers,
> Csongor
>
> On 30 Oct 2017, 12:13 +0000, Brandon Allbery <allbery.b at gmail.com>, wrote:
>> > On Mon, Oct 30, 2017 at 5:14 AM, Gabor Greif <ggreif at gmail.com> wrote:
>> > > My original question, though, is not answered yet, namely why not to
>> > > detect that we are about to pattern match on a GADT constructor and
>> > > allow the programmer to capture the *refined* type with her type
>> > > annotation. Sure this would necessitate a change to the type checker,
>> > > but would also increase the expressive power a bit.
>> > >
>> > > Is there some fundamental problem with this? Or simply nobody wanted
>> > > to do this yet? Would it be hard to implement type checking *after*
>> > > refinement on GADT(-like) patterns?
>>
>> I wouldn't be surprised if type checking is precisely what enables
>> refinement, making this a bit chicken-and-egg.
>>
>> --
>> 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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From david at well-typed.com  Tue Oct 31 15:42:11 2017
From: david at well-typed.com (David Feuer)
Date: Tue, 31 Oct 2017 11:42:11 -0400
Subject: GHCi recompilation avoidance UI
Message-ID: <7587879.l535S4SiGz@squirrel>

Changes in GHC 8.2.1 lead to a lot of recompilation, because GHCi now refuses to load optimized
code unless -fobject-code (and optimization flags) are enabled. I propose the following slight
modification to https://ghc.haskell.org/trac/ghc/ticket/13604#comment:48

1. Optimization flags (except -O0) imply -fobject-code. This ensures that GHC respects optimization flags regardless of --interactive. 

2. Even when -fobject-code is on, :load *M will load M as bytecode. This provides the "escape hatch" from -fobject-code that you need to use debugging features, etc. 

3. New -fignore-optim-changes and -fignore-hpc-changes (​​Phab:D4123) flags should enable users to put together object code and bytecode with diverse optimization levels/options and HPC options while still updating automatically based on source changes and whether profiling is enabled.

Does this seem like a reasonable way forward?

David Feuer

From ben at well-typed.com  Tue Oct 31 18:15:24 2017
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 31 Oct 2017 14:15:24 -0400
Subject: [ANNOUNCE] GHC 8.2.2 release candidate 2
Message-ID: <877evbuqtf.fsf@ben-laptop.smart-cactus.org>


Hello everyone,

The GHC team is very pleased to announce the second candidate of the
8.2.2 release of the Glasgow Haskell Compiler. Source and binary
distributions are available at

    https://downloads.haskell.org/~ghc/8.2.2-rc2/

This is the second and hopefully last of two release candidates leading
up the final 8.2.2 release. This release fixes approximately fifty bugs
present in 8.2.1. These most notably include,

 * A correctness issue resulting in segmentation faults in some
   FFI-users (#13707, #14346)

 * A correctness issue resulting in undefined behavior in some programs
   using STM (#14171)

 * A bug which may have manifested in segmentation faults in
   out-of-memory condition (#14329)

 * clearBit of Natural no longer bottoms (#13203)

 * A specialisation bug resulting in exponential blowup of compilation
   time in some specialisation-intensive programs (#14379)

 * ghc-pkg now works even in environments with misconfigured NFS mounts
   (#13945)

 * GHC again supports production of position-independent executables
   (#13702)

 * Better error messages around kind mismatches (#11198, #12373, #13530,
   #13610)

See [1] for the full list.

As always, please report any issues you encounter.

Happy testing,

- Ben


[1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.2.2&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171031/b1193560/attachment.sig>

From qdunkan at gmail.com  Tue Oct 31 19:47:56 2017
From: qdunkan at gmail.com (Evan Laforge)
Date: Tue, 31 Oct 2017 12:47:56 -0700
Subject: GHCi recompilation avoidance UI
In-Reply-To: <7587879.l535S4SiGz@squirrel>
References: <7587879.l535S4SiGz@squirrel>
Message-ID: <CACbaDy5Kqk+PBAuByfWd2FhhD_CreY7+PT62EouRBtg=o7o=Hg@mail.gmail.com>

I updated the trac ticket, but here's a copy-paste:

I still don't feel like 1 is necessary, I'd rather flags cause other
flags to be ignored with a warning, rather than turn on other flags.
But that's just a vague preference, with no strong evidence for it.
Maybe it could emit a warning if you didn't put -fobject-code in
explicitly, e.g. "-O implies -fobject-code, adding that flag." So as
long as we accept 1, then 2 and 3 follow naturally. Given that, I
support this UI.

Thanks for looking into it!

From iavor.diatchki at gmail.com  Tue Oct 31 21:26:42 2017
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 31 Oct 2017 21:26:42 +0000
Subject: Building the docs, again
Message-ID: <CAGK9nurAdAAqatNkdH98TEZxuRS_egg2X27BGybXpWFQDGu9Og@mail.gmail.com>

Hello,

sometime ago, I asked if it is possible to build just the GHC docs, without
building the compiler.  I was told to just run `make html`.  This does not
appear to work, the command seems to just start building GHC.  What am I
doing wrong?

Here is the output I see, running the command from the root of the GHC tree.

> make html V=0
===--- building phase 0
make --no-print-directory -f ghc.mk phase=0 phase_0_builds
make[1]: Nothing to be done for 'phase_0_builds'.
===--- building phase 1
make --no-print-directory -f ghc.mk phase=1 phase_1_builds
  HC [stage 0] compiler/stage1/build/BufWrite.o
  HC [stage 0] compiler/stage1/build/Pretty.o
compilation IS NOT required
  HC [stage 0] compiler/stage1/build/PprColour.o
compilation IS NOT required
  HC [stage 0] compiler/stage1/build/Outputable.o
compilation IS NOT required
  HC [stage 0] compiler/stage1/build/Json.o
compilation IS NOT required
  HC [stage 0] compiler/stage1/build/SrcLoc.o
compilation IS NOT required
  HC [stage 0] compiler/stage1/build/BasicTypes.o
compilation IS NOT required
  HC [stage 0] compiler/stage1/build/Unique.o
  HC [stage 0] compiler/stage1/build/Packages.o-boot
compilation IS NOT required
  HC [stage 0] compiler/stage1/build/FiniteMap.o
compilation IS NOT required
  HC [stage 0] compiler/stage1/build/Name.o-boot

(then I interrupted it).

Also, in `mk/config.mk` I see this:
BUILD_SPHINX_HTML        = YES

-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171031/5f199e9c/attachment.html>

From iavor.diatchki at gmail.com  Tue Oct 31 21:49:12 2017
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 31 Oct 2017 21:49:12 +0000
Subject: Building the docs, again
In-Reply-To: <CAGK9nurAdAAqatNkdH98TEZxuRS_egg2X27BGybXpWFQDGu9Og@mail.gmail.com>
References: <CAGK9nurAdAAqatNkdH98TEZxuRS_egg2X27BGybXpWFQDGu9Og@mail.gmail.com>
Message-ID: <CAGK9nuqcRszHHR1qPnucJbf68YPrUqLp6n8iaBhOaAu7yb5soQ@mail.gmail.com>

Hello,

never mind, I figured it out---apparently the build targets were disabled
for the `quick` flavor, which I was using.

It is quite confusing that we can be setting the same variable to different
values in different places.   It would also be quite helpful if we modified
the Makefile to say `documentation build target is disabled` or some such,
rather then going ahead and building the whole of GHC, only at the end to
inform me that it doesn't know what is `html`.

-Iavor



On Tue, Oct 31, 2017 at 2:26 PM Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> Hello,
>
> sometime ago, I asked if it is possible to build just the GHC docs,
> without building the compiler.  I was told to just run `make html`.  This
> does not appear to work, the command seems to just start building GHC.
> What am I doing wrong?
>
> Here is the output I see, running the command from the root of the GHC
> tree.
>
> > make html V=0
> ===--- building phase 0
> make --no-print-directory -f ghc.mk phase=0 phase_0_builds
> make[1]: Nothing to be done for 'phase_0_builds'.
> ===--- building phase 1
> make --no-print-directory -f ghc.mk phase=1 phase_1_builds
>   HC [stage 0] compiler/stage1/build/BufWrite.o
>   HC [stage 0] compiler/stage1/build/Pretty.o
> compilation IS NOT required
>   HC [stage 0] compiler/stage1/build/PprColour.o
> compilation IS NOT required
>   HC [stage 0] compiler/stage1/build/Outputable.o
> compilation IS NOT required
>   HC [stage 0] compiler/stage1/build/Json.o
> compilation IS NOT required
>   HC [stage 0] compiler/stage1/build/SrcLoc.o
> compilation IS NOT required
>   HC [stage 0] compiler/stage1/build/BasicTypes.o
> compilation IS NOT required
>   HC [stage 0] compiler/stage1/build/Unique.o
>   HC [stage 0] compiler/stage1/build/Packages.o-boot
> compilation IS NOT required
>   HC [stage 0] compiler/stage1/build/FiniteMap.o
> compilation IS NOT required
>   HC [stage 0] compiler/stage1/build/Name.o-boot
>
> (then I interrupted it).
>
> Also, in `mk/config.mk` I see this:
> BUILD_SPHINX_HTML        = YES
>
> -Iavor
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171031/bc009f61/attachment.html>

From ben at well-typed.com  Tue Oct 31 18:15:24 2017
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 31 Oct 2017 14:15:24 -0400
Subject: [ANNOUNCE] GHC 8.2.2 release candidate 3
Message-ID: <87h8u31b9x.fsf@ben-laptop.smart-cactus.org>


Hello everyone,

The GHC team is very pleased to announce the third candidate of the
8.2.2 release of the Glasgow Haskell Compiler. Source and binary
distributions are available at

    https://downloads.haskell.org/~ghc/8.2.2-rc3/

This is the third and last of three release candidates leading up the
final 8.2.2 release. This release fixes approximately fifty bugs present
in 8.2.1. These most notably include,

 * A correctness issue resulting in segmentation faults in some
   FFI-users (#13707, #14346)

 * A correctness issue resulting in undefined behavior in some programs
   using STM (#14171)

 * A bug which may have manifested in segmentation faults in
   out-of-memory condition (#14329)

 * clearBit of Natural no longer bottoms (#13203)

 * A specialisation bug resulting in exponential blowup of compilation
   time in some specialisation-intensive programs (#14379)

 * ghc-pkg now works even in environments with misconfigured NFS mounts
   (#13945)

 * GHC again supports production of position-independent executables
   (#13702)

 * Better error messages around kind mismatches (#11198, #12373, #13530,
   #13610)

See [1] for the full list.

Release candidate three contains only two patches not present in -rc2
but fixes a packaging issue which lead to unintentional downgrading the
process and Cabal libraries.

As always, please report any issues you encounter.

Happy testing,

- Ben

[1]
https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.2.2&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171031/376370da/attachment.sig>