org-babel: Meta-LaTeX-Python-Environment

org-babel: Meta-LaTeX-Python-Environment

[Torsten Wagner]

Hi,

I started working on an little latex-package to allow the execution of python 
code in LaTeX a while ago. It stopped at some point and now it is on my 
pending project lists for a while already.

When I read about org-babel I saw a lot of similarities. I like to start again 
on the basis of org-babel and trying to accomplish the following idea.

Within a LaTeX-file (org-file) I like to use python snippets to perform calculus 
and other tasks which are otherwise extremely difficult or time consuming to 
perform directly in LaTeX. E.g. on-the-fly-generation of graphs or calculus of 
statistical values (e.g., (very simple) the mean value of n numbers). 

I guess org-mode together with org-babel can do most of this already. I played 
around with it and it is very nice, many thanks to the developers. However, I 
found the following point which I wasn't able to figure out yet.

1. Hiding of the source code blocks for export
I like to export the results of the source code block to LaTeX only. However, 
I tried different options all resulting in embedding the source-code itself 
inside the final LaTeX file. I guess this is more due to the org-export function 
rather then org-babel

2. Inline source code blocks
I guess this was discussed once already. Instead of a verbose source code 
block a single short command to elaborate a python variable or a one line 
calculus would be nice e.g., "#:session_name a#" to replace this command by 
the results of variable a of the session session_name during the export to 
LaTeX.

I like to combine this with a little python module specialised in creating 
proper LaTeX export for all kind of python data types.
E.g.  tab_export([1,2,3,4,5]) could generate the string "1 & 2 & 3 & 4 & 5 \\"

The idea is to use this as a form of reproducible research allowing the data 
evaluation together with the textual and graphical representation. 
Furthermore, I would like to use org as a publication system with meta-
description capabilities. This would allow to commentary what someone is doing 
"between the lines". By this one could merge somehow the lab-book, data 
analysis and the final paper into one org-file (or org-project) and keep always 
all infos and data close together

Something like (pseudo code):

/---------------------------------------------------------------------------------/

12.03.2148: Scotty
I'm going to create a better warp drive system: 
...
First measurements should show the better efficiency. The old set-up is moved to 
the lab downstairs .... the old measurement files back-up is at ....
First lets load the values and calculate the performance:

#+srcname: measurement 
#+begin_src python 
data=load(measurement.csv)
perf = calculate_performance(data.values)
#+end_src

This was the final measurement performed with the new set-up. It shows already 
the nice improvements... 
Just some infos of the measurement
Measurement date: #:measurement data.date#
Measurement parameter: #:measurement data.param1#

13.3.2148: Scotty
Spoke told me it could be better by performing a new warp-core calibration... 
However, I could write the abstract already:

#+srcname: paper_for_star_fleet_physics_journal
#+begin_src LaTeX 
\begin{abstract}
.... the new set-up shows a $#:measurement perf#,/%$ better perfomance then 
the old warp drive...
\end{abstract}
#+end_src

13.04.2148: Scotty
Finally I applied the calibration as Spoke said but results are not better. 
Results can be found here _link_ but will not be published yet... lost one 
month... will kick some Vulcans ass ...
Let's continuous with the graphs I need for figure 4...
...
...
...

/--------------------------------------------------------------------------------------------/

I hope this gives an idea of what I like to do. :)

Export should allow selections like "export all" (including comment texts and 
source code blocks), "export without source code blocks" and "export results 
only". The last one would produce the native LaTeX code ready for submission. 
This would allow to process the file with any standard LaTeX environment.

I know there is the tangle function. However, it would require a LaTeX-source 
block for org-babel. Creating one would result in the problem that I have to 
replace spaceholders within the LaTeX-code blocks  with the results of python-
blocks (as shown in the example). 

It would be nice to hear if someone is doing something similar or if somebody 
has some ideas how to accomplish this with org-mode and org-babel

Best regards,

Torsten


CC. Sorry for the long mail

 

Re: org-babel: Meta-LaTeX-Python-Environment

[Dan Davison]

Torsten Wagner <torsten.wagner@gmail.com> writes:

<...>

> Within a LaTeX-file (org-file) I like to use python snippets to perform calculus 
> and other tasks which are otherwise extremely difficult or time consuming to 
> perform directly in LaTeX. E.g. on-the-fly-generation of graphs or calculus of 
> statistical values (e.g., (very simple) the mean value of n numbers). 
>
> I guess org-mode together with org-babel can do most of this already. I played 
> around with it and it is very nice, many thanks to the developers. However, I 
> found the following point which I wasn't able to figure out yet.

Hi Torsten,

>
> 1. Hiding of the source code blocks for export
> I like to export the results of the source code block to LaTeX only. However, 

Using ':exports results' specifies that only the results should appear
in the exported document. This

#+begin_src python :exports results
  6 + 6
#+end_src

is exported to latex as this:

\begin{verbatim}
 12
\end{verbatim}

Is that working for you?

> I tried different options all resulting in embedding the source-code itself 
> inside the final LaTeX file. I guess this is more due to the org-export function 
> rather then org-babel
>
> 2. Inline source code blocks
> I guess this was discussed once already. Instead of a verbose source code 
> block a single short command to elaborate a python variable or a one line 
> calculus would be nice e.g., "#:session_name a#" to replace this command by 
> the results of variable a of the session session_name during the export to 
> LaTeX.

Yes, you can do that (and it is now doumented on worg). The syntax for
that is src_lang[optional header args]{code}

See below for examples.

>
> I like to combine this with a little python module specialised in creating 
> proper LaTeX export for all kind of python data types.
> E.g.  tab_export([1,2,3,4,5]) could generate the string "1 & 2 & 3 & 4 & 5 \\"
>
> The idea is to use this as a form of reproducible research allowing the data 
> evaluation together with the textual and graphical representation. 
> Furthermore, I would like to use org as a publication system with meta-
> description capabilities. This would allow to commentary what someone is doing 
> "between the lines". By this one could merge somehow the lab-book, data 
> analysis and the final paper into one org-file (or org-project) and keep always 
> all infos and data close together
>
> Something like (pseudo code):

>
> /---------------------------------------------------------------------------------/
>
> 12.03.2148: Scotty
> I'm going to create a better warp drive system: 
> ...
> First measurements should show the better efficiency. The old set-up is moved to 
> the lab downstairs .... the old measurement files back-up is at ....
> First lets load the values and calculate the performance:
>
> #+srcname: measurement 
> #+begin_src python 
> data=load(measurement.csv)
> perf = calculate_performance(data.values)
> #+end_src
>
> This was the final measurement performed with the new set-up. It shows already 
> the nice improvements... 
> Just some infos of the measurement
> Measurement date: #:measurement data.date#
> Measurement parameter: #:measurement data.param1#

