From: Rainer M Krug <Rainer@krugs.de>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: Bastien <bzg@gnu.org>,
"emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>,
"Charles C. Berry" <ccberry@ucsd.edu>
Subject: Re: [babel][PATCHES] ob-R patches for review
Date: Mon, 12 May 2014 21:08:04 +0200 [thread overview]
Message-ID: <m2a9amu86j.fsf@krugs.de> (raw)
In-Reply-To: <87y4y7uifu.fsf@gmail.com> (Eric Schulte's message of "Mon, 12 May 2014 09:21:09 -0600")
[-- 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 --]
next prev parent reply other threads:[~2014-05-12 19:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-29 12:43 [babel][PATCHES] ob-R patches for review Rainer M Krug
2014-04-29 18:15 ` Charles Berry
2014-04-30 12:28 ` Rainer M Krug
2014-04-30 22:49 ` Charles C. Berry
2014-05-01 9:10 ` Rainer M Krug
2014-05-07 10:27 ` Eric Schulte
2014-05-08 2:26 ` Charles Berry
2014-05-08 10:02 ` Rainer M Krug
2014-05-09 9:11 ` Rainer M Krug
2014-05-09 12:02 ` Rainer M Krug
2014-05-08 9:57 ` Rainer M Krug
2014-05-09 13:03 ` Bastien
2014-05-09 13:45 ` Rainer M Krug
2014-05-09 14:34 ` Eric Schulte
2014-05-12 8:33 ` Rainer M Krug
2014-05-12 12:23 ` Suvayu Ali
2014-05-12 12:41 ` Rainer M Krug
2014-05-12 14:01 ` Queestion concerning lists - was: " Rainer M Krug
2014-05-12 15:23 ` Eric Schulte
2014-05-12 15:21 ` Eric Schulte
2014-05-12 19:08 ` Rainer M Krug [this message]
2014-05-12 22:05 ` Charles C. Berry
[not found] ` <m2y4y2f499.fsf@krugs.de>
2014-05-16 18:22 ` Charles C. Berry
2014-06-06 16:11 ` Eric Schulte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2a9amu86j.fsf@krugs.de \
--to=rainer@krugs.de \
--cc=bzg@gnu.org \
--cc=ccberry@ucsd.edu \
--cc=emacs-orgmode@gnu.org \
--cc=schulte.eric@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.