From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Leha Subject: Re: problems with export and :cache Date: Thu, 29 Oct 2015 14:58:30 +0000 Message-ID: References: <87vb9pyf0l.fsf@gmail.com> 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]:36861) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrofQ-000447-12 for emacs-orgmode@gnu.org; Thu, 29 Oct 2015 10:59:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZrofM-0000RB-Lk for emacs-orgmode@gnu.org; Thu, 29 Oct 2015 10:59:03 -0400 Received: from plane.gmane.org ([80.91.229.3]:48184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrofM-0000R7-BE for emacs-orgmode@gnu.org; Thu, 29 Oct 2015 10:59:00 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Zrof7-0000mJ-0V for emacs-orgmode@gnu.org; Thu, 29 Oct 2015 15:58:55 +0100 Received: from 193.63.222.227 ([193.63.222.227]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Oct 2015 15:58:44 +0100 Received: from andreas.leha by 193.63.222.227 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Oct 2015 15:58:44 +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 Aaron, Aaron Ecay writes: > Hi Andreas, > > 2015ko urriak 28an, Andreas Leha-ek idatzi zuen: >> >> Hi all, >> >> Andreas Leha writes: >>> Hi all, >>> >>> babel's :cache seems to be ignored during export. At least on #+call >>> lines. >>> >>> In the example below the caching works fine for interactive evaluation, >>> i.e. C-c C-c on the #+call line returns immediately. >>> >>> If I export the subtree with the #+call line, however, the code block >>> gets executed and the export is slow. > > Export works by making a copy of the org buffer, modifying it in some > ways while executing babel code, then exporting the modified buffer > copy. The modifications can under some circumstances change the > relevant features for the cache, leading to spurious re-evaluation. > > I tried to write a patch that would do the buffer modifications in such > a way that they would not affect the cache. But I was never happy with > the patch, and also could not find a nice simple test case for the > re-evaluation bug. So this work never went anywhere. (It was also 2 > years ago, so things could have changed quite a bit.) The simple patch > attached to this message fixes a bug that my testing indicated was > responsible for erroneous re-evaluations at least some of the time. > Thanks a lot. I applied your patch but it seems that your patch does not solve the problem in this specific situation. Or do I miss something? > I personally regard the babel cache as dangerous and unpredictable in > its present form. You’re much better off using language-specific > caching/memoization features and/or a disciplined regime of manual > reevaluation. I agree and avoid the caching mechanism generally. But all alternative approaches do involve more work, so I am regularly tempted to use it again. Generally, I think that caching is a sensitive area. And if we think that it is unpredictable and advise people to stay off of it, we are better off removing it than offering it in this state. At least until it behaves (more) predictable. > >>> >>> I'd expect no evaluation even during export. >>> >>> Is this a bug or am I missing something? >>> >>> Regards, >>> Andreas >>> >>> PS: The example: >>> >>> * Test Cached Export >>> ** A long running code block. >>> #+name: foo >>> #+begin_src emacs-lisp :var bar="baz" >>> (sit-for 15) >>> (message "bar=%S" bar) >>> #+end_src >>> >>> #+RESULTS: foo >>> : bar="baz" >>> >>> ** Calling >>> >>> Exporting this subtree will demonstrate my problem. I expect the call >>> line below to not execute anything. This works for interactive >>> execution (C-c C-c). But if I export this subtree only, the code is >>> executed. >>> >>> This returns immediately thanks to the cached result. >>> #+call: foo("qux") :cache yes >>> >>> #+results[f2b650eb5296f72a1f7237c2a65b7fb3443acf5f]: >>> : bar="qux" >> >> >> I should have added that adding :eval no-export to the #+call line does >> not help either. > > There are two places you could add the :eval option. See > (info "(org) Evaluating code blocks") . You may have to experiment with > putting it in one or both places in order to get the desired result. > (If none of the possible combinations works, then it is a bug IMO.) True. But can you explain to me why it is not possible to disable the evaluation of a call line? If the evaluation of a code block is disabled (:eval never) there is no evaluation and no results. If I specify ':eval never' at the end of the #+call line I do not get any results either but the called source block is unnecessarily and unexpectedly evaluated. So, basically I would argue that #+call: foo("qux") :eval never should do what it says an evaluate never, i.e. it should behave as #+call: foo[:eval never]("qux") :eval never Regards, Andreas > > From d7355798edc643bbbca7ab1ead2a2e11f37aa64c Mon Sep 17 00:00:00 2001 > From: Aaron Ecay > Date: Thu, 29 Oct 2015 13:31:28 +0000 > Subject: [PATCH] babel: fix header arg duplication > > * lisp/ob-core.el (org-babel-process-params): Make idempotent. > * testing/lisp/test-ob.el (ob/process-params-no-duplicates): New test. > --- > lisp/ob-core.el | 8 +++++++- > testing/lisp/test-ob.el | 12 ++++++++++++ > 2 files changed, 19 insertions(+), 1 deletion(-) > > diff --git a/lisp/ob-core.el b/lisp/ob-core.el > index 61753ce..fd6d785 100644 > --- a/lisp/ob-core.el > +++ b/lisp/ob-core.el > @@ -1597,7 +1597,13 @@ shown below. > (cons :result-type (cond ((member "output" result-params) 'output) > ((member "value" result-params) 'value) > (t 'value)))) > - (org-babel-get-header params :var 'other)))) > + (loop for item in params > + unless (memq (car item) '(:colname-names > + :rowname-names > + :result-params > + :result-type > + :var)) > + collect item)))) > > ;; row and column names > (defun org-babel-del-hlines (table) > diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el > index 508a3ed..c2feb39 100644 > --- a/testing/lisp/test-ob.el > +++ b/testing/lisp/test-ob.el > @@ -1477,6 +1477,18 @@ echo \"$data\" > (should (equal "foo\\\"bar" > (org-babel-script-escape "\"foo\\\\\\\"bar\"")))) > > +(ert-deftest ob/process-params-no-duplicates () > + (should (equal (org-babel-process-params '((:colname-names . 1) > + (:rowname-names . 1) > + (:result-params . 1) > + (:result-type . 1) > + (:var . "\"foo\""))) > + '((:var) > + (:colname-names . 1) > + (:rowname-names . 1) > + (:result-params . 1) > + (:result-type . value))))) > + > (provide 'test-ob) > > ;;; test-ob ends here > -- > 2.6.2