- cabal-devel - Haskell.org

Re: [Hackage] #656: Cabal-1.8-style dependencies stop Haddock from working
by Hackage 10 Nov '10

10 Nov '10

#656: Cabal-1.8-style dependencies stop Haddock from working ------------------------------+--------------------------------------------- Reporter: Ivan Miljenovic | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal library | Version: 1.8.0.4 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ------------------------------+--------------------------------------------- Changes (by GeoffreyMainland): * cc: mainland@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/656#comment:8> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #704: sort out design for foreign code in Haskell libraries
by Hackage 09 Nov '10

09 Nov '10

#704: sort out design for foreign code in Haskell libraries ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Currently we often happily add little bits of C glue code into Haskell packages. This is perfectly reasonably but we also want to be able to do things like linking multiple versions of a Haskell package into a single application. That does not work if the C symbols are visible outside of the package (see #701). It seems reasonable to require that C code in a Haskell package respects the properties that we want for Haskell packages. However we must also allow for libraries that are foreign code and not Haskell libraries at all. For example, the zlib binding package ships a complete copy of the zlib C code for platforms that do not have it natively. Unlike bits of FFI glue code, it is unreasonable to expect to change the zlib code to conform to Haskell library requirements. Perhaps what we need is to explicitly identify foreign libraries and hold them to different (lower) standards compared to Haskell libraries. One idea would be to draw together the features proposed in these tickets: * #276 : support for convenience libraries * #148 : producing foreign libraires The idea with convenience libraries is that a package can have multiple libraries in it, even though at most one can be the library that has exposed modules. Other libraries could be used by executables or the main library in that package. The main purpose is sharing but it could also be a way to separate the requirements of haskell code and foreign code. Producing foreign libraries is about making libraries (usually but not necessarily containing Haskell code) that export a foreign C API and are not intended to be used by other Haskell code. Combining these two features would allow for the zlib example to work ok. We would declare a foreign library with the zlib C code and make the main Haskell binding library depend on it. Note that packages that depend on the binding package would not directly link to the C library (this is significant for shared libs). The key constraint for foreign libraries is that we cannot link more than one version into a single application (because the symbols would clash), where as we may assume that it is perfectly safe to link multiple versions of a Haskell package. Any design must also consider symbol visibility. This is relevant both for shared and static libs. With static libs it is hard to avoid every symbol being globally visible. With shared libs there is greater control over symbol visibility but also the restriction on some systems that each shared lib must resolve all symbol references. This means we must more explicitly identify which libraries import symbols from others. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/704> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #758: expose existing functionality: fetchPackage/unpackPackage
by Hackage 09 Nov '10

09 Nov '10

#758: expose existing functionality: fetchPackage/unpackPackage ---------------------------------+------------------------------------------ Reporter: claus | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ `cabal-install` has functionality for fetching and unpacking `cabal` packages (`.tar.gz`, as produced by `cabal sdist`). It would be very helpful to expose these functions as `cabal-install` commands. `unpackPackage` is the more important of the two, though being able to fetch individual packages from URLs (think blogs, wikis, ..) without having to establish a full hackage-like repo would also be very welcome. Most importantly, you could remove the whole http://www.haskell.org/haskellwiki/How_to_unpack_a_tar_file_in_windows hazzle. Instead of package authors and users having to worry about whether some unpacker is installed client-side, everyone could just rely on {{{ cabal unpack Example.tar.gz }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/758> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

Re: [Hackage] #597: non-exhaustive patterns when trying to install base
by Hackage 09 Nov '10

09 Nov '10

#597: non-exhaustive patterns when trying to install base ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.2 Severity: minor | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | ---------------------------------+------------------------------------------ Comment(by duncan): If someone wants to fix this, the other thing to check is with and older or newer GHC that does not have two versions of base. A user reported that with ghc-6.6 they get an "impossible" internal error in this situation. The general fix here is to have a per-compiler list of packages that are impossible to upgrade. If the user explicitly asks to install one then they should get a sensible error. For all other cases it should use a constraint on picking an installed instance of these packages. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/597#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #597: non-exhaustive patterns when trying to install base
by Hackage 09 Nov '10

09 Nov '10

