forked from mirrors/org-mode
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:
commit
809462e3ee
|
@ -122,26 +122,25 @@ last statement in BODY, as elisp."
|
||||||
(full-body (mapconcat #'org-babel-chomp
|
(full-body (mapconcat #'org-babel-chomp
|
||||||
(list body last-value-eval org-babel-R-eoe-indicator) "\n"))
|
(list body last-value-eval org-babel-R-eoe-indicator) "\n"))
|
||||||
(raw (org-babel-comint-with-output buffer org-babel-R-eoe-output nil
|
(raw (org-babel-comint-with-output buffer org-babel-R-eoe-output nil
|
||||||
(insert full-body) (inferior-ess-send-input)))
|
(insert full-body) (inferior-ess-send-input))) broke results)
|
||||||
(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))))))
|
|
||||||
(case result-type
|
(case result-type
|
||||||
(output (org-babel-chomp (mapconcat #'identity results "\n")))
|
|
||||||
(value (org-babel-R-process-value-result
|
(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)
|
(defun org-babel-R-process-value-result (result column-names-p)
|
||||||
"R-specific processing of return value prior to return to org-babel.
|
"R-specific processing of return value prior to return to org-babel.
|
||||||
|
|
|
@ -63,7 +63,7 @@ variable names and the value to be used in the gnuplot code."
|
||||||
|
|
||||||
(defun org-babel-execute:gnuplot (body params)
|
(defun org-babel-execute:gnuplot (body params)
|
||||||
"Execute a block of Gnuplot code with org-babel. This function is
|
"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")
|
(message "executing Gnuplot source code block")
|
||||||
(let* ((vars (org-babel-gnuplot-process-vars params))
|
(let* ((vars (org-babel-gnuplot-process-vars params))
|
||||||
(result-params (split-string (or (cdr (assoc :results params)) "")))
|
(result-params (split-string (or (cdr (assoc :results params)) "")))
|
||||||
|
|
|
@ -232,7 +232,7 @@ the word 'call'."
|
||||||
(goto-char head)
|
(goto-char head)
|
||||||
(if (save-excursion
|
(if (save-excursion
|
||||||
(forward-line -1)
|
(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)))))))
|
(org-babel-clean-text-properties (match-string 1)))))))
|
||||||
|
|
||||||
(defun org-babel-get-src-block-info ()
|
(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."
|
buffer or nil if no such result exists."
|
||||||
(save-excursion
|
(save-excursion
|
||||||
(goto-char (point-min))
|
(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))))
|
(move-beginning-of-line 1) (point))))
|
||||||
|
|
||||||
(defun org-babel-where-is-src-block-result ()
|
(defun org-babel-where-is-src-block-result ()
|
||||||
|
|
596
org-babel.org
596
org-babel.org
|
@ -207,7 +207,139 @@ would then be [[#sandbox][the sandbox]].
|
||||||
#+end_src
|
#+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
|
** PROPOSED optional timestamp for output
|
||||||
Add option to place an (inactive) timestamp at the #+resname, to
|
Add option to place an (inactive) timestamp at the #+resname, to
|
||||||
record when that output was generated.
|
record when that output was generated.
|
||||||
|
@ -341,7 +473,7 @@ org-mode core
|
||||||
org-src-mode would be better.
|
org-src-mode would be better.
|
||||||
**** DONE Changed minor mode name and added hooks
|
**** 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
|
This should be implemented in the org-mode core
|
||||||
|
|
||||||
** TODO resolve references to other org buffers/files
|
** TODO resolve references to other org buffers/files
|
||||||
|
@ -357,6 +489,13 @@ org-mode core
|
||||||
similar status to a source code block?
|
similar status to a source code block?
|
||||||
- Would be nice to allow org and non-org files to be remote
|
- Would be nice to allow org and non-org files to be remote
|
||||||
** TODO figure out how to handle errors during evaluation
|
** 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
|
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
|
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
|
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
|
- file :: use org-open-at-point to open the file
|
||||||
- scalar :: open results unquoted in a new buffer
|
- scalar :: open results unquoted in a new buffer
|
||||||
- tabular :: export the table to a new buffer and open that buffer
|
- tabular :: export the table to a new buffer and open that buffer
|
||||||
|
|
||||||
** TODO Finalise behaviour regarding vector/scalar output
|
** TODO Finalise behaviour regarding vector/scalar output
|
||||||
*** DONE Stop spaces causing vector output
|
*** DONE Stop spaces causing vector output
|
||||||
This simple example of multilingual chaining produces vector output if
|
This simple example of multilingual chaining produces vector output if
|
||||||
|
@ -535,17 +673,86 @@ we should color these blocks differently
|
||||||
*** TODO refine html exportation
|
*** TODO refine html exportation
|
||||||
should use a span class, and should show original source in tool-tip
|
should use a span class, and should show original source in tool-tip
|
||||||
|
|
||||||
** STARTED Column (and row) names of tables in R input/output
|
** TODO LoB: re-implement plotting and analysis functions from org-R
|
||||||
*** DONE column names
|
I'll do this soon, now that we things are a bit more settled and we
|
||||||
This has been implemented: Automatic on input to R; optional in output.
|
have column names in R.
|
||||||
*** TODO row names
|
** PROPOSED conversion between org-babel and noweb (e.g. .Rnw) format
|
||||||
Perhaps add a :rownames header arg. This would be an integer
|
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
|
(usually 1) which would have the effect of post-processing all the
|
||||||
variables created in the R session in the following way: if 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
|
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
|
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
|
take any value other than 1. The default would be nil which would
|
||||||
mean no such behaviour.
|
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
|
*** Old notes
|
||||||
[I don't think it's as problematic as this makes out]
|
[I don't think it's as problematic as this makes out]
|
||||||
This is non-trivial, but may be worth doing, in particular to
|
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]].
|
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?
|
** DEFERRED use textConnection to pass tsv to R?
|
||||||
When passing args from the org buffer to R, the following route is
|
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
|
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
|
2) The function is called inside of a =write.table= function call
|
||||||
writing the results to a table
|
writing the results to a table
|
||||||
3) The table is read using =org-table-import=
|
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?
|
** DONE use example block for large amounts of stdout output?
|
||||||
We're currently `examplizing' with : at the beginning of the line,
|
We're currently `examplizing' with : at the beginning of the line,
|
||||||
but should larger amounts of output be in a
|
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]])
|
(see [[* file result types][file result types]])
|
||||||
|
|
||||||
|
|
||||||
* Bugs [22/34]
|
* Bugs [24/36]
|
||||||
** TODO avoid stripping whitespace from output when :results output
|
** 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
|
** TODO problem with newlines in output when :results value
|
||||||
#+begin_src python :results value
|
#+begin_src python :results value
|
||||||
'\n'.join(map(str, range(4)))
|
'\n'.join(map(str, range(4)))
|
||||||
|
@ -2187,6 +2394,87 @@ packaged into Library of Babel functions.
|
||||||
|
|
||||||
#+resname:
|
#+resname:
|
||||||
: 0
|
: 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
|
** TODO prompt characters appearing in output with R
|
||||||
#+begin_src R :session *R* :results output
|
#+begin_src R :session *R* :results output
|
||||||
x <- 6
|
x <- 6
|
||||||
|
@ -2219,20 +2507,6 @@ for example
|
||||||
#+end_src
|
#+end_src
|
||||||
|
|
||||||
#+resname: this-doesn't-match-orgtbl
|
#+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
|
** 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
|
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
|
not org-babel-ruby-evaluate
|
||||||
** TODO use new merge function [[file:lisp/org-babel-ref.el::t%20nil%20org%20combine%20plists%20args%20nil][here]]?
|
** 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?
|
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
|
** TODO LoB is not populated on startup
|
||||||
org-babel-library-of-babel is nil for me on startup. I have to
|
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.
|
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
|
** DEFERRED weird escaped characters in shell prompt break shell evaluation
|
||||||
E.g. this doesn't work. Should the shell sessions set a sane prompt
|
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
|
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
|
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
|
set this automatically, and we are SOL without a regexp to match
|
||||||
the prompt.
|
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
|
** DONE LoB: with output to buffer, not working in buffers other than library-of-babel.org
|
||||||
*** Initial report
|
*** Initial report
|
||||||
I haven't fixed this yet. org-babel-ref-resolve-reference moves
|
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='(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=""
|
#+TBLFM: $5=""::$6=""
|
||||||
|
|
||||||
|
|
||||||
The second TBLFM line (followed by replacing '[]' with '') can be used
|
The second TBLFM line (followed by replacing '[]' with '') can be used
|
||||||
to blank out the table results, in the absence of a better method.
|
to blank out the table results, in the absence of a better method.
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue