<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 16, 2018 at 11:50 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 9:33 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>
>> >> Cray and others have admitted to doing this for as long as I've used<br>
>> >> PETSc.  It's possible to discourage it without setting land mines.<br>
>> ><br>
>> ><br>
>> > I guess my attitude is that most people using PETSc attempt to work<br>
>> > within the structures setup to use it. Cray people seem not to give a<br>
>> > fuck and just change stuff willy nilly until it works for them. Thats<br>
>> > fine. We can't stop them, but I am not motivated to enable them<br>
>> > either.<br>
>><br>
>> I just don't see the value of RDict.  It's read interface right now is<br>
>> grotesque (requires a lot of code and knowing a lot of almost magic<br>
>> names, thus it gets copy-pasted).<br>
><br>
><br>
> Criticism of the interface is fine. Rewrite it. No one will stop you.<br>
<br>
</span>You were suggesting stripping out tons of needless complexity.  I wanted<br>
to understand why it even needs to be persistent, especially in this<br>
non-human-readable form.  If the complexity is gutted so it becomes just<br>
a dict with attributes, then it could be persisted as JSON which would<br>
be more stable and human readable.</blockquote><div><br></div><div>Okay, JSON is fine. I am opposed to YAP.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
>>   I'd mainly prefer a nicer read<br>
>> interface, but if we redo the read interface, I'd rather it come from a<br>
>> human readable source.  And less duplication is better.<br>
>><br>
><br>
> This is the truly strange thing. You are advocating communicating between<br>
> programs by text files. This is a bizarre, and I thought dead, opinion. I<br>
> would much rather have structured data, than unstructured text that we<br>
> parse each time we want to do something.<br>
<br>
</span>Text is easier to debug and transform, and not a security hazard.<br>
<br>
Our configure doesn't cache anything because it's really hard to<br>
determine what might have become stale.  (CMake does a lot of caching<br>
and makes a mess of cache invalidation.)  I really don't know what all<br>
is in RDict.db so I can't assess when it might be stale.  It apparently<br>
contains the build directory which Debian does not want referenced in<br>
anything it installs.<br>
</blockquote></div><br>I think there is a conceptual difference here. "Caching" is the retention of</div><div class="gmail_extra">test results to be used in a _subsequent_ run of configure. This is wholly</div><div class="gmail_extra">wrong, and we do not do it, as you note. We persist the configure information</div><div class="gmail_extra">directly as Python modules in order that a later consumer can get at it.</div><div class="gmail_extra">This is safer, since there is no translation between the code that ran in</div><div class="gmail_extra">configure and what you output. I think it is easier to debug, because you do</div><div class="gmail_extra">not have to debug serialization at the same time. I would also argue its easier</div><div class="gmail_extra">to transform because it is already code, but I could see the other side on that.</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>