Re: release timing

+1 for the API Annotations patches. On Tue, May 5, 2015 at 11:26 AM, Alan Kim Zimmerman alan.z...@gmail.com wrote: I'd love to see the various queued API Annotations diffs go in. Alan On Tue, May 5, 2015 at 12:16 PM, Roman Cheplyaka r...@ro-che.info wrote: I'd love to see GHC 7.10.2 once

Re: Record syntax for pattern synonyms

Thank you for your comments Richard. I'm assuming `pattern Foo{bar, baz} = (bar, baz)` from the wiki page, without any further pattern type signature. This example then looks straightforward to me -- I feel I'm missing the subtlety. `foo` would get the type `(a,b) - (b,b)` and would be

Re: [GHC] #9868: ghc: panic! Dynamic linker not initialised

I can't reproduce this with 7.10.2. On Wed, Aug 12, 2015 at 4:54 PM, GHC ghc-devs@haskell.org wrote: #9868: ghc: panic! Dynamic linker not initialised -+- Reporter: Jamedjo | Owner:

Re: Record syntax for pattern synonyms

The patch now validates at D1152. https://phabricator.haskell.org/D1152 On Tue, Aug 11, 2015 at 11:26 PM, Matthew Pickering matthewtpicker...@gmail.com wrote: Thank you for your comments Richard. I'm assuming `pattern Foo{bar, baz} = (bar, baz)` from the wiki page, without any further

Record syntax for pattern synonyms

I was looking at implementing #8582 but before I got too far I thought it best to clear up a few design points. A summary can be found below and a more fleshed out version with some examples can be found on the wiki page[1]. My main question is about how best to deal with record updates. Say

Re: Documenting record pattern synonyms

08d2 > | > e05387f2%7c72f988bf86f141af91ab2d7cd011db47%7c1=nEAgwVmvFQNgN%2bANGD4H > | z1flN%2fucKSRFoZMdhRqQKSM%3d > | > | >------- > | > | commit 2a74a64e8329ab9e0c74bec47198cb492d25affb > | Author: Matthew Pickering <matthewtpicker...@gmail.com> > | Date: Mon

Re: Type-level error messages

