- cabal-devel - Haskell.org

patch applied (cabal): Define bracketOnError in compat; fixes the build for GHC 6.4
by Ian Lynagh 14 May '08

14 May '08

Tue May 13 17:39:19 PDT 2008 Ian Lynagh <igloo(a)earth.li> * Define bracketOnError in compat; fixes the build for GHC 6.4 A ./Distribution/Compat/Exception.hs M ./Distribution/Simple/Utils.hs -1 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080514003919-3fd76-c86be214…

1 0

patch applied (cabal): Print exit code and stderr for failing progs at debug level verbosity
by Duncan Coutts 13 May '08

13 May '08

Tue May 13 02:40:55 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Print exit code and stderr for failing progs at debug level verbosity Also adjust the verbosity level we get during configure at -v3 Should make it a bit easier to track down failing calls. M ./Distribution/Simple/Utils.hs -1 +10 M ./Distribution/Verbosity.hs -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080513094055-adfee-2bca3dd5…

1 0

Re: Specifying dependencies on Haskell code
by Simon Marlow 12 May '08

12 May '08

Roman Leshchinskiy wrote: > IMO, a package is absolutely the wrong thing to depend on. Essentially, > a package is an implementation of an interface and depending on > implementations is a bad thing. Code should only depend on interfaces > which are completely independent entities. I suspect that a lot of the > problems with packages occur because the current system doesn't follow > this simple principle. > > It would be nice if Cabal had an explicit concept of interfaces, with > the idea that code depends on them and packages implement them. In the > simplest case, an interface is just a name. Ideally, it would be a > combination of type signatures, Quickcheck properties, proof obligations > etc. The important thing is that it has an explicit definition which is > completely independent of any concrete implementation and which never > changes. > > Something like this would immediately solve a lot of problems. Several > packages could implement the same interface and we could pick which one > we want when building stuff. We could have much more fine-grained > dependencies (if all I need is an AVL tree, I don't want to depend on > the entire containers package, but rather just on the AVL part of it). > One package could implement several versions of an interface to ensure > compatibility with old code (I could imagine module names like > AVL_1.Data.AVLTree, AVL_2.Data.AVLTree etc., where AVL_1 and AVL_2 are > interface names; Cabal could then map the right module to Data.AVLTree > when building). If interface definitions include something like > Quickcheck properties, we would have at least some assurance that a > package actually does implement its interfaces. Moreover, this would > also make the properties themselves reusable. We already have interfaces, in the sense that a package *is* an interface. You're suggestion decoupling these notions, which I believe would add a lot of extra complexity without enough benefit to make it worthwhile. Let's take the examples you gave above: 1. several packages could implement the same interface. This can be done by having a single package that exports an interface and depends on one of the underlying "providers" selected at build-time. 2. fine-grained dependencies: just split up packages, or define new packages that just re-export parts of existing packages, if that's what you want. 3. one package could implement several versions of an interface. This is no different from having several versions of a package that can all be installed and used together. 4. interface definitions could have QuickCheck properties. Absolutely! And packages can have QuickCheck properties too. Admittedly in order to do most of this we need to be able to define packages that re-export the contents of other packages. You can in fact already do this, but it's clumsy, we just need some tool and compiler support to make it smoother. I'm already convinced that we need this, and I believe we should do it in the GHC 6.10 timeframe in order to allow better backwards compatibility. Using the Package Versioning Policy we have a clear way to know when a package's interface has changed, or when the interface has remained the same but the implementation has changed. We need tool support to check that the author is adhering to the PVP, though. Basically the current scheme minimizes the cognitive load by having a single concept (the package) that embodies several units: distribution, licensing, dependency, linking (amongst others). Cheers, Simon

1 0

patch applied (cabal-install): Update for distPref changes
by Duncan Coutts 12 May '08

12 May '08

Sun May 11 17:54:44 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Update for distPref changes M ./Hackage/Install.hs -2 +5 M ./Hackage/SetupWrapper.hs -13 +16 M ./Hackage/SrcDist.hs -3 +4 M ./Main.hs -13 +28 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080512005444-adfee-…

1 0

patch applied (cabal): Remove a hardcoded "dist"
by Ian Lynagh 12 May '08

12 May '08

Sun May 11 11:13:05 PDT 2008 Ian Lynagh <igloo(a)earth.li> * Remove a hardcoded "dist" M ./Distribution/Simple/Program.hs -3 +5 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080511181305-3fd76-09642c50…

1 0

patch applied (cabal): Make the "dist" directory configurable
by Ian Lynagh 12 May '08

12 May '08

