Folks:

I tried the executables from

http://www.cs.mu.oz.au/~rgm/darcs/

but they don't do anything on my Windows XP system, not even pop up a  
crash dialog.  "./darcs.exe --version", for example, returns silently  
to the prompt.

Regards,

Zooko

Zooko, 

Those are not official binaries, so I'm marking this as "not our bug". 

However, I'm also assigning it to "RGM" whose username is in the URL, and who
also has account in this bug tracker, in case s/he wants to follow-up about this.

In the meantime, it would be useful if someone added a note to the wiki about
this result, to prefer further user frustration.

I use these builds of darcs on the system I use to make the builds, I have also 
tested them on another Windows XP system that does not belong to me. In both 
cases they have worked properly. I am not sure how to even begin figuring out 
what is going wrong here.

Um, okay, so I tried it again and now it works.

My apologies for the false alarm.

By the way, I would like for the darcs project to start treating bugs in the
Windows version of darcs as "our bugs".  I would be willing to continue put in a
little time every now and then to fix such bugs, as I have been doing for years.

Being able to use the bug tracker to track the status of such issues and more
importantly feeling like I "belong" would encourage me to do that kind of thing.

Oh, I see why.  Because the darcs_2008-01-02.exe and the darcs_2008-01-16.exe
work, but the darcs_2008-01-19.exe returns silently from any invocation of it. 
So there's definitely something suspicious about these three executables.  Two
of them work for me and the latest one doesn't.

I'm taking the liberty of marking this as priority "bug" (if this tracker will
let me).  I've added the "Windows" keyword to the "Topics".

I'm still curious about why the darcs build returned silently. Was it a .dll
issue? My ability to test my windows builds on multiple systems is very limited,
as I only have access to two windows PCs, so it's possible for build problems or
other bugs to only manifest on other people's computers.

Zooko, I agree with marking this as "bug".  Although it's not one that I can
help you with, alas.

David

The exit code was 53.  Dependency Walker (thanks for the suggestion, Simon
Marlow) says that ZLIB1.DLL, EFSADU.DLL and MSJAVA.DLL are not found when
inspecting darcs_2008-01-19.exe -- the one that doesn't work.  When inspecting
darcs_2008-01-16.exe -- the one that works -- it says only that efsadu.dll and
msjava.dll are not found.  That's a relief -- for a minute there I was afraid
that MSJAVA.DLL was required...  ;-)

On Wed, Jan 23, 2008 at 01:50:42PM -0000, Zooko wrote:
> The exit code was 53.  Dependency Walker (thanks for the suggestion, Simon
> Marlow) says that ZLIB1.DLL, EFSADU.DLL and MSJAVA.DLL are not found when
> inspecting darcs_2008-01-19.exe -- the one that doesn't work.  When inspecting
> darcs_2008-01-16.exe -- the one that works -- it says only that efsadu.dll and
> msjava.dll are not found.  That's a relief -- for a minute there I was afraid
> that MSJAVA.DLL was required...  ;-)

So it sounds like zlib is dynamically linked in the latest windows binary,
and that's what's causing the trouble? That sounds like something that
ought to be easily fixable just by statically linking with zlib.  :)

(And yes, before I finished reading your email, I also had already freaked
out about why MSJABA.DLL was required...)
-- 
David Roundy
Department of Physics
Oregon State University

Zooko wrote:
>
> By the way, I would like for the darcs project to start treating bugs in the
> Windows version of darcs as "our bugs".  I would be willing to continue put in a
> little time every now and then to fix such bugs, as I have been doing for years.

Zooko,

I'm sorry if the intent of my "wont-fix" change wasn't clear. I believe 
Darcs can and does support Windows bugs. There are a number of open 
Windows bugs in the system now. (rather having met the "wont-fix" fate.)

What I don't think is reasonable to support are packaging issues. If 
Someone publishes an Arch Linux binary that needs a missing ".so" file, 
or a Windows executable that needs a missing ".dll" file....I see those 
as packaging issues that are difficult for the developers to address-- 
the packagers need to fix those issues, and those packagers may not be 
following the bug tracker.

