This is the perfect project for a non-darcs Haskeller to get on. Good for us, good for the whole Haskell community. Approach : identify likely haskellers (e.g. authors/maintainers of respective hackage packages) and ask for their help?
We should spin off
Things that probably should be spun off into standard libraries (or merged with, replaced with, etc)
- diff detection, edit distance, lcs, code
- I've imported Lcs.lhs into the lcs package maintained by Igloo; I'm just waiting on relicensing permission from Dr. Roundy
- crypto stuff
- the folks behind the Crypto package seem to say that our implementation of SHA1 (was it sha1?) was faster but more imperative... so what to do here? Can we make the functional crypto faster? Should we submit our code as a fast crypto variant of the pure implementation?
- bytestring
done by DonStewart during darcs hacking sprint #1 (2008-10)
- bytestring add-ons
- gzip/gunzip (interactions with bytestring)
GaneshSittampalam has done this (add a Haskell zlib interface)
- phases remaining
- switch to using Haskell zlib by default - after 2009-01?
- remove old C libz ffi imports - after 2009-07?
- date parsing
- utf-8 suppport (ours does safe handling of errors; utf8-string does not... can we improve the latter?)
- The error handling doesn't appear to be relevant, since presumably we can trust the Haskell runtime to not feed the 'encode' function any corrupt [Char]s. There's a patch to make UTF8.lhs merely an importer of the utf8-string library.
- System.Posix stuff for windows (package: unix-compat ?)
- Unfortunately, the unix-compat package does not currently export everything we need (ie. no System.Posix, no System.Posix.IO) and it's unclear to me why the CtrlC.hs module.
- fetching remote files (curl on Hackage, but maybe generic wrapper for curl/libwww/HTTP)
XML handling can probably be reduced; no doubt a lot of the functions in src/Darcs/Patch/Viewing.lhs are redundant with HaXml or something.
Darcs.Patch.Ordered => Data.Ordered
- Patch.Ordered looks pretty Darcs-specific to me, what with importing Sealed. Who exactly could make use of it?
Advanced printing: Darcs.ColorPrinter and Printer
- Slurpies?
- Commands/subcommands/arguments infrastructure
See the parseargs library
- Features we would need
- commands (darcs whatsnew) and subcommands (darcs show repository)
- disambiguation (darcs wh)
- hidden commands (darcs transfer mode)
- basic vs advanced commands
- default arguments
- etc (note that we probably can't realistically rely on the library to do everything, but the more we can reasonably outsource the better)
Note that programs like cabal-install and twidge use this. You can imagine a ton of programs that you could use this, for example, a timesheet helper, e.g hstimesheet clockin task1
We should introduce
- proper MIME parsing
- SMTP
We may have to keep
- filepath stuff - we have our idiosyncrasies
From issue341: "I'm not convinced that System.FilePath is a route we'd want to go. We already have code that is almost certainly better tested than System.FilePath, and that we understand." -- DavidRoundy 2006-11
- Potential pitfalls
- encode/decode white
- utf-8 (should not affect filepath; just packing)
- safeFileChar?
- 100% backwards-compatibility for internal patch stuff (safest bet is not to change code)
- subtle semantic differences
Good news: it's just the FilePath type we're dealing with here (i.e. String), so it should be a relatively painless switch.
EricKow has done some work to replace some of our ad-hoc code with filepath code; there may be more to go, though
Darcs To Ploughshares ?!
The original name of this page comes from an english saying about converting weapons to useful food-growing tools. Some of us find it a bit confusing.