darcs

Patch 1593 clean up display of file names by separating display and storage of patches

Title clean up display of file names by separating display and storage of patches
Superseder Nosy List gh
Related Issues
Status accepted Assigned To
Milestone

Created on 2017-08-31.21:16:57 by gh, last changed 2017-10-03.14:49:07 by gh.

Files
File name Status Uploaded Type Edit Remove
clean-up-display-of-file-names-by-separating-display-and-storage-of-patches.dpatch gh, 2017-08-31.21:16:55 application/octet-stream
clean-up-display-of-file-names-by-separating-display-and-storage-of-patches.dpatch gh, 2017-08-31.21:39:02 application/octet-stream
clean-up-display-of-file-names-by-separating-display-and-storage-of-patches.dpatch bfrk, 2017-09-23.12:23:15 application/x-darcs-patch
clean-up-display-of-file-names-by-separating-display-and-storage-of-patches.dpatch bfrk, 2017-09-23.22:03:43 application/x-darcs-patch
clean-up-display-of-file-names-by-separating-display-and-storage-of-patches.dpatch bfrk, 2017-09-24.15:46:59 application/x-darcs-patch
clean-up-display-of-file-names-by-separating-display-and-storage-of-patches.dpatch bfrk, 2017-10-02.07:50:02 application/x-darcs-patch
delete-commented-code.dpatch gh, 2017-10-03.14:47:54 application/octet-stream
See mailing list archives for discussion on individual patches.
Messages
msg19635 (view) Author: gh Date: 2017-08-31.21:16:55
These are the last 2 patches from Ben's darcs-encoding branch, the other
ones are at http://bugs.darcs.net/patch1592 .

They apply cleanly on HEAD and all tests pass (wiht darcs1 and darcs2
repositories).

Note that the issue raised by Ben in his mail [1] are created by the
first patch below.

[1] https://lists.osuosl.org/pipermail/darcs-devel/2017-May/018016.html

2 patches for repository http://darcs.net:

patch 0b44fbb1718bbb2b61724fc9eeed3ae2f4ebd583
Author: Ben Franksen <ben.franksen@online.de>
Date:   Thu Aug 31 17:17:28 -03 2017
  * clean up display of file names by separating display and storage of
patches

  Darcs has always used the same code to serialize patches for storage
on disk
  and for displaying them to the user. This makes sense in terms of code
  economy but until now led to strange issues when displaying non-ASCII
  filenames.

  This patch makes a few small changes at the bottom of the hierarchy of
  classes that make up the Patch API, but these small changes necessitate
  rather deep and far-reaching changes in many other places.

  The first change is to add a second parameter to showPatch and
  showContextPatch to indicate the intended use (ForDisplay |
ForStorage). The
  correct value for this parameter must be added everywhere these functions
  are used, which is tedious but mostly trivial.

  The second is to remove the instances of Darcs.Patch.Prim.V1.Prim for
  ShowPatchBasic and ShowPatch. The reason is that the Prim patch type is
  shared (as a type parameter) between RepoPatchV1 and RepoPatchV2, so it
  *cannot* know which file name encoding to use for storage. (This is why
  there are PrimShow and PrimRead classes that get the file name format
passed
  as a parameter.) Nevertheless, we *need* primitive patches to implement
  these classes! Half of the rest of the darcs code and large parts of the
  test harness rely on prim patches having the same API as full repo
patches.

  The dilemma is solved by adding yet another layer of types: V1 and V2 now
  each define their own newtype wrapper for the shared Prim type. This
wrapper
  has knowledge about how to render file names (and also patch lists) in the
  correct format and thus can implement ShowPatchBasic, ShowPatch, and
the now
  separate ShowContextPatch classes. This is the type that is now
returned by
  the PrimOf type function.

  Incidentally, this patch fixes a failure for darcs1 format of
  issue2382-mv-dir-to-file-confuses-darcs.sh that was causes by the
output of
  darcs record adding (legacy) braces around patch lists for display. We now
  use the ListFormatDefault (no braces) for all display so this problem just
  vanished. Similarly, the peculiar darcs-specific "white space
encoding" for
  filenames is now strictly limited to the on-disk format of patches
  (including patch bundles) and inventories and no longer affects the UI.