In this case, Rob Moss was in the system, so that was helpful.

Of course, I speak for myself. David or others may be in favor of trying 
to support packaging issues.

     Mark

On Wed, Jan 23, 2008 at 02:41:14PM -0000, Mark Stosberg wrote:
> I'm sorry if the intent of my "wont-fix" change wasn't clear. I believe 
> Darcs can and does support Windows bugs. There are a number of open 
> Windows bugs in the system now. (rather having met the "wont-fix" fate.)
> 
> What I don't think is reasonable to support are packaging issues. If 
> Someone publishes an Arch Linux binary that needs a missing ".so" file, 
> or a Windows executable that needs a missing ".dll" file....I see those 
> as packaging issues that are difficult for the developers to address-- 
> the packagers need to fix those issues, and those packagers may not be 
> following the bug tracker.

I agree that we can't in general support packaging problems.  However,
because Windows is a particularly hard platform on which to compile darcs
(at least, as far as I understand), I think it does make sense to provide a
bit more help on that platform.  Particularly as Windows itself is without
(again, so far as I know) any resources to help packagers.  Any linux
distribution has users and devel mailing lists, but Windows is without all
that, and I'd say that it's reasonable to allow the folks who package
darcs for Windows to make use of our bug tracker.  Perhaps we should create
a separate bug level (packaging-bug?) for them, if this crops up enough.

Probably MacOS falls in the same category, although there seem to be more
MacOS-using darcs developers, so it's less challenging than Windows.

In the worst-case scenario, if there's a packaging bug that is reported on
the tracker that doesn't get fixed and the packager is MIA, we can define
the bug as a bug in the wiki, and can close the bug by removing the link to
that binary from the wiki (or just add a warning note of some sort).

> In this case, Rob Moss was in the system, so that was helpful.

Indeed.  And I greatly appreciate his help (as I'm sure Zooko does as
well).
-- 
David Roundy
Department of Physics
Oregon State University

On Jan 23, 2008, at 7:41 AM, Mark Stosberg wrote:

> In this case, Rob Moss was in the system, so that was helpful.

Yeah, let us please distinguish between "people who are using the  
shared development resources -- bug tracker, darcs repo, wiki, unit  
tests -- to improve the usability of darcs" vs. "people who are not  
looking at the bug tracker" instead of between "packaging" vs. "core".

Regards,

Zooko

On Wed, Jan 23, 2008, David Roundy <bugs@darcs.net> said:

> On Wed, Jan 23, 2008 at 01:50:42PM -0000, Zooko wrote:
>> The exit code was 53.  Dependency Walker (thanks for the suggestion, Simon
>> Marlow) says that ZLIB1.DLL, EFSADU.DLL and MSJAVA.DLL are not found when
>> inspecting darcs_2008-01-19.exe -- the one that doesn't work.  When inspecting
>> darcs_2008-01-16.exe -- the one that works -- it says only that efsadu.dll and
>> msjava.dll are not found.  That's a relief -- for a minute there I was afraid
>> that MSJAVA.DLL was required...  ;-)
> 
> So it sounds like zlib is dynamically linked in the latest windows binary,
> and that's what's causing the trouble? That sounds like something that
> ought to be easily fixable just by statically linking with zlib.  :)
> 
> (And yes, before I finished reading your email, I also had already freaked
> out about why MSJABA.DLL was required...)

I compiled the latest windows build on a second computer that I thought
was configured identically to mine, but I suppose there must have been a
difference that caused zlib to become linked dynamically. I'll compile a
new build on my computer in the next day or so.

I don't know why MSJAVA.DLL and EFSADU.DLL are showing up (according to
google, EFSADU has to do with file encryption?!?). I'm sorry to reply to
everything with "I don't know", but my windows experience is limited to
writing relatively
simple OCaml and Python programs where compilation is a breeze.

cheers,
Rob

A new build is available.

Considering this resolved based on the new build. Re-open if there is a problem.