January 2009 - cabal-devel

patch applied (cabal): Improve runE parse error message
by Duncan Coutts 18 Jan '09

18 Jan '09

Fri Jan 16 05:32:14 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Improve runE parse error message Only really used in parsing config files derived from command line flags. M ./Distribution/ParseUtils.hs -1 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090116133214-adfee-65f8f9f2…

1 0

[Hackage] #447: do parallel builds
by Hackage 18 Jan '09

18 Jan '09

#447: do parallel builds ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ The latest version of the gentoo portage tool is rather slick. It can do parallel builds and it displays a nice summary on the command line, eg: {{{ # emerge -uD system -j --load-average=4.5 Calculating dependencies... done! >>> Verifying ebuild manifests >>> Starting parallel fetch >>> Emerging (1 of 14) dev-libs/expat-2.0.1-r1 >>> Emerging (2 of 14) sys-devel/autoconf-wrapper-6 >>> Emerging (3 of 14) sys-kernel/linux-headers-2.6.27-r2 >>> Installing sys-devel/autoconf-wrapper-6 >>> Jobs: 0 of 14 complete, 1 running Load avg: 2.99, 1.59, 0.67 }}} Note how they solve the problem of how to display what is going on when there are multiple builds happening. The answer is not to display it at all! This would have to go hand-in-hand with logging all builds so that we can still diagnose failures. Note the final line, that gets updated to display the current number of jobs running, the number completed etc. It also shows the load average. The job scheduler has two parameters, one is a maximum number of jobs (or unlimited) and the other is a load average. It will only launch new jobs if the load average is less than the given maximum. That allows it to interact reasonably well with builds that use `make -j` internally. In the example above I set the load average to be just slightly more than the number of CPUs I've got. It looks to me like it serialises some bits, like installing, since saturating the disk with multiple parallel installs is generally of no benefit, indeed it can be slower. Also downloads seem to be serialised, again because there is probably little benefit to making multiple connections to the same server. Anyway, the point is, cabal-install ought to be able to do all this. Some bits we can do now. We already have a graph representation of the install plan and we recalculate when a package fails to install. We will need an improved download api, probably involving sending requests off to a dedicated download thread (which would serialise them). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/447> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

4 7

Cabal 2.0
by Duncan Coutts 17 Jan '09

17 Jan '09

All, I've started a wiki page to collect ideas for Cabal 2 http://hackage.haskell.org/trac/hackage/wiki/Cabal-2 The basic idea for Cabal 2 is to learn lessons from our how the existing design has fared and how we can make a better design to tackle an expanded set of goals. I'd like the page to be about suggested design concepts. I don't want to fill it with "wouldn't it be nice if we had a feature to help me doing ..." I guess it would also be useful to make links on that page to some of the discussions we've had on various lists, eg on the ghc users and libraries mailing lists where various people have made criticisms of the current design and suggested alternatives and improvements. Duncan

1 0

darcs patch: Fallback onto simpleHTTP when Network.Browser fails
by Stephen Hicks 17 Jan '09

17 Jan '09

Sat Oct 11 11:45:25 EDT 2008 Stephen Hicks <sdh33(a)cornell.edu> * Fallback onto simpleHTTP when Network.Browser fails

2 4

Technical Discussion of Cabal Improvements
by Curt Sampson 17 Jan '09

17 Jan '09

I've not noticed anything but PR and commit traffic on this list in the past couple of weeks; is it also the place to have discussions about (possibly radical) improvements to Cabal? For example, automatic generation of lists of dependent packages and so on? cjs -- Curt Sampson <cjs(a)starling-software.com> +81 90 7737 2974 Functional programming in all senses of the word: http://www.starling-software.com

2 1

[Hackage] #459: Find out what we can learn from SCons
by Hackage 17 Jan '09

17 Jan '09

#459: Find out what we can learn from SCons ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- [http://www.scons.org/ SCons] is a build system for various languages. This task is to do some research to compare SCons to the build component in Cabal and find out what lessons we can learn from SCons. The findings should be recorded on the [wiki:SCons] wiki page. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/459> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

patch applied (cabal-install): Only print the config file location for the global --help
by Duncan Coutts 16 Jan '09

16 Jan '09

Fri Jan 16 09:59:00 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Only print the config file location for the global --help M ./Main.hs -3 +6 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090116175900-adfee-…

1 0

[Hackage] #399: More information in the Paths_pkg.hs module, or a new module
by Hackage 16 Jan '09

16 Jan '09

#399: More information in the Paths_pkg.hs module, or a new module ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- There is more information about the system or about the package or configuration that we could include into a generated module. For example: * OS name (from standard enum names, not System.Info.os) * Arch name (similarly) * Compiler used for build * Package version (perhaps moved out of the `Paths_` module) * Other .cabal file package details (as Strings) * `x-foo` extension fields * license enum * authors, copyright * synopsis / description * home page, bug report url * configuration flag values * System details * big or little endian * Revision control context * git hash * darcs context -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/399> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #401: better support for multi-valued configuration flags
by Hackage 16 Jan '09

16 Jan '09

#401: better support for multi-valued configuration flags ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- For some packages one has to pick one of several mutually exclusive options. For example `yi` has a number of console or gui front ends. That can be expressed in terms of boolean flags but it's a little clumsy. We should consider adding some syntactic sugar. Currently it can be expressed by excluding the choice of picking none: {{{ if flag(gtk) ... if flag(vty) ... if flag(coca) && os(osx) ... if ! ( flag(gtk) || flag(vty) || (flag(coca) && os(osx)) ) buildable: false }}} That doesn't exclude the possibility of picking two options of course. In some cases we would want the options to be mutually exclusive and in others we would want to simply force the choice of one option, but multiple options might be possible. So the question is what kind of syntactic sugar would we like, how would it translate and how would it be exposed to package managers. eg: {{{ flag gui values: gtk, vty, coca if flag(gui==gtk) ... etc }}} and it'd translate into boolean choices that forced a choice of one flag being true and the others false. Needs some thought. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/401> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #400: fail and warnings for build configurations
by Hackage 16 Jan '09

16 Jan '09

#400: fail and warnings for build configurations ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- People expect `buildable: False` to fail the current configuration (rather than letting it configure and then not working at build time). But perhaps we should make that more explicit and allow a message, eg instead of: {{{ if os(windows) buildable: False }}} allow {{{ if os(windows) fail: it doesn't work on windows because, blah blah blah }}} And similarly we might want to warn users about selecting particular configurations eg: {{{ if flag(http) ... else warn: no http implementation selected, only local operations will be possible. You probably really want some http implementation. }}} The semantics roughly is that it's a workable but sub-optimal configuration. The solver should try to avoid warnings, by selecting another alternative. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/400> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1