On Aug 17, 2012, at 2:12 PM, Jed Brown <[email protected]> wrote:

I'll test this. I'm impressed by how much code you have removed and I'm happy to put it in petsc-dev, but we're building up a lot of changes to petsc-3.3. That's because it doesn't aim at being a full fledge yaml parser, and is based on a very minimalist recursive parser I found at http://stackoverflow.com/a/621451 rather than on the full featured example in the libyaml distribution. I'll try to get a student to work on implementing aliases and sequences this semester.

I added 2 tests (ex79.c and ex79f90.f90) and runex79 in the makefile in src/sys/examples/tutorials The global option -options_file_yaml can also be used to

Should we call the next patch release 3.3.1 instead of 3.3p? It's a significant enough change that people should be able to test for it with the PETSC_VERSION_ macros.

That's fine with me. That said, I doubt that the patch will break anybody's code. Should there be a rule for inclusion in the release tree vs. development? For instance that patches cannot change or delete a public interface and must pass all tests?

This line can certainly be removed.

+#define PETSC_MAX_YAML_LEN 128000

Yike... it was supposed to be removed indeed. Blaise

On Fri, Aug 17, 2012 at 1:52 PM, Blaise Bourdin <[email protected]> wrote: Hi,

Here is a revised version of my YAML patch that eliminates the limit on the yaml file length. Is there any rational objection to pushing it to petsc-3.3 and petsc-dev?

Blaise

-- Department of Mathematics and Center for Computation & Technology Louisiana State University, Baton Rouge, LA 70803, USA Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin

-- Department of Mathematics and Center for Computation & Technology Louisiana State University, Baton Rouge, LA 70803, USA Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin