I set my defaultrepo file to
        simonpj@microsoft.com:/home/darcs/packages/base
and tried to push.  Here's what Darcs said:

Secure connection to microsoft.com refused.
Pushing to "simonpj@microsoft.com:/darcs/home/packages/base"...
darcs.exe: bug in darcs!
fromJust error at Push.lhs:136 compiled 11:51:58 Jun 16 2006
Please report this to bugs@darcs.net,
If possible include the output of 'darcs --exact-version'.

I got the host address wrong.  It should be darcs.haskell.org, not Microsoft.com.

But the error message is rather misleading, isn't it?  It says that darcs is at fault.   But it isn't!

Simon

Yet another example of poor error handling in darcs.  I guess you could say it's
 a bug, in the sense that something goes wrong with ssh and darcs doesn't know
about it.  We ought to fix this too.

On Fri, Nov 24, 2006 at 10:16:25AM +0000, simonpj wrote:
> I set my defaultrepo file to
>         simonpj@microsoft.com:/home/darcs/packages/base
> and tried to push.  Here's what Darcs said:
> 
> Secure connection to microsoft.com refused.
> Pushing to "simonpj@microsoft.com:/darcs/home/packages/base"...
> darcs.exe: bug in darcs!
> fromJust error at Push.lhs:136 compiled 11:51:58 Jun 16 2006
> Please report this to bugs@darcs.net,
> If possible include the output of 'darcs --exact-version'.
> 
> I got the host address wrong.  It should be darcs.haskell.org, not
> Microsoft.com.
> 
> But the error message is rather misleading, isn't it?  It says that darcs
> is at fault.  But it isn't!

Indeed, this is a bug, which'll take more than the few minutes I've got
free to fix.  We're somehow not realizing that this isn't a valid
repository, which is very bad, and not failing until we are unable to
download a patch.  There should have been a failure in identifyRepository
way back in line 121 of Push.lhs.  So that's where to start looking at
this.  And this looks like a bug that could bite other bits of darcs as
well, so it's very much worth fixing.

I'm cc'ing darcs-devel in hopes of motivating some up-and-coming darcs
developer... or perhaps some overburdened darcs maintainer, but preferably
the former.  I think this is a tractable bug for someone moderately
familiar with Haskell, provided it can be reproduced...

I see that I'm not able to reproduce it! So maybe this is a tricky bug of
some sort.  I hate windows-specific bugs--not that this is necesarily one,
but odds are good, since it doesn't occur on my computer.  :(
-- 
David Roundy
Department of Physics
Oregon State University

I cannot reproduce this bug under Unix.  I suspect that I fixed it on
26 March 2006.  Please reopen it if you can reproduce it with a recent
Darcs.

I've tried various variants of your mistake (unknown hosts, hosts with no
ssh server, hosts with no darcs, incorrect path of the remote repository), and
in all cases I got some variant of the following error:

  darcs failed:  Not a repository: lanthane:/tmp/foo/bar/ (user error ((scp)
failed to fetch: lanthane:/tmp/foo/bar/_darcs/hashed_inventory))

The only part that's confusing is the ``user error'', but that's a bug in the
GHC libraries, not a bug in Darcs.

                                                   Juliusz

On Mon, Dec 18, 2006 at 12:52:11AM +0000, Juliusz Chroboczek wrote:
> I've tried various variants of your mistake (unknown hosts, hosts with no
> ssh server, hosts with no darcs, incorrect path of the remote repository), and
> in all cases I got some variant of the following error:
> 
>   darcs failed:  Not a repository: lanthane:/tmp/foo/bar/ (user error ((scp)
> failed to fetch: lanthane:/tmp/foo/bar/_darcs/hashed_inventory))
> 
> The only part that's confusing is the ``user error'', but that's a bug in the
> GHC libraries, not a bug in Darcs.

I'd say that it's a bug to reveal the "user error" to our users.  We ought
not to use the show instance on exceptions without first checking whether
they are "user errors".
-- 
David Roundy
http://www.darcs.net

>> The only part that's confusing is the ``user error'', but that's a bug in the
>> GHC libraries, not a bug in Darcs.

> I'd say that it's a bug to reveal the "user error" to our users.  We ought
> not to use the show instance on exceptions without first checking whether
> they are "user errors".

You're right.  Sending a patch straight away.

Sorry for the slander,

                                        Juliusz