<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 16, 2018 at 2:20 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
<br>
> On Fri, Mar 16, 2018 at 1:27 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
><br>
>> Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
>><br>
>> > On Fri, Mar 16, 2018 at 1:17 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
>> ><br>
>> >> Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
>> >><br>
>> >> > I agree. We should remove all code (about 2/3 of it) which does a<br>
>> >> > hierarchy of communicating dicts (the original design). That would<br>
>> >> > make everything simple.  No threads, no parents, etc. We leave in the<br>
>> >> > help the way we want it, types for args, etc. One thing its notably<br>
>> >> > missing, and that PETSc Options are missing, is listing the thing that<br>
>> >> > set the option (default, command line, code, env).<br>
>> >><br>
>> >> Does RDict even need to be persistent?  Who all reads it?  I wonder if<br>
>> >> an existing human-readable file would be sufficient instead?<br>
>> >><br>
>> ><br>
>> > I think we should persist the entire set of options used to configure for<br>
>> > later<br>
>> > interrogation, however we have not done that much so far.<br>
>><br>
>> CONFIGURE_OPTIONS is written to petscvariables and printed by make info.<br>
>> I think fewer duplications is desirable.<br>
>><br>
><br>
> This gets into a separate discussion. I think Python info is more useful<br>
> since its<br>
> directly visible to scripts we might write.<br>
<br>
</span>Just call your Python parsing function. </blockquote><div><br></div><div>Parse a makefile to get info? This is too convoluted for my first choice.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> But this gets back to my earlier question: who needs to read RDict.db and for what purpose?<br>
</blockquote></div><div class="gmail_extra"><br></div>1) We read this to get the configure modules during install and other post configure operations.</div><div class="gmail_extra"><br>2) I would like us to read RDict.db to get the original configure environment</div><div class="gmail_extra"><br></div><div class="gmail_extra">   Matt<br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.caam.rice.edu/~mk51/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div>
</div></div>