From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer M Krug Subject: Re: Tangling with variables in R Date: Mon, 16 Jun 2014 14:15:17 +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]:38600) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WwVov-0005jd-Q9 for emacs-orgmode@gnu.org; Mon, 16 Jun 2014 08:15:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WwVol-00038Z-IL for emacs-orgmode@gnu.org; Mon, 16 Jun 2014 08:15:29 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:38468) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WwVol-00038V-8k for emacs-orgmode@gnu.org; Mon, 16 Jun 2014 08:15:19 -0400 Received: by mail-wi0-f174.google.com with SMTP id bs8so3951545wib.1 for ; Mon, 16 Jun 2014 05:15:18 -0700 (PDT) In-Reply-To: (Andreas Leha's message of "Wed, 11 Jun 2014 22:36:23 +0100") 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: Andreas Leha Cc: emacs-orgmode@gnu.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Andreas Leha writes: > Hi Rainer, Hi Andreas, > > Rainer M Krug writes: > >> 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: >> >> #+NAME: YEARS >> | | year | >> |---+---------------| >> | 1 | 1990 | >> | 2 | 2000 | >> #+PROPERTY: var+ YEARS=3DYEARS >> #+PROPERTY: var+ PRESENT=3D2008 >> >> >> I get the following code in the tangled .R file: >> >> ,---- >> | YEARS <- read.table("/var/folders/50/wcr5bjwn75q595n6x82gxj280000gn/T/= babel-97151aBD/R-import-97151vpn", >> | header=3DTRUE, >> | row.names=3D1, >> | sep=3D"\t", >> | as.is=3DTRUE) >> | 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. > > Me too, see http://thread.gmane.org/gmane.emacs.orgmode/51067 > OK - then I will include a fix to the tangling of tables issue in one of my first patches. > >> >> 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=20 >> >> 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: >> >> #+NAME: YEARS >> | | year | >> |---+---------------| >> | 1 | 1990 | >> | 2 | 2000 | >> #+PROPERTY: var+ YEARS=3DYEARS >> #+PROPERTY: var+ PRESENT=3D2008 >> >> #+begin_src R >> x <- 4 >> cat(x^2) >> #+end_src >> >> 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. > > These are good thoughts! Thanks. > > For the general question on whether tangling should directly reflect > weaving, there was a long (and fruitless) discussion or R-devel lately. > See http://thread.gmane.org/gmane.comp.lang.r.devel/36031 and maybe > http://thread.gmane.org/gmane.comp.lang.r.devel/36031/focus=3D36075 where > Yihui states that it is very hard to tangle code that produces the > same result as weaving. This might actually be easier in org than in > Sweave/knitr, but still the org setup will have a big impact, that would > be hard to replicate in the tangled R code. I agree completely - but it might be worth to try to go into this direction rather then blocking it with choosing the wrong approach initially. > > Setting aside the general question: > In my opinion, it should definitely be possible to tangle with > variables. I think the approach of the environments to address (2) is a > good one. OK - I will put some thoughts into this and see how it could be done easily and with limited rewuirements to supplementary files. > > > >> >> 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? >> > > See above. And thanks for your work on ob-R! Keep it up! Thanks - I will do. Your email comes at the right moment, as I was wondering if I am the only one using R and ESS and org. But I guess it is rather the inner workings do not impact on most users. I will see that I get the first set of patches together before the end of June (after this it is holidays). Cheers, Rainer > >> Thanks, >> >> Rainer >> >> Footnotes:=20 >> [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 > > > Best, > Andreas > > =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) iQEcBAEBAgAGBQJTnt/ZAAoJENvXNx4PUvmC8V4IAI+kMddMle7jV/phhlVn9opd TiVU5yNZZEDUlJTC93i+MpMn0h+LrAlk8Mm/t5UDHeV/V5Ml624W6mJifita01yo nFGu2qxPm3VGPodP1irdKgIetIrMpZJZ3NhYp4Cny0jVX7VVz35UsyVBUVQxjdpM /GNiNNkIQK6w2q/bbbRal7JjveWwVhD5g9LuLDqa4zm7OL5xZSFvsCaBqXF1Nujb GKUFlj+Ayh2BhqEeXP3d4NmoBQWi2ea/8eXx84VkznYMyE2R/2TNd9Z+79yjfmuf y7I27xoK85UuMfeB2+/pha/krrVXnwgv/R9nNd4sD+vYUSkZAm5kNbF4weEuhCY= =AeKi -----END PGP SIGNATURE----- --=-=-=--