You can use inline blocks as follows. Note that the source block needs
to be evaluated to ensure that the variables exist in the session (hence
the :exports results header)

--8<---------------cut here---------------start------------->8---
#+srcname: measurement 
#+begin_src python :session :exports results
  date = "12.03.2148"
  param1 = 19.7
  perf = 77
#+end_src

Measurement date: src_python[:session]{date}
Measurement parameter: src_python[:session]{param1}
--8<---------------cut here---------------end--------------->8---

>
> 13.3.2148: Scotty
> Spoke told me it could be better by performing a new warp-core calibration... 
> However, I could write the abstract already:
>
> #+srcname: paper_for_star_fleet_physics_journal
> #+begin_src LaTeX 
> \begin{abstract}
> .... the new set-up shows a $#:measurement perf#,/%$ better perfomance then 
> the old warp drive...
> \end{abstract}
> #+end_src

The inline code blocks will not be processed inside source blocks. I'm
not sure how to achieve what you want with the current machinery, but
have you read the recent posts by Thomas Dye describing how he uses
latex blocks with org-babel?  In particular you should look at the noweb
reference expansions. These are also documented on the Worg page. In
general of course, the more you can write in org rather than latex, the
more functionality you'll get out of org-babel. Is it possible write the
abstract in org and defer export to latex?

<...>
> I hope this gives an idea of what I like to do. :)
>
> Export should allow selections like "export all" (including comment texts and 
> source code blocks), "export without source code blocks" and "export results 
> only". The last one would produce the native LaTeX code ready for submission. 
> This would allow to process the file with any standard LaTeX environment.

The Worg page says

,----
| exports
|     exports arguments specify what should be included in html or latex exports of the org-mode file
| 
|     code
|         the body of code is included into the exported file 
|     results
|         the results of evaluating the code is included in the exported file 
|     both
|         both the code and results are included in the exported file 
|     none
|         nothing is included in the exported file 
| 
`----

could you clarify how you would like it to be different?

>
> I know there is the tangle function. However, it would require a LaTeX-source 
> block for org-babel. Creating one would result in the problem that I have to 
> replace spaceholders within the LaTeX-code blocks  with the results of python-
> blocks (as shown in the example). 
>
> It would be nice to hear if someone is doing something similar or if somebody 
> has some ideas how to accomplish this with org-mode and org-babel

Hope I've helped a bit. Have another look at our Worg page and let us
know if it can be improved, and also check out the threads involving
Eric Thomas Dye[1]. And let us know how your approach evolves.

Thanks,
Dan

Footnotes:

[1] http://search.gmane.org/search.php?group=gmane.emacs.orgmode&query=Thomas+Dye


>
> Best regards,
>
> Torsten
>
>
> CC. Sorry for the long mail
>
>  
>
>
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: org-babel: Meta-LaTeX-Python-Environment

[Thomas S. Dye]

[-- Attachment #1.1: Type: text/plain, Size: 1234 bytes --]


On Oct 26, 2009, at 2:24 PM, Dan Davison wrote:

> Torsten Wagner <torsten.wagner@gmail.com> writes:
>
> <...>
>
< ... >
>
> The inline code blocks will not be processed inside source blocks. I'm
> not sure how to achieve what you want with the current machinery, but
> have you read the recent posts by Thomas Dye describing how he uses
> latex blocks with org-babel?  In particular you should look at the  
> noweb
> reference expansions. These are also documented on the Worg page. In
> general of course, the more you can write in org rather than latex,  
> the
> more functionality you'll get out of org-babel. Is it possible write  
> the
> abstract in org and defer export to latex?
>
> <...>


Hi Torsten,

Perhaps this will do what you want?  When I run org-babel-tangle on  
the following org file, and then LaTeX the output, the resulting pdf  
file says: A bit of LATEX code, with the result: 6

* Test org
#+begin_src python
   x = 6
   f = open('python_results.tex', 'w')
   f.write(str(x))
   f.close()
#+end_src

#+resname:
: None

#+begin_src latex :tangle test_arg_passing
\documentclass{article}
\begin{document}
   A bit of \LaTeX code, with the result: \input{python_results}
\end{document}
#+end_src

HTH,
Tom


[-- Attachment #1.2: Type: text/html, Size: 1997 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: org-babel: Meta-LaTeX-Python-Environment

[Torsten Wagner]

[-- Attachment #1.1: Type: text/plain, Size: 924 bytes --]

>
>
> Perhaps this will do what you want?  When I run org-babel-tangle on the
> following org file, and then LaTeX the output, the resulting pdf file
> says: A bit of LATEX code, with the result: 6
>
> * Test org
> #+begin_src python
>   x = 6
>   f = open('python_results.tex', 'w')
>   f.write(str(x))
>   f.close()
> #+end_src
>
> #+resname:
> : None
>
> #+begin_src latex :tangle test_arg_passing
> \documentclass{article}
> \begin{document}
>   A bit of \LaTeX code, with the result: \input{python_results}
> \end{document}
> #+end_src
>
> HTH,
> Tom
>
> Hi Tom
Thanks for sharing this idea. Actually my first (org-babel free) attempt was
working like that. However, it becomes fast difficult and complex. On the
other hand it solves nicely the problem with the code evaluation in another
source block. I just wonder if there is a more comfortable method rather
then creating a file.

Thanks again for sharing

Torsten

[-- Attachment #1.2: Type: text/html, Size: 1830 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: org-babel: Meta-LaTeX-Python-Environment

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

Torsten Wagner <torsten.wagner@gmail.com> writes:

>     Perhaps this will do what you want?  When I run org-babel-tangle on the following org file, and then
>     LaTeX the output, the resulting pdf file says: A bit of LATEX code, with the result: 6

> I just wonder if there is a more comfortable method rather then
> creating a file.

Although I still don't fully understand the need to embed latex *inside*
of source-code blocks, perhaps the attached org-babel-latex.el file [1]
will represent a simpler solution for embedding the results of
source-code blocks in latex source-code blocks.  It makes use of
the :var org-babel header argument as shown in the attached example file
[2].  To reproduce first load org-babel-latex.el and then evaluate the
latex block (note the results are already in the file from my test
evaluation).

Hope this helps -- Eric

Footnotes: 
[1]  

[-- Attachment #2: org-babel-latex.el --]
[-- Type: application/emacs-lisp, Size: 2179 bytes --]

[-- Attachment #3: Type: text/plain, Size: 6 bytes --]


[2]  

[-- Attachment #4: latex.org --]
[-- Type: application/octet-stream, Size: 466 bytes --]

#+TITLE: weird latex export
#+OPTIONS: num:nil ^:nil
#+LaTeX_CLASS: normal

* Test org
#+srcname: simple_six
#+begin_src python :results silent
  6
#+end_src

#+begin_src latex :var python_result=simple_six
\documentclass{article}
\begin{document}
  A bit of \LaTeX code, with the result: python_result
\end{document}
#+end_src

#+resname:
#+BEGIN_LaTeX
\documentclass{article}
\begin{document}
  A bit of \LaTeX code, with the result: 6
\end{document}
#+END_LaTeX


[-- Attachment #5: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: org-babel: Meta-LaTeX-Python-Environment

[Thomas S. Dye]

On Oct 27, 2009, at 12:55 PM, Eric Schulte wrote:

> Torsten Wagner <torsten.wagner@gmail.com> writes:
>
>>    Perhaps this will do what you want?  When I run org-babel-tangle  
>> on the following org file, and then
>>    LaTeX the output, the resulting pdf file says: A bit of LATEX  
>> code, with the result: 6
>
>> I just wonder if there is a more comfortable method rather then
>> creating a file.
>
> Although I still don't fully understand the need to embed latex  
> *inside*
> of source-code blocks, perhaps the attached org-babel-latex.el file  
> [1]
> will represent a simpler solution for embedding the results of
> source-code blocks in latex source-code blocks.  It makes use of
> the :var org-babel header argument as shown in the attached example  
> file
> [2].  To reproduce first load org-babel-latex.el and then evaluate the
> latex block (note the results are already in the file from my test
> evaluation).
>
> Hope this helps -- Eric
>
> Footnotes:
> [1]  <org-babel-latex.el>
> [2]  <latex.org>

Thanks for this, Eric.  It looks neat.  I was happy with all the  
little .tex files, but agree with Torsten that this path is  
potentially cleaner.

In response to the implicit question in your comment, perhaps there  
isn't a need to embed LaTeX inside source blocks and the uses to which  
I put them could be accomplished in org-mode without them.  My  
programming skills are pretty crude and I'm aware that I'm a long way  
from understanding org-mode and its vast potential.  With that caveat,  
here is my $0.02.

First, practical reasons:

1) I'm comfortable writing LaTeX and am particular about the results;  
it is hard for me to map the inverse transformation through the org- 
mode LaTeX exporter to express in org the particular LaTeX result I'm  
after.

2) Someone on the list (Carsten?) mentioned a couple of days ago that  
it wasn't reasonable to expect the org LaTeX exporter to capture the  
full complexity of LaTeX (I'm paraphrasing, but I think that was the  
gist); I ran up against an example of this (or so I think) when trying  
to configure export to beamer code, where beamer's use of columns  
tripped me up.

Second, conceptual reasons:

1) I consider writing LaTeX to be programming (here I mean no  
disrespect to real programmers) and appreciate being able to do  
literate LaTeX programming; the LaTeX source blocks let me write my  
beamer presentation a slide or two at a time, just as I want them,  
along with an adjacent source block for my print document, just as i  
want it, that covers the same conceptual space, while I use the  
surrounding org entries to document why I am doing things a particular  
way, etc.

2) I think this workflow, with an org-mode meta-document that  
encapsulates the print document and presentation materials, along with  
the SQL, R, and Python code used to create the datasets and analyze  
them, takes org-babel a step closer to realizing its potential as a  
tool for reproducible research.  Here, I am thinking of an org  
document that captures the ways in which a piece of research is one  
logical path among many possibilities, implemented and expressed in  
one particular way (or two, if you want to distinguish print from  
presentation) among many possibilities.

The LaTeX source blocks in org-babel give me an easy and natural way  
to accomplish these things.  In the short time I've used them, they've  
yielded results that impress me.  I'm confident they hold much more  
potential than I've been able to tap.

It is a real pleasure leveraging your good work.

Tom

Re: org-babel: Meta-LaTeX-Python-Environment

[Eric Schulte]

"Thomas S. Dye" <tsd@tsdye.com> writes:

> On Oct 27, 2009, at 12:55 PM, Eric Schulte wrote:

>> Although I still don't fully understand the need to embed latex
>> *inside*
>> of source-code blocks, perhaps the attached org-babel-latex.el file
>> [1]
>> will represent a simpler solution for embedding the results of
>> source-code blocks in latex source-code blocks.  It makes use of
>> the :var org-babel header argument as shown in the attached example
>> file
>> [2].  To reproduce first load org-babel-latex.el and then evaluate the
>> latex block (note the results are already in the file from my test
>> evaluation).
>>
>> Hope this helps -- Eric
>>
>> Footnotes:
>> [1]  <org-babel-latex.el>
>> [2]  <latex.org>
>
> Thanks for this, Eric.  It looks neat.  I was happy with all the
> little .tex files, but agree with Torsten that this path is
> potentially cleaner.
>

Please let me know if you do find this useful or have any suggestions.
If it proves useful I will add it to the org-mode repository.

>
> In response to the implicit question in your comment, perhaps there
> isn't a need to embed LaTeX inside source blocks and the uses to which
> I put them could be accomplished in org-mode without them.  My
> programming skills are pretty crude and I'm aware that I'm a long way
> from understanding org-mode and its vast potential.  With that caveat,
> here is my $0.02.
>

I'm also very far from taking full advantage of Org-mode export

>
> First, practical reasons:
>
> 1) I'm comfortable writing LaTeX and am particular about the results;
> it is hard for me to map the inverse transformation through the org- 
> mode LaTeX exporter to express in org the particular LaTeX result I'm
> after.
>
> 2) Someone on the list (Carsten?) mentioned a couple of days ago that
> it wasn't reasonable to expect the org LaTeX exporter to capture the
> full complexity of LaTeX (I'm paraphrasing, but I think that was the
> gist); I ran up against an example of this (or so I think) when trying
> to configure export to beamer code, where beamer's use of columns
> tripped me up.
>

I fully understand your point.  I guess that given my personal paucity
of latex knowledge and abilities the same need has never occurred to
me.  In my case the Org-mode exported generally knows more about latex
than I do.

>
> Second, conceptual reasons:
>
> 1) I consider writing LaTeX to be programming (here I mean no
> disrespect to real programmers) and appreciate being able to do
> literate LaTeX programming; the LaTeX source blocks let me write my
> beamer presentation a slide or two at a time, just as I want them,
> along with an adjacent source block for my print document, just as i
> want it, that covers the same conceptual space, while I use the
> surrounding org entries to document why I am doing things a particular
> way, etc.
>

I see, you are using the org-mode file "a level above" the direct
export.  Maybe another option here would be to tag headlines based on
which export target they are included within, and then base your exports
on the headline tags (using #+EXPORT_INCLUDE_TAGS:), although I agree
this also seems like an appropriate place to use the tangle
functionality.

>
> 2) I think this workflow, with an org-mode meta-document that
> encapsulates the print document and presentation materials, along with
> the SQL, R, and Python code used to create the datasets and analyze
> them, takes org-babel a step closer to realizing its potential as a
> tool for reproducible research.  Here, I am thinking of an org
> document that captures the ways in which a piece of research is one
> logical path among many possibilities, implemented and expressed in
> one particular way (or two, if you want to distinguish print from
> presentation) among many possibilities.
>
> The LaTeX source blocks in org-babel give me an easy and natural way
> to accomplish these things.  In the short time I've used them, they've
> yielded results that impress me.  I'm confident they hold much more
> potential than I've been able to tap.
>

I didn't mean to imply that because I didn't understand the need for
direct inclusion of latex code there *wasn't* a need for direct
inclusion of latex code :) Thanks for the explanation.

>
> It is a real pleasure leveraging your good work.
>

It is a pleasure to be able to participate in such a nice open-source
community. -- Eric

>
> Tom

[babel] Re: org-babel: Meta-LaTeX-Python-Environment

[Dan Davison]

Dear thread participants, please note that we were breaking the rule of
prepending the subject line with the string [babel]!

One question inline below.

"Eric Schulte" <schulte.eric@gmail.com> writes:

> "Thomas S. Dye" <tsd@tsdye.com> writes:
>
>> On Oct 27, 2009, at 12:55 PM, Eric Schulte wrote:
>
>>> Although I still don't fully understand the need to embed latex
>>> *inside*
>>> of source-code blocks, perhaps the attached org-babel-latex.el file
>>> [1]
>>> will represent a simpler solution for embedding the results of
>>> source-code blocks in latex source-code blocks.  It makes use of
>>> the :var org-babel header argument as shown in the attached example
>>> file
>>> [2].  To reproduce first load org-babel-latex.el and then evaluate the
>>> latex block (note the results are already in the file from my test
>>> evaluation).
>>>
>>> Hope this helps -- Eric
>>>
>>> Footnotes:
>>> [1]  <org-babel-latex.el>
>>> [2]  <latex.org>
>>
>> Thanks for this, Eric.  It looks neat.  I was happy with all the
>> little .tex files, but agree with Torsten that this path is
>> potentially cleaner.
>>
>
> Please let me know if you do find this useful or have any suggestions.
> If it proves useful I will add it to the org-mode repository.

Am I right in thinking that one issue remaining in this thread is that
we currently have no means of tangling the output of org-babel-latex?
Thus the 'begin_src latex' blocks that we can tangle have unevaluated
variables, and the resulting 'begin_latex' blocks have evaluated
variables but can't be tangled? (We could extend tangling to cover such
blocks, or perhaps preferably use ':results code' to generate 'begin_src
latex' blocks?)

Dan



>
>>
>> In response to the implicit question in your comment, perhaps there
>> isn't a need to embed LaTeX inside source blocks and the uses to which
>> I put them could be accomplished in org-mode without them.  My
>> programming skills are pretty crude and I'm aware that I'm a long way
>> from understanding org-mode and its vast potential.  With that caveat,
>> here is my $0.02.
>>
>
> I'm also very far from taking full advantage of Org-mode export
>
>>
>> First, practical reasons:
>>
>> 1) I'm comfortable writing LaTeX and am particular about the results;
>> it is hard for me to map the inverse transformation through the org- 
>> mode LaTeX exporter to express in org the particular LaTeX result I'm
>> after.
>>
>> 2) Someone on the list (Carsten?) mentioned a couple of days ago that
>> it wasn't reasonable to expect the org LaTeX exporter to capture the
>> full complexity of LaTeX (I'm paraphrasing, but I think that was the
>> gist); I ran up against an example of this (or so I think) when trying
>> to configure export to beamer code, where beamer's use of columns
>> tripped me up.
>>
>
> I fully understand your point.  I guess that given my personal paucity
> of latex knowledge and abilities the same need has never occurred to
> me.  In my case the Org-mode exported generally knows more about latex
> than I do.
>
>>
>> Second, conceptual reasons:
>>
>> 1) I consider writing LaTeX to be programming (here I mean no
>> disrespect to real programmers) and appreciate being able to do
>> literate LaTeX programming; the LaTeX source blocks let me write my
>> beamer presentation a slide or two at a time, just as I want them,
>> along with an adjacent source block for my print document, just as i
>> want it, that covers the same conceptual space, while I use the
>> surrounding org entries to document why I am doing things a particular
>> way, etc.
>>
>
> I see, you are using the org-mode file "a level above" the direct
> export.  Maybe another option here would be to tag headlines based on
> which export target they are included within, and then base your exports
> on the headline tags (using #+EXPORT_INCLUDE_TAGS:), although I agree
> this also seems like an appropriate place to use the tangle
> functionality.
>
>>
>> 2) I think this workflow, with an org-mode meta-document that
>> encapsulates the print document and presentation materials, along with
>> the SQL, R, and Python code used to create the datasets and analyze
>> them, takes org-babel a step closer to realizing its potential as a
>> tool for reproducible research.  Here, I am thinking of an org
>> document that captures the ways in which a piece of research is one
>> logical path among many possibilities, implemented and expressed in
>> one particular way (or two, if you want to distinguish print from
>> presentation) among many possibilities.
>>
>> The LaTeX source blocks in org-babel give me an easy and natural way
>> to accomplish these things.  In the short time I've used them, they've
>> yielded results that impress me.  I'm confident they hold much more
>> potential than I've been able to tap.
>>
>
> I didn't mean to imply that because I didn't understand the need for
> direct inclusion of latex code there *wasn't* a need for direct
> inclusion of latex code :) Thanks for the explanation.
>
>>
>> It is a real pleasure leveraging your good work.
>>
>
> It is a pleasure to be able to participate in such a nice open-source
> community. -- Eric
>
>>
>> Tom
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [babel] Re: org-babel: Meta-LaTeX-Python-Environment

[Dan Davison]

Dan Davison <davison@stats.ox.ac.uk> writes:

> Am I right in thinking that one issue remaining in this thread is that
> we currently have no means of tangling the output of org-babel-latex?
> Thus the 'begin_src latex' blocks that we can tangle have unevaluated
> variables, and the resulting 'begin_latex' blocks have evaluated
> variables but can't be tangled? (We could extend tangling to cover such
> blocks, or perhaps preferably use ':results code' to generate 'begin_src
> latex' blocks?)

Sorry, I see. 'begin_latex' is inserted directly into latex export and
omitted from other export targets. Still, it might sometimes be useful
to use the tangling machinery in which case ':results code' is what is
needed.

Dan

>
> Dan
>
>
>
>>
>>>
>>> In response to the implicit question in your comment, perhaps there
>>> isn't a need to embed LaTeX inside source blocks and the uses to which
>>> I put them could be accomplished in org-mode without them.  My
>>> programming skills are pretty crude and I'm aware that I'm a long way
>>> from understanding org-mode and its vast potential.  With that caveat,
>>> here is my $0.02.
>>>
>>
>> I'm also very far from taking full advantage of Org-mode export
>>
>>>
>>> First, practical reasons:
>>>
>>> 1) I'm comfortable writing LaTeX and am particular about the results;
>>> it is hard for me to map the inverse transformation through the org- 
>>> mode LaTeX exporter to express in org the particular LaTeX result I'm
>>> after.
>>>
>>> 2) Someone on the list (Carsten?) mentioned a couple of days ago that
>>> it wasn't reasonable to expect the org LaTeX exporter to capture the
>>> full complexity of LaTeX (I'm paraphrasing, but I think that was the
>>> gist); I ran up against an example of this (or so I think) when trying
>>> to configure export to beamer code, where beamer's use of columns
>>> tripped me up.
>>>
>>
>> I fully understand your point.  I guess that given my personal paucity
>> of latex knowledge and abilities the same need has never occurred to
>> me.  In my case the Org-mode exported generally knows more about latex
>> than I do.
>>
>>>
>>> Second, conceptual reasons:
>>>
>>> 1) I consider writing LaTeX to be programming (here I mean no
>>> disrespect to real programmers) and appreciate being able to do
>>> literate LaTeX programming; the LaTeX source blocks let me write my
>>> beamer presentation a slide or two at a time, just as I want them,
>>> along with an adjacent source block for my print document, just as i
>>> want it, that covers the same conceptual space, while I use the
>>> surrounding org entries to document why I am doing things a particular
>>> way, etc.
>>>
>>
>> I see, you are using the org-mode file "a level above" the direct
>> export.  Maybe another option here would be to tag headlines based on
>> which export target they are included within, and then base your exports
>> on the headline tags (using #+EXPORT_INCLUDE_TAGS:), although I agree
>> this also seems like an appropriate place to use the tangle
>> functionality.
>>
>>>
>>> 2) I think this workflow, with an org-mode meta-document that
>>> encapsulates the print document and presentation materials, along with
>>> the SQL, R, and Python code used to create the datasets and analyze
>>> them, takes org-babel a step closer to realizing its potential as a
>>> tool for reproducible research.  Here, I am thinking of an org
>>> document that captures the ways in which a piece of research is one
>>> logical path among many possibilities, implemented and expressed in
>>> one particular way (or two, if you want to distinguish print from
>>> presentation) among many possibilities.
>>>
>>> The LaTeX source blocks in org-babel give me an easy and natural way
>>> to accomplish these things.  In the short time I've used them, they've
>>> yielded results that impress me.  I'm confident they hold much more
>>> potential than I've been able to tap.
>>>
>>
>> I didn't mean to imply that because I didn't understand the need for
>> direct inclusion of latex code there *wasn't* a need for direct
>> inclusion of latex code :) Thanks for the explanation.
>>
>>>
>>> It is a real pleasure leveraging your good work.
>>>
>>
>> It is a pleasure to be able to participate in such a nice open-source
>> community. -- Eric
>>
>>>
>>> Tom
>>
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Remember: use `Reply All' to send replies to the list.
>> Emacs-orgmode@gnu.org
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[babel] Re: org-babel: Meta-LaTeX-Python-Environment

