Re: Weight field in issues too fine grained?

On Tue, 2 Jul 2019, 9.05 Ömer Sinan Ağacan, wrote: > > Is it possible to do switch to trac-style priority/weight field in Gitlab? > Anyone else think that this would be good? > > Ömer > > [1]: > https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/issues#triage-protocol Hi Ömer, Yes, it's possible

Weight field in issues too fine grained?

Hi, One of the problems I'm having when triaging is that I think the "weight" field for issues is currently too fine grained. The triage protocol[1] gives some idea but it's still up to the person who's doing triaging to decide, for example, between 7 vs. 10 for a runtime crash. I think a better

Re: Workflow question (changing codegen)

Ömer Sinan Ağacan writes: > My current workaround is this: I have a branch which is just master + the new > file I've added. I first build it from a clean tree (git clean -xfd; then > build), then switch to my branch, and run `make 1` in `compiler/`. That way I > don't have to run ./configure (be

Re: Workflow question (changing codegen)

Sebastian Graf writes: > Re: git worktree: That's the workflow I'm currently using. It has its > problems with submodules, see > https://stackoverflow.com/questions/31871888/what-goes-wrong-when-using-git-worktree-with-git-submodules. > But you can make it work with this git alias from the first

Re: Workflow question (changing codegen)

Richard Eisenberg writes: > Just to pass on something that looks cool (I haven't tried it myself > yet): git worktree. It seems git can hang several different checkouts > of a repo in different directories. This seems far superior to my > current habit of having many clones of ghc, sometimes goin

Re: User manual

Matthew Pickering writes: > It seems the the `doc-tarball` job stopped working because the > `-deb9-debug` variant uses the `validate` flavour which doesn't build > the documentation pdf. > > How is best to fix this Ben? The dwarf build does have the PDF but is 350mb . > A good question. I can se

Re: User manual

It seems the the `doc-tarball` job stopped working because the `-deb9-debug` variant uses the `validate` flavour which doesn't build the documentation pdf. How is best to fix this Ben? The dwarf build does have the PDF but is 350mb . On Mon, Jul 1, 2019 at 2:50 PM Simon Peyton Jones via ghc-devs

Re: User manual

Simon Peyton Jones via ghc-devs writes: > I use this link to see the most up to date GHC user manual > https://ghc.gitlab.haskell.org/ghc/doc/users_guide/index.html > But I think I'm seeing on from 13 June. It's labelled as GHC 8.9.0.20190613 > User's Guide

Re:

Copying on ghc-devs, since i think that's what you wanted. On Mon, Jul 1, 2019, 11:14 AM Andrew Martin wrote: > To get GHC to raise an exception from an inline primop, I presume that I'd > need to jump to stg_raisezh. None of the existing inline primops do > anything quite like this. I see thing

Re: Cloning (Shayne Fletcher)

Well this is an unexpected and most welcome development. Way to go Arnaud! On Mon, Jul 1, 2019, 06:53 Artem Pelenitsyn wrote: > Hello Jost, > > Thanks for researching this! In fact, Arnaud did his own research on this > topic and submitted !1309 [1] to switch to the absolute paths. The MR has >

User manual

I use this link to see the most up to date GHC user manual https://ghc.gitlab.haskell.org/ghc/doc/users_guide/index.html But I think I'm seeing on from 13 June. It's labelled as GHC 8.9.0.20190613 User's Guide How come it's so out of

Re: Cloning (Shayne Fletcher)

Hello Jost, Thanks for researching this! In fact, Arnaud did his own research on this topic and submitted !1309 [1] to switch to the absolute paths. The MR has been approved by Ben swiftly and now awaits merging. I believe we should default to the common case, which is to use abs paths making the

Re: Cloning (Shayne Fletcher)

Just on this detail in the previous mails: On 6/25/19 10:00 PM, ghc-devs-requ...@haskell.org wrote: More generally, I'm actually wondering, why GHC's .gitsubmodules use relative paths. Why not make them absolute? I continue to wonder about that and if switching to absolute paths might remove

Re: Workflow question (changing codegen)

My current workaround is this: I have a branch which is just master + the new file I've added. I first build it from a clean tree (git clean -xfd; then build), then switch to my branch, and run `make 1` in `compiler/`. That way I don't have to run ./configure (because the new file is already built