November 2010 - cabal-devel

patch: pretty printing for Cabal
by Jürgen Nicklisch-Franken 15 Nov '10

15 Nov '10

I did send this mail a week ago or so to the haskell-libraries mailing list, but this was probably the wrong list. I have in the meantime tested with all cabbal files on haddock, and have fixed some issues. This patch adds a pretty printer for GenericPackageDescription. It fixes ticket http://hackage.haskell.org/trac/hackage/ticket/647. I added a new module Distribution.PackageDescription.PrettyPrint which exports writeGenericPackageDescription and showGenericPackageDescription. I use the field printers from Parse.hs, so that I had to add export statements for them in Distribution.PackageDescription.Parse. I decided to not use a class based approach because: 1. their is already the Text class, which has a parse I didn't want to write, and 2. and more important, I didn't want to use -XFlexibleInstances because I guess cabal should be portable. I have not removed the old printer code, although this may be a good idea (maybe mark it as deprecated first). Then it would make sense as well to rename writeGenericPackageDescription to writePackageDescription and showGenericPackageDescription to showPackageDescription, to be symmetric. I tested with the code from Appendix 1 and all the cabal files on hackage. The test succeds when writing and reading a package description results in an equal description. This is more rigorous then required, cause different GenericPackageDescr.. can have the same semantic, so for example the order of exe definitions is not relevant. But for our needs (GUI editor of cabal files for leksah), e.g. preserving of order is important and it will help to test the parser and printer to make this approach work. Furthermore I want to print out the cabal file as short as possible, e.g. not printing all empty fields like the old printer did. Testing the code I found the following problems: 1. Found up an obvious "age old" bug: hunk ./Distribution/PackageDescription/Parse.hs 359 - ghcProfOptions (\val binfo -> binfo{ghcSharedOptions=val}) + ghcSharedOptions (\val binfo -> binfo{ghcSharedOptions=val}) 2. The order of elements are reversed by the parser. E.g executables: (repos, flags, lib, exes, tests) <- getBody return (repos, flags, lib, exes ++ [(exename, flds)], tests) since the rest is parsed in the line before, the element needs to be prepended. so I changed to: (repos, flags, lib, exes, tests) <- getBody return (repos, flags, lib, (exename, flds): exes, tests) The same applies to test fields. The opposite order problem applies to storeXFields.., which is called in the order of processing, so I changed it to storeXFieldsPD (f@('x':'-':_),val) pkg = Just pkg{ customFieldsPD = (customFieldsPD pkg) ++ [(f,val)]} 3. The next problem is that we print nothing for empty fields , which works ok, except for compiler opts, where empty opts differ from not given opts, so I added this line to optsField in ParseUtils, which causes empty opts to be parsed, as if no opts are given: update f opts [] = [(f,opts)] 4. The next problem is that we loose final newlines with showFreeText. Astonishing enough the culpid is lines from the List module , which evals lines "a\n" to ["a"]. By the way even the claim that "'unlines' is an inverse operation to 'lines'" from the List module is not true, as unlines (lines "a") -> "a\n" (see Appendix 2). So I use my own unlines' now!. 5. This is connected to the CondTree structure. When I write a Cabl file like: ... library extensions: ForeignFunctionInterface if flag(use_xft) build-depends: X11-xft >= 0.2, utf8-string extensions: ForeignFunctionInterface ... the extension ForeignFunctionInterface in the conditional branch is superflous, as it is specified in any case, so the printer can simplify it to: ... library extensions: ForeignFunctionInterface if flag(use_xft) build-depends: X11-xft >= 0.2, utf8-string ... However the parse result for the two cabal files will differ. Now I gave up here, and added a variable simplifiedPrinting which disables the printer smartness for now. However, I hope someone can make the parser smarter in this respect. 6. If free text starts with a line with a dot, the dot must be in a new line. 7. Version tags have to be printed, which was not the case before (why?). 8. VersionRangeParens needs to be printed. 9. Compiler options have to be put in a canonical order after parsing, which is easy as CompilerFlavors do derive Ord. Kind regards Jürgen Nicklisch-Franken PS. I have added a remark about the new test suite syntax below. ------------------- Appendix1: Test code main = do allCabalFiles <- ... res <- mapM test allCabalFiles if and res then putStrLn "all test succeeded" else putStrLn $ "tests failed: " ++ show (length (filter (== False) res)) ++ " of: " ++ show (length res) test :: FilePath -> IO Bool test cabalFilePath = catch (do gpd <- readPackageDescription silent cabalFilePath writeGenericPackageDescription tempPath gpd gpd2 <- readPackageDescription silent tempPath if gpd == gpd2 then do putStr "." return True else do putStrLn $ "failed for " ++ cabalFilePath return False) (\e -> do putStrLn $ "runtime error " ++ show e ++ " for " ++ cabalFilePath return False) ------------------ Appendix2: lines and unlines revised: -- | 'unlines' is an inverse operation to 'lines'. -- It joins lines, after appending a terminating newline to each. unlines' :: [String] -> String unlines' [] = [] unlines' [x] = x unlines' (x:xs) = x ++ ('\n' : unlines' xs) -- | 'lines' breaks a string up into a list of strings at newline -- characters. The resulting strings do not contain newlines. lines' :: String -> [String] lines' [] = [""] lines' s = let (l, s') = break (== '\n') s in l : case s' of [] -> [] (_:s'') -> lines' s'' ---------------- Appendix 3: I find the test suite syntax problematic, for an exe I have to remeber the combination: test-suite foo type: exitcode-stdio-1.0 main-is: main.hs , and for a module: test-suite bar type: library-1.0 test-module: Bar So its the combination of exitcode-stdio- and main-is or library- and test-module which does the trick. Wouldn't it be easier to write something like: test-suite foo test-version: 1.0 main-is: main.hs , and for a module: test-suite bar test-version: 1.0 test-module: Bar

