Custom Query (162 matches)
Results (28 - 30 of 162)
|#1543||fixed||Performant Amazon S3 interface||dons|
Amazon S3 , http://aws.amazon.com/s3 , is an online storage system for internet applcations, providing a simple interface to store and retrieve data from anywhere on the web. The storage is highly scalable.
This project would extend and improve the current s3 bindings,
to supprt bytestring based network, and the full features of the system. A simple, well structured interface should make it easy to store and retrieve large amounts of data in Haskell, using this service.
|#1545||fixed||Parser and pretty printer framework for C||dons|
The c2hs library implements a fairly complete parser for gcc C, and there exist various smaller pretty printers for subsets of the language.
This project would aim to consolidate the support for parsing and generating C code from Haskell, providing a single library, under Language.C.
It would reuse c2hs' infrastructure where necessary.
More details here http://haskell.org/pipermail/haskell-cafe/2007-April/024703.html
Benedikt Huber <benedikt.huber@…>
|#1552||fixed||Cabal 'make-like' dependency framework||duncan|
This project aims to prototype a make-like dependency system to use in Cabal.
Currently Cabal's building style is imperative and it relies on ghc --make or hmake to rebuild Haskell modules.
All the Cabal hackers agree that ideally almost all of the building code in Cabal should be done in a dependency style. There are many features we cannot currently add and bugs we cannot currently fix because they need a dependency system and for Cabal to do it's own module chasing rather than using ghc --make.
For Cabal-2.0 we aim to move to a dependency framework, this project is to prototype that system.
The cabal hackers already have quite a few ideas about the requirement and about how it could be done. Any student interested in this project should talk to the Cabal hackers to make sure they understand the issues and to help improve their project proposal.
One way the prototype project might work might be to implement module dependency analysis for yhc which is currently not supported by Cabal at all (or perhaps nhc98). This would allow the code to be included in the main Cabal development repo without destabilising the ghc support. From there we could move to using the dependency stuff for pre-processors, which would be very useful as it'd allow proper support for c2hs (which is what is holding back Cabalisation of gtk2hs).