From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer M Krug Subject: Re: [babel][PATCHES] ob-R patches for review Date: Wed, 30 Apr 2014 14:28:28 +0200 Message-ID: References: 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]:56004) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WfTdJ-00075e-AU for emacs-orgmode@gnu.org; Wed, 30 Apr 2014 08:29:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WfTdD-00083y-S4 for emacs-orgmode@gnu.org; Wed, 30 Apr 2014 08:29:05 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:37059) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WfTdD-00083i-Iz for emacs-orgmode@gnu.org; Wed, 30 Apr 2014 08:28:59 -0400 Received: by mail-wi0-f175.google.com with SMTP id cc10so9034435wib.14 for ; Wed, 30 Apr 2014 05:28:58 -0700 (PDT) In-Reply-To: (Charles Berry's message of "Tue, 29 Apr 2014 18:15:47 +0000 (UTC)") 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: Charles Berry Cc: emacs-orgmode@gnu.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Charles Berry writes: > Rainer M Krug krugs.de> writes: > >>=20 >> Hi >>=20 >> Attached please find seven patches for review to implement the storing >> of org variables in their own environment and to make the org-issued R >> code look nicer in the R session. > > > Rainer, > > > I have suggestions and a concern. > > I suggest that you look at how ESS handles R objects and constructs > calls in elisp to be executed in an R session. > > It uses a package and its NAMESPACE to provide that functionality and > store objects. That makes the elisp interface a lot cleaner and keeps > ESS variables out of the users way. The package is found at /etc/ESS= R/. That is effectively what I am doing as well, only that I am not using a package but an environment and add it to the search path.=20 By doing this, the org variables are stored in this environment and do not overwrite existing R objects by the same name. If objects by the same name as the org variables are existing in the global R environment, they are still found first, but variables transferred from org can *always* be accessed by using ,---- | .org_variables_$VARIABLE_NAME `---- in R. As said, existing VARIABLE_NAME objects in R are *not* impacted on. If you use only ,---- | VARIABLE_NAME `---- in R it returns the first object in the R search path. So the only variable which can be overwritten when this patch is used is ,---- | .org_variables_ `---- which, I think, is quite unlikely to exist. Concerning package: I like the idea and thought about it with the aim of putting all R code into a package, to make it easier to maintain the code and to customize it. The org variables can then be injected in this package. But the problem of name clashes between user defined variables and the name of the namespace / environment of the package is the same - possible higher, as a package name (and therefore the namespace and environment) should have meaningful names. > > I also suggest that you introduce a customization variable to > allow a user to turn off the functionality you have created. I don't think this is necessary as the behavior for the user does not change at all, only that it becomes safer to use org variables in R (see above). > > My concern is that you are injecting code into the R user session or > script that the user may not want. If I already have an R object named > 'org' your code will break my code. Please see my later patch, which renames this to ".org_variables_" which sounds like an unlikely name to exist. > > Further, all of this is hard coded, so I can't change the > variable/file names. OK - this can be added as a variable, and in regards to the file name this makes sense. For the moment I would leave it as it is and discuss what would be the useful approach, as there are some problems with the usefulness of saving the variables - imagining different variables passed to different code blocks. One option would be to have a variable, whose default is NIL, which contains the file name: =2D NIL :: no saving =2D string :: saving under the name given > > HTH, Yes definitely - discussions more then welcome, Rainer > > Chuck > > > > > =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) iQEcBAEBAgAGBQJTYOxxAAoJENvXNx4PUvmCCdsH/1qzxTh+TuV2YXruXJuRSRUU X212gKce4jGzINA9r7EaZLDTJVirQ2goUA0mSrT02/WBFTUM0JaCFm8li4miD358 rvDcpCwkRf4UE+qdAKKVAT/v1PolwAyTb7Hj/74UVYFjLAv/VTkkohbdVr5sv/KH GysVsrhSN1ClTIElGwFtpVNYj9rDklxO+EG/SrjsA8KYHTV7o2vRY6AeaDzNcn85 0S3tLCIFuZ+k1Psy9gFec+SUU3q7aOErjqC0c322RTMD9Mn020JY0P0bA0nFcppF LnRqz3OOnoFub+Xf0Pq9wp3tV1SlPdfhpJfcFLrGNuyvi3LGAtRn2WJ1w5DZwnA= =D98H -----END PGP SIGNATURE----- --=-=-=--