Issue 2591 latin9-input regressions on Windows in darcs 2.14

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

Created on 2018-06-17.16:57:55 by ganesh, last changed 2022-04-12.13:51:51 by bfrk.

File name Uploaded Type Edit Remove
rollback-patch1683-build-failure.txt ganesh, 2020-07-26.16:00:14 text/plain
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: bfrk 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: bfrk 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.
msg22262 (view) Author: ganesh Date: 2020-07-26.16:00:14
Somewhat belatedly, I'm attaching the build failure I get if I rollback
patch1683. (Surprisingly it's still undepended-on, except by tags)

I think the code it was fixing was just broken - with WIN32 defined, 
encode/decode were only being imported qualified, and
encodeUtf8/decodeUtf8 weren't defined at all, yet all were exported.
Date User Action Args
2018-06-17 16:57:55ganeshcreate
2018-07-13 19:01:38bfrksetmessages: + msg20185
2018-07-13 19:27:48bfrksetmessages: + msg20186
2020-07-26 16:00:17ganeshsetfiles: + rollback-patch1683-build-failure.txt
messages: + msg22262
2022-04-12 13:51:51bfrksetpriority: bug