@@ -149,7 +149,13 @@ place and initialized properly. Now the fun begins.
** :results value
The collection class of the =:results= header argument supports two mutually exclusive options: =value= and =output=. When =:results value= is specified, Org takes the body of the source block, creates a function with that body, evaluates the function with =julia=, stores the result in a =.csv= file, then converts the =.csv= file to an =emacs-lisp= table, and finally inserts the table in the buffer. /Whew!/ The bottom line? Hit =C-c C-c= in the following code block.
The collection class of the =:results= header argument supports two
mutually exclusive options: =value= and =output=. When =:results
value= is specified, Org takes the body of the source block, creates a
function with that body, evaluates the function with =julia=, stores
the result in a =.csv= file, then converts the =.csv= file to an
=emacs-lisp= table, and finally inserts the table in the buffer.
/Whew!/ The bottom line? Hit =C-c C-c= in the following code block.
As expected, the output of the command was a =2x3= array and Org inserted a table into the buffer. This functionality is relatively powerful with other languages such as R, for instance, because =ob-R.el= works with =TAB= separated files instead and =read.table= in R supports reading of much more varied data types compared to =readcsv= in =julia= (at the present time). Nevertheless, the functionality exists in =julia= and as time passes and =julia= adds more options we'll add more, too.
As expected, the output of the command was a =2x3= array and Org
inserted a table into the buffer. This functionality is relatively
powerful with other languages such as R, for instance, because
=ob-R.el= works with =TAB= separated files instead and =read.table= in
R supports reading of much more varied data types compared to
=readcsv= in =julia= (at the present time). Nevertheless, the
functionality exists in =julia= and as time passes and =julia= adds
more options we'll add more, too.
** :results output
We will get a lot more mileage out of the =:results output= option. Every command in the src block body is evaluated by =julia= in turn and the results are placed in the buffer to be typeset in a verbatim environment. This option is similar to typing commands in =julia= at an interactive session. The analogy isn't exact, though, because at an interactive session it is one (1) command in, one (1) result out. Multiple lines in an org SRC block in contrast have RESULTS which are lumped together. Like this: (do =C-c C-c=)
We will get a lot more mileage out of the =:results output=
option. Every command in the src block body is evaluated by =julia= in
turn and the results are placed in the buffer to be typeset in a
verbatim environment. This option is similar to typing commands in
=julia= at an interactive session. The analogy isn't exact, though,
because at an interactive session it is one (1) command in, one (1)
result out. Multiple lines in an org SRC block in contrast have
RESULTS which are lumped together. Like this: (do =C-c C-c=)
#+BEGIN_SRC julia
2 + 3
...
...
@@ -176,7 +196,10 @@ sqrt(5)
: hello
: 2.23606797749979
It is sometimes helpful to split up SRC blocks into smaller chunks so that buildup of RESULTS does not get out of hand. Also, specific to =julia= we can sometimes put a semicolon at the end of the command to suppress output, like this:
It is sometimes helpful to split up SRC blocks into smaller chunks so
that buildup of RESULTS does not get out of hand. Also, specific to
=julia= we can sometimes put a semicolon at the end of the command to
suppress output, like this:
#+BEGIN_SRC julia
2 + 3;
...
...
@@ -420,4 +443,3 @@ Org manual, and see Worg too for more information.
- =ob-julia.el= does not support =rownames= and =colnames= like