Sun May 11 08:56:40 PDT 2008 Ian Lynagh <igloo(a)earth.li> * Make the "dist" directory configurable M ./Distribution/Simple.hs -31 +60 M ./Distribution/Simple/Build.hs -10 +13 M ./Distribution/Simple/BuildPaths.hs -9 +7 M ./Distribution/Simple/Configure.hs -21 +21 M ./Distribution/Simple/Haddock.hs -11 +17 M ./Distribution/Simple/Install.hs -5 +7 M ./Distribution/Simple/Register.hs -26 +28 M ./Distribution/Simple/Setup.hs -6 +102 M ./Distribution/Simple/SetupWrapper.hs -3 +4 M ./Distribution/Simple/SrcDist.hs -3 +5 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080511155640-3fd76-c04c9e3e…

1 0

patch applied (cabal): Remove gnerated file (doc/fptools.css)
by Ian Lynagh 12 May '08

12 May '08

Sun May 11 06:00:35 PDT 2008 Ian Lynagh <igloo(a)earth.li> * Remove gnerated file (doc/fptools.css) R ./doc/fptools.css View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080511130035-3fd76-fbdc261f…

1 0

patch applied (cabal): Fix a bug in the unlitter
by Ian Lynagh 11 May '08

11 May '08

Sat May 10 16:38:52 PDT 2008 Ian Lynagh <igloo(a)earth.li> * Fix a bug in the unlitter If we see a birdtrack while we are in latex mode, then we stay in latex mode - don't change into bird mode! M ./Distribution/Simple/PreProcess/Unlit.hs -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080510233852-3fd76-b123a0a8…

1 0

[Hackage] #260: cabal upgrade runs install on the current package instead of upgrading installed packages
by Hackage 11 May '08

11 May '08

#260: cabal upgrade runs install on the current package instead of upgrading installed packages ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ---------------------------------+------------------------------------------ I was very suprised when I tried to use cabal to upgrade my installed packages today: {{{ $ cabal upgrade cabal: No cabal file found. Please create a package description file <pkgname>.cabal }}} Looks like Cabal tries to do a build instead so I tried it in a directory with a .cabal file: {{{ $ cd hyena $ cabal upgrade Configuring hyena-0.1.0... Preprocessing library hyena-0.1.0... Preprocessing executables for hyena-0.1.0... Building hyena-0.1.0... ar: creating archive dist/build/libHShyena-0.1.0.a [5 of 7] Compiling Hyena.Logging ( Hyena/Logging.hs, dist/build/hello- world/hello-world-tmp/Hyena/Logging.o ) [6 of 7] Compiling Hyena.Server ( Hyena/Server.hs, dist/build/hello- world/hello-world-tmp/Hyena/Server.o ) [7 of 7] Compiling Main ( ./Hyena/HelloWorld.hs, dist/build /hello-world/hello-world-tmp/Main.o ) Linking dist/build/hello-world/hello-world ... Installing: /Users/tibell/.cabal/lib/hyena-0.1.0/ghc-6.8.2 Installing: /Users/tibell/.cabal/bin Registering hyena-0.1.0... Reading package info from "dist/installed-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. }}} Instead of upgrading my installed packages it installed ''this'' package! Here are Cabal and cabal-install versions: {{{ $ cabal --version cabal-install version 0.4.4 using version 1.3.7 of the Cabal library }}} I've synced from HEAD today. Here are the latest patches I'm using. Cabal: {{{ Wed Mar 12 21:39:47 CET 2008 Duncan Coutts <duncan(a)haskell.org> * Fix search dirs used for pre-processing executables }}} and for cabal-install: {{{ Wed Mar 12 14:53:35 CET 2008 Duncan Coutts <duncan(a)haskell.org> * Parse filepaths in the config file the same way as in .cabal files }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/260> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #278: Default to non-versioned links in Hackage index
by Hackage 11 May '08

11 May '08

#278: Default to non-versioned links in Hackage index --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: HackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | --------------------------------+------------------------------------------- When one visits http://hackage.haskell.org/packages/archive/pkg-list.html and looks for, say, Don's pcre-light, one sees: '# pcre-light library: A small, efficient and portable regex library for Perl 5 compatible regular expressions'. When one clicks upon it, one goes to the link http://hackage.haskell.org /cgi-bin/hackage-scripts/package/pcre-light-0.3.1 For me, this is not good. Suppose I'm editing a README or a wiki page, and I want to add a Hackage link: 'For the Hackage'd packages...' 'you can find pcre-light on Hackage at...'. In this case, what I want is a link to *all* the pcre-lights. As it happens, I discovered by accident that I can in fact do that sort of link: http://hackage.haskell.org/cgi-bin/hackage- scripts/package/pcre-light (and ever since, I've been manually editing the URL). This one will default to taking you to the 0.3.1 page, but if a more recent pcre-light is uploaded, it'll then take you to it instead (I believe). This makes perfect sense in the most common use case. Yes, people will want to link to a specific version sometimes, but to draw an analogy: if I tell you to go read up on Catamorphisms on Wikipedia, and I want to copy-paste the URL, is it better for Wikipedia to send me to https://secure.wikimedia.org/wikipedia/en/wiki/Catamorphism - or https://secure.wikimedia.org/wikipedia/en/w/index.php?title=Catamorphism&ol… ? -- gwern -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/278> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2