From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Banel Subject: Re: speeding up Babel Gnuplot Date: Wed, 04 Jan 2017 21:29:19 +0100 Message-ID: <586D5B1F.2040803@free.fr> References: <5864217C.7060001@free.fr> <586963CB.1000006@free.fr> <87d1g6qrqh.fsf@nicolasgoaziou.fr> <586AB3DB.6070702@free.fr> <586C1A53.90601@free.fr> <87tw9eg28w.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54230) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cOsBb-0007yv-99 for emacs-orgmode@gnu.org; Wed, 04 Jan 2017 15:29:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cOsBa-0005ju-7Q for emacs-orgmode@gnu.org; Wed, 04 Jan 2017 15:29:27 -0500 Received: from smtp3-g21.free.fr ([2a01:e0c:1:1599::12]:36317) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cOsBa-0005jZ-0d for emacs-orgmode@gnu.org; Wed, 04 Jan 2017 15:29:26 -0500 Received: from [IPv6:2a01:e35:2e21:def0:6d84:fa8b:21b6:7ab7] (unknown [IPv6:2a01:e35:2e21:def0:6d84:fa8b:21b6:7ab7]) by smtp3-g21.free.fr (Postfix) with ESMTP id C0DB913F769 for ; Wed, 4 Jan 2017 21:29:22 +0100 (CET) In-Reply-To: <87tw9eg28w.fsf@Rainer.invalid> 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" To: emacs-orgmode@gnu.org Le 04/01/2017 18:32, Achim Gratz a =E9crit : > Thierry Banel writes: >> There is no way to ensure a single call to >> (org-babel-gnuplot-process-vars) without modifying ob-core.el. I don't >> want to do that because I would have to change a lot of babel backends= . > But that is the right fix to apply, unless there is a reason for the > input vars to be processed multiple times. I haven't looked at the > Babel code in the last two years, but generally I'd suggest that each > argument should only be processed once per Babel block since the second > processing could have unwanted side-effects. > > Absolutely! But not so easy. Here is a simplified version of the involved functions: #+BEGIN_SRC elisp (defun org-babel-expand-body:gnuplot (body params) (let ((vars (org-babel-gnuplot-process-vars params))) ;; <-- 1st call (org-babel-variable-assignments:gnuplot params))) (defun org-babel-variable-assignments:gnuplot (params) (org-babel-gnuplot-process-vars params)) ;; <-- 2nd call (defun org-babel-gnuplot-process-vars (params) (... generate temp file ...)) #+END_SRC Following the flow of calls, we can see that starting from (org-babel-expand-body:gnuplot), the function (org-babel-gnuplot-process-vars) is called twice. I would like to pass `vars' around (which is the result of the first call) to avoid the second call. To do that I need to add a parameter `vars' to (org-babel-variable-assignments:gnuplot). Unfortunately I cannot because the parameter of this function (and all functions matching (org-babel-variable-assignments:*)) is enforced by the Babel cor= e. Therefore to pass information around, the only channel is the `params' parameter. I use it as a cache in my patch. Moreover, the above simplified ELisp sketch is not the whole story. There is also the (org-babel-prep-session:gnuplot) function involved. I have not yet investigated that. But, the `params' cache trick takes care of this flow without having to understand it. To sum-up: yes, ob-gnuplot.el is doing the double `params' processing. But to avoid that without the cache trick, ob-core.el should be changed, as well as all dependent ob-*.el backends. Lot of work. Or I may be missing something... Regards Thierry