Hi Iavor, You can update your diff by using "arc diff --update D1236" Matt On Tue, Oct 27, 2015 at 8:48 PM, Iavor Diatchki wrote: > Hi Ben, > > I updated the wiki page for GHC 8.0.1 to add an entry for the custom type > errors (under "in flight, but likely to make

Re: On the record pattern synonyms patch

Hi Edward, I don't understand what should and shouldn't be in interface files. I tried to make the least changes to get everything still to work. The change was because of the corresponding change to the datatype.

Re: [commit: ghc] master: Remove PatSynBuilderId (2208011)

t.com%7c761b0bb4068a4d3ebe4c08d2 > | > e7ce3c86%7c72f988bf86f141af91ab2d7cd011db47%7c1=SQ%2fUVBd2qpKcBoN17ALE > | MES4qFLtEuWiJakOotW0IUM%3d > | > | >------- > | > | commit 22080113f02f6644e2a0e3ce8adb1502346ab3b4 >

Re: pattern synonym with required ctx having polykinded constraint fails

Looks like a definite bug. Filed as #10977 https://ghc.haskell.org/trac/ghc/ticket/10997 Matt On Wed, Oct 21, 2015 at 12:49 PM, Sreenidhi Nair wrote: > Hello, > > We have a pattern synonym as follows > > type family Showable (a :: k) :: Constraint where > Showable

Re: Planning for the 7.12 release

Hi Ben, I think that D1152 (Record Pattern Synonyms) will be ready for 7.12. https://phabricator.haskell.org/D1152 On Thu, Aug 27, 2015 at 5:38 PM, Ben Gamari b...@well-typed.com wrote: Hello everyone! With the 7.10.1 release nearly six months behind us and 7.10.2 out of the way, now is a

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: Proposal: Automatic derivation of Lift

Continuing my support of the generics route. Is there a fundamental reason why it couldn't handle unlifted types? Given their relative paucity, it seems like a fair compromise to generically define lift instances for all normal data types but require TH for unlifted types. This approach seems much

Pattern Synonym Signature Confusion

I think that the current state of pattern synonym signatures is quite confusing, especially regarding the constraints. For those unfamiliar, a signature looks like the following, pattern ExNumPat :: (Show b) => (Num a, Eq a) => b -> T a The first constraint being the "provided constraints" and

Re: Pattern Synonym Signature Confusion

> constraints, that would be even better. > > Cheers, > Andres > > On Fri, Oct 2, 2015 at 1:58 PM, Matthew Pickering > <matthewtpicker...@gmail.com> wrote: >> I have grepped the whole of hackage. There are only 10 pattern synonym >> signatures in total in th

Proposal: Associating pattern synonyms with types

Dear devs, There has been a bit of discussion on #10653 about extending exports to allow users to associate pattern synonyms with types (just like ordinary data constructors). There is a section on the wiki which describes the problem and the proposed behaviour.

Re: Open data kinds

Jan, Is there a specific reason for implementing closed data kinds? The way I have been thinking about open data kinds is that they should be like defining types. There is no language support to define a "closed datatype" but it is possible to do so by not exporting any of the constructors used

Re: Haddock for GHC 8.0

Hi Gautier, Indeed the task has been done. Here is the current rebased branch - https://github.com/haskell/haddock/tree/ghc-head Matt On Sun, Dec 20, 2015 at 11:36 PM, Gautier DI FOLCO wrote: > >> >> tl;dr: Help needed to bring

Improving trac notifications

I subscribe to the ghc-tickets[1] mailing list which provides updates to all trac tickets. This is very useful, however when a ticket description is updated the whole description is included in the email which makes it hard to see what actually changed. The web interface shows a nice diff[2] of

Re: Remove deprecated quasiquote syntax

> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of > | Matthew Pickering > | Sent: 25 November 2015 12:12 > | To: GHC developers <ghc-devs@haskell.org> > | Subject: Remove deprecated quasiquote syntax > | > | The [$qq| quasiquote syntax has been

Remove deprecated quasiquote syntax

The [$qq| quasiquote syntax has been deprecated since around 2010. Is there any objection to removing the backwards compatibility now? I counted 216 uses of it on hackage in a handful of packages, some in comments. http://lpaste.net/145938 Here is the commit which deprecated it -

Re: Phab not running a full validate?

I think it does run them all. If you look at the full stdout log it runs the failing tests again after finishing the run. Matt On 12 Jan 2016 00:59, "Richard Eisenberg" wrote: > Hi devs, > > Take a look at https://phabricator.haskell.org/harbormaster/build/9990/ > > See how

Harbourmaster is still not building diffs

Since a couple of months ago, harbourmaster no longer builds diffs. This is quite a large barrier to entry for new contributors as running ./validate takes a long time. It seems to be a very low priority issue to get it back working. Are there plans to get harbourmaster to build diffs again?

Re: Optimizing "counting" GADTs

David, Carter, It would be nice to use pattern synonyms for this task but they do not work quite as expected as they don't cause type refinement. I quickly assembled this note to explain why. http://mpickering.github.io/posts/2016-06-18-why-no-refinement.html Matt On Fri, May 27, 2016 at 4:50

Re: issues on Glasgow Haskell Compiler 8.0.1, release candidate 1

Hi George, For the the second error, building cabal from the github repo will stop the warnings. Matt On Sat, Jan 16, 2016 at 2:43 PM, George Colpitts wrote: > Hi Ben > > Yes this fixes the issue I found on the Mac. Although it seems there is a > minor problem that I

Re: Improving trac notifications

Have you had any chance to think about this yet Herbert? Matt On Wed, Jan 6, 2016 at 6:44 PM, Ben Gamari <b...@smart-cactus.org> wrote: > Ben Gamari <b...@smart-cactus.org> writes: > >> Matthew Pickering <matthewtpicker...@gmail.com> writes: >> >>> I

Re: Improving trac notifications

I attach a patch which should improve the notifications. Here is an example of the new output. https://www.irccloud.com/pastebin/HdlVbQt4/ Matt On Tue, Jan 19, 2016 at 11:29 AM, Matthew Pickering <matthewtpicker...@gmail.com> wrote: > Have you had any chance to think about this ye

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

Hello, I have renamed it to -Wmissing-pat-syn-signatures. Matt On Mon, Feb 15, 2016 at 9:09 PM, Ben Gamari wrote: > Sven Panne writes: > >> 2016-02-15 20:16 GMT+01:00 Ben Gamari : >> >>> Sven Panne

Re: Potentially confusing syntax for injective type families

I guess my point is that the most natural parsing of class Hcl a b where type Ht a b = r | r -> a b is (type Ht a b = r) (| r -> a b) rather than (type Ht a b) (= r | r -> a b). A concrete example, in the case of functional dependencies, the vertical bar is used to signal what we expect

Syntax changes due to TypeInType

Hello, I'm trying to update the haskell-src-exts parser for the syntax changes in GHC 8 but I'm struggling to find information about what exactly the kind equalities patch has changed. Could someone please give me a brief overview about what changes were made to the parser? I was waiting for the

Re: Feature development

n_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 <matthewtpicker...@gmail.com> > wrote: > > Hello Nikita, > > I d

Re: Feature development

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

Inlining Wiki Page

Dear Devs, I've spent the last day looking at the inliner. In doing so I updated the wiki page about inlining to be a lot more useful to other people wanting to understand the intricacies and problems. https://ghc.haskell.org/trac/ghc/wiki/Inlining This looks like the perfect place for a

Re: Help on first ticket

Hello Richard, It is certainly hard work on the first ticket. I spent about an hour this morning trying to find out where the right part to change was and then read Ben's email earlier in this thread which made everything much clearer for me! The essential problem we are trying to solve is: >

Re: RdrName and decorations

I agree with you Alan. In particular, information about 'pattern' and 'type' keywords should be captured in the AST. It can be scrubbed out in the renamer to avoid polluting later passes. At the moment, the 'type' keyword doesn't do anything to direct the renaming process, it just resolves an

Re: Note [Api annotations]

These comments are meant to indicate which annotations each AST fragment has. However, they are rarely kept up to date and ultimately not that useful. If someone wants to know then it is easier to look at the `Annotate` module in `ghc-exactprint`where this information also exists programatically.

Re: Note [Api annotations]

On Wed, Jul 20, 2016 at 12:22 PM, Ben Gamari <b...@smart-cactus.org> wrote: > Matthew Pickering <matthewtpicker...@gmail.com> writes: > >> These comments are meant to indicate which annotations each AST >> fragment has. However, they are rarely kept up to date and

Broken Build due to T1969

Hi all, https://phabricator.haskell.org/rGHC773e3aadac4bbee9a0173ebc90ffdc9458a2a3a9 broke the build by re-enabling the test T1969 The ticket tracking this is: https://ghc.haskell.org/trac/ghc/ticket/12437 Omer: Is it best to revert this patch and mark the test broken again? Matt

Re: Broken Build due to T1969

than temporarily disabling it. > > What are the numbers you're getting? > > 2016-08-17 14:16 GMT+00:00 Matthew Pickering <matthewtpicker...@gmail.com>: >> Hi all, >> >> https://phabricator.haskell.org/rGHC773e3aadac4bbee9a0173ebc90ffdc9458a2a3a9 >> >&

Re: Phabricator upgrade tomorrow

Ben has completed the upgrade. Smooth sailing ahead! Highlights from this release: 1. A new homepage - https://blog.phacility.com/post/8/the_new_home_menu/ 2. The new favourites menu - https://blog.phacility.com/post/6/extending_the_menubar/ 3. Emoji Autocomplete -

Re: Disable messages with GHC API

The errors are eventually caught and printed by "handleSourceError" which is used a few times in your code. You could either modify one of these to not print out any errors or try something more intelligent like is in `parUpsweep_one` which does use the `log_action` in order to print the errors

Re: Disable messages with GHC API

have completed in the first place. > > On 3 February 2017 at 12:50, Matthew Pickering > <matthewtpicker...@gmail.com> wrote: >> The errors are eventually caught and printed by "handleSourceError" >> which is used a few times in your code. You could either m

Re: Next steps of the trac-to-maniphest migration?

i, > > Am Dienstag, den 24.01.2017, 10:37 + schrieb Matthew Pickering: >> If you have any example queries that you run often or queries which >> you have embedded into wikipages then it would be useful to share >> them so I can investigate. > > the embedded query on

Re: Next steps of the trac-to-maniphest migration?

ting interface which trac doesn't provide for these kinds of queries. Matt On Tue, Jan 24, 2017 at 9:41 AM, Simon Marlow <marlo...@gmail.com> wrote: > On 21 January 2017 at 22:21, Matthew Pickering <matthewtpicker...@gmail.com> > wrote: >> >> Hello devs, >> >

Re: Cannot build GHC using the Newcomers guide

Can you try with the "--no-ghc-package-path" option in your wrapper? Matt On Thu, Jan 26, 2017 at 10:22 AM, Marius Ghita wrote: > Following is a list of steps that I ran and their output linked: > > - clone repo >

Re: Cannot build GHC using the Newcomers guide

I think the intention is that if you are already using stack to manage your GHC installations then it is desirable to use their managed version of GHC rather than have to install another version. It seems to me that the solution that Harendra suggests is the easiest for anyone with this setup.

Re: Next steps of the trac-to-maniphest migration?

, Simon Marlow <marlo...@gmail.com> wrote: > On 24 January 2017 at 14:09, Matthew Pickering <matthewtpicker...@gmail.com> > wrote: >> >> On Tue, Jan 24, 2017 at 1:26 PM, Simon Marlow <marlo...@gmail.com> wrote: >> >> > Can we have custom fields wit

Re: [commit: ghc] wip/discount-fv: Discount scrutinized free variables (fd9608e)

I think the motivation was your suggestion in #4960. Matt On Wed, Jan 25, 2017 at 10:11 AM, Simon Peyton Jones via ghc-devs wrote: > Alex > > Interesting. Care to give us any background on what you are working on? > > I've often thought about discounting for free vars.

Re: Magical function to support reflection

I modified the example on the wiki to compile but I seem to have missed something, could you perhaps point out what I missed? https://gist.github.com/mpickering/da6d7852af2f6c8f59f80ce726baa864 ``` *Main> test1 2 123 441212 441335 ``` On Thu, Jan 19, 2017 at 3:58 AM, David Feuer

Next steps of the trac-to-maniphest migration?

Hello devs, Thanks to everyone so far who has looked at and commented on the prototype. It seems that the response is generally positive so I would like to drive the process forwards. In order for that to happen, someone needs to decide whether we as a community think it is a good idea. It seems

Re: Problems with `arc` and `phabricator`

Hello Iavor, You need to upload you ssh key to phabricator. You can do it here, https://phabricator.haskell.org/settings/user/yav/page/ssh/ If you need any more help with phab then feel free to ping me on IRC or by email. Matt On Thu, Jan 26, 2017 at 9:35 PM, Iavor Diatchki

Re: Trac maintenance

Were there any particular features that we should know about which motivated the upgrade? Displaying real names is slightly inconvenient now for the purposes of assigning and ccing tickets as you must still use the user names for those fields. Matt On Sun, Feb 12, 2017 at 2:56 AM, Ben Gamari

Re: Improving trac notifications

Cheers Ben! Matt On Sun, Feb 12, 2017 at 10:57 PM, Ben Gamari <b...@well-typed.com> wrote: > Matthew Pickering <matthewtpicker...@gmail.com> writes: > >> I attach a patch which should improve the notifications. >> > I have applied this patch to our Trac 1.2 in

Re: Trac

I am using Chrome and it is closed by default On Monday, February 13, 2017, Richard Eisenberg wrote: > > > On Feb 13, 2017, at 1:06 PM, Ben Gamari > wrote: > > > > What browsers are you all using? > > Firefox, in agreement with your

Re: Next steps of the trac-to-maniphest migration?

On Tue, Jan 24, 2017 at 1:26 PM, Simon Marlow <marlo...@gmail.com> wrote: > On 24 January 2017 at 10:37, Matthew Pickering <matthewtpicker...@gmail.com> > wrote: >> >> Thank you Simon. >> >> If you have any example queries that you run often or queries

Re: [Diffusion] [Build Failed] rGHC5a9a1738023a: Refine exprOkForSpeculation

I restarted the build to see if it is a transient failure. I haven't seen errors like that before. On Mon, Jan 16, 2017 at 5:00 PM, Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote: > I’m sorry but I cannot make head or tail of the offending build log here. > I validated from

Re: Broken Build due to T1969

Thanks for checking Omer. I reverted the patch for now and the build is green. I'm not sure about the answers to your other questions, as long as the build stays green then I don't mind :) Matt ___ ghc-devs mailing list ghc-devs@haskell.org

Re: Rewrapping with simple bidirectional pattern synonyms

The relevant ticket is - https://ghc.haskell.org/trac/ghc/ticket/12203 On Wed, Aug 24, 2016 at 11:11 PM, David Feuer wrote: > I'm trying to write a bidirectional pattern synonym which is morally > simple, but as far as I can tell there's no way to write it as a > simple

OSX Test Failures

Occasionally a do a full validate on OSX, there are usually some tests which fail but not on other systems. I usually don't report these failures as there are always some and they are usually do to do with parts of the compiler I don't know anything about. However, on

Re: OSX Test Failures

The last time I did a full validate was about two weeks ago, I saw the same failures as you described on the ticket. I will report the issues from now. Matt On Tue, Sep 6, 2016 at 3:04 PM, Ben Gamari <b...@well-typed.com> wrote: > Matthew Pickering <matthewtpicker...@gmail

Re: Notes from Ben's "contribute to ghc" discussion

There is a phabricator module, ponder [1], which looks suitable for the Q feature. Surely we all agree that it is easier to setup this module than to host a completely separate service ourselves! This also has the advantage of being able to reference commits, differentials and tickets in an easy

Re: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

Thanks for the useful data point Mathieu. I think it should also be noted that GHC contributions spiked after switching to phabricator so it could just be the effect of moving to *some* code review tool. Could you perhaps summarise the salient points in the LLVM thread? It is very long with lots

Re: GHC 8.0.2 status

The easiest way I found to build stackage recently was to take the cabal.config file [1] and then manipulate it to just install each package in turn. cabal install package-1 cabal install package-2 This was quite a bit easier than using stackage-curator if you just want to build packages to

Re: Request for feedback: deriving strategies syntax

I also like 'bespoke' but then it seems to be a much more common in British English than American English. On Thu, Aug 18, 2016 at 7:46 PM, Ryan Scott wrote: > Bardur, > > Since you don't like "bespoke", would you mind suggesting an > alternative, or advocating for a

Re: Trying to refactor DeriveAnyClass, stuck on typechecker-related code

Ryan and I chatted about this on IRC and he has a plan to fix this problem. On Sat, Aug 27, 2016 at 5:07 PM, Ryan Scott wrote: > Simon, > > I'm currently working on a solution to #12144, which changes the way > inferred contexts for DeriveAnyClass works, as per your

Re: Trac commit notifications on stable branches

Ah right my bad. Seems like a good change to me then. Matt On Fri, Aug 26, 2016 at 12:06 AM, Ben Gamari <b...@well-typed.com> wrote: > Matthew Pickering <matthewtpicker...@gmail.com> writes: > >> I did notice today that I received a lot of emails as you were merging

Re: Trac commit notifications on stable branches

I did notice today that I received a lot of emails as you were merging patches to the stable branch. If it makes things much easier for you then I don't mind the extra notifications but it would perhaps be better to suppress email notification somehow. Matt On Thu, Aug 25, 2016 at 11:21 PM, Ben

Re: Notes from Ben's "contribute to ghc" discussion

I don't understand this fascination with Rust the Haskell community has. The two projects are very different. As you say in the post, GHC is a much older project and as a result has much less hype around it. Rust is the definition of a "hot new thing" and so it makes sense that there are more

Re: Notes from Ben's "contribute to ghc" discussion

mers, not producers! Excellent process, documentation, > and community is what turns those consumers into producers! > > This is so short-sighted and wrong that I don't think there's any > point in my saying more. You've made it clear you don't care. > > On Sat, Sep 24, 2016 at 7:17 PM, Matt

Re: Notes from Ben's "contribute to ghc" discussion

If we loop this discussion back to the original post. There is a suggestion in there which seems to be what you are looking for. > Have a GHC StackOverflow on haskell.org (Jacob Zalewski jakz...@gmail.com > offers to do this! – thank you). It has a useful new Documentation feature. > Eg

Re: Notes from Ben's "contribute to ghc" discussion

would appreciate it if you would directly respond to the suggestions in this message. Matt On Sun, Sep 25, 2016 at 2:13 AM, Anthony Cowley <acow...@seas.upenn.edu> wrote: > On Sat, Sep 24, 2016 at 8:17 PM, Matthew Pickering > <matthewtpicker...@gmail.com> wrote: >> I think

Re: Notes from Ben's "contribute to ghc" discussion

I think this comment is useful because it highlights the point that it isn't very clear what "the point" even is. Is the problem that the code review process happens on phabricator and trac rather than github? It seems unlikely the project will move to github, phabricator works well for existing

Re: Submitting a patch for hsc2hs

To close up this thread, once D2676 is merged to hsc2hs then you will be able to submit patches using the same workflow as for GHC. On Friday, 4 November 2016, Erik de Castro Lopo wrote: > Erik de Castro Lopo wrote: > > > How long ago was it that it worked, because it

Windows Builder Disabled

I have disabled the windows builder as it is consistently failing with the same error message. From this log for example: https://phabricator.haskell.org/harbormaster/build/14430/ ghc.exe: getMBlocks: VirtualAlloc MEM_COMMIT failed: The paging file is too small for this operation to complete.

Re: Aarrgh! Windows build broken again

Erik has a patch which fixes this. I will merge it now. Matt On Sun, Oct 23, 2016 at 12:11 AM, Simon Peyton Jones via ghc-devs wrote: > On Windows with HEAD I get > > C:/code/HEAD/inplace/mingw/bin/ld.exe: cannot find -lnuma > > Sigh. This didn’t happen a day or two ago

Re: [Diffusion] [Build Failed] rGHC6ddba64287fe: Improve TcCanonical.unifyWanted and unifyDerived

I can reproduce the failure locally but not always. No clue as to the sudden cause but here's the ticket and differential to mark the test as broken for now. https://ghc.haskell.org/trac/ghc/ticket/12751 https://phabricator.haskell.org/D2622 Matt On Fri, Oct 21, 2016 at 10:20 PM, Simon Peyton

OSX build failing

Hi all, The OSX build is broken due to 55d535da10dd63bbaf03fb176ced7179087cd0d4 Should I revert the patch or is there a fix coming? Matt = commit 55d535da10dd63bbaf03fb176ced7179087cd0d4 Author: Simon Marlow Date: Wed Nov 9 09:20:02 2016 + Remove

Re: OSX build failing

I now see D2705, sorry for the noise. Matt On Mon, Nov 14, 2016 at 9:00 PM, Matthew Pickering <matthewtpicker...@gmail.com> wrote: > Hi all, > > The OSX build is broken due to 55d535da10dd63bbaf03fb176ced7179087cd0d4 > > Should I revert the patch or is there a

Exhaustiveness checking for pattern synonyms

Hello devs, I have implemented exhaustiveness checking for pattern synonyms. The idea is very simple, you specify a set of pattern synonyms (or data constructors) which are regarded as a complete match. The pattern match checker then uses this information in order to check whether a function

Re: Specialization plugin

I am helping Ryan investigate this. See https://ghc.haskell.org/trac/ghc/ticket/12791 for one example which we have identified so far. Matt On Fri, Oct 28, 2016 at 10:14 PM, Simon Peyton Jones via ghc-devs wrote: > I’d really like to know why INLINABLE pragmas don’t work.

Updated Phabricator Home Page

Hi all, I have updated the homepage for our phabricator installation. I moved some things around, deleted some unused panels and updated the landing text. If anyone has any other gripes with the installation please message me and I will see if I can fix them! If you liked the old version better,

Re: Inlining Wiki Page

wanted to work on for this year. > Just letting you know that I'm starting to look at some of the easier > tickets in that page. > > Is there a good person or place to ask questions if I get stuck on anything? > > Cheers, > Tim > > > On Thursday, 4 August 2016, Matthew Pi

Re: Build failures

Ben has a patch to fix it on phab - https://phabricator.haskell.org/D2964 Matt On Fri, Jan 13, 2017 at 8:41 AM, Simon Peyton Jones via ghc-devs wrote: > recomp001 is failing on Harbormaster on OSX (only). Does anyone know why? > See for example > >

Travis Builds are broken

A recent commit has caused the Travis builds to stop working. I think it was caused by https://phabricator.haskell.org/rGHCc2bd62ed62d2fae126819136d428989a7b4ddc79 Example failure Wrong exit code for plugins01()(expected 0 , actual 2 ) Stderr ( plugins01 ): ghc-stage2:

Re: Exhaustiveness checking for pattern synonyms

or the build in set of data constructors for a type constructor. > Simon > > | -Original Message- > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Matthew > | Pickering > | Sent: 22 November 2016 10:43 > | To: GHC developers <ghc-devs@

Re: Trac to Phabricator (Maniphest) migration prototype

<b...@smart-cactus.org> wrote: > Matthew Pickering <matthewtpicker...@gmail.com> writes: > >> Dear devs, >> >> I have completed writing a migration which moves tickets from trac to >> phabricator. The conversion is essentially lossless. The trac >>

Re: Please don’t break travis

de 1) errors were: > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 8.1.20161118 for x86_64-unknown-linux): > No match in record selector is_iloc > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > *** unexpected failure for

