[darcs-devel] hints on how to debug?

[David Roundy]

On Thu, Feb 03, 2005 at 09:20:28AM -0800, Wallace, Eric S wrote:
> Hi,

Hello!

> I have a darcs pull which is hanging indefinitely and I'd love to
> be able to determine where darcs is having problems (I have no
> pretensions about determining "why" as yet).

I'm guessing that you've got a large conflict or series of
conflicts--that's usually what causes these symptoms.  This is often caused
by two developers recording identical code, or removing a file that someone
else has made many changes to, or reindenting a large file which someone
else has been modifying.

Unfortunately, darcs uses an O(2^n) algorithm for dealing with conflicts.
:( This is a problem I'm currently working on (when not bug fixing or
trying to get a release out).

>From the other end of the debugging problem, simplifying the pull is a good
way to track down what's causing it.  Often (if you're pulling mulitple
patches simultaneously), pulling one at a time can reveal the culprit.
This is especially helpful if you end up having to work around a conflict,
or if you want to make a repository available for me to see what the bug
is.

> The problem is, I'm new to darcs and new to Haskell, and I have
> no idea how to go about debugging such a problem. I've tried the
> following:
> 
>     (a) building darcs with "hat", the tracing tool; I failed
>         to get this to work

Nor have I.

>     (b) using "ghci", but it looks like it can't really tell me
>         anything about what's being evaluated

Indeed.

>     (c) adding "prints" to the code, only to be thwarted by my
>         lack of understanding of Haskell's evaluation

This is what I often do.  You can either add putStrs to the IO code (which
gives a *very* rough idea of where darcs is spending its time), or you can
use Debug.Trace, which allows you to stick debug messages into purely
functional code.

Another option (which only works when darcs is able to actually
terminate--but cntrl-C might be able to do this for you, since darcs
catches it and exits cleanly) is of course compiling with profiling
enabled.  This gives a pretty nice call sequence, which is often more
helpful than "trace" output.

If the slowdown is in IO calls (probably not the case for you), strace can
be helpful.
-- 
David Roundy
http://www.darcs.net