April 2009 - cabal-devel

haddock-2.3.0 literate comments discarded from .lhs input
by Alistair Bayley 27 May '09

27 May '09

I have this test case for Haddock (2.3.0): -------------------------------------------------- | Module : Test.Haddock Copyright : (c) 2009 Alistair Bayley License : BSD-style Maintainer : alistair(a)abayley.org Stability : stable Portability : portable Test case for Haddock. > module Test.Haddock > ( > -- $named_block > Fail(..) > ) > where > data Fail = Fail | Succeed $named_block This is some hadock documentation. -------------------------------------------------- This fails with: [1 of 1] Compiling Test.Fail ( Test\Fail.hs, Test\Fail.o ) Test\Fail.hs:11:26: Can't make a derived instance of `Typeable Fail' (You need -XDeriveDataTypeable to derive an instance for this class) In the data type declaration for `Fail' If I manually unlit, then Haddock is happy: -------------------------------------------------- -- | -- Module : Test.Haddock2 -- Copyright : (c) 2009 Alistair Bayley -- License : BSD-style -- Maintainer : alistair(a)abayley.org -- Stability : stable -- Portability : portable -- -- Test case for Haddock. module Test.Haddock2 ( -- $named_block Fail(..) ) where data Fail = Fail | Succeed -- $named_block -- -- This is some hadock documentation. -------------------------------------------------- so it looks as though it's discarding the literate comments. Is this intended? I was under the impression that because it used the ghc parser, it could now properly handle .lhs input. Ona related note, we have a nice unlitter in cabal that would preserve these comments before invoking haddock. Is this still used with haddock2, or does it now assume haddock2 will do the right thing? Alistair

5 27

[Hackage] #504: executables with a C main function
by Hackage 03 May '09

03 May '09

#504: executables with a C main function ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- We would like to be able to do: {{{ executable blah main-is: main.c }}} Either for pure C programs or mixed C/Haskell programs with main in the C code rather than Haskell code. == Workaround == Until this is implemented one can use a main in Haskell that calls out to the C main function. For example: `main.c` {{{ int real_main () { return 42; } }}} `Main.hs` {{{ import System.Exit import Foreign.C main = real_main >>= exitWith . ExitFailure . fromIntegral foreign import ccall "real_main" real_main :: IO CInt }}} `c-main.cabal` {{{ name: c-main version: 0.0 build-type: Simple cabal-version: >= 1.2 extra-source-files: main.h executable c-main main-is: Main.hs c-sources: main.c includes: main.h extensions: ForeignFunctionInterface build-depends: base }}} == Implementation notes == At the moment Cabal's "Simple" build system requires `main-is` to specify a `.hs` or `.lhs` file (though it does allow that to be generated by a pre-processor). If we lift that restriction the first thing to go wrong will be that `ghc --make` does not work with `-no-hs-main`. We will have to do the build and link steps separately (which is probably a good thing anyway). We would use `ghc --make` to compile all Haskell modules to `.o` files and then invoke `ghc` in batch mode passing it all the `.o` files (from Haskell and C modules) and `-package` flags. If we're using a C main then we'd do the link step with `-no-hs-main`. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/504> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

cabal-install fails with tar checksum error
by Alistair Bayley 30 Apr '09

30 Apr '09

On WinXP. I've uploaded Takusen-0.8.4 to hackage, and thought I'd see how well cabal-install downloads and installs it. cabal install Takusen --flags="sqlite odbc oracle postgres" --reinstall -v3 results in (with some trimming): ... In order, the following would be installed: Takusen-0.8.4 (reinstall) Takusen-0.8.4 has already been downloaded. Extracting C:\Documents and Settings\bayleya\Application Data\cabal\packages\hackage.haskell.org\Takusen\0.8.4\Takusen-0.8.4.tar.gz to C:\DOCUME~1\bayleya\LOCALS~1\Temp\Takusen-0.8.411372... cabal: Error: some packages failed to install: Takusen-0.8.4 failed while unpacking the package. The exception was: user error (TAR checksum error) The uploaded package was created with "darcs dist -d Takusen-0.8.4". Can I check before uploading that the tar file is valid? darcs --version gives: 2.0.2 (+ 76 patches) Alistair

2 1

[Hackage] #550: bad error message when proxy cannot be resolved
by Hackage 29 Apr '09

29 Apr '09

#550: bad error message when proxy cannot be resolved ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: low | Milestone: Component: cabal-install tool | Version: Severity: minor | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ---------------------------------+------------------------------------------ As reported by a user: {{{ when I run cabal update I get some strange error: % cabal update Downloading the latest package list from hackage.haskell.org cabal: user error (openTCPConnection: host lookup failure for "") }}} Turns out the problem was that `http_proxy` environment variable was set to "" (ie the empty string). The problem with the error of course is that we've no idea what it is it thinks is "", there's no indication that it's the proxy. If it said that it encountered the problem while contacting the proxy that'd be an improvement. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/550> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #231: "buildable: False" should fail the current configuration
by Hackage 27 Apr '09

27 Apr '09

#231: "buildable: False" should fail the current configuration ----------------------------+----------------------------------------------- Reporter: duncan | 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: | ----------------------------+----------------------------------------------- Currently resolving configurations does not take account of the `buildable` field. It should act rather like `build-depends: non- existant`, though with a different error message. If possible the error message should relate to the guard condition expression (the conjunction if there are several nested guards). At the moment it is not considered at all and we don't notice that the package cannot be built until the build step, rather than the configure step. One problem is that it's not clear if `buildable: False` is always fatal. People sometimes do that for test executables that are not supposed to be installed. So what should the behaviour be? The lib or only exe failing to configure must be an error. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/231> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #548: Aid in function lookup in IDEs
by Hackage 25 Apr '09

25 Apr '09

#548: Aid in function lookup in IDEs ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Currently haskellmode builds an index of functions based on the docs installed on a system. This means a user has to install all docs for all packages. HackageDB builds docs for all modules on the site, so it seems silly that I need to install the docs myself. It would be cool, and probably useful for IDEs if a file was available from HackageDB that contained enough information to build that index, and point to docs on HackageDB. Then people with limited disk space, who are on always-online machines, can enjoy easy function lookup. Even cooler would be if there was a web API (e.g. XML-RPC server) available that could be used to do the function lookups. For instance passing a function name would return a list of pairs of module name and URL. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/548> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #338: use of HTTP needs overhauling
by Hackage 24 Apr '09

24 Apr '09

#338: use of HTTP needs overhauling ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ We're not using HTTP the protocol or HTTP the package effectively * As I understand it, the HTTP lib buffers the entire http download in memory rather than returning it lazily, so we cannot stream it to disk. It's also all done using `String`. * We do not check (and nor does the HTTP lib) for truncated downloads. That is where the `Content-Length` header differs from the actual length. * We do not cache the ETag so we cannot optimise the case of re- downloading an unchanged index. * We make a new tcp connection for each download, rather than doing all downloads within a single browse session. * We are not doing downloads concurrent with package builds. We should probably use a dedicated thread for downloads. It should serialise downloads and use a single browse session. Even without support for streaming the body directly we could at least write files atomically, checking length header. And also cache the ETag. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/338> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #448: cabal-install needs new http download component
by Hackage 24 Apr '09

24 Apr '09

#448: cabal-install needs new http download component ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- The way in which cabal-install currently uses the HTTP library API is quite sub-optimal. It starts a new `Broswer` session for each connection. This means that it cannot take advantage of HTTP pipelining, connection pooling and other goodies. One design would involve making some HTTP download object and making requests through that. The download object would start a thread to make the actual requests. Requests would be serialised, eg using a `Chan`. It probably wants to work by directing URLS be downloaded to local files. On top of this we should build some caching mechanism so that we can check for example if our package index is up to date before downloading the whole thing. It would also be nice to check the length and md5 header to catch short or corrupted downloads. Something like: {{{ downloader :: Settings -> IO Downloader download :: Downloader -> URL -> FilePath -> IO () }}} The `download` function is given the URL and the local file path. If the local file exists it is taken to be the cached file. It should download the URL to a temp file in the target directory and if all successful it should atomically rename it over the target file. Perhaps error handling needs to be more explicit than just using `IOError`s. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/448> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

cabal-install fails on WinXP
by Alistair Bayley 23 Apr '09

23 Apr '09

I've tried using cabal-install (cabal.exe) for the first time to install yi, and all of the packages fail to download. Reducing to a simple test case, "cabal install binary" fails with: Resolving dependencies... Downloading binary-0.4.4... cabal: Error: some packages failed to install: binary-0.4.4 failed while downloading the package. Where do I look to diagnose this? Alistair

2 6

[Hackage] #289: symlink binaries into ~/bin
by Hackage 23 Apr '09

23 Apr '09

#289: symlink binaries into ~/bin ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ Currently cabal-install uses `--prefix=$HOME/.cabal` and does not specify `--bindir` so we use `$HOME/.cabal/bin` as the bindir. Obviously this is not on the `$PATH` by default. It would be trivial to specify `--bindir=$HOME/bin` however the worry is that we would be stomping on programs that the user has already installed there. One solution is to continue to install into `$HOME/.cabal/bin` and then to make symlinks into `$HOME/bin` if the target name does not already exist. If the name does exist we could give a warning and let the user sort it out. Of course we need to be able to overwrite our own symlinks. We know it's a symlink we're allowed to overwrite if it links into `$HOME/.cabal/bin`. It would be nice to install into `$HOME/.cabal/bin` using versioned binary names (Cabal supports that now) and symlink the generic name into `$HOME/bin`. We can discover the names of the binary we're installing by checking the executable names in the `PackageDescription`. Of course this has to be an optional feature since not everyone wants it and there are no symlinks on windows. I'd imagine we'd have it in the `~/.cabal/config` file something like: {{{ prefix: $HOME/.cabal -- bindir: $HOME/.cabal/bin symlink-bindir: $HOME/bin }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/289> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 17