[Thomas S. Dye]

On Oct 28, 2009, at 6:10 AM, Dan Davison wrote:

> Dear thread participants, please note that we were breaking the rule  
> of
> prepending the subject line with the string [babel]!
>
> One question inline below.
>
> "Eric Schulte" <schulte.eric@gmail.com> writes:
>
>> "Thomas S. Dye" <tsd@tsdye.com> writes:
>>
>>> On Oct 27, 2009, at 12:55 PM, Eric Schulte wrote:
>>
>>>> Although I still don't fully understand the need to embed latex
>>>> *inside*
>>>> of source-code blocks, perhaps the attached org-babel-latex.el file
>>>> [1]
>>>> will represent a simpler solution for embedding the results of
>>>> source-code blocks in latex source-code blocks.  It makes use of
>>>> the :var org-babel header argument as shown in the attached example
>>>> file
>>>> [2].  To reproduce first load org-babel-latex.el and then  
>>>> evaluate the
>>>> latex block (note the results are already in the file from my test
>>>> evaluation).
>>>>
>>>> Hope this helps -- Eric
>>>>
>>>> Footnotes:
>>>> [1]  <org-babel-latex.el>
>>>> [2]  <latex.org>
>>>
>>> Thanks for this, Eric.  It looks neat.  I was happy with all the
>>> little .tex files, but agree with Torsten that this path is
>>> potentially cleaner.
>>>
>>
>> Please let me know if you do find this useful or have any  
>> suggestions.
>> If it proves useful I will add it to the org-mode repository.
>
> Am I right in thinking that one issue remaining in this thread is that
> we currently have no means of tangling the output of org-babel-latex?
> Thus the 'begin_src latex' blocks that we can tangle have unevaluated
> variables, and the resulting 'begin_latex' blocks have evaluated
> variables but can't be tangled? (We could extend tangling to cover  
> such
> blocks, or perhaps preferably use ':results code' to generate  
> 'begin_src
> latex' blocks?)
>
> Dan

