From trac at galois.com Wed Apr 2 14:10:55 2008 From: trac at galois.com (Hackage) Date: Wed Apr 2 14:06:52 2008 Subject: [Hackage] #264: unionBuildInfo should not always use nub Message-ID: <042.1b5c379209554d2eb3bda0e32cc13593@localhost> #264: unionBuildInfo should not always use nub ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- The below report was originally filed as http://hackage.haskell.org/trac/ghc/ticket/2190 In libraries/Cabal/Distribution/PackageDescription.hs, the unionBuildInfo function combines, for example, ldOptions from two BuildInfos, using nub to eliminate duplicate arguments. This is wrong for ldOptions and some other elements. For example, if ldOptions contains: {{{-Xlinker -R -Xlinker /dir1 -Xlinker -R -Xlinker /dir2}}} Then the nubbed result is: {{{-Xlinker -R /dir1 /dir2}}} which doesn't work at all. There may be some redundancy that could be eliminated, but for arguments passed to external programs, it can only be done safely by understanding the semantics of the arguments. Similarly for extraLibs, {{{-lfoo -lbar -lfoo}}} may be necessary if {{{libfoo}}} and {{{libbar}}} reference each other's symbols. Using nub is wrong for at least cppOptions, ccOptions, ldOptions, and extraLibs. But I think it is necessary for some other BuildInfo components, like hsSourceDirs, so it can't be removed completely; that results in an error while building GHC: {{{ Preprocessing library unix-2.3.0.0... Generating Makefile unix-2.3.0.0... Setup: makefile: can't cope with multiple hs-source-dirs yet, sorry }}} So {{{combine}}} could take an extra arguments, which would be nub in some cases or id in others. -- Ticket URL: Hackage Hackage: Cabal and related projects From ndmitchell at gmail.com Thu Apr 3 09:04:24 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Apr 3 09:00:20 2008 Subject: Cabal bugs/oddities Message-ID: <404396ef0804030604lce03b3uddd5bde4366624f1@mail.gmail.com> Hi, All these bugs are against the homeomorphic library I have written. To play along, you can do darcs get --partial http://www.cs.york.ac.uk/fp/darcs/homeomorphic Bug 1: cabal install worked the first time, running it a second time fails. $ cabal install .. works.. $ cabal install .. configuring ... setupWrapper in Nothing : ["build"] Preprocessing library homeomorphic-0.1... Building homeomorphic-0.1... E:\ghc\ghc-6.8.2\bin\ar.exe: creating dist\build\libHShomeomorphic-0.1.a setupWrapper in Nothing : ["install"] cabal: Error: some packages failed to install: homeomorphic-0.1 failed during the final install step. Bug 2: cabal haddock fails $ cabal haddock Preprocessing library homeomorphic-0.1... Running Haddock for homeomorphic-0.1... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: base-3.0.1.0, QuickCheck-1.1.0.0, mtl-1.1.0.0, containers-0.1.0.1 dist/build/tmp/Data/Homeomorphic/Hash1.hs:4:0: Include/Hash.hs: No such file or directory This one may well be my fault, if some extra magic is required for the haddock with CPP, but not the building - but that seems weird, if there is enough info to build the file, surely there is enough info to haddock it Bug 3: Cabal upload doesn't work: $ cabal upload Username: ... Password: .... Not even a "goodbye and thanks for your password, I'm off to raid your paypal". It should certainly say something $ cabal upload dist E:\Neil\homeomorphic>cabal upload dist\homeomorphic-0.1.tar.gz Hackage username: NeilMitchell Hackage password: yoda Uploading dist\homeomorphic-0.1.tar.gz... ERROR: dist\homeomorphic-0.1.tar.gz: 400 Error in upload 400 error in upload - not the worlds most helpful error message... Bug 4: Cabal upload asks for your password in plain text. That one is security related - you are asking for someones password, and giving the appearance that you aren't overly fussed about keeping it secret. Thanks Neil From duncan.coutts at worc.ox.ac.uk Sat Apr 5 15:18:42 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Apr 5 15:14:32 2008 Subject: patch applied (cabal-install): Add missing modules in other-modules, fixes sdist Message-ID: <20080405191842.GA32598@haskell.galois.com> Sun Mar 30 12:37:10 PDT 2008 Spencer Janssen * Add missing modules in other-modules, fixes sdist M ./cabal-install.cabal +3 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080330193710-a5988-80e80d161cb6c1d36068c2366844fff0b6ee8b61.gz From duncan.coutts at worc.ox.ac.uk Sun Apr 6 13:15:09 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 6 13:10:59 2008 Subject: ANNOUNCE: Cabal-1.4 release candidate In-Reply-To: <20080330194717.GB8952@celeborn> References: <20080329203104.5981084128@webmail219.herald.ox.ac.uk> <20080330194717.GB8952@celeborn> Message-ID: <1207502109.13231.1.camel@dell.linuxdev.us.dell.com> On Sun, 2008-03-30 at 14:47 -0500, Spencer Janssen wrote: > On Sat, Mar 29, 2008 at 08:31:04PM +0000, Duncan Coutts wrote: > > == cabal-install == > > > > A snapshot of cabal-install is available: > > http://haskell.org/cabal/release/cabal-install-0.4.6.tar.gz > > This tarball is missing several files. See my 'Add missing modules' patch. Thanks, applied. I'll put out another release soonish, though probably after the hackathon at this rate. Duncan From peteg42 at gmail.com Sun Apr 6 21:25:05 2008 From: peteg42 at gmail.com (Peter Gammie) Date: Sun Apr 6 21:21:02 2008 Subject: Cabal, profiling, GHC 6.6.1 Message-ID: <2C500BB8-F693-4B9B-94AA-012ACA621D61@gmail.com> Hello, I've built some libraries using "-p" and installed them, resulting in e.g.: mjollnir-debian ~$ ls ~/lib/hsql-postgresql-1.7/ghc-6.6.1/ Database HShsql-postgresql-1.7.o include libHShsql-postgresql-1.7.a libHShsql-postgresql_p-1.7.a When I try to use them: mjollnir-debian ~$ ghc -prof -auto-all -Wall -fglasgow-exts -main- is Import.News.main --make -o news ghc_rts_opts.c Import.News [..] Linking news ... /usr/bin/ld: cannot find -lHShsql-postgresql-1.7_p collect2: ld returned 1 exit status make: *** [news] Error 1 Note that Cabal created "libHShsql-postgresql_p-1.7.a" but GHC expected "libHShsql-postgresql-1.7_p.a". Is this an issue with GHC 6.6.1 or Cabal? cheers peter From duncan.coutts at worc.ox.ac.uk Sun Apr 6 21:42:41 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 6 21:38:24 2008 Subject: patch applied (cabal): Fix names of profiling libs Message-ID: <20080407014240.GA30689@haskell.galois.com> Sun Apr 6 18:34:49 PDT 2008 Duncan Coutts * Fix names of profiling libs I broke this recently when refactoring. Restore the original behaviour. Was generating "libHSfoo_p-1.0.a" when it should be "libHSfoo-1.0_p.a". M ./Distribution/Simple/BuildPaths.hs -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080407013449-adfee-dbba5be8f9c656558808e40de1f7b7d4d7abb213.gz From duncan.coutts at worc.ox.ac.uk Sun Apr 6 21:44:08 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 6 21:39:49 2008 Subject: Cabal, profiling, GHC 6.6.1 In-Reply-To: <2C500BB8-F693-4B9B-94AA-012ACA621D61@gmail.com> References: <2C500BB8-F693-4B9B-94AA-012ACA621D61@gmail.com> Message-ID: <1207532648.13231.69.camel@dell.linuxdev.us.dell.com> On Mon, 2008-04-07 at 08:25 +0700, Peter Gammie wrote: > Note that Cabal created "libHShsql-postgresql_p-1.7.a" but GHC > expected "libHShsql-postgresql-1.7_p.a". > > Is this an issue with GHC 6.6.1 or Cabal? It's an issue with Cabal. I broke it. :-) I've pushed a patch to fix it. This reminds us that we need a decent set of automated regression tests. It's too easy to break the less commonly used features. Lennart has been looking at this a bit which is good. Duncan From duncan.coutts at worc.ox.ac.uk Sun Apr 6 22:38:13 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 6 22:33:55 2008 Subject: patch applied (cabal-branches/cabal-1.4): Fix names of profiling libs Message-ID: <20080407023813.GA31875@haskell.galois.com> Sun Apr 6 18:34:49 PDT 2008 Duncan Coutts * Fix names of profiling libs I broke this recently when refactoring. Restore the original behaviour. Was generating "libHSfoo_p-1.0.a" when it should be "libHSfoo-1.0_p.a". M ./Distribution/Simple/BuildPaths.hs -1 +1 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080407013449-adfee-dbba5be8f9c656558808e40de1f7b7d4d7abb213.gz From peteg42 at gmail.com Mon Apr 7 04:30:54 2008 From: peteg42 at gmail.com (Peter Gammie) Date: Mon Apr 7 04:26:52 2008 Subject: Cabal, profiling, GHC 6.6.1 In-Reply-To: <1207532648.13231.69.camel@dell.linuxdev.us.dell.com> References: <2C500BB8-F693-4B9B-94AA-012ACA621D61@gmail.com> <1207532648.13231.69.camel@dell.linuxdev.us.dell.com> Message-ID: On 07/04/2008, at 8:44 AM, Duncan Coutts wrote: > On Mon, 2008-04-07 at 08:25 +0700, Peter Gammie wrote: > >> Note that Cabal created "libHShsql-postgresql_p-1.7.a" but GHC >> expected "libHShsql-postgresql-1.7_p.a". >> >> Is this an issue with GHC 6.6.1 or Cabal? > > It's an issue with Cabal. I broke it. :-) > > I've pushed a patch to fix it. Thanks Duncan, that worked great. I should say I'm pretty amazed at how usable Cabal is now. Thanks again for your hard work. cheers peter From trac at galois.com Mon Apr 7 11:47:12 2008 From: trac at galois.com (Hackage) Date: Mon Apr 7 11:42:58 2008 Subject: [Hackage] #223: allow per-package configuration options in config file In-Reply-To: <043.9e5a6edffae59aa9c9bd9e84111a1e75@localhost> References: <043.9e5a6edffae59aa9c9bd9e84111a1e75@localhost> Message-ID: <052.f1d9643f3803d2435d01b2b24c0ad917@localhost> #223: allow per-package configuration options in config file ---------------------------------+------------------------------------------ Reporter: duncan | Owner: mnislaih Type: enhancement | Status: assigned Priority: normal | Milestone: Cabal-1.4 Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ---------------------------------+------------------------------------------ Comment (by guest): It would be useful to be able to specify flags in the config file for all the commands and not only for configure e.g. install's --root-cmd. This poses the question if it should be possible to specify different defaults for the same flag for two different commands. -- Ticket URL: Hackage Hackage: Cabal and related projects From explicitcall at googlemail.com Mon Apr 7 14:46:07 2008 From: explicitcall at googlemail.com (Max Desyatov) Date: Mon Apr 7 14:41:50 2008 Subject: [GSoC] Cabal 'make-like' dependency framework Message-ID: Hi, There are only few hours until the deadline, but I still have some hope to receive comments to improve my proposal. The goal of the project I am intending to do is to develop a working prototype of a make-style module/file dependency framework for the Cabal, which is the most actively evolving Haskell build system at the moment. At this time building process with Cabal is somewhat imperative and depends on GHC's "--make" option or hmake when building modules written in the Haskell language. Thus, new dependency system should support its own module chasing from a description given the declarative style, which would give a possibility to add many new features and resolve old bugs in the Haskell Cabal (as there are currently more than 10 tickets which depend on the dependency tracking implementation). Pre-processors (c2hs e.g.) and some other Haskell compilers, which don't have their own dependency system, would greatly benefit from this improvement. Gtk2hs will also greatly benefit from this project, as at this time it uses shell language and limited functional language on top (make) for its build system which prevents handling of dynamic dependencies in the right way. Absence of dependencies tracking in Cabal prevents gtkhs to be cabalised fully. Getting some ideas from the first sketchy prototype we can see that dynamic dependencies should be supported, i.e. some actions can be run while computing the dependency graph. The plan to deploy the code of the project in the real use cases is to code dependency resolver for yhc or nhc98 (depends on the difficulty of integration with existing compiler codebase). Doing this won't hurt ghc support, which is quite important. The great part of the work is contriving an embedded domain specific language for the make actions specification. This will reduce complexity, role of imperative parts and code size of Cabal in general. The form of this EDSL needs careful investigation. The system should be fairly generic and extensible for actions and rules to be expressed crearly. Framework can be customised with pre-processors or other actions which are run in the process of the dependency resolving. For the aid in testing and clarifying project goals some sophisticated examples will be constructed (using pre-processors, cases with search path shadowing etc). Seeing the existing problems we can decide how to improve Cabal for their resolution. With the help of parametrisation over a type of used monad for actions we can do tests without any IO through QuickCheck. Do you think there are some things in this abstract I should remove or I should definitely add? Are there some wrong assumptions or things that can go beyond my project? Thanks for advance for any advice, comment or question. -- Max From peteg42 at gmail.com Tue Apr 8 00:09:56 2008 From: peteg42 at gmail.com (Peter Gammie) Date: Tue Apr 8 00:05:41 2008 Subject: Cabal partial builds Message-ID: Hello, Is it possible to ask Cabal to just build one of the targets in the .cabal file? I have a bunch of executables in a single file, most of which are uninteresting while developing. I'd like to say: runghc Setup build blah and have "blah" built (and its dependencies, when you have the framework) but not blah2 etc. cheers peter From sanzhiyan at gmail.com Tue Apr 8 11:01:36 2008 From: sanzhiyan at gmail.com (Andrea Vezzosi) Date: Tue Apr 8 10:57:20 2008 Subject: Cabal partial builds In-Reply-To: References: Message-ID: <8625cd9c0804080801v3e75f159vc6b06e3730904458@mail.gmail.com> You can almost get that with cabal configurations and the field Buildable: [...] Flag devel Default: False [...] Executable foo if flag(devel) Buildable: False [...] With that if you pass --flags="devel" to configure the executable foo won't be built. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/cabal-devel/attachments/20080408/ff4bc581/attachment.htm From trac at galois.com Tue Apr 8 19:02:57 2008 From: trac at galois.com (Hackage) Date: Tue Apr 8 18:58:35 2008 Subject: [Hackage] #265: Cabal field stability not useful Message-ID: <042.a3d936740f7b920fec16947f94343a86@localhost> #265: Cabal field stability not useful ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- As it stands, the 'stability:' field isn't very useful. Hardly anyone uses it, and even if someone does, it does minimal good, since it's just an arbitrary string. I propose it be changed into an enumerated type, like license: is. That way we could do things like have cabal-install warn when installing unstable, add view filters to Hackage, and so on. This is all stuff that'd be pretty ad-hoc if done on whatever strings package authors were writing. Now, what should the entries be? Ideally, we'd like to be able to say a couple things. We'd like to say that a release is Stable, or Unstable. For example, HaXml's most recent package on Hackage is Unstable, and that's why Goerzen's Hpodder uses an older, Stable, version of HaXml. But we'd also like to express not just stability, but feature-completeness - Alpha, Beta, Release. It's perfectly sensible to have a piece of software which is a Stable Alpha; early XMonads were very stable (I was using it from the first public repo patches, and it only ever crashed a handful of times, less than StumpWM). And equally I'd suggest you could have Unstable Betas. Most cabal files I've seen using stability: seem to use 'Stable', 'Unstable', 'Experimental', 'Alpha', or 'Beta'. (Although GTK2HS seems to be using 'Stability: provisional'). So perhaps one could make the stability field accept 0-2 entries: one from Stable/Unstable, and one from Experimental/Alpha/Beta/Release. -- gwern -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Tue Apr 8 22:31:27 2008 From: trac at galois.com (Hackage) Date: Tue Apr 8 22:27:03 2008 Subject: [Hackage] #244: Add Changelog summary feature to sdist In-Reply-To: <042.b58cd479042a6bb23287737855b11716@localhost> References: <042.b58cd479042a6bb23287737855b11716@localhost> Message-ID: <051.86722f75ce49c6eb6ed7776c98aa8b96@localhost> #244: Add Changelog summary feature to sdist ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: low | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by guest): It's worth noting that Darcs actually already has a little utility program which parses 'darcs changes'; it's probably a useful place to start. -- Ticket URL: Hackage Hackage: Cabal and related projects From peteg42 at gmail.com Tue Apr 8 23:49:32 2008 From: peteg42 at gmail.com (Peter Gammie) Date: Tue Apr 8 23:45:25 2008 Subject: Cabal partial builds In-Reply-To: <8625cd9c0804080801v3e75f159vc6b06e3730904458@mail.gmail.com> References: <8625cd9c0804080801v3e75f159vc6b06e3730904458@mail.gmail.com> Message-ID: Andrea: On 08/04/2008, at 10:01 PM, Andrea Vezzosi wrote: > You can almost get that with cabal configurations and the field > Buildable: > [...] > Flag devel > Default: False > [...] > Executable foo > if flag(devel) > Buildable: False > [...] > > With that if you pass --flags="devel" to configure the executable > foo won't be built. Thanks for the advice. Coincidentally I started down that path yesterday, and it somewhat works. I have a problem with package dependencies now. I've attached the .cabal file and build -v output below. In brief: I want to build a bunch of binaries that depend more-or-less on the same packages. 'configure' goes through fine, but then Cabal does not include the packages in the 'build' step. Clearly I have to state the dependencies another way, but is there one that avoids a lot of repetition? cheers peter name: site version: 0.1 license: BSD3 license-file: ../LICENSE author: peteg42 at gmail dot com homepage: http://peteg.org/ category: Text synopsis: A Hope site description: Build binaries for a Hope site. build-type: Simple cabal-version: >= 1.2 build-depends: base, cgi, haskell98, hsql-postgresql, hope, mtl, utf8-string Flag FastCGI description: Build a Fast CGI binary. default: False Flag Import description: Build the import binaries. default: False Executable hope.cgi if flag(FastCGI) buildable: False GHC-Options: -Wall Hs-Source-Dirs: . c-sources: ghc_rts_opts.c Main-Is: Hope/CGI.hs Executable hope.fcgi if !flag(FastCGI) buildable: False else build-depends: fastcgi GHC-Options: -Wall Hs-Source-Dirs: . c-sources: ghc_rts_opts.c Main-Is: Hope/FastCGI.hs Executable elibrary if !flag(Import) buildable: False build-depends: hope-elibrary GHC-Options: -Wall Hs-Source-Dirs: . Main-Is: Import/ELibrary.hs Executable news if !flag(Import) buildable: False GHC-Options: -Wall Hs-Source-Dirs: . Main-Is: Import/News.hs Executable user if !flag(Import) buildable: False GHC-Options: -Wall Hs-Source-Dirs: . Main-Is: Import/User.hs $ runghc Setup d -v Creating dist/build (and its parents) Creating dist/build/autogen (and its parents) Preprocessing executables for site-0.1... Building site-0.1... Building executable: hope.cgi... Creating dist/build/hope.cgi (and its parents) Creating dist/build/hope.cgi/hope.cgi-tmp (and its parents) Building C Sources. Creating dist/build/hope.cgi/hope.cgi-tmp (and its parents) /usr/bin/ghc -package hope-elibrary-0.1 -optc-O2 -odir dist/build/ hope.cgi/hope.cgi-tmp -c ghc_rts_opts.c /usr/bin/ghc -o dist/build/hope.cgi/hope.cgi --make -hide-all-packages -i -idist/build/autogen -idist/build/hope.cgi/hope.cgi-tmp -i. -Idist/ build/hope.cgi/hope.cgi-tmp -odir dist/build/hope.cgi/hope.cgi-tmp - hidir dist/build/hope.cgi/hope.cgi-tmp -package hope-elibrary-0.1 -O - Wall dist/build/hope.cgi/hope.cgi-tmp/ghc_rts_opts.o ./Hope/CGI.hs ./Hope/CGI.hs:8:7: Could not find module `Network.CGI': it is a member of package cgi-3001.1.5.1, which is hidden From duncan.coutts at worc.ox.ac.uk Wed Apr 9 16:57:06 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Apr 9 16:52:40 2008 Subject: nice little Cabal gotcha In-Reply-To: References: Message-ID: <1207774626.6082.23.camel@dell.linuxdev.us.dell.com> Hi Peter, On Mon, 2008-04-07 at 18:37 +0700, Peter Gammie wrote: > Imagine this: you're hacking a library, and occasionally you put a "- > p" on your config line and sometimes you don't. Yep. And Cabal doesn't track if the profiling versions of dependencies are installed. > (My cycle is occasional-clean-setup then build, which I grant might be > a bit paranoid. I get impatient and fiddle with the profiling and > optimisation options.) > > Now, if one compiles a library with "-p", then without it, the old > profiling library persists in the installed location, leading to some > head scratching when a later compilation with a "-p" config option > mysteriously fails. You mean because the old version of the profiling lib is installed but it does not match the newer non-profiling version? So building a dependent lib with -p fails with weird complication errors? > Two proposals: > > - rm -r $INSTALL_LOCATION (e.g. ~/lib/package/) > (brutal but effective; I think Cabal should claim ownership of at > least the package subdirs that it will populate) > - print "Compiling normally..." and "Compiling for profiling..." to > make it clearer when the compilation craps out We could easily do the latter. > I guess you'll be squeamish about the first one, Yep :-) > but I for one would like such an option when hacking. There are two ways we could do it, one is to make it possible to build several related packages without installing them all, then we have complete control over what is in the dist/ dir and we know when the profiling versions of libs are out of date. Another way is for cabal-install to gain more package management features and remember what files belong to a package, so then we can uninstall packages and when we replace packages we can remove all files belonging to the existing instance of that package. Duncan From duncan.coutts at worc.ox.ac.uk Wed Apr 9 16:58:35 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Apr 9 16:54:08 2008 Subject: nice little Cabal gotcha In-Reply-To: References: Message-ID: <1207774715.6082.26.camel@dell.linuxdev.us.dell.com> Peter, BTW, do file a bug report describing this issue so we do not forget. If you want to include my two suggestions then you could link it to the ticket aboug making cabal/cabal-install remember what files it installs. Duncan On Mon, 2008-04-07 at 18:37 +0700, Peter Gammie wrote: > Imagine this: you're hacking a library, and occasionally you put a "- > p" on your config line and sometimes you don't. > > (My cycle is occasional-clean-setup then build, which I grant might be > a bit paranoid. I get impatient and fiddle with the profiling and > optimisation options.) > > Now, if one compiles a library with "-p", then without it, the old > profiling library persists in the installed location, leading to some > head scratching when a later compilation with a "-p" config option > mysteriously fails. > > Two proposals: > > - rm -r $INSTALL_LOCATION (e.g. ~/lib/package/) > (brutal but effective; I think Cabal should claim ownership of at > least the package subdirs that it will populate) > - print "Compiling normally..." and "Compiling for profiling..." to > make it clearer when the compilation craps out > > I guess you'll be squeamish about the first one, but I for one would > like such an option when hacking. > > cheers > peter From duncan.coutts at worc.ox.ac.uk Wed Apr 9 17:28:49 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Apr 9 17:24:23 2008 Subject: Cabal bugs/oddities In-Reply-To: <404396ef0804030604lce03b3uddd5bde4366624f1@mail.gmail.com> References: <404396ef0804030604lce03b3uddd5bde4366624f1@mail.gmail.com> Message-ID: <1207776529.6082.40.camel@dell.linuxdev.us.dell.com> On Thu, 2008-04-03 at 14:04 +0100, Neil Mitchell wrote: > Hi, > > All these bugs are against the homeomorphic library I have written. To > play along, you can do Thanks Neil, I'll try this when I get a second. I presume this is on Windows. What version of Cabal were you using? > darcs get --partial http://www.cs.york.ac.uk/fp/darcs/homeomorphic > > Bug 1: > cabal install worked the first time, running it a second time fails. Hmm. Nothing obvious from the log and it works for me on Linux. I'll have to try it on Windows. > Bug 2: cabal haddock fails > dist/build/tmp/Data/Homeomorphic/Hash1.hs:4:0: > Include/Hash.hs: No such file or directory > > This one may well be my fault, if some extra magic is required for the > haddock with CPP, but not the building - but that seems weird, if > there is enough info to build the file, surely there is enough info to > haddock it Right, there is no such guarantee at the moment. That's because ghc --make can find things by import chasing where Cabal needs more stuff specified explicitly. One day when Cabal does the import chasing they'll be consistent. In this case though it doesn't look like on of those problems. It seems to be because for haddock we're copying files to dist/ and then running cpp on them. That means of course that relative #includes do not work. It's not entirely clear to me why we are copying them before running cpp and not just running cpp on the files from their original locations. Please file a ticket for this one. > Bug 3: > Cabal upload doesn't work: > > $ cabal upload > Username: ... > Password: .... You reported this one before and I fixed it: $ cabal upload cabal: the 'upload' command expects one or more .tar.gz packages. > $ cabal upload dist > E:\Neil\homeomorphic>cabal upload dist\homeomorphic-0.1.tar.gz > Hackage username: NeilMitchell > Hackage password: yoda > Uploading dist\homeomorphic-0.1.tar.gz... > ERROR: dist\homeomorphic-0.1.tar.gz: 400 Error in upload > > 400 error in upload - not the worlds most helpful error message... Indeed. There is an error message available but I'm not sure how we get at it. Any ideas Ross? Another ticket for this one. > Bug 4: > > Cabal upload asks for your password in plain text. That one is > security related - you are asking for someones password, and giving > the appearance that you aren't overly fussed about keeping it secret. I'm happy to add that if anyone can figure out the code to do it. It's presumably different on ANSI terminals and the Windows command console. So yet another ticket for that. Duncan From trac at galois.com Wed Apr 9 17:49:16 2008 From: trac at galois.com (Hackage) Date: Wed Apr 9 17:44:50 2008 Subject: [Hackage] #266: cabal haddock plus cpp preprocessing with relative #include files Message-ID: <042.bc60c790871f8b697ce6a62e68096370@localhost> #266: cabal haddock plus cpp preprocessing with relative #include files ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- All these bugs are against the homeomorphic library I have written. To play along, you can do darcs get --partial http://www.cs.york.ac.uk/fp/darcs/homeomorphic Bug 2: cabal haddock fails $ cabal haddock Preprocessing library homeomorphic-0.1... Running Haddock for homeomorphic-0.1... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: base-3.0.1.0, QuickCheck-1.1.0.0, mtl-1.1.0.0, containers-0.1.0.1 dist/build/tmp/Data/Homeomorphic/Hash1.hs:4:0: Include/Hash.hs: No such file or directory This one may well be my fault, if some extra magic is required for the haddock with CPP, but not the building - but that seems weird, if there is enough info to build the file, surely there is enough info to haddock it Duncan says: Right, there is no such guarantee at the moment. That's because ghc --make can find things by import chasing where Cabal needs more stuff specified explicitly. One day when Cabal does the import chasing they'll be consistent. In this case though it doesn't look like on of those problems. It seems to be because for haddock we're copying files to dist/ and then running cpp on them. That means of course that relative #includes do not work. It's not entirely clear to me why we are copying them before running cpp and not just running cpp on the files from their original locations. Please file a ticket for this one. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Wed Apr 9 17:52:32 2008 From: trac at galois.com (Hackage) Date: Wed Apr 9 17:48:05 2008 Subject: [Hackage] #267: cabal upload has poor error messages (just an HTTP response code) Message-ID: <042.7406bd491a8ebc93e9f9e327d9e092d9@localhost> #267: cabal upload has poor error messages (just an HTTP response code) ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- All these bugs are against the homeomorphic library I have written. To play along, you can do darcs get --partial http://www.cs.york.ac.uk/fp/darcs/homeomorphic $ cabal upload dist E:\Neil\homeomorphic>cabal upload dist\homeomorphic-0.1.tar.gz Hackage username: NeilMitchell Hackage password: yoda Uploading dist\homeomorphic-0.1.tar.gz... ERROR: dist\homeomorphic-0.1.tar.gz: 400 Error in upload 400 error in upload - not the worlds most helpful error message... Duncan says: Indeed. There is an error message available but I'm not sure how we get at it. Any ideas Ross? Another ticket for this one. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Wed Apr 9 17:55:24 2008 From: trac at galois.com (Hackage) Date: Wed Apr 9 17:50:56 2008 Subject: [Hackage] #268: cabal upload asks for a password in plain text Message-ID: <042.194090d9016445d7e9ae4a0e3ba60d0f@localhost> #268: cabal upload asks for a password in plain text ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- > > Cabal upload asks for your password in plain text. That one is > > security related - you are asking for someones password, and giving > > the appearance that you aren't overly fussed about keeping it secret. > > I'm happy to add that if anyone can figure out the code to do it. It's > presumably different on ANSI terminals and the Windows command console. getChar in a loop? You can always do: c <- getChar putChar '*' If you so feel like it. You can even use putStr "\b \b" to move back one character, even on Windows. -- Ticket URL: Hackage Hackage: Cabal and related projects From ndmitchell at gmail.com Wed Apr 9 17:55:59 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed Apr 9 17:51:40 2008 Subject: Cabal bugs/oddities In-Reply-To: <1207776529.6082.40.camel@dell.linuxdev.us.dell.com> References: <404396ef0804030604lce03b3uddd5bde4366624f1@mail.gmail.com> <1207776529.6082.40.camel@dell.linuxdev.us.dell.com> Message-ID: <404396ef0804091455u309a336vf28bef195a7f18c@mail.gmail.com> Hi > I presume this is on Windows. What version of Cabal were you using? HEAD whenever the original message was sent. Windows is always a safe bet with me :-) > > Bug 1: > > cabal install worked the first time, running it a second time fails. > > Hmm. Nothing obvious from the log and it works for me on Linux. I'll > have to try it on Windows. Its entirely possible its a bug in ghc-pkg rather than cabal. Perhaps those pesky .manifest files are still floating around breaking something. > Bug 2: > Please file a ticket for this one. Done #266 > > Bug 3: > > Cabal upload doesn't work: > > > > $ cabal upload > > Username: ... > > Password: .... > > You reported this one before and I fixed it: Yeah, but when I tried again it didn't work still. I wonder why - its possible one of the versions isn't as up to date as I think. Otherwise, it may still be an issue - did you push the patch? > > $ cabal upload dist > > E:\Neil\homeomorphic>cabal upload dist\homeomorphic-0.1.tar.gz > > Hackage username: NeilMitchell > > Hackage password: yoda > > Uploading dist\homeomorphic-0.1.tar.gz... > > ERROR: dist\homeomorphic-0.1.tar.gz: 400 Error in upload > > > > 400 error in upload - not the worlds most helpful error message... > > Indeed. There is an error message available but I'm not sure how we get > at it. Any ideas Ross? > > Another ticket for this one. #267 > > Cabal upload asks for your password in plain text. That one is > > security related - you are asking for someones password, and giving > > the appearance that you aren't overly fussed about keeping it secret. > > I'm happy to add that if anyone can figure out the code to do it. It's > presumably different on ANSI terminals and the Windows command console. getChar in a loop? You can always do: c <- getChar putChar '*' If you so feel like it. You can even use putStr "\b \b" to move back one character, even on Windows. #268 Thanks Neil From trac at galois.com Wed Apr 9 20:16:03 2008 From: trac at galois.com (Hackage) Date: Wed Apr 9 20:11:36 2008 Subject: [Hackage] #267: cabal upload has poor error messages (just an HTTP response code) In-Reply-To: <042.7406bd491a8ebc93e9f9e327d9e092d9@localhost> References: <042.7406bd491a8ebc93e9f9e327d9e092d9@localhost> Message-ID: <051.5a45f90d7590ca3606021495aa6bd499@localhost> #267: cabal upload has poor error messages (just an HTTP response code) ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by ross): The CGI script uses `outputError`, which returns a response with a status header ''400 Error in upload'', with the error message (in HTML) in the body. Cabal upload is presumably ignoring the message because it wants plain text, but the CGI library doesn't offer that. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Wed Apr 9 20:20:30 2008 From: trac at galois.com (Hackage) Date: Wed Apr 9 20:16:03 2008 Subject: [Hackage] #267: cabal upload has poor error messages (just an HTTP response code) In-Reply-To: <042.7406bd491a8ebc93e9f9e327d9e092d9@localhost> References: <042.7406bd491a8ebc93e9f9e327d9e092d9@localhost> Message-ID: <051.2cdc05bb74133f51646c6ec212219eaa@localhost> #267: cabal upload has poor error messages (just an HTTP response code) ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by ross): OK, I can bypass outputError and send the plain text on request. Then cabal upload can stop ignoring it. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Fri Apr 11 05:29:37 2008 From: trac at galois.com (Hackage) Date: Fri Apr 11 05:25:16 2008 Subject: [Hackage] #155: show . readPackageDescription /= id In-Reply-To: <062.7ab68407296e577f3ca8026fe40bb35d@localhost> References: <062.7ab68407296e577f3ca8026fe40bb35d@localhost> Message-ID: <071.a819bd46f228befdd0e7c0618345b68a@localhost> #155: show . readPackageDescription /= id ----------------------------------------+----------------------------------- Reporter: kolmodin@dtek.chalmers.se | Owner: nominolo Type: defect | Status: closed Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Resolution: wontfix Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux ----------------------------------------+----------------------------------- Changes (by nominolo): * status: assigned => closed * resolution: => wontfix Comment: This will never be possible in general. We can try {{{showPD . readPD . showPD . readPD == readPD}}}. Closing as wontfix. -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Fri Apr 11 06:32:57 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Apr 11 06:28:27 2008 Subject: patch applied (cabal): Fix spelling in error message Message-ID: <20080411103257.GA7492@haskell.galois.com> Tue Apr 8 06:46:10 PDT 2008 Duncan Coutts * Fix spelling in error message M ./Distribution/PackageDescription/Check.hs -2 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080408134610-adfee-bd57c57cb8945b65edb0cd7a91feaf39d93a0e33.gz From duncan.coutts at worc.ox.ac.uk Fri Apr 11 06:32:59 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Apr 11 06:28:28 2008 Subject: patch applied (cabal): Fix for detecting ~/.cabal/ dir as a .cabal file Message-ID: <20080411103259.GA7515@haskell.galois.com> Wed Apr 9 00:32:36 PDT 2008 Duncan Coutts * Fix for detecting ~/.cabal/ dir as a .cabal file Which happened if you use cabal configure in your home dir. Now produced the right error message, or if you actually put a cabal project in your home dir, it might actually work. Also, do the same fix for findHookedPackageDesc. M ./Distribution/Simple/Utils.hs -14 +24 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080409073236-adfee-6bf25fc9a6d3a684d6c073e1bcd370cedea93399.gz From duncan.coutts at worc.ox.ac.uk Fri Apr 11 06:33:00 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Apr 11 06:28:31 2008 Subject: patch applied (cabal): Remove unused import Message-ID: <20080411103300.GA7532@haskell.galois.com> Wed Apr 9 00:33:52 PDT 2008 Duncan Coutts * Remove unused import M ./Distribution/Simple/BuildPaths.hs -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080409073352-adfee-312cc1d29b9d790c81a977db0de40ec96555b562.gz From duncan.coutts at worc.ox.ac.uk Fri Apr 11 06:33:02 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Apr 11 06:28:31 2008 Subject: patch applied (cabal): Use relative file paths in .cabal parse error messages Message-ID: <20080411103302.GA7549@haskell.galois.com> Wed Apr 9 08:40:30 PDT 2008 Duncan Coutts * Use relative file paths in .cabal parse error messages Do this by normalising the file path in the error message and when looking for .cabal files, by looking in '.' rather than the absolute path of the current directory. M ./Distribution/Simple/Utils.hs -6 +8 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080409154030-adfee-98e35b39ee030d7e865e5e4283af8c27e85cf97e.gz From duncan.coutts at worc.ox.ac.uk Fri Apr 11 06:33:03 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Apr 11 06:28:32 2008 Subject: patch applied (cabal): Check for the required cabal version early in parsing Message-ID: <20080411103303.GA7566@haskell.galois.com> Wed Apr 9 08:46:55 PDT 2008 Duncan Coutts * Check for the required cabal version early in parsing Previously we only checked the "cabal-version" field after parsing and all other configure processing. If the package really needs a later Cabal version it is of course highly likely that parsing or configure are going to fail and the user is not going to get the helpful error message about the version of Cabal required. So now we do the check early during parsing. If a later version is required and parsing subsequently fails, we now report the version issue, not the subsequent parse error. If parsing succeeds we still issue a warning which should be a useful hint to the user if subsequent configure processing fails. M ./Distribution/PackageDescription/Parse.hs -15 +34 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080409154655-adfee-7618f75270d5c66cb34a9120eb775d57aaf0f799.gz From duncan.coutts at worc.ox.ac.uk Fri Apr 11 06:35:09 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Apr 11 06:30:37 2008 Subject: patch applied (cabal-branches/cabal-1.4): Fix spelling in error message Message-ID: <20080411103509.GA7655@haskell.galois.com> Tue Apr 8 06:46:10 PDT 2008 Duncan Coutts * Fix spelling in error message M ./Distribution/PackageDescription/Check.hs -2 +2 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080408134610-adfee-bd57c57cb8945b65edb0cd7a91feaf39d93a0e33.gz From duncan.coutts at worc.ox.ac.uk Fri Apr 11 06:35:10 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Apr 11 06:30:39 2008 Subject: patch applied (cabal-branches/cabal-1.4): Fix for detecting ~/.cabal/ dir as a .cabal file Message-ID: <20080411103510.GA7678@haskell.galois.com> Wed Apr 9 00:32:36 PDT 2008 Duncan Coutts * Fix for detecting ~/.cabal/ dir as a .cabal file Which happened if you use cabal configure in your home dir. Now produced the right error message, or if you actually put a cabal project in your home dir, it might actually work. Also, do the same fix for findHookedPackageDesc. M ./Distribution/Simple/Utils.hs -14 +24 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080409073236-adfee-6bf25fc9a6d3a684d6c073e1bcd370cedea93399.gz From duncan.coutts at worc.ox.ac.uk Fri Apr 11 06:35:12 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Apr 11 06:30:41 2008 Subject: patch applied (cabal-branches/cabal-1.4): Remove unused import Message-ID: <20080411103512.GA7695@haskell.galois.com> Wed Apr 9 00:33:52 PDT 2008 Duncan Coutts * Remove unused import M ./Distribution/Simple/BuildPaths.hs -1 +1 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080409073352-adfee-312cc1d29b9d790c81a977db0de40ec96555b562.gz From duncan.coutts at worc.ox.ac.uk Fri Apr 11 06:35:13 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Apr 11 06:30:43 2008 Subject: patch applied (cabal-branches/cabal-1.4): Use relative file paths in .cabal parse error messages Message-ID: <20080411103513.GA7712@haskell.galois.com> Wed Apr 9 08:40:30 PDT 2008 Duncan Coutts * Use relative file paths in .cabal parse error messages Do this by normalising the file path in the error message and when looking for .cabal files, by looking in '.' rather than the absolute path of the current directory. M ./Distribution/Simple/Utils.hs -6 +8 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080409154030-adfee-98e35b39ee030d7e865e5e4283af8c27e85cf97e.gz From duncan.coutts at worc.ox.ac.uk Fri Apr 11 06:35:15 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Apr 11 06:30:44 2008 Subject: patch applied (cabal-branches/cabal-1.4): Check for the required cabal version early in parsing Message-ID: <20080411103515.GA7729@haskell.galois.com> Wed Apr 9 08:46:55 PDT 2008 Duncan Coutts * Check for the required cabal version early in parsing Previously we only checked the "cabal-version" field after parsing and all other configure processing. If the package really needs a later Cabal version it is of course highly likely that parsing or configure are going to fail and the user is not going to get the helpful error message about the version of Cabal required. So now we do the check early during parsing. If a later version is required and parsing subsequently fails, we now report the version issue, not the subsequent parse error. If parsing succeeds we still issue a warning which should be a useful hint to the user if subsequent configure processing fails. M ./Distribution/PackageDescription/Parse.hs -15 +34 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080409154655-adfee-7618f75270d5c66cb34a9120eb775d57aaf0f799.gz From trac at galois.com Fri Apr 11 12:30:20 2008 From: trac at galois.com (Hackage) Date: Fri Apr 11 12:26:28 2008 Subject: [Hackage] #269: Not having an up-to-date package list causes indexing out of bounds error Message-ID: <042.a24e28a4d8cc4298e623440f9cae2936@localhost> #269: Not having an up-to-date package list causes indexing out of bounds error ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: low | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ Not having an up-to-date package list causes {{{ cabal: Data.ByteString.Lazy.index: index too large: 0 }}} (.. which is a bad error message.) -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Sat Apr 12 06:22:14 2008 From: trac at galois.com (Hackage) Date: Sat Apr 12 06:17:39 2008 Subject: [Hackage] #270: Build executables that can be run "in-place" Message-ID: <042.b3caaaa026be0c328c6690f00371f76b@localhost> #270: Build executables that can be run "in-place" ----------------------------+----------------------------------------------- Reporter: waern | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- It would be nice if Cabal could build executables that could be told where to get their data files (etc), instead of always hard-wiring them to the installation dirs. Perhaps an environmental variable could be used to specify where the data files are. This would enable us to run applications "in-place", i.e. from the source directory directly, which would be useful for test suites, for example. David -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Sat Apr 12 14:22:22 2008 From: trac at galois.com (Hackage) Date: Sat Apr 12 14:17:46 2008 Subject: [Hackage] #270: Build executables that can be run "in-place" In-Reply-To: <042.b3caaaa026be0c328c6690f00371f76b@localhost> References: <042.b3caaaa026be0c328c6690f00371f76b@localhost> Message-ID: <051.9e093c87d7b4a1783c8aa93f26921ff8@localhost> #270: Build executables that can be run "in-place" ----------------------------+----------------------------------------------- Reporter: waern | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * difficulty: normal => easy (<4 hours) Comment: Yes, we could have the generated `Paths_` module check an environment variable and if it exists, use that in preference to the normal value. Doesn't sound too hard. It might also be a good opportunity to clean up that code and move it into it's own module. -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Sat Apr 12 16:46:05 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Apr 12 16:41:29 2008 Subject: patch applied (cabal): fix for #187 -- directory of Paths_packagename is included when looking for source files Message-ID: <20080412204604.GA13160@haskell.galois.com> Sat Apr 12 13:49:04 PDT 2008 Andres Loeh * fix for #187 -- directory of Paths_packagename is included when looking for source files M ./Distribution/Simple/GHC.hs -1 +1 M ./Distribution/Simple/Haddock.hs -1 +1 M ./Distribution/Simple/JHC.hs -1 +1 M ./Distribution/Simple/PreProcess.hs -2 +3 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080412204904-90534-67d6c3ff38d4e153f52457658102aed9f6770747.gz From duncan.coutts at worc.ox.ac.uk Sat Apr 12 16:47:00 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Apr 12 16:42:22 2008 Subject: patch applied (cabal-branches/cabal-1.4): fix for #187 -- directory of Paths_packagename is included when looking for source files Message-ID: <20080412204700.GA13205@haskell.galois.com> Sat Apr 12 13:49:04 PDT 2008 Andres Loeh * fix for #187 -- directory of Paths_packagename is included when looking for source files M ./Distribution/Simple/GHC.hs -1 +1 M ./Distribution/Simple/Haddock.hs -1 +1 M ./Distribution/Simple/JHC.hs -1 +1 M ./Distribution/Simple/PreProcess.hs -2 +3 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080412204904-90534-67d6c3ff38d4e153f52457658102aed9f6770747.gz From trac at galois.com Sat Apr 12 16:47:25 2008 From: trac at galois.com (Hackage) Date: Sat Apr 12 16:42:49 2008 Subject: [Hackage] #184: cabal-install should report build results to hackage server In-Reply-To: <043.0e078e89d8e918f0ee0711d88c9a0264@localhost> References: <043.0e078e89d8e918f0ee0711d88c9a0264@localhost> Message-ID: <052.1d53b67031a428ee60cce2300becce6d@localhost> #184: cabal-install should report build results to hackage server ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: closed Priority: high | Milestone: Component: cabal-install tool | Version: 1.2.2.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: project(> week) Ghcversion: 6.4.2 | Platform: Linux ---------------------------------+------------------------------------------ Changes (by duncan): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Sat Apr 12 22:49:04 CEST 2008 Andres Loeh * fix for #187 -- directory of Paths_packagename is included when looking for source files }}} -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Sat Apr 12 16:53:14 2008 From: trac at galois.com (Hackage) Date: Sat Apr 12 16:48:38 2008 Subject: [Hackage] #184: cabal-install should report build results to hackage server In-Reply-To: <043.0e078e89d8e918f0ee0711d88c9a0264@localhost> References: <043.0e078e89d8e918f0ee0711d88c9a0264@localhost> Message-ID: <052.e4cd8671cbc1731958508c7ec262f9f2@localhost> #184: cabal-install should report build results to hackage server ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: reopened Priority: high | Milestone: Component: cabal-install tool | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: 6.4.2 | Platform: Linux ---------------------------------+------------------------------------------ Changes (by duncan): * status: closed => reopened * resolution: fixed => Comment: Oops, closed the wrong bug.... -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Sat Apr 12 16:53:56 2008 From: trac at galois.com (Hackage) Date: Sat Apr 12 16:49:19 2008 Subject: [Hackage] #187: Paths_pkgname module is hard to use in a library In-Reply-To: <043.6749848e9de650d2dc64e8b81a37543e@localhost> References: <043.6749848e9de650d2dc64e8b81a37543e@localhost> Message-ID: <052.854e6ae1e879fafca629da3084339946@localhost> #187: Paths_pkgname module is hard to use in a library ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: closed Priority: normal | Milestone: Cabal-1.4 Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.1 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed Comment: Close the right ticket this time... {{{ Sat Apr 12 22:49:04 CEST 2008 Andres Loeh * fix for #187 -- directory of Paths_packagename is included when looking for source files }}} -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Sat Apr 12 17:31:17 2008 From: trac at galois.com (Hackage) Date: Sat Apr 12 17:26:45 2008 Subject: [Hackage] #258: case confusion - cabal vs Cabal In-Reply-To: <042.762ca4d90e878449bc2d1c7c7098b022@localhost> References: <042.762ca4d90e878449bc2d1c7c7098b022@localhost> Message-ID: <051.39b5871272a5557a52ec56164d2a10dc@localhost> #258: case confusion - cabal vs Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: closed Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Resolution: wontfix Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by kolmodin): * status: new => closed * resolution: => wontfix Comment: The name of the package is indeed Cabal, with a capital C. Renaming either the name of the .cabal file or the repo dir is not trivial though. * Changing the name of the .cabal file would also require to rename the package, since hackage requires the file name to be consistent with the package name. This would effectively break all packages depending on Cabal, and of course make much hassle with forward and backwards compatibility. * Renaming the repo name would break the darcs installations of all our developers, something we are really not keen to do. We could set up a symlink to use the {{{Cabal}}} name, but I'd find that even more confusing than just having a single repository. http://www.orlyowl.com/upload/files/NOOOO!!!.JPG -- Ticket URL: Hackage Hackage: Cabal and related projects From nominolo at googlemail.com Sun Apr 13 09:33:58 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Sun Apr 13 09:29:21 2008 Subject: darcs patch: Change dependency resolution algorithm. (and 2 more) Message-ID: <48020bc6.0216300a.6291.ffffdf8f@mx.google.com> Sun Apr 13 15:18:07 CEST 2008 Thomas Schilling * Change dependency resolution algorithm. There were two reasons to do this. Firstly, this formulation makes it easier to add the --constraint command line flag that adds additional constraints on the packages that should be used. Secondly, with the orgininal algorithm it was possible to satisfy the constraint "foo < 1, foo > 2" if we had two versions of package "foo" which each satisfy one constraint. This patch fixes this by requiring the same package to satisfy both constraints (which of course is impossible in this case). Sun Apr 13 15:18:39 CEST 2008 Thomas Schilling * Fix/Add documentation. Sun Apr 13 15:20:02 CEST 2008 Thomas Schilling * Add simple test case for the dependency resolution case. This should go into the test suite one day. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 7245 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20080413/a48a93c7/attachment.bin From nominolo at googlemail.com Sun Apr 13 14:28:39 2008 From: nominolo at googlemail.com (Thomas Schilling) Date: Sun Apr 13 14:24:02 2008 Subject: darcs patch: Change dependency resolution algorithm. (and 4 more) Message-ID: <480250d7.0722300a.14fc.fffff483@mx.google.com> Sun Apr 13 15:18:07 CEST 2008 Thomas Schilling * Change dependency resolution algorithm. There were two reasons to do this. Firstly, this formulation makes it easier to add the --constraint command line flag that adds additional constraints on the packages that should be used. Secondly, with the orgininal algorithm it was possible to satisfy the constraint "foo < 1, foo > 2" if we had two versions of package "foo" which each satisfy one constraint. This patch fixes this by requiring the same package to satisfy both constraints (which of course is impossible in this case). Sun Apr 13 15:18:39 CEST 2008 Thomas Schilling * Fix/Add documentation. Sun Apr 13 15:20:02 CEST 2008 Thomas Schilling * Add simple test case for the dependency resolution case. This should go into the test suite one day. Sun Apr 13 20:20:42 CEST 2008 Thomas Schilling * Add 'readP_to_E' function that takes the longest parse. Sun Apr 13 20:26:59 CEST 2008 Thomas Schilling * Fix #224. We do not yet warn if the user specified a dependency that did not occur in the package (it is just silently ignored.) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 10918 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20080413/c6a7edfc/attachment-0001.bin From duncan.coutts at worc.ox.ac.uk Sun Apr 13 19:26:23 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Apr 14 04:12:26 2008 Subject: Cabal bugs/oddities In-Reply-To: <404396ef0804091455u309a336vf28bef195a7f18c@mail.gmail.com> References: <404396ef0804030604lce03b3uddd5bde4366624f1@mail.gmail.com> <1207776529.6082.40.camel@dell.linuxdev.us.dell.com> <404396ef0804091455u309a336vf28bef195a7f18c@mail.gmail.com> Message-ID: <1208129183.9923.111.camel@dell.linuxdev.us.dell.com> On Wed, 2008-04-09 at 22:55 +0100, Neil Mitchell wrote: > Hi > > > I presume this is on Windows. What version of Cabal were you using? > > HEAD whenever the original message was sent. Ok. > Windows is always a safe bet with me :-) Of course :-) > > > Bug 1: > > > cabal install worked the first time, running it a second time fails. > > > > Hmm. Nothing obvious from the log and it works for me on Linux. I'll > > have to try it on Windows. > > Its entirely possible its a bug in ghc-pkg rather than cabal. Perhaps > those pesky .manifest files are still floating around breaking > something. When I get back from the hackathon I'll give it a go. Could you report it anyway so we don't forget and in case any other windows users can add any details. > > Bug 2: > > Please file a ticket for this one. > > Done #266 Thanks. > > > Bug 3: > > > Cabal upload doesn't work: > > > > > > $ cabal upload > > > Username: ... > > > Password: .... > > > > You reported this one before and I fixed it: > > Yeah, but when I tried again it didn't work still. I wonder why - its > possible one of the versions isn't as up to date as I think. > Otherwise, it may still be an issue - did you push the patch? Definitely pushed. You're sure you rebuilt and installed cabal-install? $ cabal upload cabal: the 'upload' command expects one or more .tar.gz packages. $ cabal --version cabal-install version 0.4.6 using version 1.3.10 of the Cabal library > > > $ cabal upload dist > > > E:\Neil\homeomorphic>cabal upload dist\homeomorphic-0.1.tar.gz > > > Hackage username: NeilMitchell > > > Hackage password: yoda > > > Uploading dist\homeomorphic-0.1.tar.gz... > > > ERROR: dist\homeomorphic-0.1.tar.gz: 400 Error in upload > > > > > > 400 error in upload - not the worlds most helpful error message... > > > > Indeed. There is an error message available but I'm not sure how we get > > at it. Any ideas Ross? > > > > Another ticket for this one. > > #267 Thanks. Ross and Bj?rn have been looking into it which is great. > > > Cabal upload asks for your password in plain text. That one is > > > security related - you are asking for someones password, and giving > > > the appearance that you aren't overly fussed about keeping it secret. > > > > I'm happy to add that if anyone can figure out the code to do it. It's > > presumably different on ANSI terminals and the Windows command console. > > getChar in a loop? You can always do: > > c <- getChar > putChar '*' > > If you so feel like it. You can even use putStr "\b \b" to move back > one character, even on Windows. But not in emacs :-) > #268 Ta. Duncan From duncan.coutts at worc.ox.ac.uk Sun Apr 13 19:36:06 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Apr 14 04:12:30 2008 Subject: nice little Cabal gotcha In-Reply-To: <9E3ABFB0-09DC-4827-8810-346005E752E3@gmail.com> References: <1207774626.6082.23.camel@dell.linuxdev.us.dell.com> <9E3ABFB0-09DC-4827-8810-346005E752E3@gmail.com> Message-ID: <1208129766.9923.120.camel@dell.linuxdev.us.dell.com> On Thu, 2008-04-10 at 11:29 +0700, Peter Gammie wrote: > On 10/04/2008, at 3:57 AM, Duncan Coutts wrote: > > On Mon, 2008-04-07 at 18:37 +0700, Peter Gammie wrote: > >> Imagine this: you're hacking a library, and occasionally you put a "- > >> p" on your config line and sometimes you don't. > > > > Yep. And Cabal doesn't track if the profiling versions of dependencies > > are installed. > > > >> (My cycle is occasional-clean-setup then build, which I grant might > >> be > >> a bit paranoid. I get impatient and fiddle with the profiling and > >> optimisation options.) > >> > >> Now, if one compiles a library with "-p", then without it, the old > >> profiling library persists in the installed location, leading to some > >> head scratching when a later compilation with a "-p" config option > >> mysteriously fails. > > > > You mean because the old version of the profiling lib is installed but > > it does not match the newer non-profiling version? So building a > > dependent lib with -p fails with weird complication errors? > > Just to clarify slightly: "install" is just additive, so any old cruft > in the install directories persists if not overwritten. If the package > interface hasn't changed, the later "-p" compilation of something else > may succeed, but misbehave relative to expectations. Ah, so same interface but changed semantics. > My proposal is that if cabal is going to install something in, e.g.: > > ~/lib/package/ghc-6.6.1/ > > that it say: > > rm -rf ~/lib/package/ghc-6.6.1/* > > first. Surely it is reasonable to say Cabal "owns" that particular > directory? I don't think so, no. > I also feel the same way about documentation. > > Now tracking dependencies a partial solution to this: imagine I remove > a module from my .cabal file, then "clean" "build" "install". Will > Cabal delete the removed-module's .hi (etc.) file? No. > Can you expand on your squeamishness? We should not delete files we don't know that we own. We only know we own files we're installing. So we cannot delete anything. Only a package manager can do that because it knows what files belong to the package we're replacing. Of course cabal-install is a package manager of sorts so if it tracked what files belonged to packages it installed then it'd know what files to remove when it replaced packages. > I can feel a proposal for a "--force" relative coming on, something > like "--purge-old-crap". :-) The other problem is that we do not necessarily install all files into one directory. In fact it's not even the default on unix. The various different kinds of files go in different dirs and the user can change any of them. > I'll write up a ticket after your response. Perhaps I can convince you that the better solution is to get Cabal to provide a way track installed files and for cabal-install to actually do so. Duncan From duncan.coutts at worc.ox.ac.uk Sun Apr 13 19:38:36 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Apr 14 04:12:30 2008 Subject: [Fwd: darcs patch: Made it possible to run executeables with data files i...] Message-ID: <1208129916.9923.123.camel@dell.linuxdev.us.dell.com> Comments? Perhaps we want to generalise this for the other dirs too, prefix, libdir etc to provide a way to have relocatable packages on unix with a wrapper script. Also, comments on the name of the environment variables would be appreciated and indeed if people agree that using env vars is the right approach. Duncan -------------- next part -------------- An embedded message was scrubbed... From: Johan Tibell Subject: darcs patch: Made it possible to run executeables with data files i... Date: Sun, 13 Apr 2008 15:45:09 +0200 (CEST) Size: 6377 Url: http://www.haskell.org/pipermail/cabal-devel/attachments/20080414/9058e4f1/attachment.eml From ndmitchell at gmail.com Mon Apr 14 04:41:52 2008 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Apr 14 04:37:31 2008 Subject: Cabal bugs/oddities In-Reply-To: <1208129183.9923.111.camel@dell.linuxdev.us.dell.com> References: <404396ef0804030604lce03b3uddd5bde4366624f1@mail.gmail.com> <1207776529.6082.40.camel@dell.linuxdev.us.dell.com> <404396ef0804091455u309a336vf28bef195a7f18c@mail.gmail.com> <1208129183.9923.111.camel@dell.linuxdev.us.dell.com> Message-ID: <404396ef0804140141n1b10408ch4a19eb6e21eff639@mail.gmail.com> Hi > Definitely pushed. You're sure you rebuilt and installed cabal-install? I just tried upgrading my work machine, cabal goes fine, but cabal-install: [21 of 21] Compiling Main ( ./Main.hs, dist\build\cabal\cabal-tmp/Ma in.o ) ./Main.hs:221:24: Couldn't match expected type `Distribution.Verbosity.Verbosity' against inferred type `Verbosity' In the first argument of `check', namely `(fromFlag verbosityFlag)' In a 'do' expression: allOk <- check (fromFlag verbosityFlag) In the expression: do (unless (null extraArgs)) $ (do die $ ("'check' doesn't take any extra arguments: " ++ (unwords extraArgs))) allOk <- check (fromFlag verbosityFlag) unless allOk exitFailure cabal: Error: some packages failed to install: cabal-install-0.4.6 failed during the building phase. Thanks Neil From peteg42 at gmail.com Mon Apr 14 05:08:05 2008 From: peteg42 at gmail.com (Peter Gammie) Date: Mon Apr 14 05:03:51 2008 Subject: nice little Cabal gotcha In-Reply-To: <1208129766.9923.120.camel@dell.linuxdev.us.dell.com> References: <1207774626.6082.23.camel@dell.linuxdev.us.dell.com> <9E3ABFB0-09DC-4827-8810-346005E752E3@gmail.com> <1208129766.9923.120.camel@dell.linuxdev.us.dell.com> Message-ID: On 14/04/2008, at 6:36 AM, Duncan Coutts wrote: > On Thu, 2008-04-10 at 11:29 +0700, Peter Gammie wrote: >> On 10/04/2008, at 3:57 AM, Duncan Coutts wrote: >>> On Mon, 2008-04-07 at 18:37 +0700, Peter Gammie wrote: >>> >> Just to clarify slightly: "install" is just additive, so any old >> cruft >> in the install directories persists if not overwritten. If the >> package >> interface hasn't changed, the later "-p" compilation of something >> else >> may succeed, but misbehave relative to expectations. > > Ah, so same interface but changed semantics. Yes. >> My proposal is that if cabal is going to install something in, e.g.: >> >> ~/lib/package/ghc-6.6.1/ >> >> that it say: >> >> rm -rf ~/lib/package/ghc-6.6.1/* >> >> first. Surely it is reasonable to say Cabal "owns" that particular >> directory? > > I don't think so, no. > >> I also feel the same way about documentation. >> >> Now tracking dependencies a partial solution to this: imagine I >> remove >> a module from my .cabal file, then "clean" "build" "install". Will >> Cabal delete the removed-module's .hi (etc.) file? > > No. > >> Can you expand on your squeamishness? > > We should not delete files we don't know that we own. We only know we > own files we're installing. So we cannot delete anything. As I said before, I disagree. Directories like ~/lib/package/ghc-6.6.1 are clearly Cabal-directories. (Please insert some $'s to make that suitably relative). All sorts of gunk piles up in there while developing. When hacking libs, one really wants "install" to mirror what one has just built. Consider this sequence: Step 1: configure -p build install Step 2: clean configure build install Now the profiling libs are out of date, Cabal "owned" them before but not now... Also consider: configure build install and now we may have some .hi files orphaned by Cabal. Ditto for documentation. > Only a package manager can do that because it knows what files > belong to > the package we're replacing. Of course cabal-install is a package > manager of sorts so if it tracked what files belonged to packages it > installed then it'd know what files to remove when it replaced > packages. This is a non-solution: I've *changed* what is owned by the package. Is anyone really going to expect Cabal et al not to clobber the library install directory? What if I've already carefully installed a .a file of my own before "install"? I claim this is all so arbitrary that it is better for Cabal to simply throw everything out... the alternative is endless prompts: "do you really want me to clobber this file you don't care about?" or dodgy behaviour in corner cases. >> I can feel a proposal for a "--force" relative coming on, something >> like "--purge-old-crap". :-) > > The other problem is that we do not necessarily install all files into > one directory. In fact it's not even the default on unix. The various > different kinds of files go in different dirs and the user can change > any of them. Well, yes and no. I expect all "hi" files to end up in one place, and .a's and so forth. BTW can I really ask Cabal to install a lib into: ~/ and have all files end up there? (i.e. no ghc-6.6.1 etc. subdirs?) If not, we are arguing past each other. >> I'll write up a ticket after your response. > > Perhaps I can convince you that the better solution is to get Cabal to > provide a way track installed files and for cabal-install to > actually do > so. Would be nice. You need debian-style "remove using old .cabal" "install using new .cabal" persistence though, in case the .cabal has changed. cheers peter From trac at galois.com Mon Apr 14 16:40:06 2008 From: trac at galois.com (Hackage) Date: Mon Apr 14 16:35:26 2008 Subject: [Hackage] #187: Paths_pkgname module is hard to use in a library In-Reply-To: <043.6749848e9de650d2dc64e8b81a37543e@localhost> References: <043.6749848e9de650d2dc64e8b81a37543e@localhost> Message-ID: <052.694fb1655be73c62512b671a15d364f6@localhost> #187: Paths_pkgname module is hard to use in a library ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: closed Priority: normal | Milestone: Cabal-1.4 Component: Cabal library | Version: 1.2.2.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.1 | Platform: ----------------------------+----------------------------------------------- Comment (by guest): There's still a problem for sdist: sdist shouldn't care about Paths_pkgname because it's installation dependent, but if you have Paths_pkgname in Other-modules sdist tries to include that module in the tarball, and so fails to create the package because it can't find the file. two ways to solve this might be: (i) add Paths_pkgname automatically during build, install and haddock. (ii) filter Paths_pkgname out in sdist. but maybe the cleanest solution is to have a dedicated field in the package description? -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Fri Apr 18 06:59:30 2008 From: trac at galois.com (Hackage) Date: Fri Apr 18 06:54:35 2008 Subject: [Hackage] #268: cabal upload asks for a password in plain text In-Reply-To: <042.194090d9016445d7e9ae4a0e3ba60d0f@localhost> References: <042.194090d9016445d7e9ae4a0e3ba60d0f@localhost> Message-ID: <051.00e22532f087c036bed098d11e53e332@localhost> #268: cabal upload asks for a password in plain text ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: very easy (<1 hour) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * difficulty: normal => very easy (<1 hour) -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Fri Apr 18 07:02:12 2008 From: trac at galois.com (Hackage) Date: Fri Apr 18 06:57:16 2008 Subject: [Hackage] #264: unionBuildInfo should not always use nub In-Reply-To: <042.1b5c379209554d2eb3bda0e32cc13593@localhost> References: <042.1b5c379209554d2eb3bda0e32cc13593@localhost> Message-ID: <051.97b3e0b4963c7a7fd0b5ac2860d8e405@localhost> #264: unionBuildInfo should not always use nub ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.4 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * difficulty: normal => easy (<4 hours) * milestone: => Cabal-1.4 -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Fri Apr 18 07:05:03 2008 From: trac at galois.com (Hackage) Date: Fri Apr 18 07:00:08 2008 Subject: [Hackage] #253: Check for invalid operating system names In-Reply-To: <043.c36a01dabaf2115e0a55b8a705f59ed4@localhost> References: <043.c36a01dabaf2115e0a55b8a705f59ed4@localhost> Message-ID: <052.6631593af94c0d442c0ad919b24c83e4@localhost> #253: Check for invalid operating system names ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.4 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * difficulty: very easy (<1 hour) => easy (<4 hours) * milestone: => Cabal-1.4 Comment: Requires an API change in Distribution.PackageDescription.Check to take the `GenericPackageDescription`. Because it's a (minor) api change we should get it into Cabal-1.4. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Fri Apr 18 07:06:38 2008 From: trac at galois.com (Hackage) Date: Fri Apr 18 07:01:43 2008 Subject: [Hackage] #171: Add command to automagically create an initial cabal package In-Reply-To: <042.6b76770d9ed8d626a3821473c28643d4@localhost> References: <042.6b76770d9ed8d626a3821473c28643d4@localhost> Message-ID: <051.0757ad3bb89fe900e2ca8dd7c5e66849@localhost> #171: Add command to automagically create an initial cabal package ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-2.0 Component: cabal-install tool | Version: 1.2.2.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux ---------------------------------+------------------------------------------ Changes (by duncan): * milestone: => Cabal-2.0 -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Fri Apr 18 07:08:48 2008 From: trac at galois.com (Hackage) Date: Fri Apr 18 07:03:54 2008 Subject: [Hackage] #265: Cabal field stability not useful In-Reply-To: <042.a3d936740f7b920fec16947f94343a86@localhost> References: <042.a3d936740f7b920fec16947f94343a86@localhost> Message-ID: <051.1befb3a9010744bc809caeeb5c3de505@localhost> #265: Cabal field stability not useful ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): Perhaps we should just deprecate it and add a field for the api versioning scheme, like the package versioning policy. -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Fri Apr 18 13:41:25 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Apr 18 13:36:38 2008 Subject: [Haskell-cafe] announcing franchise 0.0 In-Reply-To: <20080418153703.GN8763@darcs.net> Message-ID: <20080418174125.F3562E4001@webmail219.herald.ox.ac.uk> In message <20080418153703.GN8763@darcs.net> haskell-cafe@haskell.org, darcs-devel@darcs.net writes: > One goal of franchise is to not require developers to provide redundant > information. For instance, you've already listed all the modules you use, > and ghc already knows which modules are present in which packages, so > there's in general no need for you to list the packages that you require, > much less their versions. Yeah, this is an important point. Part of the original idea of Cabal was to help distribution by properly tracking dependencies. It's not too bad for that use case but it's really a pain in comparison to ghc --make or hmake which just do the right thing given the environment. Part of our plan for Cabal 2.x is to do proper module dependency chasing so that it will work without a .cabal file in simple cases and be usable for the ghc --make or hmake use cases (but with support for preprocessors and parallel build). It should be possible to just start hacking and derive a skeleton .cabal file afterwards if you decide you want to distribute a package. Duncan From duncan.coutts at worc.ox.ac.uk Sun Apr 20 10:50:26 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 10:45:25 2008 Subject: nice little Cabal gotcha In-Reply-To: References: <1207774626.6082.23.camel@dell.linuxdev.us.dell.com> <9E3ABFB0-09DC-4827-8810-346005E752E3@gmail.com> <1208129766.9923.120.camel@dell.linuxdev.us.dell.com> Message-ID: <1208703026.5960.54.camel@dell.linuxdev.us.dell.com> On Mon, 2008-04-14 at 16:08 +0700, Peter Gammie wrote: > >> Can you expand on your squeamishness? > > > > We should not delete files we don't know that we own. We only know we > > own files we're installing. So we cannot delete anything. > > As I said before, I disagree. Directories like ~/lib/package/ghc-6.6.1 > are clearly Cabal-directories. (Please insert some $'s to make that > suitably relative). All sorts of gunk piles up in there while > developing. When hacking libs, one really wants "install" to mirror > what one has just built. It may look that way but what if someone configures to use ~/lib directly? The directory structure we use is just a default, it's all completely configurable. We cannot rely on 'owning' anything. > Consider this sequence: > > Step 1: > > configure -p > build > install > > Step 2: > > > clean > configure > build > install > > Now the profiling libs are out of date, Cabal "owned" them before but > not now... Sure I see the problem. > Also consider: > > > > configure > build > install > > and now we may have some .hi files orphaned by Cabal. > > Ditto for documentation. Yep. > > Only a package manager can do that because it knows what files > > belong to > > the package we're replacing. Of course cabal-install is a package > > manager of sorts so if it tracked what files belonged to packages it > > installed then it'd know what files to remove when it replaced > > packages. > > This is a non-solution: I've *changed* what is owned by the package. Exactly! That's just why we need a package manager. It remembers what files belonged to the Foo package before and now that we're installing Foo again it knows that we're *replacing* Foo, so it's safe to delete all the old files that belonged to the Foo package and install all the new Foo files (and remember them for later). > I claim this is all so arbitrary that it is better for Cabal to simply > throw everything out... the alternative is endless prompts: "do you > really want me to clobber this file you don't care about?" or dodgy > behaviour in corner cases. This behaviour is completely consistent with all other build systems I know of. We really need package managers to solve the problem. > BTW can I really ask Cabal to install a lib into: > > ~/ > > and have all files end up there? (i.e. no ghc-6.6.1 etc. subdirs?) Yes you can do that. > If not, we are arguing past each other. > Would be nice. You need debian-style "remove using old .cabal" > "install using new .cabal" persistence though, in case the .cabal has > changed. Well, as I said, the package manager just needs to remember the set of files that belong to each installed package. A related problem is that we need to solve this problem at least within the ./dist/ directory. One of your examples was changing a .cabal file to add/remove a module. Currently we would not delete any existing .hi or .o files within ./dist/. As it happens for .o and .hi we copy out exactly the ones we need, but that's not the case for the documentation for example so we might end up copying stale .html files. To do that properly we'd need to track generated files much more closely. Duncan From duncan.coutts at worc.ox.ac.uk Sun Apr 20 15:25:24 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 15:20:23 2008 Subject: patch applied (cabal): Change dependency resolution algorithm. Message-ID: <20080420192524.GA28772@haskell.galois.com> Sun Apr 13 06:18:07 PDT 2008 Thomas Schilling * Change dependency resolution algorithm. There were two reasons to do this. Firstly, this formulation makes it easier to add the --constraint command line flag that adds additional constraints on the packages that should be used. Secondly, with the orgininal algorithm it was possible to satisfy the constraint "foo < 1, foo > 2" if we had two versions of package "foo" which each satisfy one constraint. This patch fixes this by requiring the same package to satisfy both constraints (which of course is impossible in this case). M ./Distribution/PackageDescription/Configuration.hs -10 +17 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080413131807-75a80-cc4c1b141f6726caefd27689d4fef4de3fb86f2c.gz From duncan.coutts at worc.ox.ac.uk Sun Apr 20 15:25:26 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 15:20:24 2008 Subject: patch applied (cabal): Fix/Add documentation. Message-ID: <20080420192526.GA28795@haskell.galois.com> Sun Apr 13 06:18:39 PDT 2008 Thomas Schilling * Fix/Add documentation. M ./Distribution/PackageDescription/Configuration.hs -3 +24 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080413131839-75a80-943489c44e35e45125797c38f7f749f2980187ac.gz From duncan.coutts at worc.ox.ac.uk Sun Apr 20 15:25:27 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 15:20:28 2008 Subject: patch applied (cabal): Add simple test case for the dependency resolution case. This should Message-ID: <20080420192527.GA28812@haskell.galois.com> Sun Apr 13 06:20:02 PDT 2008 Thomas Schilling * Add simple test case for the dependency resolution case. This should go into the test suite one day. M ./Distribution/PackageDescription/Configuration.hs +10 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080413132002-75a80-38b154dae31897ec806784c8f8a7ebde0f112340.gz From duncan.coutts at worc.ox.ac.uk Sun Apr 20 15:25:29 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 15:20:29 2008 Subject: patch applied (cabal): Add 'readP_to_E' function that takes the longest parse. Message-ID: <20080420192529.GA28829@haskell.galois.com> Sun Apr 13 11:20:42 PDT 2008 Thomas Schilling * Add 'readP_to_E' function that takes the longest parse. M ./Distribution/ReadE.hs -1 +9 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080413182042-75a80-104af7044cb9af3b19c91c15a49b86ca105a52b4.gz From duncan.coutts at worc.ox.ac.uk Sun Apr 20 15:25:30 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 15:20:29 2008 Subject: patch applied (cabal): Fix #224. We do not yet warn if the user specified a dependency that Message-ID: <20080420192530.GA28846@haskell.galois.com> Sun Apr 13 11:26:59 PDT 2008 Thomas Schilling * Fix #224. We do not yet warn if the user specified a dependency that did not occur in the package (it is just silently ignored.) M ./Distribution/PackageDescription/Configuration.hs -4 +23 M ./Distribution/Simple/Configure.hs +1 M ./Distribution/Simple/Setup.hs -1 +12 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080413182659-75a80-db7f5ff7b7aa3ad0e29f7bf42266371c2c6d9015.gz From duncan.coutts at worc.ox.ac.uk Sun Apr 20 15:25:32 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 15:20:32 2008 Subject: patch applied (cabal): Make finalizePackageDescription use CompilerId type Message-ID: <20080420192532.GA28863@haskell.galois.com> Sun Apr 13 15:41:11 PDT 2008 Duncan Coutts * Make finalizePackageDescription use CompilerId type Use the proper data type rather than a tuple (CompilerFlavor, Version) M ./Distribution/PackageDescription/Configuration.hs -6 +7 M ./Distribution/ReadE.hs -1 +1 M ./Distribution/Simple/Configure.hs -9 +9 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080413224111-adfee-aa61f26a50110ecef41fe0192c19ea4028c5a553.gz From duncan.coutts at worc.ox.ac.uk Sun Apr 20 15:25:33 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 15:20:32 2008 Subject: patch applied (cabal): Add PackageIndex.insert and reverse merge/mappend Message-ID: <20080420192533.GA28880@haskell.galois.com> Tue Apr 15 13:36:37 PDT 2008 Duncan Coutts * Add PackageIndex.insert and reverse merge/mappend Packages in the second argument to merge now mask those in the first. M ./Distribution/Simple/PackageIndex.hs -9 +22 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080415203637-adfee-1ad59c6ebc462a24d691a75bac2533dd2a50d248.gz From duncan.coutts at worc.ox.ac.uk Sun Apr 20 15:25:35 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 15:20:34 2008 Subject: patch applied (cabal): Add newtype FlagName and FlagAssignment type alias Message-ID: <20080420192535.GA28897@haskell.galois.com> Tue Apr 15 13:48:54 PDT 2008 Duncan Coutts * Add newtype FlagName and FlagAssignment type alias and use them in the appropriate places. M ./Distribution/PackageDescription.hs -6 +14 M ./Distribution/PackageDescription/Configuration.hs -13 +13 M ./Distribution/PackageDescription/Parse.hs -8 +8 M ./Distribution/Simple/Configure.hs -3 +5 M ./Distribution/Simple/Setup.hs -8 +12 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080415204854-adfee-87f16abe58f178a53f402a9f20c6ae06ce898f2e.gz From duncan.coutts at worc.ox.ac.uk Sun Apr 20 15:25:36 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 15:20:34 2008 Subject: patch applied (cabal): Fix unionBuildInfo Message-ID: <20080420192536.GA28915@haskell.galois.com> Sun Apr 20 11:05:20 PDT 2008 Duncan Coutts * Fix unionBuildInfo Fix ticket #264 to use nub only on the fields which are treated as sets. Probably we should be using the right types and mappend for each field. Change to construct a new value from scratch rather than overriding one of the two args. This helps to make sure we're updating all the field as we get a warning if we miss any. Turns out we were missing the ghc profiling and shared libs options which meant they were getting dropped. That had the effect of ghc-prof-options: in .cabal files being ignored. Thanks to 'midfield' from #haskell for spotting this. M ./Distribution/PackageDescription.hs -21 +24 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080420180520-adfee-bd40fd1bbf411a5322fdb6f572311f9f751bb511.gz From duncan.coutts at worc.ox.ac.uk Sun Apr 20 15:25:38 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 15:20:36 2008 Subject: patch applied (cabal): Don't nub extra-libs in unionBuildInfo Message-ID: <20080420192538.GA28932@haskell.galois.com> Sun Apr 20 12:23:12 PDT 2008 Duncan Coutts * Don't nub extra-libs in unionBuildInfo It's possible that we sometimes need to list the same library more than once if there are circular symbol references. M ./Distribution/PackageDescription.hs -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080420192312-adfee-077ab5a13c7d248c480ce1d7f63523fdc506e407.gz From duncan.coutts at worc.ox.ac.uk Sun Apr 20 15:26:31 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 15:21:28 2008 Subject: patch applied (cabal-install): Half-done build reporting stuff Message-ID: <20080420192631.GA28970@haskell.galois.com> Sat Apr 12 16:40:57 PDT 2008 * Half-done build reporting stuff A ./Hackage/Reporting.hs View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080412234057-da39a-5eb4cbdfcf728831fa0cf7c8f04236ef9e33a484.gz From duncan.coutts at worc.ox.ac.uk Sun Apr 20 15:26:33 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 15:21:31 2008 Subject: patch applied (cabal-install): Update for change to finalizePackageDescription Message-ID: <20080420192633.GA28987@haskell.galois.com> Sun Apr 13 15:39:10 PDT 2008 Duncan Coutts * Update for change to finalizePackageDescription M ./Hackage/Dependency.hs -3 +2 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080413223910-adfee-81a993836acf1e9dd81eb34ab2ebb5c7332df662.gz From duncan.coutts at worc.ox.ac.uk Sun Apr 20 15:26:34 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 15:21:32 2008 Subject: patch applied (cabal-install): Relax version constraint on HTTP, seems to work with 3001.1 Message-ID: <20080420192634.GA29004@haskell.galois.com> Sun Apr 13 15:39:40 PDT 2008 Duncan Coutts * Relax version constraint on HTTP, seems to work with 3001.1 M ./cabal-install.cabal -1 +1 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080413223940-adfee-6c51904e1b557bfe77e2ecb59b38031fb81371eb.gz From duncan.coutts at worc.ox.ac.uk Sun Apr 20 15:26:36 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 15:21:33 2008 Subject: patch applied (cabal-install): Make ResolvedDependency an internal detail of dependency calculation Message-ID: <20080420192636.GA29021@haskell.galois.com> Sun Apr 13 16:41:19 PDT 2008 Duncan Coutts * Make ResolvedDependency an internal detail of dependency calculation Externally we currently use a DepGraph, though we'll move to a InstallPlan. This is a step towards making it easier to swap in different package dependency resolution algorithms. Because we're hiding ResolvedDependency we have to disable the extended Hackage.Info stuff for the moment. M ./Hackage/Dependency.hs -12 +18 M ./Hackage/Fetch.hs -3 +2 M ./Hackage/Install.hs -11 +10 M ./Hackage/Types.hs -11 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080413234119-adfee-81895c76ea527e03c894230e6fb03999c27ee541.gz From duncan.coutts at worc.ox.ac.uk Sun Apr 20 15:26:37 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 15:21:34 2008 Subject: patch applied (cabal-install): Change resolveDependencies to take OS and Arch as parameters Message-ID: <20080420192637.GA29038@haskell.galois.com> Sun Apr 13 17:04:19 PDT 2008 Duncan Coutts * Change resolveDependencies to take OS and Arch as parameters Rather than using global 'constants' for the current os and arch. M ./Hackage/Dependency.hs -21 +28 M ./Hackage/Fetch.hs -2 +6 M ./Hackage/Install.hs -3 +8 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080414000419-adfee-efc2cf79eb5b6ada5275fc6524731ef3cc6113dc.gz From duncan.coutts at worc.ox.ac.uk Sun Apr 20 15:26:39 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 15:21:36 2008 Subject: patch applied (cabal-install): Simplify install --only implementation Message-ID: <20080420192639.GA29055@haskell.galois.com> Mon Apr 14 07:34:57 PDT 2008 Duncan Coutts * Simplify install --only implementation The install --only doesn't do any planning or build reporting so make it completely separate so we do not have to make up fake build plans or results. M ./Hackage/Install.hs -17 +6 M ./Main.hs +3 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080414143457-adfee-fd3c1e0d2233ce13e96d2da21ddb8f0a996ede7f.gz From duncan.coutts at worc.ox.ac.uk Sun Apr 20 15:26:40 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 15:21:38 2008 Subject: patch applied (cabal-install): Add new InstallPlan type Message-ID: <20080420192640.GA29072@haskell.galois.com> Mon Apr 14 10:19:14 PDT 2008 Duncan Coutts * Add new InstallPlan type This is joint work with Kolmodin. An InstallPlan records what we want to install and records the outcome of installing packages. It has a fairly strict internal invariant which should guarantee that each package can be configured sucessfully. A ./Hackage/InstallPlan.hs View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080414171914-adfee-aaa7e78f45182814c57eba21863cb1505579767a.gz From duncan.coutts at worc.ox.ac.uk Sun Apr 20 15:26:42 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 15:21:40 2008 Subject: patch applied (cabal-install): Update for FlagAssignment changes Message-ID: <20080420192642.GA29089@haskell.galois.com> Sun Apr 20 12:15:43 PDT 2008 Duncan Coutts * Update for FlagAssignment changes M ./Hackage/DepGraph.hs +2 M ./Hackage/Dependency.hs -4 +4 M ./Hackage/Install.hs -3 +4 M ./Hackage/InstallPlan.hs -3 +3 M ./Hackage/Types.hs -6 +2 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080420191543-adfee-e84d33a2c0764ea70cd71e3c3d688c8ab691902c.gz From trac at galois.com Sun Apr 20 15:26:45 2008 From: trac at galois.com (Hackage) Date: Sun Apr 20 15:21:43 2008 Subject: [Hackage] #264: unionBuildInfo should not always use nub In-Reply-To: <042.1b5c379209554d2eb3bda0e32cc13593@localhost> References: <042.1b5c379209554d2eb3bda0e32cc13593@localhost> Message-ID: <051.1855d6c618070cd8e264a7170c0372db@localhost> #264: unionBuildInfo should not always use nub ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: closed Priority: normal | Milestone: Cabal-1.4 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed Comment: So we now do not use nub on all the options fields, and the `x-*` extension fields. -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Sun Apr 20 15:28:27 2008 From: trac at galois.com (Hackage) Date: Sun Apr 20 15:23:24 2008 Subject: [Hackage] #224: allow specifying package version constraints to configure In-Reply-To: <043.b48e227e62cf2b070d3f7d3c44138f4a@localhost> References: <043.b48e227e62cf2b070d3f7d3c44138f4a@localhost> Message-ID: <052.8772d6c8b758b7fa9eddbe12d4ccea11@localhost> #224: allow specifying package version constraints to configure ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Cabal-1.4 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Sun Apr 13 14:18:07 BST 2008 Thomas Schilling * Change dependency resolution algorithm. There were two reasons to do this. Firstly, this formulation makes it easier to add the --constraint command line flag that adds additional constraints on the packages that should be used. Secondly, with the orgininal algorithm it was possible to satisfy the constraint "foo < 1, foo > 2" if we had two versions of package "foo" which each satisfy one constraint. This patch fixes this by requiring the same package to satisfy both constraints (which of course is impossible in this case). Sun Apr 13 19:26:59 BST 2008 Thomas Schilling * Fix #224. We do not yet warn if the user specified a dependency that did not occur in the package (it is just silently ignored.) }}} -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Sun Apr 20 16:22:56 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 16:17:54 2008 Subject: Specifying dependencies on Haskell code Message-ID: <1208722976.5960.101.camel@dell.linuxdev.us.dell.com> All, In the initial discussions on a common architecture for building applications and libraries one of the goals was to reduce or eliminate untracked dependencies. The aim being that you could reliably deploy a package from one machine to another. We settled on a fairly traditional model, where one specifies the names and versions of packages of Haskell code. An obvious alternative model is embodied in ghc --make and in autoconf style systems where you look in the environment not for packages but rather for specific modules or functions. Both models have passionate advocates. There are of course advantages and disadvantages to each. Both models seem to get implemented as reactions having the other model inflicted on the author. For example the current Cabal model of package names and versions was a reaction to the perceived problem of untracked dependencies with the ghc --make system. One could see implementations such as searchpath and franchise as reactions in the opposite direction. The advantages and disadvantages of specifying dependencies on module names vs package names and versions are mostly inverses. Module name clashes between packages are problematic with one system and not a problem with the other. Moving modules between packages is not a problem for one system and a massive pain for the other. The fact is that both module name and package name + version are being used as proxies to represent some vague combination of required Haskell interface and implementation thereof. Sometimes people intend only to specify an interface and sometimes people really want to specify (partial) semantics (eg to require a version of something including some bug fix / semantic change). In this situation the package version is being used to specify an implementation as a proxy for semantics. Neither are very good ways of identifying an interface or implementation/semantics. Modules do move from one package to another without fundamentally changing. Modules do change interface and semantics without changing name. There is no guarantee about the relationship between a package's version and its interface or semantics though there are some conventions. Another view would be to try and identify the requirements about dependent code more accurately. For example to view modules as functors and look at what interface they require of the modules they import. Then we can say that they depend on any module that provides a superset of that interface. It doesn't help with semantics of course. Dependencies like these are not so compact and easy to write down. I don't have any point here exactly, except that there is no obvious solution. I guess I'd like to provoke a bit of a discussion on this, though hopefully not just rehashing known issues. In particular if people have any ideas about how we could improve either model to address their weak points then that'd be well worth discussing. For example the package versioning policy attempts to tighten the relationship between a package version and changes in its interface and semantics. It still does not help at all with modules moving between packages. Duncan From bos at serpentine.com Sun Apr 20 16:59:27 2008 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sun Apr 20 16:54:29 2008 Subject: Cabal spelunking considered tricky Message-ID: <480BAEAF.4090105@serpentine.com> As I've been maintaining cabal-rpm to try to keep up with developments in Cabal, I've found myself wondering why it's not using many of the usual tricks to hide the plumbing, such as a custom monad transformer stack. Some parameters, such as flags, compiler info, and package descriptions, pop up simply all over the place, and they're passed around explicitly. This seems a smidge peculiar. A couple of days with a crowbar and ReaderT StateT IO would do wonders for readability, if anyone feels so inclined :-) References: <480BAEAF.4090105@serpentine.com> Message-ID: <1208727660.5960.131.camel@dell.linuxdev.us.dell.com> On Sun, 2008-04-20 at 13:59 -0700, Bryan O'Sullivan wrote: > As I've been maintaining cabal-rpm to try to keep up with developments > in Cabal, I've found myself wondering why it's not using many of the > usual tricks to hide the plumbing, such as a custom monad transformer stack. > Some parameters, such as flags, compiler info, and package descriptions, > pop up simply all over the place, and they're passed around explicitly. > This seems a smidge peculiar. A couple of days with a crowbar and > ReaderT StateT IO would do wonders for readability, if anyone feels so > inclined :-) Yeah, it's part of the plan for the new development series. The reason we could not do it in the last is api compatibility with existing Setup.hs scripts. The UserHooks types severely restrict that kind of refactoring but I hope we can redesign UserHooks this dev series. It'll break all custom Setup.hs scripts again though. Duncan From duncan.coutts at worc.ox.ac.uk Sun Apr 20 17:48:14 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Apr 20 17:43:10 2008 Subject: Cabal spelunking considered tricky In-Reply-To: <480BAEAF.4090105@serpentine.com> References: <480BAEAF.4090105@serpentine.com> Message-ID: <1208728094.5960.139.camel@dell.linuxdev.us.dell.com> On Sun, 2008-04-20 at 13:59 -0700, Bryan O'Sullivan wrote: > As I've been maintaining cabal-rpm to try to keep up with developments > in Cabal, I've found myself wondering why it's not using many of the > usual tricks to hide the plumbing, such as a custom monad transformer stack. One such change I'd like to make is to lift Cabal off the IO monad. There will always have to be IO somewhere down at the bottom but it'll help lots of things to have a layer in between. In particular it'll help us to regularise quite a lot of code. If you're in IO you can do anything and so we often do. A more restricted action monad would help us to better separate deciding what to do from actually doing it. It'd also reduce the number of ways of doing the same thing. I'd also like to separate IO actions that have mutative side effects from IO actions that merely query the system environment. Another useful thing would be to introspect IO actions to dynamically enforce policies, like never writing files outside of ./dist/. Such policies don't have to be global: actionWatcher checkFileWrites $ do ... Another candidate to monadify is logging. At the moment we have to remember to do logging consistently and we do it immediately to stderr. Callers like IDEs would like to get logging output in a more convenient format. Duncan From Malcolm.Wallace at cs.york.ac.uk Tue Apr 22 09:31:00 2008 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Apr 22 09:25:54 2008 Subject: patch applied (cabal): fix import for nhc98 Message-ID: <20080422133059.GA13416@haskell.galois.com> Tue Apr 22 06:30:09 PDT 2008 Malcolm.Wallace@cs.york.ac.uk * fix import for nhc98 M ./Distribution/Simple/Setup.hs -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080422133009-6871e-4110c628275f78ac0b278d51ae490d920e76406c.gz From duncan.coutts at worc.ox.ac.uk Tue Apr 22 11:07:31 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Apr 22 11:02:23 2008 Subject: patch applied (cabal): Update UTF8 code Message-ID: <20080422150731.GA18364@haskell.galois.com> Tue Apr 22 07:15:39 PDT 2008 Duncan Coutts * Update UTF8 code Some code and test cases taken from the utf8-string package. Updated copyright notice appropriately (I think). M ./Distribution/Simple/Utils.hs -11 +39 A ./tests/UnitTest/UTF8 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080422141539-adfee-fe5c62db069f4b325539ba5fbd60e10092b58243.gz From duncan.coutts at worc.ox.ac.uk Tue Apr 22 11:07:34 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Apr 22 11:02:26 2008 Subject: patch applied (cabal): Make warning messages show the file name Message-ID: <20080422150732.GA18387@haskell.galois.com> Tue Apr 22 07:19:09 PDT 2008 Duncan Coutts * Make warning messages show the file name M ./Distribution/ParseUtils.hs -2 +4 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080422141909-adfee-c4332c37ff0b9a27814fd2073d50dec04f771298.gz From ross at soi.city.ac.uk Tue Apr 22 11:46:21 2008 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Apr 22 11:41:29 2008 Subject: patch applied (cabal): Update UTF8 code In-Reply-To: <20080422150731.GA18364@haskell.galois.com> References: <20080422150731.GA18364@haskell.galois.com> Message-ID: <20080422153155.GA19708@soi.city.ac.uk> On Tue, Apr 22, 2008 at 08:07:31AM -0700, Duncan Coutts wrote: > Tue Apr 22 07:15:39 PDT 2008 Duncan Coutts > * Update UTF8 code > Some code and test cases taken from the utf8-string package. Can you push this to 1.4? I've been using a custom hacked version for hackageDB to make it reject isolated high bytes. It would be great if the released Cabal rejected them too. From duncan.coutts at worc.ox.ac.uk Tue Apr 22 18:44:49 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Apr 22 18:39:44 2008 Subject: patch applied (cabal): Update UTF8 code In-Reply-To: <20080422153155.GA19708@soi.city.ac.uk> References: <20080422150731.GA18364@haskell.galois.com> <20080422153155.GA19708@soi.city.ac.uk> Message-ID: <1208904289.27748.115.camel@localhost> On Tue, 2008-04-22 at 16:46 +0100, Ross Paterson wrote: > On Tue, Apr 22, 2008 at 08:07:31AM -0700, Duncan Coutts wrote: > > Tue Apr 22 07:15:39 PDT 2008 Duncan Coutts > > * Update UTF8 code > > Some code and test cases taken from the utf8-string package. > > Can you push this to 1.4? I've been using a custom hacked version > for hackageDB to make it reject isolated high bytes. It would be > great if the released Cabal rejected them too. Yes will do. There are a bunch of recent changes that should go to the 1.4 branch. Duncan From trac at galois.com Wed Apr 23 11:35:18 2008 From: trac at galois.com (Hackage) Date: Wed Apr 23 11:30:07 2008 Subject: [Hackage] #253: Check for invalid operating system names In-Reply-To: <043.c36a01dabaf2115e0a55b8a705f59ed4@localhost> References: <043.c36a01dabaf2115e0a55b8a705f59ed4@localhost> Message-ID: <052.26dee3b720d12730f66c1c80dbe4ee0d@localhost> #253: Check for invalid operating system names ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.4 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): Fixed {{{ Wed Apr 23 16:14:10 BST 2008 Duncan Coutts * Add checks for unknown OS Arch and Compiler names They're ok locally but for distribution they need to be known. }}} -- Ticket URL: Hackage Hackage: Cabal and related projects From trac at galois.com Wed Apr 23 11:35:53 2008 From: trac at galois.com (Hackage) Date: Wed Apr 23 11:30:42 2008 Subject: [Hackage] #253: Check for invalid operating system names In-Reply-To: <043.c36a01dabaf2115e0a55b8a705f59ed4@localhost> References: <043.c36a01dabaf2115e0a55b8a705f59ed4@localhost> Message-ID: <052.6af80b9a4f8d679d2ea00661cc1a85ad@localhost> #253: Check for invalid operating system names ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: Cabal-1.4 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.8.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed -- Ticket URL: Hackage Hackage: Cabal and related projects From duncan.coutts at worc.ox.ac.uk Wed Apr 23 11:38:13 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Apr 23 11:33:02 2008 Subject: patch applied (cabal): Package check now take a GenericPackageDescription Message-ID: <20080423153813.GA16228@haskell.galois.com> Wed Apr 23 08:03:54 PDT 2008 Duncan Coutts * Package check now take a GenericPackageDescription Unfortunately in some cases we only have a already-configured PackageDescription to we have to expose a checkConfiguredPackage. We should refactor things so that we keep all the information even in a configured PackageDescription. M ./Distribution/PackageDescription/Check.hs -3 +21 M ./Distribution/Simple/Configure.hs -6 +14 M ./Distribution/Simple/SrcDist.hs -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080423150354-adfee-27a582e3874da47e35846194b0015ab43c358330.gz From duncan.coutts at worc.ox.ac.uk Wed Apr 23 11:38:14 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Apr 23 11:33:05 2008 Subject: patch applied (cabal): Add checks for unknown OS Arch and Compiler names Message-ID: <20080423153814.GA16251@haskell.galois.com> Wed Apr 23 08:14:10 PDT 2008 Duncan Coutts * Add checks for unknown OS Arch and Compiler names They're ok locally but for distribution they need to be known. M ./Distribution/PackageDescription/Check.hs -4 +47 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080423151410-adfee-d013d0384679463f7e28471cc18ee6b40f6dc6d9.gz From duncan.coutts at worc.ox.ac.uk Wed Apr 23 11:40:27 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Apr 23 11:35:16 2008 Subject: patch applied (cabal-install): Update for checkPackage change Message-ID: <20080423154027.GA16386@haskell.galois.com> Wed Apr 23 08:38:17 PDT 2008 Duncan Coutts * Update for checkPackage change M ./Hackage/Check.hs -1 +1 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080423153817-adfee-428b6637ced2031d95f43b1ac20766e88c0a7c6e.gz From duncan.coutts at worc.ox.ac.uk Wed Apr 23 11:46:28 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Apr 23 11:41:16 2008 Subject: patch applied (cabal-branches/cabal-1.4): expose tryGetConfigStateFile Message-ID: <20080423154627.GA16508@haskell.galois.com> Thu Apr 17 11:02:48 PDT 2008 jeanphilippe.bernardy@gmail.com * expose tryGetConfigStateFile This is needed by Yi to (try to) load an arbitrary project. M ./Distribution/Simple/Configure.hs +1 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080417180248-9c550-28d5010cca0c4301ba62b473efb515fd4d16dded.gz From duncan.coutts at worc.ox.ac.uk Wed Apr 23 11:46:29 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Apr 23 11:41:19 2008 Subject: patch applied (cabal-branches/cabal-1.4): expose ghcOptions Message-ID: <20080423154629.GA16531@haskell.galois.com> Thu Apr 17 14:12:21 PDT 2008 jeanphilippe.bernardy@gmail.com * expose ghcOptions This helps finding the options to pass to GHC API in various tools M ./Distribution/Simple/GHC.hs +1 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080417211221-9c550-acc474f8c6530566ef030ffc3fc3b62ece5434f9.gz From duncan.coutts at worc.ox.ac.uk Wed Apr 23 11:46:31 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Apr 23 11:41:20 2008 Subject: patch applied (cabal-branches/cabal-1.4): Change dependency resolution algorithm. Message-ID: <20080423154631.GA16548@haskell.galois.com> Sun Apr 13 06:18:07 PDT 2008 Thomas Schilling * Change dependency resolution algorithm. There were two reasons to do this. Firstly, this formulation makes it easier to add the --constraint command line flag that adds additional constraints on the packages that should be used. Secondly, with the orgininal algorithm it was possible to satisfy the constraint "foo < 1, foo > 2" if we had two versions of package "foo" which each satisfy one constraint. This patch fixes this by requiring the same package to satisfy both constraints (which of course is impossible in this case). M ./Distribution/PackageDescription/Configuration.hs -10 +17 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080413131807-75a80-cc4c1b141f6726caefd27689d4fef4de3fb86f2c.gz From duncan.coutts at worc.ox.ac.uk Wed Apr 23 11:46:33 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Apr 23 11:41:21 2008 Subject: patch applied (cabal-branches/cabal-1.4): Fix/Add documentation. Message-ID: <20080423154632.GA16565@haskell.galois.com> Sun Apr 13 06:18:39 PDT 2008 Thomas Schilling * Fix/Add documentation. M ./Distribution/PackageDescription/Configuration.hs -3 +24 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080413131839-75a80-943489c44e35e45125797c38f7f749f2980187ac.gz From duncan.coutts at worc.ox.ac.uk Wed Apr 23 11:46:34 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Apr 23 11:41:25 2008 Subject: patch applied (cabal-branches/cabal-1.4): Add simple test case for the dependency resolution case. This should Message-ID: <20080423154634.GA16582@haskell.galois.com> Sun Apr 13 06:20:02 PDT 2008 Thomas Schilling * Add simple test case for the dependency resolution case. This should go into the test suite one day. M ./Distribution/PackageDescription/Configuration.hs +10 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080413132002-75a80-38b154dae31897ec806784c8f8a7ebde0f112340.gz From duncan.coutts at worc.ox.ac.uk Wed Apr 23 11:46:36 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Apr 23 11:41:26 2008 Subject: patch applied (cabal-branches/cabal-1.4): Add 'readP_to_E' function that takes the longest parse. Message-ID: <20080423154636.GA16599@haskell.galois.com> Sun Apr 13 11:20:42 PDT 2008 Thomas Schilling * Add 'readP_to_E' function that takes the longest parse. M ./Distribution/ReadE.hs -1 +9 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080413182042-75a80-104af7044cb9af3b19c91c15a49b86ca105a52b4.gz From duncan.coutts at worc.ox.ac.uk Wed Apr 23 11:46:37 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Apr 23 11:41:27 2008 Subject: patch applied (cabal-branches/cabal-1.4): Fix #224. We do not yet warn if the user specified a dependency that Message-ID: <20080423154637.GA16616@haskell.galois.com> Sun Apr 13 11:26:59 PDT 2008 Thomas Schilling * Fix #224. We do not yet warn if the user specified a dependency that did not occur in the package (it is just silently ignored.) M ./Distribution/PackageDescription/Configuration.hs -4 +23 M ./Distribution/Simple/Configure.hs +1 M ./Distribution/Simple/Setup.hs -1 +12 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080413182659-75a80-db7f5ff7b7aa3ad0e29f7bf42266371c2c6d9015.gz From duncan.coutts at worc.ox.ac.uk Wed Apr 23 11:46:39 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Apr 23 11:41:28 2008 Subject: patch applied (cabal-branches/cabal-1.4): Make finalizePackageDescription use CompilerId type Message-ID: <20080423154639.GA16633@haskell.galois.com> Sun Apr 13 15:41:11 PDT 2008 Duncan Coutts * Make finalizePackageDescription use CompilerId type Use the proper data type rather than a tuple (CompilerFlavor, Version) M ./Distribution/PackageDescription/Configuration.hs -6 +7 M ./Distribution/ReadE.hs -1 +1 M ./Distribution/Simple/Configure.hs -9 +9 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080413224111-adfee-aa61f26a50110ecef41fe0192c19ea4028c5a553.gz From duncan.coutts at worc.ox.ac.uk Wed Apr 23 11:46:40 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Apr 23 11:41:31 2008 Subject: patch applied (cabal-branches/cabal-1.4): Add PackageIndex.insert and reverse merge/mappend Message-ID: <20080423154640.GA16650@haskell.galois.com> Tue Apr 15 13:36:37 PDT 2008 Duncan Coutts * Add PackageIndex.insert and reverse merge/mappend Packages in the second argument to merge now mask those in the first. M ./Distribution/Simple/PackageIndex.hs -9 +22 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/20080415203637-adfee-1ad59c6ebc462a24d691a75bac2533dd2a50d248.gz From duncan.coutts at worc.ox.ac.uk Wed Apr 23 11:46:42 2008 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Apr 23 11:41:32 2008 Subject: patch applied (cabal-branches/cabal-1.4): Add newtype FlagName and FlagAssignment type alias Message-ID: <20080423154642.GA16667@haskell.galois.com> Tue Apr 15 13:48:54 PDT 2008 Duncan Coutts * Add new