July 2008 - cabal-devel

Re: consistency in "ghc-pkg field '*' haddock-html"?
by Duncan Coutts 20 Jul '08

20 Jul '08

On Sat, 2008-07-19 at 21:58 +0100, Claus Reinke wrote: > >> - some entries '/', some use '\\', some use a combination of > >> '/' and *unescaped* '\' (the latter two come from ghc's > >> cabal configure run either with or without --prefix) > > > > That's fine. They use \\ when using Haskell String format. When not then > > windows accepts both \ and / as path separators, it's not an escape > > char. > > Since windows is so forgiving, why not be consistent and always > use '/'? We do. But if someone passes Cabal a path containing '\' then we don't interpret or check it, we just use it. > That also reduces the number of escapes as well as the > danger of missing escapes when going via several levels of > shells/interpretation. Only the double quotes to protect spaces > remain necessary. The convention everywhere in Cabal (and in the ghc-pkg registration files) is to allow Haskell String syntax. It's only essential when one wants to use characters that would otherwise be interpreted as separators. > > It's not strictly necessary for ghc-pkg to know where index files are > > that cover various packages but it would be nice to do something better > > there. People ask for Cabal to maintain an index over all packages > > though it's not clear where it should put this. > > For context: I've just extended the haskellmode plugins for Vim > to handle docs for libraries outside code+extra (not yet online), > and while it was no big deal working around all those inconsistencies, > it certainly seemed unnecessary and ugly. > > Right now, only core+extralibs have a unified index, and that can > be found by all kinds of ugly guesses (though ghc-paths will help > there in the future). Once Cabal generates and maintains a master > index, perhaps there could simply be a standard file pointing to it, > in the haddock-html dirs? It would not be per-package of course so I don't think it makes sense to put it in package registration files. Duncan

1 1

Re: consistency in "ghc-pkg field '*' haddock-html"?
by Duncan Coutts 19 Jul '08

19 Jul '08

On Sat, 2008-07-19 at 11:02 +0100, Claus Reinke wrote: > When I issue the command from the subject line in a relatively > bare built-from-darcs GHC HEAD on windows, this is what I get: > > $ ghc-pkg field '*' haddock-html > haddock-html: > haddock-html: file:///c:/ghc/ghc-6.9.20080514/doc/libraries/ghc-prim > haddock-html: file:///c:/ghc/ghc-6.9.20080514/doc/libraries/integer > haddock-html: file:///c:/ghc/ghc-6.9.20080514/doc/libraries/base > haddock-html: file:///c:/ghc/ghc-6.9.20080514/doc/libraries/array > .. > haddock-html: c:/ghc/ghc-6.9.20080514/html/libraries/ghc > haddock-html: c:/ghc/libraries\doc\ghc-paths-0.1.0.1\html > haddock-html: c:/ghc/libraries\doc\haskell-src-exts-0.3.4\html > haddock-html: "C:\\Program Files\\Haskell\\doc\\uniplate-1.2.0.1\\html" > > The first empty line is from rts (as you can confim by using > ghc-pkg field '*' name,haddock-html instead), which is correct, > as that package has no Haddocks. But note the rest: > > - some entries '/', some use '\\', some use a combination of > '/' and *unescaped* '\' (the latter two come from ghc's > cabal configure run either with or without --prefix) That's fine. They use \\ when using Haskell String format. When not then windows accepts both \ and / as path separators, it's not an escape char. > - some entries are URLs, some entries are path names Yeah, that's not good. > - the entry for the ghc package is a lie (the html/ directory > doesn't exist, and the doc/html/libraries/ directory has > no ghc package docs) Blame the ghc build system :-) > - while the paths for the core and extra libraries are strictly > speaking correct, there is no indication that all of them > have been integrated into a unified index (one level up), > in contrast to the addon packages, which have their own > indices > > It would be helpful if the consistency and usefulness of this > data could be improved, eg, cabal always using '/' and be > consistent in its escape strategy, ghc and cabal using either > all URLs or all path names, not adding paths for non-existing > docs, and having some indication of whether the package docs > have been integrated into some global documentation index. Cabal uses whatever path the user tells us to use. Whenever Cabal makes up its own paths it uses the standard path separator for the platform. When the path contains spaces it has to use the String format because space is a field separator. So the problems as I see it are why the core packages are using urls. It's not strictly necessary for ghc-pkg to know where index files are that cover various packages but it would be nice to do something better there. People ask for Cabal to maintain an index over all packages though it's not clear where it should put this. Duncan

