I too was seeing this with RC1, but I haven't tried RC2. Looking at the commits on the 7.4 branch, I don't see anything that would have likely affected/fixed it, so I speculate I'll see the same thing with RC2. I'll try tonight and report back. I will note that manually built copies of HEAD work just dandy. I do wonder if it's a problem with the binary distribution itself, as opposed to some bug fix that didn't get merged into 7.4. I wonder if I built my own copy and binary-dist of 7.4 if GHCi would segfault or not - this would indicate it being a problem with the binary distribution if it doesn't (which sucks, as it means you have to compile it yourself.) Ian, can I ask what the procedure would be to check out the 7.4 branch of GHC and all the associated libraries to try this out? I'm not familiar with all the `sync-all`-fu, but I speculate it's what'll do it. :) On Fri, Jan 27, 2012 at 10:57 PM, Evan Laforge wrote:

Unfortunately ghci still segfaults for me most times (the previous release candidate did too).  Anyone else seeing this?  What should I do to troubleshoot?

OS X 10.6.8, using GHC-7.4.0.20120126-x86_64.pkg

I'll try GHC-7.4.0.20120126-i386.pkg in a bit, but I probably do need the 64 bit version, previously I had to hassle around with the 32bit version because it didn't want to link with all the other 64 bit compiled code.

