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 23:01:01 +0000 Message-ID: References: <87vb9pyf0l.fsf@gmail.com> <87oafhoby4.fsf@nicolasgoaziou.fr> <877fm5xzpm.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]:56734) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrwD8-0008Ez-3I for emacs-orgmode@gnu.org; Thu, 29 Oct 2015 19:02:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZrwD4-0006A5-RZ for emacs-orgmode@gnu.org; Thu, 29 Oct 2015 19:02:22 -0400 Received: from plane.gmane.org ([80.91.229.3]:54348) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZrwD4-00069f-Kv for emacs-orgmode@gnu.org; Thu, 29 Oct 2015 19:02:18 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZrwD1-0005pZ-Nq for emacs-orgmode@gnu.org; Fri, 30 Oct 2015 00:02:15 +0100 Received: from cpc33-cmbg15-2-0-cust4.5-4.cable.virginm.net ([81.102.136.5]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 30 Oct 2015 00:02:15 +0100 Received: from andreas.leha by cpc33-cmbg15-2-0-cust4.5-4.cable.virginm.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 30 Oct 2015 00:02:15 +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 Thomas, Thomas S. Dye writes: > Aloha all, > > Aaron Ecay writes: > >> Hi Nicolas, >> >> 2015ko urriak 29an, Nicolas Goaziou-ek idatzi zuen: >>> >>> Andreas Leha writes: >>> >>>> 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. >>> >>> Is it necessarily broken? >> >> If this means “can it ever work?” then I think the answer is “yes it >> can”. But I think the current implementation is broken and likely to >> remain so for the foreseeable future. The issues are: >> >> 1. :cache only works for code which is a pure function of its header args >> 2. When combined with :session, the environment that the code is evaluated >> in is not created anew each time it is run. This makes it much easier >> to leak references to (e.g.) variables defined in other blocks >> 3. The proper notion of purity is not easily defined when the code does >> things like modifying the emacs environment, touching the filesystem, >> or accessing the language’s RNG. >> 4. We (org devs) don’t actually understand how the semantics of cache >> interacts with other babel features. See: >> . >> >> 1-3 are likely to be extremely confusing for users, especially less >> technically sophisticated ones (what’s a “pure function” anyway)? The >> inability to give a clear introductory explanation of the feature in >> combination with 4 indicating we don’t actually understand it ourselves >> makes me feel like we should not be advertising, let alone recommending, >> it. >> >> The only other literate programming environment that I know of that >> implements such a feature is knitr (for R). They address these issues >> by providing (optional) free-variable analysis to construct a dependency >> graph between code blocks. There is also some handling of RNG seed >> values. The documentation is much >> more comprehensive, including a prominent statement about the dangers of >> side effect-ful code and a nuanced discussion of several issues, >> including the RNG. >> >> Aaron >> >> PS I’ve looked through my old notes on the interaction of cache with >> babel export. I can’t reproduce any of my old test cases, so maybe that >> bug has been fixed as a side effect of some other change. > > FWIW, I think relying on cache to speed up export is the wrong > approach. Having all code run during each export is, to me, a feature > that makes a document "live." I'm willing to be patient during export > to get this feature. > > If speed is important and a live document isn't desired, then one > solution is to rename the results and refer to this name in the > document, rather than to the name of the code block that produced the > results. I do this manually, which is OK, but I've often wanted > something like :persist-as my-result so I can be certain to have a good > link from the results back to the code that produced them. There we go again. Another advice not to use the :cache. > > That said, points 2 and 4 seem to me serious issues that users must > understand if they choose to use :cache. So, at the least, the > documentation needs revision. > Just to add (maybe that belongs to point 4 anyway): And the caching should work predictably -- even during export. Regards, Andreas