From ben at smart-cactus.org  Fri Apr  1 15:53:39 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Fri, 01 Apr 2016 17:53:39 +0200
Subject: Initial compile time benchmarks
In-Reply-To: <CAMQQO3m3pb+Kzu-A107WhzHObpABzkus96mNetwvtQ1RKi=QeQ@mail.gmail.com>
References: <CAMQQO3kVEpBPbTrywo6KN1XPxQqwd2AHRsseuiNvvSh8bp382Q@mail.gmail.com>
 <1459414144.1628.6.camel@joachim-breitner.de>
 <CAMQQO3mpEbGcP5AohUK4+FtBoDt0J+tJ1WTqZQWc=a5BByVPeg@mail.gmail.com>
 <CAMQQO3m3K5Ms-LgGex3UpUo_Q4foLs+tkSg=6Rwr4_f+aC0F5Q@mail.gmail.com>
 <CAMQQO3m3pb+Kzu-A107WhzHObpABzkus96mNetwvtQ1RKi=QeQ@mail.gmail.com>
Message-ID: <877fgh5nr0.fsf@smart-cactus.org>

?mer Sinan A?acan <omeragacan at gmail.com> writes:

> I just benchmarked another set of packages, this time using -O2 optimized libs
> + stage 2 (6ea42c7):
>
> https://gist.githubusercontent.com/osa1/b483216953e3b02c0c79f9e4c8f8f931/raw/64001a1bfb71c0c4441c07f9f195bf5629095a6f/gistfile1.txt
>
> For me the most surprising part is that CodeGen is sometimes taking 86% of the
> time. It seems like we can start looking for improvements there. (I'll do that
> myself but I'm too busy for a few more days)
>
>
> Joachim, I think the difference is because of how thunk evaluation and cost
> centers work. If you generate a thunk with cost-center "X", you attribute the
> evaluation costs of that thunk to the cost-center "X". This is unlike how GHC
> currently printing the timing information: We essentially measure the time of
> thunk creation, not normalization of thunks. So the numbers you get from the
> profiling output may be more correct.
>
> We should try actually forcing the values in `withTiming` and see how it'll
> effect the timings. I feel like some of the costs attributed to CodeGen step
> is because of thunks we generate in previous steps. It's probably not possible
> to completely evaluate the values (because of cycles), but we can still do a
> better job probably.
>
> One last thing is that profiling can prevent some optimizations and cause
> different runtime behavior. Problems with instrumentation ...
>
Absolutely true; this is why I ultimately decided to hold off adding any
forcing in the initial patch. I had hoped to have time to do more sanity
checking of the numbers myself before the release, but sadly time hasn't
allowed. I'm very happy that you are picking up this effort. Thanks!

Cheers,

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

From conal at conal.net  Sat Apr  2 19:23:38 2016
From: conal at conal.net (Conal Elliott)
Date: Sat, 2 Apr 2016 12:23:38 -0700
Subject: "opt_univ fell into a hole"
Message-ID: <CAD6SzR+QHtCFGQfUOfM-+TNqWeYJ_4zK1EBqw3FsBU9QQUya=A@mail.gmail.com>

I'm getting the following error message from a GHC plugin I'm developing
(note GHC version):

    ghc-stage2: panic! (the 'impossible' happened)
      (GHC version 8.1.20160307 for x86_64-apple-darwin):
            opt_univ fell into a hole {aD1S}

I don't get this error when compiling without my plugin, so I may well be
violating a compiler invariant.

Shortly before the error, the plugin produced the following dictionary
expression, which does indeed contain a `UnivCo` with a `HoleProv`. The
plugin does sometimes generate `UnivCo`s but not with `HoleProv`.

    let {
      $dHasRep_aD1T :: HasRep (Vec 'Z s_aD1R[fuv:0])
      $dHasRep_aD1T = $fHasRepVec0 @ s_aD1R[fuv:0] } in
    let {
      $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR :: HasRep (Vec 'Z (Key h_aCnh))
      $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR =
        $dHasRep_aD1T
        `cast` ((HasRep
                   (Vec
                      <'Z>_N
                      (Sym U(hole:{aD1S}, Key h_aCnh,
s_aD1R[fuv:0])_N))_N)_R
                :: HasRep (Vec 'Z s_aD1R[fuv:0])
                   ~R# HasRep (Vec 'Z (Key h_aCnh))) } in
    $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR

Here, `Key` is a type family from `Data.Key` in the keys package, and `Vec`
is a GADT of statically length-indexed lists.

Suggestions?

Thanks, - Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160402/bcef91f8/attachment.html>

From rrnewton at gmail.com  Mon Apr  4 05:06:13 2016
From: rrnewton at gmail.com (Ryan Newton)
Date: Mon, 4 Apr 2016 01:06:13 -0400
Subject: Benchmarking harnesses for a more modern nofib?
Message-ID: <CACYs5AYHDn-LWn1++A08xKPs4W8_WAXRac7UeH=Zg8zS82kw1w@mail.gmail.com>

Hi all,

Is anyone currently working in, or interested in helping with, a new
benchmark suite for Haskell?  Perhaps, packaging up existing apps and app
benchmarks into a new benchmark suite that gives a broad picture of Haskell
application performance today?

Background: We run nofib, and we run the shootout benchmarks.  But when we
want to evaluate basic changes to GHC optimizations or data representation,
these really don't give us a full picture of whether a change is beneficial.

A few years ago, fibon <https://hackage.haskell.org/package/fibon> tried to
gather some Hackage benchmarks.  This may work even better with Stackage,
where there are 180 benchmark suites among the 1770 packages currently.

Also, these days companies are building substantial apps in Hackage.  Which
substantial apps could or should go into a benchmark suite?  I see Warp and
other web server benchmarks
<http://www.infoq.com/news/2015/04/web-frameworks-benchmark-2015?utm_source=infoqEmail&utm_medium=WeeklyNL_EditorialContentOperationsInfrastructure&utm_campaign=04282015news>
all
over the web.  But is there a harness that can time some of this code while
running inside a single-machine, easy-setup benchmark suite?

Best,
  -Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160404/e782575f/attachment.html>

From rrnewton at gmail.com  Mon Apr  4 05:07:32 2016
From: rrnewton at gmail.com (Ryan Newton)
Date: Mon, 4 Apr 2016 01:07:32 -0400
Subject: Benchmarking harnesses for a more modern nofib?
In-Reply-To: <CACYs5AYHDn-LWn1++A08xKPs4W8_WAXRac7UeH=Zg8zS82kw1w@mail.gmail.com>
References: <CACYs5AYHDn-LWn1++A08xKPs4W8_WAXRac7UeH=Zg8zS82kw1w@mail.gmail.com>
Message-ID: <CACYs5AZZEh7yYTja-O3+gZ8Bk6MoNx9uFX7C6jqFd48oBgr3rQ@mail.gmail.com>

Sorry, bit too late: excuse typos:

Also, these days companies are building substantial apps in Hackage.
>

In *Haskell*, of course.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160404/8bc15e31/attachment.html>

From simonpj at microsoft.com  Mon Apr  4 07:45:23 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 4 Apr 2016 07:45:23 +0000
Subject: Benchmarking harnesses for a more modern nofib?
In-Reply-To: <CACYs5AYHDn-LWn1++A08xKPs4W8_WAXRac7UeH=Zg8zS82kw1w@mail.gmail.com>
References: <CACYs5AYHDn-LWn1++A08xKPs4W8_WAXRac7UeH=Zg8zS82kw1w@mail.gmail.com>
Message-ID: <30f3313fdc904390895716339b172cb8@DB4PR30MB030.064d.mgd.msft.net>

Is anyone currently working in, or interested in helping with, a new benchmark suite for Haskell?  Perhaps, packaging up existing apps and app benchmarks into a new benchmark suite that gives a broad picture of Haskell application performance today?
I would love to see this done.  nofib is showing its age.

An incentive is this: we benchmark GHC against nofib pretty regularly, and pay attention to regressions.   If your program is in the benchmark suite, it?s more likely that its performance will be good and stay good.

The tension is that, to be usable, it must be possible to actually run the benchmark suite, on a variety of platforms, without consuming too much time.

?         nofib has zero package dependencies.  Adding some dependencies is fine, but it adding zillions is not.  Often they can be cut down because some of the dependencies are related to incidental features of the benchmark that can be stubbed off.

?         More seriously, for figures to be comparable we have to compare the same code.  So any package dependencies must be hard dependencies on particular versions. And as GHC moves on, those packages may require (hopefully minor) updates to stay working.

?         Test data and test environment can be a challenge, especially for things like web servers.  Again we don?t to force the developer to install too much other stuff.

All that said, it must be possible to do MUCH better than we are right now, with a 20-year old suite!  Please do join Ryan in working on this.

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Ryan Newton
Sent: 04 April 2016 06:06
To: ghc-devs at haskell.org; Haskell Cafe <haskell-cafe at haskell.org>
Subject: Benchmarking harnesses for a more modern nofib?

Hi all,

Is anyone currently working in, or interested in helping with, a new benchmark suite for Haskell?  Perhaps, packaging up existing apps and app benchmarks into a new benchmark suite that gives a broad picture of Haskell application performance today?

Background: We run nofib, and we run the shootout benchmarks.  But when we want to evaluate basic changes to GHC optimizations or data representation, these really don't give us a full picture of whether a change is beneficial.

A few years ago, fibon<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fhackage.haskell.org%2fpackage%2ffibon&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c97ff82e27fe943e829a408d35c46e8e5%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9TmwKAqL9dOSyqzwcFvVoI7K7aVlxL80Uqws2uZK3Dk%3d> tried to gather some Hackage benchmarks.  This may work even better with Stackage, where there are 180 benchmark suites among the 1770 packages currently.

Also, these days companies are building substantial apps in Hackage.  Which substantial apps could or should go into a benchmark suite?  I see Warp and other web server benchmarks<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.infoq.com%2fnews%2f2015%2f04%2fweb-frameworks-benchmark-2015%3futm_source%3dinfoqEmail%26utm_medium%3dWeeklyNL_EditorialContentOperationsInfrastructure%26utm_campaign%3d04282015news&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c97ff82e27fe943e829a408d35c46e8e5%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=EPCgYJwmVzo0JVCdhPjnp1FwfcRcJid%2bAZFyhUp7e0U%3d> all over the web.  But is there a harness that can time some of this code while running inside a single-machine, easy-setup benchmark suite?

Best,
  -Ryan

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

From mail at joachim-breitner.de  Mon Apr  4 08:32:11 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 04 Apr 2016 10:32:11 +0200
Subject: [Haskell-cafe] Benchmarking harnesses for a more modern nofib?
In-Reply-To: <CACYs5AYHDn-LWn1++A08xKPs4W8_WAXRac7UeH=Zg8zS82kw1w@mail.gmail.com>
References: <CACYs5AYHDn-LWn1++A08xKPs4W8_WAXRac7UeH=Zg8zS82kw1w@mail.gmail.com>
Message-ID: <1459758731.1677.6.camel@joachim-breitner.de>

Hi,

definitely interested. I have just talked about this with Richard
yesterday, and we quite agree with what you observed. As the maintainer
of http://perf.haskell.org/ghc, I?d very much welcome better data!

Note that fibon already has bitrotted, and does not quite work any
more. So there is some low hanging fruit in resurrecting that one.

Simon mentioned a few points, such as dependencies. But note that you
can relatively easily dump the dependencies?s modules in your source
repository to both bundle and freeze them. I?d prefer that to (even
strict) dependencies to something external, as that lowers the barrier
for developers to actually run the benchmarks!

Another important step in that direction would be to define a common
output for benchmark suites defined in .cabal files, so it is easier to
set up things like?http://perf.haskell.org/ghc?and?http://perf.haskell.
org/binary?for?these projects.

About the harness: haskell.org is currently paying a student (CCed) to
setup a travis-like infrastructure based on gipeda (the software behind
perf.haskell.org) that would allow library authors to very simply get
continuous benchmark measurements. Let?s see what comes out of that!

Greetings,
Joachim

Am Montag, den 04.04.2016, 01:06 -0400 schrieb Ryan Newton:
> Hi all,
> 
> Is anyone currently working in, or interested in helping with, a new
> benchmark suite for Haskell?? Perhaps, packaging up existing apps and
> app benchmarks into a new benchmark suite that gives a broad picture
> of Haskell application performance today?
> 
> Background: We run nofib, and we run the shootout benchmarks.? But
> when we want to evaluate basic changes to GHC optimizations or data
> representation, these really don't give us a full picture of whether
> a change is beneficial.
> 
> A few years ago, fibon?tried to gather some Hackage benchmarks.? This
> may work even better with Stackage, where there are 180 benchmark
> suites among the 1770 packages currently.
> 
> Also, these days companies are building substantial apps in Hackage.?
> Which substantial apps could or should go into a benchmark suite?? I
> see?Warp and other web server benchmarks?all over the web.? But is
> there a harness that can time some of this code while running inside
> a single-machine, easy-setup benchmark suite?
> 
> Best,
> ? -Ryan
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-- 
Joachim ?nomeata? Breitner
? mail at joachim-breitner.de ? https://www.joachim-breitner.de/
? XMPP: nomeata at joachim-breitner.de?? OpenPGP-Key: 0xF0FBF51F
? Debian Developer: nomeata at debian.org

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

From simonpj at microsoft.com  Mon Apr  4 09:48:25 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 4 Apr 2016 09:48:25 +0000
Subject: "opt_univ fell into a hole"
In-Reply-To: <CAD6SzR+QHtCFGQfUOfM-+TNqWeYJ_4zK1EBqw3FsBU9QQUya=A@mail.gmail.com>
References: <CAD6SzR+QHtCFGQfUOfM-+TNqWeYJ_4zK1EBqw3FsBU9QQUya=A@mail.gmail.com>
Message-ID: <34e8d9166f8b4e078161aecfec84ba0e@DB4PR30MB030.064d.mgd.msft.net>

Definitely a bug. All HoleProvs should be eliminated by the type checker.

Did your plugin produce a HoleProv?  It definitely should not do so; see the notes with that constructor.

Lint checks for this ? did you run with ?dcore-lint?

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal Elliott
Sent: 02 April 2016 20:24
To: ghc-devs at haskell.org
Subject: "opt_univ fell into a hole"

I'm getting the following error message from a GHC plugin I'm developing (note GHC version):

    ghc-stage2: panic! (the 'impossible' happened)
      (GHC version 8.1.20160307 for x86_64-apple-darwin):
            opt_univ fell into a hole {aD1S}

I don't get this error when compiling without my plugin, so I may well be violating a compiler invariant.

Shortly before the error, the plugin produced the following dictionary expression, which does indeed contain a `UnivCo` with a `HoleProv`. The plugin does sometimes generate `UnivCo`s but not with `HoleProv`.

    let {
      $dHasRep_aD1T :: HasRep (Vec 'Z s_aD1R[fuv:0])
      $dHasRep_aD1T = $fHasRepVec0 @ s_aD1R[fuv:0] } in
    let {
      $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR :: HasRep (Vec 'Z (Key h_aCnh))
      $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR =
        $dHasRep_aD1T
        `cast` ((HasRep
                   (Vec
                      <'Z>_N
                      (Sym U(hole:{aD1S}, Key h_aCnh, s_aD1R[fuv:0])_N))_N)_R
                :: HasRep (Vec 'Z s_aD1R[fuv:0])
                   ~R# HasRep (Vec 'Z (Key h_aCnh))) } in
    $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR

Here, `Key` is a type family from `Data.Key` in the keys package, and `Vec` is a GADT of statically length-indexed lists.

Suggestions?

Thanks, - Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160404/dca082e7/attachment.html>

From conal at conal.net  Mon Apr  4 16:21:29 2016
From: conal at conal.net (Conal Elliott)
Date: Mon, 4 Apr 2016 09:21:29 -0700
Subject: "opt_univ fell into a hole"
In-Reply-To: <34e8d9166f8b4e078161aecfec84ba0e@DB4PR30MB030.064d.mgd.msft.net>
References: <CAD6SzR+QHtCFGQfUOfM-+TNqWeYJ_4zK1EBqw3FsBU9QQUya=A@mail.gmail.com>
 <34e8d9166f8b4e078161aecfec84ba0e@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAD6SzRK7J66_eYXxVE63FNOP++dZU3_JSd2+MftoE83LxU0hCQ@mail.gmail.com>

Hi Simon. Thanks for the reply. My plugin appears to produce the HoleProv
indirectly (and to my surprise) while building a dictionary to satisfy a
given constraint, using mkNonCanonical and solveWanteds. I don't know why
solveWanteds produces a HoleProv in this case and not in the many others
I've tried. The constraint being solved in the example I included was
'HasRep (Vec ('S n_aCj7) (Key h_aCj6))', where HasRep is similar to Generic
(from GHC.Generics), and there is a HasRep instance for Vec ('S n x). Come
to think of it, the free type variable s_aD1S troubles me as well.

I'm not terribly confident in the code I use for constructing these
dictionaries (setting up and calling solveWanteds) during Core-to-Core
transformation. Do you know of any relevant example code, docs, etc?

Yes, I'm using -dcore-lint, as well explicitly linting each small
transformation step (while debugging). Doing so has been very helpful in
finding bugs quickly.

Cheers, - Conal

On Mon, Apr 4, 2016 at 2:48 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Definitely a bug. All HoleProvs should be eliminated by the type checker.
>
>
>
> Did your plugin produce a HoleProv?  It definitely should not do so; see
> the notes with that constructor.
>
>
>
> Lint checks for this ? did you run with ?dcore-lint?
>
>
>
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Conal
> Elliott
> *Sent:* 02 April 2016 20:24
> *To:* ghc-devs at haskell.org
> *Subject:* "opt_univ fell into a hole"
>
>
>
> I'm getting the following error message from a GHC plugin I'm developing
> (note GHC version):
>
>     ghc-stage2: panic! (the 'impossible' happened)
>       (GHC version 8.1.20160307 for x86_64-apple-darwin):
>             opt_univ fell into a hole {aD1S}
>
> I don't get this error when compiling without my plugin, so I may well be
> violating a compiler invariant.
>
> Shortly before the error, the plugin produced the following dictionary
> expression, which does indeed contain a `UnivCo` with a `HoleProv`. The
> plugin does sometimes generate `UnivCo`s but not with `HoleProv`.
>
>     let {
>       $dHasRep_aD1T :: HasRep (Vec 'Z s_aD1R[fuv:0])
>       $dHasRep_aD1T = $fHasRepVec0 @ s_aD1R[fuv:0] } in
>     let {
>       $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR :: HasRep (Vec 'Z (Key h_aCnh))
>       $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR =
>         $dHasRep_aD1T
>         `cast` ((HasRep
>                    (Vec
>                       <'Z>_N
>                       (Sym U(hole:{aD1S}, Key h_aCnh,
> s_aD1R[fuv:0])_N))_N)_R
>                 :: HasRep (Vec 'Z s_aD1R[fuv:0])
>                    ~R# HasRep (Vec 'Z (Key h_aCnh))) } in
>     $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR
>
> Here, `Key` is a type family from `Data.Key` in the keys package, and
> `Vec` is a GADT of statically length-indexed lists.
>
> Suggestions?
>
> Thanks, - Conal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160404/59567b22/attachment.html>

From eir at cis.upenn.edu  Mon Apr  4 16:37:21 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 4 Apr 2016 18:37:21 +0200
Subject: "opt_univ fell into a hole"
In-Reply-To: <CAD6SzRK7J66_eYXxVE63FNOP++dZU3_JSd2+MftoE83LxU0hCQ@mail.gmail.com>
References: <CAD6SzR+QHtCFGQfUOfM-+TNqWeYJ_4zK1EBqw3FsBU9QQUya=A@mail.gmail.com>
 <34e8d9166f8b4e078161aecfec84ba0e@DB4PR30MB030.064d.mgd.msft.net>
 <CAD6SzRK7J66_eYXxVE63FNOP++dZU3_JSd2+MftoE83LxU0hCQ@mail.gmail.com>
Message-ID: <8AE0A67F-4A73-4624-BD3E-335C654104BE@cis.upenn.edu>

Coercion holes (the payload of a HoleProv) get created for all wanted equality constraints (and for nothing else). If you're working over only class dictionaries, you won't encounter holes. But my guess is that your HasRep somehow induces a wanted equality. If the solver fills the hole -- as it should if the equality is solvable -- then you may just need to zonk it properly. zonkCoHole does the job, but this should be called from zonkTcTypeToType, which I imagine you're already doing.

I hope this helps,
Richard

On Apr 4, 2016, at 6:21 PM, Conal Elliott <conal at conal.net> wrote:

> Hi Simon. Thanks for the reply. My plugin appears to produce the HoleProv indirectly (and to my surprise) while building a dictionary to satisfy a given constraint, using mkNonCanonical and solveWanteds. I don't know why solveWanteds produces a HoleProv in this case and not in the many others I've tried. The constraint being solved in the example I included was 'HasRep (Vec ('S n_aCj7) (Key h_aCj6))', where HasRep is similar to Generic (from GHC.Generics), and there is a HasRep instance for Vec ('S n x). Come to think of it, the free type variable s_aD1S troubles me as well.
> 
> I'm not terribly confident in the code I use for constructing these dictionaries (setting up and calling solveWanteds) during Core-to-Core transformation. Do you know of any relevant example code, docs, etc?
> 
> Yes, I'm using -dcore-lint, as well explicitly linting each small transformation step (while debugging). Doing so has been very helpful in finding bugs quickly.
> 
> Cheers, - Conal
> 
> On Mon, Apr 4, 2016 at 2:48 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> Definitely a bug. All HoleProvs should be eliminated by the type checker.
> 
>  
> 
> Did your plugin produce a HoleProv?  It definitely should not do so; see the notes with that constructor.
> 
>  
> 
> Lint checks for this ? did you run with ?dcore-lint?
> 
>  
> 
> Simon
> 
>  
> 
> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal Elliott
> Sent: 02 April 2016 20:24
> To: ghc-devs at haskell.org
> Subject: "opt_univ fell into a hole"
> 
>  
> 
> I'm getting the following error message from a GHC plugin I'm developing (note GHC version):
> 
>     ghc-stage2: panic! (the 'impossible' happened)
>       (GHC version 8.1.20160307 for x86_64-apple-darwin):
>             opt_univ fell into a hole {aD1S}
> 
> I don't get this error when compiling without my plugin, so I may well be violating a compiler invariant.
> 
> Shortly before the error, the plugin produced the following dictionary expression, which does indeed contain a `UnivCo` with a `HoleProv`. The plugin does sometimes generate `UnivCo`s but not with `HoleProv`.
> 
>     let {
>       $dHasRep_aD1T :: HasRep (Vec 'Z s_aD1R[fuv:0])
>       $dHasRep_aD1T = $fHasRepVec0 @ s_aD1R[fuv:0] } in
>     let {
>       $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR :: HasRep (Vec 'Z (Key h_aCnh))
>       $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR =
>         $dHasRep_aD1T
>         `cast` ((HasRep
>                    (Vec
>                       <'Z>_N
>                       (Sym U(hole:{aD1S}, Key h_aCnh, s_aD1R[fuv:0])_N))_N)_R
>                 :: HasRep (Vec 'Z s_aD1R[fuv:0])
>                    ~R# HasRep (Vec 'Z (Key h_aCnh))) } in
>     $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR
> 
> Here, `Key` is a type family from `Data.Key` in the keys package, and `Vec` is a GADT of statically length-indexed lists.
> 
> Suggestions?
> 
> Thanks, - Conal
> 
> 
> _______________________________________________
> 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/20160404/3bf45803/attachment.html>

From conal at conal.net  Mon Apr  4 17:16:06 2016
From: conal at conal.net (Conal Elliott)
Date: Mon, 4 Apr 2016 10:16:06 -0700
Subject: "opt_univ fell into a hole"
In-Reply-To: <8AE0A67F-4A73-4624-BD3E-335C654104BE@cis.upenn.edu>
References: <CAD6SzR+QHtCFGQfUOfM-+TNqWeYJ_4zK1EBqw3FsBU9QQUya=A@mail.gmail.com>
 <34e8d9166f8b4e078161aecfec84ba0e@DB4PR30MB030.064d.mgd.msft.net>
 <CAD6SzRK7J66_eYXxVE63FNOP++dZU3_JSd2+MftoE83LxU0hCQ@mail.gmail.com>
 <8AE0A67F-4A73-4624-BD3E-335C654104BE@cis.upenn.edu>
Message-ID: <CAD6SzRKUbeDz2ku3Jva3OUAFn5ojRPc+a4cGEr6f7S3E6rQUXA@mail.gmail.com>

Hi Richard. Thanks for the tips. I haven't learned about zonking, so it may
well be what I'm missing here. I'm using some inherited code that includes
the following line to get bindings then used with dsEvBinds and mkCoreLets
to build an expression:

>         (_wCs', bnds) <- second evBindMapBinds <$> runTcS (solveWanteds
wCs)

Should I be zonking in here somewhere?

More context for this code, if helpful:

> -- | Build a dictionary for the given
> buildDictionary' :: HscEnv -> DynFlags -> ModGuts -> Id -> (Id,
[CoreBind])
> buildDictionary' env dflags guts evar =
>     let (i, bs) = runTcMUnsafe env dflags guts $ do
>         loc <- getCtLocM (GivenOrigin UnkSkol) Nothing
>         let predTy = varType evar
>             nonC = mkNonCanonical $
>                      CtWanted { ctev_pred = predTy, ctev_dest = EvVarDest
evar
>                               , ctev_loc = loc }
>             wCs = mkSimpleWC [cc_ev nonC]
>         -- TODO: Make sure solveWanteds is the right function to call.
>         (_wCs', bnds) <- second evBindMapBinds <$> runTcS (solveWanteds
wCs)
>         -- pprTrace "buildDictionary' _wCs'" (ppr _wCs') (return ())
>         warnAllUnsolved _wCs'
>         return (evar, bnds)
>     in
>       (i, runDsMUnsafe env dflags guts (dsEvBinds bs))

where runTcMUnsafe and runDsMUnsafe use unsafePerformIO (ouch) to

> runTcMUnsafe :: HscEnv -> DynFlags -> ModGuts -> TcM a -> a
> runTcMUnsafe env dflags guts m = unsafePerformIO $ do
>     -- What is the effect of HsSrcFile (should we be using something
else?)
>     -- What should the boolean flag be set to?
>     (msgs, mr) <- initTcFromModGuts env guts HsSrcFile False m
>     let showMsgs (warns, errs) = showSDoc dflags $ vcat
>                                                  $    text "Errors:" :
pprErrMsgBagWithLoc errs
>                                                    ++ text "Warnings:" :
pprErrMsgBagWithLoc warns
>     maybe (fail $ showMsgs msgs) return mr
>
> -- TODO: Try initTcForLookup or initTcInteractive in place of
initTcFromModGuts.
> -- If successful, drop dflags and guts arguments.
>
> runDsMUnsafe :: HscEnv -> DynFlags -> ModGuts -> DsM a -> a
> runDsMUnsafe env dflags guts = runTcMUnsafe env dflags guts . initDsTc

and initTcFromModGuts is something I pulled in from HERMIT.

Thanks and regards, - Conal

On Mon, Apr 4, 2016 at 9:37 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> Coercion holes (the payload of a HoleProv) get created for all wanted
> equality constraints (and for nothing else). If you're working over only
> class dictionaries, you won't encounter holes. But my guess is that your
> HasRep somehow induces a wanted equality. If the solver fills the hole --
> as it should if the equality is solvable -- then you may just need to zonk
> it properly. zonkCoHole does the job, but this should be called from
> zonkTcTypeToType, which I imagine you're already doing.
>
> I hope this helps,
> Richard
>
> On Apr 4, 2016, at 6:21 PM, Conal Elliott <conal at conal.net> wrote:
>
> Hi Simon. Thanks for the reply. My plugin appears to produce the HoleProv
> indirectly (and to my surprise) while building a dictionary to satisfy a
> given constraint, using mkNonCanonical and solveWanteds. I don't know why
> solveWanteds produces a HoleProv in this case and not in the many others
> I've tried. The constraint being solved in the example I included was
> 'HasRep (Vec ('S n_aCj7) (Key h_aCj6))', where HasRep is similar to Generic
> (from GHC.Generics), and there is a HasRep instance for Vec ('S n x). Come
> to think of it, the free type variable s_aD1S troubles me as well.
>
> I'm not terribly confident in the code I use for constructing these
> dictionaries (setting up and calling solveWanteds) during Core-to-Core
> transformation. Do you know of any relevant example code, docs, etc?
>
> Yes, I'm using -dcore-lint, as well explicitly linting each small
> transformation step (while debugging). Doing so has been very helpful in
> finding bugs quickly.
>
> Cheers, - Conal
>
> On Mon, Apr 4, 2016 at 2:48 AM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
>> Definitely a bug. All HoleProvs should be eliminated by the type checker.
>>
>>
>>
>> Did your plugin produce a HoleProv?  It definitely should not do so; see
>> the notes with that constructor.
>>
>>
>>
>> Lint checks for this ? did you run with ?dcore-lint?
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Conal
>> Elliott
>> *Sent:* 02 April 2016 20:24
>> *To:* ghc-devs at haskell.org
>> *Subject:* "opt_univ fell into a hole"
>>
>>
>>
>> I'm getting the following error message from a GHC plugin I'm developing
>> (note GHC version):
>>
>>     ghc-stage2: panic! (the 'impossible' happened)
>>       (GHC version 8.1.20160307 for x86_64-apple-darwin):
>>             opt_univ fell into a hole {aD1S}
>>
>> I don't get this error when compiling without my plugin, so I may well be
>> violating a compiler invariant.
>>
>> Shortly before the error, the plugin produced the following dictionary
>> expression, which does indeed contain a `UnivCo` with a `HoleProv`. The
>> plugin does sometimes generate `UnivCo`s but not with `HoleProv`.
>>
>>     let {
>>       $dHasRep_aD1T :: HasRep (Vec 'Z s_aD1R[fuv:0])
>>       $dHasRep_aD1T = $fHasRepVec0 @ s_aD1R[fuv:0] } in
>>     let {
>>       $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR :: HasRep (Vec 'Z (Key h_aCnh))
>>       $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR =
>>         $dHasRep_aD1T
>>         `cast` ((HasRep
>>                    (Vec
>>                       <'Z>_N
>>                       (Sym U(hole:{aD1S}, Key h_aCnh,
>> s_aD1R[fuv:0])_N))_N)_R
>>                 :: HasRep (Vec 'Z s_aD1R[fuv:0])
>>                    ~R# HasRep (Vec 'Z (Key h_aCnh))) } in
>>     $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR
>>
>> Here, `Key` is a type family from `Data.Key` in the keys package, and
>> `Vec` is a GADT of statically length-indexed lists.
>>
>> Suggestions?
>>
>> Thanks, - Conal
>>
>
> _______________________________________________
> 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/20160404/a6301bdc/attachment-0001.html>

From nikitasazanovich at gmail.com  Mon Apr  4 18:22:46 2016
From: nikitasazanovich at gmail.com (Sazanovich Nikita)
Date: Mon, 4 Apr 2016 21:22:46 +0300
Subject: Feature development
Message-ID: <2BEDC7D9-D184-436D-9EAF-F2214CB6AD60@gmail.com>

  Hello! 
  I am working on ticket https://ghc.haskell.org/trac/ghc/ticket/5850 <https://ghc.haskell.org/trac/ghc/ticket/5850> now. I?ve come upon converting the type, which GHC.compileExpr returns, to my prompt function type [PModule] -> Int -> IO String. But this function returns ghc-prim-0.5.0.0:GHC.Prim.Any. I don?t see a clear way to convert it. So my questions are:
- What this type is about? I know Any type in Haskell. Is it a specific version of it?
- Or maybe it is not the best way to check a function correctness? I?ve checked out InteractiveEval module and it seems that there are only four quite similar functions to compile Expressions.
  Last person, who was trying to solve this problem, used Unsafe.Coerce and it is also doing this job pretty well now, but the name speaks for itself.   
  Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160404/9e183da1/attachment.html>

From conal at conal.net  Mon Apr  4 18:34:50 2016
From: conal at conal.net (Conal Elliott)
Date: Mon, 4 Apr 2016 11:34:50 -0700
Subject: "opt_univ fell into a hole"
In-Reply-To: <CAD6SzRKUbeDz2ku3Jva3OUAFn5ojRPc+a4cGEr6f7S3E6rQUXA@mail.gmail.com>
References: <CAD6SzR+QHtCFGQfUOfM-+TNqWeYJ_4zK1EBqw3FsBU9QQUya=A@mail.gmail.com>
 <34e8d9166f8b4e078161aecfec84ba0e@DB4PR30MB030.064d.mgd.msft.net>
 <CAD6SzRK7J66_eYXxVE63FNOP++dZU3_JSd2+MftoE83LxU0hCQ@mail.gmail.com>
 <8AE0A67F-4A73-4624-BD3E-335C654104BE@cis.upenn.edu>
 <CAD6SzRKUbeDz2ku3Jva3OUAFn5ojRPc+a4cGEr6f7S3E6rQUXA@mail.gmail.com>
Message-ID: <CAD6SzRLH9LC7g3c71f14_WGyH35u+3LgYFY-AW+tJfvO=H-cYg@mail.gmail.com>

Oops. Just noticed an unfinished sentence. Meant to say "... where
runTcMUnsafe and runDsMUnsafe use unsafePerformIO (ouch) to construct
dictionary expressions in a 'built-in' rewrite rule". Of course, I'd love
to find a way not to need the unsafePerformIO.

On Mon, Apr 4, 2016 at 10:16 AM, Conal Elliott <conal at conal.net> wrote:

> Hi Richard. Thanks for the tips. I haven't learned about zonking, so it
> may well be what I'm missing here. I'm using some inherited code that
> includes the following line to get bindings then used with dsEvBinds and
> mkCoreLets to build an expression:
>
> >         (_wCs', bnds) <- second evBindMapBinds <$> runTcS (solveWanteds
> wCs)
>
> Should I be zonking in here somewhere?
>
> More context for this code, if helpful:
>
> > -- | Build a dictionary for the given
> > buildDictionary' :: HscEnv -> DynFlags -> ModGuts -> Id -> (Id,
> [CoreBind])
> > buildDictionary' env dflags guts evar =
> >     let (i, bs) = runTcMUnsafe env dflags guts $ do
> >         loc <- getCtLocM (GivenOrigin UnkSkol) Nothing
> >         let predTy = varType evar
> >             nonC = mkNonCanonical $
> >                      CtWanted { ctev_pred = predTy, ctev_dest =
> EvVarDest evar
> >                               , ctev_loc = loc }
> >             wCs = mkSimpleWC [cc_ev nonC]
> >         -- TODO: Make sure solveWanteds is the right function to call.
> >         (_wCs', bnds) <- second evBindMapBinds <$> runTcS (solveWanteds
> wCs)
> >         -- pprTrace "buildDictionary' _wCs'" (ppr _wCs') (return ())
> >         warnAllUnsolved _wCs'
> >         return (evar, bnds)
> >     in
> >       (i, runDsMUnsafe env dflags guts (dsEvBinds bs))
>
> where runTcMUnsafe and runDsMUnsafe use unsafePerformIO (ouch) to
>
> > runTcMUnsafe :: HscEnv -> DynFlags -> ModGuts -> TcM a -> a
> > runTcMUnsafe env dflags guts m = unsafePerformIO $ do
> >     -- What is the effect of HsSrcFile (should we be using something
> else?)
> >     -- What should the boolean flag be set to?
> >     (msgs, mr) <- initTcFromModGuts env guts HsSrcFile False m
> >     let showMsgs (warns, errs) = showSDoc dflags $ vcat
> >                                                  $    text "Errors:" :
> pprErrMsgBagWithLoc errs
> >                                                    ++ text "Warnings:" :
> pprErrMsgBagWithLoc warns
> >     maybe (fail $ showMsgs msgs) return mr
> >
> > -- TODO: Try initTcForLookup or initTcInteractive in place of
> initTcFromModGuts.
> > -- If successful, drop dflags and guts arguments.
> >
> > runDsMUnsafe :: HscEnv -> DynFlags -> ModGuts -> DsM a -> a
> > runDsMUnsafe env dflags guts = runTcMUnsafe env dflags guts . initDsTc
>
> and initTcFromModGuts is something I pulled in from HERMIT.
>
> Thanks and regards, - Conal
>
> On Mon, Apr 4, 2016 at 9:37 AM, Richard Eisenberg <eir at cis.upenn.edu>
> wrote:
>
>> Coercion holes (the payload of a HoleProv) get created for all wanted
>> equality constraints (and for nothing else). If you're working over only
>> class dictionaries, you won't encounter holes. But my guess is that your
>> HasRep somehow induces a wanted equality. If the solver fills the hole --
>> as it should if the equality is solvable -- then you may just need to zonk
>> it properly. zonkCoHole does the job, but this should be called from
>> zonkTcTypeToType, which I imagine you're already doing.
>>
>> I hope this helps,
>> Richard
>>
>> On Apr 4, 2016, at 6:21 PM, Conal Elliott <conal at conal.net> wrote:
>>
>> Hi Simon. Thanks for the reply. My plugin appears to produce the HoleProv
>> indirectly (and to my surprise) while building a dictionary to satisfy a
>> given constraint, using mkNonCanonical and solveWanteds. I don't know why
>> solveWanteds produces a HoleProv in this case and not in the many others
>> I've tried. The constraint being solved in the example I included was
>> 'HasRep (Vec ('S n_aCj7) (Key h_aCj6))', where HasRep is similar to Generic
>> (from GHC.Generics), and there is a HasRep instance for Vec ('S n x). Come
>> to think of it, the free type variable s_aD1S troubles me as well.
>>
>> I'm not terribly confident in the code I use for constructing these
>> dictionaries (setting up and calling solveWanteds) during Core-to-Core
>> transformation. Do you know of any relevant example code, docs, etc?
>>
>> Yes, I'm using -dcore-lint, as well explicitly linting each small
>> transformation step (while debugging). Doing so has been very helpful in
>> finding bugs quickly.
>>
>> Cheers, - Conal
>>
>> On Mon, Apr 4, 2016 at 2:48 AM, Simon Peyton Jones <simonpj at microsoft.com
>> > wrote:
>>
>>> Definitely a bug. All HoleProvs should be eliminated by the type checker.
>>>
>>>
>>>
>>> Did your plugin produce a HoleProv?  It definitely should not do so; see
>>> the notes with that constructor.
>>>
>>>
>>>
>>> Lint checks for this ? did you run with ?dcore-lint?
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Conal
>>> Elliott
>>> *Sent:* 02 April 2016 20:24
>>> *To:* ghc-devs at haskell.org
>>> *Subject:* "opt_univ fell into a hole"
>>>
>>>
>>>
>>> I'm getting the following error message from a GHC plugin I'm developing
>>> (note GHC version):
>>>
>>>     ghc-stage2: panic! (the 'impossible' happened)
>>>       (GHC version 8.1.20160307 for x86_64-apple-darwin):
>>>             opt_univ fell into a hole {aD1S}
>>>
>>> I don't get this error when compiling without my plugin, so I may well
>>> be violating a compiler invariant.
>>>
>>> Shortly before the error, the plugin produced the following dictionary
>>> expression, which does indeed contain a `UnivCo` with a `HoleProv`. The
>>> plugin does sometimes generate `UnivCo`s but not with `HoleProv`.
>>>
>>>     let {
>>>       $dHasRep_aD1T :: HasRep (Vec 'Z s_aD1R[fuv:0])
>>>       $dHasRep_aD1T = $fHasRepVec0 @ s_aD1R[fuv:0] } in
>>>     let {
>>>       $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR :: HasRep (Vec 'Z (Key h_aCnh))
>>>       $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR =
>>>         $dHasRep_aD1T
>>>         `cast` ((HasRep
>>>                    (Vec
>>>                       <'Z>_N
>>>                       (Sym U(hole:{aD1S}, Key h_aCnh,
>>> s_aD1R[fuv:0])_N))_N)_R
>>>                 :: HasRep (Vec 'Z s_aD1R[fuv:0])
>>>                    ~R# HasRep (Vec 'Z (Key h_aCnh))) } in
>>>     $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR
>>>
>>> Here, `Key` is a type family from `Data.Key` in the keys package, and
>>> `Vec` is a GADT of statically length-indexed lists.
>>>
>>> Suggestions?
>>>
>>> Thanks, - Conal
>>>
>>
>> _______________________________________________
>> 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/20160404/5d6c188c/attachment.html>

From rrnewton at gmail.com  Mon Apr  4 20:35:26 2016
From: rrnewton at gmail.com (Ryan Newton)
Date: Mon, 4 Apr 2016 16:35:26 -0400
Subject: [Haskell-cafe] Benchmarking harnesses for a more modern nofib?
In-Reply-To: <1459758731.1677.6.camel@joachim-breitner.de>
References: <CACYs5AYHDn-LWn1++A08xKPs4W8_WAXRac7UeH=Zg8zS82kw1w@mail.gmail.com>
 <1459758731.1677.6.camel@joachim-breitner.de>
Message-ID: <CACYs5AbeoC4xuOKtj5Ks4sNJOy+Ja05ahp==xWOcEPCs4ZNAVg@mail.gmail.com>

Great!  I'm glad to hear folks are interested.

It sounds like there is need for a better low-dependencies benchmark
suite.  I was just grepping through nofib looking for things that are
*missing* and I realized there are no uses of atomicModifyIORef, for
example.

What we're working on at Indiana right this second is not quite this
effort, but is the separate, complementary, effort to gather as much data
as possible from a large swath of packages (high dependency-count) .

Note that fibon already has bitrotted, and does not quite work any
> more. So there is some low hanging fruit in resurrecting that one.
>

Agreed.  Though I see that nofib already contains some of them.

Even though stack + GHC head loses many of stack's benefits, I think that
stack and cabal freeze should make it easier to keep things running for the
long term than it was with fibon (which bitrotted quickly).


> Another important step in that direction would be to define a common
> output for benchmark suites defined in .cabal files, so it is easier to
> set up things like http://perf.haskell.org/ghc and http://perf.haskell.
> org/binary for these projects.
>

Yes, exitcode-stdio-1.0 is useful for testing but not so much for
benchmarking.  To attempt to harvest Stackage benchmarks we were going to
just assume things are criterion and catch errors as we go.  Should we go
further and aim to standardize a new value for "type:" within benchmark
suites?

About the harness: haskell.org is currently paying a student (CCed) to
> setup a travis-like infrastructure based on gipeda (the software behind
> perf.haskell.org) that would allow library authors to very simply get
> continuous benchmark measurements. Let?s see what comes out of that!
>

What's the infrastructure that currently gathers the data for
perf.haskell.org?  Is there a repo you can point to?  (Since gipeda itself
is just the presentation layer, and something else must be running things &
gathering data.)

Cheers,
 -Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160404/0a1e444e/attachment-0001.html>

From mail at joachim-breitner.de  Mon Apr  4 20:44:04 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 04 Apr 2016 22:44:04 +0200
Subject: [Haskell-cafe] Benchmarking harnesses for a more modern nofib?
In-Reply-To: <CACYs5AbeoC4xuOKtj5Ks4sNJOy+Ja05ahp==xWOcEPCs4ZNAVg@mail.gmail.com>
References: <CACYs5AYHDn-LWn1++A08xKPs4W8_WAXRac7UeH=Zg8zS82kw1w@mail.gmail.com>
 <1459758731.1677.6.camel@joachim-breitner.de>
 <CACYs5AbeoC4xuOKtj5Ks4sNJOy+Ja05ahp==xWOcEPCs4ZNAVg@mail.gmail.com>
Message-ID: <1459802644.4559.7.camel@joachim-breitner.de>

Hi Ryan,

Am Montag, den 04.04.2016, 16:35 -0400 schrieb Ryan Newton:
> What's the infrastructure that currently gathers the data for
> perf.haskell.org?? Is there a repo you can point to? ?(Since gipeda
> itself is just the presentation layer, and something else must be
> running things & gathering data.)

the infrastructure is my office desktop computer, which I don?t use (as
I always use my laptop). There, a script? runs which polls the git
repository, looks for new revisions, builds them, and pushes the logs
to a dedicate repository on github? (which can be valuable data source
on its own!). A cron job on a virtual machine provided to me by
haskell.org polls that repository, runs gipepda, and pushes the output
onto www.haskell.org,?which serves perf.haskell.org.

Not the most sophisticated or robust setup, but it works.

Greetings,
Joachim


??https://github.com/nomeata/codespeed/blob/ghc/tools/ghc/watch.sh
(the repository location is an historical artifact, I really should
move this into the gipeda repo or somewhere else).


??https://github.com/nomeata/ghc-speed-logs
I suggest to not do a full checkout, but rather do a bare clone and use
commands like "git show" to access the files, as this repository is
huge! This is also what gipeda does.


-- 
Joachim ?nomeata? Breitner
? mail at joachim-breitner.de ? https://www.joachim-breitner.de/
? XMPP: nomeata at joachim-breitner.de?? OpenPGP-Key: 0xF0FBF51F
? Debian Developer: nomeata at debian.org

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

From eir at cis.upenn.edu  Mon Apr  4 21:00:53 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 4 Apr 2016 23:00:53 +0200
Subject: "opt_univ fell into a hole"
In-Reply-To: <CAD6SzRKUbeDz2ku3Jva3OUAFn5ojRPc+a4cGEr6f7S3E6rQUXA@mail.gmail.com>
References: <CAD6SzR+QHtCFGQfUOfM-+TNqWeYJ_4zK1EBqw3FsBU9QQUya=A@mail.gmail.com>
 <34e8d9166f8b4e078161aecfec84ba0e@DB4PR30MB030.064d.mgd.msft.net>
 <CAD6SzRK7J66_eYXxVE63FNOP++dZU3_JSd2+MftoE83LxU0hCQ@mail.gmail.com>
 <8AE0A67F-4A73-4624-BD3E-335C654104BE@cis.upenn.edu>
 <CAD6SzRKUbeDz2ku3Jva3OUAFn5ojRPc+a4cGEr6f7S3E6rQUXA@mail.gmail.com>
Message-ID: <2EDA5A23-A13C-4A3A-B920-D8CC56B44261@cis.upenn.edu>

Can't say anything about the setup to use unsafePerformIO, but I can say that, yes, you need a zonk.

You may wish to read Note [What is zonking?] in TcMType. Running your bnds through a zonkEvBinds (using an emptyZonkEnv) should help.

Also, use TcMType.newWanted to make your CtWanted. As it stands, if predTy is an equality constraint, your CtWanted will be ill-formed, as all equality constraints should have HoleDests, not EvVarDests. Using TcMType.newWanted will simplify and improve your code.

I hope this helps,
Richard

On Apr 4, 2016, at 7:16 PM, Conal Elliott <conal at conal.net> wrote:

> Hi Richard. Thanks for the tips. I haven't learned about zonking, so it may well be what I'm missing here. I'm using some inherited code that includes the following line to get bindings then used with dsEvBinds and mkCoreLets to build an expression:
> 
> >         (_wCs', bnds) <- second evBindMapBinds <$> runTcS (solveWanteds wCs)
> 
> Should I be zonking in here somewhere?
> 
> More context for this code, if helpful:
> 
> > -- | Build a dictionary for the given
> > buildDictionary' :: HscEnv -> DynFlags -> ModGuts -> Id -> (Id, [CoreBind])
> > buildDictionary' env dflags guts evar =
> >     let (i, bs) = runTcMUnsafe env dflags guts $ do
> >         loc <- getCtLocM (GivenOrigin UnkSkol) Nothing
> >         let predTy = varType evar
> >             nonC = mkNonCanonical $
> >                      CtWanted { ctev_pred = predTy, ctev_dest = EvVarDest evar
> >                               , ctev_loc = loc }
> >             wCs = mkSimpleWC [cc_ev nonC]
> >         -- TODO: Make sure solveWanteds is the right function to call.
> >         (_wCs', bnds) <- second evBindMapBinds <$> runTcS (solveWanteds wCs)
> >         -- pprTrace "buildDictionary' _wCs'" (ppr _wCs') (return ())
> >         warnAllUnsolved _wCs'
> >         return (evar, bnds)
> >     in
> >       (i, runDsMUnsafe env dflags guts (dsEvBinds bs))
> 
> where runTcMUnsafe and runDsMUnsafe use unsafePerformIO (ouch) to 
> 
> > runTcMUnsafe :: HscEnv -> DynFlags -> ModGuts -> TcM a -> a
> > runTcMUnsafe env dflags guts m = unsafePerformIO $ do
> >     -- What is the effect of HsSrcFile (should we be using something else?)
> >     -- What should the boolean flag be set to?
> >     (msgs, mr) <- initTcFromModGuts env guts HsSrcFile False m
> >     let showMsgs (warns, errs) = showSDoc dflags $ vcat
> >                                                  $    text "Errors:" : pprErrMsgBagWithLoc errs
> >                                                    ++ text "Warnings:" : pprErrMsgBagWithLoc warns
> >     maybe (fail $ showMsgs msgs) return mr
> >
> > -- TODO: Try initTcForLookup or initTcInteractive in place of initTcFromModGuts.
> > -- If successful, drop dflags and guts arguments.
> >
> > runDsMUnsafe :: HscEnv -> DynFlags -> ModGuts -> DsM a -> a
> > runDsMUnsafe env dflags guts = runTcMUnsafe env dflags guts . initDsTc
> 
> and initTcFromModGuts is something I pulled in from HERMIT.
> 
> Thanks and regards, - Conal
> 
> On Mon, Apr 4, 2016 at 9:37 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> Coercion holes (the payload of a HoleProv) get created for all wanted equality constraints (and for nothing else). If you're working over only class dictionaries, you won't encounter holes. But my guess is that your HasRep somehow induces a wanted equality. If the solver fills the hole -- as it should if the equality is solvable -- then you may just need to zonk it properly. zonkCoHole does the job, but this should be called from zonkTcTypeToType, which I imagine you're already doing.
> 
> I hope this helps,
> Richard
> 
> On Apr 4, 2016, at 6:21 PM, Conal Elliott <conal at conal.net> wrote:
> 
>> Hi Simon. Thanks for the reply. My plugin appears to produce the HoleProv indirectly (and to my surprise) while building a dictionary to satisfy a given constraint, using mkNonCanonical and solveWanteds. I don't know why solveWanteds produces a HoleProv in this case and not in the many others I've tried. The constraint being solved in the example I included was 'HasRep (Vec ('S n_aCj7) (Key h_aCj6))', where HasRep is similar to Generic (from GHC.Generics), and there is a HasRep instance for Vec ('S n x). Come to think of it, the free type variable s_aD1S troubles me as well.
>> 
>> I'm not terribly confident in the code I use for constructing these dictionaries (setting up and calling solveWanteds) during Core-to-Core transformation. Do you know of any relevant example code, docs, etc?
>> 
>> Yes, I'm using -dcore-lint, as well explicitly linting each small transformation step (while debugging). Doing so has been very helpful in finding bugs quickly.
>> 
>> Cheers, - Conal
>> 
>> On Mon, Apr 4, 2016 at 2:48 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>> Definitely a bug. All HoleProvs should be eliminated by the type checker.
>> 
>>  
>> 
>> Did your plugin produce a HoleProv?  It definitely should not do so; see the notes with that constructor.
>> 
>>  
>> 
>> Lint checks for this ? did you run with ?dcore-lint?
>> 
>>  
>> 
>> Simon
>> 
>>  
>> 
>> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal Elliott
>> Sent: 02 April 2016 20:24
>> To: ghc-devs at haskell.org
>> Subject: "opt_univ fell into a hole"
>> 
>>  
>> 
>> I'm getting the following error message from a GHC plugin I'm developing (note GHC version):
>> 
>>     ghc-stage2: panic! (the 'impossible' happened)
>>       (GHC version 8.1.20160307 for x86_64-apple-darwin):
>>             opt_univ fell into a hole {aD1S}
>> 
>> I don't get this error when compiling without my plugin, so I may well be violating a compiler invariant.
>> 
>> Shortly before the error, the plugin produced the following dictionary expression, which does indeed contain a `UnivCo` with a `HoleProv`. The plugin does sometimes generate `UnivCo`s but not with `HoleProv`.
>> 
>>     let {
>>       $dHasRep_aD1T :: HasRep (Vec 'Z s_aD1R[fuv:0])
>>       $dHasRep_aD1T = $fHasRepVec0 @ s_aD1R[fuv:0] } in
>>     let {
>>       $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR :: HasRep (Vec 'Z (Key h_aCnh))
>>       $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR =
>>         $dHasRep_aD1T
>>         `cast` ((HasRep
>>                    (Vec
>>                       <'Z>_N
>>                       (Sym U(hole:{aD1S}, Key h_aCnh, s_aD1R[fuv:0])_N))_N)_R
>>                 :: HasRep (Vec 'Z s_aD1R[fuv:0])
>>                    ~R# HasRep (Vec 'Z (Key h_aCnh))) } in
>>     $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR
>> 
>> Here, `Key` is a type family from `Data.Key` in the keys package, and `Vec` is a GADT of statically length-indexed lists.
>> 
>> Suggestions?
>> 
>> Thanks, - Conal
>> 
>> 
>> _______________________________________________
>> 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/20160404/62868bf2/attachment.html>

From conal at conal.net  Mon Apr  4 21:56:34 2016
From: conal at conal.net (Conal Elliott)
Date: Mon, 4 Apr 2016 14:56:34 -0700
Subject: "opt_univ fell into a hole"
In-Reply-To: <2EDA5A23-A13C-4A3A-B920-D8CC56B44261@cis.upenn.edu>
References: <CAD6SzR+QHtCFGQfUOfM-+TNqWeYJ_4zK1EBqw3FsBU9QQUya=A@mail.gmail.com>
 <34e8d9166f8b4e078161aecfec84ba0e@DB4PR30MB030.064d.mgd.msft.net>
 <CAD6SzRK7J66_eYXxVE63FNOP++dZU3_JSd2+MftoE83LxU0hCQ@mail.gmail.com>
 <8AE0A67F-4A73-4624-BD3E-335C654104BE@cis.upenn.edu>
 <CAD6SzRKUbeDz2ku3Jva3OUAFn5ojRPc+a4cGEr6f7S3E6rQUXA@mail.gmail.com>
 <2EDA5A23-A13C-4A3A-B920-D8CC56B44261@cis.upenn.edu>
Message-ID: <CAD6SzRLoyV=6=N4-CTYcwm0FQRyYRkCEaSXXEMSdD-Cyo1TZpg@mail.gmail.com>

Thanks, Richard!  Unfortunately, zonkEvBinds is not exported from TcHsSyn.
Do you think there's another route to zonking that could work for my
circumstances?  - Conal


On Mon, Apr 4, 2016 at 2:00 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> Can't say anything about the setup to use unsafePerformIO, but I can say
> that, yes, you need a zonk.
>
> You may wish to read Note [What is zonking?] in TcMType. Running your bnds
> through a zonkEvBinds (using an emptyZonkEnv) should help.
>
> Also, use TcMType.newWanted to make your CtWanted. As it stands, if predTy
> is an equality constraint, your CtWanted will be ill-formed, as all
> equality constraints should have HoleDests, not EvVarDests. Using
> TcMType.newWanted will simplify and improve your code.
>
> I hope this helps,
> Richard
>
> On Apr 4, 2016, at 7:16 PM, Conal Elliott <conal at conal.net> wrote:
>
> Hi Richard. Thanks for the tips. I haven't learned about zonking, so it
> may well be what I'm missing here. I'm using some inherited code that
> includes the following line to get bindings then used with dsEvBinds and
> mkCoreLets to build an expression:
>
> >         (_wCs', bnds) <- second evBindMapBinds <$> runTcS (solveWanteds
> wCs)
>
> Should I be zonking in here somewhere?
>
> More context for this code, if helpful:
>
> > -- | Build a dictionary for the given
> > buildDictionary' :: HscEnv -> DynFlags -> ModGuts -> Id -> (Id,
> [CoreBind])
> > buildDictionary' env dflags guts evar =
> >     let (i, bs) = runTcMUnsafe env dflags guts $ do
> >         loc <- getCtLocM (GivenOrigin UnkSkol) Nothing
> >         let predTy = varType evar
> >             nonC = mkNonCanonical $
> >                      CtWanted { ctev_pred = predTy, ctev_dest =
> EvVarDest evar
> >                               , ctev_loc = loc }
> >             wCs = mkSimpleWC [cc_ev nonC]
> >         -- TODO: Make sure solveWanteds is the right function to call.
> >         (_wCs', bnds) <- second evBindMapBinds <$> runTcS (solveWanteds
> wCs)
> >         -- pprTrace "buildDictionary' _wCs'" (ppr _wCs') (return ())
> >         warnAllUnsolved _wCs'
> >         return (evar, bnds)
> >     in
> >       (i, runDsMUnsafe env dflags guts (dsEvBinds bs))
>
> where runTcMUnsafe and runDsMUnsafe use unsafePerformIO (ouch) to
>
> > runTcMUnsafe :: HscEnv -> DynFlags -> ModGuts -> TcM a -> a
> > runTcMUnsafe env dflags guts m = unsafePerformIO $ do
> >     -- What is the effect of HsSrcFile (should we be using something
> else?)
> >     -- What should the boolean flag be set to?
> >     (msgs, mr) <- initTcFromModGuts env guts HsSrcFile False m
> >     let showMsgs (warns, errs) = showSDoc dflags $ vcat
> >                                                  $    text "Errors:" :
> pprErrMsgBagWithLoc errs
> >                                                    ++ text "Warnings:" :
> pprErrMsgBagWithLoc warns
> >     maybe (fail $ showMsgs msgs) return mr
> >
> > -- TODO: Try initTcForLookup or initTcInteractive in place of
> initTcFromModGuts.
> > -- If successful, drop dflags and guts arguments.
> >
> > runDsMUnsafe :: HscEnv -> DynFlags -> ModGuts -> DsM a -> a
> > runDsMUnsafe env dflags guts = runTcMUnsafe env dflags guts . initDsTc
>
> and initTcFromModGuts is something I pulled in from HERMIT.
>
> Thanks and regards, - Conal
>
> On Mon, Apr 4, 2016 at 9:37 AM, Richard Eisenberg <eir at cis.upenn.edu>
> wrote:
>
>> Coercion holes (the payload of a HoleProv) get created for all wanted
>> equality constraints (and for nothing else). If you're working over only
>> class dictionaries, you won't encounter holes. But my guess is that your
>> HasRep somehow induces a wanted equality. If the solver fills the hole --
>> as it should if the equality is solvable -- then you may just need to zonk
>> it properly. zonkCoHole does the job, but this should be called from
>> zonkTcTypeToType, which I imagine you're already doing.
>>
>> I hope this helps,
>> Richard
>>
>> On Apr 4, 2016, at 6:21 PM, Conal Elliott <conal at conal.net> wrote:
>>
>> Hi Simon. Thanks for the reply. My plugin appears to produce the HoleProv
>> indirectly (and to my surprise) while building a dictionary to satisfy a
>> given constraint, using mkNonCanonical and solveWanteds. I don't know why
>> solveWanteds produces a HoleProv in this case and not in the many others
>> I've tried. The constraint being solved in the example I included was
>> 'HasRep (Vec ('S n_aCj7) (Key h_aCj6))', where HasRep is similar to Generic
>> (from GHC.Generics), and there is a HasRep instance for Vec ('S n x). Come
>> to think of it, the free type variable s_aD1S troubles me as well.
>>
>> I'm not terribly confident in the code I use for constructing these
>> dictionaries (setting up and calling solveWanteds) during Core-to-Core
>> transformation. Do you know of any relevant example code, docs, etc?
>>
>> Yes, I'm using -dcore-lint, as well explicitly linting each small
>> transformation step (while debugging). Doing so has been very helpful in
>> finding bugs quickly.
>>
>> Cheers, - Conal
>>
>> On Mon, Apr 4, 2016 at 2:48 AM, Simon Peyton Jones <simonpj at microsoft.com
>> > wrote:
>>
>>> Definitely a bug. All HoleProvs should be eliminated by the type checker.
>>>
>>>
>>>
>>> Did your plugin produce a HoleProv?  It definitely should not do so; see
>>> the notes with that constructor.
>>>
>>>
>>>
>>> Lint checks for this ? did you run with ?dcore-lint?
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Conal
>>> Elliott
>>> *Sent:* 02 April 2016 20:24
>>> *To:* ghc-devs at haskell.org
>>> *Subject:* "opt_univ fell into a hole"
>>>
>>>
>>>
>>> I'm getting the following error message from a GHC plugin I'm developing
>>> (note GHC version):
>>>
>>>     ghc-stage2: panic! (the 'impossible' happened)
>>>       (GHC version 8.1.20160307 for x86_64-apple-darwin):
>>>             opt_univ fell into a hole {aD1S}
>>>
>>> I don't get this error when compiling without my plugin, so I may well
>>> be violating a compiler invariant.
>>>
>>> Shortly before the error, the plugin produced the following dictionary
>>> expression, which does indeed contain a `UnivCo` with a `HoleProv`. The
>>> plugin does sometimes generate `UnivCo`s but not with `HoleProv`.
>>>
>>>     let {
>>>       $dHasRep_aD1T :: HasRep (Vec 'Z s_aD1R[fuv:0])
>>>       $dHasRep_aD1T = $fHasRepVec0 @ s_aD1R[fuv:0] } in
>>>     let {
>>>       $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR :: HasRep (Vec 'Z (Key h_aCnh))
>>>       $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR =
>>>         $dHasRep_aD1T
>>>         `cast` ((HasRep
>>>                    (Vec
>>>                       <'Z>_N
>>>                       (Sym U(hole:{aD1S}, Key h_aCnh,
>>> s_aD1R[fuv:0])_N))_N)_R
>>>                 :: HasRep (Vec 'Z s_aD1R[fuv:0])
>>>                    ~R# HasRep (Vec 'Z (Key h_aCnh))) } in
>>>     $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR
>>>
>>> Here, `Key` is a type family from `Data.Key` in the keys package, and
>>> `Vec` is a GADT of statically length-indexed lists.
>>>
>>> Suggestions?
>>>
>>> Thanks, - Conal
>>>
>>
>> _______________________________________________
>> 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/20160404/ec3b9b5b/attachment-0001.html>

From matthewtpickering at gmail.com  Mon Apr  4 23:25:49 2016
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Tue, 5 Apr 2016 00:25:49 +0100
Subject: Feature development
In-Reply-To: <2BEDC7D9-D184-436D-9EAF-F2214CB6AD60@gmail.com>
References: <2BEDC7D9-D184-436D-9EAF-F2214CB6AD60@gmail.com>
Message-ID: <CALuQ0m-NAGfOVL4qGDy_76Ks=SqW1FE1Se-vd_baRcm0Dmi=cg@mail.gmail.com>

Hello Nikita,

I don't know the answers to your questions but I do know that it's
easier to give help if there is some code to look at. I would suggest
you put a diff up on phab with what you have done so far so that it is
easy for others to give specific comments about where you are stuck.

Matt

On Mon, Apr 4, 2016 at 7:22 PM, Sazanovich Nikita
<nikitasazanovich at gmail.com> wrote:
>   Hello!
>   I am working on ticket https://ghc.haskell.org/trac/ghc/ticket/5850 now.
> I?ve come upon converting the type, which GHC.compileExpr returns, to my
> prompt function type [PModule] -> Int -> IO String. But this function
> returns ghc-prim-0.5.0.0:GHC.Prim.Any. I don?t see a clear way to convert
> it. So my questions are:
> - What this type is about? I know Any type in Haskell. Is it a specific
> version of it?
> - Or maybe it is not the best way to check a function correctness? I?ve
> checked out InteractiveEval module and it seems that there are only four
> quite similar functions to compile Expressions.
>   Last person, who was trying to solve this problem, used Unsafe.Coerce and
> it is also doing this job pretty well now, but the name speaks for itself.
>   Thank you.
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From carter.schonwald at gmail.com  Tue Apr  5 00:54:58 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 4 Apr 2016 20:54:58 -0400
Subject: whats the current state of runtime rep for ghc 8 onwards?
Message-ID: <CAHYVw0w-C4r+7F2T4FYcC8=XHFLApFYrtjMmxA0pHfsRr3GzAA@mail.gmail.com>

i was reading https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds
and looking at some of the applicable code, and it looks like i can't
quantify over ptr-y heap values that may or may not be lifted, at least
with the current state of play, is this correct?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160404/658a97ae/attachment.html>

From sgraf1337 at gmail.com  Tue Apr  5 07:10:41 2016
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Tue, 5 Apr 2016 00:10:41 -0700 (PDT)
Subject: [Haskell-cafe] Benchmarking harnesses for a more modern nofib?
In-Reply-To: <CACYs5AbeoC4xuOKtj5Ks4sNJOy+Ja05ahp==xWOcEPCs4ZNAVg@mail.gmail.com>
References: <CACYs5AYHDn-LWn1++A08xKPs4W8_WAXRac7UeH=Zg8zS82kw1w@mail.gmail.com>
 <1459758731.1677.6.camel@joachim-breitner.de>
 <CACYs5AbeoC4xuOKtj5Ks4sNJOy+Ja05ahp==xWOcEPCs4ZNAVg@mail.gmail.com>
Message-ID: <8a52fe4b-b66c-4d2b-9e60-b80fb75a18e0@googlegroups.com>

(sorry for duplicates, realized I couldn't post to the mailing list without 
registering)

Hi Ryan,

I'm the student working on the CI part Joachim mentioned. It's not quite 
there yet, but the ground work is done. 

Basically, I'm writing a daemon that will read a config file for a list of 
git repositories, maintain periodically updated clones for them and execute 
a benchmark script on new (Repository, Commit) pairs, after which gipeda is 
(re-)run, so that might be exactly what you are looking for. 

You can find the current code at https://github.com/sgraf812/feed-gipeda. 
There are still some rough edges (not on Hackage yet, somewhat laborious 
setup) and documentation is somewhat incomplete, but you can always leave 
me a mail if you get stuck while setting it up. Also, documentation etc. 
should come within the next week.

I'll CC you in the mail thread where we discuss things, if you don't mind.

Regards,
Sebastian

On Monday, 4 April 2016 22:35:56 UTC+2, Ryan Newton wrote:
>
> Great!  I'm glad to hear folks are interested.  
>
> It sounds like there is need for a better low-dependencies benchmark 
> suite.  I was just grepping through nofib looking for things that are 
> *missing* and I realized there are no uses of atomicModifyIORef, for 
> example.
>
> What we're working on at Indiana right this second is not quite this 
> effort, but is the separate, complementary, effort to gather as much data 
> as possible from a large swath of packages (high dependency-count) .
>
> Note that fibon already has bitrotted, and does not quite work any
>> more. So there is some low hanging fruit in resurrecting that one.
>>
>
> Agreed.  Though I see that nofib already contains some of them.  
>
> Even though stack + GHC head loses many of stack's benefits, I think that 
> stack and cabal freeze should make it easier to keep things running for the 
> long term than it was with fibon (which bitrotted quickly).
>  
>
>> Another important step in that direction would be to define a common
>> output for benchmark suites defined in .cabal files, so it is easier to
>> set up things like http://perf.haskell.org/ghc and http://perf.haskell.
>> org/binary for these projects.
>>
>
> Yes, exitcode-stdio-1.0 is useful for testing but not so much for 
> benchmarking.  To attempt to harvest Stackage benchmarks we were going to 
> just assume things are criterion and catch errors as we go.  Should we go 
> further and aim to standardize a new value for "type:" within benchmark 
> suites?
>
> About the harness: haskell.org is currently paying a student (CCed) to
>> setup a travis-like infrastructure based on gipeda (the software behind
>> perf.haskell.org) that would allow library authors to very simply get
>> continuous benchmark measurements. Let?s see what comes out of that!
>>
>
> What's the infrastructure that currently gathers the data for 
> perf.haskell.org?  Is there a repo you can point to?  (Since gipeda 
> itself is just the presentation layer, and something else must be running 
> things & gathering data.)
>
> Cheers,
>  -Ryan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160405/4530aa49/attachment.html>

From eir at cis.upenn.edu  Tue Apr  5 07:44:39 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 5 Apr 2016 09:44:39 +0200
Subject: whats the current state of runtime rep for ghc 8 onwards?
In-Reply-To: <CAHYVw0w-C4r+7F2T4FYcC8=XHFLApFYrtjMmxA0pHfsRr3GzAA@mail.gmail.com>
References: <CAHYVw0w-C4r+7F2T4FYcC8=XHFLApFYrtjMmxA0pHfsRr3GzAA@mail.gmail.com>
Message-ID: <AC376F41-BBDD-4B7B-82FC-083225ABDB51@cis.upenn.edu>

Yes, that's correct. The RuntimeRep story generally allows for such polymorphism in the future, but it's not implemented yet. One concern is that doing this would require RuntimeRep to look like

> data Levity = Lifted | Unlifted
> data RuntimeRep = PtrRep Levity | IntRep | VoidRep | ...

The problem here is that, in the vastly common case of kind *, this requires an extra indirection. I actually implemented this, and indeed the performance of GHC decreased. Given that we have no way, yet, to take advantage of the kind of polymorphism you seek, I flattened the structure of RuntimeRep in order to get a modest but consistent performance boost.

So I'm, personally, very open to this direction of travel, but we have to work out both how the polymorphism should work and how to implement this without degrading performance.

Richard

On Apr 5, 2016, at 2:54 AM, Carter Schonwald <carter.schonwald at gmail.com> wrote:

> i was reading https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds
> and looking at some of the applicable code, and it looks like i can't quantify over ptr-y heap values that may or may not be lifted, at least with the current state of play, is this correct?
> _______________________________________________
> 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/20160405/3a644698/attachment.html>

From eir at cis.upenn.edu  Tue Apr  5 07:55:59 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 5 Apr 2016 09:55:59 +0200
Subject: "opt_univ fell into a hole"
In-Reply-To: <CAD6SzRLoyV=6=N4-CTYcwm0FQRyYRkCEaSXXEMSdD-Cyo1TZpg@mail.gmail.com>
References: <CAD6SzR+QHtCFGQfUOfM-+TNqWeYJ_4zK1EBqw3FsBU9QQUya=A@mail.gmail.com>
 <34e8d9166f8b4e078161aecfec84ba0e@DB4PR30MB030.064d.mgd.msft.net>
 <CAD6SzRK7J66_eYXxVE63FNOP++dZU3_JSd2+MftoE83LxU0hCQ@mail.gmail.com>
 <8AE0A67F-4A73-4624-BD3E-335C654104BE@cis.upenn.edu>
 <CAD6SzRKUbeDz2ku3Jva3OUAFn5ojRPc+a4cGEr6f7S3E6rQUXA@mail.gmail.com>
 <2EDA5A23-A13C-4A3A-B920-D8CC56B44261@cis.upenn.edu>
 <CAD6SzRLoyV=6=N4-CTYcwm0FQRyYRkCEaSXXEMSdD-Cyo1TZpg@mail.gmail.com>
Message-ID: <6308DA27-B051-4B32-BFD8-A2E159F23186@cis.upenn.edu>

No -- that's the one you want. Either wrap your EvBinds in some structure that you can zonk, or submit a patch exporting zonkEvBinds. :)

Richard

On Apr 4, 2016, at 11:56 PM, Conal Elliott <conal at conal.net> wrote:

> Thanks, Richard!  Unfortunately, zonkEvBinds is not exported from TcHsSyn. Do you think there's another route to zonking that could work for my circumstances?  - Conal
> 
> 
> On Mon, Apr 4, 2016 at 2:00 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> Can't say anything about the setup to use unsafePerformIO, but I can say that, yes, you need a zonk.
> 
> You may wish to read Note [What is zonking?] in TcMType. Running your bnds through a zonkEvBinds (using an emptyZonkEnv) should help.
> 
> Also, use TcMType.newWanted to make your CtWanted. As it stands, if predTy is an equality constraint, your CtWanted will be ill-formed, as all equality constraints should have HoleDests, not EvVarDests. Using TcMType.newWanted will simplify and improve your code.
> 
> I hope this helps,
> Richard
> 
> On Apr 4, 2016, at 7:16 PM, Conal Elliott <conal at conal.net> wrote:
> 
>> Hi Richard. Thanks for the tips. I haven't learned about zonking, so it may well be what I'm missing here. I'm using some inherited code that includes the following line to get bindings then used with dsEvBinds and mkCoreLets to build an expression:
>> 
>> >         (_wCs', bnds) <- second evBindMapBinds <$> runTcS (solveWanteds wCs)
>> 
>> Should I be zonking in here somewhere?
>> 
>> More context for this code, if helpful:
>> 
>> > -- | Build a dictionary for the given
>> > buildDictionary' :: HscEnv -> DynFlags -> ModGuts -> Id -> (Id, [CoreBind])
>> > buildDictionary' env dflags guts evar =
>> >     let (i, bs) = runTcMUnsafe env dflags guts $ do
>> >         loc <- getCtLocM (GivenOrigin UnkSkol) Nothing
>> >         let predTy = varType evar
>> >             nonC = mkNonCanonical $
>> >                      CtWanted { ctev_pred = predTy, ctev_dest = EvVarDest evar
>> >                               , ctev_loc = loc }
>> >             wCs = mkSimpleWC [cc_ev nonC]
>> >         -- TODO: Make sure solveWanteds is the right function to call.
>> >         (_wCs', bnds) <- second evBindMapBinds <$> runTcS (solveWanteds wCs)
>> >         -- pprTrace "buildDictionary' _wCs'" (ppr _wCs') (return ())
>> >         warnAllUnsolved _wCs'
>> >         return (evar, bnds)
>> >     in
>> >       (i, runDsMUnsafe env dflags guts (dsEvBinds bs))
>> 
>> where runTcMUnsafe and runDsMUnsafe use unsafePerformIO (ouch) to 
>> 
>> > runTcMUnsafe :: HscEnv -> DynFlags -> ModGuts -> TcM a -> a
>> > runTcMUnsafe env dflags guts m = unsafePerformIO $ do
>> >     -- What is the effect of HsSrcFile (should we be using something else?)
>> >     -- What should the boolean flag be set to?
>> >     (msgs, mr) <- initTcFromModGuts env guts HsSrcFile False m
>> >     let showMsgs (warns, errs) = showSDoc dflags $ vcat
>> >                                                  $    text "Errors:" : pprErrMsgBagWithLoc errs
>> >                                                    ++ text "Warnings:" : pprErrMsgBagWithLoc warns
>> >     maybe (fail $ showMsgs msgs) return mr
>> >
>> > -- TODO: Try initTcForLookup or initTcInteractive in place of initTcFromModGuts.
>> > -- If successful, drop dflags and guts arguments.
>> >
>> > runDsMUnsafe :: HscEnv -> DynFlags -> ModGuts -> DsM a -> a
>> > runDsMUnsafe env dflags guts = runTcMUnsafe env dflags guts . initDsTc
>> 
>> and initTcFromModGuts is something I pulled in from HERMIT.
>> 
>> Thanks and regards, - Conal
>> 
>> On Mon, Apr 4, 2016 at 9:37 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>> Coercion holes (the payload of a HoleProv) get created for all wanted equality constraints (and for nothing else). If you're working over only class dictionaries, you won't encounter holes. But my guess is that your HasRep somehow induces a wanted equality. If the solver fills the hole -- as it should if the equality is solvable -- then you may just need to zonk it properly. zonkCoHole does the job, but this should be called from zonkTcTypeToType, which I imagine you're already doing.
>> 
>> I hope this helps,
>> Richard
>> 
>> On Apr 4, 2016, at 6:21 PM, Conal Elliott <conal at conal.net> wrote:
>> 
>>> Hi Simon. Thanks for the reply. My plugin appears to produce the HoleProv indirectly (and to my surprise) while building a dictionary to satisfy a given constraint, using mkNonCanonical and solveWanteds. I don't know why solveWanteds produces a HoleProv in this case and not in the many others I've tried. The constraint being solved in the example I included was 'HasRep (Vec ('S n_aCj7) (Key h_aCj6))', where HasRep is similar to Generic (from GHC.Generics), and there is a HasRep instance for Vec ('S n x). Come to think of it, the free type variable s_aD1S troubles me as well.
>>> 
>>> I'm not terribly confident in the code I use for constructing these dictionaries (setting up and calling solveWanteds) during Core-to-Core transformation. Do you know of any relevant example code, docs, etc?
>>> 
>>> Yes, I'm using -dcore-lint, as well explicitly linting each small transformation step (while debugging). Doing so has been very helpful in finding bugs quickly.
>>> 
>>> Cheers, - Conal
>>> 
>>> On Mon, Apr 4, 2016 at 2:48 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>>> Definitely a bug. All HoleProvs should be eliminated by the type checker.
>>> 
>>>  
>>> 
>>> Did your plugin produce a HoleProv?  It definitely should not do so; see the notes with that constructor.
>>> 
>>>  
>>> 
>>> Lint checks for this ? did you run with ?dcore-lint?
>>> 
>>>  
>>> 
>>> Simon
>>> 
>>>  
>>> 
>>> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Conal Elliott
>>> Sent: 02 April 2016 20:24
>>> To: ghc-devs at haskell.org
>>> Subject: "opt_univ fell into a hole"
>>> 
>>>  
>>> 
>>> I'm getting the following error message from a GHC plugin I'm developing (note GHC version):
>>> 
>>>     ghc-stage2: panic! (the 'impossible' happened)
>>>       (GHC version 8.1.20160307 for x86_64-apple-darwin):
>>>             opt_univ fell into a hole {aD1S}
>>> 
>>> I don't get this error when compiling without my plugin, so I may well be violating a compiler invariant.
>>> 
>>> Shortly before the error, the plugin produced the following dictionary expression, which does indeed contain a `UnivCo` with a `HoleProv`. The plugin does sometimes generate `UnivCo`s but not with `HoleProv`.
>>> 
>>>     let {
>>>       $dHasRep_aD1T :: HasRep (Vec 'Z s_aD1R[fuv:0])
>>>       $dHasRep_aD1T = $fHasRepVec0 @ s_aD1R[fuv:0] } in
>>>     let {
>>>       $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR :: HasRep (Vec 'Z (Key h_aCnh))
>>>       $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR =
>>>         $dHasRep_aD1T
>>>         `cast` ((HasRep
>>>                    (Vec
>>>                       <'Z>_N
>>>                       (Sym U(hole:{aD1S}, Key h_aCnh, s_aD1R[fuv:0])_N))_N)_R
>>>                 :: HasRep (Vec 'Z s_aD1R[fuv:0])
>>>                    ~R# HasRep (Vec 'Z (Key h_aCnh))) } in
>>>     $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR
>>> 
>>> Here, `Key` is a type family from `Data.Key` in the keys package, and `Vec` is a GADT of statically length-indexed lists.
>>> 
>>> Suggestions?
>>> 
>>> Thanks, - Conal
>>> 
>>> 
>>> _______________________________________________
>>> 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/20160405/d48097b0/attachment-0001.html>

From dominic at steinitz.org  Tue Apr  5 09:44:45 2016
From: dominic at steinitz.org (Dominic Steinitz)
Date: Tue, 5 Apr 2016 09:44:45 +0000 (UTC)
Subject: Benchmarking harnesses for a more modern nofib?
References: <CACYs5AYHDn-LWn1++A08xKPs4W8_WAXRac7UeH=Zg8zS82kw1w@mail.gmail.com>
Message-ID: <loom.20160405T113937-69@post.gmane.org>

Ryan Newton <rrnewton <at> gmail.com> writes:

>  Hi all, Is anyone currently working in, or interested in helping
> with, a new benchmark suite for Haskell?? Perhaps, packaging up
> existing apps and app benchmarks into a new benchmark suite that
> gives a broad picture of Haskell application performance today?

I am very interested. I recently encountered a serious performance
regression from 7.8 to 7.10 which seems to be fixed in 8.0. Now it's
not clear whether this was a library change or ghc itself. I suspect
the latter but given the performance is better in 8.0, I was not
motivated to confirm this.

I am happy to wrap up my example in whatever format but note that it
does pull in quite a few libraries.

Dominic.

From carter.schonwald at gmail.com  Tue Apr  5 13:55:08 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 5 Apr 2016 09:55:08 -0400
Subject: whats the current state of runtime rep for ghc 8 onwards?
In-Reply-To: <AC376F41-BBDD-4B7B-82FC-083225ABDB51@cis.upenn.edu>
References: <CAHYVw0w-C4r+7F2T4FYcC8=XHFLApFYrtjMmxA0pHfsRr3GzAA@mail.gmail.com>
 <AC376F41-BBDD-4B7B-82FC-083225ABDB51@cis.upenn.edu>
Message-ID: <CAHYVw0zK_V+gepfGnBnQ7uVXV815b_r2hMhicXtDyNkBgTpbFA@mail.gmail.com>

So in the mean time , if I want write a data type that's polymorphic over
types that are heap pointer represented, I'll need to use a kind type class
to bound my polymorphism? I'm interested in trying To understand if this
lets me quantify over ptry structures safely.

@ed, does any of this have an impact or relevance to your structs lib
experiment you were sharing at Icfp?

On Tuesday, April 5, 2016, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> Yes, that's correct. The RuntimeRep story generally allows for such
> polymorphism in the future, but it's not implemented yet. One concern is
> that doing this would require RuntimeRep to look like
>
> data Levity = Lifted | Unlifted
> data RuntimeRep = PtrRep Levity | IntRep | VoidRep | ...
>
>
> The problem here is that, in the vastly common case of kind *, this
> requires an extra indirection. I actually implemented this, and indeed the
> performance of GHC decreased. Given that we have no way, yet, to take
> advantage of the kind of polymorphism you seek, I flattened the structure
> of RuntimeRep in order to get a modest but consistent performance boost.
>
> So I'm, personally, very open to this direction of travel, but we have to
> work out both how the polymorphism should work and how to implement this
> without degrading performance.
>
> Richard
>
> On Apr 5, 2016, at 2:54 AM, Carter Schonwald <carter.schonwald at gmail.com
> <javascript:_e(%7B%7D,'cvml','carter.schonwald at gmail.com');>> wrote:
>
> i was reading https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds
> and looking at some of the applicable code, and it looks like i can't
> quantify over ptr-y heap values that may or may not be lifted, at least
> with the current state of play, is this correct?
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> <javascript:_e(%7B%7D,'cvml','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/20160405/801c7325/attachment.html>

From eir at cis.upenn.edu  Tue Apr  5 14:51:39 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 5 Apr 2016 16:51:39 +0200
Subject: whats the current state of runtime rep for ghc 8 onwards?
In-Reply-To: <CAHYVw0zK_V+gepfGnBnQ7uVXV815b_r2hMhicXtDyNkBgTpbFA@mail.gmail.com>
References: <CAHYVw0w-C4r+7F2T4FYcC8=XHFLApFYrtjMmxA0pHfsRr3GzAA@mail.gmail.com>
 <AC376F41-BBDD-4B7B-82FC-083225ABDB51@cis.upenn.edu>
 <CAHYVw0zK_V+gepfGnBnQ7uVXV815b_r2hMhicXtDyNkBgTpbFA@mail.gmail.com>
Message-ID: <4E744D19-19EA-4921-9752-B3FFF9EE9A86@cis.upenn.edu>

In the mean time, there is simply no way to do what you want. GHC 8 disallows any variable whose type has a representation that contains any type variables. Otherwise, GHC cannot be sure that the variable has a sensible runtime representation.

Richard

On Apr 5, 2016, at 3:55 PM, Carter Schonwald <carter.schonwald at gmail.com> wrote:

> So in the mean time , if I want write a data type that's polymorphic over types that are heap pointer represented, I'll need to use a kind type class to bound my polymorphism? I'm interested in trying To understand if this lets me quantify over ptry structures safely.  
> 
> @ed, does any of this have an impact or relevance to your structs lib experiment you were sharing at Icfp?
> 
> On Tuesday, April 5, 2016, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> Yes, that's correct. The RuntimeRep story generally allows for such polymorphism in the future, but it's not implemented yet. One concern is that doing this would require RuntimeRep to look like
> 
>> data Levity = Lifted | Unlifted
>> data RuntimeRep = PtrRep Levity | IntRep | VoidRep | ...
> 
> The problem here is that, in the vastly common case of kind *, this requires an extra indirection. I actually implemented this, and indeed the performance of GHC decreased. Given that we have no way, yet, to take advantage of the kind of polymorphism you seek, I flattened the structure of RuntimeRep in order to get a modest but consistent performance boost.
> 
> So I'm, personally, very open to this direction of travel, but we have to work out both how the polymorphism should work and how to implement this without degrading performance.
> 
> Richard
> 
> On Apr 5, 2016, at 2:54 AM, Carter Schonwald <carter.schonwald at gmail.com> wrote:
> 
>> i was reading https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds
>> and looking at some of the applicable code, and it looks like i can't quantify over ptr-y heap values that may or may not be lifted, at least with the current state of play, is this correct?
>> _______________________________________________
>> 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/20160405/8abcbdca/attachment.html>

From carter.schonwald at gmail.com  Tue Apr  5 15:59:30 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 5 Apr 2016 11:59:30 -0400
Subject: Benchmarking harnesses for a more modern nofib?
In-Reply-To: <loom.20160405T113937-69@post.gmane.org>
References: <CACYs5AYHDn-LWn1++A08xKPs4W8_WAXRac7UeH=Zg8zS82kw1w@mail.gmail.com>
 <loom.20160405T113937-69@post.gmane.org>
Message-ID: <CAHYVw0xurJX5CG7nw24zx-ZPo-CJeztgZE1u3sL-vtWhwe3uOw@mail.gmail.com>

The cause of the initial blowup was adding the vector test suite to the
normal cabal file, in both 0O and O2 forms.  This was done so that fusion
rules based bugs wouldn't lie in hiding for years.

It sounds like the issues that resulted in built blowup are fixed in 8.0.
My guess is it's a combination of some type class coercion / equality
manipulation getting better plus other improvements in 8.0, both.

On Tuesday, April 5, 2016, Dominic Steinitz <dominic at steinitz.org> wrote:

> Ryan Newton <rrnewton <at> gmail.com> writes:
>
> >  Hi all, Is anyone currently working in, or interested in helping
> > with, a new benchmark suite for Haskell?  Perhaps, packaging up
> > existing apps and app benchmarks into a new benchmark suite that
> > gives a broad picture of Haskell application performance today?
>
> I am very interested. I recently encountered a serious performance
> regression from 7.8 to 7.10 which seems to be fixed in 8.0. Now it's
> not clear whether this was a library change or ghc itself. I suspect
> the latter but given the performance is better in 8.0, I was not
> motivated to confirm this.
>
> I am happy to wrap up my example in whatever format but note that it
> does pull in quite a few libraries.
>
> Dominic.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <javascript:;>
> 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/20160405/7a1ed762/attachment.html>

From nikitasazanovich at gmail.com  Tue Apr  5 17:58:29 2016
From: nikitasazanovich at gmail.com (Sazanovich Nikita)
Date: Tue, 5 Apr 2016 20:58:29 +0300
Subject: Feature development
In-Reply-To: <CALuQ0m-NAGfOVL4qGDy_76Ks=SqW1FE1Se-vd_baRcm0Dmi=cg@mail.gmail.com>
References: <2BEDC7D9-D184-436D-9EAF-F2214CB6AD60@gmail.com>
 <CALuQ0m-NAGfOVL4qGDy_76Ks=SqW1FE1Se-vd_baRcm0Dmi=cg@mail.gmail.com>
Message-ID: <9F5E10E9-06BB-4B5D-BA39-17CF023D8B12@gmail.com>

Thanks for your reply, Matthew.

I?ve tried to merge my local repository with ghc/master branch and after this I couldn't build it (even checked out to a successful commit). I am getting  this kind of error.

Undefined symbols for architecture x86_64:
"_stg_sel_17_upd_info", referenced from:
_s1yAM_info in UI.dyn_o
_s1yC7_info in UI.dyn_o
_s1yKD_info in UI.dyn_o
_s1yLa_info in UI.dyn_o

It seems like something specific to OS X. Can you help me?

> On 05 Apr 2016, at 2:25 AM, Matthew Pickering <matthewtpickering at gmail.com> wrote:
> 
> Hello Nikita,
> 
> I don't know the answers to your questions but I do know that it's
> easier to give help if there is some code to look at. I would suggest
> you put a diff up on phab with what you have done so far so that it is
> easy for others to give specific comments about where you are stuck.
> 
> Matt
> 
> On Mon, Apr 4, 2016 at 7:22 PM, Sazanovich Nikita
> <nikitasazanovich at gmail.com> wrote:
>>  Hello!
>>  I am working on ticket https://ghc.haskell.org/trac/ghc/ticket/5850 now.
>> I?ve come upon converting the type, which GHC.compileExpr returns, to my
>> prompt function type [PModule] -> Int -> IO String. But this function
>> returns ghc-prim-0.5.0.0:GHC.Prim.Any. I don?t see a clear way to convert
>> it. So my questions are:
>> - What this type is about? I know Any type in Haskell. Is it a specific
>> version of it?
>> - Or maybe it is not the best way to check a function correctness? I?ve
>> checked out InteractiveEval module and it seems that there are only four
>> quite similar functions to compile Expressions.
>>  Last person, who was trying to solve this problem, used Unsafe.Coerce and
>> it is also doing this job pretty well now, but the name speaks for itself.
>>  Thank you.
>> 
>> _______________________________________________
>> 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/20160405/4bd8c92d/attachment-0001.html>

From matthewtpickering at gmail.com  Tue Apr  5 18:23:17 2016
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Tue, 5 Apr 2016 19:23:17 +0100
Subject: Feature development
In-Reply-To: <9F5E10E9-06BB-4B5D-BA39-17CF023D8B12@gmail.com>
References: <2BEDC7D9-D184-436D-9EAF-F2214CB6AD60@gmail.com>
 <CALuQ0m-NAGfOVL4qGDy_76Ks=SqW1FE1Se-vd_baRcm0Dmi=cg@mail.gmail.com>
 <9F5E10E9-06BB-4B5D-BA39-17CF023D8B12@gmail.com>
Message-ID: <CALuQ0m8KCU6QYcjh7dQGzJEsu+2wk=orjx8jOWzS_0dcxcF5ow@mail.gmail.com>

Seems like this issue - https://ghc.haskell.org/trac/ghc/ticket/11155

I also build on OS X and haven't had any problems recently fwiw.

On Tue, Apr 5, 2016 at 6:58 PM, Sazanovich Nikita
<nikitasazanovich at gmail.com> wrote:
> Thanks for your reply, Matthew.
>
> I?ve tried to merge my local repository with ghc/master branch and after
> this I couldn't build it (even checked out to a successful commit). I am
> getting  this kind of error.
>
> Undefined symbols for architecture x86_64:
> "_stg_sel_17_upd_info", referenced from:
> _s1yAM_info in UI.dyn_o
> _s1yC7_info in UI.dyn_o
> _s1yKD_info in UI.dyn_o
> _s1yLa_info in UI.dyn_o
>
> It seems like something specific to OS X. Can you help me?
>
> On 05 Apr 2016, at 2:25 AM, Matthew Pickering <matthewtpickering at gmail.com>
> wrote:
>
> Hello Nikita,
>
> I don't know the answers to your questions but I do know that it's
> easier to give help if there is some code to look at. I would suggest
> you put a diff up on phab with what you have done so far so that it is
> easy for others to give specific comments about where you are stuck.
>
> Matt
>
> On Mon, Apr 4, 2016 at 7:22 PM, Sazanovich Nikita
> <nikitasazanovich at gmail.com> wrote:
>
>  Hello!
>  I am working on ticket https://ghc.haskell.org/trac/ghc/ticket/5850 now.
> I?ve come upon converting the type, which GHC.compileExpr returns, to my
> prompt function type [PModule] -> Int -> IO String. But this function
> returns ghc-prim-0.5.0.0:GHC.Prim.Any. I don?t see a clear way to convert
> it. So my questions are:
> - What this type is about? I know Any type in Haskell. Is it a specific
> version of it?
> - Or maybe it is not the best way to check a function correctness? I?ve
> checked out InteractiveEval module and it seems that there are only four
> quite similar functions to compile Expressions.
>  Last person, who was trying to solve this problem, used Unsafe.Coerce and
> it is also doing this job pretty well now, but the name speaks for itself.
>  Thank you.
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>

From nikitasazanovich at gmail.com  Wed Apr  6 07:29:20 2016
From: nikitasazanovich at gmail.com (Sazanovich Nikita)
Date: Wed, 6 Apr 2016 10:29:20 +0300
Subject: Feature development
In-Reply-To: <CALuQ0m8KCU6QYcjh7dQGzJEsu+2wk=orjx8jOWzS_0dcxcF5ow@mail.gmail.com>
References: <2BEDC7D9-D184-436D-9EAF-F2214CB6AD60@gmail.com>
 <CALuQ0m-NAGfOVL4qGDy_76Ks=SqW1FE1Se-vd_baRcm0Dmi=cg@mail.gmail.com>
 <9F5E10E9-06BB-4B5D-BA39-17CF023D8B12@gmail.com>
 <CALuQ0m8KCU6QYcjh7dQGzJEsu+2wk=orjx8jOWzS_0dcxcF5ow@mail.gmail.com>
Message-ID: <4171C9F1-E31A-4A4D-9536-161E9B0D8496@gmail.com>

Oh, sure it is gcc ticket right now. Thanks.

So this is that I?ve done so far. https://phabricator.haskell.org/D2084 <https://phabricator.haskell.org/D2084>
Just for your convenience I've copied my initial message:

I am working on ticket https://ghc.haskell.org/trac/ghc/ticket/5850 now.
I?ve come upon converting the type, which GHC.compileExpr returns, to my prompt function type [PModule] -> Int -> IO String. But this function returns ghc-prim-0.5.0.0:GHC.Prim.Any. I don?t see a clear way to convert it. So my questions are:
- What this type is about? I know Any type in Haskell. Is it a specific version of it?
- Or maybe it is not the best way to check a function correctness? I?ve checked out InteractiveEval module and it seems that there are only four quite similar functions to compile Expressions.
Last person, who was trying to solve this problem, used Unsafe.Coerce and it is also doing this job pretty well now, but the name speaks for itself.

> On 05 Apr 2016, at 9:23 PM, Matthew Pickering <matthewtpickering at gmail.com> wrote:
> 
> Seems like this issue - https://ghc.haskell.org/trac/ghc/ticket/11155
> 
> I also build on OS X and haven't had any problems recently fwiw.
> 
> On Tue, Apr 5, 2016 at 6:58 PM, Sazanovich Nikita
> <nikitasazanovich at gmail.com> wrote:
>> Thanks for your reply, Matthew.
>> 
>> I?ve tried to merge my local repository with ghc/master branch and after
>> this I couldn't build it (even checked out to a successful commit). I am
>> getting  this kind of error.
>> 
>> Undefined symbols for architecture x86_64:
>> "_stg_sel_17_upd_info", referenced from:
>> _s1yAM_info in UI.dyn_o
>> _s1yC7_info in UI.dyn_o
>> _s1yKD_info in UI.dyn_o
>> _s1yLa_info in UI.dyn_o
>> 
>> It seems like something specific to OS X. Can you help me?
>> 
>> On 05 Apr 2016, at 2:25 AM, Matthew Pickering <matthewtpickering at gmail.com>
>> wrote:
>> 
>> Hello Nikita,
>> 
>> I don't know the answers to your questions but I do know that it's
>> easier to give help if there is some code to look at. I would suggest
>> you put a diff up on phab with what you have done so far so that it is
>> easy for others to give specific comments about where you are stuck.
>> 
>> Matt
>> 
>> On Mon, Apr 4, 2016 at 7:22 PM, Sazanovich Nikita
>> <nikitasazanovich at gmail.com> wrote:
>> 
>> Hello!
>> I am working on ticket https://ghc.haskell.org/trac/ghc/ticket/5850 now.
>> I?ve come upon converting the type, which GHC.compileExpr returns, to my
>> prompt function type [PModule] -> Int -> IO String. But this function
>> returns ghc-prim-0.5.0.0:GHC.Prim.Any. I don?t see a clear way to convert
>> it. So my questions are:
>> - What this type is about? I know Any type in Haskell. Is it a specific
>> version of it?
>> - Or maybe it is not the best way to check a function correctness? I?ve
>> checked out InteractiveEval module and it seems that there are only four
>> quite similar functions to compile Expressions.
>> Last person, who was trying to solve this problem, used Unsafe.Coerce and
>> it is also doing this job pretty well now, but the name speaks for itself.
>> Thank you.
>> 
>> _______________________________________________
>> 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/20160406/ee681e27/attachment.html>

From conal at conal.net  Wed Apr  6 16:50:28 2016
From: conal at conal.net (Conal Elliott)
Date: Wed, 6 Apr 2016 09:50:28 -0700
Subject: "opt_univ fell into a hole"
In-Reply-To: <6308DA27-B051-4B32-BFD8-A2E159F23186@cis.upenn.edu>
References: <CAD6SzR+QHtCFGQfUOfM-+TNqWeYJ_4zK1EBqw3FsBU9QQUya=A@mail.gmail.com>
 <34e8d9166f8b4e078161aecfec84ba0e@DB4PR30MB030.064d.mgd.msft.net>
 <CAD6SzRK7J66_eYXxVE63FNOP++dZU3_JSd2+MftoE83LxU0hCQ@mail.gmail.com>
 <8AE0A67F-4A73-4624-BD3E-335C654104BE@cis.upenn.edu>
 <CAD6SzRKUbeDz2ku3Jva3OUAFn5ojRPc+a4cGEr6f7S3E6rQUXA@mail.gmail.com>
 <2EDA5A23-A13C-4A3A-B920-D8CC56B44261@cis.upenn.edu>
 <CAD6SzRLoyV=6=N4-CTYcwm0FQRyYRkCEaSXXEMSdD-Cyo1TZpg@mail.gmail.com>
 <6308DA27-B051-4B32-BFD8-A2E159F23186@cis.upenn.edu>
Message-ID: <CAD6SzRLF1osPTMMeQPAa8PB62sR-bNBe6S=drx_oPnrF7BoqYg@mail.gmail.com>

Thanks! Will do.

On Tue, Apr 5, 2016 at 12:55 AM, Richard Eisenberg <eir at cis.upenn.edu>
wrote:

> No -- that's the one you want. Either wrap your EvBinds in some structure
> that you can zonk, or submit a patch exporting zonkEvBinds. :)
>
> Richard
>
> On Apr 4, 2016, at 11:56 PM, Conal Elliott <conal at conal.net> wrote:
>
> Thanks, Richard!  Unfortunately, zonkEvBinds is not exported from TcHsSyn.
> Do you think there's another route to zonking that could work for my
> circumstances?  - Conal
>
>
> On Mon, Apr 4, 2016 at 2:00 PM, Richard Eisenberg <eir at cis.upenn.edu>
> wrote:
>
>> Can't say anything about the setup to use unsafePerformIO, but I can say
>> that, yes, you need a zonk.
>>
>> You may wish to read Note [What is zonking?] in TcMType. Running your
>> bnds through a zonkEvBinds (using an emptyZonkEnv) should help.
>>
>> Also, use TcMType.newWanted to make your CtWanted. As it stands, if
>> predTy is an equality constraint, your CtWanted will be ill-formed, as all
>> equality constraints should have HoleDests, not EvVarDests. Using
>> TcMType.newWanted will simplify and improve your code.
>>
>> I hope this helps,
>> Richard
>>
>> On Apr 4, 2016, at 7:16 PM, Conal Elliott <conal at conal.net> wrote:
>>
>> Hi Richard. Thanks for the tips. I haven't learned about zonking, so it
>> may well be what I'm missing here. I'm using some inherited code that
>> includes the following line to get bindings then used with dsEvBinds and
>> mkCoreLets to build an expression:
>>
>> >         (_wCs', bnds) <- second evBindMapBinds <$> runTcS (solveWanteds
>> wCs)
>>
>> Should I be zonking in here somewhere?
>>
>> More context for this code, if helpful:
>>
>> > -- | Build a dictionary for the given
>> > buildDictionary' :: HscEnv -> DynFlags -> ModGuts -> Id -> (Id,
>> [CoreBind])
>> > buildDictionary' env dflags guts evar =
>> >     let (i, bs) = runTcMUnsafe env dflags guts $ do
>> >         loc <- getCtLocM (GivenOrigin UnkSkol) Nothing
>> >         let predTy = varType evar
>> >             nonC = mkNonCanonical $
>> >                      CtWanted { ctev_pred = predTy, ctev_dest =
>> EvVarDest evar
>> >                               , ctev_loc = loc }
>> >             wCs = mkSimpleWC [cc_ev nonC]
>> >         -- TODO: Make sure solveWanteds is the right function to call.
>> >         (_wCs', bnds) <- second evBindMapBinds <$> runTcS (solveWanteds
>> wCs)
>> >         -- pprTrace "buildDictionary' _wCs'" (ppr _wCs') (return ())
>> >         warnAllUnsolved _wCs'
>> >         return (evar, bnds)
>> >     in
>> >       (i, runDsMUnsafe env dflags guts (dsEvBinds bs))
>>
>> where runTcMUnsafe and runDsMUnsafe use unsafePerformIO (ouch) to
>>
>> > runTcMUnsafe :: HscEnv -> DynFlags -> ModGuts -> TcM a -> a
>> > runTcMUnsafe env dflags guts m = unsafePerformIO $ do
>> >     -- What is the effect of HsSrcFile (should we be using something
>> else?)
>> >     -- What should the boolean flag be set to?
>> >     (msgs, mr) <- initTcFromModGuts env guts HsSrcFile False m
>> >     let showMsgs (warns, errs) = showSDoc dflags $ vcat
>> >                                                  $    text "Errors:" :
>> pprErrMsgBagWithLoc errs
>> >                                                    ++ text "Warnings:"
>> : pprErrMsgBagWithLoc warns
>> >     maybe (fail $ showMsgs msgs) return mr
>> >
>> > -- TODO: Try initTcForLookup or initTcInteractive in place of
>> initTcFromModGuts.
>> > -- If successful, drop dflags and guts arguments.
>> >
>> > runDsMUnsafe :: HscEnv -> DynFlags -> ModGuts -> DsM a -> a
>> > runDsMUnsafe env dflags guts = runTcMUnsafe env dflags guts . initDsTc
>>
>> and initTcFromModGuts is something I pulled in from HERMIT.
>>
>> Thanks and regards, - Conal
>>
>> On Mon, Apr 4, 2016 at 9:37 AM, Richard Eisenberg <eir at cis.upenn.edu>
>> wrote:
>>
>>> Coercion holes (the payload of a HoleProv) get created for all wanted
>>> equality constraints (and for nothing else). If you're working over only
>>> class dictionaries, you won't encounter holes. But my guess is that your
>>> HasRep somehow induces a wanted equality. If the solver fills the hole --
>>> as it should if the equality is solvable -- then you may just need to zonk
>>> it properly. zonkCoHole does the job, but this should be called from
>>> zonkTcTypeToType, which I imagine you're already doing.
>>>
>>> I hope this helps,
>>> Richard
>>>
>>> On Apr 4, 2016, at 6:21 PM, Conal Elliott <conal at conal.net> wrote:
>>>
>>> Hi Simon. Thanks for the reply. My plugin appears to produce the
>>> HoleProv indirectly (and to my surprise) while building a dictionary to
>>> satisfy a given constraint, using mkNonCanonical and solveWanteds. I don't
>>> know why solveWanteds produces a HoleProv in this case and not in the many
>>> others I've tried. The constraint being solved in the example I included
>>> was 'HasRep (Vec ('S n_aCj7) (Key h_aCj6))', where HasRep is similar to
>>> Generic (from GHC.Generics), and there is a HasRep instance for Vec ('S n
>>> x). Come to think of it, the free type variable s_aD1S troubles me as well.
>>>
>>> I'm not terribly confident in the code I use for constructing these
>>> dictionaries (setting up and calling solveWanteds) during Core-to-Core
>>> transformation. Do you know of any relevant example code, docs, etc?
>>>
>>> Yes, I'm using -dcore-lint, as well explicitly linting each small
>>> transformation step (while debugging). Doing so has been very helpful in
>>> finding bugs quickly.
>>>
>>> Cheers, - Conal
>>>
>>> On Mon, Apr 4, 2016 at 2:48 AM, Simon Peyton Jones <
>>> simonpj at microsoft.com> wrote:
>>>
>>>> Definitely a bug. All HoleProvs should be eliminated by the type
>>>> checker.
>>>>
>>>>
>>>>
>>>> Did your plugin produce a HoleProv?  It definitely should not do so;
>>>> see the notes with that constructor.
>>>>
>>>>
>>>>
>>>> Lint checks for this ? did you run with ?dcore-lint?
>>>>
>>>>
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Conal
>>>> Elliott
>>>> *Sent:* 02 April 2016 20:24
>>>> *To:* ghc-devs at haskell.org
>>>> *Subject:* "opt_univ fell into a hole"
>>>>
>>>>
>>>>
>>>> I'm getting the following error message from a GHC plugin I'm
>>>> developing (note GHC version):
>>>>
>>>>     ghc-stage2: panic! (the 'impossible' happened)
>>>>       (GHC version 8.1.20160307 for x86_64-apple-darwin):
>>>>             opt_univ fell into a hole {aD1S}
>>>>
>>>> I don't get this error when compiling without my plugin, so I may well
>>>> be violating a compiler invariant.
>>>>
>>>> Shortly before the error, the plugin produced the following dictionary
>>>> expression, which does indeed contain a `UnivCo` with a `HoleProv`. The
>>>> plugin does sometimes generate `UnivCo`s but not with `HoleProv`.
>>>>
>>>>     let {
>>>>       $dHasRep_aD1T :: HasRep (Vec 'Z s_aD1R[fuv:0])
>>>>       $dHasRep_aD1T = $fHasRepVec0 @ s_aD1R[fuv:0] } in
>>>>     let {
>>>>       $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR :: HasRep (Vec 'Z (Key h_aCnh))
>>>>       $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR =
>>>>         $dHasRep_aD1T
>>>>         `cast` ((HasRep
>>>>                    (Vec
>>>>                       <'Z>_N
>>>>                       (Sym U(hole:{aD1S}, Key h_aCnh,
>>>> s_aD1R[fuv:0])_N))_N)_R
>>>>                 :: HasRep (Vec 'Z s_aD1R[fuv:0])
>>>>                    ~R# HasRep (Vec 'Z (Key h_aCnh))) } in
>>>>     $dHasRepZLVeczqZZZLKeyhZRZR_Ii5CR
>>>>
>>>> Here, `Key` is a type family from `Data.Key` in the keys package, and
>>>> `Vec` is a GADT of statically length-indexed lists.
>>>>
>>>> Suggestions?
>>>>
>>>> Thanks, - Conal
>>>>
>>>
>>> _______________________________________________
>>> 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/20160406/3e6b25b6/attachment.html>

From rrnewton at gmail.com  Wed Apr  6 17:17:41 2016
From: rrnewton at gmail.com (Ryan Newton)
Date: Wed, 6 Apr 2016 13:17:41 -0400
Subject: Benchmarking harnesses for a more modern nofib?
In-Reply-To: <CAHYVw0xurJX5CG7nw24zx-ZPo-CJeztgZE1u3sL-vtWhwe3uOw@mail.gmail.com>
References: <CACYs5AYHDn-LWn1++A08xKPs4W8_WAXRac7UeH=Zg8zS82kw1w@mail.gmail.com>
 <loom.20160405T113937-69@post.gmane.org>
 <CAHYVw0xurJX5CG7nw24zx-ZPo-CJeztgZE1u3sL-vtWhwe3uOw@mail.gmail.com>
Message-ID: <CACYs5AZo+2wxPYCf1y7sd7-s_r2_F9kXxC4gLfUvqcdZWpsEGg@mail.gmail.com>

FYI, moving discussion off the ghc-devs list to avoid spamming it.  Check
out this mailing list if interested:

https://groups.google.com/forum/#!forum/haskell-benchmark-infrastructure

So far, we're discussing benchmark harnesses and perf dashboards, but I'm
sure we'll get to the benchmarks themselves at some point.






On Tue, Apr 5, 2016 at 11:59 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> The cause of the initial blowup was adding the vector test suite to the
> normal cabal file, in both 0O and O2 forms.  This was done so that fusion
> rules based bugs wouldn't lie in hiding for years.
>
> It sounds like the issues that resulted in built blowup are fixed in 8.0.
> My guess is it's a combination of some type class coercion / equality
> manipulation getting better plus other improvements in 8.0, both.
>
>
> On Tuesday, April 5, 2016, Dominic Steinitz <dominic at steinitz.org> wrote:
>
>> Ryan Newton <rrnewton <at> gmail.com> writes:
>>
>> >  Hi all, Is anyone currently working in, or interested in helping
>> > with, a new benchmark suite for Haskell?  Perhaps, packaging up
>> > existing apps and app benchmarks into a new benchmark suite that
>> > gives a broad picture of Haskell application performance today?
>>
>> I am very interested. I recently encountered a serious performance
>> regression from 7.8 to 7.10 which seems to be fixed in 8.0. Now it's
>> not clear whether this was a library change or ghc itself. I suspect
>> the latter but given the performance is better in 8.0, I was not
>> motivated to confirm this.
>>
>> I am happy to wrap up my example in whatever format but note that it
>> does pull in quite a few libraries.
>>
>> Dominic.
>> _______________________________________________
>> 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/20160406/ac682928/attachment-0001.html>

From ben at well-typed.com  Wed Apr  6 19:47:11 2016
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 06 Apr 2016 21:47:11 +0200
Subject: directory and GHC 8.0.1
Message-ID: <87d1q24j0g.fsf@smart-cactus.org>

Hi Phil,

I noticed that directory has a master-1.2.6 branch with at least one
useful looking bug-fix on it. Is this the branch that you would prefer
to be included in 8.0.1?

Cheers,

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

From rf at rufflewind.com  Wed Apr  6 21:08:39 2016
From: rf at rufflewind.com (rf at rufflewind.com)
Date: Wed, 06 Apr 2016 17:08:39 -0400
Subject: directory and GHC 8.0.1
In-Reply-To: <87d1q24j0g.fsf@smart-cactus.org>
References: <87d1q24j0g.fsf@smart-cactus.org>
Message-ID: <1459976919.2379569.571159985.696D36D2@webmail.messagingengine.com>

> I noticed that directory has a master-1.2.6 branch with at least one
> useful looking bug-fix on it. Is this the branch that you would prefer
> to be included in 8.0.1?

I was being cautious and didn't want to add new things between RCs.  As
long as no-one minds the minor version bump, then 1.2.6.0 would be
preferable.

Thanks.

From ben at well-typed.com  Wed Apr  6 22:19:02 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 07 Apr 2016 00:19:02 +0200
Subject: directory and GHC 8.0.1
In-Reply-To: <1459976919.2379569.571159985.696D36D2@webmail.messagingengine.com>
References: <87d1q24j0g.fsf@smart-cactus.org>
 <1459976919.2379569.571159985.696D36D2@webmail.messagingengine.com>
Message-ID: <87a8l64bzd.fsf@smart-cactus.org>

rf at rufflewind.com writes:

>> I noticed that directory has a master-1.2.6 branch with at least one
>> useful looking bug-fix on it. Is this the branch that you would prefer
>> to be included in 8.0.1?
>
> I was being cautious and didn't want to add new things between RCs.  As
> long as no-one minds the minor version bump, then 1.2.6.0 would be
> preferable.
>
Given how much else has changed since rc2 I suspect directory will be
the least of our concerns :)

Would you be able to cut a proper 1.2.6 release in time for the 8.0.1
release?

Cheers,

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

From conal at conal.net  Thu Apr  7 00:11:43 2016
From: conal at conal.net (Conal Elliott)
Date: Wed, 6 Apr 2016 17:11:43 -0700
Subject: Trouble with first GHC patch submission: uncommitted changes
Message-ID: <CAD6SzRLqfWMHqk=ZO2bCwpmvuRA6f-0Sr-1dNkkgy3nEZF7_uA@mail.gmail.com>

I'm trying to get through my first GHC patch submission, using git and
Phabricator, following directions at
https://ghc.haskell.org/trac/ghc/wiki/Phabricator. "git status" shows two
unstaged changes: "deleted:    test   spaces" and "modified:
../libraries/bytestring (modified content)" (in a submodule). I don't know
where either change came from. When I use "arc diff" to submit my intended
change to the compiler, I get asked about these to uncommitted changes. I
say to ignore the submodule change and do not amend my commit with the
"test   spaces" deletion, I get "Usage Exception: You can not continue with
uncommitted changes. Commit or discard them before proceeding." I don't
know how to discard (nor whether safe), and I don't think I want to commit.

Note: the directions say to use "arc diff~" (rather than "arc diff"), to
which arc replied "(Assuming 'diff~' is the British spelling of 'diff'.)".

Thanks for any help!

-- Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160406/b7b2e8db/attachment.html>

From austin at well-typed.com  Thu Apr  7 00:21:11 2016
From: austin at well-typed.com (Austin Seipp)
Date: Wed, 6 Apr 2016 19:21:11 -0500
Subject: Trouble with first GHC patch submission: uncommitted changes
In-Reply-To: <CAD6SzRLqfWMHqk=ZO2bCwpmvuRA6f-0Sr-1dNkkgy3nEZF7_uA@mail.gmail.com>
References: <CAD6SzRLqfWMHqk=ZO2bCwpmvuRA6f-0Sr-1dNkkgy3nEZF7_uA@mail.gmail.com>
Message-ID: <CAEs96n1Xvps+bk6q=+KrU4zY4YikKPiKPQoGeTJvzp0ZTi7tkA@mail.gmail.com>

On Wed, Apr 6, 2016 at 7:11 PM, Conal Elliott <conal at conal.net> wrote:
> I'm trying to get through my first GHC patch submission, using git and
> Phabricator, following directions at
> https://ghc.haskell.org/trac/ghc/wiki/Phabricator. "git status" shows two
> unstaged changes: "deleted:    test   spaces" and "modified:
> ../libraries/bytestring (modified content)" (in a submodule). I don't know
> where either change came from. When I use "arc diff" to submit my intended
> change to the compiler, I get asked about these to uncommitted changes. I
> say to ignore the submodule change and do not amend my commit with the "test
> spaces" deletion, I get "Usage Exception: You can not continue with
> uncommitted changes. Commit or discard them before proceeding." I don't know
> how to discard (nor whether safe), and I don't think I want to commit.

I'm not sure about the 'test spaces' change. That should be added to
.gitignore I think. I'll try to see if I can get that done for you.

It should be fine to discard the changes; the spaces thing is an
artifact of the build system testing a binary distribution (I assume
you did ./validate ?)

The bytestring change might be because there were some left over files
from the build system lingering, that might not be in .gitignore. Just
try running 'git status' in libraries/bytestring and seeing what it
shows.

> Note: the directions say to use "arc diff~" (rather than "arc diff"), to
> which arc replied "(Assuming 'diff~' is the British spelling of 'diff'.)".

Ugh, sorry. That's a clerical error. I must have typo'd that...

Assuming you want to submit the latest patch, on your current branch, you want:

$ arc diff HEAD~

The first argument to 'diff' is essentially the commit to start as the
'base' commit. You then get a diff generated, from the 'base' commit
against the head commit of your working copy. In other words, when
you say "arc diff XXX", that's basically a way of saying "Send the
diff between XXX..HEAD".

In this case, you can see that if you say "git log HEAD~..HEAD", which
would only contain one commit (presumably, what you want).

Arcanist can always tell you exactly what it will do, in a detailed
way, before doing it. Instead of running 'arc diff', run 'arc which'

$ arc which HEAD~

That will tell you exactly what arcanist will do, in a detailed
manner. E.g. it will tell you if it will create a new diff, or update
an old one, and exactly the commits it will use to create or update
that diff. You can use further flags/arguments to 'arc diff' or 'arc
which' to override the behavior as you want.

> Thanks for any help!
>
> -- Conal
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

-- 
Regards,

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

From conal at conal.net  Thu Apr  7 01:25:41 2016
From: conal at conal.net (Conal Elliott)
Date: Wed, 6 Apr 2016 18:25:41 -0700
Subject: Trouble with first GHC patch submission: uncommitted changes
In-Reply-To: <CAEs96n1Xvps+bk6q=+KrU4zY4YikKPiKPQoGeTJvzp0ZTi7tkA@mail.gmail.com>
References: <CAD6SzRLqfWMHqk=ZO2bCwpmvuRA6f-0Sr-1dNkkgy3nEZF7_uA@mail.gmail.com>
 <CAEs96n1Xvps+bk6q=+KrU4zY4YikKPiKPQoGeTJvzp0ZTi7tkA@mail.gmail.com>
Message-ID: <CAD6SzRJkj-SbAmJJvs5EM=+gpzQ_fHiL5hzaNidJzBhODxyYGQ@mail.gmail.com>

Thanks again, Austin, for all the help in this exchange and on #ghc,
leading to https://phabricator.haskell.org/D2088. Looking forward to more
GHC involvement.  - Conal

On Wed, Apr 6, 2016 at 5:21 PM, Austin Seipp <austin at well-typed.com> wrote:

> On Wed, Apr 6, 2016 at 7:11 PM, Conal Elliott <conal at conal.net> wrote:
> > I'm trying to get through my first GHC patch submission, using git and
> > Phabricator, following directions at
> > https://ghc.haskell.org/trac/ghc/wiki/Phabricator. "git status" shows
> two
> > unstaged changes: "deleted:    test   spaces" and "modified:
> > ../libraries/bytestring (modified content)" (in a submodule). I don't
> know
> > where either change came from. When I use "arc diff" to submit my
> intended
> > change to the compiler, I get asked about these to uncommitted changes. I
> > say to ignore the submodule change and do not amend my commit with the
> "test
> > spaces" deletion, I get "Usage Exception: You can not continue with
> > uncommitted changes. Commit or discard them before proceeding." I don't
> know
> > how to discard (nor whether safe), and I don't think I want to commit.
>
> I'm not sure about the 'test spaces' change. That should be added to
> .gitignore I think. I'll try to see if I can get that done for you.
>
> It should be fine to discard the changes; the spaces thing is an
> artifact of the build system testing a binary distribution (I assume
> you did ./validate ?)
>
> The bytestring change might be because there were some left over files
> from the build system lingering, that might not be in .gitignore. Just
> try running 'git status' in libraries/bytestring and seeing what it
> shows.
>
> > Note: the directions say to use "arc diff~" (rather than "arc diff"), to
> > which arc replied "(Assuming 'diff~' is the British spelling of
> 'diff'.)".
>
> Ugh, sorry. That's a clerical error. I must have typo'd that...
>
> Assuming you want to submit the latest patch, on your current branch, you
> want:
>
> $ arc diff HEAD~
>
> The first argument to 'diff' is essentially the commit to start as the
> 'base' commit. You then get a diff generated, from the 'base' commit
> against the head commit of your working copy. In other words, when
> you say "arc diff XXX", that's basically a way of saying "Send the
> diff between XXX..HEAD".
>
> In this case, you can see that if you say "git log HEAD~..HEAD", which
> would only contain one commit (presumably, what you want).
>
> Arcanist can always tell you exactly what it will do, in a detailed
> way, before doing it. Instead of running 'arc diff', run 'arc which'
>
> $ arc which HEAD~
>
> That will tell you exactly what arcanist will do, in a detailed
> manner. E.g. it will tell you if it will create a new diff, or update
> an old one, and exactly the commits it will use to create or update
> that diff. You can use further flags/arguments to 'arc diff' or 'arc
> which' to override the behavior as you want.
>
> > Thanks for any help!
> >
> > -- Conal
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160406/1d3e3e9b/attachment.html>

From conal at conal.net  Thu Apr  7 01:36:36 2016
From: conal at conal.net (Conal Elliott)
Date: Wed, 6 Apr 2016 18:36:36 -0700
Subject: Broken haddock in new GHC HEAD build
Message-ID: <CAD6SzRJxCruS=-ov8NQeZQJk8SZTy17Vr=h2h9SwgNPDzZ4wQg@mail.gmail.com>

I built GHC HEAD from git yesterday (using GHC 7.10.3 on Mac OS 10.9.5),
and the haddock I got dies with

    bash-3.2$ haddock --version
    dyld: Symbol not found: _ghc_GHC_modInfoExportszugo_info
      Referenced from:
/Users/conal/git-repos/ghc-2016-04-05/inplace/lib/bin/haddock
      Expected in:
/Users/conal/git-repos/ghc-2016-04-05/compiler/stage2/build/libHSghc-8.1-ghc8.1.20160405.dylib
     in /Users/conal/git-repos/ghc-2016-04-05/inplace/lib/bin/haddock
    Trace/BPT trap: 5

Luckily, I have a working haddock from 2016-03-07 sources that I copied
into my new GHC bin (~/git-repos/ghc-2016-04-05/inplace/bin/) for now.

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

From rf at rufflewind.com  Thu Apr  7 03:35:48 2016
From: rf at rufflewind.com (rf at rufflewind.com)
Date: Wed, 06 Apr 2016 23:35:48 -0400
Subject: directory and GHC 8.0.1
In-Reply-To: <87a8l64bzd.fsf@smart-cactus.org>
References: <87d1q24j0g.fsf@smart-cactus.org>
 <1459976919.2379569.571159985.696D36D2@webmail.messagingengine.com>
 <87a8l64bzd.fsf@smart-cactus.org>
Message-ID: <1460000148.3221856.571408153.7456C7C7@webmail.messagingengine.com>

> Would you be able to cut a proper 1.2.6 release in time for the 8.0.1
> release?

I should be able to.  Any idea what that exact date will be?

From ben at well-typed.com  Thu Apr  7 08:39:29 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 07 Apr 2016 10:39:29 +0200
Subject: directory and GHC 8.0.1
In-Reply-To: <1460000148.3221856.571408153.7456C7C7@webmail.messagingengine.com>
References: <87d1q24j0g.fsf@smart-cactus.org>
 <1459976919.2379569.571159985.696D36D2@webmail.messagingengine.com>
 <87a8l64bzd.fsf@smart-cactus.org>
 <1460000148.3221856.571408153.7456C7C7@webmail.messagingengine.com>
Message-ID: <877fg94xtq.fsf@smart-cactus.org>

rf at rufflewind.com writes:

>> Would you be able to cut a proper 1.2.6 release in time for the 8.0.1
>> release?
>
> I should be able to.  Any idea what that exact date will be?

Well, the release candidate 3 source distribution is going out today;
the binary distributions will be available at latest a week from today.
Then presumably we'll want at least a week of testing, so I'd say
probably in two weeks or so.

Cheers,

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

From ben at well-typed.com  Thu Apr  7 08:52:34 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 07 Apr 2016 10:52:34 +0200
Subject: Broken haddock in new GHC HEAD build
In-Reply-To: <CAD6SzRJxCruS=-ov8NQeZQJk8SZTy17Vr=h2h9SwgNPDzZ4wQg@mail.gmail.com>
References: <CAD6SzRJxCruS=-ov8NQeZQJk8SZTy17Vr=h2h9SwgNPDzZ4wQg@mail.gmail.com>
Message-ID: <8737qx4x7x.fsf@smart-cactus.org>

Conal Elliott <conal at conal.net> writes:

> I built GHC HEAD from git yesterday (using GHC 7.10.3 on Mac OS 10.9.5),
> and the haddock I got dies with
>
Thanks for the report, Conal!


>     bash-3.2$ haddock --version
>     dyld: Symbol not found: _ghc_GHC_modInfoExportszugo_info
>       Referenced from:
> /Users/conal/git-repos/ghc-2016-04-05/inplace/lib/bin/haddock
>       Expected in:
> /Users/conal/git-repos/ghc-2016-04-05/compiler/stage2/build/libHSghc-8.1-ghc8.1.20160405.dylib
>      in /Users/conal/git-repos/ghc-2016-04-05/inplace/lib/bin/haddock
>     Trace/BPT trap: 5
>
> Luckily, I have a working haddock from 2016-03-07 sources that I copied
> into my new GHC bin (~/git-repos/ghc-2016-04-05/inplace/bin/) for now.

Hmm, this is quite concerning, especially considering I haven't observed
it in my own OS X builds. Are you sure you started from a clean tree
(e.g. ran `make distclean`)?

Cheers,

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

From ben at well-typed.com  Thu Apr  7 08:56:56 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 07 Apr 2016 10:56:56 +0200
Subject: Benchmarking harnesses for a more modern nofib?
In-Reply-To: <CACYs5AZo+2wxPYCf1y7sd7-s_r2_F9kXxC4gLfUvqcdZWpsEGg@mail.gmail.com>
References: <CACYs5AYHDn-LWn1++A08xKPs4W8_WAXRac7UeH=Zg8zS82kw1w@mail.gmail.com>
 <loom.20160405T113937-69@post.gmane.org>
 <CAHYVw0xurJX5CG7nw24zx-ZPo-CJeztgZE1u3sL-vtWhwe3uOw@mail.gmail.com>
 <CACYs5AZo+2wxPYCf1y7sd7-s_r2_F9kXxC4gLfUvqcdZWpsEGg@mail.gmail.com>
Message-ID: <87zit53ig7.fsf@smart-cactus.org>

Ryan Newton <rrnewton at gmail.com> writes:

> FYI, moving discussion off the ghc-devs list to avoid spamming it.  Check
> out this mailing list if interested:
>
> https://groups.google.com/forum/#!forum/haskell-benchmark-infrastructure
>
> So far, we're discussing benchmark harnesses and perf dashboards, but I'm
> sure we'll get to the benchmarks themselves at some point.
>
Thanks for this, Ryan! Attention here is badly needed.

After the 8.0.1 release Austin and I will be turning some attention to
this area as well. I'm looking forward to future discussions.

Cheers,

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

From m at tweag.io  Fri Apr  8 13:48:39 2016
From: m at tweag.io (Boespflug, Mathieu)
Date: Fri, 8 Apr 2016 15:48:39 +0200
Subject: Reification of out-of-scope variables?
Message-ID: <CAJ0eudrYKW=+s25+G9x_3AQNJTU2Uqj18uZfbzZedF2p8oq=LQ@mail.gmail.com>

Hi all,

the community is increasingly using quasiquotation as a means to
interoperate with foreign languages. E.g. language-c-inline, inline-c
and inline-r allow calling foreign functions using foreign language
syntax, rather than "foreign import" declarations. There are efforts
underway for Java, Javascript and other languages too. The pattern
common to most of these libraries is:

* collect the content of all quasiquotes that appear in a module,
generate a compilable foreign source file based on that, and then link
the object code resulting from compiling that.

When the foreign language is itself statically typed, we need to make
sure we generate code with proper type annotations, including for any
antiquotation variables. In older versions of GHC, we could derive the
type annotations from the inferred Haskell types, but this is not
possible since 7.8 because the types of any variable in the current
"declaration group" are not made available. So libraries like inline-c
ask for some extra verbosity from the user:

mycossin1 :: Double -> IO Double
mycossin1 somex = [cexp| double { cos($(double somex)) * sin($(double
somex)) } |]

The type annotations inside the quasiquote are redundant with the
explicitly provided type signature. C types are typically short
enough, but other languages (e.g. C++, Java), have really long fully
qualified type names, so the extra annotations are a cost.

The are good reasons why types aren't available from within a
declaration group (it was possible to observe the order in which type
inference works), hence why the extra annotations are necessary. But
by the time type checking of the whole module is finished, types are
fixed once and for all. So the question is:

* Could we make it possible to query the types of local variables at
the end of type checking?

The reason I ask is: with 'addModFinalizer' and friends that TH
provides, we're tantalizingly close to being able to generate foreign
code wrappers that have the right types that match those of the
antiquotation variables present in a module.

Template Haskell already provides 'addModFinalizer'. You feed it a Q
action, which will run once the whole module is type checked. If at
that point we could ask, "what's the type of somex (above)?", then we
could let the user write

mycossin2 :: Double -> IO Double
mycossin2 somex = [cexp| cos($somex) * sin($somex) |]

and yet still generate a C file capturing the content of above
quasiquote with the right types:

double module_foo_qq1(double v1)
{
    return (cos(v1) * sin(v1));
}

since we know that somex :: Double and that the Haskell type "Double"
corresponds to C's "double" primitive type.

Bound variables have a unique name associated to them, which we can
get hold of in Template Haskell using the 'var syntax, but

f x = $(let name = 'x in addModFinalizer (reify name >>= \info ->
runIO (print info)) >> [| x |])

results in a compiler error,

    The exact Name `x' is not in scope
      Probable cause: you used a unique Template Haskell name (NameU),
      perhaps via newName, but did not bind it
      If that's it, then -ddump-splices might be useful

because by the time the TH finalizer runs, we're no longer in the scope of x.

But since the names of the local variables are unique, could it
possibly make sense to allow calling reify on them, even outside of
their scope, so as to get at their type?

Best,

Mathieu

From mgsloan at gmail.com  Sat Apr  9 00:12:03 2016
From: mgsloan at gmail.com (Michael Sloan)
Date: Fri, 8 Apr 2016 17:12:03 -0700
Subject: Reification of out-of-scope variables?
In-Reply-To: <CAJ0eudrYKW=+s25+G9x_3AQNJTU2Uqj18uZfbzZedF2p8oq=LQ@mail.gmail.com>
References: <CAJ0eudrYKW=+s25+G9x_3AQNJTU2Uqj18uZfbzZedF2p8oq=LQ@mail.gmail.com>
Message-ID: <CAEDDsWe9rehbHB3Wzf1mzv2b1w=P=hYRq+-e8fV8Jaem+QJKcg@mail.gmail.com>

I have considered how to add this capability some in the past, it's
something I'd also like to have.  Collecting the type info in the module
finalizer is an interesting idea!  This may well be the cheapest way to get
the info necessary for this usecase.

As far as I understand it, currently we're in the middle of typechecking
when quasiquotes get run, so we don't yet have concrete.  The types of
reified variables may well depend upon the type of the expression generated
by the quasi-quote.  There seems to be a straightforward-ish way to resolve
this - run typechecking twice.  The first typechecking pass uses
quasi-quotes substituted with stub versions of their output.  For this
example, it'd be (undefined :: IO double).  To support this, we'd add a
(Maybe ExpQ) field to QuasiQuoter, hopefully doing this in a way that
preserves backwards compatibility (via pattern syns, or adding a new
constructor to QuasiQuoter).

For consistency, we would want to ensure that the stub unifies with the
expression that actually gets used.  To enforce this, we'd typecheck
something equivalent to

case True of
    True -> ... -- generated code
    False -> (undefined :: IO Double)  -- stub

My particular use case is similar, in that it's related to FFI.  What I
want to do is have quasiquoters for typescript in GHCJS code.  Since GHCJS
already runs TH in node, we can actually load up the typescript compiler
and do the typechecking directly at the quasi-quote location.  For the
first-pass stubs, we pretend like all the captured variables are the "Any"
type, and ask typescript what it thinks the overall type is.  For the
second pass, we have the types of the anti-quotes, and so can typecheck the
whole expression.

It'd also be really cool if we could generated code + typecheck anti-quotes
during the first pass.  This would make it possible to use anti-quotes
which are more complicated than just a variable.

-Michael

On Fri, Apr 8, 2016 at 6:48 AM, Boespflug, Mathieu <m at tweag.io> wrote:

> Hi all,
>
> the community is increasingly using quasiquotation as a means to
> interoperate with foreign languages. E.g. language-c-inline, inline-c
> and inline-r allow calling foreign functions using foreign language
> syntax, rather than "foreign import" declarations. There are efforts
> underway for Java, Javascript and other languages too. The pattern
> common to most of these libraries is:
>
> * collect the content of all quasiquotes that appear in a module,
> generate a compilable foreign source file based on that, and then link
> the object code resulting from compiling that.
>
> When the foreign language is itself statically typed, we need to make
> sure we generate code with proper type annotations, including for any
> antiquotation variables. In older versions of GHC, we could derive the
> type annotations from the inferred Haskell types, but this is not
> possible since 7.8 because the types of any variable in the current
> "declaration group" are not made available. So libraries like inline-c
> ask for some extra verbosity from the user:
>
> mycossin1 :: Double -> IO Double
> mycossin1 somex = [cexp| double { cos($(double somex)) * sin($(double
> somex)) } |]
>
> The type annotations inside the quasiquote are redundant with the
> explicitly provided type signature. C types are typically short
> enough, but other languages (e.g. C++, Java), have really long fully
> qualified type names, so the extra annotations are a cost.
>
> The are good reasons why types aren't available from within a
> declaration group (it was possible to observe the order in which type
> inference works), hence why the extra annotations are necessary. But
> by the time type checking of the whole module is finished, types are
> fixed once and for all. So the question is:
>
> * Could we make it possible to query the types of local variables at
> the end of type checking?
>
> The reason I ask is: with 'addModFinalizer' and friends that TH
> provides, we're tantalizingly close to being able to generate foreign
> code wrappers that have the right types that match those of the
> antiquotation variables present in a module.
>
> Template Haskell already provides 'addModFinalizer'. You feed it a Q
> action, which will run once the whole module is type checked. If at
> that point we could ask, "what's the type of somex (above)?", then we
> could let the user write
>
> mycossin2 :: Double -> IO Double
> mycossin2 somex = [cexp| cos($somex) * sin($somex) |]
>
> and yet still generate a C file capturing the content of above
> quasiquote with the right types:
>
> double module_foo_qq1(double v1)
> {
>     return (cos(v1) * sin(v1));
> }
>
> since we know that somex :: Double and that the Haskell type "Double"
> corresponds to C's "double" primitive type.
>
> Bound variables have a unique name associated to them, which we can
> get hold of in Template Haskell using the 'var syntax, but
>
> f x = $(let name = 'x in addModFinalizer (reify name >>= \info ->
> runIO (print info)) >> [| x |])
>
> results in a compiler error,
>
>     The exact Name `x' is not in scope
>       Probable cause: you used a unique Template Haskell name (NameU),
>       perhaps via newName, but did not bind it
>       If that's it, then -ddump-splices might be useful
>
> because by the time the TH finalizer runs, we're no longer in the scope of
> x.
>
> But since the names of the local variables are unique, could it
> possibly make sense to allow calling reify on them, even outside of
> their scope, so as to get at their type?
>
> Best,
>
> Mathieu
> _______________________________________________
> 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/20160408/02e2e1d1/attachment.html>

From _deepfire at feelingofgreen.ru  Sat Apr  9 22:41:28 2016
From: _deepfire at feelingofgreen.ru (Kosyrev Serge)
Date: Sun, 10 Apr 2016 01:41:28 +0300
Subject: Odd error message due to PolyKinds
Message-ID: <87oa9i4d7r.fsf@feelingofgreen.ru>

Good day folks,

Here is a test case that exposes a certain weakness in PolyKinds
error messaging.  In the following snippet (T W) :: * is malkinded:

> {-# LANGUAGE PolyKinds #-}
> {-# LANGUAGE UnicodeSyntax #-}
> 
> class Eq a ? EqSyn a where
> data T w
> data W f
> 
> x = (undefined ? EqSyn w ? T w ? ()) (undefined ? T W)

8.0.1rc2 yields:

> ../ghc-playground.hs:8:42: error:
>     ? Expected kind ?T W?, but ?undefined :: T W? has kind ?T W?
>     ? In the first argument of ?undefined ::
>                                   EqSyn w => T w -> ()?, namely
>         ?(undefined :: T W)?
>       In the expression:
>         (undefined :: EqSyn w => T w -> ()) (undefined :: T W)
>       In an equation for ?main?:
>           main = (undefined :: EqSyn w => T w -> ()) (undefined :: T W)

..which is.. not informative.

With PolyKinds removed:

> ../ghc-playground.hs:7:56: error:
>     ? Expecting one more argument to ?W?
>       Expected a type, but ?W? has kind ?* -> *?
>     ? In the first argument of ?T?, namely ?W?
>       In an expression type signature: T W
>       In the first argument of ?undefined ::
>                                   EqSyn w => T w -> ()?, namely
>         ?(undefined :: T W)?

I'm not sure if this was reported, so I'm sorry for the noise if it was.

-- 
? ???????e? / respectfully,
??????? ??????

From eir at cis.upenn.edu  Sun Apr 10 14:22:30 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sun, 10 Apr 2016 10:22:30 -0400
Subject: Reification of out-of-scope variables?
In-Reply-To: <CAJ0eudrYKW=+s25+G9x_3AQNJTU2Uqj18uZfbzZedF2p8oq=LQ@mail.gmail.com>
References: <CAJ0eudrYKW=+s25+G9x_3AQNJTU2Uqj18uZfbzZedF2p8oq=LQ@mail.gmail.com>
Message-ID: <266BEB36-AA3D-4049-84F7-138C6FF7539A@cis.upenn.edu>

I actually don't think this would be all that hard to do.

Concretely, how would this work:

TH will offer a new function `addGroupFinalizer :: Q () -> Q ()` that runs its argument in the local typing environment available when addGroupFinalizer is called. However, by the time the passed action is run -- after finishing typechecking a mutually-recursive group -- all the local variables' types have settled and are available.

Does that satisfy your needs? Of course, your quasiquoter will still have to output code when it is originally run, so the addGroupFinalizer action could only, say, set up the external file.

If this idea is acceptable, it will still need a volunteer to implement. I'm happy to advise.

Richard

On Apr 8, 2016, at 9:48 AM, "Boespflug, Mathieu" <m at tweag.io> wrote:

> Hi all,
> 
> the community is increasingly using quasiquotation as a means to
> interoperate with foreign languages. E.g. language-c-inline, inline-c
> and inline-r allow calling foreign functions using foreign language
> syntax, rather than "foreign import" declarations. There are efforts
> underway for Java, Javascript and other languages too. The pattern
> common to most of these libraries is:
> 
> * collect the content of all quasiquotes that appear in a module,
> generate a compilable foreign source file based on that, and then link
> the object code resulting from compiling that.
> 
> When the foreign language is itself statically typed, we need to make
> sure we generate code with proper type annotations, including for any
> antiquotation variables. In older versions of GHC, we could derive the
> type annotations from the inferred Haskell types, but this is not
> possible since 7.8 because the types of any variable in the current
> "declaration group" are not made available. So libraries like inline-c
> ask for some extra verbosity from the user:
> 
> mycossin1 :: Double -> IO Double
> mycossin1 somex = [cexp| double { cos($(double somex)) * sin($(double
> somex)) } |]
> 
> The type annotations inside the quasiquote are redundant with the
> explicitly provided type signature. C types are typically short
> enough, but other languages (e.g. C++, Java), have really long fully
> qualified type names, so the extra annotations are a cost.
> 
> The are good reasons why types aren't available from within a
> declaration group (it was possible to observe the order in which type
> inference works), hence why the extra annotations are necessary. But
> by the time type checking of the whole module is finished, types are
> fixed once and for all. So the question is:
> 
> * Could we make it possible to query the types of local variables at
> the end of type checking?
> 
> The reason I ask is: with 'addModFinalizer' and friends that TH
> provides, we're tantalizingly close to being able to generate foreign
> code wrappers that have the right types that match those of the
> antiquotation variables present in a module.
> 
> Template Haskell already provides 'addModFinalizer'. You feed it a Q
> action, which will run once the whole module is type checked. If at
> that point we could ask, "what's the type of somex (above)?", then we
> could let the user write
> 
> mycossin2 :: Double -> IO Double
> mycossin2 somex = [cexp| cos($somex) * sin($somex) |]
> 
> and yet still generate a C file capturing the content of above
> quasiquote with the right types:
> 
> double module_foo_qq1(double v1)
> {
>    return (cos(v1) * sin(v1));
> }
> 
> since we know that somex :: Double and that the Haskell type "Double"
> corresponds to C's "double" primitive type.
> 
> Bound variables have a unique name associated to them, which we can
> get hold of in Template Haskell using the 'var syntax, but
> 
> f x = $(let name = 'x in addModFinalizer (reify name >>= \info ->
> runIO (print info)) >> [| x |])
> 
> results in a compiler error,
> 
>    The exact Name `x' is not in scope
>      Probable cause: you used a unique Template Haskell name (NameU),
>      perhaps via newName, but did not bind it
>      If that's it, then -ddump-splices might be useful
> 
> because by the time the TH finalizer runs, we're no longer in the scope of x.
> 
> But since the names of the local variables are unique, could it
> possibly make sense to allow calling reify on them, even outside of
> their scope, so as to get at their type?
> 
> Best,
> 
> Mathieu
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From eir at cis.upenn.edu  Sun Apr 10 14:39:35 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sun, 10 Apr 2016 10:39:35 -0400
Subject: Odd error message due to PolyKinds
In-Reply-To: <87oa9i4d7r.fsf@feelingofgreen.ru>
References: <87oa9i4d7r.fsf@feelingofgreen.ru>
Message-ID: <EA6193A8-B494-4CE1-A46D-4097F3BA7C03@cis.upenn.edu>

Though there's still room for improvement, this one has gotten a lot better since RC2:

> Scratch.hs:24:39: error:
>     ? Couldn't match type ?k0 -> *? with ?*?
>       Expected type: T W
>         Actual type: T W
>       Use -fprint-explicit-kinds to see the kind arguments
>     ? In the first argument of ?undefined ::
>                                   EqSyn w => T w -> ()?, namely
>         ?(undefined :: T W)?
>       In the expression:
>         (undefined :: EqSyn w => T w -> ()) (undefined :: T W)
>       In an equation for ?x?:
>           x = (undefined :: EqSyn w => T w -> ()) (undefined :: T W)

Richard

On Apr 9, 2016, at 6:41 PM, Kosyrev Serge <_deepfire at feelingofgreen.ru> wrote:

> Good day folks,
> 
> Here is a test case that exposes a certain weakness in PolyKinds
> error messaging.  In the following snippet (T W) :: * is malkinded:
> 
>> {-# LANGUAGE PolyKinds #-}
>> {-# LANGUAGE UnicodeSyntax #-}
>> 
>> class Eq a ? EqSyn a where
>> data T w
>> data W f
>> 
>> x = (undefined ? EqSyn w ? T w ? ()) (undefined ? T W)
> 
> 8.0.1rc2 yields:
> 
>> ../ghc-playground.hs:8:42: error:
>>    ? Expected kind ?T W?, but ?undefined :: T W? has kind ?T W?
>>    ? In the first argument of ?undefined ::
>>                                  EqSyn w => T w -> ()?, namely
>>        ?(undefined :: T W)?
>>      In the expression:
>>        (undefined :: EqSyn w => T w -> ()) (undefined :: T W)
>>      In an equation for ?main?:
>>          main = (undefined :: EqSyn w => T w -> ()) (undefined :: T W)
> 
> ..which is.. not informative.
> 
> With PolyKinds removed:
> 
>> ../ghc-playground.hs:7:56: error:
>>    ? Expecting one more argument to ?W?
>>      Expected a type, but ?W? has kind ?* -> *?
>>    ? In the first argument of ?T?, namely ?W?
>>      In an expression type signature: T W
>>      In the first argument of ?undefined ::
>>                                  EqSyn w => T w -> ()?, namely
>>        ?(undefined :: T W)?
> 
> I'm not sure if this was reported, so I'm sorry for the noise if it was.
> 
> -- 
> ? ???????e? / respectfully,
> ??????? ??????
> _______________________________________________
> 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  Sun Apr 10 15:05:11 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 10 Apr 2016 17:05:11 +0200
Subject: GHC 8.0.1-rc3 source tarball availability
Message-ID: <87egadbj2w.fsf@smart-cactus.org>

tl;dr: If you would like to produce a binary distribution for GHC
       8.0.1-rc3 then let us know, grab the source distribution and
       start building. The binary distributions will be all released one
       week from today.


Hello GHC packagers,

Austin and I are happy to announce the release of the 8.0.1-rc3 source
distribution to binary packagers. You will find the tarball and usual
assortment of signatures at

    http://downloads.haskell.org/~ghc/8.0.1-rc3/

This release is the first where we are following our new release policy
[1], where a one-week delay will be introduced between the release of
the source and binary distributions. The goal of this policy is to give
all platforms the opportunity for support from the first day of a
release.

If all of the expected binary releases are submitted before the
week-long delay is through, we can move forward with the release ahead
of schedule. Given how late release candidate 3 is, we'd naturally like
to get the binary releases out as soon is possible: The sooner we can
get this -rc out the door the sooner we can get to the final release.
Moreover, it would be appreciated if you could confirm that you intend
to offer a binary distribution this release.

Otherwise, let either Austin or I know if you have any trouble building
your distribution. I have yet to push the 8.0.1-rc3 tag in case we
encounter unexpected issues but all of my builds with this tarball
thusfar have gone quite well.

Good luck and thanks for all of your work!

Cheers,

- Ben


[1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160410/52ee3bde/attachment.sig>

From mainland at apeiron.net  Sun Apr 10 17:16:53 2016
From: mainland at apeiron.net (Geoffrey Mainland)
Date: Sun, 10 Apr 2016 13:16:53 -0400
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <87egadbj2w.fsf@smart-cactus.org>
References: <87egadbj2w.fsf@smart-cactus.org>
Message-ID: <570A8A85.8070102@apeiron.net>

Does it take a while for the source tarball to show up? All I see is the
Linux binary distribution.

Geoff

On 04/10/2016 11:05 AM, Ben Gamari wrote:
> tl;dr: If you would like to produce a binary distribution for GHC
>        8.0.1-rc3 then let us know, grab the source distribution and
>        start building. The binary distributions will be all released one
>        week from today.
>
>
> Hello GHC packagers,
>
> Austin and I are happy to announce the release of the 8.0.1-rc3 source
> distribution to binary packagers. You will find the tarball and usual
> assortment of signatures at
>
>     http://downloads.haskell.org/~ghc/8.0.1-rc3/
>
> This release is the first where we are following our new release policy
> [1], where a one-week delay will be introduced between the release of
> the source and binary distributions. The goal of this policy is to give
> all platforms the opportunity for support from the first day of a
> release.
>
> If all of the expected binary releases are submitted before the
> week-long delay is through, we can move forward with the release ahead
> of schedule. Given how late release candidate 3 is, we'd naturally like
> to get the binary releases out as soon is possible: The sooner we can
> get this -rc out the door the sooner we can get to the final release.
> Moreover, it would be appreciated if you could confirm that you intend
> to offer a binary distribution this release.
>
> Otherwise, let either Austin or I know if you have any trouble building
> your distribution. I have yet to push the 8.0.1-rc3 tag in case we
> encounter unexpected issues but all of my builds with this tarball
> thusfar have gone quite well.
>
> Good luck and thanks for all of your work!
>
> Cheers,
>
> - Ben
>
>
> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html
>
>
> _______________________________________________
> 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  Sun Apr 10 17:53:28 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 10 Apr 2016 19:53:28 +0200
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <570A8A85.8070102@apeiron.net>
References: <87egadbj2w.fsf@smart-cactus.org> <570A8A85.8070102@apeiron.net>
Message-ID: <87bn5hbbaf.fsf@smart-cactus.org>

Geoffrey Mainland <mainland at apeiron.net> writes:

> Does it take a while for the source tarball to show up? All I see is the
> Linux binary distribution.
>
Oh dear, it seems I moved over the wrong file. Sorry about that,
everyone.

Moreover, I noticed while looking through the patch review queue this
afternoon that there are a few patches that should really be in the RC
as well. I may take this mistake as an opportunity to fold these in.

I'll try to get a new tarball up in the next few hours and post an
update here when this happens.

Cheers,

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

From carter.schonwald at gmail.com  Sun Apr 10 21:20:36 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 10 Apr 2016 17:20:36 -0400
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <87bn5hbbaf.fsf@smart-cactus.org>
References: <87egadbj2w.fsf@smart-cactus.org> <570A8A85.8070102@apeiron.net>
 <87bn5hbbaf.fsf@smart-cactus.org>
Message-ID: <CAHYVw0wre5B+wiK1bxCo=MXctVuMcUBmFyOFUvOtiG_vfLEHYQ@mail.gmail.com>

http://git.haskell.org/ghc.git also doesn't seem to list an rc3 tag yet :)

On Sun, Apr 10, 2016 at 1:53 PM, Ben Gamari <ben at well-typed.com> wrote:

> Geoffrey Mainland <mainland at apeiron.net> writes:
>
> > Does it take a while for the source tarball to show up? All I see is the
> > Linux binary distribution.
> >
> Oh dear, it seems I moved over the wrong file. Sorry about that,
> everyone.
>
> Moreover, I noticed while looking through the patch review queue this
> afternoon that there are a few patches that should really be in the RC
> as well. I may take this mistake as an opportunity to fold these in.
>
> I'll try to get a new tarball up in the next few hours and post an
> update here when this happens.
>
> 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/20160410/185cc0f6/attachment.html>

From carter.schonwald at gmail.com  Sun Apr 10 21:38:50 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 10 Apr 2016 17:38:50 -0400
Subject: heres an integer-simple build of ghc 7.10.3 for OS X
Message-ID: <CAHYVw0wMVSzq61fwMquTbG8ttYL22SUQY7Y99-ySBFmJ-Fz+3w@mail.gmail.com>

1-2 industrial folks who need to distribute applications on mac seem to
have trouble building ghc 7.10.3  with integer simple on OS X 10.11
(probably because of various build tool changes that happened), so I took
the time to make a build on my 10.10 mac. should be useful for others too!

http://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.3-x86_64-apple-darwin-integer-simple-built-by-carter.tar.bz2

https will work,but you'll get a warning that its an aws wildcard cert :)

for those who prefer https and dont mind the cert warning

https://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.3-x86_64-apple-darwin-integer-simple-built-by-carter.tar.bz2

shasum -a512
ghc-7.10.3-x86_64-apple-darwin-integer-simple-built-by-carter.tar.bz2
is
37ccb3c3fe3f21b7c56ed09b8c3d59601bde21d651d17609f62b4b41f3658e6f5a7089a0b271d44d18ba856256681a124bc34b3525c245f4917940a66a3aec63
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160410/1a49a802/attachment-0001.html>

From ben at well-typed.com  Sun Apr 10 21:38:57 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 10 Apr 2016 23:38:57 +0200
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <CAHYVw0wre5B+wiK1bxCo=MXctVuMcUBmFyOFUvOtiG_vfLEHYQ@mail.gmail.com>
References: <87egadbj2w.fsf@smart-cactus.org> <570A8A85.8070102@apeiron.net>
 <87bn5hbbaf.fsf@smart-cactus.org>
 <CAHYVw0wre5B+wiK1bxCo=MXctVuMcUBmFyOFUvOtiG_vfLEHYQ@mail.gmail.com>
Message-ID: <878u0lb0um.fsf@smart-cactus.org>

Carter Schonwald <carter.schonwald at gmail.com> writes:

> http://git.haskell.org/ghc.git also doesn't seem to list an rc3 tag yet :)
>
That's correct, I mentioned in the original announcement that I didn't
push the tag yet in the in case there are issues. I likely won't push it
until we have at least a few of the binary distributions done.

Cheers,

- Ben

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

From carter.schonwald at gmail.com  Sun Apr 10 21:58:03 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 10 Apr 2016 17:58:03 -0400
Subject: heres an integer-simple build of ghc 7.10.3 for OS X
In-Reply-To: <CAHYVw0wMVSzq61fwMquTbG8ttYL22SUQY7Y99-ySBFmJ-Fz+3w@mail.gmail.com>
References: <CAHYVw0wMVSzq61fwMquTbG8ttYL22SUQY7Y99-ySBFmJ-Fz+3w@mail.gmail.com>
Message-ID: <CAHYVw0yVEU4L4MyOa8N40Xsdrh+nSj9H5xgUinS39xWYS9X7kw@mail.gmail.com>

got an https url working
https://s3-us-west-2.amazonaws.com/wellposed-carter-files/opensource/ghc/releasebuild-unofficial/ghc-7.10.3-x86_64-apple-darwin-integer-simple-built-by-carter.tar.bz2?torrent
for the torrent
https://s3-us-west-2.amazonaws.com/wellposed-carter-files/opensource/ghc/releasebuild-unofficial/ghc-7.10.3-x86_64-apple-darwin-integer-simple-built-by-carter.tar.bz2
for the binary build directly

On Sun, Apr 10, 2016 at 5:38 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> 1-2 industrial folks who need to distribute applications on mac seem to
> have trouble building ghc 7.10.3  with integer simple on OS X 10.11
> (probably because of various build tool changes that happened), so I took
> the time to make a build on my 10.10 mac. should be useful for others too!
>
>
> http://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.3-x86_64-apple-darwin-integer-simple-built-by-carter.tar.bz2
>
> https will work,but you'll get a warning that its an aws wildcard cert :)
>
> for those who prefer https and dont mind the cert warning
>
>
> https://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.3-x86_64-apple-darwin-integer-simple-built-by-carter.tar.bz2
>
> shasum -a512
> ghc-7.10.3-x86_64-apple-darwin-integer-simple-built-by-carter.tar.bz2
> is
> 37ccb3c3fe3f21b7c56ed09b8c3d59601bde21d651d17609f62b4b41f3658e6f5a7089a0b271d44d18ba856256681a124bc34b3525c245f4917940a66a3aec63
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160410/c34e208a/attachment.html>

From ben at well-typed.com  Mon Apr 11 01:55:24 2016
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 11 Apr 2016 03:55:24 +0200
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <87bn5hbbaf.fsf@smart-cactus.org>
References: <87egadbj2w.fsf@smart-cactus.org> <570A8A85.8070102@apeiron.net>
 <87bn5hbbaf.fsf@smart-cactus.org>
Message-ID: <8760voc3jn.fsf@smart-cactus.org>

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

> Geoffrey Mainland <mainland at apeiron.net> writes:
>
>> Does it take a while for the source tarball to show up? All I see is the
>> Linux binary distribution.
>>
> Oh dear, it seems I moved over the wrong file. Sorry about that,
> everyone.
>
> Moreover, I noticed while looking through the patch review queue this
> afternoon that there are a few patches that should really be in the RC
> as well. I may take this mistake as an opportunity to fold these in.
>
> I'll try to get a new tarball up in the next few hours and post an
> update here when this happens.
>
I've pushed a new tarball based on
9c48d8a02dd80bba3bd313bc52add841530e28dc. I have pushed essentially
everything into this candidate that I expect will go into 8.0.1. It
validates but it isn't nearly as well tested as the previous tree. I'll
try doing some further builds tomorrow and let you all know if anything
goes awry.

Happy building!

Cheers,

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

From asr at eafit.edu.co  Mon Apr 11 03:45:48 2016
From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=)
Date: Sun, 10 Apr 2016 22:45:48 -0500
Subject: GHC 8.0.1-rc3 and required version of elfutils [Was: GHC 8.0.1-rc3
 source tarball availability]
Message-ID: <CAOUWSGC_XZfuomGo_dfmmPN9kRFiMJ=8qktp_HM8MBG1rTMYmw@mail.gmail.com>

On 10 April 2016 at 20:55, Ben Gamari <ben at well-typed.com> wrote:
> I've pushed a new tarball based on
> 9c48d8a02dd80bba3bd313bc52add841530e28dc. I have pushed essentially
> everything into this candidate that I expect will go into 8.0.1. It
> validates but it isn't nearly as well tested as the previous tree. I'll
> try doing some further builds tomorrow and let you all know if anything
> goes awry.

>From running `./configure` on

  http://downloads.haskell.org/~ghc/8.0.1-rc3/ghc-8.0.0.20160408-x86_64-unknown-linux.tar.xz

it seems that the required version of elfutils is 0.158, however this
version of elfutils is not checked when running `./configure` on

  http://downloads.haskell.org/~ghc/8.0.1-rc3/ghc-8.0.0.20160411-src.tar.xz

That is, instead of get an error on configuration time because my
version of elfutils is too old, I get an error on compilation time.

-- 
Andr?s

From carter.schonwald at gmail.com  Mon Apr 11 05:03:09 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 11 Apr 2016 01:03:09 -0400
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <8760voc3jn.fsf@smart-cactus.org>
References: <87egadbj2w.fsf@smart-cactus.org> <570A8A85.8070102@apeiron.net>
 <87bn5hbbaf.fsf@smart-cactus.org> <8760voc3jn.fsf@smart-cactus.org>
Message-ID: <CAHYVw0xEWGgWzNw3X1JKpKPZyN4ijogtwBxGLdc0xnLEf_66xw@mail.gmail.com>

https://wellposed-carter-files.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-8.0.0.20160411-x86_64-apple-darwin.tar.xz

the sha512 is
shasum -a512 ghc-8.0.0.20160411-x86_64-apple-darwin.tar.xz
3cb8b6c2e549539eb6adf0bda080c96018485df62b59889ddc2f4023c406c2eb4e923078721c42e4be3d889ea04dffd84b05de911285f9a0daf71c95fd68fe80

enjoy!

On Sun, Apr 10, 2016 at 9:55 PM, Ben Gamari <ben at well-typed.com> wrote:

> Ben Gamari <ben at well-typed.com> writes:
>
> > Geoffrey Mainland <mainland at apeiron.net> writes:
> >
> >> Does it take a while for the source tarball to show up? All I see is the
> >> Linux binary distribution.
> >>
> > Oh dear, it seems I moved over the wrong file. Sorry about that,
> > everyone.
> >
> > Moreover, I noticed while looking through the patch review queue this
> > afternoon that there are a few patches that should really be in the RC
> > as well. I may take this mistake as an opportunity to fold these in.
> >
> > I'll try to get a new tarball up in the next few hours and post an
> > update here when this happens.
> >
> I've pushed a new tarball based on
> 9c48d8a02dd80bba3bd313bc52add841530e28dc. I have pushed essentially
> everything into this candidate that I expect will go into 8.0.1. It
> validates but it isn't nearly as well tested as the previous tree. I'll
> try doing some further builds tomorrow and let you all know if anything
> goes awry.
>
> Happy building!
>
> 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/20160411/ff3507c1/attachment.html>

From ben at well-typed.com  Mon Apr 11 08:24:17 2016
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 11 Apr 2016 10:24:17 +0200
Subject: GHC 8.0.1-rc3 and required version of elfutils [Was: GHC
 8.0.1-rc3 source tarball availability]
In-Reply-To: <CAOUWSGC_XZfuomGo_dfmmPN9kRFiMJ=8qktp_HM8MBG1rTMYmw@mail.gmail.com>
References: <CAOUWSGC_XZfuomGo_dfmmPN9kRFiMJ=8qktp_HM8MBG1rTMYmw@mail.gmail.com>
Message-ID: <8737qsblji.fsf@smart-cactus.org>

Andr?s Sicard-Ram?rez <asr at eafit.edu.co> writes:

> On 10 April 2016 at 20:55, Ben Gamari <ben at well-typed.com> wrote:
>> I've pushed a new tarball based on
>> 9c48d8a02dd80bba3bd313bc52add841530e28dc. I have pushed essentially
>> everything into this candidate that I expect will go into 8.0.1. It
>> validates but it isn't nearly as well tested as the previous tree. I'll
>> try doing some further builds tomorrow and let you all know if anything
>> goes awry.
>
> From running `./configure` on
>
>   http://downloads.haskell.org/~ghc/8.0.1-rc3/ghc-8.0.0.20160408-x86_64-unknown-linux.tar.xz
>
This binary distribution was uploaded unintentionally and was built for
general public consumption. Our binary distributions won't be built with
libdw support

> it seems that the required version of elfutils is 0.158, however this
> version of elfutils is not checked when running `./configure` on
>
>   http://downloads.haskell.org/~ghc/8.0.1-rc3/ghc-8.0.0.20160411-src.tar.xz
>
> That is, instead of get an error on configuration time because my
> version of elfutils is too old, I get an error on compilation time.
>
Ahhh, yes, it seems like neither the source nor binary distribution
configure scripts actually check for the libdw version. Thanks for
noticing this! I've opened #11820 to track this and D2103 with what I
believe is a fix.

Cheers,

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

From pali.gabor at gmail.com  Mon Apr 11 10:32:07 2016
From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=)
Date: Mon, 11 Apr 2016 12:32:07 +0200
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <8760voc3jn.fsf@smart-cactus.org>
References: <87egadbj2w.fsf@smart-cactus.org> <570A8A85.8070102@apeiron.net>
 <87bn5hbbaf.fsf@smart-cactus.org> <8760voc3jn.fsf@smart-cactus.org>
Message-ID: <CAHnG2Cx-+s=kZyP_-wkcnC-gow4eU6zrrL4SzSurVyHAdeU=wQ@mail.gmail.com>

2016-04-11 3:55 GMT+02:00 Ben Gamari <ben at well-typed.com>:
> Ben Gamari <ben at well-typed.com> writes:
> I've pushed a new tarball based on
> 9c48d8a02dd80bba3bd313bc52add841530e28dc.

The FreeBSD builds (32- and 64-bit, suitable for 9.3-RELEASE or later)
are now available there:

http://haskell.inf.elte.hu/ghc/8.0.0.20160411/

From george.colpitts at gmail.com  Mon Apr 11 11:07:56 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Mon, 11 Apr 2016 11:07:56 +0000
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <8760voc3jn.fsf@smart-cactus.org>
References: <87egadbj2w.fsf@smart-cactus.org> <570A8A85.8070102@apeiron.net>
 <87bn5hbbaf.fsf@smart-cactus.org> <8760voc3jn.fsf@smart-cactus.org>
Message-ID: <CAB-d4A6oEatkob_GpPMwtObP4Zn9TA=hC2BWXzbVo7+4-nmpTg@mail.gmail.com>

This fails for me with the following error; I'm using  the latest macOS and
Xcode.

"inplace/bin/ghc-stage1" -o ghc/stage2/build/tmp/ghc-stage2 -hisuf dyn_hi
-osuf  dyn_o -hcsuf dyn_hc -fPIC -dynamic  -H32m -O -Wall
 -hide-all-packages -i -ighc/. -ighc/stage2/build
-ighc/stage2/build/autogen -Ighc/stage2/build -Ighc/stage2/build/autogen
 -optP-DGHCI -optP-include -optPghc/stage2/build/autogen/cabal_macros.h
-package-id array-0.5.1.0 -package-id base-4.9.0.0 -package-id
bytestring-0.10.7.0 -package-id containers-0.5.7.1 -package-id
deepseq-1.4.2.0 -package-id directory-1.2.5.1 -package-id filepath-1.4.1.0
-package-id ghc-8.0.0.20160411 -package-id ghc-boot-8.0.0.20160411
-package-id ghci-8.0.0.20160411 -package-id haskeline-0.7.2.2 -package-id
process-1.4.2.0 -package-id time-1.6 -package-id transformers-0.5.2.0
-package-id unix-2.7.2.0 -Wall -fno-warn-name-shadowing -XHaskell2010  -O2
-no-hs-main -threaded -no-user-package-db -rtsopts
 -Wnoncanonical-monad-instances  -odir ghc/stage2/build -hidir
ghc/stage2/build -stubdir ghc/stage2/build
 -optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/haskeline/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/terminfo/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/compiler/stage2/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/process/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/hpc/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/hoopl/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/ghci/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/transformers/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/template-haskell/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/pretty/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/ghc-boot/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/directory/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/unix/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/time/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/filepath/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/binary/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/containers/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/bytestring/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/deepseq/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/array/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/base/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/integer-gmp/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/libraries/ghc-prim/dist-install/build'
-optl-L'/Users/gcolpitts/Downloads/ghc-8.0.0.20160411/rts/dist/build'
-optl-lncurses -optl-liconv -optl-lgmp -optl-lm -optl-ldl -fPIC -dynamic
 -H32m -O -Wall      -hide-all-packages -i -ighc/. -ighc/stage2/build
-ighc/stage2/build/autogen -Ighc/stage2/build -Ighc/stage2/build/autogen
 -optP-DGHCI -optP-include -optPghc/stage2/build/autogen/cabal_macros.h
-package-id array-0.5.1.0 -package-id base-4.9.0.0 -package-id
bytestring-0.10.7.0 -package-id containers-0.5.7.1 -package-id
deepseq-1.4.2.0 -package-id directory-1.2.5.1 -package-id filepath-1.4.1.0
-package-id ghc-8.0.0.20160411 -package-id ghc-boot-8.0.0.20160411
-package-id ghci-8.0.0.20160411 -package-id haskeline-0.7.2.2 -package-id
process-1.4.2.0 -package-id time-1.6 -package-id transformers-0.5.2.0
-package-id unix-2.7.2.0 -Wall -fno-warn-name-shadowing -XHaskell2010  -O2
-no-hs-main -threaded -no-user-package-db -rtsopts
 -Wnoncanonical-monad-instances  -fno-use-rpaths -optl-Wl,-rpath
-optl-Wl,'@loader_path/../haskeline-0.7.2.2' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../terminfo-0.4.0.2' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../ghc-8.0.0.20160411' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../process-1.4.2.0' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../hpc-0.6.0.3' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../hoopl-3.10.2.1' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../ghci-8.0.0.20160411' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../transformers-0.5.2.0' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../template-haskell-2.11.0.0' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../pretty-1.1.3.3' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../ghc-boot-8.0.0.20160411' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../directory-1.2.5.1' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../unix-2.7.2.0' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../time-1.6' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../filepath-1.4.1.0' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../binary-0.8.2.1' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../containers-0.5.7.1' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../bytestring-0.10.7.0' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../deepseq-1.4.2.0' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../array-0.5.1.0' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../base-4.9.0.0' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../integer-gmp-1.0.0.1' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../ghc-prim-0.5.0.0' -optl-Wl,-rpath
-optl-Wl,'@loader_path/../rts' ghc/stage2/build/Main.dyn_o
ghc/stage2/build/GHCi/UI.dyn_o ghc/stage2/build/GHCi/UI/Info.dyn_o
ghc/stage2/build/GHCi/UI/Monad.dyn_o ghc/stage2/build/GHCi/UI/Tags.dyn_o
ghc/stage2/build/hschooks.dyn_o
Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main.
    Call hs_init_ghc() from your main() function to set these options.
Undefined symbols for architecture x86_64:
  "_stg_sel_17_upd_info", referenced from:
      _s1xEL_info in UI.dyn_o
      _s1xG6_info in UI.dyn_o
      _s1xPC_info in UI.dyn_o
      _s1xQ9_info in UI.dyn_o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
`gcc' failed in phase `Linker'. (Exit code: 1)
make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1
make: *** [all] Error 2
bash-3.2$



On Sun, Apr 10, 2016 at 10:55 PM Ben Gamari <ben at well-typed.com> wrote:

> Ben Gamari <ben at well-typed.com> writes:
>
> > Geoffrey Mainland <mainland at apeiron.net> writes:
> >
> >> Does it take a while for the source tarball to show up? All I see is the
> >> Linux binary distribution.
> >>
> > Oh dear, it seems I moved over the wrong file. Sorry about that,
> > everyone.
> >
> > Moreover, I noticed while looking through the patch review queue this
> > afternoon that there are a few patches that should really be in the RC
> > as well. I may take this mistake as an opportunity to fold these in.
> >
> > I'll try to get a new tarball up in the next few hours and post an
> > update here when this happens.
> >
> I've pushed a new tarball based on
> 9c48d8a02dd80bba3bd313bc52add841530e28dc. I have pushed essentially
> everything into this candidate that I expect will go into 8.0.1. It
> validates but it isn't nearly as well tested as the previous tree. I'll
> try doing some further builds tomorrow and let you all know if anything
> goes awry.
>
> Happy building!
>
> 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/20160411/df6ab57a/attachment.html>

From asr at eafit.edu.co  Mon Apr 11 12:17:01 2016
From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=)
Date: Mon, 11 Apr 2016 07:17:01 -0500
Subject: GHC 8.0.1-rc3 and required version of elfutils [Was: GHC
 8.0.1-rc3 source tarball availability]
In-Reply-To: <8737qsblji.fsf@smart-cactus.org>
References: <CAOUWSGC_XZfuomGo_dfmmPN9kRFiMJ=8qktp_HM8MBG1rTMYmw@mail.gmail.com>
 <8737qsblji.fsf@smart-cactus.org>
Message-ID: <CAOUWSGDiJM_bG=833KUc=aw5bM+WWXEVARpGUEte=DLjDWqjnw@mail.gmail.com>

2016-04-11 3:24 GMT-05:00 Ben Gamari <ben at well-typed.com>:
> Our binary distributions won't be built with
> libdw support
>

> Ahhh, yes, it seems like neither the source nor binary distribution
> configure scripts actually check for the libdw version. Thanks for
> noticing this! I've opened #11820 to track this and D2103 with what I
> believe is a fix.

Good to know I'll be able to use 8.0.1 on my Ubuntu 12.04.5 LTS. Thanks!



-- 
Andr?s

From ben at well-typed.com  Mon Apr 11 12:32:58 2016
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 11 Apr 2016 14:32:58 +0200
Subject: GHC 8.0.1-rc3 and required version of elfutils [Was: GHC
 8.0.1-rc3 source tarball availability]
In-Reply-To: <8737qsblji.fsf@smart-cactus.org>
References: <CAOUWSGC_XZfuomGo_dfmmPN9kRFiMJ=8qktp_HM8MBG1rTMYmw@mail.gmail.com>
 <8737qsblji.fsf@smart-cactus.org>
Message-ID: <87egac1g1x.fsf@smart-cactus.org>

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

> Andr?s Sicard-Ram?rez <asr at eafit.edu.co> writes:
>
>> On 10 April 2016 at 20:55, Ben Gamari <ben at well-typed.com> wrote:
>>> I've pushed a new tarball based on
>>> 9c48d8a02dd80bba3bd313bc52add841530e28dc. I have pushed essentially
>>> everything into this candidate that I expect will go into 8.0.1. It
>>> validates but it isn't nearly as well tested as the previous tree. I'll
>>> try doing some further builds tomorrow and let you all know if anything
>>> goes awry.
>>
>> From running `./configure` on
>>
>>   http://downloads.haskell.org/~ghc/8.0.1-rc3/ghc-8.0.0.20160408-x86_64-unknown-linux.tar.xz
>>
> This binary distribution was uploaded unintentionally and was built for
> general public consumption.
>
Ahem, that was supposed to read "was *not* built for public
consumption".

Apologies for the confusion.

Cheers,

- Ben

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

From ben at well-typed.com  Mon Apr 11 12:33:50 2016
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 11 Apr 2016 14:33:50 +0200
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <CAB-d4A6oEatkob_GpPMwtObP4Zn9TA=hC2BWXzbVo7+4-nmpTg@mail.gmail.com>
References: <87egadbj2w.fsf@smart-cactus.org> <570A8A85.8070102@apeiron.net>
 <87bn5hbbaf.fsf@smart-cactus.org> <8760voc3jn.fsf@smart-cactus.org>
 <CAB-d4A6oEatkob_GpPMwtObP4Zn9TA=hC2BWXzbVo7+4-nmpTg@mail.gmail.com>
Message-ID: <87d1pw1g0h.fsf@smart-cactus.org>

George Colpitts <george.colpitts at gmail.com> writes:

> This fails for me with the following error; I'm using  the latest macOS and
> Xcode.
>
Hmm, this is very odd. Unfortunately due to firewall issues I don't have
reliable access to our OS X box, so I was unable to test this particular
tarball, but a few days ago I was able to build without any trouble.

Have you checked the obvious things (e.g. distclean, rebuild, etc.)?

Cheers,

- Ben

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

From carter.schonwald at gmail.com  Mon Apr 11 14:06:24 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 11 Apr 2016 10:06:24 -0400
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <87d1pw1g0h.fsf@smart-cactus.org>
References: <87egadbj2w.fsf@smart-cactus.org> <570A8A85.8070102@apeiron.net>
 <87bn5hbbaf.fsf@smart-cactus.org> <8760voc3jn.fsf@smart-cactus.org>
 <CAB-d4A6oEatkob_GpPMwtObP4Zn9TA=hC2BWXzbVo7+4-nmpTg@mail.gmail.com>
 <87d1pw1g0h.fsf@smart-cactus.org>
Message-ID: <CAHYVw0zSFDXbbxGpidr8it6RwfxmS2K+65sHUdB_uw-GkazUPQ@mail.gmail.com>

George: does my build work for you?

On Monday, April 11, 2016, Ben Gamari <ben at well-typed.com> wrote:

> George Colpitts <george.colpitts at gmail.com <javascript:;>> writes:
>
> > This fails for me with the following error; I'm using  the latest macOS
> and
> > Xcode.
> >
> Hmm, this is very odd. Unfortunately due to firewall issues I don't have
> reliable access to our OS X box, so I was unable to test this particular
> tarball, but a few days ago I was able to build without any trouble.
>
> Have you checked the obvious things (e.g. distclean, rebuild, etc.)?
>
> Cheers,
>
> - Ben
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160411/c9dc0aa0/attachment.html>

From johannes.waldmann at htwk-leipzig.de  Mon Apr 11 17:43:07 2016
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Mon, 11 Apr 2016 19:43:07 +0200
Subject: how to cabal-install with ghc-8.rc3 ?
Message-ID: <570BE22B.20101@htwk-leipzig.de>

Hi.

I would love to test rc3. Building (with 7.10.3)
from source went fine. But then I cannot cabal-install anything:

random-1.1: installed package info from too old version of Cabal (key field
does not match id field)
Failed to install random-1.1

What is the recommended upgrade path?

( bootstrap.sh in cabal/cabal-install (current from github)
does not work, tries to download a Cabal version that's not on hackage )

Thanks, J.W.


From ben at well-typed.com  Mon Apr 11 18:06:58 2016
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 11 Apr 2016 20:06:58 +0200
Subject: how to cabal-install with ghc-8.rc3 ?
In-Reply-To: <570BE22B.20101@htwk-leipzig.de>
References: <570BE22B.20101@htwk-leipzig.de>
Message-ID: <87shysf29p.fsf@smart-cactus.org>

Johannes Waldmann <johannes.waldmann at htwk-leipzig.de> writes:

> Hi.
>
> I would love to test rc3. Building (with 7.10.3)
> from source went fine. But then I cannot cabal-install anything:
>
> random-1.1: installed package info from too old version of Cabal (key field
> does not match id field)
> Failed to install random-1.1
>
> What is the recommended upgrade path?
>
See [1].

Cheers,

- Ben


[1] https://mail.haskell.org/pipermail/ghc-devs/2016-February/011409.html

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

From johannes.waldmann at htwk-leipzig.de  Mon Apr 11 19:10:06 2016
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Mon, 11 Apr 2016 21:10:06 +0200
Subject: how to cabal-install with ghc-8.rc3 ?
In-Reply-To: <87shysf29p.fsf@smart-cactus.org>
References: <570BE22B.20101@htwk-leipzig.de> <87shysf29p.fsf@smart-cactus.org>
Message-ID: <570BF68E.8010304@htwk-leipzig.de>

On 11.04.2016 20:06, Ben Gamari wrote:

> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-February/011409.html

Ah! I needed to do the above with ghc < 8.rc3 ,
then it created a cabal-install that works for 8.rc3 .

Thanks - J.W.


From eir at cis.upenn.edu  Mon Apr 11 19:53:12 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 11 Apr 2016 15:53:12 -0400
Subject: reduce needs for InScopeSets?
Message-ID: <F797D004-69E1-4A1A-8451-B820260A01CA@cis.upenn.edu>

Hi all,

I now frequently run across ASSERTion failures triggered by the new substitution invariant checks. This is surely a good thing, but it's gotten me thinking about the need for InScopeSets in substitutions at all. It seems to me that the only(?) use of the InScopeSet is in the uniqAway in substTyVarBndr. uniqAway is used here when the kind of a tyvar changes.

Why do we need a new unique when a tyvar's kind changes? Can't we just update the kinds of tyvar occurrences?

One might argue that updating tyvar occurrences' kinds is inefficient. This may be true, but we can tackle that problem head-on by storing a separate TyVarEnv Type that contains tyvar occurrence updates. There's still no need for a new unique.

If we can get rid of InScopeSets in substitutions, that would be a wonderful thing, I think.

Separately, I also see that substTyVar does not currently recur into a tyvar's kind, if the tyvar is not mapped by the substitution. This behavior seems wrong to me, but I guess it's worked thus far.

Thoughts?

Richard

From george.colpitts at gmail.com  Mon Apr 11 21:57:02 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Mon, 11 Apr 2016 18:57:02 -0300
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <87d1pw1g0h.fsf@smart-cactus.org>
References: <87egadbj2w.fsf@smart-cactus.org> <570A8A85.8070102@apeiron.net>
 <87bn5hbbaf.fsf@smart-cactus.org> <8760voc3jn.fsf@smart-cactus.org>
 <CAB-d4A6oEatkob_GpPMwtObP4Zn9TA=hC2BWXzbVo7+4-nmpTg@mail.gmail.com>
 <87d1pw1g0h.fsf@smart-cactus.org>
Message-ID: <CAB-d4A7xLvTHFQX0vvsxyCcLafkvE4KtH_oS7qf_S6rt6obWxA@mail.gmail.com>

Thanks Ben, none of this is obvious to me  :) I just read the doc which
doesn't mention distclean or rebuild
? which I have never had to do on earlier source distributions?
?
. I did a make distclean, then a configure, then a make -j5 and got the
same error. by rebuild do you mean do it again starting from scratch?

I did google the error, i.e. 'Haskell "_stg_sel_17_upd_info" ' and found
that a few people have encountered this this month. Most importantly it led
me to https://ghc.haskell.org/trac/ghc/ticket/11155#comment:10 :

Changed 2 days ago by wereHamster
? Reply
Ran into this trying to build HEAD today on Mac OS X 10.11.3. But a
slightly different message:

Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main.
    Call hs_init_ghc() from your main() function to set these options.
Undefined symbols for architecture x86_64:
  "_stg_sel_17_upd_info", referenced from:
      _s1xPf_info in UI.dyn_o
      _s1xQA_info in UI.dyn_o
      _s1xZU_info in UI.dyn_o
      _s1y0r_info in UI.dyn_o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
`gcc' failed in phase `Linker'. (Exit code: 1)
make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1
make: *** [all] Error 2

??Should I reopen 11155 or open a new ticket?

Thanks
George



On Mon, Apr 11, 2016 at 9:33 AM Ben Gamari <ben at well-typed.com> wrote:

> George Colpitts <george.colpitts at gmail.com> writes:
>
> > This fails for me with the following error; I'm using  the latest macOS
> and
> > Xcode.
> >
> Hmm, this is very odd. Unfortunately due to firewall issues I don't have
> reliable access to our OS X box, so I was unable to test this particular
> tarball, but a few days ago I was able to build without any trouble.
>
> Have you checked the obvious things (e.g. distclean, rebuild, etc.)?
>
> Cheers,
>
> - Ben
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160411/1c65bd79/attachment-0001.html>

From carter.schonwald at gmail.com  Mon Apr 11 22:36:41 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 11 Apr 2016 18:36:41 -0400
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <CAB-d4A7xLvTHFQX0vvsxyCcLafkvE4KtH_oS7qf_S6rt6obWxA@mail.gmail.com>
References: <87egadbj2w.fsf@smart-cactus.org> <570A8A85.8070102@apeiron.net>
 <87bn5hbbaf.fsf@smart-cactus.org> <8760voc3jn.fsf@smart-cactus.org>
 <CAB-d4A6oEatkob_GpPMwtObP4Zn9TA=hC2BWXzbVo7+4-nmpTg@mail.gmail.com>
 <87d1pw1g0h.fsf@smart-cactus.org>
 <CAB-d4A7xLvTHFQX0vvsxyCcLafkvE4KtH_oS7qf_S6rt6obWxA@mail.gmail.com>
Message-ID: <CAHYVw0zGWiRygrcncH_CaZm=G5qHYBye6JWyiP7nR68QajSn1g@mail.gmail.com>

George: In the mean time does my build work on your machine?
On Apr 11, 2016 5:57 PM, "George Colpitts" <george.colpitts at gmail.com>
wrote:

> Thanks Ben, none of this is obvious to me  :) I just read the doc which
> doesn't mention distclean or rebuild
> ? which I have never had to do on earlier source distributions?
> ?
> . I did a make distclean, then a configure, then a make -j5 and got the
> same error. by rebuild do you mean do it again starting from scratch?
>
> I did google the error, i.e. 'Haskell "_stg_sel_17_upd_info" ' and found
> that a few people have encountered this this month. Most importantly it led
> me to https://ghc.haskell.org/trac/ghc/ticket/11155#comment:10 :
>
> Changed 2 days ago by wereHamster
> ? Reply
> Ran into this trying to build HEAD today on Mac OS X 10.11.3. But a
> slightly different message:
>
> Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main.
>     Call hs_init_ghc() from your main() function to set these options.
> Undefined symbols for architecture x86_64:
>   "_stg_sel_17_upd_info", referenced from:
>       _s1xPf_info in UI.dyn_o
>       _s1xQA_info in UI.dyn_o
>       _s1xZU_info in UI.dyn_o
>       _s1y0r_info in UI.dyn_o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> `gcc' failed in phase `Linker'. (Exit code: 1)
> make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1
> make: *** [all] Error 2
>
> ??Should I reopen 11155 or open a new ticket?
>
> Thanks
> George
>
>
>
> On Mon, Apr 11, 2016 at 9:33 AM Ben Gamari <ben at well-typed.com> wrote:
>
>> George Colpitts <george.colpitts at gmail.com> writes:
>>
>> > This fails for me with the following error; I'm using  the latest macOS
>> and
>> > Xcode.
>> >
>> Hmm, this is very odd. Unfortunately due to firewall issues I don't have
>> reliable access to our OS X box, so I was unable to test this particular
>> tarball, but a few days ago I was able to build without any trouble.
>>
>> Have you checked the obvious things (e.g. distclean, rebuild, etc.)?
>>
>> 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/20160411/01166e81/attachment.html>

From simonpj at microsoft.com  Mon Apr 11 22:39:25 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 11 Apr 2016 22:39:25 +0000
Subject: reduce needs for InScopeSets?
In-Reply-To: <F797D004-69E1-4A1A-8451-B820260A01CA@cis.upenn.edu>
References: <F797D004-69E1-4A1A-8451-B820260A01CA@cis.upenn.edu>
Message-ID: <4493c96e12574c37a429d8d58aff4bb7@DB4PR30MB030.064d.mgd.msft.net>

It's _nothing_ to do with whether the kind changes!

It's everything to do with cloning the binder if it is already in scope.  See "Secrets of the GHC inliner", the section called "The rapier", I think.

| Separately, I also see that substTyVar does not currently recur into a
| tyvar's kind, if the tyvar is not mapped by the substitution. This behavior
| seems wrong to me, but I guess it's worked thus far.

Well that would be deeply strange.  The point is that every occurrence of a type variable should have the same kind as its binding site.  So if we have
    forall (a:k).  ....(a:k')....
then k and k' should jolly well be the same.

Suppose the substitution S has a binding kv -> k, for some kind variable kv.  Then suppose apply this substitution to 
    forall (a:blah). ...(a:blah)...
where blah mentions kv. Then we'll substitute k for kv in blah, and extend the substitution with (a:blah) -> (a : S(blah)). That will ensure that all occurrences of a get updated.

But it would be most odd to apply S to the body of the forall, but not to the binder.   Recursing into the kind would give 
   forall (a:blah. ....(a:S(blah))...
which is bogus (Lint will reject it).  But not recursing into the kind would also go wrong if we had, say (Proxy blah (a:blah)).  The if we don?t recurse in we'd get Proxy S(blah) (a:blah), which is bogus.

So there's another invariant hiding here, but I'm not sure how to state it.

Simon
  
| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard
| Eisenberg
| Sent: 11 April 2016 20:53
| To: ghc-devs at haskell.org developers <ghc-devs at haskell.org>
| Subject: reduce needs for InScopeSets?
| 
| Hi all,
| 
| I now frequently run across ASSERTion failures triggered by the new
| substitution invariant checks. This is surely a good thing, but it's gotten
| me thinking about the need for InScopeSets in substitutions at all. It seems
| to me that the only(?) use of the InScopeSet is in the uniqAway in
| substTyVarBndr. uniqAway is used here when the kind of a tyvar changes.
| 	
| Why do we need a new unique when a tyvar's kind changes? Can't we just update
| the kinds of tyvar occurrences?
| 
| One might argue that updating tyvar occurrences' kinds is inefficient. This
| may be true, but we can tackle that problem head-on by storing a separate
| TyVarEnv Type that contains tyvar occurrence updates. There's still no need
| for a new unique.
| 
| If we can get rid of InScopeSets in substitutions, that would be a wonderful
| thing, I think.
| 
| Separately, I also see that substTyVar does not currently recur into a
| tyvar's kind, if the tyvar is not mapped by the substitution. This behavior
| seems wrong to me, but I guess it's worked thus far.
| 
| Thoughts?
| 
| Richard
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From george.colpitts at gmail.com  Mon Apr 11 23:33:22 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Mon, 11 Apr 2016 23:33:22 +0000
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <CAHYVw0zGWiRygrcncH_CaZm=G5qHYBye6JWyiP7nR68QajSn1g@mail.gmail.com>
References: <87egadbj2w.fsf@smart-cactus.org> <570A8A85.8070102@apeiron.net>
 <87bn5hbbaf.fsf@smart-cactus.org> <8760voc3jn.fsf@smart-cactus.org>
 <CAB-d4A6oEatkob_GpPMwtObP4Zn9TA=hC2BWXzbVo7+4-nmpTg@mail.gmail.com>
 <87d1pw1g0h.fsf@smart-cactus.org>
 <CAB-d4A7xLvTHFQX0vvsxyCcLafkvE4KtH_oS7qf_S6rt6obWxA@mail.gmail.com>
 <CAHYVw0zGWiRygrcncH_CaZm=G5qHYBye6JWyiP7nR68QajSn1g@mail.gmail.com>
Message-ID: <CAB-d4A4GFDasYVEE3t+iVyiS_ve+_ivVR9qVa2rJYGOwM9FWHQ@mail.gmail.com>

Yes it does.

On Mon, Apr 11, 2016 at 7:36 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> George: In the mean time does my build work on your machine?
> On Apr 11, 2016 5:57 PM, "George Colpitts" <george.colpitts at gmail.com>
> wrote:
>
>> Thanks Ben, none of this is obvious to me  :) I just read the doc which
>> doesn't mention distclean or rebuild
>> ? which I have never had to do on earlier source distributions?
>> ?
>> . I did a make distclean, then a configure, then a make -j5 and got the
>> same error. by rebuild do you mean do it again starting from scratch?
>>
>> I did google the error, i.e. 'Haskell "_stg_sel_17_upd_info" ' and found
>> that a few people have encountered this this month. Most importantly it led
>> me to https://ghc.haskell.org/trac/ghc/ticket/11155#comment:10 :
>>
>> Changed 2 days ago by wereHamster
>> ? Reply
>> Ran into this trying to build HEAD today on Mac OS X 10.11.3. But a
>> slightly different message:
>>
>> Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main.
>>     Call hs_init_ghc() from your main() function to set these options.
>> Undefined symbols for architecture x86_64:
>>   "_stg_sel_17_upd_info", referenced from:
>>       _s1xPf_info in UI.dyn_o
>>       _s1xQA_info in UI.dyn_o
>>       _s1xZU_info in UI.dyn_o
>>       _s1y0r_info in UI.dyn_o
>> ld: symbol(s) not found for architecture x86_64
>> clang: error: linker command failed with exit code 1 (use -v to see
>> invocation)
>> `gcc' failed in phase `Linker'. (Exit code: 1)
>> make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1
>> make: *** [all] Error 2
>>
>> ??Should I reopen 11155 or open a new ticket?
>>
>> Thanks
>> George
>>
>>
>>
>> On Mon, Apr 11, 2016 at 9:33 AM Ben Gamari <ben at well-typed.com> wrote:
>>
>>> George Colpitts <george.colpitts at gmail.com> writes:
>>>
>>> > This fails for me with the following error; I'm using  the latest
>>> macOS and
>>> > Xcode.
>>> >
>>> Hmm, this is very odd. Unfortunately due to firewall issues I don't have
>>> reliable access to our OS X box, so I was unable to test this particular
>>> tarball, but a few days ago I was able to build without any trouble.
>>>
>>> Have you checked the obvious things (e.g. distclean, rebuild, etc.)?
>>>
>>> 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/20160411/cb7d6f21/attachment-0001.html>

From conal at conal.net  Tue Apr 12 02:40:02 2016
From: conal at conal.net (Conal Elliott)
Date: Mon, 11 Apr 2016 19:40:02 -0700
Subject: Broken haddock in new GHC HEAD build
In-Reply-To: <8737qx4x7x.fsf@smart-cactus.org>
References: <CAD6SzRJxCruS=-ov8NQeZQJk8SZTy17Vr=h2h9SwgNPDzZ4wQg@mail.gmail.com>
 <8737qx4x7x.fsf@smart-cactus.org>
Message-ID: <CAD6SzR+P3KVPAbBUvw2ZZEA4WenefEHXNYB9XzSJAPzUSH+vSw@mail.gmail.com>

Thanks for the reply, Ben. I guess I'm not 100% sure, as I tried a few
variations. Next time I rebuild GHC, I'll take care to record my steps and
see what happens.  - Conal

On Thu, Apr 7, 2016 at 1:52 AM, Ben Gamari <ben at well-typed.com> wrote:

> Conal Elliott <conal at conal.net> writes:
>
> > I built GHC HEAD from git yesterday (using GHC 7.10.3 on Mac OS 10.9.5),
> > and the haddock I got dies with
> >
> Thanks for the report, Conal!
>
>
> >     bash-3.2$ haddock --version
> >     dyld: Symbol not found: _ghc_GHC_modInfoExportszugo_info
> >       Referenced from:
> > /Users/conal/git-repos/ghc-2016-04-05/inplace/lib/bin/haddock
> >       Expected in:
> >
> /Users/conal/git-repos/ghc-2016-04-05/compiler/stage2/build/libHSghc-8.1-ghc8.1.20160405.dylib
> >      in /Users/conal/git-repos/ghc-2016-04-05/inplace/lib/bin/haddock
> >     Trace/BPT trap: 5
> >
> > Luckily, I have a working haddock from 2016-03-07 sources that I copied
> > into my new GHC bin (~/git-repos/ghc-2016-04-05/inplace/bin/) for now.
>
> Hmm, this is quite concerning, especially considering I haven't observed
> it in my own OS X builds. Are you sure you started from a clean tree
> (e.g. ran `make distclean`)?
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160411/843495dc/attachment.html>

From mle+hs at mega-nerd.com  Tue Apr 12 04:22:23 2016
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Tue, 12 Apr 2016 14:22:23 +1000
Subject: TH changes for ghc 8.0
Message-ID: <20160412142223.2a789bc08233a6d66153aae8@mega-nerd.com>

Hi all,

I'm working on updating persistent-template for ghc-8.0 and reading the
migration guide:

    https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0#template-haskell-2.11.0.0

specifically the bit that says:

> * the DataD, NewtypeD, DataInstD, and NewtypeInstD constructors have a new
>   field `Maybe Kind` (#10828), and take a `CxtQ` instead of a `[Name]` for
>   the derived classes (#10819). If you don't know what to do, use `Nothing`
>   for the kind signature, and `cxt []` for the derived classes. 

Using `Nothing` as suggested is working out well enough, but I'm a bit befuddled
by the change from `[Name]` to `CtxQ` and the usage of `ctx []`. I can't seem to
find *any* function named `ctx`.

Any light people may be about to shed on this would be much appreciated.

Cheers,
Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From mf at zerobuzz.net  Tue Apr 12 05:36:59 2016
From: mf at zerobuzz.net (Matthias Fischmann)
Date: Tue, 12 Apr 2016 07:36:59 +0200
Subject: TH changes for ghc 8.0
In-Reply-To: <20160412142223.2a789bc08233a6d66153aae8@mega-nerd.com>
References: <20160412142223.2a789bc08233a6d66153aae8@mega-nerd.com>
Message-ID: <20160412053659.GD1519@lig>

On Tue, Apr 12, 2016 at 02:22:23PM +1000, Erik de Castro Lopo wrote:
> Date: Tue, 12 Apr 2016 14:22:23 +1000
> From: Erik de Castro Lopo <mle+hs at mega-nerd.com>
> To: ghc-devs at haskell.org
> Subject: TH changes for ghc 8.0
>
> Hi all,
>
> I'm working on updating persistent-template for ghc-8.0 and reading the
> migration guide:
>
>     https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0#template-haskell-2.11.0.0
>
> specifically the bit that says:
>
> > * the DataD, NewtypeD, DataInstD, and NewtypeInstD constructors have a new
> >   field `Maybe Kind` (#10828), and take a `CxtQ` instead of a `[Name]` for
> >   the derived classes (#10819). If you don't know what to do, use `Nothing`
> >   for the kind signature, and `cxt []` for the derived classes.
>
> Using `Nothing` as suggested is working out well enough, but I'm a bit befuddled
> by the change from `[Name]` to `CtxQ` and the usage of `ctx []`. I can't seem to
> find *any* function named `ctx`.

the docs say `cxt`, not `ctx`.

not sure what that means either.  (-:

cheers,
m.

From hesselink at gmail.com  Tue Apr 12 07:34:15 2016
From: hesselink at gmail.com (Erik Hesselink)
Date: Tue, 12 Apr 2016 09:34:15 +0200
Subject: TH changes for ghc 8.0
In-Reply-To: <20160412053659.GD1519@lig>
References: <20160412142223.2a789bc08233a6d66153aae8@mega-nerd.com>
 <20160412053659.GD1519@lig>
Message-ID: <CAPeieQHJr9aYL2ymaQ4ML4iJjWjajgkQSyPKo_kEbxVkEk_bCQ@mail.gmail.com>

On 12 April 2016 at 07:36, Matthias Fischmann <mf at zerobuzz.net> wrote:
> On Tue, Apr 12, 2016 at 02:22:23PM +1000, Erik de Castro Lopo wrote:
>> Date: Tue, 12 Apr 2016 14:22:23 +1000
>> From: Erik de Castro Lopo <mle+hs at mega-nerd.com>
>> To: ghc-devs at haskell.org
>> Subject: TH changes for ghc 8.0
>>
>> Hi all,
>>
>> I'm working on updating persistent-template for ghc-8.0 and reading the
>> migration guide:
>>
>>     https://ghc.haskell.org/trac/ghc/wiki/Migration/8.0#template-haskell-2.11.0.0
>>
>> specifically the bit that says:
>>
>> > * the DataD, NewtypeD, DataInstD, and NewtypeInstD constructors have a new
>> >   field `Maybe Kind` (#10828), and take a `CxtQ` instead of a `[Name]` for
>> >   the derived classes (#10819). If you don't know what to do, use `Nothing`
>> >   for the kind signature, and `cxt []` for the derived classes.
>>
>> Using `Nothing` as suggested is working out well enough, but I'm a bit befuddled
>> by the change from `[Name]` to `CtxQ` and the usage of `ctx []`. I can't seem to
>> find *any* function named `ctx`.
>
> the docs say `cxt`, not `ctx`.
>
> not sure what that means either.  (-:

That function does exist for me in rc2:

cxt :: [PredQ] -> CxtQ

Erik

From ben at well-typed.com  Tue Apr 12 08:10:48 2016
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 12 Apr 2016 10:10:48 +0200
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <CAB-d4A7xLvTHFQX0vvsxyCcLafkvE4KtH_oS7qf_S6rt6obWxA@mail.gmail.com>
References: <87egadbj2w.fsf@smart-cactus.org> <570A8A85.8070102@apeiron.net>
 <87bn5hbbaf.fsf@smart-cactus.org> <8760voc3jn.fsf@smart-cactus.org>
 <CAB-d4A6oEatkob_GpPMwtObP4Zn9TA=hC2BWXzbVo7+4-nmpTg@mail.gmail.com>
 <87d1pw1g0h.fsf@smart-cactus.org>
 <CAB-d4A7xLvTHFQX0vvsxyCcLafkvE4KtH_oS7qf_S6rt6obWxA@mail.gmail.com>
Message-ID: <87oa9ffdrr.fsf@smart-cactus.org>

George Colpitts <george.colpitts at gmail.com> writes:

> Thanks Ben, none of this is obvious to me :) I just read the doc which
> doesn't mention distclean or rebuild ? which I have never had to do on
> earlier source distributions?
> ?
Hi George!

Sorry for the poor choice of words, indeed the tracking down issue like this
is anything but obvious; thanks for your time identifying this one!

For the record, `make distclean` is a more thorough variant of `make
clean`; distclean'ing a fresh source distribution should never
be necessary, although it is often a good first step just to make sure
things are in a known state.

> . I did a make distclean, then a configure, then a make -j5 and got the
> same error. by rebuild do you mean do it again starting from scratch?
>
> I did google the error, i.e. 'Haskell "_stg_sel_17_upd_info" ' and found
> that a few people have encountered this this month. Most importantly it led
> me to https://ghc.haskell.org/trac/ghc/ticket/11155#comment:10 :
>
Ahh, great find! Yes, it sounds like this issue is still not resolved
although the fact that it now only appears to occur on OS X boxen is
rather odd. Let's continue this discussion on the ticket.

Cheers,

- Ben

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

From mle+hs at mega-nerd.com  Tue Apr 12 08:17:02 2016
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Tue, 12 Apr 2016 18:17:02 +1000
Subject: TH changes for ghc 8.0
In-Reply-To: <CAPeieQHJr9aYL2ymaQ4ML4iJjWjajgkQSyPKo_kEbxVkEk_bCQ@mail.gmail.com>
References: <20160412142223.2a789bc08233a6d66153aae8@mega-nerd.com>
 <20160412053659.GD1519@lig>
 <CAPeieQHJr9aYL2ymaQ4ML4iJjWjajgkQSyPKo_kEbxVkEk_bCQ@mail.gmail.com>
Message-ID: <20160412181702.9ac5dca7dd114ebfd2350513@mega-nerd.com>

Erik Hesselink wrote:

> That function does exist for me in rc2:
> 
> cxt :: [PredQ] -> CxtQ

Ah, there is it is!

But I'm trying to write code that works with ghc-7.10 *and* ghc-8.0
(yes, I'm using CPP in all its ugly glory), but if I've got code that
works with ghc-7.10 (the first type signature below):

> - dataD :: CxtQ -> Name -> [TyVarBndr]               -> [ConQ] -> [Name] -> DecQ
> + dataD :: CxtQ -> Name -> [TyVarBndr] -> Maybe Kind -> [ConQ] -> CxtQ   -> DecQ

how do I convert it to the second? Adding a `Nothing` for the `Maybe
Kind` argument is easy, but if the old code has `[Name]`, how do I
convert it to a `CxtQ`. The `cxt` function won't do it.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From christiaan.baaij at gmail.com  Tue Apr 12 08:29:32 2016
From: christiaan.baaij at gmail.com (Christiaan Baaij)
Date: Tue, 12 Apr 2016 10:29:32 +0200
Subject: TH changes for ghc 8.0
In-Reply-To: <20160412181702.9ac5dca7dd114ebfd2350513@mega-nerd.com>
References: <20160412142223.2a789bc08233a6d66153aae8@mega-nerd.com>
 <20160412053659.GD1519@lig>
 <CAPeieQHJr9aYL2ymaQ4ML4iJjWjajgkQSyPKo_kEbxVkEk_bCQ@mail.gmail.com>
 <20160412181702.9ac5dca7dd114ebfd2350513@mega-nerd.com>
Message-ID: <570CB1EC.4020808@gmail.com>

mapM conT :: [Name] -> Q [Type] :: [Name] -> Q [Pred] :: [Name] -> CxtQ

Those `Name`s are Class names, which are Type constructors, hence `conT`

Christiaan

On 04/12/2016 10:17 AM, Erik de Castro Lopo wrote:
> Erik Hesselink wrote:
>
>> That function does exist for me in rc2:
>>
>> cxt :: [PredQ] -> CxtQ
>
> Ah, there is it is!
>
> But I'm trying to write code that works with ghc-7.10 *and* ghc-8.0
> (yes, I'm using CPP in all its ugly glory), but if I've got code that
> works with ghc-7.10 (the first type signature below):
>
>> - dataD :: CxtQ -> Name -> [TyVarBndr]               -> [ConQ] -> [Name] -> DecQ
>> + dataD :: CxtQ -> Name -> [TyVarBndr] -> Maybe Kind -> [ConQ] -> CxtQ   -> DecQ
>
> how do I convert it to the second? Adding a `Nothing` for the `Maybe
> Kind` argument is easy, but if the old code has `[Name]`, how do I
> convert it to a `CxtQ`. The `cxt` function won't do it.
>
> Erik
>

From mle+hs at mega-nerd.com  Tue Apr 12 08:56:43 2016
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Tue, 12 Apr 2016 18:56:43 +1000
Subject: TH changes for ghc 8.0
In-Reply-To: <570CB1EC.4020808@gmail.com>
References: <20160412142223.2a789bc08233a6d66153aae8@mega-nerd.com>
 <20160412053659.GD1519@lig>
 <CAPeieQHJr9aYL2ymaQ4ML4iJjWjajgkQSyPKo_kEbxVkEk_bCQ@mail.gmail.com>
 <20160412181702.9ac5dca7dd114ebfd2350513@mega-nerd.com>
 <570CB1EC.4020808@gmail.com>
Message-ID: <20160412185643.11c9ef4576d78ebabf0f4071@mega-nerd.com>

Christiaan Baaij wrote:

> mapM conT :: [Name] -> Q [Type] :: [Name] -> Q [Pred] :: [Name] -> CxtQ
> 
> Those `Name`s are Class names, which are Type constructors, hence `conT`

Thanks Christiaan, thats got it for me. I'll update the migration guide
as well.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From ben at smart-cactus.org  Tue Apr 12 09:05:14 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 12 Apr 2016 11:05:14 +0200
Subject: TH changes for ghc 8.0
In-Reply-To: <20160412185643.11c9ef4576d78ebabf0f4071@mega-nerd.com>
References: <20160412142223.2a789bc08233a6d66153aae8@mega-nerd.com>
 <20160412053659.GD1519@lig>
 <CAPeieQHJr9aYL2ymaQ4ML4iJjWjajgkQSyPKo_kEbxVkEk_bCQ@mail.gmail.com>
 <20160412181702.9ac5dca7dd114ebfd2350513@mega-nerd.com>
 <570CB1EC.4020808@gmail.com>
 <20160412185643.11c9ef4576d78ebabf0f4071@mega-nerd.com>
Message-ID: <87lh4jfb91.fsf@smart-cactus.org>

Erik de Castro Lopo <mle+hs at mega-nerd.com> writes:

> Christiaan Baaij wrote:
>
>> mapM conT :: [Name] -> Q [Type] :: [Name] -> Q [Pred] :: [Name] -> CxtQ
>> 
>> Those `Name`s are Class names, which are Type constructors, hence `conT`
>
> Thanks Christiaan, thats got it for me. I'll update the migration guide
> as well.
>
Thanks Erik!

Cheers,

- Ben

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

From eir at cis.upenn.edu  Tue Apr 12 12:52:32 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 12 Apr 2016 08:52:32 -0400
Subject: reduce needs for InScopeSets?
In-Reply-To: <4493c96e12574c37a429d8d58aff4bb7@DB4PR30MB030.064d.mgd.msft.net>
References: <F797D004-69E1-4A1A-8451-B820260A01CA@cis.upenn.edu>
 <4493c96e12574c37a429d8d58aff4bb7@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <987FC0B7-4395-4906-BA90-875D993131FD@cis.upenn.edu>


On Apr 11, 2016, at 6:39 PM, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> It's _nothing_ to do with whether the kind changes!
> 
> It's everything to do with cloning the binder if it is already in scope.  See "Secrets of the GHC inliner", the section called "The rapier", I think.

Ah yes. Silly me.

Thanks,
Richard

From johannes.waldmann at htwk-leipzig.de  Tue Apr 12 13:13:11 2016
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Tue, 12 Apr 2016 15:13:11 +0200
Subject: timings for individual compiler passes (in rc3)
Message-ID: <570CF467.4060001@htwk-leipzig.de>

Hi.

There is this (closed) https://ghc.haskell.org/trac/ghc/ticket/11653
and it's landed in 8.rc3.

Thats good, and I want to make an effort to use this.
But how? Just "-v2"? This gives a lot of noise. And no summary?

Automatic analysis (of the output text stream, by external program)
could be somewhat easier if each data set (starting at "\n!!!")
did occupy exactly one line (currently, line breaks do occur).

Anyway, what do I look for? Any large or suspicious number -
but what exactly is "suspicious"? Anything above 1 second?

Are we to believe the assignment of cost to pass,
or could there be mis-attribution because
result of an earlier pass is only forced later?

Oh, and where do you want discussion of this feature
(mailing list, ticket, ...)? I do hope that it will prove useful,
in the sense that it could allow non-developers like me,
or even build bots, to help spot performance problems.
(E.g., you could advertise to enable this on travis.
Yes, their build times depend on a lot of things, but still.)

- J.W.

From facundo.dominguez at tweag.io  Tue Apr 12 21:35:32 2016
From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=)
Date: Tue, 12 Apr 2016 18:35:32 -0300
Subject: Reification of out-of-scope variables?
In-Reply-To: <266BEB36-AA3D-4049-84F7-138C6FF7539A@cis.upenn.edu>
References: <CAJ0eudrYKW=+s25+G9x_3AQNJTU2Uqj18uZfbzZedF2p8oq=LQ@mail.gmail.com>
 <266BEB36-AA3D-4049-84F7-138C6FF7539A@cis.upenn.edu>
Message-ID: <CA+Q==SDrdJBAKWt4ULwgYpPu0vHwz-WqSK4U1upTaA2DTtGPAQ@mail.gmail.com>

Hello Richard,

>  TH will offer a new function `addGroupFinalizer :: Q () -> Q ()` that runs its argument in the local typing environment available when addGroupFinalizer is called.

When considering this approach, how could one capture the local typing
environment given that the untyped splices are run in the renamer
where no such environment is populated yet?

Facundo


On Sun, Apr 10, 2016 at 11:22 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> I actually don't think this would be all that hard to do.
>
> Concretely, how would this work:
>
> TH will offer a new function `addGroupFinalizer :: Q () -> Q ()` that runs its argument in the local typing environment available when addGroupFinalizer is called. However, by the time the passed action is run -- after finishing typechecking a mutually-recursive group -- all the local variables' types have settled and are available.
>
> Does that satisfy your needs? Of course, your quasiquoter will still have to output code when it is originally run, so the addGroupFinalizer action could only, say, set up the external file.
>
> If this idea is acceptable, it will still need a volunteer to implement. I'm happy to advise.
>
> Richard
>
> On Apr 8, 2016, at 9:48 AM, "Boespflug, Mathieu" <m at tweag.io> wrote:
>
>> Hi all,
>>
>> the community is increasingly using quasiquotation as a means to
>> interoperate with foreign languages. E.g. language-c-inline, inline-c
>> and inline-r allow calling foreign functions using foreign language
>> syntax, rather than "foreign import" declarations. There are efforts
>> underway for Java, Javascript and other languages too. The pattern
>> common to most of these libraries is:
>>
>> * collect the content of all quasiquotes that appear in a module,
>> generate a compilable foreign source file based on that, and then link
>> the object code resulting from compiling that.
>>
>> When the foreign language is itself statically typed, we need to make
>> sure we generate code with proper type annotations, including for any
>> antiquotation variables. In older versions of GHC, we could derive the
>> type annotations from the inferred Haskell types, but this is not
>> possible since 7.8 because the types of any variable in the current
>> "declaration group" are not made available. So libraries like inline-c
>> ask for some extra verbosity from the user:
>>
>> mycossin1 :: Double -> IO Double
>> mycossin1 somex = [cexp| double { cos($(double somex)) * sin($(double
>> somex)) } |]
>>
>> The type annotations inside the quasiquote are redundant with the
>> explicitly provided type signature. C types are typically short
>> enough, but other languages (e.g. C++, Java), have really long fully
>> qualified type names, so the extra annotations are a cost.
>>
>> The are good reasons why types aren't available from within a
>> declaration group (it was possible to observe the order in which type
>> inference works), hence why the extra annotations are necessary. But
>> by the time type checking of the whole module is finished, types are
>> fixed once and for all. So the question is:
>>
>> * Could we make it possible to query the types of local variables at
>> the end of type checking?
>>
>> The reason I ask is: with 'addModFinalizer' and friends that TH
>> provides, we're tantalizingly close to being able to generate foreign
>> code wrappers that have the right types that match those of the
>> antiquotation variables present in a module.
>>
>> Template Haskell already provides 'addModFinalizer'. You feed it a Q
>> action, which will run once the whole module is type checked. If at
>> that point we could ask, "what's the type of somex (above)?", then we
>> could let the user write
>>
>> mycossin2 :: Double -> IO Double
>> mycossin2 somex = [cexp| cos($somex) * sin($somex) |]
>>
>> and yet still generate a C file capturing the content of above
>> quasiquote with the right types:
>>
>> double module_foo_qq1(double v1)
>> {
>>    return (cos(v1) * sin(v1));
>> }
>>
>> since we know that somex :: Double and that the Haskell type "Double"
>> corresponds to C's "double" primitive type.
>>
>> Bound variables have a unique name associated to them, which we can
>> get hold of in Template Haskell using the 'var syntax, but
>>
>> f x = $(let name = 'x in addModFinalizer (reify name >>= \info ->
>> runIO (print info)) >> [| x |])
>>
>> results in a compiler error,
>>
>>    The exact Name `x' is not in scope
>>      Probable cause: you used a unique Template Haskell name (NameU),
>>      perhaps via newName, but did not bind it
>>      If that's it, then -ddump-splices might be useful
>>
>> because by the time the TH finalizer runs, we're no longer in the scope of x.
>>
>> But since the names of the local variables are unique, could it
>> possibly make sense to allow calling reify on them, even outside of
>> their scope, so as to get at their type?
>>
>> Best,
>>
>> Mathieu
>> _______________________________________________
>> 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 ryan.gl.scott at gmail.com  Tue Apr 12 23:47:13 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Tue, 12 Apr 2016 19:47:13 -0400
Subject: How does topological sorting of kind variables really work?
Message-ID: <CADdQpRAK8BhaSF7huO8=H9vNBeKuFGeGw6yksXA5ahSQ0OJtDQ@mail.gmail.com>

I'm doing some work in GHC that requires explicitly applying kinds to
the kind variables of a data type. I noticed that the order in which
the implicit kind variables are sorted is not as predictable as I
originally thought. To illustrate what I mean, here is a GHCi session
I had recently (with GHC HEAD):

    $ /opt/ghc/head/bin/ghci -XTypeInType
    GHCi, version 8.1.20160412: http://www.haskell.org/ghc/  :? for help
    Loaded GHCi configuration from /home/ryanglscott/.ghci
    > data T (a :: j -> k -> l) (b :: (x, y, z)) = MkT
    > :t MkT
    MkT
      :: forall x y z l k j (a :: j -> k -> l) (b :: (x, y, z)). T a b

Much to my surprise, the order of the kind variables wasn't [j, k, l,
x, y, z], but rather [x, y, z, l, k, j]! I know that type variables
are sorted with a stable topological sort [1], but there must be some
other subtlety that I'm missing. How does GHC come up with the order
[x, y, z, l, k, j]?

Ryan S.
-----
[1] http://git.haskell.org/ghc.git/blob/d81cdc227cd487659995ddea577214314c9b4b97:/docs/users_guide/glasgow_exts.rst#l8708

From eir at cis.upenn.edu  Wed Apr 13 02:25:51 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 12 Apr 2016 22:25:51 -0400
Subject: Reification of out-of-scope variables?
In-Reply-To: <CA+Q==SDrdJBAKWt4ULwgYpPu0vHwz-WqSK4U1upTaA2DTtGPAQ@mail.gmail.com>
References: <CAJ0eudrYKW=+s25+G9x_3AQNJTU2Uqj18uZfbzZedF2p8oq=LQ@mail.gmail.com>
 <266BEB36-AA3D-4049-84F7-138C6FF7539A@cis.upenn.edu>
 <CA+Q==SDrdJBAKWt4ULwgYpPu0vHwz-WqSK4U1upTaA2DTtGPAQ@mail.gmail.com>
Message-ID: <1DA2B8DB-1830-44A4-9564-F3B508771909@cis.upenn.edu>

On Apr 12, 2016, at 5:35 PM, Facundo Dom?nguez <facundo.dominguez at tweag.io> wrote:

> Hello Richard,
> 
>> TH will offer a new function `addGroupFinalizer :: Q () -> Q ()` that runs its argument in the local typing environment available when addGroupFinalizer is called.
> 
> When considering this approach, how could one capture the local typing
> environment given that the untyped splices are run in the renamer
> where no such environment is populated yet?
> 

Ah. Excellent point. I hadn't quite thought it through. Not sure, off the top of my head, how to get around this.

Richard


From eir at cis.upenn.edu  Wed Apr 13 02:30:46 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 12 Apr 2016 22:30:46 -0400
Subject: How does topological sorting of kind variables really work?
In-Reply-To: <CADdQpRAK8BhaSF7huO8=H9vNBeKuFGeGw6yksXA5ahSQ0OJtDQ@mail.gmail.com>
References: <CADdQpRAK8BhaSF7huO8=H9vNBeKuFGeGw6yksXA5ahSQ0OJtDQ@mail.gmail.com>
Message-ID: <EB841B13-9469-4938-8437-F427A4A152FD@cis.upenn.edu>

I don't think this has to do with topological sorting so much as inferring the order of undeclared (but written) kind variables. You could, with -XTypeInType, always make the order explicit:

> data T :: forall j k l x y z. (j -> k -> l) -> (x, y, z) -> * where MkT :: T a b

The order of these variables is derived from the extractHsTyRdrTyVars function and friends in RnTypes. I'm sure you could look closely at those functions and see where the behavior is coming from. It's very likely an improvement can be found here.

Richard

On Apr 12, 2016, at 7:47 PM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:

> I'm doing some work in GHC that requires explicitly applying kinds to
> the kind variables of a data type. I noticed that the order in which
> the implicit kind variables are sorted is not as predictable as I
> originally thought. To illustrate what I mean, here is a GHCi session
> I had recently (with GHC HEAD):
> 
>    $ /opt/ghc/head/bin/ghci -XTypeInType
>    GHCi, version 8.1.20160412: http://www.haskell.org/ghc/  :? for help
>    Loaded GHCi configuration from /home/ryanglscott/.ghci
>> data T (a :: j -> k -> l) (b :: (x, y, z)) = MkT
>> :t MkT
>    MkT
>      :: forall x y z l k j (a :: j -> k -> l) (b :: (x, y, z)). T a b
> 
> Much to my surprise, the order of the kind variables wasn't [j, k, l,
> x, y, z], but rather [x, y, z, l, k, j]! I know that type variables
> are sorted with a stable topological sort [1], but there must be some
> other subtlety that I'm missing. How does GHC come up with the order
> [x, y, z, l, k, j]?
> 
> Ryan S.
> -----
> [1] http://git.haskell.org/ghc.git/blob/d81cdc227cd487659995ddea577214314c9b4b97:/docs/users_guide/glasgow_exts.rst#l8708
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From ryan.gl.scott at gmail.com  Wed Apr 13 02:44:29 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Tue, 12 Apr 2016 22:44:29 -0400
Subject: How does topological sorting of kind variables really work?
In-Reply-To: <EB841B13-9469-4938-8437-F427A4A152FD@cis.upenn.edu>
References: <CADdQpRAK8BhaSF7huO8=H9vNBeKuFGeGw6yksXA5ahSQ0OJtDQ@mail.gmail.com>
 <EB841B13-9469-4938-8437-F427A4A152FD@cis.upenn.edu>
Message-ID: <CADdQpRCWCnDQp4RGn0U2U-NeMf4qmiSbRFnWcxFsz1tX5ksDUw@mail.gmail.com>

Aha! For some reason, it never clicked that you could use forall
within a datatype's kind signature like that. That technique would, at
the very least, allow me to guarantee the order in which the kind
variables appear. Thanks!

It's a bit of a shame that type inference doesn't give you a reliable
order, but I suppose if you rely on -XTypeApplications working a
certain way, you're taking a risk by NOT using a forall.

Ryan S.

On Tue, Apr 12, 2016 at 10:30 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> I don't think this has to do with topological sorting so much as inferring the order of undeclared (but written) kind variables. You could, with -XTypeInType, always make the order explicit:
>
>> data T :: forall j k l x y z. (j -> k -> l) -> (x, y, z) -> * where MkT :: T a b
>
> The order of these variables is derived from the extractHsTyRdrTyVars function and friends in RnTypes. I'm sure you could look closely at those functions and see where the behavior is coming from. It's very likely an improvement can be found here.
>
> Richard
>
> On Apr 12, 2016, at 7:47 PM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
>
>> I'm doing some work in GHC that requires explicitly applying kinds to
>> the kind variables of a data type. I noticed that the order in which
>> the implicit kind variables are sorted is not as predictable as I
>> originally thought. To illustrate what I mean, here is a GHCi session
>> I had recently (with GHC HEAD):
>>
>>    $ /opt/ghc/head/bin/ghci -XTypeInType
>>    GHCi, version 8.1.20160412: http://www.haskell.org/ghc/  :? for help
>>    Loaded GHCi configuration from /home/ryanglscott/.ghci
>>> data T (a :: j -> k -> l) (b :: (x, y, z)) = MkT
>>> :t MkT
>>    MkT
>>      :: forall x y z l k j (a :: j -> k -> l) (b :: (x, y, z)). T a b
>>
>> Much to my surprise, the order of the kind variables wasn't [j, k, l,
>> x, y, z], but rather [x, y, z, l, k, j]! I know that type variables
>> are sorted with a stable topological sort [1], but there must be some
>> other subtlety that I'm missing. How does GHC come up with the order
>> [x, y, z, l, k, j]?
>>
>> Ryan S.
>> -----
>> [1] http://git.haskell.org/ghc.git/blob/d81cdc227cd487659995ddea577214314c9b4b97:/docs/users_guide/glasgow_exts.rst#l8708
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From eir at cis.upenn.edu  Wed Apr 13 02:45:42 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 12 Apr 2016 22:45:42 -0400
Subject: How does topological sorting of kind variables really work?
In-Reply-To: <CADdQpRCWCnDQp4RGn0U2U-NeMf4qmiSbRFnWcxFsz1tX5ksDUw@mail.gmail.com>
References: <CADdQpRAK8BhaSF7huO8=H9vNBeKuFGeGw6yksXA5ahSQ0OJtDQ@mail.gmail.com>
 <EB841B13-9469-4938-8437-F427A4A152FD@cis.upenn.edu>
 <CADdQpRCWCnDQp4RGn0U2U-NeMf4qmiSbRFnWcxFsz1tX5ksDUw@mail.gmail.com>
Message-ID: <F3CB1771-9C0C-48B5-AFA8-330C2C10C675@cis.upenn.edu>


On Apr 12, 2016, at 10:44 PM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
> 
> It's a bit of a shame that type inference doesn't give you a reliable
> order, but I suppose if you rely on -XTypeApplications working a
> certain way, you're taking a risk by NOT using a forall.

Inference is meant to give you a reliable ordering. If it's not, that's a bug!

From ryan.gl.scott at gmail.com  Wed Apr 13 02:55:39 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Tue, 12 Apr 2016 22:55:39 -0400
Subject: How does topological sorting of kind variables really work?
In-Reply-To: <F3CB1771-9C0C-48B5-AFA8-330C2C10C675@cis.upenn.edu>
References: <CADdQpRAK8BhaSF7huO8=H9vNBeKuFGeGw6yksXA5ahSQ0OJtDQ@mail.gmail.com>
 <EB841B13-9469-4938-8437-F427A4A152FD@cis.upenn.edu>
 <CADdQpRCWCnDQp4RGn0U2U-NeMf4qmiSbRFnWcxFsz1tX5ksDUw@mail.gmail.com>
 <F3CB1771-9C0C-48B5-AFA8-330C2C10C675@cis.upenn.edu>
Message-ID: <CADdQpRABemHYiUp=XLkkTTJxFHayE3xDCZQrhuLBbQ3fMGuxxw@mail.gmail.com>

Well, I'd be hesitant to call it "reliable":

    $ /opt/ghc/8.0.1/bin/ghci -XRankNTypes -XTypeInType
-fprint-explicit-foralls -fprint-explicit-kinds
    GHCi, version 8.0.0.20160411: http://www.haskell.org/ghc/  :? for help
    Loaded GHCi configuration from /home/ryanglscott/.ghci
    > import Data.Proxy
    > let wat :: forall (a :: j -> k -> l) (b :: (x, y, z)). Proxy a
-> Proxy b; wat = undefined
    > :t wat
    wat
      :: forall {j} {k} {l} {x} {y} {z} {a :: j -> k -> l} {b :: (x, y,
                                                                  z)}.
         Proxy (j -> k -> l) a -> Proxy (x, y, z) b
    > data Wat (a :: j -> k -> l) (b :: (x, y, z)) = Wat (Proxy a) (Proxy b)
    > :t Wat
    Wat
      :: forall {x} {y} {z} {l} {k} {j} {a :: j -> k -> l} {b :: (x, y,
                                                                  z)}.
         Proxy (j -> k -> l) a -> Proxy (x, y, z) b -> Wat x y z l k j a b

In the example above, a plain old function gives me the ordering I'd
expect, but a data constructor does not. Now, maybe there's something
tricky involving data that makes this different - I'm not qualified
enough to say for sure. But it has made me a lot more paranoid about
checking the order of the variables with :t before I use
-XTypeApplications, since you never know what you're going to get
sometimes.

Ryan S.

On Tue, Apr 12, 2016 at 10:45 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>
> On Apr 12, 2016, at 10:44 PM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
>>
>> It's a bit of a shame that type inference doesn't give you a reliable
>> order, but I suppose if you rely on -XTypeApplications working a
>> certain way, you're taking a risk by NOT using a forall.
>
> Inference is meant to give you a reliable ordering. If it's not, that's a bug!

From m at tweag.io  Wed Apr 13 09:09:11 2016
From: m at tweag.io (Boespflug, Mathieu)
Date: Wed, 13 Apr 2016 11:09:11 +0200
Subject: Reification of out-of-scope variables?
In-Reply-To: <1DA2B8DB-1830-44A4-9564-F3B508771909@cis.upenn.edu>
References: <CAJ0eudrYKW=+s25+G9x_3AQNJTU2Uqj18uZfbzZedF2p8oq=LQ@mail.gmail.com>
 <266BEB36-AA3D-4049-84F7-138C6FF7539A@cis.upenn.edu>
 <CA+Q==SDrdJBAKWt4ULwgYpPu0vHwz-WqSK4U1upTaA2DTtGPAQ@mail.gmail.com>
 <1DA2B8DB-1830-44A4-9564-F3B508771909@cis.upenn.edu>
Message-ID: <CAJ0eudoNEa-dpSNwT1fhPxdQr6CpYvsuexVJNoxowoDu6KBahA@mail.gmail.com>

Hi Richard,

Facundo and I had a chat about this offline. Facundo noticed that
there /is/ a form of splicing that runs during type checking, and
therefore has access to the type environment: namely typed splices,
which return a TExp rather than an Exp. Turns out the example from my
first email does work if you adapt it to use typed splices:

f :: Int -> Int
f x = $$(do let {name = mkName x}; info <- reify name; runIO (print
info) [|| x ||])

Running reify still doesn't work inside addModFinalizer, but at least
we do have access to x's type from within the typed splice, so we can
record it for use in the foreign code generation phase later.

The issue is, typed splices run afoul of the very same issue that
caused GHC HQ to move splice expansion out of the type checker and
into the renamer: namely that type inference becomes observable, as
documented here:

https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/BlogPostChanges

In particular,

f x = $$(... same splice as above...) `asTypeOf` True

yields a type error, while

f :: Bool -> Bool
f x = $$(... same splice as above...)

does not.

So let's discuss what the next actions are:

* Should we consider it a bug (and file a ticket) that reification in
typed splices is able to observe the order of type checking, just like
reify used to do in untyped splices?
* While Richard's proposed addGroupFinalizer might not work with
untyped splices, perhaps it can be made to work with typed splices,
since these run in the type checker?
* If part of the solution here is to use typed splices, how do we get
quasiquotation to be syntactic sugar for a *typed* splice? Do we want
to be introducing a typed quasiquotation syntax, just like Geoff did
for much of the rest of Template Haskell?

Facundo and I think that something like Richard's addGroupFinalizer is
still interesting to have, because while reification during type
checking sounds dubious, reification /after/ the declaration group is
fully type checked is perfectly safe.

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


On 13 April 2016 at 04:25, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> On Apr 12, 2016, at 5:35 PM, Facundo Dom?nguez <facundo.dominguez at tweag.io> wrote:
>
>> Hello Richard,
>>
>>> TH will offer a new function `addGroupFinalizer :: Q () -> Q ()` that runs its argument in the local typing environment available when addGroupFinalizer is called.
>>
>> When considering this approach, how could one capture the local typing
>> environment given that the untyped splices are run in the renamer
>> where no such environment is populated yet?
>>
>
> Ah. Excellent point. I hadn't quite thought it through. Not sure, off the top of my head, how to get around this.
>
> Richard
>

From simonpj at microsoft.com  Wed Apr 13 09:17:03 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 13 Apr 2016 09:17:03 +0000
Subject: How does topological sorting of kind variables really work?
In-Reply-To: <F3CB1771-9C0C-48B5-AFA8-330C2C10C675@cis.upenn.edu>
References: <CADdQpRAK8BhaSF7huO8=H9vNBeKuFGeGw6yksXA5ahSQ0OJtDQ@mail.gmail.com>
 <EB841B13-9469-4938-8437-F427A4A152FD@cis.upenn.edu>
 <CADdQpRCWCnDQp4RGn0U2U-NeMf4qmiSbRFnWcxFsz1tX5ksDUw@mail.gmail.com>
 <F3CB1771-9C0C-48B5-AFA8-330C2C10C675@cis.upenn.edu>
Message-ID: <89ee309d27dc4da793390d399073cda6@DB4PR30MB030.064d.mgd.msft.net>


| > It's a bit of a shame that type inference doesn't give you a reliable
| > order, but I suppose if you rely on -XTypeApplications working a
| > certain way, you're taking a risk by NOT using a forall.
| 
| Inference is meant to give you a reliable ordering. If it's not, that's a
| bug!


I thought that inferred foralls are Invisible binders (see Note [TyBinders and VisibilityFlags]); and you can't use visible type application for Invisible binders.  

I thought that was because it's hard to specify the order of inferred type variable, just as Ryan says.

So /is/ inference meant to give a reliable ordering?  If so why?  

Also I don't understand why Ryan needs a reliable ordering.

So you can see I'm a bit confused here

Simon

From george.colpitts at gmail.com  Wed Apr 13 11:07:31 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Wed, 13 Apr 2016 11:07:31 +0000
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <87egadbj2w.fsf@smart-cactus.org>
References: <87egadbj2w.fsf@smart-cactus.org>
Message-ID: <CAB-d4A7a-eydMU2tnZ84xBGLe895ukK1htUAa2jeOOPsUbwLFQ@mail.gmail.com>

My understanding is that the required version of llvm is 3.7. Is it safe to
assume that 3.7.1 is also okay?

On Sun, Apr 10, 2016 at 12:05 PM Ben Gamari <ben at well-typed.com> wrote:

> tl;dr: If you would like to produce a binary distribution for GHC
>        8.0.1-rc3 then let us know, grab the source distribution and
>        start building. The binary distributions will be all released one
>        week from today.
>
>
> Hello GHC packagers,
>
> Austin and I are happy to announce the release of the 8.0.1-rc3 source
> distribution to binary packagers. You will find the tarball and usual
> assortment of signatures at
>
>     http://downloads.haskell.org/~ghc/8.0.1-rc3/
>
> This release is the first where we are following our new release policy
> [1], where a one-week delay will be introduced between the release of
> the source and binary distributions. The goal of this policy is to give
> all platforms the opportunity for support from the first day of a
> release.
>
> If all of the expected binary releases are submitted before the
> week-long delay is through, we can move forward with the release ahead
> of schedule. Given how late release candidate 3 is, we'd naturally like
> to get the binary releases out as soon is possible: The sooner we can
> get this -rc out the door the sooner we can get to the final release.
> Moreover, it would be appreciated if you could confirm that you intend
> to offer a binary distribution this release.
>
> Otherwise, let either Austin or I know if you have any trouble building
> your distribution. I have yet to push the 8.0.1-rc3 tag in case we
> encounter unexpected issues but all of my builds with this tarball
> thusfar have gone quite well.
>
> Good luck and thanks for all of your work!
>
> Cheers,
>
> - Ben
>
>
> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.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/20160413/534ac2c6/attachment-0001.html>

From ben at well-typed.com  Wed Apr 13 11:20:35 2016
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 13 Apr 2016 13:20:35 +0200
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <CAB-d4A7a-eydMU2tnZ84xBGLe895ukK1htUAa2jeOOPsUbwLFQ@mail.gmail.com>
References: <87egadbj2w.fsf@smart-cactus.org>
 <CAB-d4A7a-eydMU2tnZ84xBGLe895ukK1htUAa2jeOOPsUbwLFQ@mail.gmail.com>
Message-ID: <877fg1g3gc.fsf@smart-cactus.org>

George Colpitts <george.colpitts at gmail.com> writes:

> My understanding is that the required version of llvm is 3.7. Is it safe to
> assume that 3.7.1 is also okay?
>
Yep, in principle anything from the 3.7 series should work.

Now that you mention it, we should probably do a better job of
advertising which LLVM versions are supported.

Cheers,

- Ben

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

From facundo.dominguez at tweag.io  Wed Apr 13 11:31:41 2016
From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=)
Date: Wed, 13 Apr 2016 08:31:41 -0300
Subject: Reification of out-of-scope variables?
In-Reply-To: <CAJ0eudoNEa-dpSNwT1fhPxdQr6CpYvsuexVJNoxowoDu6KBahA@mail.gmail.com>
References: <CAJ0eudrYKW=+s25+G9x_3AQNJTU2Uqj18uZfbzZedF2p8oq=LQ@mail.gmail.com>
 <266BEB36-AA3D-4049-84F7-138C6FF7539A@cis.upenn.edu>
 <CA+Q==SDrdJBAKWt4ULwgYpPu0vHwz-WqSK4U1upTaA2DTtGPAQ@mail.gmail.com>
 <1DA2B8DB-1830-44A4-9564-F3B508771909@cis.upenn.edu>
 <CAJ0eudoNEa-dpSNwT1fhPxdQr6CpYvsuexVJNoxowoDu6KBahA@mail.gmail.com>
Message-ID: <CA+Q==SA_LGtUBKHv9WhePWrWgebeTd7O7v7A4_5fypgd8GFuVA@mail.gmail.com>

An implementation for untyped splices could be:
* Have a map from internal names to the local typing environments.
* When the renamer runs addGroupFinalizer it generates an internal
name and annotates the AST with the internal name at the location of
the splice.
* When the type checker finds the annotation it inserts the local
typing environment in the map.
* When the finalizer runs, it looks up its local typing environment in the map.

It is not as simple as running the splice in the typechecker, but
would you still be happy merging a solution like this?

Facundo


On Wed, Apr 13, 2016 at 6:09 AM, Boespflug, Mathieu <m at tweag.io> wrote:
> Hi Richard,
>
> Facundo and I had a chat about this offline. Facundo noticed that
> there /is/ a form of splicing that runs during type checking, and
> therefore has access to the type environment: namely typed splices,
> which return a TExp rather than an Exp. Turns out the example from my
> first email does work if you adapt it to use typed splices:
>
> f :: Int -> Int
> f x = $$(do let {name = mkName x}; info <- reify name; runIO (print
> info) [|| x ||])
>
> Running reify still doesn't work inside addModFinalizer, but at least
> we do have access to x's type from within the typed splice, so we can
> record it for use in the foreign code generation phase later.
>
> The issue is, typed splices run afoul of the very same issue that
> caused GHC HQ to move splice expansion out of the type checker and
> into the renamer: namely that type inference becomes observable, as
> documented here:
>
> https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/BlogPostChanges
>
> In particular,
>
> f x = $$(... same splice as above...) `asTypeOf` True
>
> yields a type error, while
>
> f :: Bool -> Bool
> f x = $$(... same splice as above...)
>
> does not.
>
> So let's discuss what the next actions are:
>
> * Should we consider it a bug (and file a ticket) that reification in
> typed splices is able to observe the order of type checking, just like
> reify used to do in untyped splices?
> * While Richard's proposed addGroupFinalizer might not work with
> untyped splices, perhaps it can be made to work with typed splices,
> since these run in the type checker?
> * If part of the solution here is to use typed splices, how do we get
> quasiquotation to be syntactic sugar for a *typed* splice? Do we want
> to be introducing a typed quasiquotation syntax, just like Geoff did
> for much of the rest of Template Haskell?
>
> Facundo and I think that something like Richard's addGroupFinalizer is
> still interesting to have, because while reification during type
> checking sounds dubious, reification /after/ the declaration group is
> fully type checked is perfectly safe.
>
> Best,
> --
> Mathieu Boespflug
> Founder at http://tweag.io.
>
>
> On 13 April 2016 at 04:25, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>> On Apr 12, 2016, at 5:35 PM, Facundo Dom?nguez <facundo.dominguez at tweag.io> wrote:
>>
>>> Hello Richard,
>>>
>>>> TH will offer a new function `addGroupFinalizer :: Q () -> Q ()` that runs its argument in the local typing environment available when addGroupFinalizer is called.
>>>
>>> When considering this approach, how could one capture the local typing
>>> environment given that the untyped splices are run in the renamer
>>> where no such environment is populated yet?
>>>
>>
>> Ah. Excellent point. I hadn't quite thought it through. Not sure, off the top of my head, how to get around this.
>>
>> Richard
>>

From mle+hs at mega-nerd.com  Wed Apr 13 11:40:57 2016
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Wed, 13 Apr 2016 21:40:57 +1000
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <CAB-d4A7a-eydMU2tnZ84xBGLe895ukK1htUAa2jeOOPsUbwLFQ@mail.gmail.com>
References: <87egadbj2w.fsf@smart-cactus.org>
 <CAB-d4A7a-eydMU2tnZ84xBGLe895ukK1htUAa2jeOOPsUbwLFQ@mail.gmail.com>
Message-ID: <20160413214057.d2e6fcd78ce186b7cd2a35aa@mega-nerd.com>

George Colpitts wrote:

> My understanding is that the required version of llvm is 3.7. Is it safe to
> assume that 3.7.1 is also okay?
> 
> On Sun, Apr 10, 2016 at 12:05 PM Ben Gamari <ben at well-typed.com> wrote:
> 
> > tl;dr: If you would like to produce a binary distribution for GHC
> >        8.0.1-rc3 then let us know, grab the source distribution and
> >        start building. The binary distributions will be all released one
> >        week from today.
> >
> >
> > Hello GHC packagers,
> >
> > Austin and I are happy to announce the release of the 8.0.1-rc3 source
> > distribution to binary packagers. You will find the tarball and usual
> > assortment of signatures at
> >
> >     http://downloads.haskell.org/~ghc/8.0.1-rc3/
> >
> > This release is the first where we are following our new release policy
> > [1], where a one-week delay will be introduced between the release of
> > the source and binary distributions. The goal of this policy is to give
> > all platforms the opportunity for support from the first day of a
> > release.
> >
> > If all of the expected binary releases are submitted before the
> > week-long delay is through, we can move forward with the release ahead
> > of schedule. Given how late release candidate 3 is, we'd naturally like
> > to get the binary releases out as soon is possible: The sooner we can
> > get this -rc out the door the sooner we can get to the final release.
> > Moreover, it would be appreciated if you could confirm that you intend
> > to offer a binary distribution this release.
> >
> > Otherwise, let either Austin or I know if you have any trouble building
> > your distribution. I have yet to push the 8.0.1-rc3 tag in case we
> > encounter unexpected issues but all of my builds with this tarball
> > thusfar have gone quite well.
> >
> > Good luck and thanks for all of your work!
> >
> > Cheers,
> >
> > - Ben
> >
> >
> > [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >


-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From simonpj at microsoft.com  Wed Apr 13 12:55:35 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 13 Apr 2016 12:55:35 +0000
Subject: [GHC] #11824: GHC error in desugarer lookup
In-Reply-To: <061.6a21d313942a94900735c0c8a7674929@haskell.org>
References: <046.bef37bafb0de36b55d56e17189a8ba9e@haskell.org>
 <061.6a21d313942a94900735c0c8a7674929@haskell.org>
Message-ID: <9732b66656ae46bbb57ac6142c505972@DB4PR30MB030.064d.mgd.msft.net>

Ben

I'm offline, so can't reply on Phab.

Calling mkTypeableBinds in tcRnHsBootDecls isn't quite right, because it'll generate lots of *bindings* whereas all we want is the *Ids* in the GlobalValEnv.

(It's possible that tcg_binds is ignored in the boot-module case, but it's unsavoury to generate the bindings at all.  They are generated when we process the main module.)

I suggest the easiest fix is, in mkModIdBinding and mkTypeableTyConBinds, guard the binding-generation with a test for whether isHsBootOrSig is true.

Simon

| -----Original Message-----
| From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf Of GHC
| Sent: 13 April 2016 12:06
| Cc: ghc-tickets at haskell.org
| Subject: Re: [GHC] #11824: GHC error in desugarer lookup
| 
| #11824: GHC error in desugarer lookup
| -------------------------------------+-------------------------------------
|         Reporter:  darchon           |                Owner:
|             Type:  bug               |               Status:  patch
|         Priority:  normal            |            Milestone:  8.0.1
|        Component:  Compiler          |              Version:  8.0.1-rc3
|       Resolution:                    |             Keywords:
| Operating System:  Unknown/Multiple  |         Architecture:
|  Type of failure:  Compile-time      |  Unknown/Multiple
|   crash                              |            Test Case:
|       Blocked By:                    |             Blocking:
|  Related Tickets:                    |  Differential Rev(s):  Phab:D2107,
|        Wiki Page:                    |  Phab:D2108
| -------------------------------------+-------------------------------------
| Changes (by bgamari):
| 
|  * status:  new => patch
|  * differential:   => Phab:D2107, Phab:D2108
| 
| 
| --
| Ticket URL:
| <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.haskell.
| org%2ftrac%2fghc%2fticket%2f11824%23comment%3a6&data=01%7c01%7csimonpj%40064d
| .mgd.microsoft.com%7cd4862d0ed83c493164fb08d3638c0642%7c72f988bf86f141af91ab2
| d7cd011db47%7c1&sdata=JaXInqbrHs1nrAM9JsMUfX6J6hfbzJHI2k5KKRbH9i0%3d>
| GHC
| <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.haskell.
| org%2fghc%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd4862d0ed83c49
| 3164fb08d3638c0642%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=S85zedvr8ceEm
| 4UeWtejgMl%2buRm4XMrgdWiHwcXDVuU%3d>
| The Glasgow Haskell Compiler
| _______________________________________________
| ghc-tickets mailing list
| ghc-tickets at haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
| org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| tickets&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cd4862d0ed83c493164f
| b08d3638c0642%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=WywP4RhTbL5cEfl%2b
| xztoUe1EYuHPthiCb3vS2%2b%2fP4F8%3d

From ben at well-typed.com  Wed Apr 13 13:53:01 2016
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 13 Apr 2016 15:53:01 +0200
Subject: [GHC] #11824: GHC error in desugarer lookup
In-Reply-To: <9732b66656ae46bbb57ac6142c505972@DB4PR30MB030.064d.mgd.msft.net>
References: <046.bef37bafb0de36b55d56e17189a8ba9e@haskell.org>
 <061.6a21d313942a94900735c0c8a7674929@haskell.org>
 <9732b66656ae46bbb57ac6142c505972@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <8737qpfwea.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> Ben
>
> I'm offline, so can't reply on Phab.
>
> Calling mkTypeableBinds in tcRnHsBootDecls isn't quite right, because it'll generate lots of *bindings* whereas all we want is the *Ids* in the GlobalValEnv.
>
> (It's possible that tcg_binds is ignored in the boot-module case, but it's unsavoury to generate the bindings at all.  They are generated when we process the main module.)
>
> I suggest the easiest fix is, in mkModIdBinding and mkTypeableTyConBinds, guard the binding-generation with a test for whether isHsBootOrSig is true.
>
Are you concerned about the bindings being generated at all or merely
that they are being added to the typechecking environment?

If the latter there is no reason to fear: TcBinds.addTypecheckedBinds
(which TcTypeable uses) ensures that no bindings are added to the
environment if we are compiling a boot module,

    addTypecheckedBinds :: TcGblEnv -> [LHsBinds Id] -> TcGblEnv
    addTypecheckedBinds tcg_env binds
      | isHsBootOrSig (tcg_src tcg_env) = tcg_env
        -- Do not add the code for record-selector bindings
        -- when compiling hs-boot files
      | otherwise = tcg_env { tcg_binds = foldr unionBags
                                                (tcg_binds tcg_env)
                                                binds }

Of course, we are still doing the work of producing the bindings; if it
is this that you are concerned about then I can be more careful in
guarding their production.

Cheers,

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

From ryan.gl.scott at gmail.com  Wed Apr 13 14:12:15 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Wed, 13 Apr 2016 10:12:15 -0400
Subject: How does topological sorting of kind variables really work?
In-Reply-To: <89ee309d27dc4da793390d399073cda6@DB4PR30MB030.064d.mgd.msft.net>
References: <CADdQpRAK8BhaSF7huO8=H9vNBeKuFGeGw6yksXA5ahSQ0OJtDQ@mail.gmail.com>
 <EB841B13-9469-4938-8437-F427A4A152FD@cis.upenn.edu>
 <CADdQpRCWCnDQp4RGn0U2U-NeMf4qmiSbRFnWcxFsz1tX5ksDUw@mail.gmail.com>
 <F3CB1771-9C0C-48B5-AFA8-330C2C10C675@cis.upenn.edu>
 <89ee309d27dc4da793390d399073cda6@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CADdQpRDePQxVU3OzA-JgWYDWhiyeR-g=on3gq4Ws23-89kc-tw@mail.gmail.com>

> I thought that inferred foralls are Invisible binders (see Note [TyBinders and VisibilityFlags]); and you can't use visible type application for Invisible binders.

In this particular case, j, k, l, x, y, and z aren't invisible
binders, but rather specified ones. And you certainly can use visible
type application on specified binders; this is important for my use
case.

> Also I don't understand why Ryan needs a reliable ordering.

I guess I should elaborate on what exactly my use case is. I'm trying
to fix Trac #10604 (i.e., make Generic1 poly-kinded). As part of this
effort, I need to generalize the (:.:) type [2] from GHC.Generics like
so:

    newtype (:.:) (f :: k2 -> *) (g :: k1 -> k2) (p :: k1) = Comp1 (f (g a))

I also need to change a part of TcGenGenerics where I apply the (:.:)
type constructor to some other types [3]. Previously, (:.:) was
monokinded, so I only needed to apply (:.:) to some type arguments.
But now that (:.:) is poly-kinded, I need to also apply it to two kind
arguments!

Now for the interesting part: in which order do you give the kind
arguments for (:.:)? I originally thought the order in which you'd do
it would be [k2,k1] (since that's the order they appear in the
definition from left to right), but in reality, it's actually [k1,k2]
due to the reasons mentioned earlier in this thread. This is quite
bewildering, especially since in GHC 7.10.3, it was the former order,
but in GHC 8.0 it's the latter order. Who's to say that the order
won't change again in a later GHC, and then deriving Generic1 will
silently break as a result?

So at this point, I see my options as follows:

1. Change the definition of (:.:) to use the GADT syntax that Richard
proposed. This would give a stable ordering for the kind variables,
but I'm loathe to make such a drastic change to the surface syntax to
fix a silly problem like this.
2. Investigate a fix to the implicitly quantified ordering issue. I'm
not sure where the issue could lie, and just from looking at
extract_lty [4], it's not clear at all what causes the current
ordering.
3. Live with the issue, and just change the code in TcGenGenerics if
the kind variable ordering ever changes. This is a bummer, but looks
like the simplest option.

Ryan S.
-----
[1] https://ghc.haskell.org/trac/ghc/ticket/10604
[2] http://hackage.haskell.org/package/base-4.8.2.0/docs/GHC-Generics.html#t::.:
[3] http://git.haskell.org/ghc.git/blob/d81cdc227cd487659995ddea577214314c9b4b97:/compiler/typecheck/TcGenGenerics.hs#l526
[4] http://git.haskell.org/ghc.git/blob/d81cdc227cd487659995ddea577214314c9b4b97:/compiler/rename/RnTypes.hs#l1611

From niteria at gmail.com  Wed Apr 13 15:50:23 2016
From: niteria at gmail.com (Bartosz Nitka)
Date: Wed, 13 Apr 2016 16:50:23 +0100
Subject: How does topological sorting of kind variables really work?
In-Reply-To: <CADdQpRDePQxVU3OzA-JgWYDWhiyeR-g=on3gq4Ws23-89kc-tw@mail.gmail.com>
References: <CADdQpRAK8BhaSF7huO8=H9vNBeKuFGeGw6yksXA5ahSQ0OJtDQ@mail.gmail.com>
 <EB841B13-9469-4938-8437-F427A4A152FD@cis.upenn.edu>
 <CADdQpRCWCnDQp4RGn0U2U-NeMf4qmiSbRFnWcxFsz1tX5ksDUw@mail.gmail.com>
 <F3CB1771-9C0C-48B5-AFA8-330C2C10C675@cis.upenn.edu>
 <89ee309d27dc4da793390d399073cda6@DB4PR30MB030.064d.mgd.msft.net>
 <CADdQpRDePQxVU3OzA-JgWYDWhiyeR-g=on3gq4Ws23-89kc-tw@mail.gmail.com>
Message-ID: <CAOSxnRjr9QwyRB4K706yQQMVujJg6y9Va2_pULY=B8_nMpuwmw@mail.gmail.com>

I can't say for sure, but this could be related to #4012.

The order that things appear in lists often depends on the way that uniques
get allocated. I know for sure that inferred type signatures are
nondeterministic right now, see [1] for an attempt to fix it.

The easiest way to check if it affects you is to reverse the order of
allocated uniques by passing `-dunique-increment=-1` on the command line.

If you rely on orders lining up I'd also recommend testing with it. See
#11148, #11362, #11361 for examples where it failed with reversed uniques.

[1] https://phabricator.haskell.org/D1924

2016-04-13 15:12 GMT+01:00 Ryan Scott <ryan.gl.scott at gmail.com>:

> > I thought that inferred foralls are Invisible binders (see Note
> [TyBinders and VisibilityFlags]); and you can't use visible type
> application for Invisible binders.
>
> In this particular case, j, k, l, x, y, and z aren't invisible
> binders, but rather specified ones. And you certainly can use visible
> type application on specified binders; this is important for my use
> case.
>
> > Also I don't understand why Ryan needs a reliable ordering.
>
> I guess I should elaborate on what exactly my use case is. I'm trying
> to fix Trac #10604 (i.e., make Generic1 poly-kinded). As part of this
> effort, I need to generalize the (:.:) type [2] from GHC.Generics like
> so:
>
>     newtype (:.:) (f :: k2 -> *) (g :: k1 -> k2) (p :: k1) = Comp1 (f (g
> a))
>
> I also need to change a part of TcGenGenerics where I apply the (:.:)
> type constructor to some other types [3]. Previously, (:.:) was
> monokinded, so I only needed to apply (:.:) to some type arguments.
> But now that (:.:) is poly-kinded, I need to also apply it to two kind
> arguments!
>
> Now for the interesting part: in which order do you give the kind
> arguments for (:.:)? I originally thought the order in which you'd do
> it would be [k2,k1] (since that's the order they appear in the
> definition from left to right), but in reality, it's actually [k1,k2]
> due to the reasons mentioned earlier in this thread. This is quite
> bewildering, especially since in GHC 7.10.3, it was the former order,
> but in GHC 8.0 it's the latter order. Who's to say that the order
> won't change again in a later GHC, and then deriving Generic1 will
> silently break as a result?
>
> So at this point, I see my options as follows:
>
> 1. Change the definition of (:.:) to use the GADT syntax that Richard
> proposed. This would give a stable ordering for the kind variables,
> but I'm loathe to make such a drastic change to the surface syntax to
> fix a silly problem like this.
> 2. Investigate a fix to the implicitly quantified ordering issue. I'm
> not sure where the issue could lie, and just from looking at
> extract_lty [4], it's not clear at all what causes the current
> ordering.
> 3. Live with the issue, and just change the code in TcGenGenerics if
> the kind variable ordering ever changes. This is a bummer, but looks
> like the simplest option.
>
> Ryan S.
> -----
> [1] https://ghc.haskell.org/trac/ghc/ticket/10604
> [2]
> http://hackage.haskell.org/package/base-4.8.2.0/docs/GHC-Generics.html#t::
> .:
> [3]
> http://git.haskell.org/ghc.git/blob/d81cdc227cd487659995ddea577214314c9b4b97:/compiler/typecheck/TcGenGenerics.hs#l526
> [4]
> http://git.haskell.org/ghc.git/blob/d81cdc227cd487659995ddea577214314c9b4b97:/compiler/rename/RnTypes.hs#l1611
> _______________________________________________
> 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/20160413/0889637f/attachment-0001.html>

From ben at well-typed.com  Wed Apr 13 17:15:55 2016
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 13 Apr 2016 19:15:55 +0200
Subject: timings for individual compiler passes (in rc3)
In-Reply-To: <570CF467.4060001@htwk-leipzig.de>
References: <570CF467.4060001@htwk-leipzig.de>
Message-ID: <871t69zayc.fsf@smart-cactus.org>

Johannes Waldmann <johannes.waldmann at htwk-leipzig.de> writes:

> Hi.
>
> There is this (closed) https://ghc.haskell.org/trac/ghc/ticket/11653
> and it's landed in 8.rc3.
>
> Thats good, and I want to make an effort to use this.
> But how? Just "-v2"? This gives a lot of noise. And no summary?
>
Indeed, -v2 does produce a lot of noise. We considered adding a
dedicated -ftimings flag but ultimately decided that it wouldn't be
necessary. Afterall, the most obvious users of this functionality are
not end-users but tooling and compiler developers since the timings
themselves are quite tricky to interpret.

I think there are two likely use-cases for this functionality,

 1. for long-term tracking of the performance of various compiler
    subsystems on a set of stable benchmarks (e.g. nofib)

 2. for precise characterization of the effects of optimizations on
    individual compiler passes while working on the compiler

In both cases you'll likely want to feed the compiler's output through
some sort of analysis tool so I thought it wouldn't really be worth
cluttering the implementation with any sort of nice summarization.

?mer has already [1] put together some nice tooling for extracting and
summarizing timings and I believe he is interested in continuing this
line of work. Perhaps you two should chat!

Finally, note that we still have a fair amount of work to do to verify
that the timings produced actually reflect the amount of work done by
each pass. Laziness makes this rather tricky.

The original feature request ticket (#11653) is one obvious place to
hang comments; this list is also appropriate.

Cheers,

- Ben


[1] https://github.com/osa1/analyze-ghc-timings
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160413/debd0746/attachment.sig>

From ryan.gl.scott at gmail.com  Wed Apr 13 17:30:15 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Wed, 13 Apr 2016 13:30:15 -0400
Subject: How does topological sorting of kind variables really work?
In-Reply-To: <CAOSxnRjr9QwyRB4K706yQQMVujJg6y9Va2_pULY=B8_nMpuwmw@mail.gmail.com>
References: <CADdQpRAK8BhaSF7huO8=H9vNBeKuFGeGw6yksXA5ahSQ0OJtDQ@mail.gmail.com>
 <EB841B13-9469-4938-8437-F427A4A152FD@cis.upenn.edu>
 <CADdQpRCWCnDQp4RGn0U2U-NeMf4qmiSbRFnWcxFsz1tX5ksDUw@mail.gmail.com>
 <F3CB1771-9C0C-48B5-AFA8-330C2C10C675@cis.upenn.edu>
 <89ee309d27dc4da793390d399073cda6@DB4PR30MB030.064d.mgd.msft.net>
 <CADdQpRDePQxVU3OzA-JgWYDWhiyeR-g=on3gq4Ws23-89kc-tw@mail.gmail.com>
 <CAOSxnRjr9QwyRB4K706yQQMVujJg6y9Va2_pULY=B8_nMpuwmw@mail.gmail.com>
Message-ID: <CADdQpRAyv27hFdpsQQfpDSBkjzypsgC-k1qvkxKnL4y9tD8R2g@mail.gmail.com>

Ah, I hadn't considered what effect nondeterminism might have on this.
Here's a quick experiment:

With normal uniques:

    $ /opt/ghc/8.0.1/bin/ghci -XTypeInType -fprint-explicit-kinds
-fprint-explicit-foralls
    GHCi, version 8.0.0.20160411: http://www.haskell.org/ghc/  :? for help
    Loaded GHCi configuration from /home/ryanglscott/.ghci
    ?> data T (a :: j -> k -> l) (b :: (x, y, z)) = MkT
    ?> :info T
    type role T nominal nominal nominal nominal nominal nominal phantom phantom
    data T x y z l k j (a :: j -> k -> l) (b :: (x, y, z)) = MkT
            -- Defined at <interactive>:1:1
    ?> :type MkT
    MkT
      :: forall {x} {y} {z} {l} {k} {j} {a :: j -> k -> l} {b :: (x, y,
                                                                  z)}.
         T x y z l k j a b

With reversed uniques:

    $ /opt/ghc/8.0.1/bin/ghci -XTypeInType -fprint-explicit-kinds
-fprint-explicit-foralls -dunique-increment=-1
-dinitial-unique=16777000
    GHCi, version 8.0.0.20160411: http://www.haskell.org/ghc/  :? for help
    Loaded GHCi configuration from /home/ryanglscott/.ghci
    ?> data T (a :: j -> k -> l) (b :: (x, y, z)) = MkT
    ?> :info T
    type role T nominal nominal nominal nominal nominal nominal phantom phantom
    data T x y z l k j (a :: j -> k -> l) (b :: (x, y, z)) = MkT
            -- Defined at <interactive>:1:1
    ?> :type MkT
    MkT
      :: forall {j} {k} {l} {z} {y} {x} {b :: (x, y, z)} {a :: j
                                                               -> k -> l}.
         T x y z l k j a b

So if :info is to be believed, uniques don't (appear to) have an
effect on the order in which the kind variables are bound in the type
constructor, but they do have an effect with :type (which isn't
surprising, since :type re-generalizes the type signature, and
generalization is precisely what you found to be non-deterministic).

Ryan S.

From george.colpitts at gmail.com  Wed Apr 13 17:43:57 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Wed, 13 Apr 2016 17:43:57 +0000
Subject: 7.10.3 fails to build with Xcode 7.3
In-Reply-To: <8CB8A4E2-32AD-4730-9A1D-0BF3CD3319B0@justtesting.org>
References: <8CB8A4E2-32AD-4730-9A1D-0BF3CD3319B0@justtesting.org>
Message-ID: <CAB-d4A7qB4PiyBa7AQMV2paASEvWWQXpBrL4i5b87ADerjmhnA@mail.gmail.com>

It turns out, not surprisingly, that this also breaks ghc 8, but in a
totally different way, see
https://ghc.haskell.org/trac/ghc/ticket/11823#comment:13



On Sat, Mar 26, 2016 at 6:35 AM Manuel M T Chakravarty <chak at justtesting.org>
wrote:

> I just noticed that GHC 7.10.3 (latest release version) fails to build
> with version 7.3 of Xcode (which just came out of beta). Maybe this is due
> to
>
>   https://ghc.haskell.org/trac/ghc/ticket/11744
>
> The problem manifests in the form of a SEGV when dll-split is invoked for
> the first time ? specifically lldb has the following to say,
>
> Process 17348 launched: '../lib/bin/dll-split' (x86_64)
> Process 17348 stopped
> * thread #1: tid = 0x4a821e, 0x0000000100e26357
> libHSrts-ghc7.10.3.dylib`stg_returnToStackTop + 7, queue =
> 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1e)
>     frame #0: 0x0000000100e26357
> libHSrts-ghc7.10.3.dylib`stg_returnToStackTop + 7
> libHSrts-ghc7.10.3.dylib`stg_returnToStackTop:
> ->  0x100e26357 <+7>:  movq   0x1e(%rax), %rbx
>     0x100e2635b <+11>: movq   0x10(%rbx), %rbp
>     0x100e2635f <+15>: leaq   0x126(%rbx), %r15
>     0x100e26366 <+22>: movq   $0x0, 0x904(%r13)
>
> Interestingly, the GHC 8.0.1-rc2 build does not exhibit that same failure.
> It does, however, fail to build due to an undefined symbol:
>
> Undefined symbols for architecture x86_64:
>   "_stg_sel_18_upd_info", referenced from:
>       _sc9J_info in Monad.dyn_o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> `gcc' failed in phase `Linker'. (Exit code: 1)
> make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1
> make: *** [all] Error 2
>
> (This may be unrelated to Xcode 7.3 and a known problem on OS X with that
> RC. I didn?t follow the 8.0.1-rc2 tickets in detail.)
>
> As I assume that there will be no further 7.10 release, I am posting this
> here just to save others the time to track the problem down.
>
> Manuel
>
> PS: I wish I had the time to check GHC builds with Xcode beta releases,
> but alas, I usually don?t.
> _______________________________________________
> 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/20160413/e12f4002/attachment.html>

From george.colpitts at gmail.com  Wed Apr 13 17:54:13 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Wed, 13 Apr 2016 17:54:13 +0000
Subject: 7.10.3 fails to build with Xcode 7.3
In-Reply-To: <CAB-d4A7qB4PiyBa7AQMV2paASEvWWQXpBrL4i5b87ADerjmhnA@mail.gmail.com>
References: <8CB8A4E2-32AD-4730-9A1D-0BF3CD3319B0@justtesting.org>
 <CAB-d4A7qB4PiyBa7AQMV2paASEvWWQXpBrL4i5b87ADerjmhnA@mail.gmail.com>
Message-ID: <CAB-d4A7jRH7x_=JOTBP90AHqEZRJT5QQb-93ROG4KXqK=rVdBg@mail.gmail.com>

Sorry I see that Manuel mentioned the problem with 8.0.1 rc2 alreadyin his
first email about this

On Wed, Apr 13, 2016 at 2:43 PM George Colpitts <george.colpitts at gmail.com>
wrote:

> It turns out, not surprisingly, that this also breaks ghc 8, but in a
> totally different way, see
> https://ghc.haskell.org/trac/ghc/ticket/11823#comment:13
>
>
>
> On Sat, Mar 26, 2016 at 6:35 AM Manuel M T Chakravarty <
> chak at justtesting.org> wrote:
>
>> I just noticed that GHC 7.10.3 (latest release version) fails to build
>> with version 7.3 of Xcode (which just came out of beta). Maybe this is due
>> to
>>
>>   https://ghc.haskell.org/trac/ghc/ticket/11744
>>
>> The problem manifests in the form of a SEGV when dll-split is invoked for
>> the first time ? specifically lldb has the following to say,
>>
>> Process 17348 launched: '../lib/bin/dll-split' (x86_64)
>> Process 17348 stopped
>> * thread #1: tid = 0x4a821e, 0x0000000100e26357
>> libHSrts-ghc7.10.3.dylib`stg_returnToStackTop + 7, queue =
>> 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1e)
>>     frame #0: 0x0000000100e26357
>> libHSrts-ghc7.10.3.dylib`stg_returnToStackTop + 7
>> libHSrts-ghc7.10.3.dylib`stg_returnToStackTop:
>> ->  0x100e26357 <+7>:  movq   0x1e(%rax), %rbx
>>     0x100e2635b <+11>: movq   0x10(%rbx), %rbp
>>     0x100e2635f <+15>: leaq   0x126(%rbx), %r15
>>     0x100e26366 <+22>: movq   $0x0, 0x904(%r13)
>>
>> Interestingly, the GHC 8.0.1-rc2 build does not exhibit that same
>> failure. It does, however, fail to build due to an undefined symbol:
>>
>> Undefined symbols for architecture x86_64:
>>   "_stg_sel_18_upd_info", referenced from:
>>       _sc9J_info in Monad.dyn_o
>> ld: symbol(s) not found for architecture x86_64
>> clang: error: linker command failed with exit code 1 (use -v to see
>> invocation)
>> `gcc' failed in phase `Linker'. (Exit code: 1)
>> make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1
>> make: *** [all] Error 2
>>
>> (This may be unrelated to Xcode 7.3 and a known problem on OS X with that
>> RC. I didn?t follow the 8.0.1-rc2 tickets in detail.)
>>
>> As I assume that there will be no further 7.10 release, I am posting this
>> here just to save others the time to track the problem down.
>>
>> Manuel
>>
>> PS: I wish I had the time to check GHC builds with Xcode beta releases,
>> but alas, I usually don?t.
>> _______________________________________________
>> 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/20160413/f524bbe9/attachment.html>

From george.colpitts at gmail.com  Wed Apr 13 19:49:46 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Wed, 13 Apr 2016 19:49:46 +0000
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <87egadbj2w.fsf@smart-cactus.org>
References: <87egadbj2w.fsf@smart-cactus.org>
Message-ID: <CAB-d4A4gHuVSfZw_ci-2aooTQ4seuAzz1tU+wyyPznHh=Met=g@mail.gmail.com>

I got past my first problem (see
https://ghc.haskell.org/trac/ghc/ticket/11823#comment:13 for the
resolution) but now I have the following problem building the doc (on a
Mac) .

It seems like it doesn't like font names with spaces, not sure why (or if!)
this would be Mac specific:

       Invalid fontname `DejaVu Sans', contains ' '

longer extract from the output:

copying static files... This is XeTeX, Version 3.14159265-2.6-0.99992 (TeX
Live 2015) (preloaded format=xelatex)
 restricted \write18 enabled.
entering extended mode
(./users_guide.tex
LaTeX2e <2015/01/01>
Babel <3.9l> and hyphenation patterns for 79 languages loaded.
(./sphinxmanual.cls
Document Class: sphinxmanual 2009/06/02 Document class (Sphinx manual)
(/usr/local/texlive/2015/texmf-dist/tex/latex/base/report.cls
Document Class: report 2014/09/29 v1.4h Standard LaTeX document class
(/usr/local/texlive/2015/texmf-dist/tex/latex/base/size10.clodone
copying extra files... done
dumping search index in English (code: en) ... )))
(/usr/local/texlive/2015/texmf-dist/tex/latex/cmap/cmap.sty

Package cmap Warning: pdftex not detected - exiting.

)done
dumping object inventory...
 (/usr/local/texlive/2015/texmf-dist/tex/latex/base/fontenc.sty
(/usr/local/texlive/2015/texmf-dist/tex/latex/base/t1enc.defdone
build succeeded, 25 warnings.
))
(/usr/local/texlive/2015/texmf-dist/tex/generic/babel/babel.sty
(/usr/local/texlive/2015/texmf-dist/tex/generic/babel-english/english.ldf
(/usr/local/texlive/2015/texmf-dist/tex/generic/babel/babel.def
(/usr/local/texlive/2015/texmf-dist/tex/generic/babel/xebabel.def))))
(/usr/local/texlive/2015/texmf-dist/tex/latex/psnfss/times.sty)
(./fncychap.sty
) (/usr/local/texlive/2015/texmf-dist/tex/latex/tools/longtable.sty)
(./sphinx.sty
(/usr/local/texlive/2015/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty)
(/usr/local/texlive/2015/texmf-dist/tex/latex/base/textcomp.sty
(/usr/local/texlive/2015/texmf-dist/tex/latex/base/ts1enc.def))
(/usr/local/texlive/2015/texmf-dist/tex/latex/fancybox/fancybox.sty
Style option: `fancybox' v1.4 <2010/05/15> (tvz)
) (/usr/local/texlive/2015/texmf-dist/tex/latex/titlesec/titlesec.sty)
(./tabulary.sty
(/usr/local/texlive/2015/texmf-dist/tex/latex/tools/array.sty))
 (/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amsmath.sty
For additional information on amsmath, use the `?' option.
(/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amstext.sty
(/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amsgen.sty))
(/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amsbsy.sty)
(/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amsopn.sty))
(/usr/local/texlive/2015/texmf-dist/tex/latex/base/makeidx.sty)
(/usr/local/texlive/2015/texmf-dist/tex/latex/framed/framed.sty)
(/usr/local/texlive/2015/texmf-dist/tex/latex/base/ifthen.sty)
(/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/color.sty
(/usr/local/texlive/2015/texmf-dist/tex/latex/latexconfig/color.cfg)
(/usr/local/texlive/2015/texmf-dist/tex/xelatex/xetex-def/xetex.def))
(/usr/local/texlive/2015/texmf-dist/tex/latex/fancyvrb/fancyvrb.sty
Style option: `fancyvrb' v2.7a, with DG/SPQR fixes, and firstline=lastline
fix
<2008/02/07> (tvz)
(/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/keyval.sty))
(/usr/local/texlive/2015/texmf-dist/tex/latex/threeparttable/threeparttable.sty
) (/usr/local/texlive/2015/texmf-dist/tex/latex/mdwtools/footnote.sty)
(/usr/local/texlive/2015/texmf-dist/tex/latex/wrapfig/wrapfig.sty)
(/usr/local/texlive/2015/texmf-dist/tex/latex/parskip/parskip.sty)
(/usr/local/texlive/2015/texmf-dist/tex/latex/base/alltt.sty)
(/usr/local/texlive/2015/texmf-dist/tex/latex/upquote/upquote.sty)
(/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/graphicx.sty
(/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/graphics.sty
(/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/trig.sty)
(/usr/local/texlive/2015/texmf-dist/tex/latex/latexconfig/graphics.cfg)))
(/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/hyperref.sty
(/usr/local/texlive/2015/texmf-dist/tex/generic/oberdiek/hobsub-hyperref.sty
(/usr/local/texlive/2015/texmf-dist/tex/generic/oberdiek/hobsub-generic.sty))
(/usr/local/texlive/2015/texmf-dist/tex/generic/ifxetex/ifxetex.sty)
(/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/auxhook.sty)
(/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/kvoptions.sty)
(/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/pd1enc.def)
(/usr/local/texlive/2015/texmf-dist/tex/latex/latexconfig/hyperref.cfg)
(/usr/local/texlive/2015/texmf-dist/tex/latex/url/url.sty))

Package hyperref Message: Driver (autodetected): hxetex.

(/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/hxetex.def
(/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/puenc.def)
(/usr/local/texlive/2015/texmf-dist/tex/generic/oberdiek/stringenc.sty)
(/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/rerunfilecheck.sty))
(/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/hypcap.sty)
(/usr/local/texlive/2015/texmf-dist/tex/latex/caption/newfloat.sty)
(/usr/local/texlive/2015/texmf-dist/tex/latex/capt-of/capt-of.sty)
(/usr/local/texlive/2015/texmf-dist/tex/latex/needspace/needspace.sty))
(/usr/local/texlive/2015/texmf-dist/tex/latex/multirow/multirow.sty)
(/usr/local/texlive/2015/texmf-dist/tex/latex/eqparbox/eqparbox.sty
(/usr/local/texlive/2015/texmf-dist/tex/latex/environ/environ.sty
(/usr/local/texlive/2015/texmf-dist/tex/latex/trimspaces/trimspaces.sty)))
(/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec.sty
(/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/expl3.sty
(/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/expl3-code.tex)
(/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/l3unicode-data.def)
(/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/l3xdvipdfmx.def))
(/usr/local/texlive/2015/texmf-dist/tex/latex/l3packages/xparse/xparse.sty)
(/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec-patches.sty)
(/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
(/usr/local/texlive/2015/texmf-dist/tex/latex/base/fontenc.sty
(/usr/local/texlive/2015/texmf-dist/tex/latex/euenc/eu1enc.def)
(/usr/local/texlive/2015/texmf-dist/tex/latex/euenc/eu1lmr.fd))
(/usr/local/texlive/2015/texmf-dist/tex/xelatex/xunicode/xunicode.sty
(/usr/local/texlive/2015/texmf-dist/tex/latex/tipa/t3enc.def
(/usr/local/texlive/2015/texmf-dist/tex/latex/euenc/eu1lmss.fd)))
(/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec.cfg)))kpathsea:make_tex:
.


!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!
! fontspec error: "font-not-found"
!
! The font "DejaVu Sans" cannot be found.
!
! See the fontspec documentation for further information.
!
! For immediate help type H <return>.
!...............................................

l.23 \setsansfont{DejaVu Sans}

?

On Sun, Apr 10, 2016 at 12:05 PM Ben Gamari <ben at well-typed.com> wrote:

> tl;dr: If you would like to produce a binary distribution for GHC
>        8.0.1-rc3 then let us know, grab the source distribution and
>        start building. The binary distributions will be all released one
>        week from today.
>
>
> Hello GHC packagers,
>
> Austin and I are happy to announce the release of the 8.0.1-rc3 source
> distribution to binary packagers. You will find the tarball and usual
> assortment of signatures at
>
>     http://downloads.haskell.org/~ghc/8.0.1-rc3/
>
> This release is the first where we are following our new release policy
> [1], where a one-week delay will be introduced between the release of
> the source and binary distributions. The goal of this policy is to give
> all platforms the opportunity for support from the first day of a
> release.
>
> If all of the expected binary releases are submitted before the
> week-long delay is through, we can move forward with the release ahead
> of schedule. Given how late release candidate 3 is, we'd naturally like
> to get the binary releases out as soon is possible: The sooner we can
> get this -rc out the door the sooner we can get to the final release.
> Moreover, it would be appreciated if you could confirm that you intend
> to offer a binary distribution this release.
>
> Otherwise, let either Austin or I know if you have any trouble building
> your distribution. I have yet to push the 8.0.1-rc3 tag in case we
> encounter unexpected issues but all of my builds with this tarball
> thusfar have gone quite well.
>
> Good luck and thanks for all of your work!
>
> Cheers,
>
> - Ben
>
>
> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.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/20160413/73fc0a37/attachment-0001.html>

From austin at well-typed.com  Wed Apr 13 19:56:40 2016
From: austin at well-typed.com (Austin Seipp)
Date: Wed, 13 Apr 2016 14:56:40 -0500
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <CAB-d4A4gHuVSfZw_ci-2aooTQ4seuAzz1tU+wyyPznHh=Met=g@mail.gmail.com>
References: <87egadbj2w.fsf@smart-cactus.org>
 <CAB-d4A4gHuVSfZw_ci-2aooTQ4seuAzz1tU+wyyPznHh=Met=g@mail.gmail.com>
Message-ID: <CAEs96n24m9DAitZhZqKPu=mWidBuE1HU-V4jnjNUJgo+L+td8w@mail.gmail.com>

If you look at the bottom of the error, `fontspec` has already given
you the more specific diagnosis of what's wrong:

> The font "DejaVu Sans" cannot be found.

That is, you need to install the DejaVu Sans font. Dealing with fonts
and modern typesetting is a complete mystery to me though, so I'll
leave you to install it on your Mac. :)

On Wed, Apr 13, 2016 at 2:49 PM, George Colpitts
<george.colpitts at gmail.com> wrote:
> I got past my first problem (see
> https://ghc.haskell.org/trac/ghc/ticket/11823#comment:13 for the resolution)
> but now I have the following problem building the doc (on a Mac) .
>
> It seems like it doesn't like font names with spaces, not sure why (or if!)
> this would be Mac specific:
>
>        Invalid fontname `DejaVu Sans', contains ' '
>
> longer extract from the output:
>
> copying static files... This is XeTeX, Version 3.14159265-2.6-0.99992 (TeX
> Live 2015) (preloaded format=xelatex)
>  restricted \write18 enabled.
> entering extended mode
> (./users_guide.tex
> LaTeX2e <2015/01/01>
> Babel <3.9l> and hyphenation patterns for 79 languages loaded.
> (./sphinxmanual.cls
> Document Class: sphinxmanual 2009/06/02 Document class (Sphinx manual)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/base/report.cls
> Document Class: report 2014/09/29 v1.4h Standard LaTeX document class
> (/usr/local/texlive/2015/texmf-dist/tex/latex/base/size10.clodone
> copying extra files... done
> dumping search index in English (code: en) ... )))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/cmap/cmap.sty
>
> Package cmap Warning: pdftex not detected - exiting.
>
> )done
> dumping object inventory...
> (/usr/local/texlive/2015/texmf-dist/tex/latex/base/fontenc.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/base/t1enc.defdone
> build succeeded, 25 warnings.
> ))
> (/usr/local/texlive/2015/texmf-dist/tex/generic/babel/babel.sty
> (/usr/local/texlive/2015/texmf-dist/tex/generic/babel-english/english.ldf
> (/usr/local/texlive/2015/texmf-dist/tex/generic/babel/babel.def
> (/usr/local/texlive/2015/texmf-dist/tex/generic/babel/xebabel.def))))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/psnfss/times.sty)
> (./fncychap.sty
> ) (/usr/local/texlive/2015/texmf-dist/tex/latex/tools/longtable.sty)
> (./sphinx.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/base/textcomp.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/base/ts1enc.def))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/fancybox/fancybox.sty
> Style option: `fancybox' v1.4 <2010/05/15> (tvz)
> ) (/usr/local/texlive/2015/texmf-dist/tex/latex/titlesec/titlesec.sty)
> (./tabulary.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/tools/array.sty))
>  (/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amsmath.sty
> For additional information on amsmath, use the `?' option.
> (/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amstext.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amsgen.sty))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amsbsy.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amsopn.sty))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/base/makeidx.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/framed/framed.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/base/ifthen.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/color.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/latexconfig/color.cfg)
> (/usr/local/texlive/2015/texmf-dist/tex/xelatex/xetex-def/xetex.def))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/fancyvrb/fancyvrb.sty
> Style option: `fancyvrb' v2.7a, with DG/SPQR fixes, and firstline=lastline
> fix
> <2008/02/07> (tvz)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/keyval.sty))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/threeparttable/threeparttable.sty
> ) (/usr/local/texlive/2015/texmf-dist/tex/latex/mdwtools/footnote.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/wrapfig/wrapfig.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/parskip/parskip.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/base/alltt.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/upquote/upquote.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/graphicx.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/graphics.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/trig.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/latexconfig/graphics.cfg)))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/hyperref.sty
> (/usr/local/texlive/2015/texmf-dist/tex/generic/oberdiek/hobsub-hyperref.sty
> (/usr/local/texlive/2015/texmf-dist/tex/generic/oberdiek/hobsub-generic.sty))
> (/usr/local/texlive/2015/texmf-dist/tex/generic/ifxetex/ifxetex.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/auxhook.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/kvoptions.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/pd1enc.def)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/latexconfig/hyperref.cfg)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/url/url.sty))
>
> Package hyperref Message: Driver (autodetected): hxetex.
>
> (/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/hxetex.def
> (/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/puenc.def)
> (/usr/local/texlive/2015/texmf-dist/tex/generic/oberdiek/stringenc.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/rerunfilecheck.sty))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/hypcap.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/caption/newfloat.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/capt-of/capt-of.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/needspace/needspace.sty))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/multirow/multirow.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/eqparbox/eqparbox.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/environ/environ.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/trimspaces/trimspaces.sty)))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/expl3.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/expl3-code.tex)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/l3unicode-data.def)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/l3xdvipdfmx.def))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/l3packages/xparse/xparse.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec-patches.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/base/fontenc.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/euenc/eu1enc.def)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/euenc/eu1lmr.fd))
> (/usr/local/texlive/2015/texmf-dist/tex/xelatex/xunicode/xunicode.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/tipa/t3enc.def
> (/usr/local/texlive/2015/texmf-dist/tex/latex/euenc/eu1lmss.fd)))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec.cfg)))kpathsea:make_tex:
> .
>
>
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !
> ! fontspec error: "font-not-found"
> !
> ! The font "DejaVu Sans" cannot be found.
> !
> ! See the fontspec documentation for further information.
> !
> ! For immediate help type H <return>.
> !...............................................
>
> l.23 \setsansfont{DejaVu Sans}
>
> ?
>
> On Sun, Apr 10, 2016 at 12:05 PM Ben Gamari <ben at well-typed.com> wrote:
>>
>> tl;dr: If you would like to produce a binary distribution for GHC
>>        8.0.1-rc3 then let us know, grab the source distribution and
>>        start building. The binary distributions will be all released one
>>        week from today.
>>
>>
>> Hello GHC packagers,
>>
>> Austin and I are happy to announce the release of the 8.0.1-rc3 source
>> distribution to binary packagers. You will find the tarball and usual
>> assortment of signatures at
>>
>>     http://downloads.haskell.org/~ghc/8.0.1-rc3/
>>
>> This release is the first where we are following our new release policy
>> [1], where a one-week delay will be introduced between the release of
>> the source and binary distributions. The goal of this policy is to give
>> all platforms the opportunity for support from the first day of a
>> release.
>>
>> If all of the expected binary releases are submitted before the
>> week-long delay is through, we can move forward with the release ahead
>> of schedule. Given how late release candidate 3 is, we'd naturally like
>> to get the binary releases out as soon is possible: The sooner we can
>> get this -rc out the door the sooner we can get to the final release.
>> Moreover, it would be appreciated if you could confirm that you intend
>> to offer a binary distribution this release.
>>
>> Otherwise, let either Austin or I know if you have any trouble building
>> your distribution. I have yet to push the 8.0.1-rc3 tag in case we
>> encounter unexpected issues but all of my builds with this tarball
>> thusfar have gone quite well.
>>
>> Good luck and thanks for all of your work!
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.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
>



-- 
Regards,

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

From carter.schonwald at gmail.com  Wed Apr 13 20:11:56 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 13 Apr 2016 16:11:56 -0400
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <CAHYVw0x4MP38qvir10zDLpodDdXXk2SiPS8miyUgd3pMFqP4YA@mail.gmail.com>
References: <87egadbj2w.fsf@smart-cactus.org>
 <CAB-d4A4gHuVSfZw_ci-2aooTQ4seuAzz1tU+wyyPznHh=Met=g@mail.gmail.com>
 <CAEs96n24m9DAitZhZqKPu=mWidBuE1HU-V4jnjNUJgo+L+td8w@mail.gmail.com>
 <CAHYVw0x4MP38qvir10zDLpodDdXXk2SiPS8miyUgd3pMFqP4YA@mail.gmail.com>
Message-ID: <CAHYVw0y87yAYHCp1J6q93eTimawTcwx3kUedaSA2OEmGeQZOdw@mail.gmail.com>

Downloading the ttf font files and opening them via font book handles the
import / font registry on Macs
On Apr 13, 2016 3:56 PM, "Austin Seipp" <austin at well-typed.com> wrote:

If you look at the bottom of the error, `fontspec` has already given
you the more specific diagnosis of what's wrong:

> The font "DejaVu Sans" cannot be found.

That is, you need to install the DejaVu Sans font. Dealing with fonts
and modern typesetting is a complete mystery to me though, so I'll
leave you to install it on your Mac. :)

On Wed, Apr 13, 2016 at 2:49 PM, George Colpitts
<george.colpitts at gmail.com> wrote:
> I got past my first problem (see
> https://ghc.haskell.org/trac/ghc/ticket/11823#comment:13 for the
resolution)
> but now I have the following problem building the doc (on a Mac) .
>
> It seems like it doesn't like font names with spaces, not sure why (or
if!)
> this would be Mac specific:
>
>        Invalid fontname `DejaVu Sans', contains ' '
>
> longer extract from the output:
>
> copying static files... This is XeTeX, Version 3.14159265-2.6-0.99992 (TeX
> Live 2015) (preloaded format=xelatex)
>  restricted \write18 enabled.
> entering extended mode
> (./users_guide.tex
> LaTeX2e <2015/01/01>
> Babel <3.9l> and hyphenation patterns for 79 languages loaded.
> (./sphinxmanual.cls
> Document Class: sphinxmanual 2009/06/02 Document class (Sphinx manual)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/base/report.cls
> Document Class: report 2014/09/29 v1.4h Standard LaTeX document class
> (/usr/local/texlive/2015/texmf-dist/tex/latex/base/size10.clodone
> copying extra files... done
> dumping search index in English (code: en) ... )))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/cmap/cmap.sty
>
> Package cmap Warning: pdftex not detected - exiting.
>
> )done
> dumping object inventory...
> (/usr/local/texlive/2015/texmf-dist/tex/latex/base/fontenc.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/base/t1enc.defdone
> build succeeded, 25 warnings.
> ))
> (/usr/local/texlive/2015/texmf-dist/tex/generic/babel/babel.sty
> (/usr/local/texlive/2015/texmf-dist/tex/generic/babel-english/english.ldf
> (/usr/local/texlive/2015/texmf-dist/tex/generic/babel/babel.def
> (/usr/local/texlive/2015/texmf-dist/tex/generic/babel/xebabel.def))))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/psnfss/times.sty)
> (./fncychap.sty
> ) (/usr/local/texlive/2015/texmf-dist/tex/latex/tools/longtable.sty)
> (./sphinx.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/base/textcomp.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/base/ts1enc.def))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/fancybox/fancybox.sty
> Style option: `fancybox' v1.4 <2010/05/15> (tvz)
> ) (/usr/local/texlive/2015/texmf-dist/tex/latex/titlesec/titlesec.sty)
> (./tabulary.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/tools/array.sty))
>  (/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amsmath.sty
> For additional information on amsmath, use the `?' option.
> (/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amstext.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amsgen.sty))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amsbsy.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amsopn.sty))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/base/makeidx.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/framed/framed.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/base/ifthen.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/color.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/latexconfig/color.cfg)
> (/usr/local/texlive/2015/texmf-dist/tex/xelatex/xetex-def/xetex.def))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/fancyvrb/fancyvrb.sty
> Style option: `fancyvrb' v2.7a, with DG/SPQR fixes, and firstline=lastline
> fix
> <2008/02/07> (tvz)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/keyval.sty))
>
(/usr/local/texlive/2015/texmf-dist/tex/latex/threeparttable/threeparttable.sty
> ) (/usr/local/texlive/2015/texmf-dist/tex/latex/mdwtools/footnote.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/wrapfig/wrapfig.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/parskip/parskip.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/base/alltt.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/upquote/upquote.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/graphicx.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/graphics.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/trig.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/latexconfig/graphics.cfg)))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/hyperref.sty
>
(/usr/local/texlive/2015/texmf-dist/tex/generic/oberdiek/hobsub-hyperref.sty
>
(/usr/local/texlive/2015/texmf-dist/tex/generic/oberdiek/hobsub-generic.sty))
> (/usr/local/texlive/2015/texmf-dist/tex/generic/ifxetex/ifxetex.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/auxhook.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/kvoptions.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/pd1enc.def)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/latexconfig/hyperref.cfg)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/url/url.sty))
>
> Package hyperref Message: Driver (autodetected): hxetex.
>
> (/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/hxetex.def
> (/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/puenc.def)
> (/usr/local/texlive/2015/texmf-dist/tex/generic/oberdiek/stringenc.sty)
>
(/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/rerunfilecheck.sty))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/hypcap.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/caption/newfloat.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/capt-of/capt-of.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/needspace/needspace.sty))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/multirow/multirow.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/eqparbox/eqparbox.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/environ/environ.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/trimspaces/trimspaces.sty)))
> (/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/expl3.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/expl3-code.tex)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/l3unicode-data.def)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/l3xdvipdfmx.def))
>
(/usr/local/texlive/2015/texmf-dist/tex/latex/l3packages/xparse/xparse.sty)
>
(/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec-patches.sty)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/base/fontenc.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/euenc/eu1enc.def)
> (/usr/local/texlive/2015/texmf-dist/tex/latex/euenc/eu1lmr.fd))
> (/usr/local/texlive/2015/texmf-dist/tex/xelatex/xunicode/xunicode.sty
> (/usr/local/texlive/2015/texmf-dist/tex/latex/tipa/t3enc.def
> (/usr/local/texlive/2015/texmf-dist/tex/latex/euenc/eu1lmss.fd)))
>
(/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec.cfg)))kpathsea:make_tex:
> .
>
>
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !
> ! fontspec error: "font-not-found"
> !
> ! The font "DejaVu Sans" cannot be found.
> !
> ! See the fontspec documentation for further information.
> !
> ! For immediate help type H <return>.
> !...............................................
>
> l.23 \setsansfont{DejaVu Sans}
>
> ?
>
> On Sun, Apr 10, 2016 at 12:05 PM Ben Gamari <ben at well-typed.com> wrote:
>>
>> tl;dr: If you would like to produce a binary distribution for GHC
>>        8.0.1-rc3 then let us know, grab the source distribution and
>>        start building. The binary distributions will be all released one
>>        week from today.
>>
>>
>> Hello GHC packagers,
>>
>> Austin and I are happy to announce the release of the 8.0.1-rc3 source
>> distribution to binary packagers. You will find the tarball and usual
>> assortment of signatures at
>>
>>     http://downloads.haskell.org/~ghc/8.0.1-rc3/
>>
>> This release is the first where we are following our new release policy
>> [1], where a one-week delay will be introduced between the release of
>> the source and binary distributions. The goal of this policy is to give
>> all platforms the opportunity for support from the first day of a
>> release.
>>
>> If all of the expected binary releases are submitted before the
>> week-long delay is through, we can move forward with the release ahead
>> of schedule. Given how late release candidate 3 is, we'd naturally like
>> to get the binary releases out as soon is possible: The sooner we can
>> get this -rc out the door the sooner we can get to the final release.
>> Moreover, it would be appreciated if you could confirm that you intend
>> to offer a binary distribution this release.
>>
>> Otherwise, let either Austin or I know if you have any trouble building
>> your distribution. I have yet to push the 8.0.1-rc3 tag in case we
>> encounter unexpected issues but all of my builds with this tarball
>> thusfar have gone quite well.
>>
>> Good luck and thanks for all of your work!
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.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
>



--
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
_______________________________________________
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/20160413/56ae2a82/attachment-0001.html>

From eir at cis.upenn.edu  Wed Apr 13 20:20:45 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 13 Apr 2016 16:20:45 -0400
Subject: How does topological sorting of kind variables really work?
In-Reply-To: <89ee309d27dc4da793390d399073cda6@DB4PR30MB030.064d.mgd.msft.net>
References: <CADdQpRAK8BhaSF7huO8=H9vNBeKuFGeGw6yksXA5ahSQ0OJtDQ@mail.gmail.com>
 <EB841B13-9469-4938-8437-F427A4A152FD@cis.upenn.edu>
 <CADdQpRCWCnDQp4RGn0U2U-NeMf4qmiSbRFnWcxFsz1tX5ksDUw@mail.gmail.com>
 <F3CB1771-9C0C-48B5-AFA8-330C2C10C675@cis.upenn.edu>
 <89ee309d27dc4da793390d399073cda6@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <EB5F176B-9093-47C2-9500-4466C58D99E3@cis.upenn.edu>


On Apr 13, 2016, at 5:17 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> I thought that inferred foralls are Invisible binders (see Note [TyBinders and VisibilityFlags]); and you can't use visible type application for Invisible binders.  

No. See that Note. A binder is Invisible only when it is completely unmentioned in the source. The implicitly-bound kind variables Ryan uses are meant to be Specified.

> 
> I thought that was because it's hard to specify the order of inferred type variable, just as Ryan says.

Once the user has written something, then we have a left-to-right ordering to guide us.

> 
> So /is/ inference meant to give a reliable ordering?  If so why?  

We had decided that a signature `f :: a -> a` meant that `a` is specified. It seemed silly if `data P (a :: k)` did not mean that `k` is specified, too.

Another confounding detail here: the `:type` command now fully instantiates a type and then regeneralizes. So any output of `:type` can't be relied upon to get the variable ordering correct. For simple functions, you can use `:info`. But for data constructors, for example, GHC currently provides no way to see which variables are specified, and what order they appear in. See #11376.

It is my intent that any variables mentioned by the user appear in a predictable order in types. That does not seem to be the case here, so this is a bug.

Richard

From eir at cis.upenn.edu  Wed Apr 13 20:25:43 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 13 Apr 2016 16:25:43 -0400
Subject: Reification of out-of-scope variables?
In-Reply-To: <CAJ0eudoNEa-dpSNwT1fhPxdQr6CpYvsuexVJNoxowoDu6KBahA@mail.gmail.com>
References: <CAJ0eudrYKW=+s25+G9x_3AQNJTU2Uqj18uZfbzZedF2p8oq=LQ@mail.gmail.com>
 <266BEB36-AA3D-4049-84F7-138C6FF7539A@cis.upenn.edu>
 <CA+Q==SDrdJBAKWt4ULwgYpPu0vHwz-WqSK4U1upTaA2DTtGPAQ@mail.gmail.com>
 <1DA2B8DB-1830-44A4-9564-F3B508771909@cis.upenn.edu>
 <CAJ0eudoNEa-dpSNwT1fhPxdQr6CpYvsuexVJNoxowoDu6KBahA@mail.gmail.com>
Message-ID: <9BF5E2D1-B54D-430C-A40F-164B5B46D3FF@cis.upenn.edu>

Very interesting.

On Apr 13, 2016, at 5:09 AM, "Boespflug, Mathieu" <m at tweag.io> wrote:
> 
> * Should we consider it a bug (and file a ticket) that reification in
> typed splices is able to observe the order of type checking, just like
> reify used to do in untyped splices?

I think so, yes.

> * While Richard's proposed addGroupFinalizer might not work with
> untyped splices, perhaps it can be made to work with typed splices,
> since these run in the type checker?

I think so, yes. Perhaps it would be more well-typed to have typed TH splices run in a new monad TQ such that TQ allows addGroupFinalizer but Q does not. This may be overkill though.

> * If part of the solution here is to use typed splices, how do we get
> quasiquotation to be syntactic sugar for a *typed* splice? Do we want
> to be introducing a typed quasiquotation syntax, just like Geoff did
> for much of the rest of Template Haskell?

Maybe. Quasiquotation sugar is very light: [blah|...|] is the same as $(selector blah "...") where `selector` is the right record selector depending on the splice context. Is it worth trying to expand quasiquotation syntax to work with typed TH? I'm unconvinced it's worth the bother. Also, note that doing [blah||...||] is not backward-compatible, because that looks like an untyped quasiquote that begins and ends with a vertical bar. We could get around this problem by using a new extension, but the waters are just getting muddier, and for seemingly little benefit.

Richard

> 
> Facundo and I think that something like Richard's addGroupFinalizer is
> still interesting to have, because while reification during type
> checking sounds dubious, reification /after/ the declaration group is
> fully type checked is perfectly safe.
> 
> Best,
> --
> Mathieu Boespflug
> Founder at http://tweag.io.
> 
> 
> On 13 April 2016 at 04:25, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>> On Apr 12, 2016, at 5:35 PM, Facundo Dom?nguez <facundo.dominguez at tweag.io> wrote:
>> 
>>> Hello Richard,
>>> 
>>>> TH will offer a new function `addGroupFinalizer :: Q () -> Q ()` that runs its argument in the local typing environment available when addGroupFinalizer is called.
>>> 
>>> When considering this approach, how could one capture the local typing
>>> environment given that the untyped splices are run in the renamer
>>> where no such environment is populated yet?
>>> 
>> 
>> Ah. Excellent point. I hadn't quite thought it through. Not sure, off the top of my head, how to get around this.
>> 
>> Richard
>> 
> 


From eir at cis.upenn.edu  Wed Apr 13 20:28:46 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 13 Apr 2016 16:28:46 -0400
Subject: Reification of out-of-scope variables?
In-Reply-To: <CA+Q==SA_LGtUBKHv9WhePWrWgebeTd7O7v7A4_5fypgd8GFuVA@mail.gmail.com>
References: <CAJ0eudrYKW=+s25+G9x_3AQNJTU2Uqj18uZfbzZedF2p8oq=LQ@mail.gmail.com>
 <266BEB36-AA3D-4049-84F7-138C6FF7539A@cis.upenn.edu>
 <CA+Q==SDrdJBAKWt4ULwgYpPu0vHwz-WqSK4U1upTaA2DTtGPAQ@mail.gmail.com>
 <1DA2B8DB-1830-44A4-9564-F3B508771909@cis.upenn.edu>
 <CAJ0eudoNEa-dpSNwT1fhPxdQr6CpYvsuexVJNoxowoDu6KBahA@mail.gmail.com>
 <CA+Q==SA_LGtUBKHv9WhePWrWgebeTd7O7v7A4_5fypgd8GFuVA@mail.gmail.com>
Message-ID: <2725F10B-AFAF-4B26-B627-492AD5CA759D@cis.upenn.edu>

This is a bit invasive, but I don't immediately see an easier way. I'd personally want a few more people to weigh in before accepting this plan of attack. In your favor is that you are Real Users who want the feature to Get Work Done.

Let's see what others think, but I'm not opposed.

Richard

On Apr 13, 2016, at 7:31 AM, Facundo Dom?nguez <facundo.dominguez at tweag.io> wrote:

> An implementation for untyped splices could be:
> * Have a map from internal names to the local typing environments.
> * When the renamer runs addGroupFinalizer it generates an internal
> name and annotates the AST with the internal name at the location of
> the splice.
> * When the type checker finds the annotation it inserts the local
> typing environment in the map.
> * When the finalizer runs, it looks up its local typing environment in the map.
> 
> It is not as simple as running the splice in the typechecker, but
> would you still be happy merging a solution like this?
> 
> Facundo
> 
> 
> On Wed, Apr 13, 2016 at 6:09 AM, Boespflug, Mathieu <m at tweag.io> wrote:
>> Hi Richard,
>> 
>> Facundo and I had a chat about this offline. Facundo noticed that
>> there /is/ a form of splicing that runs during type checking, and
>> therefore has access to the type environment: namely typed splices,
>> which return a TExp rather than an Exp. Turns out the example from my
>> first email does work if you adapt it to use typed splices:
>> 
>> f :: Int -> Int
>> f x = $$(do let {name = mkName x}; info <- reify name; runIO (print
>> info) [|| x ||])
>> 
>> Running reify still doesn't work inside addModFinalizer, but at least
>> we do have access to x's type from within the typed splice, so we can
>> record it for use in the foreign code generation phase later.
>> 
>> The issue is, typed splices run afoul of the very same issue that
>> caused GHC HQ to move splice expansion out of the type checker and
>> into the renamer: namely that type inference becomes observable, as
>> documented here:
>> 
>> https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/BlogPostChanges
>> 
>> In particular,
>> 
>> f x = $$(... same splice as above...) `asTypeOf` True
>> 
>> yields a type error, while
>> 
>> f :: Bool -> Bool
>> f x = $$(... same splice as above...)
>> 
>> does not.
>> 
>> So let's discuss what the next actions are:
>> 
>> * Should we consider it a bug (and file a ticket) that reification in
>> typed splices is able to observe the order of type checking, just like
>> reify used to do in untyped splices?
>> * While Richard's proposed addGroupFinalizer might not work with
>> untyped splices, perhaps it can be made to work with typed splices,
>> since these run in the type checker?
>> * If part of the solution here is to use typed splices, how do we get
>> quasiquotation to be syntactic sugar for a *typed* splice? Do we want
>> to be introducing a typed quasiquotation syntax, just like Geoff did
>> for much of the rest of Template Haskell?
>> 
>> Facundo and I think that something like Richard's addGroupFinalizer is
>> still interesting to have, because while reification during type
>> checking sounds dubious, reification /after/ the declaration group is
>> fully type checked is perfectly safe.
>> 
>> Best,
>> --
>> Mathieu Boespflug
>> Founder at http://tweag.io.
>> 
>> 
>> On 13 April 2016 at 04:25, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>>> On Apr 12, 2016, at 5:35 PM, Facundo Dom?nguez <facundo.dominguez at tweag.io> wrote:
>>> 
>>>> Hello Richard,
>>>> 
>>>>> TH will offer a new function `addGroupFinalizer :: Q () -> Q ()` that runs its argument in the local typing environment available when addGroupFinalizer is called.
>>>> 
>>>> When considering this approach, how could one capture the local typing
>>>> environment given that the untyped splices are run in the renamer
>>>> where no such environment is populated yet?
>>>> 
>>> 
>>> Ah. Excellent point. I hadn't quite thought it through. Not sure, off the top of my head, how to get around this.
>>> 
>>> Richard
>>> 
> 


From mainland at drexel.edu  Wed Apr 13 20:37:33 2016
From: mainland at drexel.edu (Geoffrey Mainland)
Date: Wed, 13 Apr 2016 16:37:33 -0400
Subject: Reification of out-of-scope variables?
In-Reply-To: <9BF5E2D1-B54D-430C-A40F-164B5B46D3FF@cis.upenn.edu>
References: <CAJ0eudrYKW=+s25+G9x_3AQNJTU2Uqj18uZfbzZedF2p8oq=LQ@mail.gmail.com>
 <266BEB36-AA3D-4049-84F7-138C6FF7539A@cis.upenn.edu>
 <CA+Q==SDrdJBAKWt4ULwgYpPu0vHwz-WqSK4U1upTaA2DTtGPAQ@mail.gmail.com>
 <1DA2B8DB-1830-44A4-9564-F3B508771909@cis.upenn.edu>
 <CAJ0eudoNEa-dpSNwT1fhPxdQr6CpYvsuexVJNoxowoDu6KBahA@mail.gmail.com>
 <9BF5E2D1-B54D-430C-A40F-164B5B46D3FF@cis.upenn.edu>
Message-ID: <570EAE0D.9020406@drexel.edu>

I'm afraid I'm coming late to the game, so I'm not clear on the extent
of the problem (or even precisely what it is that isn't working).

In addition to creating a ticket, it would be great to have a wiki page
that outlines the problem and proposed solution(s).

The TH finalizer stuff was meant to make support for things like
language-c-inline easier, but it is incomplete. Before we go munging
around again, it would be good to have a list of use cases so we can
cover all the bases this time.

Geoff

On 04/13/2016 04:25 PM, Richard Eisenberg wrote:
> Very interesting.
>
> On Apr 13, 2016, at 5:09 AM, "Boespflug, Mathieu" <m at tweag.io> wrote:
>> * Should we consider it a bug (and file a ticket) that reification in
>> typed splices is able to observe the order of type checking, just like
>> reify used to do in untyped splices?
> I think so, yes.
>
>> * While Richard's proposed addGroupFinalizer might not work with
>> untyped splices, perhaps it can be made to work with typed splices,
>> since these run in the type checker?
> I think so, yes. Perhaps it would be more well-typed to have typed TH splices run in a new monad TQ such that TQ allows addGroupFinalizer but Q does not. This may be overkill though.
>
>> * If part of the solution here is to use typed splices, how do we get
>> quasiquotation to be syntactic sugar for a *typed* splice? Do we want
>> to be introducing a typed quasiquotation syntax, just like Geoff did
>> for much of the rest of Template Haskell?
> Maybe. Quasiquotation sugar is very light: [blah|...|] is the same as $(selector blah "...") where `selector` is the right record selector depending on the splice context. Is it worth trying to expand quasiquotation syntax to work with typed TH? I'm unconvinced it's worth the bother. Also, note that doing [blah||...||] is not backward-compatible, because that looks like an untyped quasiquote that begins and ends with a vertical bar. We could get around this problem by using a new extension, but the waters are just getting muddier, and for seemingly little benefit.
>
> Richard
>
>> Facundo and I think that something like Richard's addGroupFinalizer is
>> still interesting to have, because while reification during type
>> checking sounds dubious, reification /after/ the declaration group is
>> fully type checked is perfectly safe.
>>
>> Best,
>> --
>> Mathieu Boespflug
>> Founder at http://tweag.io.
>>
>>
>> On 13 April 2016 at 04:25, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>>> On Apr 12, 2016, at 5:35 PM, Facundo Dom?nguez <facundo.dominguez at tweag.io> wrote:
>>>
>>>> Hello Richard,
>>>>
>>>>> TH will offer a new function `addGroupFinalizer :: Q () -> Q ()` that runs its argument in the local typing environment available when addGroupFinalizer is called.
>>>> When considering this approach, how could one capture the local typing
>>>> environment given that the untyped splices are run in the renamer
>>>> where no such environment is populated yet?
>>>>
>>> Ah. Excellent point. I hadn't quite thought it through. Not sure, off the top of my head, how to get around this.
>>>
>>> Richard
>>>


From george.colpitts at gmail.com  Wed Apr 13 21:12:25 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Wed, 13 Apr 2016 21:12:25 +0000
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <CAEs96n24m9DAitZhZqKPu=mWidBuE1HU-V4jnjNUJgo+L+td8w@mail.gmail.com>
References: <87egadbj2w.fsf@smart-cactus.org>
 <CAB-d4A4gHuVSfZw_ci-2aooTQ4seuAzz1tU+wyyPznHh=Met=g@mail.gmail.com>
 <CAEs96n24m9DAitZhZqKPu=mWidBuE1HU-V4jnjNUJgo+L+td8w@mail.gmail.com>
Message-ID: <CAB-d4A71ECi4JBpfjDGJ0a-y2_qk=__47_01kTBbnwofP2QTMA@mail.gmail.com>

Thanks! with your response and Carter's I was able to get the doc to build!

On Wed, Apr 13, 2016 at 4:56 PM Austin Seipp <austin at well-typed.com> wrote:

> If you look at the bottom of the error, `fontspec` has already given
> you the more specific diagnosis of what's wrong:
>
> > The font "DejaVu Sans" cannot be found.
>
> That is, you need to install the DejaVu Sans font. Dealing with fonts
> and modern typesetting is a complete mystery to me though, so I'll
> leave you to install it on your Mac. :)
>
> On Wed, Apr 13, 2016 at 2:49 PM, George Colpitts
> <george.colpitts at gmail.com> wrote:
> > I got past my first problem (see
> > https://ghc.haskell.org/trac/ghc/ticket/11823#comment:13 for the
> resolution)
> > but now I have the following problem building the doc (on a Mac) .
> >
> > It seems like it doesn't like font names with spaces, not sure why (or
> if!)
> > this would be Mac specific:
> >
> >        Invalid fontname `DejaVu Sans', contains ' '
> >
> > longer extract from the output:
> >
> > copying static files... This is XeTeX, Version 3.14159265-2.6-0.99992
> (TeX
> > Live 2015) (preloaded format=xelatex)
> >  restricted \write18 enabled.
> > entering extended mode
> > (./users_guide.tex
> > LaTeX2e <2015/01/01>
> > Babel <3.9l> and hyphenation patterns for 79 languages loaded.
> > (./sphinxmanual.cls
> > Document Class: sphinxmanual 2009/06/02 Document class (Sphinx manual)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/base/report.cls
> > Document Class: report 2014/09/29 v1.4h Standard LaTeX document class
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/base/size10.clodone
> > copying extra files... done
> > dumping search index in English (code: en) ... )))
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/cmap/cmap.sty
> >
> > Package cmap Warning: pdftex not detected - exiting.
> >
> > )done
> > dumping object inventory...
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/base/fontenc.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/base/t1enc.defdone
> > build succeeded, 25 warnings.
> > ))
> > (/usr/local/texlive/2015/texmf-dist/tex/generic/babel/babel.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/generic/babel-english/english.ldf
> > (/usr/local/texlive/2015/texmf-dist/tex/generic/babel/babel.def
> > (/usr/local/texlive/2015/texmf-dist/tex/generic/babel/xebabel.def))))
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/psnfss/times.sty)
> > (./fncychap.sty
> > ) (/usr/local/texlive/2015/texmf-dist/tex/latex/tools/longtable.sty)
> > (./sphinx.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/base/textcomp.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/base/ts1enc.def))
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/fancybox/fancybox.sty
> > Style option: `fancybox' v1.4 <2010/05/15> (tvz)
> > ) (/usr/local/texlive/2015/texmf-dist/tex/latex/titlesec/titlesec.sty)
> > (./tabulary.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/tools/array.sty))
> >  (/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amsmath.sty
> > For additional information on amsmath, use the `?' option.
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amstext.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amsgen.sty))
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amsbsy.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amsopn.sty))
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/base/makeidx.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/framed/framed.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/base/ifthen.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/color.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/latexconfig/color.cfg)
> > (/usr/local/texlive/2015/texmf-dist/tex/xelatex/xetex-def/xetex.def))
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/fancyvrb/fancyvrb.sty
> > Style option: `fancyvrb' v2.7a, with DG/SPQR fixes, and
> firstline=lastline
> > fix
> > <2008/02/07> (tvz)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/keyval.sty))
> >
> (/usr/local/texlive/2015/texmf-dist/tex/latex/threeparttable/threeparttable.sty
> > ) (/usr/local/texlive/2015/texmf-dist/tex/latex/mdwtools/footnote.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/wrapfig/wrapfig.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/parskip/parskip.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/base/alltt.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/upquote/upquote.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/graphicx.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/graphics.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/trig.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/latexconfig/graphics.cfg)))
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/hyperref.sty
> >
> (/usr/local/texlive/2015/texmf-dist/tex/generic/oberdiek/hobsub-hyperref.sty
> >
> (/usr/local/texlive/2015/texmf-dist/tex/generic/oberdiek/hobsub-generic.sty))
> > (/usr/local/texlive/2015/texmf-dist/tex/generic/ifxetex/ifxetex.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/auxhook.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/kvoptions.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/pd1enc.def)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/latexconfig/hyperref.cfg)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/url/url.sty))
> >
> > Package hyperref Message: Driver (autodetected): hxetex.
> >
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/hxetex.def
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/puenc.def)
> > (/usr/local/texlive/2015/texmf-dist/tex/generic/oberdiek/stringenc.sty)
> >
> (/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/rerunfilecheck.sty))
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/hypcap.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/caption/newfloat.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/capt-of/capt-of.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/needspace/needspace.sty))
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/multirow/multirow.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/eqparbox/eqparbox.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/environ/environ.sty
> >
> (/usr/local/texlive/2015/texmf-dist/tex/latex/trimspaces/trimspaces.sty)))
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/expl3.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/expl3-code.tex)
> >
> (/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/l3unicode-data.def)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/l3xdvipdfmx.def))
> >
> (/usr/local/texlive/2015/texmf-dist/tex/latex/l3packages/xparse/xparse.sty)
> >
> (/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec-patches.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/base/fontenc.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/euenc/eu1enc.def)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/euenc/eu1lmr.fd))
> > (/usr/local/texlive/2015/texmf-dist/tex/xelatex/xunicode/xunicode.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/tipa/t3enc.def
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/euenc/eu1lmss.fd)))
> >
> (/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec.cfg)))kpathsea:make_tex:
> > .
> >
> >
> > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> > !
> > ! fontspec error: "font-not-found"
> > !
> > ! The font "DejaVu Sans" cannot be found.
> > !
> > ! See the fontspec documentation for further information.
> > !
> > ! For immediate help type H <return>.
> > !...............................................
> >
> > l.23 \setsansfont{DejaVu Sans}
> >
> > ?
> >
> > On Sun, Apr 10, 2016 at 12:05 PM Ben Gamari <ben at well-typed.com> wrote:
> >>
> >> tl;dr: If you would like to produce a binary distribution for GHC
> >>        8.0.1-rc3 then let us know, grab the source distribution and
> >>        start building. The binary distributions will be all released one
> >>        week from today.
> >>
> >>
> >> Hello GHC packagers,
> >>
> >> Austin and I are happy to announce the release of the 8.0.1-rc3 source
> >> distribution to binary packagers. You will find the tarball and usual
> >> assortment of signatures at
> >>
> >>     http://downloads.haskell.org/~ghc/8.0.1-rc3/
> >>
> >> This release is the first where we are following our new release policy
> >> [1], where a one-week delay will be introduced between the release of
> >> the source and binary distributions. The goal of this policy is to give
> >> all platforms the opportunity for support from the first day of a
> >> release.
> >>
> >> If all of the expected binary releases are submitted before the
> >> week-long delay is through, we can move forward with the release ahead
> >> of schedule. Given how late release candidate 3 is, we'd naturally like
> >> to get the binary releases out as soon is possible: The sooner we can
> >> get this -rc out the door the sooner we can get to the final release.
> >> Moreover, it would be appreciated if you could confirm that you intend
> >> to offer a binary distribution this release.
> >>
> >> Otherwise, let either Austin or I know if you have any trouble building
> >> your distribution. I have yet to push the 8.0.1-rc3 tag in case we
> >> encounter unexpected issues but all of my builds with this tarball
> >> thusfar have gone quite well.
> >>
> >> Good luck and thanks for all of your work!
> >>
> >> Cheers,
> >>
> >> - Ben
> >>
> >>
> >> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.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
> >
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160413/e440c4ac/attachment-0001.html>

From george.colpitts at gmail.com  Wed Apr 13 21:13:39 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Wed, 13 Apr 2016 21:13:39 +0000
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <CAHYVw0y87yAYHCp1J6q93eTimawTcwx3kUedaSA2OEmGeQZOdw@mail.gmail.com>
References: <87egadbj2w.fsf@smart-cactus.org>
 <CAB-d4A4gHuVSfZw_ci-2aooTQ4seuAzz1tU+wyyPznHh=Met=g@mail.gmail.com>
 <CAEs96n24m9DAitZhZqKPu=mWidBuE1HU-V4jnjNUJgo+L+td8w@mail.gmail.com>
 <CAHYVw0x4MP38qvir10zDLpodDdXXk2SiPS8miyUgd3pMFqP4YA@mail.gmail.com>
 <CAHYVw0y87yAYHCp1J6q93eTimawTcwx3kUedaSA2OEmGeQZOdw@mail.gmail.com>
Message-ID: <CAB-d4A7=oFOg-D_sNRhgeAehXynNDq73a+48j=z=xLxbMYLNrg@mail.gmail.com>

Thanks, with your response and Austin's I was able to get the doc to build

On Wed, Apr 13, 2016 at 5:11 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> Downloading the ttf font files and opening them via font book handles the
> import / font registry on Macs
> On Apr 13, 2016 3:56 PM, "Austin Seipp" <austin at well-typed.com> wrote:
>
> If you look at the bottom of the error, `fontspec` has already given
> you the more specific diagnosis of what's wrong:
>
> > The font "DejaVu Sans" cannot be found.
>
> That is, you need to install the DejaVu Sans font. Dealing with fonts
> and modern typesetting is a complete mystery to me though, so I'll
> leave you to install it on your Mac. :)
>
> On Wed, Apr 13, 2016 at 2:49 PM, George Colpitts
> <george.colpitts at gmail.com> wrote:
> > I got past my first problem (see
> > https://ghc.haskell.org/trac/ghc/ticket/11823#comment:13 for the
> resolution)
> > but now I have the following problem building the doc (on a Mac) .
> >
> > It seems like it doesn't like font names with spaces, not sure why (or
> if!)
> > this would be Mac specific:
> >
> >        Invalid fontname `DejaVu Sans', contains ' '
> >
> > longer extract from the output:
> >
> > copying static files... This is XeTeX, Version 3.14159265-2.6-0.99992
> (TeX
> > Live 2015) (preloaded format=xelatex)
> >  restricted \write18 enabled.
> > entering extended mode
> > (./users_guide.tex
> > LaTeX2e <2015/01/01>
> > Babel <3.9l> and hyphenation patterns for 79 languages loaded.
> > (./sphinxmanual.cls
> > Document Class: sphinxmanual 2009/06/02 Document class (Sphinx manual)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/base/report.cls
> > Document Class: report 2014/09/29 v1.4h Standard LaTeX document class
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/base/size10.clodone
> > copying extra files... done
> > dumping search index in English (code: en) ... )))
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/cmap/cmap.sty
> >
> > Package cmap Warning: pdftex not detected - exiting.
> >
> > )done
> > dumping object inventory...
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/base/fontenc.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/base/t1enc.defdone
> > build succeeded, 25 warnings.
> > ))
> > (/usr/local/texlive/2015/texmf-dist/tex/generic/babel/babel.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/generic/babel-english/english.ldf
> > (/usr/local/texlive/2015/texmf-dist/tex/generic/babel/babel.def
> > (/usr/local/texlive/2015/texmf-dist/tex/generic/babel/xebabel.def))))
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/psnfss/times.sty)
> > (./fncychap.sty
> > ) (/usr/local/texlive/2015/texmf-dist/tex/latex/tools/longtable.sty)
> > (./sphinx.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/base/textcomp.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/base/ts1enc.def))
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/fancybox/fancybox.sty
> > Style option: `fancybox' v1.4 <2010/05/15> (tvz)
> > ) (/usr/local/texlive/2015/texmf-dist/tex/latex/titlesec/titlesec.sty)
> > (./tabulary.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/tools/array.sty))
> >  (/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amsmath.sty
> > For additional information on amsmath, use the `?' option.
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amstext.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amsgen.sty))
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amsbsy.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/amsmath/amsopn.sty))
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/base/makeidx.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/framed/framed.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/base/ifthen.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/color.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/latexconfig/color.cfg)
> > (/usr/local/texlive/2015/texmf-dist/tex/xelatex/xetex-def/xetex.def))
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/fancyvrb/fancyvrb.sty
> > Style option: `fancyvrb' v2.7a, with DG/SPQR fixes, and
> firstline=lastline
> > fix
> > <2008/02/07> (tvz)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/keyval.sty))
> >
> (/usr/local/texlive/2015/texmf-dist/tex/latex/threeparttable/threeparttable.sty
> > ) (/usr/local/texlive/2015/texmf-dist/tex/latex/mdwtools/footnote.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/wrapfig/wrapfig.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/parskip/parskip.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/base/alltt.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/upquote/upquote.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/graphicx.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/graphics.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/graphics/trig.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/latexconfig/graphics.cfg)))
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/hyperref.sty
> >
> (/usr/local/texlive/2015/texmf-dist/tex/generic/oberdiek/hobsub-hyperref.sty
> >
> (/usr/local/texlive/2015/texmf-dist/tex/generic/oberdiek/hobsub-generic.sty))
> > (/usr/local/texlive/2015/texmf-dist/tex/generic/ifxetex/ifxetex.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/auxhook.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/kvoptions.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/pd1enc.def)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/latexconfig/hyperref.cfg)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/url/url.sty))
> >
> > Package hyperref Message: Driver (autodetected): hxetex.
> >
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/hxetex.def
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/hyperref/puenc.def)
> > (/usr/local/texlive/2015/texmf-dist/tex/generic/oberdiek/stringenc.sty)
> >
> (/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/rerunfilecheck.sty))
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/oberdiek/hypcap.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/caption/newfloat.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/capt-of/capt-of.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/needspace/needspace.sty))
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/multirow/multirow.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/eqparbox/eqparbox.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/environ/environ.sty
> >
> (/usr/local/texlive/2015/texmf-dist/tex/latex/trimspaces/trimspaces.sty)))
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/expl3.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/expl3-code.tex)
> >
> (/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/l3unicode-data.def)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/l3kernel/l3xdvipdfmx.def))
> >
> (/usr/local/texlive/2015/texmf-dist/tex/latex/l3packages/xparse/xparse.sty)
> >
> (/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec-patches.sty)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/base/fontenc.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/euenc/eu1enc.def)
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/euenc/eu1lmr.fd))
> > (/usr/local/texlive/2015/texmf-dist/tex/xelatex/xunicode/xunicode.sty
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/tipa/t3enc.def
> > (/usr/local/texlive/2015/texmf-dist/tex/latex/euenc/eu1lmss.fd)))
> >
> (/usr/local/texlive/2015/texmf-dist/tex/latex/fontspec/fontspec.cfg)))kpathsea:make_tex:
> > .
> >
> >
> > !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> > !
> > ! fontspec error: "font-not-found"
> > !
> > ! The font "DejaVu Sans" cannot be found.
> > !
> > ! See the fontspec documentation for further information.
> > !
> > ! For immediate help type H <return>.
> > !...............................................
> >
> > l.23 \setsansfont{DejaVu Sans}
> >
> > ?
> >
> > On Sun, Apr 10, 2016 at 12:05 PM Ben Gamari <ben at well-typed.com> wrote:
> >>
> >> tl;dr: If you would like to produce a binary distribution for GHC
> >>        8.0.1-rc3 then let us know, grab the source distribution and
> >>        start building. The binary distributions will be all released one
> >>        week from today.
> >>
> >>
> >> Hello GHC packagers,
> >>
> >> Austin and I are happy to announce the release of the 8.0.1-rc3 source
> >> distribution to binary packagers. You will find the tarball and usual
> >> assortment of signatures at
> >>
> >>     http://downloads.haskell.org/~ghc/8.0.1-rc3/
> >>
> >> This release is the first where we are following our new release policy
> >> [1], where a one-week delay will be introduced between the release of
> >> the source and binary distributions. The goal of this policy is to give
> >> all platforms the opportunity for support from the first day of a
> >> release.
> >>
> >> If all of the expected binary releases are submitted before the
> >> week-long delay is through, we can move forward with the release ahead
> >> of schedule. Given how late release candidate 3 is, we'd naturally like
> >> to get the binary releases out as soon is possible: The sooner we can
> >> get this -rc out the door the sooner we can get to the final release.
> >> Moreover, it would be appreciated if you could confirm that you intend
> >> to offer a binary distribution this release.
> >>
> >> Otherwise, let either Austin or I know if you have any trouble building
> >> your distribution. I have yet to push the 8.0.1-rc3 tag in case we
> >> encounter unexpected issues but all of my builds with this tarball
> >> thusfar have gone quite well.
> >>
> >> Good luck and thanks for all of your work!
> >>
> >> Cheers,
> >>
> >> - Ben
> >>
> >>
> >> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.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
> >
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> 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/20160413/32f3c0be/attachment.html>

From facundo.dominguez at tweag.io  Wed Apr 13 23:34:08 2016
From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=)
Date: Wed, 13 Apr 2016 20:34:08 -0300
Subject: Reification of out-of-scope variables?
In-Reply-To: <570EAE0D.9020406@drexel.edu>
References: <CAJ0eudrYKW=+s25+G9x_3AQNJTU2Uqj18uZfbzZedF2p8oq=LQ@mail.gmail.com>
 <266BEB36-AA3D-4049-84F7-138C6FF7539A@cis.upenn.edu>
 <CA+Q==SDrdJBAKWt4ULwgYpPu0vHwz-WqSK4U1upTaA2DTtGPAQ@mail.gmail.com>
 <1DA2B8DB-1830-44A4-9564-F3B508771909@cis.upenn.edu>
 <CAJ0eudoNEa-dpSNwT1fhPxdQr6CpYvsuexVJNoxowoDu6KBahA@mail.gmail.com>
 <9BF5E2D1-B54D-430C-A40F-164B5B46D3FF@cis.upenn.edu>
 <570EAE0D.9020406@drexel.edu>
Message-ID: <CA+Q==SAZg-PaF5kUG-AoHfxdROAjyGPNQjbZJZpU44fuVea0iw@mail.gmail.com>

Here is the wiki page [1] and here is the ticket [2]

Best

[1] https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Reify
[2] https://ghc.haskell.org/trac/ghc/ticket/11832

On Wed, Apr 13, 2016 at 5:37 PM, Geoffrey Mainland <mainland at drexel.edu> wrote:
> I'm afraid I'm coming late to the game, so I'm not clear on the extent
> of the problem (or even precisely what it is that isn't working).
>
> In addition to creating a ticket, it would be great to have a wiki page
> that outlines the problem and proposed solution(s).
>
> The TH finalizer stuff was meant to make support for things like
> language-c-inline easier, but it is incomplete. Before we go munging
> around again, it would be good to have a list of use cases so we can
> cover all the bases this time.
>
> Geoff
>
> On 04/13/2016 04:25 PM, Richard Eisenberg wrote:
>> Very interesting.
>>
>> On Apr 13, 2016, at 5:09 AM, "Boespflug, Mathieu" <m at tweag.io> wrote:
>>> * Should we consider it a bug (and file a ticket) that reification in
>>> typed splices is able to observe the order of type checking, just like
>>> reify used to do in untyped splices?
>> I think so, yes.
>>
>>> * While Richard's proposed addGroupFinalizer might not work with
>>> untyped splices, perhaps it can be made to work with typed splices,
>>> since these run in the type checker?
>> I think so, yes. Perhaps it would be more well-typed to have typed TH splices run in a new monad TQ such that TQ allows addGroupFinalizer but Q does not. This may be overkill though.
>>
>>> * If part of the solution here is to use typed splices, how do we get
>>> quasiquotation to be syntactic sugar for a *typed* splice? Do we want
>>> to be introducing a typed quasiquotation syntax, just like Geoff did
>>> for much of the rest of Template Haskell?
>> Maybe. Quasiquotation sugar is very light: [blah|...|] is the same as $(selector blah "...") where `selector` is the right record selector depending on the splice context. Is it worth trying to expand quasiquotation syntax to work with typed TH? I'm unconvinced it's worth the bother. Also, note that doing [blah||...||] is not backward-compatible, because that looks like an untyped quasiquote that begins and ends with a vertical bar. We could get around this problem by using a new extension, but the waters are just getting muddier, and for seemingly little benefit.
>>
>> Richard
>>
>>> Facundo and I think that something like Richard's addGroupFinalizer is
>>> still interesting to have, because while reification during type
>>> checking sounds dubious, reification /after/ the declaration group is
>>> fully type checked is perfectly safe.
>>>
>>> Best,
>>> --
>>> Mathieu Boespflug
>>> Founder at http://tweag.io.
>>>
>>>
>>> On 13 April 2016 at 04:25, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>>>> On Apr 12, 2016, at 5:35 PM, Facundo Dom?nguez <facundo.dominguez at tweag.io> wrote:
>>>>
>>>>> Hello Richard,
>>>>>
>>>>>> TH will offer a new function `addGroupFinalizer :: Q () -> Q ()` that runs its argument in the local typing environment available when addGroupFinalizer is called.
>>>>> When considering this approach, how could one capture the local typing
>>>>> environment given that the untyped splices are run in the renamer
>>>>> where no such environment is populated yet?
>>>>>
>>>> Ah. Excellent point. I hadn't quite thought it through. Not sure, off the top of my head, how to get around this.
>>>>
>>>> Richard
>>>>
>

From mainland at drexel.edu  Wed Apr 13 23:47:25 2016
From: mainland at drexel.edu (Geoffrey Mainland)
Date: Wed, 13 Apr 2016 19:47:25 -0400
Subject: Reification of out-of-scope variables?
In-Reply-To: <CA+Q==SAZg-PaF5kUG-AoHfxdROAjyGPNQjbZJZpU44fuVea0iw@mail.gmail.com>
References: <CAJ0eudrYKW=+s25+G9x_3AQNJTU2Uqj18uZfbzZedF2p8oq=LQ@mail.gmail.com>
 <266BEB36-AA3D-4049-84F7-138C6FF7539A@cis.upenn.edu>
 <CA+Q==SDrdJBAKWt4ULwgYpPu0vHwz-WqSK4U1upTaA2DTtGPAQ@mail.gmail.com>
 <1DA2B8DB-1830-44A4-9564-F3B508771909@cis.upenn.edu>
 <CAJ0eudoNEa-dpSNwT1fhPxdQr6CpYvsuexVJNoxowoDu6KBahA@mail.gmail.com>
 <9BF5E2D1-B54D-430C-A40F-164B5B46D3FF@cis.upenn.edu>
 <570EAE0D.9020406@drexel.edu>
 <CA+Q==SAZg-PaF5kUG-AoHfxdROAjyGPNQjbZJZpU44fuVea0iw@mail.gmail.com>
Message-ID: <570EDA8D.3050901@drexel.edu>

Wow, thanks!

Geoff

On 04/13/2016 07:34 PM, Facundo Dom?nguez wrote:
> Here is the wiki page [1] and here is the ticket [2]
>
> Best
>
> [1] https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Reify
> [2] https://ghc.haskell.org/trac/ghc/ticket/11832
>
> On Wed, Apr 13, 2016 at 5:37 PM, Geoffrey Mainland <mainland at drexel.edu> wrote:
>> I'm afraid I'm coming late to the game, so I'm not clear on the extent
>> of the problem (or even precisely what it is that isn't working).
>>
>> In addition to creating a ticket, it would be great to have a wiki page
>> that outlines the problem and proposed solution(s).
>>
>> The TH finalizer stuff was meant to make support for things like
>> language-c-inline easier, but it is incomplete. Before we go munging
>> around again, it would be good to have a list of use cases so we can
>> cover all the bases this time.
>>
>> Geoff
>>
>> On 04/13/2016 04:25 PM, Richard Eisenberg wrote:
>>> Very interesting.
>>>
>>> On Apr 13, 2016, at 5:09 AM, "Boespflug, Mathieu" <m at tweag.io> wrote:
>>>> * Should we consider it a bug (and file a ticket) that reification in
>>>> typed splices is able to observe the order of type checking, just like
>>>> reify used to do in untyped splices?
>>> I think so, yes.
>>>
>>>> * While Richard's proposed addGroupFinalizer might not work with
>>>> untyped splices, perhaps it can be made to work with typed splices,
>>>> since these run in the type checker?
>>> I think so, yes. Perhaps it would be more well-typed to have typed TH splices run in a new monad TQ such that TQ allows addGroupFinalizer but Q does not. This may be overkill though.
>>>
>>>> * If part of the solution here is to use typed splices, how do we get
>>>> quasiquotation to be syntactic sugar for a *typed* splice? Do we want
>>>> to be introducing a typed quasiquotation syntax, just like Geoff did
>>>> for much of the rest of Template Haskell?
>>> Maybe. Quasiquotation sugar is very light: [blah|...|] is the same as $(selector blah "...") where `selector` is the right record selector depending on the splice context. Is it worth trying to expand quasiquotation syntax to work with typed TH? I'm unconvinced it's worth the bother. Also, note that doing [blah||...||] is not backward-compatible, because that looks like an untyped quasiquote that begins and ends with a vertical bar. We could get around this problem by using a new extension, but the waters are just getting muddier, and for seemingly little benefit.
>>>
>>> Richard
>>>
>>>> Facundo and I think that something like Richard's addGroupFinalizer is
>>>> still interesting to have, because while reification during type
>>>> checking sounds dubious, reification /after/ the declaration group is
>>>> fully type checked is perfectly safe.
>>>>
>>>> Best,
>>>> --
>>>> Mathieu Boespflug
>>>> Founder at http://tweag.io.
>>>>
>>>>
>>>> On 13 April 2016 at 04:25, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>>>>> On Apr 12, 2016, at 5:35 PM, Facundo Dom?nguez <facundo.dominguez at tweag.io> wrote:
>>>>>
>>>>>> Hello Richard,
>>>>>>
>>>>>>> TH will offer a new function `addGroupFinalizer :: Q () -> Q ()` that runs its argument in the local typing environment available when addGroupFinalizer is called.
>>>>>> When considering this approach, how could one capture the local typing
>>>>>> environment given that the untyped splices are run in the renamer
>>>>>> where no such environment is populated yet?
>>>>>>
>>>>> Ah. Excellent point. I hadn't quite thought it through. Not sure, off the top of my head, how to get around this.
>>>>>
>>>>> Richard
>>>>>


From ryan.trinkle at gmail.com  Thu Apr 14 00:28:47 2016
From: ryan.trinkle at gmail.com (Ryan Trinkle)
Date: Wed, 13 Apr 2016 20:28:47 -0400
Subject: Waiting for finalizers to run; exposing Capability internals
Message-ID: <CAHNEpix5t5JXgsXA5Zkvj94vnqLxuFEnS38c3eL9duK9pPvqNA@mail.gmail.com>

Hi everyone,

I'm attempting to create benchmarks that include the cost of finalizers
that the code creates.  To do this, I'm running the test, running
performGC, and then waiting for finalizers to finish.  However, that last
part is a bit of a beast.  I'm trying to determine if I can make an
improvement to GHC that will better support this.

Currently, to wait for finalizers to finish, I do the following:
  * Run with -N1
  * Ensure (i.e., hope) that no finalizers in the program ever block
  * Repeatedly check whether rts_unsafeGetMyCapability()->run_queue_hd ==
END_TSO_QUEUE.  If it does not, yield; if it does, terminate the program.

In my testing, this appears to work.  However, since the Capability_ struct
is not available in the rts headers provided by GHC, I was only able to
achieve this by pasting the relevant headers into my project.  I don't
expect this kind of functionality to be very forwards compatible, but
copy/paste is a level of hackery that I'd prefer to avoid.

I'm not very experienced with GHC or RTS development, but I'd like to
contribute something that would help make this code more maintainable.  A
couple of things come to mind:

   - I could add a function that does the exact check I need
   (rts_unsafeGetMyCapability()->run_queue_hd == END_TSO_QUEUE) and expose it
   to userspace.  This is probably the simplest approach, and would certainly
   be the easiest for me, but it also strikes me as a fairly inelegant
   addition to the RTS API.
   - I could expose the private header files, rts/*.h, as <rts/private/*.h>
   to userspace C files.  This seems like a generally useful approach, but I
   would want to ensure that it did not create maintenance headaches for
   anyone.

I'm also very open to other suggestions.

Thanks for reading, and I look forward to hearing your input.


Regards,
Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160413/bade1827/attachment.html>

From facundo.dominguez at tweag.io  Thu Apr 14 01:15:44 2016
From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=)
Date: Wed, 13 Apr 2016 22:15:44 -0300
Subject: Reification of out-of-scope variables?
In-Reply-To: <CA+Q==SAZg-PaF5kUG-AoHfxdROAjyGPNQjbZJZpU44fuVea0iw@mail.gmail.com>
References: <CAJ0eudrYKW=+s25+G9x_3AQNJTU2Uqj18uZfbzZedF2p8oq=LQ@mail.gmail.com>
 <266BEB36-AA3D-4049-84F7-138C6FF7539A@cis.upenn.edu>
 <CA+Q==SDrdJBAKWt4ULwgYpPu0vHwz-WqSK4U1upTaA2DTtGPAQ@mail.gmail.com>
 <1DA2B8DB-1830-44A4-9564-F3B508771909@cis.upenn.edu>
 <CAJ0eudoNEa-dpSNwT1fhPxdQr6CpYvsuexVJNoxowoDu6KBahA@mail.gmail.com>
 <9BF5E2D1-B54D-430C-A40F-164B5B46D3FF@cis.upenn.edu>
 <570EAE0D.9020406@drexel.edu>
 <CA+Q==SAZg-PaF5kUG-AoHfxdROAjyGPNQjbZJZpU44fuVea0iw@mail.gmail.com>
Message-ID: <CA+Q==SDK3dGVSC1j+E34XoZ-kuQs0Y9BmpSWa=XWsagcBP-PLQ@mail.gmail.com>

Michael,
  Please, feel free to add your thoughts to the wiki. I couldn't
follow your proposal in enough detail to make it justice.

Facundo

On Wed, Apr 13, 2016 at 8:34 PM, Facundo Dom?nguez
<facundo.dominguez at tweag.io> wrote:
> Here is the wiki page [1] and here is the ticket [2]
>
> Best
>
> [1] https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Reify
> [2] https://ghc.haskell.org/trac/ghc/ticket/11832
>
> On Wed, Apr 13, 2016 at 5:37 PM, Geoffrey Mainland <mainland at drexel.edu> wrote:
>> I'm afraid I'm coming late to the game, so I'm not clear on the extent
>> of the problem (or even precisely what it is that isn't working).
>>
>> In addition to creating a ticket, it would be great to have a wiki page
>> that outlines the problem and proposed solution(s).
>>
>> The TH finalizer stuff was meant to make support for things like
>> language-c-inline easier, but it is incomplete. Before we go munging
>> around again, it would be good to have a list of use cases so we can
>> cover all the bases this time.
>>
>> Geoff
>>
>> On 04/13/2016 04:25 PM, Richard Eisenberg wrote:
>>> Very interesting.
>>>
>>> On Apr 13, 2016, at 5:09 AM, "Boespflug, Mathieu" <m at tweag.io> wrote:
>>>> * Should we consider it a bug (and file a ticket) that reification in
>>>> typed splices is able to observe the order of type checking, just like
>>>> reify used to do in untyped splices?
>>> I think so, yes.
>>>
>>>> * While Richard's proposed addGroupFinalizer might not work with
>>>> untyped splices, perhaps it can be made to work with typed splices,
>>>> since these run in the type checker?
>>> I think so, yes. Perhaps it would be more well-typed to have typed TH splices run in a new monad TQ such that TQ allows addGroupFinalizer but Q does not. This may be overkill though.
>>>
>>>> * If part of the solution here is to use typed splices, how do we get
>>>> quasiquotation to be syntactic sugar for a *typed* splice? Do we want
>>>> to be introducing a typed quasiquotation syntax, just like Geoff did
>>>> for much of the rest of Template Haskell?
>>> Maybe. Quasiquotation sugar is very light: [blah|...|] is the same as $(selector blah "...") where `selector` is the right record selector depending on the splice context. Is it worth trying to expand quasiquotation syntax to work with typed TH? I'm unconvinced it's worth the bother. Also, note that doing [blah||...||] is not backward-compatible, because that looks like an untyped quasiquote that begins and ends with a vertical bar. We could get around this problem by using a new extension, but the waters are just getting muddier, and for seemingly little benefit.
>>>
>>> Richard
>>>
>>>> Facundo and I think that something like Richard's addGroupFinalizer is
>>>> still interesting to have, because while reification during type
>>>> checking sounds dubious, reification /after/ the declaration group is
>>>> fully type checked is perfectly safe.
>>>>
>>>> Best,
>>>> --
>>>> Mathieu Boespflug
>>>> Founder at http://tweag.io.
>>>>
>>>>
>>>> On 13 April 2016 at 04:25, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>>>>> On Apr 12, 2016, at 5:35 PM, Facundo Dom?nguez <facundo.dominguez at tweag.io> wrote:
>>>>>
>>>>>> Hello Richard,
>>>>>>
>>>>>>> TH will offer a new function `addGroupFinalizer :: Q () -> Q ()` that runs its argument in the local typing environment available when addGroupFinalizer is called.
>>>>>> When considering this approach, how could one capture the local typing
>>>>>> environment given that the untyped splices are run in the renamer
>>>>>> where no such environment is populated yet?
>>>>>>
>>>>> Ah. Excellent point. I hadn't quite thought it through. Not sure, off the top of my head, how to get around this.
>>>>>
>>>>> Richard
>>>>>
>>

From rf at rufflewind.com  Thu Apr 14 11:15:19 2016
From: rf at rufflewind.com (rf at rufflewind.com)
Date: Thu, 14 Apr 2016 07:15:19 -0400
Subject: directory and GHC 8.0.1
In-Reply-To: <877fg94xtq.fsf@smart-cactus.org>
References: <87d1q24j0g.fsf@smart-cactus.org>
 <1459976919.2379569.571159985.696D36D2@webmail.messagingengine.com>
 <87a8l64bzd.fsf@smart-cactus.org>
 <1460000148.3221856.571408153.7456C7C7@webmail.messagingengine.com>
 <877fg94xtq.fsf@smart-cactus.org>
Message-ID: <1460632519.1473955.578559009.58BCE9FF@webmail.messagingengine.com>

Alright, directory-1.2.6.0 has been pushed to master (74e5058) and I've
added a note to indicate that it is bundled with GHC 8.0.1.  Looks good?

Thanks,
RF

From iavor.diatchki at gmail.com  Thu Apr 14 17:42:36 2016
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 14 Apr 2016 10:42:36 -0700
Subject: GHC 8 and Template Haskell
Message-ID: <CAGK9nuoz8Nhq2mVpGGm+miKMTRLnHVRwUeS7E+y7bJmaAVJhLg@mail.gmail.com>

Hello,

Now that "OVERLAPPING" and "OVERLAPPABLE" are pragmas on the instances, do
we have a way to generate instances with such pragmas using Template
Haskell?   I can't seem to find a way to do this, which is unfortunate.

If I am not missing anything, would there be objections to adding it to the
TH library before the next release---I would volunteer to do the change
ASAP.

Let me know,

-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160414/6fbf79b8/attachment.html>

From ben at well-typed.com  Thu Apr 14 18:12:34 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 14 Apr 2016 20:12:34 +0200
Subject: GHC 8 and Template Haskell
In-Reply-To: <CAGK9nuoz8Nhq2mVpGGm+miKMTRLnHVRwUeS7E+y7bJmaAVJhLg@mail.gmail.com>
References: <CAGK9nuoz8Nhq2mVpGGm+miKMTRLnHVRwUeS7E+y7bJmaAVJhLg@mail.gmail.com>
Message-ID: <87potsxdnx.fsf@smart-cactus.org>

Iavor Diatchki <iavor.diatchki at gmail.com> writes:

> Hello,
>
> Now that "OVERLAPPING" and "OVERLAPPABLE" are pragmas on the instances, do
> we have a way to generate instances with such pragmas using Template
> Haskell?   I can't seem to find a way to do this, which is unfortunate.
>
> If I am not missing anything, would there be objections to adding it to the
> TH library before the next release---I would volunteer to do the change
> ASAP.
>
Indeed this is an unfortunate gap. Given that this shouldn't be a
terribly invasive change I would be alright with this if Richard approves.

Cheers,

- Ben

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

From austin at well-typed.com  Thu Apr 14 18:17:46 2016
From: austin at well-typed.com (Austin Seipp)
Date: Thu, 14 Apr 2016 13:17:46 -0500
Subject: GHC 8 and Template Haskell
In-Reply-To: <87potsxdnx.fsf@smart-cactus.org>
References: <CAGK9nuoz8Nhq2mVpGGm+miKMTRLnHVRwUeS7E+y7bJmaAVJhLg@mail.gmail.com>
 <87potsxdnx.fsf@smart-cactus.org>
Message-ID: <CAEs96n1kh56VTsZY-eiKLVwaRfrqu8M+qPSmzhjOjQjK2ihf-g@mail.gmail.com>

Here's a question, on top of this one: why don't we require
template-haskell changes for most corresponding syntax changes? We
tend to play catch up with template-haskell sometimes and it's
relatively strange. I mean, in some sense, we could have said a while
back "This needs another revision, please add template haskell
support" and avoided it all.

Richard has a better insight into this than I do, I'm sure, but it
seems - to me, anyway - like template-haskell support is a reasonable
bar for most surface-level syntax change to cross, before getting
merged.

My intuition tells me that, most of the time, a lot of us simply
forget to make the changes, or ask for them in reviews, and so it
goes.

On Thu, Apr 14, 2016 at 1:12 PM, Ben Gamari <ben at well-typed.com> wrote:
> Iavor Diatchki <iavor.diatchki at gmail.com> writes:
>
>> Hello,
>>
>> Now that "OVERLAPPING" and "OVERLAPPABLE" are pragmas on the instances, do
>> we have a way to generate instances with such pragmas using Template
>> Haskell?   I can't seem to find a way to do this, which is unfortunate.
>>
>> If I am not missing anything, would there be objections to adding it to the
>> TH library before the next release---I would volunteer to do the change
>> ASAP.
>>
> Indeed this is an unfortunate gap. Given that this shouldn't be a
> terribly invasive change I would be alright with this if Richard approves.
>
> Cheers,
>
> - Ben
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>



-- 
Regards,

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

From eir at cis.upenn.edu  Thu Apr 14 20:59:16 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Thu, 14 Apr 2016 16:59:16 -0400
Subject: GHC 8 and Template Haskell
In-Reply-To: <CAEs96n1kh56VTsZY-eiKLVwaRfrqu8M+qPSmzhjOjQjK2ihf-g@mail.gmail.com>
References: <CAGK9nuoz8Nhq2mVpGGm+miKMTRLnHVRwUeS7E+y7bJmaAVJhLg@mail.gmail.com>
 <87potsxdnx.fsf@smart-cactus.org>
 <CAEs96n1kh56VTsZY-eiKLVwaRfrqu8M+qPSmzhjOjQjK2ihf-g@mail.gmail.com>
Message-ID: <F44273AB-78CE-47D9-AFBC-AB66AF6BDECB@cis.upenn.edu>

I'm happy to be overruled on this, but I vote against this change for GHC 8. Personally, I like to have a policy of "no TH changes after the first RC". This gives ample time for TH clients to update their code. Iavor's suggestion would likely involve a new part of the InstanceD constructor, which would affect anyone constructing or matching on this constructor. If the change involved, say, only adding new functionality without changing anything existing, I would be more willing to include for GHC 8.

And, yes, I agree with Austin.

Richard

On Apr 14, 2016, at 2:17 PM, Austin Seipp <austin at well-typed.com> wrote:

> Here's a question, on top of this one: why don't we require
> template-haskell changes for most corresponding syntax changes? We
> tend to play catch up with template-haskell sometimes and it's
> relatively strange. I mean, in some sense, we could have said a while
> back "This needs another revision, please add template haskell
> support" and avoided it all.
> 
> Richard has a better insight into this than I do, I'm sure, but it
> seems - to me, anyway - like template-haskell support is a reasonable
> bar for most surface-level syntax change to cross, before getting
> merged.
> 
> My intuition tells me that, most of the time, a lot of us simply
> forget to make the changes, or ask for them in reviews, and so it
> goes.
> 
> On Thu, Apr 14, 2016 at 1:12 PM, Ben Gamari <ben at well-typed.com> wrote:
>> Iavor Diatchki <iavor.diatchki at gmail.com> writes:
>> 
>>> Hello,
>>> 
>>> Now that "OVERLAPPING" and "OVERLAPPABLE" are pragmas on the instances, do
>>> we have a way to generate instances with such pragmas using Template
>>> Haskell?   I can't seem to find a way to do this, which is unfortunate.
>>> 
>>> If I am not missing anything, would there be objections to adding it to the
>>> TH library before the next release---I would volunteer to do the change
>>> ASAP.
>>> 
>> Indeed this is an unfortunate gap. Given that this shouldn't be a
>> terribly invasive change I would be alright with this if Richard approves.
>> 
>> Cheers,
>> 
>> - Ben
>> 
>> 
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> 
> 
> 
> 
> -- 
> Regards,
> 
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/


From iavor.diatchki at gmail.com  Thu Apr 14 21:11:26 2016
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 14 Apr 2016 14:11:26 -0700
Subject: GHC 8 and Template Haskell
In-Reply-To: <F44273AB-78CE-47D9-AFBC-AB66AF6BDECB@cis.upenn.edu>
References: <CAGK9nuoz8Nhq2mVpGGm+miKMTRLnHVRwUeS7E+y7bJmaAVJhLg@mail.gmail.com>
 <87potsxdnx.fsf@smart-cactus.org>
 <CAEs96n1kh56VTsZY-eiKLVwaRfrqu8M+qPSmzhjOjQjK2ihf-g@mail.gmail.com>
 <F44273AB-78CE-47D9-AFBC-AB66AF6BDECB@cis.upenn.edu>
Message-ID: <CAGK9nupmPZ=LOHJt3iTgXh6dQXetx4jkKpzcWBYz+G2BgTiL1w@mail.gmail.com>

Hi,

objection!  :-)

If we were to delay things, we would ship a version of the library that has
missing functionality *and* we'll break everyone's code on the next
release.   If we make the change now, then at least when people fix their
TH code to work with GHC 8, they'd be getting access to more functionality.

This change does indeed change the data structure for declarations, so if
you were working with it directly, indeed you'll have to make changes.
However, if you use the "smart" constructors in TH, you shouldn't need to
change anything.
In particular, I left `instanceD` as before---it does not add any
overlapping pragmas, and I added a new function `instanceWithOverlapD`,
which has an extra parameter that allows you to specify pragmas.

I'd like to get this in, if possible, as I have a library that needs this
feature.  My current work-around it quite ugly:  ask the clients of the
library to enable "Language OverlappingInstaces", which is cumbersome,
*and* generates deprecation warnings.

-Iavor






On Thu, Apr 14, 2016 at 1:59 PM, Richard Eisenberg <eir at cis.upenn.edu>
wrote:

> I'm happy to be overruled on this, but I vote against this change for GHC
> 8. Personally, I like to have a policy of "no TH changes after the first
> RC". This gives ample time for TH clients to update their code. Iavor's
> suggestion would likely involve a new part of the InstanceD constructor,
> which would affect anyone constructing or matching on this constructor. If
> the change involved, say, only adding new functionality without changing
> anything existing, I would be more willing to include for GHC 8.
>
> And, yes, I agree with Austin.
>
> Richard
>
> On Apr 14, 2016, at 2:17 PM, Austin Seipp <austin at well-typed.com> wrote:
>
> > Here's a question, on top of this one: why don't we require
> > template-haskell changes for most corresponding syntax changes? We
> > tend to play catch up with template-haskell sometimes and it's
> > relatively strange. I mean, in some sense, we could have said a while
> > back "This needs another revision, please add template haskell
> > support" and avoided it all.
> >
> > Richard has a better insight into this than I do, I'm sure, but it
> > seems - to me, anyway - like template-haskell support is a reasonable
> > bar for most surface-level syntax change to cross, before getting
> > merged.
> >
> > My intuition tells me that, most of the time, a lot of us simply
> > forget to make the changes, or ask for them in reviews, and so it
> > goes.
> >
> > On Thu, Apr 14, 2016 at 1:12 PM, Ben Gamari <ben at well-typed.com> wrote:
> >> Iavor Diatchki <iavor.diatchki at gmail.com> writes:
> >>
> >>> Hello,
> >>>
> >>> Now that "OVERLAPPING" and "OVERLAPPABLE" are pragmas on the
> instances, do
> >>> we have a way to generate instances with such pragmas using Template
> >>> Haskell?   I can't seem to find a way to do this, which is unfortunate.
> >>>
> >>> If I am not missing anything, would there be objections to adding it
> to the
> >>> TH library before the next release---I would volunteer to do the change
> >>> ASAP.
> >>>
> >> Indeed this is an unfortunate gap. Given that this shouldn't be a
> >> terribly invasive change I would be alright with this if Richard
> approves.
> >>
> >> Cheers,
> >>
> >> - Ben
> >>
> >>
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >>
> >
> >
> >
> > --
> > Regards,
> >
> > Austin Seipp, Haskell Consultant
> > Well-Typed LLP, http://www.well-typed.com/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160414/3cb64255/attachment.html>

From eric at seidel.io  Thu Apr 14 21:31:53 2016
From: eric at seidel.io (Eric Seidel)
Date: Thu, 14 Apr 2016 14:31:53 -0700
Subject: GHC 8 and Template Haskell
In-Reply-To: <F44273AB-78CE-47D9-AFBC-AB66AF6BDECB@cis.upenn.edu>
References: <CAGK9nuoz8Nhq2mVpGGm+miKMTRLnHVRwUeS7E+y7bJmaAVJhLg@mail.gmail.com>
 <87potsxdnx.fsf@smart-cactus.org>
 <CAEs96n1kh56VTsZY-eiKLVwaRfrqu8M+qPSmzhjOjQjK2ihf-g@mail.gmail.com>
 <F44273AB-78CE-47D9-AFBC-AB66AF6BDECB@cis.upenn.edu>
Message-ID: <1460669513.1427652.579171513.0542E391@webmail.messagingengine.com>

I think a general "no TH changes after the first RC" seems reasonable as
part of the broader feature freeze. 

But this case seems decidedly more of a bug fix than a feature addition,
since TH *should* have feature parity with Haskell syntax. So I'd favor
merging Iavor's patch.

I also like Austin's suggestion that we require template-haskell patches
alongside new syntax.

Eric

On Thu, Apr 14, 2016, at 13:59, Richard Eisenberg wrote:
> I'm happy to be overruled on this, but I vote against this change for GHC
> 8. Personally, I like to have a policy of "no TH changes after the first
> RC". This gives ample time for TH clients to update their code. Iavor's
> suggestion would likely involve a new part of the InstanceD constructor,
> which would affect anyone constructing or matching on this constructor.
> If the change involved, say, only adding new functionality without
> changing anything existing, I would be more willing to include for GHC 8.
> 
> And, yes, I agree with Austin.
> 
> Richard
> 
> On Apr 14, 2016, at 2:17 PM, Austin Seipp <austin at well-typed.com> wrote:
> 
> > Here's a question, on top of this one: why don't we require
> > template-haskell changes for most corresponding syntax changes? We
> > tend to play catch up with template-haskell sometimes and it's
> > relatively strange. I mean, in some sense, we could have said a while
> > back "This needs another revision, please add template haskell
> > support" and avoided it all.
> > 
> > Richard has a better insight into this than I do, I'm sure, but it
> > seems - to me, anyway - like template-haskell support is a reasonable
> > bar for most surface-level syntax change to cross, before getting
> > merged.
> > 
> > My intuition tells me that, most of the time, a lot of us simply
> > forget to make the changes, or ask for them in reviews, and so it
> > goes.
> > 
> > On Thu, Apr 14, 2016 at 1:12 PM, Ben Gamari <ben at well-typed.com> wrote:
> >> Iavor Diatchki <iavor.diatchki at gmail.com> writes:
> >> 
> >>> Hello,
> >>> 
> >>> Now that "OVERLAPPING" and "OVERLAPPABLE" are pragmas on the instances, do
> >>> we have a way to generate instances with such pragmas using Template
> >>> Haskell?   I can't seem to find a way to do this, which is unfortunate.
> >>> 
> >>> If I am not missing anything, would there be objections to adding it to the
> >>> TH library before the next release---I would volunteer to do the change
> >>> ASAP.
> >>> 
> >> Indeed this is an unfortunate gap. Given that this shouldn't be a
> >> terribly invasive change I would be alright with this if Richard approves.
> >> 
> >> Cheers,
> >> 
> >> - Ben
> >> 
> >> 
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >> 
> > 
> > 
> > 
> > -- 
> > Regards,
> > 
> > Austin Seipp, Haskell Consultant
> > Well-Typed LLP, http://www.well-typed.com/
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From hvriedel at gmail.com  Thu Apr 14 21:33:18 2016
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Thu, 14 Apr 2016 23:33:18 +0200
Subject: GHC 8 and Template Haskell
In-Reply-To: <CAGK9nupmPZ=LOHJt3iTgXh6dQXetx4jkKpzcWBYz+G2BgTiL1w@mail.gmail.com>
 (Iavor Diatchki's message of "Thu, 14 Apr 2016 14:11:26 -0700")
References: <CAGK9nuoz8Nhq2mVpGGm+miKMTRLnHVRwUeS7E+y7bJmaAVJhLg@mail.gmail.com>
 <87potsxdnx.fsf@smart-cactus.org>
 <CAEs96n1kh56VTsZY-eiKLVwaRfrqu8M+qPSmzhjOjQjK2ihf-g@mail.gmail.com>
 <F44273AB-78CE-47D9-AFBC-AB66AF6BDECB@cis.upenn.edu>
 <CAGK9nupmPZ=LOHJt3iTgXh6dQXetx4jkKpzcWBYz+G2BgTiL1w@mail.gmail.com>
Message-ID: <87r3e7swo1.fsf@gmail.com>

On 2016-04-14 at 23:11:26 +0200, Iavor Diatchki wrote:

[...]

> If we were to delay things, we would ship a version of the library that has
> missing functionality *and* we'll break everyone's code on the next
> release.

>   If we make the change now, then at least when people fix their TH
> code to work with GHC 8, they'd be getting access to more
> functionality.
>
> This change does indeed change the data structure for declarations, so if
> you were working with it directly, indeed you'll have to make changes.

This so late in the process involves retroactively tighten upper bounds
on template-haskell for existing releases on Hackage which already
extended support to template-haskell-2.11.

Sadly, I have lost track of how many packages were already updated
several weeks ago since the first RC came out to work with
template-haskell-2.11 so I don't have any numbers to offer nor a
concrete list of which packages are likely candidates to become
penalized for having been early adopters of GHC 8.0.

So this will cause a regression on Hackage which will be actionable only
after GHC 8.0 final gets out (unless we happen to have a RC4), as
otherwise we'd break parts of Hackage for GHC 8.0 RC3 users
(this includes Travis jobs already including GHC 8.0 in their configs)

However, I do sympathize with the desire to get this in while it's still
relatively cheap, rather than have to wait a year until it's time for
template-haskell-2.12 ...

Would you be willing to help out with making sure popular packages
depending on template-haskell[1] are brought up speed as soon as your
proposed change lands to reduce the pain/cost of such a last-minute
change?


 [1]: http://packdeps.haskellers.com/reverse/template-haskell


> However, if you use the "smart" constructors in TH, you shouldn't need to
> change anything.
> In particular, I left `instanceD` as before---it does not add any
> overlapping pragmas, and I added a new function `instanceWithOverlapD`,
> which has an extra parameter that allows you to specify pragmas.
>
> I'd like to get this in, if possible, as I have a library that needs this
> feature.  My current work-around it quite ugly:  ask the clients of the
> library to enable "Language OverlappingInstaces", which is cumbersome,
> *and* generates deprecation warnings.

From mail at joachim-breitner.de  Thu Apr 14 21:44:59 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 14 Apr 2016 23:44:59 +0200
Subject: Phabricator build failures
Message-ID: <1460670299.2121.7.camel@joachim-breitner.de>

Hi,

some recent commits on GHC HEAD fail to validate on phabricator, all
with a segfault in the tests, but in an different tests each (or
sometimes no failure at all).

This this known?

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
? mail at joachim-breitner.de ? https://www.joachim-breitner.de/
? XMPP: nomeata at joachim-breitner.de?? OpenPGP-Key: 0xF0FBF51F
? Debian Developer: nomeata at debian.org

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

From iavor.diatchki at gmail.com  Thu Apr 14 22:04:05 2016
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 14 Apr 2016 15:04:05 -0700
Subject: GHC 8 and Template Haskell
In-Reply-To: <87r3e7swo1.fsf@gmail.com>
References: <CAGK9nuoz8Nhq2mVpGGm+miKMTRLnHVRwUeS7E+y7bJmaAVJhLg@mail.gmail.com>
 <87potsxdnx.fsf@smart-cactus.org>
 <CAEs96n1kh56VTsZY-eiKLVwaRfrqu8M+qPSmzhjOjQjK2ihf-g@mail.gmail.com>
 <F44273AB-78CE-47D9-AFBC-AB66AF6BDECB@cis.upenn.edu>
 <CAGK9nupmPZ=LOHJt3iTgXh6dQXetx4jkKpzcWBYz+G2BgTiL1w@mail.gmail.com>
 <87r3e7swo1.fsf@gmail.com>
Message-ID: <CAGK9nuopbymasWrUYe0RQ59gZZQ2npmGwTOrjbjetwD8+3dhAw@mail.gmail.com>

Sure, I'd be happy to help whoever needs help---just let me know.

The change that one would have to do is:  whenever you'd used "InstaceD"
 replace it with "InstanceD Nothing".




On Thu, Apr 14, 2016 at 2:33 PM, Herbert Valerio Riedel <hvriedel at gmail.com>
wrote:

> On 2016-04-14 at 23:11:26 +0200, Iavor Diatchki wrote:
>
> [...]
>
> > If we were to delay things, we would ship a version of the library that
> has
> > missing functionality *and* we'll break everyone's code on the next
> > release.
>
> >   If we make the change now, then at least when people fix their TH
> > code to work with GHC 8, they'd be getting access to more
> > functionality.
> >
> > This change does indeed change the data structure for declarations, so if
> > you were working with it directly, indeed you'll have to make changes.
>
> This so late in the process involves retroactively tighten upper bounds
> on template-haskell for existing releases on Hackage which already
> extended support to template-haskell-2.11.
>
> Sadly, I have lost track of how many packages were already updated
> several weeks ago since the first RC came out to work with
> template-haskell-2.11 so I don't have any numbers to offer nor a
> concrete list of which packages are likely candidates to become
> penalized for having been early adopters of GHC 8.0.
>
> So this will cause a regression on Hackage which will be actionable only
> after GHC 8.0 final gets out (unless we happen to have a RC4), as
> otherwise we'd break parts of Hackage for GHC 8.0 RC3 users
> (this includes Travis jobs already including GHC 8.0 in their configs)
>
> However, I do sympathize with the desire to get this in while it's still
> relatively cheap, rather than have to wait a year until it's time for
> template-haskell-2.12 ...
>
> Would you be willing to help out with making sure popular packages
> depending on template-haskell[1] are brought up speed as soon as your
> proposed change lands to reduce the pain/cost of such a last-minute
> change?
>
>
>  [1]: http://packdeps.haskellers.com/reverse/template-haskell
>
>
> > However, if you use the "smart" constructors in TH, you shouldn't need to
> > change anything.
> > In particular, I left `instanceD` as before---it does not add any
> > overlapping pragmas, and I added a new function `instanceWithOverlapD`,
> > which has an extra parameter that allows you to specify pragmas.
> >
> > I'd like to get this in, if possible, as I have a library that needs this
> > feature.  My current work-around it quite ugly:  ask the clients of the
> > library to enable "Language OverlappingInstaces", which is cumbersome,
> > *and* generates deprecation warnings.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160414/e2e7cf93/attachment.html>

From hvriedel at gmail.com  Thu Apr 14 22:58:43 2016
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Fri, 15 Apr 2016 00:58:43 +0200
Subject: GHC 8 and Template Haskell
In-Reply-To: <CAGK9nuopbymasWrUYe0RQ59gZZQ2npmGwTOrjbjetwD8+3dhAw@mail.gmail.com>
 (Iavor Diatchki's message of "Thu, 14 Apr 2016 15:04:05 -0700")
References: <CAGK9nuoz8Nhq2mVpGGm+miKMTRLnHVRwUeS7E+y7bJmaAVJhLg@mail.gmail.com>
 <87potsxdnx.fsf@smart-cactus.org>
 <CAEs96n1kh56VTsZY-eiKLVwaRfrqu8M+qPSmzhjOjQjK2ihf-g@mail.gmail.com>
 <F44273AB-78CE-47D9-AFBC-AB66AF6BDECB@cis.upenn.edu>
 <CAGK9nupmPZ=LOHJt3iTgXh6dQXetx4jkKpzcWBYz+G2BgTiL1w@mail.gmail.com>
 <87r3e7swo1.fsf@gmail.com>
 <CAGK9nuopbymasWrUYe0RQ59gZZQ2npmGwTOrjbjetwD8+3dhAw@mail.gmail.com>
Message-ID: <87k2jzsspo.fsf@gmail.com>

On 2016-04-15 at 00:04:05 +0200, Iavor Diatchki wrote:
> Sure, I'd be happy to help whoever needs help---just let me know.

Great... :-)

> The change that one would have to do is:  whenever you'd used "InstaceD"
>  replace it with "InstanceD Nothing".

I've done a quick grep for InstanceD over the stackage-nightly-subset of Hackage:

 https://gist.githubusercontent.com/hvr/97a4f0f0f594faa9c17857b52add9a2e

so those are most likely the packages (within the stackage-subset) that
will lose their GHC 8.0-readyness (if they had it to begin with...).

As a popular package example, `lens-4.13.{1,2,2.1}` has been GHC
8.0-ready for 3 releases already; so this would require retroactively
blocking those 3 releases by tightening the template-haskell upper-bound
via cabal-edits, and making a new release of `lens` as soon as GHC 8.0
final (or RC4) gets released...

On the bright side, the amount of packages affected seems manageable...


From simonpj at microsoft.com  Fri Apr 15 11:04:49 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 15 Apr 2016 11:04:49 +0000
Subject: [commit: ghc] wip/T10613: State hack hack in ticky report
 (02493dc)
In-Reply-To: <20160414203435.6A44C3A300@ghc.haskell.org>
References: <20160414203435.6A44C3A300@ghc.haskell.org>
Message-ID: <d0ea38ed836043f3b5b4e4762c311cb7@DB4PR30MB030.064d.mgd.msft.net>

Joachim

The commit message says something about "tick reports", but the
change to the code is entirely un-commented, and appears to have
nothing to do with ticky reports.

Could you add a comment or Note to explain? 

Thanks!

Simon

|  -----Original Message-----
|  From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf Of
|  git at git.haskell.org
|  Sent: 14 April 2016 21:35
|  To: ghc-commits at haskell.org
|  Subject: [commit: ghc] wip/T10613: State hack hack in ticky report
|  (02493dc)
|  
|  Repository : ssh://git at git.haskell.org/ghc
|  
|  On branch  : wip/T10613
|  Link       :
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.has
|  kell.org%2ftrac%2fghc%2fchangeset%2f02493dcf580141110e90fa943ec70640115
|  de0ed%2fghc&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c306055dca
|  afa407e7ce708d364a49c11%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=d%
|  2f7isihh6dMDZX93hTY8rsMQ7y%2f6mkiDm2asfPXpMrQ%3d
|  
|  >---------------------------------------------------------------
|  
|  commit 02493dcf580141110e90fa943ec70640115de0ed
|  Author: Joachim Breitner <mail at joachim-breitner.de>
|  Date:   Wed Mar 23 11:10:25 2016 +0100
|  
|      State hack hack in ticky report
|  
|      In the ticky report, do not mark a function with a State# argument
|  as
|      its first argument as single-entry.
|  
|  
|  >---------------------------------------------------------------
|  
|  02493dcf580141110e90fa943ec70640115de0ed
|   compiler/codeGen/StgCmmClosure.hs | 5 ++++-
|   1 file changed, 4 insertions(+), 1 deletion(-)
|  
|  diff --git a/compiler/codeGen/StgCmmClosure.hs
|  b/compiler/codeGen/StgCmmClosure.hs
|  index b467048..3b83b8e 100644
|  --- a/compiler/codeGen/StgCmmClosure.hs
|  +++ b/compiler/codeGen/StgCmmClosure.hs
|  @@ -234,7 +234,10 @@ mkLFReEntrant _ _ [] _
|     = pprPanic "mkLFReEntrant" empty
|   mkLFReEntrant top fvs args arg_descr
|     = LFReEntrant top os_info (length args) (null fvs) arg_descr
|  -  where os_info = idOneShotInfo (head args)
|  +  where
|  +    state_hack_hack = isStateHackType (idType (head args))
|  +    os_info | state_hack_hack = noOneShotInfo
|  +            | otherwise       = idOneShotInfo (head args)
|  
|   -------------
|   mkLFThunk :: Type -> TopLevelFlag -> [Id] -> UpdateFlag ->
|  LambdaFormInfo
|  
|  _______________________________________________
|  ghc-commits mailing list
|  ghc-commits at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c306055dcaafa4
|  07e7ce708d364a49c11%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=c0Gvy1
|  OhKUN%2f%2f5Gtx9pCjHEFyj0FMdQBuEzEF4bfvio%3d

From mail at joachim-breitner.de  Fri Apr 15 11:38:57 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 15 Apr 2016 13:38:57 +0200
Subject: [commit: ghc] wip/T10613: State hack hack in ticky report
 (02493dc)
In-Reply-To: <d0ea38ed836043f3b5b4e4762c311cb7@DB4PR30MB030.064d.mgd.msft.net>
References: <20160414203435.6A44C3A300@ghc.haskell.org>
 <d0ea38ed836043f3b5b4e4762c311cb7@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <1460720337.1717.20.camel@joachim-breitner.de>

Dear Simon,

Am Freitag, den 15.04.2016, 11:04 +0000 schrieb Simon Peyton Jones:
> The commit message says something about "tick reports", but the
> change to the code is entirely un-commented, and appears to have
> nothing to do with ticky reports.
> 
> Could you add a comment or Note to explain??

sorry that this happens so often; but this is again just a work-in-
progress-commit on a wip branch, and as such not yet in the polished
stat required to go to master.

This commit makes a bit more sense when seen in conjunction with

    30b9061317ea7b834339d9458c46bd6b9108d947
    Be more explicit about closure types in ticky-ticky-report

which is already in master (and where, upon reading right now, I?m not
sure if the current code

    mkLFReEntrant top fvs args arg_descr
    ? = LFReEntrant top os_info (length args) (null fvs) arg_descr
    ? where os_info = idOneShotInfo (head args)

is really the right away, or whether the idOneShotInfo of all arguments
should be used here (I think you said something along these lines, I
failed to follow up on it).


Greetings,
Joachim
-- 
Joachim ?nomeata? Breitner
? mail at joachim-breitner.de ? https://www.joachim-breitner.de/
? XMPP: nomeata at joachim-breitner.de?? OpenPGP-Key: 0xF0FBF51F
? Debian Developer: nomeata at debian.org

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

From simonpj at microsoft.com  Fri Apr 15 11:56:32 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 15 Apr 2016 11:56:32 +0000
Subject: [GHC] #11824: GHC error in desugarer lookup
In-Reply-To: <8737qpfwea.fsf@smart-cactus.org>
References: <046.bef37bafb0de36b55d56e17189a8ba9e@haskell.org>
 <061.6a21d313942a94900735c0c8a7674929@haskell.org>
 <9732b66656ae46bbb57ac6142c505972@DB4PR30MB030.064d.mgd.msft.net>
 <8737qpfwea.fsf@smart-cactus.org>
Message-ID: <1740ed3287ad411c9e803d17816e22cc@DB4PR30MB030.064d.mgd.msft.net>

|  If the latter there is no reason to fear: TcBinds.addTypecheckedBinds
|  (which TcTypeable uses) ensures that no bindings are added to the
|  environment if we are compiling a boot module,

Ah, I had missed that; it's pretty deeply hidden.

Suggestion:

* Move tcRecSelBinds from tcAddImplicits, to mkTypeableBinds.
  More precisely, make a new function addDerivedBindings, which
    * add record-selector bindings (via tcRecSelBinds)
    * adds typeable bindings (via mkTypableBinds)
  and call it where we currently call mkTypeableBinds.

* Instead of burying the "drop the bindings" deep in addTypecheckedBinds,
  inline it into addDerivedBindings:
   - make mkTypeableBinds *return* bindings rather than extending gbl-env
   - ditto tcRecSelBinds
  Then addDerivedBinds can test hs-boot, and extend the tcg_binds if necessary

That would put the two together nicely, they really are very similar.


I'm not bothered about the cost of generating bindings and then discarding them; it only happens for hs-boot files.  I _am_ concerned about clarity!

Thanks!

Simon

|  -----Original Message-----
|  From: Ben Gamari [mailto:ben at well-typed.com]
|  Sent: 13 April 2016 14:53
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: GHC developers <ghc-devs at haskell.org>
|  Subject: RE: [GHC] #11824: GHC error in desugarer lookup
|  
|  Simon Peyton Jones <simonpj at microsoft.com> writes:
|  
|  > Ben
|  >
|  > I'm offline, so can't reply on Phab.
|  >
|  > Calling mkTypeableBinds in tcRnHsBootDecls isn't quite right, because
|  it'll generate lots of *bindings* whereas all we want is the *Ids* in
|  the GlobalValEnv.
|  >
|  > (It's possible that tcg_binds is ignored in the boot-module case, but
|  > it's unsavoury to generate the bindings at all.  They are generated
|  > when we process the main module.)
|  >
|  > I suggest the easiest fix is, in mkModIdBinding and
|  mkTypeableTyConBinds, guard the binding-generation with a test for
|  whether isHsBootOrSig is true.
|  >
|  Are you concerned about the bindings being generated at all or merely
|  that they are being added to the typechecking environment?
|  
|  If the latter there is no reason to fear: TcBinds.addTypecheckedBinds
|  (which TcTypeable uses) ensures that no bindings are added to the
|  environment if we are compiling a boot module,
|  
|      addTypecheckedBinds :: TcGblEnv -> [LHsBinds Id] -> TcGblEnv
|      addTypecheckedBinds tcg_env binds
|        | isHsBootOrSig (tcg_src tcg_env) = tcg_env
|          -- Do not add the code for record-selector bindings
|          -- when compiling hs-boot files
|        | otherwise = tcg_env { tcg_binds = foldr unionBags
|                                                  (tcg_binds tcg_env)
|                                                  binds }
|  
|  Of course, we are still doing the work of producing the bindings; if it
|  is this that you are concerned about then I can be more careful in
|  guarding their production.
|  
|  Cheers,
|  
|  - Ben

From simonpj at microsoft.com  Fri Apr 15 12:11:52 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 15 Apr 2016 12:11:52 +0000
Subject: [GHC] #11863: MSN Customer Service %% 18552337309 %% Live Tech
 Assistance Phone Number
In-Reply-To: <051.a0e72c7235c6f1a63a72b3a060664f61@haskell.org>
References: <051.a0e72c7235c6f1a63a72b3a060664f61@haskell.org>
Message-ID: <1f0283245045426b92aa837eceecb7bc@DB4PR30MB030.064d.mgd.msft.net>

Devs,

Is there anything anyone can do to kill off this spam?

Simon

|  -----Original Message-----
|  From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf Of
|  GHC
|  Sent: 15 April 2016 13:08
|  Cc: ghc-tickets at haskell.org
|  Subject: [GHC] #11863: MSN Customer Service %% 18552337309 %% Live Tech
|  Assistance Phone Number
|  
|  #11863: MSN Customer Service %% 18552337309 %% Live Tech Assistance
|  Phone Number
|  -------------------------------------+---------------------------------
|  -
|  -------------------------------------+---
|             Reporter:  roxiertaylor   |             Owner:
|                 Type:  bug            |            Status:  new
|             Priority:  normal         |         Milestone:
|            Component:  Compiler       |           Version:  7.10.3
|             Keywords:                 |  Operating System:
|  Unknown/Multiple
|         Architecture:                 |   Type of failure:  None/Unknown
|    Unknown/Multiple                   |
|            Test Case:                 |        Blocked By:
|             Blocking:                 |   Related Tickets:
|  Differential Rev(s):                 |         Wiki Page:
|  -------------------------------------+---------------------------------
|  -
|  -------------------------------------+---
|   MSN Customer Service %% 18552337309 %% Live Tech Assistance Phone
|  Number  Msn Customer Service Number .
|   Msn Customer Service Phone Number .
|   Msn Customer Service Contact Number .
|   Msn Customer Service Telephone Number .
|   Msn Customer Service Helpline Number .
|   Msn Customer Service Toll Free Number .
|   Phone Number For Msn .
|   Msn Customer Support Phone Number .
|   Msn Customer Service Help Desk Number .
|   Msn Customer Service Landline Number .
|   Msn Customer Service 24/7 Number .
|   Msn Customer Service Number .
|   Msn Customer Service Number .
|   Msn tech support number .
|   Msn tech support phone number .
|   Msn tech support contact number .
|   Msn tech support helpline number .
|   Msn tech support help .
|   Msn tech support help desk number .
|   Msn tech support telephone number .
|   Msn tech support mobile number .
|   Msn tech support landline number .
|   Msn tech support toll free number .
|   Msn tech support 24/7 hours number .
|   Msn tech support contact details .
|   Msn tech support contact info .
|   Msn tech support line .
|   Msn tech support number .
|   Msn tech support number .
|   Msn tech support representative .
|   Msn tech support phone number .
|   Msn tech support phone number .
|   Msn tech support team .
|   Msn tech support live support .
|   Msn tech support assistance .
|   Msn tech support assistance number .
|   Msn tech support assistance contact number .
|   Msn tech support assistance phone number .
|   Msn tech support assistance helpline number .
|   Msn tech support assistance help desk number .
|   Msn customer support assistance 24/7 .
|   Msn tech support online support .
|   Msn tech support number .
|   Msn tech support number .
|   Msn tech support no. .
|   Msn team support number .
|   Msn team support phone number .
|   Msn team support contact number .
|   Msn team support helpline number .
|   Msn team support help .
|   Msn team support help desk number .
|   Msn team support telephone number .
|   Msn team support mobile number .
|   Msn team support landline number .
|   Msn team support toll free number .
|   Msn team support 24/7 hours number .
|   Msn team support contact details .
|   Msn team support contact info .
|   Msn team support line .
|   Msn team support number .
|   Msn team support number .
|   Msn team support representative .
|   Msn team support phone number .
|   Msn team support phone number .
|   Msn team support team .
|   Msn team support team support .
|   Msn team support assistance .
|   Msn team support assistance number .
|   Msn team support assistance contact number .
|   Msn team support assistance phone number .
|   Msn team support assistance helpline number .
|   Msn team support assistance help desk number .
|   Msn customer support assistance 24/7 .
|   Msn team support online support .
|   Msn team support number .
|   Msn team support no. .
|   Msn help desk number .
|   Msn help desk phone number .
|   Msn help desk contact number .
|   Msn help desk helpline number .
|   Msn help desk help .
|   Msn help desk help desk number .
|   Msn help desk telephone number .
|   Msn help desk mobile number .
|   Msn help desk landline number .
|   Msn help desk toll free number .
|   Msn help desk 24/7 hours number .
|   Msn help desk contact details .
|  
|   (call) I*855*2I2*2247 Msn Customer Service and Support Phone Number
|  Helpline (USA)
|  
|  --
|  Ticket URL:
|  <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.ha
|  skell.org%2ftrac%2fghc%2fticket%2f11863&data=01%7c01%7csimonpj%40064d.m
|  gd.microsoft.com%7cf0b502d0bd064851372f08d365270a49%7c72f988bf86f141af9
|  1ab2d7cd011db47%7c1&sdata=q42%2bpnHzKHYRpQAa5RTUN%2bpY6AAjGeD%2fDGtVJn9
|  PILc%3d>
|  GHC
|  <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ha
|  skell.org%2fghc%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cf0
|  b502d0bd064851372f08d365270a49%7c72f988bf86f141af91ab2d7cd011db47%7c1&s
|  data=xCiJdocJi4IW1A9Yzb922NIefegLQTA5x6FJjwXzvMo%3d>
|  The Glasgow Haskell Compiler
|  _______________________________________________
|  ghc-tickets mailing list
|  ghc-tickets at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  tickets&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cf0b502d0bd064
|  851372f08d365270a49%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9gk1SL
|  AtX%2fhlwci77qo95c2JsBgFKbqt2KEV4IQqTOU%3d

From ben at well-typed.com  Fri Apr 15 12:18:35 2016
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 15 Apr 2016 14:18:35 +0200
Subject: GHC 8 and Template Haskell
In-Reply-To: <nepook$i59$1@ger.gmane.org>
References: <CAGK9nuoz8Nhq2mVpGGm+miKMTRLnHVRwUeS7E+y7bJmaAVJhLg@mail.gmail.com>
 <87potsxdnx.fsf@smart-cactus.org>
 <CAEs96n1kh56VTsZY-eiKLVwaRfrqu8M+qPSmzhjOjQjK2ihf-g@mail.gmail.com>
 <nepook$i59$1@ger.gmane.org>
Message-ID: <87k2jzxdyc.fsf@smart-cactus.org>

Bardur Arantsson <spam at scientician.net> writes:

> On 04/14/2016 08:17 PM, Austin Seipp wrote:
>> Here's a question, on top of this one: why don't we require
>> template-haskell changes for most corresponding syntax changes? We
>> tend to play catch up with template-haskell sometimes and it's
>> relatively strange. I mean, in some sense, we could have said a while
>> back "This needs another revision, please add template haskell
>> support" and avoided it all.
>> 
>> Richard has a better insight into this than I do, I'm sure, but it
>> seems - to me, anyway - like template-haskell support is a reasonable
>> bar for most surface-level syntax change to cross, before getting
>> merged.
>> 
>> My intuition tells me that, most of the time, a lot of us simply
>> forget to make the changes, or ask for them in reviews, and so it
>> goes.
>> 
>
> ISTM that this kind of thing could be reasonably handled by simply
> having a checklist for new functionality -- which includes TH support as
> a checkbox.
>
Indeed, I have a list that I try to check against while reviewing. I've
put it up here [1] (and added checking for template-haskell support)
although I agree that it would be nice if this were better integrated
into the review process.


> I'm sure others there are other frequently-forgotten-but-important
> things that people can think of to put into such a checklist.
>
> (Not sure if GHC has a "Release" checklist, but I'd imagine one of those
> might also be useful.)

There is the MakingReleases page [2].

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/PatchChecklist
[2] https://ghc.haskell.org/trac/ghc/wiki/MakingReleases
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160415/7bbab10a/attachment.sig>

From ben at well-typed.com  Fri Apr 15 12:22:43 2016
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 15 Apr 2016 14:22:43 +0200
Subject: directory and GHC 8.0.1
In-Reply-To: <1460632519.1473955.578559009.58BCE9FF@webmail.messagingengine.com>
References: <87d1q24j0g.fsf@smart-cactus.org>
 <1459976919.2379569.571159985.696D36D2@webmail.messagingengine.com>
 <87a8l64bzd.fsf@smart-cactus.org>
 <1460000148.3221856.571408153.7456C7C7@webmail.messagingengine.com>
 <877fg94xtq.fsf@smart-cactus.org>
 <1460632519.1473955.578559009.58BCE9FF@webmail.messagingengine.com>
Message-ID: <87h9f3xdrg.fsf@smart-cactus.org>

rf at rufflewind.com writes:

> Alright, directory-1.2.6.0 has been pushed to master (74e5058) and I've
> added a note to indicate that it is bundled with GHC 8.0.1.  Looks good?
>
Looks good to me. Thanks Phil!

Cheers,

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

From ben at smart-cactus.org  Fri Apr 15 12:29:00 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Fri, 15 Apr 2016 14:29:00 +0200
Subject: [GHC] #11863: MSN Customer Service %% 18552337309 %% Live Tech
 Assistance Phone Number
In-Reply-To: <1f0283245045426b92aa837eceecb7bc@DB4PR30MB030.064d.mgd.msft.net>
References: <051.a0e72c7235c6f1a63a72b3a060664f61@haskell.org>
 <1f0283245045426b92aa837eceecb7bc@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <87ega7xdgz.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> Devs,
>
> Is there anything anyone can do to kill off this spam?
>
I've spent a few hours today amending the spam filter list and trying to
expunge as much as I can manually. Unfortunately doing this via the web
interface is an incredibly labor intensive process, so I've suspended my
efforts until I can get shell access to our Trac installation.

It also looks like spambayes support isn't enabled in our Trac
configuration; I hopeful that enabling it will help immensely in
stemming this spam spree (but sadly this too will require shell access).

Cheers,

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

From simonpj at microsoft.com  Fri Apr 15 12:38:05 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 15 Apr 2016 12:38:05 +0000
Subject: Lint warnings
Message-ID: <2eedb0f8fa734e82aa4d40dd576ff9e3@DB4PR30MB030.064d.mgd.msft.net>

Lint has started emitting lots of warnings like this, when compiling libraries.

Lint warning: case binder's type has no constructors

  ds_sPA5 V1 p_a7vb

Does anyone have any idea why?
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160415/10deeb79/attachment-0001.html>

From simonpj at microsoft.com  Fri Apr 15 12:40:15 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 15 Apr 2016 12:40:15 +0000
Subject: Trac spam
Message-ID: <d6cb979dfad54007a1a767852a8330c0@DB4PR30MB030.064d.mgd.msft.net>

|  I've spent a few hours today amending the spam filter list and trying
|  to expunge as much as I can manually. Unfortunately doing this via the
|  web interface is an incredibly labor intensive process, so I've
|  suspended my efforts until I can get shell access to our Trac
|  installation.

Do you know when that will be?  I'm getting one spam/minute at the moment.

Simon

|  -----Original Message-----
|  From: Ben Gamari [mailto:ben at smart-cactus.org]
|  Sent: 15 April 2016 13:29
|  To: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs at haskell.org
|  Subject: RE: [GHC] #11863: MSN Customer Service %% 18552337309 %% Live
|  Tech Assistance Phone Number
|  
|  Simon Peyton Jones <simonpj at microsoft.com> writes:
|  
|  > Devs,
|  >
|  > Is there anything anyone can do to kill off this spam?
|  >
|  I've spent a few hours today amending the spam filter list and trying
|  to expunge as much as I can manually. Unfortunately doing this via the
|  web interface is an incredibly labor intensive process, so I've
|  suspended my efforts until I can get shell access to our Trac
|  installation.
|  
|  It also looks like spambayes support isn't enabled in our Trac
|  configuration; I hopeful that enabling it will help immensely in
|  stemming this spam spree (but sadly this too will require shell
|  access).
|  
|  Cheers,
|  
|  - Ben

From ben at well-typed.com  Fri Apr 15 12:51:14 2016
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 15 Apr 2016 14:51:14 +0200
Subject: Trac spam
In-Reply-To: <d6cb979dfad54007a1a767852a8330c0@DB4PR30MB030.064d.mgd.msft.net>
References: <d6cb979dfad54007a1a767852a8330c0@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <87bn5bxcfx.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> |  I've spent a few hours today amending the spam filter list and trying
> |  to expunge as much as I can manually. Unfortunately doing this via the
> |  web interface is an incredibly labor intensive process, so I've
> |  suspended my efforts until I can get shell access to our Trac
> |  installation.
>
> Do you know when that will be?  I'm getting one spam/minute at the moment.
>
Unfortunately Herbert is, as far as I know, the only one with
administrative rights to this machine and he is quite busy today. For
the time being I've tried to tighten the spam policies a bit more at the
expense of perhaps rejecting legitimate traffic.

Cheers,

- Ben

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

From ben at smart-cactus.org  Fri Apr 15 13:43:45 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Fri, 15 Apr 2016 15:43:45 +0200
Subject: Trac spam
In-Reply-To: <d6cb979dfad54007a1a767852a8330c0@DB4PR30MB030.064d.mgd.msft.net>
References: <d6cb979dfad54007a1a767852a8330c0@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <878u0fxa0e.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> |  I've spent a few hours today amending the spam filter list and trying
> |  to expunge as much as I can manually. Unfortunately doing this via the
> |  web interface is an incredibly labor intensive process, so I've
> |  suspended my efforts until I can get shell access to our Trac
> |  installation.
>
> Do you know when that will be?  I'm getting one spam/minute at the moment.
>
Alright, I have configured spambayes and it seems to be doing its job
admirably. Now to try and undo the damage done up until this point.

Cheers,

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

From ryan.gl.scott at gmail.com  Fri Apr 15 14:14:09 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Fri, 15 Apr 2016 10:14:09 -0400
Subject: GHC 8 and Template Haskell
Message-ID: <CADdQpRBkh-g8KOiSYeqhV+GMPHnYcxam0HsDNNwV=gpkwX8Zxg@mail.gmail.com>

> I've done a quick grep for InstanceD over the stackage-nightly-subset of Hackage:

Wouldn't we also need to check for the instanceD function from
Language.Haskell.TH.Lib as well? I know several of my packages use
that exclusively over the InstanceD constructor, and I imagine others
do as well.

Ryan S.

From simonpj at microsoft.com  Fri Apr 15 14:37:18 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 15 Apr 2016 14:37:18 +0000
Subject: [Diffusion] [Build Failed] rGHC2acfaae9a99d: Comments only
In-Reply-To: <20160415143457.8334.19761.7FBC8045@phabricator.haskell.org>
References: <diffusion-audit-PHID-CMIT-ttibbxgi6s3xaiq7dj23@phabricator.haskell.org>
 <20160415143457.8334.19761.7FBC8045@phabricator.haskell.org>
Message-ID: <361f0dbfbaf64e538ca0fe6e86e36586@DB4PR30MB030.064d.mgd.msft.net>

Bizarre.  Harbourmaster says:

ghc-stage1: ghc-stage1: out of memory (requested 1048576 bytes)
out of memory (requested 1048576 bytes)

I have no idea what is going on

SImon

|  -----Original Message-----
|  From: noreply at phabricator.haskell.org
|  [mailto:noreply at phabricator.haskell.org]
|  Sent: 15 April 2016 15:35
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Subject: [Diffusion] [Build Failed] rGHC2acfaae9a99d: Comments only
|  
|  Harbormaster failed to build B9176: rGHC2acfaae9a99d: Comments only!
|  
|  BRANCHES
|    master
|  
|  USERS
|    simonpj (Author)
|    GHC - Core/System FC (Auditor)
|  
|  COMMIT
|    https://phabricator.haskell.org/rGHC2acfaae9a99d
|  
|  EMAIL PREFERENCES
|    https://phabricator.haskell.org/settings/panel/emailpreferences/
|  
|  To: simonpj, GHC - Core/System FC, Harbormaster

From austin at well-typed.com  Fri Apr 15 14:38:39 2016
From: austin at well-typed.com (Austin Seipp)
Date: Fri, 15 Apr 2016 09:38:39 -0500
Subject: [Diffusion] [Build Failed] rGHC2acfaae9a99d: Comments only
In-Reply-To: <361f0dbfbaf64e538ca0fe6e86e36586@DB4PR30MB030.064d.mgd.msft.net>
References: <diffusion-audit-PHID-CMIT-ttibbxgi6s3xaiq7dj23@phabricator.haskell.org>
 <20160415143457.8334.19761.7FBC8045@phabricator.haskell.org>
 <361f0dbfbaf64e538ca0fe6e86e36586@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAEs96n28K_2AeBPgdFQBmq9DzpX1-2hQtCkyy_TXqJkEqoDwgQ@mail.gmail.com>

I'm looking into Harbormaster today (following Joachim's email
earlier). Not sure why the machine is running out of memory...

On Fri, Apr 15, 2016 at 9:37 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> Bizarre.  Harbourmaster says:
>
> ghc-stage1: ghc-stage1: out of memory (requested 1048576 bytes)
> out of memory (requested 1048576 bytes)
>
> I have no idea what is going on
>
> SImon
>
> |  -----Original Message-----
> |  From: noreply at phabricator.haskell.org
> |  [mailto:noreply at phabricator.haskell.org]
> |  Sent: 15 April 2016 15:35
> |  To: Simon Peyton Jones <simonpj at microsoft.com>
> |  Subject: [Diffusion] [Build Failed] rGHC2acfaae9a99d: Comments only
> |
> |  Harbormaster failed to build B9176: rGHC2acfaae9a99d: Comments only!
> |
> |  BRANCHES
> |    master
> |
> |  USERS
> |    simonpj (Author)
> |    GHC - Core/System FC (Auditor)
> |
> |  COMMIT
> |    https://phabricator.haskell.org/rGHC2acfaae9a99d
> |
> |  EMAIL PREFERENCES
> |    https://phabricator.haskell.org/settings/panel/emailpreferences/
> |
> |  To: simonpj, GHC - Core/System FC, Harbormaster
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Regards,

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

From ben at well-typed.com  Fri Apr 15 15:28:56 2016
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 15 Apr 2016 17:28:56 +0200
Subject: Spam filtering
Message-ID: <877ffyyjpj.fsf@smart-cactus.org>


Hello GHCers,

As you may have noticed, the GHC Trac instance is currently being hit
with a significant amount of spam traffic recently. I believe I've
cleared up most of the garbage and the filter configuration has been
tightened so that future spam attacks will be easier to quell.

Of course, this tightening means that there is a greater chance of false
positives. If you do find that your ticket comments or Wiki edits are
being rejected by the spam filter, please notify either Austin or me so
that we can train the filter on your example.

Cheers,

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

From iavor.diatchki at gmail.com  Fri Apr 15 15:42:02 2016
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 15 Apr 2016 08:42:02 -0700
Subject: GHC 8 and Template Haskell
In-Reply-To: <CADdQpRBkh-g8KOiSYeqhV+GMPHnYcxam0HsDNNwV=gpkwX8Zxg@mail.gmail.com>
References: <CADdQpRBkh-g8KOiSYeqhV+GMPHnYcxam0HsDNNwV=gpkwX8Zxg@mail.gmail.com>
Message-ID: <CAGK9nuquFT8oX1Np6BgpjLJpWC0_pTd5fWSYgZWFTb+YBbGkHA@mail.gmail.com>

I left the "instanceD" functions as is, and added a new function
`instanceWithOverlapD` to avoid that problem:

instanceD :: CxtQ -> TypeQ -> [DecQ] -> DecQ
instanceWithOverlapD :: Maybe Overlap -> CxtQ -> TypeQ -> [DecQ] -> DecQ

The patch is here btw:

https://phabricator.haskell.org/D2118





On Fri, Apr 15, 2016 at 7:14 AM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:

> > I've done a quick grep for InstanceD over the stackage-nightly-subset of
> Hackage:
>
> Wouldn't we also need to check for the instanceD function from
> Language.Haskell.TH.Lib as well? I know several of my packages use
> that exclusively over the InstanceD constructor, and I imagine others
> do as well.
>
> Ryan S.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160415/6f978877/attachment.html>

From ryan.gl.scott at gmail.com  Fri Apr 15 15:50:28 2016
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Fri, 15 Apr 2016 11:50:28 -0400
Subject: GHC 8 and Template Haskell
In-Reply-To: <CAGK9nuquFT8oX1Np6BgpjLJpWC0_pTd5fWSYgZWFTb+YBbGkHA@mail.gmail.com>
References: <CADdQpRBkh-g8KOiSYeqhV+GMPHnYcxam0HsDNNwV=gpkwX8Zxg@mail.gmail.com>
 <CAGK9nuquFT8oX1Np6BgpjLJpWC0_pTd5fWSYgZWFTb+YBbGkHA@mail.gmail.com>
Message-ID: <CADdQpRDHhoDdfW14nyjvty0EOj3zeLDcmFbJJ5jcJR5r-3skVA@mail.gmail.com>

Ah, that sounds like a good way to handle it. Thanks for the quick response!

Ryan S.

On Fri, Apr 15, 2016 at 11:42 AM, Iavor Diatchki
<iavor.diatchki at gmail.com> wrote:
> I left the "instanceD" functions as is, and added a new function
> `instanceWithOverlapD` to avoid that problem:
>
> instanceD :: CxtQ -> TypeQ -> [DecQ] -> DecQ
> instanceWithOverlapD :: Maybe Overlap -> CxtQ -> TypeQ -> [DecQ] -> DecQ
>
> The patch is here btw:
>
> https://phabricator.haskell.org/D2118
>
>
>
>
>
> On Fri, Apr 15, 2016 at 7:14 AM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
>>
>> > I've done a quick grep for InstanceD over the stackage-nightly-subset of
>> > Hackage:
>>
>> Wouldn't we also need to check for the instanceD function from
>> Language.Haskell.TH.Lib as well? I know several of my packages use
>> that exclusively over the InstanceD constructor, and I imagine others
>> do as well.
>>
>> Ryan S.
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>

From simonpj at microsoft.com  Fri Apr 15 15:51:06 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 15 Apr 2016 15:51:06 +0000
Subject: Reification of out-of-scope variables?
In-Reply-To: <CAJ0eudoNEa-dpSNwT1fhPxdQr6CpYvsuexVJNoxowoDu6KBahA@mail.gmail.com>
References: <CAJ0eudrYKW=+s25+G9x_3AQNJTU2Uqj18uZfbzZedF2p8oq=LQ@mail.gmail.com>
 <266BEB36-AA3D-4049-84F7-138C6FF7539A@cis.upenn.edu>
 <CA+Q==SDrdJBAKWt4ULwgYpPu0vHwz-WqSK4U1upTaA2DTtGPAQ@mail.gmail.com>
 <1DA2B8DB-1830-44A4-9564-F3B508771909@cis.upenn.edu>
 <CAJ0eudoNEa-dpSNwT1fhPxdQr6CpYvsuexVJNoxowoDu6KBahA@mail.gmail.com>
Message-ID: <02700e82027346eea0d10776603e6610@DB4PR30MB030.064d.mgd.msft.net>


|  a TExp rather than an Exp. Turns out the example from my first email
|  does work if you adapt it to use typed splices:
|  
|  f :: Int -> Int
|  f x = $$(do let {name = mkName x}; info <- reify name; runIO (print
|  info) [|| x ||])

Hang on!  The design for typed splices, describe here,
https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/BlogPostChanges
says "Unlike TH, the only way to construct a value of type TExp is with a quote. You cannot drop into do-notation, nor use explicit construction of the values in the Exp algebraic data type. That restriction limits expressiveness, but it enables the strong typing guarantees." 

So why does the above work?  $$(e) requires a TExp, and do-notation doesn?t produce a TExp.

|  * Should we consider it a bug (and file a ticket) that reification in
|  typed splices is able to observe the order of type checking, just like
|  reify used to do in untyped splices?

Yes I think so!!!

Simon

From simonpj at microsoft.com  Fri Apr 15 15:57:08 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 15 Apr 2016 15:57:08 +0000
Subject: Reification of out-of-scope variables?
In-Reply-To: <9BF5E2D1-B54D-430C-A40F-164B5B46D3FF@cis.upenn.edu>
References: <CAJ0eudrYKW=+s25+G9x_3AQNJTU2Uqj18uZfbzZedF2p8oq=LQ@mail.gmail.com>
 <266BEB36-AA3D-4049-84F7-138C6FF7539A@cis.upenn.edu>
 <CA+Q==SDrdJBAKWt4ULwgYpPu0vHwz-WqSK4U1upTaA2DTtGPAQ@mail.gmail.com>
 <1DA2B8DB-1830-44A4-9564-F3B508771909@cis.upenn.edu>
 <CAJ0eudoNEa-dpSNwT1fhPxdQr6CpYvsuexVJNoxowoDu6KBahA@mail.gmail.com>
 <9BF5E2D1-B54D-430C-A40F-164B5B46D3FF@cis.upenn.edu>
Message-ID: <0b6741c269cf4b65bae940cb12b4f129@DB4PR30MB030.064d.mgd.msft.net>


|  > * If part of the solution here is to use typed splices, how do we get
|  > quasiquotation to be syntactic sugar for a *typed* splice? Do we want
|  > to be introducing a typed quasiquotation syntax, just like Geoff did
|  > for much of the rest of Template Haskell?
|  
|  Maybe. Quasiquotation sugar is very light: [blah|...|] is the same as
|  $(selector blah "...") where `selector` is the right record selector
|  depending on the splice context. Is it worth trying to expand
|  quasiquotation syntax to work with typed TH? I'm unconvinced it's worth
|  the bother. Also, note that doing [blah||...||] is not backward-
|  compatible, because that looks like an untyped quasiquote that begins
|  and ends with a vertical bar. 

The merit of a typed splice is that if you see
	$$(f [|| x ||])
and (f [|| x ||]) typechecks, then you know that the splice result will typecheck. You never have to look at the expansion of the splice.

Nothing like that can be said about quasiquotes
	[flob| ...arbitrary string... |]

We can't say "if ...arbitrary string.. typechecks then the quasiquote will typecheck.

To put it another way, it's equivalent to

	$(getExprParser flob "...arby string....")

and that typechecks trivially, but its expansion of course might not.

So there is literally no point in thinking about typed-splices for quasiquotes.

Simon

From simonpj at microsoft.com  Fri Apr 15 15:59:18 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 15 Apr 2016 15:59:18 +0000
Subject: trac span
Message-ID: <2df6cb968f364a9fb178f2e596a08359@DB4PR30MB030.064d.mgd.msft.net>

Ben, can you switch off Trac edits until you've found a way to plug this?

Simon

|  -----Original Message-----
|  From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf Of
|  GHC
|  Sent: 15 April 2016 16:54
|  Cc: ghc-tickets at haskell.org
|  Subject: [GHC] #11900: HELP@@ 1 844 446 4460 phone number for pogo
|  customer service
|  
|  #11900: HELP@@ 1 844 446 4460 phone number for pogo customer service
|  -------------------------------------+---------------------------------
|  -
|  -------------------------------------+---
|             Reporter:  vimpy          |             Owner:
|                 Type:  bug            |            Status:  new
|             Priority:  normal         |         Milestone:
|            Component:  Compiler       |           Version:  7.10.3
|             Keywords:                 |  Operating System:
|  Unknown/Multiple
|         Architecture:                 |   Type of failure:  None/Unknown
|    Unknown/Multiple                   |
|            Test Case:                 |        Blocked By:
|             Blocking:                 |   Related Tickets:
|  Differential Rev(s):                 |         Wiki Page:
|  -------------------------------------+---------------------------------
|  -
|  -------------------------------------+---
|   HELP@@ 1 844 446 4460 phone number for pogo customer serviceUA-
|  75287313-1  WYNN 1-844 446 -4460 wynn POGO GAMES CONTACT Tech Support
|  Toll-Free Phone  Number Technical Support Toll-Free Phone Number UA-
|  75287313-1  {| class="wikitable"
|   |-
|   ! wynn POGO GAMES CONTACT tech Support Number !! 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT technical Support Phone Number || 1 844 446
|  4460
|   |-
|   | wynn POGO GAMES CONTACT technical Support Number || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT tech Support Phone Number || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT tech Support Number || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT technical Support Phone Number || 1 844 446
|  4460
|   |-
|   | wynn POGO GAMES CONTACT technical Support Number || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT service number || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT service phone number || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT support number || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT support phone number || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT payroll tech Support Phone Number || 1 844
|  446
|   4460
|   |-
|   | wynn POGO GAMES CONTACT payroll tech Support Number || 1 844 446
|  4460
|   |-
|   | wynn POGO GAMES CONTACT payroll technical Support Phone Number || 1
|  844
|   446 4460
|   |-
|   | wynn POGO GAMES CONTACT payroll technical Support Number || 1 844
|  446
|   4460
|   |-
|   | wynn POGO GAMES CONTACT premier support phone number || 1 844 446
|  4460
|   |-
|   | wynn POGO GAMES CONTACT premier support number || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT premier support number || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT help desk phone number || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT help desk number || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT Error Support Number || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT Error Support phone Number || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT Contact Number || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT Error Support || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT Support Contact Number || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT Support Phone Number || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT Support Phone Number || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT Support Phone Number || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT Support Phone Number || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT tech Support Phone Number USA || 1 844 446
|  4460
|   |-
|   | wynn POGO GAMES CONTACT tech Support Number ?USA || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT technical Support Phone Number USA || 1 844
|  446
|   4460
|   |-
|   | wynn POGO GAMES CONTACT technical Support Number USA || 1 844 446
|  4460
|   |-
|   | wynn POGO GAMES CONTACT tech Support Phone Number USA || 1 844 446
|  4460
|   |-
|   | wynn POGO GAMES CONTACT tech Support Number USA || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT technical Support Phone Number USA || 1 844
|  446
|   4460
|   |-
|   | wynn POGO GAMES CONTACT technical Support Number USA || 1 844 446
|  4460
|   |-
|   | wynn POGO GAMES CONTACT service number USA || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT service phone number USA || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT support number USA || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT support phone number USA || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT payroll tech Support Phone Number USA || 1
|  844
|   446 4460
|   |-
|   | wynn POGO GAMES CONTACT payroll tech Support Number USA || 1 844 446
|   4460
|   |-
|   | wynn POGO GAMES CONTACT payroll technical Support Phone Number USA
|  || 1
|   844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT payroll technical Support Number USA || 1
|  844
|   446 4460
|   |-
|   | wynn POGO GAMES CONTACT premier support phone number USA || 1 844
|  446
|   4460
|   |-
|   | wynn POGO GAMES CONTACT premier support number USA || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT help desk phone number USA || 1 844 446 4460
|   |-
|   | wynn POGO GAMES CONTACT help desk number USA || 1 844 446 4460  |}
|  
|  
|  
|   Jack and Jill went up the hill to call 1844 446 4460 wynn POGO GAMES
|  CONTACT Desktop care phone number. Jack fell on 1844 446 4460 wynn POGO
|  GAMES CONTACT care number and broke his crown and jill came on 1844 446
|   4460 wynn POGO GAMES CONTACT care helpline number. JAck has a teddy
|  bear  called 1844 446 4460 wynn POGO GAMES CONTACT care helpline phone
|  number,  and jill has a barbie doll named 1844 446 4460 wynn POGO GAMES
|  CONTACT  care Helpline. Twiinkle twinkle little star 1844 446 4460 wynn
|  POGO GAMES  CONTACT Desktop care Helpdesk phone number how i wonder
|  what you are 1844
|   446 4460 wynn POGO GAMES CONTACT care Helpdesk number. Up above the
|  world  of 1844 446 4460 wynn POGO GAMES CONTACT care Helpdesk, like a
|  diamond in  the sky. Humpty dumpty 1844 446 4460 wynn POGO GAMES
|  CONTACT service phone  number sat on a 1844 446 4460 wynn POGO GAMES
|  CONTACT service number,  Humpty dumpty had a gret fall 1844 446 4460
|  wynn POGO GAMES CONTACT  Desktop service helpline phone number. All the
|  kings horses all the 1844
|   446 4460 wynn POGO GAMES CONTACT service helpline number could not put
|  humpty togather again. Ba ba black sheep have u 1844 446 4460 wynn POGO
|  GAMES CONTACT service helpline, Yes sir yes sir three 1844 446 4460
|  wynn  POGO GAMES CONTACT Desktop service helpdesk phone number bags
|  full. One  for my master 1844 446 4460 wynn POGO GAMES CONTACT service
|  helpdesk  number one for the dame 1844 446 4460 wynn POGO GAMES CONTACT
|  service  helpdesk. One for the little boy 1844 446 4460 wynn POGO GAMES
|  CONTACT  support phone number who lives down the lane. Johhny johhny
|  1844 446 4460  wynn POGO GAMES CONTACT support number, Yes papa Eating
|  sugar 1844 446
|   4460 wynn POGO GAMES CONTACT support ,No papa. telling lies 1844 446
|  4460  wynn POGO GAMES CONTACT support helpline phone number no papa
|  faad thoda  ha ha ha 1844 446 4460 wynn POGO GAMES CONTACT Desktop
|  support helpline  number. A lion and a unicorn 1844 446 4460 wynn POGO
|  GAMES CONTACT support  helpline were in the jungle 1844 446 4460 wynn
|  POGO GAMES CONTACT support  helpdesk phone number, the lion beat the
|  unicorn balck and brown 1844 446
|   4460 wynn POGO GAMES CONTACT support helpdesk number so the unicorn
|  gave  birth to my child 1844 446 4460 wynn POGO GAMES CONTACT Desktop
|  support  helpdesk.
|  
|   wynn POGO GAMES CONTACT is an accounting software package developed
|  and  marketed by Intuit Wanna call them at 1-844 446 -4460 . wynn POGO
|  GAMES  CONTACT ducts are geared mainly toward small and medium-sized
|  businesses  and offer on-premises accounting applications as well as
|  cloud based  versions that accept business payments, manage and pay
|  bills and payroll  functions.Intuit was founded in 1983 by Scott Cook
|  1-844 446 -4460 and Tom  ulx in Mountain View, California, USA 1-844
|  446 -4460 . After the success  of wynn POGO GAMES CONTACT for
|  individual financial management, the  company developed a similar
|  solution for small business owners.Intuit has  integrated several web-
|  based features into wynn POGO GAMES CONTACT ,  including remote access
|  capabilities, remote payroll assistance and  outsourcing, electronic
|  payment functions , banking and reconciliation,  mapping features
|  through integration with Google Maps, marketing options  through
|  Google, and im ved e-mail functionality through Microsoft Outlook  and
|  Outlook Express @1-844 446 -4460 . For the 2008 version, the company
|  has also added import from Excel spreadsheets, additional employee time
|  tracking options, pre-authorization of electronic funds and new Help
|  functions. In June 2007, Intuit announced that wynn POGO GAMES CONTACT
|  Enterprise Solutions would run on Linux servers, whereas previously it
|  required a Windows server to run ask them at 1-844 446 -4460 .
|  
|   Hi All, Facebook users have liked wynn POGO GAMES CONTACT technical
|  support phone number 1-844 -446 -4460 for the simple reason that the
|  service they got was excellent on www.facebook.com. Tripadvisor users
|  have  reviewed Intuit wynn POGO GAMES CONTACT Intuit Technical Support
|  Phone  number +1 844 446 4460 as the best on their forum
|  www.TripAdvisor.com.
|   Amazon also sells Intuit wynn POGO GAMES CONTACT Desktop tech support
|  phone number 1-844 -446 -4460 on its platform
|  https://na01.safelinks.protection.outlook.com/?url=www.amazon.com&data=
|  01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c3acbd55190fd4d9a312908d365
|  468ea0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1WZy64Fi6ba5pgbAxT6
|  oiVbM5CajYnAOL%2f0UxfsH0%2fo%3d because they  know it is a great
|  company. Apple users have been posting on
|  https://na01.safelinks.protection.outlook.com/?url=www.twitter.com&data
|  =01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c3acbd55190fd4d9a312908d36
|  5468ea0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=SSJZd2ZHdh7Uy07e1z
|  Y5dx9%2fSCcPgLDIf8ExkYH1%2bms%3d that Intuit tech support phone number
|  1-844 -446 -4460 is  the best. Apple also has a handle for Intuit wynn
|  POGO GAMES CONTACT tech  support phone number 1-844 -446 -4460 on their
|  app store www.apple.com.
|   Twitter gets a lot of tweets daily for wynn POGO GAMES CONTACT Care
|  phone  number 1-844 -446 -4460 . There are amazing videos of Intuit
|  wynn POGO  GAMES CONTACT Care phone number UA-75287313-11-844 -446 -
|  4460 on youtube  on their site
|  https://na01.safelinks.protection.outlook.com/?url=www.youtube.com&data
|  =01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c3acbd55190fd4d9a312908d36
|  5468ea0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=DoKTXMnIzYOV%2bEth
|  KQ7Zd9GLPDyl5HKDCQxujnIzwEc%3d they say it is great. wynn POGO GAMES
|  CONTACT technical support Helpline phone number 1-844 -446 -4460 is for
|  servicing to all USA / CANADA Customers as appeared in the Forbes
|  Magazine  2015. Forbes Magazine reviews say that wynn POGO GAMES
|  CONTACT technical  support Helpline number 1-844 -446 -4460 advisor and
|  Advisor are the best  Payroll Softwares in the USA / CANADA at the
|  moment. According to a survey  done by Forbes magazine BMW, Rolex,
|  Sony, Canon, Lego Group, Volkswagon,  Nestle, Intel, IBM,Rolls Royce
|  Aerospace etc are all the various clients  of wynn POGO GAMES CONTACT
|  technical support Helpline 1-844 -446 -4460 and  using their ducts.
|  Youtube videos have been telling us the story of Intuit  wynn POGO
|  GAMES CONTACT Technical Support Phone number +1 844 446 4460 on  the
|  url  &  . Intuit wynn POGO GAMES CONTACT Technical Support Phone number
|  +1 844 446
|   4460 has been the pioneer in the field of viding service in terms of
|  issues related to wynn POGO GAMES CONTACT , Payroll Support phone
|  number
|   1844 446 4460 , POGO GAMES CONTACT Tech support phone number 1844 446
|  4460  and advisor Tech support phone number 1844 446 4460 . Actionable
|  Analytics  for the Web has been witnessing an increase in the overall
|  pr ranking of  Intuit wynn POGO GAMES CONTACT Tech support phone number
|  1844 446 4460 due  to ever increasing traffic. Yahoo has a page and
|  landing platform for Tech  support phone number 1844 446 4460 users on
|  their Page on
|  https://na01.safelinks.protection.outlook.com/?url=wikipedia.org&data=0
|  1%7c01%7csimonpj%40064d.mgd.microsoft.com%7c3acbd55190fd4d9a312908d3654
|  68ea0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=5%2bxmWdaH6qgcEgg3Tk
|  VTLyHAI0BHlhXNtmIvzWHN2gI%3d
|   gives us an idea of the goodness Tech support phone number 1844 446
|  4460  achieves by catering to the customer issues from Australia / USA
|  / New  Zealand / UK and other countries. You can buy Tech support phone
|  number
|   1844 446 4460 from Electronics, Cars, Fashion, Collectibles, Coupons
|  and  More or Electronics, Cars, Fashion, Collectibles, Coupons and More
|  Shopping. the front page of the internet has been moting Tech support
|  phone number 1844 446 4460 stories through their platform. Intuit wynn
|  POGO GAMES CONTACT Technical Support @ 1-844 -446 -4460 is also one of
|  the  places that talks about Tech support phone number 1844 446 4460 .
|  You can  pay for Tech support phone number 1844 446 4460 through
|  https://na01.safelinks.protection.outlook.com/?url=www.paypal.com&data=
|  01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c3acbd55190fd4d9a312908d365
|  468ea0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=EKy5owRih1ZhgkrO2zH
|  KThnYuoqnxQql1g5V6yUSogQ%3d or  VISA or Master. Blogger have ranked
|  Tech support phone number 1844 446
|   4460 as number1. Stories of Tech support phone number 1844 446 4460
|  are  going on Breaking News, Daily News and Videos -
|  https://na01.safelinks.protection.outlook.com/?url=CNN.com&data=01%7c01
|  %7csimonpj%40064d.mgd.microsoft.com%7c3acbd55190fd4d9a312908d365468ea0%
|  7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=utFDBw2rWrxZvrBCTVfEyHKzkl
|  uLyI6EP4V%2b0mbviao%3d and ESPN: The  Worldwide Leader in Sports. If
|  you search Tech support phone number 1844
|   446 4460 on Go or Page on
|  https://na01.safelinks.protection.outlook.com/?url=craiglist.org&data=0
|  1%7c01%7csimonpj%40064d.mgd.microsoft.com%7c3acbd55190fd4d9a312908d3654
|  68ea0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=gPZQXPQmou%2fVI7ZxQL
|  VVUa%2bSbYLB5RXp2GDCdD1ocz0%3d you will know Tech support phone  number
|  1844 446 4460 is special. They vide best wynn POGO GAMES CONTACT
|  support. This is best toll free number 1844 -446 -4460 .this is
|  technical  support number for wynn POGO GAMES CONTACT 24|7.you can call
|  any time for  any blem of wynn POGO GAMES CONTACT like wynn POGO GAMES
|  CONTACT payroll,  wynn POGO GAMES CONTACT data recovery, wynn POGO
|  GAMES CONTACT Desktop  enterprises, wynn POGO GAMES CONTACT and
|  Quikbooks . Call on 1844 -446
|   -4460 . Call@ 1-844 -446 -4460 wynn POGO GAMES CONTACT tech support ,
|  wynn  POGO GAMES CONTACT Tech Support Phone Number USA , wynn POGO
|  GAMES CONTACT  Technical Support phone Number, wynn POGO GAMES CONTACT
|  support phone  number , wynn POGO GAMES CONTACT support phone number
|  USA , wynn POGO  GAMES CONTACT technical support number USA , wynn POGO
|  GAMES CONTACT tech  support telephone number, wynn POGO GAMES CONTACT
|  help phone number,  Intuit technical support phone number, wynn POGO
|  GAMES CONTACT support  number , Quickbook tech support phone number,
|  Intuit wynn POGO GAMES  CONTACT Desktop tech support phone number, wynn
|  POGO GAMES CONTACT  enterprise support phone number, wynn POGO GAMES
|  CONTACT component repair  tool for windows xp|vista|7 , wynn POGO GAMES
|  CONTACT Desktop not  connecting to internet. wynn POGO GAMES CONTACT
|  unsupported system  configuration, Dealing some random error message
|  installing wynn POGO  GAMES CONTACT , wynn POGO GAMES CONTACT Data
|  export or import issues, wynn  POGO GAMES CONTACT failed to make an
|  internet connection, wynn POGO GAMES  CONTACT multi user mode not
|  syncing, wynn POGO GAMES CONTACT not opening  in multi-user mode, wynn
|  POGO GAMES CONTACT payroll support phone number
|   1-844 -446 -4460 .wynn POGO GAMES CONTACT payroll support phone number
|   1-844 -446 -4460 . Showing error while updating company data file in
|  wynn  POGO GAMES CONTACT , wynn POGO GAMES CONTACT Desktop is a crucial
|  tool for  businesses according to the Forbes magazine. It helps
|  organizations manage  their money, pay their employees, and pay their
|  bills. But wynn POGO GAMES  CONTACT Desktop is also a fairly complex
|  application. This complexity  means that wynn POGO GAMES CONTACT is ne
|  to having blems like how to  restore wynn POGO GAMES CONTACT auto data
|  recovery, wynn POGO GAMES  CONTACT Connection blem and connection
|  configuration, wynn POGO GAMES  CONTACT Installation Support Phone
|  Number, wynn POGO GAMES CONTACT Company  File Not Opening in Multi User
|  Mode, wynn POGO GAMES CONTACT Keeps  Disconnecting From Server, wynn
|  POGO GAMES CONTACT Error Message Server  Busy, wynn POGO GAMES CONTACT
|  Payroll Tech Support Phone Number, wynn POGO  GAMES CONTACT Data File
|  Needs To Be Updated. wynn POGO GAMES CONTACT Data  File Recovery
|  Extention, wynn POGO GAMES CONTACT UA-75287313-1connection  has been
|  lost, wynn POGO GAMES CONTACT Desktop Installation Error
|  1722,1334,15215&1904, wynn POGO GAMES CONTACT Desktop error code
|  6000,3371, wynn POGO GAMES CONTACT error code message H-303 & H-202.
|  You  can search on Google or Bing but you cannot get these issues
|  resolved.
|   When something goes wrong with wynn POGO GAMES CONTACT , the
|  consequences  can be pretty dire. Luckily, many common blems are easy
|  to fix -- once you  know about them. Our wynn POGO GAMES CONTACT level
|  5 technicians are  available for fix any queries all ducts of wynn POGO
|  GAMES CONTACT . We  vide best service of any blems. Call us anytime
|  24|7 on 1844 -446 -4460  for technical support. We are ready to fix
|  your blems of wynn POGO GAMES  CONTACT Desktop . This is our best
|  customer care service. Contact us for  resolve your any wynn POGO GAMES
|  CONTACT blems.
|   #New York, New York
|   #Los Angeles, California
|   #Chicago, Illinois
|   #Houston, Texas
|   #Philadelphia, Pennsylvania
|   #Phoenix, Arizona
|   #San Diego, California
|   #San Antonio, Texas
|   #Dallas, Texas
|   #Detroit, Michigan
|   #San Jose, California
|   #Indianapolis, Indiana
|   #Jacksonville, Florida
|   #San Francisco, California
|   #Columbus, Ohio
|   #Austin, Texas
|   #Memphis, Tennessee
|   #Baltimore, Maryland
|   #Charlotte, North Carolina
|   #Fort Worth, Texas
|   #Boston, Massachusetts
|   #Milwaukee, Wisconsin
|   #El Paso, Texas
|   #Washington, District of Columbia
|   #Nashville-Davidson, Tennessee
|   #Seattle, Washington
|   #Denver, Colorado
|   #Las Vegas, Nevada
|   #Portland, Oregon
|   #Oklahoma City, Oklahoma
|   #Tucson, Arizona
|   #Albuquerque, New Mexico
|   #Atlanta, Georgia
|   #Long Beach, California
|   #Kansas City, Missouri
|   #Fresno, California
|   #New Orleans, Louisiana
|   #Cleveland, Ohio
|   #Sacramento, California
|   #Mesa, Arizona
|   #Virginia Beach, Virginia
|   #Omaha, Nebraska
|   #Colorado Springs, Colorado
|   #Oakland, California
|   #Miami, Florida
|   #Tulsa, Oklahoma
|   #Minneapolis, Minnesota
|   #Honolulu, Hawaii
|   #Arlington, Texas
|   #Wichita, Kansas
|   #St. Louis, Missouri
|   #Raleigh, North Carolina
|   #Santa Ana, California
|   #Cincinnati, Ohio
|   #Anaheim, California
|   #Tampa, Florida
|   #Toledo, Ohio
|   #Pittsburgh, Pennsylvania
|   #Aurora, Colorado
|   #Bakersfield, California
|   #Riverside, California
|   #Stockton, California
|   #Corpus Christi, Texas
|   #Lexington-Fayette, Kentucky
|   #Buffalo, New York
|   #St. Paul, Minnesota
|   #Anchorage, Alaska
|   #Newark, New Jersey
|   #Plano, Texas
|   #Fort Wayne, Indiana
|   #St. Petersburg, Florida
|   #Glendale, Arizona
|   #Lincoln, Nebraska
|   #Norfolk, Virginia
|   #Jersey City, New Jersey
|   #Greensboro, North Carolina
|   #Chandler, Arizona
|   #Birmingham, Alabama
|   #Henderson, Nevada
|   #Scottsdale, Arizona
|   #North Hempstead, New York
|   #Madison, Wisconsin
|   #Hialeah, Florida
|   #Baton Rouge, Louisiana
|   #Chesapeake, Virginia
|   #Orlando, Florida
|   #Lubbock, Texas
|   #Garland, Texas
|   #Akron, Ohio
|   #Rochester, New York
|   #Chula Vista, California
|   #Reno, Nevada
|   #Laredo, Texas
|   #Durham, North Carolina
|   #Modesto, California
|   #Huntington, New York
|   #Montgomery, Alabama
|   #Boise, Idaho
|   #Arlington, Virginia
|   #San Bernardino, California
|   #New York
|   #Los Angeles
|   #Chicago
|   #Houston
|   #Philadelphia
|   #Phoenix
|   #San Diego
|   #San Antonio
|   #Dallas
|   #Detroit
|   #San Jose
|   #Indianapolis
|   #Jacksonville
|   #San Francisco
|   #Columbus
|   #Austin
|   #Memphis
|   #Baltimore
|   #Charlotte
|   #Fort Worth
|   #Boston
|   #Milwaukee
|   #El Paso
|   #Washington
|   #Nashville-Davidson
|   #Seattle
|   #Denver
|   #Las Vegas
|   #Portland
|   #Oklahoma City
|   #Tucson
|   #Albuquerque
|   #Atlanta
|   #Long Beach
|   #Kansas City
|   #Fresno
|   #New Orleans
|   #Cleveland
|   #Sacramento
|   #Mesa
|   #Virginia Beach
|   #Omaha
|   #Colorado Springs
|   #Oakland
|   #Miami
|   #Tulsa
|   #Minneapolis
|   #Honolulu
|   #Arlington
|   #Wichita
|   #St. Louis
|   #Raleigh
|   #Santa Ana
|   #Cincinnati
|   #Anaheim
|   #Tampa
|   #Toledo
|   #Pittsburgh
|   #Aurora
|   #Bakersfield
|   #Riverside
|   #Stockton
|   #Corpus Christi
|   #Lexington-Fayette
|   #Buffalo
|   #St. Paul
|   #Anchorage
|   #Newark
|   #Plano
|   #Fort Wayne
|   #St. Petersburg
|   #Glendale
|   #Lincoln
|   #Norfolk
|   #Jersey City
|   #Greensboro
|   #Chandler
|   #Birmingham
|   #Henderson
|   #Scottsdale
|   #North Hempstead
|   #Madison
|   #Hialeah
|   #Baton Rouge
|   #Chesapeake
|   #Orlando
|   #Lubbock
|   #Garland
|   #Akron
|   #Rochester
|   #Chula Vista
|   #Reno
|   #Laredo
|   #Durham
|   #Modesto
|   #Huntington
|   #Montgomery
|   #Boise
|   #Arlington
|   #San Bernardino
|   #Alabama
|   #Alaska
|   #Arizona
|   #Arkansas
|   #California
|   #Colorado
|   #Connecticut
|   #Delaware
|   #Florida
|   #Georgia
|   #Hawaii
|   #Idaho
|   #Illinois
|   #Indiana
|   #Iowa
|   #Kansas
|   #Kentucky
|   #Louisiana
|   #Maine
|   #Maryland
|   #Massachusetts
|   #Michigan
|   #Minnesota
|   #Mississippi
|   #Missouri
|   #Montana
|   #Nebraska
|   #Nevada
|   #New Hampshire
|   #New Jersey
|   #New Mexico
|   #New York
|   #North Carolina
|   #North Dakota
|   #Ohio
|   #Oklahoma
|   #Oregon
|   #Pennsylvania
|   #Rhode Island
|   #South Carolina
|   #South Dakota
|   #Tennessee
|   #Texas
|   #Utah
|   #Vermont
|   #Virginia
|   #Washington
|   #West Virginia
|   #Wisconsin
|   #Wyoming
|  
|  --
|  Ticket URL:
|  <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.ha
|  skell.org%2ftrac%2fghc%2fticket%2f11900&data=01%7c01%7csimonpj%40064d.m
|  gd.microsoft.com%7c3acbd55190fd4d9a312908d365468ea0%7c72f988bf86f141af9
|  1ab2d7cd011db47%7c1&sdata=lqrdx8aRfLDLuJqeXLViK3IKwaqrW1B11hjtPxQhbZ8%3
|  d>
|  GHC
|  <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ha
|  skell.org%2fghc%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c3a
|  cbd55190fd4d9a312908d365468ea0%7c72f988bf86f141af91ab2d7cd011db47%7c1&s
|  data=O%2fh6%2facT1j5z%2f7GSFnbbZqKxBG9Mtmk%2fiJ6bYYz8jCk%3d>
|  The Glasgow Haskell Compiler
|  _______________________________________________
|  ghc-tickets mailing list
|  ghc-tickets at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  tickets&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c3acbd55190fd4
|  d9a312908d365468ea0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=eyU35%
|  2b12Qp8UAwJ6TTjRoUE9Kmm5EPh91cv7NRwHBPA%3d

From ben at well-typed.com  Fri Apr 15 17:48:08 2016
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 15 Apr 2016 19:48:08 +0200
Subject: trac span
In-Reply-To: <2df6cb968f364a9fb178f2e596a08359@DB4PR30MB030.064d.mgd.msft.net>
References: <2df6cb968f364a9fb178f2e596a08359@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <874mb2yd9j.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> Ben, can you switch off Trac edits until you've found a way to plug this?
>
I think I finally have things under control although I still have a
close eye on the spam monitoring page.

I've enabled Trac's support external spam filtering services, which
provide a bit more evidence in the event that the local spambayes filter
is uncertain.

Cheers,

- Ben

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

From simonpj at microsoft.com  Fri Apr 15 21:18:33 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 15 Apr 2016 21:18:33 +0000
Subject: [Diffusion] [Build Failed] rGHCa7ee2d4c4229: Improve
 TcFlatten.flattenTyVar
In-Reply-To: <20160415210231.88650.93237.516CA84F@phabricator.haskell.org>
References: <diffusion-audit-PHID-CMIT-7gxdnlmftrr73yvh43ae@phabricator.haskell.org>
 <20160415210231.88650.93237.516CA84F@phabricator.haskell.org>
Message-ID: <a18dcf5d42294e94873334345b888d32@AM3PR30MB019.064d.mgd.msft.net>

I can't see what's going wrong from the log. Works for me!

Simon

| -----Original Message-----
| From: noreply at phabricator.haskell.org
| [mailto:noreply at phabricator.haskell.org]
| Sent: 15 April 2016 22:03
| To: Simon Peyton Jones <simonpj at microsoft.com>
| Subject: [Diffusion] [Build Failed] rGHCa7ee2d4c4229: Improve
| TcFlatten.flattenTyVar
| 
| Harbormaster failed to build B9191: rGHCa7ee2d4c4229: Improve
| TcFlatten.flattenTyVar!
| 
| BRANCHES
|   master
| 
| USERS
|   simonpj (Author)
|   GHC - Testsuite (Auditor)
|   GHC - Type checker/inferencer (Auditor)
| 
| COMMIT
|   https://phabricator.haskell.org/rGHCa7ee2d4c4229
| 
| EMAIL PREFERENCES
|   https://phabricator.haskell.org/settings/panel/emailpreferences/
| 
| To: simonpj, GHC - Testsuite, GHC - Type checker/inferencer, Harbormaster

From ben at well-typed.com  Fri Apr 15 22:15:17 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 16 Apr 2016 00:15:17 +0200
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <5711454E.2060706@centrum.cz>
References: <87egadbj2w.fsf@smart-cactus.org> <570A8A85.8070102@apeiron.net>
 <87bn5hbbaf.fsf@smart-cactus.org> <8760voc3jn.fsf@smart-cactus.org>
 <5711454E.2060706@centrum.cz>
Message-ID: <87wpnywmbu.fsf@smart-cactus.org>

Karel Gardas <karel.gardas at centrum.cz> writes:

> Hi Ben,
>
> just got back from business trip and attempting to build distros for you 
> I've found that:
>
> karel at silence:~/Downloads/GHC/8.0.1/rc3$ gpg2 --verify 
> ghc-8.0.0.20160411-src.tar.xz.sig
> Warning: using insecure memory!
> gpg: Signature made April 11, 2016 03:23:45 AM CEST using RSA key ID 
> 97DB64AD
> gpg: BAD signature from "Benjamin Gamari <ben at well-typed.com>"
>
It seems that the issue was once again my inability to convince the
content delivery network to fully purge its cache. Thanks for realizing
this issue.

On the bright side, I think I have finally worked out how to reliably
flush the cache so hopefully there will be no further issues of this
tiresome sort.

Unfortunately it's quite unclear what to do about your binary
distribution as it's likely derived from the wrong source tree.
As we will likely have to do a fourth release candidate anyways (due to
the template haskell issue brought up by Iavor today), perhaps it would
be best just to wait until then before sinking any more of your time
into further builds. It likely won't be long before we have another
source tree available although I'll leave the decision to you.

Cheers,

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

From mail at nh2.me  Sat Apr 16 00:40:15 2016
From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=)
Date: Sat, 16 Apr 2016 02:40:15 +0200
Subject: Spam filtering
In-Reply-To: <877ffyyjpj.fsf@smart-cactus.org>
References: <877ffyyjpj.fsf@smart-cactus.org>
Message-ID: <571189EF.2020101@nh2.me>

Hi Ben,

Could we not have a captcha instead of a reject, to avoid false positives? That would require no training.

Since I assume most Trac spammers are extremely unsophisticated, a simple hardcoded question like "What programming language is GC all about?" may be sufficient.

On 15/04/16 17:28, Ben Gamari wrote:
>
> Hello GHCers,
>
> As you may have noticed, the GHC Trac instance is currently being hit
> with a significant amount of spam traffic recently. I believe I've
> cleared up most of the garbage and the filter configuration has been
> tightened so that future spam attacks will be easier to quell.
>
> Of course, this tightening means that there is a greater chance of false
> positives. If you do find that your ticket comments or Wiki edits are
> being rejected by the spam filter, please notify either Austin or me so
> that we can train the filter on your example.
>
> 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  Sat Apr 16 09:18:01 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 16 Apr 2016 11:18:01 +0200
Subject: Spam filtering
In-Reply-To: <571189EF.2020101@nh2.me>
References: <877ffyyjpj.fsf@smart-cactus.org> <571189EF.2020101@nh2.me>
Message-ID: <87shylx67q.fsf@smart-cactus.org>

Niklas Hamb?chen <mail at nh2.me> writes:

> Hi Ben,
>
> Could we not have a captcha instead of a reject, to avoid false
> positives? That would require no training.
>
> Since I assume most Trac spammers are extremely unsophisticated, a
> simple hardcoded question like "What programming language is GC all
> about?" may be sufficient.
>
The CAPTCHAs being broken are the reason why this incident occurred.
I have added some more CAPTCHAs to try to dilute the pool of answers
that they already know, but they still seem to solve them easily
enough regardless. I can only imagine they have some sentient beings
sitting at computers solving CAPTCHAs.

I don't really feel like we can make the CAPTCHAs themselves any more
difficult without excluding real new users, which I really want to avoid.

Regardless, my goal here is to error on the side of less filtering, not
more, even if this does mean more manual maintenance. To this end, I've
configured the filters such that the probability of legitimate activity
being suppressed should be negligible,

 * I've been careful to only train the Bayes filter on obvious spam;
   I have tested it against various snippets from the wiki and mailing
   list and have yet to see it score anything legitimate with a spam
   likelihood > 5%.

 * Even if the Bayes filter does deem your content to be spammy enough
   to warrant further attention, you will merely be asked to solve a
   CAPTCHA. Posts will not be outright rejected unless it is quite clear
   that they are spam.

I am optimistic that the filtering will have negligible effect on
legitimate traffic. As a smoke test I managed to create a new account,
open a new ticket, and start a new Wiki page without even needing to
solve a CAPTCHA.

Cheers,

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

From ben at well-typed.com  Sat Apr 16 12:19:25 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 16 Apr 2016 14:19:25 +0200
Subject: [GHC] #11824: GHC error in desugarer lookup
In-Reply-To: <1740ed3287ad411c9e803d17816e22cc@DB4PR30MB030.064d.mgd.msft.net>
References: <046.bef37bafb0de36b55d56e17189a8ba9e@haskell.org>
 <061.6a21d313942a94900735c0c8a7674929@haskell.org>
 <9732b66656ae46bbb57ac6142c505972@DB4PR30MB030.064d.mgd.msft.net>
 <8737qpfwea.fsf@smart-cactus.org>
 <1740ed3287ad411c9e803d17816e22cc@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <87potpwxte.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> |  If the latter there is no reason to fear: TcBinds.addTypecheckedBinds
> |  (which TcTypeable uses) ensures that no bindings are added to the
> |  environment if we are compiling a boot module,
>
> Ah, I had missed that; it's pretty deeply hidden.
>
> Suggestion:
>
> * Move tcRecSelBinds from tcAddImplicits, to mkTypeableBinds.
>   More precisely, make a new function addDerivedBindings, which
>     * add record-selector bindings (via tcRecSelBinds)
>     * adds typeable bindings (via mkTypableBinds)
>   and call it where we currently call mkTypeableBinds.
>
> * Instead of burying the "drop the bindings" deep in addTypecheckedBinds,
>   inline it into addDerivedBindings:
>    - make mkTypeableBinds *return* bindings rather than extending gbl-env
>    - ditto tcRecSelBinds
>   Then addDerivedBinds can test hs-boot, and extend the tcg_binds if necessary
>
> That would put the two together nicely, they really are very similar.
>
Lumping Typeable binding generation in with record selector generation
is tricky...

The problem is this: we must generate and typecheck record selectors on
a per-group basis, since they may be used by later groups. However, to
generate Typeable TyCon bindings we need to first generate a Module
binding. However, we should only generate one Module binding per
typechecked module, so this clearly can't be done per-group; moreover
the Module binding can only be generated after types have been
typechecked (since we may be generating bindings for GHC.Types, where
Module itself is defined).

The alternative here is to wire-in the Module and TyCon types, which I
did previously but this lead to ticket:11120#comment:31. All of this is
quite tiresome and I suspect things would be on the whole simpler if we
just went back to wiring in these types, but that would require that we
find a way to address comment:31.

Of course, comment:31 itself would be moot if we could always rely on
word64PrimTy being available, even on 64-bit architectures. I have long
wondered why this isn't the case as it's a nasty inconsistency which
adds a fair amount of ugliness in unexpected places (see, for instance,
the definition of Word64 in GHC.Word). It seems to me like you should be
able to use Word# if you just want a word-sized type and Word64# if you
want a 64-bit type (regardless of the machine's word-size).

Perhaps fixing this would and returning to wiring-in Module and TyCon be
the easiest way forward. This would allow us to emit a Module binding at
the beginning of typechecking and then emit TyCons in a per-group
manner, just as we do for record selectors. Thoughts?

Future plans aside,, would you be okay with pushing D2108 to the ghc-8.0
branch as-is in the interest of moving the release along?

Cheers,

- Ben

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

From eir at cis.upenn.edu  Sat Apr 16 14:02:12 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Sat, 16 Apr 2016 10:02:12 -0400
Subject: Reification of out-of-scope variables?
In-Reply-To: <02700e82027346eea0d10776603e6610@DB4PR30MB030.064d.mgd.msft.net>
References: <CAJ0eudrYKW=+s25+G9x_3AQNJTU2Uqj18uZfbzZedF2p8oq=LQ@mail.gmail.com>
 <266BEB36-AA3D-4049-84F7-138C6FF7539A@cis.upenn.edu>
 <CA+Q==SDrdJBAKWt4ULwgYpPu0vHwz-WqSK4U1upTaA2DTtGPAQ@mail.gmail.com>
 <1DA2B8DB-1830-44A4-9564-F3B508771909@cis.upenn.edu>
 <CAJ0eudoNEa-dpSNwT1fhPxdQr6CpYvsuexVJNoxowoDu6KBahA@mail.gmail.com>
 <02700e82027346eea0d10776603e6610@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <6A50C2C2-3AEA-4AFF-94BA-C24D4F8184F4@cis.upenn.edu>


On Apr 15, 2016, at 11:51 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> Hang on!  The design for typed splices, describe here,
> https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/BlogPostChanges
> says "Unlike TH, the only way to construct a value of type TExp is with a quote. You cannot drop into do-notation, nor use explicit construction of the values in the Exp algebraic data type. That restriction limits expressiveness, but it enables the strong typing guarantees." 
> 
> So why does the above work?  $$(e) requires a TExp, and do-notation doesn?t produce a TExp.

Indeed this is true -- this is what that page says. But it's not what's implemented: when I say $$( _ ) :: Bool, GHC tells me that the hole has type Q (TExp Bool).

There still is no way to create a TExp other than to use a type TH quote.

Addressing your other message: a typed quasiquoter would be somewhat limited, but not utterly silly. For example, this works:

> bool :: String -> Q (TExp Bool)
> bool "true"  = [|| True ||]
> bool "false" = [|| False ||]
> bool _ = fail "not a bool"
> 
> -- and then, in another module because of the stage restriction:
> yes :: Bool
> yes = $$(bool "true")

Now `bool` could be a typed quasiquoter.

I don't know whether any of this is worth implementing, but it's not, a priori, a terrible idea.

Richard

> 
> |  * Should we consider it a bug (and file a ticket) that reification in
> |  typed splices is able to observe the order of type checking, just like
> |  reify used to do in untyped splices?
> 
> Yes I think so!!!
> 
> Simon
> 


From simonpj at microsoft.com  Sat Apr 16 19:35:18 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Sat, 16 Apr 2016 19:35:18 +0000
Subject: [GHC] #11824: GHC error in desugarer lookup
In-Reply-To: <87potpwxte.fsf@smart-cactus.org>
References: <046.bef37bafb0de36b55d56e17189a8ba9e@haskell.org>
 <061.6a21d313942a94900735c0c8a7674929@haskell.org>
 <9732b66656ae46bbb57ac6142c505972@DB4PR30MB030.064d.mgd.msft.net>
 <8737qpfwea.fsf@smart-cactus.org>
 <1740ed3287ad411c9e803d17816e22cc@DB4PR30MB030.064d.mgd.msft.net>
 <87potpwxte.fsf@smart-cactus.org>
Message-ID: <088a28f63117490787bf2e118ff84c99@DB4PR30MB030.064d.mgd.msft.net>

| The problem is this: we must generate and typecheck record selectors on
| a per-group basis, since they may be used by later groups.

Why?  Record selectors are value bindings which aren't used when typechecking data types.

| Future plans aside,, would you be okay with pushing D2108 to the ghc-8.0
| branch as-is in the interest of moving the release along?

I guess so.  But at least prominently comment the bit I missed.

Simon

From ben at well-typed.com  Sun Apr 17 09:44:04 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 17 Apr 2016 11:44:04 +0200
Subject: [GHC] #11824: GHC error in desugarer lookup
In-Reply-To: <088a28f63117490787bf2e118ff84c99@DB4PR30MB030.064d.mgd.msft.net>
References: <046.bef37bafb0de36b55d56e17189a8ba9e@haskell.org>
 <061.6a21d313942a94900735c0c8a7674929@haskell.org>
 <9732b66656ae46bbb57ac6142c505972@DB4PR30MB030.064d.mgd.msft.net>
 <8737qpfwea.fsf@smart-cactus.org>
 <1740ed3287ad411c9e803d17816e22cc@DB4PR30MB030.064d.mgd.msft.net>
 <87potpwxte.fsf@smart-cactus.org>
 <088a28f63117490787bf2e118ff84c99@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <87fuukwowr.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> | The problem is this: we must generate and typecheck record selectors on
> | a per-group basis, since they may be used by later groups.
>
> Why?  Record selectors are value bindings which aren't used when typechecking data types.
>
Yes, they are value bindings and may be used in bindings in later
groups. For instance, let's consider the following,

    data ARecord = ARecord { aField :: Int }

    $(return [])   -- group delimiter

    aFieldIncr :: ARecord -> Int
    aFieldIncr = succ . aField

My point in,

> | we must generate and typecheck record selectors on a per-group basis

is that we must generate the `aField` binding before proceeding to
typecheck the second group (containing `aFieldIncr`). Failing to do this
would result in `aField` being out of scope when we attempted to
typecheck the RHS of `aFieldIncr`. Perhaps I have misunderstood?

Cheers,

- Ben

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

From carter.schonwald at gmail.com  Sun Apr 17 13:32:06 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 17 Apr 2016 09:32:06 -0400
Subject: Whither default build variables for make files?
Message-ID: <CAHYVw0xB-NFTk1j957thHFCNZtg-mvtWDJugrGM3F87aPyTPaA@mail.gmail.com>

Hey all,
I just did a checkout of the tip of ghc 8.0 branch and it looks like the
build.mk files have seen a bit of reorganization! Now for the perf aka
release  build the various doc variavles seem to be implicitly set
somewhere else and I got a bit lost when trying to dig them up.

On the flip side : is the shake build system alternative mature enough for
it to be reasonable to attempt using it on my Mac ?

Many thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160417/442ac7dd/attachment.html>

From carter.schonwald at gmail.com  Sun Apr 17 13:34:32 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 17 Apr 2016 09:34:32 -0400
Subject: Spam filtering
In-Reply-To: <87shylx67q.fsf@smart-cactus.org>
References: <877ffyyjpj.fsf@smart-cactus.org> <571189EF.2020101@nh2.me>
 <87shylx67q.fsf@smart-cactus.org>
Message-ID: <CAHYVw0xh-XzxTJGqw3JXJZ4A6R5w4WW_mMgNOCQKa01egZgy2A@mail.gmail.com>

Question: are we talking captcha or REcaptcha?
My understanding is that REcaptcha is better than old school captcha

Have we evaluated it as an option?
http://www.google.com/recaptcha/intro/index.html

On Saturday, April 16, 2016, Ben Gamari <ben at well-typed.com> wrote:

> Niklas Hamb?chen <mail at nh2.me <javascript:;>> writes:
>
> > Hi Ben,
> >
> > Could we not have a captcha instead of a reject, to avoid false
> > positives? That would require no training.
> >
> > Since I assume most Trac spammers are extremely unsophisticated, a
> > simple hardcoded question like "What programming language is GC all
> > about?" may be sufficient.
> >
> The CAPTCHAs being broken are the reason why this incident occurred.
> I have added some more CAPTCHAs to try to dilute the pool of answers
> that they already know, but they still seem to solve them easily
> enough regardless. I can only imagine they have some sentient beings
> sitting at computers solving CAPTCHAs.
>
> I don't really feel like we can make the CAPTCHAs themselves any more
> difficult without excluding real new users, which I really want to avoid.
>
> Regardless, my goal here is to error on the side of less filtering, not
> more, even if this does mean more manual maintenance. To this end, I've
> configured the filters such that the probability of legitimate activity
> being suppressed should be negligible,
>
>  * I've been careful to only train the Bayes filter on obvious spam;
>    I have tested it against various snippets from the wiki and mailing
>    list and have yet to see it score anything legitimate with a spam
>    likelihood > 5%.
>
>  * Even if the Bayes filter does deem your content to be spammy enough
>    to warrant further attention, you will merely be asked to solve a
>    CAPTCHA. Posts will not be outright rejected unless it is quite clear
>    that they are spam.
>
> I am optimistic that the filtering will have negligible effect on
> legitimate traffic. As a smoke test I managed to create a new account,
> open a new ticket, and start a new Wiki page without even needing to
> solve a CAPTCHA.
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160417/3ca1002a/attachment.html>

From ben at well-typed.com  Sun Apr 17 13:59:33 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 17 Apr 2016 15:59:33 +0200
Subject: Spam filtering
In-Reply-To: <CAHYVw0xh-XzxTJGqw3JXJZ4A6R5w4WW_mMgNOCQKa01egZgy2A@mail.gmail.com>
References: <877ffyyjpj.fsf@smart-cactus.org> <571189EF.2020101@nh2.me>
 <87shylx67q.fsf@smart-cactus.org>
 <CAHYVw0xh-XzxTJGqw3JXJZ4A6R5w4WW_mMgNOCQKa01egZgy2A@mail.gmail.com>
Message-ID: <87a8kswd2y.fsf@smart-cactus.org>

Carter Schonwald <carter.schonwald at gmail.com> writes:

> Question: are we talking captcha or REcaptcha?
> My understanding is that REcaptcha is better than old school captcha
>
> Have we evaluated it as an option?
> http://www.google.com/recaptcha/intro/index.html
>
We are using a GHC-specific CAPTCHA generator written by thomie. 

We could switch to reCAPTCHA if there is a compelling reason but at the
moment things seem to work reasonably well so I'm not inclined to touch
it.

Cheers,

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

From carter.schonwald at gmail.com  Sun Apr 17 14:46:10 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 17 Apr 2016 10:46:10 -0400
Subject: Spam filtering
In-Reply-To: <87a8kswd2y.fsf@smart-cactus.org>
References: <877ffyyjpj.fsf@smart-cactus.org> <571189EF.2020101@nh2.me>
 <87shylx67q.fsf@smart-cactus.org>
 <CAHYVw0xh-XzxTJGqw3JXJZ4A6R5w4WW_mMgNOCQKa01egZgy2A@mail.gmail.com>
 <87a8kswd2y.fsf@smart-cactus.org>
Message-ID: <CAHYVw0w6v_e5i2_abjds8kR2AS7Re-412ASYkcMHhSKVwUsk3A@mail.gmail.com>

Gotcha.

On Sunday, April 17, 2016, Ben Gamari <ben at well-typed.com> wrote:

> Carter Schonwald <carter.schonwald at gmail.com <javascript:;>> writes:
>
> > Question: are we talking captcha or REcaptcha?
> > My understanding is that REcaptcha is better than old school captcha
> >
> > Have we evaluated it as an option?
> > http://www.google.com/recaptcha/intro/index.html
> >
> We are using a GHC-specific CAPTCHA generator written by thomie.
>
> We could switch to reCAPTCHA if there is a compelling reason but at the
> moment things seem to work reasonably well so I'm not inclined to touch
> it.
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160417/7c07366b/attachment.html>

From rf at rufflewind.com  Sun Apr 17 15:25:01 2016
From: rf at rufflewind.com (rf at rufflewind.com)
Date: Sun, 17 Apr 2016 11:25:01 -0400
Subject: directory and GHC 8.0.1
In-Reply-To: <87h9f3xdrg.fsf@smart-cactus.org>
References: <87d1q24j0g.fsf@smart-cactus.org>
 <1459976919.2379569.571159985.696D36D2@webmail.messagingengine.com>
 <87a8l64bzd.fsf@smart-cactus.org>
 <1460000148.3221856.571408153.7456C7C7@webmail.messagingengine.com>
 <877fg94xtq.fsf@smart-cactus.org>
 <1460632519.1473955.578559009.58BCE9FF@webmail.messagingengine.com>
 <87h9f3xdrg.fsf@smart-cactus.org>
Message-ID: <1460906701.3782749.581243577.01B40E05@webmail.messagingengine.com>

I've bumped directory to 1.2.6.1 now after your PR (#47).  Since it's a
rather critical issue, GHC's submodule should be updated to this
version.

Thanks,
RF

From ben at well-typed.com  Mon Apr 18 07:57:45 2016
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 18 Apr 2016 09:57:45 +0200
Subject: Phabricator build failures
In-Reply-To: <1460670299.2121.7.camel@joachim-breitner.de>
References: <1460670299.2121.7.camel@joachim-breitner.de>
Message-ID: <871t63wdqe.fsf@smart-cactus.org>

Joachim Breitner <mail at joachim-breitner.de> writes:

> [ Unknown signature status ]
> Hi,
>
> some recent commits on GHC HEAD fail to validate on phabricator, all
> with a segfault in the tests, but in an different tests each (or
> sometimes no failure at all).
>
> This this known?
>
I know about the the issue although I don't have access to the machine
so haven't yet been able to look into it. Austin, perhaps you could
check or let me know how I can do so myself?

Cheers,

- Ben

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

From andrey.mokhov at newcastle.ac.uk  Mon Apr 18 12:18:30 2016
From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov)
Date: Mon, 18 Apr 2016 12:18:30 +0000
Subject: Whither default build variables for make files?
In-Reply-To: <mailman.5.1460980801.13937.ghc-devs@haskell.org>
References: <mailman.5.1460980801.13937.ghc-devs@haskell.org>
Message-ID: <AM3PR07MB118733504C5A17332D3CEFF4A56B0@AM3PR07MB1187.eurprd07.prod.outlook.com>

Hi Carter,

> On the flip side : is the shake build system alternative mature enough
> for it to be reasonable to attempt using it on my Mac ?

Here are the limitations of the Shake build system:

https://github.com/snowleopard/shaking-up-ghc#current-limitations

If you are not put off by them, please give the new build system a try!

Cheers,
Andrey


From simonpj at microsoft.com  Mon Apr 18 13:14:10 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 18 Apr 2016 13:14:10 +0000
Subject: Should TH TExp be able use the Q monad
Message-ID: <7fefdb2ab3e24056875b8690be00873f@DB4PR30MB030.064d.mgd.msft.net>

|  > Hang on!  The design for typed splices, describe here,
|  > https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/BlogPostChanges
|  > says "Unlike TH, the only way to construct a value of type TExp is
|  with a quote. You cannot drop into do-notation, nor use explicit
|  construction of the values in the Exp algebraic data type. That
|  restriction limits expressiveness, but it enables the strong typing
|  guarantees."
|  >
|  > So why does the above work?  $$(e) requires a TExp, and do-notation
|  doesn?t produce a TExp.
|  
|  Indeed this is true -- this is what that page says. But it's not what's
|  implemented: when I say $$( _ ) :: Bool, GHC tells me that the hole has
|  type Q (TExp Bool).
|  There still is no way to create a TExp other than to use a type TH quote

Humph.  I suppose that provided you can't forge a TExp, there's no way to splice in a type-incorrect program; and having Q available lets you (say) do input/output or consult the context to decide which of two quotes to return.

We could do this selectively.  For example we'd certainly need (TExp t) to be able to fail

> bool :: String -> TExp Bool
> bool "true"  = [|| True ||]
> bool "false" = [|| False ||]
> bool _ = failTexp "not a bool"

My instinct is to make it less expressive, though, and only allow (TExp t) as the argument of $$. 

Does anyone care either way?   I suppose we'd better open a ticket for this.

Simon

|  
|  quote.
|  
|  Addressing your other message: a typed quasiquoter would be somewhat
|  limited, but not utterly silly. For example, this works:
|  
|  > bool :: String -> Q (TExp Bool)
|  > bool "true"  = [|| True ||]
|  > bool "false" = [|| False ||]
|  > bool _ = fail "not a bool"
|  >
|  > -- and then, in another module because of the stage restriction:
|  > yes :: Bool
|  > yes = $$(bool "true")
|  
|  Now `bool` could be a typed quasiquoter.
|  
|  I don't know whether any of this is worth implementing, but it's not, a
|  priori, a terrible idea.
|  
|  Richard
|  
|  >
|  > |  * Should we consider it a bug (and file a ticket) that reification
|  > | in  typed splices is able to observe the order of type checking,
|  > | just like  reify used to do in untyped splices?
|  >
|  > Yes I think so!!!
|  >
|  > Simon
|  >


From eir at cis.upenn.edu  Mon Apr 18 13:35:48 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 18 Apr 2016 09:35:48 -0400
Subject: Should TH TExp be able use the Q monad
In-Reply-To: <7fefdb2ab3e24056875b8690be00873f@DB4PR30MB030.064d.mgd.msft.net>
References: <7fefdb2ab3e24056875b8690be00873f@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <35F0CC7C-5044-45C8-BA95-4FA59646DED3@cis.upenn.edu>


On Apr 18, 2016, at 9:14 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> My instinct is to make it less expressive, though, and only allow (TExp t) as the argument of $$. 
> 
> Does anyone care either way?   I suppose we'd better open a ticket for this.

I don't see any harm that is introduced by having access to the Q monad. As you say, as long as we can create only well-typed TExps, it doesn't seem to matter what information we have access to on the way. In other words: what's the gain by reducing expressiveness here?

Richard

From carter.schonwald at gmail.com  Mon Apr 18 13:38:38 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 18 Apr 2016 09:38:38 -0400
Subject: directory and GHC 8.0.1
In-Reply-To: <1460906701.3782749.581243577.01B40E05@webmail.messagingengine.com>
References: <87d1q24j0g.fsf@smart-cactus.org>
 <1459976919.2379569.571159985.696D36D2@webmail.messagingengine.com>
 <87a8l64bzd.fsf@smart-cactus.org>
 <1460000148.3221856.571408153.7456C7C7@webmail.messagingengine.com>
 <877fg94xtq.fsf@smart-cactus.org>
 <1460632519.1473955.578559009.58BCE9FF@webmail.messagingengine.com>
 <87h9f3xdrg.fsf@smart-cactus.org>
 <1460906701.3782749.581243577.01B40E05@webmail.messagingengine.com>
Message-ID: <CAHYVw0xms6Z2K43dtRUt0sdGhXxAi1yrF_7HM6XFb=zAPkMvBQ@mail.gmail.com>

Does the ghc sub module still need this fix? I hit some build errors
related to directory when I tried to build the tip of the 8.0 branch last
night

On Sunday, April 17, 2016, <rf at rufflewind.com> wrote:

> I've bumped directory to 1.2.6.1 now after your PR (#47).  Since it's a
> rather critical issue, GHC's submodule should be updated to this
> version.
>
> Thanks,
> RF
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <javascript:;>
> 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/20160418/d82813bf/attachment.html>

From eir at cis.upenn.edu  Mon Apr 18 13:39:43 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 18 Apr 2016 09:39:43 -0400
Subject: Whither default build variables for make files?
In-Reply-To: <CAHYVw0xB-NFTk1j957thHFCNZtg-mvtWDJugrGM3F87aPyTPaA@mail.gmail.com>
References: <CAHYVw0xB-NFTk1j957thHFCNZtg-mvtWDJugrGM3F87aPyTPaA@mail.gmail.com>
Message-ID: <D5EB62D5-62A7-4C48-BC4C-31CAD2C34659@cis.upenn.edu>

Hi Carter,

Are you perhaps looking for the `flavours` subdirectory of `mk`? That should contain what you're looking for.

Richard

On Apr 17, 2016, at 9:32 AM, Carter Schonwald <carter.schonwald at gmail.com> wrote:

> Hey all,
> I just did a checkout of the tip of ghc 8.0 branch and it looks like the build.mk files have seen a bit of reorganization! Now for the perf aka release  build the various doc variavles seem to be implicitly set somewhere else and I got a bit lost when trying to dig them up.  
> 
> On the flip side : is the shake build system alternative mature enough for it to be reasonable to attempt using it on my Mac ?
> 
> Many thanks 
> _______________________________________________
> 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/20160418/b0286062/attachment-0001.html>

From carter.schonwald at gmail.com  Mon Apr 18 13:41:50 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 18 Apr 2016 09:41:50 -0400
Subject: Whither default build variables for make files?
In-Reply-To: <D5EB62D5-62A7-4C48-BC4C-31CAD2C34659@cis.upenn.edu>
References: <CAHYVw0xB-NFTk1j957thHFCNZtg-mvtWDJugrGM3F87aPyTPaA@mail.gmail.com>
 <D5EB62D5-62A7-4C48-BC4C-31CAD2C34659@cis.upenn.edu>
Message-ID: <CAHYVw0xSS2HQ5s6_4tkEQr7Ry8SVLNa8XOvtbNBKMUXmz34DwA@mail.gmail.com>

I looked there, but it seems to only have overrides or such, since the perf
flavor doesn't specify the doc build variables

On Monday, April 18, 2016, Richard Eisenberg <eir at cis.upenn.edu> wrote:

> Hi Carter,
>
> Are you perhaps looking for the `flavours` subdirectory of `mk`? That
> should contain what you're looking for.
>
> Richard
>
> On Apr 17, 2016, at 9:32 AM, Carter Schonwald <carter.schonwald at gmail.com
> <javascript:_e(%7B%7D,'cvml','carter.schonwald at gmail.com');>> wrote:
>
> Hey all,
> I just did a checkout of the tip of ghc 8.0 branch and it looks like the
> build.mk files have seen a bit of reorganization! Now for the perf aka
> release  build the various doc variavles seem to be implicitly set
> somewhere else and I got a bit lost when trying to dig them up.
>
> On the flip side : is the shake build system alternative mature enough for
> it to be reasonable to attempt using it on my Mac ?
>
> Many thanks
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> <javascript:_e(%7B%7D,'cvml','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/20160418/c7c37deb/attachment.html>

From simonpj at microsoft.com  Mon Apr 18 13:45:00 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 18 Apr 2016 13:45:00 +0000
Subject: Should TH TExp be able use the Q monad
In-Reply-To: <35F0CC7C-5044-45C8-BA95-4FA59646DED3@cis.upenn.edu>
References: <7fefdb2ab3e24056875b8690be00873f@DB4PR30MB030.064d.mgd.msft.net>
 <35F0CC7C-5044-45C8-BA95-4FA59646DED3@cis.upenn.edu>
Message-ID: <f7e4ecbf79404e29b3b8a4bdc5a254dd@DB4PR30MB030.064d.mgd.msft.net>

Well, it opens up the entire issue of dependence on typechecking order and reification.  Other things being equal, simple is good...

Simon

|  -----Original Message-----
|  From: Richard Eisenberg [mailto:eir at cis.upenn.edu]
|  Sent: 18 April 2016 14:36
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: Boespflug, Mathieu <m at tweag.io>; mainland at drexel.edu; Manuel M T
|  Chakravarty <chak at justtesting.org>; ghc-devs <ghc-devs at haskell.org>
|  Subject: Re: Should TH TExp be able use the Q monad
|  
|  
|  On Apr 18, 2016, at 9:14 AM, Simon Peyton Jones <simonpj at microsoft.com>
|  wrote:
|  >
|  > My instinct is to make it less expressive, though, and only allow
|  (TExp t) as the argument of $$.
|  >
|  > Does anyone care either way?   I suppose we'd better open a ticket
|  for this.
|  
|  I don't see any harm that is introduced by having access to the Q
|  monad. As you say, as long as we can create only well-typed TExps, it
|  doesn't seem to matter what information we have access to on the way.
|  In other words: what's the gain by reducing expressiveness here?
|  
|  Richard

From eir at cis.upenn.edu  Mon Apr 18 14:04:18 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Mon, 18 Apr 2016 10:04:18 -0400
Subject: Should TH TExp be able use the Q monad
In-Reply-To: <f7e4ecbf79404e29b3b8a4bdc5a254dd@DB4PR30MB030.064d.mgd.msft.net>
References: <7fefdb2ab3e24056875b8690be00873f@DB4PR30MB030.064d.mgd.msft.net>
 <35F0CC7C-5044-45C8-BA95-4FA59646DED3@cis.upenn.edu>
 <f7e4ecbf79404e29b3b8a4bdc5a254dd@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <B769E30B-A3BF-4B5B-AF56-F46F5C28EE16@cis.upenn.edu>


On Apr 18, 2016, at 9:45 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> Well, it opens up the entire issue of dependence on typechecking order and reification.  Other things being equal, simple is good...

Of course that's true, but other things aren't equal -- losing Q decreases the usefulness of typed TH. I agree that there is some nastiness regarding reification. We could refuse to reify something from the same group. I'm not sure how hard that would be to enforce. Or if reification were a real bear, we could provide the IO monad. 

Just to see how this is used, I poked around in a download of all of Hackage from September 2015. Here's what I found.

- 6 packages use typed TH: clash-prelude-0.9.2, llvm-general-quote-0.2.0.0, lookup-tables-0.1.1.1, network-uri-static-0.1.0.0, refined-0.1.1.0, and validated-literals-0.2.0.

- None seem to use the ability to do work in the Q (or IO) monad.

- Two (lookup-tables and refined) do use the fact that the TExp constructor is exported from Language.Haskell.TH.Syntax to make an untyped TH expression and unsafely force it into a typed TH expression. If we're going to close back doors, this seems like a much wider one than access to Q.

So I guess this suggests that taking typed TH out of the Q monad wouldn't be too disruptive. But saying "no reification of anything, anywhere" seems like a big sledgehammer to stop people from reifying local things whose typed haven't settled yet.

Richard

From ben at smart-cactus.org  Mon Apr 18 14:16:51 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 18 Apr 2016 16:16:51 +0200
Subject: Whither default build variables for make files?
In-Reply-To: <CAHYVw0xSS2HQ5s6_4tkEQr7Ry8SVLNa8XOvtbNBKMUXmz34DwA@mail.gmail.com>
References: <CAHYVw0xB-NFTk1j957thHFCNZtg-mvtWDJugrGM3F87aPyTPaA@mail.gmail.com>
 <D5EB62D5-62A7-4C48-BC4C-31CAD2C34659@cis.upenn.edu>
 <CAHYVw0xSS2HQ5s6_4tkEQr7Ry8SVLNa8XOvtbNBKMUXmz34DwA@mail.gmail.com>
Message-ID: <87k2jvuhm4.fsf@smart-cactus.org>

Carter Schonwald <carter.schonwald at gmail.com> writes:

> I looked there, but it seems to only have overrides or such, since the perf
> flavor doesn't specify the doc build variables
>
What variables in particular are you looking for?

- Ben

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

From ben at smart-cactus.org  Mon Apr 18 14:18:58 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 18 Apr 2016 16:18:58 +0200
Subject: directory and GHC 8.0.1
In-Reply-To: <CAHYVw0xms6Z2K43dtRUt0sdGhXxAi1yrF_7HM6XFb=zAPkMvBQ@mail.gmail.com>
References: <87d1q24j0g.fsf@smart-cactus.org>
 <1459976919.2379569.571159985.696D36D2@webmail.messagingengine.com>
 <87a8l64bzd.fsf@smart-cactus.org>
 <1460000148.3221856.571408153.7456C7C7@webmail.messagingengine.com>
 <877fg94xtq.fsf@smart-cactus.org>
 <1460632519.1473955.578559009.58BCE9FF@webmail.messagingengine.com>
 <87h9f3xdrg.fsf@smart-cactus.org>
 <1460906701.3782749.581243577.01B40E05@webmail.messagingengine.com>
 <CAHYVw0xms6Z2K43dtRUt0sdGhXxAi1yrF_7HM6XFb=zAPkMvBQ@mail.gmail.com>
Message-ID: <87h9ezuhil.fsf@smart-cactus.org>

Carter Schonwald <carter.schonwald at gmail.com> writes:

> Does the ghc sub module still need this fix? I hit some build errors
> related to directory when I tried to build the tip of the 8.0 branch last
> night
>
The directory submodule was updated on the ghc-8.0 branch in
80894f2b83390de9c57f3711506a1a810bb86b30, which was committed around
03:30 EST.

Cheers,

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

From carter.schonwald at gmail.com  Mon Apr 18 14:51:24 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 18 Apr 2016 10:51:24 -0400
Subject: directory and GHC 8.0.1
In-Reply-To: <87h9ezuhil.fsf@smart-cactus.org>
References: <87d1q24j0g.fsf@smart-cactus.org>
 <1459976919.2379569.571159985.696D36D2@webmail.messagingengine.com>
 <87a8l64bzd.fsf@smart-cactus.org>
 <1460000148.3221856.571408153.7456C7C7@webmail.messagingengine.com>
 <877fg94xtq.fsf@smart-cactus.org>
 <1460632519.1473955.578559009.58BCE9FF@webmail.messagingengine.com>
 <87h9f3xdrg.fsf@smart-cactus.org>
 <1460906701.3782749.581243577.01B40E05@webmail.messagingengine.com>
 <CAHYVw0xms6Z2K43dtRUt0sdGhXxAi1yrF_7HM6XFb=zAPkMvBQ@mail.gmail.com>
 <87h9ezuhil.fsf@smart-cactus.org>
Message-ID: <CAHYVw0y5AWSreh80RsNTN3b0p70-vM7ATc8Kq44-WXeGuLwf7A@mail.gmail.com>

3am? Yup that's after I tried to do the build so I'll try again today :)

On Monday, April 18, 2016, Ben Gamari <ben at smart-cactus.org> wrote:

> Carter Schonwald <carter.schonwald at gmail.com <javascript:;>> writes:
>
> > Does the ghc sub module still need this fix? I hit some build errors
> > related to directory when I tried to build the tip of the 8.0 branch last
> > night
> >
> The directory submodule was updated on the ghc-8.0 branch in
> 80894f2b83390de9c57f3711506a1a810bb86b30, which was committed around
> 03:30 EST.
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160418/92f436c2/attachment-0001.html>

From carter.schonwald at gmail.com  Mon Apr 18 18:49:03 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 18 Apr 2016 14:49:03 -0400
Subject: Should TH TExp be able use the Q monad
In-Reply-To: <CAHYVw0wT5Bq6agOry4NE6gw3n9npOWiz2Se+mdpeGaoUSVknxA@mail.gmail.com>
References: <7fefdb2ab3e24056875b8690be00873f@DB4PR30MB030.064d.mgd.msft.net>
 <35F0CC7C-5044-45C8-BA95-4FA59646DED3@cis.upenn.edu>
 <f7e4ecbf79404e29b3b8a4bdc5a254dd@DB4PR30MB030.064d.mgd.msft.net>
 <B769E30B-A3BF-4B5B-AF56-F46F5C28EE16@cis.upenn.edu>
 <CAHYVw0xEF0eb8fZ1vugdRmorvcEB+64DBpt5m8vcei-C8X-LnQ@mail.gmail.com>
 <CAHYVw0wT5Bq6agOry4NE6gw3n9npOWiz2Se+mdpeGaoUSVknxA@mail.gmail.com>
Message-ID: <CAHYVw0x51qV5KcdgmL0UHNYw-ed10Qz6h3mZbO=Rg==y5xo7wQ@mail.gmail.com>

This thread is reminding me of the metaprograming ux that agda has as of
the new 2.5 release, where there's a type checking monad for proposed terms
and the ability to choose to do error handling when a proposed term fails
to type check.  Note that their meta ast is unindexed, so the program
fragments are constructed in a sort of untyped  debrujin data model of agda
terms
On Apr 18, 2016 10:04 AM, "Richard Eisenberg" <eir at cis.upenn.edu> wrote:


On Apr 18, 2016, at 9:45 AM, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Well, it opens up the entire issue of dependence on typechecking order
and reification.  Other things being equal, simple is good...

Of course that's true, but other things aren't equal -- losing Q decreases
the usefulness of typed TH. I agree that there is some nastiness regarding
reification. We could refuse to reify something from the same group. I'm
not sure how hard that would be to enforce. Or if reification were a real
bear, we could provide the IO monad.

Just to see how this is used, I poked around in a download of all of
Hackage from September 2015. Here's what I found.

- 6 packages use typed TH: clash-prelude-0.9.2, llvm-general-quote-0.2.0.0,
lookup-tables-0.1.1.1, network-uri-static-0.1.0.0, refined-0.1.1.0, and
validated-literals-0.2.0.

- None seem to use the ability to do work in the Q (or IO) monad.

- Two (lookup-tables and refined) do use the fact that the TExp constructor
is exported from Language.Haskell.TH.Syntax to make an untyped TH
expression and unsafely force it into a typed TH expression. If we're going
to close back doors, this seems like a much wider one than access to Q.

So I guess this suggests that taking typed TH out of the Q monad wouldn't
be too disruptive. But saying "no reification of anything, anywhere" seems
like a big sledgehammer to stop people from reifying local things whose
typed haven't settled yet.

Richard
_______________________________________________
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/20160418/e143f158/attachment.html>

From tomberek at gmail.com  Mon Apr 18 18:50:54 2016
From: tomberek at gmail.com (Thomas Bereknyei)
Date: Mon, 18 Apr 2016 14:50:54 -0400
Subject: Should TH TExp be able use the Q monad
In-Reply-To: <CAHYVw0x51qV5KcdgmL0UHNYw-ed10Qz6h3mZbO=Rg==y5xo7wQ@mail.gmail.com>
References: <7fefdb2ab3e24056875b8690be00873f@DB4PR30MB030.064d.mgd.msft.net>
 <35F0CC7C-5044-45C8-BA95-4FA59646DED3@cis.upenn.edu>
 <f7e4ecbf79404e29b3b8a4bdc5a254dd@DB4PR30MB030.064d.mgd.msft.net>
 <B769E30B-A3BF-4B5B-AF56-F46F5C28EE16@cis.upenn.edu>
 <CAHYVw0xEF0eb8fZ1vugdRmorvcEB+64DBpt5m8vcei-C8X-LnQ@mail.gmail.com>
 <CAHYVw0wT5Bq6agOry4NE6gw3n9npOWiz2Se+mdpeGaoUSVknxA@mail.gmail.com>
 <CAHYVw0x51qV5KcdgmL0UHNYw-ed10Qz6h3mZbO=Rg==y5xo7wQ@mail.gmail.com>
Message-ID: <CA+CkF22xwaFuwCL5zVWY4+SX7BCupWe3ywX9BcTf0P7um-Nm7g@mail.gmail.com>

I'm not clear what the tradeoffs would be in the case that prompted this
thread, but I have been in situations where I wanted a richer ecosystem
around Typed TH. Access to Q effects are definitely part of that.

On Mon, Apr 18, 2016 at 2:49 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> This thread is reminding me of the metaprograming ux that agda has as of
> the new 2.5 release, where there's a type checking monad for proposed terms
> and the ability to choose to do error handling when a proposed term fails
> to type check.  Note that their meta ast is unindexed, so the program
> fragments are constructed in a sort of untyped  debrujin data model of agda
> terms
> On Apr 18, 2016 10:04 AM, "Richard Eisenberg" <eir at cis.upenn.edu> wrote:
>
>
> On Apr 18, 2016, at 9:45 AM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
> > Well, it opens up the entire issue of dependence on typechecking order
> and reification.  Other things being equal, simple is good...
>
> Of course that's true, but other things aren't equal -- losing Q decreases
> the usefulness of typed TH. I agree that there is some nastiness regarding
> reification. We could refuse to reify something from the same group. I'm
> not sure how hard that would be to enforce. Or if reification were a real
> bear, we could provide the IO monad.
>
> Just to see how this is used, I poked around in a download of all of
> Hackage from September 2015. Here's what I found.
>
> - 6 packages use typed TH: clash-prelude-0.9.2,
> llvm-general-quote-0.2.0.0, lookup-tables-0.1.1.1,
> network-uri-static-0.1.0.0, refined-0.1.1.0, and validated-literals-0.2.0.
>
> - None seem to use the ability to do work in the Q (or IO) monad.
>
> - Two (lookup-tables and refined) do use the fact that the TExp
> constructor is exported from Language.Haskell.TH.Syntax to make an untyped
> TH expression and unsafely force it into a typed TH expression. If we're
> going to close back doors, this seems like a much wider one than access to
> Q.
>
> So I guess this suggests that taking typed TH out of the Q monad wouldn't
> be too disruptive. But saying "no reification of anything, anywhere" seems
> like a big sledgehammer to stop people from reifying local things whose
> typed haven't settled yet.
>
> Richard
> _______________________________________________
> 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/20160418/1589d39d/attachment.html>

From carter.schonwald at gmail.com  Mon Apr 18 18:59:45 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 18 Apr 2016 14:59:45 -0400
Subject: Should TH TExp be able use the Q monad
In-Reply-To: <CA+CkF22xwaFuwCL5zVWY4+SX7BCupWe3ywX9BcTf0P7um-Nm7g@mail.gmail.com>
References: <7fefdb2ab3e24056875b8690be00873f@DB4PR30MB030.064d.mgd.msft.net>
 <35F0CC7C-5044-45C8-BA95-4FA59646DED3@cis.upenn.edu>
 <f7e4ecbf79404e29b3b8a4bdc5a254dd@DB4PR30MB030.064d.mgd.msft.net>
 <B769E30B-A3BF-4B5B-AF56-F46F5C28EE16@cis.upenn.edu>
 <CAHYVw0xEF0eb8fZ1vugdRmorvcEB+64DBpt5m8vcei-C8X-LnQ@mail.gmail.com>
 <CAHYVw0wT5Bq6agOry4NE6gw3n9npOWiz2Se+mdpeGaoUSVknxA@mail.gmail.com>
 <CAHYVw0x51qV5KcdgmL0UHNYw-ed10Qz6h3mZbO=Rg==y5xo7wQ@mail.gmail.com>
 <CA+CkF22xwaFuwCL5zVWY4+SX7BCupWe3ywX9BcTf0P7um-Nm7g@mail.gmail.com>
Message-ID: <CAHYVw0yWKHp3HvLGyG-11s0F5TLyzT4X9TuHoXWTb0UTffg+Xg@mail.gmail.com>

to better clarify what i'm referrring to i shall link to
http://agda.readthedocs.org/en/latest/language/reflection.html
which describes the agda reflection / type checking monad and associated
quote/unquote facilitie further

On Mon, Apr 18, 2016 at 2:50 PM, Thomas Bereknyei <tomberek at gmail.com>
wrote:

> I'm not clear what the tradeoffs would be in the case that prompted this
> thread, but I have been in situations where I wanted a richer ecosystem
> around Typed TH. Access to Q effects are definitely part of that.
>
> On Mon, Apr 18, 2016 at 2:49 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> This thread is reminding me of the metaprograming ux that agda has as of
>> the new 2.5 release, where there's a type checking monad for proposed terms
>> and the ability to choose to do error handling when a proposed term fails
>> to type check.  Note that their meta ast is unindexed, so the program
>> fragments are constructed in a sort of untyped  debrujin data model of agda
>> terms
>> On Apr 18, 2016 10:04 AM, "Richard Eisenberg" <eir at cis.upenn.edu> wrote:
>>
>>
>> On Apr 18, 2016, at 9:45 AM, Simon Peyton Jones <simonpj at microsoft.com>
>> wrote:
>>
>> > Well, it opens up the entire issue of dependence on typechecking order
>> and reification.  Other things being equal, simple is good...
>>
>> Of course that's true, but other things aren't equal -- losing Q
>> decreases the usefulness of typed TH. I agree that there is some nastiness
>> regarding reification. We could refuse to reify something from the same
>> group. I'm not sure how hard that would be to enforce. Or if reification
>> were a real bear, we could provide the IO monad.
>>
>> Just to see how this is used, I poked around in a download of all of
>> Hackage from September 2015. Here's what I found.
>>
>> - 6 packages use typed TH: clash-prelude-0.9.2,
>> llvm-general-quote-0.2.0.0, lookup-tables-0.1.1.1,
>> network-uri-static-0.1.0.0, refined-0.1.1.0, and validated-literals-0.2.0.
>>
>> - None seem to use the ability to do work in the Q (or IO) monad.
>>
>> - Two (lookup-tables and refined) do use the fact that the TExp
>> constructor is exported from Language.Haskell.TH.Syntax to make an untyped
>> TH expression and unsafely force it into a typed TH expression. If we're
>> going to close back doors, this seems like a much wider one than access to
>> Q.
>>
>> So I guess this suggests that taking typed TH out of the Q monad wouldn't
>> be too disruptive. But saying "no reification of anything, anywhere" seems
>> like a big sledgehammer to stop people from reifying local things whose
>> typed haven't settled yet.
>>
>> Richard
>> _______________________________________________
>> 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/20160418/97354afa/attachment.html>

From ben at well-typed.com  Mon Apr 18 19:54:44 2016
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 18 Apr 2016 21:54:44 +0200
Subject: [ANNOUNCE] GHC 8.0.1 release candidate 3 available
Message-ID: <87d1pmvgjf.fsf@smart-cactus.org>


Hello Haskellers,

The GHC team is happy to announce the availability of third release
candidate of the Glasgow Haskell Compiler's 8.0.1 release. Source and
binary distributions can be found at,

    http://downloads.haskell.org/~ghc/8.0.1-rc3/

This is the third of what will be four candidates leading up to the
8.0.1 release. As there are a number of known issues with this
candidate, we expect to produce the fourth and final release candidate
shortly. While we considered not releasing this candidate at all and
instead skipping to rc4, we decided that it would be helpful to make it
available despite its issues to increase the likelihood of catching any
remaining bugs.

That being said, this candidate lacks the range of binary distributions
which we usually offer,

  * We are unable to release Windows bindists due to a compatibility
    issue which we didn't catch until after preparing the source
    distribution.

  * Binaries targeting Redhat distributions are currently not available

Regardless, users for whom a distribution is available are encouraged to
try this candidate as it fixes dozens of issues present in release
candidate two. These include,

  * A type-checker panic triggered by use of Typeable on a
    kind-polymorphic type constructor (#11334)

  * A type-checker explosion where -XTypeInType would gobble up massive
    amounts of memory when used in a data instance (#11407)

  * Various issues involving unexpected laziness resulting in exception
    handlers not being invoked (#11555)

  * GHC now fails more gracefully when used with an older cabal-install
    release (#11558)

  * TypeInType now has proper documentation in the users guide (#11614)

  * The story surrounding type `RuntimeRep`s (formerly known as
    `Levity`) is now far better developed, closing several doors to
    unsafe behavior that TypeInType previously opened (#11473, #11723)

  * A long-standing bug in the constant-folding rules for `mod` for the
    `Word` type has been resolved (#11702)

  * Various issues introduced by OverloadedRecordFields have been fixed
    (#11662, #11401) 

  * A regression in the typechecker resulting in the rejection of code
    in the `free` and `microlens` packages has been fixed (#11608)

  * A bug in the LLVM code generator which caused some programs to emit
    unbuildable LLVM IR has been fixed (#11649)

  * A bug where pattern synonyms defined in terms of a pattern match on
    a record would be rejected if the fields weren't written in the same order
    as they were defined has been resolved (#11633)

  * A bug in the runtime system's treatment of weak references which
    could result in segmentation faults in some cases has been fixed (#11108)

  * a variety of optimizations improving compiler performance have been
    merged

  * and many others

Mac OS X users should be aware that the recent XCode 7.3 release ships
with a broken `nm` utility which breaks the GHC build (#11744, #11823).
Unfortunately, this candidate does not notice this brokenness and odd
behavior can result. OS X users running XCode 7.3 are encouraged to open
a ticket with Apple and build GHC with the `--with-nm=nm-classic`
configure option until a fix is available.

As mentioned earlier, there are a number of known issues with this
candidate which will be addressed in release candidate four. These
issues include,

  * A number of typechecker bugs (#11811, #11797, #11813, #11814)

  * A build issue seen on OS X (#11828)

  * Template Haskell lacks the ability to produce instances with
    OVERLAPP{ING,ABLE,ED} pragmas

  * Autoconf has inadequate version checks for libdw (#11820)

  * Typeable and hs-boot files interact poorly (#11824)

  * The build system doesn't check for the broken Apple `nm` utility,
    leading to unpredictable results (#11823, #11744)

We hope to have release candidate four available by the middle of next
week.

Thanks to everyone who has contributed code, testing, builds, and bug
reports thusfar!

Cheers,

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

From m at tweag.io  Mon Apr 18 21:01:50 2016
From: m at tweag.io (Boespflug, Mathieu)
Date: Mon, 18 Apr 2016 23:01:50 +0200
Subject: Reification of out-of-scope variables?
In-Reply-To: <6A50C2C2-3AEA-4AFF-94BA-C24D4F8184F4@cis.upenn.edu>
References: <CAJ0eudrYKW=+s25+G9x_3AQNJTU2Uqj18uZfbzZedF2p8oq=LQ@mail.gmail.com>
 <266BEB36-AA3D-4049-84F7-138C6FF7539A@cis.upenn.edu>
 <CA+Q==SDrdJBAKWt4ULwgYpPu0vHwz-WqSK4U1upTaA2DTtGPAQ@mail.gmail.com>
 <1DA2B8DB-1830-44A4-9564-F3B508771909@cis.upenn.edu>
 <CAJ0eudoNEa-dpSNwT1fhPxdQr6CpYvsuexVJNoxowoDu6KBahA@mail.gmail.com>
 <02700e82027346eea0d10776603e6610@DB4PR30MB030.064d.mgd.msft.net>
 <6A50C2C2-3AEA-4AFF-94BA-C24D4F8184F4@cis.upenn.edu>
Message-ID: <CAJ0eudrrzvr77QG5vNrN_wOiaAOmdZA5mcE7xR_H5-3=GFmnQw@mail.gmail.com>

Hi all,

For our use case, namely automatic bindings generation via
quasiquotation ? la language-c-inline, typed quasiquotation alone
wouldn't solve much. Because in order to be sensible it would likely
have to be restricted (one way or another) to only allowing
reification of variables in the previous declaration groups (since we
AFAICT all agree that the current permissiveness of reification in
typed splices is a bug). That won't fit the use case, since it's
precisely the types of the locally bound variables we're interested in
(see examples on the updated wiki page:
https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Reify).

So that brings us back to the question of allowing addModFinalizer to
capture the local type environment of the call site somehow. There's a
proposal for this that Facundo came up with and wrote up at the end of
the aforementioned wiki page, but does anyone else have a better way
of doing this in mind?

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


On 16 April 2016 at 16:02, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>
> On Apr 15, 2016, at 11:51 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>>
>> Hang on!  The design for typed splices, describe here,
>> https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/BlogPostChanges
>> says "Unlike TH, the only way to construct a value of type TExp is with a quote. You cannot drop into do-notation, nor use explicit construction of the values in the Exp algebraic data type. That restriction limits expressiveness, but it enables the strong typing guarantees."
>>
>> So why does the above work?  $$(e) requires a TExp, and do-notation doesn?t produce a TExp.
>
> Indeed this is true -- this is what that page says. But it's not what's implemented: when I say $$( _ ) :: Bool, GHC tells me that the hole has type Q (TExp Bool).
>
> There still is no way to create a TExp other than to use a type TH quote.
>
> Addressing your other message: a typed quasiquoter would be somewhat limited, but not utterly silly. For example, this works:
>
>> bool :: String -> Q (TExp Bool)
>> bool "true"  = [|| True ||]
>> bool "false" = [|| False ||]
>> bool _ = fail "not a bool"
>>
>> -- and then, in another module because of the stage restriction:
>> yes :: Bool
>> yes = $$(bool "true")
>
> Now `bool` could be a typed quasiquoter.
>
> I don't know whether any of this is worth implementing, but it's not, a priori, a terrible idea.
>
> Richard
>
>>
>> |  * Should we consider it a bug (and file a ticket) that reification in
>> |  typed splices is able to observe the order of type checking, just like
>> |  reify used to do in untyped splices?
>>
>> Yes I think so!!!
>>
>> Simon
>>
>

From simonpj at microsoft.com  Tue Apr 19 11:21:57 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 19 Apr 2016 11:21:57 +0000
Subject: [GHC] #11824: GHC error in desugarer lookup
In-Reply-To: <87fuukwowr.fsf@smart-cactus.org>
References: <046.bef37bafb0de36b55d56e17189a8ba9e@haskell.org>
 <061.6a21d313942a94900735c0c8a7674929@haskell.org>
 <9732b66656ae46bbb57ac6142c505972@DB4PR30MB030.064d.mgd.msft.net>
 <8737qpfwea.fsf@smart-cactus.org>
 <1740ed3287ad411c9e803d17816e22cc@DB4PR30MB030.064d.mgd.msft.net>
 <87potpwxte.fsf@smart-cactus.org>
 <088a28f63117490787bf2e118ff84c99@DB4PR30MB030.064d.mgd.msft.net>
 <87fuukwowr.fsf@smart-cactus.org>
Message-ID: <b237305c4e2945449741555b769de663@DB4PR30MB030.064d.mgd.msft.net>

Oh, you are right.  I was thinking of generating the Typeable bindings (and record selectors) at the end of tcTyAndClassDecls.   That would work perfectly EXCEPT that we only want to generate the module-name bindings once.

But it's easy to spot if it's been done already because tcg_tr_module is a Just.

So, I suggest you generate Typeable binding along with record selectors, at the end of tcTyAndClassDecls; but take care that mkModIdBindings is a no-op if tcg_tr_module says it's been done already.  


But I don't mind if you want to leave it as-is, provided you comment to avoid the confusion I fell into.

Simon

|  -----Original Message-----
|  From: Ben Gamari [mailto:ben at well-typed.com]
|  Sent: 17 April 2016 10:44
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: GHC developers <ghc-devs at haskell.org>
|  Subject: RE: [GHC] #11824: GHC error in desugarer lookup
|  
|  Simon Peyton Jones <simonpj at microsoft.com> writes:
|  
|  > | The problem is this: we must generate and typecheck record
|  selectors
|  > | on a per-group basis, since they may be used by later groups.
|  >
|  > Why?  Record selectors are value bindings which aren't used when
|  typechecking data types.
|  >
|  Yes, they are value bindings and may be used in bindings in later
|  groups. For instance, let's consider the following,
|  
|      data ARecord = ARecord { aField :: Int }
|  
|      $(return [])   -- group delimiter
|  
|      aFieldIncr :: ARecord -> Int
|      aFieldIncr = succ . aField
|  
|  My point in,
|  
|  > | we must generate and typecheck record selectors on a per-group
|  basis
|  
|  is that we must generate the `aField` binding before proceeding to
|  typecheck the second group (containing `aFieldIncr`). Failing to do
|  this would result in `aField` being out of scope when we attempted to
|  typecheck the RHS of `aFieldIncr`. Perhaps I have misunderstood?
|  
|  Cheers,
|  
|  - Ben


From eir at cis.upenn.edu  Tue Apr 19 14:49:58 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 19 Apr 2016 10:49:58 -0400
Subject: Reification of out-of-scope variables?
In-Reply-To: <CAJ0eudrrzvr77QG5vNrN_wOiaAOmdZA5mcE7xR_H5-3=GFmnQw@mail.gmail.com>
References: <CAJ0eudrYKW=+s25+G9x_3AQNJTU2Uqj18uZfbzZedF2p8oq=LQ@mail.gmail.com>
 <266BEB36-AA3D-4049-84F7-138C6FF7539A@cis.upenn.edu>
 <CA+Q==SDrdJBAKWt4ULwgYpPu0vHwz-WqSK4U1upTaA2DTtGPAQ@mail.gmail.com>
 <1DA2B8DB-1830-44A4-9564-F3B508771909@cis.upenn.edu>
 <CAJ0eudoNEa-dpSNwT1fhPxdQr6CpYvsuexVJNoxowoDu6KBahA@mail.gmail.com>
 <02700e82027346eea0d10776603e6610@DB4PR30MB030.064d.mgd.msft.net>
 <6A50C2C2-3AEA-4AFF-94BA-C24D4F8184F4@cis.upenn.edu>
 <CAJ0eudrrzvr77QG5vNrN_wOiaAOmdZA5mcE7xR_H5-3=GFmnQw@mail.gmail.com>
Message-ID: <2ED45C34-9071-4199-BF07-3496B3E62E17@cis.upenn.edu>

I don't have a better idea. I've added a few small comments to the bottom of that wiki page, which still, for me, represents the best solution to this problem.

Richard

On Apr 18, 2016, at 5:01 PM, "Boespflug, Mathieu" <m at tweag.io> wrote:

> Hi all,
> 
> For our use case, namely automatic bindings generation via
> quasiquotation ? la language-c-inline, typed quasiquotation alone
> wouldn't solve much. Because in order to be sensible it would likely
> have to be restricted (one way or another) to only allowing
> reification of variables in the previous declaration groups (since we
> AFAICT all agree that the current permissiveness of reification in
> typed splices is a bug). That won't fit the use case, since it's
> precisely the types of the locally bound variables we're interested in
> (see examples on the updated wiki page:
> https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Reify).
> 
> So that brings us back to the question of allowing addModFinalizer to
> capture the local type environment of the call site somehow. There's a
> proposal for this that Facundo came up with and wrote up at the end of
> the aforementioned wiki page, but does anyone else have a better way
> of doing this in mind?
> 
> Best,
> --
> Mathieu Boespflug
> Founder at http://tweag.io.
> 
> 
> On 16 April 2016 at 16:02, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>> 
>> On Apr 15, 2016, at 11:51 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
>>> 
>>> Hang on!  The design for typed splices, describe here,
>>> https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/BlogPostChanges
>>> says "Unlike TH, the only way to construct a value of type TExp is with a quote. You cannot drop into do-notation, nor use explicit construction of the values in the Exp algebraic data type. That restriction limits expressiveness, but it enables the strong typing guarantees."
>>> 
>>> So why does the above work?  $$(e) requires a TExp, and do-notation doesn?t produce a TExp.
>> 
>> Indeed this is true -- this is what that page says. But it's not what's implemented: when I say $$( _ ) :: Bool, GHC tells me that the hole has type Q (TExp Bool).
>> 
>> There still is no way to create a TExp other than to use a type TH quote.
>> 
>> Addressing your other message: a typed quasiquoter would be somewhat limited, but not utterly silly. For example, this works:
>> 
>>> bool :: String -> Q (TExp Bool)
>>> bool "true"  = [|| True ||]
>>> bool "false" = [|| False ||]
>>> bool _ = fail "not a bool"
>>> 
>>> -- and then, in another module because of the stage restriction:
>>> yes :: Bool
>>> yes = $$(bool "true")
>> 
>> Now `bool` could be a typed quasiquoter.
>> 
>> I don't know whether any of this is worth implementing, but it's not, a priori, a terrible idea.
>> 
>> Richard
>> 
>>> 
>>> |  * Should we consider it a bug (and file a ticket) that reification in
>>> |  typed splices is able to observe the order of type checking, just like
>>> |  reify used to do in untyped splices?
>>> 
>>> Yes I think so!!!
>>> 
>>> Simon
>>> 
>> 
> 


From george.colpitts at gmail.com  Wed Apr 20 00:33:28 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Wed, 20 Apr 2016 00:33:28 +0000
Subject: [GHC] #10053: Regression on MacOS platform, error in ghci calling
 main after loading compiled code: "Too late for parseStaticFlags..."
In-Reply-To: <060.74e97b3a6678d8d330a2c00fa31fcfeb@haskell.org>
References: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org>
 <060.74e97b3a6678d8d330a2c00fa31fcfeb@haskell.org>
Message-ID: <CAB-d4A4H4shZhgx3wZB+jnJ3BoFw_Z5EMpKyUXGBm5Uqmd-bPw@mail.gmail.com>

Yes, this is consistent with my investigation. The only place I could find
in the source which emitted the message "Too late for parseStaticFlags..."
was ghc/Main.hs. What puzzled me was why this is a Mac specific bug.

On Tue, Apr 19, 2016 at 10:21 AM GHC <ghc-devs at haskell.org> wrote:

> #10053: Regression on MacOS platform, error  in ghci calling main after
> loading
> compiled code: "Too late for parseStaticFlags..."
> -------------------------------------+-------------------------------------
>         Reporter:  George            |                Owner:  ak3n
>             Type:  bug               |               Status:  new
>         Priority:  normal            |            Milestone:
>        Component:  GHCi              |              Version:  7.10.1-rc2
>       Resolution:                    |             Keywords:
> Operating System:  MacOS X           |         Architecture:  x86_64
>  Type of failure:  Incorrect result  |  (amd64)
>   at runtime                         |            Test Case:
>       Blocked By:                    |             Blocking:
>  Related Tickets:                    |  Differential Rev(s):
>        Wiki Page:                    |
> -------------------------------------+-------------------------------------
>
> Comment (by ak3n):
>
>  Replying to [comment:17 bgamari]:
>  > ak3n, could you elaborate?
>
>  This error is raised in
>  [https://github.com/ghc/ghc/blob/master/compiler/main/StaticFlags.hs#L80
>  compiler/main/Staticflags.hs], when parseStaticFlags is called in
>  [https://github.com/ghc/ghc/blob/master/ghc/Main.hs#L113 ghc/Main.hs].
>
>  So, this code is called two times: on ghci start and on "main" input
>  statement.
>
>  It looks like, linker replaces "main" from the loaded module
>  with "main" of ghc.
>
> --
> Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10053#comment:18>
> GHC <http://www.haskell.org/ghc/>
> The Glasgow Haskell Compiler
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160420/2f2140d6/attachment.html>

From simonpj at microsoft.com  Wed Apr 20 15:24:59 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 20 Apr 2016 15:24:59 +0000
Subject: [Diffusion] [Build Failed] rGHC353d8ae6fafe: SCC analysis for
 instances as well as types/classes
In-Reply-To: <20160420150738.35064.7555.57235D4E@phabricator.haskell.org>
References: <diffusion-audit-PHID-CMIT-6lzwpyqxi2akfb63rl5u@phabricator.haskell.org>
 <20160420150738.35064.7555.57235D4E@phabricator.haskell.org>
Message-ID: <e29dc64c8c474b77977ad611cac763fd@DB4PR30MB030.064d.mgd.msft.net>

Harbormaster below says that T11195 and T4029 fail; but they don't on my machine.

But tcrun045 does.. patch for that coming

Simon

|  -----Original Message-----
|  From: noreply at phabricator.haskell.org
|  [mailto:noreply at phabricator.haskell.org]
|  Sent: 20 April 2016 16:08
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Subject: [Diffusion] [Build Failed] rGHC353d8ae6fafe: SCC analysis for
|  instances as well as types/classes
|  
|  Harbormaster failed to build B9256: rGHC353d8ae6fafe: SCC analysis for
|  instances as well as types/classes!
|  
|  BRANCHES
|    master
|  
|  USERS
|    simonpj (Author)
|    GHC - Testsuite (Auditor)
|    GHC - Core/System FC (Auditor)
|    GHC - HsSyn/Parser (Auditor)
|    GHC - Renamer (Auditor)
|    GHC - Type checker/inferencer (Auditor)
|    GHC - Utilities (Auditor)
|  
|  COMMIT
|    https://phabricator.haskell.org/rGHC353d8ae6fafe
|  
|  EMAIL PREFERENCES
|    https://phabricator.haskell.org/settings/panel/emailpreferences/
|  
|  To: simonpj, GHC - Testsuite, GHC - Core/System FC, GHC - HsSyn/Parser,
|  GHC - Renamer, GHC - Type checker/inferencer, GHC - Utilities,
|  Harbormaster

From david.feuer at gmail.com  Wed Apr 20 16:50:07 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 20 Apr 2016 12:50:07 -0400
Subject: Pattern synonym type flexibility
Message-ID: <CAMgWh9uBsO=MZ+HoVrDXU4u2POpa6QVy-bmkX0Eesu2uU9VFhg@mail.gmail.com>

As far as I can tell from the 7.10 documentation, it's impossible to
make a bidirectional pattern synonym used as a constructor have a
different type signature than when used as a pattern. Has this been
improved in 8.0? I really want something like

class FastCons x xs | xs -> x where
  fcons :: x -> xs -> xs
class FastViewL x xs | xs -> x where
  fviewl :: xs -> ViewL x xs

pattern x :<| xs <- (fviewl -> ConsL x xs) where
  x :<| xs = fcons x xs

This would allow users to learn just *one* name, :<|, that they can
use for sequences that are consable or viewable even if they may not
be the other.

If this is not yet possible, then I think the most intuitive approach
is to sever the notions of "pattern synonym" and "smart constructor".
So I'd write

pattern x :<| xs <- (fviewl -> ConsL x xs)
constructor (:<|) = fcons

The current syntax could easily be desugared to produce *both* a
pattern synonym and a smart constructor in the bidirectional case.

From carter.schonwald at gmail.com  Wed Apr 20 17:27:08 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 20 Apr 2016 13:27:08 -0400
Subject: Pattern synonym type flexibility
In-Reply-To: <CAMgWh9uBsO=MZ+HoVrDXU4u2POpa6QVy-bmkX0Eesu2uU9VFhg@mail.gmail.com>
References: <CAMgWh9uBsO=MZ+HoVrDXU4u2POpa6QVy-bmkX0Eesu2uU9VFhg@mail.gmail.com>
Message-ID: <CAHYVw0xxyb51g6iGBdA0N+6=bjuWj4beZSjmGk2LgD_opTaHow@mail.gmail.com>

Would that duality be related to the given vs wanted constraints ?

On Wednesday, April 20, 2016, David Feuer <david.feuer at gmail.com> wrote:

> As far as I can tell from the 7.10 documentation, it's impossible to
> make a bidirectional pattern synonym used as a constructor have a
> different type signature than when used as a pattern. Has this been
> improved in 8.0? I really want something like
>
> class FastCons x xs | xs -> x where
>   fcons :: x -> xs -> xs
> class FastViewL x xs | xs -> x where
>   fviewl :: xs -> ViewL x xs
>
> pattern x :<| xs <- (fviewl -> ConsL x xs) where
>   x :<| xs = fcons x xs
>
> This would allow users to learn just *one* name, :<|, that they can
> use for sequences that are consable or viewable even if they may not
> be the other.
>
> If this is not yet possible, then I think the most intuitive approach
> is to sever the notions of "pattern synonym" and "smart constructor".
> So I'd write
>
> pattern x :<| xs <- (fviewl -> ConsL x xs)
> constructor (:<|) = fcons
>
> The current syntax could easily be desugared to produce *both* a
> pattern synonym and a smart constructor in the bidirectional case.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <javascript:;>
> 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/20160420/feefe886/attachment.html>

From david.feuer at gmail.com  Wed Apr 20 17:33:05 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 20 Apr 2016 13:33:05 -0400
Subject: Pattern synonym type flexibility
In-Reply-To: <CAHYVw0xxyb51g6iGBdA0N+6=bjuWj4beZSjmGk2LgD_opTaHow@mail.gmail.com>
References: <CAMgWh9uBsO=MZ+HoVrDXU4u2POpa6QVy-bmkX0Eesu2uU9VFhg@mail.gmail.com>
 <CAHYVw0xxyb51g6iGBdA0N+6=bjuWj4beZSjmGk2LgD_opTaHow@mail.gmail.com>
Message-ID: <CAMgWh9v6W5EuzW7f+8zZ6-_dGQBa7_GVa+KYwMTKhgof5QwsXw@mail.gmail.com>

To some degree, it probably could be. But I believe that imposing any
substantial relationship between the smart constructor and the pattern
synonym is likely to fall squarely into the category of things that are
subtle, hard, and almost completely useless. In the arrangement I
suggested, people would be free to do some things that "don't make sense",
and that doesn't bother me in the least.
On Apr 20, 2016 1:27 PM, "Carter Schonwald" <carter.schonwald at gmail.com>
wrote:

> Would that duality be related to the given vs wanted constraints ?
>
> On Wednesday, April 20, 2016, David Feuer <david.feuer at gmail.com> wrote:
>
>> As far as I can tell from the 7.10 documentation, it's impossible to
>> make a bidirectional pattern synonym used as a constructor have a
>> different type signature than when used as a pattern. Has this been
>> improved in 8.0? I really want something like
>>
>> class FastCons x xs | xs -> x where
>>   fcons :: x -> xs -> xs
>> class FastViewL x xs | xs -> x where
>>   fviewl :: xs -> ViewL x xs
>>
>> pattern x :<| xs <- (fviewl -> ConsL x xs) where
>>   x :<| xs = fcons x xs
>>
>> This would allow users to learn just *one* name, :<|, that they can
>> use for sequences that are consable or viewable even if they may not
>> be the other.
>>
>> If this is not yet possible, then I think the most intuitive approach
>> is to sever the notions of "pattern synonym" and "smart constructor".
>> So I'd write
>>
>> pattern x :<| xs <- (fviewl -> ConsL x xs)
>> constructor (:<|) = fcons
>>
>> The current syntax could easily be desugared to produce *both* a
>> pattern synonym and a smart constructor in the bidirectional case.
>> _______________________________________________
>> 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/20160420/b27c2cac/attachment.html>

From carter.schonwald at gmail.com  Wed Apr 20 17:41:07 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 20 Apr 2016 13:41:07 -0400
Subject: Pattern synonym type flexibility
In-Reply-To: <CAMgWh9v6W5EuzW7f+8zZ6-_dGQBa7_GVa+KYwMTKhgof5QwsXw@mail.gmail.com>
References: <CAMgWh9uBsO=MZ+HoVrDXU4u2POpa6QVy-bmkX0Eesu2uU9VFhg@mail.gmail.com>
 <CAHYVw0xxyb51g6iGBdA0N+6=bjuWj4beZSjmGk2LgD_opTaHow@mail.gmail.com>
 <CAMgWh9v6W5EuzW7f+8zZ6-_dGQBa7_GVa+KYwMTKhgof5QwsXw@mail.gmail.com>
Message-ID: <CAHYVw0weq78S9NM6eWqXG5w4gx7e89WQZvNw3px_bFYfTuARPg@mail.gmail.com>

Shouldn't the design simply be both directions are the dual of the other,
and pure in some sense ?

On Wednesday, April 20, 2016, David Feuer <david.feuer at gmail.com> wrote:

> To some degree, it probably could be. But I believe that imposing any
> substantial relationship between the smart constructor and the pattern
> synonym is likely to fall squarely into the category of things that are
> subtle, hard, and almost completely useless. In the arrangement I
> suggested, people would be free to do some things that "don't make sense",
> and that doesn't bother me in the least.
> On Apr 20, 2016 1:27 PM, "Carter Schonwald" <carter.schonwald at gmail.com
> <javascript:_e(%7B%7D,'cvml','carter.schonwald at gmail.com');>> wrote:
>
>> Would that duality be related to the given vs wanted constraints ?
>>
>> On Wednesday, April 20, 2016, David Feuer <david.feuer at gmail.com
>> <javascript:_e(%7B%7D,'cvml','david.feuer at gmail.com');>> wrote:
>>
>>> As far as I can tell from the 7.10 documentation, it's impossible to
>>> make a bidirectional pattern synonym used as a constructor have a
>>> different type signature than when used as a pattern. Has this been
>>> improved in 8.0? I really want something like
>>>
>>> class FastCons x xs | xs -> x where
>>>   fcons :: x -> xs -> xs
>>> class FastViewL x xs | xs -> x where
>>>   fviewl :: xs -> ViewL x xs
>>>
>>> pattern x :<| xs <- (fviewl -> ConsL x xs) where
>>>   x :<| xs = fcons x xs
>>>
>>> This would allow users to learn just *one* name, :<|, that they can
>>> use for sequences that are consable or viewable even if they may not
>>> be the other.
>>>
>>> If this is not yet possible, then I think the most intuitive approach
>>> is to sever the notions of "pattern synonym" and "smart constructor".
>>> So I'd write
>>>
>>> pattern x :<| xs <- (fviewl -> ConsL x xs)
>>> constructor (:<|) = fcons
>>>
>>> The current syntax could easily be desugared to produce *both* a
>>> pattern synonym and a smart constructor in the bidirectional case.
>>> _______________________________________________
>>> 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/20160420/ab78cb97/attachment-0001.html>

From david.feuer at gmail.com  Wed Apr 20 17:48:19 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 20 Apr 2016 13:48:19 -0400
Subject: Pattern synonym type flexibility
In-Reply-To: <CAMgWh9sr-CfzFwma-2LbFiGT4Ko=42TN1HP5TxQE7j1kSydh7w@mail.gmail.com>
References: <CAMgWh9uBsO=MZ+HoVrDXU4u2POpa6QVy-bmkX0Eesu2uU9VFhg@mail.gmail.com>
 <CAHYVw0xxyb51g6iGBdA0N+6=bjuWj4beZSjmGk2LgD_opTaHow@mail.gmail.com>
 <CAMgWh9v6W5EuzW7f+8zZ6-_dGQBa7_GVa+KYwMTKhgof5QwsXw@mail.gmail.com>
 <CAHYVw0weq78S9NM6eWqXG5w4gx7e89WQZvNw3px_bFYfTuARPg@mail.gmail.com>
 <CAMgWh9s+nAkxV4HMAP8k2vy0dyNO8zws1YyeGsA7Ow24J2ZSyQ@mail.gmail.com>
 <CAMgWh9s8e8BbyiTH3BUFskEK_+MOjCcdJDegg-s5g-PEp0OEWA@mail.gmail.com>
 <CAMgWh9tZEZ-6-=QDmpCB874tu3vS7+T-zvrStVdU0OAOyp=D8w@mail.gmail.com>
 <CAMgWh9sr-CfzFwma-2LbFiGT4Ko=42TN1HP5TxQE7j1kSydh7w@mail.gmail.com>
Message-ID: <CAMgWh9ubYJ1ZJzJdAziLeQs5j2DLMeZ382ywpT-7Xfb7+XmxSw@mail.gmail.com>

I don't know what that means. There's no way to enforce duality at the term
level. Enforcing it at the type level prevents me from doing what I want
and serves no apparent purpose. Remember that pattern synonyms are all
about providing nice syntax, not adding essential expressiveness.
On Apr 20, 2016 1:41 PM, "Carter Schonwald" <carter.schonwald at gmail.com>
wrote:

Shouldn't the design simply be both directions are the dual of the other,
and pure in some sense ?


On Wednesday, April 20, 2016, David Feuer <david.feuer at gmail.com> wrote:

> To some degree, it probably could be. But I believe that imposing any
> substantial relationship between the smart constructor and the pattern
> synonym is likely to fall squarely into the category of things that are
> subtle, hard, and almost completely useless. In the arrangement I
> suggested, people would be free to do some things that "don't make sense",
> and that doesn't bother me in the least.
> On Apr 20, 2016 1:27 PM, "Carter Schonwald" <carter.schonwald at gmail.com>
> wrote:
>
>> Would that duality be related to the given vs wanted constraints ?
>>
>> On Wednesday, April 20, 2016, David Feuer <david.feuer at gmail.com> wrote:
>>
>>> As far as I can tell from the 7.10 documentation, it's impossible to
>>> make a bidirectional pattern synonym used as a constructor have a
>>> different type signature than when used as a pattern. Has this been
>>> improved in 8.0? I really want something like
>>>
>>> class FastCons x xs | xs -> x where
>>>   fcons :: x -> xs -> xs
>>> class FastViewL x xs | xs -> x where
>>>   fviewl :: xs -> ViewL x xs
>>>
>>> pattern x :<| xs <- (fviewl -> ConsL x xs) where
>>>   x :<| xs = fcons x xs
>>>
>>> This would allow users to learn just *one* name, :<|, that they can
>>> use for sequences that are consable or viewable even if they may not
>>> be the other.
>>>
>>> If this is not yet possible, then I think the most intuitive approach
>>> is to sever the notions of "pattern synonym" and "smart constructor".
>>> So I'd write
>>>
>>> pattern x :<| xs <- (fviewl -> ConsL x xs)
>>> constructor (:<|) = fcons
>>>
>>> The current syntax could easily be desugared to produce *both* a
>>> pattern synonym and a smart constructor in the bidirectional case.
>>> _______________________________________________
>>> 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/20160420/cc6243bf/attachment.html>

From simonpj at microsoft.com  Wed Apr 20 20:50:58 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 20 Apr 2016 20:50:58 +0000
Subject: [Diffusion] [Build Failed] rGHC55b1b85df424: Accept tcrun045
 output
In-Reply-To: <20160420204843.123879.90990.C2678174@phabricator.haskell.org>
References: <diffusion-audit-PHID-CMIT-wpe3failx3ivocqvp6sv@phabricator.haskell.org>
 <20160420204843.123879.90990.C2678174@phabricator.haskell.org>
Message-ID: <57112c328ba244eea7130a3253e344b4@DB4PR30MB030.064d.mgd.msft.net>

Ben: now are down to T4029 with max-bytes increased. Maybe just increase it?  it's a flaky number because it depends on timing of major gc

Simon

| -----Original Message-----
| From: noreply at phabricator.haskell.org
| [mailto:noreply at phabricator.haskell.org]
| Sent: 20 April 2016 21:49
| To: Simon Peyton Jones <simonpj at microsoft.com>
| Subject: [Diffusion] [Build Failed] rGHC55b1b85df424: Accept tcrun045 output
| 
| Harbormaster failed to build B9261: rGHC55b1b85df424: Accept tcrun045 output!
| 
| BRANCHES
|   master
| 
| USERS
|   simonpj (Author)
|   GHC - Testsuite (Auditor)
| 
| COMMIT
|   https://phabricator.haskell.org/rGHC55b1b85df424
| 
| EMAIL PREFERENCES
|   https://phabricator.haskell.org/settings/panel/emailpreferences/
| 
| To: simonpj, GHC - Testsuite, Harbormaster

From david.feuer at gmail.com  Wed Apr 20 21:17:26 2016
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 20 Apr 2016 17:17:26 -0400
Subject: Pattern synonym type flexibility
In-Reply-To: <CAMgWh9ubYJ1ZJzJdAziLeQs5j2DLMeZ382ywpT-7Xfb7+XmxSw@mail.gmail.com>
References: <CAMgWh9uBsO=MZ+HoVrDXU4u2POpa6QVy-bmkX0Eesu2uU9VFhg@mail.gmail.com>
 <CAHYVw0xxyb51g6iGBdA0N+6=bjuWj4beZSjmGk2LgD_opTaHow@mail.gmail.com>
 <CAMgWh9v6W5EuzW7f+8zZ6-_dGQBa7_GVa+KYwMTKhgof5QwsXw@mail.gmail.com>
 <CAHYVw0weq78S9NM6eWqXG5w4gx7e89WQZvNw3px_bFYfTuARPg@mail.gmail.com>
 <CAMgWh9s+nAkxV4HMAP8k2vy0dyNO8zws1YyeGsA7Ow24J2ZSyQ@mail.gmail.com>
 <CAMgWh9s8e8BbyiTH3BUFskEK_+MOjCcdJDegg-s5g-PEp0OEWA@mail.gmail.com>
 <CAMgWh9tZEZ-6-=QDmpCB874tu3vS7+T-zvrStVdU0OAOyp=D8w@mail.gmail.com>
 <CAMgWh9sr-CfzFwma-2LbFiGT4Ko=42TN1HP5TxQE7j1kSydh7w@mail.gmail.com>
 <CAMgWh9ubYJ1ZJzJdAziLeQs5j2DLMeZ382ywpT-7Xfb7+XmxSw@mail.gmail.com>
Message-ID: <CAMgWh9tFyErddK=XNNm2vqN2TRAx8DdC_sSQCfx=KmQ_uhyLFQ@mail.gmail.com>

Think about it this way. The matching aspect of a pattern synonym is
basically about defining a function to a somewhat weird type, except of
course optimized and maybe a bit more general.

data HList :: [*] -> * where
  HNil :: HList '[]
  HCons :: a -> HList as -> HList (a ': as)

data PatternResult :: ([*] -> Constraint) -> * where
  PatternResult :: provides ts => HList ts -> PatternResult provides

type Matcher requires provides = forall x . requires x => x ->
PatternResult provides

The smart constructor side of a pattern synonym is much, much simpler! It's
just a regular old Haskell value! The only special bit is that it's
treated, syntactically, as a constructor. There's simply nothing else worth
saying about it, so the less said the better.
On Apr 20, 2016 1:48 PM, "David Feuer" <david.feuer at gmail.com> wrote:

> I don't know what that means. There's no way to enforce duality at the
> term level. Enforcing it at the type level prevents me from doing what I
> want and serves no apparent purpose. Remember that pattern synonyms are all
> about providing nice syntax, not adding essential expressiveness.
> On Apr 20, 2016 1:41 PM, "Carter Schonwald" <carter.schonwald at gmail.com>
> wrote:
>
> Shouldn't the design simply be both directions are the dual of the other,
> and pure in some sense ?
>
>
> On Wednesday, April 20, 2016, David Feuer <david.feuer at gmail.com> wrote:
>
>> To some degree, it probably could be. But I believe that imposing any
>> substantial relationship between the smart constructor and the pattern
>> synonym is likely to fall squarely into the category of things that are
>> subtle, hard, and almost completely useless. In the arrangement I
>> suggested, people would be free to do some things that "don't make sense",
>> and that doesn't bother me in the least.
>> On Apr 20, 2016 1:27 PM, "Carter Schonwald" <carter.schonwald at gmail.com>
>> wrote:
>>
>>> Would that duality be related to the given vs wanted constraints ?
>>>
>>> On Wednesday, April 20, 2016, David Feuer <david.feuer at gmail.com> wrote:
>>>
>>>> As far as I can tell from the 7.10 documentation, it's impossible to
>>>> make a bidirectional pattern synonym used as a constructor have a
>>>> different type signature than when used as a pattern. Has this been
>>>> improved in 8.0? I really want something like
>>>>
>>>> class FastCons x xs | xs -> x where
>>>>   fcons :: x -> xs -> xs
>>>> class FastViewL x xs | xs -> x where
>>>>   fviewl :: xs -> ViewL x xs
>>>>
>>>> pattern x :<| xs <- (fviewl -> ConsL x xs) where
>>>>   x :<| xs = fcons x xs
>>>>
>>>> This would allow users to learn just *one* name, :<|, that they can
>>>> use for sequences that are consable or viewable even if they may not
>>>> be the other.
>>>>
>>>> If this is not yet possible, then I think the most intuitive approach
>>>> is to sever the notions of "pattern synonym" and "smart constructor".
>>>> So I'd write
>>>>
>>>> pattern x :<| xs <- (fviewl -> ConsL x xs)
>>>> constructor (:<|) = fcons
>>>>
>>>> The current syntax could easily be desugared to produce *both* a
>>>> pattern synonym and a smart constructor in the bidirectional case.
>>>> _______________________________________________
>>>> 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/20160420/79c91d0f/attachment-0001.html>

From nair.sreenidhi at gmail.com  Thu Apr 21 14:36:07 2016
From: nair.sreenidhi at gmail.com (Sreenidhi Nair)
Date: Thu, 21 Apr 2016 20:06:07 +0530
Subject: Possible compile time regression in GHC 8
Message-ID: <CABhZaDehfujFy-Z2UsHpB=YjYNHan2m4-W8iow6patuyMPaptg@mail.gmail.com>

Hello,

While compiling the `record` package with ghc-8 rc3 with `stack build`, the
memory usage went above 6gb and started trashing. But when `stack build
--fast` (-O0) was being used the package compiled with maximum memory at
1.8gb.

Also `stack build` works fine with ghc-7.10.3 with the build taking about
1.7gb. Attached is the stack file to reproduce the issue.

Steps to reproduce:
1. Create a new directory and put the attached stack.yaml there.
2. run `stack build` - this will thrash after some time
3. run `stack build --fast` - this will succeed
4. run `stack build --resolver=ghc-7.10.3` - this will succeed as well
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160421/6a4d3ddd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stack.yaml
Type: application/x-yaml
Size: 498 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160421/6a4d3ddd/attachment.bin>

From ben at smart-cactus.org  Thu Apr 21 15:04:36 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 21 Apr 2016 17:04:36 +0200
Subject: Possible compile time regression in GHC 8
In-Reply-To: <CABhZaDehfujFy-Z2UsHpB=YjYNHan2m4-W8iow6patuyMPaptg@mail.gmail.com>
References: <CABhZaDehfujFy-Z2UsHpB=YjYNHan2m4-W8iow6patuyMPaptg@mail.gmail.com>
Message-ID: <87potjt33v.fsf@smart-cactus.org>

Sreenidhi Nair <nair.sreenidhi at gmail.com> writes:

> Hello,
>
> While compiling the `record` package with ghc-8 rc3 with `stack build`, the
> memory usage went above 6gb and started trashing. But when `stack build
> --fast` (-O0) was being used the package compiled with maximum memory at
> 1.8gb.
>
Can you provide a reproduction case that does not rely on stack? As far
as I can tell record has not been updated for GHC 8 (or even since 2015
[1]).

Cheers,

- Ben


[1] https://github.com/nikita-volkov/record
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160421/ecea213a/attachment.sig>

From ben at well-typed.com  Thu Apr 21 15:08:50 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 21 Apr 2016 17:08:50 +0200
Subject: [Diffusion] [Build Failed] rGHC55b1b85df424: Accept tcrun045
 output
In-Reply-To: <57112c328ba244eea7130a3253e344b4@DB4PR30MB030.064d.mgd.msft.net>
References: <diffusion-audit-PHID-CMIT-wpe3failx3ivocqvp6sv@phabricator.haskell.org>
 <20160420204843.123879.90990.C2678174@phabricator.haskell.org>
 <57112c328ba244eea7130a3253e344b4@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <87mvont2wt.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> Ben: now are down to T4029 with max-bytes increased. Maybe just
> increase it? it's a flaky number because it depends on timing of major
> gc
>
Done in 8c33cd4fde89a367e427116b7c5dda019b5bf813.

Cheers,

- Ben

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

From nair.sreenidhi at gmail.com  Thu Apr 21 18:37:26 2016
From: nair.sreenidhi at gmail.com (Sreenidhi Nair)
Date: Fri, 22 Apr 2016 00:07:26 +0530
Subject: Possible compile time regression in GHC 8
In-Reply-To: <87potjt33v.fsf@smart-cactus.org>
References: <CABhZaDehfujFy-Z2UsHpB=YjYNHan2m4-W8iow6patuyMPaptg@mail.gmail.com>
 <87potjt33v.fsf@smart-cactus.org>
Message-ID: <CABhZaDeYoi-SjovRQVRowAYwF+GJ2V+1oZUvSw6PJkzc9gL4gQ@mail.gmail.com>

Hello Ben,

We were trying to get `record` working on ghc-8 when we observed this
issue. Nikita has kindly merged in our pull request which makes `record`
now work on ghc-8. These were the steps we followed to reproduce the issue
with cabal

|23:52:40| ~/ghc-8-TH :git clone
https://github.com/nikita-volkov/base-prelude
Cloning into 'base-prelude'...
|23:53:03| ~/ghc-8-TH :git clone https://github.com/nikita-volkov/record
Cloning into 'record'...
|23:53:12| ~/ghc-8-TH :cd record
|23:53:15| ~/ghc-8-TH/record :cabal --version
cabal-install version 1.23.0.0
compiled using version 1.23.1.0 of the Cabal library
|23:53:19| ~/ghc-8-TH/record :ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160411
|23:53:23| ~/ghc-8-TH/record :cabal sandbox init
Writing a default package environment file to
/home/sreenidhi/ghc-8-TH/record/cabal.sandbox.config
Creating a new sandbox at /home/sreenidhi/ghc-8-TH/record/.cabal-sandbox
|23:53:26| ~/ghc-8-TH/record :cabal sandbox add-source ../base-prelude
|23:53:34| ~/ghc-8-TH/record :cabal install --dependencies-only

now doing a `cabal build` takes about 2.8 g memory and took nearly 3
minutes to complete. After switching to ghc 7.10.3

|23:43:49| ~/ghc-8-TH/record :cabal --version
cabal-install version 1.22.9.0
using version 1.22.8.0 of the Cabal library
|0:01:05| ~/ghc-8-TH/record :ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.3

`cabal build` took about 1.2g memory and completed in 1 minute 40 secs.
When -O0 option was passed the memory consumed was about the same in both 8
and 7.10.3 but time taken was nearly double for 8. These measurements were
roughly noted from `top` so may not be entirely accurate.

Please let me know if you need any further information.


On Thu, Apr 21, 2016 at 8:34 PM, Ben Gamari <ben at smart-cactus.org> wrote:

> Sreenidhi Nair <nair.sreenidhi at gmail.com> writes:
>
> > Hello,
> >
> > While compiling the `record` package with ghc-8 rc3 with `stack build`,
> the
> > memory usage went above 6gb and started trashing. But when `stack build
> > --fast` (-O0) was being used the package compiled with maximum memory at
> > 1.8gb.
> >
> Can you provide a reproduction case that does not rely on stack? As far
> as I can tell record has not been updated for GHC 8 (or even since 2015
> [1]).
>
> Cheers,
>
> - Ben
>
>
> [1] https://github.com/nikita-volkov/record
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160422/abe2bd25/attachment.html>

From alex.dzyoba at gmail.com  Thu Apr 21 20:22:59 2016
From: alex.dzyoba at gmail.com (Alex Dzyoba)
Date: Thu, 21 Apr 2016 23:22:59 +0300
Subject: CmmSwitchTest
Message-ID: <CAJWW8ffintM5f1fcBQKd3voJJ--v5UVzEbbLcVzgmeHX6T7Pwg@mail.gmail.com>

Hello,

I was trying to reproduce issue #11297 (CmmSwitchTest is broken on
32-bit platforms ) from Newcomers page and seems to stuck. I would
like to ask for help here, but if there is a more suitable place to
ask, please let me know.

I've built current master (8c33cd4) stage2 compiler, removed
"when(wordsize(32), expect_broken(11297))" from
testsuite/tests/codeGen/should_run/all.T to see same errors as in
issue and got this (unrelated?) assertion:

=====> CmmSwitchTest(normal) 1 of 1 [0, 0, 0]
cd ./codeGen/should_run &&  "/home/avd/ghc/inplace/test
spaces/ghc-stage2" -o CmmSwitchTest CmmSwitchTest.hs -fforce-recomp
-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts
-fno-warn-tabs -fno-warn-missed-specialisations -fshow-warning-groups
-fno-ghci-history   > CmmSwitchTest.comp.stderr 2>&1
Compile failed (status 256) errors were:
[1 of 1] Compiling Main             ( CmmSwitchTest.hs, CmmSwitchTest.o )
ghc-stage2: panic! (the 'impossible' happened)
  (GHC version 8.1.20160419 for i386-unknown-linux):
    ASSERT failed!
  CallStack (from HasCallStack):
  assertPprPanic, called at compiler/basicTypes/Literal.hs:224:75 in ghc:Literal
  18446744073709551615

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


*** unexpected failure for CmmSwitchTest(normal)

Is there anything I can do with this? Is it because that test has
64-bit unboxed integers and I'm running it on 32-bit VM?

Thanks,
Alex

From mail at joachim-breitner.de  Thu Apr 21 20:50:14 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 21 Apr 2016 22:50:14 +0200
Subject: CmmSwitchTest
In-Reply-To: <CAJWW8ffintM5f1fcBQKd3voJJ--v5UVzEbbLcVzgmeHX6T7Pwg@mail.gmail.com>
References: <CAJWW8ffintM5f1fcBQKd3voJJ--v5UVzEbbLcVzgmeHX6T7Pwg@mail.gmail.com>
Message-ID: <1461271814.15648.3.camel@joachim-breitner.de>

Hi Alex,

welcome on ghc-dev.

Am Donnerstag, den 21.04.2016, 23:22 +0300 schrieb Alex Dzyoba:
> I was trying to reproduce issue #11297 (CmmSwitchTest is broken on
> 32-bit platforms ) from Newcomers page and seems to stuck. I would
> like to ask for help here, but if there is a more suitable place to
> ask, please let me know.

This is the right place!

> I've built current master (8c33cd4) stage2 compiler, removed
> "when(wordsize(32), expect_broken(11297))" from
> testsuite/tests/codeGen/should_run/all.T to see same errors as in
> issue and got this (unrelated?) assertion:

I don?t think it is entirely unrelated, but there is a separate ticket
about this:
https://ghc.haskell.org/trac/ghc/ticket/10246
It even proposes a fix.

But if you want to be unblocked in implementing #11297, simply comment
out the assertion in Literal.hs (just for you), or compile without
-DDEBUG.



> Is there anything I can do with this? Is it because that test has
> 64-bit unboxed integers and I'm running it on 32-bit VM?

Right, but that is the point of #11297: The test case is tailored to 64
bit, and the task is to create a second test case with 32 bit numbers.



Greetings,
Joachim
-- 
Joachim ?nomeata? Breitner
? mail at joachim-breitner.de ? https://www.joachim-breitner.de/
? XMPP: nomeata at joachim-breitner.de?? OpenPGP-Key: 0xF0FBF51F
? Debian Developer: nomeata at debian.org

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

From alex.dzyoba at gmail.com  Fri Apr 22 07:14:56 2016
From: alex.dzyoba at gmail.com (Alex Dzyoba)
Date: Fri, 22 Apr 2016 10:14:56 +0300
Subject: CmmSwitchTest
In-Reply-To: <1461271814.15648.3.camel@joachim-breitner.de>
References: <CAJWW8ffintM5f1fcBQKd3voJJ--v5UVzEbbLcVzgmeHX6T7Pwg@mail.gmail.com>
 <1461271814.15648.3.camel@joachim-breitner.de>
Message-ID: <20160422071220.GA5738@alien>

On Thu, Apr 21, 2016 at 10:50:14PM +0200, Joachim Breitner wrote:
> 
> I don?t think it is entirely unrelated, but there is a separate ticket
> about this:
> https://ghc.haskell.org/trac/ghc/ticket/10246
> It even proposes a fix.
> 
> But if you want to be unblocked in implementing #11297, simply comment
> out the assertion in Literal.hs (just for you), or compile without
> -DDEBUG.

Without asserts it's reproducing. Thanks a lot!

> > Is there anything I can do with this? Is it because that test has
> > 64-bit unboxed integers and I'm running it on 32-bit VM?
> 
> Right, but that is the point of #11297: The test case is tailored to 64
> bit, and the task is to create a second test case with 32 bit numbers.

Yes, I saw that it's tricking integer overflow but only for 64 bit. I will come
back later with the new test.

Thanks,
Alex

From yannick.boesmans at gmail.com  Fri Apr 22 10:58:45 2016
From: yannick.boesmans at gmail.com (Yannick Boesmans)
Date: Fri, 22 Apr 2016 10:58:45 +0000
Subject: Accessing dictionaries from a GHC plugin
Message-ID: <CAFQR6mbiT=ixFUGNBF0iR96KCNXs+z0UiFs02kAH0hAN+kfRdg@mail.gmail.com>

Hi,

I'm trying to develop a GHC plugin to transform effect handlers for free
monads. I have created my own module with the free monad definitions. The
goal is that if a user uses these definitions, my plugin will rewrite the
handlers into a form which will allow fusion.


For a first simple example I'm trying to transform the following code:

handleNondet :: Functor g => Free (Nondet + g) a -> Free g [a]
handleNondet = \y -> case y of
    Var x -> Var [x]
    Con op -> case op of
        Inl x -> case x of
            Or l r -> (handleNondet l >>= (\ll -> handleNondet r >>= (\rr
-> Var (ll ++ rr))))
        Inr x -> Con (fmap handleNondet x)


into this:

handleNondet :: Functor g => Free (Nondet + g) a -> Free g [a]
handleNondet = foldFree genNondet algNondet

genNondet :: Functor g => a -> Free g [a]
genNondet x = Var [x]

algNondet :: Functor g => (Nondet + g) (Free g [a]) -> Free g [a]
algNondet op = case op of
    Inl x -> case x of
        Or l r -> (l >>= (\ll -> r >>= (\rr -> Var (ll ++ rr))))
    Inr x -> Con x

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

In my module with definitions, Free, Con, Var, the (+), Inl and Inr are
defined and the foldFree function is defined.
There is also a functor instance:    instance (Functor f, Functor g) =>
Functor (f + g)


The problem is that when trying to do this transformation in GHC Core, I
only get a dictionary for the functor g, but not for Nondet or for
(Nondet + g).
What is need is of the form:
(WhatMorphism.Free.$fFunctor+
                @ Nondet @ g_a2MS Types.$fFunctorNondet $dFunctor_a2R9)

and I have access to @ Nondet, @ g_a2MS and $dFunctor_a2R9, but I don't
know how to find WhatMorphism.Free.$fFunctor+ and Types.$fFunctorNondet.

I am trying to find out whether it is possible to find these dictionaries
from a GHC Core plugin, or whether this has to happen in an earlier stage
of the compilation. If it is possible, how would I go about it? And if it
is not, where should I start looking to implement this functionality anyway?

Regards,
Yannick Boesmans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160422/2c2255b6/attachment.html>

From ben at smart-cactus.org  Fri Apr 22 13:01:49 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Fri, 22 Apr 2016 15:01:49 +0200
Subject: Accessing dictionaries from a GHC plugin
In-Reply-To: <CAFQR6mbiT=ixFUGNBF0iR96KCNXs+z0UiFs02kAH0hAN+kfRdg@mail.gmail.com>
References: <CAFQR6mbiT=ixFUGNBF0iR96KCNXs+z0UiFs02kAH0hAN+kfRdg@mail.gmail.com>
Message-ID: <878u05u79e.fsf@smart-cactus.org>

Yannick Boesmans <yannick.boesmans at gmail.com> writes:

snip
>
> In my module with definitions, Free, Con, Var, the (+), Inl and Inr are
> defined and the foldFree function is defined.
> There is also a functor instance:    instance (Functor f, Functor g) =>
> Functor (f + g)
>
>
> The problem is that when trying to do this transformation in GHC Core, I
> only get a dictionary for the functor g, but not for Nondet or for
> (Nondet + g).
> What is need is of the form:
> (WhatMorphism.Free.$fFunctor+
>                 @ Nondet @ g_a2MS Types.$fFunctorNondet $dFunctor_a2R9)
>
> and I have access to @ Nondet, @ g_a2MS and $dFunctor_a2R9, but I don't
> know how to find WhatMorphism.Free.$fFunctor+ and Types.$fFunctorNondet.
>
Ahh, I see; is DataCon.classDataCon perhaps what you are looking for?
Given the Class you should be able to construct the needed dictionary
(hopefully it's not too difficult to construct).

Looking up your class will likely involve starting with the OccName,
looking it up in the name cache, then using MonadThings.lookupTyCon to
grab the TyCon. Then you can use TyCon.tyConClass_maybe to fetch the
Class from your TyCon. Then you should have everything you need to
construct your dictionary.

Cheers,

- Ben

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

From ben at well-typed.com  Fri Apr 22 14:27:18 2016
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 22 Apr 2016 16:27:18 +0200
Subject: GHC 8.0.1-rc4 source tarball availability
Message-ID: <877ffpu3ax.fsf@smart-cactus.org>

tl;dr: If you would like to produce a binary distribution for GHC
       8.0.1-rc4 then let us know, grab the source distribution and
       start building. The binary distributions will be all released one
       week from today.

Hello GHC packagers,

I am happy to announce the release of the 8.0.1-rc4 source distribution
to binary packagers. This release should resolve all of the issues noted
in the release candidate 3 announcement. You will find the usual
artifacts at

    http://downloads.haskell.org/~ghc/8.0.1-rc4/

For this candidate we are again following our new release policy [1],
with a one-week delay between the release of the source and binary
distributions. The goal of this policy is to give all platforms the
opportunity for support from the first day of a release.

If all of the expected binary releases are submitted before the
week-long delay has elapsed, we will move forward with the release of
the binaries on an accelerated schedule. It would be appreciated if you
could reply to this message confirming that you intend to offer a binary
distribution this release.

Otherwise, let either Austin or I know if you have any trouble building
your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case we
encounter unexpected issues but all of my builds with this tarball
thusfar have gone quite well.

Good luck and thanks for all of your work!

Cheers,

- Ben


[1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160422/dd56d2f0/attachment.sig>

From carter.schonwald at gmail.com  Fri Apr 22 15:08:31 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 22 Apr 2016 11:08:31 -0400
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <877ffpu3ax.fsf@smart-cactus.org>
References: <877ffpu3ax.fsf@smart-cactus.org>
Message-ID: <CAHYVw0yjdjAawOCSvP7dD9WNcyDn6ry-YU7q17mpd44dMe5r7Q@mail.gmail.com>

heres my OSX build that matches up with that RC4 commit / 8.0 tip
https://wellposed-carter-files.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz

$ shasum -a512 ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz
3ecd0a9c4578ac38883de03f66e8d86955368eec2bea52a409de0053386b53c89ac954b2806ef5ac73bb924d62821ce685ff5301b780646fedd45c99d5942a90
 ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz

On Fri, Apr 22, 2016 at 10:27 AM, Ben Gamari <ben at well-typed.com> wrote:

> tl;dr: If you would like to produce a binary distribution for GHC
>        8.0.1-rc4 then let us know, grab the source distribution and
>        start building. The binary distributions will be all released one
>        week from today.
>
> Hello GHC packagers,
>
> I am happy to announce the release of the 8.0.1-rc4 source distribution
> to binary packagers. This release should resolve all of the issues noted
> in the release candidate 3 announcement. You will find the usual
> artifacts at
>
>     http://downloads.haskell.org/~ghc/8.0.1-rc4/
>
> For this candidate we are again following our new release policy [1],
> with a one-week delay between the release of the source and binary
> distributions. The goal of this policy is to give all platforms the
> opportunity for support from the first day of a release.
>
> If all of the expected binary releases are submitted before the
> week-long delay has elapsed, we will move forward with the release of
> the binaries on an accelerated schedule. It would be appreciated if you
> could reply to this message confirming that you intend to offer a binary
> distribution this release.
>
> Otherwise, let either Austin or I know if you have any trouble building
> your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case we
> encounter unexpected issues but all of my builds with this tarball
> thusfar have gone quite well.
>
> Good luck and thanks for all of your work!
>
> Cheers,
>
> - Ben
>
>
> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.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/20160422/4f77fee8/attachment.html>

From ben at well-typed.com  Fri Apr 22 15:46:12 2016
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 22 Apr 2016 17:46:12 +0200
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAHYVw0yjdjAawOCSvP7dD9WNcyDn6ry-YU7q17mpd44dMe5r7Q@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAHYVw0yjdjAawOCSvP7dD9WNcyDn6ry-YU7q17mpd44dMe5r7Q@mail.gmail.com>
Message-ID: <874mattznf.fsf@smart-cactus.org>

Carter Schonwald <carter.schonwald at gmail.com> writes:

> heres my OSX build that matches up with that RC4 commit / 8.0 tip
> https://wellposed-carter-files.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz
>
> $ shasum -a512 ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz
> 3ecd0a9c4578ac38883de03f66e8d86955368eec2bea52a409de0053386b53c89ac954b2806ef5ac73bb924d62821ce685ff5301b780646fedd45c99d5942a90
>  ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz
>
Thanks Carter!

Cheers,

- Ben

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

From pali.gabor at gmail.com  Fri Apr 22 21:08:48 2016
From: pali.gabor at gmail.com (=?UTF-8?B?UMOhbGkgR8OhYm9yIErDoW5vcw==?=)
Date: Fri, 22 Apr 2016 23:08:48 +0200
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <877ffpu3ax.fsf@smart-cactus.org>
References: <877ffpu3ax.fsf@smart-cactus.org>
Message-ID: <CAHnG2Cz4F6rOoOUd1neccrcOwLaVPbtvOhfODSw3BRv2drzaHg@mail.gmail.com>

2016-04-22 16:27 GMT+02:00 Ben Gamari <ben at well-typed.com>:
> tl;dr: If you would like to produce a binary distribution for GHC
>        8.0.1-rc4 then let us know, grab the source distribution and
>        start building.

The FreeBSD builds (32- and 64-bit, for 9.3-RELEASE or later) are now
available there:

http://haskell.inf.elte.hu/ghc/8.0.0.20160421/

From george.colpitts at gmail.com  Sat Apr 23 13:37:50 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Sat, 23 Apr 2016 13:37:50 +0000
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <877ffpu3ax.fsf@smart-cactus.org>
References: <877ffpu3ax.fsf@smart-cactus.org>
Message-ID: <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>

I'm having problems using the Apple toolchain to build this on Mac OS. Has
anybody succeeded with the Apple toolchain?

First I get the error:

     broken 'nm' detected, see https://ghc.haskell.org/ticket/11744.
     Workaround: You may want to pass '--with-nm=nm-classic' to 'configure'.

but after I try that workaround I get:

inplace/bin/deriveConstants --gen-header -o
includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir
includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc"
--gcc-flag -Wall --gcc-flag -Wno-unknown-pragmas --gcc-flag -m64 --gcc-flag
-fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist
--gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag
-Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon
--nm-program "nm-classic" --target-os "darwin"
deriveConstants: nm-classic: readCreateProcess: runInteractiveProcess:
exec: does not exist (No such file or directory)
make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h]
Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2

Thanks
George

On Fri, Apr 22, 2016 at 11:27 AM Ben Gamari <ben at well-typed.com> wrote:

> tl;dr: If you would like to produce a binary distribution for GHC
>        8.0.1-rc4 then let us know, grab the source distribution and
>        start building. The binary distributions will be all released one
>        week from today.
>
> Hello GHC packagers,
>
> I am happy to announce the release of the 8.0.1-rc4 source distribution
> to binary packagers. This release should resolve all of the issues noted
> in the release candidate 3 announcement. You will find the usual
> artifacts at
>
>     http://downloads.haskell.org/~ghc/8.0.1-rc4/
>
> For this candidate we are again following our new release policy [1],
> with a one-week delay between the release of the source and binary
> distributions. The goal of this policy is to give all platforms the
> opportunity for support from the first day of a release.
>
> If all of the expected binary releases are submitted before the
> week-long delay has elapsed, we will move forward with the release of
> the binaries on an accelerated schedule. It would be appreciated if you
> could reply to this message confirming that you intend to offer a binary
> distribution this release.
>
> Otherwise, let either Austin or I know if you have any trouble building
> your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case we
> encounter unexpected issues but all of my builds with this tarball
> thusfar have gone quite well.
>
> Good luck and thanks for all of your work!
>
> Cheers,
>
> - Ben
>
>
> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.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/20160423/b5f8952f/attachment.html>

From carter.schonwald at gmail.com  Sat Apr 23 13:42:42 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 23 Apr 2016 09:42:42 -0400
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
Message-ID: <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>

I've a working build I'll circulate
Also that path to nm classic is wrong.

On Saturday, April 23, 2016, George Colpitts <george.colpitts at gmail.com>
wrote:

> I'm having problems using the Apple toolchain to build this on Mac OS. Has
> anybody succeeded with the Apple toolchain?
>
> First I get the error:
>
>      broken 'nm' detected, see https://ghc.haskell.org/ticket/11744.
>      Workaround: You may want to pass '--with-nm=nm-classic' to
> 'configure'.
>
> but after I try that workaround I get:
>
> inplace/bin/deriveConstants --gen-header -o
> includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir
> includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc"
> --gcc-flag -Wall --gcc-flag -Wno-unknown-pragmas --gcc-flag -m64 --gcc-flag
> -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist
> --gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag
> -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon
> --nm-program "nm-classic" --target-os "darwin"
> deriveConstants: nm-classic: readCreateProcess: runInteractiveProcess:
> exec: does not exist (No such file or directory)
> make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h]
> Error 1
> make[1]: *** Waiting for unfinished jobs....
> make: *** [all] Error 2
>
> Thanks
> George
>
> On Fri, Apr 22, 2016 at 11:27 AM Ben Gamari <ben at well-typed.com
> <javascript:_e(%7B%7D,'cvml','ben at well-typed.com');>> wrote:
>
>> tl;dr: If you would like to produce a binary distribution for GHC
>>        8.0.1-rc4 then let us know, grab the source distribution and
>>        start building. The binary distributions will be all released one
>>        week from today.
>>
>> Hello GHC packagers,
>>
>> I am happy to announce the release of the 8.0.1-rc4 source distribution
>> to binary packagers. This release should resolve all of the issues noted
>> in the release candidate 3 announcement. You will find the usual
>> artifacts at
>>
>>     http://downloads.haskell.org/~ghc/8.0.1-rc4/
>>
>> For this candidate we are again following our new release policy [1],
>> with a one-week delay between the release of the source and binary
>> distributions. The goal of this policy is to give all platforms the
>> opportunity for support from the first day of a release.
>>
>> If all of the expected binary releases are submitted before the
>> week-long delay has elapsed, we will move forward with the release of
>> the binaries on an accelerated schedule. It would be appreciated if you
>> could reply to this message confirming that you intend to offer a binary
>> distribution this release.
>>
>> Otherwise, let either Austin or I know if you have any trouble building
>> your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case we
>> encounter unexpected issues but all of my builds with this tarball
>> thusfar have gone quite well.
>>
>> Good luck and thanks for all of your work!
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> <javascript:_e(%7B%7D,'cvml','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/20160423/5d4fabf3/attachment.html>

From george.colpitts at gmail.com  Sat Apr 23 13:49:24 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Sat, 23 Apr 2016 13:49:24 +0000
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
Message-ID: <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>

Thanks Carter. I'm not so concerned with obtaining a working build. I'd
like to be able to build with the Apple toolchain. I assume there are other
developers who feel the same.

Can you elaborate on the "path to nm classic is wrong" ?

Cheers
George

On Sat, Apr 23, 2016 at 10:42 AM Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> I've a working build I'll circulate
> Also that path to nm classic is wrong.
>
>
> On Saturday, April 23, 2016, George Colpitts <george.colpitts at gmail.com>
> wrote:
>
>> I'm having problems using the Apple toolchain to build this on Mac OS.
>> Has anybody succeeded with the Apple toolchain?
>>
>> First I get the error:
>>
>>      broken 'nm' detected, see https://ghc.haskell.org/ticket/11744.
>>      Workaround: You may want to pass '--with-nm=nm-classic' to
>> 'configure'.
>>
>> but after I try that workaround I get:
>>
>> inplace/bin/deriveConstants --gen-header -o
>> includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir
>> includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc"
>> --gcc-flag -Wall --gcc-flag -Wno-unknown-pragmas --gcc-flag -m64 --gcc-flag
>> -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist
>> --gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag
>> -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon
>> --nm-program "nm-classic" --target-os "darwin"
>> deriveConstants: nm-classic: readCreateProcess: runInteractiveProcess:
>> exec: does not exist (No such file or directory)
>> make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h]
>> Error 1
>> make[1]: *** Waiting for unfinished jobs....
>> make: *** [all] Error 2
>>
>> Thanks
>> George
>>
>> On Fri, Apr 22, 2016 at 11:27 AM Ben Gamari <ben at well-typed.com> wrote:
>>
>>> tl;dr: If you would like to produce a binary distribution for GHC
>>>        8.0.1-rc4 then let us know, grab the source distribution and
>>>        start building. The binary distributions will be all released one
>>>        week from today.
>>>
>>> Hello GHC packagers,
>>>
>>> I am happy to announce the release of the 8.0.1-rc4 source distribution
>>> to binary packagers. This release should resolve all of the issues noted
>>> in the release candidate 3 announcement. You will find the usual
>>> artifacts at
>>>
>>>     http://downloads.haskell.org/~ghc/8.0.1-rc4/
>>>
>>> For this candidate we are again following our new release policy [1],
>>> with a one-week delay between the release of the source and binary
>>> distributions. The goal of this policy is to give all platforms the
>>> opportunity for support from the first day of a release.
>>>
>>> If all of the expected binary releases are submitted before the
>>> week-long delay has elapsed, we will move forward with the release of
>>> the binaries on an accelerated schedule. It would be appreciated if you
>>> could reply to this message confirming that you intend to offer a binary
>>> distribution this release.
>>>
>>> Otherwise, let either Austin or I know if you have any trouble building
>>> your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case we
>>> encounter unexpected issues but all of my builds with this tarball
>>> thusfar have gone quite well.
>>>
>>> Good luck and thanks for all of your work!
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>>
>>> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.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/20160423/795a2bd5/attachment-0001.html>

From george.colpitts at gmail.com  Sat Apr 23 13:52:23 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Sat, 23 Apr 2016 13:52:23 +0000
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
 <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>
Message-ID: <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>

retrying with

./configure --with-nm=$(xcode-select
-p)/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic

On Sat, Apr 23, 2016 at 10:49 AM George Colpitts <george.colpitts at gmail.com>
wrote:

> Thanks Carter. I'm not so concerned with obtaining a working build. I'd
> like to be able to build with the Apple toolchain. I assume there are other
> developers who feel the same.
>
> Can you elaborate on the "path to nm classic is wrong" ?
>
> Cheers
> George
>
> On Sat, Apr 23, 2016 at 10:42 AM Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> I've a working build I'll circulate
>> Also that path to nm classic is wrong.
>>
>>
>> On Saturday, April 23, 2016, George Colpitts <george.colpitts at gmail.com>
>> wrote:
>>
>>> I'm having problems using the Apple toolchain to build this on Mac OS.
>>> Has anybody succeeded with the Apple toolchain?
>>>
>>> First I get the error:
>>>
>>>      broken 'nm' detected, see https://ghc.haskell.org/ticket/11744.
>>>      Workaround: You may want to pass '--with-nm=nm-classic' to
>>> 'configure'.
>>>
>>> but after I try that workaround I get:
>>>
>>> inplace/bin/deriveConstants --gen-header -o
>>> includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir
>>> includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc"
>>> --gcc-flag -Wall --gcc-flag -Wno-unknown-pragmas --gcc-flag -m64 --gcc-flag
>>> -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist
>>> --gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag
>>> -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon
>>> --nm-program "nm-classic" --target-os "darwin"
>>> deriveConstants: nm-classic: readCreateProcess: runInteractiveProcess:
>>> exec: does not exist (No such file or directory)
>>> make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h]
>>> Error 1
>>> make[1]: *** Waiting for unfinished jobs....
>>> make: *** [all] Error 2
>>>
>>> Thanks
>>> George
>>>
>>> On Fri, Apr 22, 2016 at 11:27 AM Ben Gamari <ben at well-typed.com> wrote:
>>>
>>>> tl;dr: If you would like to produce a binary distribution for GHC
>>>>        8.0.1-rc4 then let us know, grab the source distribution and
>>>>        start building. The binary distributions will be all released one
>>>>        week from today.
>>>>
>>>> Hello GHC packagers,
>>>>
>>>> I am happy to announce the release of the 8.0.1-rc4 source distribution
>>>> to binary packagers. This release should resolve all of the issues noted
>>>> in the release candidate 3 announcement. You will find the usual
>>>> artifacts at
>>>>
>>>>     http://downloads.haskell.org/~ghc/8.0.1-rc4/
>>>>
>>>> For this candidate we are again following our new release policy [1],
>>>> with a one-week delay between the release of the source and binary
>>>> distributions. The goal of this policy is to give all platforms the
>>>> opportunity for support from the first day of a release.
>>>>
>>>> If all of the expected binary releases are submitted before the
>>>> week-long delay has elapsed, we will move forward with the release of
>>>> the binaries on an accelerated schedule. It would be appreciated if you
>>>> could reply to this message confirming that you intend to offer a binary
>>>> distribution this release.
>>>>
>>>> Otherwise, let either Austin or I know if you have any trouble building
>>>> your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case we
>>>> encounter unexpected issues but all of my builds with this tarball
>>>> thusfar have gone quite well.
>>>>
>>>> Good luck and thanks for all of your work!
>>>>
>>>> Cheers,
>>>>
>>>> - Ben
>>>>
>>>>
>>>> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.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/20160423/64aeee49/attachment.html>

From juhpetersen at gmail.com  Sat Apr 23 14:16:17 2016
From: juhpetersen at gmail.com (Jens Petersen)
Date: Sat, 23 Apr 2016 23:16:17 +0900
Subject: [ANNOUNCE] GHC 8.0.1 release candidate 3 available
In-Reply-To: <87d1pmvgjf.fsf@smart-cactus.org>
References: <87d1pmvgjf.fsf@smart-cactus.org>
Message-ID: <CAEDGBqJYibbZ=Ur-xeb=VFR7PUW8NPffucVDqeevwEY9yBoGNQ@mail.gmail.com>

On 19 April 2016 at 04:54, Ben Gamari <ben at well-typed.com> wrote:
> The GHC team is happy to announce the availability of third release
> candidate of the Glasgow Haskell Compiler's 8.0.1 release. Source and
> binary distributions can be found at,
>
>     http://downloads.haskell.org/~ghc/8.0.1-rc3/

Thank you!  Sorry for the delay I have now done perf builds in my Fedora Copr:

https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.1/

Jens

ps next onto RC4. :)

From carter.schonwald at gmail.com  Sat Apr 23 15:51:20 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 23 Apr 2016 11:51:20 -0400
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
 <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>
 <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>
Message-ID: <CAHYVw0x6hMfh8FHrDbhd5UC_yQOd_5JVv+M_FiiUN===TYiFCQ@mail.gmail.com>

i'm running into some confusions with getting docs built correclty / not
generating the pdfs and html assets i expect, i'll share an updated sha etc
when i track that down

On Sat, Apr 23, 2016 at 9:52 AM, George Colpitts <george.colpitts at gmail.com>
wrote:

> retrying with
>
> ./configure --with-nm=$(xcode-select
> -p)/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic
>
> On Sat, Apr 23, 2016 at 10:49 AM George Colpitts <
> george.colpitts at gmail.com> wrote:
>
>> Thanks Carter. I'm not so concerned with obtaining a working build. I'd
>> like to be able to build with the Apple toolchain. I assume there are other
>> developers who feel the same.
>>
>> Can you elaborate on the "path to nm classic is wrong" ?
>>
>> Cheers
>> George
>>
>> On Sat, Apr 23, 2016 at 10:42 AM Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> I've a working build I'll circulate
>>> Also that path to nm classic is wrong.
>>>
>>>
>>> On Saturday, April 23, 2016, George Colpitts <george.colpitts at gmail.com>
>>> wrote:
>>>
>>>> I'm having problems using the Apple toolchain to build this on Mac OS.
>>>> Has anybody succeeded with the Apple toolchain?
>>>>
>>>> First I get the error:
>>>>
>>>>      broken 'nm' detected, see https://ghc.haskell.org/ticket/11744.
>>>>      Workaround: You may want to pass '--with-nm=nm-classic' to
>>>> 'configure'.
>>>>
>>>> but after I try that workaround I get:
>>>>
>>>> inplace/bin/deriveConstants --gen-header -o
>>>> includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir
>>>> includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc"
>>>> --gcc-flag -Wall --gcc-flag -Wno-unknown-pragmas --gcc-flag -m64 --gcc-flag
>>>> -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist
>>>> --gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag
>>>> -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon
>>>> --nm-program "nm-classic" --target-os "darwin"
>>>> deriveConstants: nm-classic: readCreateProcess: runInteractiveProcess:
>>>> exec: does not exist (No such file or directory)
>>>> make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h]
>>>> Error 1
>>>> make[1]: *** Waiting for unfinished jobs....
>>>> make: *** [all] Error 2
>>>>
>>>> Thanks
>>>> George
>>>>
>>>> On Fri, Apr 22, 2016 at 11:27 AM Ben Gamari <ben at well-typed.com> wrote:
>>>>
>>>>> tl;dr: If you would like to produce a binary distribution for GHC
>>>>>        8.0.1-rc4 then let us know, grab the source distribution and
>>>>>        start building. The binary distributions will be all released
>>>>> one
>>>>>        week from today.
>>>>>
>>>>> Hello GHC packagers,
>>>>>
>>>>> I am happy to announce the release of the 8.0.1-rc4 source distribution
>>>>> to binary packagers. This release should resolve all of the issues
>>>>> noted
>>>>> in the release candidate 3 announcement. You will find the usual
>>>>> artifacts at
>>>>>
>>>>>     http://downloads.haskell.org/~ghc/8.0.1-rc4/
>>>>>
>>>>> For this candidate we are again following our new release policy [1],
>>>>> with a one-week delay between the release of the source and binary
>>>>> distributions. The goal of this policy is to give all platforms the
>>>>> opportunity for support from the first day of a release.
>>>>>
>>>>> If all of the expected binary releases are submitted before the
>>>>> week-long delay has elapsed, we will move forward with the release of
>>>>> the binaries on an accelerated schedule. It would be appreciated if you
>>>>> could reply to this message confirming that you intend to offer a
>>>>> binary
>>>>> distribution this release.
>>>>>
>>>>> Otherwise, let either Austin or I know if you have any trouble building
>>>>> your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case we
>>>>> encounter unexpected issues but all of my builds with this tarball
>>>>> thusfar have gone quite well.
>>>>>
>>>>> Good luck and thanks for all of your work!
>>>>>
>>>>> Cheers,
>>>>>
>>>>> - Ben
>>>>>
>>>>>
>>>>> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.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/20160423/e1463910/attachment-0001.html>

From carter.schonwald at gmail.com  Sat Apr 23 16:18:12 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 23 Apr 2016 12:18:12 -0400
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAHYVw0x6hMfh8FHrDbhd5UC_yQOd_5JVv+M_FiiUN===TYiFCQ@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
 <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>
 <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>
 <CAHYVw0x6hMfh8FHrDbhd5UC_yQOd_5JVv+M_FiiUN===TYiFCQ@mail.gmail.com>
Message-ID: <CAHYVw0yyxE5Q5EwHcEXF6k7bbMr_A5OXrFg7q0eR4Tphe8qM+g@mail.gmail.com>

looks like i dont have dblatex setup on that build machine, fixing that
now! (slightly trick on mac)

On Sat, Apr 23, 2016 at 11:51 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> i'm running into some confusions with getting docs built correclty / not
> generating the pdfs and html assets i expect, i'll share an updated sha etc
> when i track that down
>
> On Sat, Apr 23, 2016 at 9:52 AM, George Colpitts <
> george.colpitts at gmail.com> wrote:
>
>> retrying with
>>
>> ./configure --with-nm=$(xcode-select
>> -p)/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic
>>
>> On Sat, Apr 23, 2016 at 10:49 AM George Colpitts <
>> george.colpitts at gmail.com> wrote:
>>
>>> Thanks Carter. I'm not so concerned with obtaining a working build. I'd
>>> like to be able to build with the Apple toolchain. I assume there are other
>>> developers who feel the same.
>>>
>>> Can you elaborate on the "path to nm classic is wrong" ?
>>>
>>> Cheers
>>> George
>>>
>>> On Sat, Apr 23, 2016 at 10:42 AM Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>> I've a working build I'll circulate
>>>> Also that path to nm classic is wrong.
>>>>
>>>>
>>>> On Saturday, April 23, 2016, George Colpitts <george.colpitts at gmail.com>
>>>> wrote:
>>>>
>>>>> I'm having problems using the Apple toolchain to build this on Mac OS.
>>>>> Has anybody succeeded with the Apple toolchain?
>>>>>
>>>>> First I get the error:
>>>>>
>>>>>      broken 'nm' detected, see https://ghc.haskell.org/ticket/11744.
>>>>>      Workaround: You may want to pass '--with-nm=nm-classic' to
>>>>> 'configure'.
>>>>>
>>>>> but after I try that workaround I get:
>>>>>
>>>>> inplace/bin/deriveConstants --gen-header -o
>>>>> includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir
>>>>> includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc"
>>>>> --gcc-flag -Wall --gcc-flag -Wno-unknown-pragmas --gcc-flag -m64 --gcc-flag
>>>>> -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist
>>>>> --gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag
>>>>> -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon
>>>>> --nm-program "nm-classic" --target-os "darwin"
>>>>> deriveConstants: nm-classic: readCreateProcess: runInteractiveProcess:
>>>>> exec: does not exist (No such file or directory)
>>>>> make[1]: ***
>>>>> [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1
>>>>> make[1]: *** Waiting for unfinished jobs....
>>>>> make: *** [all] Error 2
>>>>>
>>>>> Thanks
>>>>> George
>>>>>
>>>>> On Fri, Apr 22, 2016 at 11:27 AM Ben Gamari <ben at well-typed.com>
>>>>> wrote:
>>>>>
>>>>>> tl;dr: If you would like to produce a binary distribution for GHC
>>>>>>        8.0.1-rc4 then let us know, grab the source distribution and
>>>>>>        start building. The binary distributions will be all released
>>>>>> one
>>>>>>        week from today.
>>>>>>
>>>>>> Hello GHC packagers,
>>>>>>
>>>>>> I am happy to announce the release of the 8.0.1-rc4 source
>>>>>> distribution
>>>>>> to binary packagers. This release should resolve all of the issues
>>>>>> noted
>>>>>> in the release candidate 3 announcement. You will find the usual
>>>>>> artifacts at
>>>>>>
>>>>>>     http://downloads.haskell.org/~ghc/8.0.1-rc4/
>>>>>>
>>>>>> For this candidate we are again following our new release policy [1],
>>>>>> with a one-week delay between the release of the source and binary
>>>>>> distributions. The goal of this policy is to give all platforms the
>>>>>> opportunity for support from the first day of a release.
>>>>>>
>>>>>> If all of the expected binary releases are submitted before the
>>>>>> week-long delay has elapsed, we will move forward with the release of
>>>>>> the binaries on an accelerated schedule. It would be appreciated if
>>>>>> you
>>>>>> could reply to this message confirming that you intend to offer a
>>>>>> binary
>>>>>> distribution this release.
>>>>>>
>>>>>> Otherwise, let either Austin or I know if you have any trouble
>>>>>> building
>>>>>> your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case we
>>>>>> encounter unexpected issues but all of my builds with this tarball
>>>>>> thusfar have gone quite well.
>>>>>>
>>>>>> Good luck and thanks for all of your work!
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> - Ben
>>>>>>
>>>>>>
>>>>>> [1]
>>>>>> https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.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/20160423/b67b0800/attachment.html>

From carter.schonwald at gmail.com  Sat Apr 23 16:23:17 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 23 Apr 2016 12:23:17 -0400
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAHYVw0yyxE5Q5EwHcEXF6k7bbMr_A5OXrFg7q0eR4Tphe8qM+g@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
 <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>
 <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>
 <CAHYVw0x6hMfh8FHrDbhd5UC_yQOd_5JVv+M_FiiUN===TYiFCQ@mail.gmail.com>
 <CAHYVw0yyxE5Q5EwHcEXF6k7bbMr_A5OXrFg7q0eR4Tphe8qM+g@mail.gmail.com>
Message-ID: <CAHYVw0wHe3Pje1_s_oApM32pc=1scSgam031uruGyyL3u-wL=Q@mail.gmail.com>

err, i mean, sphinx was giving
checking for version of sphinx-build... Sphinx (sphinx-build) 1.4.1
./configure: line 9698: test: Sphinx (sphinx-build) 1: integer expression
expected

which version of sphinx for which python are we supposed to use?

On Sat, Apr 23, 2016 at 12:18 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> looks like i dont have dblatex setup on that build machine, fixing that
> now! (slightly trick on mac)
>
> On Sat, Apr 23, 2016 at 11:51 AM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> i'm running into some confusions with getting docs built correclty / not
>> generating the pdfs and html assets i expect, i'll share an updated sha etc
>> when i track that down
>>
>> On Sat, Apr 23, 2016 at 9:52 AM, George Colpitts <
>> george.colpitts at gmail.com> wrote:
>>
>>> retrying with
>>>
>>> ./configure --with-nm=$(xcode-select
>>> -p)/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic
>>>
>>> On Sat, Apr 23, 2016 at 10:49 AM George Colpitts <
>>> george.colpitts at gmail.com> wrote:
>>>
>>>> Thanks Carter. I'm not so concerned with obtaining a working build. I'd
>>>> like to be able to build with the Apple toolchain. I assume there are other
>>>> developers who feel the same.
>>>>
>>>> Can you elaborate on the "path to nm classic is wrong" ?
>>>>
>>>> Cheers
>>>> George
>>>>
>>>> On Sat, Apr 23, 2016 at 10:42 AM Carter Schonwald <
>>>> carter.schonwald at gmail.com> wrote:
>>>>
>>>>> I've a working build I'll circulate
>>>>> Also that path to nm classic is wrong.
>>>>>
>>>>>
>>>>> On Saturday, April 23, 2016, George Colpitts <
>>>>> george.colpitts at gmail.com> wrote:
>>>>>
>>>>>> I'm having problems using the Apple toolchain to build this on Mac
>>>>>> OS. Has anybody succeeded with the Apple toolchain?
>>>>>>
>>>>>> First I get the error:
>>>>>>
>>>>>>      broken 'nm' detected, see https://ghc.haskell.org/ticket/11744.
>>>>>>      Workaround: You may want to pass '--with-nm=nm-classic' to
>>>>>> 'configure'.
>>>>>>
>>>>>> but after I try that workaround I get:
>>>>>>
>>>>>> inplace/bin/deriveConstants --gen-header -o
>>>>>> includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir
>>>>>> includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc"
>>>>>> --gcc-flag -Wall --gcc-flag -Wno-unknown-pragmas --gcc-flag -m64 --gcc-flag
>>>>>> -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist
>>>>>> --gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag
>>>>>> -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon
>>>>>> --nm-program "nm-classic" --target-os "darwin"
>>>>>> deriveConstants: nm-classic: readCreateProcess:
>>>>>> runInteractiveProcess: exec: does not exist (No such file or directory)
>>>>>> make[1]: ***
>>>>>> [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1
>>>>>> make[1]: *** Waiting for unfinished jobs....
>>>>>> make: *** [all] Error 2
>>>>>>
>>>>>> Thanks
>>>>>> George
>>>>>>
>>>>>> On Fri, Apr 22, 2016 at 11:27 AM Ben Gamari <ben at well-typed.com>
>>>>>> wrote:
>>>>>>
>>>>>>> tl;dr: If you would like to produce a binary distribution for GHC
>>>>>>>        8.0.1-rc4 then let us know, grab the source distribution and
>>>>>>>        start building. The binary distributions will be all released
>>>>>>> one
>>>>>>>        week from today.
>>>>>>>
>>>>>>> Hello GHC packagers,
>>>>>>>
>>>>>>> I am happy to announce the release of the 8.0.1-rc4 source
>>>>>>> distribution
>>>>>>> to binary packagers. This release should resolve all of the issues
>>>>>>> noted
>>>>>>> in the release candidate 3 announcement. You will find the usual
>>>>>>> artifacts at
>>>>>>>
>>>>>>>     http://downloads.haskell.org/~ghc/8.0.1-rc4/
>>>>>>>
>>>>>>> For this candidate we are again following our new release policy [1],
>>>>>>> with a one-week delay between the release of the source and binary
>>>>>>> distributions. The goal of this policy is to give all platforms the
>>>>>>> opportunity for support from the first day of a release.
>>>>>>>
>>>>>>> If all of the expected binary releases are submitted before the
>>>>>>> week-long delay has elapsed, we will move forward with the release of
>>>>>>> the binaries on an accelerated schedule. It would be appreciated if
>>>>>>> you
>>>>>>> could reply to this message confirming that you intend to offer a
>>>>>>> binary
>>>>>>> distribution this release.
>>>>>>>
>>>>>>> Otherwise, let either Austin or I know if you have any trouble
>>>>>>> building
>>>>>>> your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case
>>>>>>> we
>>>>>>> encounter unexpected issues but all of my builds with this tarball
>>>>>>> thusfar have gone quite well.
>>>>>>>
>>>>>>> Good luck and thanks for all of your work!
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> - Ben
>>>>>>>
>>>>>>>
>>>>>>> [1]
>>>>>>> https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.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/20160423/ee1ebb7c/attachment-0001.html>

From carter.schonwald at gmail.com  Sat Apr 23 16:25:27 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 23 Apr 2016 12:25:27 -0400
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAHYVw0wHe3Pje1_s_oApM32pc=1scSgam031uruGyyL3u-wL=Q@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
 <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>
 <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>
 <CAHYVw0x6hMfh8FHrDbhd5UC_yQOd_5JVv+M_FiiUN===TYiFCQ@mail.gmail.com>
 <CAHYVw0yyxE5Q5EwHcEXF6k7bbMr_A5OXrFg7q0eR4Tphe8qM+g@mail.gmail.com>
 <CAHYVw0wHe3Pje1_s_oApM32pc=1scSgam031uruGyyL3u-wL=Q@mail.gmail.com>
Message-ID: <CAHYVw0wjyzTFjYvOMm4Rm1qJuP4RjE6sPu-KrOGNzwOF=XqydA@mail.gmail.com>

fixed up the sphinx confusion...

seems we need the python 2.7 sphinx installed? (or at least, it wasn't
checking sphinx correctly to handle the version supported in the python 3
series?!)

On Sat, Apr 23, 2016 at 12:23 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> err, i mean, sphinx was giving
> checking for version of sphinx-build... Sphinx (sphinx-build) 1.4.1
> ./configure: line 9698: test: Sphinx (sphinx-build) 1: integer expression
> expected
>
> which version of sphinx for which python are we supposed to use?
>
> On Sat, Apr 23, 2016 at 12:18 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> looks like i dont have dblatex setup on that build machine, fixing that
>> now! (slightly trick on mac)
>>
>> On Sat, Apr 23, 2016 at 11:51 AM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> i'm running into some confusions with getting docs built correclty / not
>>> generating the pdfs and html assets i expect, i'll share an updated sha etc
>>> when i track that down
>>>
>>> On Sat, Apr 23, 2016 at 9:52 AM, George Colpitts <
>>> george.colpitts at gmail.com> wrote:
>>>
>>>> retrying with
>>>>
>>>> ./configure --with-nm=$(xcode-select
>>>> -p)/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic
>>>>
>>>> On Sat, Apr 23, 2016 at 10:49 AM George Colpitts <
>>>> george.colpitts at gmail.com> wrote:
>>>>
>>>>> Thanks Carter. I'm not so concerned with obtaining a working build.
>>>>> I'd like to be able to build with the Apple toolchain. I assume there are
>>>>> other developers who feel the same.
>>>>>
>>>>> Can you elaborate on the "path to nm classic is wrong" ?
>>>>>
>>>>> Cheers
>>>>> George
>>>>>
>>>>> On Sat, Apr 23, 2016 at 10:42 AM Carter Schonwald <
>>>>> carter.schonwald at gmail.com> wrote:
>>>>>
>>>>>> I've a working build I'll circulate
>>>>>> Also that path to nm classic is wrong.
>>>>>>
>>>>>>
>>>>>> On Saturday, April 23, 2016, George Colpitts <
>>>>>> george.colpitts at gmail.com> wrote:
>>>>>>
>>>>>>> I'm having problems using the Apple toolchain to build this on Mac
>>>>>>> OS. Has anybody succeeded with the Apple toolchain?
>>>>>>>
>>>>>>> First I get the error:
>>>>>>>
>>>>>>>      broken 'nm' detected, see https://ghc.haskell.org/ticket/11744.
>>>>>>>      Workaround: You may want to pass '--with-nm=nm-classic' to
>>>>>>> 'configure'.
>>>>>>>
>>>>>>> but after I try that workaround I get:
>>>>>>>
>>>>>>> inplace/bin/deriveConstants --gen-header -o
>>>>>>> includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir
>>>>>>> includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc"
>>>>>>> --gcc-flag -Wall --gcc-flag -Wno-unknown-pragmas --gcc-flag -m64 --gcc-flag
>>>>>>> -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist
>>>>>>> --gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag
>>>>>>> -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon
>>>>>>> --nm-program "nm-classic" --target-os "darwin"
>>>>>>> deriveConstants: nm-classic: readCreateProcess:
>>>>>>> runInteractiveProcess: exec: does not exist (No such file or directory)
>>>>>>> make[1]: ***
>>>>>>> [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1
>>>>>>> make[1]: *** Waiting for unfinished jobs....
>>>>>>> make: *** [all] Error 2
>>>>>>>
>>>>>>> Thanks
>>>>>>> George
>>>>>>>
>>>>>>> On Fri, Apr 22, 2016 at 11:27 AM Ben Gamari <ben at well-typed.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> tl;dr: If you would like to produce a binary distribution for GHC
>>>>>>>>        8.0.1-rc4 then let us know, grab the source distribution and
>>>>>>>>        start building. The binary distributions will be all
>>>>>>>> released one
>>>>>>>>        week from today.
>>>>>>>>
>>>>>>>> Hello GHC packagers,
>>>>>>>>
>>>>>>>> I am happy to announce the release of the 8.0.1-rc4 source
>>>>>>>> distribution
>>>>>>>> to binary packagers. This release should resolve all of the issues
>>>>>>>> noted
>>>>>>>> in the release candidate 3 announcement. You will find the usual
>>>>>>>> artifacts at
>>>>>>>>
>>>>>>>>     http://downloads.haskell.org/~ghc/8.0.1-rc4/
>>>>>>>>
>>>>>>>> For this candidate we are again following our new release policy
>>>>>>>> [1],
>>>>>>>> with a one-week delay between the release of the source and binary
>>>>>>>> distributions. The goal of this policy is to give all platforms the
>>>>>>>> opportunity for support from the first day of a release.
>>>>>>>>
>>>>>>>> If all of the expected binary releases are submitted before the
>>>>>>>> week-long delay has elapsed, we will move forward with the release
>>>>>>>> of
>>>>>>>> the binaries on an accelerated schedule. It would be appreciated if
>>>>>>>> you
>>>>>>>> could reply to this message confirming that you intend to offer a
>>>>>>>> binary
>>>>>>>> distribution this release.
>>>>>>>>
>>>>>>>> Otherwise, let either Austin or I know if you have any trouble
>>>>>>>> building
>>>>>>>> your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case
>>>>>>>> we
>>>>>>>> encounter unexpected issues but all of my builds with this tarball
>>>>>>>> thusfar have gone quite well.
>>>>>>>>
>>>>>>>> Good luck and thanks for all of your work!
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> - Ben
>>>>>>>>
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.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/20160423/01165ab8/attachment.html>

From carter.schonwald at gmail.com  Sat Apr 23 16:30:40 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 23 Apr 2016 12:30:40 -0400
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAHYVw0wjyzTFjYvOMm4Rm1qJuP4RjE6sPu-KrOGNzwOF=XqydA@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
 <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>
 <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>
 <CAHYVw0x6hMfh8FHrDbhd5UC_yQOd_5JVv+M_FiiUN===TYiFCQ@mail.gmail.com>
 <CAHYVw0yyxE5Q5EwHcEXF6k7bbMr_A5OXrFg7q0eR4Tphe8qM+g@mail.gmail.com>
 <CAHYVw0wHe3Pje1_s_oApM32pc=1scSgam031uruGyyL3u-wL=Q@mail.gmail.com>
 <CAHYVw0wjyzTFjYvOMm4Rm1qJuP4RjE6sPu-KrOGNzwOF=XqydA@mail.gmail.com>
Message-ID: <CAHYVw0wBez8_x1igGHRcEmcL+beR9QOsa6i3dd3U87nxBZfZUw@mail.gmail.com>

ok, its detecting my python3 sphinx 1.4 install,
but also looks like the autoconf is getting confused
FP_COMPARE_VERSIONS([$fp_cv_sphinx_version],-lt,1.0.0,
    [AC_MSG_WARN([Sphinx version 1.0.0 or later is required to build
documentation]); SPHINXBUILD=;])
seems to be the relevant bit, though its setting the config correctly now I
*believe
*

On Sat, Apr 23, 2016 at 12:25 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> fixed up the sphinx confusion...
>
> seems we need the python 2.7 sphinx installed? (or at least, it wasn't
> checking sphinx correctly to handle the version supported in the python 3
> series?!)
>
> On Sat, Apr 23, 2016 at 12:23 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> err, i mean, sphinx was giving
>> checking for version of sphinx-build... Sphinx (sphinx-build) 1.4.1
>> ./configure: line 9698: test: Sphinx (sphinx-build) 1: integer expression
>> expected
>>
>> which version of sphinx for which python are we supposed to use?
>>
>> On Sat, Apr 23, 2016 at 12:18 PM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> looks like i dont have dblatex setup on that build machine, fixing that
>>> now! (slightly trick on mac)
>>>
>>> On Sat, Apr 23, 2016 at 11:51 AM, Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>> i'm running into some confusions with getting docs built correclty /
>>>> not generating the pdfs and html assets i expect, i'll share an updated sha
>>>> etc when i track that down
>>>>
>>>> On Sat, Apr 23, 2016 at 9:52 AM, George Colpitts <
>>>> george.colpitts at gmail.com> wrote:
>>>>
>>>>> retrying with
>>>>>
>>>>> ./configure --with-nm=$(xcode-select
>>>>> -p)/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic
>>>>>
>>>>> On Sat, Apr 23, 2016 at 10:49 AM George Colpitts <
>>>>> george.colpitts at gmail.com> wrote:
>>>>>
>>>>>> Thanks Carter. I'm not so concerned with obtaining a working build.
>>>>>> I'd like to be able to build with the Apple toolchain. I assume there are
>>>>>> other developers who feel the same.
>>>>>>
>>>>>> Can you elaborate on the "path to nm classic is wrong" ?
>>>>>>
>>>>>> Cheers
>>>>>> George
>>>>>>
>>>>>> On Sat, Apr 23, 2016 at 10:42 AM Carter Schonwald <
>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>
>>>>>>> I've a working build I'll circulate
>>>>>>> Also that path to nm classic is wrong.
>>>>>>>
>>>>>>>
>>>>>>> On Saturday, April 23, 2016, George Colpitts <
>>>>>>> george.colpitts at gmail.com> wrote:
>>>>>>>
>>>>>>>> I'm having problems using the Apple toolchain to build this on Mac
>>>>>>>> OS. Has anybody succeeded with the Apple toolchain?
>>>>>>>>
>>>>>>>> First I get the error:
>>>>>>>>
>>>>>>>>      broken 'nm' detected, see https://ghc.haskell.org/ticket/11744
>>>>>>>> .
>>>>>>>>      Workaround: You may want to pass '--with-nm=nm-classic' to
>>>>>>>> 'configure'.
>>>>>>>>
>>>>>>>> but after I try that workaround I get:
>>>>>>>>
>>>>>>>> inplace/bin/deriveConstants --gen-header -o
>>>>>>>> includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir
>>>>>>>> includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc"
>>>>>>>> --gcc-flag -Wall --gcc-flag -Wno-unknown-pragmas --gcc-flag -m64 --gcc-flag
>>>>>>>> -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist
>>>>>>>> --gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag
>>>>>>>> -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon
>>>>>>>> --nm-program "nm-classic" --target-os "darwin"
>>>>>>>> deriveConstants: nm-classic: readCreateProcess:
>>>>>>>> runInteractiveProcess: exec: does not exist (No such file or directory)
>>>>>>>> make[1]: ***
>>>>>>>> [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1
>>>>>>>> make[1]: *** Waiting for unfinished jobs....
>>>>>>>> make: *** [all] Error 2
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> George
>>>>>>>>
>>>>>>>> On Fri, Apr 22, 2016 at 11:27 AM Ben Gamari <ben at well-typed.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> tl;dr: If you would like to produce a binary distribution for GHC
>>>>>>>>>        8.0.1-rc4 then let us know, grab the source distribution and
>>>>>>>>>        start building. The binary distributions will be all
>>>>>>>>> released one
>>>>>>>>>        week from today.
>>>>>>>>>
>>>>>>>>> Hello GHC packagers,
>>>>>>>>>
>>>>>>>>> I am happy to announce the release of the 8.0.1-rc4 source
>>>>>>>>> distribution
>>>>>>>>> to binary packagers. This release should resolve all of the issues
>>>>>>>>> noted
>>>>>>>>> in the release candidate 3 announcement. You will find the usual
>>>>>>>>> artifacts at
>>>>>>>>>
>>>>>>>>>     http://downloads.haskell.org/~ghc/8.0.1-rc4/
>>>>>>>>>
>>>>>>>>> For this candidate we are again following our new release policy
>>>>>>>>> [1],
>>>>>>>>> with a one-week delay between the release of the source and binary
>>>>>>>>> distributions. The goal of this policy is to give all platforms the
>>>>>>>>> opportunity for support from the first day of a release.
>>>>>>>>>
>>>>>>>>> If all of the expected binary releases are submitted before the
>>>>>>>>> week-long delay has elapsed, we will move forward with the release
>>>>>>>>> of
>>>>>>>>> the binaries on an accelerated schedule. It would be appreciated
>>>>>>>>> if you
>>>>>>>>> could reply to this message confirming that you intend to offer a
>>>>>>>>> binary
>>>>>>>>> distribution this release.
>>>>>>>>>
>>>>>>>>> Otherwise, let either Austin or I know if you have any trouble
>>>>>>>>> building
>>>>>>>>> your distribution. I have yet to push the ghc-8.0.1-rc4 tag in
>>>>>>>>> case we
>>>>>>>>> encounter unexpected issues but all of my builds with this tarball
>>>>>>>>> thusfar have gone quite well.
>>>>>>>>>
>>>>>>>>> Good luck and thanks for all of your work!
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> - Ben
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>> https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.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/20160423/e8a50bde/attachment-0001.html>

From carter.schonwald at gmail.com  Sat Apr 23 19:13:35 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 23 Apr 2016 15:13:35 -0400
Subject: make target doesn't include make pdf or html targets by default!
Message-ID: <CAHYVw0zfMfL=9iLJGOs5BkXeifLhB5EG16XmWG5mrVDdJRENtA@mail.gmail.com>

even though i had sphinx html and pdf flags set to YES  in my mk/build.mk
file!

this was quite surprising.

This seems to have been a change that happened sometime after the RC3 tag...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160423/7bafc63f/attachment.html>

From mail at joachim-breitner.de  Sat Apr 23 19:41:03 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 23 Apr 2016 21:41:03 +0200
Subject: =?UTF-8?Q?perf=2Ehaskell=2Eorg=E2=80=99s?= list of branches got
 more useful
Message-ID: <1461440463.8186.9.camel@joachim-breitner.de>

Hi,

the list of branches on?https://perf.haskell.org/ghc?got more useful.
It now shows the difference from the branch head to the merge base?,
which should roughly exhibit the performance change that would be
caused by merging the branch into master.

If the branch head or the merge base have not been measured (e.g.
because the build failed), the display might be a bit confusing. Same
with branches that often merge or cherry-pick from master. But in the
common case of a linear, possibly rebased, feature branch, it should
work fine.

Greetings,
Joachim

? Which, I think, is the youngest commit also reachable from master. Or
something like that. Consult "man git merge-base" if you want a little
mind teaser.

-- 
Joachim ?nomeata? Breitner
? mail at joachim-breitner.de ? https://www.joachim-breitner.de/
? XMPP: nomeata at joachim-breitner.de?? OpenPGP-Key: 0xF0FBF51F
? Debian Developer: nomeata at debian.org

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

From george.colpitts at gmail.com  Sat Apr 23 20:11:09 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Sat, 23 Apr 2016 20:11:09 +0000
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
Message-ID: <CAB-d4A6Ny+wX+3tqC3XZgKwJantZ8_+Bwcunah=9SGxDDKEPGg@mail.gmail.com>

The error message should be changed from

      Workaround: You may want to pass '--with-nm=nm-classic' to
'configure'.

to

       Workaround: You may want to pass '--with-nm=$(xcode-select
-p)/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic' to 'configure'.

Once I did that (as documented in https://ghc.haskell.org/ticket/11744) I
was able to do a build

Cheers
George


On Sat, Apr 23, 2016 at 10:37 AM George Colpitts <george.colpitts at gmail.com>
wrote:

> I'm having problems using the Apple toolchain to build this on Mac OS. Has
> anybody succeeded with the Apple toolchain?
>
> First I get the error:
>
>      broken 'nm' detected, see https://ghc.haskell.org/ticket/11744.
>      Workaround: You may want to pass '--with-nm=nm-classic' to
> 'configure'.
>
> but after I try that workaround I get:
>
> inplace/bin/deriveConstants --gen-header -o
> includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir
> includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc"
> --gcc-flag -Wall --gcc-flag -Wno-unknown-pragmas --gcc-flag -m64 --gcc-flag
> -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist
> --gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag
> -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon
> --nm-program "nm-classic" --target-os "darwin"
> deriveConstants: nm-classic: readCreateProcess: runInteractiveProcess:
> exec: does not exist (No such file or directory)
> make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h]
> Error 1
> make[1]: *** Waiting for unfinished jobs....
> make: *** [all] Error 2
>
> Thanks
> George
>
> On Fri, Apr 22, 2016 at 11:27 AM Ben Gamari <ben at well-typed.com> wrote:
>
>> tl;dr: If you would like to produce a binary distribution for GHC
>>        8.0.1-rc4 then let us know, grab the source distribution and
>>        start building. The binary distributions will be all released one
>>        week from today.
>>
>> Hello GHC packagers,
>>
>> I am happy to announce the release of the 8.0.1-rc4 source distribution
>> to binary packagers. This release should resolve all of the issues noted
>> in the release candidate 3 announcement. You will find the usual
>> artifacts at
>>
>>     http://downloads.haskell.org/~ghc/8.0.1-rc4/
>>
>> For this candidate we are again following our new release policy [1],
>> with a one-week delay between the release of the source and binary
>> distributions. The goal of this policy is to give all platforms the
>> opportunity for support from the first day of a release.
>>
>> If all of the expected binary releases are submitted before the
>> week-long delay has elapsed, we will move forward with the release of
>> the binaries on an accelerated schedule. It would be appreciated if you
>> could reply to this message confirming that you intend to offer a binary
>> distribution this release.
>>
>> Otherwise, let either Austin or I know if you have any trouble building
>> your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case we
>> encounter unexpected issues but all of my builds with this tarball
>> thusfar have gone quite well.
>>
>> Good luck and thanks for all of your work!
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.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/20160423/1684e3a5/attachment.html>

From carter.schonwald at gmail.com  Sat Apr 23 20:18:24 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 23 Apr 2016 16:18:24 -0400
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAB-d4A6Ny+wX+3tqC3XZgKwJantZ8_+Bwcunah=9SGxDDKEPGg@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAB-d4A6Ny+wX+3tqC3XZgKwJantZ8_+Bwcunah=9SGxDDKEPGg@mail.gmail.com>
Message-ID: <CAHYVw0zmsjhCmFs1RRmfpmuB4Sifn3AYZvL4nm6NuGq2i-uV9Q@mail.gmail.com>

oddly enough the suggestions in the release notes for 8.0 have the correct
path suggestion, I guess that the command line got out of sync

On Sat, Apr 23, 2016 at 4:11 PM, George Colpitts <george.colpitts at gmail.com>
wrote:

> The error message should be changed from
>
>       Workaround: You may want to pass '--with-nm=nm-classic' to
> 'configure'.
>
> to
>
>        Workaround: You may want to pass '--with-nm=$(xcode-select
> -p)/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic' to 'configure'.
>
> Once I did that (as documented in https://ghc.haskell.org/ticket/11744) I
> was able to do a build
>
> Cheers
> George
>
>
> On Sat, Apr 23, 2016 at 10:37 AM George Colpitts <
> george.colpitts at gmail.com> wrote:
>
>> I'm having problems using the Apple toolchain to build this on Mac OS.
>> Has anybody succeeded with the Apple toolchain?
>>
>> First I get the error:
>>
>>      broken 'nm' detected, see https://ghc.haskell.org/ticket/11744.
>>      Workaround: You may want to pass '--with-nm=nm-classic' to
>> 'configure'.
>>
>> but after I try that workaround I get:
>>
>> inplace/bin/deriveConstants --gen-header -o
>> includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir
>> includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc"
>> --gcc-flag -Wall --gcc-flag -Wno-unknown-pragmas --gcc-flag -m64 --gcc-flag
>> -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist
>> --gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag
>> -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon
>> --nm-program "nm-classic" --target-os "darwin"
>> deriveConstants: nm-classic: readCreateProcess: runInteractiveProcess:
>> exec: does not exist (No such file or directory)
>> make[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h]
>> Error 1
>> make[1]: *** Waiting for unfinished jobs....
>> make: *** [all] Error 2
>>
>> Thanks
>> George
>>
>> On Fri, Apr 22, 2016 at 11:27 AM Ben Gamari <ben at well-typed.com> wrote:
>>
>>> tl;dr: If you would like to produce a binary distribution for GHC
>>>        8.0.1-rc4 then let us know, grab the source distribution and
>>>        start building. The binary distributions will be all released one
>>>        week from today.
>>>
>>> Hello GHC packagers,
>>>
>>> I am happy to announce the release of the 8.0.1-rc4 source distribution
>>> to binary packagers. This release should resolve all of the issues noted
>>> in the release candidate 3 announcement. You will find the usual
>>> artifacts at
>>>
>>>     http://downloads.haskell.org/~ghc/8.0.1-rc4/
>>>
>>> For this candidate we are again following our new release policy [1],
>>> with a one-week delay between the release of the source and binary
>>> distributions. The goal of this policy is to give all platforms the
>>> opportunity for support from the first day of a release.
>>>
>>> If all of the expected binary releases are submitted before the
>>> week-long delay has elapsed, we will move forward with the release of
>>> the binaries on an accelerated schedule. It would be appreciated if you
>>> could reply to this message confirming that you intend to offer a binary
>>> distribution this release.
>>>
>>> Otherwise, let either Austin or I know if you have any trouble building
>>> your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case we
>>> encounter unexpected issues but all of my builds with this tarball
>>> thusfar have gone quite well.
>>>
>>> Good luck and thanks for all of your work!
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>>
>>> [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.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/20160423/5aebc043/attachment-0001.html>

From ben at well-typed.com  Sat Apr 23 22:41:10 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 24 Apr 2016 00:41:10 +0200
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
 <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>
 <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>
Message-ID: <87lh44eynt.fsf@smart-cactus.org>

George Colpitts <george.colpitts at gmail.com> writes:

> retrying with
>
> ./configure --with-nm=$(xcode-select -p)/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic
>
Hi George,

Did this work out for you? Indeed the advice given by the error message
may be a bit misleading (as nm-classic may not be in PATH). Let me know
if you have any suggestions for how to improve the message.

Thanks for trying the build and sorry for the late reply!

Cheers,

- Ben

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

From ben at well-typed.com  Sat Apr 23 22:43:59 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 24 Apr 2016 00:43:59 +0200
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAHYVw0wBez8_x1igGHRcEmcL+beR9QOsa6i3dd3U87nxBZfZUw@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
 <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>
 <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>
 <CAHYVw0x6hMfh8FHrDbhd5UC_yQOd_5JVv+M_FiiUN===TYiFCQ@mail.gmail.com>
 <CAHYVw0yyxE5Q5EwHcEXF6k7bbMr_A5OXrFg7q0eR4Tphe8qM+g@mail.gmail.com>
 <CAHYVw0wHe3Pje1_s_oApM32pc=1scSgam031uruGyyL3u-wL=Q@mail.gmail.com>
 <CAHYVw0wjyzTFjYvOMm4Rm1qJuP4RjE6sPu-KrOGNzwOF=XqydA@mail.gmail.com>
 <CAHYVw0wBez8_x1igGHRcEmcL+beR9QOsa6i3dd3U87nxBZfZUw@mail.gmail.com>
Message-ID: <87inz8eyj4.fsf@smart-cactus.org>

Carter Schonwald <carter.schonwald at gmail.com> writes:

> ok, its detecting my python3 sphinx 1.4 install,
> but also looks like the autoconf is getting confused
> FP_COMPARE_VERSIONS([$fp_cv_sphinx_version],-lt,1.0.0,
>     [AC_MSG_WARN([Sphinx version 1.0.0 or later is required to build
> documentation]); SPHINXBUILD=;])
> seems to be the relevant bit, though its setting the config correctly now I
> *believe*

Hmm, did you ever work out what was going on here? I've built with both
Python 2 and Python 3 Sphinx installations and had no trouble in either
case. That being said, this was on Linux so this data point may not mean
much on OS X.

Cheers,

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

From ben at well-typed.com  Sat Apr 23 22:45:45 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 24 Apr 2016 00:45:45 +0200
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAB-d4A6Ny+wX+3tqC3XZgKwJantZ8_+Bwcunah=9SGxDDKEPGg@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAB-d4A6Ny+wX+3tqC3XZgKwJantZ8_+Bwcunah=9SGxDDKEPGg@mail.gmail.com>
Message-ID: <87fuuceyg6.fsf@smart-cactus.org>

George Colpitts <george.colpitts at gmail.com> writes:

> The error message should be changed from
>
>       Workaround: You may want to pass '--with-nm=nm-classic' to
> 'configure'.
>
> to
>
>        Workaround: You may want to pass '--with-nm=$(xcode-select
> -p)/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic' to 'configure'.
>
> Once I did that (as documented in https://ghc.haskell.org/ticket/11744) I
> was able to do a build
>
Ahh, great! Ignore my previous message. I'll update the error.

Thanks for looking at this, George! Working out papercuts like this is
extremely helpful.

Cheers,

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

From carter.schonwald at gmail.com  Sat Apr 23 22:47:07 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 23 Apr 2016 18:47:07 -0400
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <87inz8eyj4.fsf@smart-cactus.org>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
 <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>
 <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>
 <CAHYVw0x6hMfh8FHrDbhd5UC_yQOd_5JVv+M_FiiUN===TYiFCQ@mail.gmail.com>
 <CAHYVw0yyxE5Q5EwHcEXF6k7bbMr_A5OXrFg7q0eR4Tphe8qM+g@mail.gmail.com>
 <CAHYVw0wHe3Pje1_s_oApM32pc=1scSgam031uruGyyL3u-wL=Q@mail.gmail.com>
 <CAHYVw0wjyzTFjYvOMm4Rm1qJuP4RjE6sPu-KrOGNzwOF=XqydA@mail.gmail.com>
 <CAHYVw0wBez8_x1igGHRcEmcL+beR9QOsa6i3dd3U87nxBZfZUw@mail.gmail.com>
 <87inz8eyj4.fsf@smart-cactus.org>
Message-ID: <CAHYVw0yET5xT6FZtXRsbHwJ25XcjJzZ+Pk3339u5KEKOiqyEOA@mail.gmail.com>

Thomie (Thomas M?) pointed out that there may have been a "are-validating"
make file in my /mk/ dir that could have been messing with things.

i've gotten a build i'm happy with, i'm now seeing if i can tweak it to
have the otool -L output favor stuff in /usr/lib (ie mac standard stuff) vs
userland overlays for some basic linker stuff

On Sat, Apr 23, 2016 at 6:43 PM, Ben Gamari <ben at well-typed.com> wrote:

> Carter Schonwald <carter.schonwald at gmail.com> writes:
>
> > ok, its detecting my python3 sphinx 1.4 install,
> > but also looks like the autoconf is getting confused
> > FP_COMPARE_VERSIONS([$fp_cv_sphinx_version],-lt,1.0.0,
> >     [AC_MSG_WARN([Sphinx version 1.0.0 or later is required to build
> > documentation]); SPHINXBUILD=;])
> > seems to be the relevant bit, though its setting the config correctly
> now I
> > *believe*
>
> Hmm, did you ever work out what was going on here? I've built with both
> Python 2 and Python 3 Sphinx installations and had no trouble in either
> case. That being said, this was on Linux so this data point may not mean
> much on OS X.
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160423/122ba6ee/attachment.html>

From ben at well-typed.com  Sat Apr 23 22:49:47 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 24 Apr 2016 00:49:47 +0200
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAB-d4A6Ny+wX+3tqC3XZgKwJantZ8_+Bwcunah=9SGxDDKEPGg@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAB-d4A6Ny+wX+3tqC3XZgKwJantZ8_+Bwcunah=9SGxDDKEPGg@mail.gmail.com>
Message-ID: <87d1pgey9g.fsf@smart-cactus.org>

George Colpitts <george.colpitts at gmail.com> writes:

> The error message should be changed from
>
>       Workaround: You may want to pass '--with-nm=nm-classic' to
> 'configure'.
>
> to
>
>        Workaround: You may want to pass '--with-nm=$(xcode-select
> -p)/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic' to 'configure'.
>
> Once I did that (as documented in https://ghc.haskell.org/ticket/11744) I
> was able to do a build
>
Hmm, although I just checked on our OS X test box (which has the
command-line tools installed, not full XCode) and it seems that the
/Library/Developer/CommandLineTools/Toolchains directory doesn't exist.
Presumably this is a (rather unfortunate) difference between full XCode
and the command-line package. Do you know whether there is some advice
that we might be able to offer that will work in both cases?

If not I suspect we should just go with your suggestion; the full-XCode
case is the far more likely of the two.

Cheers,

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

From ben at well-typed.com  Sat Apr 23 22:52:45 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 24 Apr 2016 00:52:45 +0200
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAHYVw0x6hMfh8FHrDbhd5UC_yQOd_5JVv+M_FiiUN===TYiFCQ@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
 <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>
 <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>
 <CAHYVw0x6hMfh8FHrDbhd5UC_yQOd_5JVv+M_FiiUN===TYiFCQ@mail.gmail.com>
Message-ID: <878u04ey4i.fsf@smart-cactus.org>

Carter Schonwald <carter.schonwald at gmail.com> writes:

> i'm running into some confusions with getting docs built correclty / not
> generating the pdfs and html assets i expect, i'll share an updated sha etc
> when i track that down
>
It would be great if you could share a few more details about what
particular issues you have encountered (and what was necessary to get
past them) so we can hopefully smooth them out in the release (either
with code changes or better build documentation in the Wiki).

Cheers,

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

From ben at well-typed.com  Sat Apr 23 22:57:51 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 24 Apr 2016 00:57:51 +0200
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAHYVw0yET5xT6FZtXRsbHwJ25XcjJzZ+Pk3339u5KEKOiqyEOA@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
 <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>
 <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>
 <CAHYVw0x6hMfh8FHrDbhd5UC_yQOd_5JVv+M_FiiUN===TYiFCQ@mail.gmail.com>
 <CAHYVw0yyxE5Q5EwHcEXF6k7bbMr_A5OXrFg7q0eR4Tphe8qM+g@mail.gmail.com>
 <CAHYVw0wHe3Pje1_s_oApM32pc=1scSgam031uruGyyL3u-wL=Q@mail.gmail.com>
 <CAHYVw0wjyzTFjYvOMm4Rm1qJuP4RjE6sPu-KrOGNzwOF=XqydA@mail.gmail.com>
 <CAHYVw0wBez8_x1igGHRcEmcL+beR9QOsa6i3dd3U87nxBZfZUw@mail.gmail.com>
 <87inz8eyj4.fsf@smart-cactus.org>
 <CAHYVw0yET5xT6FZtXRsbHwJ25XcjJzZ+Pk3339u5KEKOiqyEOA@mail.gmail.com>
Message-ID: <8760v8exw0.fsf@smart-cactus.org>

Carter Schonwald <carter.schonwald at gmail.com> writes:

> Thomie (Thomas M?) pointed out that there may have been a "are-validating"
> make file in my /mk/ dir that could have been messing with things.
>
> i've gotten a build i'm happy with, i'm now seeing if i can tweak it to
> have the otool -L output favor stuff in /usr/lib (ie mac standard stuff) vs
> userland overlays for some basic linker stuff
>
Could you elaborate a bit here?

If there are manual tweaks applied to the build then we need to make
sure they are documented (or ideally scripted, with the script in a
publicly accessible, version controlled location), especially if we
want to offer your build in some "official" capacity.

Cheers,

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

From allbery.b at gmail.com  Sat Apr 23 22:59:06 2016
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 23 Apr 2016 18:59:06 -0400
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <87d1pgey9g.fsf@smart-cactus.org>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAB-d4A6Ny+wX+3tqC3XZgKwJantZ8_+Bwcunah=9SGxDDKEPGg@mail.gmail.com>
 <87d1pgey9g.fsf@smart-cactus.org>
Message-ID: <CAKFCL4UayyOck7a1Gy+NHD=MU-_ZNJBgRVim13M-GOkxJ_4bog@mail.gmail.com>

On Sat, Apr 23, 2016 at 6:49 PM, Ben Gamari <ben at well-typed.com> wrote:

> Hmm, although I just checked on our OS X test box (which has the
> command-line tools installed, not full XCode) and it seems that the
> /Library/Developer/CommandLineTools/Toolchains directory doesn't exist.
> Presumably this is a (rather unfortunate) difference between full XCode
> and the command-line package. Do you know whether there is some advice
> that we might be able to offer that will work in both cases?
>

There doesn't seem to be an nm-classic corresponding to the Command Line
Tools. In 10.11 at least, that package name is a misnomer; the command line
utilities are part of the base system (com.apple.pkg.Essentials) and the
SDK package is just includes and libs. There's no nm-classic hidden in
either of them.

-- 
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/20160423/a1ed6900/attachment-0001.html>

From ben at well-typed.com  Sat Apr 23 23:05:03 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 24 Apr 2016 01:05:03 +0200
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAKFCL4UayyOck7a1Gy+NHD=MU-_ZNJBgRVim13M-GOkxJ_4bog@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAB-d4A6Ny+wX+3tqC3XZgKwJantZ8_+Bwcunah=9SGxDDKEPGg@mail.gmail.com>
 <87d1pgey9g.fsf@smart-cactus.org>
 <CAKFCL4UayyOck7a1Gy+NHD=MU-_ZNJBgRVim13M-GOkxJ_4bog@mail.gmail.com>
Message-ID: <87ziskdizk.fsf@smart-cactus.org>

Brandon Allbery <allbery.b at gmail.com> writes:

> On Sat, Apr 23, 2016 at 6:49 PM, Ben Gamari <ben at well-typed.com> wrote:
>
>> Hmm, although I just checked on our OS X test box (which has the
>> command-line tools installed, not full XCode) and it seems that the
>> /Library/Developer/CommandLineTools/Toolchains directory doesn't exist.
>> Presumably this is a (rather unfortunate) difference between full XCode
>> and the command-line package. Do you know whether there is some advice
>> that we might be able to offer that will work in both cases?
>>
>
> There doesn't seem to be an nm-classic corresponding to the Command Line
> Tools. In 10.11 at least, that package name is a misnomer; the command line
> utilities are part of the base system (com.apple.pkg.Essentials) and the
> SDK package is just includes and libs. There's no nm-classic hidden in
> either of them.
>
Ahh, this is useful. Thanks!

In that case I suppose I need to work out how to install the full XCode
package via the command line. If you have any pointers for this it would
be greatly appreciated.

Cheers,

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

From allbery.b at gmail.com  Sat Apr 23 23:11:42 2016
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 23 Apr 2016 19:11:42 -0400
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <87ziskdizk.fsf@smart-cactus.org>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAB-d4A6Ny+wX+3tqC3XZgKwJantZ8_+Bwcunah=9SGxDDKEPGg@mail.gmail.com>
 <87d1pgey9g.fsf@smart-cactus.org>
 <CAKFCL4UayyOck7a1Gy+NHD=MU-_ZNJBgRVim13M-GOkxJ_4bog@mail.gmail.com>
 <87ziskdizk.fsf@smart-cactus.org>
Message-ID: <CAKFCL4U+jGoraZxfosK7yYF23H0brcg2P0ULOfv1Bhwj0XaVXg@mail.gmail.com>

On Sat, Apr 23, 2016 at 7:05 PM, Ben Gamari <ben at well-typed.com> wrote:

>
> In that case I suppose I need to work out how to install the full XCode
> package via the command line.


Uh, it's Apple. They don't *do* that. No Apple-sanctioned CLI access to the
App Store (but see https://github.com/argon/mas --- note need to sign in to
it with an Apple ID before use), and need to web login with an Apple ID and
some level (including free) of developer registration to get it from
developer.apple.com.

It's kinda ironic that these days even Microsoft does better (cf.
Chocolatey).

-- 
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/20160423/60105325/attachment.html>

From ben at well-typed.com  Sat Apr 23 23:21:38 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 24 Apr 2016 01:21:38 +0200
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAKFCL4U+jGoraZxfosK7yYF23H0brcg2P0ULOfv1Bhwj0XaVXg@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAB-d4A6Ny+wX+3tqC3XZgKwJantZ8_+Bwcunah=9SGxDDKEPGg@mail.gmail.com>
 <87d1pgey9g.fsf@smart-cactus.org>
 <CAKFCL4UayyOck7a1Gy+NHD=MU-_ZNJBgRVim13M-GOkxJ_4bog@mail.gmail.com>
 <87ziskdizk.fsf@smart-cactus.org>
 <CAKFCL4U+jGoraZxfosK7yYF23H0brcg2P0ULOfv1Bhwj0XaVXg@mail.gmail.com>
Message-ID: <87wpnnewsd.fsf@smart-cactus.org>

Brandon Allbery <allbery.b at gmail.com> writes:

> On Sat, Apr 23, 2016 at 7:05 PM, Ben Gamari <ben at well-typed.com> wrote:
>
>>
>> In that case I suppose I need to work out how to install the full XCode
>> package via the command line.
>
>
> Uh, it's Apple. They don't *do* that. No Apple-sanctioned CLI access to the
> App Store (but see https://github.com/argon/mas --- note need to sign in to
> it with an Apple ID before use), and need to web login with an Apple ID and
> some level (including free) of developer registration to get it from
> developer.apple.com.
>
Sigh, that is what I was afraid of that. I guess we'll have to work
something out. Thanks!

Cheers,

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

From ben at well-typed.com  Sat Apr 23 23:39:09 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 24 Apr 2016 01:39:09 +0200
Subject: make target doesn't include make pdf or html targets by default!
In-Reply-To: <CAHYVw0zfMfL=9iLJGOs5BkXeifLhB5EG16XmWG5mrVDdJRENtA@mail.gmail.com>
References: <CAHYVw0zfMfL=9iLJGOs5BkXeifLhB5EG16XmWG5mrVDdJRENtA@mail.gmail.com>
Message-ID: <87shybevz6.fsf@smart-cactus.org>

Carter Schonwald <carter.schonwald at gmail.com> writes:

> even though i had sphinx html and pdf flags set to YES  in my mk/build.mk
> file!
>
> this was quite surprising.

For the record: It appears that the issue here may have been an
mk/are-validating.mk file left in the tree.

Cheers,

- Ben

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

From carter.schonwald at gmail.com  Sun Apr 24 00:05:44 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 23 Apr 2016 20:05:44 -0400
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <8760v8exw0.fsf@smart-cactus.org>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
 <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>
 <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>
 <CAHYVw0x6hMfh8FHrDbhd5UC_yQOd_5JVv+M_FiiUN===TYiFCQ@mail.gmail.com>
 <CAHYVw0yyxE5Q5EwHcEXF6k7bbMr_A5OXrFg7q0eR4Tphe8qM+g@mail.gmail.com>
 <CAHYVw0wHe3Pje1_s_oApM32pc=1scSgam031uruGyyL3u-wL=Q@mail.gmail.com>
 <CAHYVw0wjyzTFjYvOMm4Rm1qJuP4RjE6sPu-KrOGNzwOF=XqydA@mail.gmail.com>
 <CAHYVw0wBez8_x1igGHRcEmcL+beR9QOsa6i3dd3U87nxBZfZUw@mail.gmail.com>
 <87inz8eyj4.fsf@smart-cactus.org>
 <CAHYVw0yET5xT6FZtXRsbHwJ25XcjJzZ+Pk3339u5KEKOiqyEOA@mail.gmail.com>
 <8760v8exw0.fsf@smart-cactus.org>
Message-ID: <CAHYVw0yYX8On=R8a0evyuhaExHbK8iinoz8rpRyDkEYvFksw6w@mail.gmail.com>

I'll try to collect my thoughts and tease out what did/didn't work tomorrow,
in the mean time, here's a build I believe should work for everyone on mac
and should have full docs,
http://wellposed-carter-files.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz

shasum -a512 ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz
969eb2914b9c7c31bcdfb814aac34f0dcd9d6c8d7b9e7affe1605985e9de543d911dc6dae0fa05a32da12150d56488e56ad6fbf4d1f818ec84f7a4759d876c95
 ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz

one niggling issue is that, at least based upon the output of otool -L, the
builds point to  /usr/local/lib/gcc/6/libgcc_s.1.dylib
(my userland GCC leaking through)
and I *believe* but could be wrong that its better to have it point
to /usr/lib/libgcc_s.1.dylib or something?
otoh, the otool -L output of those respective things are VERY different

I will investigate that further, though its orthogonal to my doc building
confusion that I still need to work out what happened with


On Sat, Apr 23, 2016 at 6:57 PM, Ben Gamari <ben at well-typed.com> wrote:

> Carter Schonwald <carter.schonwald at gmail.com> writes:
>
> > Thomie (Thomas M?) pointed out that there may have been a
> "are-validating"
> > make file in my /mk/ dir that could have been messing with things.
> >
> > i've gotten a build i'm happy with, i'm now seeing if i can tweak it to
> > have the otool -L output favor stuff in /usr/lib (ie mac standard stuff)
> vs
> > userland overlays for some basic linker stuff
> >
> Could you elaborate a bit here?
>
> If there are manual tweaks applied to the build then we need to make
> sure they are documented (or ideally scripted, with the script in a
> publicly accessible, version controlled location), especially if we
> want to offer your build in some "official" capacity.
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160423/02331431/attachment.html>

From carter.schonwald at gmail.com  Sun Apr 24 00:06:51 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 23 Apr 2016 20:06:51 -0400
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAHYVw0yYX8On=R8a0evyuhaExHbK8iinoz8rpRyDkEYvFksw6w@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
 <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>
 <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>
 <CAHYVw0x6hMfh8FHrDbhd5UC_yQOd_5JVv+M_FiiUN===TYiFCQ@mail.gmail.com>
 <CAHYVw0yyxE5Q5EwHcEXF6k7bbMr_A5OXrFg7q0eR4Tphe8qM+g@mail.gmail.com>
 <CAHYVw0wHe3Pje1_s_oApM32pc=1scSgam031uruGyyL3u-wL=Q@mail.gmail.com>
 <CAHYVw0wjyzTFjYvOMm4Rm1qJuP4RjE6sPu-KrOGNzwOF=XqydA@mail.gmail.com>
 <CAHYVw0wBez8_x1igGHRcEmcL+beR9QOsa6i3dd3U87nxBZfZUw@mail.gmail.com>
 <87inz8eyj4.fsf@smart-cactus.org>
 <CAHYVw0yET5xT6FZtXRsbHwJ25XcjJzZ+Pk3339u5KEKOiqyEOA@mail.gmail.com>
 <8760v8exw0.fsf@smart-cactus.org>
 <CAHYVw0yYX8On=R8a0evyuhaExHbK8iinoz8rpRyDkEYvFksw6w@mail.gmail.com>
Message-ID: <CAHYVw0xxDbj8QVDM5+aAEz61mD3GQsSVF6n5RqoPFc_P+Drhdg@mail.gmail.com>

(NB: i would like any folks who don't have a gcc6 dylib as i mention above
to please stress test it out :) ), though it didn't seem to interfere with
builds  when i deleted gcc6 and had it go through its paces

On Sat, Apr 23, 2016 at 8:05 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> I'll try to collect my thoughts and tease out what did/didn't work
> tomorrow,
> in the mean time, here's a build I believe should work for everyone on mac
> and should have full docs,
>
> http://wellposed-carter-files.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz
>
> shasum -a512 ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz
> 969eb2914b9c7c31bcdfb814aac34f0dcd9d6c8d7b9e7affe1605985e9de543d911dc6dae0fa05a32da12150d56488e56ad6fbf4d1f818ec84f7a4759d876c95
>  ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz
>
> one niggling issue is that, at least based upon the output of otool -L,
> the builds point to  /usr/local/lib/gcc/6/libgcc_s.1.dylib
> (my userland GCC leaking through)
> and I *believe* but could be wrong that its better to have it point
> to /usr/lib/libgcc_s.1.dylib or something?
> otoh, the otool -L output of those respective things are VERY different
>
> I will investigate that further, though its orthogonal to my doc building
> confusion that I still need to work out what happened with
>
>
> On Sat, Apr 23, 2016 at 6:57 PM, Ben Gamari <ben at well-typed.com> wrote:
>
>> Carter Schonwald <carter.schonwald at gmail.com> writes:
>>
>> > Thomie (Thomas M?) pointed out that there may have been a
>> "are-validating"
>> > make file in my /mk/ dir that could have been messing with things.
>> >
>> > i've gotten a build i'm happy with, i'm now seeing if i can tweak it to
>> > have the otool -L output favor stuff in /usr/lib (ie mac standard
>> stuff) vs
>> > userland overlays for some basic linker stuff
>> >
>> Could you elaborate a bit here?
>>
>> If there are manual tweaks applied to the build then we need to make
>> sure they are documented (or ideally scripted, with the script in a
>> publicly accessible, version controlled location), especially if we
>> want to offer your build in some "official" capacity.
>>
>> Cheers,
>>
>> - Ben
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160423/f8ca8bc6/attachment-0001.html>

From allbery.b at gmail.com  Sun Apr 24 00:18:03 2016
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 23 Apr 2016 20:18:03 -0400
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAHYVw0yYX8On=R8a0evyuhaExHbK8iinoz8rpRyDkEYvFksw6w@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
 <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>
 <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>
 <CAHYVw0x6hMfh8FHrDbhd5UC_yQOd_5JVv+M_FiiUN===TYiFCQ@mail.gmail.com>
 <CAHYVw0yyxE5Q5EwHcEXF6k7bbMr_A5OXrFg7q0eR4Tphe8qM+g@mail.gmail.com>
 <CAHYVw0wHe3Pje1_s_oApM32pc=1scSgam031uruGyyL3u-wL=Q@mail.gmail.com>
 <CAHYVw0wjyzTFjYvOMm4Rm1qJuP4RjE6sPu-KrOGNzwOF=XqydA@mail.gmail.com>
 <CAHYVw0wBez8_x1igGHRcEmcL+beR9QOsa6i3dd3U87nxBZfZUw@mail.gmail.com>
 <87inz8eyj4.fsf@smart-cactus.org>
 <CAHYVw0yET5xT6FZtXRsbHwJ25XcjJzZ+Pk3339u5KEKOiqyEOA@mail.gmail.com>
 <8760v8exw0.fsf@smart-cactus.org>
 <CAHYVw0yYX8On=R8a0evyuhaExHbK8iinoz8rpRyDkEYvFksw6w@mail.gmail.com>
Message-ID: <CAKFCL4Vj-YCQ0pGchRavUrO7NVDuW_vx3j73d+8j79AA3ORLkw@mail.gmail.com>

On Sat, Apr 23, 2016 at 8:05 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> and I *believe* but could be wrong that its better to have it point
> to /usr/lib/libgcc_s.1.dylib or something?
> otoh, the otool -L output of those respective things are VERY different
>

People will need to have that libgcc_s.1.dylib *by path* installed. Apple's
is likely too old to be compatible, so copying it or using
install_name_tool to repoint to it will likely lead to a non-working
program.

You mentioned at one point that you built using a local gcc install. gcc
uses its bundled libgcc_s; so you will have that dependency unless you
switch to /usr/bin/clang to build.

-- 
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/20160423/c28c6655/attachment.html>

From george.colpitts at gmail.com  Sun Apr 24 00:40:49 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Sun, 24 Apr 2016 00:40:49 +0000
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <87d1pgey9g.fsf@smart-cactus.org>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAB-d4A6Ny+wX+3tqC3XZgKwJantZ8_+Bwcunah=9SGxDDKEPGg@mail.gmail.com>
 <87d1pgey9g.fsf@smart-cactus.org>
Message-ID: <CAB-d4A4mymNnq6=kH+60B80nyOEYGNkd9uEhieVv0mciF2nd8w@mail.gmail.com>

Definitely more complicated than I thought. :)

It also seems as if Xcode has changed in that I used to be able to install
command line tools from Xcode and did. However in Xcode 7.3 Preferences->
Components implies I already have it.

I guess the best thing would be for configure to figure all this out and do
the right thing. I'm guessing that is not easy and I don't believe it is
critical for the release of 8.0. The second best thing to do would be to
have the error message suggest two possible workaround/fixes with an
explanation that one is for people with full Xcode, the other for people
with only XCode command line tools.

In any case I trust in your judgement and that of other ghc developers with
more experience than me to do the right thing. I wish I could be more
helpful.

Cheers
George


On Sat, Apr 23, 2016 at 7:49 PM Ben Gamari <ben at well-typed.com> wrote:

> George Colpitts <george.colpitts at gmail.com> writes:
>
> > The error message should be changed from
> >
> >       Workaround: You may want to pass '--with-nm=nm-classic' to
> > 'configure'.
> >
> > to
> >
> >        Workaround: You may want to pass '--with-nm=$(xcode-select
> > -p)/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm-classic' to
> 'configure'.
> >
> > Once I did that (as documented in https://ghc.haskell.org/ticket/11744)
> I
> > was able to do a build
> >
> Hmm, although I just checked on our OS X test box (which has the
> command-line tools installed, not full XCode) and it seems that the
> /Library/Developer/CommandLineTools/Toolchains directory doesn't exist.
> Presumably this is a (rather unfortunate) difference between full XCode
> and the command-line package. Do you know whether there is some advice
> that we might be able to offer that will work in both cases?
>
> If not I suspect we should just go with your suggestion; the full-XCode
> case is the far more likely of the two.
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160424/9b92b84b/attachment.html>

From carter.schonwald at gmail.com  Sun Apr 24 00:50:15 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 23 Apr 2016 20:50:15 -0400
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAKFCL4Vj-YCQ0pGchRavUrO7NVDuW_vx3j73d+8j79AA3ORLkw@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
 <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>
 <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>
 <CAHYVw0x6hMfh8FHrDbhd5UC_yQOd_5JVv+M_FiiUN===TYiFCQ@mail.gmail.com>
 <CAHYVw0yyxE5Q5EwHcEXF6k7bbMr_A5OXrFg7q0eR4Tphe8qM+g@mail.gmail.com>
 <CAHYVw0wHe3Pje1_s_oApM32pc=1scSgam031uruGyyL3u-wL=Q@mail.gmail.com>
 <CAHYVw0wjyzTFjYvOMm4Rm1qJuP4RjE6sPu-KrOGNzwOF=XqydA@mail.gmail.com>
 <CAHYVw0wBez8_x1igGHRcEmcL+beR9QOsa6i3dd3U87nxBZfZUw@mail.gmail.com>
 <87inz8eyj4.fsf@smart-cactus.org>
 <CAHYVw0yET5xT6FZtXRsbHwJ25XcjJzZ+Pk3339u5KEKOiqyEOA@mail.gmail.com>
 <8760v8exw0.fsf@smart-cactus.org>
 <CAHYVw0yYX8On=R8a0evyuhaExHbK8iinoz8rpRyDkEYvFksw6w@mail.gmail.com>
 <CAKFCL4Vj-YCQ0pGchRavUrO7NVDuW_vx3j73d+8j79AA3ORLkw@mail.gmail.com>
Message-ID: <CAHYVw0x5evLFfh9oYRwU3seXURhsW7dkKkuoCq=MrKmNiED2-g@mail.gmail.com>

It *seemed* to work fine even with that lib no longer at that path, but
famous last words. It does seem that it doesn't do anything

On Saturday, April 23, 2016, Brandon Allbery <allbery.b at gmail.com> wrote:

> On Sat, Apr 23, 2016 at 8:05 PM, Carter Schonwald <
> carter.schonwald at gmail.com
> <javascript:_e(%7B%7D,'cvml','carter.schonwald at gmail.com');>> wrote:
>
>> and I *believe* but could be wrong that its better to have it point
>> to /usr/lib/libgcc_s.1.dylib or something?
>> otoh, the otool -L output of those respective things are VERY different
>>
>
> People will need to have that libgcc_s.1.dylib *by path* installed.
> Apple's is likely too old to be compatible, so copying it or using
> install_name_tool to repoint to it will likely lead to a non-working
> program.
>
> You mentioned at one point that you built using a local gcc install. gcc
> uses its bundled libgcc_s; so you will have that dependency unless you
> switch to /usr/bin/clang to build.
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com <javascript:_e(%7B%7D,'cvml','allbery.b at gmail.com');>
>                                  ballbery at sinenomine.net
> <javascript:_e(%7B%7D,'cvml','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/20160423/a8edecf4/attachment.html>

From allbery.b at gmail.com  Sun Apr 24 00:55:02 2016
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 23 Apr 2016 20:55:02 -0400
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAHYVw0x5evLFfh9oYRwU3seXURhsW7dkKkuoCq=MrKmNiED2-g@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
 <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>
 <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>
 <CAHYVw0x6hMfh8FHrDbhd5UC_yQOd_5JVv+M_FiiUN===TYiFCQ@mail.gmail.com>
 <CAHYVw0yyxE5Q5EwHcEXF6k7bbMr_A5OXrFg7q0eR4Tphe8qM+g@mail.gmail.com>
 <CAHYVw0wHe3Pje1_s_oApM32pc=1scSgam031uruGyyL3u-wL=Q@mail.gmail.com>
 <CAHYVw0wjyzTFjYvOMm4Rm1qJuP4RjE6sPu-KrOGNzwOF=XqydA@mail.gmail.com>
 <CAHYVw0wBez8_x1igGHRcEmcL+beR9QOsa6i3dd3U87nxBZfZUw@mail.gmail.com>
 <87inz8eyj4.fsf@smart-cactus.org>
 <CAHYVw0yET5xT6FZtXRsbHwJ25XcjJzZ+Pk3339u5KEKOiqyEOA@mail.gmail.com>
 <8760v8exw0.fsf@smart-cactus.org>
 <CAHYVw0yYX8On=R8a0evyuhaExHbK8iinoz8rpRyDkEYvFksw6w@mail.gmail.com>
 <CAKFCL4Vj-YCQ0pGchRavUrO7NVDuW_vx3j73d+8j79AA3ORLkw@mail.gmail.com>
 <CAHYVw0x5evLFfh9oYRwU3seXURhsW7dkKkuoCq=MrKmNiED2-g@mail.gmail.com>
Message-ID: <CAKFCL4X4+84UV27PHdBLanRmGVK=6ktTcbin-UZP3Mmi9khhRA@mail.gmail.com>

On Sat, Apr 23, 2016 at 8:50 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> It *seemed* to work fine even with that lib no longer at that path, but
> famous last words. It does seem that it doesn't do anything


It's only used when it needs to do something for which the CPU lacks
support so a call to an emulation is used instead of trying to generate
native code for it. Maybe you got lucky and ghc doesn't actually need it in
its C bits. Or maybe it'll explode only when there's a full moon in Scorpio
and Mars is ascendant. :/ (Well, when some rarely used operation happens to
need something that x86_64 needs help with. I don't think there are many of
those --- which means it's going to be an even rarer explosion.)

-- 
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/20160423/1b3024be/attachment.html>

From carter.schonwald at gmail.com  Sun Apr 24 01:18:32 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 23 Apr 2016 21:18:32 -0400
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAKFCL4X4+84UV27PHdBLanRmGVK=6ktTcbin-UZP3Mmi9khhRA@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
 <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>
 <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>
 <CAHYVw0x6hMfh8FHrDbhd5UC_yQOd_5JVv+M_FiiUN===TYiFCQ@mail.gmail.com>
 <CAHYVw0yyxE5Q5EwHcEXF6k7bbMr_A5OXrFg7q0eR4Tphe8qM+g@mail.gmail.com>
 <CAHYVw0wHe3Pje1_s_oApM32pc=1scSgam031uruGyyL3u-wL=Q@mail.gmail.com>
 <CAHYVw0wjyzTFjYvOMm4Rm1qJuP4RjE6sPu-KrOGNzwOF=XqydA@mail.gmail.com>
 <CAHYVw0wBez8_x1igGHRcEmcL+beR9QOsa6i3dd3U87nxBZfZUw@mail.gmail.com>
 <87inz8eyj4.fsf@smart-cactus.org>
 <CAHYVw0yET5xT6FZtXRsbHwJ25XcjJzZ+Pk3339u5KEKOiqyEOA@mail.gmail.com>
 <8760v8exw0.fsf@smart-cactus.org>
 <CAHYVw0yYX8On=R8a0evyuhaExHbK8iinoz8rpRyDkEYvFksw6w@mail.gmail.com>
 <CAKFCL4Vj-YCQ0pGchRavUrO7NVDuW_vx3j73d+8j79AA3ORLkw@mail.gmail.com>
 <CAHYVw0x5evLFfh9oYRwU3seXURhsW7dkKkuoCq=MrKmNiED2-g@mail.gmail.com>
 <CAKFCL4X4+84UV27PHdBLanRmGVK=6ktTcbin-UZP3Mmi9khhRA@mail.gmail.com>
Message-ID: <CAHYVw0yj5rzYRVGrbwUyY+5=5FVRrnfguPdaw+m6B87yP+B17A@mail.gmail.com>

I guess I have some spelunking to do tomorrow

It looks like apples libgcc may be some sort of clang thingy.

On Saturday, April 23, 2016, Brandon Allbery <allbery.b at gmail.com> wrote:

> On Sat, Apr 23, 2016 at 8:50 PM, Carter Schonwald <
> carter.schonwald at gmail.com
> <javascript:_e(%7B%7D,'cvml','carter.schonwald at gmail.com');>> wrote:
>
>> It *seemed* to work fine even with that lib no longer at that path, but
>> famous last words. It does seem that it doesn't do anything
>
>
> It's only used when it needs to do something for which the CPU lacks
> support so a call to an emulation is used instead of trying to generate
> native code for it. Maybe you got lucky and ghc doesn't actually need it in
> its C bits. Or maybe it'll explode only when there's a full moon in Scorpio
> and Mars is ascendant. :/ (Well, when some rarely used operation happens to
> need something that x86_64 needs help with. I don't think there are many of
> those --- which means it's going to be an even rarer explosion.)
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com <javascript:_e(%7B%7D,'cvml','allbery.b at gmail.com');>
>                                  ballbery at sinenomine.net
> <javascript:_e(%7B%7D,'cvml','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/20160423/0f86d36b/attachment-0001.html>

From carter.schonwald at gmail.com  Sun Apr 24 01:44:23 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 23 Apr 2016 21:44:23 -0400
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAHYVw0yj5rzYRVGrbwUyY+5=5FVRrnfguPdaw+m6B87yP+B17A@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
 <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>
 <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>
 <CAHYVw0x6hMfh8FHrDbhd5UC_yQOd_5JVv+M_FiiUN===TYiFCQ@mail.gmail.com>
 <CAHYVw0yyxE5Q5EwHcEXF6k7bbMr_A5OXrFg7q0eR4Tphe8qM+g@mail.gmail.com>
 <CAHYVw0wHe3Pje1_s_oApM32pc=1scSgam031uruGyyL3u-wL=Q@mail.gmail.com>
 <CAHYVw0wjyzTFjYvOMm4Rm1qJuP4RjE6sPu-KrOGNzwOF=XqydA@mail.gmail.com>
 <CAHYVw0wBez8_x1igGHRcEmcL+beR9QOsa6i3dd3U87nxBZfZUw@mail.gmail.com>
 <87inz8eyj4.fsf@smart-cactus.org>
 <CAHYVw0yET5xT6FZtXRsbHwJ25XcjJzZ+Pk3339u5KEKOiqyEOA@mail.gmail.com>
 <8760v8exw0.fsf@smart-cactus.org>
 <CAHYVw0yYX8On=R8a0evyuhaExHbK8iinoz8rpRyDkEYvFksw6w@mail.gmail.com>
 <CAKFCL4Vj-YCQ0pGchRavUrO7NVDuW_vx3j73d+8j79AA3ORLkw@mail.gmail.com>
 <CAHYVw0x5evLFfh9oYRwU3seXURhsW7dkKkuoCq=MrKmNiED2-g@mail.gmail.com>
 <CAKFCL4X4+84UV27PHdBLanRmGVK=6ktTcbin-UZP3Mmi9khhRA@mail.gmail.com>
 <CAHYVw0yj5rzYRVGrbwUyY+5=5FVRrnfguPdaw+m6B87yP+B17A@mail.gmail.com>
Message-ID: <CAHYVw0weNYg5Hq7xLZ=3Ny_9gPz1Amejr09R43NY-+M2g+VvJQ@mail.gmail.com>

https://github.com/gcc-mirror/gcc/blob/master/libgcc/config/darwin-64.c

If my understanding of the code is correct, there's no problems ! :)
On Saturday, April 23, 2016, Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> I guess I have some spelunking to do tomorrow
>
> It looks like apples libgcc may be some sort of clang thingy.
>
> On Saturday, April 23, 2016, Brandon Allbery <allbery.b at gmail.com
> <javascript:_e(%7B%7D,'cvml','allbery.b at gmail.com');>> wrote:
>
>> On Sat, Apr 23, 2016 at 8:50 PM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> It *seemed* to work fine even with that lib no longer at that path, but
>>> famous last words. It does seem that it doesn't do anything
>>
>>
>> It's only used when it needs to do something for which the CPU lacks
>> support so a call to an emulation is used instead of trying to generate
>> native code for it. Maybe you got lucky and ghc doesn't actually need it in
>> its C bits. Or maybe it'll explode only when there's a full moon in Scorpio
>> and Mars is ascendant. :/ (Well, when some rarely used operation happens to
>> need something that x86_64 needs help with. I don't think there are many of
>> those --- which means it's going to be an even rarer explosion.)
>>
>> --
>> 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/20160423/6f892de2/attachment.html>

From allbery.b at gmail.com  Sun Apr 24 01:46:32 2016
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 23 Apr 2016 21:46:32 -0400
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAHYVw0weNYg5Hq7xLZ=3Ny_9gPz1Amejr09R43NY-+M2g+VvJQ@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
 <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>
 <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>
 <CAHYVw0x6hMfh8FHrDbhd5UC_yQOd_5JVv+M_FiiUN===TYiFCQ@mail.gmail.com>
 <CAHYVw0yyxE5Q5EwHcEXF6k7bbMr_A5OXrFg7q0eR4Tphe8qM+g@mail.gmail.com>
 <CAHYVw0wHe3Pje1_s_oApM32pc=1scSgam031uruGyyL3u-wL=Q@mail.gmail.com>
 <CAHYVw0wjyzTFjYvOMm4Rm1qJuP4RjE6sPu-KrOGNzwOF=XqydA@mail.gmail.com>
 <CAHYVw0wBez8_x1igGHRcEmcL+beR9QOsa6i3dd3U87nxBZfZUw@mail.gmail.com>
 <87inz8eyj4.fsf@smart-cactus.org>
 <CAHYVw0yET5xT6FZtXRsbHwJ25XcjJzZ+Pk3339u5KEKOiqyEOA@mail.gmail.com>
 <8760v8exw0.fsf@smart-cactus.org>
 <CAHYVw0yYX8On=R8a0evyuhaExHbK8iinoz8rpRyDkEYvFksw6w@mail.gmail.com>
 <CAKFCL4Vj-YCQ0pGchRavUrO7NVDuW_vx3j73d+8j79AA3ORLkw@mail.gmail.com>
 <CAHYVw0x5evLFfh9oYRwU3seXURhsW7dkKkuoCq=MrKmNiED2-g@mail.gmail.com>
 <CAKFCL4X4+84UV27PHdBLanRmGVK=6ktTcbin-UZP3Mmi9khhRA@mail.gmail.com>
 <CAHYVw0yj5rzYRVGrbwUyY+5=5FVRrnfguPdaw+m6B87yP+B17A@mail.gmail.com>
 <CAHYVw0weNYg5Hq7xLZ=3Ny_9gPz1Amejr09R43NY-+M2g+VvJQ@mail.gmail.com>
Message-ID: <CAKFCL4WyqQvN1UMmQwwP1tNS2O+QvuJaMMt9S=ioZyh+=irbmQ@mail.gmail.com>

On Sat, Apr 23, 2016 at 9:44 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> If my understanding of the code is correct, there's no problems ! :)


I have to admit I was wondering if it was just a stub to keep the rest of
gcc / crt0/crtn happy....

-- 
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/20160423/86acc72c/attachment.html>

From carter.schonwald at gmail.com  Sun Apr 24 02:23:22 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 23 Apr 2016 22:23:22 -0400
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <CAKFCL4WyqQvN1UMmQwwP1tNS2O+QvuJaMMt9S=ioZyh+=irbmQ@mail.gmail.com>
References: <877ffpu3ax.fsf@smart-cactus.org>
 <CAB-d4A79KU6=cLRMi8DYBABQ-mGCwAUjbwkR2bQZAymjgbPzGw@mail.gmail.com>
 <CAHYVw0wL5AR+MX-AwFVFVBk+cNWF5BaCTDa125aj01ZUM9DgmQ@mail.gmail.com>
 <CAB-d4A7KakvNxibB=ytQqfxoSUEcYKNynrtJxY1fw7UayagKRQ@mail.gmail.com>
 <CAB-d4A5qmje0ZmTUd3ZGBGB55mi7ACjpQe=Uq1c53YqZkpQVGw@mail.gmail.com>
 <CAHYVw0x6hMfh8FHrDbhd5UC_yQOd_5JVv+M_FiiUN===TYiFCQ@mail.gmail.com>
 <CAHYVw0yyxE5Q5EwHcEXF6k7bbMr_A5OXrFg7q0eR4Tphe8qM+g@mail.gmail.com>
 <CAHYVw0wHe3Pje1_s_oApM32pc=1scSgam031uruGyyL3u-wL=Q@mail.gmail.com>
 <CAHYVw0wjyzTFjYvOMm4Rm1qJuP4RjE6sPu-KrOGNzwOF=XqydA@mail.gmail.com>
 <CAHYVw0wBez8_x1igGHRcEmcL+beR9QOsa6i3dd3U87nxBZfZUw@mail.gmail.com>
 <87inz8eyj4.fsf@smart-cactus.org>
 <CAHYVw0yET5xT6FZtXRsbHwJ25XcjJzZ+Pk3339u5KEKOiqyEOA@mail.gmail.com>
 <8760v8exw0.fsf@smart-cactus.org>
 <CAHYVw0yYX8On=R8a0evyuhaExHbK8iinoz8rpRyDkEYvFksw6w@mail.gmail.com>
 <CAKFCL4Vj-YCQ0pGchRavUrO7NVDuW_vx3j73d+8j79AA3ORLkw@mail.gmail.com>
 <CAHYVw0x5evLFfh9oYRwU3seXURhsW7dkKkuoCq=MrKmNiED2-g@mail.gmail.com>
 <CAKFCL4X4+84UV27PHdBLanRmGVK=6ktTcbin-UZP3Mmi9khhRA@mail.gmail.com>
 <CAHYVw0yj5rzYRVGrbwUyY+5=5FVRrnfguPdaw+m6B87yP+B17A@mail.gmail.com>
 <CAHYVw0weNYg5Hq7xLZ=3Ny_9gPz1Amejr09R43NY-+M2g+VvJQ@mail.gmail.com>
 <CAKFCL4WyqQvN1UMmQwwP1tNS2O+QvuJaMMt9S=ioZyh+=irbmQ@mail.gmail.com>
Message-ID: <CAHYVw0wTmAZZGnrF-HHPgvGpbpzsivo5Hb2ZEyzy6G66MxNYpQ@mail.gmail.com>

it looks like the last bit i need to audit is
https://github.com/gcc-mirror/gcc/blob/master/libgcc/config.host#L569-L572
and then just run some experiments tomorrow :)

On Sat, Apr 23, 2016 at 9:46 PM, Brandon Allbery <allbery.b at gmail.com>
wrote:

> On Sat, Apr 23, 2016 at 9:44 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> If my understanding of the code is correct, there's no problems ! :)
>
>
> I have to admit I was wondering if it was just a stub to keep the rest of
> gcc / crt0/crtn happy....
>
> --
> 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/20160423/95368238/attachment.html>

From thomasmiedema at gmail.com  Sun Apr 24 09:33:16 2016
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Sun, 24 Apr 2016 11:33:16 +0200
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <CAB-d4A7=oFOg-D_sNRhgeAehXynNDq73a+48j=z=xLxbMYLNrg@mail.gmail.com>
References: <87egadbj2w.fsf@smart-cactus.org>
 <CAB-d4A4gHuVSfZw_ci-2aooTQ4seuAzz1tU+wyyPznHh=Met=g@mail.gmail.com>
 <CAEs96n24m9DAitZhZqKPu=mWidBuE1HU-V4jnjNUJgo+L+td8w@mail.gmail.com>
 <CAHYVw0x4MP38qvir10zDLpodDdXXk2SiPS8miyUgd3pMFqP4YA@mail.gmail.com>
 <CAHYVw0y87yAYHCp1J6q93eTimawTcwx3kUedaSA2OEmGeQZOdw@mail.gmail.com>
 <CAB-d4A7=oFOg-D_sNRhgeAehXynNDq73a+48j=z=xLxbMYLNrg@mail.gmail.com>
Message-ID: <CAD3WKgj07_QQKiv2RqDV-rxP8WqeN1NgkJgwhjO9dzdTbBN-gw@mail.gmail.com>

On Wed, Apr 13, 2016 at 11:13 PM, George Colpitts <george.colpitts at gmail.com
> wrote:

> Thanks, with your response and Austin's I was able to get the doc to build
>

Could you or Carter please update
https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/MacOSX. It
doesn't mention anything about "ttf font files" yet, but I guess it should.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160424/29609758/attachment.html>

From ben at well-typed.com  Sun Apr 24 10:04:16 2016
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 24 Apr 2016 12:04:16 +0200
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <CAD3WKgj07_QQKiv2RqDV-rxP8WqeN1NgkJgwhjO9dzdTbBN-gw@mail.gmail.com>
References: <87egadbj2w.fsf@smart-cactus.org>
 <CAB-d4A4gHuVSfZw_ci-2aooTQ4seuAzz1tU+wyyPznHh=Met=g@mail.gmail.com>
 <CAEs96n24m9DAitZhZqKPu=mWidBuE1HU-V4jnjNUJgo+L+td8w@mail.gmail.com>
 <CAHYVw0x4MP38qvir10zDLpodDdXXk2SiPS8miyUgd3pMFqP4YA@mail.gmail.com>
 <CAHYVw0y87yAYHCp1J6q93eTimawTcwx3kUedaSA2OEmGeQZOdw@mail.gmail.com>
 <CAB-d4A7=oFOg-D_sNRhgeAehXynNDq73a+48j=z=xLxbMYLNrg@mail.gmail.com>
 <CAD3WKgj07_QQKiv2RqDV-rxP8WqeN1NgkJgwhjO9dzdTbBN-gw@mail.gmail.com>
Message-ID: <87potfe31b.fsf@smart-cactus.org>

Thomas Miedema <thomasmiedema at gmail.com> writes:

> On Wed, Apr 13, 2016 at 11:13 PM, George Colpitts <george.colpitts at gmail.com
>> wrote:
>
>> Thanks, with your response and Austin's I was able to get the doc to build
>>
>
> Could you or Carter please update
> https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/MacOSX. It
> doesn't mention anything about "ttf font files" yet, but I guess it should.

Indeed, this would be extremely helpful! In general it would be great if
someone could take a pass through the OS X build instructions; they seem
to be a bit dated.

Thanks!

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

From carter.schonwald at gmail.com  Sun Apr 24 11:34:35 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 24 Apr 2016 07:34:35 -0400
Subject: GHC 8.0.1-rc3 source tarball availability
In-Reply-To: <87potfe31b.fsf@smart-cactus.org>
References: <87egadbj2w.fsf@smart-cactus.org>
 <CAB-d4A4gHuVSfZw_ci-2aooTQ4seuAzz1tU+wyyPznHh=Met=g@mail.gmail.com>
 <CAEs96n24m9DAitZhZqKPu=mWidBuE1HU-V4jnjNUJgo+L+td8w@mail.gmail.com>
 <CAHYVw0x4MP38qvir10zDLpodDdXXk2SiPS8miyUgd3pMFqP4YA@mail.gmail.com>
 <CAHYVw0y87yAYHCp1J6q93eTimawTcwx3kUedaSA2OEmGeQZOdw@mail.gmail.com>
 <CAB-d4A7=oFOg-D_sNRhgeAehXynNDq73a+48j=z=xLxbMYLNrg@mail.gmail.com>
 <CAD3WKgj07_QQKiv2RqDV-rxP8WqeN1NgkJgwhjO9dzdTbBN-gw@mail.gmail.com>
 <87potfe31b.fsf@smart-cactus.org>
Message-ID: <CAHYVw0xk+wtMvf+MRkDT=f1WPueg1mn1GB+JQP3Ccdwpbwp8bQ@mail.gmail.com>

Roger that
I'm also going to do some sleuthing on the docs.  Because the are
validating mk file wasn't there on the last Build. Unless it contaminated
something that maintainer clean didn't touch.

I also need to audit if ghc or any of the boot libs invoke one of the lib
gcc symbols.  Though I suspect not.

On Sunday, April 24, 2016, Ben Gamari <ben at well-typed.com> wrote:

> Thomas Miedema <thomasmiedema at gmail.com <javascript:;>> writes:
>
> > On Wed, Apr 13, 2016 at 11:13 PM, George Colpitts <
> george.colpitts at gmail.com <javascript:;>
> >> wrote:
> >
> >> Thanks, with your response and Austin's I was able to get the doc to
> build
> >>
> >
> > Could you or Carter please update
> > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/MacOSX. It
> > doesn't mention anything about "ttf font files" yet, but I guess it
> should.
>
> Indeed, this would be extremely helpful! In general it would be great if
> someone could take a pass through the OS X build instructions; they seem
> to be a bit dated.
>
> Thanks!
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160424/ddae4547/attachment-0001.html>

From carter.schonwald at gmail.com  Sun Apr 24 21:42:51 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sun, 24 Apr 2016 17:42:51 -0400
Subject: reproducible crash in profiled builds when -hb or -hr are enabled in
 ghc 8.0rc4 (and 7.10.3 and older)
Message-ID: <CAHYVw0zicNXbaZUM9HauJfkr3Mj6bS8CystVpu9iSaKezA3kMw@mail.gmail.com>

Hello all,
I've found a reproducible (on OS X) crash when using biographical or
retainer profiling (different crashes respectively) that doesn't happen
otherwise on profiled builds executables,
https://ghc.haskell.org/trac/ghc/ticket/11978 should provide enough
information to replicate it (though by no means minimal :(, but if need be
i'll try to help out on that front)

i've marked it as "highest" because an otherwise ok program triggers a
sigsegv with -hb! (which may or may not be related to the different crash
that -hr triggered).

I'm not sure how to best go about debugging this sort of crash (though if i
can find time later this week i'm happy to help)

many thanks
-Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160424/823a03d7/attachment.html>

From carter.schonwald at gmail.com  Mon Apr 25 04:55:36 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 25 Apr 2016 00:55:36 -0400
Subject: gcc5 and apple clang variants of mac ghc 8.0 rc4 build
Message-ID: <CAHYVw0wvdcU5if6f0BAccbsuW1crKSfMsGemPyv2YwDdkGN2zg@mail.gmail.com>

since i've yet to dig into if any libgcc symbols ever get invoked, heres
versions of the RC for mac built using gcc5 and apple clang respectively
(in addition to the other one i've already provided that has a gcc6 libgcc
dylib that seems to spuriously leak through)

https://wellposed-carter-files.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/vanilla-clang-ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz

shasum -a512 vanilla-clang-ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz
9105b097bb8036d6a77fc7bb87bcb0efff4ac7136232ac7ce109664ecae6e0e6757904f4a80de9120813530b979e7d90a36b4b28a1ef7bb9c371ab10a346c9dc
vanilla-clang-ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz

http://wellposed-carter-files.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/vanilla-gcc5-ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz

shasum -a512 vanilla-gcc5-ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz
43bb84fe73ac9e450d73a877022ba2ca514a08f69c18cac7367ed7038e9f7371b21cdaeef635aee345f9ba001a2fb5b527975e790f1b8d1c6f91bdf231e05090
vanilla-gcc5-ghc-8.0.0.20160421-x86_64-apple-darwin.tar.xz

enjoy!
-Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160425/5d8e7df8/attachment.html>

From simonpj at microsoft.com  Mon Apr 25 09:32:17 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 25 Apr 2016 09:32:17 +0000
Subject: =?utf-8?B?UkU6IHBlcmYuaGFza2VsbC5vcmfigJlzIGxpc3Qgb2YgYnJhbmNoZXMgZ290?=
 =?utf-8?Q?_more_useful?=
In-Reply-To: <1461440463.8186.9.camel@joachim-breitner.de>
References: <1461440463.8186.9.camel@joachim-breitner.de>
Message-ID: <c00ee22255e2455984941d58bcb9a05d@DB4PR30MB030.064d.mgd.msft.net>

Joachim

Fabulous.

But your email will soon disappear into the mists of time, and the page itself does not convey the same information.  

Is there a wiki page, kept up to date, that explains exactly how to read the performance results?

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Joachim Breitner
|  Sent: 23 April 2016 20:41
|  To: ghc-devs at haskell.org
|  Subject: perf.haskell.org?s list of branches got more useful
|  
|  Hi,
|  
|  the list of branches
|  on?https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fper
|  f.haskell.org%2fghc&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7ce
|  c0ca8588956494efa3308d36baf36f5%7c72f988bf86f141af91ab2d7cd011db47%7c1&
|  sdata=Rk2Y38BjXeE9Et8yxiuOdpiJ3PSMn9RdIxonRksxTc4%3d?got more useful.
|  It now shows the difference from the branch head to the merge base?,
|  which should roughly exhibit the performance change that would be
|  caused by merging the branch into master.
|  
|  If the branch head or the merge base have not been measured (e.g.
|  because the build failed), the display might be a bit confusing. Same
|  with branches that often merge or cherry-pick from master. But in the
|  common case of a linear, possibly rebased, feature branch, it should
|  work fine.
|  
|  Greetings,
|  Joachim
|  
|  ? Which, I think, is the youngest commit also reachable from master. Or
|  something like that. Consult "man git merge-base" if you want a little
|  mind teaser.
|  
|  --
|  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=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cec0ca8
|  588956494efa3308d36baf36f5%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata
|  =ya%2bnaZWlbasw8BSIICImvWjh1x%2fb6%2bTsHJuKRGzu2Rg%3d
|  ? XMPP: nomeata at joachim-breitner.de?? OpenPGP-Key: 0xF0FBF51F
|  ? Debian Developer: nomeata at debian.org


From mail at joachim-breitner.de  Mon Apr 25 10:34:15 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 25 Apr 2016 12:34:15 +0200
Subject: =?UTF-8?Q?perf=2Ehaskell=2Eorg=E2=80=99s?= list of branches got
 more useful
In-Reply-To: <c00ee22255e2455984941d58bcb9a05d@DB4PR30MB030.064d.mgd.msft.net>
References: <1461440463.8186.9.camel@joachim-breitner.de>
 <c00ee22255e2455984941d58bcb9a05d@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <1461580455.4490.10.camel@joachim-breitner.de>

Dear Simon,


Am Montag, den 25.04.2016, 09:32 +0000 schrieb Simon Peyton Jones:
> But your email will soon disappear into the mists of time, and the
> page itself does not convey the same information.??
> 
> Is there a wiki page, kept up to date, that explains exactly how to
> read the performance results?

no, there is not, but I have doubts it will stay up-to-date. Also, the
performance dashboard is not GHC specific, so the GHC trac is an odd
place for documentation.

Generally, UI that needs extensive documentation is bad UI.
So if the interface is confusing, gipeda needs to be improved (and may
it be with ?title? tags that explain the fields). If there are concrete
issues with the page, let me know, and I?ll try to improve the
interface.

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
? mail at joachim-breitner.de ? https://www.joachim-breitner.de/
? XMPP: nomeata at joachim-breitner.de?? OpenPGP-Key: 0xF0FBF51F
? Debian Developer: nomeata at debian.org

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

From simonpj at microsoft.com  Mon Apr 25 13:54:09 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 25 Apr 2016 13:54:09 +0000
Subject: =?utf-8?B?UkU6IHBlcmYuaGFza2VsbC5vcmfigJlzIGxpc3Qgb2YgYnJhbmNoZXMgZ290?=
 =?utf-8?Q?_more_useful?=
In-Reply-To: <1461580455.4490.10.camel@joachim-breitner.de>
References: <1461440463.8186.9.camel@joachim-breitner.de>
 <c00ee22255e2455984941d58bcb9a05d@DB4PR30MB030.064d.mgd.msft.net>
 <1461580455.4490.10.camel@joachim-breitner.de>
Message-ID: <5ed3215a33ca4fc682d11325cf8fe594@DB4PR30MB030.064d.mgd.msft.net>

|  Generally, UI that needs extensive documentation is bad UI.
|  So if the interface is confusing, gipeda needs to be improved (and may
|  it be with ?title? tags that explain the fields). If there are concrete
|  issues with the page, let me know, and I?ll try to improve the
|  interface.

Well that's a great aspiration, but it is a hard one to deliver on.  I am completely flummoxed by almost every element of the current page. (And not just this UI, but many others.)

* Nothing says what the baseline is; your email specifically says that you have changed the baseline

To take the first line of the "Branches" section

* What does "2 days ago" mean?
* What does "3 commit to cb300e" mean?
* What does 276 mean
* What does the little histogram mean?
* What does 0+0- mean?

I'm short, I'm lost.  I need a little page with an example and explanations of each element.

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Joachim Breitner
|  Sent: 25 April 2016 11:34
|  To: ghc-devs at haskell.org
|  Subject: Re: perf.haskell.org?s list of branches got more useful
|  
|  Dear Simon,
|  
|  
|  Am Montag, den 25.04.2016, 09:32 +0000 schrieb Simon Peyton Jones:
|  > But your email will soon disappear into the mists of time, and the
|  > page itself does not convey the same information.
|  >
|  > Is there a wiki page, kept up to date, that explains exactly how to
|  > read the performance results?
|  
|  no, there is not, but I have doubts it will stay up-to-date. Also, the
|  performance dashboard is not GHC specific, so the GHC trac is an odd
|  place for documentation.
|  
|  Generally, UI that needs extensive documentation is bad UI.
|  So if the interface is confusing, gipeda needs to be improved (and may
|  it be with ?title? tags that explain the fields). If there are concrete
|  issues with the page, let me know, and I?ll try to improve the
|  interface.
|  
|  Greetings,
|  Joachim
|  
|  
|  --
|  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=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c84e8b9
|  fcdb4b4c19445808d36cf528d9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata
|  =bDjE6VphGJnU1mqFdjWKkU2dH4o5554xtdx%2fl%2fLreoM%3d
|  ? XMPP: nomeata at joachim-breitner.de?? OpenPGP-Key: 0xF0FBF51F
|  ? Debian Developer: nomeata at debian.org


From mail at joachim-breitner.de  Tue Apr 26 11:09:05 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 26 Apr 2016 13:09:05 +0200
Subject: =?UTF-8?Q?perf=2Ehaskell=2Eorg=E2=80=99s?= list of branches got
 more useful
In-Reply-To: <5ed3215a33ca4fc682d11325cf8fe594@DB4PR30MB030.064d.mgd.msft.net>
References: <1461440463.8186.9.camel@joachim-breitner.de>
 <c00ee22255e2455984941d58bcb9a05d@DB4PR30MB030.064d.mgd.msft.net>
 <1461580455.4490.10.camel@joachim-breitner.de>
 <5ed3215a33ca4fc682d11325cf8fe594@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <1461668945.1781.28.camel@joachim-breitner.de>

Hi,

Am Montag, den 25.04.2016, 13:54 +0000 schrieb Simon Peyton Jones:
> > 
> > ?Generally, UI that needs extensive documentation is bad UI.
> > ?So if the interface is confusing, gipeda needs to be improved (and may
> > ?it be with ?title? tags that explain the fields). If there are concrete
> > ?issues with the page, let me know, and I?ll try to improve the
> > ?interface.
>
> Well that's a great aspiration, but it is a hard one to deliver
> on.??I am completely flummoxed by almost every element of the current
> page. (And not just this UI, but many others.)

And I am repeatedly flummoxed by your vocabularly; always a joy :-)

> * Nothing says what the baseline is; your email specifically says
> that you have changed the baseline
> 
> To take the first line of the "Branches" section
> 
> [..]
> 
> I'm short, I'm lost.??I need a little page with an example and
> explanations of each element.

Hmm, I see your point. But since I did not see it originally, maybe I?m
not the right person to describe the UI ? after all, I?m heavily biased
by having it created in the first place. Are there volunteers that that
would enjoy creating a user-oriented documentation for gipeda?
(Probably not in the form of a detached wiki page, but a help page
linked from?https://perf.haskell.org/ghc?directly.)

Until then, allow me to briefly answer your questions:
?
> * What does "2 days ago" mean?

The age of the latest commit to the branch.

> * What does "3 commit to cb300e" mean?

That this branch contains 3 commits relative to master, and that the
final commit on the branch is?cb300e. These are two links with
tooltips:
The first one says ?Compare against merge base?, which will take you to
a comparison page between the base commit and the latest commit on the
branch.
The second one says ?Show branch tip?, will will take you to that
revisions? usual results view, which is relative to its parent.

> * What does 276 mean

Number of benchmarks taken. I?m considering to remove this bit of
information here, it is not really interesting.

> * What does the little histogram mean
> * What does 0+0- mean?

Number of improvements (+) and regressions (-). In the per-branch-list
is against the merge base, in the commit list it is against the
commit?s parent. If you hover, you?ll see a list of changes (if there
are any).

Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
? mail at joachim-breitner.de ? https://www.joachim-breitner.de/
? XMPP: nomeata at joachim-breitner.de?? OpenPGP-Key: 0xF0FBF51F
? Debian Developer: nomeata at debian.org

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

From eir at cis.upenn.edu  Tue Apr 26 13:08:27 2016
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 26 Apr 2016 09:08:27 -0400
Subject: Bikeshedding request for GHCi's :type
Message-ID: <60D162E7-9FAE-45AE-BD22-9E1C6D6C7466@cis.upenn.edu>

Hi devs,

Over the weekend, I was pondering the Haskell course I will be teaching next year and shuddered at having to teach Foldable at the same time as `length`. So I implemented feature request #10963 (https://ghc.haskell.org/trac/ghc/ticket/10963), which allows for a way for a user to request a specialization of a type. It all works wonderfully, but there is a real user-facing design issue here around the default behavior of :type and whether or not to add new :type-y like commands. I have outlined the situation here: https://ghc.haskell.org/trac/ghc/wiki/Design/GHCi/Type

I'd love some broad input on this issue. If you've got a stake in how this all works, please skim that wiki page and comment on #10963.

Thanks!
Richard

From david.feuer at gmail.com  Tue Apr 26 14:33:29 2016
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 26 Apr 2016 10:33:29 -0400
Subject: Can we do something slightly nicer about (^)?
In-Reply-To: <CAMgWh9sPXC7pqtjYDjsgJLQmYc=ewBQQtkASTcxd_r6io_VhZA@mail.gmail.com>
References: <CAMgWh9sX-e3R6h5scykbAiP849A82_mF-t7r5aAT2gBoTnQcjQ@mail.gmail.com>
 <CAMgWh9spDYm_F3-sZj2dX0=xt69iasH849f_r4-BT_uLndVUMQ@mail.gmail.com>
 <CAMgWh9sOw+=1ONaXQaPQTv-P3ypOHVoCShwQdrCVnB3jK4M9bA@mail.gmail.com>
 <CAMgWh9tZLDYFvSP6buewRWCKZG3NOppd5Yb8o1jvDKPbOKo9uw@mail.gmail.com>
 <CAMgWh9sJvo9TY9xLiZ4aARJ4MP17-H+vmxx-QZ1CZc6Zj4K=dA@mail.gmail.com>
 <CAMgWh9ubDFOc87W8N2PqB1oGaZu+u5wibQ9Nvin78nVDE=qkCQ@mail.gmail.com>
 <CAMgWh9vu_zJTTRMEPcs+F+Rjwy27ykmA-szG0HJdQb6O+F_Xmg@mail.gmail.com>
 <CAMgWh9uorQ5xye1kaW=jfGBR-J4tHMG7xAgpO1jLuW9RtJinDg@mail.gmail.com>
 <CAMgWh9sSH8-NUQF8Bhtkzp60sJkDE3JY9+dXnGBJk975NAKX9g@mail.gmail.com>
 <CAMgWh9suk2NmsEpdSP9a5VCr1AMDQwSgyJAJUSRwYzRd9C6bxA@mail.gmail.com>
 <CAMgWh9sn2LNH6xeRai_cLHR_XX74kyB06BXYa1+Eo7gQ7M2D0w@mail.gmail.com>
 <CAMgWh9sPXC7pqtjYDjsgJLQmYc=ewBQQtkASTcxd_r6io_VhZA@mail.gmail.com>
Message-ID: <CAMgWh9teVfxgihGwP0vf1jGHKc+=viBe8vNj+Egofd_MyMjWRA@mail.gmail.com>

Every time someone writes, say, x^20, the literal exponent defaults to
Integer. This is the wrong default whenever the literal is in the Word
range. Fixing this goes beyond the capabilities of RULES pragmas, but I
imagine it would be a fairly simple thing to accomplish in the internal
rule language.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160426/c1fa9959/attachment.html>

From mail at joachim-breitner.de  Tue Apr 26 14:55:42 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 26 Apr 2016 16:55:42 +0200
Subject: Can we do something slightly nicer about (^)?
In-Reply-To: <CAMgWh9teVfxgihGwP0vf1jGHKc+=viBe8vNj+Egofd_MyMjWRA@mail.gmail.com>
References: <CAMgWh9sX-e3R6h5scykbAiP849A82_mF-t7r5aAT2gBoTnQcjQ@mail.gmail.com>
 <CAMgWh9spDYm_F3-sZj2dX0=xt69iasH849f_r4-BT_uLndVUMQ@mail.gmail.com>
 <CAMgWh9sOw+=1ONaXQaPQTv-P3ypOHVoCShwQdrCVnB3jK4M9bA@mail.gmail.com>
 <CAMgWh9tZLDYFvSP6buewRWCKZG3NOppd5Yb8o1jvDKPbOKo9uw@mail.gmail.com>
 <CAMgWh9sJvo9TY9xLiZ4aARJ4MP17-H+vmxx-QZ1CZc6Zj4K=dA@mail.gmail.com>
 <CAMgWh9ubDFOc87W8N2PqB1oGaZu+u5wibQ9Nvin78nVDE=qkCQ@mail.gmail.com>
 <CAMgWh9vu_zJTTRMEPcs+F+Rjwy27ykmA-szG0HJdQb6O+F_Xmg@mail.gmail.com>
 <CAMgWh9uorQ5xye1kaW=jfGBR-J4tHMG7xAgpO1jLuW9RtJinDg@mail.gmail.com>
 <CAMgWh9sSH8-NUQF8Bhtkzp60sJkDE3JY9+dXnGBJk975NAKX9g@mail.gmail.com>
 <CAMgWh9suk2NmsEpdSP9a5VCr1AMDQwSgyJAJUSRwYzRd9C6bxA@mail.gmail.com>
 <CAMgWh9sn2LNH6xeRai_cLHR_XX74kyB06BXYa1+Eo7gQ7M2D0w@mail.gmail.com>
 <CAMgWh9sPXC7pqtjYDjsgJLQmYc=ewBQQtkASTcxd_r6io_VhZA@mail.gmail.com>
 <CAMgWh9teVfxgihGwP0vf1jGHKc+=viBe8vNj+Egofd_MyMjWRA@mail.gmail.com>
Message-ID: <1461682542.13494.13.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 26.04.2016, 10:33 -0400 schrieb David Feuer:
> Fixing this goes beyond the capabilities of RULES pragmas

maybe it shouln?t:
https://ghc.haskell.org/trac/ghc/ticket/9137
https://ghc.haskell.org/trac/ghc/ticket/9601


Greetings,
Joachim


-- 
Joachim ?nomeata? Breitner
? mail at joachim-breitner.de ? https://www.joachim-breitner.de/
? XMPP: nomeata at joachim-breitner.de?? OpenPGP-Key: 0xF0FBF51F
? Debian Developer: nomeata at debian.org

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

From spam at scientician.net  Tue Apr 26 14:57:43 2016
From: spam at scientician.net (Bardur Arantsson)
Date: Tue, 26 Apr 2016 16:57:43 +0200
Subject: =?UTF-8?Q?Re:_perf.haskell.org=e2=80=99s_list_of_branches_got_more_?=
 =?UTF-8?Q?useful?=
In-Reply-To: <1461668945.1781.28.camel@joachim-breitner.de>
References: <1461440463.8186.9.camel@joachim-breitner.de>
 <c00ee22255e2455984941d58bcb9a05d@DB4PR30MB030.064d.mgd.msft.net>
 <1461580455.4490.10.camel@joachim-breitner.de>
 <5ed3215a33ca4fc682d11325cf8fe594@DB4PR30MB030.064d.mgd.msft.net>
 <1461668945.1781.28.camel@joachim-breitner.de>
Message-ID: <nfnvl7$slb$1@ger.gmane.org>

On 04/26/2016 01:09 PM, Joachim Breitner wrote:
> Hi,
> 
>  
>> * What does "2 days ago" mean?
> 
> The age of the latest commit to the branch.
> 

FWIW, I think adding a few simple table headings might help enormously.

"Last commit", "?", "Branch", "Last commit message", "Diffstat".

(or something like that.)



From george.colpitts at gmail.com  Tue Apr 26 15:31:55 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Tue, 26 Apr 2016 15:31:55 +0000
Subject: Can we do something slightly nicer about (^)?
In-Reply-To: <1461682542.13494.13.camel@joachim-breitner.de>
References: <CAMgWh9sX-e3R6h5scykbAiP849A82_mF-t7r5aAT2gBoTnQcjQ@mail.gmail.com>
 <CAMgWh9spDYm_F3-sZj2dX0=xt69iasH849f_r4-BT_uLndVUMQ@mail.gmail.com>
 <CAMgWh9sOw+=1ONaXQaPQTv-P3ypOHVoCShwQdrCVnB3jK4M9bA@mail.gmail.com>
 <CAMgWh9tZLDYFvSP6buewRWCKZG3NOppd5Yb8o1jvDKPbOKo9uw@mail.gmail.com>
 <CAMgWh9sJvo9TY9xLiZ4aARJ4MP17-H+vmxx-QZ1CZc6Zj4K=dA@mail.gmail.com>
 <CAMgWh9ubDFOc87W8N2PqB1oGaZu+u5wibQ9Nvin78nVDE=qkCQ@mail.gmail.com>
 <CAMgWh9vu_zJTTRMEPcs+F+Rjwy27ykmA-szG0HJdQb6O+F_Xmg@mail.gmail.com>
 <CAMgWh9uorQ5xye1kaW=jfGBR-J4tHMG7xAgpO1jLuW9RtJinDg@mail.gmail.com>
 <CAMgWh9sSH8-NUQF8Bhtkzp60sJkDE3JY9+dXnGBJk975NAKX9g@mail.gmail.com>
 <CAMgWh9suk2NmsEpdSP9a5VCr1AMDQwSgyJAJUSRwYzRd9C6bxA@mail.gmail.com>
 <CAMgWh9sn2LNH6xeRai_cLHR_XX74kyB06BXYa1+Eo7gQ7M2D0w@mail.gmail.com>
 <CAMgWh9sPXC7pqtjYDjsgJLQmYc=ewBQQtkASTcxd_r6io_VhZA@mail.gmail.com>
 <CAMgWh9teVfxgihGwP0vf1jGHKc+=viBe8vNj+Egofd_MyMjWRA@mail.gmail.com>
 <1461682542.13494.13.camel@joachim-breitner.de>
Message-ID: <CAB-d4A5dJH8EYFXyz1iwM9+t-buPDxGnC5L_6rBEFUCkRNhrtw@mail.gmail.com>

Let's fix it for the literal 2 :) Nobody worries about overflow of x * x
when x and the result are both declared Ints

On Tue, Apr 26, 2016 at 11:55 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Dienstag, den 26.04.2016, 10:33 -0400 schrieb David Feuer:
> > Fixing this goes beyond the capabilities of RULES pragmas
>
> maybe it shouln?t:
> https://ghc.haskell.org/trac/ghc/ticket/9137
> https://ghc.haskell.org/trac/ghc/ticket/9601
>
>
> Greetings,
> Joachim
>
>
> --
> Joachim ?nomeata? Breitner
>   mail at joachim-breitner.de ? https://www.joachim-breitner.de/
>   XMPP: nomeata at joachim-breitner.de ? OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> 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/20160426/5db60280/attachment.html>

From mail at joachim-breitner.de  Tue Apr 26 21:11:32 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 26 Apr 2016 23:11:32 +0200
Subject: =?UTF-8?Q?perf=2Ehaskell=2Eorg=E2=80=99s?= list of branches got
 more useful
In-Reply-To: <nfnvl7$slb$1@ger.gmane.org>
References: <1461440463.8186.9.camel@joachim-breitner.de>
 <c00ee22255e2455984941d58bcb9a05d@DB4PR30MB030.064d.mgd.msft.net>
 <1461580455.4490.10.camel@joachim-breitner.de>
 <5ed3215a33ca4fc682d11325cf8fe594@DB4PR30MB030.064d.mgd.msft.net>
 <1461668945.1781.28.camel@joachim-breitner.de> <nfnvl7$slb$1@ger.gmane.org>
Message-ID: <1461705092.16240.0.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 26.04.2016, 16:57 +0200 schrieb Bardur Arantsson:
> On 04/26/2016 01:09 PM, Joachim Breitner wrote:
> > * What does "2 days ago" mean?
> > The age of the latest commit to the branch.
> > 
> FWIW, I think adding a few simple table headings might help
> enormously.
> 
> "Last commit", "?", "Branch", "Last commit message", "Diffstat".
> 
> (or something like that.)

good idea; although often with tables space is thight, and narrow
columns don?t allow for wide enough headers.

Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
? mail at joachim-breitner.de ? https://www.joachim-breitner.de/
? XMPP: nomeata at joachim-breitner.de?? OpenPGP-Key: 0xF0FBF51F
? Debian Developer: nomeata at debian.org

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

From eric at seidel.io  Wed Apr 27 00:18:02 2016
From: eric at seidel.io (Eric Seidel)
Date: Tue, 26 Apr 2016 17:18:02 -0700
Subject: Bikeshedding request for GHCi's :type
In-Reply-To: <60D162E7-9FAE-45AE-BD22-9E1C6D6C7466@cis.upenn.edu>
References: <60D162E7-9FAE-45AE-BD22-9E1C6D6C7466@cis.upenn.edu>
Message-ID: <1461716282.3659203.590621921.763F467B@webmail.messagingengine.com>

I think design A (deeply instantiate + generalize) produces the most
sensible types. I don't know what the curly braces mean (perhaps that we
can't use type application anymore since the order changed?) but I don't
think they'd show up at all without -fprint-explicit-foralls, right? If
so, I'm not too concerned about it.

I also think 2C is a neat idea and should be explored further, but I
don't think it should be the default behavior of :type. I've always
expected :type to print the exact type we would infer for the
expression.

Perhaps instead of changing the default behavior of :type or adding new
commands, we could add a flag to enhance :type's output. For example,

  > :type mapM
  mapM :: (Monad m, Traversable t) => (a -> m b) -> t a -> m (t b)
  > :set -fprint-type-specializations
  > :type mapM
  mapM :: (Monad m, Traversable t) => (a -> m b) -> t a -> m (t b)
  Possible Specializations:
  mapM :: Monad m => (a -> m b) -> [a] -> m [b]
  mapM :: (a -> Maybe b) -> [a] -> Maybe [b]
  ...

I think this could be useful even for experienced Haskellers, though I'm
a bit concerned that printing the full type at the top will leave
beginners as bewildered as ever..

Eric

On Tue, Apr 26, 2016, at 06:08, Richard Eisenberg wrote:
> Hi devs,
> 
> Over the weekend, I was pondering the Haskell course I will be teaching
> next year and shuddered at having to teach Foldable at the same time as
> `length`. So I implemented feature request #10963
> (https://ghc.haskell.org/trac/ghc/ticket/10963), which allows for a way
> for a user to request a specialization of a type. It all works
> wonderfully, but there is a real user-facing design issue here around the
> default behavior of :type and whether or not to add new :type-y like
> commands. I have outlined the situation here:
> https://ghc.haskell.org/trac/ghc/wiki/Design/GHCi/Type
> 
> I'd love some broad input on this issue. If you've got a stake in how
> this all works, please skim that wiki page and comment on #10963.
> 
> Thanks!
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From _deepfire at feelingofgreen.ru  Wed Apr 27 03:21:20 2016
From: _deepfire at feelingofgreen.ru (Kosyrev Serge)
Date: Wed, 27 Apr 2016 06:21:20 +0300
Subject: =?utf-8?Q?perf=2Ehaskell=2Eorg=E2=80=99s?= list of branches got
 more useful
In-Reply-To: <1461705092.16240.0.camel@joachim-breitner.de>
 (sfid-20160427_014200_093783_2C9AA726) (Joachim Breitner's message of
 "Tue, 26 Apr 2016 23:11:32 +0200")
References: <1461440463.8186.9.camel@joachim-breitner.de>
 <c00ee22255e2455984941d58bcb9a05d@DB4PR30MB030.064d.mgd.msft.net>
 <1461580455.4490.10.camel@joachim-breitner.de>
 <5ed3215a33ca4fc682d11325cf8fe594@DB4PR30MB030.064d.mgd.msft.net>
 <1461668945.1781.28.camel@joachim-breitner.de>
 <nfnvl7$slb$1@ger.gmane.org>
 <1461705092.16240.0.camel@joachim-breitner.de>
Message-ID: <874manka8f.fsf@feelingofgreen.ru>

Joachim Breitner <mail at joachim-breitner.de> writes:
>> FWIW, I think adding a few simple table headings might help
>> enormously.
>> 
>> "Last commit", "?", "Branch", "Last commit message", "Diffstat".
>> 
>> (or something like that.)
>
> good idea; although often with tables space is thight, and narrow
> columns don?t allow for wide enough headers.

Just a random wild idea -- rotate text by approximately 90 degrees?

-- 
? ???????e? / respectfully,
??????? ??????

From spam at scientician.net  Wed Apr 27 03:42:25 2016
From: spam at scientician.net (Bardur Arantsson)
Date: Wed, 27 Apr 2016 05:42:25 +0200
Subject: =?UTF-8?Q?Re:_perf.haskell.org=e2=80=99s_list_of_branches_got_more_?=
 =?UTF-8?Q?useful?=
In-Reply-To: <1461705092.16240.0.camel@joachim-breitner.de>
References: <1461440463.8186.9.camel@joachim-breitner.de>
 <c00ee22255e2455984941d58bcb9a05d@DB4PR30MB030.064d.mgd.msft.net>
 <1461580455.4490.10.camel@joachim-breitner.de>
 <5ed3215a33ca4fc682d11325cf8fe594@DB4PR30MB030.064d.mgd.msft.net>
 <1461668945.1781.28.camel@joachim-breitner.de> <nfnvl7$slb$1@ger.gmane.org>
 <1461705092.16240.0.camel@joachim-breitner.de>
Message-ID: <nfpcf1$uls$1@ger.gmane.org>

On 04/26/2016 11:11 PM, Joachim Breitner wrote:
> Hi,
> 
> Am Dienstag, den 26.04.2016, 16:57 +0200 schrieb Bardur Arantsson:
>> On 04/26/2016 01:09 PM, Joachim Breitner wrote:
>>> * What does "2 days ago" mean?
>>> The age of the latest commit to the branch.
>>>
>> FWIW, I think adding a few simple table headings might help
>> enormously.
>>
>> "Last commit", "?", "Branch", "Last commit message", "Diffstat".
>>
>> (or something like that.)
> 
> good idea; although often with tables space is thight, and narrow
> columns don?t allow for wide enough headers.
> 

You can always shorten the text or use abbreviations and then add hover
text with the 'full name' of the column. Mouse hover text isn't *great*
UX-wise, but probably better than nothing. It's generally a little less
'discoverable' even if people are generally used to the idea of hover
tooltips. Additionnaly, I'm not sure how well this will work for blind
people who use screen readers.

Regards,



From mail at joachim-breitner.de  Wed Apr 27 07:11:48 2016
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 27 Apr 2016 09:11:48 +0200
Subject: =?UTF-8?Q?perf=2Ehaskell=2Eorg=E2=80=99s?= list of branches got
 more useful
In-Reply-To: <nfpcf1$uls$1@ger.gmane.org>
References: <1461440463.8186.9.camel@joachim-breitner.de>
 <c00ee22255e2455984941d58bcb9a05d@DB4PR30MB030.064d.mgd.msft.net>
 <1461580455.4490.10.camel@joachim-breitner.de>
 <5ed3215a33ca4fc682d11325cf8fe594@DB4PR30MB030.064d.mgd.msft.net>
 <1461668945.1781.28.camel@joachim-breitner.de> <nfnvl7$slb$1@ger.gmane.org>
 <1461705092.16240.0.camel@joachim-breitner.de> <nfpcf1$uls$1@ger.gmane.org>
Message-ID: <1461741108.1714.5.camel@joachim-breitner.de>

Hi,

Am Mittwoch, den 27.04.2016, 05:42 +0200 schrieb Bardur Arantsson:
> You can always shorten the text or use abbreviations and then add
> hover
> text with the 'full name' of the column. Mouse hover text isn't *great*
> UX-wise, but probably better than nothing. It's generally a little less
> 'discoverable' even if people are generally used to the idea of hover
> tooltips. Additionnaly, I'm not sure how well this will work for blind
> people who use screen readers.

I believe this is getting off topic on this list; I invite you to
continue brainstorming on?https://github.com/nomeata/gipeda/issues/37


Greetings,
Joachim

-- 
Joachim ?nomeata? Breitner
? mail at joachim-breitner.de ? https://www.joachim-breitner.de/
? XMPP: nomeata at joachim-breitner.de?? OpenPGP-Key: 0xF0FBF51F
? Debian Developer: nomeata at debian.org

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

From karel.gardas at centrum.cz  Wed Apr 27 10:50:48 2016
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Wed, 27 Apr 2016 12:50:48 +0200
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <877ffpu3ax.fsf@smart-cactus.org>
References: <877ffpu3ax.fsf@smart-cactus.org>
Message-ID: <57209988.3030608@centrum.cz>


Hi,

distros for

sparc-solaris2.11
i386-solaris2.11
x86_64-solaris2.11
powerpc64-linux
x86_64-openbsd5.9

uploaded and signed in http://uloz.to/xPKKdvtV/bindist-tar

Thanks,
Karel

On 04/22/16 04:27 PM, Ben Gamari wrote:
> tl;dr: If you would like to produce a binary distribution for GHC
>         8.0.1-rc4 then let us know, grab the source distribution and
>         start building. The binary distributions will be all released one
>         week from today.


From ben at well-typed.com  Wed Apr 27 11:33:05 2016
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 27 Apr 2016 13:33:05 +0200
Subject: GHC 8.0.1-rc4 source tarball availability
In-Reply-To: <57209988.3030608@centrum.cz>
References: <877ffpu3ax.fsf@smart-cactus.org> <57209988.3030608@centrum.cz>
Message-ID: <878tzznv66.fsf@smart-cactus.org>

Karel Gardas <karel.gardas at centrum.cz> writes:

> Hi,
>
> distros for
>
> sparc-solaris2.11
> i386-solaris2.11
> x86_64-solaris2.11
> powerpc64-linux
> x86_64-openbsd5.9
>
> uploaded and signed in http://uloz.to/xPKKdvtV/bindist-tar
>
Thanks Karel!

I've started to fetch the tarball; I'll likely announce the release
later today.

Cheers,

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

From leo at halfaya.org  Wed Apr 27 14:45:00 2016
From: leo at halfaya.org (John Leo)
Date: Wed, 27 Apr 2016 07:45:00 -0700
Subject: Bikeshedding request for GHCi's :type
In-Reply-To: <1461716282.3659203.590621921.763F467B@webmail.messagingengine.com>
References: <60D162E7-9FAE-45AE-BD22-9E1C6D6C7466@cis.upenn.edu>
 <1461716282.3659203.590621921.763F467B@webmail.messagingengine.com>
Message-ID: <CAHYM_VmaSr_3U58R-GhA6t6GccBTTj36yoMofDGsOpPmA1mv1g@mail.gmail.com>

Speaking as someone teaching his coworkers Haskell now, Eric's is the best
suggestion I've seen so far.

What I like about it:
* The original meaning of :type is unchanged.
* No new command is added (I prefer adding a flag to adding another
command).
* With the flag on, the full type is shown along with the possible
specializations (and good to note the list might not be exhaustive).  This
way, beginners can still see what the type should look like even if they
want to ignore it for now.  This is similar to learning to read Japanese by
using furigana.  It may be a bit confusing for beginners at first, but I
expect they'll quickly learn to ignore it until they need it, and I agree
it will be useful for experienced Haskellers.

John

On Tue, Apr 26, 2016 at 5:18 PM, Eric Seidel <eric at seidel.io> wrote:

> I think design A (deeply instantiate + generalize) produces the most
> sensible types. I don't know what the curly braces mean (perhaps that we
> can't use type application anymore since the order changed?) but I don't
> think they'd show up at all without -fprint-explicit-foralls, right? If
> so, I'm not too concerned about it.
>
> I also think 2C is a neat idea and should be explored further, but I
> don't think it should be the default behavior of :type. I've always
> expected :type to print the exact type we would infer for the
> expression.
>
> Perhaps instead of changing the default behavior of :type or adding new
> commands, we could add a flag to enhance :type's output. For example,
>
>   > :type mapM
>   mapM :: (Monad m, Traversable t) => (a -> m b) -> t a -> m (t b)
>   > :set -fprint-type-specializations
>   > :type mapM
>   mapM :: (Monad m, Traversable t) => (a -> m b) -> t a -> m (t b)
>   Possible Specializations:
>   mapM :: Monad m => (a -> m b) -> [a] -> m [b]
>   mapM :: (a -> Maybe b) -> [a] -> Maybe [b]
>   ...
>
> I think this could be useful even for experienced Haskellers, though I'm
> a bit concerned that printing the full type at the top will leave
> beginners as bewildered as ever..
>
> Eric
>
> On Tue, Apr 26, 2016, at 06:08, Richard Eisenberg wrote:
> > Hi devs,
> >
> > Over the weekend, I was pondering the Haskell course I will be teaching
> > next year and shuddered at having to teach Foldable at the same time as
> > `length`. So I implemented feature request #10963
> > (https://ghc.haskell.org/trac/ghc/ticket/10963), which allows for a way
> > for a user to request a specialization of a type. It all works
> > wonderfully, but there is a real user-facing design issue here around the
> > default behavior of :type and whether or not to add new :type-y like
> > commands. I have outlined the situation here:
> > https://ghc.haskell.org/trac/ghc/wiki/Design/GHCi/Type
> >
> > I'd love some broad input on this issue. If you've got a stake in how
> > this all works, please skim that wiki page and comment on #10963.
> >
> > Thanks!
> > Richard
> > _______________________________________________
> > 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/20160427/9c29c974/attachment.html>

From targen at gmail.com  Wed Apr 27 15:16:31 2016
From: targen at gmail.com (=?UTF-8?Q?Manuel_G=C3=B3mez?=)
Date: Wed, 27 Apr 2016 10:46:31 -0430
Subject: Bikeshedding request for GHCi's :type
In-Reply-To: <CAHYM_VmaSr_3U58R-GhA6t6GccBTTj36yoMofDGsOpPmA1mv1g@mail.gmail.com>
References: <60D162E7-9FAE-45AE-BD22-9E1C6D6C7466@cis.upenn.edu>
 <1461716282.3659203.590621921.763F467B@webmail.messagingengine.com>
 <CAHYM_VmaSr_3U58R-GhA6t6GccBTTj36yoMofDGsOpPmA1mv1g@mail.gmail.com>
Message-ID: <CAJWnFaNwFMxVdFXMj2b2AbF=CCCdPjQd43w4yRBckL3YpYgBRw@mail.gmail.com>

On Wed, Apr 27, 2016 at 10:15 AM, John Leo <leo at halfaya.org> wrote:
> Speaking as someone teaching his coworkers Haskell now, Eric's is the best
> suggestion I've seen so far.
>
> What I like about it:
> * The original meaning of :type is unchanged.
> * No new command is added (I prefer adding a flag to adding another
> command).
> * With the flag on, the full type is shown along with the possible
> specializations (and good to note the list might not be exhaustive).  This
> way, beginners can still see what the type should look like even if they
> want to ignore it for now.  This is similar to learning to read Japanese by
> using furigana.  It may be a bit confusing for beginners at first, but I
> expect they'll quickly learn to ignore it until they need it, and I agree it
> will be useful for experienced Haskellers.

Perhaps a pleasant solution would be to borrow a convention from the
PostgreSQL community's interactive console psql and its meta-commands:
http://www.postgresql.org/docs/current/static/app-psql.html#APP-PSQL-META-COMMANDS

For example:

> \d[S+] [ pattern ]
>
> For each [object] matching the pattern, show all columns, their types, the tablespace (if not the default) and any special attributes such as NOT NULL or defaults. [?]  The command form \d+ is identical, except that more information is displayed: any comments associated with the columns of the table are shown, as is the presence of OIDs in the table, the view definition if the relation is a view, a non-default replica identitysetting.

Many psql commands use this convention: add a + to the end of the
command, and you get extra information.  It?s quite nmemonic.

From magesh85 at gmail.com  Wed Apr 27 16:43:30 2016
From: magesh85 at gmail.com (Magesh B)
Date: Wed, 27 Apr 2016 22:13:30 +0530
Subject: Custom Type Error not getting triggered in the nested Type function
 call
Message-ID: <CA+fSYM5jTAjudX-3Ki7WcZsWmj+pdn0_Ohd4aaQT9ANtWnNLsw@mail.gmail.com>

Hello,

I have partial type function which is invoked by another type function.
When the inner type function fails with TypeError, outer type function is
not been able to propagate that type error to its caller.
As a result of it, I'm getting following error
  ? No instance for (KnownSymbol (NestedPartialTF (TypeError ...)))
 instead of
  ? Unexpected type @ NestedPartialTF: Char

Is this a bug? This behavior seems bit counter-intuitive as to work around,
I had to write another (duplicate) type function at the top level to get
the desired type error

I'm using GHC-8 RC 3 and have attached complete src for reference.

Regards,
Magesh B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160427/dd06becd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CErrs.hs
Type: text/x-haskell
Size: 1415 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160427/dd06becd/attachment.hs>

From iavor.diatchki at gmail.com  Wed Apr 27 17:22:34 2016
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 27 Apr 2016 10:22:34 -0700
Subject: Bikeshedding request for GHCi's :type
In-Reply-To: <CAJWnFaNwFMxVdFXMj2b2AbF=CCCdPjQd43w4yRBckL3YpYgBRw@mail.gmail.com>
References: <60D162E7-9FAE-45AE-BD22-9E1C6D6C7466@cis.upenn.edu>
 <1461716282.3659203.590621921.763F467B@webmail.messagingengine.com>
 <CAHYM_VmaSr_3U58R-GhA6t6GccBTTj36yoMofDGsOpPmA1mv1g@mail.gmail.com>
 <CAJWnFaNwFMxVdFXMj2b2AbF=CCCdPjQd43w4yRBckL3YpYgBRw@mail.gmail.com>
Message-ID: <CAGK9nup=jf3vLEt6bWcZMnP8fK6Dwna2Y6whj12XQX5Ei46nYQ@mail.gmail.com>

Hello Richard,

I think that `:type` should report the real type of an expressions (i.e.,
the fully generalized inferred type, just like it does now).  Certainly I
wouldn't want `:type` to show me some kind of (more or less) arbitrary
specialization of the type.

It could be useful to have a ghci command that would show all
instantiations of a class method (just 1 level deep) using the instances
that are currently in scope.  This would be essentially a combination of
`:info` on a class and a method.  For example, this is what it would look
like on some of the methods in 7.10's Prelude:

:inst length
length :: [a] -> Int
length :: Maybe a -> Int
length :: Either a b -> Int
length :: (a,b) -> Int

:inst (==)
(==) :: Integer -> Integer -> Bool
(==) :: Word -> Word -> Bool
...
(==) :: Eq a => [a] -> [a] -> Bool    -- Note that we only instantiate the
outer class
...
(==) :: (Eq a, Eq b, Eq c) => (a,b,c) -> (a,b,c) -> Bool  -- ditto

:inst mapM
mapM :: Monad m => (a -> m b) -> [a] -> m [b]
mapM :: Monad m => (a -> m b) -> Maybe a -> m (Maybe b)
mapM :: Monad m => (a -> m b) -> Either e a -> m (Either e b)
mapM :: Monad m => (a -> m b) -> (e,a) -> m (e,b)

This could be generalized to expressions, rather than just methods, but for
expressions with multiple constraints one could get an explosion of
possible instantiations.  However, it would be quite cool to allow things
like this:

:inst 1
1 :: Word
1 :: Integer
1 :: Int
1 :: Float
1 :: Double

Anyway, just some ideas.

-Iavor




















On Wed, Apr 27, 2016 at 8:16 AM, Manuel G?mez <targen at gmail.com> wrote:

> On Wed, Apr 27, 2016 at 10:15 AM, John Leo <leo at halfaya.org> wrote:
> > Speaking as someone teaching his coworkers Haskell now, Eric's is the
> best
> > suggestion I've seen so far.
> >
> > What I like about it:
> > * The original meaning of :type is unchanged.
> > * No new command is added (I prefer adding a flag to adding another
> > command).
> > * With the flag on, the full type is shown along with the possible
> > specializations (and good to note the list might not be exhaustive).
> This
> > way, beginners can still see what the type should look like even if they
> > want to ignore it for now.  This is similar to learning to read Japanese
> by
> > using furigana.  It may be a bit confusing for beginners at first, but I
> > expect they'll quickly learn to ignore it until they need it, and I
> agree it
> > will be useful for experienced Haskellers.
>
> Perhaps a pleasant solution would be to borrow a convention from the
> PostgreSQL community's interactive console psql and its meta-commands:
>
> http://www.postgresql.org/docs/current/static/app-psql.html#APP-PSQL-META-COMMANDS
>
> For example:
>
> > \d[S+] [ pattern ]
> >
> > For each [object] matching the pattern, show all columns, their types,
> the tablespace (if not the default) and any special attributes such as NOT
> NULL or defaults. [?]  The command form \d+ is identical, except that more
> information is displayed: any comments associated with the columns of the
> table are shown, as is the presence of OIDs in the table, the view
> definition if the relation is a view, a non-default replica identitysetting.
>
> Many psql commands use this convention: add a + to the end of the
> command, and you get extra information.  It?s quite nmemonic.
> _______________________________________________
> 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/20160427/cc8b1258/attachment-0001.html>

From cma at bitemyapp.com  Wed Apr 27 17:25:01 2016
From: cma at bitemyapp.com (Christopher Allen)
Date: Wed, 27 Apr 2016 12:25:01 -0500
Subject: Bikeshedding request for GHCi's :type
In-Reply-To: <CAGK9nup=jf3vLEt6bWcZMnP8fK6Dwna2Y6whj12XQX5Ei46nYQ@mail.gmail.com>
References: <60D162E7-9FAE-45AE-BD22-9E1C6D6C7466@cis.upenn.edu>
 <1461716282.3659203.590621921.763F467B@webmail.messagingengine.com>
 <CAHYM_VmaSr_3U58R-GhA6t6GccBTTj36yoMofDGsOpPmA1mv1g@mail.gmail.com>
 <CAJWnFaNwFMxVdFXMj2b2AbF=CCCdPjQd43w4yRBckL3YpYgBRw@mail.gmail.com>
 <CAGK9nup=jf3vLEt6bWcZMnP8fK6Dwna2Y6whj12XQX5Ei46nYQ@mail.gmail.com>
Message-ID: <7D3952E9-E5F8-467D-AD83-E6CD8435DC6D@bitemyapp.com>

I agree with Iavor that :type should report the real type. I see this only stymieing and frustrating efforts to teach the language.

I do like the :inst idea.

> On Apr 27, 2016, at 12:22 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> Hello Richard,
> 
> I think that `:type` should report the real type of an expressions (i.e., the fully generalized inferred type, just like it does now).  Certainly I wouldn't want `:type` to show me some kind of (more or less) arbitrary specialization of the type.
> 
> It could be useful to have a ghci command that would show all instantiations of a class method (just 1 level deep) using the instances that are currently in scope.  This would be essentially a combination of `:info` on a class and a method.  For example, this is what it would look like on some of the methods in 7.10's Prelude:
> 
> :inst length
> length :: [a] -> Int
> length :: Maybe a -> Int
> length :: Either a b -> Int
> length :: (a,b) -> Int
> 
> :inst (==)
> (==) :: Integer -> Integer -> Bool
> (==) :: Word -> Word -> Bool
> ...
> (==) :: Eq a => [a] -> [a] -> Bool    -- Note that we only instantiate the outer class
> ...
> (==) :: (Eq a, Eq b, Eq c) => (a,b,c) -> (a,b,c) -> Bool  -- ditto
> 
> :inst mapM
> mapM :: Monad m => (a -> m b) -> [a] -> m [b]
> mapM :: Monad m => (a -> m b) -> Maybe a -> m (Maybe b)
> mapM :: Monad m => (a -> m b) -> Either e a -> m (Either e b)
> mapM :: Monad m => (a -> m b) -> (e,a) -> m (e,b)
> 
> This could be generalized to expressions, rather than just methods, but for expressions with multiple constraints one could get an explosion of possible instantiations.  However, it would be quite cool to allow things like this:
> 
> :inst 1
> 1 :: Word
> 1 :: Integer
> 1 :: Int
> 1 :: Float
> 1 :: Double
> 
> Anyway, just some ideas.
> 
> -Iavor
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, Apr 27, 2016 at 8:16 AM, Manuel G?mez <targen at gmail.com <mailto:targen at gmail.com>> wrote:
> On Wed, Apr 27, 2016 at 10:15 AM, John Leo <leo at halfaya.org <mailto:leo at halfaya.org>> wrote:
> > Speaking as someone teaching his coworkers Haskell now, Eric's is the best
> > suggestion I've seen so far.
> >
> > What I like about it:
> > * The original meaning of :type is unchanged.
> > * No new command is added (I prefer adding a flag to adding another
> > command).
> > * With the flag on, the full type is shown along with the possible
> > specializations (and good to note the list might not be exhaustive).  This
> > way, beginners can still see what the type should look like even if they
> > want to ignore it for now.  This is similar to learning to read Japanese by
> > using furigana.  It may be a bit confusing for beginners at first, but I
> > expect they'll quickly learn to ignore it until they need it, and I agree it
> > will be useful for experienced Haskellers.
> 
> Perhaps a pleasant solution would be to borrow a convention from the
> PostgreSQL community's interactive console psql and its meta-commands:
> http://www.postgresql.org/docs/current/static/app-psql.html#APP-PSQL-META-COMMANDS <http://www.postgresql.org/docs/current/static/app-psql.html#APP-PSQL-META-COMMANDS>
> 
> For example:
> 
> > \d[S+] [ pattern ]
> >
> > For each [object] matching the pattern, show all columns, their types, the tablespace (if not the default) and any special attributes such as NOT NULL or defaults. [?]  The command form \d+ is identical, except that more information is displayed: any comments associated with the columns of the table are shown, as is the presence of OIDs in the table, the view definition if the relation is a view, a non-default replica identitysetting.
> 
> Many psql commands use this convention: add a + to the end of the
> command, and you get extra information.  It?s quite nmemonic.
> _______________________________________________
> 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
> 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/20160427/8e84a4ec/attachment.html>

From iavor.diatchki at gmail.com  Wed Apr 27 17:34:10 2016
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Wed, 27 Apr 2016 10:34:10 -0700
Subject: Custom Type Error not getting triggered in the nested Type
 function call
In-Reply-To: <CA+fSYM5jTAjudX-3Ki7WcZsWmj+pdn0_Ohd4aaQT9ANtWnNLsw@mail.gmail.com>
References: <CA+fSYM5jTAjudX-3Ki7WcZsWmj+pdn0_Ohd4aaQT9ANtWnNLsw@mail.gmail.com>
Message-ID: <CAGK9nuoZBkn9BF2HXad6yuM0HT+yE+krjBfeMAWdWLxSqd=LQA@mail.gmail.com>

Hi,

yes, this looks like a bug.  Could you please file a report on the
bug-tracker?

-Iavor

On Wed, Apr 27, 2016 at 9:43 AM, Magesh B <magesh85 at gmail.com> wrote:

> Hello,
>
> I have partial type function which is invoked by another type function.
> When the inner type function fails with TypeError, outer type function is
> not been able to propagate that type error to its caller.
> As a result of it, I'm getting following error
>   ? No instance for (KnownSymbol (NestedPartialTF (TypeError ...)))
>  instead of
>   ? Unexpected type @ NestedPartialTF: Char
>
> Is this a bug? This behavior seems bit counter-intuitive as to work
> around, I had to write another (duplicate) type function at the top level
> to get the desired type error
>
> I'm using GHC-8 RC 3 and have attached complete src for reference.
>
> Regards,
> Magesh B
>
> _______________________________________________
> 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/20160427/6432b9ff/attachment.html>

From simonpj at microsoft.com  Wed Apr 27 20:36:59 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 27 Apr 2016 20:36:59 +0000
Subject: Every GHC-compiled program seg-fault (HEAD)
Message-ID: <c111352e2d3244e6869630da63ce2c39@DB4PR30MB030.064d.mgd.msft.net>

Does anyone feel able to look at
https://ghc.haskell.org/trac/ghc/ticket/11988
The symptom is that every single GHC-compiled binary now seg-faults on Windows (with HEAD).
That?s pretty serious.
Can Travis pinpoint the offending commit?
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160427/0b71c2d7/attachment-0001.html>

From austin at well-typed.com  Wed Apr 27 21:40:20 2016
From: austin at well-typed.com (Austin Seipp)
Date: Wed, 27 Apr 2016 16:40:20 -0500
Subject: Every GHC-compiled program seg-fault (HEAD)
In-Reply-To: <c111352e2d3244e6869630da63ce2c39@DB4PR30MB030.064d.mgd.msft.net>
References: <c111352e2d3244e6869630da63ce2c39@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAEs96n2sxWrgNFDdwMmUu_LFNZORa0JeNkgEp0AapeFsiap-ng@mail.gmail.com>

Travis can't build on Windows, I'm afraid.

I'm sort of mitigating another crisis right now, but here's a shot in
the dark - based on my Very Amazing Deductive Skills[1], completed in
mere seconds, I'm guessing that perhaps
e68195a96529cf1cc2d9cc6a9bc05183fce5ecea is relevant, one of Simon's
latest commits? e.g., just try, as a shot in the dark

$ git revert e68195a96529cf1cc2d9cc6a9bc05183fce5ecea

And build again.

[1] Note: my Very Amazing Deductive Skills in this case, are as
follows. Look at git log for the last few days. See that some C code
was changed. Immediately become suspicious that is the culprit,
because it's C code. So, yes, a complete shot in the dark, but it's
one that's served me well, too. :)

On Wed, Apr 27, 2016 at 3:36 PM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> Does anyone feel able to look at
>
> https://ghc.haskell.org/trac/ghc/ticket/11988
>
> The symptom is that every single GHC-compiled binary now seg-faults on
> Windows (with HEAD).
>
> That?s pretty serious.
>
> Can Travis pinpoint the offending commit?
>
> Simon



-- 
Regards,

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

From allbery.b at gmail.com  Wed Apr 27 22:38:52 2016
From: allbery.b at gmail.com (Brandon Allbery)
Date: Wed, 27 Apr 2016 18:38:52 -0400
Subject: better improvement for nm-classic message?
Message-ID: <CAKFCL4XYbbw-JOU_s_yXLG18mZqDRO_JCKmB8btv14wvnZnH8Q@mail.gmail.com>

It's slower the first time it is run but should be fast afterward unless
you switch active Xcode toolchains, as xcrun caches the result.

    --with-nm=$(xcrun --find nm-classic)

-- 
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/20160427/e9b7d83f/attachment.html>

From ben at smart-cactus.org  Thu Apr 28 08:07:59 2016
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 28 Apr 2016 10:07:59 +0200
Subject: better improvement for nm-classic message?
In-Reply-To: <CAKFCL4XYbbw-JOU_s_yXLG18mZqDRO_JCKmB8btv14wvnZnH8Q@mail.gmail.com>
References: <CAKFCL4XYbbw-JOU_s_yXLG18mZqDRO_JCKmB8btv14wvnZnH8Q@mail.gmail.com>
Message-ID: <87y47yma00.fsf@smart-cactus.org>

Brandon Allbery <allbery.b at gmail.com> writes:

> It's slower the first time it is run but should be fast afterward unless
> you switch active Xcode toolchains, as xcrun caches the result.
>
>     --with-nm=$(xcrun --find nm-classic)
>
Ahh, perfect! Thanks!

Cheers,

- Ben

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

From ben at well-typed.com  Thu Apr 28 09:10:13 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 28 Apr 2016 11:10:13 +0200
Subject: [ANNOUNCE] GHC 8.0.1 release candidate 4 available
Message-ID: <87wpnim74a.fsf@smart-cactus.org>


Hello Haskellers,

The GHC team is happy to announce the availability of fourth release
candidate of the Glasgow Haskell Compiler's 8.0.1 release. Source and
binary distributions can be found at,

    http://downloads.haskell.org/~ghc/8.0.1-rc4/

This is the last of four candidates leading up to the 8.0.1 release,
addressing nearly all of the known issues of the previous candidates.
These include,

  * A type-checker panic triggered by use of Typeable on a
    kind-polymorphic type constructor (#11334)

  * A type-checker explosion where -XTypeInType would gobble up massive
    amounts of memory when used in a data instance (#11407)

  * A variety of other typechecker issues (#11811, #11797, #11813,
    #11814)

  * A build issue seen on OS X (#11828)

  * Template Haskell can now produce instances with
    OVERLAPP{ING,ABLE,ED} pragmas

  * Autoconf has improved version checks for libdw (#11820)

  * Typeable and hs-boot files now interact nicely (#11824)

  * The build system now checks for the broken Apple `nm` utility
    (#11823, #11744)

  * Various issues involving unexpected laziness resulting in exception
    handlers not being invoked (#11555)

  * GHC now fails more gracefully when used with an older cabal-install
    release (#11558)

  * TypeInType now has proper documentation in the users guide (#11614)

  * The story surrounding type `RuntimeRep`s (formerly known as
    `Levity`) is now far better developed, closing several doors to
    unsafe behavior that TypeInType previously opened (#11473, #11723)

  * A long-standing bug in the constant-folding rules for `mod` for the
    `Word` type has been resolved (#11702)

  * Various issues introduced by OverloadedRecordFields have been fixed
    (#11662, #11401) 

  * A regression in the typechecker resulting in the rejection of code
    in the `free` and `microlens` packages has been fixed (#11608)

  * A bug in the LLVM code generator which caused some programs to emit
    unbuildable LLVM IR has been fixed (#11649)

  * A bug where pattern synonyms defined in terms of a pattern match on
    a record would be rejected if the fields weren't written in the same order
    as they were defined has been resolved (#11633)

  * A bug in the runtime system's treatment of weak references which
    could result in segmentation faults in some cases has been fixed (#11108)

  * a variety of optimizations improving compiler performance have been
    merged

  * and many others

Mac OS X users should be aware that the recent XCode 7.3 release ships
with a broken `nm` utility which breaks the GHC build (#11744, #11823).
The build system will check for this condition and request that the tree
is configured to use the `nm-classic` utility if found. OS X users
running XCode 7.3 are encouraged to open a ticket with Apple so that
this issue may be fixed in future XCode releases.

If no major issues pop up we expect that this will be the last release
candidate before the final release, which we hope to push out in the
coming weeks. Thanks to everyone who has contributed code, testing,
builds, and bug reports thusfar!

Cheers and happy testing,

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

From johannes.waldmann at htwk-leipzig.de  Thu Apr 28 12:24:41 2016
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Thu, 28 Apr 2016 14:24:41 +0200
Subject: Bikeshedding request for GHCi's :type
Message-ID: <57220109.2070500@htwk-leipzig.de>

> .. :type should report the real type

What about defaulting? Is it real?
https://ghc.haskell.org/trac/ghc/ticket/11994

- J.W.

From iavor.diatchki at gmail.com  Thu Apr 28 15:00:29 2016
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 28 Apr 2016 08:00:29 -0700
Subject: Bikeshedding request for GHCi's :type
In-Reply-To: <57220109.2070500@htwk-leipzig.de>
References: <57220109.2070500@htwk-leipzig.de>
Message-ID: <CAGK9nuqiZf686siHpi5GG9dkiUbC8T99LZX5hYuqzmybH94e9A@mail.gmail.com>

Currently GHCi shows the "real" type of an expression (i.e., the inferred
generalized type), when you ask it:

Prelude> :t 1
1 :: Num a => a

Note that there is no defaulting happening, at least at the top level---of
course if there were local things that needed to be defaulted while the
expression was being type-checked then those would be defaulted.

If you ask GHCi to *evaluate* a polymorphic expression, then it will try to
default the type when it is figuring out how to show the result.  The
alternative would be to say "sorry, I can't evaluate this, because it is
polymorphic, so please tell me what type do you mean".  This is probably a
bit too inconvenient for practical use.

-Iavor




On Thu, Apr 28, 2016 at 5:24 AM, Johannes Waldmann <
johannes.waldmann at htwk-leipzig.de> wrote:

> > .. :type should report the real type
>
> What about defaulting? Is it real?
> https://ghc.haskell.org/trac/ghc/ticket/11994
>
> - J.W.
> _______________________________________________
> 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/20160428/f6370b98/attachment.html>

From johannes.waldmann at htwk-leipzig.de  Thu Apr 28 15:05:29 2016
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Thu, 28 Apr 2016 17:05:29 +0200
Subject: Bikeshedding request for GHCi's :type
In-Reply-To: <CAGK9nuqiZf686siHpi5GG9dkiUbC8T99LZX5hYuqzmybH94e9A@mail.gmail.com>
References: <57220109.2070500@htwk-leipzig.de>
 <CAGK9nuqiZf686siHpi5GG9dkiUbC8T99LZX5hYuqzmybH94e9A@mail.gmail.com>
Message-ID: <572226B9.6040006@htwk-leipzig.de>

Hi,

> If you ask GHCi to *evaluate* a polymorphic expression, then it will ...

Sure, I understand the motivation for defaulting,
and I am not suggesting to change anything there.

What I am saying is that I see no way to have ghci show
* the defaulted type,
* or the even the fact that defaulting did happen.

- J.


From carter.schonwald at gmail.com  Thu Apr 28 15:46:16 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 28 Apr 2016 11:46:16 -0400
Subject: Draft 8.0 Mac build directions
Message-ID: <CE46F136-D75F-40B2-BCFA-1CB9F9656A5B@gmail.com>

Hey all: 
I've drafted some hopefully cleaner Mac build directions and I'd love some feedback on them 

Nb: I think I forgot to mention the cabal install hscolour step, I'll add that 

-Carter

From simonpj at microsoft.com  Thu Apr 28 21:02:40 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 28 Apr 2016 21:02:40 +0000
Subject: Reverted your commit
Message-ID: <51758a8890d144768304409f4aa0398c@DB4PR30MB030.064d.mgd.msft.net>

Simon
I reverted your commit
https://phabricator.haskell.org/rGHC546f24e4f8a7c086b1e5afcdda624176610cbcf8
because it made every single binary that GHC builds seg-fault on windows.  Even
                main = return ()
seg-faults.
You may want to review and re-commit it.
Simon

commit 24864ba5587c1a0447beabae90529e8bb4fa117a
Author: Simon Marlow <marlowsd at gmail.com>
Date:   Sat Apr 23 22:14:43 2016 +0100
    Use __builtin_clz() to implement log_2()
        A microoptimisation in the block allocator.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160428/a87cc65d/attachment.html>

From ben at well-typed.com  Thu Apr 28 21:16:21 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 28 Apr 2016 23:16:21 +0200
Subject: Reverted your commit
In-Reply-To: <51758a8890d144768304409f4aa0398c@DB4PR30MB030.064d.mgd.msft.net>
References: <51758a8890d144768304409f4aa0398c@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <87twilmo2i.fsf@smart-cactus.org>

Simon Peyton Jones <simonpj at microsoft.com> writes:

> Simon
> I reverted your commit
> https://phabricator.haskell.org/rGHC546f24e4f8a7c086b1e5afcdda624176610cbcf8
> because it made every single binary that GHC builds seg-fault on windows.  Even
>                 main = return ()
> seg-faults.

It looks like Nathan Howell has a solution here. See D2157 [1].

Cheers,

- Ben


[1] https://phabricator.haskell.org/D2157
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160428/d616619a/attachment-0001.sig>

From simonpj at microsoft.com  Thu Apr 28 22:09:04 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 28 Apr 2016 22:09:04 +0000
Subject: Windows link failure
Message-ID: <b695334246914342ab95a1f103826b70@DB4PR30MB030.064d.mgd.msft.net>

   OK Windows is back.  But all these fail with this error
Stderr:
/bin/sh: cc: command not found
make[3]: *** [t_11223_simple_unused_duplicate_lib] Error 127
Simon
rts/T11223             T11223_link_order_a_b_2_fail [bad exit code] (normal)
   rts/T11223             T11223_link_order_a_b_succeed [bad exit code] (normal)
   rts/T11223             T11223_link_order_b_a_2_succeed [bad exit code] (normal)
   rts/T11223             T11223_link_order_b_a_succeed [bad exit code] (normal)
   rts/T11223             T11223_simple_duplicate_lib [bad exit code] (normal)
   rts/T11223             T11223_simple_link [bad exit code] (normal)
   rts/T11223             T11223_simple_link_lib [bad exit code] (normal)
   rts/T11223             T11223_simple_unused_duplicate_lib [bad exit code] (normal)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160428/f70c7896/attachment.html>

From austin at well-typed.com  Thu Apr 28 22:12:06 2016
From: austin at well-typed.com (Austin Seipp)
Date: Thu, 28 Apr 2016 17:12:06 -0500
Subject: Windows link failure
In-Reply-To: <b695334246914342ab95a1f103826b70@DB4PR30MB030.064d.mgd.msft.net>
References: <b695334246914342ab95a1f103826b70@DB4PR30MB030.064d.mgd.msft.net>
Message-ID: <CAEs96n3x2wCaM3yyyxDuRX06LiGKeLhXsQnw+SHxJQgS+WXuLQ@mail.gmail.com>

This seems to be a problem with the T11223 Makefile, which inconsistently sets:

GCC=gcc

and uses $(GCC) in some places, but only "$(CC)" in another, which
Make will default to "CC=cc"

Patch incoming.

On Thu, Apr 28, 2016 at 5:09 PM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
>    OK Windows is back.  But all these fail with this error
>
> Stderr:
>
> /bin/sh: cc: command not found
>
> make[3]: *** [t_11223_simple_unused_duplicate_lib] Error 127
>
> Simon
>
> rts/T11223             T11223_link_order_a_b_2_fail [bad exit code] (normal)
>
>    rts/T11223             T11223_link_order_a_b_succeed [bad exit code]
> (normal)
>
>    rts/T11223             T11223_link_order_b_a_2_succeed [bad exit code]
> (normal)
>
>    rts/T11223             T11223_link_order_b_a_succeed [bad exit code]
> (normal)
>
>    rts/T11223             T11223_simple_duplicate_lib [bad exit code]
> (normal)
>
>    rts/T11223             T11223_simple_link [bad exit code] (normal)
>
>    rts/T11223             T11223_simple_link_lib [bad exit code] (normal)
>
>    rts/T11223             T11223_simple_unused_duplicate_lib [bad exit code]
> (normal)
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Regards,

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

From austin at well-typed.com  Thu Apr 28 22:23:38 2016
From: austin at well-typed.com (Austin Seipp)
Date: Thu, 28 Apr 2016 17:23:38 -0500
Subject: Windows link failure
In-Reply-To: <CAEs96n3x2wCaM3yyyxDuRX06LiGKeLhXsQnw+SHxJQgS+WXuLQ@mail.gmail.com>
References: <b695334246914342ab95a1f103826b70@DB4PR30MB030.064d.mgd.msft.net>
 <CAEs96n3x2wCaM3yyyxDuRX06LiGKeLhXsQnw+SHxJQgS+WXuLQ@mail.gmail.com>
Message-ID: <CAEs96n1Rcm_DTKs+0Xp66XTDsCN6eQMjQES5dkdzt47vUi4Jpg@mail.gmail.com>

D2158

On Thu, Apr 28, 2016 at 5:12 PM, Austin Seipp <austin at well-typed.com> wrote:
> This seems to be a problem with the T11223 Makefile, which inconsistently sets:
>
> GCC=gcc
>
> and uses $(GCC) in some places, but only "$(CC)" in another, which
> Make will default to "CC=cc"
>
> Patch incoming.
>
> On Thu, Apr 28, 2016 at 5:09 PM, Simon Peyton Jones
> <simonpj at microsoft.com> wrote:
>>    OK Windows is back.  But all these fail with this error
>>
>> Stderr:
>>
>> /bin/sh: cc: command not found
>>
>> make[3]: *** [t_11223_simple_unused_duplicate_lib] Error 127
>>
>> Simon
>>
>> rts/T11223             T11223_link_order_a_b_2_fail [bad exit code] (normal)
>>
>>    rts/T11223             T11223_link_order_a_b_succeed [bad exit code]
>> (normal)
>>
>>    rts/T11223             T11223_link_order_b_a_2_succeed [bad exit code]
>> (normal)
>>
>>    rts/T11223             T11223_link_order_b_a_succeed [bad exit code]
>> (normal)
>>
>>    rts/T11223             T11223_simple_duplicate_lib [bad exit code]
>> (normal)
>>
>>    rts/T11223             T11223_simple_link [bad exit code] (normal)
>>
>>    rts/T11223             T11223_simple_link_lib [bad exit code] (normal)
>>
>>    rts/T11223             T11223_simple_unused_duplicate_lib [bad exit code]
>> (normal)
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/



-- 
Regards,

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

From carter.schonwald at gmail.com  Thu Apr 28 22:24:23 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 28 Apr 2016 18:24:23 -0400
Subject: Draft 8.0 Mac build directions
In-Reply-To: <CE46F136-D75F-40B2-BCFA-1CB9F9656A5B@gmail.com>
References: <CE46F136-D75F-40B2-BCFA-1CB9F9656A5B@gmail.com>
Message-ID: <CAHYVw0x_bNzRJDu3TqnBDHi__Y50DY_2e1Jq7XgaMGKjZ2VyxA@mail.gmail.com>

Woops forgot to link them this morning

https://gist.github.com/cartazio/32038db09222a2aac767cb5c03b406c6

Feedback would be appreciated.
And still need to mention cabal install hscolour :)

Pardon the noise and feedback would be appreciated!

On Thursday, April 28, 2016, Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> Hey all:
> I've drafted some hopefully cleaner Mac build directions and I'd love some
> feedback on them
>
> Nb: I think I forgot to mention the cabal install hscolour step, I'll add
> that
>
> -Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160428/3e23c173/attachment.html>

From george.colpitts at gmail.com  Thu Apr 28 23:25:45 2016
From: george.colpitts at gmail.com (George Colpitts)
Date: Thu, 28 Apr 2016 23:25:45 +0000
Subject: Draft 8.0 Mac build directions
In-Reply-To: <CAHYVw0x_bNzRJDu3TqnBDHi__Y50DY_2e1Jq7XgaMGKjZ2VyxA@mail.gmail.com>
References: <CE46F136-D75F-40B2-BCFA-1CB9F9656A5B@gmail.com>
 <CAHYVw0x_bNzRJDu3TqnBDHi__Y50DY_2e1Jq7XgaMGKjZ2VyxA@mail.gmail.com>
Message-ID: <CAB-d4A6VRoafjvasayCmwYK5NTC=BjLa=ONWoScGAPpQ4w0DjA@mail.gmail.com>

Thanks for working on this!

fwiw, my comments:


   1. It would be good to provide a link to the current doc so we can
   compare with that.
   2. Steps 12, 13, 14 and 15 are only necessary if you are building from
    a fresh git checkout, not necessary if  you're building from source tree
   tarball from a release candidate , right?
   3. If your path is set so that the gcc you want  to use is one it
   specifies than you don't need either of the two (!!) step 16s, at least in
   my experience.
   4. For step 17, in my experience, I don't have to use --with-gcc ....
   For with-nm the best way to specify is as Brandon wrote --with-nm=$(xcrun
   --find nm-classic)
   5. After either 18 or 19 it would probably be good to mention the option
   of doing sudo make install

Thanks for jumping on this, the old doc definitely needs updating

Cheers
George

On Thu, Apr 28, 2016 at 7:24 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> Woops forgot to link them this morning
>
> https://gist.github.com/cartazio/32038db09222a2aac767cb5c03b406c6
>
> Feedback would be appreciated.
> And still need to mention cabal install hscolour :)
>
> Pardon the noise and feedback would be appreciated!
>
> On Thursday, April 28, 2016, Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>
>> Hey all:
>> I've drafted some hopefully cleaner Mac build directions and I'd love
>> some feedback on them
>>
>> Nb: I think I forgot to mention the cabal install hscolour step, I'll add
>> that
>>
>> -Carter
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160428/9376f8ba/attachment-0001.html>

From austin at well-typed.com  Thu Apr 28 23:54:19 2016
From: austin at well-typed.com (Austin Seipp)
Date: Thu, 28 Apr 2016 18:54:19 -0500
Subject: Windows link failure
In-Reply-To: <CAEs96n1Rcm_DTKs+0Xp66XTDsCN6eQMjQES5dkdzt47vUi4Jpg@mail.gmail.com>
References: <b695334246914342ab95a1f103826b70@DB4PR30MB030.064d.mgd.msft.net>
 <CAEs96n3x2wCaM3yyyxDuRX06LiGKeLhXsQnw+SHxJQgS+WXuLQ@mail.gmail.com>
 <CAEs96n1Rcm_DTKs+0Xp66XTDsCN6eQMjQES5dkdzt47vUi4Jpg@mail.gmail.com>
Message-ID: <CAEs96n2TYzhXkxLPDJCNcOP3Of15gtg-jdujDx6W9RF9kjAsGw@mail.gmail.com>

This is in HEAD now, so please try again and I think that'll get you
up and running, Simon.

On Thu, Apr 28, 2016 at 5:23 PM, Austin Seipp <austin at well-typed.com> wrote:
> D2158
>
> On Thu, Apr 28, 2016 at 5:12 PM, Austin Seipp <austin at well-typed.com> wrote:
>> This seems to be a problem with the T11223 Makefile, which inconsistently sets:
>>
>> GCC=gcc
>>
>> and uses $(GCC) in some places, but only "$(CC)" in another, which
>> Make will default to "CC=cc"
>>
>> Patch incoming.
>>
>> On Thu, Apr 28, 2016 at 5:09 PM, Simon Peyton Jones
>> <simonpj at microsoft.com> wrote:
>>>    OK Windows is back.  But all these fail with this error
>>>
>>> Stderr:
>>>
>>> /bin/sh: cc: command not found
>>>
>>> make[3]: *** [t_11223_simple_unused_duplicate_lib] Error 127
>>>
>>> Simon
>>>
>>> rts/T11223             T11223_link_order_a_b_2_fail [bad exit code] (normal)
>>>
>>>    rts/T11223             T11223_link_order_a_b_succeed [bad exit code]
>>> (normal)
>>>
>>>    rts/T11223             T11223_link_order_b_a_2_succeed [bad exit code]
>>> (normal)
>>>
>>>    rts/T11223             T11223_link_order_b_a_succeed [bad exit code]
>>> (normal)
>>>
>>>    rts/T11223             T11223_simple_duplicate_lib [bad exit code]
>>> (normal)
>>>
>>>    rts/T11223             T11223_simple_link [bad exit code] (normal)
>>>
>>>    rts/T11223             T11223_simple_link_lib [bad exit code] (normal)
>>>
>>>    rts/T11223             T11223_simple_unused_duplicate_lib [bad exit code]
>>> (normal)
>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>
>>
>>
>> --
>> Regards,
>>
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>
>
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/



-- 
Regards,

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

From carter.schonwald at gmail.com  Fri Apr 29 00:22:18 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 28 Apr 2016 20:22:18 -0400
Subject: Draft 8.0 Mac build directions
In-Reply-To: <CAB-d4A6VRoafjvasayCmwYK5NTC=BjLa=ONWoScGAPpQ4w0DjA@mail.gmail.com>
References: <CE46F136-D75F-40B2-BCFA-1CB9F9656A5B@gmail.com>
 <CAHYVw0x_bNzRJDu3TqnBDHi__Y50DY_2e1Jq7XgaMGKjZ2VyxA@mail.gmail.com>
 <CAB-d4A6VRoafjvasayCmwYK5NTC=BjLa=ONWoScGAPpQ4w0DjA@mail.gmail.com>
Message-ID: <CAHYVw0wL0gzhdP14a45sVSDfHD1qemJ-=yJbbU-pWp6faaJbWw@mail.gmail.com>

1) done

2) steps 12,13,15 are specific to git checkout,  step 14 is still
necessary!
a) hyperlinked-source is not enabled by default for the boot libs and ghc
source, which is AMAZING to have
b) buliding the pdf version of the user guide isn't enabled by default
c)  if you have gmp lib somewhere installled in userland, ghc will by
default pick that instead of doing in tree gmp, and on mac if you want to
share you executables, that a no go!
d) unrelatedly, it seems that ghc build no longer includes the haddock
manual in html/pdf form as it used to

3/4)  i think we shouldn't make any assumptions about the path and what
gcc/clang is where / shows up first, or at least that choice should be
explicit :),  good point on the --with-nm idea

5) i prefer not mentioning sudo ever in directions, and i actually these
days install my various ghc versions into paths like
~/.install-ghc/$GHCVERSION :),  and certain prefixes may or may not be
locked down on recent osx it seems :)

On Thu, Apr 28, 2016 at 7:25 PM, George Colpitts <george.colpitts at gmail.com>
wrote:

> Thanks for working on this!
>
> fwiw, my comments:
>
>
>    1. It would be good to provide a link to the current doc so we can
>    compare with that.
>    2. Steps 12, 13, 14 and 15 are only necessary if you are building from
>     a fresh git checkout, not necessary if  you're building from source tree
>    tarball from a release candidate , right?
>    3. If your path is set so that the gcc you want  to use is one it
>    specifies than you don't need either of the two (!!) step 16s, at least in
>    my experience.
>    4. For step 17, in my experience, I don't have to use --with-gcc ....
>    For with-nm the best way to specify is as Brandon wrote --with-nm=$(xcrun
>    --find nm-classic)
>    5. After either 18 or 19 it would probably be good to mention the
>    option of doing sudo make install
>
> Thanks for jumping on this, the old doc definitely needs updating
>
> Cheers
> George
>
> On Thu, Apr 28, 2016 at 7:24 PM Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> Woops forgot to link them this morning
>>
>> https://gist.github.com/cartazio/32038db09222a2aac767cb5c03b406c6
>>
>> Feedback would be appreciated.
>> And still need to mention cabal install hscolour :)
>>
>> Pardon the noise and feedback would be appreciated!
>>
>> On Thursday, April 28, 2016, Carter Schonwald <carter.schonwald at gmail.com>
>> wrote:
>>
>>> Hey all:
>>> I've drafted some hopefully cleaner Mac build directions and I'd love
>>> some feedback on them
>>>
>>> Nb: I think I forgot to mention the cabal install hscolour step, I'll
>>> add that
>>>
>>> -Carter
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160428/e3b342e4/attachment.html>

From carter.schonwald at gmail.com  Fri Apr 29 00:24:56 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 28 Apr 2016 20:24:56 -0400
Subject: Draft 8.0 Mac build directions
In-Reply-To: <CAHYVw0wL0gzhdP14a45sVSDfHD1qemJ-=yJbbU-pWp6faaJbWw@mail.gmail.com>
References: <CE46F136-D75F-40B2-BCFA-1CB9F9656A5B@gmail.com>
 <CAHYVw0x_bNzRJDu3TqnBDHi__Y50DY_2e1Jq7XgaMGKjZ2VyxA@mail.gmail.com>
 <CAB-d4A6VRoafjvasayCmwYK5NTC=BjLa=ONWoScGAPpQ4w0DjA@mail.gmail.com>
 <CAHYVw0wL0gzhdP14a45sVSDfHD1qemJ-=yJbbU-pWp6faaJbWw@mail.gmail.com>
Message-ID: <CAHYVw0xy9xZyx9oZw2u-B8oUnTS6p-wCZW3-GMnZag=5et8Lqg@mail.gmail.com>

i also added mention of invoking ulimit before make to work around a
current bug in haddock resource usage when generating hyperlinked-source
files for all of ghc :)

On Thu, Apr 28, 2016 at 8:22 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> 1) done
>
> 2) steps 12,13,15 are specific to git checkout,  step 14 is still
> necessary!
> a) hyperlinked-source is not enabled by default for the boot libs and ghc
> source, which is AMAZING to have
> b) buliding the pdf version of the user guide isn't enabled by default
> c)  if you have gmp lib somewhere installled in userland, ghc will by
> default pick that instead of doing in tree gmp, and on mac if you want to
> share you executables, that a no go!
> d) unrelatedly, it seems that ghc build no longer includes the haddock
> manual in html/pdf form as it used to
>
> 3/4)  i think we shouldn't make any assumptions about the path and what
> gcc/clang is where / shows up first, or at least that choice should be
> explicit :),  good point on the --with-nm idea
>
> 5) i prefer not mentioning sudo ever in directions, and i actually these
> days install my various ghc versions into paths like
> ~/.install-ghc/$GHCVERSION :),  and certain prefixes may or may not be
> locked down on recent osx it seems :)
>
> On Thu, Apr 28, 2016 at 7:25 PM, George Colpitts <
> george.colpitts at gmail.com> wrote:
>
>> Thanks for working on this!
>>
>> fwiw, my comments:
>>
>>
>>    1. It would be good to provide a link to the current doc so we can
>>    compare with that.
>>    2. Steps 12, 13, 14 and 15 are only necessary if you are building
>>    from  a fresh git checkout, not necessary if  you're building from source
>>    tree tarball from a release candidate , right?
>>    3. If your path is set so that the gcc you want  to use is one it
>>    specifies than you don't need either of the two (!!) step 16s, at least in
>>    my experience.
>>    4. For step 17, in my experience, I don't have to use --with-gcc ....
>>    For with-nm the best way to specify is as Brandon wrote --with-nm=$(xcrun
>>    --find nm-classic)
>>    5. After either 18 or 19 it would probably be good to mention the
>>    option of doing sudo make install
>>
>> Thanks for jumping on this, the old doc definitely needs updating
>>
>> Cheers
>> George
>>
>> On Thu, Apr 28, 2016 at 7:24 PM Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> Woops forgot to link them this morning
>>>
>>> https://gist.github.com/cartazio/32038db09222a2aac767cb5c03b406c6
>>>
>>> Feedback would be appreciated.
>>> And still need to mention cabal install hscolour :)
>>>
>>> Pardon the noise and feedback would be appreciated!
>>>
>>> On Thursday, April 28, 2016, Carter Schonwald <
>>> carter.schonwald at gmail.com> wrote:
>>>
>>>> Hey all:
>>>> I've drafted some hopefully cleaner Mac build directions and I'd love
>>>> some feedback on them
>>>>
>>>> Nb: I think I forgot to mention the cabal install hscolour step, I'll
>>>> add that
>>>>
>>>> -Carter
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160428/a7757306/attachment.html>

From takenobu.hs at gmail.com  Fri Apr 29 05:17:36 2016
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Fri, 29 Apr 2016 14:17:36 +0900
Subject: [ANNOUNCE] GHC 8.0.1 release candidate 4 available
In-Reply-To: <87wpnim74a.fsf@smart-cactus.org>
References: <87wpnim74a.fsf@smart-cactus.org>
Message-ID: <CAPB_Nvy1_7FzfDHGq7Hi-NjuM4to=euTaMv8SZU3MHaJK0rpuA@mail.gmail.com>

Hi Ben, Richard and GHC team,

I appreciate your great effort.
The rc4 simply represents `$` type in ghci.

  $ ./ghcii.sh
  GHCi, version 8.0.0.20160421: http://www.haskell.org/ghc/  :? for help
  Prelude> :t ($)
  ($) :: (a -> b) -> a -> b

Newcomers may love it :)

Thank you very much,
Takenobu


2016-04-28 18:10 GMT+09:00 Ben Gamari <ben at well-typed.com>:

>
> Hello Haskellers,
>
> The GHC team is happy to announce the availability of fourth release
> candidate of the Glasgow Haskell Compiler's 8.0.1 release. Source and
> binary distributions can be found at,
>
>     http://downloads.haskell.org/~ghc/8.0.1-rc4/
>
> This is the last of four candidates leading up to the 8.0.1 release,
> addressing nearly all of the known issues of the previous candidates.
> These include,
>
>   * A type-checker panic triggered by use of Typeable on a
>     kind-polymorphic type constructor (#11334)
>
>   * A type-checker explosion where -XTypeInType would gobble up massive
>     amounts of memory when used in a data instance (#11407)
>
>   * A variety of other typechecker issues (#11811, #11797, #11813,
>     #11814)
>
>   * A build issue seen on OS X (#11828)
>
>   * Template Haskell can now produce instances with
>     OVERLAPP{ING,ABLE,ED} pragmas
>
>   * Autoconf has improved version checks for libdw (#11820)
>
>   * Typeable and hs-boot files now interact nicely (#11824)
>
>   * The build system now checks for the broken Apple `nm` utility
>     (#11823, #11744)
>
>   * Various issues involving unexpected laziness resulting in exception
>     handlers not being invoked (#11555)
>
>   * GHC now fails more gracefully when used with an older cabal-install
>     release (#11558)
>
>   * TypeInType now has proper documentation in the users guide (#11614)
>
>   * The story surrounding type `RuntimeRep`s (formerly known as
>     `Levity`) is now far better developed, closing several doors to
>     unsafe behavior that TypeInType previously opened (#11473, #11723)
>
>   * A long-standing bug in the constant-folding rules for `mod` for the
>     `Word` type has been resolved (#11702)
>
>   * Various issues introduced by OverloadedRecordFields have been fixed
>     (#11662, #11401)
>
>   * A regression in the typechecker resulting in the rejection of code
>     in the `free` and `microlens` packages has been fixed (#11608)
>
>   * A bug in the LLVM code generator which caused some programs to emit
>     unbuildable LLVM IR has been fixed (#11649)
>
>   * A bug where pattern synonyms defined in terms of a pattern match on
>     a record would be rejected if the fields weren't written in the same
> order
>     as they were defined has been resolved (#11633)
>
>   * A bug in the runtime system's treatment of weak references which
>     could result in segmentation faults in some cases has been fixed
> (#11108)
>
>   * a variety of optimizations improving compiler performance have been
>     merged
>
>   * and many others
>
> Mac OS X users should be aware that the recent XCode 7.3 release ships
> with a broken `nm` utility which breaks the GHC build (#11744, #11823).
> The build system will check for this condition and request that the tree
> is configured to use the `nm-classic` utility if found. OS X users
> running XCode 7.3 are encouraged to open a ticket with Apple so that
> this issue may be fixed in future XCode releases.
>
> If no major issues pop up we expect that this will be the last release
> candidate before the final release, which we hope to push out in the
> coming weeks. Thanks to everyone who has contributed code, testing,
> builds, and bug reports thusfar!
>
> Cheers and happy testing,
>
> - Ben
>
> _______________________________________________
> 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/20160429/392f8993/attachment-0001.html>

From simonpj at microsoft.com  Fri Apr 29 07:18:01 2016
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 29 Apr 2016 07:18:01 +0000
Subject: Windows link failure
In-Reply-To: <CAEs96n2TYzhXkxLPDJCNcOP3Of15gtg-jdujDx6W9RF9kjAsGw@mail.gmail.com>
References: <b695334246914342ab95a1f103826b70@DB4PR30MB030.064d.mgd.msft.net>
 <CAEs96n3x2wCaM3yyyxDuRX06LiGKeLhXsQnw+SHxJQgS+WXuLQ@mail.gmail.com>
 <CAEs96n1Rcm_DTKs+0Xp66XTDsCN6eQMjQES5dkdzt47vUi4Jpg@mail.gmail.com>
 <CAEs96n2TYzhXkxLPDJCNcOP3Of15gtg-jdujDx6W9RF9kjAsGw@mail.gmail.com>
Message-ID: <3229d8a418f04254bead83a569e6beb2@DB4PR30MB030.064d.mgd.msft.net>

Thanks everyone!

SImon

|  -----Original Message-----
|  From: mad.one at gmail.com [mailto:mad.one at gmail.com] On Behalf Of Austin
|  Seipp
|  Sent: 29 April 2016 00:54
|  To: Austin Seipp <austin at well-typed.com>
|  Cc: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs at haskell.org
|  Subject: Re: Windows link failure
|  
|  This is in HEAD now, so please try again and I think that'll get you up
|  and running, Simon.
|  
|  On Thu, Apr 28, 2016 at 5:23 PM, Austin Seipp <austin at well-typed.com>
|  wrote:
|  > D2158
|  >
|  > On Thu, Apr 28, 2016 at 5:12 PM, Austin Seipp <austin at well-typed.com>
|  wrote:
|  >> This seems to be a problem with the T11223 Makefile, which
|  inconsistently sets:
|  >>
|  >> GCC=gcc
|  >>
|  >> and uses $(GCC) in some places, but only "$(CC)" in another, which
|  >> Make will default to "CC=cc"
|  >>
|  >> Patch incoming.
|  >>
|  >> On Thu, Apr 28, 2016 at 5:09 PM, Simon Peyton Jones
|  >> <simonpj at microsoft.com> wrote:
|  >>>    OK Windows is back.  But all these fail with this error
|  >>>
|  >>> Stderr:
|  >>>
|  >>> /bin/sh: cc: command not found
|  >>>
|  >>> make[3]: *** [t_11223_simple_unused_duplicate_lib] Error 127
|  >>>
|  >>> Simon
|  >>>
|  >>> rts/T11223             T11223_link_order_a_b_2_fail [bad exit code]
|  (normal)
|  >>>
|  >>>    rts/T11223             T11223_link_order_a_b_succeed [bad exit
|  code]
|  >>> (normal)
|  >>>
|  >>>    rts/T11223             T11223_link_order_b_a_2_succeed [bad exit
|  code]
|  >>> (normal)
|  >>>
|  >>>    rts/T11223             T11223_link_order_b_a_succeed [bad exit
|  code]
|  >>> (normal)
|  >>>
|  >>>    rts/T11223             T11223_simple_duplicate_lib [bad exit
|  code]
|  >>> (normal)
|  >>>
|  >>>    rts/T11223             T11223_simple_link [bad exit code]
|  (normal)
|  >>>
|  >>>    rts/T11223             T11223_simple_link_lib [bad exit code]
|  (normal)
|  >>>
|  >>>    rts/T11223             T11223_simple_unused_duplicate_lib [bad
|  exit code]
|  >>> (normal)
|  >>>
|  >>>
|  >>> _______________________________________________
|  >>> 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=01%7c01%
|  >>>
|  7csimonpj%40064d.mgd.microsoft.com%7c02077003388f4824c54d08d36fc06ab
|  >>>
|  c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=qsd2U5uw%2fw39T5lEITa
|  >>> PuGYbY56jLZM3PvJLdEYjdfE%3d
|  >>>
|  >>
|  >>
|  >>
|  >> --
|  >> Regards,
|  >>
|  >> Austin Seipp, Haskell Consultant
|  >> Well-Typed LLP,
|  >>
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.w
|  >> ell-
|  typed.com%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c02
|  >>
|  077003388f4824c54d08d36fc06abc%7c72f988bf86f141af91ab2d7cd011db47%7c1
|  >> &sdata=zpfpVWiEPsWFKVZBv7QEJ6rXBsx%2fivSW4CmSdFaA8eo%3d
|  >
|  >
|  >
|  > --
|  > Regards,
|  >
|  > Austin Seipp, Haskell Consultant
|  > Well-Typed LLP,
|  >
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.we
|  > ll-
|  typed.com%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c0207
|  >
|  7003388f4824c54d08d36fc06abc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sd
|  > ata=zpfpVWiEPsWFKVZBv7QEJ6rXBsx%2fivSW4CmSdFaA8eo%3d
|  
|  
|  
|  --
|  Regards,
|  
|  Austin Seipp, Haskell Consultant
|  Well-Typed LLP,
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.wel
|  l-
|  typed.com%2f&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c02077003
|  388f4824c54d08d36fc06abc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=z
|  pfpVWiEPsWFKVZBv7QEJ6rXBsx%2fivSW4CmSdFaA8eo%3d

From adam at sandbergericsson.se  Fri Apr 29 08:58:14 2016
From: adam at sandbergericsson.se (Adam Sandberg Eriksson)
Date: Fri, 29 Apr 2016 10:58:14 +0200
Subject: Draft 8.0 Mac build directions
In-Reply-To: <CAHYVw0xy9xZyx9oZw2u-B8oUnTS6p-wCZW3-GMnZag=5et8Lqg@mail.gmail.com>
References: <CE46F136-D75F-40B2-BCFA-1CB9F9656A5B@gmail.com>
 <CAHYVw0x_bNzRJDu3TqnBDHi__Y50DY_2e1Jq7XgaMGKjZ2VyxA@mail.gmail.com>
 <CAB-d4A6VRoafjvasayCmwYK5NTC=BjLa=ONWoScGAPpQ4w0DjA@mail.gmail.com>
 <CAHYVw0wL0gzhdP14a45sVSDfHD1qemJ-=yJbbU-pWp6faaJbWw@mail.gmail.com>
 <CAHYVw0xy9xZyx9oZw2u-B8oUnTS6p-wCZW3-GMnZag=5et8Lqg@mail.gmail.com>
Message-ID: <4C76C1A7-49F7-4860-B9FA-A714963723ED@sandbergericsson.se>

Do we really need hscolour when using haddock with --hyperlinked-source?

Also, a section on building for development (which is what I believe the current instructions are aimed at) would be nice!

I very much welcome this clean up!

Cheers,
Adam

> On 29 Apr 2016, at 02:24, Carter Schonwald <carter.schonwald at gmail.com> wrote:
> 
> i also added mention of invoking ulimit before make to work around a current bug in haddock resource usage when generating hyperlinked-source files for all of ghc :) 
> 
> On Thu, Apr 28, 2016 at 8:22 PM, Carter Schonwald <carter.schonwald at gmail.com> wrote:
> 1) done
> 
> 2) steps 12,13,15 are specific to git checkout,  step 14 is still necessary! 
> a) hyperlinked-source is not enabled by default for the boot libs and ghc source, which is AMAZING to have
> b) buliding the pdf version of the user guide isn't enabled by default 
> c)  if you have gmp lib somewhere installled in userland, ghc will by default pick that instead of doing in tree gmp, and on mac if you want to share you executables, that a no go! 
> d) unrelatedly, it seems that ghc build no longer includes the haddock manual in html/pdf form as it used to
> 
> 3/4)  i think we shouldn't make any assumptions about the path and what gcc/clang is where / shows up first, or at least that choice should be explicit :),  good point on the --with-nm idea
> 
> 5) i prefer not mentioning sudo ever in directions, and i actually these days install my various ghc versions into paths like ~/.install-ghc/$GHCVERSION :),  and certain prefixes may or may not be locked down on recent osx it seems :) 
> 
> On Thu, Apr 28, 2016 at 7:25 PM, George Colpitts <george.colpitts at gmail.com> wrote:
> Thanks for working on this!
> 
> fwiw, my comments:
> 
> 	? It would be good to provide a link to the current doc so we can compare with that.
> 	? Steps 12, 13, 14 and 15 are only necessary if you are building from  a fresh git checkout, not necessary if  you're building from source tree tarball from a release candidate , right?
> 	? If your path is set so that the gcc you want  to use is one it specifies than you don't need either of the two (!!) step 16s, at least in my experience.
> 	? For step 17, in my experience, I don't have to use --with-gcc .... For with-nm the best way to specify is as Brandon wrote --with-nm=$(xcrun --find nm-classic)
> 	? After either 18 or 19 it would probably be good to mention the option of doing sudo make install
> Thanks for jumping on this, the old doc definitely needs updating
> 
> Cheers
> George
> 
> On Thu, Apr 28, 2016 at 7:24 PM Carter Schonwald <carter.schonwald at gmail.com> wrote:
> Woops forgot to link them this morning 
> 
> https://gist.github.com/cartazio/32038db09222a2aac767cb5c03b406c6
> 
> Feedback would be appreciated. 
> And still need to mention cabal install hscolour :)
> 
> Pardon the noise and feedback would be appreciated! 
> 
> On Thursday, April 28, 2016, Carter Schonwald <carter.schonwald at gmail.com> wrote:
> Hey all:
> I've drafted some hopefully cleaner Mac build directions and I'd love some feedback on them
> 
> Nb: I think I forgot to mention the cabal install hscolour step, I'll add that
> 
> -Carter
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From juhpetersen at gmail.com  Fri Apr 29 09:12:38 2016
From: juhpetersen at gmail.com (Jens Petersen)
Date: Fri, 29 Apr 2016 18:12:38 +0900
Subject: [ANNOUNCE] GHC 8.0.1 release candidate 4 available
In-Reply-To: <87wpnim74a.fsf@smart-cactus.org>
References: <87wpnim74a.fsf@smart-cactus.org>
Message-ID: <CAEDGBqKR5FHi1ov84ygyJO4862+EvHicF+3qN5ELuuFDs_5nYQ@mail.gmail.com>

On 28 April 2016 at 18:10, Ben Gamari <ben at well-typed.com> wrote:
> The GHC team is happy to announce the availability of fourth release
> candidate of the Glasgow Haskell Compiler's 8.0.1 release.

Thank you!  I almost finished the Fedora/RHEL building in time in my
Fedora Copr repo:

https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.1/

Jens

From carter.schonwald at gmail.com  Fri Apr 29 12:26:00 2016
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 29 Apr 2016 08:26:00 -0400
Subject: Draft 8.0 Mac build directions
In-Reply-To: <4C76C1A7-49F7-4860-B9FA-A714963723ED@sandbergericsson.se>
References: <CE46F136-D75F-40B2-BCFA-1CB9F9656A5B@gmail.com>
 <CAHYVw0x_bNzRJDu3TqnBDHi__Y50DY_2e1Jq7XgaMGKjZ2VyxA@mail.gmail.com>
 <CAB-d4A6VRoafjvasayCmwYK5NTC=BjLa=ONWoScGAPpQ4w0DjA@mail.gmail.com>
 <CAHYVw0wL0gzhdP14a45sVSDfHD1qemJ-=yJbbU-pWp6faaJbWw@mail.gmail.com>
 <CAHYVw0xy9xZyx9oZw2u-B8oUnTS6p-wCZW3-GMnZag=5et8Lqg@mail.gmail.com>
 <4C76C1A7-49F7-4860-B9FA-A714963723ED@sandbergericsson.se>
Message-ID: <CAHYVw0xLS6OssVYHdTj-VnhoZwv1YCd_Cd2249jMgU42UVbrWA@mail.gmail.com>

Dev work flows are more complicated depending on the goal and sub system.
And I've slightly more practice with erring on the side of release style
builds.

Erikd gave some good suggestions that the build steps should be turned on a
s self contained script or make file so that its more robust against bit
rot, so I'll look into it this weekend.

On Friday, April 29, 2016, Adam Sandberg Eriksson <adam at sandbergericsson.se>
wrote:

> Do we really need hscolour when using haddock with --hyperlinked-source?
>
> Also, a section on building for development (which is what I believe the
> current instructions are aimed at) would be nice!
>
> I very much welcome this clean up!
>
> Cheers,
> Adam
>
> > On 29 Apr 2016, at 02:24, Carter Schonwald <carter.schonwald at gmail.com
> <javascript:;>> wrote:
> >
> > i also added mention of invoking ulimit before make to work around a
> current bug in haddock resource usage when generating hyperlinked-source
> files for all of ghc :)
> >
> > On Thu, Apr 28, 2016 at 8:22 PM, Carter Schonwald <
> carter.schonwald at gmail.com <javascript:;>> wrote:
> > 1) done
> >
> > 2) steps 12,13,15 are specific to git checkout,  step 14 is still
> necessary!
> > a) hyperlinked-source is not enabled by default for the boot libs and
> ghc source, which is AMAZING to have
> > b) buliding the pdf version of the user guide isn't enabled by default
> > c)  if you have gmp lib somewhere installled in userland, ghc will by
> default pick that instead of doing in tree gmp, and on mac if you want to
> share you executables, that a no go!
> > d) unrelatedly, it seems that ghc build no longer includes the haddock
> manual in html/pdf form as it used to
> >
> > 3/4)  i think we shouldn't make any assumptions about the path and what
> gcc/clang is where / shows up first, or at least that choice should be
> explicit :),  good point on the --with-nm idea
> >
> > 5) i prefer not mentioning sudo ever in directions, and i actually these
> days install my various ghc versions into paths like
> ~/.install-ghc/$GHCVERSION :),  and certain prefixes may or may not be
> locked down on recent osx it seems :)
> >
> > On Thu, Apr 28, 2016 at 7:25 PM, George Colpitts <
> george.colpitts at gmail.com <javascript:;>> wrote:
> > Thanks for working on this!
> >
> > fwiw, my comments:
> >
> >       ? It would be good to provide a link to the current doc so we can
> compare with that.
> >       ? Steps 12, 13, 14 and 15 are only necessary if you are building
> from  a fresh git checkout, not necessary if  you're building from source
> tree tarball from a release candidate , right?
> >       ? If your path is set so that the gcc you want  to use is one it
> specifies than you don't need either of the two (!!) step 16s, at least in
> my experience.
> >       ? For step 17, in my experience, I don't have to use --with-gcc
> .... For with-nm the best way to specify is as Brandon wrote
> --with-nm=$(xcrun --find nm-classic)
> >       ? After either 18 or 19 it would probably be good to mention the
> option of doing sudo make install
> > Thanks for jumping on this, the old doc definitely needs updating
> >
> > Cheers
> > George
> >
> > On Thu, Apr 28, 2016 at 7:24 PM Carter Schonwald <
> carter.schonwald at gmail.com <javascript:;>> wrote:
> > Woops forgot to link them this morning
> >
> > https://gist.github.com/cartazio/32038db09222a2aac767cb5c03b406c6
> >
> > Feedback would be appreciated.
> > And still need to mention cabal install hscolour :)
> >
> > Pardon the noise and feedback would be appreciated!
> >
> > On Thursday, April 28, 2016, Carter Schonwald <
> carter.schonwald at gmail.com <javascript:;>> wrote:
> > Hey all:
> > I've drafted some hopefully cleaner Mac build directions and I'd love
> some feedback on them
> >
> > Nb: I think I forgot to mention the cabal install hscolour step, I'll
> add that
> >
> > -Carter
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org <javascript:;>
> > 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/20160429/fc3a4476/attachment.html>

From trevor at galois.com  Fri Apr 29 15:30:42 2016
From: trevor at galois.com (Trevor Elliott)
Date: Fri, 29 Apr 2016 15:30:42 +0000
Subject: Bikeshedding request for GHCi's :type
In-Reply-To: <572226B9.6040006@htwk-leipzig.de>
References: <57220109.2070500@htwk-leipzig.de>
 <CAGK9nuqiZf686siHpi5GG9dkiUbC8T99LZX5hYuqzmybH94e9A@mail.gmail.com>
 <572226B9.6040006@htwk-leipzig.de>
Message-ID: <CA+093x+s9kws11gsOBoHyZPFgqs7+dyAnqdxikx8PJYwWxYy9w@mail.gmail.com>

Hi,

Part of what you would like is already there. If you run ghci with -Wall,
you will get warnings about defaulting polymorphic expressions.

```
Prelude> 1

<interactive>:2:1: Warning:
    Defaulting the following constraint(s) to type ?Integer?
      (Num a0) arising from a use of ?it? at <interactive>:2:1
      (Show a0) arising from a use of ?print? at <interactive>:2:1
    In the first argument of ?print?, namely ?it?
    In a stmt of an interactive GHCi command: print it
1
Prelude>
```

--trevor

On Thu, Apr 28, 2016 at 8:05 AM Johannes Waldmann <
johannes.waldmann at htwk-leipzig.de> wrote:

> Hi,
>
> > If you ask GHCi to *evaluate* a polymorphic expression, then it will ...
>
> Sure, I understand the motivation for defaulting,
> and I am not suggesting to change anything there.
>
> What I am saying is that I see no way to have ghci show
> * the defaulted type,
> * or the even the fact that defaulting did happen.
>
> - J.
>
> _______________________________________________
> 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/20160429/2dc199d9/attachment.html>

From thomasmiedema at gmail.com  Sat Apr 30 08:19:52 2016
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Sat, 30 Apr 2016 10:19:52 +0200
Subject: Testsuite change: CLEANUP=1 is now the default
Message-ID: <CAD3WKgipNah-C33XMOueuL0CoOXQTW0v0Evj1=G-5VH9zMnv_w@mail.gmail.com>

Hello devs,

by popular request (#9758), the testsuite will now clean up after itself
after running the tests, removing generated files, saving you some 10G of
diskspace in the worst case. If you want the old behavior back, you can do:

```
$ make test CLEANUP=0
```

I updated
https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running.

The cleaning itself is not perfect at the moment; some temporary files are
not deleted. I have a solution for this in
https://ghc.haskell.org/trac/ghc/ticket/11980 and
https://phabricator.haskell.org/D1187. More about that later.

Cheers,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160430/958c9f5f/attachment.html>

From ben at well-typed.com  Thu Apr 21 19:20:01 2016
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 21 Apr 2016 19:20:01 -0000
Subject: [Action Needed] Document your work for the Haskell Communities and
 Activities Report
Message-ID: <87inza69vo.fsf@smart-cactus.org>

TL;DR. If you see your name in one of the two lists below, please edit
       the entries for your contributions to 8.0 and plans for 8.2 in
       the 2016 GHC HCAR report [1]. The deadline is in a few short
       weeks so act soon!


Hello GHC people,

As you might know, it's that time of the year where we have an
opportunity to reflect on the past and future strides taken by our
glorious compiler in GHC's Haskell Communities and Activities Report
submission [1]. We have had lots of great work go in to the imminent
8.0.1 release; let's make sure the community knows about it. Currently
listed is,

    Adam Gundry              Record system improvements
    Adam Sandberg Eriksson   Strict pragma
    Duncan Coutts            Environment files?
    Edward Z. Yang           Backpack improvements
    Eric Seidel              Implicit callstacks
    Eric de Casto Lopo       ARM support
    George Karachalias       Pattern match checker rewrite
    Herbert V. Riedel        AIX support
    Jan Stolarek             Injective type families
    Richard Eisenberg        Visible type application, kind equalities
    Ryan Scott               Improved Generics, DerivingLift
    Sergei Trofimovich       Portability
    Simon Marlow             Applicative do syntax, external GHCi
    Tamar Christina          Windows improvements

While Austin and I have done our best to stub out these entries, we need
your help to fill in the details. If you see your name in this list
please look at the current draft [1] and add what you can. Also, if you
see anything missing from this list please let us know or, better yet,
add an entry to the submission yourself.

Also, if you are planning on including any major changes in the 8.2
release, please add an entry to the "upcoming plans" section. As far as
I know at very least the following people should have interesting things
to share,

    Andrew Farmer            Profiler improvements
    Andrey Mokhov            Shake build system
    Austin Seipp             LLVM backend
    Bartosz Nikita           Deterministic compilation
    Core Libs Committee      Core libraries changes
    Edward Yang              Backpack, Compact regions
    Giovanni Campagna        Compact regions
    Simon Marlow             Various things I'm sure
    Ömer Sinan Ağacan        Unboxed sums, unpacking sum types

Again, if you know of someone not on this list who is considering
contributing to 8.2 please have them add their item to the report.

If there is any way that Austin or I can help don't hesitate to reach
out.

Thanks for your contributions over the last year!

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/wiki/Status/May16
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160421/03253f00/attachment-0001.sig>