1 0

[Hackage] #314: smaller logo PNG
by Hackage 19 Jul '08

19 Jul '08

#314: smaller logo PNG ----------------------------------+----------------------------------------- Reporter: brian0 | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: hackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.8.2 Platform: | ----------------------------------+----------------------------------------- Drop-in replacement for Cabal-With-Text.png about 5KB smaller than the original. Made with optipng. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/314> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #313: line counting
by Hackage 16 Jul '08

16 Jul '08

#313: line counting ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- It would be nice if Cabal had a way to do source line counting. Two programs I know of to do the hard work are sloccount http://www.dwheeler.com/sloccount/ and ohcount http://labs.ohloh.net/ohcount I've also attached a small perlscript from the GHC source tree, but it has some drawbacks (most notably, only supporting Haskell). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/313> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

patch applied (cabal): Put GHC's programArgs in GHC_OPTS when making a Makefile
by Ian Lynagh 16 Jul '08

16 Jul '08

Tue Jul 15 06:24:29 PDT 2008 Ian Lynagh <igloo(a)earth.li> * Put GHC's programArgs in GHC_OPTS when making a Makefile M ./Distribution/Simple/GHC.hs +3 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080715132429-3fd76-208de379…

1 0

patch applied (cabal): Pass -package-conf foo when using GHC as CC
by Ian Lynagh 14 Jul '08

14 Jul '08

Sun Jul 13 05:39:58 PDT 2008 Ian Lynagh <igloo(a)earth.li> * Pass -package-conf foo when using GHC as CC M ./Distribution/Simple/GHC.hs +3 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080713123958-3fd76-56b54d4e…

1 0

patch applied (cabal): If we are using ghc as hsc2hs's cc, then tell it where package.conf is
by Ian Lynagh 14 Jul '08

14 Jul '08

Sun Jul 13 04:05:48 PDT 2008 Ian Lynagh <igloo(a)earth.li> * If we are using ghc as hsc2hs's cc, then tell it where package.conf is if we have been told to use a specific one with --package-db M ./Distribution/Simple/PreProcess.hs -1 +8 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080713110548-3fd76-7f0018b7…

1 0

Config parse failure
by Allan 13 Jul '08

13 Jul '08

Dear all Currently if cabal-install encounters a parse failure in the configuration file it just uses the default configuration with a warning. This seems like the wrong behaviour to me since it is only correct if the user was using the default configuration and then updated to a newer version of cabal-install which caused the old default-config to be syntactically correct. A much more common reason is that the user has made an error when editing their config file and in this case using the default configuration is almost certainly the wrong thing to do. Attached is a patch to "die" on configuration parse failure while also writing out a default configuration to ~/.cabal/config.default that the user can use if they so wish. regards allan

1 0

patch applied (cabal): Fix installing datafiles
by Ian Lynagh 13 Jul '08

13 Jul '08

Sat Jul 12 10:39:34 PDT 2008 Ian Lynagh <igloo(a)earth.li> * Fix installing datafiles If datadir is foo and the datafile is bar then we should install it to $datadir/bar, not $datadir/foo/bar. M ./Distribution/Simple/Install.hs -3 +5 M ./Distribution/Simple/Utils.hs +11 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080712173934-3fd76-9e38979e…

1 0

patch applied (cabal): Fix the "Setup makefile" rules for C files
by Ian Lynagh 13 Jul '08

13 Jul '08

Sat Jul 12 10:38:51 PDT 2008 Ian Lynagh <igloo(a)earth.li> * Fix the "Setup makefile" rules for C files M ./Distribution/Simple/GHC/Makefile.hs -1 +1 M ./Distribution/Simple/GHC/Makefile.in -2 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080712173851-3fd76-ba04c234…

1 0