From ezyang at mit.edu Fri Aug 8 12:00:37 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 08 Aug 2014 13:00:37 +0100 Subject: HEADS UP: Running cabal install with the latest GHC Message-ID: <1407498991-sup-1278@sabre> Hey all, SPJ pointed out to me today that if you try to run: cabal install --with-ghc=/path/to/inplace/bin/ghc-stage2 with the latest GHC HEAD, this probably will not actually work, because your system installed version of Cabal is probably too old to deal with the new package key stuff in HEAD. So, how do you get a version of cabal-install (and Cabal) which is new enough to do what you need it to? The trick is to compile Cabal using your /old/ GHC. Step-by-step, this involves cd'ing into libraries/Cabal/Cabal and running `cabal install` (or install it in a sandbox, if you like) and then cd'ing to libraries/Cabal/cabal-install and cabal install'ing that. Cabal devs, is cutting a new release of Cabal and cabal-install in the near future possible? In that case, users can just cabal update; cabal install cabal-install and get a version of Cabal which will work for them. Cheers, Edward From johan.tibell at gmail.com Fri Aug 8 21:02:25 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Fri, 8 Aug 2014 23:02:25 +0200 Subject: HEADS UP: Running cabal install with the latest GHC In-Reply-To: <1407498991-sup-1278@sabre> References: <1407498991-sup-1278@sabre> Message-ID: I'm not again putting out another release, but I'd prefer to make it on top of 1.20 if possible. Making a 1.22 release takes much more work (RC time, etc). Which are the patches in question. Can they easily be cherry-picked onto the 1.20 branch? Are there any risk of breakages? On Fri, Aug 8, 2014 at 2:00 PM, Edward Z. Yang wrote: > Hey all, > > SPJ pointed out to me today that if you try to run: > > cabal install --with-ghc=/path/to/inplace/bin/ghc-stage2 > > with the latest GHC HEAD, this probably will not actually work, because > your system installed version of Cabal is probably too old to deal with > the new package key stuff in HEAD. So, how do you get a version > of cabal-install (and Cabal) which is new enough to do what you need > it to? > > The trick is to compile Cabal using your /old/ GHC. Step-by-step, this > involves cd'ing into libraries/Cabal/Cabal and running `cabal install` > (or install it in a sandbox, if you like) and then cd'ing to > libraries/Cabal/cabal-install and cabal install'ing that. > > Cabal devs, is cutting a new release of Cabal and cabal-install in the > near future possible? In that case, users can just cabal update; cabal > install cabal-install and get a version of Cabal which will work for > them. > > Cheers, > Edward > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Fri Aug 8 21:17:45 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 08 Aug 2014 22:17:45 +0100 Subject: HEADS UP: Running cabal install with the latest GHC In-Reply-To: References: <1407498991-sup-1278@sabre> Message-ID: <1407532120-sup-5118@sabre> They would be: 2b50d0a Fix regression for V09 test library handling. d3a696a Disable reinstalls with distinct package keys for now. 1d33c8f Add $pkgkey template variable, and use it for install paths. 41610a0 Implement package keys, distinguishing packages built with different deps/flags Unfortunately, these patches fuzz a bit without this next patch: 62450f9 Implement "reexported-modules" field, towards fixing GHC bug #8407. When you include that patch, there is only one piece of fuzz from 41610a0. One important caveat is that these patches do rearrange some of the API, so you wouldn't be able to build GHC 7.8 against these patches. So maybe we don't want to. If we had a way of releasing experimental, non-default picked up versions, that would be nice (i.e. Cabal 1.21). No warranty, but easy enough for GHC devs to say 'cabal install Cabal-1.21 cabal-install-1.21' or something. Edward Excerpts from Johan Tibell's message of 2014-08-08 22:02:25 +0100: > I'm not again putting out another release, but I'd prefer to make it on top > of 1.20 if possible. Making a 1.22 release takes much more work (RC time, > etc). Which are the patches in question. Can they easily be cherry-picked > onto the 1.20 branch? Are there any risk of breakages? > > On Fri, Aug 8, 2014 at 2:00 PM, Edward Z. Yang wrote: > > > Hey all, > > > > SPJ pointed out to me today that if you try to run: > > > > cabal install --with-ghc=/path/to/inplace/bin/ghc-stage2 > > > > with the latest GHC HEAD, this probably will not actually work, because > > your system installed version of Cabal is probably too old to deal with > > the new package key stuff in HEAD. So, how do you get a version > > of cabal-install (and Cabal) which is new enough to do what you need > > it to? > > > > The trick is to compile Cabal using your /old/ GHC. Step-by-step, this > > involves cd'ing into libraries/Cabal/Cabal and running `cabal install` > > (or install it in a sandbox, if you like) and then cd'ing to > > libraries/Cabal/cabal-install and cabal install'ing that. > > > > Cabal devs, is cutting a new release of Cabal and cabal-install in the > > near future possible? In that case, users can just cabal update; cabal > > install cabal-install and get a version of Cabal which will work for > > them. > > > > Cheers, > > Edward > > _______________________________________________ > > cabal-devel mailing list > > cabal-devel at haskell.org > > http://www.haskell.org/mailman/listinfo/cabal-devel > > From johan.tibell at gmail.com Wed Aug 13 14:12:13 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 13 Aug 2014 16:12:13 +0200 Subject: HEADS UP: Running cabal install with the latest GHC In-Reply-To: <1407532120-sup-5118@sabre> References: <1407498991-sup-1278@sabre> <1407532120-sup-5118@sabre> Message-ID: Edward made some changes so that GHC 7.10 is backwards compatible with older cabals (older cabals just can't use the new goodies, that's all), which means that we won't need an earlier release. I'm still aiming for another major release before 7.10? When's 7.10 scheduled before? On Fri, Aug 8, 2014 at 11:17 PM, Edward Z. Yang wrote: > They would be: > > 2b50d0a Fix regression for V09 test library handling. > d3a696a Disable reinstalls with distinct package keys for now. > 1d33c8f Add $pkgkey template variable, and use it for install paths. > 41610a0 Implement package keys, distinguishing packages built with > different deps/flags > > Unfortunately, these patches fuzz a bit without this next patch: > > 62450f9 Implement "reexported-modules" field, towards fixing GHC bug > #8407. > > When you include that patch, there is only one piece of fuzz from > 41610a0. > > One important caveat is that these patches do rearrange some of the API, > so you wouldn't be able to build GHC 7.8 against these patches. So > maybe we don't want to. > > If we had a way of releasing experimental, non-default picked up > versions, that would be nice (i.e. Cabal 1.21). No warranty, but > easy enough for GHC devs to say 'cabal install Cabal-1.21 > cabal-install-1.21' or something. > > Edward > > Excerpts from Johan Tibell's message of 2014-08-08 22:02:25 +0100: > > I'm not again putting out another release, but I'd prefer to make it on > top > > of 1.20 if possible. Making a 1.22 release takes much more work (RC time, > > etc). Which are the patches in question. Can they easily be cherry-picked > > onto the 1.20 branch? Are there any risk of breakages? > > > > On Fri, Aug 8, 2014 at 2:00 PM, Edward Z. Yang wrote: > > > > > Hey all, > > > > > > SPJ pointed out to me today that if you try to run: > > > > > > cabal install --with-ghc=/path/to/inplace/bin/ghc-stage2 > > > > > > with the latest GHC HEAD, this probably will not actually work, because > > > your system installed version of Cabal is probably too old to deal with > > > the new package key stuff in HEAD. So, how do you get a version > > > of cabal-install (and Cabal) which is new enough to do what you need > > > it to? > > > > > > The trick is to compile Cabal using your /old/ GHC. Step-by-step, this > > > involves cd'ing into libraries/Cabal/Cabal and running `cabal install` > > > (or install it in a sandbox, if you like) and then cd'ing to > > > libraries/Cabal/cabal-install and cabal install'ing that. > > > > > > Cabal devs, is cutting a new release of Cabal and cabal-install in the > > > near future possible? In that case, users can just cabal update; cabal > > > install cabal-install and get a version of Cabal which will work for > > > them. > > > > > > Cheers, > > > Edward > > > _______________________________________________ > > > cabal-devel mailing list > > > cabal-devel at haskell.org > > > http://www.haskell.org/mailman/listinfo/cabal-devel > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Wed Aug 13 14:22:14 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Wed, 13 Aug 2014 16:22:14 +0200 Subject: HEADS UP: Running cabal install with the latest GHC In-Reply-To: References: <1407498991-sup-1278@sabre> <1407532120-sup-5118@sabre> Message-ID: Hi, On 13 August 2014 16:12, Johan Tibell wrote: > I'm still aiming for another > major release before 7.10? When's 7.10 scheduled before? End of the year, I think. From the.dead.shall.rise at gmail.com Wed Aug 13 14:50:42 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Wed, 13 Aug 2014 16:50:42 +0200 Subject: HEADS UP: Running cabal install with the latest GHC In-Reply-To: References: <1407498991-sup-1278@sabre> <1407532120-sup-5118@sabre> Message-ID: Hi, On 13 August 2014 16:22, Mikhail Glushenkov wrote: > End of the year, I think. Correction: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 says "February 2015". From daniel.trstenjak at gmail.com Thu Aug 14 18:15:27 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Thu, 14 Aug 2014 20:15:27 +0200 Subject: cabal sandbox and the dist directory Message-ID: <20140814181527.GA18679@machine> Hi, currently it's conceptually and practically a bit unpleasant, that the sandbox is a bit holey, because the 'dist' directory remains when deleting the sandbox. Is there a special reason for this behaviour? In the case of a sandbox, why is there a 'dist' directory at all, respectively why isn't it located inside of the '.cabal-sandbox' directory? Greetings, Daniel From johan.tibell at gmail.com Thu Aug 14 18:57:15 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 14 Aug 2014 20:57:15 +0200 Subject: cabal sandbox and the dist directory In-Reply-To: <20140814181527.GA18679@machine> References: <20140814181527.GA18679@machine> Message-ID: Hi Daniel, I think we eventually want to move dist/ inside the sandbox and eventually move the sandbox out of the package directory too. This is too support a world which is less focused on a single package. See my answer here: http://stackoverflow.com/questions/25278996/cabal-test-in-a-sandbox?noredirect=1#comment39425358_25278996 On Thu, Aug 14, 2014 at 8:15 PM, Daniel Trstenjak < daniel.trstenjak at gmail.com> wrote: > > Hi, > > currently it's conceptually and practically a bit unpleasant, that the > sandbox is a bit holey, because the 'dist' directory remains when > deleting the sandbox. > > Is there a special reason for this behaviour? > > In the case of a sandbox, why is there a 'dist' directory at all, > respectively why isn't it located inside of the '.cabal-sandbox' directory? > > > Greetings, > Daniel > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bneijt at gmail.com Thu Aug 14 20:25:15 2014 From: bneijt at gmail.com (Bram Neijt) Date: Thu, 14 Aug 2014 22:25:15 +0200 Subject: cabal sandbox and the dist directory In-Reply-To: References: <20140814181527.GA18679@machine> Message-ID: I found the dist directory still being there a nice feature. For each project I want to start I want the newest stuff, but some of my longer running things tend to require older dependencies and I don't want to have to upgrade. This means that I have multiple small project that could share a 700MB sandbox, while my larger projects can have their own. What I do is use a single sandbox and symlink the cabal.sandbox.config file in place. This means there is no .cabal-sandbox next to my code, but there is a dist directory, which I use to run the executable and inspect the build artifacts. [1] Moving dist into cabal-sandbox would mean that I would have to either symlink my dist in also, or use the full path to my sandbox location every time I want to look at the build artifacts. How would you easily share a sandbox between multiple projects if dist is moved into the sandbox? Greetings, Bram [1] I did: mkdir project mkdir cabal-sandbox cd cabal-sandbox; cabal sandbox init cd ../project ln -s ../cabal-sandbox/cabal.sandbox.config On Thu, Aug 14, 2014 at 8:57 PM, Johan Tibell wrote: > Hi Daniel, > > I think we eventually want to move dist/ inside the sandbox and eventually > move the sandbox out of the package directory too. This is too support a > world which is less focused on a single package. See my answer here: > http://stackoverflow.com/questions/25278996/cabal-test-in-a-sandbox?noredirect=1#comment39425358_25278996 > > > On Thu, Aug 14, 2014 at 8:15 PM, Daniel Trstenjak > wrote: >> >> >> Hi, >> >> currently it's conceptually and practically a bit unpleasant, that the >> sandbox is a bit holey, because the 'dist' directory remains when >> deleting the sandbox. >> >> Is there a special reason for this behaviour? >> >> In the case of a sandbox, why is there a 'dist' directory at all, >> respectively why isn't it located inside of the '.cabal-sandbox' >> directory? >> >> >> Greetings, >> Daniel >> _______________________________________________ >> cabal-devel mailing list >> cabal-devel at haskell.org >> http://www.haskell.org/mailman/listinfo/cabal-devel > > > > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > From daniel.trstenjak at gmail.com Fri Aug 15 21:08:31 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Fri, 15 Aug 2014 23:08:31 +0200 Subject: cabal sandbox and the dist directory In-Reply-To: References: <20140814181527.GA18679@machine> Message-ID: Hi Bram, > Moving dist into cabal-sandbox would mean that I would have to either > symlink my dist in also, or use the full path to my sandbox location > every time I want to look at the build artifacts. > > How would you easily share a sandbox between multiple projects if dist > is moved into the sandbox? So it's more about how convient it's to locate the dist directory, because it should still be possible to share a sandbox between multiple projects, because each project should have a separate dist directory inside of the sandbox. Greetings, Daniel From ezyang at mit.edu Sun Aug 17 01:41:18 2014 From: ezyang at mit.edu (Edward Z. Yang) Date: Sun, 17 Aug 2014 02:41:18 +0100 Subject: Status of encapsulations in the modular dependency solver Message-ID: <1408233913-sup-646@sabre> Hello all, I wanted to know what the status of the encapsulations feature in Cabal is. Presented in HIW'11, the intent was for it to be used to support private dependencies in Cabal. However, while this is was implemented in the modular solver, it looks like it was never wired up with Cabal proper. Andres, you mentioned you might be getting around to looking at this again? Since we have more fine-grained linker symbols in GHC HEAD, this feature ought to work better. In any case, when I was reviewing the HIW'11, I realized that the semantics of encapsulations discussed there are not quite the ones you might actually want. In particular, there was an example where C encapsulates its dependency on B, but if C has another (non-encapsulated) dependency D which depends on B, now the global choice of B (witnessed through C.D.B) and C.B are required to be the same. However, it might also be useful for these two dependencies to still be different, even in this case. In particular, it may be useful to encapsulate a package *even if it shows up in the interface.* Such packages can be used for: - Building compatibility layers between multiple versions of a package (here, we want to build-depends on the same package multiple times, in an encapsulated way) - Using the encapsulations feature to represent Backpack style mix-ins, where packages with holes are considered encapsulated. (I'm not 100% this is the right way to go about implementing this, but it's one possibility). Cheers, Edward From pengyu.ut at gmail.com Sat Aug 30 20:33:10 2014 From: pengyu.ut at gmail.com (Peng Yu) Date: Sat, 30 Aug 2014 15:33:10 -0500 Subject: Error of `cabal install cabal-install` on Mac OS X 10.9.4 Message-ID: Hi, I get the following error. Does anybody know how to fix it on Mac OS X 10.9.4? Thanks. $ cabal install cabal-install Resolving dependencies... Configuring Cabal-1.20.0.2... Failed to install Cabal-1.20.0.2 Last 10 lines of the build log ( /Users/py/.cabal/logs/Cabal-1.20.0.2.log ): cabal: Error: some packages failed to install: Cabal-1.20.0.2 failed during the configure step. The exception was: user error ( /var/folders/nn/p4t2bp0n0znc79dc77q45y9m0000gn/T/Cabal-1.20.0.2-95493/Cabal-1.20.0.2/Distribution/Simple/Utils.hs:386:31: Warning: In the use of ?runGenProcess_? (imported from System.Process.Internals): Deprecated: "Please do not use this anymore, use the ordinary 'System.Process.createProcess'. If you need the SIGINT handling, use delegate_ctlc = True (runGenProcess_ is now just an imperfectly emulated stub that probably duplicates or overrides your own signal handling)." Undefined symbols for architecture x86_64: "_iconv", referenced from: _hs_iconv in libHSbase-4.7.0.1.a(iconv.o) (maybe you meant: _base_GHCziIOziEncodingziIconv_iconvEncoding9_info, _base_GHCziIOziEncodingziIconv_iconvEncoding9_closure , _hs_iconv_open , _base_GHCziIOziEncodingziIconv_iconvEncoding6_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding10_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding7_info , _base_GHCziIOziEncodingziIconv_iconvEncoding2_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_info , _base_GHCziIOziEncodingziIconv_iconvEncodingzuloc_info , _hs_iconv_close , _base_GHCziIOziEncodingziIconv_iconvEncoding3_info , _base_GHCziIOziEncodingziIconv_iconvEncoding3_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding4_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding7_closure , _base_GHCziIOziEncodingziIconv_iconvEncodingzuloc1_closure , _hs_iconv , _base_GHCziIOziEncodingziIconv_iconvEncodingzuloc_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding8_info , _base_GHCziIOziEncodingziIconv_iconvEncoding8_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding10_info , _base_GHCziIOziEncodingziIconv_iconvEncodingzuloc1_info , _base_GHCziIOziEncodingziIconv_iconvEncoding6_info ) "_iconv_close", referenced from: _hs_iconv_close in libHSbase-4.7.0.1.a(iconv.o) (maybe you meant: _hs_iconv_close) "_iconv_open", referenced from: _hs_iconv_open in libHSbase-4.7.0.1.a(iconv.o) (maybe you meant: _hs_iconv_open) "_locale_charset", referenced from: _localeEncoding in libHSbase-4.7.0.1.a(PrelIOUtils.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ) cabal-install-1.20.0.3 depends on Cabal-1.20.0.2 which failed to install. -- Regards, Peng From allbery.b at gmail.com Sat Aug 30 20:41:05 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 30 Aug 2014 16:41:05 -0400 Subject: Error of `cabal install cabal-install` on Mac OS X 10.9.4 In-Reply-To: References: Message-ID: On Sat, Aug 30, 2014 at 4:33 PM, Peng Yu wrote: > Undefined symbols for architecture x86_64: > "_iconv", referenced from: > _hs_iconv in libHSbase-4.7.0.1.a(iconv.o) > You are mixing stuff built against the system iconv with stuff built against either MacPorts or Homebrew. This won't work. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From pengyu.ut at gmail.com Sun Aug 31 14:39:19 2014 From: pengyu.ut at gmail.com (Peng Yu) Date: Sun, 31 Aug 2014 09:39:19 -0500 Subject: Error of `cabal install cabal-install` on Mac OS X 10.9.4 In-Reply-To: References: Message-ID: On Sat, Aug 30, 2014 at 3:41 PM, Brandon Allbery wrote: > On Sat, Aug 30, 2014 at 4:33 PM, Peng Yu wrote: >> >> Undefined symbols for architecture x86_64: >> "_iconv", referenced from: >> _hs_iconv in libHSbase-4.7.0.1.a(iconv.o) > > > You are mixing stuff built against the system iconv with stuff built against > either MacPorts or Homebrew. This won't work. I have MacPorts installed. But how to figure out what in MacPorts is in conflict from the one from Haskell Mac OS X installer? -- Regards, Peng From gregmainland at gmail.com Sun Aug 31 18:00:02 2014 From: gregmainland at gmail.com (Greg Horn) Date: Sun, 31 Aug 2014 20:00:02 +0200 Subject: Error of `cabal install cabal-install` on Mac OS X 10.9.4 In-Reply-To: References: Message-ID: The problem is described here http://blog.omega-prime.co.uk/?p=96. When I was using macports, I would build GHC myself using: >>* EXTRA_CABAL_CONFIGURE_FLAGS = --extra-include-dirs=/opt/local/include \ *>>* --extra-lib-dirs=/opt/local/lib * and >>* ./configure --with-iconv-includes=/opt/local/include \ *>>* --with-iconv-libraries=/opt/local/lib \ *>>* --with-gmp-includes=/opt/local/include \ *>>* --with-gmp-libraries=/opt/local/lib* as described here http://www.haskell.org/pipermail/haskell-cafe/2010-June/079204.html On Sun, Aug 31, 2014 at 4:39 PM, Peng Yu wrote: > On Sat, Aug 30, 2014 at 3:41 PM, Brandon Allbery > wrote: > > On Sat, Aug 30, 2014 at 4:33 PM, Peng Yu wrote: > >> > >> Undefined symbols for architecture x86_64: > >> "_iconv", referenced from: > >> _hs_iconv in libHSbase-4.7.0.1.a(iconv.o) > > > > > > You are mixing stuff built against the system iconv with stuff built > against > > either MacPorts or Homebrew. This won't work. > > I have MacPorts installed. But how to figure out what in MacPorts is > in conflict from the one from Haskell Mac OS X installer? > > -- > Regards, > Peng > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: