darcs

Issue 2591 latin9-input regressions on Windows in darcs 2.14

Title latin9-input regressions on Windows in darcs 2.14
Priority Status unknown
Milestone Resolved in
Superseder Nosy List ganesh
Assigned To
Topics

Created on 2018-06-17.16:57:55 by ganesh, last changed 2018-07-13.19:27:48 by bf.

Messages
msg20164 (view) Author: ganesh Date: 2018-06-17.16:57:53
As a result of the encoding changes in Darcs 2.14, which makes 
encoding behaviour much better on Linux, there have been some 
regressions in encoding behaviour on Windows (which probably didn't 
work that well anyway before). See patch1628 for some comments.

This is different to issue2590, which describes encoding problems on 
Windows which aren't a regression.
msg20185 (view) Author: bf Date: 2018-07-13.19:01:37
Ganesh, could you describe in details what exactly fails? It might give
me a hint what goes wrong and possible avenues for fixes.
msg20186 (view) Author: bf Date: 2018-07-13.19:27:46
Looking at your patch1683, it occurred to me that the Windows
implementation of decode probably fails unless the input ByteString is
in a valid unicode encoding, which excludes 8-bit encodings such as the
varuious ISO latin variants.

What exactly is build failure you fixed with patch1683?

I see (now) that GHC.IO.Encoding warns about portability issues. In
particular, it tells us that the //ROUNDTRIP encoding fails to work if
the input ByteString is in UTF-16, which seems to be the case on
(modern) Windows based on the code in src/Darcs/Util/Encoding/Win32.hs

So the code there is incorrect if the user reconfigures the system to
use an 8-bit encoding. On the other hand, the code based on
GHC.IO.Encoding should work in this case. So it would be interesting to
know why it doesn't compile.
History
Date User Action Args
2018-06-17 16:57:55ganeshcreate
2018-07-13 19:01:38bfsetmessages: + msg20185
2018-07-13 19:27:48bfsetmessages: + msg20186