With darcs2 on Windows:

$ darcs2 get http://darcs.haskell.org/packages/ndp
Unapplicable patch:
Tue Mar 14 22:43:29 GMT Standard Time 2006  Manuel M T Chakravarty 
<chak@cse.unsw.edu.au>
   * Using GADTs as closed associated types

darcs failed:  binary patch to 
./Data/Array/Parallel/Monadic/test/unit/TestBUArr couldn't apply.

darcs1 can get this repository successfully. This is 100% reproducible.

I'll bet this a binary/text file issue, and I'll also bet it's the same bug 
that causes the unapplicable patches to RnPat.lhs/RnExpr.lhs in issue842. 
Maybe this smaller test case will help track it down?

Cheers,
	Simon

Thanks for the smaller example!  Assigning to myself to reproduce.

I can get that repository successfully under Linux, for what it's worth, but as
you point out, this is a Windows issue.

I can indeed reproduce this on Windows.
  
I've also done some sanity checks, like making sure the original binary is the
same across Windows/Linux.

For the interested, I've boiled this down to a patch bundle that adds and
removes a binary file from an empty repository.  Note that if I try to simplify
the patch further, it applies cleanly, so I just left it at the original
TestBUArr.  To test:

# works fine on Linux, not on Windows
mkdir foo; cd foo
bunzip2 addrm-binary-fail.dpatch.bz2
darcs init
darcs apply addrm-binary-fail.dpatch

David?  I'll be happy to help with any other testing.

Attachments

• addrm-binary-fail.dpatch.bz2

Simon: configuring with --disable-bytestring solves this problem (we had
re-enabled it by default because Gwern had fixed a bug... guess there is another)

Gwern: may I assign this to you (since this is bytestring-related)?  An
interesting clue is that it only breaks on Windows.  It may be worthwhile to
bring Don in on this too

David: if nobody can look into this, I guess we'll have to disable bytestring by
defaul again (grumble)

Attached is a minimal example that works either on Linux (presumably) or without
bytestring, but not on Windows-with-bytestring.  We should find a good way to
add it to the suite

Attachments

• MINIMAL-addrm-binary-fail.dpatch

I haven't investigated the actual problem, but looking at FastPackedString.hs,
it says

writeFilePS :: FilePath -> PackedString -> IO ()
writeFilePS = B.writeFile

where B is Data.ByteString.Char8, which defines

writeFile :: FilePath -> ByteString -> IO ()
writeFile f txt = bracket (openFile f WriteMode) hClose
    (\h -> hPut h txt)

I assume you want Data.ByteString's

writeFile :: FilePath -> ByteString -> IO ()
writeFile f txt = bracket (openBinaryFile f WriteMode) hClose
    (\h -> hPut h txt)

(and in general want to be using Data.ByteString for everything).

So, can we close this bug? It would seem Eric has tried Igloo's suggestion.
Windows users, does it work now?

On a side note, why didn't the tests catch this?

---

Thu Jun 12 08:57:19 EDT 2008  Eric Kow <E.Y.Kow@brighton.ac.uk>
  * Resolve issue913: Use Data.Bytestring for IO, not Data.Bytestring.Char8
  
  This solution comes from Ian Lynagh, who points out that the
  difference between the two is:
  
  Data.Bytestring.Char8
  ---------------------
  writeFile :: FilePath -> ByteString -> IO ()
  writeFile f txt = bracket (openFile f WriteMode) hClose
     (\h -> hPut h txt)
  
  Data.Bytestring
  ---------------
  writeFile :: FilePath -> ByteString -> IO ()
  writeFile f txt = bracket (openBinaryFile f WriteMode) hClose
     (\h -> hPut h txt)
  
  We want this change because, as the System.IO docs say:
  
    On Windows, reading a file in text mode (which is the default) will
    translate CRLF to LF, and writing will translate LF to CRLF. This is
    usually what you want with text files. With binary files this is
    undesirable; also, as usual under Microsoft operating systems, text
    mode treats control-Z as EOF. Binary mode turns off all special
    treatment of end-of-line and end-of-file characters.

Hmm! It got pulled it, but for some reason the auto-resolver did not notice :-(

If you could submit a test for this [the binary patch issue], it would be great.
 I guess you would have to find a good way to create a binary file that has the
kind of sequence (presumably the bytes that happen to correspond to CRLF) that
make it fail