1 #+OPTIONS: H:3 num:nil toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:t skip:nil d:(HIDE) tags:not-in-toc
2 #+TITLE: rorg --- Code evaluation in org-mode, with an emphasis on R
3 #+SEQ_TODO: TODO PROPOSED | DONE DROPPED MAYBE
7 This project is basically about putting source code into org
8 files. This isn't just code to look pretty as a source code example,
9 but code to be evaluated. Org files have 3 main export targets: org,
10 html and latex. Once we have implemented a smooth bi-directional flow
11 of data between org-mode formats (including tables, and maybe lists
12 and property values) and source-code blocks, we will be able to use
13 org-mode's built in export to publish the results of evaluated source
14 code in any org-supported format using org-mode as an intermediate
15 format. We have a current focus on R code, but we are regarding that
16 more as a working example than as a defining feature of the project.
18 The main objectives of this project are...
20 # Lets start with this list and make changes as appropriate. Please
21 # try to make changes to this list, rather than starting any new
24 - [[* evaluation of embedded source code][evaluation of embedded source code]]
25 - [[* execution on demand and on export][execution on demand and on export]]
26 - [[* source blocks][source blocks]]
27 - [[* header arguments][header arguments]]
28 - [[* inline source evaluation][inline source evaluation]]
29 - [[* included source file evaluation][included source file evaluation]] ?? maybe
30 - [[* caching of evaluation][caching of evaluation]]
31 - [[* interaction with the source-code's process][interaction with the source-code's process]]
32 - [[* output of code evaluation][output of code evaluation]]
33 - [[* textual/numeric output][textual/numeric output]]
34 - [[* graphical output][graphical output]]
35 - [[* file creation][non-graphics file creation]]
36 - [[* side effects][side effects]]
37 - [[* reference to data and evaluation results][reference to data and evaluation results]]
38 - [[* reference format][reference format]]
39 - [[* source-target pairs][source-target pairs]]
40 - [[* source block output from org tables][source block output from org tables]]
41 - [[* source block outpt from other source block][source block outpt from other source block]]
42 - [[* source block output from org list][source block output from org list]] ?? maybe
43 - [[* org table from source block][org table from source block]]
44 - [[* org table from org table][org table from org table]]
45 - [[* org properties from source block][org properties from source block]]
46 - [[* org properties from org table][org properties from org table]]
47 - [[* export][export]]
50 * Objectives and Specs
52 ** evaluation of embedded source code
54 *** execution on demand and on export
55 Let's use an asterisk to indicate content which includes the
56 *result* of code evaluation, rather than the code itself. Clearly
57 we have a requirement for the following transformation:
61 Let's say this transformation is effected by a function
62 `org-eval-buffer'. This transformation is necessary when the
63 target format is org (say you want to update the values in an org
64 table, or generate a plot and create an org link to it), and it
65 can also be used as the first step by which to reach html and
70 org \to org* \to latex
72 Thus in principle we can reach our 3 target formats with
73 `org-eval-buffer', `org-export-as-latex' and `org-export-as-html'.
75 An extra transformation that we might want is
79 I.e. export to latex without evaluation of code, in such a way that R
80 code can subsequently be evaluated using
81 =Sweave(driver=RweaveLatex)=, which is what the R community is
82 used to. This would provide a `bail out' avenue where users can
83 escape org mode and enter a workflow in which the latex/noweb file
86 **** How do we implement `org-eval-buffer'?
88 AIUI The following can all be viewed as implementations of
89 org-eval-buffer for R code:
91 (see this question again posed in [[file:litorgy/litorgy-R.el::Maybe%20the%20following%20be%20replaced%20with%20a%20method%20using%20ess%20execute][litorgy-R.el]])
94 This is the beginnings of a general evaluation mechanism, that
95 could evaluate python, ruby, shell, perl, in addition to R.
96 The header says it's based on org-eval
100 org-eval was written by Carsten. It lives in the
101 org/contrib/lisp directory because it is too dangerous to
102 include in the base. Unlike org-eval-light org-eval evaluates
103 all source blocks in an org-file when the file is first opened,
104 which could be a security nightmare for example if someone
105 emailed you a pernicious file.
108 This accomplishes org \to org* in elisp by visiting code blocks
109 and evaluating code using ESS.
112 This accomplishes org \to org* using R via
114 : Sweave("file-with-unevaluated-code.org", driver=RweaveOrg, syntax=SweaveSyntaxOrg)
116 ***** org-exp-blocks.el
117 Like org-R, this achieves org \to org* in elisp by visiting code
118 blocks and using ESS to evaluate R code.
121 (see [[* Special editing and evaluation of source code][Special editing and evaluation of source code]])
124 (see [[* block headers/parameters][block headers/parameters]])
126 There are going to be many cases where we want to use header arguments
127 to change the evaluation options of source code, to pass external
128 information to a block of source code and control the inclusion of
131 *** inline source evaluation
132 *** included source file evaluation
133 It may be nice to be able to include an entire external file of source
134 code, and then evaluate and export that code as if it were in the
135 file. The format for such a file inclusion could optionally look like
138 : #+include_src filename header_arguments
140 *** caching of evaluation
142 Any kind of code that can have a block evaluated could optionally define
143 a function to write the output to a file, or to serialize the output of
144 the function. If a document or block is configured to cache input,
145 write all cached blocks to their own files and either a) hash them, or
146 b) let git and org-attach track them. Before a block gets eval'd, we
147 check to see if it has changed. If a document or block is configured to
148 cache output and a print/serialize function is available, write the
149 output of each cached block to its own file. When the file is eval'd
150 and some sort of display is called for, only update the display if the
151 output has changed. Each of these would have an override, presumably
152 something like (... & force) that could be triggered with a prefix arg
153 to the eval or export function.
157 #+begin_src emacs-lisp
158 ;; fake code that only pretends to work
159 (add-hook 'rorg-store-output-hook
160 '("r" lambda (block-environment block-label)
161 (ess-exec (concat "save.image("
163 ", file = " block-label
164 ".Rdata, compress=TRUE)"))))
167 The idea being that for r blocks that get eval'd, if output needs to be
168 stored, you should write the entire environment that was created in that
169 block to an Rdata file.
171 (see [[* block scoping][block scoping]])
173 ** interaction with the source-code's process
174 We should settle on a uniform API for sending code and receiving
175 output from a source process. Then to add a new language all we need
176 to do is implement this API.
178 for related notes see ([[* Interaction with the R process][Interaction with the R process]])
180 ** output of code evaluation
181 *** textual/numeric output
182 We (optionally) incorporate the text output as text in the target
185 We either link to the graphics or (html/latex) include them
188 I would say, if the block is being evaluated interactively then
189 lets pop up the image in a new window, and if it is being exported
190 then we can just include a link to the file which will be exported
191 appropriately by org-mode.
193 *** non-graphics files
194 ? We link to other file output
196 If we are using a continuous process in (for example an R process
197 handled by ESS) then any side effects of the process (for example
198 setting values of R variables) will be handled automatically
200 Are there side-effects which need to be considered aside from those
201 internal to the source-code evaluation process?
203 ** reference to data and evaluation results
204 I think this will be very important. I would suggest that since we
205 are using lisp we use lists as our medium of exchange. Then all we
206 need are functions going converting all of our target formats to and
207 from lists. These functions are already provided by for org tables.
209 It would be a boon both to org users and R users to allow org tables
210 to be manipulated with the R programming language. Org tables give R
211 users an easy way to enter and display data; R gives org users a
212 powerful way to perform vector operations, statistical tests, and
213 visualization on their tables.
215 This means that we will need to consider unique id's for source
216 blocks, as well as for org tables, and for any other data source or
221 Naive implementation would be to use =(org-export-table "tmp.csv")=
222 and =(ess-execute "read.csv('tmp.csv')")=.
224 org-R passes data to R from two sources: org tables, or csv
225 files. Org tables are first exported to a temporary csv file
226 using [[file:existing_tools/org-R.el::defun%20org%20R%20export%20to%20csv%20csv%20file%20options][org-R-export-to-csv]].
228 org-exp-blocks uses [[org-interblock-R-command-to-string]] to send
229 commands to an R process running in a comint buffer through ESS.
230 org-exp-blocks has no support for dumping table data to R process, or
237 This will be tricky, Dan has already come up with a solution for R, I
238 need to look more closely at that and we should try to come up with a
239 formats for referencing data from source-code in such a way that it
240 will be as source-code-language independent as possible.
242 Org tables already have a sophisticated reference system in place
243 that allows referencing table ranges in other files, as well as
244 specifying constants in the header arguments of a table. This is
245 described in [[info:org:References]].
247 **** Dan: thinking aloud re: referencing data from R
248 Suppose in some R code, we want to reference data in an org
249 table. I think that requires the use of 'header arguments', since
250 otherwise, under pure evaluation of a code block without header
251 args, R has no way to locate the data in the org buffer. So that
252 suggests a mechanism like that used by org-R whereby table names
253 or unique entry IDs are used to reference org tables (and indeed
254 potentially row/column ranges within org tables, although that
255 subsetting could also be done in R).
257 Specifically what org-R does is write the table to a temp csv
258 file, and tell R the name of that file. However:
260 1. We are not limited to a single source of input; the same sort
261 of thing could be done for several sources of input
263 2. I don't think we even have to use temp files. An alternative
264 would be to have org pass the table contents as a csv-format
265 string to textConnection() in R, thus creating an arbitrary
266 number of input objects in the appropriate R environment
267 (scope) from which the R code can read data when necessary.
269 That suggests a header option syntax something like
271 #+begin_src emacs-lisp
272 '(:R-obj-name-1 tbl-name-or-id-1 :R-obj-name-2 tbl-name-or-id-2)
275 As a result of passing that option, the code would be able to access
276 the data referenced by table-name-or-id-2 via read.table(R-obj-name-1).
278 An extension of that idea would be to allow remote files to be used as
279 data sources. In this case one might need just the remote file (if
280 it's a csv file), or if it's an org file then the name of the file
281 plus a table reference within that org file. Thus maybe something like
283 #+begin_src emacs-lisp
284 '((R-obj-name-1 . (:tblref tbl-name-or-id-1 :file file-1))
285 (R-obj-name-2 . (:tblref tbl-name-or-id-2 :file file-2)))
288 **** Eric: referencing data in general
289 So here's some thoughts for referencing data (henceforth referred to
290 as *resources*). I think this is the next thing we need to tackle for
291 implementation to move forward. We don't need to implement everything
292 below right off the bat, but I'd like to get these lists as full as
293 possible so we don't make any implementation assumptions which
296 We need to reference resources of the following types...
299 - output from a source code block (list or hash)
300 - property values of an outline header (hash)
302 - description list (hash)
305 All of these resources will live in org files which could be
307 - the current file (default)
308 - another file on the same system (path)
309 - another file on the web (url)
310 - another file in a git repo (file and commit hash)
312 What information should each of these resources be able to supply?
313 I'm thinking (again not that we'll implement all of these but just to
316 - ranges or points of vector data
317 - key/value pairs from a hash
318 - when the object was last modified
319 - commit info (author, date, message, sha, etc...)
320 - pointers to the resources upon which the resource relies
322 So we need a referencing syntax powerful enough to handle all of these
323 alternatives. Maybe something like =path:sha:name:range= where
325 - path :: is empty for the current file, is a path for files on the
326 same system, and is a url otherwise
327 - sha :: is an option git commit indicator
328 - name :: is the table/header/source-block name or id for location
329 inside of the org file (this would not be optional)
330 - range :: would indicate which information is requested from the
331 resource, so it could be a range to access parts of a
332 table, or the names of properties to be referenced from an
335 Once we agree on how this should work, I'll try to stub out some code,
336 so that we can get some simple subset of this functionality working,
337 hopefully something complex enough to do the following...
338 - [[* resource reference example][resource-reference-example]]
341 ****** multiple outputs
342 Do we want things like a source code block to leave multiple outputs,
343 or do we only want them to be able to output one vector or hash?
345 ****** environment (state and side-effects)
346 This design assumes that any changes will explicitly pass data in a
347 functional programming style. This makes no assumptions about things
348 like source code blocks changing state (in general state changes lead
349 to more difficult debugging).
351 - Do we want to take steps so ensure we do things like execute
352 consecutive R blocks in different environment, or do we want to
356 ****** passing arguments to resources
357 So I(eric) may be getting ahead of myself here, but what do you think
358 about the ability to pass arguments to resources. I'm having visions
359 of google map-reduce, processes spread out across multiple machines.
361 Maybe we could do this by allowing the arguments to be specified?
363 *** source-target pairs
365 The following can be used for special considerations based on
368 Dan: I don't quite understand this subtree; Eric -- could you give
369 a little more explanation of this and of your comment above
370 regarding using [[lists as our medium of exchange]]?
372 **** source block output from org tables
373 **** source block outpt from other source block
374 **** source block output from org list
375 **** org table from source block
376 **** org table from org table
377 **** org properties from source block
378 **** org properties from org table
381 once the previous objectives are met export should be fairly simple.
382 Basically it will consist of triggering the evaluation of source code
383 blocks with the org-export-preprocess-hook.
385 This block export evaluation will be aware of the target format
386 through the htmlp and latexp variables, and can then create quoted
387 =#+begin_html= and =#+begin_latex= blocks appropriately.
392 Unfortunately org-mode how two different block types, both useful.
393 In developing RweaveOrg, a third was introduced.
395 Eric is leaning towards using the =#+begin_src= blocks, as that is
396 really what these blocks contain: source code. Austin believes
397 that specifying export options at the beginning of a block is
398 useful functionality, to be preserved if possible.
400 Note that upper and lower case are not relevant in block headings.
402 *** PROPOSED block format
403 I (Eric) propose that we use the syntax of source code blocks as they
404 currently exist in org-mode with the addition of *evaluation*,
405 *header-arguments*, *exportation*, *single-line-blocks*, and
406 *references-to-table-data*.
408 1) *evaluation*: These blocks can be evaluated through =\C-c\C-c= with
409 a slight addition to the code already present and working in
410 [[file:existing_tools/org-eval-light.el][org-eval-light.el]]. All we should need to add for R support would
411 be an appropriate entry in [[org-eval-light-interpreters]] with a
412 corresponding evaluation function. For an example usinga
413 org-eval-light see [[* src block evaluation w/org-eval-light]].
415 2) *header-arguments*: These can be implemented along the lines of
416 Austin's header arguments in [[file:existing_tools/RweaveOrg/org-sweave.el][org-sweave.el]].
418 3) *exportation*: Should be as similar as possible to that done by
419 Sweave, and hopefully can re-use some of the code currently present
420 in [[file:existing_tools/exp-blocks/org-exp-blocks.el ][org-exp-blocks.el]].
422 4) *single-line-blocks*: It seems that it is useful to be able to
423 place a single line of R code on a line by itself. Should we add
424 syntax for this similar to Dan's =#+RR:= lines? I would lean
425 towards something here that can be re-used for any type of source
426 code in the same manner as the =#+begin_src R= blocks, maybe
427 =#+src_R=? Dan: I'm fine with this, but don't think single-line
428 blocks are a priority. My =#+R= lines were something totally
429 different: an attempt to have users specify R code implicitly,
430 using org-mode option syntax.
432 5) *references-to-table-data*: I get this impression that this is
433 vital to the efficient use of R code in an org file, so we should
434 come up with a way to reference table data from a single-line-block
435 or from an R source-code block. It looks like Dan has already done
436 this in [[file:existing_tools/org-R.el][org-R.el]].
441 : #+begin_src lang header-arguments
444 - lang :: the language of the block (R, shell, elisp, etc...)
445 - header-arguments :: a list of optional arguments which control how
446 the block is evaluated and exported, and how the results are handled
447 - body :: the actual body of the block
450 : #+begin_src lang body
451 - It's not clear how/if we would include header-arguments into a
452 single line block. Suggestions? Can we just leave them out? Dan:
453 I'm not too worried about single line blocks to start off
454 with. Their main advantage seems to be that they save 2 lines.
455 Eric: Fair enough, lets not worry about this now, also I would guess
456 that any code simple enough to fit on one line wouldn't need header
460 : #+include_src lang filename header-arguments
461 - I think this would be useful, and should be much more work (Dan:
462 didn't get the meaning of that last clause!?). Eric: scratch that,
463 I meant "*shouldn't* be too much work" :) That way whole external
464 files of source code could be evaluated as if they were an inline
465 block. Dan: again I'd say not a massive priority, as I think all the
466 languages we have in mind have facilities for doing this natively,
467 thus I think the desired effect can often be achieved from within a
468 #+begin_src block. Eric: Agreed, while this would be a nice thing
469 to include we shouldn't wast too much effort on it in the beginning.
471 What do you think? Does this accomplish everything we want to be able
472 to do with embedded R source code blocks?
474 ***** src block evaluation w/org-eval-light
475 here's an example using org-eval-light.el
477 first load the org-eval-light.el file
479 [[elisp:(load (expand-file-name "org-eval-light.el" (expand-file-name "existing_tools" (file-name-directory buffer-file-name))))]]
481 then press =\C-c\C-c= inside of the following src code snippet. The
482 results should appear in a comment immediately following the source
483 code block. It shouldn't be too hard to add R support to this
484 function through the `org-eval-light-interpreters' variable.
486 (Dan: The following causes error on export to HTML hence spaces inserted at bol)
493 **** Source code blocks
494 Org has an extremely useful method of editing source code and
495 examples in their native modes. In the case of R code, we want to
496 be able to use the full functionality of ESS mode, including
497 interactive evaluation of code.
499 Source code blocks look like the following and allow for the
500 special editing of code inside of the block through
505 ,## hit C-c ' within this block to enter a temporary buffer in r-mode.
507 ,## while in the temporary buffer, hit C-c C-c on this comment to
508 ,## evaluate this block
512 ,## hit C-c ' to exit the temporary buffer
516 dblocks are useful because org-mode will automatically call
517 `org-dblock-write:dblock-type' where dblock-type is the string
518 following the =#+BEGIN:= portion of the line.
520 dblocks look like the following and allow for evaluation of the
521 code inside of the block by calling =\C-c\C-c= on the header of
528 In developing RweaveOrg, Austin created [[file:existing_tools/RweaveOrg/org-sweave.el][org-sweave.el]]. This
529 allows for the kind of blocks shown in [[file:existing_tools/RweaveOrg/testing.Rorg][testing.Rorg]]. These blocks
530 have the advantage of accepting options to the Sweave preprocessor
531 following the #+BEGIN_R declaration.
533 *** block headers/parameters
534 Regardless of the syntax/format chosen for the source blocks, we will
535 need to be able to pass a list of parameters to these blocks. These
536 should include (but should certainly not be limited to)
537 - label or id :: Label of the block, should we provide facilities for
538 automatically generating a unique one of these?
539 - file :: names of file to which graphical/textual/numerical/tabular output
540 should be written. Do we need this, or should this be controlled
541 through the source code itself?
542 - results :: indication of where the results should be placed, maybe
543 the following values...
544 - append :: *default* meaning just append to the current buffer
545 immediately following the current source block
546 - replace :: like append, but replace any results currently there
547 - file :: save the results in a new file, and place a link to the
548 file into the current buffer immediately following the
550 - table :: save the results into a table, maybe use a table id:range
551 to identify which table and where therein
552 - nil :: meaning just discard the results
553 - not sure of a good name here :: flags for when/if the block should
554 be evaluated (on export etc...)
555 - again can't thing of a concise name :: flags for how the results of
556 the export should be displayed/included
557 - scope :: flag indicating whether the block should have a local or
559 - flags specific to the language of the source block
562 I think fleshing out this list is an important next step.
564 ** Interaction with the R process
566 We should take care to implement this in such a way that all of the
567 different components which have to interactive with R including:
568 - evaluation of source code blocks
569 - automatic evaluation on export
570 - evaluation of \R{} snippets
571 - evaluation of single source code lines
572 - evaluation of included source code files
573 - sending/receiving vector data
575 I think we currently have two implementations of interaction with R
576 processes; [[file:existing_tools/org-R.el][org-R.el]] and [[file:existing_tools/exp-blocks/org-exp-blocks.el ][org-exp-blocks.el]]. We should be sure to take
577 the best of each of these approaches.
579 More on the exchange of data at between org-mode and source code
580 blocks at [[* reference to data and evaluation results][reference to data and evaluation results]].
583 (see [[* caching of evaluation][caching of evaluation]])
585 This inadvertently raises the issue of scoping. The pretend function
586 pretends that we will create a block-local scope, and that we can save
587 just the things in that scope. Sweave takes the make-everything-global
588 approach. I can see advantages either way. If we make block-local
589 scopes, we can save each one independently, and generally speaking it
590 seems like more granularity==more control. If we make everything
591 global, we can refer to entities declared in earlier blocks without
592 having to explicitly import those entities into the current block. I
593 think this counts in the "need to think about it early on" category.
595 If we did want block-local scopes, in R we can start every eval with
598 ;; fake code that pretends to create a new, empty environment
599 (ess-exec (concat block-env " <- new.env()"))
600 (ess-exec (concat "eval(" block-contents ", envir=" block-env ")"))
602 If we decide we want block-scoping, I'm sure Dan and I can figure out
603 the right way to do this in R, if he hasn't already. I haven't thought
604 at all about how these scope issues generalize to, say, bash blocks.
606 Maybe this is something that should be controlled by a header
609 ** =\C-c\C-c= evaluation
611 With org-mode version at least 6.23, see the documentation for
612 [[info:org:Context-sensitive%20commands][info:org:Context-sensitive commands]].
614 ** free explicit variables
615 Maybe we should have some idea of variables independent of any
616 particular type of source code or source block. These could be
617 variables that have a value inside of the scope of the org-mode file,
618 and they could be used as a transport mechanism for information
619 transfer between org-tables, org-lists, and different source-blocks.
621 Each type of source code (and org-mode types like tables, lists,
622 etc...) would need to implement functions for converting different
623 types of data to and from these variables (which would be elisp
626 So for example say we want to read the values from a table into an R
627 block, perform some calculations, and then write the results back into
629 1) assign the table to a variable
630 - the table would be converted into a lisp vector (list of lists)
631 - the vector would be saved in the variable
632 2) an R source block would reference the variable
633 - the variable would be instantiated into an R variable (through
634 mechanisms mentioned [[* Dan: thinking aloud re: referencing data from R][elsewhere]])
635 - the R code is executed, and the value of the variable *inside of
637 - when the R block finished the value of the variable *globally in
638 the org buffer* would be updated
639 3) optionally the global value of the variable would be converted back
640 into an org-mode table and would be used to overwrite the existing
645 This might not be too different from what we were already talking
646 about, but I think the introduction of the idea of having variables
647 existing independently of any tables or source code blocks is novel
648 and probably has some advantages (and probably shortfalls).
652 ** TODO evaluation as background process? [DED]
654 *** TODO ability to select which of multiple R sessions is being used (like ess-switch-process in .R buffers)
655 *** TODO a header argument specifying silent evaluation (no output)
658 This is a place for code examples
660 ** litorgy.el beginning functionality
661 After evaluating litorgy.el and litorgy-script.el, you should be able
662 to evaluate the following blocks of code by pressing =\C-c\C-c= on the
663 header lines. *Note*: your version of org-mode must be at least 6.23
666 To run these examples open both [[file:litorgy/litorgy.el][litorgy.el]], [[file:litorgy/litorgy-script.el][litorgy-script.el]] and
667 evaluate them with =M-x eval-buffer=
669 #+begin_src sh :replace t
683 To run these examples open both [[file:litorgy/litorgy.el][litorgy.el]], [[file:litorgy/litorgy-R.el][litorgy-R.el]] and evaluate
684 them with =M-x eval-buffer=
686 #+begin_src R :replace t
698 First assign the variable with some sort of interpreted line
699 - this is independent of any particular type of source code
700 - this could use references to table ranges
704 ** resource reference example
706 This block holds an array of information written in [[http://www.yaml.org][YAML]]
718 This next block saves the information in the YAML array into the ruby
719 variable =ya= and then in ruby it multiplies each variable in the =ya=
723 #assign: ya = yaml-array
728 This final block takes the output of the ruby block, and writes it to
729 cell =0,0= through =0,3= of the table
732 #assign: self[0, (1..3)] = ruby-array
740 ** litorgy plays with tables
741 Alright, this should demonstrate both the ability of litorgy to read
742 tables into a lisp source code block, and to then convert the results
743 of the source code block into an org table. It's using the classic
744 "lisp is elegant" demonstration transpose function. To try this
747 1. evaluate [[file:litorgy/init.el]] to load litorgy and friends
748 2. evaluate the transpose definition =\C-u \C-c\C-c= on the beginning of
749 the source block (prefix arg to inhibit output)
750 3. evaluate the next source code block, this should read in the table
751 because of the =:var table=previous=, then transpose the table, and
752 finally it should insert the transposed table into the buffer
753 immediately following the block
757 #+begin_src emacs-lisp
758 (defun transpose (table)
759 (apply #'mapcar* #'list table))
766 #+begin_src emacs-lisp :var table=previous :replace t
770 #+begin_src emacs-lisp :var table=sandbox :replace t
776 #+begin_src ruby :var table=sandbox :replace t
777 table.first.join(" - ")
782 #+begin_src python :var table=sandbox :replace t
788 #+begin_src ruby :var table=sandbox :replace t
793 | 4 | "schulte" | 6 |
795 #+begin_src python :var table=sandbox :replace t
800 | 4 | "schulte" | 6 |
804 #+begin_src R :replace t
810 #+begin_src R :replace t
811 x <- c(rnorm(10, mean=-3, sd=1), rnorm(10, mean=3, sd=1))
815 : -2.059712 -1.299807 -2.518628 -4.319525 -1.944779 -5.345708 -3.921314
816 : -2.841109 -0.963475 -2.465979 4.092037 1.299202 1.476687 2.128594
817 : 3.200629 1.990952 1.888890 3.561541 3.818319 1.969161
822 I'm seeing this as like commit notes, and a place for less formal
823 communication of the goals of our changes.
825 ** Eric <2009-02-06 Fri 15:41>
826 I think we're getting close to a comprehensive set of objectives
827 (although since you two are the real R user's I leave that decision up
828 to you). Once we've agreed on a set of objectives and agreed on at
829 least to broad strokes of implementation, I think we should start
830 listing out and assigning tasks.
832 ** Eric <2009-02-09 Mon 14:25>
833 I've done a fairly destructive edit of this file. The main goal was
834 to enforce a structure on the document that we can use moving forward,
835 so that any future objective changes are all made to the main
838 I apologize for removing sections written by other people. I did this
839 when they were redundant or it was not clear how to fit them into this
840 structure. Rest assured if the previous text wasn't persisted in git
841 I would have been much more cautious about removing it.
843 I hope that this outline structure should be able to remain stable
844 through the process of fleshing out objectives, and cashing those
845 objectives out into tasks. That said, please feel free to make any
846 changes that you see fit.
848 ** Dan <2009-02-12 Thu 10:23>
849 Good job Eric with major works on this file.
851 ** Eric <2009-02-22 Sun 13:17>
852 So I skipped ahead and got started on the fun part. Namely stubbing
853 out some of the basic functionality. Please don't take any of the
854 decisions I've made so far (on things like names, functionality,
855 design etc...) as final decisions, I'm of course open to and hoping
858 So far [[file:litorgy/litorgy.el][litorgy.el]] and [[file:litorgy/litorgy-script.el][litorgy-script.el]] can be used to evaluate source
859 code blocks of simple scripting languages. It shouldn't be too hard
860 (any takers) to write a litorgy-R.el modeled after litorgy-script.el
861 to use for evaluating R code files.
863 See the [[* litorgy.el beginning functionality][Sandbox]] for evaluable examples.
865 ** Eric <2009-02-23 Mon 15:12>
866 While thinking about how to implement the transfer of data between
867 source blocks and the containing org-mode file, I decided it *might*
868 be useful to explicitly support the existence of variables which exist
869 independent of source blocks or tables. I'd appreciate any
870 feedback... (see [[free explicit variables][free explicit variables]])
872 ** Eric <2009-02-23 Mon 17:53>
873 So as I start populating this file with source code blocks I figure I
874 should share this... I don't know if you guys use [[http://code.google.com/p/smart-snippet/][yasnippet]] at all,
875 but if you do you might find this [[file:block][block-snippet]] org-mode snippet
876 useful (I use it all the time).
880 LocalWords: DBlocks dblocks litorgy el eric