[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [babel][PATCHES] ob-R patches for review

From: Charles C. Berry
Subject: Re: [O] [babel][PATCHES] ob-R patches for review
Date: Fri, 16 May 2014 11:22:36 -0700
User-agent: Alpine 2.00 (OSX 1167 2008-08-23)

On Fri, 16 May 2014, Rainer M Krug wrote:

Sorry for coming back to your suggestions so late, but I did some
thinking about the approach. Comments inline below.

No problem. I am about to leave town and my email for a couple of weeks,
so I might not be able to reply to further correspondence till June.

Comments inline below.


"Charles C. Berry" <address@hidden> writes:

On Mon, 12 May 2014, Rainer M Krug wrote:

Eric Schulte <address@hidden> writes:


[Rainer writes]
My idea is to have all R code in one directory and to let ESS load it
upon initialization of ESS (which is a dependency of running R from org
anyway, if I am not mistaken).

Not quite. You can run R src blocks without (require 'ess) if they require
no session. (I do not claim that anyone actually runs R src blocks who
lacks a working ESS installation, just saying...)

[Rainer again]
Hm - would it then be possible to add ESS as a requirement for running R
code, as it is already mentioned on [1] as a requirement?

I'd be surprised if it would have any impact on users. Who uses R and
org-mode without ESS? But as you say it is listed as a requirement.


I am now leaning towards the following approach:

New behavior (environment):
1) Define the R code in emacs variables, i.e. customizable in emacs.
2) Define a function to load the code into an R environment - not customizable.

## upon creation of the R session (i.e. only once for each R session)

Maybe wait till the first variable transfer is called, if it ever is.

3) use the load function to load the code from the emacs variables into
an R environment called "org:functions"
4) load all .R files in the directory ~/.orgFunctions/ into
"org:functions". This will mean that when functions of the same name as
loaded earlier will be overwritten, i.e. the functions are customizable
by R code only.

## before variable transfer at each execution of a code block

Only if there is a variable transfer, of course.

5) source all .R files in the directory RWorkingDirectory/.orgFunctions/
i.e. they are not loaded into a specific environment. Reasoning: further
customization possible, kind of an "R package light" approach.

6) use the load functions (as defied initially in (4), (3) or in () from
to load the variables. If they are loaded into an environment or not
depends on the definition of the functions.

Concerning old versus new behavior, I would actually suggest to put this
into the R functions: one could add an argument "variablesInEnvironment"
which would, if set, be the name of the environment, i.e. default value
"org:variables", if NULL it would load into .GlobalEnv, i.e. the old
behaviour. In org, one could have a variable
org-babel-R-variable-transfer-type (or whatever the proper name should
be) and to make it user configurable:

- null :: old behaviour
- "org:variables" (default) :: variables into environment called
- other string :: name of the environment to be used

As stated earlier, as I think that name clashes are more unlikely with
the new approach, I would suggest to make "org:variables" the default.

The above sounds good.

If you do not wish to implement the `org-babel-R-assign-elisp-function' variable approach I suggested, I'll make it a TINYCHANGE when I return in June. It will not impact on what you propose. However, if your implementation makes it possible for arbitrary elisp variables to be handled in R - I might not bother.


True - but I like the simplicity of being able to customize the
behavior of org-babel-R by writing an R function without having to thin
about elisp. But maybe there is a way of doing both...

noweb will do it. Quote the chunk like this:

#+BEGIN_SRC emacs-lisp :noweb yes :tangle elisp-R.el
   (setq rlines "

I must admit, I have never used macros and noweb expansion...

If you could give me your opinions on this approach, I would look into
implementing it.

It is just a labor saving suggestion for you -- it would not show up
in the final elisp. Put all your elisp and R code in src blocks in a
*.org file. You can edit and format the R code in R src blocks and
likewise the elisp. A src block like the one above will import the R
into elisp as a string. You only tangle the elisp. So the benefit is
you have ease of editting R and writing unit tests for it for R code
that appears in elisp.

IMO, noweb is a good way to mix languages in org-mode. I use the R `inline' package to write C functions that R can call. R needs the code as strings. I write the C code in C src blocks then assign it in as an R character string in an R src block. I can write an R wrapper and unit test for each little snippet of C code, then when it all looks good join up the snippets by putting multiple noweb references on successive lines.

[1]  http://orgmode.org/worg/org-contrib/babel/languages.html


reply via email to

[Prev in Thread] Current Thread [Next in Thread]