- cabal-devel - Haskell.org

Re: Broken head
by Simon Marlow 06 Aug '07

06 Aug '07

Manuel M T Chakravarty wrote: > Running validate on the current (Mon Aug 6 12:42:45 EST 2007) head, > gives me > > /opt/local/bin/ghc -H64m -Onot -fasm -I. -Iinclude -Rghc-timing -O > -fasm -ignore-package Cabal -ignore-package filepath -I../libraries > -fglasgow-exts -no-recomp -c Distribution/System.hs -o > Distribution/System.o -ohi Distribution/System.hi > > ../libraries/Cabal/Distribution/System.hs:14:10: > Not in scope: `System.Info.os' > > This is on MacOS compiling with GHC 6.6.1. > > Duncan, did you run validate before pushing all these recent cabal patches? We shouldn't expect Cabal developers to run GHC's validate when pushing patches. The right thing to do is for GHC to use a branch of Cabal (subset only, so no conflicts), and only push patches to GHC's branch after a validate. This entails some extra overhead to the development model. Thoughts? Cheers, Simon

1 0

Cabal and testing
by Neil Mitchell 05 Aug '07

05 Aug '07

Hi I'm just about to hook up Cabal for doing some testing, so I started with the obvious template: import Distribution.Simple main = defaultMainWithHooks defaultUserHooks{runTests=test} test :: Args -> Bool -> PackageDescription -> LocalBuildInfo -> IO ExitCode test args bool pd lbi = return ExitSuccess A few questions about this interface: 1) What on earth is "bool"? Perhaps either a haddock comment, or a type alias would make it more clear. 2) If the tests fail to run, ExitFailure would be appropriate. If the tests run and pass then ExitSuccess seems sensible. If the tests run, but fail, what should be returned? 3) On failure should I "print" something, or just "error" out? Thanks Neil

2 1

darcs patch: Fix haddock comment.
by Thomas Schilling 04 Aug '07

04 Aug '07

Sat Aug 4 00:49:56 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Fix haddock comment.

1 0

packages with UTF8 in people's names
by Duncan Coutts 04 Aug '07

04 Aug '07

Hi Sascha, We got a bug report the other day that someone could not upload a cabal package that had their name containing UTF8 chars. We were wondering if you could look into it. Here's another similar one: http://hackage.haskell.org/trac/hackage/ticket/145 it may well be that the best way to fix this is in Cabal. We could make sure that Cabal returns properly decoded Strings for all the free-form fields. Tell us if you want particular changes in the Cabal library for that. Duncan

1 0

darcs patch: Fix printing of 'impl' checks. (and 2 more)
by Thomas Schilling 04 Aug '07

04 Aug '07

Fri Aug 3 22:06:22 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Fix printing of 'impl' checks. Fri Aug 3 22:08:29 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Fix import path to HUnit. Fri Aug 3 23:33:31 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Change error message for tabs used as indentation to something more helpful.

1 0

darcs patch: Fix tab in Cabal.cabal. (and 1 more)
by Thomas Schilling 04 Aug '07

04 Aug '07

Fri Aug 3 19:57:01 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Fix tab in Cabal.cabal. Fri Aug 3 20:12:44 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Disallow tabs .cabal files with new syntax

1 0

darcs patch: Add documentation for Cabal Configurations.
by Thomas Schilling 03 Aug '07

03 Aug '07

Fri Aug 3 14:56:32 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Add documentation for Cabal Configurations.

1 0

Re: Good Haskell Style
by Jon Fairbairn 02 Aug '07

02 Aug '07

"Alistair Bayley" <alistair(a)abayley.org> writes: > > It uses -cpp if CPP is in the language extensions in the .cabal file. > > So it does. So now Haddock completes, but produces very limited output. > > > Perhaps unlitting should be done by converting all literate comments > > into {- ... -} style comments. I have a programme (FishFeeder) that does this; it's a bit hacky, but I could post it here if someone was interested in taking it on. > As I alluded to earlier, I have a program which I wrote to do this. It > prefixes "--" rather than enclosing in {- -}, Mine uses {- -} and escapes any such present in comments. Here is the first comment from the source, which is itself literate haddock: | Preprocess literate haskell with Haddockumentation in the literate comments for use with Haddock. So making things a bit prettier Assumes that there is at least one space after every \">\", and indents the \"{-\"s (but not the \"-}\"s) by that much so that Haddock doesn't give a parse error. This is a bit of a hack, but I reckon it's haddock's fault since comments shouldn't have any effect on layout. > and it's not perfect I'd very be surprised if mine were! > (there are a number of cases it doesn't handle, although I'm of the > opinion that you shouldn't be doing whatever it fails on). I'm > thinking it might be feasible to distribute this in the Takusen > release and hook it into the cabal "setup haddock" command to > preprocess the .lhs files. It would surely be better to distribute a tool (either with compilers or with haddock) so that it worked for anyone who likes literate haskell? > I have been tempted to run it over our .lhs once and for all, and > convert everything to regular .hs files, but Oleg seems to like the > birdtrack style, so we've decided to stick with it for now. I much prefer the birdtrack style; it's a matter of taste, and there's nothing more likely to cause disaffection than insisting that someone abide by someone else's taste. I would hate to see it deprecated just because the tools were no good. -- Jón Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk

2 2

Re: Good Haskell Style
by Duncan Coutts 02 Aug '07

02 Aug '07

On Thu, 2007-08-02 at 13:58 +0100, Alistair Bayley wrote: > > and the offending lines in this file are: > > > > #ifndef __HADDOCK__ > > deriving (Functor, Monad, MonadIO, MonadFix, MonadReader sess) > > #else > > -- Haddock can't cope with the "MonadReader sess" instance > > deriving (Functor, Monad, MonadIO, MonadFix) > > #endif > > > > so it would appear that __HADDOCK__ is not defined. > > Sorry, I should have said, "so it appears that -cpp is not being used". It uses -cpp if CPP is in the language extensions in the .cabal file. (At least that's what the code says it's supposed to be doing which is not a guarantee that it works). It does also define __HADDOCK__ when it uses cpp. Hmm, actually there is a problem here. Unlitting does indeed remove all the literate comments, so haddock will never see any markup that is put in the non-code part. To work with current haddock it'd have to be: > -- | This is a haddock comment > foo = ... because that's the only code haddock will see since unlitting turns a literate haskell file into a valid .hs file. It's a purely textual transformation and it's done by removing all the non > lines. Perhaps unlitting should be done by converting all literate comments into {- ... -} style comments. Then it'd probably work with haddock like you have it now: | haddock comment > foo = ... since that'd become: {- | haddock comment -} foo = ... Or something like that. Perhaps that's worth investigating and adding to ghc/cpphs or Cabal's own existing pure Haskell impl of unlitting. Duncan

1 0

darcs patch: Add impl(...) conditional to configurations.
by Thomas Schilling 02 Aug '07

02 Aug '07

Thu Aug 2 03:05:27 CEST 2007 Thomas Schilling <nominolo(a)gmail.com> * Add impl(...) conditional to configurations. You can now use expressions like impl( ghc >= 6.6.1 ) in conditionals in .cabal files.

1 0