# Review tools

Darcs-roundup-watch See where your repositories differ with the state of the darcs patch tracker

A tip from Eric, when patches involve a lot of hunk-moving, it is helpful to use:

darcs diff --diff-command="mv %1 %2 /tmp" --last=1
darcs changes --summary --last=1
cd /tmp
meld old-patch484/src/foo.hs new-patch484/src/bar.hs

## Helper functions

Ever wonder what functions like wspfr and jn do? Here’s a hint: helper functions in the darcs code are often just named by taking the first letter of the function they are supposed to help. So, for example, wspfr is just a helper function to with_selected_patches_from_repository.

## fmap

Darcs uses fmap a lot. In fact, darcs hacking is how I eventually managed to understand what they do. Here’s a hint: the following three bits of code do the same thing:

-- using do notation
return (myFn foo)

-- using fmap

-- using fmap as an operator
myFn fmap someMonadicThing

I like that third one; it helps me think of fmap as a monadic $ # Testing and Debugging Darcs includes a regression testing framework. Individual tests are in tests/*.sh(tests that should succeed), tests/network/*.sh(tests that should succeed and require network access) and bugs/*.sh (tests that should fail). Use cabal test, cabal test network and cabal test bugs respectively to run the different kinds of tests. Below are hints to help you get the most out of the test framework. ## Faster edit-compile cycle You can disable optimisations (to get faster compile) with cabal configure -fnoopt. Using ghci is even faster, here is the commandline that works on my system ghci -cpp -I. -DHAVE_CURSES -DHAVE_CURL -package parsec -optl- lcurl -optl-lssl -optl-lcrypto -optl-lz -optl-lcurses darcs.lhs maybe_relink.o atomic_create.o hscurl.o umask.o c_compat.o fpstring.o Crypt/sha2.o You can use e.g. :main pull --set-default for testing. ‘’Note that on a Mac you will have to run ’CFLAGS=-mmacosx-version-min=10.4 ./configure’ before running ghci in order to properly transform the symbols.’’ ## Running a subset of tests Sometimes you just want to see if a small handful of tests are working. You can use cabal test name_of_test1 test2. ## Dealing with different filesystems ‘’These are written for a Mac, but I’m sure the equivalent techniques exist under linux’’. Say you’re on a Mac, and you want to see how darcs would behave with a case sensitive file system like what Linux has. More precisely, you want to run darcs’s regression tests but on a different filesystem. Here is a trick I use: 1. create and mount disk image hdiutil create -size 3M -fs UFS -volname darcsTest darcsTest open darcsTest.dmg 2. set up the test image cd /Volumes/darcsTest # link the darcs binary ln -s YOUR_CODING_DIR/darcs darcs mkdir test 3. you might consider unmounting and backing up the dmg for future use… remount it… 4. move away your tests directory (save your test files first! close your text editor!) cd YOUR_CODING_DIR mv test orig_tests ln -s /Volumes/darcsTest/tests tests 5. test away! cp -R orig_tests/* tests make test Note: if you plan on switching back and forth alot, don’t bother mv’ing orig_tests back to tests; just make a symlink rm tests; ln -s orig_tests tests. Another trick to prevent confusion is to always edit your tests in orig_tests and copy them over. It helps me from confusing myself because I always know that orig_tests is the correct copy. ## Profiling • Configure darcs with --enable-profiling • See ghc’s profiling guide • Time profile: +RTS -p -RTS, gets you a darcs.prof file in your current working directory • Heap profile: +RTS -hc -RTS, gets you a darcs.hp file which you can make into .ps with hp2ps -c • Heap profiles work even if you interrupt darcs, time profiles don’t. • -hc and -hr go together nice # see what garbage collector is doing +RTS -sstderr ## Empty disk cache • # read some huge file (hint: to create a big file dd if=/dev/zero of=foo bs=1m count=500 - FIXME) # Playing around with your darcs I like to have my development darcs in the command line, so for example, in my .cshrc, I have something like alias mydarcs${HOME}/darcsHacking/darcs

I guess the equivalent in bash would be

alias mydarcs=${HOME}/darcsHacking/darcs # Keeping track of branches It’s often useful to have at least two branches on your computer, one for unstable, and one for your own use. Here’s how mine is set up for easy pulling and reduced disk usage. cd ~/darcsHacking darcs clone http://www.darcs.net/repos/unstable darcs clone unstable me-darcs cd unstable/_darcs/prefs wget http://www.darcs.net/repos/unstable/_darcs/prefs/email This way, when you do a darcs send from me-darcs, it tries to send to your local unstable and succesfully finds out which email address to sends it to. Occasionally I do a darcs pull from unstable, and then a darcs pull from me-darcs to propagate the patch. # Keep some sample repositories around One thing you might notice yourself doing a lot is creating lots of foobar repositories for testing simple darcs properties. It may save you a bit of time to create those repositories once and use them for further playing around d=~/darcsHacking/examples/foobar darcs init$d
touch $d/foo darcs record --repodir$d -lam foo foo
# etc etc

And then in the future, you can just do

cd /tmp
darcs clone ~/darcsHacking/examples/foobar

# Bugs and tests

## Distilling test cases

Sometimes really helpful people submit buggy repos to the tracker along with a patch bundle they couldn’t apply. Tricks

• Remove the patch bundle hash
• Edit the hunks by hand; delete as much superfluous stuff as you can, but go slow and save your work
• Use trial and error, progressively minimising the bundle as much as possible
• Ideally, you would get to a point where you can just run the bundle on an empty repository (and reproduce the bug); if you, it’s time to cook up a test case

# Testing SSH stuff

Testing SSH stuff can be tricky to automate (although I might have one or two ideas up my sleeves). Below are some ideas to ease the pain of manual testing. Some more notes can be found at SSHNotes

## Setting up SSH stuff

1. Avoid SSH passphrase stuff - you want to simulate a regular user interacting with the underlying ssh command. Add an entry to your .ssh/config which disables public key authentication for a specific host that you invent. For example, I have a host foo.pw which is really configured to connect to foo.com without public key authentication and with fewer password retries. This lets me do stuff like darcs get me@foo.pw:sampleRepo:

Host foo.pw
HostName foo.com
PubkeyAuthentication no
NumberOfPasswordPrompts 2
2. Use a shell script to automate setting up of repositories that you need. See tests/ssh_test

#!/bin/sh
echo ${SCMD} "$@" >> /tmp/ssh-log
${SCMD} "$@"
export DARCS_SSH=/tmp/chattyssh
export DARCS_SFTP=/tmp/chattysftp