Custom Query (184 matches)


Show under each result:

Results (31 - 33 of 184)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Ticket Resolution Summary Owner Reporter
#1553 fixed cabal-install package dependency resolution duncan

`cabal-install` is the new command line interface to the Cabal/Hackage? system. It does all that runghc Setup.hs does and more. Its major feature is the ability to download an install packages from hackage, including all dependencies.

For example the user says cabal install xmonad and it goes away and looks at what packages are available on hackage and which ones are already installed and works out what packages need to be installed in what order to satisfy the users request.

It turns out that deciding what packages to install is not as easy as it looks. Package dependencies can get quite complicated. Furthermore, users have preferences which we would like to respect. For example the user might want to upgrade all packages that can be upgraded, or they might prefer to install the minimum number of new packages and re-ruse as many existing installed packages as possible. So we need an algorithm that is sufficiently flexible to handle these. Users also expect good error messages in the cases that their request cannot be satisfied.

The current algorithm in cabal-install is very simplistic. It works in simple cases, but it can often generate impossible solutions and it is not flexible to respect user preferences.

There are a number of open bugs about the current system:

The first two are summary bugs (that cover a number of other previous tickets), the last is a specific one.

So this project is to design a new package dependency resolution algorithm and to implement it in cabal-install so that the whole community can benefit from hassle free package management.

Interested Mentors

  • Duncan Coutts

Interested Students

  • Maciej Wos <maciej.wos@…>
  • Piotr Kaleta <piotrek.kaleta@…>
#1559 fixed Parallel profiling tools for GHC simonmar

We currently have no tools to investigate the performance of parallel programs, other than the raw timings you get from +RTS -sstderr, and this makes parallel programming rather hard. This project would involve building and testing various tools for investigating the performance of parallel programs.

This project would particularly benefit from #1544 if that was also accepted, as there would be some benchmark code to work with.

I (SimonM) have ports of the GranSim parallel profiling tools, that were done by Michael Adams during his internship at MSR. A good starting point for this project would be to take that work, take a critical look at it and see what needs to be done (if anything) to get it into the tree. We might want to build additional tools using the same framework.

Interested Mentors

  • Simon Marlow <simonmarhaskell@…>

Interested Students

  • Donnie Jones <donnie@…>
  • Etienne Laurin <etienne@…>
#1561 fixed Cleanup, document and improve the GHC API simonmar

The GHC API currently has no documentation beyond the source and a few wiki pages, e.g. The GHC API has grown on demand: it contains mostly what GHCi needs, and not much else. This project would involve:

  • Document the GHC API using Haddock (Haddock 2 should be able to process GHC now).
  • Survey current and potential users of the GHC API to identify what they need
  • Cleanup and extend the API as necessary. Parts of its implementation are in dire need of some internal refactoring too.

The goal would be to present an easy to use and well-documented GHC API for GHC 6.10, and a selection of example code for potential users to start from.

See also

Interested Mentors

  • Simon Marlow

Interested Students

  • Thomas Schilling (nominolo)
  • Giuliano Losa (nano), <giuliano.losa@…>
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Note: See TracQuery for help on using queries.