From: Thomas S. Dye <tsd@tsdye.com>
To: Aaron Ecay <aaronecay@gmail.com>
Cc: Andreas Leha <andreas.leha@med.uni-goettingen.de>,
emacs-orgmode@gnu.org, Nicolas Goaziou <mail@nicolasgoaziou.fr>
Subject: Re: problems with export and :cache
Date: Thu, 29 Oct 2015 10:32:11 -1000 [thread overview]
Message-ID: <m28u6le7qs.fsf@tsdye.com> (raw)
In-Reply-To: <877fm5xzpm.fsf@gmail.com>
Aloha all,
Aaron Ecay <aaronecay@gmail.com> writes:
> Hi Nicolas,
>
> 2015ko urriak 29an, Nicolas Goaziou-ek idatzi zuen:
>>
>> Andreas Leha <andreas.leha@med.uni-goettingen.de> 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:
> <http://mid.gmane.org/86fvqqc8jb.fsf@somewhere.org>.
>
> 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 <http://yihui.name/knitr/demo/cache/> 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.
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.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
next prev parent reply other threads:[~2015-10-29 20:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-28 21:37 problems with export and :cache Andreas Leha
2015-10-28 21:45 ` Andreas Leha
2015-10-29 13:34 ` Aaron Ecay
2015-10-29 14:22 ` Nicolas Goaziou
2015-10-29 15:14 ` Aaron Ecay
2015-10-29 16:42 ` Nicolas Goaziou
2015-10-29 17:05 ` Aaron Ecay
2015-10-29 17:16 ` Nicolas Goaziou
2015-10-29 19:11 ` Aaron Ecay
2015-10-30 23:40 ` Andreas Leha
2015-11-07 16:37 ` Achim Gratz
2015-11-07 20:33 ` Aaron Ecay
2015-11-07 22:43 ` Achim Gratz
2015-10-29 14:58 ` Andreas Leha
2015-10-29 15:17 ` Aaron Ecay
2015-10-29 16:51 ` Nicolas Goaziou
2015-10-29 19:05 ` Aaron Ecay
2015-10-29 20:32 ` Thomas S. Dye [this message]
2015-10-29 23:01 ` Andreas Leha
2015-11-01 22:56 ` Nicolas Goaziou
2015-11-04 12:01 ` Aaron Ecay
2015-11-04 22:41 ` Nicolas Goaziou
2015-11-05 14:51 ` Aaron Ecay
2015-11-05 14:55 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m28u6le7qs.fsf@tsdye.com \
--to=tsd@tsdye.com \
--cc=aaronecay@gmail.com \
--cc=andreas.leha@med.uni-goettingen.de \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).