From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer M Krug Subject: Re: [babel][PATCHES] ob-R patches for review Date: Mon, 12 May 2014 21:08:04 +0200 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: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33280) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjvaJ-0002PK-7D for emacs-orgmode@gnu.org; Mon, 12 May 2014 15:08:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WjvaB-0005OV-SV for emacs-orgmode@gnu.org; Mon, 12 May 2014 15:08:23 -0400 In-Reply-To: <87y4y7uifu.fsf@gmail.com> (Eric Schulte's message of "Mon, 12 May 2014 09:21:09 -0600") 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: Eric Schulte Cc: Bastien , "emacs-orgmode@gnu.org" , "Charles C. Berry" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Eric Schulte 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.=20=20 >> >> 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=20 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.=20 > 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?=20 >> >>> 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 =2D-=20 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 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBAgAGBQJTcRwZAAoJENvXNx4PUvmCRxMIAN38g0IuDH6hrP+vZFWO+DWV r8OInJ0rhGOdCParBrtf459tLwchKdfnrm7+uibSEnlw/mPjPZfO5sf6dFK4ajPL kzcw/Nv10SS9r9523FYx1eGemjyP+/Ai710Afu1tYdlgw+jYTseABzw6mjWvBPym 7KPspgX4dFGbwcqyqxeyHME9WR4pdChwwBU+ZjVTYluw7YGlJ+91nU6vbfexWiSi uKyrRvQi3etlXsKV6rH3NJKuVtABz+vaURtY3cBN9iWEslGsuZDtTW8KL/1ZLYsA E1zR4VAR+N89fbI2lnMsFPMC/uaY5hX46p/Statq2iUQNUiUNxEQWZ5PHk2UNQ0= =DTsR -----END PGP SIGNATURE----- --=-=-=--