doing a:
  darcs pull --verbose

has had me waiting up to 20 minutes without a single line of text telling me
what it's doing.

I probose some-other-option or possibly verbosity level, or perhaps even fixing
the current verbose level to tell me why I should bother waiting and let me know
that it's not in fact hung.

When darcs takes a long time without feedback it is
usually busy commuting.  It would be nice to have some
commuting-progress messages, but as far as I understand it
is not possible to calculate any sensible value estimating
the amount of work ahead.  But perhaps a running count of
patches to 'check and maybe commute' and a dot every third
second while commuting a patch is enough.

As far as i'm concerned, even a "darcs is busy commuting patches.  This
may take some time ..." message would be a vast improvement on nothing at
all.

I'm cc'ing darcs-devel on this, since it's a bit beyond my haskell skill
level.  I'm sure I could figure it out, but I'm also sure that someone else
could figure it out more easily (plut I have other darcs work to do)...

It's not terribly important, but I think that a framework for providing
feedback during long pure calculations would be valuable for darcs (and
probably also for other projects--I can imagine writing this as a library
for general use).

On Sun, Dec 25, 2005 at 11:18:52AM +0000, Tommy Pettersson wrote:
> When darcs takes a long time without feedback it is usually busy
> commuting.  It would be nice to have some commuting-progress messages,
> but as far as I understand it is not possible to calculate any sensible
> value estimating the amount of work ahead.  But perhaps a running count
> of patches to 'check and maybe commute' and a dot every third second
> while commuting a patch is enough.

This sort of output would presumably require using concurrent Haskell and
perhaps some unsafe operations to update the amount of work left?

It would definitely be interesting if we could compute in advance the
number of commutations required.  But alas, when conflicts are involved
that probably isn't possible.  And of course, we don't want to insert
unnecesary overhead into the commute code just to give nicer feedback.

I wonder if we could write a function like

long_verbose_computation :: String -> a -> a

which would use seq to ensure that an unsafePerformIO spawns a new
notification thread that will notify every three seconds or so, followed by
a kill of that thread at the end.  Something like

long_verbose_computation message data =
    case unsafeSpawnMessageThread message of
    thid -> case data `seq` unsafeKillMessageThread thid of
            data' -> data'

I think something like this might be able (with appropreate unsafe...Thread
functions using unsafePerformIO) to print messages out only for long
computations.  Then we could do something like

commute (ComP x, ComP y) =
  long_verbose_computation "I'm commuting..." commute_composite (x,y)

We might also want a global lock to avoid nesting of these messages.  Note
that this will only work for functions that are slow to reach HNF, but
lazily outputting functions shouldn't usually be a problem anyways.
-- 
David Roundy
http://www.darcs.net

this is getting quite ridiculous.  I've been waiting for close on 3 hours now
for a 'pull --verbose' and the only text that has been displayed is the MOTD.