ndwarshuis
/
org-mode
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'master' into gnuplot 

Conflicts:
	lisp/langs/org-babel-gnuplot.el

With respect to the conflict, I will try removing the lines you
mentioned before my next commit.
This commit is contained in:
Eric Schulte 2009-07-20 13:07:29 -06:00
parent c81479b161 4589aacb51
commit 809462e3ee
4 changed files with 466 additions and 172 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
lisp/langs/org-babel-R.el
View File

@ -122,26 +122,25 @@ last statement in BODY, as elisp."
(full-body (mapconcat #'org-babel-chomp
(list body last-value-eval org-babel-R-eoe-indicator) "\n"))
(raw (org-babel-comint-with-output buffer org-babel-R-eoe-output nil
(insert full-body) (inferior-ess-send-input)))
(results
(let ((broke nil))
(delete
nil
(mapcar (lambda (el)
(if (or broke
(and (string-match (regexp-quote org-babel-R-eoe-output)
el) (setq broke t)))
nil
(if (= (length el) 0)
nil
(if (string-match comint-prompt-regexp el)
(substring el (match-end 0))
el))))
(mapcar #'org-babel-trim raw))))))
(insert full-body) (inferior-ess-send-input))) broke results)
(case result-type
(output (org-babel-chomp (mapconcat #'identity results "\n")))
(value (org-babel-R-process-value-result
(org-babel-import-elisp-from-file tmp-file) column-names-p)))))))
(org-babel-import-elisp-from-file tmp-file) column-names-p))
(output
(flet ((extractor
(el)
(if (or broke
(and (string-match (regexp-quote org-babel-R-eoe-output) el)
(setq broke t)))
nil
(if (= (length el) 0)
nil
(if (string-match comint-prompt-regexp el)
(substring el (match-end 0))
el)))))
(mapconcat
#'identity
(delete nil (mapcar #'extractor (mapcar #'org-babel-chomp raw))) "\n"))))))))
(defun org-babel-R-process-value-result (result column-names-p)
"R-specific processing of return value prior to return to org-babel.

2
lisp/langs/org-babel-gnuplot.el
View File

@ -63,7 +63,7 @@ variable names and the value to be used in the gnuplot code."
(defun org-babel-execute:gnuplot (body params)
"Execute a block of Gnuplot code with org-babel. This function is
called by `org-babel-execute-src-block'."
called by `org-babel-execute-src-block' via multiple-value-bind."
(message "executing Gnuplot source code block")
(let* ((vars (org-babel-gnuplot-process-vars params))
(result-params (split-string (or (cdr (assoc :results params)) "")))

5
lisp/org-babel.el
View File

@ -232,7 +232,7 @@ the word 'call'."
(goto-char head)
(if (save-excursion
(forward-line -1)
(looking-at "#\\+srcname:[ \f\t\n\r\v]*\\([^ \f\t\n\r\v]+\\)\(\\(.*\\)\)"))
(looking-at "#\\+srcname:[ \f\t\n\r\v]*\\([^ ()\f\t\n\r\v]+\\)\(\\(.*\\)\)"))
(org-babel-clean-text-properties (match-string 1)))))))
(defun org-babel-get-src-block-info ()
@ -360,7 +360,8 @@ according to org-babel-named-src-block-regexp."
buffer or nil if no such result exists."
(save-excursion
(goto-char (point-min))
(when (re-search-forward (concat "#\\+resname:[ \t]*" (regexp-quote name)) nil t)
(when (re-search-forward ;; ellow end-of-buffer in following regexp?
(concat "#\\+resname:[ \t]*" (regexp-quote name) "[ \t\n\f\v\r]") nil t)
(move-beginning-of-line 1) (point))))
(defun org-babel-where-is-src-block-result ()

596
org-babel.org
View File

@ -207,7 +207,139 @@ would then be [[#sandbox][the sandbox]].
#+end_src
* Tasks [32/50]
* Tasks [35/57]
** PROPOSED implement fully recursive evaluation machinery
The current parser / evaluator fails with greater levels of nested
function block calls (example below). If we want to overcome this I
think we'd have to redesign some of the evaluation
mechanism. Seeing as we are also facing issues like dealing with
default argument values, and seeing as we now know how we want the
library of babel to behave in addition to the source blocks, now
might be a good time to think about this. It would be nice to do
the full thing at some point, but otoh we may not consider it a
massive priority.
AIui, there are two stages: (i) construct a parse tree, and (ii)
evaluate it and return the value at the root. In the parse tree
each node represents an unevaluated value (either a literal value
or a reference). Node v may have descendent nodes, which represent
values upon which node v's evaluation depends. Once that tree is
constructed, then we evaluate the nodes from the tips towards the
root (a post-order traversal).
[This would also provide a solution for concatenating the STDOUTs
of called blocks, which is a [[*allow%20output%20mode%20to%20return%20stdout%20as%20value][task below]]; we concatenate them in
whatever order the traversal is done in.]
In addition to the variable references (i.e. daughter nodes), each
node would contain the information needed to evaluate that node
(e.g. lang body). Then we would pass a function postorder over the
tree which would call o-b-execute-src-block at each node, finally
returning the value at the root.
Fwiw I made a very tentative small start at stubbing this out in
org-babel-call.el in the 'evaluation' branch. And I've made a start
at sketching a parsing algorithm below.
*** Parse tree algorithm
Seeing as we're just trying to parse a string like
f(a=1,b=g(c=2,d=3)) it shouldn't be too hard. But of course there
are 'proper' parsers written in elisp out there,
e.g. [[http://cedet.sourceforge.net/semantic.shtml][Semantic]]. Perhaps we can find what we need -- our syntax is
pretty much the same as python and R isn't it?
Or, a complete hack, but maybe it would be we easy to transform it
to XML and then parse that with some existing tool?
But if we're doing it ourselves, something very vaguely like this?
(I'm sure there're lots of problems with this)
#+srcname: org-babel-call-parse(call)
#+begin_src python
## we are currently reading a reference name: the name of the root function
whereami = "refname"
node = root = Node()
for c in call_string:
if c == '(':
varnum = 0
whereami = "varname" # now we're reading a variable name
if c == '=':
new = Node()
node.daughters = [node.daughters, new]
new.parent = node
node = new
whereami = "refname"
if c == ',':
whereami = "varname"
varnum += 1
elif c == ')':
node = node.parent
elif c == ' ':
pass
else:
if whereami = "varname":
node.varnames[varnum] += c
elif whereami = "refname":
node.name += c
#+end_src
*** Example that fails
#+srcname: adder(a=0, b=0)
#+begin_src python
a+b
#+end_src
#+srcname: one()
#+begin_src python :results silent
1
#+end_src
This works
#+srcname: level-one-nesting
#+begin_src python :var arg=adder(a=one(),b=one())
arg
#+end_src
But this doesn't
#+srcname: level-one-nesting
#+begin_src python :var arg=adder(a=adder(a=one(),b=one()),b=adder(a=one(),b=one()))
arg
#+end_src
** PROPOSED Default args
This would be good thing to address soon. I'm imagining that
e.g. here, the 'caller' block would return the answer 30. I believe
there's a few issues here: i.e. the naked 'a' without a reference
is not understood; the default arg b=6 is not understood.
#+srcname: adder(a, b=6)
#+begin_src python
a+b
#+end_src
#+srcname: caller(var=adder(a=24))
#+begin_src python
var
#+end_src
** PROPOSED allow `anonymous' function block with function call args?
My question here is simply whether we're going to allow
#+begin_src python(arg=ref)
# whatever
#+end_src
but with preference given to
#+srcname blockname(arg=ref)
** PROPOSED allow :result as synonym for :results?
** PROPOSED allow 'output mode to return stdout as value?
Maybe we should allow this. In fact, if block x is called
with :results output, and it references blocks y and z, then
shouldn't the output of x contain a concatenation of the outputs of
y and z, together with x's own output? That would raise the
question of what happens if y is defined with :results output and z
with :results value. I guess z's (possibly vector/tabular) output
would be inside a literal example block containing the whole lot.
** PROPOSED optional timestamp for output
Add option to place an (inactive) timestamp at the #+resname, to
record when that output was generated.
@ -341,7 +473,7 @@ org-mode core
org-src-mode would be better.
**** DONE Changed minor mode name and added hooks
**** DEFERRED a hook called when the src edit buffer is created
**** DONE a hook called when the src edit buffer is created
This should be implemented in the org-mode core
** TODO resolve references to other org buffers/files
@ -357,6 +489,13 @@ org-mode core
similar status to a source code block?
- Would be nice to allow org and non-org files to be remote
** TODO figure out how to handle errors during evaluation
I expect it will be hard to do this properly, but ultimately it
would be nice to be able to specify somewhere to receive STDERR,
and to be warned if it is non-empty.
Probably simpler in non-session evaluation than session? At least
the mechanism will be different I guess.
R has a try function, with error handling, along the lines of
python. I bet ruby does too. Maybe more of an issue for functional
style; in my proposed scripting style the error just gets dumped to
@ -435,7 +574,6 @@ This could also act reasonably with other results types...
- file :: use org-open-at-point to open the file
- scalar :: open results unquoted in a new buffer
- tabular :: export the table to a new buffer and open that buffer
** TODO Finalise behaviour regarding vector/scalar output
*** DONE Stop spaces causing vector output
This simple example of multilingual chaining produces vector output if
@ -535,17 +673,86 @@ we should color these blocks differently
*** TODO refine html exportation
should use a span class, and should show original source in tool-tip
** STARTED Column (and row) names of tables in R input/output
*** DONE column names
This has been implemented: Automatic on input to R; optional in output.
*** TODO row names
Perhaps add a :rownames header arg. This would be an integer
** TODO LoB: re-implement plotting and analysis functions from org-R
I'll do this soon, now that we things are a bit more settled and we
have column names in R.
** PROPOSED conversion between org-babel and noweb (e.g. .Rnw) format
I haven't thought about this properly. Just noting it down. What
Sweave uses is called "R noweb" (.Rnw).
I found a good description of noweb in the following article (see
the [[http://www.cs.tufts.edu/~nr/pubs/lpsimp.pdf][pdf]]).
I think there are two parts to noweb, the construction of
documentation and the extraction of source-code (with notangle).
*documentation*: org-mode handles all of our documentation needs in
a manner that I believe is superior to noweb.
*source extraction* At this point I don't see anyone writing large
applications with 100% of the source code contained in org-babel
files, rather I see org-babel files containing things like
- notes with active code chunks
- interactive tutorials
- requirements documents with code running test suites
- and of course experimental reports with the code to run the
experiment, and perform analysis
Basically I think the scope of the programs written in org-babel
(at least initially) will be small enough that it wont require the
addition of a tangle type program to extract all of the source code
into a running application.
On the other hand, since we already have named blocks of source
code which reference other blocks on which they rely, this
shouldn't be too hard to implement either on our own, or possibly
relying on something like noweb/notangle.
** PROPOSED support for passing paths to files between source blocks
Maybe this should be it's own result type (in addition to scalars and
vectors). The reason being that some source-code blocks (for example
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.
** DEFERRED Support rownames and other org babel table features?
The full org table features are detailed in the manual [[http://orgmode.org/manual/Advanced-features.html#Advanced-features][here]].
*** rownames
Perhaps add a :rownames header arg. This would be an integer
(usually 1) which would have the effect of post-processing all the
variables created in the R session in the following way: if the
integer is j, set the row names to the contents of column j and
delete column j. Perhaps it is artificial to allow this integer to
take any value other than 1. The default would be nil which would
mean no such behaviour.
Actually I don't know about that. If multiple variables are passed
in, it's not appropriate to alter them all in the same way. The
rownames specification would normally refer to just one of the
variables. For now maybe just say this has to be done in R. E.g.
#+TBLNAME: sample-sizes
| collection | size | exclude | include | exclude2 | include2 |
|-----------------+------+---------+---------+----------+----------|
| 58C | 2936 | 8 | 2928 | 256 | 2680 |
| MS | 5852 | 771 | 5081 | 771 | 5081 |
| NBS | 2929 | 64 | 2865 | 402 | 2527 |
| POBI | 2717 | 1 | 2716 | 1 | 2716 |
| 58C+MS+NBS+POBI | | | 13590 | | 13004 |
#+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)
#+srcname: make-size-table(size=sample-sizes)
#+begin_src R
rownames(size) <- size[,1]
size <- size[,-1]
#+end_src
*** Old notes
[I don't think it's as problematic as this makes out]
This is non-trivial, but may be worth doing, in particular to
@ -643,106 +850,6 @@ tabel
Another example is in the [[*operations%20in%20on%20tables][grades example]].
** TODO re-implement helper functions from org-R
*** Initial statement [Eric]
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][source blocks as functions]]).
*** Objectives [Dan]
- We want to provide convenient off-the-shelf actions
(e.g. plotting data) that make use of our new code evaluation
environment but do not require any actual coding.
*** Initial Design proposal [Dan]
- *Input data* will be specified using the same mechanism as :var
references, thus the input data may come from a table, or
another source block, and it is initially available as an elisp
data structure.
- We introduce a new #+ line, e.g. #+BABELDO. C-c C-c on that
line will apply an *action* to the referenced data.
- *Actions correspond to source blocks*: our library of available
actions will be a library of org-babel source blocks. Thus the
code for executing an action, and the code for dealing with the
output of the action will be the same code as for executing
source blocks in general
- Optionally, the user can have the relevant source block inserted
into the org buffer after the (say) #+BABELDO line. This will
allow the user to fine tune the action by modifying the code
(especially useful for plots).
- So maybe a #+BABELDO line will have header args
- :data (a reference to a table or source code block)
- :action (or should that be :srcname?) which will be something
like :action pie-chart, referring to a source block which will
be executed with the :data referent passed in using a :var arg.
- :showcode or something controlling whether to show the code
*** Modification to design
I'm implementing this, at least initially, as a new interpreter
named 'babel', which has an empty body. 'babel' blocks take
a :srcname header arg, and look for the source-code block with
that name. They then execute the referenced block, after first
appending their own header args on to the target block's header
args.
If the target block is in the library of babel (a.o.t. e.g. the
current buffer), then the code in the block will refer to the
input data with a name dictated by convention (e.g. __data__
(something which is syntactically legal in all languages...). Thus
the babel block will use a :var __data__ = whatever header arg to
reference the data to be plotted.
*** Current design
This is covered by the [[file:library-of-babel.org][Library of Babel]], which will contain
ready-made source blocks designed to carry out useful common tasks.
** PROPOSED conversion between org-babel and noweb (e.g. .Rnw) format
I haven't thought about this properly. Just noting it down. What
Sweave uses is called "R noweb" (.Rnw).
I found a good description of noweb in the following article (see
the [[http://www.cs.tufts.edu/~nr/pubs/lpsimp.pdf][pdf]]).
I think there are two parts to noweb, the construction of
documentation and the extraction of source-code (with notangle).
*documentation*: org-mode handles all of our documentation needs in
a manner that I believe is superior to noweb.
*source extraction* At this point I don't see anyone writing large
applications with 100% of the source code contained in org-babel
files, rather I see org-babel files containing things like
- notes with active code chunks
- interactive tutorials
- requirements documents with code running test suites
- and of course experimental reports with the code to run the
experiment, and perform analysis
Basically I think the scope of the programs written in org-babel
(at least initially) will be small enough that it wont require the
addition of a tangle type program to extract all of the source code
into a running application.
On the other hand, since we already have named blocks of source
code which reference other blocks on which they rely, this
shouldn't be too hard to implement either on our own, or possibly
relying on something like noweb/notangle.
** PROPOSED support for passing paths to files between source blocks
Maybe this should be it's own result type (in addition to scalars and
vectors). The reason being that some source-code blocks (for example
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.
** DEFERRED use textConnection to pass tsv to R?
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
@ -935,6 +1042,70 @@ to the command if BUFF is not given.)
2) The function is called inside of a =write.table= function call
writing the results to a table
3) The table is read using =org-table-import=
** DONE extensible library of callable source blocks
*** Current design
This is covered by the [[file:library-of-babel.org][Library of Babel]], which will contain
ready-made source blocks designed to carry out useful common tasks.
*** Initial statement [Eric]
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][source blocks as functions]]).
*** Objectives [Dan]
- We want to provide convenient off-the-shelf actions
(e.g. plotting data) that make use of our new code evaluation
environment but do not require any actual coding.
*** Initial Design proposal [Dan]
- *Input data* will be specified using the same mechanism as :var
references, thus the input data may come from a table, or
another source block, and it is initially available as an elisp
data structure.
- We introduce a new #+ line, e.g. #+BABELDO. C-c C-c on that
line will apply an *action* to the referenced data.
- *Actions correspond to source blocks*: our library of available
actions will be a library of org-babel source blocks. Thus the
code for executing an action, and the code for dealing with the
output of the action will be the same code as for executing
source blocks in general
- Optionally, the user can have the relevant source block inserted
into the org buffer after the (say) #+BABELDO line. This will
allow the user to fine tune the action by modifying the code
(especially useful for plots).
- So maybe a #+BABELDO line will have header args
- :data (a reference to a table or source code block)
- :action (or should that be :srcname?) which will be something
like :action pie-chart, referring to a source block which will
be executed with the :data referent passed in using a :var arg.
- :showcode or something controlling whether to show the code
*** Modification to design
I'm implementing this, at least initially, as a new interpreter
named 'babel', which has an empty body. 'babel' blocks take
a :srcname header arg, and look for the source-code block with
that name. They then execute the referenced block, after first
appending their own header args on to the target block's header
args.
If the target block is in the library of babel (a.o.t. e.g. the
current buffer), then the code in the block will refer to the
input data with a name dictated by convention (e.g. __data__
(something which is syntactically legal in all languages...). Thus
the babel block will use a :var __data__ = whatever header arg to
reference the data to be plotted.
** DONE Column names in R input/output
This has been implemented: Automatic on input to R; optional in
output. Note that this equates column names with the header row in
an org table; whereas org actually has a mechanism whereby a row
with a '!' in the first field defines column names. I have not
attempted to support these org table mechanisms yet. See [[*Support%20rownames%20and%20other%20org%20babel%20table%20features][this
DEFERRED todo item]].
** DONE use example block for large amounts of stdout output?
We're currently `examplizing' with : at the beginning of the line,
but should larger amounts of output be in a
@ -2178,8 +2349,44 @@ packaged into Library of Babel functions.
(see [[* file result types][file result types]])
* Bugs [22/34]
** TODO avoid stripping whitespace from output when :results output
* Bugs [24/36]
** TODO allow srcname to omit function call parentheses
Someone needs to revisit those regexps. Is there an argument for
moving some of the regexps used to match function calls into
defvars? (i.e. in o-b.el and o-b-ref.el)
** TODO creeping blank lines
There's still inappropriate addition of blank lines in some circumstances.
Hmm, it's a bit confusing. It's to do with o-b-remove-result. LoB
removes the entire (#+resname and result) and starts from scratch,
whereas #+begin_src only removes the result. I haven't worked out
what the correct fix is yet. Maybe the right thing to do is to make
sure that those functions (o-b-remove-result et al.) are neutral
with respect to newlines. Sounds easy, but...
E.g.
#+begin_src sh
b=5
#+end_src
Compare the results of
#+lob: python-add(a=5, b=17)
#+resname: python-add(a=5, b=17)
: 22
--------------------------------
#+begin_src python
23
#+end_src
#+resname:
: 23
---------------------
** TODO problem with newlines in output when :results value
#+begin_src python :results value
'\n'.join(map(str, range(4)))
@ -2187,6 +2394,87 @@ packaged into Library of Babel functions.
#+resname:
: 0
Whereas I was hoping for
| 0 |
| 1 |
| 2 |
| 3 |
This is some sort of non-printing char / quoting issue I think. Note
that
#+begin_src python :results value
'\\n'.join(map(str, range(4)))
#+end_src
#+resname:
: 0\n1\n2\n3
Also, note that
#+begin_src python :results output
print('\n'.join(map(str, range(4))))
#+end_src
#+resname:
: 0
: 1
: 2
: 3
*** collapsing consecutive newlines in string output
This is an example of the same bug
#+srcname: multi-line-string-output
#+begin_src ruby :results output
"the first line ends here
and this is the second one
even a third"
#+end_src
This doesn't produce anything at all now. I believe that's because
I've changed things so that :results output really does *not* get the
value of the block, only the STDOUT. So if we add a print statement
this works OK.
#+srcname: multi-line-string-output
#+begin_src ruby :results output
print "the first line ends here
and this is the second one
even a third"
#+end_src
#+resname:
: the first line ends here
:
:
: and this is the second one
:
: even a third
However, the behaviour with :results value is wrong
#+srcname: multi-line-string-value
#+begin_src ruby
"the first line ends here
and this is the second one
even a third"
#+end_src
#+resname:
: 0
** TODO prompt characters appearing in output with R
#+begin_src R :session *R* :results output
x <- 6
@ -2219,20 +2507,6 @@ for example
#+end_src
#+resname: this-doesn't-match-orgtbl
** TODO collapsing consecutive newlines in string output
#+srcname: multi-line-string-output
#+begin_src ruby :results output
"the first line ends here
and this is the second one
even a third"
#+end_src
#+resname: multi-line-string-output
** PROPOSED external shell execution can't isolate return values
I have no idea how to do this as of yet. The result is that when
@ -2261,36 +2535,13 @@ the same for the other languages. [Dan]
not org-babel-ruby-evaluate
** TODO use new merge function [[file:lisp/org-babel-ref.el::t%20nil%20org%20combine%20plists%20args%20nil][here]]?
And at other occurrences of org-combine-plists?
** TODO creeping blank lines
There's still inappropriate addition of blank lines in some circumstances. E.g.
#+begin_src sh
b=5
#+end_src
Compare the results of
#+lob: python-add(a=5, b=17)
#+resname: python-add(a=5, b=17)
: 22
--------------------------------
#+begin_src python
23
#+end_src
#+resname:
: 23
---------------------
Hmm, it's a bit confusing. I think it's to do with the fact that
LoB removes the entire (#+resname and result) and starts from
scratch, whereas #+begin_src only removes the result. I haven't
worked out what the correct fix is yet.
** TODO LoB is not populated on startup
org-babel-library-of-babel is nil for me on startup. I have to
evaluate the [[file:lisp/org-babel-lob.el::][org-babel-lob-ingest]] line manually.
** DONE avoid stripping whitespace from output when :results output
This may be partly solved by using o-b-chomp rather than o-b-trim
in the o-b-LANG-evaluate functions.
** DEFERRED weird escaped characters in shell prompt break shell evaluation
E.g. this doesn't work. Should the shell sessions set a sane prompt
when they start up? Or is it a question of altering
@ -2319,6 +2570,48 @@ b=5
the user's regular emacs init. I can't think of a way for us to
set this automatically, and we are SOL without a regexp to match
the prompt.
** DONE function calls in #+srcname: refs
My srcname references don't seem to be working for function
calls. This needs fixing.
#+srcname: called()
#+begin_src python
59
#+end_src
srcname function call doesn't work for calling a source block
#+srcname: caller(var1=called())
#+begin_src python
var1
#+end_src
#+resname: caller
: 59
They do work for a simple reference
#+srcname: caller2(var1=56)
#+begin_src python
var1
#+end_src
#+resname: caller2
: 59
and they do work for :var header arg
#+srcname: caller3
#+begin_src python :var var1=called()
var1
#+end_src
#+resname:
: 58
** DONE LoB: with output to buffer, not working in buffers other than library-of-babel.org
*** Initial report
I haven't fixed this yet. org-babel-ref-resolve-reference moves
@ -2771,6 +3064,7 @@ of these tests may fail.
#+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))
#+TBLFM: $5=""::$6=""
The second TBLFM line (followed by replacing '[]' with '') can be used
to blank out the table results, in the absence of a better method.