Matthew Knepley <[email protected]> writes: > On Fri, Mar 16, 2018 at 1:27 PM, Jed Brown <[email protected]> wrote: > >> Matthew Knepley <[email protected]> writes: >> >> > On Fri, Mar 16, 2018 at 1:17 PM, Jed Brown <[email protected]> wrote: >> > >> >> Matthew Knepley <[email protected]> writes: >> >> >> >> > I agree. We should remove all code (about 2/3 of it) which does a >> >> > hierarchy of communicating dicts (the original design). That would >> >> > make everything simple. No threads, no parents, etc. We leave in the >> >> > help the way we want it, types for args, etc. One thing its notably >> >> > missing, and that PETSc Options are missing, is listing the thing that >> >> > set the option (default, command line, code, env). >> >> >> >> Does RDict even need to be persistent? Who all reads it? I wonder if >> >> an existing human-readable file would be sufficient instead? >> >> >> > >> > I think we should persist the entire set of options used to configure for >> > later >> > interrogation, however we have not done that much so far. >> >> CONFIGURE_OPTIONS is written to petscvariables and printed by make info. >> I think fewer duplications is desirable. >> > > This gets into a separate discussion. I think Python info is more useful > since its > directly visible to scripts we might write.
Just call your Python parsing function. But this gets back to my earlier question: who needs to read RDict.db and for what purpose?
