- cabal-devel - Haskell.org

2 patches for cabal report
by Vo Minh Thu 17 Nov '10

17 Nov '10

Hi, Here are two patches to make `cabal report` works; one for caba-install, one for hackage-server. The patch for hackage-server actually has another patch within to bring in the crypt library when building hackage-mirror. Cheers, Thu

2 1

Re: Hackage-server: GHC 7
by Antoine Latter 16 Nov '10

16 Nov '10

Just to follow-up on this - Most things are pretty easy to get this working, all of the code tweaks needed I believe have been pushed out. The rest of the changes will be to the package description, which I'm holding off on for now. The big holdups are getting happstack running. Happstack HEAD with syb-with-class HEAD both work on GHC 7, but neither have been released. I also have a patch against happstack-stable: http://groups.google.com/group/happs/browse_thread/thread/ad8497bec62f6b96# But I don't know if there will be another release from the 0.5 series. There should be a problem running any of the changes on GCH 6.12, and 6.10 compatibility wouldn't be hard (as long as happstack keeps the CPP hacks in place). Antoine On Sun, Nov 7, 2010 at 10:53 PM, Matthew Gruen <wikigracenotes(a)gmail.com> wrote: > On Wed, Nov 3, 2010 at 6:08 AM, Duncan Coutts > <duncan.coutts(a)googlemail.com> wrote: >> On Sat, 2010-09-25 at 22:01 -0500, Antoine Latter wrote: >>> Hi folks, >>> >>> I've been working on seeing what it takes to get hackage-server >>> running on GHC 7 + the new libs that ship with it. For the most part, >>> it's been pretty painless - a lot easier than the move to 6.12 was >>> last year. It helps that the biggest breaking change (no longer >>> generalizing non top-level bindings) is fixed by adding the ocasional >>> type signature, which won't break any older versions. >>> >>> Happstack requires a few fixes, though, which I'm requesting be pushed >>> against happstack-head. Would anyone be inconvenienced hackage-server >>> required happstack-head? They plan on cutting a release around >>> October. >> >> Sounds ok to me. Ok Matthew? >> > > This sounds like a great idea :) I may have a spot of quiet for the > next few weeks (between midterm season and final project panicking), > and I'm taking some time to see what kinks can be ironed out. > Switching to head will hopefully do some ironing for me, though I > think it's mostly SimpleHTTP that's improved, not so much state. > > /Matt >

1 0

Higher upper bounds for GHC 7 support
by Michael Snoyman 16 Nov '10

16 Nov '10

The following reddit thread: http://www.reddit.com/r/haskell/comments/e6o0y/ghc_701_released/c15s7rj brought up some problems building cabal-install with GHC 7. I think increasing the upper bounds on Cabal and cabal-install as below will get them to compile with GHC 7. Cabal: filepath 1.2 directory 1.1 containers 0.4 cabal-install: time 1.2

1 0

[Hackage] #765: can't read Synopsis for Data.Vector.Storable
by Hackage 15 Nov '10

15 Nov '10

#765: can't read Synopsis for Data.Vector.Storable ----------------------------+----------------------------------------------- Reporter: warren | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- When I open the Synopsis tab for Data.Vector.Storable (http://hackage.haskell.org/packages/archive/vector/0.7.0.1/doc/html/Data- Vector-Storable.html) it is too wide for my monitor (1440x900). There is a scroll bar, but the text on the left extends past the left edge of the screen and cannot be scrolled to. This makes the synopsis unusable. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/765> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

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