See mailing list archives
for discussion on individual patches.
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.
|
|
Date |
User |
Action |
Args |
2017-08-31 21:16:57 | gh | create | |
2017-08-31 21:39:02 | gh | set | files:
+ clean-up-display-of-file-names-by-separating-display-and-storage-of-patches.dpatch messages:
+ msg19636 |
2017-09-01 06:09:38 | ganesh | set | messages:
+ msg19637 |
2017-09-01 12:52:09 | gh | set | messages:
+ msg19638 |
2017-09-02 09:02:39 | bfrk | set | messages:
+ msg19641 |
2017-09-23 12:23:16 | bfrk | set | files:
+ clean-up-display-of-file-names-by-separating-display-and-storage-of-patches.dpatch messages:
+ msg19664 |
2017-09-23 21:03:56 | ganesh | set | messages:
+ msg19668 |
2017-09-23 21:59:40 | bfrk | set | messages:
+ msg19669 |
2017-09-23 22:03:44 | bfrk | set | files:
+ clean-up-display-of-file-names-by-separating-display-and-storage-of-patches.dpatch messages:
+ msg19670 |
2017-09-24 15:45:56 | bfrk | set | messages:
+ msg19671 |
2017-09-24 15:46:59 | bfrk | set | files:
+ clean-up-display-of-file-names-by-separating-display-and-storage-of-patches.dpatch messages:
+ msg19672 |
2017-09-24 16:06:48 | bfrk | set | messages:
+ msg19673 |
2017-09-30 21:22:32 | ganesh | set | messages:
+ msg19674 |
2017-09-30 21:28:32 | ganesh | set | messages:
+ msg19675 |
2017-10-01 17:05:00 | bfrk | set | messages:
+ msg19680 |
2017-10-02 07:50:03 | bfrk | set | files:
+ clean-up-display-of-file-names-by-separating-display-and-storage-of-patches.dpatch messages:
+ msg19681 |
2017-10-02 07:52:01 | bfrk | set | status: needs-screening -> needs-review messages:
+ msg19682 |
2017-10-03 14:43:19 | bfrk | set | title: 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:54 | gh | set | files:
+ delete-commented-code.dpatch messages:
+ msg19689 |
2017-10-03 14:49:07 | gh | set | status: needs-review -> accepted messages:
+ msg19690 |