2009-08-05 10:02:25 -04:00
|
|
|
#+title: The Library of Babel
|
2009-06-12 20:26:28 -04:00
|
|
|
#+SEQ_TODO: TODO PROPOSED | DONE DEFERRED REJECTED
|
2009-08-05 10:02:25 -04:00
|
|
|
#+OPTIONS: H:3 num:nil toc:2 \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:t skip:nil d:(HIDE) tags:not-in-toc
|
|
|
|
|
#+STARTUP: odd hideblocks
|
2009-09-13 23:15:17 -04:00
|
|
|
#+STYLE: <style type="text/css">#outline-container-1 { clear:both; }</style>
|
|
|
|
|
|
|
|
|
|
#+begin_html
|
|
|
|
|
<div id="logo" style="float: left; text-align: center; max-width: 340px; font-size: 8pt; margin-left: 1em;">
|
|
|
|
|
<p>
|
|
|
|
|
<img src="../../images/babel/library-of-babel.png" alt="Library of Babel"/>
|
|
|
|
|
<div id="attr">
|
|
|
|
|
The Library of Babel, by Pierre Clayette
|
|
|
|
|
<p>
|
|
|
|
|
<a href="http://downlode.org/Etext/library_of_babel.html">Full text of the Borges short story</a>
|
|
|
|
|
</p>
|
|
|
|
|
</div>
|
|
|
|
|
</p>
|
|
|
|
|
</div>
|
|
|
|
|
#+end_html
|
2009-06-12 20:26:28 -04:00
|
|
|
|
2009-08-05 10:02:25 -04:00
|
|
|
* Introduction
|
|
|
|
|
The Library of Babel is an extensible collection of ready-made and
|
|
|
|
|
easily-shortcut-callable source-code blocks for handling common
|
|
|
|
|
tasks. Org-babel comes pre-populated with the source-code blocks
|
|
|
|
|
located in this file. It is possible to add source-code blocks from
|
2009-08-05 15:35:07 -04:00
|
|
|
any org-mode file to the library by calling =(org-babel-lob-ingest
|
|
|
|
|
"path/to/file.org")=.
|
2009-09-13 23:15:17 -04:00
|
|
|
|
|
|
|
|
This file is included in worg mainly less for viewing through the
|
|
|
|
|
web interface, and more for contribution through the worg git
|
|
|
|
|
repository. If you have code snippets that you think others may
|
|
|
|
|
find useful please add them to this file and [[file:~/src/worg/worg-git.org::contribute-to-worg][contribute them]] to
|
|
|
|
|
worg.
|
|
|
|
|
|
|
|
|
|
The raw Org-mode text of this file can be downloaded at
|
|
|
|
|
[[repofile:contrib/babel/library-of-babel.org][library-of-babel.org]]
|
2009-08-05 10:02:25 -04:00
|
|
|
|
2009-06-14 17:10:04 -04:00
|
|
|
* Plotting code
|
2009-08-05 10:02:25 -04:00
|
|
|
|
|
|
|
|
** R
|
2009-06-14 17:10:04 -04:00
|
|
|
Plot column 2 (y axis) against column 1 (x axis). Columns 3 and beyond, if present, are ignored.
|
2009-06-14 10:54:55 -04:00
|
|
|
|
Enabling LoB to put results in buffer, and slowly moving towards more
unified concept of function calls.
Previously LoB calls were not able to produce results in the
buffer. These changes go some way to allowing them to do that. [There
are still some bugs to deal with]. That meant changing org-babel.el so
that there is a notion of the `source block name' for a LoB line, in
order to construct a #+resname (currently I've made the name the same
as the function call).
I'm also slowly moving towards unifying the notion of `function calls'
a bit more: I've changed the org-babel-lob-one-liner-regexp so that
instead of a monolithic match it now matches first the function name,
and second the function arguments in
parentheses. org-babel-lob-get-info makes that match, and although it
still concatenates them and returns the string, the two elements can
be accessed immediately afterwards using match-string. So that
situation is very similar to org-babel-get-src-block-name, whose
job (in this branch) is also to parse the function *name* and the
function *arguments*. In a few places in the code (esp. function
names), I think the word `info' should be replaced with `call' or
`function call', which I believe more accurately indicates what the
`info' is: a function definition, together with bound
arguments/references.
The function call syntax, i.e. function-name(arg1=ref1), originally
introduced for references (and thereby in LoB), and which I'm
proposing we use throughout, raises the question of default arguments,
and those being over-ridden by supplied arguments, as in e.g. python,
and R.
2009-07-10 22:59:10 -04:00
|
|
|
#+srcname: R-plot(data=R-plot-example-data)
|
|
|
|
|
#+begin_src R :session *R*
|
2009-06-14 10:54:55 -04:00
|
|
|
plot(data)
|
|
|
|
|
#+end_src
|
|
|
|
|
|
Enabling LoB to put results in buffer, and slowly moving towards more
unified concept of function calls.
Previously LoB calls were not able to produce results in the
buffer. These changes go some way to allowing them to do that. [There
are still some bugs to deal with]. That meant changing org-babel.el so
that there is a notion of the `source block name' for a LoB line, in
order to construct a #+resname (currently I've made the name the same
as the function call).
I'm also slowly moving towards unifying the notion of `function calls'
a bit more: I've changed the org-babel-lob-one-liner-regexp so that
instead of a monolithic match it now matches first the function name,
and second the function arguments in
parentheses. org-babel-lob-get-info makes that match, and although it
still concatenates them and returns the string, the two elements can
be accessed immediately afterwards using match-string. So that
situation is very similar to org-babel-get-src-block-name, whose
job (in this branch) is also to parse the function *name* and the
function *arguments*. In a few places in the code (esp. function
names), I think the word `info' should be replaced with `call' or
`function call', which I believe more accurately indicates what the
`info' is: a function definition, together with bound
arguments/references.
The function call syntax, i.e. function-name(arg1=ref1), originally
introduced for references (and thereby in LoB), and which I'm
proposing we use throughout, raises the question of default arguments,
and those being over-ridden by supplied arguments, as in e.g. python,
and R.
2009-07-10 22:59:10 -04:00
|
|
|
#+tblname: R-plot-example-data
|
2009-06-14 10:54:55 -04:00
|
|
|
| 1 | 2 |
|
|
|
|
|
| 2 | 4 |
|
|
|
|
|
| 3 | 9 |
|
|
|
|
|
| 4 | 16 |
|
|
|
|
|
| 5 | 25 |
|
|
|
|
|
|
Enabling LoB to put results in buffer, and slowly moving towards more
unified concept of function calls.
Previously LoB calls were not able to produce results in the
buffer. These changes go some way to allowing them to do that. [There
are still some bugs to deal with]. That meant changing org-babel.el so
that there is a notion of the `source block name' for a LoB line, in
order to construct a #+resname (currently I've made the name the same
as the function call).
I'm also slowly moving towards unifying the notion of `function calls'
a bit more: I've changed the org-babel-lob-one-liner-regexp so that
instead of a monolithic match it now matches first the function name,
and second the function arguments in
parentheses. org-babel-lob-get-info makes that match, and although it
still concatenates them and returns the string, the two elements can
be accessed immediately afterwards using match-string. So that
situation is very similar to org-babel-get-src-block-name, whose
job (in this branch) is also to parse the function *name* and the
function *arguments*. In a few places in the code (esp. function
names), I think the word `info' should be replaced with `call' or
`function call', which I believe more accurately indicates what the
`info' is: a function definition, together with bound
arguments/references.
The function call syntax, i.e. function-name(arg1=ref1), originally
introduced for references (and thereby in LoB), and which I'm
proposing we use throughout, raises the question of default arguments,
and those being over-ridden by supplied arguments, as in e.g. python,
and R.
2009-07-10 22:59:10 -04:00
|
|
|
#+lob: R-plot(data=R-plot-example-data)
|
|
|
|
|
|
2009-07-11 23:59:51 -04:00
|
|
|
#+resname: R-plot(data=R-plot-example-data)
|
2009-07-18 19:11:14 -04:00
|
|
|
: nil
|
Enabling LoB to put results in buffer, and slowly moving towards more
unified concept of function calls.
Previously LoB calls were not able to produce results in the
buffer. These changes go some way to allowing them to do that. [There
are still some bugs to deal with]. That meant changing org-babel.el so
that there is a notion of the `source block name' for a LoB line, in
order to construct a #+resname (currently I've made the name the same
as the function call).
I'm also slowly moving towards unifying the notion of `function calls'
a bit more: I've changed the org-babel-lob-one-liner-regexp so that
instead of a monolithic match it now matches first the function name,
and second the function arguments in
parentheses. org-babel-lob-get-info makes that match, and although it
still concatenates them and returns the string, the two elements can
be accessed immediately afterwards using match-string. So that
situation is very similar to org-babel-get-src-block-name, whose
job (in this branch) is also to parse the function *name* and the
function *arguments*. In a few places in the code (esp. function
names), I think the word `info' should be replaced with `call' or
`function call', which I believe more accurately indicates what the
`info' is: a function definition, together with bound
arguments/references.
The function call syntax, i.e. function-name(arg1=ref1), originally
introduced for references (and thereby in LoB), and which I'm
proposing we use throughout, raises the question of default arguments,
and those being over-ridden by supplied arguments, as in e.g. python,
and R.
2009-07-10 22:59:10 -04:00
|
|
|
|
2009-08-05 10:02:25 -04:00
|
|
|
** Gnuplot
|
|
|
|
|
|
2009-08-18 16:07:19 -04:00
|
|
|
* Table/Matrix manipulation
|
|
|
|
|
|
|
|
|
|
Elegant lisp code for transposing a matrix.
|
|
|
|
|
|
|
|
|
|
#+tblname: transpose-example
|
|
|
|
|
| 1 | 2 | 3 |
|
|
|
|
|
| 4 | 5 | 6 |
|
|
|
|
|
|
|
|
|
|
#+srcname: transpose
|
|
|
|
|
#+begin_src emacs-lisp :var table=transpose-example
|
|
|
|
|
(apply #'mapcar* #'list table)
|
|
|
|
|
#+end_src
|
|
|
|
|
|
|
|
|
|
#+resname:
|
|
|
|
|
| 1 | 4 |
|
|
|
|
|
| 2 | 5 |
|
|
|
|
|
| 3 | 6 |
|
|
|
|
|
|
2009-08-05 10:02:25 -04:00
|
|
|
* Misc
|
2009-07-11 23:59:51 -04:00
|
|
|
#+srcname: python-identity(a=1)
|
Enabling LoB to put results in buffer, and slowly moving towards more
unified concept of function calls.
Previously LoB calls were not able to produce results in the
buffer. These changes go some way to allowing them to do that. [There
are still some bugs to deal with]. That meant changing org-babel.el so
that there is a notion of the `source block name' for a LoB line, in
order to construct a #+resname (currently I've made the name the same
as the function call).
I'm also slowly moving towards unifying the notion of `function calls'
a bit more: I've changed the org-babel-lob-one-liner-regexp so that
instead of a monolithic match it now matches first the function name,
and second the function arguments in
parentheses. org-babel-lob-get-info makes that match, and although it
still concatenates them and returns the string, the two elements can
be accessed immediately afterwards using match-string. So that
situation is very similar to org-babel-get-src-block-name, whose
job (in this branch) is also to parse the function *name* and the
function *arguments*. In a few places in the code (esp. function
names), I think the word `info' should be replaced with `call' or
`function call', which I believe more accurately indicates what the
`info' is: a function definition, together with bound
arguments/references.
The function call syntax, i.e. function-name(arg1=ref1), originally
introduced for references (and thereby in LoB), and which I'm
proposing we use throughout, raises the question of default arguments,
and those being over-ridden by supplied arguments, as in e.g. python,
and R.
2009-07-10 22:59:10 -04:00
|
|
|
#+begin_src python
|
|
|
|
|
a
|
|
|
|
|
#+end_src
|
2009-07-11 23:59:51 -04:00
|
|
|
|
|
|
|
|
#+srcname: python-add(a=1, b=2)
|
|
|
|
|
#+begin_src python
|
|
|
|
|
a + b
|
|
|
|
|
#+end_src
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
