From: Anthony Cowley <acowley@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] org-latex-compile timestamp checks
Date: Sat, 16 Jan 2016 18:21:30 -0500 [thread overview]
Message-ID: <DA9F0E42-3A84-42C4-8CF2-BA6C184E12B3@gmail.com> (raw)
In-Reply-To: <87vb6tblkr.fsf@gmx.us>
[-- Attachment #1: Type: text/plain, Size: 3471 bytes --]
> On Jan 16, 2016, at 10:17 AM, Rasmus <rasmus@gmx.us> wrote:
>
> Hi Anthony and Nicolas,
>
> Anthony Cowley <acowley@gmail.com> writes:
>
>> 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.
>
> Thanks for carefully explaining exactly what is going on here.
>
>> 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.
>
> I think the approach is fine now. See below.
>
>>> 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.
>
> Actually, it's part of cl-lib now (in the broadest understanding of
> cl-lib).
>
> Since this is a bugfix I guess you should use org-sublist (*shiver*) in
> maint and cl-subseq in master. We can’t use cl-lib in maint, right
> Nicolas?
>
> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> Anthony Cowley <acowley@gmail.com> writes:
>>
>>> * 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)))
>>
>> This sounds good. Thank you.
>>
>> Although, I suggest to use `cl-subseq' instead of its alias. Also, it
>> may be worth commenting that trick right into the source.
>
> Yes, it should.
I’ve attached two remixes of the original patch: the first uses cl-subseq, the second uses org-sublist.
Anthony
[-- Attachment #2: ox-latex-timestamp.patch --]
[-- Type: application/octet-stream, Size: 1607 bytes --]
From 8e152704e3b0a3cc31ef46d31e32c7b914fd4401 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 | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index a57677b..eb1ba6c 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3576,7 +3576,10 @@ 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))
+ ;; Only compare times up to whole seconds as some filesystems
+ ;; (e.g. HFS+) do not retain any finer granularity.
+ (time-less-p (cl-subseq (nth 5 (file-attributes pdffile)) 0 2)
+ (cl-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
[-- Attachment #3: ox-latex-timestamp-maint.patch --]
[-- Type: application/octet-stream, Size: 1611 bytes --]
From 9275fd16c8ec51702a63bfc3e8e736bb787b624c 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 | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index a57677b..848fe3a 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3576,7 +3576,10 @@ 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))
+ ;; Only compare times up to whole seconds as some filesystems
+ ;; (e.g. HFS+) do not retain any finer granularity.
+ (time-less-p (org-sublist (nth 5 (file-attributes pdffile)) 1 2)
+ (org-sublist time 1 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
next prev parent reply other threads:[~2016-01-16 23:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-14 23:24 [PATCH] org-latex-compile timestamp checks Anthony Cowley
2016-01-15 12:13 ` Rasmus
2016-01-15 20:34 ` Anthony Cowley
2016-01-16 14:16 ` Nicolas Goaziou
2016-01-16 15:17 ` Rasmus
2016-01-16 23:21 ` Anthony Cowley [this message]
2016-01-21 9:54 ` Nicolas Goaziou
2016-01-21 15:53 ` Rasmus
2016-01-26 19:56 ` Anthony Cowley
2016-01-26 22:14 ` Rasmus
2016-01-26 22:20 ` Nicolas Goaziou
2016-01-26 22:25 ` Rasmus
2016-01-28 9:05 ` Nicolas Goaziou
2016-01-28 10:10 ` Rasmus
2016-01-28 15:48 ` Anthony Cowley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DA9F0E42-3A84-42C4-8CF2-BA6C184E12B3@gmail.com \
--to=acowley@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).