emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Rainer M Krug <Rainer@krugs.de>
To: Charles Berry <ccberry@ucsd.edu>
Cc: emacs-orgmode@gnu.org
Subject: Re: [babel][PATCHES] ob-R patches for review
Date: Wed, 30 Apr 2014 14:28:28 +0200	[thread overview]
Message-ID: <m2zjj380ib.fsf@krugs.de> (raw)
In-Reply-To: <loom.20140429T185123-228@post.gmane.org> (Charles Berry's message of "Tue, 29 Apr 2014 18:15:47 +0000 (UTC)")

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

Charles Berry <ccberry@ucsd.edu> writes:

> Rainer M Krug <Rainer <at> krugs.de> writes:
>
>> 
>> Hi
>> 
>> 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 <ESS>/etc/ESSR/.

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. 

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:

- NIL :: no saving
- string :: saving under the name given



>
> HTH,

Yes definitely - discussions more then welcome,

Rainer

>
> Chuck
>
>
>
>
>

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

  reply	other threads:[~2014-04-30 12:29 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 [this message]
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
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

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2zjj380ib.fsf@krugs.de \
    --to=rainer@krugs.de \
    --cc=ccberry@ucsd.edu \
    --cc=emacs-orgmode@gnu.org \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).