Re: Best practices for literate programming [was: Latex export of tables]

[Rainer@krugs.de (Rainer M. Krug)]

Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:

> Hi Vikas,
>
> On Wed, Apr 17, 2013 at 03:40:22AM +0530, Vikas Rawal wrote:
>> 
>> > At one point I realised the problem and made the decision to
>> > split things into two kinds of files: static content (document
>> > structuring, text, plots, etc), and dynamic content (babel, TikZ blocks
>> > that generate tables, plots, figures, etc used by the static content
>> > files).  It is still reproducible research, but modular and less hacky
>> > (hence more stable).
>> 
>> This is indeed a very neat approach. Would you kindly elaborate?
>> 
>> Would it be too much work for you to get some illustrations from your
>> work?
>
> Well ... it was couple of years back, the Org version was quite
> different, e.g. babel was rapidly evolving.  It might be a fair bit of
> work to get it working again.  That said, last year I gave a talk in an
> internal workshop, I made the plots with the attached file.  I didn't
> spend time to make sure everything is pretty, so the legend and titles
> might be a little wonky.  Just evaluating the two main source blocks
> should give you two plots in pdf files.
>
>> In your scheme of things, how do you finally combine the static and
>> the dynamic content?
>> 
>> Any chance that you could release the source of something like a
>> chapter of your thesis for people to see? Or may be create something
>> with dummy content?
>
> The idea is to keep the dynamic content on separate org files which you
> export less frequently during the course of your writing, e.g. any
> tables that are inputs for source blocks.  Evaluating these blocks, or
> exporting these dynamic files (whichever is your preference) generates
> the graphic which is then used in the static file.  This is not limited
> to plots, you could write org/LaTeX tables to separate files.  You can
> then easily include those in your static files.
>
> My main motivation for this was to make the export process simpler.  And
> since the complicated interacting bits are all isolated and modularised,
> there are fewer things that go wrong and many files are updated only
> when required, hence faster too!
>
> Anyway, this is all probably very vague without working examples.  I'll
> try to come up with something, but I have been rather busy for the last
> year or so and do not see any sign of respite in the near future :-/.
> I'll get this fleshed out at some point, just don't know how soon.
>
> Hope this was helpful in some way,
>
> :)
<#secure method=pgpmime mode=sign>
I did not follow the initial thread, but the new header caught my
attentian, as I am doing something similar with papers. Nothing against
org for writing papers, but I prefer LyX [1]. But for doing the analysis,
org together, nothing beats org. So in my org file I have the
analysis which creates graphs on export (and a basic report of the
analysis, including all the source code necessary, which I can then use
as an appendix for the paper).

These graphs are then inserted in the lyx file. I assume, you used
something similar, only that the oputput can then be used in the org
file (thesis) - correct?

Cheers,

Rainer

Footnotes: 
[1]  http://www.lyx.org - very nice LaTeX frontend.

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug