darcs

Patch 1292 fixed failing fromJust in look-for-replaces implementa...

Title fixed failing fromJust in look-for-replaces implementa...
Superseder Nosy List bfrk
Related Issues
Status accepted Assigned To
Milestone

Created on 2015-02-19.23:15:24 by bfrk, last changed 2015-02-22.01:19:06 by gh.

Files
File name Status Uploaded Type Edit Remove
fixed-failing-fromjust-in-look_for_replaces-implementation.dpatch bfrk, 2015-02-19.23:15:24 application/x-darcs-patch
patch-preview.txt bfrk, 2015-02-19.23:15:24 text/x-darcs-patch
unnamed bfrk, 2015-02-19.23:15:24
See mailing list archives for discussion on individual patches.
Messages
msg18176 (view) Author: bfrk Date: 2015-02-19.23:15:24
obsoletes patch1286

1 patch for repository http://darcs.net/screened:

patch 726c9d59d45aa80b92e755c3943c0d2d3e55f928
Author: Ben Franksen <benjamin.franksen@helmholtz-berlin.de>
Date:   Fri Feb 20 00:12:22 CET 2015
  * fixed failing fromJust in look-for-replaces implementation
  
  As indicated in a comment in the code, the solution is not perfect. We
  really want to fuse the expandPath with the findFile. But how to achieve
  that without bloating the API of hashed-storage needs more thought.
Attachments
msg18186 (view) Author: gh Date: 2015-02-20.13:52:53
What situation can trigger the bug fixed by this patch?
msg18189 (view) Author: bfrk Date: 2015-02-20.17:09:15
See msg18161 in reply to issue2410.
msg18192 (view) Author: gh Date: 2015-02-20.17:21:18
I was thinking more about a minimal testcase because I don't
understand the code that fixes the bug.

I wanted to reproduce the issue with a replace inside of a file that
is not at the root of the working tree, but it seems that the problem
is elsewhere.
msg18193 (view) Author: bfrk Date: 2015-02-20.17:35:50
Sorry, I have no minimal test case. I can only try to explain what goes
on: IIUC the tree can contain so called Stub items. These represent
"holes" in the tree where we should expect a file or a subtree, but the
irem has not yet been read from disc. This is an optimization which
allows us to operate on parts of a tree without reading all of it in
memory. The findFile function returns Nothing id it hits a Stub. So what
we do is to expand everything in the tree which lies on the given path
(replacing Stubs with what is actually there).

In order to create a minimal example, one would need to find out which
of the hashed-storage functions called here create such a "partially
evaluated" tree (i.e. one with stubs in it) and study which
side-conditions exactly trigger this optimization.
msg18206 (view) Author: gh Date: 2015-02-22.01:19:05
With your explanation and the comment inside of the patch I believe the
code makes sense.

I think it's good enough to go in, when we want to optimize it we'll do
it. Accepted.
History
Date User Action Args
2015-02-19 23:15:24bfrkcreate
2015-02-19 23:15:59bfrklinkpatch1286 superseder
2015-02-20 13:52:53ghsetmessages: + msg18186
2015-02-20 17:09:15bfrksetmessages: + msg18189
2015-02-20 17:16:34bfrksetstatus: needs-screening -> obsoleted
superseder: + adding -K option to less fixes "leaking last line" aft...
2015-02-20 17:19:47bfrksetstatus: obsoleted -> (no value)
superseder: - adding -K option to less fixes "leaking last line" aft...
2015-02-20 17:21:18ghsetmessages: + msg18192
2015-02-20 17:35:51bfrksetmessages: + msg18193
2015-02-20 17:36:50bfrksetstatus: needs-screening
2015-02-22 01:19:06ghsetstatus: needs-screening -> accepted
messages: + msg18206