2 2

Re: [Hackage] #656: Cabal-1.8-style dependencies stop Haddock from working
by Hackage 15 Nov '10

15 Nov '10

#656: Cabal-1.8-style dependencies stop Haddock from working ------------------------------+--------------------------------------------- Reporter: Ivan Miljenovic | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal library | Version: 1.8.0.4 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ------------------------------+--------------------------------------------- Changes (by mitar): * cc: mitar (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/656#comment:9> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

"Not a repository" error on darcs pull/send on hackage-server
by Vo Minh Thu 12 Nov '10

12 Nov '10

Hi, I'd like to create and send the patches I worked on during BelHac. This morning I tried several times to `darcs pull` from hackage-server but it failed (until the last time, when it succeded) with "darcs failed: Not a repository". Now, I have the same error trying to `darcs send`. Is it possible to create the patches without Internet connectivity? Thanks, Thu

2 1

[Hackage] #763: Warn about unused flags in Cabal file
by Hackage 11 Nov '10

11 Nov '10

#763: Warn about unused flags in Cabal file ----------------------------+----------------------------------------------- Reporter: tibbe | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Cabal should output a warning during configure if a flag is defined but never used. I almost forgot to delete an old flag due to removing its use sites but not its definition. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/763> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #420: cabal-install upgrade optionally ignore packages that want a higher base?
by Hackage 11 Nov '10

11 Nov '10

#420: cabal-install upgrade optionally ignore packages that want a higher base? --------------------------------+------------------------------------------- Reporter: jimburton | Type: enhancement Status: new | Priority: normal Milestone: cabal-install-0.8 | Component: cabal-install tool Version: 1.2.3.0 | Severity: normal Keywords: | Difficulty: normal Ghcversion: 6.8.3 | Platform: --------------------------------+------------------------------------------- Changes (by james_m_chapman): * cc: james@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/420#comment:6> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

cabal runhaskell Setup makefile
by David Peixotto 10 Nov '10

10 Nov '10

The latest cabal documentation[1] indicates that I should be able to $ runhaskell Setup makefile to generate a Makefile from the cabal file. When I try running this command I get the following: $ runhaskell Setup makefile unrecognised command: makefile (try --help) Is this command available on some version of cabal? I'm using 1.8.0.2 of the library. $ cabal --version cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library Thanks! [1]: http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/builders.…

