Re: Contributing Examples to the Documentation

Hi Sunjay, > If I use the doctest style, do I use ">>>" for the prompt? That's more a > Python thing. Maybe ">" would be more appropriate for Haskell? You should use ">>>". If you don't know doctest for Haskell, please read: https://github.com/sol/doctest#readme The following document

Re: Trac to Phabricator (Maniphest) migration prototype

In response to no# 2, I was looking at this my self since I think separate fields would definitely be useful. It seems you can customize the form design on phabricrator. I think it would definitely be worth it to make a new form layout resembling the layout of track. I don't know how it stores it

Re: Contributing Examples to the Documentation

There are lots of examples in the lens package. I can't think of a better model. On Wed, Jan 4, 2017 at 1:36 PM, Sunjay Varma wrote: > Hi all, > Are there any modules with good code examples that I should use as a > reference? I want to include both the code and output

Re: Contributing Examples to the Documentation

Hi Kazu, If I use the doctest style, do I use ">>>" for the prompt? That's more a Python thing. Maybe ">" would be more appropriate for Haskell? Sunjay On Jan 4, 2017 5:39 PM, "Kazu Yamamoto" wrote: Hi Sunjay, > Are there any modules with good code examples that I should use

Re: Contributing Examples to the Documentation

Hi Sunjay, > Are there any modules with good code examples that I should use as a > reference? I want to include both the code and output of the example as if > the user was running ghci. Are there any guidelines for contributing > documentation? I would suggest to use the doctest style so that

Re: Contributing Examples to the Documentation

Sunjay Varma writes: > Hi, > I'm considering contributing examples to the documentation. I wanted to > start with something like Data.List because it is one of the modules I end > up using the most. I think a few examples for each function would help > users understand

Re: Contributing Examples to the Documentation

Hi all, Are there any modules with good code examples that I should use as a reference? I want to include both the code and output of the example as if the user was running ghci. Are there any guidelines for contributing documentation? Thanks! Sunjay On Jan 4, 2017 9:20 AM, "Matthew Pickering"

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

> On Jan 4, 2017, at 5:18 AM, Matthew Pickering > wrote: > > 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

Contributing Examples to the Documentation

Hi, I'm considering contributing examples to the documentation. I wanted to start with something like Data.List because it is one of the modules I end up using the most. I think a few examples for each function would help users understand them better. I find myself referring back to books like

Re: FW: Lightweight Concurrency Branch

Hi KC, if blackholes only appear during thunk evaluation, could the problem you describe below be worked around by simply imposing that the scheduler never creates black holes? Say by leveraging GHC's new -XStrict language extension? -- Mathieu Boespflug Founder at http://tweag.io. On 4 January

FW: Lightweight Concurrency Branch

Reply from KC… see below. Simon From: KC Sivaramakrishnan [mailto:sk...@cam.ac.uk] Sent: 04 January 2017 11:29 To: Simon Peyton Jones Cc: Daniel Bennet ; ghc-devs@haskell.org; KC (sk...@hermes.cam.ac.uk) Subject: Re:

RE: Lightweight Concurrency Branch

David KC never finished work on this stuff. I’m copying him because I’m sure he’d be happy to help. KC: can you summarise where you left it? I think it’s very interesting work, and has the potential to make GHC’s RTS much more malleable, by moving more of it into Haskell libraries instead of

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

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