Re: Trac to Phabricator (Maniphest) migration prototype

-147-146.eu-west-1.compute.amazonaws.com/ Matt On Wed, Dec 21, 2016 at 10:12 AM, Matthew Pickering <matthewtpicker...@gmail.com> wrote: > Dear devs, > > I have completed writing a migration which moves tickets from trac to > phabricator. The conversion is essentially lossless. The

Re: Contributing Examples to the Documentation

I think this will be welcomed, go for it! All patches should be submitted on Phabricator. There are some straightforward instructions on how to submit a patch on the wiki - https://ghc.haskell.org/trac/ghc/wiki/Phabricator If you want to build the documentation then you can modify mk/build.mk

Re: Trac to Phabricator (Maniphest) migration prototype

Good comments Edward. I think the answers to all three of your points will be insightful. 1. As for why it appears some information from the ticket is missing. The version field is not very useful as there are only two active branches at once. Instead we want a project which marks tickets which

Re: Trac to Phabricator (Maniphest) migration prototype

To first reply to the one specific reoccurring point about custom fields. The problem with 'os' and 'architecture' is a philosophical one, in what way are they any different to any other metadata for a ticket? I am of the opinion that we should only include information when it is relevant, a lot

Re: Trac to Phabricator (Maniphest) migration prototype

