Re: [O] Bug? R: Org babel block execution *drastically* slower than in ESS session directly

[Thomas S. Dye]

Aloha Aaron,

Welcome to Org-mode.

Aaron Ecay <address@hidden> writes:

> 2012ko azaroak 13an, John Hendy-ek idatzi zuen:
>
> [...]
>> 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?
>
> “:results silent” just means “silent except for the minibuffer”; IDK
> why.

I think "silent" has to do with the Org buffer that contains the source
code block.  Non-silent blocks do something in the buffer.  This was,
for me, one of the amazing things about babel when it was being
developed.  One could "speak" any language and have sensible results
written back to a plain text file.

>
>> Are you sure it's only on file import? I was generating some large
>> output when I first experienced this.
>
> Yes, that’s what I meant (and didn’t explain well).  Org writes R’s
> output to a file, and then imports it into Emacs (to print in the
> minibuffer).  But it also does an expensive transformation before
> printing it – whence the slowdown.
>
>> I have to
>> change to the R buffer to see if there were any errors.
>
> I agree that this is sub-optimal.
>
> I seem to remember that ob-R.el is unmaintained (or was at some point in
> the past).  Once there is consensus on what a fix should look like, I
> can attempt to produce a patch implementing it.  And I’ll take a crack
> at error reporting in the minibuffer too.

Yes, ob-R.el is currently without a maintainer. My sense and experience
is that Eric S. is happy to entertain patches to the various ob language
files.  My experience is also that active maintainers welcome
patches--I don't think there is a barrier to patch proposals.

I can help with documentation if your patch results in some substantive
changes to R support in babel.  Please don't hesitate to ask if need be.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com