patch 1fe1c8617a2b6c8bc753f4baa3033168163ad3ae
Author: Ben Franksen <ben.franksen@online.de>
Date:   Thu Aug 31 17:20:21 -03 2017
  * use formatFileName UserFormat in Darcs.Patch.Summary
Attachments
msg19636 (view) Author: gh Date: 2017-08-31.21:39:02
Fixing a warning (anyway the test harness code has warnings because of
the commented code that Ben mentionned in his mail).
Attachments
msg19637 (view) Author: ganesh Date: 2017-09-01.06:09:37
I guess you didn't manage to fix the qc_prim test? I spent a while 
trying to do that a few months ago and failed, and I had the feeling 
it indicated a more serious issue with the new type structure.

Sorry for never writing those experiments up, I'll try to do so in 
the next couple of days. I was leaning towards just adding the extra 
parameter to the existing classes, and ignoring it in some cases, 
ugly though that is.
msg19638 (view) Author: gh Date: 2017-09-01.12:52:08
Hi Ganesh,

I have not even tried, in fact. This bundle is just the result of
porting the original patches to screened (and compiling with ghc 8.2 and
cabal 2).

Indeed I have not screened the bundle, since the changes may not be the
ones that we want.
msg19641 (view) Author: bfrk Date: 2017-09-02.09:02:38
Ganesh: Yes, the qc_prim tests are the problem.

Can you perhaps elaborate what you meant with "just adding the extra
parameter to the existing classes, and ignoring it in some cases"? Are
you referring to the test code or to an alternative solution to the
problem that printing V1 primitive patches depends on the context i.e.
higher level patch type?

The extra newtype layer I added around V1 prim patches indeed makes the
typing even more complicated than it already is. On the other hand,
adapting the actual darcs code wasn't that difficult; the typing here
actually helped.

