Does this really strain storage infrastructure? There are only a few
blobs per release. If that's really a problem, sufficiently ancient
ones can presumably be pruned down to a single format without too many
complaints (e.g., if someone wants GHC 7.6, they may not be able to
have their choice of fo
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 continuing to do bz2
tarba
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 them!)
>
> Simon
>
> | --
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 Si
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 t
| 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 hi
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
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 logically grouped, with or
> wi
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 g
On 1 February 2016 at 15:44, Jan Stolarek wrote:
> I also wonder what is the preferred way of viewing history for most of the
> people. I either use
> `git log` or github, but rarely resort to gitk. Only the latter makes the
> non-linear commits
> explicitly visible. The former two just collapse
> 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 won
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. Better to have one big, coh
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 rea
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 you are thinking about t
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 a
15 matches
Mail list logo
