On Fri, Mar 16, 2018 at 9:23 PM, Jed Brown <[email protected]> wrote:
> Matthew Knepley <[email protected]> writes: > > > On Fri, Mar 16, 2018 at 6:25 PM, Jed Brown <[email protected]> wrote: > > > >> Matthew Knepley <[email protected]> writes: > >> > >> > On Fri, Mar 16, 2018 at 2:20 PM, Jed Brown <[email protected]> wrote: > >> > > >> >> 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. > >> > > >> > > >> > Parse a makefile to get info? This is too convoluted for my first > choice. > >> > > >> > > >> >> But this gets back to my earlier question: who needs to read RDict.db > >> and > >> >> for what purpose? > >> >> > >> > > >> > 1) We read this to get the configure modules during install and other > >> post > >> > configure operations. > >> > > >> > 2) I would like us to read RDict.db to get the original configure > >> > environment > >> > >> The problem is that RDict.db is opaque > > > > > > This seems to be a normative characterization. I think the make variables > > are > > "dead" because its hard to make use of them in scripting. > > > > > >> and some people edit > >> petscvariables and/or petscconf.h to work around weird issues. > > > > > > Awful. We should not encourage this. It should flow from the top. > > Cray and others have admitted to doing this for as long as I've used > PETSc. It's possible to discourage it without setting land mines. I guess my attitude is that most people using PETSc attempt to work within the structures setup to use it. Cray people seem not to give a fuck and just change stuff willy nilly until it works for them. Thats fine. We can't stop them, but I am not motivated to enable them either. Matt > > >> We can't > >> practically get rid of petscvariables without abandoning make. > >> > > > > The aim should not be to get rid of them, but rather to have them be read > > only. > > Good luck with that. > > >> It's also frustrating to debug because the names used in Python may not > >> match the names used in human-readable output, > > > > > > Changing this is trivial. > > Hooray! > > > Matt > > > > > >> and that also prevents > >> grepping to find unused variables. > >> > > > > > > > > -- > > What most experimenters take for granted before they begin their > > experiments is infinitely more interesting than any results to which > their > > experiments lead. > > -- Norbert Wiener > > > > https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/> > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>
