From 57783f9ce288d9e14f2fde78f229e38298ccf53f Mon Sep 17 00:00:00 2001 From: Dan Davison Date: Tue, 26 May 2009 19:16:46 -0400 Subject: [PATCH 1/2] A few new TODOS: deal with hlines in tables, how do we pass multiple args in R, and some extended wittering about scoping issues in R: basically I want to argue for not abandoning the Sweave-style mode where objects created in code blocks are persisten across different blocks. --- org-babel.org | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 66 insertions(+), 1 deletion(-) diff --git a/org-babel.org b/org-babel.org index 6e522225f..985281176 100644 --- a/org-babel.org +++ b/org-babel.org @@ -114,7 +114,7 @@ table, allowing the test suite to be run be evaluation of the table and the results to be collected in the same table. -* Tasks [20/28] +* Tasks [20/31] ** TODO resolve references to other buffers This would allow source blocks to call upon tables, source-blocks, @@ -208,6 +208,70 @@ we should color these blocks differently *** TODO refine html exportation should use a span class, and should show original source in tool-tip +** TODO allow tables with hline to be passed as args into R + This doesn't seem to work at the moment (example below). It would + also be nice to have a natural way for the column names of the org + table to become the column names of the R data frame, and to have + the option to specify that the first column is to be used as row + names in R (these must be unique). But this might require a bit of + thinking about. + +#+TBLNAME: egtable +| col1 | col2 | col3 | +|------+---------+------| +| 1 | 2 | 3 | +| 4 | schulte | 6 | + +#+begin_src R var tabel=egtable +tabel +#+end_src + +** TODO pass mutliple reference arguments into R + Can we do this? I wasn't sure how to supply multiple 'var' header + args. +** TODO Create objects in top level (global) environment in R? + At the moment, objects created by computations performed in the + code block are evaluated in the scope of the + code-block-function-body and therefore disappear when the code + block is evaluated {unless you employ some extra trickery like + assign('name', object, env=globalenv()) }. I think it will be + desirable to also allow for a style wherein objects that are + created in one code block persist in the R global environment and + can be re-used in a separate block. + + This is what Sweave does, and while I'm not saying we have to be + the same as Sweave, it wouldn't be hard for us to provide the same + behaviour in this case; if we don't, we risk undeservedly being + written off as an oddity by some. + + IOW one aspect of org-babel is that of a sort of functional + meta-programming language. This is crazy, in a very good + way. Nevertheless, wrt R I think there's going to be a lot of value + in providing for a working style in which the objects are stored in + the R session, rather than elisp/org buffer. This will be a very + familiar working style to lots of people. + + There are no doubt a number of different ways of accomplishing + this, the simplest being a hack like adding + +#+begin_src R +for(objname in ls()) + assign(objname, get(objname), envir=globalenv()) +#+end_src + +to the source code block function body. (Maybe wrap it in an on.exit() call). + +However this may deserve to be thought about more carefully, perhaps +with a view to having a uniform approach across languages. E.g. shell +code blocks have the same semantics at the moment (no persistence of +variables across code blocks), because the body is evaluated in a new +bash shell process rather than a running shell. And I guess the same +is true for python. However, in both these cases, you could imagine +implementing the alternative in which the body is evaluated in a +persistent interactive session. It's just that it's particularly +natural for R, seeing as both ESS and org-babel evaluate commands in a +single persistent R session. + ** PROPOSED support for passing paths to files between source blocks Maybe this should be it's own result type (in addition to scalars and vectors). The reason being that some source-code blocks (for example @@ -1347,6 +1411,7 @@ x | 3.58355906547775 | | 3.01563442274226 | | 1.7634976849927 | + #+begin_src R var tabel=sandbox_r :results replace tabel #+end_src From 5db027b3e1c82f008d7a3607a21e1db6102185ac Mon Sep 17 00:00:00 2001 From: Dan Davison Date: Tue, 26 May 2009 19:40:47 -0400 Subject: [PATCH 2/2] Noted in hline TODO that plotting histogram in the grades example is blocked by not being able to deal with hline in the input table. (AIUI) --- org-babel.org | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/org-babel.org b/org-babel.org index 985281176..57b70e98f 100644 --- a/org-babel.org +++ b/org-babel.org @@ -68,11 +68,11 @@ pie(dirs[,1], labels = dirs[,2]) #+tblname: grades-table | student | grade | letter | |---------+-------+--------| -| 1 | 18 | F | -| 2 | 85 | B | -| 3 | 94 | A | -| 4 | 81 | B | -| 5 | 72 | C | +| 1 | 48 | F | +| 2 | 30 | F | +| 3 | 0 | F | +| 4 | 1 | F | +| 5 | 56 | F | | 6 | 46 | F | #+TBLFM: $2='(sbe random-score-generator)::$3='(sbe assign-grade (score $2)) @@ -95,7 +95,7 @@ rand(100) #+srcname: show-distribution #+begin_src R :var grades=grades-table - +hist(grades[,2]) #+end_src @@ -216,6 +216,7 @@ should use a span class, and should show original source in tool-tip names in R (these must be unique). But this might require a bit of thinking about. + #+TBLNAME: egtable | col1 | col2 | col3 | |------+---------+------| @@ -226,9 +227,11 @@ should use a span class, and should show original source in tool-tip tabel #+end_src +Another example is in the [[*operations%20in%20on%20tables][grades example]]. + ** TODO pass mutliple reference arguments into R Can we do this? I wasn't sure how to supply multiple 'var' header - args. + args. Just delete this TODO if I'm being dense. ** TODO Create objects in top level (global) environment in R? At the moment, objects created by computations performed in the code block are evaluated in the scope of the