Hi Dan,

I haven't found time to evaluate org-babel-latex, but, yes, the  
example provided with the code raised a concern that the 'begin_latex'  
blocks are divorced from the literate programming structure built up  
by the named 'begin_src latex' blocks.  Ideally, I think, the  
'begin_latex' blocks would replace <<noweb>> references to their  
source 'begin_src latex' blocks, or would employ some other mechanism  
that doesn't break the literate programming structure I create.

Tom

Re: [babel] Re: org-babel: Meta-LaTeX-Python-Environment

[Eric Schulte]

"Thomas S. Dye" <tsd@tsdye.com> writes:

> On Oct 28, 2009, at 6:10 AM, Dan Davison wrote:

>> Am I right in thinking that one issue remaining in this thread is that
>> we currently have no means of tangling the output of org-babel-latex?
>> Thus the 'begin_src latex' blocks that we can tangle have unevaluated
>> variables, and the resulting 'begin_latex' blocks have evaluated
>> variables but can't be tangled? (We could extend tangling to cover
>> such
>> blocks, or perhaps preferably use ':results code' to generate
>> begin_src
>> latex' blocks?)
>>
>> Dan
>
> Hi Dan,
>
> I haven't found time to evaluate org-babel-latex, but, yes, the
> example provided with the code raised a concern that the 'begin_latex'
> blocks are divorced from the literate programming structure built up
> by the named 'begin_src latex' blocks.  Ideally, I think, the
> begin_latex' blocks would replace <<noweb>> references to their
> source 'begin_src latex' blocks, or would employ some other mechanism
> that doesn't break the literate programming structure I create.
>

