From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rasmus Subject: Re: [PATCH] org-latex-compile timestamp checks Date: Sat, 16 Jan 2016 16:17:24 +0100 Message-ID: <87vb6tblkr.fsf@gmx.us> References: <57F8EBE2-E535-423A-828B-BCB3A2B9F797@gmail.com> <87r3hjf3b9.fsf@gmx.us> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51235) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aKSbh-0005Yf-Cc for emacs-orgmode@gnu.org; Sat, 16 Jan 2016 10:17:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aKSbd-0002BO-Ut for emacs-orgmode@gnu.org; Sat, 16 Jan 2016 10:17:37 -0500 Received: from plane.gmane.org ([80.91.229.3]:37696) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aKSbd-0002BK-Jf for emacs-orgmode@gnu.org; Sat, 16 Jan 2016 10:17:33 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aKSbb-0005K1-SI for emacs-orgmode@gnu.org; Sat, 16 Jan 2016 16:17:31 +0100 Received: from x590c5a26.dyn.telefonica.de ([89.12.90.38]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Jan 2016 16:17:31 +0100 Received: from rasmus by x590c5a26.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Jan 2016 16:17:31 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Hi Anthony and Nicolas, Anthony Cowley 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 writes: > Anthony Cowley 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. > Eventually, I think at least ox-texinfo.el, ox-man.el and ox-groff.el > need a similar trick. Perhaps there should be an error check in ox-odt as well? I guess the only thing that could happen is that the zip/odt can’t be written, which could happen if it’s open in windows, which is extremely picky with locked files. [I have had to use a windows machine at work]. > Rasmus, what do you think? I looked at the source, and in the case of ox-latex.el it looks like we cannot log at the log as org-latex-pdf-process can be a function. As such I guess file time stamp is indeed a fine proxy. Thanks, Rasmus -- Spil noget med Slayer!