patch applied (cabal): Fix warnings
Sun Sep 23 05:29:21 PDT 2007 Ian Lynagh [EMAIL PROTECTED] * Fix warnings M ./Distribution/Simple.hs -2 +1 ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #157: Haddock command fails when dependent documentation is not installed
#157: Haddock command fails when dependent documentation is not installed -+-- Reporter: duncan |Owner: Type: defect | Status: closed Priority: normal |Milestone: Component: Cabal | Version: 1.2.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: easy (4 hours) Ghcversion: 6.4.2 | Platform: Linux -+-- Changes (by duncan): * resolution: = fixed * status: new = closed -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/157 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: [Hackage] #14: allow preprocessing for Main modules
#14: allow preprocessing for Main modules -+-- Reporter: ijones |Owner: duncan Type: defect | Status: closed Priority: high|Milestone: Cabal-1.2 Component: Cabal | Version: 1.1.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: easy Ghcversion: 6.2.1 | Platform: Linux -+-- Changes (by duncan): * resolution: = fixed * status: assigned = closed -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/14 Hackage http://example.com/ My example project___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: RFC: Extended version-range descriptions for Cabal
Thomas Schilling wrote: (1) Wildcards: 1.* ~~ = 1 2 in general m.n.o.* ~~= m.n.o m.n.(o+1) I like this. (2) Ranges: 1 - 2.1 ~~= 1 = 2.1 in general m - n ~~ = m = n If the upper limit is supposed to be exclusive, this can be combined with (1): 1 - 2.0.* ~~ = 1 2.1 I like this, too, though maybe to instead of - would be a more readable token to use. A possible alternatve syntax (subsuming both (1) and (2)) could be: [1, 2.1] ~~ = 1 = 2.1 [1, 2.1) ~~ = 1 2.1 This is too prone to fencepost errors due to the ease of getting the parens wrong. Also, interval notation isn't widely enough used that people will readily remember which kind of paren means what. b ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: RFC: Extended version-range descriptions for Cabal
Hi m.n.o.* ~~= m.n.o m.n.(o+1) I like this. Me too. m - n ~~ = m = n I would much prefer m .. n as the syntax, as that is the syntax for ranges in Haskell. Thanks Neil ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: RFC: Extended version-range descriptions for Cabal
On Mon, Sep 24, 2007 at 09:53:16PM +0200, Thomas Schilling wrote: can lead to rather awkward descriptions of common version ranges, for example, base = 1 2 I don't think anything more is needed, but... (1) Wildcards: 1.* ~~ = 1 2 in general m.n.o.* ~~= m.n.o m.n.(o+1) I have no objections to this. Note, that the translation is not = 1.0 2, because that would exclude version 1, as [1] [1,0] == True. I'm not convinced that that isn't a bug. (2) Ranges: 1 - 2.1 ~~= 1 = 2.1 I don't like that. I don't think someone writing that means to not include 2.1.0.0.1. If the upper limit is supposed to be exclusive, this can be combined with (1): 1 - 2.0.* ~~ = 1 2.1 This reads very oddly to me. I'd like include this into Cabal-1.2 which is scheduled with the next ghc release, so it can fearlessly be used when getting packages ready for GC 6.8.1. I'd prefer we had more time to consider the syntax, as we don't want to be stuck with supporting whatever we come up with in the eleventh hour. Thanks Ian ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: RFC: Extended version-range descriptions for Cabal
On Mon, 2007-09-24 at 21:36 +0100, Neil Mitchell wrote: Hi m.n.o.* ~~= m.n.o m.n.(o+1) I like this. Me too. m - n ~~ = m = n I would much prefer m .. n as the syntax, as that is the syntax for ranges in Haskell. Right, that's another option. Though, I'm not sure how that looks with dots in version. For comparision: Build-depends: base 1.1 to 2.1.*, filepath 1.1 to 1.* Build-depends: base 1.1 .. 2.1.*, filepath 1.1 .. 1.* Build-depends: base 1.1 - 2.1.*, filepath 1.1 - 1.* Build-depends: base [1.1, 2.2), filepath [1.1, 2) Spaces would be recommended (but not required) in any case. / Thomas ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: RFC: Extended version-range descriptions for Cabal
On Mon, 2007-09-24 at 22:02 +0100, Ian Lynagh wrote: On Mon, Sep 24, 2007 at 09:53:16PM +0200, Thomas Schilling wrote: can lead to rather awkward descriptions of common version ranges, for example, base = 1 2 I don't think anything more is needed, but... (1) Wildcards: 1.* ~~ = 1 2 in general m.n.o.* ~~= m.n.o m.n.(o+1) I have no objections to this. Note, that the translation is not = 1.0 2, because that would exclude version 1, as [1] [1,0] == True. I'm not convinced that that isn't a bug. Ack, me neither. (2) Ranges: 1 - 2.1 ~~= 1 = 2.1 I don't like that. I don't think someone writing that means to not include 2.1.0.0.1. Well, this leads to the issue if versioning schemes make promises about compatibility, and if so, whether Cabal should deal with those. For example, using the common scheme major.minor.patch-level Cabal should not use foo 2.1 to satisfy foo = 1 as it might be (and likely is) incompatible. But it should always use foo 1.2.3 to satisfy dependency foo 1.2, but not necessarily foo 1.4. We could allow giving semantics to versioning schemes like this, but I am neither sure what the details should be, nor if this would really be worth it. As a compromise, this special case could be disallowed, by forcing the pattern m - n.*( or: m .. n.* ) but I guess that this would seem like an unnecessary restriction. If the upper limit is supposed to be exclusive, this can be combined with (1): 1 - 2.0.* ~~ = 1 2.1 This reads very oddly to me. I'd like include this into Cabal-1.2 which is scheduled with the next ghc release, so it can fearlessly be used when getting packages ready for GC 6.8.1. I'd prefer we had more time to consider the syntax, as we don't want to be stuck with supporting whatever we come up with in the eleventh hour. Fair enough. If people agree that it's not that useful or can't easily agree on what it should look like, I will not push it. I think at least (1) is uncontroversial and (2) would be a nice-to-have for the 'base' package. /Thomas ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: build-depends in old-style package descriptions
On Tue, Sep 18, 2007 at 10:02:52AM +0100, Ross Paterson wrote: Could we not just replace (deps, libfs1) = partition ((`elem` constraintFieldNames) . fName) libfs0 libfs = if null libfs1 not (null deps) then [F (lineNo (head deps)) buildable False] else libfs1 with (deps, libfs) = partition ((`elem` constraintFieldNames) . fName) libfs0 Is there any reason not to do this? It would simplify the interface for clients. ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
