Why we need CCS entries in apply functions (rts/Apply.cmm and rts/StgStdThunks.cmm)

2014-07-01 Thread Ömer Sinan Ağacan
Hi all, Code for entering cost-centres before executing the function/thunk body is generated in `compiler/codeGen/StgCmmBind.hs`, by `thunkCode` and `closureCodeBody` functions. But we also have some `enterCostCentreThunk` and `enterCostCentreFun` calls in `rts/Apply.cmm` and `rts/StgStdThunks.cmm

Re: Help needed: parsing pattern synonym contexts

2014-07-01 Thread Simon Marlow
The s/r conflicts can also be a problem, depending on what you're trying to parse. It's generally a good idea to get rid of them if you can, but at the least you should understand why they exist (use happy --info) and document them in Parser.y.pp. Cheers, Simon On 30/06/2014 14:04, Simon Pey

Re: the case of the missing Cabal doc

2014-07-01 Thread Mark Lentczner
On Mon, Jun 30, 2014 at 1:25 PM, Ian Lynagh wrote: > It was converted to markdown, and GHC's build system doesn't know how to > build markdown docs. It's in libraries/Cabal/Cabal/doc/. > Okay then... I can see how the GHC build doesn't want to depend on pandoc! I'll probably remove this from the

Re: Proposal: require Haddock comment for every new top-level function and type in GHC source code

2014-07-01 Thread Andrew Farmer
At the risk of sounding redundantly redundant, I'd like to third this. My workflow for finding stuff in the GHC codebase is a mixture of grep and Hoogle. Searching Hoogle for "+ghc :: [TyVar] -> Type -> Type" is a huge timesaver, and Hoogle sends me to the generated haddock comments. Usually the h

RE: DPH-setting in mk/build.mk (was: HEADS-UP: Git submodule conversion imminent)

2014-07-01 Thread Simon Peyton Jones
Good to document this in our building guide somewhere. https://ghc.haskell.org/trac/ghc/wiki/Building/Using perhaps Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Herbert Valerio Riedel | Sent: 01 July 2014 10:19 | To: Jan Stolarek | Cc:

Re: DPH-setting in mk/build.mk (was: HEADS-UP: Git submodule conversion imminent)

2014-07-01 Thread Jan Stolarek
> It may be worth considering setting BUILD_DPH=NO in some of the > quick-build templates in mk/build.mk, but I didn't want to change > anything w/o discussion here first. +1 from me. I see this change as being beginner-friendly - most newcomers probably don't need DPH. Janek

DPH-setting in mk/build.mk (was: HEADS-UP: Git submodule conversion imminent)

2014-07-01 Thread Herbert Valerio Riedel
On 2014-06-30 at 08:45:57 +0200, Jan Stolarek wrote: > Herbert, all, > > I just pulled the new HEAD and have a question which I believe was not > addressed so far. In my > work on the GHC tree I never pulled the dph subrepo because the only thing it > adds for me is > extra build time (of cours

Re: [commit: ghc] master: Overlapable pragmas for individual instances (#9242) (6290eea)

2014-07-01 Thread Jan Stolarek
> Sure, I've just added you to the set of users allowed to push to > GitHub's haskell/haddock repo. > > There's a ghc-devs team in the haskell github organization, > > https://github.com/orgs/haskell/teams/ghc-devs This link is broken. Is this the same as: https://github.com/orgs/haskell/members