November 2010 - cabal-devel

patch applied (cabal): Export commandParseArgs
by Duncan Coutts 05 Nov '10

05 Nov '10

Fri Nov 5 07:06:55 PDT 2010 Duncan Coutts <duncan(a)haskell.org> * Export commandParseArgs M ./Distribution/Simple/Command.hs -3 +7 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

Re: [Hackage] #428: cabal update uses too much bandwidth
by Hackage 04 Nov '10

04 Nov '10

#428: cabal update uses too much bandwidth --------------------------------+------------------------------------------- Reporter: claus | Type: defect Status: new | Priority: normal Milestone: cabal-install-0.8 | Component: cabal-install tool Version: 1.6.0.1 | Severity: normal Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.8.3 | Platform: --------------------------------+------------------------------------------- Comment(by claus): I just found another reason why this is annoying: when using `--remote- repo`, cabal requires `update`, and that will always re-download the huge hackage index as well as the tiny index for the remote repo. Not to mention that we still have to re-download the huge index every time we want to install a newly updloaded package. The compressed index has now grown to over 2MB! Given that hackage only adds, almost never removes packages, why not have checkpoints of the index every week, and daily tarballs with just the added-since-checkpoint .cabal` files? Then cabal could download just the dailies, starting from the last downloaded local checkpoint. Very little additional technology - just untar the dailies on top of the last checkpoint (if the repo doesn't support dailies, fall back to the current scheme; for hackage, one could either have a server-side script selecting the dailies, or even let cabal do that client-side - the former being more efficient, the latter placing fewer burdens on non-hackage repo providers). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/428#comment:6> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

About building wx and Cabal
by Duncan Coutts 04 Nov '10

04 Nov '10

Jeremy, I've briefly been following your posts about building wx using Cabal (for the benefit of other cabal-devel readers the latest is:) http://wewantarock.wordpress.com/2010/11/03/building-a-shared-library-in-ca… I want to make sure we don't lose what the core problem is and I'd like to work out what the "right" solution would be in terms of extra Cabal features. Perhaps you can translate into a feature request ticket that says what the core problem is (e.g. is it simply that static linking does not work for this C lib etc). Without yet understanding all the details, my first impression is that this problem would fit well with a feature I've been imagining for defining "foreign library" sections in a .cabal file, as opposed to Haskell libraries. These could contain C,C++ code as normal, but would be built using the platform rules, rather than the Haskell compiler rules. I don't yet understand why you've got a constraint on using a shared library, but perhaps the thing to do is simply to allow foreign lib sections to state such a constraint, e.g. the point might be to make a shared lib for a plugin, so a static lib is not the goal. Otoh, if it's possible to both build a static and shared lib from the same description, that's probably a useful thing in many circumstances. Duncan

1 0

Re: [Hackage] #93: Incorrect permissions on library install
by Hackage 03 Nov '10

03 Nov '10

#93: Incorrect permissions on library install ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.8.0.6 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.12.1 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by guest): * ghcversion: 6.10.1 => 6.12.1 * version: 1.1.4 => 1.8.0.6 Comment: It hasn't been mentioned that this actually causes a system-level problem on GNU/Linux which potentially makes it more severe: it makes the mandb cron task at least complain and, I think, actually fail after getting {{{ /usr/bin/mandb: can't open /usr/local/share/man/man1/markdown2pdf.1: Permission denied }}} following a `cabal install --global pandoc', although the binary is installed appropriately. This is with {{{ cabal-install version 0.8.2 using version 1.8.0.6 of the Cabal library }}} -- d.love(haskell) @ liv.ac.uk -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/93#comment:10> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

darcs optimize http://darcs.haskell.org/cabal-install/?
by Christian Maeder 01 Nov '10

01 Nov '10

Can I persuade the cabal-install maintainer? I'm using the new darcs-2.5 Cheers Christian maeder@denebola:~/haskell> darcs get http://darcs.haskell.org/cabal-install/ Converting old-fashioned repository to hashed format... ******************************************************************************* Fetching a hashed repository would be faster. Perhaps you could persuade the maintainer to run darcs optimize --upgrade with darcs 2.4.0 or higher? *******************************************************************************

1 0