|
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: 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, 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. _______________________________________________ Glasgow-haskell-users mailing list [hidden email] 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 <[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. 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 _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
In reply to this post by Austin Seipp
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: [hidden email] [mailto:glasgow-haskell- | [hidden email]] On Behalf Of Austin Seipp | Sent: 29 January 2012 02:27 | To: [hidden email] | 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 <[hidden email]> 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 | > [hidden email] | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | | | | -- | Regards, | Austin | | _______________________________________________ | Glasgow-haskell-users mailing list | [hidden email] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
In reply to this post by Andres Löh-2
On Wed, Feb 01, 2012 at 09:00:05AM +0100, Andres Löh wrote:
> > I wasn't actually aware that cabal-install is included in the ghc tree > and can be pulled via sync-all. It's only in the GHC tree because it lives in the same darcs repository as Cabal (the library) now. The code in the GHC tree is not intended to be used. Thanks Ian _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
In reply to this post by Rene de Visser
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: [hidden email] [mailto:glasgow-haskell- | [hidden email]] On Behalf Of Rene de Visser | Sent: 30 January 2012 19:15 | To: [hidden email] | 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 | [hidden email] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
In reply to this post by Evan Laforge
> 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 _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
In reply to this post by Andres Löh-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. 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. _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
> 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. I think this is most eminent with Darcs repos. Darcs can't revision file permissions (--set-scripts-executable tries to remedy that). Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
In reply to this post by Evan Laforge
On Wednesday 01 February 2012, 19:08:16, Evan Laforge wrote:
> 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. _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
On Sun, 2012-02-05 at 04:41 +0100, Daniel Fischer wrote:
> 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. ...except when enabling the CPP language extension, then you get a shebang.hs:1:0: error: invalid preprocessing directive #! phase `C pre-processor' failed (exitcode = 1) _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
In reply to this post by Austin Seipp
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. _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
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...) On Fri, Feb 10, 2012 at 12:56 PM, Evan Laforge <[hidden email]> wrote: > 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. -- Regards, Austin _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
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. _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
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 :) _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
|
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 <[hidden email]> wrote: > 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 :) -- Regards, Austin _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
| Powered by Nabble | Edit this page |
