March 2008 - cabal-devel

patch applied (cabal-branches/cabal-1.4): Tweak warning message about bool fields to include the field name
by Duncan Coutts 29 Mar '08

29 Mar '08

Thu Mar 27 18:20:06 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Tweak warning message about bool fields to include the field name Warning: The 'buildable' field is case sensitive, use 'True' or 'False'. M ./Distribution/ParseUtils.hs -2 +2 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008032801…

1 0

patch applied (cabal-branches/cabal-1.4): Simplify the parser for flags in conditions
by Duncan Coutts 29 Mar '08

29 Mar '08

Thu Mar 27 15:16:32 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Simplify the parser for flags in conditions It's a bit more consistent. M ./Distribution/PackageDescription/Configuration.hs -6 +5 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008032722…

1 0

patch applied (cabal-branches/cabal-1.4): We do not show the field value on a parse error so don't pretend we do.
by Duncan Coutts 29 Mar '08

29 Mar '08

Thu Mar 27 15:14:42 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * We do not show the field value on a parse error so don't pretend we do. Drop the trailing ": " on the error message. We could provide the field value but they're often multi-line and we cannot pin-point where the error is exactly. M ./Distribution/ParseUtils.hs -2 +2 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008032722…

1 0

patch applied (cabal-branches/cabal-1.4): Use the Text Bool instance for parsing literals in conditions
by Duncan Coutts 29 Mar '08

29 Mar '08

Thu Mar 27 14:55:01 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Use the Text Bool instance for parsing literals in conditions Since it exactly matches what the previous condition parser did. So we have two different ways of parsing Bool depending on context. Sigh. Both match exactly what was done in Cabal-1.2. M ./Distribution/PackageDescription/Configuration.hs -3 +2 M ./Distribution/Text.hs -4 +4 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008032721…

1 0

patch applied (cabal-branches/cabal-1.4): Parse Bool fields using more cunning, allow new parses with a warning
by Duncan Coutts 29 Mar '08

29 Mar '08

Thu Mar 27 14:34:11 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Parse Bool fields using more cunning, allow new parses with a warning We want to allow case-insensitive parsing however we don't want packages being uploaded to hackage that will break older versions of Cabal. If we allow new valid parses then we will end up breaking stuff. So what we really want to do is allow new parses but warn if they're not ones that older versions of Cabal would have allowed. So long as hackage rejects pakcages that have parse warnings then we can prevent new .cabal files appearing on hackage that would break older Cabal versions. Our current parser (ReadP) does not support warnings so we have to handle the bool fields specially in the parser wrapper layer that we added to handle errors and warnings. This can go away when we use a parser with support for error and warning messages. M ./Distribution/InstalledPackageInfo.hs -3 +2 M ./Distribution/PackageDescription/Parse.hs -4 +2 M ./Distribution/ParseUtils.hs -2 +20 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008032721…

1 0

patch applied (cabal): TAG 1.5.1
by Duncan Coutts 29 Mar '08

29 Mar '08

Sat Mar 29 11:13:29 PDT 2008 Duncan Coutts <duncan(a)haskell.org> tagged 1.5.1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080329181329-adfee-b72ba20e…

1 0

patch applied (cabal): Bump version to 1.5.1 -- the next development series
by Duncan Coutts 29 Mar '08

29 Mar '08

Sat Mar 29 11:11:46 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Bump version to 1.5.1 -- the next development series Though we should try and limit divergence until 1.4.0 is released. M ./Cabal.cabal -2 +2 M ./Makefile -1 +1 M ./releaseNotes -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080329181146-adfee-64736be8…

1 0

Re: [Hackage] #145: Hackage does not support UTF-8 characters
by Hackage 28 Mar '08

28 Mar '08

#145: Hackage does not support UTF-8 characters --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.4 Component: HackageDB website | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.4.2 | Platform: --------------------------------+------------------------------------------- Comment (by ross(a)soi.city.ac.uk) We're constrained by the behaviour of Text.XHtml here. I've added a meta tag to declare the charset that it's using, but it might be safer for Text.XHtml to escape everything over 127. Alternatively, if we were to serve UTF-8, the cgi package would be the appropriate place to do that. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/145#comment:5> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #145: Hackage does not support UTF-8 characters
by Hackage 28 Mar '08

28 Mar '08

#145: Hackage does not support UTF-8 characters --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.4 Component: HackageDB website | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.4.2 | Platform: --------------------------------+------------------------------------------- Comment (by guest): /packages/archive/pkg-list.html is potentially broken because it's served as utf-8 (being static) when it's intended to be viewed as latin1. Dynamic pages are instead correctly served as latin1 because that's the default for runCGI. This derives from the behaviour of the HTML Char instance in the xhtml package: it expects unicode codepoints and escapes chars >= 255 with a numerical escape. (note that the first 255 codepoints of unicode correspond to latin1) Hence it works fine as long as everything is served as latin1, so we should either set that in the webserver configuration for static pages or directly in the page itself. Or is it maybe better to produce utf8 pages? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/145#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal): Make UTF-8 decoding errors in .cabal files non-fatal
by Duncan Coutts 28 Mar '08

28 Mar '08

Wed Mar 26 20:17:40 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Make UTF-8 decoding errors in .cabal files non-fatal Previously we checked for invalid UTF-8 in the first phase of the parser, which splitting the file up into nested sections and fields. This meant the whole parser falls over if there is invalid UTF-8 anywhere in the file. Sadly there are already packages on hackage with invalid UTF-8 so we would fail when parsing the hackage index. The solution is to move the check into the parsing of the individual fields and making it a warning not an error. We most typically get invalid UTF-8 in free text fields like author name, copyright, description etc so this should work out ok usually. We now get pretty decent error messages, like: Warning: hsx.cabal:5: Invalid UTF-8 text in the 'author' field. The warning type is now structured so that hackage will be able to distinguish general non-fatal warnings from UTF-8 decoding problems which really should be fatal errors for package uploads. M ./Distribution/PackageDescription/Parse.hs -2 +8 M ./Distribution/ParseUtils.hs -20 +19 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080327031740-adfee-d022f8e7…

2 8