From simons at cryp.to Thu Nov 7 09:49:50 2013 From: simons at cryp.to (Peter Simons) Date: Thu, 07 Nov 2013 10:49:50 +0100 Subject: Compiling with --enable-shared --disable-library-vanilla Message-ID: <87siv81qyp.fsf@write-only.nokia.com> Hi guys, I'm experimenting with shared library support for Haskell in NixOS. So far, --enable-shared works great, but it comes at the cost of doubling the build times. So I tried to disable building of static libraries to fix that: $ cabal configure --enable-shared --disable-library-vanilla Resolving dependencies... Configuring funcmp-1.8... But these build won't succeed, because the in-place registration procedure can't find any *.hi files: $ cabal build ; echo $? Building funcmp-1.8... Preprocessing library funcmp-1.8... In-place registering funcmp-1.8... cabal: funcmp-1.8: file FMP.hi is missing (use --force to override) funcmp-1.8: file FMP/Canvas.hi is missing (use --force to override) funcmp-1.8: file FMP/Color.hi is missing (use --force to override) funcmp-1.8: file FMP/Core.hi is missing (use --force to override) funcmp-1.8: file FMP/File.hi is missing (use --force to override) funcmp-1.8: file FMP/Frames.hi is missing (use --force to override) funcmp-1.8: file FMP/Matrix.hi is missing (use --force to override) funcmp-1.8: file FMP/PP.hi is missing (use --force to override) funcmp-1.8: file FMP/Picture.hi is missing (use --force to override) funcmp-1.8: file FMP/RedBlack.hi is missing (use --force to override) funcmp-1.8: file FMP/Resolve.hi is missing (use --force to override) funcmp-1.8: file FMP/Symbols.hi is missing (use --force to override) funcmp-1.8: file FMP/Syntax.hi is missing (use --force to override) funcmp-1.8: file FMP/Term.hi is missing (use --force to override) funcmp-1.8: file FMP/Tree.hi is missing (use --force to override) funcmp-1.8: file FMP/Turtle.hi is missing (use --force to override) funcmp-1.8: file FMP/Types.hi is missing (use --force to override) funcmp-1.8: file Paths_funcmp.hi is missing (use --force to override) funcmp-1.8: cannot find libHSfuncmp-1.8.a on library path (use --force to override) 1 Is anyone aware of a simple remedy for this issue? Has anyone else tried this before? Can Haskell libraries be built shared-only? Best regards, Peter From the.dead.shall.rise at gmail.com Thu Nov 7 12:01:43 2013 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Thu, 7 Nov 2013 13:01:43 +0100 Subject: Compiling with --enable-shared --disable-library-vanilla In-Reply-To: <87siv81qyp.fsf@write-only.nokia.com> References: <87siv81qyp.fsf@write-only.nokia.com> Message-ID: Hi Peter, On Thu, Nov 7, 2013 at 10:49 AM, Peter Simons wrote: > Hi guys, > > I'm experimenting with shared library support for Haskell in NixOS. So far, > --enable-shared works great, but it comes at the cost of doubling the build > times. So I tried to disable building of static libraries to fix that: > > $ cabal configure --enable-shared --disable-library-vanilla > Resolving dependencies... > Configuring funcmp-1.8... > > But these build won't succeed, because the in-place registration procedure > can't find any *.hi files: > > [...] > > Is anyone aware of a simple remedy for this issue? Has anyone else tried > this before? Can Haskell libraries be built shared-only? This is likely a bug in Cabal, please file a ticket on the bug tracker: https://github.com/haskell/cabal/issues/new -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From tim at dockerz.net Sun Nov 10 22:26:31 2013 From: tim at dockerz.net (Tim Docker) Date: Mon, 11 Nov 2013 09:26:31 +1100 Subject: sandbox hashcode in dist directory Message-ID: <52800817.5020501@dockerz.net> I'm attempting to use ghc-mod and emacs to get on the fly compiling working again. This is always pleasing when it works, but it seems a never ending challenge to get it to find all my dependences :-( Several of my cabal packages require autogenerated code which used to end up in dist/build/autogen. ghc-mod is configured to search this directory, as per: https://github.com/kazu-yamamoto/ghc-mod/blob/169069f6232c617f06f24b9caa40f8f967c1cbf5/Language/Haskell/GhcMod/CabalApi.hs#L71 However since starting to use cabal sandboxes, the generated code ends up in a directory like this: dist/dist-sandbox-c4c8b1d4/build/autogen/ What is this hashcode for? Is it always generated when using a sandbox? If I have code (like ghc-mod) that needs to access the build directory, how do I work out the value of the hashcode? Thanks, Tim From the.dead.shall.rise at gmail.com Mon Nov 11 00:26:58 2013 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Mon, 11 Nov 2013 01:26:58 +0100 Subject: sandbox hashcode in dist directory In-Reply-To: <52800817.5020501@dockerz.net> References: <52800817.5020501@dockerz.net> Message-ID: Hi, On Sun, Nov 10, 2013 at 11:26 PM, Tim Docker wrote: > > However since starting to use cabal sandboxes, the generated code ends up in > a directory like this: > > dist/dist-sandbox-c4c8b1d4/build/autogen/ > > What is this hashcode for? Is it always generated when using a sandbox? If I > have code (like ghc-mod) that needs to access the > build directory, how do I work out the value of the hashcode? So that you can use the same add-source dependency with several different sandboxes and also build it standalone. See discussion in https://github.com/haskell/cabal/issues/1281 As to how generate the hash code yourself, the relevant part of the source code is https://github.com/haskell/cabal/blob/master/cabal-install/Distribution/Client/Sandbox.hs#L129 That function takes the absolute path to the current sandbox ('/path/to/.cabal-sandbox') as input. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From tim at dockerz.net Mon Nov 11 01:22:43 2013 From: tim at dockerz.net (Tim Docker) Date: Mon, 11 Nov 2013 12:22:43 +1100 Subject: sandbox hashcode in dist directory In-Reply-To: References: <52800817.5020501@dockerz.net> Message-ID: <52803163.7030104@dockerz.net> Thanks for the quick reply - I'll make an attempt to get ghc-mod to be compatible with this. Tim On 11/11/13 11:26, Mikhail Glushenkov wrote: > Hi, > > On Sun, Nov 10, 2013 at 11:26 PM, Tim Docker wrote: >> However since starting to use cabal sandboxes, the generated code ends up in >> a directory like this: >> >> dist/dist-sandbox-c4c8b1d4/build/autogen/ >> >> What is this hashcode for? Is it always generated when using a sandbox? If I >> have code (like ghc-mod) that needs to access the >> build directory, how do I work out the value of the hashcode? > So that you can use the same add-source dependency with several > different sandboxes and also build it standalone. See discussion in > https://github.com/haskell/cabal/issues/1281 > > As to how generate the hash code yourself, the relevant part of the > source code is https://github.com/haskell/cabal/blob/master/cabal-install/Distribution/Client/Sandbox.hs#L129 > That function takes the absolute path to the current sandbox > ('/path/to/.cabal-sandbox') as input. > > From shelarcy at gmail.com Mon Nov 11 02:50:07 2013 From: shelarcy at gmail.com (shelarcy) Date: Mon, 11 Nov 2013 11:50:07 +0900 Subject: Request to release cabal-install 1.18.0.3 (Was: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: Hi, cabal-install 1.18.0.2 has two critical bugs on Windows. 1. "cabal sdist" command make broken tarball on Windows. https://github.com/haskell/cabal/issues/1538 2. "cabal update" command broke package index sometimes. https://twitter.com/xyx_is/status/391944129074044929 (in Japanese) Both bugs are already fixed in 1.18 branch's cabal-install (with Cabal 1.18.1.2). But that version isn't released yet. So, please release newer version of cabal-install before releasing HP 2013.4.0.0. Best Regards, On Mon, 11 Nov 2013 01:46:18 +0900, Johan Tibell wrote: > hashable bump is good. I'm also pro shipping a newer Cabal, if it doesn't > cause any issues with the one that already comes with GHC. > > > On Sun, Nov 10, 2013 at 5:11 PM, Mark Lentczner wrote: > >> I know it is late, and so I've done some preliminary version sleuthing.... >> Here's my proposal for HP 2013.4.0.0. I know this e-mail's is long - but >> hoping to hear from all relevant parties soon. >> >> *GHC 7.6.3* -- this is a compiler bump, but all the included packages >> remain at the same version as 2013.2.0.0 >> >> *Packages with no changes:* >> fgl, haskell-src, html, HTTP, HUnit, >> mtl, parsec, QuickCheck, random, >> regex-base, regex-compat, regex-posix, >> split, stm, text, transformers, >> xhtml, zlib >> >> *Packages with minor version bumps:* >> *I'll advance these automatically this time - no need for maintainer input* >> cgi: 3001.1.7.5 ? 3001.1.8.4 >> network: 2.4.1.2 ? 2.4.2.0 >> parallel: 3.2.0.3 ? 3.2.0.4 >> syb: 0.4.0 ? 0.4.1 >> unordered-containers: 0.2.3.0 ? 0.2.3.3 >> vector: 0.10.0.1 ? 0.10.9.1? >> primitive: 0.5.0.1 ? 0.5.1.0? >> >> *Packages with major version bumps:* >> *I'd like to get confirmation from the maintainers of these packages that >> this bump is "the right thing to do". The bump should ideally only add API, >> and not orphan any program that used to compile under the HP - at least not >> without a good reason.* >> case-insensitive: 1.0.0.1 ? 1.1.0.1 >> hashable: 1.1.2.5 ? 1.2.1.0 >> >> GLUT: 2.4.0.0 ? 2.5.0.1 >> GLURaw: 1.3.0.0 ? 1.4.0.0 >> OpenGL: 2.8.0.0 ? 2.9.1.0 >> OpenGLRaw: 1.3.0.0 ? 1.4.0.0 >> >> alex: 3.0.5 ? 3.1.0 >> happy: 1.18.10 ? 1.19.0 >> >> *New Packages:* >> *There was prior discussion on the libraries mailing list, and generally >> all around resounding "YES!" for including aeson.* >> *I think we should include it. I'm looking for confirmation from the >> maintainer that this is the right version to include.* >> aeson: 0.6.2.1 >> >> *Cabal:* >> *The Cabal 1.18 release was a major new release, including the very very >> useful sandbox feature. This would require shipping a different Cabal lib >> than the version shipped with the included GHC. I'm not sure of the >> implications of doing this - in particular, whether we would have to ship >> two Cabal packages or just the later.* >> Cabal: 1.16.0 ? 1.18.1.2 >> cabal-install: 1.16.0.2 ? 1.18.0.2 >> >> What do you all think? >> >> ? Mark "late, but not forgotten" Lentczner >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries -- shelarcy http://page.freett.com/shelarcy/ From the.dead.shall.rise at gmail.com Mon Nov 11 03:44:26 2013 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Mon, 11 Nov 2013 04:44:26 +0100 Subject: Request to release cabal-install 1.18.0.3 (Was: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: Hi, On Mon, Nov 11, 2013 at 3:50 AM, shelarcy wrote: > > 2. "cabal update" command broke package index sometimes. > > https://twitter.com/xyx_is/status/391944129074044929 (in Japanese) Do you have a reference to the commit in which that was fixed? -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From johan.tibell at gmail.com Mon Nov 11 09:46:22 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 11 Nov 2013 10:46:22 +0100 Subject: What's next? In-Reply-To: References: Message-ID: Here's a status update. ## Faster builds We've made good progress on making things faster. In particular, we've implemented: * Re-linking avoidance (https://github.com/haskell/cabal/pull/1537). This is really useful if you have e.g. many test suites and only one needs to be rebuilt due to some change to the library. * Parallel builds at the module level ( https://github.com/haskell/cabal/pull/1536). This gives a modest speed-up for `cabal build`, especially for larger packages. ## Do the right thing automatically No progress here. Both tasks should be pretty straightforward. Anyone interested in taking a stab at them? I'd be happy to provide guidance. ## Support large projects We haven't yet made any progress on support for trees of packages. We're in need of a design doc here before we can do much else. There is some important work on freezing dependencies for releases under way at https://github.com/haskell/cabal/pull/1519. That thread could probably need some input for people other than me. -- Johan On Thu, Sep 5, 2013 at 6:14 AM, Johan Tibell wrote: > Hi all, > > With 1.18 out the door it's time to look towards the future. Here are > the major themes I'd like to see us work on next: > > ## Faster builds > > There are several interesting things we could do and are doing here. > > * Avoid relinking if possible. This reduces incremental build times > (i.e. when you run cabal build after making some change) by avoiding > relinking e.g. all the test suites and/or benchmarks. See > https://github.com/haskell/cabal/pull/1410 for some in-progress work. > > * Build components and different ways (e.g. profiling) in parallel. > We could build both profiling and non-profiling versions in parallel. > We could also build e.g. all test suites in parallel. The key > challenge here is to coordinate all parallel jobs so we don't spawn > too many. See https://github.com/haskell/cabal/pull/1413 > > * Build modules in parallel. This fine granularity would let us > making building a single package faster, which is the most common case > after all. There has been some GSoC work here e.g. > http://hackage.haskell.org/trac/ghc/ticket/910 and some work by > Mikhail. > > ## Do the right thing automatically > > The focus here should be on avoiding manual steps the cabal could do > for the user. > > * Automatically install dependencies when needed. When `cabal build` > would fail due to a missing dependency, just install this dependency > instead of bugging the user to do it. This will probably have to be > limited to sandboxes where we can't break the user's system > > * GHCi support could be improved by rebinding :reload to rerun e.g. > preprocessors automatically. This would enable the users to develop > completely from within ghci (i.e. faster edit-save-type-error cycle). > We have most of what we need here (i.e. GHC macro support) but someone > needs to make the final change to generate a .ghci file to pass in the > ghci invocation. > > ## Support large projects > > We need to better support projects with tens or hundreds of packages. > As projects grow it's naturally to split them up into a bunch of > packages (libraries and executables). Some changes to the project > might need changes across a couple of packages (e.g. to a supporting > library and to an executable) in a single change and developers need > to be able to > > * build several packages that have local changes, and > * share changes to packages with other developers without making a > release to some local Hackage server every time. > > Both can be done by having a single source repo with all the packages > and using `cabal sandbox add-source` to make sure they get built when > needed. However, that method only scales up to a handful of packages. > > I think we want to think about moving away from a world where all > cabal commands are run in the context of some "current" package (i.e. > in the current working directory). I think we want to be able to stand > in the root directory of some source repo and build things from there. > Example: > > $ git clone git://my-company/repo my-project > $ cd my-project > $ ls > lib-pkg1 lib-pkg2 exe-pkg1 exe-pkg2 ... > $ cabal sandbox init # or something similar > $ edit lib-pkg1/Lib.hs > $ edit exe-pkg1/Exe.hs > $ cabal build exe-pkg1 # picks up changes to lib-pkg1 > > This has implication for many things e.g. where the .cabal-sandbo and > the dist directories are kept. Perhaps dist would have a subdirectory > per package (right now we do something similar for sandbox > dependencies). > > I imagine that the syntax for e.g. cabal build would have to extended to > > cabal build [[DIR':']COMPONENT] > > Example: > > cabal build lib-pkg1:some-component > > Similar for `cabal test` and `cabal bench`. > > Cheers, > Johan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shelarcy at gmail.com Mon Nov 11 14:15:41 2013 From: shelarcy at gmail.com (shelarcy) Date: Mon, 11 Nov 2013 23:15:41 +0900 Subject: Request to release cabal-install 1.18.0.3 (Was: 2013.4.0.0 proposal In-Reply-To: References: Message-ID: On Mon, 11 Nov 2013 12:44:26 +0900, Mikhail Glushenkov wrote: > Hi, > > On Mon, Nov 11, 2013 at 3:50 AM, shelarcy wrote: >> >> 2. "cabal update" command broke package index sometimes. >> >> https://twitter.com/xyx_is/status/391944129074044929 (in Japanese) > > Do you have a reference to the commit in which that was fixed? No. I don't know which commit fixed this problem. -- shelarcy http://page.freett.com/shelarcy/ From johan.tibell at gmail.com Wed Nov 27 21:01:19 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 27 Nov 2013 22:01:19 +0100 Subject: Should we aim for a new release in late January? Message-ID: Hi, Cabal development is continuing at a furious pace. There are lots of great things in master that I'd like to get out to users, such as * relinking avoidance * build -j * ability to specify exact deps on the command line * haskell-suite compiler support * bug fixes Here's an approximate list of commits (both Cabal and cabal-install) since the last release: https://github.com/haskell/cabal/compare/Cabal-v1.18.1.2...master It's not entirely accurate as some patches were cherry-picked onto the 1.18 branch and thus have different commit IDs. -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Nov 28 11:41:51 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu, 28 Nov 2013 11:41:51 +0000 Subject: Should we aim for a new release in late January? In-Reply-To: References: Message-ID: <59543203684B2244980D7E4057D5FBC1486D3FA3@DB3EX14MBXC308.europe.corp.microsoft.com> I'm thrilled that there so much Cabal activity! Is anyone working on, or interested in, the issue of compiling and installing the same package against different dependencies? (There was a Google SoC project about this.) Cabal sandboxes address the same issue, but at some user cost. It should Just Work. Simon From: cabal-devel [mailto:cabal-devel-bounces at haskell.org] On Behalf Of Johan Tibell Sent: 27 November 2013 21:01 To: cabal-devel at haskell.org Subject: Should we aim for a new release in late January? Hi, Cabal development is continuing at a furious pace. There are lots of great things in master that I'd like to get out to users, such as * relinking avoidance * build -j * ability to specify exact deps on the command line * haskell-suite compiler support * bug fixes Here's an approximate list of commits (both Cabal and cabal-install) since the last release: https://github.com/haskell/cabal/compare/Cabal-v1.18.1.2...master It's not entirely accurate as some patches were cherry-picked onto the 1.18 branch and thus have different commit IDs. -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Thu Nov 28 12:07:25 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 28 Nov 2013 13:07:25 +0100 Subject: Should we aim for a new release in late January? In-Reply-To: <59543203684B2244980D7E4057D5FBC1486D3FA3@DB3EX14MBXC308.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1486D3FA3@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: Hi Simon, I don't think it's being actively worked on. Duncan and I chat about it once in a while when we meet in person, but we don't have the cycles to do it. On Thu, Nov 28, 2013 at 12:41 PM, Simon Peyton-Jones wrote: > I?m thrilled that there so much Cabal activity! > > > > Is anyone working on, or interested in, the issue of compiling and > installing the same package against different dependencies? (There was a > Google SoC project about this.) Cabal sandboxes address the same issue, > but at some user cost. It should Just Work. > > > > Simon > > > > *From:* cabal-devel [mailto:cabal-devel-bounces at haskell.org] *On Behalf > Of *Johan Tibell > *Sent:* 27 November 2013 21:01 > *To:* cabal-devel at haskell.org > *Subject:* Should we aim for a new release in late January? > > > > Hi, > > > > Cabal development is continuing at a furious pace. There are lots of great > things in master that I'd like to get out to users, such as > > > > * relinking avoidance > > * build -j > > * ability to specify exact deps on the command line > > * haskell-suite compiler support > > * bug fixes > > > > Here's an approximate list of commits (both Cabal and cabal-install) since > the last release: > > > > https://github.com/haskell/cabal/compare/Cabal-v1.18.1.2...master > > > > It's not entirely accurate as some patches were cherry-picked onto the > 1.18 branch and thus have different commit IDs. > > > > -- Johan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Nov 28 12:12:54 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu, 28 Nov 2013 12:12:54 +0000 Subject: Should we aim for a new release in late January? In-Reply-To: References: <59543203684B2244980D7E4057D5FBC1486D3FA3@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: <59543203684B2244980D7E4057D5FBC1486D412B@DB3EX14MBXC308.europe.corp.microsoft.com> Is it really that many cycles? (Compared to all the other great stuff the Cabal team are doing.) Simon From: Johan Tibell [mailto:johan.tibell at gmail.com] Sent: 28 November 2013 12:07 To: Simon Peyton-Jones Cc: cabal-devel at haskell.org Subject: Re: Should we aim for a new release in late January? Hi Simon, I don't think it's being actively worked on. Duncan and I chat about it once in a while when we meet in person, but we don't have the cycles to do it. On Thu, Nov 28, 2013 at 12:41 PM, Simon Peyton-Jones > wrote: I'm thrilled that there so much Cabal activity! Is anyone working on, or interested in, the issue of compiling and installing the same package against different dependencies? (There was a Google SoC project about this.) Cabal sandboxes address the same issue, but at some user cost. It should Just Work. Simon From: cabal-devel [mailto:cabal-devel-bounces at haskell.org] On Behalf Of Johan Tibell Sent: 27 November 2013 21:01 To: cabal-devel at haskell.org Subject: Should we aim for a new release in late January? Hi, Cabal development is continuing at a furious pace. There are lots of great things in master that I'd like to get out to users, such as * relinking avoidance * build -j * ability to specify exact deps on the command line * haskell-suite compiler support * bug fixes Here's an approximate list of commits (both Cabal and cabal-install) since the last release: https://github.com/haskell/cabal/compare/Cabal-v1.18.1.2...master It's not entirely accurate as some patches were cherry-picked onto the 1.18 branch and thus have different commit IDs. -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Thu Nov 28 12:32:24 2013 From: johan.tibell at gmail.com (Johan Tibell) Date: Thu, 28 Nov 2013 13:32:24 +0100 Subject: Should we aim for a new release in late January? In-Reply-To: <59543203684B2244980D7E4057D5FBC1486D412B@DB3EX14MBXC308.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1486D3FA3@DB3EX14MBXC308.europe.corp.microsoft.com> <59543203684B2244980D7E4057D5FBC1486D412B@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: Hi, I think it's non trivial due to us not having a nailed down design in several areas (i.e. it's not just coding work needed). If you look at the ToDo items at: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Packages/MultiInstances several of the ToDos don't have clear designs yet. For example: - instances of packages must install in a different location - install directory includes hash? - SDM: not done yet. One problem is that we don't know the hash until the package is built, but we need to know the install locations earlier because we bake them into Paths_foo.hs. - Simon and Andres discussed that one option is to let Cabal compute its own hash. However, then we'd have two hashes to deal with. Only using the Cabal-computed hash isn't an option either according to Simon, because apparently GHC's ABI hash computation is non-deterministic, so we might end up with situations where Cabal's hash is stable, but GHC computes an ABI-incompatible version. This is somewhat worrying ... - Duncan thinks that we should store both a package identity and a package ABI hash. Currently we form the package id from the name, version and ABI hash. We should store the ABI hash separately anyway because eventually we will want to know it, to know which packages are ABI compatible. So Cabal can compute a package Id in advance, however is sensible, and the ABI hash is calculated as now, after the build. The installation directory follows the package Id. and - GHC: discard conflicting instances during its shadowing phase - SDM: GHC will currently do *something* here, but it might end up with a result that the user didn't want/expect. One way to improve things is to prioritise packages that were installed more recently. - Andres suggests that GHC should be much cleverer, and look at the actual dependencies of the modules being compiled before deciding which packages to enable. This would almost certainly result in more things working and possibly less surprising behaviour sometimes, but Simon thinks that (a) it is too hard, (b) if users need this, they should use Cabal and its dependency resolver, which will do a good job, (c) you can often resolve problems by adding -package X, and (d) eventually we will want a system where users manage separate sessions, so they can set up an environment in which the packages they want are available. This has a lot in common with cabal-dev and sandboxes, so the mechanisms (and concepts) should be shared. (kosmikus: perhaps an alternative is to force the user to make an active decision in case of conflicts, i.e., to create a sandbox that exposes a consistent package set). -- Johan On Thu, Nov 28, 2013 at 1:12 PM, Simon Peyton-Jones wrote: > Is it really that many cycles? (Compared to all the other great stuff > the Cabal team are doing.) > > > > Simon > > > > *From:* Johan Tibell [mailto:johan.tibell at gmail.com] > *Sent:* 28 November 2013 12:07 > *To:* Simon Peyton-Jones > *Cc:* cabal-devel at haskell.org > *Subject:* Re: Should we aim for a new release in late January? > > > > Hi Simon, > > > > I don't think it's being actively worked on. Duncan and I chat about it > once in a while when we meet in person, but we don't have the cycles to do > it. > > > > On Thu, Nov 28, 2013 at 12:41 PM, Simon Peyton-Jones < > simonpj at microsoft.com> wrote: > > I?m thrilled that there so much Cabal activity! > > > > Is anyone working on, or interested in, the issue of compiling and > installing the same package against different dependencies? (There was a > Google SoC project about this.) Cabal sandboxes address the same issue, > but at some user cost. It should Just Work. > > > > Simon > > > > *From:* cabal-devel [mailto:cabal-devel-bounces at haskell.org] *On Behalf > Of *Johan Tibell > *Sent:* 27 November 2013 21:01 > *To:* cabal-devel at haskell.org > *Subject:* Should we aim for a new release in late January? > > > > Hi, > > > > Cabal development is continuing at a furious pace. There are lots of great > things in master that I'd like to get out to users, such as > > > > * relinking avoidance > > * build -j > > * ability to specify exact deps on the command line > > * haskell-suite compiler support > > * bug fixes > > > > Here's an approximate list of commits (both Cabal and cabal-install) since > the last release: > > > > https://github.com/haskell/cabal/compare/Cabal-v1.18.1.2...master > > > > It's not entirely accurate as some patches were cherry-picked onto the > 1.18 branch and thus have different commit IDs. > > > > -- Johan > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Thu Nov 28 12:58:45 2013 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Thu, 28 Nov 2013 13:58:45 +0100 Subject: Should we aim for a new release in late January? In-Reply-To: <59543203684B2244980D7E4057D5FBC1486D3FA3@DB3EX14MBXC308.europe.corp.microsoft.com> References: <59543203684B2244980D7E4057D5FBC1486D3FA3@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: On Thu, Nov 28, 2013 at 12:41 PM, Simon Peyton-Jones wrote: > I?m thrilled that there so much Cabal activity! > > > > Is anyone working on, or interested in, the issue of compiling and > installing the same package against different dependencies? (There was a > Google SoC project about this.) Cabal sandboxes address the same issue, but > at some user cost. It should Just Work. I'm interested in implementing this at some point, but don't have that much free time right now. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments