March 2010 - cabal-devel

Proposed ghc-pkg and cabal feature
by Dan Knapp 16 Mar '10

16 Mar '10

I came up with an idea for a small feature that I believe would make a useful addition to ghc-pkg and Cabal. I'm willing to implement it myself, but I have had some previous experiences with other projects where I did some work and then the maintainers said "sorry, not interested", so I want to gauge interest before I start. I've already posted to glasgow-haskell-users, where Simon Marlow was kind enough to respond; he suggested that before starting work I should also get people's opinions here. The feature itself is this: Arbitrary key-value pairs in Cabal package files and the installed-package database. The use-case is for an application supporting plugins to discover installed plugins compatible with it, interrogating these fields through the GHC API. For example, my content-management system FruitTart could enumerate the list of installed packages looking for packages which export a field "fruit-tart-plugin-interface-version" with a numeric value matching the interface version it's expecting. Once again, I'm not asking anyone to do this work for me - I'm eager to get my hands dirty and do it myself. I just want to find out what the process would be to get it accepted, once it works. Thanks in advance, -- Dan Knapp "An infallible method of conciliating a tiger is to allow oneself to be devoured." (Konrad Adenauer)

1 0

[Hackage] #215: Overhaul support for package's tests
by Hackage 15 Mar '10

15 Mar '10

#215: Overhaul support for package's tests ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: project(> week) | Ghcversion: 6.8.2 Platform: | ------------------------------+--------------------------------------------- The current support for running package's testsuites is almost uniformly unused and packages instead implement ad-hoc solutions which makes it hard for users to run the testsuites and impossible to automate on hackage. The current support is so trivial anyone who takes this task on can ignore it and start with a clean slate. A [http://www.haskell.org/pipermail/cabal-devel/2008-January/001661.html thread on the issue]. Here are some ideas for possible requirements: * Support tests even in the `Simple` build system. Do not require using the `build-type: Custom` just to be able to use tests. * Define a standard interface for returning test results from a testsuite to Cabal so they can be included into a build report and could be published on the hackage website or some other custom in-house test server. * Support for above interface in `QuickCheck` and `HUnit`. * Support for HPC when running testsuite programs, and gathering coverage results, again for reporting purposes. * We want to be able to run tests on a library that is not installed yet. This will rely on support in Cabal for registering a package inplace in a local package db, and building test code against that. * What about performance tests? What format should that use for reporting? The emphasis is on automation. A lot of interesting information becomes available with enough automation. For example we could compare on hackage which packages have more comprehensive testsuites (measured by HPC coverage). Or we could track performance over time. Once the data is available there is a lot we could do with it. It's not just for a public hackage server, developers could use this privately too. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/215> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 11

Google summer of code in Cabal?
by Diego Echeverri 15 Mar '10

15 Mar '10

Hi guys! I was wondering about the possibility to work on Cabal for the summer of code. I've been helping one of my teachers to provide (improve) a "plugin" for the uuagc (I haven't spent too much time on it, but here's the fork I'm working on http://github.com/diegoeche/uuagc) I have found how flexible the cabal libraries are but also some things haven't been straightforward to do (I've been using Cabal 1.6.0.3). Basically there's seems to be an assumption of a one-to-one relation of modules and the sources of the files which is not followed by the uuagc pre-processor. I can use List.ag and inside of it use an include declaration to List-Data.ag. If I modify List-Data.ag cabal won't precompile it again because it will only check dates against List.ag (cabal doesn't know that the file that generates List.hs depends not only in List.ag). I had to override the build hook, duplicate the check (this time getting all the dependencies) and delete the generated file to trick cabal to precompile again... and well... that's seems quite a nasty hack to me. This assumption also affect the possibility to make the output of the pre-processor not necessarily an .hs file (and not necessarily carrying the same name). Checking the code for the pre-processors (Distribution.Simple.PreProcess) I noticed it would be good to have the possibility to chain pre-processors. I believe both issues are pretty much connected. I also found the following proposal here: http://hackage.haskell.org/trac/summer-of-code/ticket/1581 which sound also interesting to me. (and there's already a mentor available!) Do you think this could be a good project for the summer of code? Maybe any other ideas I should explore? Did I write to the right list? (please excuse me if I didn't) Thanks! Diego Echeverri

2 1

[Hackage] #643: Cabal should warn & detect when no modules are imported/used from a declared dependency
by Hackage 14 Mar '10

14 Mar '10

#643: Cabal should warn & detect when no modules are imported/used from a declared dependency -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: Platform: | -----------------------------+---------------------------------------------- For context, see: http://www.haskell.org/pipermail/libraries/2010-March/013115.html http://www.haskell.org/pipermail/libraries/2010-March/013155.html http://www.haskell.org/pipermail/libraries/2010-March/013157.html Not a few Haskell packages had declared in their .cabal files that they used the 'haskell98' package; but they never imported anything from haskell98 (such as the Monad or List modules), as proven by simply removing the dependency and noting that it continued to compile. Apparently the authors were mistaken about the use, had updated the old module imports, or believed haskell98 did something it didn't. The authors never knew, because neither GHC, Cabal, nor cabal-install would ever warn about the superfluous dependency. Given that dependencies can cause failures quite easily via bit-rot or the diamond dependency problem, otiose deps are quite bad. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/643> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

cabal-install: Legacy uris and upload --check
by Antoine Latter 13 Mar '10

13 Mar '10

cabal-dev, I found it difficult to test out a local install of hackage due to the way that cabal-install redirects to 'legacy' URIs, and the fact that upload --check points to a hard-coded path. So attached is a patch which does two things: - Previously, only hackage.haskell.org could count as a legacy repo path, now localhost can also count. It's still a bit arbitrary, tough. - When not using a legacy repo URI, upload --check posts to <repo>/check, which is what the happstack-based hackage-server expects. This is similar to what we do for the upload command already. If folks would like the second half without the first, I can put together a new patch. Side effects of this patch: + Anyone running with a third-party repo in their cabal config file will get unexpected behavior with 'upload --check'. Previously this would have always hit hackage.haskell.org. + Anyone running with a repo URI of the format 'localhost/packages/archive' will now be posting 'cabal upload' commands to localhost/cgi-bin/protected/upload instead of localhost/packages/archive/upload. Take care, Antoine

1 0

patch applied (cabal-branches/cabal-install-0.8): Use non-Char8 ByteString.readFile for reading 00-index.tar.gz
by Duncan Coutts 10 Mar '10

10 Mar '10

Sun Jan 17 03:38:49 PST 2010 Duncan Coutts <duncan(a)haskell.org> * Use non-Char8 ByteString.readFile for reading 00-index.tar.gz Was showing up on windows as an error decompressing after cabal update. Thanks to Tamar Christina for reporting and helping track down the bug. M ./Distribution/Client/Update.hs -2 +3 View patch online: http://darcs.haskell.org/cabal-branches/cabal-install-0.8/_darcs/patches/20…

1 0

[Hackage] #642: [ghc-6.12] support dynamic linking of executables
by Hackage 09 Mar '10

09 Mar '10

#642: [ghc-6.12] support dynamic linking of executables ----------------------------+----------------------------------------------- Reporter: juhp | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ----------------------------+----------------------------------------------- Currently Cabal does not support dynamical linking of executables against Haskell shared libraries. A workaround is to configure without profiling and pass "--ghc-option=-dynamic" to cabal configure. Configuring with -dynamic and -p links to cabal builds failing with not being able to find p_dyn libraries. [It would be nice if 1.8 could be added to the "Version" selector and 6.12.1 to the "GHC Version" list here in trac.] -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/642> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

Re: [Hackage] #89: Sharing of object files between executable builds?
by Hackage 09 Mar '10

09 Mar '10

#89: Sharing of object files between executable builds? ---------------------------------+------------------------------------------ Reporter: bjorn@… | Owner: blackh Type: enhancement | Status: assigned Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.4.2 Platform: Linux | ---------------------------------+------------------------------------------ Comment(by guest): Stephen's patches work for me. -- Adam Vogt -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:29> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

darcs patch: de-haskell98 twoMains (and 1 more)
by gwern0＠gmail.com 09 Mar '10

09 Mar '10

Mon Mar 8 20:53:28 EST 2010 gwern0(a)gmail.com * de-haskell98 twoMains Mon Mar 8 20:54:16 EST 2010 gwern0(a)gmail.com * de-haskell98 wash2hs

1 0

Re: [Hackage] #89: Sharing of object files between executable builds?
by Hackage 08 Mar '10

08 Mar '10

#89: Sharing of object files between executable builds? ---------------------------------+------------------------------------------ Reporter: bjorn@… | Owner: blackh Type: enhancement | Status: assigned Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.4.2 Platform: Linux | ---------------------------------+------------------------------------------ Comment(by StephenBlackheath): Here's my first attempt at a patch to fix the wrong-package-id/ghc-6.12 issue more or less the right way: http://code.haskell.org/~StephenBlackheath/ticket89/ticket89-wrong- package-id-v1.darcs-send Here is my patch for cabal install to fix the other remaining ticket 89 problem where 'cabal install' fails with "internal error: could not construct a valid install plan." on any package that depends on an internally-defined library: http://code.haskell.org/~StephenBlackheath/ticket89/ticket89-cabal- install-v2.darcs-send Duncan told me he can't get to this right now, but in the meantime I'd appreciate anyone that wants to test or review these patches. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:28> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0