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

patch ffe1ef35050722f3716909e9033d60b15f9e3916
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Mar 13 12:06:33 CET 2018
  * make readTextFile strict in the content by splitting it into lines
  
  We want to be able to write a changed version of the file without worrying
  about failures due to semiopen files. (I have observed occasional but hard
  to reproduce test failures with the previous lazy version.) Since text
files
  are processed line-wise anyway (in the few places where we use
  readTextFile), this is a cheap and reliable solution.

Attachments

• make-readtextfile-strict-in-the-content-by-splitting-it-into-lines.dpatch

The changes are correct and the code looks better, I just do not see how
splitting file contents into lines makes file reading strict?

Oops. Good catch. Indeed, the new readTextFile isn't any stricter than
the old version. Reasoning about strictness is... difficult.

Why did the patch seem solve the problem I observed? I have no idea.

Attached is a follow-up patch that really makes it strict this time. I
hope ;-)

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

patch 1f3bd44d17c27deffcdb45a7b2ac353d70e24da0
Author: Ben Franksen <ben.franksen@online.de>
Date:   Sat Mar 24 18:58:18 CET 2018
  * really make readTextFile strict

Attachments

• really-make-readtextfile-strict.dpatch

I should refrain from sending untested patch bundles. In the last one I
forgot to take into account that 'last' is a partial function! Oh my...

Okay, here's another bundle. Tested it this time.

Attachments

• really-make-readtextfile-strict.dpatch

I was about to ask you why not use something like System.IO.Strict, but
then I investigated a little and found that that library uses sep +
length anyway. I'm accepting the bundle.

Yes, I looked at the strict package and found the same as you did...

Can the same function be used in Darcs.UI.Commands.ShowAuthor instead of
Ratified.readFile ?

Also I would just go ahead and nuke that Ratified module, along with
contrib/darcs-errors.hlint . The idea is to suppress hlint Errors like
"avoid hGetContents" and "avoid Prelude.readFilen", but hlint is
currently throwing 10.000 warnings, and there is probably no general
rule of which ones to silent.

Maybe it would be better to comment the places where we use these
functions and say why file contents is guaranteed to be consumed in each
case.

Please don't nuke Ratified for now, I have a pending patch where I want 
to use it.

> Can the same function be used in Darcs.UI.Commands.ShowAuthor instead
> of Ratified.readFile ?

Done, see attached follow-up bundle:

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

patch fa2350acc56b76be6994487dd4c8cce1793fd5f3
Author: Ben Franksen <ben.franksen@online.de>
Date:   Wed Mar 28 08:12:59 CEST 2018
  * use Darcs.Util.Lock.readTextFile for .authorspellings
  
  Also, use catchIOError to catch IO errors when reading the file.

Attachments

• use-darcs_util_lock_readtextfile-for-_authorspellings.dpatch

OK good, accepted.

> Please don't nuke Ratified for now, I have a pending patch where I want
> to use it.

Alright :)