From: Aaron Ecay <aaronecay@gmail.com>
To: Ista Zahn <istazahn@gmail.com>Ista Zahn <istazahn@gmail.com>,
Andreas Leha <andreas.leha@med.uni-goettingen.de>,
emacs-orgmode Mailinglist <emacs-orgmode@gnu.org>
Subject: Re: "user-error: No language for src block: (unnamed)" when running `org-icalendar-combine-agenda-files`
Date: Fri, 21 Aug 2015 16:13:13 -0400 [thread overview]
Message-ID: <87oai0v1ra.fsf@gmail.com> (raw)
In-Reply-To: <CA+vqiLFuv6zOVzjhk+i-8kxBQB7fg+YPa-h6W1soEi--H3uibg@mail.gmail.com>
Hi Ista,
2015ko abuztuak 21an, Ista Zahn-ek idatzi zuen:
>
> On Fri, Aug 21, 2015 at 11:04 AM, Nicolas Goaziou
> <mail@nicolasgoaziou.fr> wrote:
>> Ista Zahn <istazahn@gmail.com> writes:
>>
>>> I agree that it is safer. In my case its safer like a 10 MPH speed
>>> limit. Safe yes, but too slow!
>>
>> Doesn't Babel :cache property help here?
>
> It does actually, to my surprise. I have not been using :cache because
> the documentation says
>
> "Note that the :cache header argument will not attempt to cache
> results when the :session header argument is used"
>
> and since I almost always use :session I didn't expect this to work.
> To my surprise it does (at least with R source blocks, I haven't
> tested yet with others). Can I now rely on this to work even with
> :session?
I think it depends on what you mean by “work.” Specifically, :cache
doesn’t understand dependencies across source blocks when run in a
session. So in the following document, if you edit the definition of
myvar, the subsequent usage will retain the old value on subsequent
exports:
==========
#+begin_src R :session *foo* :cache yes
myvar <- 1
myvar
#+end_src
#+RESULTS[8310fa64b89f36a383660d14779e88d9aa90834a]:
: 1
#+begin_src R :session *foo* :cache yes
myvar
#+end_src
#+RESULTS[5c241816868f6400ccfb54ceb6ef15dbeea16de1]:
: 1
==========
There are also subtle issues related to the fact that in order to export
a document, org:
1) makes a copy of the buffer
2) executes the babel blocks in this copy, destructively modifying the
buffer as it goes
3) exports the result
In my experience, sometimes the header arguments, and thus the hash
that the cache depends on, can change. So in addition to the cache not
re-evaluating when it should as above, it might needlessly re-evaluate
a computationally expensive block in the middle of export.
I tried to fix this about 2 years ago by getting the relevant code to
not do any buffer modifications as it goes but rather first evaluate
all the blocks then do all the needed modifications. However, the
resultant patch was too big, and I ran out of time to work on it.
Since I made that attempt, a second, unmodified copy of the buffer has
been introduced to the process to help with some (nominally different
but related) aspects of babel processing. This might have solved the
problem, but I’m not sure.
When the cache has not worked as I expected it to in the past, it’s been
in the middle of actually trying to do something with org, usually under
deadline pressure. Thus, I’ve adopted the conservative approach of
evaluating blocks manually in all circumstances, and not trying to get
caching to work. So, you might find that these problems have all gone
away as a consequence of other changes.
For purely R-based work, Charles Berry’s ox-ravel package
<https://github.com/chasberry/orgmode-accessories/blob/master/ox-ravel.org>
is a very interesting approach, since it relies on the cache feature of
knitr, which is capable of automatically detecting cross-block
dependencies like the example above under some circumstances
<http://yihui.name/knitr/demo/cache/>. It would be interesting to see
if that approach could be used to override :cache handling for ob-R,
while falling back on org-babel’s less intelligent features for other
languages (or in R environments that don’t have knitr available). But
that’s a(nother) big project. (I’ve also never used ox-ravel in a
serious project, so my impressions are just based on reading the code
and documentation – which is a really excellent example of literate
elisp programming).
TLDR: If the standard of reliance is working as well as other cache-capable
literate programming libraries for R like knitr, in my (possibly out of
date) experience :cache + :session is not up to scratch.
--
Aaron Ecay
next prev parent reply other threads:[~2015-08-21 20:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-20 9:38 "user-error: No language for src block: (unnamed)" when running `org-icalendar-combine-agenda-files` JI, Xiang
2015-08-20 9:44 ` JI, Xiang
2015-08-21 11:50 ` Nicolas Goaziou
2015-08-21 13:46 ` Ista Zahn
2015-08-21 14:20 ` Nicolas Goaziou
2015-08-21 14:35 ` Ista Zahn
2015-08-21 14:43 ` Andreas Leha
2015-08-21 14:52 ` Ista Zahn
2015-08-21 15:04 ` Nicolas Goaziou
2015-08-21 15:57 ` Ista Zahn
2015-08-21 20:13 ` Aaron Ecay [this message]
2015-08-21 20:19 ` Andreas Leha
2015-08-22 3:19 ` Charles C. Berry
2015-08-21 20:19 ` Charles C. Berry
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=87oai0v1ra.fsf@gmail.com \
--to=aaronecay@gmail.com \
--cc=istazahn@gmail.com \
/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).