adding support for Haskell
[rgr-org-mode.git] / org-babel.org
blobd9d3dfaec5a6ecbea0b6aa637492cf0c08eef038
1 #+TITLE: org-babel --- facilitating communication between programming languages and people
2 #+SEQ_TODO: PROPOSED TODO STARTED | DONE DEFERRED REJECTED
3 #+OPTIONS:    H:3 num:nil toc:2 \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:t skip:nil d:(HIDE) tags:not-in-toc
4 #+STARTUP: oddeven hideblocks
6 #+begin_html 
7   <div id="subtitle">
8     <p>executable source code blocks in org-mode</p>
9   </div>
10   <div id="logo">
11     <p>
12       <img src="images/tower-of-babel.png"  alt="images/tower-of-babel.png" />
13       <div id="attr">from <a href="http://www.flickr.com/photos/23379658@N05/" title=""><b>Martijn Streefkerk</b></a></div>
14     </p>  
15   </div>
16 #+end_html
18 Org-Babel makes source-code blocks in Org-Mode executable and allows
19 data to pass seamlessly between different programming languages,
20 Org-Mode constructs (tables, file links, example text) and interactive
21 comint buffers.
23 In this document:
24 - The [[* Introduction][Introduction]] :: provides a brief overview of the design and use
25      of Org-Babel including tutorials and examples.
26 - In [[* Getting started][Getting Started]] :: find instructions for installing org-babel
27      into your emacs configuration.
28 - The [[* Tasks][Tasks]] :: section contains current and past tasks roughly ordered
29      by TODO state, then importance or date-completed.  This would be
30      a good place to suggest ideas for development.
31 - The [[* Bugs][Bugs]] :: section contains bug reports.
32 - The [[* Tests][Tests]] :: section consists of a large table which can be
33      evaluated to run Org-Babel's functional test suite.  This
34      provides a good overview of the current functionality with
35      pointers to example source blocks.
36 - The [[* Sandbox][Sandbox]] :: demonstrates much of the early/basic functionality
37      through commented source-code blocks.
39 Also see the [[file:library-of-babel.org][Library of Babel]], an extensible collection of ready-made
40 and easily-shortcut-callable source-code blocks for handling common
41 tasks.
43 * Introduction
45 Org-Babel enables *communication* between programming languages and
46 between people.
48 Org-Babel provides:
49 - communication between programs :: Data passes seamlessly between
50      different programming languages, Org-Mode constructs (tables,
51      file links, example text) and interactive comint buffers.
52 - communication between people :: Data and calculations are embedded
53      in the same document as notes explanations and reports.
55 ** communication between programs
57 Org-Mode supports embedded blocks of source code (in any language)
58 inside of Org documents.  Org-Babel allows these blocks of code to be
59 executed from within Org-Mode with natural handling of their inputs
60 and outputs.
62 *** simple execution
63 with both scalar, file, and table output
65 *** reading information from tables
67 *** reading information from other source blocks (disk usage in your home directory)
69 This will work for Linux and Mac users, not so sure about shell
70 commands for windows users.
72 To run place the cursor on the =#+begin_src= line of the source block
73 labeled directory-pie and press =\C-c\C-c=.
75 #+srcname: directories
76 #+begin_src bash :results replace
77 cd ~ && du -sc * |grep -v total
78 #+end_src
80 #+resname: directories
81 |       64 | "Desktop"   |
82 | 11882808 | "Documents" |
83 |  8210024 | "Downloads" |
84 |   879800 | "Library"   |
85 |    57344 | "Movies"    |
86 |  7590248 | "Music"     |
87 |  5307664 | "Pictures"  |
88 |        0 | "Public"    |
89 |      152 | "Sites"     |
90 |        8 | "System"    |
91 |       56 | "bin"       |
92 |  3274848 | "mail"      |
93 |  5282032 | "src"       |
94 |     1264 | "tools"     |
96 #+srcname: directory-pie
97 #+begin_src R :var dirs = directories :session R-pie-example
98 pie(dirs[,1], labels = dirs[,2])
99 #+end_src
106 *** operations in/on tables
108 #+tblname: grades-table
109 | student | grade | letter |
110 |---------+-------+--------|
111 |       1 |    99 | A      |
112 |       2 |    59 | F      |
113 |       3 |    75 | C      |
114 |       4 |    15 | F      |
115 |       5 |     7 | F      |
116 |       6 |    13 | F      |
117 #+TBLFM: $2='(sbe random-score-generator)::$3='(sbe assign-grade (score $2))
119 #+srcname: assign-grade
120 #+begin_src ruby :var score=99
121 case score
122    when 0..59: "F"
123    when 60..69: "D"
124    when 70..79: "C"
125    when 80..89: "B"
126    when 90..100: "A"
127    else "Invalid Score"
129 #+end_src
131 #+srcname: random-score-generator
132 #+begin_src ruby 
133 rand(100)
134 #+end_src
136 #+srcname: show-distribution
137 #+begin_src R :var grades=grades-table :session *R*
138 hist(grades$grade)
139 #+end_src
145 ** communication between people
146 Quick overview of Org-Mode's exportation abilities, with links to the
147 online Org-Mode documentation, a focus on source-code blocks, and the
148 exportation options provided by Org-Babel.
150 *** Interactive tutorial
151 This would demonstrate applicability to Reproducible Research, and
152 Literate Programming.
154 *** Tests embedded in documentation
155 org-babels own functional tests are contained in a large org-mode
156 table, allowing the test suite to be run be evaluation of the table
157 and the results to be collected in the same table.
159 *** Emacs initialization files stored in Org-Mode buffers
160 Using `org-babel-tangle' it is possible to embed your Emacs
161 initialization into org-mode files.  This allows for folding,
162 note-taking, todo's etc... embedded with the source-code of your Emacs
163 initialization, and through org-mode's publishing features aids in
164 sharing your customizations with others.
166 It may be worthwhile to create a fork of Phil Hagelberg's
167 [[http://github.com/technomancy/emacs-starter-kit/tree/master][emacs-starter-kit]] which uses literate org-mode files for all of the
168 actual elisp customization.  These org-mode files could then be
169 exported to html and used to populate the repositories wiki on [[http://github.com/][github]].
172 ** features
174 *** code evaluation (comint buffer sessions and external processes)
175 There are two main ways to evaluate source blocks with org-babel.
177 - external :: By default (if the =:session= header argument is not
178               present) all source code blocks are evaluated in
179               external processes.  In these cases an external process
180               is used to evaluate the source-code blocks.
181 - session :: Session based evaluation uses persistent sessions in
182              comint buffers.  Sessions can be used across multiple
183              source blocks setting and accessing variables in the
184              global environment.
186              Evaluating source blocks in sessions also allows for
187              interaction with the code.  To jump to the session of a
188              source block use the `org-babel-pop-to-session' command
189              or press =M-[down]= while inside of a source code block.
190              When called with a prefix argument
191              `org-babel-pop-to-session' will evaluate all header
192              arguments before jumping to the source-code block.
194 *** results (values and outputs)
195 Either the *value* or the *output* of source code blocks can be
196 collected after evaluation.
198 - value :: The default way to collect results from a source-code block
199            is to return the value of the last statement in the block.
200            This can be thought of as the return value of the block.
201            In this case any printed output of the block is ignored.
202            This can be though of a similar to a "functional" value of
203            evaluation.
204 - output :: Another way of generating results from a source-code block
205             is to collect the output generated by the execution of the
206             block.  In this case all printed output is collected
207             throughout the execution of the block.  This can be
208             thought of as similar to a "script" style of evaluation.
211 * Getting started
212 Add the following lines to your .emacs, replacing the path as
213 appropriate. A good place to check that things are up and running
214 would then be [[#sandbox][the sandbox]].
215 #+begin_src emacs-lisp
216   (add-to-list 'load-path "/path/to/org-babel/lisp")
217   (require 'org-babel-init)
218 #+end_src
220   
221 * Tasks [46/63]
222 ** PROPOSED allow `anonymous' function block with function call args?
223    My question here is simply whether we're going to allow
224 #+begin_src python(arg=ref)
225 # whatever
226 #+end_src
228 but with preference given to
229 #+srcname blockname(arg=ref)
230 ** PROPOSED allow :result as synonym for :results?
231 ** PROPOSED allow 'output mode to return stdout as value?
232    Maybe we should allow this. In fact, if block x is called
233    with :results output, and it references blocks y and z, then
234    shouldn't the output of x contain a concatenation of the outputs of
235    y and z, together with x's own output? That would raise the
236    question of what happens if y is defined with :results output and z
237    with :results value. I guess z's (possibly vector/tabular) output
238    would be inside a literal example block containing the whole lot.
239 ** PROPOSED optional timestamp for output
240    Add option to place an (inactive) timestamp at the #+resname, to
241    record when that output was generated.
243 *** source code block timestamps (optional addition)
244     [Eric] If we did this would we then want to place a timestamp on the
245     source-code block, so that we would know if the results are
246     current or out of date?  This would have the effect of caching the
247     results of calculations and then only re-running if the
248     source-code has changed.  For the caching to work we would need to
249     check not only the timestamp on a source-code block, but also the
250     timestamps of any tables or source-code blocks referenced by the
251     original source-code block.
253     [Dan] I do remember getting frustrated by Sweave always having to
254     re-do everything, so this could be desirable, as long as it's easy
255     to over-ride of course. I'm not sure it should be the default
256     behaviour unless we are very confident that it works well.
258 **** maintaining source-code block timestamps
259      It may make sense to add a hook to `org-edit-special' which could
260      update the source-code blocks timestamp.  If the user edits the
261      contents of a source-code block directly I can think of no
262      efficient way of maintaining the timestamp.
263 ** TODO make tangle files read-only?
264    With a file-local variable setting, yea that makes sense.  Maybe
265    the header should reference the related org-mode file.
267 ** TODO support for working with =*Org Edit Src Example*= buffers [4/6]
268 *** STARTED Patch against org source. 
269     I've worked on several related changes to source code edit buffer
270     behaviour in the org core.  My current patch (below) does the
271     following. Detailed explanation / working notes are below.
272     - C-x s offers to save edit buffers
273     - C-x C-c offers to save edit buffers
274     - C-x k warns that you're killing an edit buffer
275     - If you do kill an edit buffer, the overlay in the parent buffer is removed
276     - Edit buffers are named *Org Src <orgbuf>[<lang>]*, where
277       <orgbuf> is the name of the org-mode buffer containing this
278       source code block, and lang is the language major mode. The
279       latter might be unnecessary?
281 #+begin_example 
282 diff --git a/lisp/org-src.el b/lisp/org-src.el
283 index 2083c77..2be21e6 100644
284 --- a/lisp/org-src.el
285 +++ b/lisp/org-src.el
286 @@ -113,7 +113,7 @@ but which mess up the display of a snippet in Org exported files.")
288  (defvar org-src-mode-map (make-sparse-keymap))
289  (define-key org-src-mode-map "\C-c'" 'org-edit-src-exit)
290 -(define-key org-src-mode-map "\C-x\C-s" 'org-edit-src-save)
291 +;; (define-key org-src-mode-map "\C-x\C-s" 'org-edit-src-save)
292  (defvar org-edit-src-force-single-line nil)
293  (defvar org-edit-src-from-org-mode nil)
294  (defvar org-edit-src-picture nil)
295 @@ -168,7 +168,8 @@ the edited version."
296             (if (boundp 'org-edit-src-overlay)
297                 (org-delete-overlay org-edit-src-overlay)))
298           (kill-buffer buffer))
299 -       (setq buffer (generate-new-buffer "*Org Edit Src Example*"))
300 +       (setq buffer (generate-new-buffer
301 +                     (concat "*Org Src " (file-name-nondirectory buffer-file-name) "[" lang "]*")))
302         (setq ovl (org-make-overlay beg end))
303         (org-overlay-put ovl 'face 'secondary-selection)
304         (org-overlay-put ovl 'edit-buffer buffer)
305 @@ -186,8 +187,7 @@ the edited version."
306                                 '(display nil invisible nil intangible nil))
307         (org-do-remove-indentation)
308         (let ((org-inhibit-startup t))
309 -         (funcall lang-f)
310 -         (org-src-mode))
311 +         (funcall lang-f))
312         (set (make-local-variable 'org-edit-src-force-single-line) single)
313         (set (make-local-variable 'org-edit-src-from-org-mode) org-mode-p)
314         (when lfmt
315 @@ -201,6 +201,7 @@ the edited version."
316         (org-set-local 'org-edit-src-end-marker end)
317         (org-set-local 'org-edit-src-overlay ovl)
318         (org-set-local 'org-edit-src-nindent nindent)
319 +       (org-src-mode)
320         (and org-edit-src-persistent-message
321              (org-set-local 'header-line-format msg)))
322        (message "%s" msg)
323 @@ -400,12 +401,13 @@ the language, a switch telling of the content should be in a single line."
324  (defun org-edit-src-exit ()
325    "Exit special edit and protect problematic lines."
326    (interactive)
327 -  (unless (string-match "\\`*Org Edit " (buffer-name (current-buffer)))
328 -    (error "This is not an sub-editing buffer, something is wrong..."))
329 +  (unless org-edit-src-from-org-mode
330 +    (error "This is not a sub-editing buffer, something is wrong..."))
331    (let ((beg org-edit-src-beg-marker)
332         (end org-edit-src-end-marker)
333         (ovl org-edit-src-overlay)
334         (buffer (current-buffer))
335 +       (buffer-file-name nil)
336         (nindent org-edit-src-nindent)
337         code line)
338      (untabify (point-min) (point-max))
339 @@ -464,6 +466,17 @@ the language, a switch telling of the content should be in a single line."
340      (goto-char (min p (point-max)))
341      (message (or msg ""))))
343 +(defun org-src-mode-configure-buffer ()
344 +  (setq buffer-offer-save t)
345 +  (setq buffer-file-name
346 +       (concat (buffer-file-name (marker-buffer org-edit-src-beg-marker))
347 +               "[" (buffer-name) "]"))
348 +  (setq write-contents-functions '(org-edit-src-save))
349 +  (org-add-hook 'kill-buffer-hook
350 +               '(lambda () (org-delete-overlay org-edit-src-overlay)) nil 'local))
352 +(org-add-hook 'org-src-mode-hook 'org-src-mode-configure-buffer)
354  (provide 'org-src)
356  ;; arch-tag: 6a1fc84f-dec7-47be-a416-64be56bea5d8
357       
358 #+end_example
360 **** Detailed working notes to go with that patch
361 ***** Recap of current org-src-mode
362       
363       If you use C-c ' to work on code in a begin_source block, the code
364       buffer is put in minor mode org-src-mode, which features the
365       following two useful key-bindings:
367       | C-x s | org-edit-src-save | save the code in the source code block in the parent org file |
368       | C-c ' | org-edit-src-exit | return to the parent org file with new code                   |
370       Furthermore, while the edit buffer is alive, the originating code
371       block is subject to a special overlay which links to the edit
372       buffer when you click on it.
374       This is all excellent, and I use it daily, but I think there's
375       still a couple of improvements that we should make.
377 ***** Proposed bug I
378       C-x k kills the buffer without questions; the overlay remains, but
379       now links to a deleted buffer.
380 ***** Proposed bug II
381       C-x C-c kills a modified edit buffer silently, without offering to
382       save your work. I have lost work like that a number of times
383       recently.
384 ***** Proposed bug III
385       C-x s does not offer to save a modified edit buffer
386 ***** Notes on solution
387 ****** write-contents-functions
388        A good start seems to be to use org-src-mode-hook to add
389        org-edit-src-save to the write-contents-functions list. This
390        means that when it comes to saving, org-edit-src-save will be
391        called and no subsequent attempt will be made to save the buffer
392        in the normal way. (This should obviate the remapping of C-x C-s
393        to org-edit-src-save in org-src.el)
394 ****** buffer-offer-save
395        We also want to set this to t.
397 ****** Where does this get us?
399        - C-x s still does *not* offer to save the edit buffer. That's
400          because buffer-file-name is nil.
401        
402        - C-x C-c does ask us whether we want to save the
403          edit buffer. However, since buffer-file-name is nil it asks us
404          for a file name. The check in org-edit-src-exit throws an error
405          unless the buffer is named '* Org Edit '...
407        - C-x k kills the buffer silently, leaving a broken overlay
408          link. If buffer-file-name were set, it would have warned that
409          the buffer was modified.
411 ****** buffer-file-name
412        So, that all suggests that we need to set buffer-file-name, even
413        though we don't really want to associate this buffer with a file
414        in the normal way. As for the file name, my current suggestion
415        is parent-org-filename[edit-buffer-name].
416        
417        [I had to move the (org-src-mode) call to the end of
418        org-edit-src-code to make sure that the required variables were
419        defined when the hook was called.]
420        
421 ****** And so where are we now?
422        - C-x s *does* offer to save the edit buffer, but in saving
423          produces a warning that the edit buffer is modified.
424        - C-x k now gives a warning that the edit buffer is modified
425          (even if it's not).
426        - C-x C-c is working as desired, except that again we get
427          warnings that the edit buffer is modified, once when we save,
428          and again just before exiting emacs.
429        - And C-c ' now issues a warning that the edit buffer is
430          modified when we leave it, which we don't want.
431 ****** So, we need to get rid of the buffer modification warnings.
432        I've made buffer-file-name nil inside the let binding in
433        org-edit-src-exit.
434 ****** And?
435        - C-x s behaves as desired, except that as was already the case,
436          the edit buffer is always considered modified, and so repeated
437          invocations keep saving it.
438        - As was already the case, C-x k always gives a warning that the
439          edit buffer has been modified.
440        - C-x C-c is as desired (offers to save the edit buffer) except
441          that it warns of the modified buffer just before exiting.
442        - C-c ' is as it should be (silent)
443 ***** Conclusion
444       We've got the desired behaviour, at the cost of being forced to
445       assign a buffer-file-name to the edit buffer. The consequence is
446       that the edit buffer is considered to always be modified, since
447       a file of that name is never actually written to (doesn't even
448       exist). I couldn't see a way to trick emacs into believing that
449       the buffer was unmodified since last save. But in any case, I
450       think there's an argument that these modifications warnings are
451       a good thing, because one should not leave active edit buffers
452       around: you should always have exited with C-c ' first.
454 *** DONE name edit buffer according to #+srcname (and language?)
455     See above patch agains org.
456 *** DONE optionally evaluate header references when we switch to =*Org Edit Src*= buffer
457 That seems to imply that the header references need to be evaluated
458 and transformed into the target language object when we hit C-c ' to
459 enter the *Org Edit Src* buffer [DED]
461 Good point, I heartily agree that this should be supported [Eric]
463 (or at least before the first time we attempt to evaluate code in that
464 buffer -- I suppose there might be an argument for lazy evaluation, in
465 case someone hits C-c ' but is "just looking" and not actually
466 evaluating anything.) Of course if evaluating the reference is
467 computationally intensive then the user might have to wait before they
468 get the *Org Edit Src* buffer. [DED]
470 I fear that it may be hard to anticipate when the references will be
471 needed, some major-modes do on-the-fly evaluation while the buffer is
472 being edited.  I think that we should either do this before the buffer
473 is opened or not at all, specifically I think we should resolve
474 references if the user calls C-c ' with a prefix argument.  Does that
475 sound reasonable? [Eric]
477 Yes [Dan]
479 [Dan] So now that we have org-src-mode and org-src-mode-hook, I guess
480 org-babel should do this by using the hook to make sure that, when C-c
481 C-' is issued on a source block, any references are resolved and
482 assignments are made in the appropriate session.
484 #+tblname: my-little-table
485 | 1 | 2 |
486 | 3 | 4 |
488 #+srcname: resolve-vars-on-edit
489 #+begin_src ruby :var table=my-little-table :results silent :session test
490   table.size.times.do |n|
491     puts n
492   end
493 #+end_src
495 *** TODO set buffer-local-process variables appropriately [DED]
496     I think something like this would be great. You've probably
497 already thought of this, but just to note it down: it would be really
498 nice if org-babel's notion of a buffer's 'session/process' played
499 nicely with ESS's notion of the buffer's session/process. ESS keeps
500 the current process name for a buffer in a buffer-local variable
501 ess-local-process-name. So one thing we will probably want to do is
502 make sure that the *Org Edit Src Example* buffer sets that variable
503 appropriately. [DED]
505 I had not thought of that, but I agree whole heartedly. [Eric]
507 Once this is done every variable should be able to dump regions into
508 their inferior-process buffer using major-mode functions.
509 *** REJECTED send code to inferior process
510 Another thought on this topic: I think we will want users to send
511 chunks of code to the interpreter from within the *Org Edit Src*
512 buffer, and I think that's what you have in mind already. In ESS that
513 is done using the ess-eval-* functions. [DED]
515 I think we can leave this up to the major-mode in the source code
516 buffer, as almost every source-code major mode will have functions for
517 doing things like sending regions to the inferior process.  If
518 anything we might need to set the value of the buffer local inferior
519 process variable. [Eric]
521 *** DONE some possible requests/proposed changes for Carsten [4/4]
522     While I remember, some possible requests/proposed changes for Carsten
523     come to mind in that regard:
525 **** DONE Remap C-x C-s to save the source to the org buffer?
526      I've done this personally and I find it essential. I'm using 
527 #+begin_src emacs-lisp
528 (defun org-edit-src-save ()
529   "Update the parent org buffer with the edited source code, save
530 the parent org-buffer, and return to the source code edit
531 buffer."
532   (interactive)
533   (let ((p (point)))
534     (org-edit-src-exit)
535     (save-buffer)
536     (org-edit-src-code)
537     (goto-char p)))
539 (define-key org-exit-edit-mode-map "\C-x\C-s" 'org-edit-src-save)
540 #+end_src     
541     which seems to work.
543 I think this is great, but I think it should be implemented in the
544 org-mode core
546 **** DEFERRED Rename buffer and minor mode?
547      Something shorter than *Org Edit Src Example* for the buffer
548      name. org-babel is bringing org's source code interaction to a
549      level of maturity where the 'example' is no longer
550      appropriate. And if further keybindings are going to be added to
551      the minor mode then maybe org-edit-src-mode is a better name than
552      org-exit-edit-mode.
554      Maybe we should name the buffer with a combination of the source
555      code and the session.  I think that makes sense.
557      [ES] Are you also suggesting a new org-edit-src minor mode?
558      [DED] org-exit-edit-mode is a minor mode that already exists:
560      Minor mode installing a single key binding, "C-c '" to exit special edit.
562      org-edit-src-save now has a binding in that mode, so I guess all
563      I'm saying at this stage is that it's a bit of a misnomer. But
564      perhaps we will also have more functionality to add to that minor
565      mode, making it even more of a misnomer. Perhaps something like
566      org-src-mode would be better.
567 **** DONE Changed minor mode name and added hooks
568      
569 **** DONE a hook called when the src edit buffer is created
570      This should be implemented in the org-mode core
571 ** TODO resolve references to other org buffers/files
572    This would allow source blocks to call upon tables, source-blocks,
573    and results in other org buffers/files.
574    
575    See...
576    - [[file:lisp/org-babel-ref.el::TODO%20allow%20searching%20for%20names%20in%20other%20buffers][org-babel-ref.el:searching-in-other-buffers]]
577    - [[file:lisp/org-babel.el::defun%20org-babel%20find%20named%20result%20name][org-babel.el#org-babel-find-named-result]]
578 ** TODO resolve references to other non-org files
579    - tabular data in .csv, .tsv etc format
580    - files of interpreted code: anything stopping us giving such files
581      similar status to a source code block?
582    - Would be nice to allow org and non-org files to be remote
583 ** TODO Finalise behaviour regarding vector/scalar output
584 *** DONE Stop spaces causing vector output
585 This simple example of multilingual chaining produces vector output if
586 there are spaces in the message and scalar otherwise.
588 [Not any more]
590 #+srcname: msg-from-R(msg=msg-from-python)
591 #+begin_src R
592 paste(msg, "und R", sep=" ")
593 #+end_src
595 #+resname:
596 : org-babel speaks elisp y python und R
598 #+srcname: msg-from-python(msg=msg-from-elisp)
599 #+begin_src python
600 msg + " y python"
601 #+end_src
603 #+srcname: msg-from-elisp(msg="org-babel speaks")
604 #+begin_src emacs-lisp
605 (concat msg " elisp")
606 #+end_src
607 ** STARTED share org-babel [1/6]
608 how should we share org-babel?
609 *** DONE post to org-mode
610 *** TODO post to ess mailing list
611 *** TODO create a org-babel page on worg
612 *** TODO create a short screencast demonstrating org-babel in action
613 *** PROPOSED a peer-reviewed publication?
615     The following notes are biased towards statistics-oriented
616     journals because ESS and Sweave are written by people associated
617     with / in statistics departments. But I am sure there are suitable
618     journals out there for an article on using org mode for
619     reproducible research (and literate programming etc).
621     Clearly, we would invite Carsten to be involved with this.
623      ESS is described in a peer-reviewed journal article:
624      Emacs Speaks Statistics: A Multiplatform, Multipackage Development Environment for Statistical Analysis  [Abstract]
625      Journal of Computational & Graphical Statistics 13(1), 247-261
626      Rossini, A.J, Heiberger, R.M., Sparapani, R.A., Maechler, M., Hornik, K. (2004) 
627      [[http://www.amstat.org/publications/jcgs.cfm][Journal of Computational and Graphical Statistics]]
629      Also [[http://www.amstat.org/publications/jss.cfm][Journal of Statistical Software]] Established in 1996, the
630      Journal of Statistical Software publishes articles, book reviews,
631      code snippets, and software reviews. The contents are freely
632      available online. For both articles and code snippets, the source
633      code is published along with the paper.
635     Sweave has a paper: 
637     Friedrich Leisch and Anthony J. Rossini. Reproducible statistical
638     research. Chance, 16(2):46-50, 2003. [ bib ]
640     also
642     Friedrich Leisch. Sweave: Dynamic generation of statistical reports
643     using literate data analysis. In Wolfgang Härdle and Bernd Rönz,
644     editors, Compstat 2002 - Proceedings in Computational Statistics,
645     pages 575-580. Physica Verlag, Heidelberg, 2002. ISBN 3-7908-1517-9.
647     also
649     We could also look at the Journals publishing these [[http://www.reproducibleresearch.net/index.php/RR_links#Articles_about_RR_.28chronologically.29][Reproducible
650     Research articles]].
651     
652 *** PROPOSED an article in [[http://journal.r-project.org/][The R Journal]]
653 This looks good.  It seems that their main topic to software tools for
654 use by R programmers, and Org-babel is certainly that.
656 *** existing similar tools
657 try to collect pointers to similar tools 
659 Reproducible Research
660 - [[http://en.wikipedia.org/wiki/Sweave][Sweave]]
662 Literate Programming
663 - [[http://www.cs.tufts.edu/~nr/noweb/][Noweb]]
664 - [[http://www-cs-faculty.stanford.edu/~knuth/cweb.html][Cweb]]
665 - [[http://www.lri.fr/~filliatr/ocamlweb/][OCamlWeb]]
667 Meta Functional Programming
668 - ?
670 Programmable Spreadsheet
671 - ?
673 *** examples
674 we need to think up some good examples
676 **** interactive tutorials
677 This could be a place to use [[* org-babel assertions][org-babel assertions]].
679 for example the first step of a tutorial could assert that the version
680 of the software-package (or whatever) is equal to some value, then
681 source-code blocks could be used with confidence (and executed
682 directly from) the rest of the tutorial.
684 **** answering a text-book question w/code example
685 org-babel is an ideal environment enabling both the development and
686 demonstrationg of the code snippets required as answers to many
687 text-book questions.
689 **** something using tables
690 maybe something along the lines of calculations from collected grades
692 **** file sizes
693 Maybe something like the following which outputs sizes of directories
694 under the home directory, and then instead of the trivial =emacs-lisp=
695 block we could use an R block to create a nice pie chart of the
696 results.
698 #+srcname: sizes
699 #+begin_src bash :results replace
700 du -sc ~/*
701 #+end_src
703 #+begin_src emacs-lisp :var sizes=sizes :results replace
704 (mapcar #'car sizes)
705 #+end_src
706 *** Answer to question on list
707 From: Hector Villafuerte <hectorvd@gmail.com>
708 Subject: [Orgmode] Merge tables
709 Date: Wed, 19 Aug 2009 10:08:40 -0600
710 To: emacs-orgmode@gnu.org
713 I've just discovered Org and are truly impressed with it; using it for
714 more and more tasks.
716 Here's what I want to do: I have 2 tables with the same number of rows
717 (one row per subject). I would like to make just one big table by
718 copying the second table to the right of the first one. This is a
719 no-brainer in a spreadsheet but my attempts in Org have failed. Any
720 ideas?
722 By the way, thanks for this great piece of software!
723 -- 
724  hector
726 **** Suppose the tables are as follows
727 #+tblname: tab1
728 | a | b | c |
729 |---+---+---|
730 | 1 | 2 | 3 |
731 | 7 | 8 | 9 |
733 #+tblname: tab2
734 |  d |  e |  f |
735 |----+----+----|
736 |  4 |  5 |  6 |
737 | 10 | 11 | 12 |
739 **** Here is an answer using R in org-babel
741 #+srcname: column-bind(a=tab1, b=tab2)
742 #+begin_src R :colnames t
743 cbind(a, b)
744 #+end_src
746 #+resname: column-bind
747 | "a" | "b" | "c" | "d" | "e" | "f" |
748 |-----+-----+-----+-----+-----+-----|
749 |   1 |   2 |   3 |   4 |   5 |   6 |
750 |   7 |   8 |   9 |  10 |  11 |  12 |
753 **** Alternatively
754      Use org-table-export, do it in external spreadsheet software,
755      then org-table-import
756 ** TODO command line execution
757 Allow source code blocks to be called form the command line.  This
758 will be easy using the =sbe= function in [[file:lisp/org-babel-table.el][org-babel-table.el]].
760 This will rely upon [[* resolve references to other buffers][resolve references to other buffers]].
762 ** TODO inline source code blocks [3/5]
763    Like the =\R{ code }= blocks
765    not sure what the format should be, maybe just something simple
766    like =src_lang[]{}= where lang is the name of the source code
767    language to be evaluated, =[]= is optional and contains any header
768    arguments and ={}= contains the code.
770    (see [[* (sandbox) inline source blocks][the-sandbox]])
772 *** DONE evaluation with \C-c\C-c
773 Putting aside the header argument issue for now we can just run these
774 with the following default header arguments
775 - =:results= :: silent
776 - =:exports= :: results
778 *** DONE inline exportation
779 Need to add an interblock hook (or some such) through org-exp-blocks
780 *** DONE header arguments
781 We should make it possible to use header arguments.
783 *** TODO fontification
784 we should color these blocks differently
786 *** TODO refine html exportation
787 should use a span class, and should show original source in tool-tip
788 ** TODO LoB: re-implement plotting and analysis functions from org-R
789    I'll do this soon, now that we things are a bit more settled and we
790    have column names in R.
791 ** PROPOSED Creating presentations
792    The [[mairix:t:@@9854.1246500519@gamaville.dokosmarshall.org][recent thread]] containing posts by Nick Dokos and Sebastian
793    Vaubán on exporting to beamer looked very interesting, but I
794    haven't had time to try it out yet. I would really like it if,
795    eventually, we can generate a presentation (with graphics generated
796    by code blocks) from the same org file that contains all the notes
797    and code etc. I just wanted that to be on record in this document;
798    I don't have anything more profound to say about it at the moment,
799    and I'm not sure to what extent it is an org-babel issue.
800 ** PROPOSED conversion between org-babel and noweb (e.g. .Rnw) format
801    I haven't thought about this properly. Just noting it down. What
802    Sweave uses is called "R noweb" (.Rnw).
803    
804    I found a good description of noweb in the following article (see
805    the [[http://www.cs.tufts.edu/~nr/pubs/lpsimp.pdf][pdf]]).
806    
807    I think there are two parts to noweb, the construction of
808    documentation and the extraction of source-code (with notangle).
810    *documentation*: org-mode handles all of our documentation needs in
811    a manner that I believe is superior to noweb.
812    
813    *source extraction* At this point I don't see anyone writing large
814    applications with 100% of the source code contained in org-babel
815    files, rather I see org-babel files containing things like
816    - notes with active code chunks
817    - interactive tutorials
818    - requirements documents with code running test suites
819    - and of course experimental reports with the code to run the
820      experiment, and perform analysis
822    Basically I think the scope of the programs written in org-babel
823    (at least initially) will be small enough that it wont require the
824    addition of a tangle type program to extract all of the source code
825    into a running application.
827    On the other hand, since we already have named blocks of source
828    code which reference other blocks on which they rely, this
829    shouldn't be too hard to implement either on our own, or possibly
830    relying on something like noweb/notangle.
832 ** PROPOSED support for passing paths to files between source blocks
833 Maybe this should be it's own result type (in addition to scalars and
834 vectors).  The reason being that some source-code blocks (for example
835 ditaa or anything that results in the creation of a file) may want to
836 pass a file path back to org-mode which could then be inserted into
837 the org-mode buffer as a link to the file...
839 This would allow for display of images upon export providing
840 functionality similar to =org-exp-blocks= only in a more general
841 manner.
842 ** DEFERRED figure out how to handle errors during evaluation
843    I expect it will be hard to do this properly, but ultimately it
844    would be nice to be able to specify somewhere to receive STDERR,
845    and to be warned if it is non-empty.
847    Probably simpler in non-session evaluation than session? At least
848    the mechanism will be different I guess.
850    R has a try function, with error handling, along the lines of
851    python. I bet ruby does too. Maybe more of an issue for functional
852    style; in my proposed scripting style the error just gets dumped to
853    the org buffer and the user is thus alerted.
855    For now I think the current behavior of returning any error
856    messages generated by the source language is sufficient.
857 ** DEFERRED source-name visible in LaTeX and html exports
858 Maybe this should be done in backend specific manners.
860 The listings package may provide for naming a source-code block...
862 Actually there is no obvious simple and attractive way to implement
863 this.  Closing this issue for now.
864 ** DEFERRED Support rownames and other org babel table features?
866    The full org table features are detailed in the manual [[http://orgmode.org/manual/Advanced-features.html#Advanced-features][here]].
868 *** rownames
869    Perhaps add a :rownames header arg. This would be an integer
870     (usually 1) which would have the effect of post-processing all the
871     variables created in the R session in the following way: if the
872     integer is j, set the row names to the contents of column j and
873     delete column j. Perhaps it is artificial to allow this integer to
874     take any value other than 1. The default would be nil which would
875     mean no such behaviour.
877     Actually I don't know about that. If multiple variables are passed
878     in, it's not appropriate to alter them all in the same way. The
879     rownames specification would normally refer to just one of the
880     variables. For now maybe just say this has to be done in R. E.g.
882 #+TBLNAME: sample-sizes
883   | collection      | size | exclude | include | exclude2 | include2 |
884   |-----------------+------+---------+---------+----------+----------|
885   | 58C             | 2936 |       8 |    2928 |      256 |     2680 |
886   | MS              | 5852 |     771 |    5081 |      771 |     5081 |
887   | NBS             | 2929 |      64 |    2865 |      402 |     2527 |
888   | POBI            | 2717 |       1 |    2716 |        1 |     2716 |
889   | 58C+MS+NBS+POBI |      |         |   13590 |          |    13004 |
890 #+TBLFM: @2$4=@2$2 - @2$3::@2$6=@2$2 - @2$5::@3$4=@3$2-@3$3::@3$6=@3$2 - @3$5::@4$4=@4$2 - @4$3::@4$6=@4$2 - @4$5::@5$4=@5$2-@5$3::@5$6=@5$2 - @5$5::@6$4=vsum(@2$4..@5$4)::@6$6=vsum(@2$6..@5$6)
892 #+srcname: make-size-table(size=sample-sizes)
893 #+begin_src R 
894   rownames(size) <- size[,1]
895   size <- size[,-1]
896 #+end_src
899 *** Old notes
900     [I don't think it's as problematic as this makes out]
901     This is non-trivial, but may be worth doing, in particular to
902     develop a nice framework for sending data to/from R.
903 **** Notes
904     In R, indexing vector elements, and rows and columns, using
905     strings rather than integers is an important part of the
906     language.
907  - elements of a vector may have names
908  - matrices and data.frames may have "column names" and "row names"
909    which can be used for indexing
910  - In a data frame, row names *must* be unique
911 Examples
912 #+begin_example
913 > # a named vector
914 > vec <- c(a=1, b=2)
915 > vec["b"]
918 > mat <- matrix(1:4, nrow=2, ncol=2, dimnames=list(c("r1","r2"), c("c1","c2")))
919 > mat
920    c1 c2
921 r1  1  3
922 r2  2  4
923 > # The names are separate from the data: they do not interfere with operations on the data
924 > mat * 3
925    c1 c2
926 r1  3  9
927 r2  6 12
928 > mat["r1","c2"]
929 [1] 3
930 > df <- data.frame(var1=1:26, var2=26:1, row.names=letters)
931 > df$var2
932  [1] 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1
933 > df["g",]
934   var1 var2
935 g    7   20
936 #+end_example
938  So it's tempting to try to provide support for this in org-babel. For example
939  - allow R to refer to columns of a :var reference by their names
940  - When appropriate, results from R appear in the org buffer with "named
941    columns (and rows)"
943    However none (?) of the other languages we are currently supporting
944    really have a native matrix type, let alone "column names" or "row
945    names". Names are used in e.g. python and perl to refer to entries
946    in dicts / hashes.
948    It currently seems to me that support for this in org-babel would
949    require setting rules about when org tables are considered to have
950    named columns/fields, and ensuring that (a) languages with a notion
951    of named columns/fields use them appropriately and (b) languages
952    with no such notion do not treat then as data.
954  - Org allows something that *looks* like column names to be separated
955    by a hline
956  - Org also allows a row to *function* as column names when special
957    markers are placed in the first column. An hline is unnecessary
958    (indeed hlines are purely cosmetic in org [correct?]
959  - Org does not have a notion of "row names" [correct?]
960     
961    The full org table functionality exeplified [[http://orgmode.org/manual/Advanced-features.html#Advanced-features][here]] has features that
962    we would not support in e.g. R (like names for the row below).
963    
964 **** Initial statement: allow tables with hline to be passed as args into R
965    This doesn't seem to work at the moment (example below). It would
966    also be nice to have a natural way for the column names of the org
967    table to become the column names of the R data frame, and to have
968    the option to specify that the first column is to be used as row
969    names in R (these must be unique). But this might require a bit of
970    thinking about.
973 #+TBLNAME: egtable
974 | col1 | col2    | col3 |
975 |------+---------+------|
976 |    1 | 2       |    3 |
977 |    4 | schulte |    6 |
979 #+TBLNAME: egtable2
980 | 1 |         2 | 3 |
981 | 4 | schulte   | 6 |
983 #+begin_src R :var tabel=egtable :colnames t
984 tabel
985 #+end_src
987 #+resname:
988 | "col1" | "col2"    | "col3" |
989 |--------+-----------+--------|
990 |      1 | 2         |      3 |
991 |      4 | "schulte" |      6 |
994 Another example is in the [[*operations%20in%20on%20tables][grades example]].
995 ** DEFERRED use textConnection to pass tsv to R?
996    When passing args from the org buffer to R, the following route is
997    used: arg in buffer -> elisp -> tsv on file -> data frame in R. I
998    think it would be possible to avoid having to write to file by
999    constructing an R expression in org-babel-R-assign-elisp, something
1000    like this
1002 #+begin_src emacs-lisp
1003 (org-babel-R-input-command
1004  (format  "%s <- read.table(textConnection(\"%s\"), sep=\"\\t\", as.is=TRUE)"
1005           name (orgtbl-to-tsv value '(:sep "\t" :fmt org-babel-R-quote-tsv-field))))
1006 #+end_src
1008    I haven't tried to implement this yet as it's basically just
1009    fiddling with something that works. The only reason for it I can
1010    think of would be efficiency and I haven't tested that.
1012    This Didn't work after an initial test.  I still think this is a
1013    good idea (I also think we should try to do something similar when
1014    writing out results frmo R to elisp) however as it wouldn't result
1015    in any functional changes I'm bumping it down to deferred for
1016    now. [Eric]
1018 for quick tests
1020 #+tblname: quick-test
1021 | 1 | 2 | 3 |
1023 #+srcname: quick-test-src-blk
1024 #+begin_src R :var vec=quick-test
1025 mean(mean(vec))
1026 #+end_src
1028 #+resname:
1029 : 2
1032 : 2
1034 ** DEFERRED Rework Interaction with Running Processes [2/5]
1035 *** DONE robust to errors interrupting execution
1037 #+srcname: long-runner-ruby
1038 #+begin_src ruby :results silent
1039   sleep(10)
1040   :patton_is_an_grumpy
1041 #+end_src
1043 *** DEFERRED use =C-g= keyboard-quit to push processing into the background
1044 This may be possible using the `run-with-timer' command.
1046 I have no idea how this could work...
1048 #+srcname: long-runner-ruby
1049 #+begin_src ruby :results silent
1050   sleep(10)
1051   :patton_is_an_grumpy
1052 #+end_src
1054 *** TODO ability to select which of multiple sessions is being used
1055     Increasingly it is looking like we're going to want to run all
1056     source code blocks in comint buffer (sessions).  Which will have
1057     the benefits of
1058     1) allowing background execution
1059     2) maintaining state between source-blocks
1060        - allowing inline blocks w/o header arguments 
1062 **** R sessions
1063      (like ess-switch-process in .R buffers)
1064      
1065      Maybe this could be packaged into a header argument, something
1066      like =:R_session= which could accept either the name of the
1067      session to use, or the string =prompt=, in which case we could use
1068      the =ess-switch-process= command to select a new process.
1069      
1070 *** TODO evaluation of shell code as background process? 
1071     After C-c C-c on an R code block, the process may appear to
1072     block, but C-g can be used to reclaim control of the .org buffer,
1073     without interrupting the R evalution. However I believe this is not
1074     true of bash/sh evaluation. [Haven't tried other languages] Perhaps
1075     a solution is just to background the individual shell commands.
1077     The other languages (aside from emacs lisp) are run through the
1078     shell, so if we find a shell solution it should work for them as
1079     well.
1080     
1081     Adding an ampersand seems to be a supported way to run commands in
1082     the background (see [[http://www.emacswiki.org/emacs/ExecuteExternalCommand#toc4][external-commands]]).  Although a more extensible
1083     solution may involve the use of the [[elisp:(progn (describe-function 'call-process-region) nil)][call-process-region]] function.
1084     
1085     Going to try this out in a new file [[file:lisp/org-babel-proc.el][org-babel-proc.el]].  This should
1086     contain functions for asynchronously running generic shell commands
1087     in the background, and then returning their input.
1089 **** partial update of org-mode buffer
1090     The sleekest solution to this may be using a comint buffer, and
1091     then defining a filter function which would incrementally interpret
1092     the results as they are returned, including insertion into the
1093     org-mode buffer.  This may actually cause more problems than it is
1094     worth, what with the complexities of identifying the types of
1095     incrementally returned results, and the need for maintenance of a
1096     process marker in the org buffer.
1098 **** 'working' spinner
1099      It may be nice and not too difficult to place a spinner on/near the
1100      evaluating source code block
1102 *** TODO conversion of output from interactive shell, R (and python) sessions to org-babel buffers
1103     [DED] This would be a nice feature I think. Although an org-babel
1104     purist would say that it's working the wrong way round... After
1105     some interactive work in a *R* buffer, you save the buffer, maybe
1106     edit out some lines, and then convert it to org-babel format for
1107     posterity. Same for a shell session either in a *shell* buffer, or
1108     pasted from another terminal emulator. And python of course.
1109 ** DEFERRED improve the source-block snippet
1110 any real improvement seems somewhat beyond the ability of yasnippet
1111 for now.
1113 [[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]]
1114 #+begin_example
1115 ,#name : Chapter title
1116 ,# --
1117 ${1:Chapter}
1118 ${1:$(make-string (string-width text) ?\=)}
1121 #+end_example
1123 [[file:snippets/org-mode/sb][sb -- snippet]]
1125 waiting for guidance from those more familiar with yasnippets
1127 ** REJECTED re-implement R evaluation using ess-command or ess-execute
1128    I don't have any complaints with the current R evaluation code or
1129    behaviour, but I think it would be good to use the ESS functions
1130    from a political point of view. Plus of course it has the normal
1131    benefits of an API (insulates us from any underlying changes etc). [DED]
1133    I'll look into this.  I believe that I looked at and rejected these
1134    functions initially but now I can't remember why.  I agree with
1135    your overall point about using API's where available.  I will take
1136    a look back at these and either switch to using the ess commands,
1137    or at least articulate under this TODO the reasons for using our
1138    custom R-interaction commands. [Eric]
1140    ess-execute
1142    Lets just replace =org-babel-R-input-command= with =ess-execute=.
1144    I tried this, and although it works in some situations, I find that
1145    =ess-command= will often just hang indefinitely without returning
1146    results.  Also =ess-execute= will occasionally hang, and pops up
1147    the buffer containing the results of the command's execution, which
1148    is undesirable.  For now these functions can not be used.  Maybe
1149    someone more familiar with the ESS code can recommend proper usage
1150    of =ess-command= or some other lower-level function which could be
1151    used in place of [[file:lisp/org-babel-R.el::defun%20org-babel%20R%20input%20command%20command][org-babel-R-input-command]].
1153 *** ess functions
1154    
1155 #+begin_quote ess-command
1156 (ess-command COM &optional BUF SLEEP NO-PROMPT-CHECK)
1158 Send the ESS process command COM and delete the output
1159 from the ESS process buffer.  If an optional second argument BUF exists
1160 save the output in that buffer. BUF is erased before use.
1161 COM should have a terminating newline.
1162 Guarantees that the value of .Last.value will be preserved.
1163 When optional third arg SLEEP is non-nil, `(sleep-for (* a SLEEP))'
1164 will be used in a few places where `a' is proportional to `ess-cmd-delay'.
1165 #+end_quote
1167 #+begin_quote ess-execute
1168 (ess-execute COMMAND &optional INVERT BUFF MESSAGE)
1170 Send a command to the ESS process.
1171 A newline is automatically added to COMMAND.  Prefix arg (or second arg
1172 INVERT) means invert the meaning of
1173 `ess-execute-in-process-buffer'.  If INVERT is 'buffer, output is
1174 forced to go to the process buffer.  If the output is going to a
1175 buffer, name it *BUFF*.  This buffer is erased before use.  Optional
1176 fourth arg MESSAGE is text to print at the top of the buffer (defaults
1177 to the command if BUFF is not given.)
1178 #+end_quote
1180 *** out current setup
1182     1) The body of the R source code block is wrapped in a function
1183     2) The function is called inside of a =write.table= function call
1184        writing the results to a table
1185     3) The table is read using =org-table-import=
1186 ** DONE figure out how to handle graphic output
1187    
1188 This is listed under [[* graphical output][graphical output]] in out objectives.
1190 This should take advantage of the =:results file= option, and
1191 languages which almost always produce graphical output should set
1192 =:results file= to true by default (this is currently done for the
1193 gnuplot and ditaa languages).  That would handle placing these results
1194 in the buffer.  Then if there is a combination of =silent= and =file=
1195 =:results= headers we could drop the results to a temp buffer and pop
1196 open that buffer...
1198 Display of file results is addressed in the [[* =\C-c \C-o= to open results of source block][open-results-task]].
1200 I think this is done for now.  With the ability of the file option it
1201 is now possible to save images directly to a file.  Then calling
1202 =\C-c\C-o= with point on the source block will open the related
1203 results.
1205 *** R graphics to screen means session evaluation
1206     If R graphical output is going to screen then evaluation must be
1207     in a session, otherwise the graphics will disappear as soon as the
1208     R process dies.
1210 *** Adding to a discussion started in email
1211     I'm not deeply wedded to these ideas, just noting them down. I'm
1212     probably just thinking of R and haven't really thought about how
1213     this fits with the other graphics-generating languages.
1214 Dan:
1215 > I used the approach below to get graphical file output
1216 > today, which is one idea at least. Maybe it could be linked up with
1217 > your :results file variable. (Or do we need a :results image for R?)
1219 Eric:
1220 I don't think we need a special image results variable, but I may be
1221 missing what the code below accomplishes.  Would the task I added about
1222 adding org-open-at-point functionality to source code blocks take care
1223 of this need?
1225 Dan: I'm not sure. I think the ability for a script to generate both
1226 text and graphical output might be a natural expectation, at least for
1227 R users.
1230 > Dan
1232 > #+srcname: cohort-scatter-plots-2d(org_babel_graphical_output_file="cohort-scatter-plots-2d.png")
1233 > #+begin_src R 
1234 >   if(exists("org_babel_output_file"))
1235 >       png(filename=org_babel_graphical_output_file, width=1000, height=1000)
1236 >   ## plotting code in here
1237 >   if(exists("org_babel_graphical_output_file")) dev.off()
1238 > #+end_src
1240 Dan: Yes, the results :file option is nice for dealing with graphical
1241 output, and that could well be enough. Something based on the scheme
1242 above would have a couple of points in its favour:
1243 1. It's easy to switch between output going to on-screen graphics and
1244    output going to file: Output will go to screen unless a string variable
1245    with a standard name (e.g. ""org_babel_graphical_output_file"")
1246    exists in which case it will go to the file indicated by the value
1247    of that variable.
1248 2. The block can return a result / script output, as well as produce
1249    graphical output.
1251 In interactive use we might want to allow the user to choose between
1252 screen and file output. In non-interactive use such as export, it
1253 would be file output (subject to the :exports directives).
1254 ** DONE new results types (org, html, latex)
1255    Thanks to Tom Short for this recommendation.
1257    - raw or org :: in which case the results are implemented raw, unquoted
1258                    into the org-mode file.  This would also handle links as
1259                    source block output.
1260    - html :: the results are inserted inside of a #+BEGIN_HTML block
1261    - latex :: the results are inserted inside of a #+BEGIN_LATEX block
1263    It might look like:
1264 : #+begin_src R :session *R* :results org
1265 : cat("***** This is a table\n")
1266 : cat("| 1 | 2 | 3 |\n")
1267 : cat("[[http://google.com][Google it here]]\n"
1268 : #+end_src
1269 :        
1270 : #+resname:
1271 : ***** This is a table
1272 : | 1 | 2 | 3 |
1273 [[http://google.com][: Google it here]]
1275 We actually might want to remove the =#+resname= line if the results
1276 type is org-mode, not sure...  Either way I don't think there is a
1277 good way to capture/remove org type results.
1279 *** LaTeX
1280 #+srcname: latex-results
1281 #+begin_src emacs-lisp :results latex
1282 "this should be inside of a LaTeX block"
1283 #+end_src
1285 #+resname:
1286 #+BEGIN_LaTeX
1287 this should be inside of a LaTeX block
1288 #+END_LaTeX
1290 *** Html
1291 #+srcname: html-results
1292 #+begin_src emacs-lisp :results html
1293 "this should be inside of a HTML block
1297 and more
1301 is long"
1302 #+end_src
1304 #+resname:
1305 #+BEGIN_HTML
1306 this should be inside of a HTML block
1310 and more
1314 is long
1315 #+END_HTML
1317 *** raw
1319 Added a =raw= results header argument, which will insert the results
1320 of a source-code block into an org buffer un-escaped.  Also, if the
1321 results look like a table, then the table will be aligned.
1323 #+srcname: raw-table-demonstration
1324 #+begin_src ruby :results output raw
1325   puts "| root | square |"
1326   puts "|---"
1327   10.times do |n|
1328     puts "| #{n} | #{n*n} |"
1329   end
1330 #+end_src
1332 #+resname:
1333 | root | square |
1334 |------+--------|
1335 |    0 |      0 |
1336 |    1 |      1 |
1337 |    2 |      4 |
1338 |    3 |      9 |
1339 |    4 |     16 |
1340 |    5 |     25 |
1341 |    6 |     36 |
1342 |    7 |     49 |
1343 |    8 |     64 |
1344 |    9 |     81 |
1346 Not sure how/if this would work, but it may be desirable.
1347 ** DONE org-bable-tangle: no default extension if one already exists
1348 ** DONE take default values for header args from properties
1349    Use file-wide and subtree wide properties to set default values for
1350    header args.
1351    
1352    [DED] One thing I'm finding when working with R is that an org file
1353    may contain many source blocks, but that I just want to evaluate a
1354    subset of them. Typically this is in order to take up where I left
1355    off: I need to recreate a bunch of variables in the session
1356    environment. I'm thinking maybe we want to use a tag-based
1357    mechanism similar to :export: and :noexport: to control evaluation
1358    on a per-subtree basis.
1360 *** test-header with properties
1361     :PROPERTIES:
1362     :tangle:   yes
1363     :var:      def=8
1364     :END:
1366 Ahh... as is so often the case, just had to wrap
1367 `org-babel-params-from-properties' in a `save-match-data' form.
1369 #+tblname: why-def-props-cause-probs
1370 | 1 | 2 | 3 | 4 |
1372 #+srcname: default-props-implementation
1373 #+begin_src emacs-lisp :tangle no :var my-lis=why-def-props-cause-probs :results silent
1374 (+ (length my-lis) def)
1375 #+end_src
1377 ** DONE new reference syntax *inside* source code blocks
1378 This is from an email discussion on the org-mode mailing list with
1379 Sébastien.  The goal here is to mimic the source-block reference style
1380 of Noweb.  Upon export and/or tangle these references could be
1381 replaced with the actual body of the referenced source-code block.
1383 See the following for an example.
1385 #+srcname: ems-ruby-print-header
1386 #+begin_src ruby 
1387 puts "---------------------------header---------------------------"
1388 #+end_src
1390 #+srcname: emacs-ruby-print-footer
1391 #+begin_src ruby 
1392 puts "---------------------------footer---------------------------"
1393 #+end_src
1395 #+srcname: ems-ruby-print-message
1396 #+begin_src ruby :file ruby-noweb.rb
1397   # <<ems-ruby-print-header>>
1398   puts "                            Ruby                            "
1399   # <<ems-ruby-print-footer>>
1400 #+end_src
1402 Upon export the previous source-code block would result in a file
1403 being generated at =ruby-noweb.rb= with the following contents
1405 : puts "---------------------------header---------------------------"
1406 : puts "                            Ruby                            "
1407 : puts "---------------------------footer---------------------------"
1409 the body of a source-code block with all =<<src-name>>= references
1410 expanded can now be returned by `org-babel-expand-noweb-references'.
1411 This function is now called by default on all source-code blocks on
1412 export.
1414 ** DONE re-work tangling system
1415 Sometimes when tangling a file (e.g. when extracting elisp from a
1416 org-mode file) we want to get nearly every source-code block.
1418 Sometimes we want to only extract those source-code blocks which
1419 reference a indicate that they should be extracted (e.g. traditional
1420 literate programming along the Noweb model)
1422 I'm not sure how we can devise a single simple tangling system that
1423 naturally fits both of these use cases.
1425 *** new setup
1426 the =tangle= header argument will default to =no= meaning source-code
1427 blocks will *not* be exported by default.  In order for a source-code
1428 block to be tangled it needs to have an output file specified.  This
1429 can happen in two ways...
1431 1) a file-wide default output file can be passed to `org-babel-tangle'
1432    which will then be used for all blocks
1433 2) if the value of the =tangle= header argument is anything other than
1434    =no= or =yes= then it is used as the file name
1436 #+srcname: test-new-tangling
1437 #+begin_src emacs-lisp 
1438   (org-babel-load-file "test-tangle.org")
1439   (if (string= test-tangle-advert "use org-babel-tangle for all your emacs initialization files!!")
1440       "succeed"
1441     "fail")
1442 #+end_src
1444 #+resname:
1445 : succeed
1447 ** DONE =\C-c \C-o= to open results of source block
1448 by adding a =defadvice= to =org-open-at-point= we can use the common
1449 =\C-c \C-o= keybinding to open the results of a source-code block.
1450 This would be especially useful for source-code blocks which generate
1451 graphical results and insert a file link as the results in the
1452 org-mode buffer.  (see [[* figure out how to handle graphic output][TODO figure out how to handle graphic output]]).
1453 This could also act reasonably with other results types...
1455 - file :: use org-open-at-point to open the file
1456 - scalar :: open results unquoted in a new buffer
1457 - tabular :: export the table to a new buffer and open that buffer
1459 when called with a prefix argument the block is re-run
1461 #+srcname: task-opening-results-of-blocks
1462 #+begin_src ditaa :results replace :file blue.png :cmdline -r
1463 +---------+
1464 | cBLU    |
1465 |         |
1466 |    +----+
1467 |    |cPNK|
1468 |    |    |
1469 +----+----+
1470 #+end_src
1472 #+resname:
1473 [[file:blue.png][blue.png]]
1475 #+srcname: task-open-vector
1476 #+begin_src emacs-lisp
1477 '((1 2) (3 4))
1478 #+end_src
1480 #+resname:
1481 | 1 | 2 |
1482 | 3 | 4 |
1484 #+srcname: task-open-scalar
1485 #+begin_src ruby :results output
1486   8.times do |n|
1487     puts "row #{n}"
1488   end
1489 #+end_src
1491 #+resname:
1492 : row 0
1493 : row 1
1494 : row 2
1495 : row 3
1496 : row 4
1497 : row 5
1498 : row 6
1499 : row 7
1501 ** DONE Stop spaces causing vector output
1502 This simple example of multilingual chaining produces vector output if
1503 there are spaces in the message and scalar otherwise.
1505 [Not any more]
1507 #+srcname: msg-from-R(msg=msg-from-python)
1508 #+begin_src R
1509 paste(msg, "und R", sep=" ")
1510 #+end_src
1512 #+resname:
1513 : org-babel speaks elisp y python und R
1515 #+srcname: msg-from-python(msg=msg-from-elisp)
1516 #+begin_src python
1517 msg + " y python"
1518 #+end_src
1520 #+srcname: msg-from-elisp(msg="org-babel speaks")
1521 #+begin_src emacs-lisp
1522 (concat msg " elisp")
1523 #+end_src
1525 ** DONE add =:tangle= family of header arguments
1526 values are
1527 - no :: don't include source-code block when tangling
1528 - yes :: do include source-code block when tangling
1530 this is tested in [[file:test-tangle.org::*Emacs%20Lisp%20initialization%20stuff][test-tangle.org]]
1532 ** DONE extensible library of callable source blocks
1533 *** Current design
1534     This is covered by the [[file:library-of-babel.org][Library of Babel]], which will contain
1535     ready-made source blocks designed to carry out useful common tasks.
1536 *** Initial statement [Eric]
1537     Much of the power of org-R seems to be in it's helper functions for
1538     the quick graphing of tables.  Should we try to re-implement these
1539     functions on top of org-babel?
1541     I'm thinking this may be useful both to add features to org-babel-R and
1542     also to potentially suggest extensions of the framework.  For example
1543     one that comes to mind is the ability to treat a source-code block
1544     like a function which accepts arguments and returns results. Actually
1545     this can be it's own TODO (see [[* source blocks as functions][source blocks as functions]]).
1546 *** Objectives [Dan]
1547     - We want to provide convenient off-the-shelf actions
1548       (e.g. plotting data) that make use of our new code evaluation
1549       environment but do not require any actual coding.
1550 *** Initial Design proposal [Dan]
1551     - *Input data* will be specified using the same mechanism as :var
1552       references, thus the input data may come from a table, or
1553       another source block, and it is initially available as an elisp
1554       data structure.
1555     - We introduce a new #+ line, e.g.  #+BABELDO. C-c C-c on that
1556       line will apply an *action* to the referenced data.
1557     - *Actions correspond to source blocks*: our library of available
1558       actions will be a library of org-babel source blocks. Thus the
1559       code for executing an action, and the code for dealing with the
1560       output of the action will be the same code as for executing
1561       source blocks in general
1562     - Optionally, the user can have the relevant source block inserted
1563       into the org buffer after the (say) #+BABELDO line. This will
1564       allow the user to fine tune the action by modifying the code
1565       (especially useful for plots).
1566     - So maybe a #+BABELDO line will have header args
1567       - :data (a reference to a table or source code block)
1568       - :action (or should that be :srcname?) which will be something
1569         like :action pie-chart, referring to a source block which will
1570         be executed with the :data referent passed in using a :var arg.
1571       - :showcode or something controlling whether to show the code
1572       
1573 *** Modification to design
1574     I'm implementing this, at least initially, as a new interpreter
1575     named 'babel', which has an empty body. 'babel' blocks take
1576     a :srcname header arg, and look for the source-code block with
1577     that name. They then execute the referenced block, after first
1578     appending their own header args on to the target block's header
1579     args.
1581     If the target block is in the library of babel (a.o.t. e.g. the
1582     current buffer), then the code in the block will refer to the
1583     input data with a name dictated by convention (e.g. __data__
1584     (something which is syntactically legal in all languages...). Thus
1585     the babel block will use a :var __data__ = whatever header arg to
1586     reference the data to be plotted.
1588 ** DONE Column names in R input/output
1589    This has been implemented: Automatic on input to R; optional in
1590    output. Note that this equates column names with the header row in
1591    an org table; whereas org actually has a mechanism whereby a row
1592    with a '!' in the first field defines column names. I have not
1593    attempted to support these org table mechanisms yet. See [[*Support%20rownames%20and%20other%20org%20babel%20table%20features][this
1594    DEFERRED todo item]].
1595 ** DONE use example block for large amounts of stdout output?
1596    We're currently `examplizing' with : at the beginning of the line,
1597    but should larger amounts of output be in a
1598    \#+begin_example...\#+end_example block? What's the cutoff? > 1
1599    line?  This would be nice as it would allow folding of lengthy
1600    output. Sometimes one will want to see stdout just to check
1601    everything looks OK, and then fold it away.
1603    I'm addressing this in branch 'examplizing-output'.
1604    Yea, that makes sense.  (either that or allow folding of large
1605    blocks escaped with =:=).
1607    Proposed cutoff of 10 lines, we can save this value in a user
1608    customizable variable.
1609 *** DONE add ability to remove such results
1610 ** DONE exclusive =exports= params
1611    
1612 #+srcname: implement-export-exclusivity
1613 #+begin_src ruby 
1614 :this_is_a_test
1615 #+end_src
1617 #+resname:
1618 : :this_is_a_test
1619 ** DONE LoB: allow output in buffer
1620 ** DONE allow default header arguments by language
1621 org-babel-default-header-args:lang-name
1623 An example of when this is useful is for languages which always return
1624 files as their results (e.g. [[*** ditaa][ditaa]], and [[*** gnuplot][gnuplot]]).
1625 ** DONE singe-function tangling and loading elisp from literate org-mode file [3/3]
1627 This function should tangle the org-mode file for elisp, and then call
1628 `load-file' on the resulting tangled file.
1630 #+srcname: test-loading-embedded-emacs-lisp
1631 #+begin_src emacs-lisp :results replace
1632   (setq test-tangle-advert nil)
1633   (setq test-tangle-loading nil)
1634   (setq results (list :before test-tangle-loading test-tangle-advert))
1635   (org-babel-load-file "test-tangle.org")
1636   (setq results (list (list :after test-tangle-loading test-tangle-advert) results))
1637   (delete-file "test-tangle.el")
1638   (reverse results)
1639 #+end_src
1641 #+resname: test-loading-embedded-emacs-lisp
1642 | :before | nil                 | nil                                                              |
1643 | :after  | "org-babel tangles" | "use org-babel-tangle for all your emacs initialization files!!" |
1645 *** DONE add optional language limiter to org-babel-tangle
1646 This should check to see if there is any need to re-export
1648 *** DONE ensure that org-babel-tangle returns the path to the tangled file(s)
1650 #+srcname: test-return-value-of-org-babel-tangle
1651 #+begin_src emacs-lisp :results replace
1652   (mapcar #'file-name-nondirectory (org-babel-tangle-file "test-tangle.org" "emacs-lisp"))
1653 #+end_src
1655 #+resname:
1656 | "test-tangle.el" |
1658 *** DONE only tangle the file if it's actually necessary
1659 ** DONE add a function to jump to a source-block by name
1660    I've had an initial stab at that in org-babel-find-named-block
1661    (library-of-babel branch).
1663    At the same time I introduced org-babel-named-src-block-regexp, to
1664    match src-blocks with srcname.
1666    This is now working with the command
1667    `org-babel-goto-named-source-block', all we need is a good key
1668    binding.
1670 ** DONE add =:none= session argument (for purely functional execution) [4/4]
1671 This would allow source blocks to be run in their own new process
1673 - These blocks could then also be run in the background (since we can
1674   detach and just wait for the process to signal that it has terminated)
1675 - We wouldn't be drowning in session buffers after running the tests
1676 - we can re-use much of the session code to run in a more /functional/
1677   mode
1679 While session provide a lot of cool features, like persistent
1680 environments, [[* DONE function to bring up inferior-process buffer][pop-to-session]], and hints at exportation for
1681 org-babel-tangle, they also have some down sides and I'm thinking that
1682 session-based execution maybe shouldn't be the default behavior.
1684 Down-sides to sessions
1685 - *much* more complicated than functional evaluation
1686   - maintaining the state of the session has weird issues
1687   - waiting for evaluation to finish
1688   - prompt issues like [[* TODO weird escaped characters in shell prompt break shell evaluation][shell-prompt-escapes-bug]]
1689 - can't run in background
1690 - litter emacs with session buffers
1692 *** DONE ruby
1694 #+srcname: ruby-task-no-session
1695 #+begin_src ruby :results replace output
1696 puts :eric
1697 puts :schulte
1698 [1, 2, 3]
1699 #+end_src
1701 #+resname: ruby-task-no-session
1702 | "eric"    |
1703 | "schulte" |
1704 *** DONE python
1706 #+srcname: task-python-none-session
1707 #+begin_src python :session none :results replace value
1708 print 'something'
1709 print 'output'
1710 [1, 2, 3]
1711 #+end_src
1713 #+resname: task-python-none-session
1714 | 1 | 2 | 3 |
1716 *** DONE sh
1718 #+srcname: task-session-none-sh
1719 #+begin_src sh :results replace
1720 echo "first"
1721 echo "second"
1722 #+end_src
1724 #+resname: task-session-none-sh
1725 | "first"  |
1726 | "second" |
1728 *** DONE R
1730 #+srcname: task-no-session-R
1731 #+begin_src R :results replace output
1732 a <- 8
1733 b <- 9
1734 a + b
1735 b - a
1736 #+end_src
1738 #+resname: task-no-session-R
1739 | "[1]" | 17 |
1740 | "[1]" |  1 |
1742 ** DONE fully purge org-babel-R of direct comint interaction
1743 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
1745 ** DONE Create objects in top level (global) environment [5/5]
1746 *sessions*
1748 *** initial requirement statement [DED]
1749    At the moment, objects created by computations performed in the
1750    code block are evaluated in the scope of the
1751    code-block-function-body and therefore disappear when the code
1752    block is evaluated {unless you employ some extra trickery like
1753    assign('name', object, env=globalenv()) }. I think it will be
1754    desirable to also allow for a style wherein objects that are
1755    created in one code block persist in the R global environment and
1756    can be re-used in a separate block.
1758    This is what Sweave does, and while I'm not saying we have to be
1759    the same as Sweave, it wouldn't be hard for us to provide the same
1760    behaviour in this case; if we don't, we risk undeservedly being
1761    written off as an oddity by some.
1763    IOW one aspect of org-babel is that of a sort of functional
1764    meta-programming language. This is crazy, in a very good
1765    way. Nevertheless, wrt R I think there's going to be a lot of value
1766    in providing for a working style in which the objects are stored in
1767    the R session, rather than elisp/org buffer. This will be a very
1768    familiar working style to lots of people.
1770    There are no doubt a number of different ways of accomplishing
1771    this, the simplest being a hack like adding
1773 #+begin_src R
1774 for(objname in ls())
1775     assign(objname, get(objname), envir=globalenv())
1776 #+end_src
1778 to the source code block function body. (Maybe wrap it in an on.exit() call).
1780 However this may deserve to be thought about more carefully, perhaps
1781 with a view to having a uniform approach across languages. E.g. shell
1782 code blocks have the same semantics at the moment (no persistence of
1783 variables across code blocks), because the body is evaluated in a new
1784 bash shell process rather than a running shell. And I guess the same
1785 is true for python. However, in both these cases, you could imagine
1786 implementing the alternative in which the body is evaluated in a
1787 persistent interactive session. It's just that it's particularly
1788 natural for R, seeing as both ESS and org-babel evaluate commands in a
1789 single persistent R session.
1791 *** sessions [Eric]
1793 Thanks for bringing this up.  I think you are absolutely correct that we
1794 should provide support for a persistent environment (maybe called a
1795 *session*) in which to evaluate code blocks.  I think the current setup
1796 demonstrates my personal bias for a functional style of programming
1797 which is certainly not ideal in all contexts.
1799 While the R function you mention does look like an elegant solution, I
1800 think we should choose an implementation that would be the same across
1801 all source code types.  Specifically I think we should allow the user to
1802 specify an optional *session* as a header variable (when not present we
1803 assume a default session for each language).  The session name could be
1804 used to name a comint buffer (like the *R* buffer) in which all
1805 evaluation would take place (within which variables would retain their
1806 values --at least once I remove some of the functional method wrappings
1807 currently in place-- ).
1809 This would allow multiple environments to be used in the same buffer,
1810 and once this setup was implemented we should be able to fairly easily
1811 implement commands for jumping between source code blocks and the
1812 related session buffers, as well as for dumping the last N commands from
1813 a session into a new or existing source code block.
1815 Please let me know if you foresee any problems with this proposed setup,
1816 or if you think any parts might be confusing for people coming from
1817 Sweave.  I'll hopefully find some time to work on this later in the
1818 week.
1820 *** can functional and interpreted/interactive models coexist?
1822 Even though both of these use the same =*R*= buffer the value of =a=
1823 is not preserved because it is assigned inside of a functional
1824 wrapper.
1826 #+srcname: task-R-sessions
1827 #+begin_src R 
1828 a <- 9
1829 b <- 21
1830 a + b
1831 #+end_src
1833 #+srcname: task-R-same-session
1834 #+begin_src R 
1836 #+end_src
1838 This functional wrapper was implemented in order to efficiently return
1839 the results of the execution of the entire source code block.  However
1840 it inhibits the evaluation of source code blocks in the top level,
1841 which would allow for persistence of variable assignment across
1842 evaluations.  How can we allow *both* evaluation in the top level, and
1843 efficient capture of the return value of an entire source code block
1844 in a language independent manner?
1846 Possible solutions...
1847 1) we can't so we will have to implement two types of evaluation
1848    depending on which is appropriate (functional or imperative)
1849 2) we remove the functional wrapper and parse the source code block
1850    into it's top level statements (most often but not always on line
1851    breaks) so that we can isolate the final segment which is our
1852    return value.
1853 3) we add some sort of "#+return" line to the code block
1854 4) we take advantage of each languages support for meta-programming
1855    through =eval= type functions, and use said to evaluate the entire
1856    blocks in such a way that their environment can be combined with the
1857    global environment, and their results are still captured.
1858 5) I believe that most modern languages which support interactive
1859    sessions have support for a =last_result= type function, which
1860    returns the result of the last input without re-calculation.  If
1861    widely enough present this would be the ideal solution to a
1862    combination of functional and imperative styles.
1864 None of these solutions seem very desirable, but for now I don't see
1865 what else would be possible.
1867 Of these options I was leaning towards (1) and (4) but now believe
1868 that if it is possible option (5) will be ideal.
1870 **** (1) both functional and imperative evaluation
1871 Pros
1872 - can take advantage of built in functions for sending regions to the
1873   inferior process
1874 - retains the proven tested and working functional wrappers
1876 Cons
1877 - introduces the complication of keeping track of which type of
1878   evaluation is best suited to a particular context
1879 - the current functional wrappers may require some changes in order to
1880   include the existing global context
1882 **** (4) exploit language meta-programming constructs to explicitly evaluate code
1883 Pros
1884 - only one type of evaluation
1886 Cons
1887 - some languages may not have sufficient meta-programming constructs
1889 **** (5) exploit some =last_value= functionality if present
1891 Need to ensure that most languages have such a function, those without
1892 will simply have to implement their own similar solution...
1894 | language   | =last_value= function       |
1895 |------------+-----------------------------|
1896 | R          | .Last.value                 |
1897 | ruby       | _                           |
1898 | python     | _                           |
1899 | shell      | see [[* last command for shells][last command for shells]] |
1900 | emacs-lisp | see [[* emacs-lisp will be a special case][special-case]]            |
1902 #+srcname: task-last-value
1903 #+begin_src ruby
1904 82 + 18
1905 #+end_src
1907 ***** last command for shells
1908 Do this using the =tee= shell command, and continually pipe the output
1909 to a file.
1911 Got this idea from the following [[http://linux.derkeiler.com/Mailing-Lists/Fedora/2004-01/0898.html][email-thread]].
1913 suggested from mailing list
1915 #+srcname: bash-save-last-output-to-file
1916 #+begin_src sh 
1917 while read line 
1918 do 
1919   bash -c "$line" | tee /tmp/last.out1 
1920   mv /tmp/last.out1 /tmp/last.out 
1921 done
1922 #+end_src
1924 another proposed solution from the above thread
1926 #+srcname: bash-save-in-variable
1927 #+begin_src sh 
1928 #!/bin/bash 
1929 # so - Save Output. Saves output of command in OUT shell variable. 
1930 OUT=`$*` 
1931 echo $OUT 
1932 #+end_src
1934 and another
1936 #+begin_quote
1937 .inputrc: 
1938 "^[k": accept-line 
1939 "^M": " | tee /tmp/h_lastcmd.out ^[k" 
1941 .bash_profile: 
1942 export __=/tmp/h_lastcmd.out 
1944 If you try it, Alt-k will stand for the old Enter; use "command $__" to 
1945 access the last output. 
1947 Best, 
1951 Herculano de Lima Einloft Neto
1952 #+end_quote
1954 ***** emacs-lisp will be a special case
1955 While it is possible for emacs-lisp to be run in a console type
1956 environment (see the =elim= function) it is *not* possible to run
1957 emacs-lisp in a different *session*.  Meaning any variable set top
1958 level of the console environment will be set *everywhere* inside
1959 emacs.  For this reason I think that it doesn't make any sense to
1960 worry about session support for emacs-lisp.
1962 *** Further thoughts on 'scripting' vs. functional approaches
1964     These are just thoughts, I don't know how sure I am about this.
1965     And again, perhaps I'm not saying anything very radical, just that
1966     it would be nice to have some options supporting things like
1967     receiving text output in the org buffer.
1969     I can see that you've already gone some way down the road towards
1970     the 'last value' approach, so sorry if my comments come rather
1971     late. I am concerned that we are not giving sufficient attention
1972     to stdout / the text that is returned by the interpreters. In
1973     contrast, many of our potential users will be accustomed to a
1974     'scripting' approach, where they are outputting text at various
1975     points in the code block, not just at the end. I am leaning
1976     towards thinking that we should have 2 modes of evaluation:
1977     'script' mode, and 'functional' mode.
1979     In script mode, evaluation of a code block would result in *all*
1980     text output from that code block appearing as output in the org
1981     buffer, presumably as an #+begin_example...#+end_example. There
1982     could be an :echo option controlling whether the input commands
1983     also appear in the output. [This is like Sweave].
1985     In functional mode, the *result* of the code block is available as
1986     an elisp object, and may appear in the org buffer as an org
1987     table/string, via the mechanisms you have developed already.
1989     One thing I'm wondering about is whether, in script mode, there
1990     simply should not be a return value. Perhaps this is not so
1991     different from what exists: script mode would be new, and what
1992     exists currently would be functional mode.
1994     I think it's likely that, while code evaluation will be exciting
1995     to people, a large majority of our users in a large majority of
1996     their usage will not attempt to actually use the return value from
1997     a source code block in any meaningful way. In that case, it seems
1998     rather restrictive to only allow them to see output from the end
1999     of the code block.
2001     Instead I think the most accessible way to introduce org-babel to
2002     people, at least while they are learning it, is as an immensely
2003     powerful environment in which to embed their 'scripts', which now
2004     also allows them to 'run' their 'scripts'. Especially as such
2005     people are likely to be the least capable of the user-base, a
2006     possible design-rule would be to make the scripting style of usage
2007     easy (default?), perhaps requiring a special option to enable a
2008     functional style. Those who will use the functional style won't
2009     have a problem understanding what's going on, whereas the 'skript
2010     kiddies' might not even know the syntax for defining a function in
2011     their language of choice. And of course we can allow the user to
2012     set a variable in their .emacs controlling the preference, so that
2013     functional users are not inconveniennced by having to provide
2014     header args the whole time.
2016     Please don't get the impression that I am down-valuing the
2017     functional style of org-babel. I am constantly horrified at the
2018     messy 'scripts' that my colleagues produce in perl or R or
2019     whatever! Nevertheless that seems to be how a lot of people work.
2020     
2021     I think you were leaning towards the last-value approach because
2022     it offered the possibility of unified code supporting both the
2023     single evaluation environment and the functional style. If you
2024     agree with any of the above then perhaps it will impact upon this
2025     and mean that the code in the two branches has to differ a bit. In
2026     that case, functional mode could perhaps after all evaluate each
2027     code block in its own environment, thus (re)approaching 'true'
2028     functional programming (side-effects are hard to achieve).
2030 #+begin_src sh
2031 ls > files
2032 echo "There are `wc -l files` files in this directory"
2034 #+end_src
2036 *** even more thoughts on evaluation, results, models and options
2038 Thanks Dan, These comments are invaluable.
2040 What do you think about this as a new list of priorities/requirements
2041 for the execution of source-code blocks.
2043 - Sessions
2044    1)  we want the evaluation of the source code block to take place in a
2045        session which can persist state (variables, current directory,
2046        etc...).
2047    2)  source code blocks can specify their session with a header argument
2048    3)  each session should correspond to an Emacs comint buffer so that the
2049        user can drop into the session and experiment with live code
2050        evaluation.
2051 - Results
2052   1) each source-code block generates some form of results which (as
2053      we have already implemented) is transfered into emacs-lisp
2054      after which it can be inserted into the org-mode buffer, or
2055      used by other source-code blocks
2056   2) when the results are translated into emacs-lisp, forced to be
2057      interpreted as a scalar (dumping their raw values into the
2058      org-mode buffer), as a vector (which is often desirable with R
2059      code blocks), or interpreted on the fly (the default option).
2060      Note that this is very nearly currently implemented through the
2061      [[* DONE results-type header (vector/file)][results-type-header]].
2062   3) there should be *two* means of collecting results from the
2063      execution of a source code block.  *Either* the value of the
2064      last statement of the source code block, or the collection of
2065      all that has been passed to STDOUT during the evaluation.
2067 **** header argument or return line (*header argument*)
2069    Rather than using a header argument to specify how the return value
2070    should be passed back, I'm leaning towards the use of a =#+RETURN=
2071    line inside the block.  If such a line *is not present* then we
2072    default to using STDOUT to collect results, but if such a line *is
2073    present* then we use it's value as the results of the block.  I
2074    think this will allow for the most elegant specification between
2075    functional and script execution.  This also cleans up some issues
2076    of implementation and finding which statement is the last
2077    statement.
2079    Having given this more thought, I think a header argument is
2080    preferable.  The =#+return:= line adds new complicating syntax for
2081    something that does little more than we would accomplish through
2082    the addition of a header argument.  The only benefit being that we
2083    know where the final statement starts, which is not an issue in
2084    those languages which contain 'last value' operators.
2086    new header =:results= arguments
2087    - script :: explicitly states that we want to use STDOUT to
2088                initialize our results
2089    - return_last :: stdout is ignored instead the *value* of the final
2090                     statement in the block is returned
2091    - echo :: means echo the contents of the source-code block along
2092              with the results (this implies the *script* =:results=
2093              argument as well)
2095 *** DONE rework evaluation lang-by-lang [4/4]
2097 This should include...
2098 - functional results working with the comint buffer
2099 - results headers
2100   - script :: return the output of STDOUT
2101     - write a macro which runs the first redirection, executes the
2102       body, then runs the second redirection
2103   - last :: return the value of the last statement
2104     - 
2106 - sessions in comint buffers
2108 **** DONE Ruby [4/4]
2109 - [X] functional results working with comint
2110 - [X] script results
2111 - [X] ensure scalar/vector results args are taken into consideration
2112 - [X] ensure callable by other source block
2114 #+srcname: ruby-use-last-output
2115 #+begin_src ruby :results replace
2116 a = 2
2117 b = 4
2118 c = a + b
2119 [a, b, c, 78]
2120 #+end_src
2122 #+resname: ruby-use-last-output
2123 | 2 | 4 | 6 | 78 |
2125 #+srcname: task-call-use-last-output
2126 #+begin_src ruby :var last=ruby-use-last-output :results replace
2127 last.flatten.size + 1
2128 #+end_src
2130 #+resname: task-call-use-last-output
2131 : 5
2133 ***** ruby sessions
2135 #+srcname: first-ruby-session-task
2136 #+begin_src ruby :session schulte :results silent
2137 schulte = 27
2138 #+end_src
2140 #+srcname: second-ruby-session-task
2141 #+begin_src ruby :session schulte :results silent
2142 schulte + 3
2143 #+end_src
2145 #+srcname: without-the-right-session
2146 #+begin_src ruby :results silent
2147 schulte
2148 #+end_src
2150 **** DONE R [4/4]
2152 - [X] functional results working with comint
2153 - [X] script results
2154 - [X] ensure scalar/vector results args are taken into consideration
2155 - [X] ensure callable by other source block
2157 To redirect output to a file, you can use the =sink()= command.
2159 #+srcname: task_R_B
2160 #+begin_src R :results value vector silent
2161 a <- 9
2162 b <- 10
2163 b - a
2164 a + b
2165 #+end_src
2167 #+srcname: task-R-use-other-output
2168 #+begin_src R :var twoentyseven=task_R_B() :results replace value
2170 twoentyseven + 9
2171 #+end_src
2173 #+resname: task-R-use-other-output
2174 : 28
2176 **** DONE Python [4/4]
2177 - [X] functional results working with comint
2178 - [X] script results
2179 - [X] ensure scalar/vector results args are taken into consideration
2180 - [X] ensure callable by other source block
2182 #+srcname: task-new-eval-for-python
2183 #+begin_src python :results silent output scalar
2187 #+end_src
2189 #+srcname: task-use-new-eval
2190 #+begin_src python :var tasking=task-new-eval-for-python() :results replace
2191 tasking + 2
2192 #+end_src
2194 #+resname: task-use-new-eval
2195 : 12
2197 **** DONE Shells [4/4]
2198 - [X] functional results working with comint
2199 - [X] script results
2200 - [X] ensure scalar/vector results args are taken into consideration
2201 - [X] ensure callable by other source block
2203 #+srcname: task-shell-new-evaluation
2204 #+begin_src sh :results silent value scalar
2205 echo 'eric'
2206 date
2207 #+end_src
2209 #+srcname: task-call-other-shell
2210 #+begin_src sh :var other=task-shell-new-evaluation() :results replace  scalar
2211 echo $other ' is the old date'
2212 #+end_src
2214 #+resname: task-call-other-shell
2215 : $ Fri Jun 12 13:08:37 PDT 2009  is the old date
2217 *** DONE implement a *session* header argument [4/4]
2218 =:session= header argument to override the default *session* buffer
2220 **** DONE ruby
2222 #+srcname: task-ruby-named-session
2223 #+begin_src ruby :session schulte :results replace
2224 schulte = :in_schulte
2225 #+end_src
2227 #+resname: task-ruby-named-session
2228 : :in_schulte
2230 #+srcname: another-in-schulte
2231 #+begin_src ruby :session schulte 
2232 schulte
2233 #+end_src
2235 #+resname: another-in-schulte
2236 : :in_schulte
2237 : :in_schulte
2238 : :in_schulte
2240 **** DONE python
2242 #+srcname: python-session-task
2243 #+begin_src python :session what :results silent
2244 what = 98
2245 #+end_src
2247 #+srcname: python-get-from-session
2248 #+begin_src python :session what :results replace
2249 what
2250 #+end_src
2252 #+resname: python-get-from-session
2253 : 98
2255 **** DONE shell
2257 #+srcname: task-shell-sessions
2258 #+begin_src sh :session what
2259 WHAT='patton'
2260 #+end_src
2262 #+srcname: task-shell-sessions-what
2263 #+begin_src sh :session what :results replace
2264 echo $WHAT
2265 #+end_src
2267 #+resname: task-shell-sessions-what
2268 : patton
2270 **** DONE R
2272 #+srcname: task-R-session
2273 #+begin_src R :session what :results replace
2274 a <- 9
2275 b <- 8
2276 a + b
2277 #+end_src
2279 #+resname: task-R-session
2280 : 17
2282 #+srcname: another-task-R-session
2283 #+begin_src R :session what :results replace
2284 a + b
2285 #+end_src
2287 *** DONE function to bring up inferior-process buffer [4/4]
2289 This should be callable from inside of a source-code block in an
2290 org-mode buffer.  It should evaluate the header arguments, then bring
2291 up the inf-proc buffer using =pop-to-buffer=.
2293 For lack of a better place, lets add this to the `org-metadown-hook'
2294 hook.
2296 To give this a try, place the cursor on a source block with variables,
2297 (optionally git a prefix argument) then hold meta and press down.
2299 **** DONE ruby
2301 #+srcname: task-ruby-pop-to-session
2302 #+begin_src ruby :var num=9 :var another="something else"
2303 num.times{|n| puts another}
2304 #+end_src
2306 **** DONE python
2308 #+srcname: task-python-pop-to-session
2309 #+begin_src python :var num=9 :var another="something else"
2310 another * num
2311 #+end_src
2312 **** DONE R
2314 #+srcname: task-R-pop-to-session
2315 #+begin_src R :var a=9 :var b=8
2316 a * b
2317 #+end_src
2319 **** DONE shell
2321 #+srcname: task-shell-pop-sessions
2322 #+begin_src sh :var NAME="eric"
2323 echo $NAME
2324 #+end_src
2326 *** DEFERRED function to dump last N lines from inf-proc buffer into the current source block
2328 Callable with a prefix argument to specify how many lines should be
2329 dumped into the source-code buffer.
2331 *** REJECTED comint notes
2333 Implementing comint integration in [[file:lisp/org-babel-comint.el][org-babel-comint.el]].
2335 Need to have...
2336 - handling of outputs
2337   - split raw output from process by prompts
2338   - a ring of the outputs, buffer-local, `org-babel-comint-output-ring'
2339   - a switch for dumping all outputs to a buffer
2340 - inputting commands
2342 Lets drop all this language specific stuff, and just use
2343 org-babel-comint to split up our outputs, and return either the last
2344 value of an execution or the combination of values from the
2345 executions.
2347 **** comint filter functions
2348 : ;;  comint-input-filter-functions     hook    process-in-a-buffer
2349 : ;;  comint-output-filter-functions    hook    function modes.
2350 : ;;  comint-preoutput-filter-functions   hook
2351 : ;;  comint-input-filter                       function ...
2353 #+srcname: obc-filter-ruby
2354 #+begin_src ruby :results last
2360 #+end_src
2362 ** DONE Remove protective commas from # comments before evaluating
2363    org inserts protective commas in front of ## comments in language
2364    modes that use them. We need to remove them prior to sending code
2365    to the interpreter.
2367 #+srcname: testing-removal-of-protective-comas
2368 #+begin_src ruby
2369 ,# this one might break it??
2370 :comma_protection
2371 #+end_src
2373 ** DONE pass multiple reference arguments into R
2374    Can we do this? I wasn't sure how to supply multiple 'var' header
2375    args. Just delete this if I'm being dense.
2377    This should be working, see the following example...
2379 #+srcname: two-arg-example
2380 #+begin_src R :var n=2 :var m=8
2381 n + m
2382 #+end_src
2384 #+resname: two-arg-example
2385 : 10
2387 ** DONE ensure that table ranges work
2388 when a table range is passed to org-babel as an argument, it should be
2389 interpreted as a vector.
2391 | 1 | 2 | simple       |
2392 | 2 | 3 | Fixnum:1     |
2393 | 3 | 4 | Array:123456 |
2394 | 4 | 5 |              |
2395 | 5 | 6 |              |
2396 | 6 | 7 |              |
2397 #+TBLFM: @1$3='(sbe simple-sbe-example (n 4))::@2$3='(sbe task-table-range (n @1$1..@6$1))::@3$3='(sbe task-table-range (n (@1$1..@6$1)))
2399 #+srcname: simple-sbe-example
2400 #+begin_src emacs-lisp 
2401 "simple"
2402 #+end_src
2404 #+srcname: task-table-range
2405 #+begin_src ruby :var n=simple-sbe-example
2406 "#{n.class}:#{n}"
2407 #+end_src
2409 #+srcname: simple-results
2410 #+begin_src emacs-lisp :var n=task-table-range(n=(1 2 3))
2412 #+end_src
2414 #+resname: simple-results
2415 : Array:123
2417 #+srcname: task-arr-referent
2418 #+begin_src ruby :var ar=(1 2 3)
2419 ar.size
2420 #+end_src
2422 #+resname: task-arr-referent
2423 : 3
2425 ** DONE global variable indicating default to vector output
2426 how about an alist... =org-babel-default-header-args= this may already
2427 exist... just execute the following and all source blocks will default
2428 to vector output
2430 #+begin_src emacs-lisp 
2431 (setq org-babel-default-header-args '((:results . "vector")))
2432 #+end_src
2434 ** DONE name named results if source block is named
2435 currently this isn't happening although it should be
2437 #+srcname: test-naming-named-source-blocks
2438 #+begin_src emacs-lisp 
2439 :namer
2440 #+end_src
2442 #+resname: test-naming-named-source-blocks
2443 : :namer
2444 ** DONE (simple caching) check for named results before source blocks
2445 see the TODO comment in [[file:lisp/org-babel-ref.el::TODO%20This%20should%20explicitly%20look%20for%20resname%20lines%20before][org-babel-ref.el#org-babel-ref-resolve-reference]]
2446 ** DONE set =:results silent= when eval with prefix argument
2448 #+begin_src emacs-lisp
2449 'silentp
2450 #+end_src
2451 ** DONE results-type header (vector/file) [3/3]
2452    In response to a point in Dan's email.  We should allow the user to
2453    force scalar or vector results.  This could be done with a header
2454    argument, and the default behavior could be controlled through a
2455    configuration variable.
2456    
2457 #+srcname: task-trivial-vector
2458 #+begin_src ruby :results replace vector
2459 :scalar
2460 #+end_src
2462 #+resname:
2463 | ":scalar" |
2465    since it doesn't make sense to turn a vector into a scalar, lets
2466    just add a two values...
2467    
2468    - vector :: forces the results to be a vector (potentially 1 dimensional)
2469    - file :: this throws an error if the result isn't a string, and
2470              tries to treat it as a path to a file.
2472    I'm just going to cram all of these into the =:results= header
2473    argument.  Then if we allow multiple header arguments it should
2474    work out, for example one possible header argument string could be
2475    =:results replace vector file=, which would *replace* any existing
2476    results forcing the results into an org-mode table, and
2477    interpreting any strings as file paths.
2479 *** DONE multiple =:results= headers
2481 #+srcname: multiple-result-headers
2482 #+begin_src ruby :results replace silent
2483 :schulte
2484 #+end_src
2486 #+resname:
2488 *** DONE file result types
2489 When inserting into an org-mode buffer create a link with the path
2490 being the value, and optionally the display being the
2491 =file-name-nondirectory= if it exists.
2493 #+srcname: task-file-result
2494 #+begin_src python :results replace file
2495 "something"
2496 #+end_src
2498 #+resname:
2499 [[something][something]]
2502 This will be useful because blocks like =ditaa= and =dot= can return
2503 the string path of their files, and can add =file= to their results
2504 header.
2506 *** DONE vector result types
2508 #+srcname: task-force-results
2509 #+begin_src emacs-lisp :results vector
2511 #+end_src
2513 #+resname:
2514 | 8 |
2516 ** DONE results name
2517     In order to do this we will need to start naming our results.
2518     Since the source blocks are named with =#+srcname:= lines we can
2519     name results with =#+resname:= lines (if the source block has no
2520     name then no name is given to the =#+resname:= line on creation,
2521     otherwise the name of the source block is used).
2523     This will have the additional benefit of allowing results and
2524     source blocks to be located in different places in a buffer (and
2525     eventually in different buffers entirely).
2527 #+srcname: developing-resnames
2528 #+begin_src emacs-lisp  :results silent
2529 'schulte
2530 #+end_src
2532     Once source blocks are able to find their own =#+resname:= lines
2533     we then need to...
2535 #+srcname: sbe-w-new-results
2536 #+begin_src emacs-lisp :results replace
2537 (sbe "developing-resnames")
2538 #+end_src
2540 #+resname:
2541 : schulte
2543 *** TODO change the results insertion functions to use these lines
2545 *** TODO teach references to resolve =#+resname= lines.
2547 ** DONE org-babel tests org-babel [1/1]
2548 since we are accumulating this nice collection of source-code blocks
2549 in the sandbox section we should make use of them as unit tests.
2550 What's more, we should be able to actually use org-babel to run these
2551 tests.
2553 We would just need to cycle over every source code block under the
2554 sandbox, run it, and assert that the return value is equal to what we
2555 expect.
2557 I have the feeling that this should be possible using only org-babel
2558 functions with minimal or no additional elisp.  It would be very cool
2559 for org-babel to be able to test itself.
2561 This is now done, see [[* Tests]].
2563 *** DEFERRED org-babel assertions (may not be necessary)
2564 These could be used to make assertions about the results of a
2565 source-code block.  If the assertion fails then the point could be
2566 moved to the block, and error messages and highlighting etc... could
2567 ensue
2569 ** DONE make C-c C-c work anywhere within source code block?
2570    This seems like it would be nice to me, but perhaps it would be
2571    inefficient or ugly in implementation? I suppose you could search
2572    forward, and if you find #+end_src before you find #+begin_src,
2573    then you're inside one. [DED]
2575    Agreed, I think inside of the =#+srcname: line= would be useful as
2576    well.
2578 #+srcname: testing-out-cc
2579 #+begin_src emacs-lisp
2580 'schulte
2581 #+end_src
2583 ** DONE integration with org tables
2584 We should make it easy to call org-babel source blocks from org-mode
2585 table formulas.  This is practical now that it is possible to pass
2586 arguments to org-babel source blocks.
2588 See the related [[* (sandbox) integration w/org tables][sandbox]] header for tests/examples.
2590 *** digging in org-table.el
2591 In the past [[file:~/src/org/lisp/org-table.el::org%20table%20el%20The%20table%20editor%20for%20Org%20mode][org-table.el]] has proven difficult to work with.
2593 Should be a hook in [[file:~/src/org/lisp/org-table.el::defun%20org%20table%20eval%20formula%20optional%20arg%20equation][org-table-eval-formula]].
2595 Looks like I need to change this [[file:~/src/org/lisp/org-table.el::if%20lispp][if statement]] (line 2239) into a cond
2596 expression.
2598 ** DONE source blocks as functions
2600 Allow source code blocks to be called like functions, with arguments
2601 specified.  We are already able to call a source-code block and assign
2602 it's return result to a variable.  This would just add the ability to
2603 specify the values of the arguments to the source code block assuming
2604 any exist.  For an example see 
2606 When a variable appears in a header argument, how do we differentiate
2607 between it's value being a reference or a literal value?  I guess this
2608 could work just like a programming language.  If it's escaped or in
2609 quotes, then we count it as a literal, otherwise we try to look it up
2610 and evaluate it.
2612 ** DONE folding of code blocks? [2/2]
2613    [DED] In similar way to using outline-minor-mode for folding function
2614    bodies, can we fold code blocks?  #+begin whatever statements are
2615    pretty ugly, and in any case when you're thinking about the overall
2616    game plan you don't necessarily want to see the code for each Step.
2618 *** DONE folding of source code block
2619     Sounds good, and wasn't too hard to implement.  Code blocks should
2620     now be fold-able in the same manner as headlines (by pressing TAB
2621     on the first line).
2623 *** REJECTED folding of results
2624     So, lets do a three-stage tab cycle... First fold the src block,
2625     then fold the results, then unfold.
2626     
2627     There's no way to tell if the results are a table or not w/o
2628     actually executing the block which would be too expensive of an
2629     operation.
2631 ** DONE selective export of text, code, figures
2632    [DED] The org-babel buffer contains everything (code, headings and
2633    notes/prose describing what you're up to, textual/numeric/graphical
2634    code output, etc). However on export to html / LaTeX one might want
2635    to include only a subset of that content. For example you might
2636    want to create a presentation of what you've done which omits the
2637    code.
2639    [EMS] So I think this should be implemented as a property which can
2640    be set globally or on the outline header level (I need to review
2641    the mechanics of org-mode properties).  And then as a source block
2642    header argument which will apply only to a specific source code
2643    block.  A header argument of =:export= with values of
2644    
2645    - =code= :: just show the code in the source code block
2646    - =none= :: don't show the code or the results of the evaluation
2647    - =results= :: just show the results of the code evaluation (don't
2648                   show the actual code)
2649    - =both= :: show both the source code, and the results
2651 this will be done in [[* (sandbox) selective export][(sandbox) selective export]].
2653 ** DONE a header argument specifying silent evaluation (no output)
2654 This would be useful across all types of source block.  Currently
2655 there is a =:replace t= option to control output, this could be
2656 generalized to an =:output= option which could take the following
2657 options (maybe more)
2659 - =t= :: this would be the default, and would simply insert the
2660          results after the source block
2661 - =replace= :: to replace any results which may already be there
2662 - =silent= :: this would inhibit any insertion of the results
2664 This is now implemented see the example in the [[* silent evaluation][sandbox]]
2666 ** DONE assign variables from tables in R
2667 This is now working (see [[* (sandbox table) R][(sandbox-table)-R]]).  Although it's not that
2668 impressive until we are able to print table results from R.
2670 ** DONE insert 2-D R results as tables
2671 everything is working but R and shell
2673 *** DONE shells
2675 *** DONE R
2677 This has already been tackled by Dan in [[file:existing_tools/org-R.el::defconst%20org%20R%20write%20org%20table%20def][org-R:check-dimensions]].  The
2678 functions there should be useful in combination with [[http://cran.r-project.org/doc/manuals/R-data.html#Export-to-text-files][R-export-to-csv]]
2679 as a means of converting multidimensional R objects to emacs lisp.
2681 It may be as simple as first checking if the data is multidimensional,
2682 and then, if so using =write= to write the data out to a temporary
2683 file from which emacs can read the data in using =org-table-import=.
2685 Looking into this further, is seems that there is no such thing as a
2686 scalar in R [[http://tolstoy.newcastle.edu.au/R/help/03a/3733.html][R-scalar-vs-vector]]  In that light I am not sure how to
2687 deal with trivial vectors (scalars) in R.  I'm tempted to just treat
2688 them as vectors, but then that would lead to a proliferation of
2689 trivial 1-cell tables...
2691 ** DONE allow variable initialization from source blocks
2692 Currently it is possible to initialize a variable from an org-mode
2693 table with a block argument like =table=sandbox= (note that the
2694 variable doesn't have to named =table=) as in the following example
2696 #+TBLNAME: sandbox
2697 | 1 |       2 | 3 |
2698 | 4 | schulte | 6 |
2700 #+begin_src emacs-lisp :var table=sandbox :results replace
2701 (message (format "table = %S" table))
2702 #+end_src
2704 : "table = ((1 2 3) (4 \"schulte\" 6))"
2706 It would be good to allow initialization of variables from the results
2707 of other source blocks in the same manner.  This would probably
2708 require the addition of =#+SRCNAME: example= lines for the naming of
2709 source blocks, also the =table=sandbox= syntax may have to be expanded
2710 to specify whether the target is a source code block or a table
2711 (alternately we could just match the first one with the given name
2712 whether it's a table or a source code block).
2714 At least initially I'll try to implement this so that there is no need
2715 to specify whether the reference is to a table or a source-code block.
2716 That seems to be simpler both in terms of use and implementation.
2718 This is now working for emacs-lisp, ruby and python (and mixtures of
2719 the three) source blocks.  See the examples in the [[* (sandbox) referencing other source blocks][sandbox]].
2721 This is currently working only with emacs lisp as in the following
2722 example in the [[* emacs lisp source reference][emacs lisp source reference]].
2725 ** TODO Add languages [12/16]
2726 I'm sure there are many more that aren't listed here.  Please add
2727 them, and bubble any that you particularly care about up to the top.
2729 Any new language should be implemented in a org-babel-lang.el file.
2730 Follow the pattern set by [[file:lisp/org-babel-script.el][org-babel-script.el]], [[file:lisp/org-babel-shell.el][org-babel-shell.el]] and
2731 [[file:lisp/org-babel-R.el][org-babel-R.el]].
2733 *** DONE Haskell
2734 #+begin_src haskell
2735 "hello Haskell"
2736 #+end_src
2738 #+resname:
2739 : hello Haskell
2741 #+begin_src haskell
2742   let fac n = if n == 0 then 1 else n * fac (n - 1)
2743   fac 4
2744 #+end_src
2746 #+resname:
2747 : 24
2749 #+begin_src haskell
2750 [1, 2, 3, 4, 5]
2751 #+end_src
2753 #+resname:
2754 | 1 | 2 | 3 | 4 | 5 |
2756 *** STARTED ocaml [2/3]
2758 - [X] Working for the simple case (no arguments, simple output)
2759 - [X] correct handling of vector/list output
2760 - [ ] ability to import arguments
2762 #+begin_src ocaml
2763 let rec fib x =
2764   match x with
2765     | 0 -> 1
2766     | 1 -> 1
2767     | n -> fib(n - 1) + fib(n - 2) in
2768   fib 12
2769 #+end_src
2771 #+resname:
2772 : 233
2774 #+begin_src ocaml
2775 "string"
2776 #+end_src
2778 #+resname:
2779 : "string"
2781 #+begin_src ocaml
2782 [1; 2; 3; 4]
2783 #+end_src
2785 #+resname:
2786 | 1 | 2 | 3 | 4 |
2788 #+begin_src ocaml
2789 [|"ocaml"; "array"|]
2790 #+end_src
2792 #+resname:
2793 | "ocaml" | "array" |
2795 *** TODO perl
2796 This could probably be added to [[file:lisp/org-babel-script.el][org-babel-script.el]]
2797 *** TODO java
2798 *** STARTED SQL
2799 Things left to do
2800 - support for sessions
2801 - add more useful header arguments (user, passwd, database, etc...)
2802 - support for more engines (currently only supports mysql)
2803 - what's a reasonable way to drop table data into SQL?
2805 #+srcname: sql-example
2806 #+begin_src sql :engine mysql
2807   show databases
2808 #+end_src
2810 #+resname:
2811 | "Database"           |
2812 | "information_schema" |
2813 | "test"               |
2815 *** DONE SASS
2816 Sass is a very nice extension of CSS, which is much nicer to read and
2817 write (see [[http://sass-lang.com/][sass-lang]]).
2819 #+srcname: sass-example
2820 #+begin_src sass :file stylesheet.css :results file
2821   #me
2822     position: absolute
2823     top: 1em
2824     left: 1em
2825     .head
2826       text-align: center
2827 #+end_src
2829 #+resname:
2830 [[file:stylesheet.css][stylesheet.css]]
2832 *** DONE CSS
2833 trivial [[file:lisp/langs/org-babel-css.el][org-babel-css.el]]
2835 *** DONE ditaa
2836 (see [[* file result types][file result types]])
2838 #+srcname: implementing-ditaa
2839 #+begin_src ditaa :results replace :file blue.png :cmdline -r
2840 +---------+
2841 | cBLU    |
2842 |         |
2843 |    +----+
2844 |    |cPNK|
2845 |    |    |
2846 +----+----+
2847 #+end_src
2849 #+resname: implementing-ditaa
2850 [[file:blue.png][blue.png]]
2852 *** DONE gnuplot [7/7]
2853 (see [[* file result types][file result types]])
2855 #+PLOT: title:"Citas" ind:1 deps:(3) type:2d with:histograms set:"yrange [0:]"
2856 #+TBLNAME: gnuplot-data
2857 | independent var | first dependent var | second dependent var |
2858 |-----------------+---------------------+----------------------|
2859 |             0.1 |               0.425 |                0.375 |
2860 |             0.2 |              0.3125 |               0.3375 |
2861 |             0.3 |          0.24999993 |           0.28333338 |
2862 |             0.4 |               0.275 |              0.28125 |
2863 |             0.5 |                0.26 |                 0.27 |
2864 |             0.6 |          0.25833338 |           0.24999993 |
2865 |             0.7 |          0.24642845 |           0.23928553 |
2866 |             0.8 |             0.23125 |               0.2375 |
2867 |             0.9 |          0.23333323 |            0.2333332 |
2868 |               1 |              0.2225 |                 0.22 |
2869 |             1.1 |          0.20909075 |           0.22272708 |
2870 |             1.2 |          0.19999998 |           0.21458333 |
2871 |             1.3 |          0.19615368 |           0.21730748 |
2873 #+srcname: implementing-gnuplot
2874 #+begin_src gnuplot :var data=gnuplot-data :results silent
2875 set title "Implementing Gnuplot"
2876 plot data using 1:2 with lines
2877 #+end_src
2879 **** DONE add variables
2880      gnuplot 4.2 and up support user defined variables.  This is how
2881      we will handle variables with org-babel (meaning we will need to
2882      require gnuplot 4.2 and up for variable support, which can be
2883      install using [[http://www.macports.org/install.php][macports]] on Mac OSX).
2885      - scalar variables should be replaced in the body of the gnuplot code
2886      - vector variables should be exported to tab-separated files, and
2887        the variable names should be replaced with the path to the files
2889 **** DONE direct plotting w/o session
2890 **** DEFERRED gnuplot support for column/row names
2891 This should be implemented along the lines of the [[* STARTED Column (and row) names of tables in R input/output][R-colname-support]].
2893 We can do something similar to the :labels param in org-plot, we just
2894 have to be careful to ensure that each label is aligned with the
2895 related data file.
2897 This may be walking too close to an entirely prebuilt plotting tool
2898 rather than straight gnuplot code evaluation.  For now I think this
2899 can wait.
2901 **** DONE a =file= header argument
2902 to specify a file holding the results
2904 #+srcname: gnuplot-to-file-implementation
2905 #+begin_src gnuplot :file plot.png :var data=gnuplot-data
2906 plot data using 1:2, data using 1:3 with lines
2907 #+end_src
2909 #+resname:
2910 [[file:plot.png][plot.png]]
2912 **** DONE helpers from org-plot.el
2913 There are a variety of helpers in org-plot which can be fit nicely
2914 into custom gnuplot header arguments.
2916 These should all be in place by now.
2918 **** DEFERRED header argument specifying 3D data
2920 #+tblname: org-grid
2921 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
2922 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
2923 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
2924 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 0 | 0 |
2925 | 0 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 1 | 0 |
2926 | 0 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 1 | 0 |
2927 | 0 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 1 | 1 | 0 |
2928 | 0 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 |
2929 | 0 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 |
2930 | 0 | 1 | 0 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 1 | 0 |
2931 | 0 | 1 | 0 | 0 | 1 | 0 | 1 | 1 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 1 | 0 |
2932 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 1 | 0 | 0 |
2933 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
2934 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
2936 #+srcname: implementing-gnuplot-grid-plots
2937 #+begin_src gnuplot :vars data=org-grid
2939 #+end_src
2941 **** DONE gnuplot sessions
2942 Working on this, we won't support multiple sessions as `gnuplot-mode'
2943 isn't setup for such things.
2945 Also we can't display results with the default :none session, so for
2946 gnuplot we really want the default behavior to be :default, and to
2947 only run a :none session when explicitly specified.
2949 #+srcname: implementing-gnuplot-sessions
2950 #+begin_src gnuplot :var data=gnuplot-data :session none :file session.png
2951 set title "Implementing Gnuplot Sessions"
2952 plot data using 1:2 with lines
2953 #+end_src
2955 #+resname:
2956 [[file:session.png][session.png]]
2958 *** DONE dot
2959 (see [[* file result types][file result types]])
2961 #+srcname: implementing-dot-support
2962 #+begin_src dot :file test-dot.png :cmdline -Tpng
2963 digraph data_relationships {
2964   "data_requirement" [shape=Mrecord, label="{DataRequirement|description\lformat\l}"]
2965   "data_product" [shape=Mrecord, label="{DataProduct|name\lversion\lpoc\lformat\l}"]
2966   "data_requirement" -> "data_product"
2968 #+end_src
2970 #+resname:
2971 [[file:test-dot.png][test-dot.png]]
2973 *** DONE asymptote
2974 (see [[* file result types][file result types]])
2976 for information on asymptote see http://asymptote.sourceforge.net
2978 #+begin_src asymptote :file asymptote-test.png
2979 import graph;
2981 size(0,4cm);
2983 real f(real t) {return 1+cos(t);}
2985 path g=polargraph(f,0,2pi,operator ..)--cycle;
2986 filldraw(g,pink);
2988 xaxis("$x$",above=true);
2989 yaxis("$y$",above=true);
2991 dot("$(a,0)$",(1,0),N);
2992 dot("$(2a,0)$",(2,0),N+E);
2993 #+end_src
2995 #+resname:
2996 [[file:asymptote-test.png][asymptote-test.png]]
2998 *** DONE ruby
2999 *** DONE python
3000 *** DONE R
3001 *** DONE emacs-lisp
3002 *** DONE sh
3005 * Bugs [39/43]
3006 ** DONE stripping indentation from source-code blocks
3007 This is a problem in [[file:lisp/org-babel-exp.el][org-babel-exp.el]].
3009 ** DONE failing to write srcname to resname when evaluating a named block
3011 #+srcname: please-name-my-result
3012 #+begin_src emacs-lisp 
3013 "I'm the result"
3014 #+end_src
3016 #+resname: please-name-my-result
3017 : I'm the result
3020 ** DONE Python session evaluation bug
3021    The following block evaluates correctly with :session none
3022    (set :results to output), but fails with session-based evaluation
3023    (with :results value, as below, you see the error message)
3025    I edebug'ed it and it seems fine until [[file:lisp/langs/org-babel-python.el::comint%20session%20evaluation%20org%20babel%20comint%20in%20buffer%20buffer%20let%20full%20body][we go to comint]].
3027 #+begin_src python :session pysession :results value
3028   import os
3029   from subprocess import *
3030   
3031   chunk = 10000
3032   format = '.gen.gz'
3033   
3034   cc = [('58C','NBS'),
3035         ('58C','POBI'),
3036         ('NBS','POBI')]
3037   
3038   for outdir in ['none', 'noscots', 'lax', 'strict']:
3039       outdir = os.path.join('exclusion-study', outdir)
3040       for case, control in cc:
3041           outfile = os.path.join(outdir, '%s-vs-%s-direct' % (case, control))
3042           cmd = 'snptest %s -frequentist 1 -hwe ' % ('-gen_gz' if format == '.gen.gz' else '')
3043           cmd += '-cases %s %s ' % (case + format, case + '.sample')
3045           cmd += '-controls %s %s ' % (control + format, control + '.sample')
3046           cmd += '-exclude_samples %s ' % os.path.join(outdir, 'exclusions')
3047           cmd += '-o %s ' % outfile
3048           cmd += '-chunk %d ' % chunk
3049           cmd += '> %s' % outfile + '.log'
3050           # os.system(cmd)
3051           print(cmd)
3052 #+end_src
3054 #+resname:
3055 #+begin_example
3056 snptest -gen_gz -frequentist 1 -hwe -cases 58C.gen.gz 58C.sample -controls NBS.gen.gz NBS.sample -exclude_samples exclusion-study/none/exclusions -o exclusion-study/none/58C-vs-NBS-direct -chunk 10000 > exclusion-study/none/58C-vs-NBS-direct.log
3057 snptest -gen_gz -frequentist 1 -hwe -cases 58C.gen.gz 58C.sample -controls POBI.gen.gz POBI.sample -exclude_samples exclusion-study/none/exclusions -o exclusion-study/none/58C-vs-POBI-direct -chunk 10000 > exclusion-study/none/58C-vs-POBI-direct.log
3058 snptest -gen_gz -frequentist 1 -hwe -cases NBS.gen.gz NBS.sample -controls POBI.gen.gz POBI.sample -exclude_samples exclusion-study/none/exclusions -o exclusion-study/none/NBS-vs-POBI-direct -chunk 10000 > exclusion-study/none/NBS-vs-POBI-direct.log
3059 snptest -gen_gz -frequentist 1 -hwe -cases 58C.gen.gz 58C.sample -controls NBS.gen.gz NBS.sample -exclude_samples exclusion-study/noscots/exclusions -o exclusion-study/noscots/58C-vs-NBS-direct -chunk 10000 > exclusion-study/noscots/58C-vs-NBS-direct.log
3060 snptest -gen_gz -frequentist 1 -hwe -cases 58C.gen.gz 58C.sample -controls POBI.gen.gz POBI.sample -exclude_samples exclusion-study/noscots/exclusions -o exclusion-study/noscots/58C-vs-POBI-direct -chunk 10000 > exclusion-study/noscots/58C-vs-POBI-direct.log
3061 snptest -gen_gz -frequentist 1 -hwe -cases NBS.gen.gz NBS.sample -controls POBI.gen.gz POBI.sample -exclude_samples exclusion-study/noscots/exclusions -o exclusion-study/noscots/NBS-vs-POBI-direct -chunk 10000 > exclusion-study/noscots/NBS-vs-POBI-direct.log
3062 snptest -gen_gz -frequentist 1 -hwe -cases 58C.gen.gz 58C.sample -controls NBS.gen.gz NBS.sample -exclude_samples exclusion-study/lax/exclusions -o exclusion-study/lax/58C-vs-NBS-direct -chunk 10000 > exclusion-study/lax/58C-vs-NBS-direct.log
3063 snptest -gen_gz -frequentist 1 -hwe -cases 58C.gen.gz 58C.sample -controls POBI.gen.gz POBI.sample -exclude_samples exclusion-study/lax/exclusions -o exclusion-study/lax/58C-vs-POBI-direct -chunk 10000 > exclusion-study/lax/58C-vs-POBI-direct.log
3064 snptest -gen_gz -frequentist 1 -hwe -cases NBS.gen.gz NBS.sample -controls POBI.gen.gz POBI.sample -exclude_samples exclusion-study/lax/exclusions -o exclusion-study/lax/NBS-vs-POBI-direct -chunk 10000 > exclusion-study/lax/NBS-vs-POBI-direct.log
3065 snptest -gen_gz -frequentist 1 -hwe -cases 58C.gen.gz 58C.sample -controls NBS.gen.gz NBS.sample -exclude_samples exclusion-study/strict/exclusions -o exclusion-study/strict/58C-vs-NBS-direct -chunk 10000 > exclusion-study/strict/58C-vs-NBS-direct.log
3066 snptest -gen_gz -frequentist 1 -hwe -cases 58C.gen.gz 58C.sample -controls POBI.gen.gz POBI.sample -exclude_samples exclusion-study/strict/exclusions -o exclusion-study/strict/58C-vs-POBI-direct -chunk 10000 > exclusion-study/strict/58C-vs-POBI-direct.log
3067 snptest -gen_gz -frequentist 1 -hwe -cases NBS.gen.gz NBS.sample -controls POBI.gen.gz POBI.sample -exclude_samples exclusion-study/strict/exclusions -o exclusion-study/strict/NBS-vs-POBI-direct -chunk 10000 > exclusion-study/strict/NBS-vs-POBI-direct.log
3068 #+end_example
3070 ** DONE require users to explicitly turn on each language
3071 As we continue to add more languages to org-babel, many of which will
3072 require new major-modes we need to re-think how languages are added to
3073 org-babel.
3075 Currently we are requiring all available languages in the
3076 [[file:lisp/org-babel-init.el][org-babel-init.el]] file.  I think we need to change this to a user
3077 setting so that only the language which have their requirements met
3078 (in terms of system executables and emacs major modes) are loaded.  It
3079 is one more step for install, but it seems to me to be the only
3080 solution.  Thoughts?
3082 *** proposed
3084 we add something like the following to the instillation instructions  
3086 #+begin_src emacs-lisp
3087 ;; Uncomment each of the following require lines if you want org-babel
3088 ;; to support that language.  Each language has a comment explaining
3089 ;; it's dependencies.  See the related files in lisp/langs for more
3090 ;; detailed explanations of requirements.
3091 ;; 
3092 ;; (require 'org-babel-R)         ;; ess-mode
3093 ;; (require 'org-babel-asymptote) ;; asymptote be installed on your system
3094 ;; (require 'org-babel-css)       ;; none
3095 ;; (require 'org-babel-ditaa)     ;; ditaa be installed on your system
3096 ;; (require 'org-babel-dot)       ;; dot be installed on your system
3097 ;; (require 'org-babel-gnuplot)   ;; gnuplot-mode
3098 ;; (require 'org-babel-python)    ;; python-mode
3099 ;; (require 'org-babel-ruby)      ;; inf-ruby mode, ruby and irb must be installed on your system
3100 ;; (require 'org-babel-sql)       ;; none
3101 #+end_src
3103 note that =org-babel-sh=, =org-babel-emacs-lisp= are not included in
3104 the list as they can safely be assumed to work on any system.
3106 *** impetus
3107 we should come up with a way to gracefully degrade when support for a
3108 specific language is missing
3110 > To demonstrate creation of documents, open the "test-export.org" file in
3111 > the base of the org-babel directory, and export it as you would any
3112 > other org-mode file.  The "exports" header argument controls how
3113 > source-code blocks are exported, with the following options
3115 > - none :: no part of the source-code block is exported in the document
3116 > - results :: only the output of the evaluated block is exported
3117 > - code :: the code itself is exported
3118 > - both :: both the code and results are exported
3120 I have this error showing up:
3122 executing Ruby source code block
3123 apply: Searching for program: no such file or directory, irb
3125 ** DONE problem with newlines in output when :results value
3127 #+begin_src python :results value
3128 '\n'.join(map(str, range(4)))
3129 #+end_src
3131 #+resname:
3132 : 0
3133 : 1
3134 : 2
3135 : 3
3137 Whereas I was hoping for
3139 | 0 |
3140 | 1 |
3141 | 2 |
3142 | 3 |
3144 *Note*: to generate the above you can try using the new =raw= results
3145 header.
3147 #+begin_src python :results value raw
3148 '|'+'|\n|'.join(map(str, range(4)))+'|'
3149 #+end_src
3151 #+resname:
3152 | 0 |
3153 | 1 |
3154 | 2 |
3155 | 3 |
3157 This is now working, it doesn't return as a table because the value
3158 returned is technically a string.  To return the table mentioned above
3159 try something like the following.
3161 #+begin_src python
3162 [[0], [1], [2], [3]]
3163 #+end_src
3165 #+resname:
3166 | 0 |
3167 | 1 |
3168 | 2 |
3169 | 3 |
3171 This is some sort of non-printing char / quoting issue I think. Note
3172 that
3174 #+begin_src python :results value
3175 '\\n'.join(map(str, range(4)))
3176 #+end_src
3178 #+resname:
3179 : 0\n1\n2\n3
3181 Also, note that
3182 #+begin_src python :results output
3183 print('\n'.join(map(str, range(4))))
3184 #+end_src
3186 #+resname:
3187 : 0
3188 : 1
3189 : 2
3190 : 3
3192 *** collapsing consecutive newlines in string output
3193     
3194     This is an example of the same bug
3196 #+srcname: multi-line-string-output
3197 #+begin_src ruby :results output
3198 "the first line ends here
3201      and this is the second one
3203 even a third"
3204 #+end_src
3206 This doesn't produce anything at all now. I believe that's because
3207 I've changed things so that :results output really does *not* get the
3208 value of the block, only the STDOUT. So if we add a print statement
3209 this works OK.
3211 #+srcname: multi-line-string-output
3212 #+begin_src ruby :results output
3213 print "the first line ends here
3216      and this is the second one
3218 even a third"
3219 #+end_src
3221 #+resname:
3222 : the first line ends here
3225 :      and this is the second one
3227 : even a third
3229 However, the behaviour with :results value is wrong
3231 #+srcname: multi-line-string-value
3232 #+begin_src ruby
3233 "the first line ends here
3236      and this is the second one
3238 even a third"
3239 #+end_src
3241 #+resname:
3242 : 0
3244 ** TODO prompt characters appearing in output with R
3245 #+begin_src R :session *R* :results output
3246   x <- 6
3247   y <- 8
3248   3
3249 #+end_src      
3251 #+resname:
3252 : > [1] 3
3254 ** TODO o-b-execute-subtree overwrites heading when subtree is folded
3255 *** Example
3256     Try M-x org-babel-execute-subtree with the subtree folded and
3257     point at the beginning of the heading line.
3258 #+begin_src sh
3259 size=5
3260 #+end_src
3261 ** DONE non-orgtbl formatted lists
3262 for example
3264 #+srcname: this-doesn't-match-orgtbl
3265 #+begin_src emacs-lisp :results replace
3266 '((:results . "replace"))
3267 #+end_src
3269 #+resname:
3270 | (:results . "replace") |
3272 #+srcname: this-probably-also-wont-work
3273 #+begin_src emacs-lisp :results replace
3274 '(eric schulte)
3275 #+end_src
3277 #+resname:
3278 | eric | schulte |
3280 ** PROPOSED allow un-named arguments
3282 #+srcname: f(x)
3283 #+begin_src python 
3285 #+end_src
3287 #+lob: f(5)
3289 ## produces no output
3291  It's not essential but would be nice for this to work. To do it
3292 properly, would mean that we'd have to specify rules for how a string
3293 of supplied arguments (some possibly named) interact with the
3294 arguments in the definition (some possibly with defaults) to give
3295 values to the variables in the funbction body.
3296 ** PROPOSED external shell execution can't isolate return values
3297 I have no idea how to do this as of yet.  The result is that when
3298 shell functions are run w/o a session there is no difference between
3299 the =output= and =value= result arguments.
3301 Yea, I don't know how to do this either.  I searched extensively on
3302 how to isolate the *last* output of a series of shell commands (see
3303 [[* last command for
3304  shells][last command for shells]]).  The results of the search were basically
3305 that it was not possible (or at least not accomplish-able with a
3306 reasonable amount of effort).
3308 That fact combined with the tenancy to all ways use standard out in
3309 shell scripts led me to treat these two options (=output= and =value=)
3310 as identical in shell evaluation.  Not ideal but maybe good enough for
3311 the moment.
3313 In the `results' branch I've changed this so that they're not quite
3314 identical: output results in raw stdout contents, whereas value
3315 converts it to elisp, perhaps to a table if it looks tabular. This is
3316 the same for the other languages. [Dan]
3317    
3318 ** DONE adding blank line when source-block produces no output
3320 #+srcname: show-org-babel-trim
3321 #+begin_src sh
3322 find . \( -path \*/SCCS -o -path \*/RCS -o -path \*/CVS -o -path \*/MCVS -o -path \*/.svn -o -path \*/.git -o -path \*/.hg -o -path \*/.bzr -o -path \*/_MTN -o -path \*/_darcs -o -path \*/\{arch\} \) -prune -o  -type f \( -iname \*.el \) -exec grep -i -nH -e org-babel-trim {} \;
3323 #+end_src
3325 ** DONE Allow source blocks to be recognised when #+ are not first characters on the line
3326    I think Carsten has recently altered the core so that #+ can have
3327    preceding whitespace, at least for literal/code examples. org-babel
3328    should support this.
3330 #+srcname: testing-indentation
3331    #+begin_src emacs-lisp :results silent
3332    (message "i'm indented")
3333    #+end_src
3335 #+srcname: testing-non-indentation
3336 #+begin_src emacs-lisp :results silent
3337 (message "I'm not indented")
3338 #+end_src
3340 #+srcname: i-resolve-references-to-the-indented
3341 #+begin_src emacs-lisp :var speech=testing-indentation :results silent
3342 (message "I said %s" speech)
3343 #+end_src
3345 ** DONE are the org-babel-trim s necessary?
3346    at the end of e.g. org-babel-R-evaluate, org-babel-python-evaluate, but
3347    not org-babel-ruby-evaluate
3348    
3349    I think it depends on the language, if we find that extra blank
3350    lines are being inserted in a particular language that is a good
3351    indication that the trim or chomp functions may be appropriate.
3353    org-babel-trim and the related org-babel-chomp are use throughout
3354    org-babel...
3356 #+srcname: show-org-babel-trim-usage
3357 #+begin_src sh :results output
3358 find lisp/ \( -path \*/SCCS -o -path \*/RCS -o -path \*/CVS -o -path \*/MCVS -o -path \*/.svn -o -path \*/.git -o -path \*/.hg -o -path \*/.bzr -o -path \*/_MTN -o -path \*/_darcs -o -path \*/\{arch\} \) -prune -o  -type f \( -iname \*.el \) -exec grep -i -nH org-babel-trim {} \;
3359 #+end_src
3361 #+resname:
3362 #+begin_example
3363 lisp//langs/org-babel-python.el:49:                  vars "\n") "\n" (org-babel-trim body) "\n")) ;; then the source block body
3364 lisp//langs/org-babel-python.el:143:                           (org-remove-indentation (org-babel-trim body)) "[\r\n]")))
3365 lisp//langs/org-babel-python.el:158:           #'org-babel-trim
3366 lisp//langs/org-babel-python.el:166:                                           (reverse (mapcar #'org-babel-trim raw)))))))
3367 lisp//langs/org-babel-python.el:169:      (output (org-babel-trim (mapconcat #'identity (reverse (cdr results)) "\n")))
3368 lisp//langs/org-babel-python.el:170:      (value (org-babel-python-table-or-string (org-babel-trim (car results)))))))))
3369 lisp//langs/org-babel-ruby.el:149:                                                  (mapcar #'org-babel-trim raw)))))))
3370 lisp//langs/org-babel-sh.el:148:                                                  (mapcar #'org-babel-trim raw)))))))
3371 lisp//langs/org-babel-sh.el:151:            (output (org-babel-trim (mapconcat #'org-babel-trim (reverse results) "\n")))
3372 lisp//org-babel-ref.el:161:    (mapcar #'org-babel-trim (reverse (cons buffer return)))))
3373 lisp//org-babel.el:198:    (with-temp-buffer (insert (org-babel-trim body)) (copy-region-as-kill (point-min) (point-max)))
3374 lisp//org-babel.el:465:           (org-babel-trim
3375 lisp//org-babel.el:706:(defun org-babel-trim (string &optional regexp)
3376 #+end_example
3378 #+srcname: show-org-babel-chomp-usage
3379 #+begin_src sh :results output
3380 find lisp/ \( -path \*/SCCS -o -path \*/RCS -o -path \*/CVS -o -path \*/MCVS -o -path \*/.svn -o -path \*/.git -o -path \*/.hg -o -path \*/.bzr -o -path \*/_MTN -o -path \*/_darcs -o -path \*/\{arch\} \) -prune -o  -type f \( -iname \*.el \) -exec grep -i -nH org-babel-chomp {} \;
3381 #+end_src
3383 #+resname:
3384 #+begin_example
3385 lisp//langs/org-babel-R.el:122:             (full-body (mapconcat #'org-babel-chomp
3386 lisp//langs/org-babel-R.el:143:       (delete nil (mapcar #'extractor (mapcar #'org-babel-chomp raw))) "\n"))))))))
3387 lisp//langs/org-babel-ruby.el:143:           #'org-babel-chomp
3388 lisp//langs/org-babel-sh.el:142:           (full-body (mapconcat #'org-babel-chomp
3389 lisp//org-babel-tangle.el:163:      (insert (format "\n%s\n" (org-babel-chomp body)))
3390 lisp//org-babel.el:362:                  (org-babel-chomp (match-string 2 arg)))
3391 lisp//org-babel.el:698:(defun org-babel-chomp (string &optional regexp)
3392 lisp//org-babel.el:707:  "Like `org-babel-chomp' only it runs on both the front and back of the string"
3393 lisp//org-babel.el:708:  (org-babel-chomp (org-babel-reverse-string
3394 lisp//org-babel.el:709:                    (org-babel-chomp (org-babel-reverse-string string) regexp)) regexp))
3395 #+end_example
3397 ** DONE LoB is not populated on startup
3398    org-babel-library-of-babel is nil for me on startup. I have to
3399    evaluate the [[file:lisp/org-babel-lob.el::][org-babel-lob-ingest]] line manually.
3401 #+tblname: R-plot-example-data
3402 | 1 |  2 |
3403 | 2 |  4 |
3404 | 3 |  9 |
3405 | 4 | 16 |
3406 | 5 | 25 |
3408 #+lob: R-plot(data=R-plot-example-data)
3412    I've added a section to [[file:lisp/org-babel-init.el][org-babel-init.el]] which will load the
3413    library of babel on startup.
3415    Note that this needs to be done in [[file:lisp/org-babel-init.el][org-babel-init.el]] rather than in
3416    [[file:lisp/org-babel-lob.el][org-babel-lob.el]], not entirely sure why, something about it being
3417    required directly?
3419    Also, I'm now having the file closed if it wasn't being visited by
3420    a buffer before being loaded.
3422 ** DONE use new merge function [[file:lisp/org-babel-ref.el::t%20nil%20org%20combine%20plists%20args%20nil][here]]?
3423    And at other occurrences of org-combine-plists?
3424 ** DONE creeping blank lines
3425    There's still inappropriate addition of blank lines in some circumstances. 
3427    Hmm, it's a bit confusing. It's to do with o-b-remove-result. LoB
3428    removes the entire (#+resname and result) and starts from scratch,
3429    whereas #+begin_src only removes the result. I haven't worked out
3430    what the correct fix is yet. Maybe the right thing to do is to make
3431    sure that those functions (o-b-remove-result et al.) are neutral
3432    with respect to newlines. Sounds easy, but...
3434    E.g.
3436 #+begin_src sh
3438 #+end_src
3442    Compare the results of
3443 #+lob: adder(a=5, b=17)
3445 #+resname: python-add(a=5, b=17)
3446 : 22
3447 --------------------------------
3449 #+begin_src python
3451 #+end_src
3453 #+resname:
3454 : 23
3455 ---------------------
3456 ** DONE #+srcname arg parsing bug
3457 #+srcname: test-zz(arg=adder(a=1, b=1))
3458 #+begin_src python 
3460 #+end_src
3462 #+resname: test-zz
3463 : 2
3466 #+srcname: test-zz-nasty(arg=adder(a=adder(a=19,b=adder(a=5,b=2)),b=adder(a=adder(a=1,b=9),b=adder(a=1,b=3))))
3467 #+begin_src python 
3469 #+end_src
3471 #+resname: test-zz-nasty
3472 : 40
3476 #+srcname: test-zz-hdr-arg
3477 #+begin_src python :var arg=adder(a=adder(a=19,b=adder(a=5,b=2)),b=adder(a=adder(a=1,b=9),b=adder(a=1,b=3)))
3479 #+end_src
3481 #+resname:
3482 : 40
3484 ** DONE Fix nested evaluation and default args
3485    The current parser / evaluator fails with greater levels of nested
3486    function block calls (example below).
3488 *** Initial statement [ded]
3489     If we want to overcome this I think we'd have to redesign some of
3490     the evaluation mechanism. Seeing as we are also facing issues like
3491     dealing with default argument values, and seeing as we now know
3492     how we want the library of babel to behave in addition to the
3493     source blocks, now might be a good time to think about this. It
3494     would be nice to do the full thing at some point, but otoh we may
3495     not consider it a massive priority.
3496     
3497     AIui, there are two stages: (i) construct a parse tree, and (ii)
3498     evaluate it and return the value at the root. In the parse tree
3499     each node represents an unevaluated value (either a literal value
3500     or a reference). Node v may have descendent nodes, which represent
3501     values upon which node v's evaluation depends. Once that tree is
3502     constructed, then we evaluate the nodes from the tips towards the
3503     root (a post-order traversal).
3505     [This would also provide a solution for concatenating the STDOUTs
3506     of called blocks, which is a [[*allow%20output%20mode%20to%20return%20stdout%20as%20value][task below]]; we concatenate them in
3507     whatever order the traversal is done in.]
3509     In addition to the variable references (i.e. daughter nodes), each
3510     node would contain the information needed to evaluate that node
3511     (e.g. lang body). Then we would pass a function postorder over the
3512     tree which would call o-b-execute-src-block at each node, finally
3513     returning the value at the root.
3515     Fwiw I made a very tentative small start at stubbing this out in
3516     org-babel-call.el in the 'evaluation' branch. And I've made a start
3517     at sketching a parsing algorithm below.
3518 **** Parse tree algorithm
3519     Seeing as we're just trying to parse a string like
3520     f(a=1,b=g(c=2,d=3)) it shouldn't be too hard. But of course there
3521     are 'proper' parsers written in elisp out there,
3522     e.g. [[http://cedet.sourceforge.net/semantic.shtml][Semantic]]. Perhaps we can find what we need -- our syntax is
3523     pretty much the same as python and R isn't it?
3525     Or, a complete hack, but maybe it would be we easy to transform it
3526     to XML and then parse that with some existing tool?
3527     
3528     But if we're doing it ourselves, something very vaguely like this?
3529     (I'm sure there're lots of problems with this)
3531 #+srcname: org-babel-call-parse(call)
3532 #+begin_src python 
3533   ## we are currently reading a reference name: the name of the root function
3534   whereami = "refname"
3535   node = root = Node()
3536   for c in call_string:
3537       if c == '(':
3538           varnum = 0
3539           whereami = "varname" # now we're reading a variable name
3540       if c == '=':
3541           new = Node()
3542           node.daughters = [node.daughters, new]
3543           new.parent = node
3544           node = new
3545           whereami = "refname"
3546       if c == ',':
3547           whereami = "varname"
3548           varnum += 1
3549       elif c == ')':
3550           node = node.parent
3551       elif c == ' ':
3552           pass
3553       else:
3554           if whereami = "varname":
3555               node.varnames[varnum] += c
3556           elif whereami = "refname":
3557               node.name += c
3558 #+end_src
3559     
3560 *** discussion / investigation
3561 I believe that this issue should be addressed as a bug rather than as
3562 a point for new development.   The code in [[file:lisp/org-babel-ref.el][org-babel-ref.el]] already
3563 resolves variable references in a recursive manner which *should* work
3564 in the same manner regardless of the depth of the number of nested
3565 function calls.  This recursive evaluation has the effect of
3566 implicitly constructing the parse tree that your are thinking of
3567 constructing explicitly.
3569 Through using some of the commented out debugging statements in
3570 [[file:lisp/org-babel-ref.el][org-babel-ref.el]] I have looked at what may be going wrong in the
3571 current evaluation setup, and it seems that nested variables are being
3572 set using the =:var= header argument, and these variables are being
3573 overridden by the *default* variables which are being entered through
3574 the new functional syntax (see the demonstration header below).
3576 I believe that once this bug is fixed we should be back to fully
3577 resolution of nested arguments.  We should capture this functionality
3578 in a test to ensure that we continue to test it as we move forward.  I
3579 can take a look at implementing this once I get a chance.
3581 Looks like the problem may be in [[file:lisp/org-babel.el::defun%20org%20babel%20merge%20params%20rest%20plists][org-babel-merge-params]], which seems
3582 to be trampling the provided :vars values.
3584 Nope, now it seems that we are actually looking up the results line,
3585 rather than the actual source-code block, which would make sense given
3586 that the results-line will return the same value regardless of the
3587 arguments supplied.  See the output of this [[file:lisp/org-babel-ref.el::message%20type%20S%20type%20debugging][debug-statement]].
3589 We need to be sure that we don't read from a =#+resname:= line when we
3590 have a non-nil set of arguments.
3592 **** demonstration
3593 After uncommenting the debugging statements located [[file:lisp/org-babel-ref.el::message%20format%20first%20second%20S%20S%20new%20refere%20new%20referent%20debugging][here]] and more
3594 importantly [[file:lisp/org-babel-ref.el::message%20nested%20args%20S%20args%20debugging][here]], we can see that the current reference code does
3595 evaluate the references correctly, and it uses the =:var= header
3596 argument to set =a=8=, however the default variables specified using
3597 the functional syntax in =adder(a=3, b=2)= is overriding this
3598 specification.
3600 ***** doesn't work with functional syntax
3602 #+srcname: adder-func(a=3, b=2)
3603 #+begin_src python 
3604 a + b
3605 #+end_src
3607 #+resname: adder-func
3608 : 5
3610 #+srcname: after-adder-func(arg=adder-func(a=8))
3611 #+begin_src python 
3613 #+end_src
3615 #+resname: after-adder-func
3616 : 5
3618 ***** still does work with =:var= syntax
3620 so it looks like regardless of the syntax used we're not overriding
3621 the default argument values.
3623 #+srcname: adder-header
3624 #+begin_src python :var a=3 :var b=2
3625 a + b
3626 #+end_src
3628 #+resname: adder-header
3629 : 5
3631 #+srcname: after-adder-header
3632 #+begin_src python :var arg=adder-header(a=8, b=0)
3634 #+end_src
3636 #+resname: after-adder-header
3637 : 5
3639 *** Set of test cases
3640 **** Both defaults provided in definition
3641 #+srcname: adder1(a=10,b=20)
3642 #+begin_src python
3644 #+end_src
3646 #+resname: adder1
3647 : 30
3648 ****** DONE Rely on defaults
3649 #+lob: adder1()
3651 #+resname: adder1()
3652 : 30
3654 ## should be 30
3655 ## OK, but
3656 ******* DONE empty parens () not recognised as lob call
3657         E.g. remove spaces between parens above
3659         updated [[file:lisp/org-babel-lob.el::defvar%20org%20babel%20lob%20one%20liner%20regexp%20lob%20t%20n%20n%20t%20n][org-babel-lob-one-liner-regexp]]
3661 ****** DONE One supplied, one default
3662 #+lob: adder1(a=0)
3664 #+resname: adder1(a=0)
3665 : 20
3667 ## should be 20
3669 #+lob: adder1(b=0)
3671 #+resname: adder1(b=0)
3672 ## should be 10
3673 : 10
3675 ****** DONE Both supplied
3676 #+lob: adder1(a=1,b=2)
3678 #+resname: adder1(a=1,b=2)
3680 : 3
3681 **** One arg lacks default in definition
3682 #+srcname: adder2(a=10,b)
3683 #+begin_src python
3685 #+end_src
3686 ****** DEFERRED Rely on defaults (one of which is missing)
3687 #+lob: adder2( )
3689 [no output]
3691 ## should be error: b has no default
3693 Maybe we should let the programming language handle this case.  For
3694 example python spits out an error in the =#+lob= line above.  Maybe
3695 rather than catching these errors our-selves we should raise an error
3696 when the source-block returns an error.  I'll propose a [[* PROPOSED raise elisp error when source-blocks return errors][task]] for this
3697 idea, I'm not sure how/if it would work...
3699 ****** DEFERRED Default over-ridden
3700 #+lob: adder2(a=1)
3702 See the above [[* DEFERRED Rely on defaults (one of which is missing)][deferred]] and the new proposed [[* PROPOSED raise elisp error when source-blocks return errors][task]], I think it may be
3703 more flexible to allow the source block language to handle the error.
3705 [no output ]
3706 ## should be error: b has no default
3708 ****** DONE Missing default supplied
3709 #+lob: adder2(b=1)
3711 #+resname: adder2(b=1)
3712 : 11
3715 ## should be 11
3716 ## OK
3718 ****** DONE One over-ridden, one supplied
3719 #+lob: adder2(a=1,b=2)
3721 #+resname: adder2(a=1,b=2)
3722 : 3
3724 ## should be 3
3726 *** Example that fails
3727     
3728 #+srcname: adder(a=0, b=99)
3729 #+begin_src python 
3731 #+end_src
3735 #+srcname: one()
3736 #+begin_src python
3738 #+end_src
3740 **** nesting
3741 #+srcname: level-one-nesting()
3742 #+begin_src python :var arg=adder(a=one(),b=one())
3744 #+end_src
3746 #+resname: level-one-nesting
3748 : nil
3750 #+srcname: level-one-nesting()
3751 #+begin_src python :var arg=adder(a=adder(a=one(),b=one()),b=adder(a=one(),b=one()))
3753 #+end_src
3755 #+resname:
3756 : 12
3758 *** DONE deeply nested arguments still fails
3760 #+srcname: deeply-nested-args-bug
3761 #+begin_src python :var arg=adder(a=adder(a=one(),b=one()),b=adder(a=one(),b=one()))
3763 #+end_src
3765 #+resname:
3766 : 4
3768 **** Used to result in this error
3769 : supplied params=nil
3770 : new-refere="adder", new-referent="a=adder(a=one(),b=one()),b=adder(a=one(),b=one())"
3771 : args=((:var . "a=adder(a=one()") (:var . "b=one())") (:var . "b=adder(a=one()") (:var . "b=one())"))
3772 : type=source-block
3773 : supplied params=((:var . "a=adder(a=one()") (:var . "b=one())") (:var . "b=adder(a=one()") (:var . "b=one())"))
3774 : new-refere="adder", new-referent="a=one("
3775 : args=((:var . "a=one("))
3776 : type=source-block
3777 : supplied params=((:var . "a=one("))
3778 : reference 'one(' not found in this buffer
3780 Need to change the regexp in [[file:lisp/org-babel-ref.el::assign%20any%20arguments%20to%20pass%20to%20source%20block][org-babel-ref-resolve-reference]] so that
3781 it only matches when the parenthesis are balanced.  Maybe look at
3782 [[http://www.gnu.org/software/emacs/elisp/html_node/List-Motion.html][this]].
3784 *** DONE Still some problems with deeply nested arguments and defaults
3785 **** sandbox
3786 **** DONE Parsing / defaults bug
3787      Try inserting a space between 'a=0,' and 'b=0' and comparing results
3788 #+srcname: parsing-defaults-bug()
3789 #+begin_src python :var arg=adder(a=adder(a=0,b=0))
3791 #+end_src
3793 #+resname: parsing-defaults-bug
3795 : 99
3797 #+srcname: deeply-nested-args-bug-orig()
3798 #+begin_src python :var arg=adder(a=adder(a=one(),b=one()),b=adder(a=adder(a=3, b=4),b=one()))
3800 #+end_src
3802 #+resname: deeply-nested-args-bug-orig
3804 : 10
3807 **** DONE Nesting problem II
3808      This generates parsing errors
3810      Fixed: c2bef96b7f644c05be5a38cad6ad1d28723533aa
3812 #+srcname: deeply-nested-args-bug-II-1()
3813 #+begin_src python :var arg=adder(a=adder(a=one(),b=adder(a=2,b=4)))
3815 #+end_src
3817 #+resname: deeply-nested-args-bug-II-1
3819 : 106
3821 #+srcname: deeply-nested-args-bug-II-original()
3822 #+begin_src python :var arg=adder(a=adder(a=one(),b=one()),b=adder(a=one(),b=adder(a=1,b=4)))
3824 #+end_src
3826 #+resname: deeply-nested-args-bug-II-original
3827 : 8
3831 **** DONE Why does this give 8?
3832      It was picking up the wrong definition of adder
3833 #+srcname: deeply-nested-args-bug-2()
3834 #+begin_src python :var arg=adder(a=adder(a=one(),b=one()))
3836 #+end_src
3838 #+resname: deeply-nested-args-bug-2
3840 : 101
3842 **** DONE Problem with empty argument list
3843      This gives empty list with () and 'no output' with ( )
3845      I think this is OK now.
3847 #+srcname: x
3848 #+begin_src python :var arg=adder( )
3850 #+end_src
3852 #+resname:
3853 : 99
3855 #+srcname: deeply-nested-args-bug-orig()
3856 #+begin_src python :var arg=adder(a=adder(a=one(),b=one()),b=adder(a=adder(a=3, b=4),b=one()))
3858 #+end_src
3860 #+resname: deeply-nested-args-bug-orig
3862 : 10
3865 **** DONE Nesting problem II
3866      This generates parsing errors
3868      Fixed: c2bef96b7f644c05be5a38cad6ad1d28723533aa
3870 #+srcname: deeply-nested-args-bug-II-1()
3871 #+begin_src python :var arg=adder(a=adder(a=one(),b=adder(a=2,b=4)))
3873 #+end_src
3875 #+resname: deeply-nested-args-bug-II-1
3877 : 106
3879 #+srcname: deeply-nested-args-bug-II-original()
3880 #+begin_src python :var arg=adder(a=adder(a=one(),b=one()),b=adder(a=one(),b=adder(a=1,b=4)))
3882 #+end_src
3884 #+resname: deeply-nested-args-bug-II-original
3885 : 8
3889 **** DONE Why does this give 8?
3890      It was picking up the wrong definition of adder
3891 #+srcname: deeply-nested-args-bug-2()
3892 #+begin_src python :var arg=adder(a=adder(a=one(),b=one()))
3894 #+end_src
3896 #+resname: deeply-nested-args-bug-2
3898 : 101
3900 **** DONE Problem with empty argument list
3901      This gives empty list with () and 'no output' with ( )
3903      I think this is OK now.
3905 #+srcname: x
3906 #+begin_src python :var arg=adder( )
3908 #+end_src
3910 #+resname:
3911 : 99
3939 #+srcname: test-zz(arg=adder(a=adder(a=19,b=adder(a=5,b=2)),b=adder(a=adder(a=1,b=9),b=adder(a=1,b=3))))
3940 #+begin_src python 
3942 #+end_src
3945 *** DONE Arg lacking default
3946    This would be good thing to address soon. I'm imagining that
3947    e.g. here, the 'caller' block would return the answer 30. I believe
3948    there's a few issues here: i.e. the naked 'a' without a reference
3949    is not understood; the default arg b=6 is not understood.
3951 #+srcname: adder-with-arg-lacking-default(a, b=6)
3952 #+begin_src python 
3954 #+end_src
3958 #+srcname: caller(var=adder-with-arg-lacking-default(a=24))
3959 #+begin_src python :results silent
3961 #+end_src
3963 ** DONE allow srcname to omit function call parentheses
3964    Someone needs to revisit those regexps. Is there an argument for
3965    moving some of the regexps used to match function calls into
3966    defvars? (i.e. in o-b.el and o-b-ref.el)
3968    This seems to work now. It still might be a good idea to separate
3969    out some of the key regexps into defvars at some point.
3971 #+srcname: omit-parens-test
3972 #+begin_src ruby :results output
3973 3.times {puts 'x'}
3974 #+end_src
3976 #+resname:
3977 : x
3978 : x
3979 : x
3981 ** DONE avoid stripping whitespace from output when :results output
3982    This may be partly solved by using o-b-chomp rather than o-b-trim
3983    in the o-b-LANG-evaluate functions.
3984 ** DEFERRED weird escaped characters in shell prompt break shell evaluation
3985    E.g. this doesn't work. Should the shell sessions set a sane prompt
3986    when they start up? Or is it a question of altering
3987    comint-prompt-regexp? Or altering org-babel regexps?
3988    
3989 #+begin_src sh   
3990    black=30 ; red=31 ; green=32 ; yellow=33 ; blue=34 ; magenta=35 ; cyan=36 ; white=37
3991    prompt_col=$red
3992    prompt_char='>'
3993    export PS1="\[\033[${prompt_col}m\]\w${prompt_char} \[\033[0m\]"
3994 #+end_src
3996    I just pushed a good amount of changes, could you see if your shell
3997    problems still exist?
3999    The problem's still there. Specifically, aIui, at [[file:lisp/langs/org-babel-sh.el::raw%20org%20babel%20comint%20with%20output%20buffer%20org%20babel%20sh%20eoe%20output%20nil%20insert%20full%20body%20comint%20send%20input%20nil%20t][this line]] of
4000    org-babel-sh.el, raw gets the value
4002 ("" "\e[0m Sun Jun 14 19:26:24 EDT 2009\n" "\e[0m org_babel_sh_eoe\n" "\e[0m ")
4004    and therefore (member org-babel-sh-eoe-output ...) fails
4006    I think that `comint-prompt-regexp' needs to be altered to match
4007    the shell prompt.  This shouldn't be too difficult to do by hand,
4008    using the `regexp-builder' command and should probably be part of
4009    the user's regular emacs init.  I can't think of a way for us to
4010    set this automatically, and we are SOL without a regexp to match
4011    the prompt.
4012 ** DONE function calls in #+srcname: refs
4013    
4014    My srcname references don't seem to be working for function
4015    calls. This needs fixing.
4016    
4017 #+srcname: called()
4018 #+begin_src python 
4020 #+end_src
4022 srcname function call doesn't work for calling a source block
4023 #+srcname: caller(var1=called())
4024 #+begin_src python
4025 var1
4026 #+end_src
4028 #+resname: caller
4029 : 59
4036 They do work for a simple reference
4037 #+srcname: caller2(var1=56)
4038 #+begin_src python 
4039 var1
4040 #+end_src
4042 #+resname: caller2
4043 : 59
4046 and they do work for :var header arg
4047 #+srcname: caller3
4048 #+begin_src python :var var1=called() 
4049 var1
4050 #+end_src
4052 #+resname:
4053 : 58
4054 ** DONE LoB: with output to buffer, not working in buffers other than library-of-babel.org
4055 *** Initial report
4056    I haven't fixed this yet. org-babel-ref-resolve-reference moves
4057    point around, inside a save-excursion. Somehow when it comes to
4058    inserting the results (after possible further recursive calls to
4059    org-babel-ref-resolve-reference), point hasn't gone back to the
4060    lob line.
4062 #+tblname: test-data
4063 | 1 |    1 |
4064 | 2 |   .5 |
4065 | 3 | .333 |
4067 #+lob: R-plot(data=test-data)
4069 #+lob: python-add(a=2, b=9)
4071 #+resname: python-add(a=2, b=9)
4072 : 11
4074 *** Now
4075     I think this got fixed in the bugfixes before merging results into master.
4077 ** DONE cursor movement when evaluating source blocks
4078    E.g. the pie chart example. Despite the save-window-excursion in
4079    org-babel-execute:R. (I never learned how to do this properly: org-R
4080    jumps all over the place...)
4082    I don't see this now [ded]
4084 ** DONE LoB: calls fail if reference has single character name
4085    commit 21d058869df1ff23f4f8cc26f63045ac9c0190e2
4086 **** This doesn't work
4087 #+lob: R-plot(data=X)
4089 #+tblname: X
4090 | 1 |     1 |
4091 | 2 |    .5 |
4092 | 3 | .3333 |
4093 | 4 |   .25 |
4094 | 5 |    .2 |
4095 | 6 | .1666 |
4097 **** But this is OK
4098 #+tblname: XX
4099 | 1 |     1 |
4100 | 2 |    .5 |
4101 | 3 | .3333 |
4102 | 4 |   .25 |
4103 | 5 |    .2 |
4104 | 6 | .1666 |
4106 #+lob: R-plot(data=XX)
4108 ** DONE make :results replace the default?
4109    I'm tending to think that appending results to pre-existing results
4110    creates mess, and that the cleaner `replace' option should be the
4111    default. E.g. when a source block creates an image, we would want
4112    that to be updated, rather than have a new one be added.
4113    
4114    I agree.
4116 ** DONE ruby evaluation not working under ubuntu emacs 23
4117    With emacs 23.0.91.1 on ubuntu, for C-h f run-ruby I have the
4118    following, which seems to conflict with [[file:lisp/langs/org-babel-ruby.el::let%20session%20buffer%20save%20window%20excursion%20run%20ruby%20nil%20session%20current%20buffer][this line]] in org-babel-ruby.el.
4120 #+begin_example
4121 run-ruby is an interactive compiled Lisp function.
4123 (run-ruby cmd)
4125 Run an inferior Ruby process, input and output via buffer *ruby*.
4126 If there is a process already running in `*ruby*', switch to that buffer.
4127 With argument, allows you to edit the command line (default is value
4128 of `ruby-program-name').  Runs the hooks `inferior-ruby-mode-hook'
4129 (after the `comint-mode-hook' is run).
4130 (Type C-h m in the process buffer for a list of commands.)
4131 #+end_example
4133    So, I may have a non-standard inf-ruby.el.  Here's my version of
4134    run-ruby.
4136 #+begin_example 
4137 run-ruby is an interactive Lisp function in `inf-ruby.el'.
4139 (run-ruby &optional COMMAND NAME)
4141 Run an inferior Ruby process, input and output via buffer *ruby*.
4142 If there is a process already running in `*ruby*', switch to that buffer.
4143 With argument, allows you to edit the command line (default is value
4144 of `ruby-program-name').  Runs the hooks `inferior-ruby-mode-hook'
4145 (after the `comint-mode-hook' is run).
4146 (Type C-h m in the process buffer for a list of commands.)
4147 #+end_example
4149    It seems we could either bundle my version of inf-ruby.el (as it's
4150    the newest).  Or we could change the use of `run-ruby' so that it
4151    is robust across multiple distributions.  I think I'd prefer the
4152    former, unless the older version of inf-ruby is actually bundled
4153    with emacs, in which case maybe we should go out of our way to
4154    support it.  Thoughts?
4156    I think for now I'll just include the latest [[file:util/inf-ruby.el][inf-ruby.el]] in the
4157    newly created utility directory.  I doubt anyone would have a
4158    problem using the latest version of this file.
4159 ** DONE test failing forcing vector results with =test-forced-vector-results= ruby code block
4160 Note that this only seems to happen the *second* time the test table
4161 is evaluated
4163 #+srcname: bug-trivial-vector
4164 #+begin_src emacs-lisp :results vector silent
4166 #+end_src
4168 #+srcname: bug-forced-vector-results
4169 #+begin_src ruby :var triv=test-trivial-vector :results silent
4170 triv.class.name
4171 #+end_src
4173 mysteriously this seems to be fixed...
4174 ** DONE defunct R sessions
4175 Sometimes an old R session will turn defunct, and newly inserted code
4176 will not be evaluated (leading to a hang).
4178 This seems to be fixed by using `inferior-ess-send-input' rather than `comint-send-input'.
4179 ** DONE ruby fails on first call to non-default session
4181 #+srcname: bug-new-session
4182 #+begin_src ruby :session is-new
4183 :patton
4184 #+end_src
4186 ** DONE when reading results from =#+resname= line
4188 Errors when trying to read from resname lines.
4190 #+resname: bug-in-resname
4191 : 8
4193 #+srcname: bug-in-resname-reader
4194 #+begin_src emacs-lisp :var buggy=bug-in-resname() :results silent
4195 buggy
4196 #+end_src
4198 ** DONE R-code broke on "org-babel" rename
4200 #+srcname: bug-R-babels
4201 #+begin_src R 
4202 8 * 2
4203 #+end_src
4205 ** DONE error on trivial R results
4207 So I know it's generally not a good idea to squash error without
4208 handling them, but in this case the error almost always means that
4209 there was no file contents to be read by =org-table-import=, so I
4210 think it's ok.
4212 #+srcname: bug-trivial-r1
4213 #+begin_src R :results replace
4214 pie(c(1, 2, 3), labels = c(1, 2, 3))
4215 #+end_src
4217 #+srcname: bug-trivial-r2
4218 #+begin_src R :results replace
4220 #+end_src
4222 #+resname: bug-trivial-r2
4223 : 8
4225 #+srcname: bug-trivial-r3
4226 #+begin_src R :results replace
4227 c(1,2,3)
4228 #+end_src
4230 #+resname: bug-trivial-r3
4231 | 1 |
4232 | 2 |
4233 | 3 |
4235 ** DONE ruby new variable creation (multi-line ruby blocks)
4236 Actually it looks like we were dropping all but the last line.
4238 #+srcname: multi-line-ruby-test
4239 #+begin_src ruby :var table=bug-numerical-table :results replace
4240 total = 0
4241 table.each{|n| total += n}
4242 total/table.size
4243 #+end_src
4245 #+resname:
4246 : 2
4248 ** DONE R code execution seems to choke on certain inputs
4249 Currently the R code seems to work on vertical (but not landscape)
4250 tables
4252 #+srcname: little-fake
4253 #+begin_src emacs-lisp 
4254 "schulte"
4255 #+end_src
4258 #+begin_src R :var num=little-fake
4260 #+end_src
4262 #+resname:
4263 : schulte
4265 #+srcname: set-debug-on-error
4266 #+begin_src emacs-lisp :results silent
4267 (setq debug-on-error t)
4268 #+end_src
4270 #+srcname: bug-numerical-table
4271 #+begin_src emacs-lisp :results silent
4272 '(1 2 3)
4273 #+end_src
4278 #+srcname: bug-R-number-evaluation
4279 #+begin_src R :var table=bug-numerical-table
4280 mean(mean(table))
4281 #+end_src
4283 #+resname:
4284 : 2
4288 #+tblname: bug-vert-table
4289 | 1 |
4290 | 2 |
4291 | 3 |
4293 #+srcname: bug-R-vertical-table
4294 #+begin_src R :var table=bug-vert-table :results silent
4295 mean(table)
4296 #+end_src
4298 ** DONE org bug/request: prevent certain org behaviour within code blocks
4299    E.g. [[]] gets recognised as a link (when there's text inside the
4300    brackets). This is bad for R code at least, and more generally
4301    could be argued to be inappropriate. Is it difficult to get org to
4302    ignore text in code blocks? [DED]
4303    
4304    I believe Carsten addressed this recently on the mailing list with
4305    the comment that it was indeed a difficult issue.  I believe this
4306    may be one area where we could wait for an upstream (org-mode) fix.
4308    [Dan] Carsten has fixed this now in the core.
4310 ** DONE with :results replace, non-table output doesn't replace table output
4311    And vice versa. E.g. Try this first with table and then with len(table) [DED]
4312 #+begin_src python :var table=sandbox :results replace
4313 table
4314 #+end_src
4316 | 1 |         2 | 3 |
4317 | 4 | "schulte" | 6 |
4318 : 2
4320 Yes, this is certainly a problem.  I fear that if we begin replacing
4321 anything immediately following a source block (regardless of whether
4322 it matches the type of our current results) we may accidentally delete
4323 hand written portions of the user's org-mode buffer.
4325 I think that the best solution here would be to actually start
4326 labeling results with a line that looks something like...
4328 #+results: name
4330 This would have a couple of benefits...
4331 1) we wouldn't have to worry about possibly deleting non-results
4332    (which is currently an issue)
4333 2) we could reliably replace results even if there are different types
4334 3) we could reference the results of a source-code block in variable
4335    definitions, which would be useful if for example we don't wish to
4336    re-run a source-block every time because it is long-running.
4338 Thoughts?  If no-one objects, I believe I will implement the labeling
4339 of results.
4341 ** DONE extra quotes for nested string
4342 Well R appears to be reading the tables without issue...
4344 these *should* be quoted
4345 #+srcname: ls
4346 #+begin_src sh :results replace
4348 #+end_src
4350 | "COPYING"          |
4351 | "README.markdown"  |
4352 | "block"            |
4353 | "examples.org"     |
4354 | "existing_tools"   |
4355 | "intro.org"        |
4356 | "org-babel"          |
4357 | "rorg.org"         |
4358 | "test-export.html" |
4359 | "test-export.org"  |
4361 #+srcname: test-quotes
4362 #+begin_src ruby :var tab=ls
4363 tab[1][0]
4364 #+end_src
4366 : README.markdown
4368 #+srcname: test-quotes
4369 #+begin_src R :var tab=ls
4370 as.matrix(tab[2,])
4371 #+end_src
4373 : README.markdown
4375 ** DONE simple ruby arrays not working
4377 As an example eval the following.  Adding a line to test
4379 #+tblname: simple-ruby-array
4380 | 3 | 4 | 5 |
4382 #+srcname: ruby-array-test
4383 #+begin_src ruby :var ar = simple-ruby-array :results silent
4384 ar.first.first
4385 #+end_src
4387 ** DONE space trailing language name
4388 fix regexp so it works when there's a space trailing the language name
4390 #+srcname: test-trailing-space
4391 #+begin_src ruby 
4392 :schulte
4393 #+end_src
4395 ** DONE Args out of range error
4396    
4397 The following block resulted in the error below [DED]. It ran without
4398 error directly in the shell.
4399 #+begin_src sh
4400 cd ~/work/genopca
4401 for platf in ill aff ; do
4402     for pop in CEU YRI ASI ; do
4403         rm -f $platf/hapmap-genos-$pop-all $platf/hapmap-rs-all
4404         cat $platf/hapmap-genos-$pop-* > $platf/hapmap-genos-$pop-all
4405         cat $platf/hapmap-rs-* > $platf/hapmap-rs-all
4406     done
4407 done
4408 #+end_src
4409   
4410  executing source block with sh...
4411 finished executing source block
4412 string-equal: Args out of range: "", -1, 0
4414 the error =string-equal: Args out of range: "", -1, 0= looks like what
4415 used to be output when the block returned an empty results string.
4416 This should be fixed in the current version, you should now see the
4417 following message =no result returned by source block=.
4419 ** DONE ruby arrays not recognized as such
4421 Something is wrong in [[file:lisp/org-babel-script.el]] related to the
4422 recognition of ruby arrays as such.
4424 #+begin_src ruby :results replace
4425 [1, 2, 3, 4]
4426 #+end_src
4428 | 1 | 2 | 3 | 4 |
4430 #+begin_src python :results replace
4431 [1, 2, 3, 4]
4432 #+end_src
4434 | 1 | 2 | 3 | 4 |
4435 ** REJECTED elisp reference fails for literal number
4436    That's a bug in Dan's elisp, not in org-babel.
4437 #+srcname: elisp-test(a=4)
4438 #+begin_src emacs-lisp 
4439 (message a)
4440 #+end_src
4446 : 30
4449 * Tests
4450 Evaluate all the cells in this table for a comprehensive test of the
4451 org-babel functionality.
4453 *Note*: if you have customized =org-babel-default-header-args= then some
4454 of these tests may fail.
4456 #+TBLNAME: org-babel-tests
4457 | functionality           | block                      | arg |    expected |     results | pass |
4458 |-------------------------+----------------------------+-----+-------------+-------------+------|
4459 | basic evaluation        |                            |     |             |             | pass |
4460 |-------------------------+----------------------------+-----+-------------+-------------+------|
4461 | emacs lisp              | basic-elisp                |     |           5 |           5 | pass |
4462 | shell                   | basic-shell                |     |           6 |           6 | pass |
4463 | ruby                    | basic-ruby                 |     |   org-babel |   org-babel | pass |
4464 | python                  | basic-python               |     | hello world | hello world | pass |
4465 | R                       | basic-R                    |     |          13 |          13 | pass |
4466 |-------------------------+----------------------------+-----+-------------+-------------+------|
4467 | tables                  |                            |     |             |             | pass |
4468 |-------------------------+----------------------------+-----+-------------+-------------+------|
4469 | emacs lisp              | table-elisp                |     |           3 |           3 | pass |
4470 | ruby                    | table-ruby                 |     |       1-2-3 |       1-2-3 | pass |
4471 | python                  | table-python               |     |           5 |           5 | pass |
4472 | R                       | table-R                    |     |         3.5 |         3.5 | pass |
4473 | R: col names in R       | table-R-colnames           |     |          -3 |          -3 | pass |
4474 | R: col names in org     | table-R-colnames-org       |     |         169 |         169 | pass |
4475 |-------------------------+----------------------------+-----+-------------+-------------+------|
4476 | source block references |                            |     |             |             | pass |
4477 |-------------------------+----------------------------+-----+-------------+-------------+------|
4478 | all languages           | chained-ref-last           |     |       Array |       Array | pass |
4479 |-------------------------+----------------------------+-----+-------------+-------------+------|
4480 | source block functions  |                            |     |             |             | pass |
4481 |-------------------------+----------------------------+-----+-------------+-------------+------|
4482 | emacs lisp              | defun-fibb                 |     |       fibbd |       fibbd | pass |
4483 | run over                | Fibonacci                  |   0 |           1 |           1 | pass |
4484 | a                       | Fibonacci                  |   1 |           1 |           1 | pass |
4485 | variety                 | Fibonacci                  |   2 |           2 |           2 | pass |
4486 | of                      | Fibonacci                  |   3 |           3 |           3 | pass |
4487 | different               | Fibonacci                  |   4 |           5 |           5 | pass |
4488 | arguments               | Fibonacci                  |   5 |           8 |           8 | pass |
4489 |-------------------------+----------------------------+-----+-------------+-------------+------|
4490 | bugs and tasks          |                            |     |             |             | pass |
4491 |-------------------------+----------------------------+-----+-------------+-------------+------|
4492 | simple ruby arrays      | ruby-array-test            |     |           3 |           3 | pass |
4493 | R number evaluation     | bug-R-number-evaluation    |     |           2 |           2 | pass |
4494 | multi-line ruby blocks  | multi-line-ruby-test       |     |           2 |           2 | pass |
4495 | forcing vector results  | test-forced-vector-results |     |       Array |       Array | pass |
4496 | deeply nested arguments | deeply-nested-args-bug     |     |           4 |           4 | pass |
4497 |-------------------------+----------------------------+-----+-------------+-------------+------|
4498 | sessions                |                            |     |             |             | pass |
4499 |-------------------------+----------------------------+-----+-------------+-------------+------|
4500 | set ruby session        | set-ruby-session-var       |     |        :set |        :set | pass |
4501 | get from ruby session   | get-ruby-session-var       |     |           3 |           3 | pass |
4502 | set python session      | set-python-session-var     |     |         set |         set | pass |
4503 | get from python session | get-python-session-var     |     |           4 |           4 | pass |
4504 | set R session           | set-R-session-var          |     |         set |         set | pass |
4505 | get from R session      | get-R-session-var          |     |           5 |           5 | pass |
4506 #+TBLFM: $5='(if (= (length $3) 1) (progn (message (format "running %S" '(sbe $2 (n $3)))) (sbe $2 (n $3))) (sbe $2))::$6='(if (string= $4 $5) "pass" (format "expected %S but was %S" $4 $5))
4507 #+TBLFM: $5=""::$6=""
4510 The second TBLFM line (followed by replacing '[]' with '') can be used
4511 to blank out the table results, in the absence of a better method.
4513 ** basic tests
4515 #+srcname: basic-elisp
4516 #+begin_src emacs-lisp :results silent
4517 (+ 1 4)
4518 #+end_src
4521 #+srcname: basic-shell
4522 #+begin_src sh :results silent
4523 expr 1 + 5
4524 #+end_src
4527 #+srcname: date-simple
4528 #+begin_src sh :results silent
4529 date
4530 #+end_src
4532 #+srcname: basic-ruby
4533 #+begin_src ruby :results silent
4534 "org-babel"
4535 #+end_src
4538 #+srcname: basic-python
4539 #+begin_src python :results silent
4540 'hello world'
4541 #+end_src
4544 #+srcname: basic-R
4545 #+begin_src R :results silent
4546 b <- 9
4547 b + 4
4548 #+end_src
4551 ** read tables
4553 #+tblname: test-table
4554 | 1 | 2 | 3 |
4555 | 4 | 5 | 6 |
4557 #+tblname: test-table-colnames
4558 | var1 | var2 | var3 |
4559 |------+------+------|
4560 |    1 |   22 |   13 |
4561 |   41 |   55 |   67 |
4563 #+srcname: table-elisp
4564 #+begin_src emacs-lisp :results silent :var table=test-table
4565 (length (car table))
4566 #+end_src
4569 #+srcname: table-ruby
4570 #+begin_src ruby :results silent :var table=test-table
4571 table.first.join("-")
4572 #+end_src
4575 #+srcname: table-python
4576 #+begin_src python :var table=test-table
4577 table[1][1]
4578 #+end_src
4580 #+srcname: table-R(table=test-table)
4581 #+begin_src R
4582 mean(mean(table))
4583 #+end_src
4585 #+srcname: table-R-colnames(table=test-table-colnames)
4586 #+begin_src R :results silent
4587 sum(table$var2 - table$var3)
4588 #+end_src
4590 #+srcname: R-square(x=default-name-doesnt-exist)
4591 #+begin_src R :colnames t
4593 #+end_src
4595 This should return 169. The fact that R is able to use the column name
4596 to index the data frame (x$var3) proves that a table with column names
4597 (a header row) has been recognised as input for the R-square function
4598 block, and that the R-square block has output an elisp table with
4599 column names, and that the colnames have again been recognised when
4600 creating the R variables in this block.
4601 #+srcname: table-R-colnames-org(x = R-square(x=test-table-colnames))
4602 #+begin_src R
4603 x$var3[1]
4604 #+end_src
4609 ** references
4611 Lets pass a references through all of our languages...
4613 Lets start by reversing the table from the previous examples
4615 #+srcname: chained-ref-first
4616 #+begin_src python :var table = test-table
4617 table.reverse()
4618 table
4619 #+end_src
4621 #+resname: chained-ref-first
4622 | 4 | 5 | 6 |
4623 | 1 | 2 | 3 |
4625 Take the first part of the list
4627 #+srcname: chained-ref-second
4628 #+begin_src R :var table = chained-ref-first
4629 table[1]
4630 #+end_src
4632 #+resname: chained-ref-second
4633 | 4 |
4634 | 1 |
4636 Turn the numbers into string
4638 #+srcname: chained-ref-third
4639 #+begin_src emacs-lisp :var table = chained-ref-second
4640 (mapcar (lambda (el) (format "%S" el)) table)
4641 #+end_src
4643 #+resname: chained-ref-third
4644 | "(4)" | "(1)" |
4646 and Check that it is still a list
4648 #+srcname: chained-ref-last
4649 #+begin_src ruby :var table=chained-ref-third
4650 table.class.name
4651 #+end_src
4654 ** source blocks as functions
4656 #+srcname: defun-fibb
4657 #+begin_src emacs-lisp :results silent
4658 (defun fibbd (n) (if (< n 2) 1 (+ (fibbd (- n 1)) (fibbd (- n 2)))))
4659 #+end_src
4662 #+srcname: fibonacci
4663 #+begin_src emacs-lisp :results silent :var n=7
4664 (fibbd n)
4665 #+end_src
4673 ** sbe tests (these don't seem to be working...)
4674 Testing the insertion of results into org-mode tables.
4676 #+srcname: multi-line-output
4677 #+begin_src ruby :results replace
4678 "the first line ends here
4681      and this is the second one
4683 even a third"
4684 #+end_src
4686 #+resname:
4687 : the first line ends here\n\n\n     and this is the second one\n\neven a third
4689 #+srcname: multi-line-error
4690 #+begin_src ruby :results replace
4691 raise "oh nooooooooooo"
4692 #+end_src
4694 #+resname:
4695 : oh nooooooooooo
4697 | the first line ends here... | -:5: warning: parenthesize argument(s) for future version... |
4698 #+TBLFM: $1='(sbe "multi-line-output")::$2='(sbe "multi-line-error")
4700 ** forcing results types tests
4702 #+srcname: test-trivial-vector
4703 #+begin_src emacs-lisp :results vector silent
4705 #+end_src
4707 #+srcname: test-forced-vector-results
4708 #+begin_src ruby :var triv=test-trivial-vector :results silent
4709 triv.class.name
4710 #+end_src
4712 ** sessions
4714 #+srcname: set-ruby-session-var
4715 #+begin_src ruby :session :results silent
4716 var = [1, 2, 3]
4717 :set
4718 #+end_src
4720 #+srcname: get-ruby-session-var
4721 #+begin_src ruby :session :results silent
4722 var.size
4723 #+end_src
4725 #+srcname: set-python-session-var
4726 #+begin_src python :session
4727 var=4
4728 'set'
4729 #+end_src
4731 #+srcname: get-python-session-var
4732 #+begin_src python :session
4734 #+end_src
4736 #+srcname: set-R-session-var
4737 #+begin_src R :session
4738 a <- 5
4739 'set'
4740 #+end_src
4742 #+srcname: get-R-session-var
4743 #+begin_src R :session
4745 #+end_src
4748 * Sandbox
4749   :PROPERTIES:
4750   :CUSTOM_ID: sandbox
4751   :END:
4752 To run these examples evaluate [[file:lisp/org-babel-init.el][org-babel-init.el]]
4754 ** org-babel.el beginning functionality
4756 #+begin_src sh  :results replace
4757 date
4758 #+end_src
4760 #+resname:
4761 : Sun Jul  5 18:54:39 EDT 2009
4763 #+begin_src ruby
4764 Time.now
4765 #+end_src
4767 #+resname:
4768 : Sun Jul 05 18:54:35 -0400 2009
4770 #+begin_src python
4771 "Hello World"
4772 #+end_src
4774 #+resname:
4775 : Hello World
4778 ** org-babel-R
4780 #+begin_src R :results replace
4781 a <- 9
4782 b <- 16
4783 a + b
4784 #+end_src
4786 #+resname:
4787 : 25
4789 #+begin_src R
4790 hist(rgamma(20,3,3))
4791 #+end_src
4795 ** org-babel plays with tables
4796 Alright, this should demonstrate both the ability of org-babel to read
4797 tables into a lisp source code block, and to then convert the results
4798 of the source code block into an org table.  It's using the classic
4799 "lisp is elegant" demonstration transpose function.  To try this
4800 out...
4802 1. evaluate [[file:lisp/org-babel-init.el]] to load org-babel and friends
4803 2. evaluate the transpose definition =\C-c\\C-c= on the beginning of
4804    the source block
4805 3. evaluate the next source code block, this should read in the table
4806    because of the =:var table=previous=, then transpose the table, and
4807    finally it should insert the transposed table into the buffer
4808    immediately following the block
4810 *** Emacs lisp
4812 #+begin_src emacs-lisp :results silent
4813 (defun transpose (table)
4814   (apply #'mapcar* #'list table))
4815 #+end_src
4818 #+TBLNAME: sandbox
4819 | 1 |       2 | 3 |
4820 | 4 | schulte | 6 |
4822 #+begin_src emacs-lisp :var table=sandbox :results replace
4823 (transpose table)
4824 #+end_src
4827 #+begin_src emacs-lisp
4828 '(1 2 3 4 5)
4829 #+end_src
4831 #+resname:
4832 | 1 | 2 | 3 | 4 | 5 |
4834 *** Ruby and Python
4836 #+begin_src ruby :var table=sandbox :results replace
4837 table.first.join(" - ")
4838 #+end_src
4840 #+resname:
4841 : 1 - 2 - 3
4843 #+begin_src python :var table=sandbox
4844 table[0]
4845 #+end_src
4848 #+begin_src ruby :var table=sandbox :results replace
4849 table
4850 #+end_src
4852 #+resname:
4853 : [[1, 2, 3], [4, "schulte", 6]]
4856 | 1 |         2 | 3 |
4857 | 4 | "schulte" | 6 |
4859 #+begin_src python :var table=sandbox :results replace
4860 len(table)
4861 #+end_src
4863 : 2
4865 | "__add__" | "__class__" | "__contains__" | "__delattr__" | "__delitem__" | "__delslice__" | "__doc__" | "__eq__" | "__format__" | "__ge__" | "__getattribute__" | "__getitem__" | "__getslice__" | "__gt__" | "__hash__" | "__iadd__" | "__imul__" | "__init__" | "__iter__" | "__le__" | "__len__" | "__lt__" | "__mul__" | "__ne__" | "__new__" | "__reduce__" | "__reduce_ex__" | "__repr__" | "__reversed__" | "__rmul__" | "__setattr__" | "__setitem__" | "__setslice__" | "__sizeof__" | "__str__" | "__subclasshook__" | "append" | "count" | "extend" | "index" | "insert" | "pop" | "remove" | "reverse" | "sort" |
4867 *** (sandbox table) R
4869 #+TBLNAME: sandbox_r
4870 | 1 |       2 | 3 |
4871 | 4 | schulte | 6 |
4873 #+begin_src R :results replace
4874 x <- c(rnorm(10, mean=-3, sd=1), rnorm(10, mean=3, sd=1))
4876 #+end_src
4878 | -3.35473133869346 |
4879 |    -2.45714878661 |
4880 | -3.32819924928633 |
4881 | -2.97310212756194 |
4882 | -2.09640758369576 |
4883 | -5.06054014378736 |
4884 | -2.20713700711221 |
4885 | -1.37618039712037 |
4886 | -1.95839385821742 |
4887 | -3.90407396475502 |
4888 |  2.51168071590226 |
4889 |  3.96753011570494 |
4890 |  3.31793212627865 |
4891 |  1.99829753972341 |
4892 |  4.00403686419829 |
4893 |  4.63723764452927 |
4894 |  3.94636744261313 |
4895 |  3.58355906547775 |
4896 |  3.01563442274226 |
4897 |   1.7634976849927 |
4899 #+begin_src R var tabel=sandbox_r :results replace
4900 tabel
4901 #+end_src
4903 | 1 |         2 | 3 |
4904 | 4 | "schulte" | 6 |
4906 *** shell
4907 Now shell commands are converted to tables using =org-table-import=
4908 and if these tables are non-trivial (i.e. have multiple elements) then
4909 they are imported as org-mode tables...
4911 #+begin_src sh :results replace
4912 ls -l
4913 #+end_src
4915 | "total"      | 208 | ""    | ""    |    "" |   "" | "" | ""                |
4916 | "-rw-r--r--" |   1 | "dan" | "dan" |    57 | 2009 | 15 | "block"           |
4917 | "-rw-r--r--" |   1 | "dan" | "dan" | 35147 | 2009 | 15 | "COPYING"         |
4918 | "-rw-r--r--" |   1 | "dan" | "dan" |   722 | 2009 | 18 | "examples.org"    |
4919 | "drwxr-xr-x" |   4 | "dan" | "dan" |  4096 | 2009 | 19 | "existing_tools"  |
4920 | "-rw-r--r--" |   1 | "dan" | "dan" |  2207 | 2009 | 14 | "intro.org"       |
4921 | "drwxr-xr-x" |   2 | "dan" | "dan" |  4096 | 2009 | 18 | "org-babel"         |
4922 | "-rw-r--r--" |   1 | "dan" | "dan" |   277 | 2009 | 20 | "README.markdown" |
4923 | "-rw-r--r--" |   1 | "dan" | "dan" | 11837 | 2009 | 18 | "rorg.html"       |
4924 | "-rw-r--r--" |   1 | "dan" | "dan" | 61829 | 2009 | 19 | "#rorg.org#"      |
4925 | "-rw-r--r--" |   1 | "dan" | "dan" | 60190 | 2009 | 19 | "rorg.org"        |
4926 | "-rw-r--r--" |   1 | "dan" | "dan" |   972 | 2009 | 11 | "test-export.org" |
4929 ** silent evaluation
4931 #+begin_src ruby
4932 :im_the_results
4933 #+end_src
4935 : :im_the_results
4937 #+begin_src ruby :results silent
4938 :im_the_results
4939 #+end_src
4941 #+begin_src ruby :results replace
4942 :im_the_results_
4943 #+end_src
4945 : :im_the_results_
4948 ** (sandbox) referencing other source blocks
4949 Doing this in emacs-lisp first because it's trivial to convert
4950 emacs-lisp results to and from emacs-lisp.
4952 *** emacs lisp source reference
4953 This first example performs a calculation in the first source block
4954 named =top=, the results of this calculation are then saved into the
4955 variable =first= by the header argument =:var first=top=, and it is
4956 used in the calculations of the second source block.
4958 #+SRCNAME: top
4959 #+begin_src emacs-lisp
4960 (+ 4 2)
4961 #+end_src
4963 #+begin_src emacs-lisp :var first=top :results replace
4964 (* first 3)
4965 #+end_src
4967 : 18
4969 This example is the same as the previous only the variable being
4970 passed through is a table rather than a number.
4972 #+begin_src emacs-lisp :results silent
4973 (defun transpose (table)
4974   (apply #'mapcar* #'list table))
4975 #+end_src
4977 #+TBLNAME: top_table
4978 | 1 |       2 | 3 |
4979 | 4 | schulte | 6 |
4981 #+SRCNAME: second_src_example
4982 #+begin_src emacs-lisp :var table=top_table
4983 (transpose table)
4984 #+end_src
4986 #+begin_src emacs-lisp :var table=second_src_example :results replace
4987 (transpose table)
4988 #+end_src
4990 | 1 |         2 | 3 |
4991 | 4 | "schulte" | 6 |
4992 *** ruby python
4993 Now working for ruby
4995 #+srcname: start
4996 #+begin_src ruby
4998 #+end_src
5000 #+begin_src ruby :var other=start :results replace
5001 2 * other
5002 #+end_src
5004 and for python
5006 #+SRCNAME: start_two
5007 #+begin_src python
5009 #+end_src
5011 #+begin_src python :var another=start_two :results replace
5012 another*3
5013 #+end_src
5015 *** mixed languages
5016 Since all variables are converted into Emacs Lisp it is no problem to
5017 reference variables specified in another language.
5019 #+SRCNAME: ruby-block
5020 #+begin_src ruby
5022 #+end_src
5024 #+SRCNAME: lisp_block
5025 #+begin_src emacs-lisp :var ruby-variable=ruby-block
5026 (* ruby-variable 8)
5027 #+end_src
5029 #+begin_src python :var lisp_var=lisp_block
5030 lisp_var + 4
5031 #+end_src
5033 : 20
5035 *** R
5037 #+srcname: first_r
5038 #+begin_src R :results replace
5039 a <- 9
5041 #+end_src
5043 : 9
5045 #+begin_src R :var other=first_r :results replace
5046 other + 2
5047 #+end_src
5049 : 11
5052 ** (sandbox) selective export
5054 For exportation tests and examples see (including exportation of
5055 inline source code blocks) [[file:test-export.org]]
5058 ** (sandbox) source blocks as functions
5060 #+srcname: default
5061 #+begin_src emacs-lisp :results silent
5063 #+end_src
5065 #+srcname: triple
5066 #+begin_src emacs-lisp :var n=default :results replace
5067 (* 3 n)
5068 #+end_src
5070 : 15
5072 #+begin_src emacs-lisp :var result=triple(n=3, m=98) :results replace
5073 result
5074 #+end_src
5076 : 294
5078 The following just demonstrates the ability to assign variables to
5079 literal values, which was not implemented until recently.
5081 #+begin_src ruby :var num="eric" :results replace
5082 num+" schulte "
5083 #+end_src
5085 : "eric schulte "
5088 ** (sandbox) inline source blocks
5090 This is an inline source code block src_ruby{1 + 6}.  And another
5091 source block with text output src_emacs-lisp{"eric"}.
5093 This is an inline source code block with header
5094 arguments.  src_ruby[:var n=fibbd( n = 0 )]{n}
5097 ** (sandbox) integration w/org tables
5099 #+begin_src emacs-lisp :results silent
5100 (defun fibbd (n) (if (< n 2) 1 (+ (fibbd (- n 1)) (fibbd (- n 2)))))
5101 #+end_src
5103 #+srcname: fibbd
5104 #+begin_src emacs-lisp :var n=4 :results silent
5105 (fibbd n)
5106 #+end_src
5108 #+begin_src emacs-lisp :results silent
5109 (mapcar #'fibbd '(0 1 2 3 4 5 6 7 8))
5110 #+end_src
5112 Something is not working here.  The function `sbe ' works fine when
5113 called from outside of the table (see the source block below), but
5114 produces an error when called from inside the table.  I think there
5115 must be some narrowing going on during intra-table emacs-lisp
5116 evaluation.
5118 | original | fibbd |
5119 |----------+-------|
5120 |        0 |     1 |
5121 |        1 |     1 |
5122 |        2 |     2 |
5123 |        3 |     3 |
5124 |        4 |     5 |
5125 |        5 |     8 |
5126 |        6 |    13 |
5127 |        7 |    21 |
5128 |        8 |    34 |
5129 |        9 |    55 |
5130 #+TBLFM: $2='(sbe "fibbd" (n $1))
5132 silent-result
5134 #+begin_src emacs-lisp :results silent
5135 (sbe 'fibbd (n "8"))
5136 #+end_src
5139 * Buffer Dictionary
5140  LocalWords:  DBlocks dblocks org-babel el eric fontification