Re: Linker change in GHC 7.8 leads to widespread issues

2014-12-03 Thread Bryan O'Sullivan
On Wed, Dec 3, 2014 at 12:49 PM, Mikhail Glushenkov < the.dead.shall.r...@gmail.com> wrote: > I've now fixed this issue in Cabal HEAD and also pushed the fix to > 1.20 and 1.18 branches. 1.20 and 1.18 point releases should be out > soon. > Thanks, Mikhail! Does this imply that package authors can

Linker change in GHC 7.8 leads to widespread issues

2014-12-02 Thread Bryan O'Sullivan
Hi folks, It seems that something somewhere in linker-land changed in GHC 7.8 such that packages that include C components now need to be built with position-independent code on some platforms. This affects a number of my packages. I am not sure whether the correct fix is to pepper all of these p

Re: Status updates

2014-08-04 Thread Bryan O'Sullivan
Hey Austin – It's very helpful and informative to know what you're up to. Thanks for taking the time to write these updates; I assure you they're appreciated. On Mon, Aug 4, 2014 at 9:51 AM, Austin Seipp wrote: > Hi *, > > Here's some weekly status updates! > > - I'm merging Applicative-Monad

Re: Status of Haskell Platform 2014.2.0.0

2014-07-15 Thread Bryan O'Sullivan
On Tue, Jul 15, 2014 at 3:14 PM, Mark Lentczner wrote: > But only if you use the Data.Atooparsec.Text parsers double, number, and > rational parser, right? > Well yes, but that's a rather important "if". ___ ghc-devs mailing list ghc-devs@haskell.org h

Re: Status of Haskell Platform 2014.2.0.0

2014-07-15 Thread Bryan O'Sullivan
On Tue, Jul 15, 2014 at 1:43 PM, Mark Lentczner wrote: > This is rather late to hear this... given that I plan to Alpha this > weekend or sooner. > > Can you quantify the security fixes? Do they only revolve around floats? > Well, it was rather late to hear that you weren't going to upgrade atto

Re: Status of Haskell Platform 2014.2.0.0

2014-07-15 Thread Bryan O'Sullivan
On Tue, Jul 15, 2014 at 6:44 AM, Mark Lentczner wrote: > ​Unsure: > >- Not sure if you want QuickCheck 2.7.5 rather than 2.6 -- cc'ing >QuickCheck devs: Would they like to weigh in? > > I would really like to see 2.7.5 go in, as it has a number of both improvements and backwards incompati

Forcing apps to collect GC stats?

2014-07-14 Thread Bryan O'Sullivan
I spent a bit of time over the weekend trying to figure out how to force the RTS to collect GC statistics, but was unable to do so. I'm currently working on enriching criterion's ability to gather data, among which I'd like to see GC statistics. If I try to obtain GC stats using criterion when I'm

Re: [Haskell] ANNOUNCE: GHC version 7.8.3

2014-07-13 Thread Bryan O'Sullivan
On Sun, Jul 13, 2014 at 10:08 AM, Mark Lentczner wrote: > I'd like to be sure that my -P fix as part of the Platform fixes things. > Can you point me to a small package that that haddock fails on? Then I can > repro with the 7.8.3 bindist, and test the fix. > Using -P seems to work for me - than

Re: ANNOUNCE: GHC version 7.8.3

2014-07-13 Thread Bryan O'Sullivan
On Sun, Jul 13, 2014 at 10:51 AM, Carter Schonwald < carter.schonw...@gmail.com> wrote: > Bryan: what version of cabal-install do you have? I suspect it might be > because you have an older version of cabal install? > I have the very latest version. I'll have to retry with clang's cpp, though, as

Re: [Haskell] ANNOUNCE: GHC version 7.8.3

