From f87a673c9c3b430f60b5bcd928242fd019c21db0 Mon Sep 17 00:00:00 2001 From: Eric Schulte Date: Fri, 29 May 2009 18:01:38 -0700 Subject: [PATCH] replacing parts of org-babel lost in a merge namely some extended discussion of environments and sessions under the "Create objects in top level (global) environment in R?" header --- org-babel.org | 140 ++++++++++++++++++++++++++++++++++---------------- 1 file changed, 96 insertions(+), 44 deletions(-) diff --git a/org-babel.org b/org-babel.org index b7567174c..cd478536f 100644 --- a/org-babel.org +++ b/org-babel.org @@ -114,7 +114,102 @@ table, allowing the test suite to be run be evaluation of the table and the results to be collected in the same table. -* Tasks [21/32] +* Tasks [21/34] +** TODO Create objects in top level (global) environment in R? +*** initial requirement statement [DED] + 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. + +*** sessions [Eric] + +Thanks for bringing this up. I think you are absolutely correct that we +should provide support for a persistent environment (maybe called a +*session*) in which to evaluate code blocks. I think the current setup +demonstrates my personal bias for a functional style of programming +which is certainly not ideal in all contexts. + +While the R function you mention does look like an elegant solution, I +think we should choose an implementation that would be the same across +all source code types. Specifically I think we should allow the user to +specify an optional *session* as a header variable (when not present we +assume a default session for each language). The session name could be +used to name a comint buffer (like the *R* buffer) in which all +evaluation would take place (within which variables would retain their +values --at least once I remove some of the functional method wrappings +currently in place-- ). + +This would allow multiple environments to be used in the same buffer, +and once this setup was implemented we should be able to fairly easily +implement commands for jumping between source code blocks and the +related session buffers, as well as for dumping the last N commands from +a session into a new or existing source code block. + +Please let me know if you foresee any problems with this proposed setup, +or if you think any parts might be confusing for people coming from +Sweave. I'll hopefully find some time to work on this later in the +week. +*** implementation +in [[file:lisp/org-babel-comint.el][org-babel-comint.el]] + +Currently I've coppied and begun generalizing the functions for +interacting with R buffers. +** TODO fully purge org-babel-R of direct comint interaction +try to remove all code under the [[file:lisp/org-babel-R.el::functions%20for%20evaluation%20of%20R%20code][;; functions for evaluation of R code]] line + +** TODO improve the source-block snippet + +[[file:~/src/emacs-starter-kit/src/snippets/text-mode/rst-mode/chap::name%20Chapter%20title][file:~/src/emacs-starter-kit/src/snippets/text-mode/rst-mode/chap::name Chapter title]] +#+begin_example +,#name : Chapter title +,# -- +${1:Chapter} +${1:$(make-string (string-width text) ?\=)} + +$0 +#+end_example + +[[file:snippets/org-mode/sb][sb -- snippet]] + +waiting for guidance from those more familiar with yasnippets ** TODO resolve references to other buffers This would allow source blocks to call upon tables, source-blocks, @@ -261,49 +356,6 @@ Another example is in the [[*operations%20in%20on%20tables][grades example]]. shouldn't be too hard to implement either on our own, or possibly relying on something like noweb/notangle. -** PROPOSED 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