ANNOUNCE: GHC 7.4.1 Release Candidate 2

Re: ANNOUNCE: GHC 7.4.1 Release Candidate 2

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.

I downloaded the latest cabal-install from
http://hackage.haskell.org/package/cabal-install and that was a
mistake right off. 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. This one has newer but also has out of
date dependencies:

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? 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?

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?

Oh, and before I could have any of those problems, the binary
distribution itself didn't want to install: it was evidently compiled
against libgmp3 and archlinux is now installing libgmp5 with no option
to downgrade (though oddly it calls it .10 in the so file). I tracked
down an old libgmp and install with tar since arch doesn't seem to
want more than one libgmp installed simultaneously.

I don't know how many other linuxes out there do this, but I know I'm
not the only archlinux using haskell user.

Re: ANNOUNCE: GHC 7.4.1 Release Candidate 2

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 <[hidden email]> 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.

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:

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?

RE: ANNOUNCE: GHC 7.4.1 Release Candidate 2

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.

RE: ANNOUNCE: GHC 7.4.1 Release Candidate 2

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.

Re: ANNOUNCE: GHC 7.4.1 Release Candidate 2

>> 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.

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.

Re: ANNOUNCE: GHC 7.4.1 Release Candidate 2

> On Wed, Feb 1, 2012 at 8:16 AM, Simon Hengel <[hidden email]> 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.

Re: ANNOUNCE: GHC 7.4.1 Release Candidate 2

> 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 Sun, Jan 29, 2012 at 5:12 PM, Austin Seipp <[hidden email]> 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.

Re: ANNOUNCE: GHC 7.4.1 Release Candidate 2

On Fri, Feb 10, 2012 at 10:59 AM, Austin Seipp <[hidden email]> 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.

Re: ANNOUNCE: GHC 7.4.1 Release Candidate 2

> On Fri, Feb 10, 2012 at 10:59 AM, Austin Seipp <[hidden email]> 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 :)

> On Sun, Feb 12, 2012 at 3:05 PM, Evan Laforge <[hidden email]> wrote:
>> On Fri, Feb 10, 2012 at 10:59 AM, Austin Seipp <[hidden email]> 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 :)