May 2008 - cabal-devel

patch applied (cabal): Make Distribution.Compat.Char for isSymbol; fixes the build with GHC 6.4
by Ian Lynagh 13 May '08

13 May '08

Tue May 13 17:47:03 PDT 2008 Ian Lynagh <igloo(a)earth.li> * Make Distribution.Compat.Char for isSymbol; fixes the build with GHC 6.4 A ./Distribution/Compat/Char.hs M ./Distribution/ParseUtils.hs -1 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080514004703-3fd76-0d4e6716…

1 0

patch applied (cabal): Hack around lack of Read for Map in GHC 6.4
by Ian Lynagh 13 May '08

13 May '08

Tue May 13 17:44:00 PDT 2008 Ian Lynagh <igloo(a)earth.li> * Hack around lack of Read for Map in GHC 6.4 This is made worse by Show on Map being strange in GHC 6.4. The code could be better, but it works, and all the ugliness is in #if's that we can remove at some point down the line. M ./Distribution/PackageDescription/Configuration.hs -1 +31 M ./Distribution/Simple/PackageIndex.hs +30 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080514004400-3fd76-f920b119…

1 0

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

13 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 11 May '08

11 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 11 May '08

11 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 11 May '08

11 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 11 May '08

11 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