tt On Sun, Jan 8, 2017 at 5:40 AM, Ben Gamari <b...@smart-cactus.org> wrote: > Matthew Pickering <matthewtpicker...@gmail.com> writes: > >> Dear devs, >> > Hi Matthew and Dan, > > First, thanks for your work on this; it is an impressive effort. > Reconstru

Re: Trac to Phabricator (Maniphest) migration prototype

I am persuaded that component is useful. Richard makes the point that there is a murky divide between component and keywords. This is right and it indicates that we should keep the component field but also homogenise it was the keywords (in the form of projects). I have included which fields are

Re: Trac to Phabricator (Maniphest) migration prototype

I should have looked more closely at the implementation.. the component field was already preserved. There is a bug where it is not set properly if it was set by the ticket reporter. I will look into this problem this evening! Matt On Wed, Jan 4, 2017 at 10:18 AM, Matthew Pickering

Re: Trac to Phabricator (Maniphest) migration prototype

a list of amorphous labels. Matt On Mon, Jan 9, 2017 at 6:41 PM, Richard Eisenberg <r...@cs.brynmawr.edu> wrote: > >> On Jan 9, 2017, at 6:41 AM, Matthew Pickering <matthewtpicker...@gmail.com> >> wrote: >> >> Component -> Projects >> OS -> (Sub)P

