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

[Rainer M Krug <Rainer@krugs.de>]

[-- Attachment #1: Type: text/plain, Size: 3718 bytes --]

Eric Schulte <schulte.eric@gmail.com> writes:

>>> If not would you mind submitting a version of the patches split into
>>> multiple commits with as much of the hard-coded R code as feasible
>>> placed into customizable variables along the lines of the
>>> `org-babel-R-assign-elisp-function' variable suggested by Charles.  
>>
>> I am thinking of actually not providing the R code in org-variables, but
>> to put them into R files and to source them. By doing this, the
>> customization could be done in R, which will be much easier for R users
>> then to customize emacs variables.
>>
>
> I think this is a bad idea, such external R source files may be hard to
> manage and load reliably across systems 

I see your points, but I am looking at ESS (which is loading .R files as
well into the ESSR environment) and whose loading mechanism I want
to piggy back the loading of .R for org. If I understand the variable
transfer from org to R correctly, it anyway only works on local R
sessions, which makes it even easier to do then ESS which also caters
for remote R sessions.
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). I have a prototype working, and will keep
you posted. The complication would be that a newer version of ESS would
be needed.

The other option would be to just copy the code ESS uses into org, which
would make the process independent of changes in ESS. But I don't like
the duplication of code.

> and it is not clear where they should live in the Org-mode repository.

I would suggest in a etc/R. 

> Additionally, if the variables simply hold R code text, then users can
> easily initialize them from R files locally with something like the
> following.
>
>     (setq org-babel-R-assign-elisp-function
>           (with-temp-buffer
>             (insert-file-contents-literally "personal.R")
>             (buffer-string)))
>
> I think this approach is much simpler.

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...

Thanks for your comments,

Rainer

>
> Best,
> Eric
>
>>
>> These would be sourced and stored into an environment "org:functions",
>> using the same approach as ESS is using to store functions into an
>> environment "ESSR". I would then put the variables transfered into
>> "org:variables". These environments would only exist in the search path,
>> and not overwrite any user set objects in R.
>>
>> As it needs to be sourced for each R process once, the right place would
>> be in  org-babel-R-initiate-session - correct?
>>
>> What would be the best place to put these R files? 
>>
>>> One lesson I've certainly learned from the Org-mode mailing list is
>>> that you can't anticipate all of the ways that your code will be used,
>>> so up-front customizability generally pays off.
>>
>> OK - point taken - and I am definitely one of those users who thinks
>> about unusual usages of certain features.
>>
>> Cheers,
>>
>> Rainer
>>
>>>
>>> Thanks,
>>> Eric
>>>
>>>>
>>>> Thanks
>>>>
>>>> Rainer

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]