[20/28]
[3/5]
[0/3]
:results silent when eval with prefix argument
[3/3]
[1/1]
[2/2]
[0/5]
[10/13]
Org-Babel enables communication between programming languages and between people.
Org-Babel provides:
Data passes seamlessly between different programming languages, text, and tables.
Data and calculations are embedded in the same document as notes explanations and reports.
This will work for Linux and Mac users, not so sure about shell commands for windows users.
To run place the cursor on the #+begin_src line of the source block
labeled directory-pie and press \C-c\C-c.
cd ~ && du -sc * |grep -v total
| 64 | "Desktop" |
| 11882808 | "Documents" |
| 8210024 | "Downloads" |
| 879800 | "Library" |
| 57344 | "Movies" |
| 7590248 | "Music" |
| 5307664 | "Pictures" |
| 0 | "Public" |
| 152 | "Sites" |
| 8 | "System" |
| 56 | "bin" |
| 3274848 | "mail" |
| 5282032 | "src" |
| 1264 | "tools" |
pie(dirs[,1], labels = dirs[,2])
org-babels own functional tests are contained in a large org-mode table, allowing the test suite to be run be evaluation of the table and the results to be collected in the same table.
This would demonstrate applicability to Reproducible Research, and Literate Programming.
[20/28]
This would allow source blocks to call upon tables, source-blocks, and results in other buffers.
See…
This is listed under graphical output in out objectives.
This should take advantage of the :results file option, and
languages which almost always produce graphical output should set
:results file to true by default. That would handle placing these
results in the buffer. Then if there is a combination of silent and
file :results headers we could drop the results to a temp buffer
and pop open that buffer…
how should we share org-babel?
post to org-mode and ess mailing lists
create a org-babel page on worg
create a short screencast demonstrating org-babel in action
we need to think up some good examples
This could be a place to use org-babel assertions.
for example the first step of a tutorial could assert that the version of the software-package (or whatever) is equal to some value, then source-code blocks could be used with confidence (and executed directly from) the rest of the tutorial.
org-babel is an ideal environment enabling both the development and demonstrationg of the code snippets required as answers to many text-book questions.
maybe something along the lines of calculations from collected grades
Maybe something like the following which outputs sizes of directories
under the home directory, and then instead of the trivial emacs-lisp
block we could use an R block to create a nice pie chart of the
results.
du -sc ~/*
(mapcar #'car sizes)
Allow source code blocks to be called form the command line. This
will be easy using the sbe function in org-babel-table.el.
This will rely upon resolve references to other buffers.
[3/5]
Like the \R{ code } blocks
not sure what the format should be, maybe just something simple
like src_lang[]{} where lang is the name of the source code
language to be evaluated, [] is optional and contains any header
arguments and {} contains the code.
(see the-sandbox)
Putting aside the header argument issue for now we can just run these with the following default header arguments
:results
silent
:exports
results
Need to add an interblock hook (or some such) through org-exp-blocks
We should make it possible to use header arguments.
we should color these blocks differently
should use a span class, and should show original source in tool-tip
Maybe this should be it's own result type (in addition to scalars and vectors). The reason being that some source-code blocks (for example ditaa or anything that results in the creation of a file) may want to pass a file path back to org-mode which could then be inserted into the org-mode buffer as a link to the file…
This would allow for display of images upon export providing
functionality similar to org-exp-blocks only in a more general
manner.
Much of the power of org-R seems to be in it's helper functions for the quick graphing of tables. Should we try to re-implement these functions on top of org-babel?
I'm thinking this may be useful both to add features to org-babel-R and also to potentially suggest extensions of the framework. For example one that comes to mind is the ability to treat a source-code block like a function which accepts arguments and returns results. Actually this can be it's own TODO (see source blocks as functions).
When passing args from the org buffer to R, the following route is used: arg in buffer -> elisp -> tsv on file -> data frame in R. I think it would be possible to avoid having to write to file by constructing an R expression in org-babel-R-assign-elisp, something like this
(org-babel-R-input-command (format "%s <- read.table(textConnection(\"%s\"), sep=\"\\t\", as.is=TRUE)" name (orgtbl-to-tsv value '(:sep "\t" :fmt org-babel-R-quote-tsv-field))))
I haven't tried to implement this yet as it's basically just fiddling with something that works. The only reason for it I can think of would be efficiency and I haven't tested that.
This Didn't work after an initial test. I still think this is a good idea (I also think we should try to do something similar when writing out results frmo R to elisp) however as it wouldn't result in any functional changes I'm bumping it down to deferred for now. [Eric]
for quick tests
| 1 | 2 | 3 |
mean(mean(vec))
2
I don't have any complaints with the current R evaluation code or behaviour, but I think it would be good to use the ESS functions from a political point of view. Plus of course it has the normal benefits of an API (insulates us from any underlying changes etc). [DED]
I'll look into this. I believe that I looked at and rejected these functions initially but now I can't remember why. I agree with your overall point about using API's where available. I will take a look back at these and either switch to using the ess commands, or at least articulate under this TODO the reasons for using our custom R-interaction commands. [Eric]
ess-execute
Lets just replace org-babel-R-input-command with ess-execute.
I tried this, and although it works in some situations, I find that
ess-command will often just hang indefinitely without returning
results. Also ess-execute will occasionally hang, and pops up
the buffer containing the results of the command's execution, which
is undesirable. For now these functions can not be used. Maybe
someone more familiar with the ESS code can recommend proper usage
of ess-command or some other lower-level function which could be
used in place of org-babel-R-input-command.
(ess-command COM &optional BUF SLEEP NO-PROMPT-CHECK)
Send the ESS process command COM and delete the output from the ESS process buffer. If an optional second argument BUF exists save the output in that buffer. BUF is erased before use. COM should have a terminating newline. Guarantees that the value of .Last.value will be preserved. When optional third arg SLEEP is non-nil, `(sleep-for (* a SLEEP))' will be used in a few places where `a' is proportional to `ess-cmd-delay'.
(ess-execute COMMAND &optional INVERT BUFF MESSAGE)
Send a command to the ESS process. A newline is automatically added to COMMAND. Prefix arg (or second arg INVERT) means invert the meaning of `ess-execute-in-process-buffer'. If INVERT is 'buffer, output is forced to go to the process buffer. If the output is going to a buffer, name it BUFF. This buffer is erased before use. Optional fourth arg MESSAGE is text to print at the top of the buffer (defaults to the command if BUFF is not given.)
The body of the R source code block is wrapped in a function
The function is called inside of a write.table function call
writing the results to a table
The table is read using org-table-import
[0/3]
Increasingly it is looking like we're going to want to run all source code blocks in comint buffer (sessions). Which will have the benefits of
allowing background execution
maintaining state between source-blocks
allowing inline blocks w/o header arguments
(like ess-switch-process in .R buffers)
Maybe this could be packaged into a header argument, something
like :R_session which could accept either the name of the
session to use, or the string prompt, in which case we could use
the ess-switch-process command to select a new process.
After C-c C-c on an R code block, the process may appear to block, but C-g can be used to reclaim control of the .org buffer, without interrupting the R evalution. However I believe this is not true of bash/sh evaluation. [Haven't tried other languages] Perhaps a solution is just to background the individual shell commands.
The other languages (aside from emacs lisp) are run through the shell, so if we find a shell solution it should work for them as well.
Adding an ampersand seems to be a supported way to run commands in the background (see external-commands). Although a more extensible solution may involve the use of the call-process-region function.
Going to try this out in a new file org-babel-proc.el. This should contain functions for asynchronously running generic shell commands in the background, and then returning their input.
The sleekest solution to this may be using a comint buffer, and then defining a filter function which would incrementally interpret the results as they are returned, including insertion into the org-mode buffer. This may actually cause more problems than it is worth, what with the complexities of identifying the types of incrementally returned results, and the need for maintenance of a process marker in the org buffer.
It may be nice and not too difficult to place a spinner on/near the evaluating source code block
[DED] This would be a nice feature I think. Although a org-babel purist would say that it's working the wrong way round… After some interactive work in a R buffer, you save the buffer, maybe edit out some lines, and then convert it to org-babel format for posterity. Same for a shell session either in a shell buffer, or pasted from another terminal emulator. And python of course.
when a table range is passed to org-babel as an argument, it should be interpreted as a vector.
| 1 | 2 | simple |
| 2 | 3 | Fixnum:1 |
| 3 | 4 | Array:123456 |
| 4 | 5 | |
| 5 | 6 | |
| 6 | 7 |
"simple"
"#{n.class}:#{n}"
n
Array:123
ar.size
3
how about an alist… org-babel-default-header-args this may already
exist… just execute the following and all source blocks will default
to vector output
(setq org-babel-default-header-args '((:results . "vector")))
currently this isn't happening although it should be
:namer
:namer
see the TODO comment in org-babel-ref.el#org-babel-ref-resolve-reference
:results silent when eval with prefix argument
'silentp
[3/3]
In response to a point in Dan's email. We should allow the user to force scalar or vector results. This could be done with a header argument, and the default behavior could be controlled through a configuration variable.
:scalar
| ":scalar" |
since it doesn't make sense to turn a vector into a scalar, lets just add a two values…
forces the results to be a vector (potentially 1 dimensional)
this throws an error if the result isn't a string, and tries to treat it as a path to a file.
I'm just going to cram all of these into the :results header
argument. Then if we allow multiple header arguments it should
work out, for example one possible header argument string could be
:results replace vector file, which would replace any existing
results forcing the results into an org-mode table, and
interpreting any strings as file paths.
:results headers
:schulte
When inserting into an org-mode buffer create a link with the path
being the value, and optionally the display being the
file-name-nondirectory if it exists.
"something"
This will be useful because blocks like ditaa and dot can return
the string path of their files, and can add file to their results
header.
8
| 8 |
In order to do this we will need to start naming our results.
Since the source blocks are named with #+srcname: lines we can
name results with #+resname: lines (if the source block has no
name then no name is given to the #+resname: line on creation,
otherwise the name of the source block is used).
This will have the additional benefit of allowing results and source blocks to be located in different places in a buffer (and eventually in different buffers entirely).
'schulte
Once source blocks are able to find their own #+resname: lines
we then need to…
(sbe "developing-resnames")
schulte
#+resname lines.
[1/1]
since we are accumulating this nice collection of source-code blocks in the sandbox section we should make use of them as unit tests. What's more, we should be able to actually use org-babel to run these tests.
We would just need to cycle over every source code block under the sandbox, run it, and assert that the return value is equal to what we expect.
I have the feeling that this should be possible using only org-babel functions with minimal or no additional elisp. It would be very cool for org-babel to be able to test itself.
This is now done, see * Tests.
These could be used to make assertions about the results of a source-code block. If the assertion fails then the point could be moved to the block, and error messages and highlighting etc… could ensue
This seems like it would be nice to me, but perhaps it would be inefficient or ugly in implementation? I suppose you could search forward, and if you find #+end_src before you find #+begin_src, then you're inside one. [DED]
Agreed, I think inside of the #+srcname: line would be useful as
well.
'schulte
We should make it easy to call org-babel source blocks from org-mode table formulas. This is practical now that it is possible to pass arguments to org-babel source blocks.
See the related sandbox header for tests/examples.
In the past org-table.el has proven difficult to work with.
Should be a hook in org-table-eval-formula.
Looks like I need to change this if statement (line 2239) into a cond expression.
Allow source code blocks to be called like functions, with arguments specified. We are already able to call a source-code block and assign it's return result to a variable. This would just add the ability to specify the values of the arguments to the source code block assuming any exist. For an example see
When a variable appears in a header argument, how do we differentiate between it's value being a reference or a literal value? I guess this could work just like a programming language. If it's escaped or in quotes, then we count it as a literal, otherwise we try to look it up and evaluate it.
[2/2]
[DED] In similar way to using outline-minor-mode for folding function bodies, can we fold code blocks? #+begin whatever statements are pretty ugly, and in any case when you're thinking about the overall game plan you don't necessarily want to see the code for each Step.
Sounds good, and wasn't too hard to implement. Code blocks should now be fold-able in the same manner as headlines (by pressing TAB on the first line).
So, lets do a three-stage tab cycle… First fold the src block, then fold the results, then unfold.
There's no way to tell if the results are a table or not w/o actually executing the block which would be too expensive of an operation.
[DED] The org-babel buffer contains everything (code, headings and notes/prose describing what you're up to, textual/numeric/graphical code output, etc). However on export to html / LaTeX one might want to include only a subset of that content. For example you might want to create a presentation of what you've done which omits the code.
[EMS] So I think this should be implemented as a property which can
be set globally or on the outline header level (I need to review
the mechanics of org-mode properties). And then as a source block
header argument which will apply only to a specific source code
block. A header argument of :export with values of
code
just show the code in the source code block
none
don't show the code or the results of the evaluation
results
just show the results of the code evaluation (don't show the actual code)
both
show both the source code, and the results
this will be done in (sandbox) selective export.
This would be useful across all types of source block. Currently
there is a :replace t option to control output, this could be
generalized to an :output option which could take the following
options (maybe more)
t
this would be the default, and would simply insert the results after the source block
replace
to replace any results which may already be there
silent
this would inhibit any insertion of the results
This is now implemented see the example in the sandbox
This is now working (see (sandbox-table)-R). Although it's not that impressive until we are able to print table results from R.
everything is working but R and shell
This has already been tackled by Dan in org-R:check-dimensions. The functions there should be useful in combination with R-export-to-csv as a means of converting multidimensional R objects to emacs lisp.
It may be as simple as first checking if the data is multidimensional,
and then, if so using write to write the data out to a temporary
file from which emacs can read the data in using org-table-import.
Looking into this further, is seems that there is no such thing as a scalar in R R-scalar-vs-vector. In that light I am not sure how to deal with trivial vectors (scalars) in R. I'm tempted to just treat them as vectors, but then that would lead to a proliferation of trivial 1-cell tables…
Currently it is possible to initialize a variable from an org-mode
table with a block argument like table=sandbox (note that the
variable doesn't have to named table) as in the following example
| 1 | 2 | 3 |
| 4 | schulte | 6 |
(message (format "table = %S" table))
"table = ((1 2 3) (4 \"schulte\" 6))"
It would be good to allow initialization of variables from the results
of other source blocks in the same manner. This would probably
require the addition of #+SRCNAME: example lines for the naming of
source blocks, also the table=sandbox syntax may have to be expanded
to specify whether the target is a source code block or a table
(alternately we could just match the first one with the given name
whether it's a table or a source code block).
At least initially I'll try to implement this so that there is no need to specify whether the reference is to a table or a source-code block. That seems to be simpler both in terms of use and implementation.
This is now working for emacs-lisp, ruby and python (and mixtures of the three) source blocks. See the examples in the sandbox.
This is currently working only with emacs lisp as in the following example in the emacs lisp source reference.
[0/5]
I'm sure there are many more that aren't listed here. Please add them, and bubble any that you particularly care about up to the top.
Any new language should be implemented in a org-babel-lang.el file. Follow the pattern set by org-babel-script.el, org-babel-shell.el and org-babel-R.el.
This could probably be added to org-babel-script.el
(see file result types)
(see file result types)
(see file result types)
[10/13]
for example
'((:results . "replace"))
"the first line ends here
and this is the second one
even a third"
the first line ends here and this is the second one return even a third
E.g. the pie chart example. Despite the save-window-excursion in org-babel-execute:R. (I never learned how to do this properly: org-R jumps all over the place…)
So I know it's generally not a good idea to squash error without
handling them, but in this case the error almost always means that
there was no file contents to be read by org-table-import, so I
think it's ok.
pie(c(1, 2, 3), labels = c(1, 2, 3))
8
8
c(1, 2, 3)
| 1 |
| 2 |
| 3 |
Actually it looks like we were dropping all but the last line.
total = 0
table.each{|n| total += n}
total/table.size
2
Currently the R code seems to work on vertical (but not landscape) tables
"schulte"
num
schulte 11 11 11 schulte 9 9 11
(setq debug-on-error t)
'(1 2 3)
mean(mean(table))
2
| 1 |
| 2 |
| 3 |
mean(table)
E.g. gets recognised as a link (when there's text inside the brackets). This is bad for R code at least, and more generally could be argued to be inappropriate. Is it difficult to get org to ignore text in code blocks? [DED]
I believe Carsten addressed this recently on the mailing list with the comment that it was indeed a difficult issue. I believe this may be one area where we could wait for an upstream (org-mode) fix.
And vice versa. E.g. Try this first with table and then with len(table) [DED]
table
| 1 | 2 | 3 |
| 4 | "schulte" | 6 |
2
Yes, this is certainly a problem. I fear that if we begin replacing anything immediately following a source block (regardless of whether it matches the type of our current results) we may accidentally delete hand written portions of the user's org-mode buffer.
I think that the best solution here would be to actually start labeling results with a line that looks something like…
This would have a couple of benefits…
we wouldn't have to worry about possibly deleting non-results (which is currently an issue)
we could reliably replace results even if there are different types
we could reference the results of a source-code block in variable definitions, which would be useful if for example we don't wish to re-run a source-block every time because it is long-running.
Thoughts? If no-one objects, I believe I will implement the labeling of results.
Well R appears to be reading the tables without issue…
these should be quoted
ls
| "COPYING" |
| "README.markdown" |
| "block" |
| "examples.org" |
| "existing_tools" |
| "intro.org" |
| "org-babel" |
| "rorg.org" |
| "test-export.html" |
| "test-export.org" |
tab[1][0]
README.markdown
as.matrix(tab[2,])
README.markdown
As an example eval the following. Adding a line to test
[3, 4, 5]
ar.first
fix regexp so it works when there's a space trailing the language name
:schulte
The following block resulted in the error below [DED]. It ran without error directly in the shell.
cd ~/work/genopca
for platf in ill aff ; do
for pop in CEU YRI ASI ; do
rm -f $platf/hapmap-genos-$pop-all $platf/hapmap-rs-all
cat $platf/hapmap-genos-$pop-* > $platf/hapmap-genos-$pop-all
cat $platf/hapmap-rs-* > $platf/hapmap-rs-all
done
done
executing source block with sh… finished executing source block string-equal: Args out of range: "", -1, 0
the error string-equal: Args out of range: "", -1, 0 looks like what
used to be output when the block returned an empty results string.
This should be fixed in the current version, you should now see the
following message no result returned by source block.
Something is wrong in org-babel/org-babel-script.el related to the recognition of ruby arrays as such.
[1, 2, 3, 4]
| 1 | 2 | 3 | 4 |
[1, 2, 3, 4]
| 1 | 2 | 3 | 4 |
Evaluate all the cells in this table for a comprehensive test of the org-babel functionality.
Note: if you have customized org-babel-default-header-args then some
of these tests may fail.
| functionality | block | arg | expected | results | pass |
|---|---|---|---|---|---|
| basic evaluation | pass | ||||
| emacs lisp | basic-elisp | 5 | 5 | pass | |
| shell | basic-shell | 6 | 6 | pass | |
| ruby | basic-ruby | org-babel | org-babel | pass | |
| python | basic-python | hello world | hello world | pass | |
| R | basic-R | 13 | 13 | pass | |
| tables | pass | ||||
| emacs lisp | table-elisp | 3 | 3 | pass | |
| ruby | table-ruby | 1-2-3 | 1-2-3 | pass | |
| python | table-python | 5 | 5 | pass | |
| R | table-R | 3.5 | 3.5 | pass | |
| source block references | pass | ||||
| all languages | chained-ref-last | Array | Array | pass | |
| source block functions | pass | ||||
| emacs lisp | defun-fibb | fibbd | fibbd | pass | |
| run over | Fibonacci | 0 | 1 | 1 | pass |
| a | Fibonacci | 1 | 1 | 1 | pass |
| variety | Fibonacci | 2 | 2 | 2 | pass |
| of | Fibonacci | 3 | 3 | 3 | pass |
| different | Fibonacci | 4 | 5 | 5 | pass |
| arguments | Fibonacci | 5 | 8 | 8 | pass |
| bugs and tasks | pass | ||||
| simple ruby arrays | ruby-array-test | 3 | 3 | pass | |
| R number evaluation | bug-R-number-evaluation | 2 | 2 | pass | |
| multi-line ruby blocks | multi-line-ruby-test | 2 | 2 | pass | |
| forcing vector results | test-forced-vector-results | Array | Array | pass |
(+ 1 4)
expr 1 + 5
"org-babel"
'hello world'
b <- 9 b + 4
| 1 | 2 | 3 |
| 4 | 5 | 6 |
(length (car table))
table.first.join("-")
table[1][1]
mean(mean(table))
Lets pass a references through all of our languages…
Lets start by reversing the table from the previous examples
table.reverse
Take the first part of the list
table[1]
Turn the numbers into string
(mapcar (lambda (el) (format "%S" el)) table)
and Check that it is still a list
table.class.name
(defun fibbd (n) (if (< n 2) 1 (+ (fibbd (- n 1)) (fibbd (- n 2)))))
(fibbd n)
Testing the insertion of results into org-mode tables.
"the first line ends here
and this is the second one
even a third"
the first line ends here and this is the second one return even a third
raise "oh nooooooooooo"
-:5: warning: parenthesize argument(s) for future version -:5:in `main': oh nooooooooooo (RuntimeError) from -:8
| the first line ends here… | -:5: warning: parenthesize argument(s) for future version… |
8
triv.class.name
To run these examples evaluate org-babel-init.el
date
Thu May 14 18:52:25 EDT 2009
Time.now
Thu May 14 18:59:09 -0400 2009
"Hello World"
Hello World
a <- 9 b <- 16 a + b
25
hist(rgamma(20,3,3))
Alright, this should demonstrate both the ability of org-babel to read tables into a lisp source code block, and to then convert the results of the source code block into an org table. It's using the classic "lisp is elegant" demonstration transpose function. To try this out…
evaluate org-babel/init.el to load org-babel and friends
evaluate the transpose definition \C-c\C-c on the beginning of
the source block
evaluate the next source code block, this should read in the table
because of the :var table=previous, then transpose the table, and
finally it should insert the transposed table into the buffer
immediately following the block
(defun transpose (table) (apply #'mapcar* #'list table))
| 1 | 2 | 3 |
| 4 | schulte | 6 |
(transpose table)
'(1 2 3 4 5)
| 1 | 2 | 3 | 4 | 5 |
table.first.join(" - ")
"1 - 2 - 3"
table[0]
| 1 | 2 | 3 |
table
| 1 | 2 | 3 |
| 4 | "schulte" | 6 |
len(table)
2
| "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" |
| 1 | 2 | 3 |
| 4 | schulte | 6 |
x <- c(rnorm(10, mean=-3, sd=1), rnorm(10, mean=3, sd=1)) x
| -3.35473133869346 |
| -2.45714878661 |
| -3.32819924928633 |
| -2.97310212756194 |
| -2.09640758369576 |
| -5.06054014378736 |
| -2.20713700711221 |
| -1.37618039712037 |
| -1.95839385821742 |
| -3.90407396475502 |
| 2.51168071590226 |
| 3.96753011570494 |
| 3.31793212627865 |
| 1.99829753972341 |
| 4.00403686419829 |
| 4.63723764452927 |
| 3.94636744261313 |
| 3.58355906547775 |
| 3.01563442274226 |
| 1.7634976849927 |
tabel
| 1 | 2 | 3 |
| 4 | "schulte" | 6 |
Now shell commands are converted to tables using org-table-import
and if these tables are non-trivial (i.e. have multiple elements) then
they are imported as org-mode tables…
ls -l
| "total" | 208 | "" | "" | "" | "" | "" | "" |
| "-rw-r–r–" | 1 | "dan" | "dan" | 57 | 2009 | 15 | "block" |
| "-rw-r–r–" | 1 | "dan" | "dan" | 35147 | 2009 | 15 | "COPYING" |
| "-rw-r–r–" | 1 | "dan" | "dan" | 722 | 2009 | 18 | "examples.org" |
| "drwxr-xr-x" | 4 | "dan" | "dan" | 4096 | 2009 | 19 | "existing_tools" |
| "-rw-r–r–" | 1 | "dan" | "dan" | 2207 | 2009 | 14 | "intro.org" |
| "drwxr-xr-x" | 2 | "dan" | "dan" | 4096 | 2009 | 18 | "org-babel" |
| "-rw-r–r–" | 1 | "dan" | "dan" | 277 | 2009 | 20 | "README.markdown" |
| "-rw-r–r–" | 1 | "dan" | "dan" | 11837 | 2009 | 18 | "rorg.html" |
| "-rw-r–r–" | 1 | "dan" | "dan" | 61829 | 2009 | 19 | "#rorg.org#" |
| "-rw-r–r–" | 1 | "dan" | "dan" | 60190 | 2009 | 19 | "rorg.org" |
| "-rw-r–r–" | 1 | "dan" | "dan" | 972 | 2009 | 11 | "test-export.org" |
:im_the_results
:im_the_results
:im_the_results
:im_the_results_
:im_the_results_
Doing this in emacs-lisp first because it's trivial to convert emacs-lisp results to and from emacs-lisp.
This first example performs a calculation in the first source block
named top, the results of this calculation are then saved into the
variable first by the header argument :var first=top, and it is
used in the calculations of the second source block.
(+ 4 2)
(* first 3)
18
This example is the same as the previous only the variable being passed through is a table rather than a number.
(defun transpose (table) (apply #'mapcar* #'list table))
| 1 | 2 | 3 |
| 4 | schulte | 6 |
(transpose table)
(transpose table)
| 1 | 2 | 3 |
| 4 | "schulte" | 6 |
Now working for ruby
89
2 * other
and for python
98
another*3
Since all variables are converted into Emacs Lisp it is no problem to reference variables specified in another language.
2
(* ruby-variable 8)
lisp_var + 4
20
a <- 9 a
9
other + 2
11
For exportation tests and examples see (including exportation of inline source code blocks) test-export.org
5
(* 3 n)
15
result
294
The following just demonstrates the ability to assign variables to literal values, which was not implemented until recently.
num+" schulte "
"eric schulte "
This is an inline source code block src_ruby{1 + 6}. And another source block with text output src_emacs-lisp{"eric"}.
This is an inline source code block with header arguments. src_ruby[:var n=fibbd( n = 0 )]{n}
(defun fibbd (n) (if (< n 2) 1 (+ (fibbd (- n 1)) (fibbd (- n 2)))))
(fibbd n)
(mapcar #'fibbd '(0 1 2 3 4 5 6 7 8))
Something is not working here. The function `sbe ' works fine when called from outside of the table (see the source block below), but produces an error when called from inside the table. I think there must be some narrowing going on during intra-table emacs-lisp evaluation.
| original | fibbd |
|---|---|
| 0 | 1 |
| 1 | 1 |
| 2 | 2 |
| 3 | 3 |
| 4 | 5 |
| 5 | 8 |
| 6 | 13 |
| 7 | 21 |
| 8 | 34 |
| 9 | 55 |
silent-result
(sbe 'fibbd (n "8"))
LocalWords: DBlocks dblocks org-babel el eric fontification