I just started a new branch [1] in the org-mode/babel [2] repository
where we should be able to implement a solution without too much
trouble.  If we expand the noweb syntax such that if a source-code block
name has parenthesis "()" appended to the end of it's name, then the
block will be evaluated during noweb reference expansion and it's
results will be placed in the source-code block.  That structure should
even allow simple literal arguments to be passed to the referenced
block.

So for example what I'm proposing is that in the following case this

--8<---------------cut here---------------start------------->8---
#+srcname: noweb-example
#+begin_src python :var a=0
  a+10
#+end_src

#+begin_src latex :tangle somewhere
  \begin{itemize}
    \item <<noweb-example>>
    \item <<noweb-example()>>
    \item <<noweb-example(a=8)>>
  \end{itemize}
#+end_src
--8<---------------cut here---------------end--------------->8---

would tangle to somewhere.tex as

--8<---------------cut here---------------start------------->8---
\begin{itemize}
  \item a+10
  \item 10
  \item 18
\end{itemize}
--8<---------------cut here---------------end--------------->8---

Does that sound appropriate? -- Eric

Footnotes: 
[1]  http://repo.or.cz/w/org-mode/babel.git?a=shortlog;h=refs/heads/noweb-evaluate

[2]  http://repo.or.cz/w/org-mode/babel.git

Re: [babel] Re: org-babel: Meta-LaTeX-Python-Environment

[Thomas S. Dye]

On Oct 28, 2009, at 7:15 AM, Eric Schulte wrote:

> "Thomas S. Dye" <tsd@tsdye.com> writes:
>
>> On Oct 28, 2009, at 6:10 AM, Dan Davison wrote:
>
>>> Am I right in thinking that one issue remaining in this thread is  
>>> that
>>> we currently have no means of tangling the output of org-babel- 
>>> latex?
>>> Thus the 'begin_src latex' blocks that we can tangle have  
>>> unevaluated
>>> variables, and the resulting 'begin_latex' blocks have evaluated
>>> variables but can't be tangled? (We could extend tangling to cover
>>> such
>>> blocks, or perhaps preferably use ':results code' to generate
>>> begin_src
>>> latex' blocks?)
>>>
>>> Dan
>>
>> Hi Dan,
>>
>> I haven't found time to evaluate org-babel-latex, but, yes, the
>> example provided with the code raised a concern that the  
>> 'begin_latex'
>> blocks are divorced from the literate programming structure built up
>> by the named 'begin_src latex' blocks.  Ideally, I think, the
>> begin_latex' blocks would replace <<noweb>> references to their
>> source 'begin_src latex' blocks, or would employ some other mechanism
>> that doesn't break the literate programming structure I create.
>>
>
> I just started a new branch [1] in the org-mode/babel [2] repository
> where we should be able to implement a solution without too much
> trouble.  If we expand the noweb syntax such that if a source-code  
> block
> name has parenthesis "()" appended to the end of it's name, then the
> block will be evaluated during noweb reference expansion and it's
> results will be placed in the source-code block.  That structure  
> should
> even allow simple literal arguments to be passed to the referenced
> block.
>
> So for example what I'm proposing is that in the following case this
>
> --8<---------------cut here---------------start------------->8---
> #+srcname: noweb-example
> #+begin_src python :var a=0
>  a+10
> #+end_src
>
> #+begin_src latex :tangle somewhere
>  \begin{itemize}
>    \item <<noweb-example>>
>    \item <<noweb-example()>>
>    \item <<noweb-example(a=8)>>
>  \end{itemize}
> #+end_src
> --8<---------------cut here---------------end--------------->8---
>
> would tangle to somewhere.tex as
>
> --8<---------------cut here---------------start------------->8---
> \begin{itemize}
>  \item a+10
>  \item 10
>  \item 18
> \end{itemize}
> --8<---------------cut here---------------end--------------->8---
>
> Does that sound appropriate? -- Eric
>
> Footnotes:
> [1]  http://repo.or.cz/w/org-mode/babel.git?a=shortlog;h=refs/heads/noweb-evaluate
>
> [2]  http://repo.or.cz/w/org-mode/babel.git
>
Eric,

I think Torsten has a clearer idea than I do about what kinds of  
programming structures might be appropriate here, but your suggestion  
looks to me like an elegant replacement for the file based technique  
I'm using to pass information into 'begin_src latex' blocks now.   
Expanding the noweb syntax in the way you propose looks extremely  
useful.  I think it introduces an exciting range of possibilities into  
the workflow I'm developing with org-babel.  So, yes, your proposal  
sounds appropriate to me.

Tom

Re: [babel] Re: org-babel: Meta-LaTeX-Python-Environment

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

"Thomas S. Dye" <tsd@tsdye.com> writes:

[...]

> Eric,
>
> I think Torsten has a clearer idea than I do about what kinds of
> programming structures might be appropriate here, but your suggestion
> looks to me like an elegant replacement for the file based technique
> I'm using to pass information into 'begin_src latex' blocks now.
> Expanding the noweb syntax in the way you propose looks extremely
> useful.  I think it introduces an exciting range of possibilities into
> the workflow I'm developing with org-babel.  So, yes, your proposal
> sounds appropriate to me.
>
> Tom

This has now been implemented.  To try it out grab the most recent
version of Org-mode.  Changes include
- the ability to insert the *results* of source-code blocks through the
  use of noweb references in which the source-name is followed by ()s,
  and
- the addition of the org-babel-latex.el file which should make it
  easier to add latex to the languages known to org-babel

To try this out please run org-babel-tangle on the attached org-mode
file.