Re: Trac to Phabricator (Maniphest) migration prototype

Peyton Jones <simo...@microsoft.com> wrote: > On this Phab question, does Phab have an equivalent to Trac's wiki? That's > quite important. > > Simon > > | -Original Message- > | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Matthew &

Trac to Phabricator (Maniphest) migration prototype

Dear devs, I have completed writing a migration which moves tickets from trac to phabricator. The conversion is essentially lossless. The trac transaction history is replayed which means all events are transferred with their original authors and timestamps. I welcome comments on the work I have

Re: Trac to Phabricator (Maniphest) migration prototype

tom fields > we have now or is it just one box where you have to add stuff to all in one > line? > I sent you some login details so you can try it out. > Kind regards, > Tamar Matt > > On Wed, 21 Dec 2016, 10:13 Matthew Pickering, <matthewtpicker...@gmail.com> > w

Re: Trac to Phabricator (Maniphest) migration prototype

t; If we do the transfer, we should redirect: > https://ghc.haskell.org/trac/ghc/ticket/{NN}#comment:{CC} > to > phabricator.haskell.org/T{NN}#{tracToPhabComment(NN,CC)} > where "tracToPhabComment" function remains to be written ;-) > > Thanks, > Sylvain > > &

Re: Trac to Phabricator (Maniphest) migration prototype

I just noticed that the instance was down because the disk quota had been reached. I expanded the size of storage and it should be working again. Matt On Wed, Dec 21, 2016 at 10:12 AM, Matthew Pickering <matthewtpicker...@gmail.com> wrote: > Dear devs, > > I have completed writ

  1   2   3   4   5   >