emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Rainer M Krug <Rainer@krugs.de>
To: emacs-orgmode@gnu.org
Subject: Tangling with variables in R
Date: Mon, 02 Jun 2014 10:44:21 +0200	[thread overview]
Message-ID: <m238fng0pm.fsf@krugs.de> (raw)

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

Hi

I just realized (again) that tangling with variables in R contains many
particularities.

1) it only works with non-tables, i.e. single values.

When defining the following variables:

--8<---------------cut here---------------start------------->8---
#+NAME: YEARS
|   | year          |
|---+---------------|
| 1 | 1990          |
| 2 | 2000          |
#+PROPERTY: var+ YEARS=YEARS
#+PROPERTY: var+ PRESENT=2008
--8<---------------cut here---------------end--------------->8---

I get the following code in the tangled .R file:

,----
| YEARS <- read.table("/var/folders/50/wcr5bjwn75q595n6x82gxj280000gn/T/babel-97151aBD/R-import-97151vpn",
|                       header=TRUE,
|                       row.names=1,
|                       sep="\t",
|                       as.is=TRUE)
| PRESENT <- 2008
`----

Variable transfer from tables does not work, as it is based on a
temporary file, which is not easy to distribute together with the
tangled.R file and requires manual work as the path will be different.

I consider this as a bug which should be fixed.

2) With regards to variables which are defined non-file wide, (i.e. in
properties in a subtree and variables defined per code block and
function call), these are set when they occur in the tangled code, but
they are not unset *for the next code block* or *for R code in the next
subtree* (I hope you know what I mean). They are therefore similar to
the use of a session header argument instead of non-session evaluation
of the code.

This is a (conceptually) a more complex issue, and requires some initial
thought on how this should be dealt with and how the tangled code should
relate to the executed code.

- Should the tangled .R file result in the same output as the execution in
the org file, i.e. an accompanying .R file to a exported pdf, so that
the .R file can be used to reproduce the graphs and analysis in the .pdf
exported from the .org? or

- Is tangling a completely thing to execution, and the resulting R code
in the .R file is not expected to reproduce the results in the org file?

- Finally, does tangling with variables makes sense?

My opinions are 

a) *All* variables should be transferred to the .R file. This can be
already disabled via the :no-expand header argument. Unfortunately, this
is combined with noweb expansion, and it might be useful to split these
two, i.e. to be able to only disable variable expansion but to keep
noweb (I don't use noweb so far, so it is not a problem to me as it is
now).

b) The variable assignments should be per code block / function call. So
a tangled block should look as follow:

--8<---------------cut here---------------start------------->8---
#+NAME: YEARS
|   | year          |
|---+---------------|
| 1 | 1990          |
| 2 | 2000          |
#+PROPERTY: var+ YEARS=YEARS
#+PROPERTY: var+ PRESENT=2008

#+begin_src R
x <- 4
cat(x^2)
#+end_src
--8<---------------cut here---------------end--------------->8---

should result in something like the following:

,----
| ## # Set the variables
| YEARS <- TRANSFER_TABLE()
| PRESENT <- TRANSFER_VALUE()
| ## Here begins the real code
| x <- 4
| cat(x^2)
| ## # Unset all variables previously set
`----

but I prefer the following approach, as the result would be very
similar, only that the variables are still present afterwards which
would make debugging easier:

,----
| ## # Unset all variables previously set
| ## # Set the variables
| YEARS <- TRANSFER_TABLE()
| PRESENT <- TRANSFER_VALUE()
| ## Here begins the real code
| x <- 4
| cat(x^2)
`----

This is effectively already implemented by using R environments. See [1]
and particularly [2] and [3] for how it is implemented. This does not
yet address the concern about the transfer of tables, but I will look at
this.

Apologies for a long post, but I would like to know which direction of
the tangling / variable transfer from org to R should take - I don't
want to spend a lot of time solving a problem which does not really
exist.

So - any comments? Suggestions?

Thanks,

Rainer

Footnotes: 
[1]  https://github.com/rkrug/orgmode-dev

[2]  https://github.com/rkrug/orgmode-dev/blob/R-env/lisp/ob-R.el

[3]  https://github.com/rkrug/orgmode-dev/blob/R-env/etc/R/org_functions.R

-- 
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-06-02  8:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-02  8:44 Rainer M Krug [this message]
2014-06-11 21:36 ` Tangling with variables in R Andreas Leha
2014-06-16 12:15   ` Rainer M Krug
2014-06-17 12:54     ` Sebastien Vauban

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=m238fng0pm.fsf@krugs.de \
    --to=rainer@krugs.de \
    --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).