[-- Attachment #2: noweb-eval.org --]
[-- Type: application/octet-stream, Size: 339 bytes --]

#+TITLE: Noweb Evaluation Test
#+OPTIONS: num:nil ^:nil
#+LaTeX_CLASS: normal

* top

more here

#+srcname: noweb-example
#+begin_src python :var a=0
  a+10
#+end_src

#+begin_src latex :tangle somewhere
  \begin{itemize}
    \item <<noweb-example>>
    \item <<noweb-example()>>
    \item <<noweb-example(a=8)>>
  \end{itemize}
#+end_src

[-- Attachment #3: Type: text/plain, Size: 48 bytes --]


which should result in the attached .tex file


[-- Attachment #4: somewhere.tex --]
[-- Type: application/x-tex, Size: 171 bytes --]

[-- Attachment #5: Type: text/plain, Size: 92 bytes --]


Let me know if I should make any changes to this new setup.  Thanks for
the ideas. -- Eric

[-- Attachment #6: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [babel] Re: org-babel: Meta-LaTeX-Python-Environment

[Thomas S. Dye]

[-- Attachment #1.1: Type: text/plain, Size: 1684 bytes --]

On Oct 28, 2009, at 12:19 PM, Eric Schulte wrote:

> "Thomas S. Dye" <tsd@tsdye.com> writes:
>
> [...]
>
>> Eric,
>>
>> I think Torsten has a clearer idea than I do about what kinds of
>> programming structures might be appropriate here, but your suggestion
>> looks to me like an elegant replacement for the file based technique
>> I'm using to pass information into 'begin_src latex' blocks now.
>> Expanding the noweb syntax in the way you propose looks extremely
>> useful.  I think it introduces an exciting range of possibilities  
>> into
>> the workflow I'm developing with org-babel.  So, yes, your proposal
>> sounds appropriate to me.
>>
>> Tom
>
> This has now been implemented.  To try it out grab the most recent
> version of Org-mode.  Changes include
> - the ability to insert the *results* of source-code blocks through  
> the
>  use of noweb references in which the source-name is followed by ()s,
>  and
> - the addition of the org-babel-latex.el file which should make it
>  easier to add latex to the languages known to org-babel
>
> To try this out please run org-babel-tangle on the attached org-mode
> file.
>
> <noweb-eval.org>
> which should result in the attached .tex file
>
> <somewhere.tex>
> Let me know if I should make any changes to this new setup.  Thanks  
> for
> the ideas. -- Eric

Eric,

Yes, the expanded noweb syntax works here as advertised.  Wonderful.   
I look forward to making use of it and will take you up on your offer  
to make changes as new possibilities make themselves known.

All the best,
Tom

Thomas S. Dye, Ph.D.
T. S. Dye & Colleagues, Archaeologists, Inc.
Phone: (808) 529-0866 Fax: (808) 529-0884
http://www.tsdye.com



[-- Attachment #1.2: Type: text/html, Size: 4804 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: org-babel: Meta-LaTeX-Python-Environment

[Thomas S. Dye]

On Oct 28, 2009, at 5:19 AM, Eric Schulte wrote:

> I see, you are using the org-mode file "a level above" the direct
> export.  Maybe another option here would be to tag headlines based on
> which export target they are included within, and then base your  
> exports
> on the headline tags (using #+EXPORT_INCLUDE_TAGS:), although I agree
> this also seems like an appropriate place to use the tangle
> functionality.

Eric,

Thanks for pointing this out.  I'll look into this option.

All the best,
Tom

Re: org-babel: Meta-LaTeX-Python-Environment

[Torsten Wagner]

[-- Attachment #1.1: Type: text/plain, Size: 356 bytes --]

Ups,
sorry that happens if you are working normally with  emacs and compose a
message in a online editor (gmail). My fingers hit some emacs shortcuts
without my brain was telling them ;) ... and fired up the unfinished mail.

Anyhow I hope it is somehow clear what I like to do

Thus, just the greetings where missing

Thanks for help and reading

Torsten

[-- Attachment #1.2: Type: text/html, Size: 802 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

[babel] Meta-LaTeX-Python-Environment

[Dan Davison]

Hi Torsten,

Torsten Wagner <torsten.wagner@gmail.com> writes:

<...>
> I used the following simple example:

<...>
> #+srcname: test()
> #+begin_src python  :results latex

<...>

> As you can see, the result is wrapped now in LaTeX source code blocks.
> However, if I export the file by
> M-x org-export l
> the resulting LaTeX file still contains the source code itself (the part in the 
> verbatim environment.

Yes, you need ':exports results' as well as ':results latex'. The
':results latex' is necessary to specify that the *result* of the block
is latex code. The ':exports results' is necessary in order to tell it
only to include the result in the export product.

<...>
> Wished export-result (trimmed to relevant part):
> ...
> \usepackage{color}
> \definecolor{gray}{gray}{0.95}
> ...
> \section{Simple Test of org-babel}
> \label{sec-1}
> \colorbox{gray}{
> This is a Test: if a =1 and b = 2 then a + b = 3 right ?!
> }
> ...
>

> As you can see, I like to indicate the source block results resp. the LaTeX 
> source code blocks in a way which indicate clearly that they belong to the 
> "official" output. E.g. by adding a slight gray background.

OK, so I think what you want is that the results are

(a) latex code, and
(b) in a box, set apart as different from the main text

Well, org-babel doesn't do anything like that with latex results by
default, so you'd have to do it yourself. How about defining a source
block function which does the job of putting your latex results in a
box, and calling it with #+lob ? The following exports to latex with the
results in a red box. (Please pull the latest org-mode as this required
a change that I've just made.)

--8<---------------cut here---------------start------------->8---
#+LATEX_HEADER: \usepackage{color}

* Simple Test of org-babel
#+srcname: test()
#+begin_src python :exports none
  a = 1
  b = 2
  c = a+b
  "This is a Test: if a =" + str(a) + " and b = " + str(b) + " then a + b = " + str(c) + " right ?!" 
#+end_src

#+lob: putinbox(body=test()) :results latex :exports results

* Library code
  This could go in a separate file, as long as the file is added to the
  Library of Babel.
#+srcname: putinbox(body)
#+begin_src latex :exports none
\colorbox{red}{
body
}
#+end_src
--8<---------------cut here---------------end--------------->8---


>
> As mentioned before, I like to have mainly three ways of export 
> 1. Export everything

:exports both

> 2. Export everything except the source codes itself

:exports results

> 3. Export a particular LaTeX source code session (e.g. by using the tangle 
> function)

tangle


Hth,

Dan

>
> Nevertheless, I will try the other very good ideas in this thread. Maybe this 
> works for me already.
>
> Best regards and thanks again 
>
> Torsten
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: org-babel: Meta-LaTeX-Python-Environment

[Dan Davison]

[cc'ing list who were accidentally omitted]

Torsten Wagner <torsten.wagner@gmail.com> writes:

> Hi Dan,
>  
>
>
>     > 1. Hiding of the source code blocks for export
>     > I like to export the results of the source code block to LaTeX only.
>     However,
>
>     Using ':exports results' specifies that only the results should appear
>     in the exported document. This
>
>     #+begin_src python :exports results
>      6 + 6
>     #+end_src
>
>

Hi Torsten

> I tried this but the result is first the source code block followed by the
> result:

If it's not working, could you provide the exact example and tell us
your operating system, git version etc?

> Furthermore, I tried to create some LaTeX code as result of the code block

You need to use the ':results latex' header if you want the result to be
output as latex.

<...>

> In general I could try to use org-mode as much as possible. However, in that
> special case I like to merge three (or more) documents together.
> 1. The source code (e.g. python)
> 2. A laboratory journal (this would use org-mode magic)
> 3. An official report e.g. a manuscript to be submitted to a journal (this
> would be a LaTeX file)
>
> The idea is to be able to merge all this together to make sure data
> manipulation and calculus (source code) are as close as possible to the
> specific journal entry, which may supply additional important information and
> the final manuscript snippets which presents officially the particular result.
> A short example would be (without real headers)
>
> --8<-------------------------------------------------------------->8---
> * 23.10.09
> Measurement this morning was performed as usual but this time without warm up
> of device foo.
> Measurement file is saved under _link_.
> TODO: Don't forget to prepare for meeting tomorrow
>
> <<Python>>
> for foo import *
> a = load("data.csv")
> b = apply_filter(a,lp)
> plot(b)
> saveplot(bar.pdf)
> <<Python>>

OK, currently, the way to do that is something like

#+srcname: pyplot(file="bar.pdf")
#+begin_src python :results file
  plot(outfile=file)
  file
#+end_src
 
#+resname: pyplot
[[file:bar.pdf]]


Note that for a generalist language like python (which does not always
create output to file) you currently need to

1. specify that it outputs a file with ':results file'
2. explicitly send output to the file in your python code
3. explicitly return the filepath as a string at the end of the
   block. it will get inserted as a link.

You have the option of not hard-wiring the filepath in the python code
by using a variable as I did there.

[We may want to change this so that (3) happens automatically when
':file filepath' or ':results file' is provided]

>
> First low pass filter was applied then a plot is generated
> This plot will be used in publication for journal foo
> DEADLINE: <2009-12-14 Mo>
> <<LaTeX>>
> \begin{figure}
>   \includegraphics{bar.pdf}
> \end{figure}
> <<LaTeX>>

To avoid hard-wiring the filename into the latex block you could use the
org-babel-latex.el that Eric has posted.

>  --8<-------------------------------------------------------------->8---
>
> Text outside should be org-mode text.
> Now I like to export with three scenarios
> 1. Only the LaTeX part (e.g. by using tangle) resulting in a pure native
> LaTeX-file ready for submission

See emails in the concurrent main thread on this topic.

> Above example will result in
>
> \begin{figure}
>   \includegraphics{bar.pdf}
> \end{figure}
>
> 2. The LaTeX part and the org-mode parts whereas the LaTeX blocks should be
> somehow verbatim
> or in a some way marked inline. Above example should result in a LaTeX export
> like 

'begin_src latex' blocks are exported as code blocks with appropriate
fontification under org-mode.

I hope this is getting clearer now :)

Dan

>
> \section{23.10.09}
> Measurement this morning was performed as usual but this time without warm up
> time.
> Measurement file is saved under \footnote[/home/foo/data.csv]{link}.
> First low pass filter was applied then a plot is generated
> This plot will be used in publication for journal foo
> \begin{minipage}
> \begin{figure}
>   \includegraphics{bar.pdf}
> \end{figure}
> \end{minipage}
>
> 3. Export of all which will include the python blocks in a inline form as well.
>
> First of all I would be happy if I could avoid to have the source code blocks
> in the export file.
> I simply like to generate LaTeX-snipplets in python and export a LaTeX file
> finally.
>
> Thus,
>
> #+srcname: LaTeX
> #+begin_src python :session :exports results
>   plot([1,2,3,4,5],[2,4,6,8,10])
>  savefig(file,f-acecolor='w', edgecolor='w',format=None)
>  param1 = 19.7
>  perf = 77
> #+end_src

Re: [babel]org-babel: Meta-LaTeX-Python-Environment

[Torsten Wagner]

Hi Dan,
thanks for helping me to realize my idea.

Actually, I do not know whether it is not working or it is not working as I 
expect:
I used the following simple example:

--8<--------------------------cut here--start--------------------------->8---
* Simple Test of org-babel
#+srcname: test()
#+begin_src python  :results latex
  a = 1
  b = 2
  c = a+b
  "This is a Test: if a =" + str(a) + " and b = " + str(b) + " then a + b = " 
+ str(c) + " right ?!" 
#+end_src

#+resname: test
#+BEGIN_LaTeX
This is a Test: if a =1 and b = 2 then a + b = 3 right ?!
#+END_LaTeX
--8<--------------------------cut here--end--------------------------->8---

As you can see, the result is wrapped now in LaTeX source code blocks.
However, if I export the file by
M-x org-export l
the resulting LaTeX file still contains the source code itself (the part in the 
verbatim environment.
What I was looking for was something _without_ the source code just the 
result.

Getting export-result (trimmed to relevant part):
...
\section{Simple Test of org-babel}
\label{sec-1}
\begin{verbatim}
a = 1
b = 2
c = a+b
"This is a Test: if a =" + str(a) + " and b = " + str(b) + " then a + b = " + 
str(c) + " right ?!"
\end{verbatim}
This is a Test: if a =1 and b = 2 then a + b = 3 right ?!
...

Wished export-result (trimmed to relevant part):
...
\usepackage{color}
\definecolor{gray}{gray}{0.95}
...
\section{Simple Test of org-babel}
\label{sec-1}
\colorbox{gray}{
This is a Test: if a =1 and b = 2 then a + b = 3 right ?!
}
...

As you can see, I like to indicate the source block results resp. the LaTeX 
source code blocks in a way which indicate clearly that they belong to the 
"official" output. E.g. by adding a slight gray background.

As mentioned before, I like to have mainly three ways of export 
1. Export everything
2. Export everything except the source codes itself
3. Export a particular LaTeX source code session (e.g. by using the tangle 
function)

Nevertheless, I will try the other very good ideas in this thread. Maybe this 
works for me already.

Best regards and thanks again 

Torsten