#597: non-exhaustive patterns when trying to install base ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.2 Severity: minor | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | ---------------------------------+------------------------------------------ Comment(by guest): The problem persists in Cabal-1.8.0.6. Installing library in /Users/abel/.cabal/lib/Cabal-1.8.0.6/ghc-6.12.1 Registering Cabal-1.8.0.6... $ cabal install base Resolving dependencies... cabal: Distribution/Client/Dependency/TopDown.hs:171:37-73: Non-exhaustive patterns in lambda --Andreas Abel -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/597#comment:2> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: parseCSV "name" . printCSV not idempotent
by Antoine Latter 09 Nov '10

09 Nov '10

On Mon, Nov 8, 2010 at 2:45 PM, Jaap Weel <jaapweel(a)gmail.com> wrote: > Yes, that is precisely what is going wrong. And I made a new version > that does not use unlines. It's on hackage and on github now. (I'm > jaapweel on github.) > > Jaap Weel Thanks for the quick fix, Jaap! Joachim - so it looks like we would be okay requiring the new version of CSV and getting rid of my workaround? Antoine

2 1

parseCSV "name" . printCSV not idempotent
by Joachim Breitner 08 Nov '10

08 Nov '10

Hi Jaap, your CSV library is used in the Hackage2 project. I found that backup and restore does not work with a pristine state, and the reason seems to be a problem with your library: It either adds unnecessary newlines or interprets empty lines at the end of the program for no apparent reason: Prelude Text.CSV> (parseCSV "name" . printCSV) [] Right [[""]] Prelude Text.CSV> (parseCSV "name" . printCSV) [[]] Right [[""],[""]] Prelude Text.CSV> (parseCSV "name" . printCSV) [[],[]] Right [[""],[""]] Prelude Text.CSV> (parseCSV "name" . printCSV) [["hi"],["ho"]] Right [["hi"],["ho"],[""]] Prelude Text.CSV> (parseCSV "name" . printCSV) [["hi"]] Right [["hi"],[""]] Prelude Text.CSV> Is that easy to fix? Thanks, Joachim -- Joachim "nomeata" Breitner mail: mail(a)joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata(a)joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata(a)debian.org

2 3

darcs patch: Only warn about missing static directory (and 2 more)
by Joachim Breitner 08 Nov '10

08 Nov '10

Hi, 3 patches for repository http://code.haskell.org/hackage-server: These implement bulk writing and reading of Distro data in CSV format. Greetings, Joachim Sat Nov 6 11:43:59 CET 2010 Joachim Breitner <mail(a)joachim-breitner.de> * Only warn about missing static directory As the new command does not have a flag for it and does not require it. Sat Nov 6 13:59:28 CET 2010 Joachim Breitner <mail(a)joachim-breitner.de> * Create a new ResourceType CSVFile Sat Nov 6 13:59:52 CET 2010 Joachim Breitner <mail(a)joachim-breitner.de> * Support Bulk update of distro info using CSV format

3 2

darcs patch: bugfix: --state-dir not used for backup ... (and 2 more)
by Joachim Breitner 08 Nov '10

08 Nov '10

[Re-send to the list, http://code.haskell.org/hackage-server/_darcs/prefs/email contains Duncan’s address] Hi, here is the support for Distro releases. The release name "default", if used in the public API, is special to indicate "no release name", for distributions that does not distinguish between releases. I’ll update the Wiki to reflect the new paths now. Greetins, Joachim 3 patches for repository http://code.haskell.org/hackage-server: Sun Nov 7 10:27:23 CET 2010 Joachim Breitner <mail(a)joachim-breitner.de> * bugfix: --state-dir not used for backup tarball name Sun Nov 7 10:49:52 CET 2010 Joachim Breitner <mail(a)joachim-breitner.de> * Fix importing of empty groups from backup Sun Nov 7 11:01:59 CET 2010 Joachim Breitner <mail(a)joachim-breitner.de> * Support for more than one release per distribution

1 0

darcs patch: Search for programs in bindir of user
by Martin Kiefel 07 Nov '10

07 Nov '10

Hi, I wrote this for #663. Unfortunately, I did not find an easy way to find out if a Program type is using the standard way of locating a program or if it uses a custom method for this (without breaking the signitures). So my solution tries to locate a program (no compilers) first in the directories of PATH and then falls back to the bindir that will be used to install the program later on. Not sure if this is the nicest way to do this, since program detection has to be split up in programs that are found the traditional way and others that are additionally search in the bindir. Cheers, Martin Sun Nov 7 15:13:12 CET 2010 Martin Kiefel <mk(a)nopw.de> * Search for programs in bindir of user See Ticket #663. If program is not found in the PATH directories it will be search in the local bindir, which was specified by the user.

1 0