Changes related to the Name type in Darcs.Util.Path. The main one here is to
use ShortByteString, which should reduce memory consumption.

4 patches for repository https://darcs.net/screened:

patch 34012b0f3c3fec83b3d4e851f4a4bec3dbc42ea7
Author: Ben Franksen <ben.franksen@online.de>
Date:   Sun Apr 23 18:37:23 CEST 2023
  * document Name and turn unName from record accessor to a separate function

  This makes the derived Show instance less verbose, which is helpful when
  debugging failing test cases.

patch 22b35c6b822281bea274838a96d5fdbc37c9d24e
Author: Ben Franksen <ben.franksen@online.de>
Date:   Fri May 12 11:36:46 CEST 2023
  * use ShortByteString for Name (and thus AnchoredPath)

  This is the minimum necessary change that keeps the external API as is.

patch e4f4f99cd9e24818a2099eca454f15400bcb2a9d
Author: Ben Franksen <ben.franksen@online.de>
Date:   Sat May 13 08:20:54 CEST 2023
  * remove unused name2fp

patch b340726142282fa5a084d5558241580d0fb28789
Author: Ben Franksen <ben.franksen@online.de>
Date:   Sat May 13 08:36:08 CEST 2023
  * optimize eqAnycase

Attachments

• document-name-and-turn-unname-from-record-accessor-to-a-separate-function.dpatch
• patch-preview.txt

Follow-up

1 patch for repository /home/franksen/src/darcs/bla:

patch d56aa483b47935dda652c07d756835d20cb8f1aa
Author: Ben Franksen <ben.franksen@online.de>
Date:   Mon Dec 16 20:22:31 CET 2024
  * fix: require bytestring >= 0.11.3.0

  Earlier versions don't export Data.ByteString.Short.map. This fixes building with
  ghc < 9.2, after being broken by

  patch 22b35c6b822281bea274838a96d5fdbc37c9d24e
  Author: Ben Franksen <ben.franksen@online.de>
  Date:   Fri May 12 11:36:46 CEST 2023
    * use ShortByteString for Name (and thus AnchoredPath)

Attachments

• fix_-require-bytestring-__-0_11_3_0.dpatch
• patch-preview.txt

Looks good.

>   * optimize eqAnycase

Reading this made me realise that our code won't spot case-insensitive 
clashes between non-ASCII characters (both before and after this
patch). I have no idea how case-insensitive filesystems handle that
either.

> Reading this made me realise that our code won't spot case-insensitive 
> clashes between non-ASCII characters (both before and after this
> patch). I have no idea how case-insensitive filesystems handle that either.

The most interesting candidate here would be Windows' NTFS. According to the 
internet resources I could find, it uses a sequence of 16-bit values for file 
names. It supports, but does NOT require or enforce, UTF-16 encoding. I could 
not find any precise specification of case insensitive semantics. Perhaps they 
case-normalize using the standard unicode semantics /if/ the full name is valid 
UTF-16 (and do not normalize otherwise). Or perhaps they they use unicode case 
rules for valid 16-bit UTF-16 code points (and the literal values for those 
which are not). I guess one would have to do experiments to find out the 
details. I guess there are still these things they call "code pages" around 
which may influence this or not.