• Non-Haskell folks
• Haskell hackers

Non-Haskell folks

You can run darcs on your projects, and let us know how it goes. In particular, we'd like to know how it works on your' actual'repositories. You probably use quite a different set of darcs' features than we do. Let us know about:

1. Bugs. Bonus points if you can produce a shell script that reproduces the bug, so we can add it to our test suite, and thus reduce the danger of the same bug reappearing later.
2. Triage the BugTracker! If there are no new bugs to triage, look for stale bug reports or check up on people we need follow-ups from, etc.
3. Commands that run unusually slowly
4. Run timings (see Benchmarks).
5. Bonus points for producing a shell script to demonstrate the poor behavior.
6. Feature requests. When you're using darcs (particularly hashed repositories) is there something that seems like it would make your life easier? Please, focus on features in some way related to the changes in darcs.
7. Your impression: which new features do you like, what do you find confusing?
8. Documentation: Read the documentation, and let us know what's unclear. Even better, write improved documentation and send us a patch.

Haskell hackers

While there's a lot that anyone can do (especially in the realm of documentation reading and writing!), there's even more for Haskellers. Here's a short list of features that could use work, some more difficult, some less so. Some I'll get to work on myself pretty soon once I get a chance, and some will have to wait for someone else. Now that this release is out, however, I expect that I'll be spending much more time tracking down bug reports and improving documentation than I am on some of these optimization tasks. If you don't understand one of the suggestions, please ask for clarification... but some of these are tasks that I myself am not well qualified to carry out, so don't feel discouraged if I discourage you from pursuing a particularly tough problem.

1. Check the bug tracker. Look out for bugs marked PropablyEasy ( http://tinyurl.com/darcs-probablyeasy2 ) otherwise, bugs with a comment like "this looks like something for a new darcs hacker to work on" which is your cue that the bug is easy enough to tackle.
2. Run profiling tests, to see where our slowdowns are and fix them.
3. issue1567 The new FL and RL types are great for safety, but they don't get deforested. Implement a RULES system (maybe Don's streams?) to allow deforestation/fusion.
4. issue1357 Change the hunk patch to store solid blocks for the "new" and "old" text (rather than PackedString), and introduce a new hunk format without the '+'s and '-'s at the beginnings of the lines (which would make it much faster to parse).
5. issue1009 Similar to the previous: an efficient binary patch format.
6. Document some of the internal APIs. If you take the time to read the code to understand a module, you could consider sharing that understanding with the world by documenting it. Yes, I know this is very lazy of me, but there you go.
7. issue1007: Change darcs to use lazy bytestrings instead of FastPackedString. Ideally, we'd do this after introducing the new hunk patches. Also note that I do not want lazy IO, as that's been a major source of headaches in terms of problems like file handle leaks. But O(1) append would be nice, as would the highly-optimized nature of bytestring.
8. issue1568 Try changing FileName to store filenames as bytestrings rather than String. This should speed parsing somewhat, and reduce memory usage. We'd still need to convert to String for IO functions, but those are relatively isolated, so I think this'd still be a win (particularly as the filename starts out as a packed string in the patch files.
9. If you want something more substantial to work on, check out the project ideas in GoogleSummerOfCode

This is all that I've been able to come up with off the top of my head. These are not small projects, but there is a not-small amount of glory to be gained by taking them on, so go ahead and join the fun! :)

• Development