Re: [O] R code block produces only partial output

[Aaron Ecay]

Hi Chuck,

Thanks for your feedback.  The patch you’ve sent looks basically correct
to me.

2014ko abuztuak 23an, "Charles C. Berry"-ek idatzi zuen:

[...]

> The old hacky way works pretty well most of the time. I suspect that it 
> will be hard to get folks to really test a new ob-R.el in advance of its 
> moving to maint. ./lisp/test-ob-R.el only has one :session src block and 
> a few other src blocks...

Agreed, more tests are something I want to add to this patch before
landing it, and I’ll try to encourage that in the future (from myself
most of all!).

> 
> I was thinking of having a drop in replacement for the each of the two 
> functions that are changed and maybe selecting which version to use with 
> defalias. If there is a slicker way to enable a user to revert to an 
> earlier version without having good git skills, fine. But I think the 
> possibility of breaking something that someone needs and not noticing till 
> the changes go to maint is high.

I think that having two different implementations will in the long run
increase the surface area susceptible to bugs.  We should do our best
and then release what we have when we feel it’s stable.

(I admit to being a bit bewildered by org’s release process; I just use
whatever is in git and deal with the occasional breakage.  The big no-no
is letting a bug slip into an emacs-bundled version of Org, since that
will live for years.  But it seems like it takes a long time even after
reaching maint for code to make its way into emacs.)


[...]

> 
> Not sure I get why the sentinel file is needed, 

The execution of the R commands is asynchronous (from emacs’ POV); org
polls for the existence of this file to let it know that R has finished
its execution.

> but the patch here uses on.exit(file.create(...)) to ensure that that
> file is created. One hiccup (not sure if it exists in master,too) is
> that starting a remote session and then trying to run src blocks from
> a buffer for a local file will hang (because a local temp file is used
> for sentinel). So there is still stuff to do.

Hmm, OK.


[...]

> 
> Putting objects in userspace is considered poor practice. FWIW, CRAN 
> disallows it. `environment-hacking' as you call it underlies much of R. If 
> you must create and hold variables use the attach(NULL,name="org-vars") 
> trick.

I’ll defer to your judgment.

Thanks again for the feedback and revised patch.  I’ll try to get a few
tests written this weekend, and study the remote vs. local files
business.

-- 
Aaron Ecay