[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] Literate programming in org
From: |
Sebastien Vauban |
Subject: |
Re: [O] Literate programming in org |
Date: |
Wed, 26 Aug 2015 12:36:04 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (windows-nt) |
Hi,
Max Linke <address@hidden> writes:
> I'm currently trying to use org-modes literate programming capabilities
> to write up a paper. So far it has been a joy to have the plotting code
> and text in the same document. Thanks for all the work people here have
> already put in to make this so easy.
Can't add anything! ;-)
> I have run into a two small problems so far
>
> * How can I use computed variables (string/int/float) in floating text?
>
> I have for example calculated a autocorrelation time and now want to
> use that calculated number in the text. The best solution I have
> found so far is
>
> #+name: print_acf_time
> #+begin_src ipython :session :exports none
>
> print(acf_time)
> #+end_src
>
> The autocorrelation time for the process is call_print_acf_time().
> That is OK-ish but I have to write a special code cell for every
> variable that I want to reference in my document. Is there another
> method to export variables to be easily accessible in org-mode?
See:
- inline Babel calls: ... call_<NAME>(<ARGUMENTS>) ... and/or
- inline code blocks: src_<LANGUAGE>{<BODY>}.
> * reruning specific cells only one time after emacs was started
>
> I have some cells that are long running and produce some variables
> I later use for plotting or calculating related values. To avoid
> recalculating I have added `cache: yes` to these cells. But they
> are only run once across restarts of emacs or my interpreter session
> in the background. When I start working again I would like to have a
> way to rerun all code-cells independent of the fact if they are cached
> or not. This would lead to a huge speed up in converting to latex for
> me.
I don't understand why re-running code blocks which are cached is
a problem. Could you elaborate?
Best regards,
Seb
--
Sebastien Vauban