fenics team mailing list archive

[Kristian Oelgaard <k.b.oelgaard@xxxxxxxxx>]

On 28 April 2010 18:26, Anders Logg <logg@xxxxxxxxx> wrote:
> On Wed, Apr 28, 2010 at 12:05:19PM +0200, Kristian Oelgaard wrote:
> > On 28 April 2010 11:59, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
> > >
> > >
> > >On 27/04/10 13:52, Kristian Oelgaard wrote:
> > >>
> > >>
> > >>On 27 April 2010 14:18, Anders Logg <logg@xxxxxxxxx> wrote:
> > >>>
> > >>>Any ideas on how to keep the code in the documentation and the actual
> > >>>demos in sync? Should we have a script that copies all the source
> > >>>files? Or should we do the opposite: extract the demos from the
> > >>>documentation?
> > >>
> > >>Good question, initially I thought copying from DOLFIN to documentation
> > >>was the way to go, but on second thought the other way around might be
> > >>better.
> > >>The reason is that if the demos break, then they will be fixed in the
> > >>documentation which makes is more likely that the accompanying text (and
> > >>code snippets) will also be corrected.
> > >>
> > >
> > >We'll usually have the source code for a demo broken into pieces in the
> > >documentation with an explanation for each part of the code (rather than one
> > >big chunk), so how would this work with syncing to the actual demo code?
> >
> > I think the entire main.cpp file (and UFL ) should be available for download as it is now.
> > Then, if a demo breaks one will have to manually modify the code snippets and the text.
> > (and of course the code in main.cpp and the UFL file if appropriate)
>
> Shouldn't it be possible to write a script that extracts the pieces
> and patches them together?

Probably, assuming that all pieces match up to the entire code.
For each demo, the piece of code you decide to present in the documentation might be different, so the script will have to be custom made for each demo.
I think we should stick to adding two or three demos in the beginning to see how we can get this running in some automated way.

> That way, the buildbot will test nightly that the documentation makes
> sense.

This should definitely happen in some form.
I guess we should also have stable releases of the documentation and follow the DOLFIN release cycle and version numbering.

Kristian

> --
> Anders
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkvYYb4ACgkQTuwUCDsYZdF7SACfUNGoVdS376NtL/wCToQSqnCQ
> 0roAnA6ABN+tLPfhHB60FzT2gAsAGkVh
> =QraE
> -----END PGP SIGNATURE-----

Attachment: signature.asc
Description: OpenPGP digital signature