Shared data type for extension flags

#10820 on Trac [1] and D1200 on Phabricator [2] discuss adding the capababilty to Template Haskell to detect which language extensions enabled. Unfortunately, since template-haskell can't depend on ghc (as ghc depends on template-haskell), it can't simply re-export the ExtensionFlag type from

Re: Shared data type for extension flags

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 creating their own enumeration. On Wed, Sep 2, 2015 at 9:47 AM,

Re: Shared data type for extension flags

That sounds like a good approach. Are there other things that would go nicely in a shared package like this, in addition to the extension data type? On Wed, Sep 2, 2015 at 1:00 AM, Matthew Pickering < matthewtpicker...@gmail.com> wrote: > Surely the easiest way here (including for other tooling

Re: [Haskell] ETA on 7.10.3?

Sorry, I dropped the ball on creating a ticket. I just did so: https://ghc.haskell.org/trac/ghc/ticket/10829 (As an aside, the original ticket, #10528, had a milestone set as 7.10.3, so I just assumed a 7.10.3 was planned and coming soon.) On Wed, Sep 2, 2015 at 7:43 AM, Simon Peyton Jones

Re: Shared data type for extension flags

The package description for that is "The GHC compiler's view of the GHC package database format", and this doesn't really have to do with the package database format. Would it be okay to put this in there anyway? On Wed, Sep 2, 2015, 07:33 Simon Peyton Jones wrote: > we

Re: more releases

I think some of my idea was misunderstood here: my goal was to have quick releases only from the stable branch. The goal would not be to release the new and shiny, but instead to get bugfixes out to users quicker. The new and shiny (master) would remain as it is now. In other words: more users

Re: more releases

Richard Eisenberg writes: > I think some of my idea was misunderstood here: my goal was to have > quick releases only from the stable branch. The goal would not be to > release the new and shiny, but instead to get bugfixes out to users > quicker. The new and shiny (master)

Re: Proposal: accept pull requests on GitHub

I like Niklas's suggestion of a middle-ground approach. There are benefits to using phabricator (and arc), but there should be a lowered-bar approach where people can start contributing through github (even though they may be forced to do the code review on phabricator). On Tue, Sep 1, 2015 at

Re: Shared data type for extension flags

I don't know about the entire AST. GHC's AST contains a lot of complexity that one wouldn't want to expose at the TH level. And the separation allows GHC to change the internal AST around while maintaining a stable interface for packages depending on TH. That said, there are some bits that I

Re: HEADS UP: interface file format change, full rebuild required

A long time coming. Congratulations! On Wed, Sep 2, 2015 at 10:57 PM, Jan Stolarek wrote: > I just pushed injective type families patch, which changes interface file > format. Full rebuild of > GHC is required after you pull. > > Jan > >

HEADS UP: interface file format change, full rebuild required

I just pushed injective type families patch, which changes interface file format. Full rebuild of GHC is required after you pull. Jan ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal: accept pull requests on GitHub

(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 associated costs for everyone, the benefits aren't really clear, and I think it obscures

Re: Proposal: accept pull requests on GitHub

On Wed, Sep 2, 2015 at 9:41 PM, Austin Seipp wrote: > - Make it clear what we expect of contributors. I feel like a lot of > this could be explained by having a 5 minute drive-by guide for > patches, and then a longer 10-minute guide about A) How to style > things, B)

Re: Shared data type for extension flags

Would this be a feasible approach for harmonising the AST between GHC and TH too? Alan On 2 Sep 2015 09:27, "Michael Smith" wrote: > The package description for that is "The GHC compiler's view of the GHC > package database format", and this doesn't really have to do with

Testsuite and validate changes

All, I made the following changes today: * `make accept` now runs all tests for a single way (instead of all ways) * `make test` now runs all tests for a single way (instead of all ways) * `./validate` now runs all tests for a single way (instead of skipping some tests) * Phabricator now runs

Re: Proposal: accept pull requests on GitHub

Simon Marlow writes: > On 01/09/2015 11:34, Thomas Miedema wrote: >> Hello all, >> >> my arguments against Phabricator are here: >> https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator. > > Thanks for taking the time to summarize all the issues. > > Personally, I think

Re: Proposal: accept pull requests on GitHub

On Wed, Sep 2, 2015 at 8:51 PM, Simon Marlow wrote: > Stacks of commits are hard to reviewers to follow, so making them > easier might have a detrimental effect on our processes. It might > feel better for the author, but discovering what changed between two > branches of

Re: Proposal: accept pull requests on GitHub

On 02/09/15 22:42, Kosyrev Serge wrote: > As a wild idea -- did anyone look at /Gitlab/ instead? Hi, yes. It does not currently have a sufficient review functionality (cannot handle multiple revisions easily). On 02/09/15 20:51, Simon Marlow wrote: > It might feel better > for the author, but

Foreign calls and periodic alarm signals

TL;DR: Does 'foreign import safe' silence the periodic alarm signals? I received a report on this rather strange bug in 'directory': https://github.com/haskell/directory/issues/35#issuecomment-136890912 I've concluded based on the dtruss log that it's caused by the timer signal that the GHC

Re: more releases

Richard Eisenberg writes: > On Sep 1, 2015, at 12:01 AM, Herbert Valerio Riedel > wrote: > >> I'd say mostly organisational overhead which can't be fully automated >> (afaik, Ben has already automated large parts but not everything can be): >> >> -

Re: more releases

On 2015-09-02 at 12:43:57 +0200, Ben Gamari wrote: [...] > The question is whether users want more rapid releases. Those working on > GHC will use their own builds. Most users want something reasonably > stable (in both the interface sense and the reliability sense) and > therefore I suspect

RE: Shared data type for extension flags

we already have such a shared library, I think: bin-package-db. would that do? Simon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Michael Smith Sent: 02 September 2015 09:21 To: Matthew Pickering Cc: GHC developers Subject: Re: Shared data type for extension flags That

RE: [Haskell] ETA on 7.10.3?

Ah, well https://github.com/ku-fpg/hermit/issues/144#issuecomment-128762767 links in turn to https://github.com/ku-fpg/hermit/issues/141, which is a long thread I can't follow. Ryan, Andy: if 7.10.2 is unusable for you, for some reason, please make a ticket to explain why, and ask for 7.10.3.