From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Charles C. Berry" Subject: Re: [babel][PATCHES] ob-R patches for review Date: Fri, 16 May 2014 11:22:36 -0700 Message-ID: References: <87ppjpm5n5.fsf@gmail.com> <8F4A9158-D8BD-4FE7-8D9A-A22C4871BDB6@gmail.com> <87ppjnt88e.fsf@bzg.ath.cx> <874n0zhvgi.fsf@gmail.com> <87y4y7uifu.fsf@gmail.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43552) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WlMmU-0007aF-Py for emacs-orgmode@gnu.org; Fri, 16 May 2014 14:23:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WlMmO-0002AH-Kk for emacs-orgmode@gnu.org; Fri, 16 May 2014 14:22:54 -0400 In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Rainer M Krug Cc: Bastien , "emacs-orgmode@gnu.org" , Eric Schulte 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. Chuck > > "Charles C. Berry" writes: > >> On Mon, 12 May 2014, Rainer M Krug wrote: >> >>> Eric Schulte 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). >> [Chuck] >> 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 > "org:variables" > - 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 " >> <>") >> #+END_SRC > > 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. > > > Footnotes: > [1] http://orgmode.org/worg/org-contrib/babel/languages.html > [...]