2014-07-13 Thread Bryan O'Sullivan
On Sun, Jul 13, 2014 at 10:08 AM, Mark Lentczner wrote: > I'd like to be sure that my -P fix as part of the Platform fixes things. > Can you point me to a small package that that haddock fails on? Then I can > repro with the 7.8.3 bindist, and test the fix. > Haddock was failing on just about ev

Re: [Haskell] ANNOUNCE: GHC version 7.8.3

2014-07-13 Thread Bryan O'Sullivan
It was exactly the clang cpp issue. Since I didn't know what I was doing, I reinstalled GHC telling it to use cpphs (at Carter's suggestion), and that worked. Thanks! > On Jul 13, 2014, at 7:35, Mark Lentczner wrote: > > If this is happening on OS X and your computer is really clang (gcc -ver

Re: [Haskell] ANNOUNCE: GHC version 7.8.3

2014-07-12 Thread Bryan O'Sullivan
On Fri, Jul 11, 2014 at 6:40 AM, Austin Seipp wrote: > The GHC Team is pleased to announce a new patchlevel release of GHC, 7.8.3. > haddock 2.14.3 that ships with it seems to be quite broken. Perhaps it's a bad interaction with cabal, it's hard to say from the outside, but here are some details

Re: Ghc 7.8 branch broken

2014-05-27 Thread Bryan O'Sullivan
On Tue, May 27, 2014 at 5:57 AM, Richard Eisenberg wrote: > To build the manual, yes, in my experience. Builds without the manual work > fine. > Perhaps adding --nonet to the xsltproc command line is in order. ___ ghc-devs mailing list ghc-devs@haskell.

Re: GHC status report

2014-05-02 Thread Bryan O'Sullivan
On Fri, May 2, 2014 at 10:19 AM, Edward Kmett wrote: > I may have to dig to find an example, but when I last checked it seemed > that c++ libraries would load fine, but there was a problem with static > initializers not getting called, when loading from ghci, so if your c++ > library needed them

Re: Out with the new, in with the old for the vector library WAS: [commit: packages/vector] ghc-head: Snapshot of the real 0.10.0.1 release (a3a65b5)

2013-11-14 Thread Bryan O'Sullivan
On Thu, Nov 14, 2013 at 11:25 AM, Geoffrey Mainland wrote: > Perhaps the roll-back in functionality was just done to get 7.8 out the > door? > That's correct. Also, the vector repo was never properly tagged, so it was impossible to untangle the work in progress on bundles from anything stable. __

Re: GHC HEAD vs Hackage, panic-free edition

2013-11-07 Thread Bryan O'Sullivan
On Sun, Oct 13, 2013 at 2:14 AM, Michael Snoyman wrote: > The issue with yesod-core was an issue from the underlying hamlet package. > hamlet has some internal functions which are used by the TH-generated code > it produces, and those internal functions were not previously exported. > With previou

Re: Why do we put GMP allocations on GHC heaps?

2013-10-23 Thread Bryan O'Sullivan
On Wed, Oct 23, 2013 at 4:31 AM, Gergely Risko wrote: > I can understand that this may be slower in CPU, but can you please > elaborate why would it be worse in memory, how the frees wouldn't happen > in a "timely manner"? I thought finalisers are called when the > referencee is GCd, so if we fr

Re: [commit: packages/unix] master: Fix assumption that RLIM_INFINITY is a simple number (b092e35)

2013-10-13 Thread Bryan O'Sullivan
On Sun, Oct 13, 2013 at 12:20 AM, Herbert Valerio Riedel wrote: > > unpackRLimit :: CRLim -> ResourceLimit > > unpackRLimit (#const RLIM_INFINITY) = ResourceLimitInfinity > > [...] > > I wonder though, how could that even have compiled in the past on OSX if > the expanded RLIM_INFINITY macro #d

Re: small improvement to roles mechanism

2013-10-12 Thread Bryan O'Sullivan
On Fri, Oct 11, 2013 at 7:17 PM, Mark Lentczner wrote: > Do I read Bryan's post correctly, that 20% of packages on hackage fail to > compile with GHC 7.8? > There are currently 5615 packages on Hackage. Of those, 3443 built successfully with 7.6.3 on my test machine yesterday, so let's call that

GHC HEAD vs Hackage, panic-free edition

2013-10-11 Thread Bryan O'Sullivan
Thanks to the efforts of the Simons, we now have a GHC that does not panic on any package that it's able to try compiling. Since the last report, the number of packages on Hackage has increased by 1.8%, from 5564 to 5604, but the number of failing builds has dropped by 4.2%, from 1186 to 1136. Thi

Re: GHC 7.8 Release Status & Schedule

2013-10-09 Thread Bryan O'Sullivan
On Sat, Oct 5, 2013 at 9:25 AM, Austin Seipp wrote: > - Nov 1st: Cut branch, and I plan on making a 7.8 RC1 available the > same day, for several platforms. > Hi, Austin - Thanks for writing this up. One of the factors that's blocking my ability to build Hackage packages is that Hackage does

HEAD vs Hackage status report

2013-09-29 Thread Bryan O'Sullivan
I spent a little time the other day building all of Hackage with GHC HEAD. Here's a quick writeup of what I found. Total packages: 5564 Succeeded with 7.6.3: 3234 Succeeded with HEAD: 2061 Succeeded with 7.6.3 *but failed with HEAD: 1186* (A few dozen packages built with HEAD, but not with 7.6.3,

Re: I've moved the primitive package to github

2013-09-24 Thread Bryan O'Sullivan
On Tue, Sep 24, 2013 at 6:17 PM, Herbert Valerio Riedel wrote: > However, I've tried integrating the new vector/primitive versions > released into the GHC build (after patching up the DPH libs), but I get > Core lint errors: > No clue. For me, the new releases of primitive and vector build happi

Re: I've moved the primitive package to github

2013-09-24 Thread Bryan O'Sullivan
On Tue, Sep 24, 2013 at 11:47 AM, Jan Stolarek wrote: > That's really surprising - I based them on code available at > http://code.haskell.org/primitive, > which I believe was version 0.5.0.1. Was there anything newer? > Oh, I was going on the versions that are in a repo on git.haskell.org. _

Re: I've moved the primitive package to github

2013-09-24 Thread Bryan O'Sullivan
On Tue, Sep 24, 2013 at 6:53 AM, Jan Stolarek wrote: > Austin, will you be > able to apply changes from my branch to upstream primitive? > Your patches are based on an outdated version of the library. I just wrote a new patch and applied it. It builds fine on several versions of GHC, so I tagged

I've moved the primitive package to github

2013-09-24 Thread Bryan O'Sullivan
Roman seems to have gone silent, and primitive being broken with GHC HEAD means that there's a ton of packages we can't build right now. Accordingly, I've imported the old darcs repo into git and published it on github. https://github.com/haskell/primitive Austin, please plan to fix the GHC buil

Re: 7.8 Release Update

2013-09-13 Thread Bryan O'Sullivan
On Fri, Sep 13, 2013 at 9:10 AM, Jan Stolarek wrote: > I suspect that we will be building against newer version of libgmp, but > the problem still remains. Would it be possible to ship libgmp with binary > distribution of GHC so that users don't have to rely on their distro > providing a precise v

Re: Haskell platform

2013-08-23 Thread Bryan O'Sullivan
On Fri, Aug 23, 2013 at 1:06 AM, Simon Peyton-Jones wrote: > They [happy,alex] are in /lib/extralibs/bin now for some reason. > The HP installer should have added that to the PATH though. > > That seems like an oversight - I can't think of a good reason to have them in a different bin directo

Re: 7.8 Feature window

2013-08-21 Thread Bryan O'Sullivan
On Tue, Aug 20, 2013 at 10:01 AM, Austin Seipp wrote: > There are a few things we know for sure are - or were - tentatively > scheduled for this release: > > * SIMD improvements > * New Template Haskell > * Constraint solver for type naturals > I have some additional optimizations to the new

Re: Adding constant folding for Integer div and mod

2013-07-19 Thread Bryan O'Sullivan
On Fri, Jul 19, 2013 at 9:58 AM, Jan Stolarek wrote: > It seems that currently there are no built-in constant folding rules for > Integer div and mod. I plan on adding those rules, but before I do that I > wanted to ask whether there is a good reason that these rules don't exist? > I would guess

Any interest in moving GHC issues / wiki to github?

2013-07-05 Thread Bryan O'Sullivan
We have a repeated problem with the GHC wiki and issue tracker getting filled with spam, and the server is currently taking about a minute to respond to each attempt to load a web page. I wonder if anyone would be open to us migrating the content to github instead. (Actually, while I'm at it, clon

Can't build a ghc cloned from github

2013-07-05 Thread Bryan O'Sullivan
There appears to be a bad ref on the server for the Cabal repo: == running git submodule update error: Unable to find b4d0c0f2846542dc2e2df189fe145a56ac9b30b6 under http://darcs.haskell.org/libraries/Cabal.git Cannot obtain needed object b4d0c0f2846542dc2e2df189fe145a56ac9b30b6 while processing co

Re: STM Commentary

2013-05-20 Thread Bryan O'Sullivan
On Mon, May 20, 2013 at 12:29 PM, Carter Schonwald < carter.schonw...@gmail.com> wrote: > you have access to hardware for testing HTM? I thought haswell wasn't > publicly available yet... > Intel's been handing out sample hardware for a while. ___ ghc-d

Re: Turning on -funbox-small-strict-fields by default in GHC 7.8

2013-04-25 Thread Bryan O'Sullivan
On Thu, Apr 25, 2013 at 10:32 PM, Johan Tibell wrote: > If you remember where it would be great to see an example. > I'm afraid I don't remember. I spend a lot of time optimising things down to the last memory allocation, and this was one of those cases where I could keep heap allocation constant

Re: Turning on -funbox-small-strict-fields by default in GHC 7.8

2013-04-25 Thread Bryan O'Sullivan
On Thu, Apr 25, 2013 at 4:01 PM, Johan Tibell wrote: > I think you could make up a case where it is a loss. It would boil down to > repeated reboxing of a value pulled out of a strict field. In practice I > think it's pretty hard. I've seen this in real-world code, though it is indeed rare in my

Re: Why not rebase instead of merge?

2013-02-22 Thread Bryan O'Sullivan
On Fri, Feb 22, 2013 at 9:12 AM, Geoffrey Mainland wrote: > That's a good reason. Might it be time to revisit the question? > Surely this isn't important at all? ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-

Re: GHC 7.8 release?

2013-02-08 Thread Bryan O'Sullivan
On Fri, Feb 8, 2013 at 1:29 AM, Tim Watson wrote: > Likewise, I'm in the process of setting up Elastic Bamboo on EC2 for Cloud > Haskell and would be very interested in seeing how you've dealt with > multiple versions of GHC. > It's easy to parameterize builds in Jenkins based on different value

Re: nofib regressions in HEAD since 7.6.2 release

2013-02-08 Thread Bryan O'Sullivan
On Thu, Feb 7, 2013 at 1:18 PM, Johan Tibell wrote: > I just ran nofib on current HEAD and compared it to 7.6.2 on my 64-bit > Linux machine. There are some regressions I think we should look into > before a release: > It would be interesting to see the numbers compared to 7.6.1, if possible, as

Re: simd branch ready for review

2013-01-31 Thread Bryan O'Sullivan
On Thu, Jan 31, 2013 at 12:30 PM, Geoffrey Mainland wrote: > 2) SSE support is processor and platform dependent. What is the proper > way for the programmer to know what SSE primitives are available? A CPP > define? If so, what should it be called? > This needs a combination of compile-time and r