Also, I notice that the ghc, ghci, ghc-pkg, and haddock links are all versioned, but not hsc2hs.  hsc2hs is also highly dependent on the ghc version so it should be versioned too!  I suppose this is for the mac package maintainer (Mark M, that's you, right?).  What I mean by versioned is that the other binaries have a ghc and then a ghc-$version link, so I can switch ghc versions by running a little shell script.  But for hsc2hs I have to create the hsc2h-$version link first.  Not a big deal, just a minor quibble.

On Fri, Jan 27, 2012 at 3:15 PM, Ian Lynagh wrote:

...

We are pleased to announce the first release candidate for GHC 7.4.1:

   http://www.haskell.org/ghc/dist/7.4.1-rc2/

This includes the source tarball, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD.

Please test as much as possible; bugs are much cheaper if we find them before the release!

We expect this to be the last release candidate, with the final release in approximately 1 week's time.

Thanks Ian, on behalf of the GHC team

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-- Regards, Austin

On Fri, Jan 27, 2012 at 08:57:35PM -0800, Evan Laforge wrote:

Unfortunately ghci still segfaults for me most times (the previous release candidate did too). Anyone else seeing this? What should I do to troubleshoot?

OS X 10.6.8, using GHC-7.4.0.20120126-x86_64.pkg

Ah, sorry, I should have said: The OS X installer (and the bindist) is known to work on OS X 10.7.2 with Xcode 4.1, and will not work with some older versions (I don't know if it's older versions of OS X or of XCode that cause problems). If you build GHC yourself on an older version, then the result should work. Thanks Ian

On Sat, Jan 28, 2012 at 6:52 AM, Sanket Agrawal wrote:

The reason I am asking is I want to try LLVM backend but GHC keeps complaining about missing llvm tools (opt, llc). I checked LLVM webpage but couldn't find information about how to determine what llvm tools are installed on my Mac. My guess is XCode 4.1 comes with llvm backend for GCC, but not standalone LLVM tools that GHC needs, and that upgrading to XCode 4.2 would give me LLVM 3.0 tools as well. Please correct me if I got it wrong.

I just downloaded the LLVM binaries and put them somewhere on my PATH. -- Johan

On Jan 28, 2012 11:14 AM, "Sanket Agrawal" wrote:

Yes, that is another possibility. I would like to keep it simple, and just upgrade to XCode 4.2, instead of installing Clang+LLVM binaries separately, if it is not an issue for GHC.

Xcode 4.2 doesn't include full LLVM either; moreover, what it does have is an llvm3 prerelease that apparently doesn't work with -fllvm. -- ...tabula non rasa (brandon s allbery kf8nh on the padd)

Ian, Thanks for pointing this out. I run XCode 4 (and haven't had the opportunity to upgrade.) Would it be reasonable to make a binary distribution for people like Evan and Me and hopefully have it put on the download page? I presume the people in our boat are actually pretty small in number (OS X users are fairly keen to upgrade pretty quickly,) but it would be nice to not have to build it ourselves if that's the case. On Sat, Jan 28, 2012 at 7:55 AM, Ian Lynagh wrote:

On Fri, Jan 27, 2012 at 08:57:35PM -0800, Evan Laforge wrote:

...

Unfortunately ghci still segfaults for me most times (the previous release candidate did too).  Anyone else seeing this?  What should I do to troubleshoot?

OS X 10.6.8, using GHC-7.4.0.20120126-x86_64.pkg

Ah, sorry, I should have said:

The OS X installer (and the bindist) is known to work on OS X 10.7.2 with Xcode 4.1, and will not work with some older versions (I don't know if it's older versions of OS X or of XCode that cause problems).

If you build GHC yourself on an older version, then the result should work.

Thanks Ian

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-- Regards, Austin

On Sat, Jan 28, 2012 at 05:09:20PM -0600, Austin Seipp wrote:

I run XCode 4 (and haven't had the opportunity to upgrade.) Would it be reasonable to make a binary distribution for people like Evan and Me and hopefully have it put on the download page?

If someone makes a bindist and/or installer then I can add it to the download page. Thanks Ian

On Sun, Jan 29, 2012 at 5:12 PM, Austin Seipp wrote:

I've done so, and have an RC2 bindist that doesn't have a segfaulting GHCi. I suppose this build should be advocated to Snow Leopard users.

I currently need a place to put the bindist. I'm about to send an email to community.haskell.org to get my code.haskell.org SSH keys updated, and I'll then be able to upload the RC2 bindist there and follow up here (so people like Evan can give it a shot.)

If nobody else is opposed, I'll take care of finding out how to build an OS X pkg, and provide that and a bindist for SL once the release goes final.

Did you ever make any progress here? I'm thinking of building one myself, but if there's already a package out there it would be easier to use that.

On Fri, Feb 10, 2012 at 10:59 AM, Austin Seipp wrote:

Sorry, I got caught up doing a few other things the past few days.

I'll make a binary of the 7.4.1 release later today and upload it to my code.haskell.org account and report back here (the uploading will take as long as the build, due to bad internet right now...)

Thanks, waiting eagerly :) Meanwhile, I tried compiling myself, but got hung up in compiler/deSugar/Coverage.lhs, where it's not importing getModificationTime from System.Directory, but if I import that then we have disagreements about whether the result should be Integer, ClockTime, or UTCTime. I'm guessing this is due to recent changes from old-time to time, and it makes me think if I patch these up there will just be other problems later, so I must be doing something wrong. Either download the 7.4.1 source distribution (I'm using the 7.4 git branch), or go install 7.2 and compile with that... I don't know if the tree is just temporarily broken or if I'm supposed to be doing something to insert a compatibility shim.

Evan, I've finished making a binary distribution and a .pkg installer for OS X (partly delayed due to terrible internet at the moment.) The binary distribution and GHC package, as well as md5 sums, can be found here: http://code.haskell.org/~thoughtpolice/ghc-741-osx-sl/ If anybody else would like to test this, I'd be very appreciative. Providing the feedback is good, this can hopefully be put on the download page for Snow Leopard users. On Sun, Feb 12, 2012 at 7:13 PM, Evan Laforge wrote:

On Sun, Feb 12, 2012 at 3:05 PM, Evan Laforge wrote:

...

On Fri, Feb 10, 2012 at 10:59 AM, Austin Seipp wrote:

...

Sorry, I got caught up doing a few other things the past few days.

I'll make a binary of the 7.4.1 release later today and upload it to my code.haskell.org account and report back here (the uploading will take as long as the build, due to bad internet right now...)

Thanks, waiting eagerly :)  Meanwhile, I tried compiling myself, but got hung up in compiler/deSugar/Coverage.lhs, where it's not importing getModificationTime from System.Directory, but if I import that then we have disagreements about whether the result should be Integer, ClockTime, or UTCTime.  I'm guessing this is due to recent changes

Never mind me.  For anyone else who might care: compile from the source distribution, not from the git branch.  And don't run out of disk space halfway through :)

-- Regards, Austin

On Sat, Jan 28, 2012 at 08:32:31PM +0400, Serge D. Mechveliani wrote:

On Fri, Jan 27, 2012 at 11:15:46PM +0000, Ian Lynagh wrote:

...

We are pleased to announce the first release candidate for GHC 7.4.1:

http://www.haskell.org/ghc/dist/7.4.1-rc2/

The first candidate or the second?

Sorry, copy-and-paste error. This is the second release candidate.

(for the date is Jan 27). Is ghc-7.4.0.20111219 the first candidate?

Yes.

Also people already reported a couple of bugs for 7.4.1-rc2/. So, is there going to be the third candidate?

That's very unlikely.

If not, then I'll, probably, have to test this second candidate

That would be great, thanks! Thanks Ian

Austin The ticket (#5719) says "merge if you like but I don't think it's needed". No one complained at the time, so Ian didn't merge it. He's tried merging just the patches you identify, but they don't merge cleanly any more. So I'm afraid this particular fix won't be in 7.4. Sorry. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Austin Seipp | Sent: 29 January 2012 02:27 | To: glasgow-haskell-users@haskell.org | Subject: Re: ANNOUNCE: GHC 7.4.1 Release Candidate 2 | | Hello again Ian, | | I noticed that in December, Bas van Dijk reported a bug in the | implementation of ConstraintKinds/associated type defaults, and the | fix wasn't merged to 7.4.1. | | The relevant email thread is archived here: | | http://www.haskell.org/pipermail/glasgow-haskell-users/2011- | December/021318.html | | The relevant trac ticket is #5719 here: | | http://hackage.haskell.org/trac/ghc/ticket/5719 | | The example in the ticket does not type-check with GHC 7.4.1-rc2, but | it does with a copy of HEAD. There seem to be 2 commits that are | relevant to this issue: | | https://github.com/ghc/ghc/commit/416c5903f3b8cf4cdd4a03c8949489df18cd790a | | https://github.com/ghc/ghc/commit/8785726b57ccd44c5451385de61913a79fe02eb7 | | Would it be possible to have these merged into the 7.4 branch before | release? They fix the issue Bas reported, and eliminate the need for | his kludgy fix which uses an Empty typeclass to get around the issue. | It makes turning Set into a Functor much cleaner in this case, IMO. | | | | On Fri, Jan 27, 2012 at 5:15 PM, Ian Lynagh wrote: | > | > We are pleased to announce the first release candidate for GHC 7.4.1: | > | >    http://www.haskell.org/ghc/dist/7.4.1-rc2/ | > | > This includes the source tarball, installers for OS X and Windows, and | > bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. | > | > Please test as much as possible; bugs are much cheaper if we find them | > before the release! | > | > We expect this to be the last release candidate, with the final release | > in approximately 1 week's time. | > | > | > Thanks | > Ian, on behalf of the GHC team | > | > | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users@haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | | | | -- | Regards, | Austin | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Trac #5623 is very much on my radar; it's just that I have been too snowed under to get to it. It's not entirely straightforward because the inlining machinery needs careful modification, lest one fix one performance bug only to introduce another. So the bug is still in 7.4 I'm afraid. I will get to it, but I'm very interested to have feedback from anyone who actually trips over it in practice; if you do, please add to the ticket. http://hackage.haskell.org/trac/ghc/ticket/5623 Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Rene de Visser | Sent: 30 January 2012 19:15 | To: glasgow-haskell-users@haskell.org | Subject: Re: ANNOUNCE: GHC 7.4.1 Release Candidate 2 | | What are the plans for http://hackage.haskell.org/trac/ghc/ticket/5623 which | seems to be still open? | | Quoting form the ticket ... | Just to spam a little more, it seems that the HEAD happily duplicates all | computations on unboxed types. It even duplicates x+x in this example: | | foo :: Float -> Float | foo x = let y = x+x in y+yI haven't tested but this looks bad for | performance critical code. | | Rene. | | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Hi there. First of all: I'm aware that the current situation with cabal-install is suboptimal and a new release it desperately needed. Still, some general advice and attempts at explaining strange behaviour: On Wed, Feb 1, 2012 at 8:05 AM, Evan Laforge wrote:

So it embarrasses me to admit it, but I'm having the same problem I always have when I install a new ghc, and that's cabal and cabal install.

Whenever you install GHC successfully, you *have* a version of Cabal (the library) already. It's used by GHC to build GHC. There shouldn't be any need to touch it. For the current GHC 7.4.1 release candidate, that version is 1.14.0. About cabal-install:

I downloaded the latest cabal-install from http://hackage.haskell.org/package/cabal-install and that was a mistake right off.

Assuming you upgraded, you probably had an old version of cabal-install. You should be able to keep using it for the time being. The cabal binary picks up the GHC that's currently in path (or the one you explicitly specify via --with-ghc). There's no requirement to use it with the GHC version that it has been built with.

After fiddling around I figured out I apparently need the one bundled with ghc... and sure enough, the source version has a cabal-install-0.13.3.

The current development version is indeed at 0.13.3, but since it's in development, your copy might or might not have the latest patches. The definitive darcs repository for both Cabal and cabal-install is at: darcs get http://darcs.haskell.org/cabal/

This one has newer but also has out of date dependencies:

Configuring cabal-install-0.13.3... Setup.hs: At least the following dependencies are missing: Cabal >=1.13.3 && <1.14, base >=2.0 && <2.2, filepath >=1.0 && <1.3, time >=1.1 && <1.3,

This seems to indicate that you haven't tried with the current development version of cabal-install. The dependency ranges have been updated to allow building with the ghc-7.4.1 release candidate.

But shouldn't cabal-install be updated for the version of ghc it's with?  I cloned branch 7.4 and did a ./sync-all pull so I should have the latest version, right?

I wasn't actually aware that cabal-install is included in the ghc tree and can be pulled via sync-all. I'll try to reproduce what you did and see if there's anything wrong.

And how are other people testing this out if cabal-install has out of date dependencies?  And strangest, why is the 'base' dependency so old?

That's a consequence of how Cabal tries to resolve dependencies. There are multiple flags in the .cabal file (to allow it to build with older or strange configurations), and once the default flag settings fail, Cabal will automatically try other assignments. If all assignments fail, it will complain about the missing dependencies for the flag assignment it tried last. So there isn't really a dependency on such an old version of base.

And while I'm wondering about cabal, why on earth is it that so many Setup.hs files are actually Setup.lhs and with no actual literate contents?

Does it really matter? Cheers, Andres

...

I downloaded the latest cabal-install from http://hackage.haskell.org/package/cabal-install and that was a mistake right off.

Assuming you upgraded, you probably had an old version of cabal-install. You should be able to keep using it for the time being. The cabal binary picks up the GHC that's currently in path (or the one you explicitly specify via --with-ghc). There's no requirement to use it with the GHC version that it has been built with.

In fact it's a new install from scratch, no previous ghc. I didn't see why I should install a bunch of stuff I didn't plan on using (I do main development on another machine), but maybe I should have installed the platform first, and then replaced the ghc.

...

After fiddling around I figured out I apparently need the one bundled with ghc... and sure enough, the source version has a cabal-install-0.13.3.

The current development version is indeed at 0.13.3, but since it's in development, your copy might or might not have the latest patches. The definitive darcs repository for both Cabal and cabal-install is at:

 darcs get http://darcs.haskell.org/cabal/

Ah, I'll give that a try as soon as I get back home.

...

And how are other people testing this out if cabal-install has out of date dependencies?  And strangest, why is the 'base' dependency so old?

That's a consequence of how Cabal tries to resolve dependencies. There are multiple flags in the .cabal file (to allow it to build with older or strange configurations), and once the default flag settings fail, Cabal will automatically try other assignments. If all assignments fail, it will complain about the missing dependencies for the flag assignment it tried last. So there isn't really a dependency on such an old version of base.

Thanks for the explanation. I'd seen this kind of behaviour from cabal before, and noted that the constraint does exist under certain flags, but didn't understand how it would choose a particular flag if I didn't pass it.

...

And while I'm wondering about cabal, why on earth is it that so many Setup.hs files are actually Setup.lhs and with no actual literate contents?

Does it really matter?

It's not of great importance. But it means the Setup names are unpredictable so using shell history tends to fail, I have to remember to complete with tab and not automatically type "Setup.hs", simple shell functions tend to break, etc. I was more curious about how it happens so much in the first place. My best guess is that someone at the very beginning had an "everything lhs" style, and then most people simply copy another project's Setup, so it's a sort of founder's effect. To be honest it probably mostly piques my sense of tidiness. On Wed, Feb 1, 2012 at 8:16 AM, Simon Hengel wrote:

Are you referring to the classical pattern, that allows you to add a shebang?

   #!/usr/bin/env runhaskell

   > import Distribution.Simple    > main = defaultMain

Ohh, so it's a trick to allow #! in there... I guess that would explain it! I just type runghc on everything and it seems like a lot of those don't have the executable bit set, so I hadn't thought of that reason.

On Wednesday 01 February 2012, 19:08:16, Evan Laforge wrote:

On Wed, Feb 1, 2012 at 8:16 AM, Simon Hengel wrote:

...

Are you referring to the classical pattern, that allows you to add a shebang?

#!/usr/bin/env runhaskell

...

import Distribution.Simple main = defaultMain

Ohh, so it's a trick to allow #! in there... I guess that would explain it! I just type runghc on everything and it seems like a lot of those don't have the executable bit set, so I hadn't thought of that reason.

That may have been the idea, but doesn't make a difference. GHC allows a shebang line as the first line of a file also in .hs files.

And while I'm wondering about cabal, why on earth is it that so many Setup.hs files are actually Setup.lhs and with no actual literate contents?

Are you referring to the classical pattern, that allows you to add a shebang? #!/usr/bin/env runhaskell > import Distribution.Simple > main = defaultMain Cheers, Simon