Re: more releases

I have the impression (no data to back it up, though) that no small number of users download bindists (because most OS packages are out of date: Debian Unstable is still on 7.8.4, as is Ubuntu Wily; Arch is on 7.10.1). On Wed, Sep 2, 2015 at 12:04 PM, Ben Gamari wrote: >

Fwd: RE: D1182: Implement improved error messages for ambiguous type variables (#10733)

It's certainly true that hsig is in flux, but it doesn't seem like injective type families should have broken this test. I'll take a look. Edward Excerpts from Simon Peyton Jones's message of 2015-09-03 09:08:23 -0700: > Edward > > | Jan's injective type families commit is causing tcfail220 to

Re: D1182: Implement improved error messages for ambiguous type variables (#10733)

On 03/09/2015 09:08, Simon Peyton Jones wrote: Edward | Jan's injective type families commit is causing tcfail220 to fail, but | that's unrelated to this ticket. This is true. I told Jan to commit anyway because tcfail220 is a "hsig" test, and a) I know that hsigs are in flux (although I

Re: RE: D1182: Implement improved error messages for ambiguous type variables (#10733)

The bug is trigger by Maybe now being a wired-in type. See https://phabricator.haskell.org/D1208 for a workaround. On Thu, Sep 3, 2015 at 6:13 PM, Edward Z. Yang wrote: > It's certainly true that hsig is in flux, but it doesn't seem like > injective type families should have

Re: Shared data type for extension flags

On 2015-09-02 at 10:00:40 +0200, Matthew Pickering wrote: > Surely the easiest way here (including for other tooling - ie > haskell-src-exts) is to create a package which just provides this > enumeration. GHC, cabal, th, haskell-src-exts and so on then all > depend on this package rather than

RE: D1182: Implement improved error messages for ambiguous type variables (#10733)

Edward | Jan's injective type families commit is causing tcfail220 to fail, but | that's unrelated to this ticket. This is true. I told Jan to commit anyway because tcfail220 is a "hsig" test, and a) I know that hsigs are in flux (although I am not clear about how) b) I don't understand them

Re: Using GHC API to compile Haskell file

Hello Neil, Sorry about the delay; I hadn't gotten around to seeing if I could reproduce it. Here is a working copy of the program which appears to work with GHC 7.10.2 on 64-bit Windows: module Main where import GHC import GHC.Paths ( libdir ) import DynFlags import SysTools main = do

Re: Shared data type for extension flags

On Thu, Sep 3, 2015 at 12:41 PM, Herbert Valerio Riedel wrote: > On 2015-09-02 at 10:00:40 +0200, Matthew Pickering wrote: > > Surely the easiest way here (including for other tooling - ie > > haskell-src-exts) is to create a package which just provides this > > enumeration.

Re: D1182: Implement improved error messages for ambiguous type variables (#10733)

> In general we shouldn't commit anything that breaks validate, because > this causes problems for other developers. The right thing to do would > be to mark it expect_broken before committing. Sorry for that. I was actually thinking about marking the test as expect_broken, but then the problem

Re: RE: D1182: Implement improved error messages for ambiguous type variables (#10733)

Thanks Thomas, I think this workaround is fine. Excerpts from Thomas Miedema's message of 2015-09-03 09:17:35 -0700: > The bug is trigger by Maybe now being a wired-in type. See > https://phabricator.haskell.org/D1208 for a workaround. > > On Thu, Sep 3, 2015 at 6:13 PM, Edward Z. Yang

addTopDecls restrictions

Hi Geoff, The TH addTopDecls function is restricted to only a few kinds of declarations (functions, mostly). This set has been expanded in #10486 (https://ghc.haskell.org/trac/ghc/ticket/10486). Do you remember why the set of allowed declarations is restricted? It looks to me like any

Re: Proposal: accept pull requests on GitHub

> As a wild idea -- did anyone look at /Gitlab/ instead? My personal experience with Gitlab at a previous job is that it is extremely unstable. I'd say even more unstable than trac and phabricator. It's especially bad when dealing with long files. ___

Re: Proposal: accept pull requests on GitHub

> > The real hint is that "the number of contributions will go up". That's > a noble goal and I think it's at the heart of this proposal. > It's not. What's at the heart of my proposal is that `arc` sucks. Most of those quotes I posted are from regular contributors (here's another one: "arcanist

Re: Proposal: accept pull requests on GitHub

On 03/09/2015 10:53, Thomas Miedema wrote: The real hint is that "the number of contributions will go up". That's a noble goal and I think it's at the heart of this proposal. When you're going to require contributors to use a non-standard tool to get patches to your code review

Re: Proposal: accept pull requests on GitHub

On Thu, Sep 3, 2015 at 12:43 PM, Vincent Hanquez wrote: > there's (probably) lots of small/janitorial contributions that do not need > the full power of phabricator or any sophisticated code review. > Austin's point, and I agree, is that we shouldn't optimize the system for

Re: [Diffusion] [Committed] rGHCbe0ce8718ea4: Fix for crash in setnumcapabilities001

Simon, for what it's worth, I sporadically (< once per month) see this test timing out on Phabricator. Latest occurence: https://phabricator.haskell.org/harbormaster/build/5904/?l=0 Thomas On Fri, Jun 26, 2015 at 10:32 AM, simonmar (Simon Marlow) < nore...@phabricator.haskell.org> wrote: >

Re: UNS: Re: Proposal: accept pull requests on GitHub

Joe Hillenbrand writes: >> As a wild idea -- did anyone look at /Gitlab/ instead? > > My personal experience with Gitlab at a previous job is that it is > extremely unstable. I'd say even more unstable than trac and > phabricator. It's especially bad when dealing with long

Re: Foreign calls and periodic alarm signals

On 02/09/2015 15:42, Phil Ruffwind wrote: TL;DR: Does 'foreign import safe' silence the periodic alarm signals? No it doesn't. Perhaps the fact that a safe FFI call may create another worker thread means that the timer signal has gone to the other thread and didn't interrupt the thread

Re: Proposal: accept pull requests on GitHub

On Thu, Sep 3, 2015 at 6:41 AM, Austin Seipp wrote: > (JFYI: I hate to announce my return with a giant novel of > negative-nancy-ness about a proposal that just came up. I'm sorry > about this!) > > TL;DR: I'm strongly -1 on this, because I think it introduces a lot > of

Re: Proposal: accept pull requests on GitHub

On 09/03/2015 09:18 AM, Joe Hillenbrand wrote: >> As a wild idea -- did anyone look at /Gitlab/ instead? > > My personal experience with Gitlab at a previous job is that it is > extremely unstable. I'd say even more unstable than trac and > phabricator. It's especially bad when dealing with long

Re: A process for reporting security-sensitive issues

On 03/09/15 08:22, Michael Smith wrote: > I feel there should be some process for reporting security-sensitive issues > in GHC -- for example, #9562 and #10826 in Trac. Perhaps something like the > SensitiveTicketsPlugin [3] could be used? > > [1] https://ghc.haskell.org/trac/ghc/ticket/9562 >