PrimRep constructor Vec

2016-02-02 Thread Richard Eisenberg
Hi Geoff, I'm working on the fix for #11471, which involves interacting with the PrimRep type. (You don't need the ticket background to understand this question, though.) One of PrimRep's constructors is VecRep, which Simon tells me is your domain. The problem is that I can find nowhere in the

RE: CallStack naming

2016-02-02 Thread Ben Gamari
Simon Peyton Jones writes: > OK. Let's make sure the wiki page and documentation reflects this. > It looks like the Wiki [1] hasn't yet been updated. Let's make sure this happens. Thanks! - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations signature.asc Descr

RE: [GHC] #11526: unsafeLookupStaticPtr should not live in IO

2016-02-02 Thread Simon Peyton Jones
Fine. So long as the result of deserialising doesn’t change with time! It’s not clear what the “opt-in” mechanism would look like, but maybe you or Facundo can articulate a design? S From: Mathieu Boespflug [mailto:0xbadc...@gmail.com] Sent: 02 February 2016 14:38 To: ghc-devs@haskell.org; S

Re: Best practices for merging?

2016-02-02 Thread Brandon Allbery
On Tue, Feb 2, 2016 at 9:55 AM, Richard Eisenberg wrote: > What if there were an official place to keep dirty histories? git actually has a place for these, although at a price: when you squash commits or otherwise modify history, the originals are retained in the reflog. By default the reflog

Re: Best practices for merging?

2016-02-02 Thread Richard Eisenberg
What if there were an official place to keep dirty histories? For example, my TypeInType patch has a very long, very tortuous history. Probably the majority of commits don't compile. (On a development branch meant for private use, I see no good reason to insist that each commit builds.) I would

Re: Best practices for merging?

2016-02-02 Thread Brandon Allbery
On Tue, Feb 2, 2016 at 9:23 AM, Alexander Berntsen wrote: > On 02/02/16 15:20, Brandon Allbery wrote: > > Only if it builds and passes tests across all ten commits. > Yes, obviously. I have never worked anywhere where breaking commits > were allowed, and I did not intend to suggest that breaking

Re: [GHC] #11526: unsafeLookupStaticPtr should not live in IO

2016-02-02 Thread Mathieu Boespflug
IMHO this dynamic linking thing is a red herring. In principle any function call becomes potentially impure given eg the ability to shadow symbols. In practice that's not something we do to programs. We could consider having two tables though: an initial tackle generated at compile time that will n

Re: Best practices for merging?

2016-02-02 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/02/16 15:20, Brandon Allbery wrote: > Only if it builds and passes tests across all ten commits. Yes, obviously. I have never worked anywhere where breaking commits were allowed, and I did not intend to suggest that breaking commits were a Good

Re: Best practices for merging?

2016-02-02 Thread Brandon Allbery
On Tue, Feb 2, 2016 at 8:54 AM, Alexander Berntsen wrote: > It then becomes comparatively trivial to hunt > down the error by bisecting ten 25 line commits, when the converse is > figuring out a 250+ lines patch. > Only if it builds and passes tests across all ten commits. -- brandon s allbery

Re: Best practices for merging?

2016-02-02 Thread Alexander Berntsen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/02/16 18:11, Simon Peyton Jones wrote: > The sometimes-torturous history is not of interest to later > readers. I would like to add as a big asterisk to this statement that in practice, big features often break things in subtle ways that are o

Re: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1

2016-02-02 Thread Ben Gamari
Jens Petersen writes: > On 14 January 2016 at 00:43, Ben Gamari wrote: >> The GHC Team is very pleased to announce the first release candidate of >> the Glasgow Haskell Compiler 8.0.1 release. > > Thanks! - I spent a little trying to build/package it for Fedora, but > running in the usual proble

Re: Dropping bzip2 release tarballs?

2016-02-02 Thread Jan Stolarek
> it appears that essentially everyone uses the xz distributions. If this > really is the > case, then I would ask why are we spending the disk space, effort, > bandwidth, and complexity preparing the bzips. I stayed quite in this discusion so far, but I am one of the people still using bz2 rathe

Re: Build failing

2016-02-02 Thread Ben Gamari
Ben Gamari writes: > Phyx writes: > >> Hi Simon, >> >> I have made a diff to fix it but it hasn't been reviewed yet >> https://phabricator.haskell.org/D1878 > > Thanks Phyx. > > I just fired off a validation build locally. I'll merge as soon as it > passes. > It has been merged. Thanks again!

Re: Dropping bzip2 release tarballs?

2016-02-02 Thread Ben Gamari
David Feuer writes: > Does this really strain storage infrastructure? There are only a few > blobs per release. > To me the real motivation here is to simplify the distribution preparation process. Currently I need to worry about producing, signing, hashing, and uploading two of each tarball. To

Re: Build failing

2016-02-02 Thread Ben Gamari
Phyx writes: > Hi Simon, > > I have made a diff to fix it but it hasn't been reviewed yet > https://phabricator.haskell.org/D1878 Thanks Phyx. I just fired off a validation build locally. I'll merge as soon as it passes. Cheers, - Ben signature.asc Description: PGP signature __

Re: Build failing

2016-02-02 Thread Phyx
Hi Simon, I have made a diff to fix it but it hasn't been reviewed yet https://phabricator.haskell.org/D1878 Regards, Tamar Sent from my Mobile On Feb 2, 2016 12:07 PM, "Simon Peyton Jones" wrote: > A clean Windows build fails. See below. help! > > Simon > > > > rts\Linker.c:444:7: error: >

Build failing

2016-02-02 Thread Simon Peyton Jones
A clean Windows build fails. See below. help! Simon rts\Linker.c:444:7: error: error: pointer type mismatch in conditional expression [-Werror] : pinfo->owner->fileName ^ rts\Linker.c:429:7: error: error: format '%ls' expects argument of type 'wchar_t *',

Re: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1

2016-02-02 Thread Jens Petersen
On 14 January 2016 at 00:43, Ben Gamari wrote: > The GHC Team is very pleased to announce the first release candidate of > the Glasgow Haskell Compiler 8.0.1 release. Thanks! - I spent a little trying to build/package it for Fedora, but running in the usual problem with changes in the library pat