From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: problems with export and :cache Date: Wed, 04 Nov 2015 23:41:49 +0100 Message-ID: <87lhad1j6a.fsf@nicolasgoaziou.fr> References: <87vb9pyf0l.fsf@gmail.com> <87oafhoby4.fsf@nicolasgoaziou.fr> <877fm5xzpm.fsf@gmail.com> <87io5ll45q.fsf@nicolasgoaziou.fr> <877flyvurj.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41946) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zu6iv-0003C2-VH for emacs-orgmode@gnu.org; Wed, 04 Nov 2015 17:40:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zu6iu-00036v-MK for emacs-orgmode@gnu.org; Wed, 04 Nov 2015 17:40:09 -0500 Received: from relay4-d.mail.gandi.net ([2001:4b98:c:538::196]:51430) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zu6iu-00032a-G3 for emacs-orgmode@gnu.org; Wed, 04 Nov 2015 17:40:08 -0500 Received: from selenimh (unknown [IPv6:2a01:6600:8080:9601::2de]) (Authenticated sender: mail@nicolasgoaziou.fr) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id C972017208B for ; Wed, 4 Nov 2015 23:40:03 +0100 (CET) In-Reply-To: <877flyvurj.fsf@gmail.com> (Aaron Ecay's message of "Wed, 04 Nov 2015 12:01:04 +0000") 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 Hello, Aaron Ecay writes: > See the attached patch. I=E2=80=99ve tried to put all my experience and = best > practices in there; comments are welcome of course. Thank you. It looks good. Some comments follow. > +unchanged code blocks. When the cache is active, a source block is not > +re-evaluated if a result for it is present in the buffer and neither the > +header arguments (including the value of @code{:var} references) nor the= text > +of the block itself has changed since the result was computed. The feat= ure > +helps avoid re-running long calculations. However, there are edge cases= and > +you should not rely on the cache to behave reliably in all circumstances. > + > +The caching feature works best when a babel block is a pure function of = its > +arguments (see @ref{var}). That is, the function always returns the > same (see @ref{var}) =3D> (@pxref{var}) > +results when given the same arguments, and does not touch external resou= rces > +(like the filesystem or the language=E2=80=99s RNG) in any way. > + > +The documentation of the knitr reproducible research package for the R > +language has some good discussion of issues that may arise when using the > +cache in such a context. See @uref{http://yihui.name/knitr/demo/cache/}, > +especially the sections =E2=80=9CEven more stuff for cache?=E2=80=9D and= =E2=80=9CReproducibility > +with RNG=E2=80=9D. Shouldn't this be : ``Even more stuff for cache?''. Ditto for the other title. > (Obviously, you will have to abstract away from the knitr > +implementation details which the documentation also discusses.) I think this last paragraph could go in a footnote at the end of the paragraph before it. > +Note that the @code{:cache} header argument will attempt to cache results > +when the @code{:session} header argument is used, even though the result= s of > +the code block execution stored in the session may lead to unexpected > +results. > + > +Noweb references (see @ref{Noweb reference syntax}) are currently not (see @ref{Noweb reference syntax}) =3D> (@pxref{Noweb reference syntax}) > +expanded when calculating whether the text of the code block has changed. > +Perhaps in principle they ought to be, but this could introduce unexpect= ed > +complexity. See @uref{http://thread.gmane.org/gmane.emacs.orgmode/79046= }. > + > +The @code{:cache} header argument can have one of two values: @code{yes}= or > +@code{no}. Regards, --=20 Nicolas Goaziou