2 1

Re: [Hackage] #656: Cabal-1.8-style dependencies stop Haddock from working
by Hackage 10 Nov '10

10 Nov '10

#656: Cabal-1.8-style dependencies stop Haddock from working ------------------------------+--------------------------------------------- Reporter: Ivan Miljenovic | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal library | Version: 1.8.0.4 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ------------------------------+--------------------------------------------- Changes (by GeoffreyMainland): * cc: mainland@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/656#comment:8> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #704: sort out design for foreign code in Haskell libraries
by Hackage 09 Nov '10

09 Nov '10

#704: sort out design for foreign code in Haskell libraries ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Currently we often happily add little bits of C glue code into Haskell packages. This is perfectly reasonably but we also want to be able to do things like linking multiple versions of a Haskell package into a single application. That does not work if the C symbols are visible outside of the package (see #701). It seems reasonable to require that C code in a Haskell package respects the properties that we want for Haskell packages. However we must also allow for libraries that are foreign code and not Haskell libraries at all. For example, the zlib binding package ships a complete copy of the zlib C code for platforms that do not have it natively. Unlike bits of FFI glue code, it is unreasonable to expect to change the zlib code to conform to Haskell library requirements. Perhaps what we need is to explicitly identify foreign libraries and hold them to different (lower) standards compared to Haskell libraries. One idea would be to draw together the features proposed in these tickets: * #276 : support for convenience libraries * #148 : producing foreign libraires The idea with convenience libraries is that a package can have multiple libraries in it, even though at most one can be the library that has exposed modules. Other libraries could be used by executables or the main library in that package. The main purpose is sharing but it could also be a way to separate the requirements of haskell code and foreign code. Producing foreign libraries is about making libraries (usually but not necessarily containing Haskell code) that export a foreign C API and are not intended to be used by other Haskell code. Combining these two features would allow for the zlib example to work ok. We would declare a foreign library with the zlib C code and make the main Haskell binding library depend on it. Note that packages that depend on the binding package would not directly link to the C library (this is significant for shared libs). The key constraint for foreign libraries is that we cannot link more than one version into a single application (because the symbols would clash), where as we may assume that it is perfectly safe to link multiple versions of a Haskell package. Any design must also consider symbol visibility. This is relevant both for shared and static libs. With static libs it is hard to avoid every symbol being globally visible. With shared libs there is greater control over symbol visibility but also the restriction on some systems that each shared lib must resolve all symbol references. This means we must more explicitly identify which libraries import symbols from others. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/704> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #758: expose existing functionality: fetchPackage/unpackPackage
by Hackage 09 Nov '10

09 Nov '10

#758: expose existing functionality: fetchPackage/unpackPackage ---------------------------------+------------------------------------------ Reporter: claus | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ `cabal-install` has functionality for fetching and unpacking `cabal` packages (`.tar.gz`, as produced by `cabal sdist`). It would be very helpful to expose these functions as `cabal-install` commands. `unpackPackage` is the more important of the two, though being able to fetch individual packages from URLs (think blogs, wikis, ..) without having to establish a full hackage-like repo would also be very welcome. Most importantly, you could remove the whole http://www.haskell.org/haskellwiki/How_to_unpack_a_tar_file_in_windows hazzle. Instead of package authors and users having to worry about whether some unpacker is installed client-side, everyone could just rely on {{{ cabal unpack Example.tar.gz }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/758> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

Re: [Hackage] #597: non-exhaustive patterns when trying to install base
by Hackage 09 Nov '10

09 Nov '10

#597: non-exhaustive patterns when trying to install base ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.2 Severity: minor | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | ---------------------------------+------------------------------------------ Comment(by duncan): If someone wants to fix this, the other thing to check is with and older or newer GHC that does not have two versions of base. A user reported that with ghc-6.6 they get an "impossible" internal error in this situation. The general fix here is to have a per-compiler list of packages that are impossible to upgrade. If the user explicitly asks to install one then they should get a sensible error. For all other cases it should use a constraint on picking an installed instance of these packages. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/597#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0