Re: [PATCH] org-latex-compile timestamp checks

[Anthony Cowley <acowley@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2282 bytes --]


> On Jan 15, 2016, at 7:13 AM, Rasmus <rasmus@gmx.us> wrote:
> 
> Hi Anthony,
> 
> Thanks for raising this issue.
> 
> Anthony Cowley <acowley@gmail.com> writes:
> 
>> I’ve had some trouble with toggling latex fragment previews in a
>> document on OS X. It would sometimes work, sometimes not, so I could
>> just try a few times until it worked and get on with things. Looking
>> into it more, the problem seems to be with the HFS+ filesystem’s
>> second granularity on file timestamps. The Org code checks that the
>> generated file is not older than a (current-time) obtained before
>> starting latex compilation, but the truncated time of the generated
>> file can indeed be older in the sub-second fields of the timestamp.
>> 
>> The attached patch simply compares timestamps truncated to 1-second
>> precision.
> 
> Isn't this a bug in Emacs file-attributes rather than Org?  If so, it
> should be fixed in Emacs rather than worked around in Org IMO.


Thanks for taking a look, Rasmus! The bug is in Org, not Emacs. One may perhaps assume the invariant that successive calls to `current-time` will return non-decreasing values. One might also assume the invariant that successive touches of different files will result in file attributes with non-decreasing timestamps. It is mixing the two that is the bug, and Emacs itself shouldn’t try to fix that. To be clear, the limiting factor in this comparison is the filesystem whose timestamp granularity is much coarser than the system clock.

We could do something like generate an entirely separate temporary file before compilation, and use its timestamp as the reference by which compilation output is evaluated. However, the approach of checking file freshness with a one-second granularity seems like a pretty good compromise.

> 
> Maybe you could just check the log directly for failures rather than
> checking the file attributes, if these are not reliable.
> 
> Also, what is the ‘take‘?  I don’t seem to have it in my Emacs…

Sorry about that. Believe it or not I had already rewritten those two lines — as simple as they are — trying to not include extra dependencies. I’ve attached an updated patch that uses subseq from cl.el. I hope that is okay.

Anthony

[-- Attachment #2: 0001-lisp-ox-latex.el-PDF-generation-timestamp-check.patch --]
[-- Type: application/octet-stream, Size: 1476 bytes --]

From d7960187c9b4be87ac8811810da3bb500837018c Mon Sep 17 00:00:00 2001
From: Anthony Cowley <acowley@gmail.com>
Date: Thu, 14 Jan 2016 18:13:45 -0500
Subject: [PATCH] lisp/ox-latex.el: PDF generation timestamp check

* lisp/ox-latex.el (org-latex-compile): Improve timestamp check on HFS+
  filesystem by only considering 1-second clock resolution.

Previously, the call to (current-time) could return a timestamp with
a non-zero microsecond or picosecond fields, while the file attribute
always has zeros for these fields. The check that the generated file is
newer than the reference timestamp only succeeded when the time to
generate the file crossed a 1-second clock interval.

TINYCHANGE
---
 lisp/ox-latex.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index a57677b..f803b7e 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3576,7 +3576,8 @@ Return PDF file name or an error if it couldn't be produced."
 	;; Check for process failure.  Provide collected errors if
 	;; possible.
 	(if (or (not (file-exists-p pdffile))
-		(time-less-p (nth 5 (file-attributes pdffile)) time))
+		(time-less-p (subseq (nth 5 (file-attributes pdffile)) 0 2)
+			     (subseq time 0 2)))
 	    (error (format "PDF file %s wasn't produced" pdffile))
 	  ;; Else remove log files, when specified, and signal end of
 	  ;; process to user, along with any error encountered.
-- 
2.6.4