The test suite is another matter, though. IMO it is based to much on
overloading and type families, which is why it is so hard to get the
typing right. I also find the test code very hard to understand.
msg19664 (view) Author: bfrk Date: 2017-09-23.12:23:15
This is new version that incorporates the ideas I wrote about on the
mailing list
(https://lists.osuosl.org/pipermail/darcs-devel/2017-September/018219.html).

In particular: PrimPatchRaw and all related functions have been removed.
RepoPatchV1 and V2 take the final (wrapped) prim as type parameter and
no longer need to know anything about the share Prim.V1 type.

This simplified everything considerably! I could easily convert all test
code in less than one day's work. All tests passed the first time I got
the test suite to compile.

The patch is now smaller and (I think) easier to review.
Attachments
msg19668 (view) Author: ganesh Date: 2017-09-23.21:03:55
Just to check - from a quick look, the patch you've attached is dated 
August 31st, still talks about a new layer in the description, and 
introduces a Prim.V2 patch type. Is that the one you intended to 
attach?
msg19669 (view) Author: bfrk Date: 2017-09-23.21:59:40
This bundle adds another three patches that further simplify the
wrappers and also their use. They no longer take the common base type as
parameter, instead it is baked directly into V1.Prim and V2.Prim.
msg19670 (view) Author: bfrk Date: 2017-09-23.22:03:43
sorry, forgot to attach the undle, here goes
Attachments
msg19671 (view) Author: bfrk Date: 2017-09-24.15:45:56
Same bundle but with an additional bug fix for the test suite.
msg19672 (view) Author: bfrk Date: 2017-09-24.15:46:59
Grrr, again forgot to attach the bundle. Here it is.
Attachments
msg19673 (view) Author: bfrk Date: 2017-09-24.16:06:48
Ganesh: It is an amended version of my earlier patch, with the same date
and comment. I merely removed the PrimPatchRaw complication. Take a look
at the latest version here, I think it is no longer too heavy-weight for
what it achieves. Using newtype wrappers to guide instance selection is
a standard technique in modern Haskell. The implementation of the
wrappers themselves is almost trivial (thanks to
GeneralizedNewtypeDeriving). The only really ugly thing is that we must
repeat all the instances in harness/Darcs/Test/Patch/Arbitrary/PrimV1.hs
for both types of Prim.V1 patches.
msg19674 (view) Author: ganesh Date: 2017-09-30.21:22:30
Sorry for being slow (again). I've had a look through and I agree it 
seems like a reasonable approach - there's much less extra machinery 
needed than before and it's not too hard to follow.
msg19675 (view) Author: ganesh Date: 2017-09-30.21:28:32
One other thought - with your final design, do we need wrappers for 
both V1 and V2? Could we treat one as a legacy case requiring a wrapper 
and the other as a simpler/more standard one?
msg19680 (view) Author: bfrk Date: 2017-10-01.17:04:59
> Could we treat one as a legacy case requiring a wrapper 
> and the other as a simpler/more standard one?

I think it would be possible to do that. Indeed, the idea is tempting.
However, this is no small refactoring in itself. It raises a number of
design questions: What to do with PrimRead and PrimShow classes when we
do that? What to do with the FileFormat and PatchListFormat types? I
don't have the head for these questions at the moment, since I have so
many other patches in my queue (some of them not yet in code but only in
my head).

There is nothing stopping anyone from doing another refactor along these
lines after this patch is screened, which is what I am going to do now
(though I may rebase it once more before I do that).
msg19681 (view) Author: bfrk Date: 2017-10-02.07:50:02
Hopefully the last version. I amended everything into a single patch and
also added some small fixes. Also, added class IsPrimV1 to
Darcs.Repository.Job and constrain PrimV1Job with it in order to support
the way darcsden wants access to prim patch details.
Attachments
msg19682 (view) Author: bfrk Date: 2017-10-02.07:52:01
Finally screening this one, yay!
msg19689 (view) Author: gh Date: 2017-10-03.14:47:54
I went ahead and wrote the patch (the queue of patches in screened is
getting bigger ,we need to process it more). from Ganesh's comments I
think it is safe to accept the bundle. Congratulations \o/
Attachments
msg19690 (view) Author: gh Date: 2017-10-03.14:49:04
Oh well, Ignore my patch :D
Ben has pushed his own version to screened before me. Now I'm pushing
them to reviewed.
History
Date User Action Args
2017-08-31 21:16:57ghcreate
2017-08-31 21:39:02ghsetfiles: + clean-up-display-of-file-names-by-separating-display-and-storage-of-patches.dpatch
messages: + msg19636
2017-09-01 06:09:38ganeshsetmessages: + msg19637
2017-09-01 12:52:09ghsetmessages: + msg19638
2017-09-02 09:02:39bfrksetmessages: + msg19641
2017-09-23 12:23:16bfrksetfiles: + clean-up-display-of-file-names-by-separating-display-and-storage-of-patches.dpatch
messages: + msg19664
2017-09-23 21:03:56ganeshsetmessages: + msg19668
2017-09-23 21:59:40bfrksetmessages: + msg19669
2017-09-23 22:03:44bfrksetfiles: + clean-up-display-of-file-names-by-separating-display-and-storage-of-patches.dpatch
messages: + msg19670
2017-09-24 15:45:56bfrksetmessages: + msg19671
2017-09-24 15:46:59bfrksetfiles: + clean-up-display-of-file-names-by-separating-display-and-storage-of-patches.dpatch
messages: + msg19672
2017-09-24 16:06:48bfrksetmessages: + msg19673
2017-09-30 21:22:32ganeshsetmessages: + msg19674
2017-09-30 21:28:32ganeshsetmessages: + msg19675
2017-10-01 17:05:00bfrksetmessages: + msg19680
2017-10-02 07:50:03bfrksetfiles: + clean-up-display-of-file-names-by-separating-display-and-storage-of-patches.dpatch
messages: + msg19681
2017-10-02 07:52:01bfrksetstatus: needs-screening -> needs-review
messages: + msg19682
2017-10-03 14:43:19bfrksettitle: clean up display of file names by separating display and storage of patches (rebased from Ben's encoding branch) -> clean up display of file names by separating display and storage of patches
2017-10-03 14:47:54ghsetfiles: + delete-commented-code.dpatch
messages: + msg19689
2017-10-03 14:49:07ghsetstatus: needs-review -> accepted
messages: + msg19690