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