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
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
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
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
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
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
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
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.
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
| 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
> 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
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
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
13 matches
Mail list logo