I just ran into this problem. It is caused by the calls to
‘org-babel-import-elisp-from-file’ on lines 310 and 343 of ‘ob-R.el’
(for non-session and session code blocks respectively). I determined
this by setting ‘debug-on-quit’ to t in Emacs, then hitting C-g when cpu
usage spiked, and examining the backtrace.
Yes! I'm not crazy! I'm not very familiar with the debug options in emacs and had a heck of a time setting it up right the last time. Thanks so much for checking this out.
It seems like Emacs tries to read in the last value of the R command, to
print it in the minibuffer. It gets bogged down doing so. As a
stopgap, putting NULL as the last line of the source block fixes the
problem (the value “returned” by the block is just NULL). I believe
setting “:results output” (as opposed to “value”) would also make the
bug disappear, since the output will be very small. This is likely what
made cberry’s test differ from John’s.
Crazy. I really wondered if it had something to do with trying to spit out the results into the minibuffer. Why is that behavior included?
I’m not sure what the right strategy would be for a fix. Two ideas
would be:
1) adding a sanity check to o-b-import-elisp-from-file, which asks the
user whether to really import very large files (or just ignores such
files)
Are you sure it's only on file import? I was generating some large output when I first experienced this. It was only to avoid running that code that I wrote it to file once and decided to just read it once per session afterward (thinking reading would be faster than generating the input on demand). I was generating a grid of interactions with something akin to:
#+begin_src R
dat <- expand.grid(var1 = seq(0, 40000, by = 200), var2 = seq(0, 40000, by = 200))
#+end_src
I can check this tomorrow if you'd like, but I remember it lagging as it tried to print all of that into the minibuffer.
2) adding a new :results handling header arg “really-silent” (probably
with a better name...) that discards the result entirely, not even
printing it to the minibuffer.
I like this, in addition to changing the minibuffer output as it is. It would be fantastic to have the minibuffer say more than it does already (something akin to "Block execution complete"). I have to change to the R buffer to see if there were any errors. I like how the LaTeX exporter tells you if PDF export failed. It'd be nice to see something like (in addition to no results in the minibuffer), "Block execution complete but with errors."
Thanks again, and I'm glad you were able to track this down.
John
--
Aaron Ecay