RE: StgCase - are LiveVars and SRT fields going to be used?

2016-02-01 Thread Simon Peyton Jones
Those fields are dead, now that the Cmm pass deals with it. We left it in while making the transition, but they can go now. Go ahead! (Lots of code should disappear along with them!) Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ömer

StgCase - are LiveVars and SRT fields going to be used?

2016-02-01 Thread Ömer Sinan Ağacan
Hi all, This is how case expression in STG currently defined: | StgCase (GenStgExpr bndr occ) (GenStgLiveVars occ) (GenStgLiveVars occ) bndr SRT AltType [GenStgAlt bndr occ] The GenStgLiveVars and SRT fields are never used anywhere in

Re: StgCase - are LiveVars and SRT fields going to be used?

2016-02-01 Thread Ömer Sinan Ağacan
https://phabricator.haskell.org/D1880 2016-02-01 18:04 GMT-05:00 Simon Peyton Jones : > Those fields are dead, now that the Cmm pass deals with it. We left it in > while making the transition, but they can go now. Go ahead! > > (Lots of code should disappear along with

Re: Dropping bzip2 release tarballs?

2016-02-01 Thread Jens Petersen
On 14 January 2016 at 01:19, Ben Gamari wrote: > tl;dr do you rely on the .bz2 release tarballs on downloads.haskell.org? I don't have a strong opinion about it and understand the desire to standardize on one archive type. I use the xz src tarballs myself, but how about

RE: Nailing down what we expect IO to do and not do - and why

2016-02-01 Thread Simon Peyton Jones
If you are thinking about the compiler internals, then knowing about State# etc is necessary. “Digging it up in the compiler is hard” Indeed, and you should not have to do that. If you are think about programmers, and how they reason about their programs, then my working hypothesis is that

RE: Best practices for merging?

2016-02-01 Thread Simon Peyton Jones
I'm no git expert here, but * Feature branches typically have lots of intermediate fixups. We don’t want that sequence in the main history; it's like watching sausage being made, and many intermediate points may be broken. Better to have one big, coherent commit. * If a feature branch

Re: Nailing down what we expect IO to do and not do - and why

2016-02-01 Thread Christopher Allen
Right, I'm seeking to understand the internals more generally, but specifically I'd like to know the answers to my questions in my original email. I'd really appreciate some pointers and information on this. On Mon, Feb 1, 2016 at 2:57 AM, Simon Peyton Jones wrote: > If

RE: Best practices for merging?

2016-02-01 Thread Ben Gamari
Simon Peyton Jones writes: > I'm no git expert here, but > > * Feature branches typically have lots of intermediate fixups. > We don’t want that sequence in the main history; it's like > watching sausage being made, and many intermediate points may > be broken.

Re: Best practices for merging?

2016-02-01 Thread Richard Eisenberg
I have this in effect: alias gitlog='git log --graph --full-history --all --color --pretty=format:"%x1b[31m%h%x09%x1b[32m%d%x1b[0m%x20%s"' I didn't come up with the incantation (and I forget the source), but it has obviated entirely my use of gitk. I use this command many times a day. Richard

RE: Best practices for merging?

2016-02-01 Thread Simon Peyton Jones
| Squashing large change sets into a single patch is also undesirable--- | it makes figuring out exactly what changed more difficult and makes | bisecting less useful. My personal preference is: * Always squash the "sausage-being-made" commits of a feature branch. The sometimes-torturous

Re: Best practices for merging?

2016-02-01 Thread Jan Stolarek
> If there are multiple commits then a merge commit can serve to logically > group them. The cost of this is non-linear history. But I am still not sure what the actual benefit is? If the commits come one after another they are still logically grouped, with or without a merge commit. I also

Re: Best practices for merging?

2016-02-01 Thread Geoffrey Mainland
On 02/01/2016 09:44 AM, Jan Stolarek wrote: >> If there are multiple commits then a merge commit can serve to logically >> group them. > The cost of this is non-linear history. But I am still not sure what the > actual benefit is? If the > commits come one after another they are still logically

Re: Best practices for merging?

2016-02-01 Thread Ben Gamari
Jan Stolarek writes: >> If there are multiple commits then a merge commit can serve to logically >> group them. > The cost of this is non-linear history. But I am still not sure what the > actual benefit is? If the > commits come one after another they are still