On Fri, Mar 16, 2018 at 11:50 PM, Jed Brown <[email protected]> wrote:
> Matthew Knepley <[email protected]> writes: > > > On Fri, Mar 16, 2018 at 9:33 PM, Jed Brown <[email protected]> wrote: > > > >> Matthew Knepley <[email protected]> writes: > >> > >> >> 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. > >> > >> I just don't see the value of RDict. It's read interface right now is > >> grotesque (requires a lot of code and knowing a lot of almost magic > >> names, thus it gets copy-pasted). > > > > > > Criticism of the interface is fine. Rewrite it. No one will stop you. > > You were suggesting stripping out tons of needless complexity. I wanted > to understand why it even needs to be persistent, especially in this > non-human-readable form. If the complexity is gutted so it becomes just > a dict with attributes, then it could be persisted as JSON which would > be more stable and human readable. Okay, JSON is fine. I am opposed to YAP. > >> I'd mainly prefer a nicer read > >> interface, but if we redo the read interface, I'd rather it come from a > >> human readable source. And less duplication is better. > >> > > > > This is the truly strange thing. You are advocating communicating between > > programs by text files. This is a bizarre, and I thought dead, opinion. I > > would much rather have structured data, than unstructured text that we > > parse each time we want to do something. > > Text is easier to debug and transform, and not a security hazard. > > Our configure doesn't cache anything because it's really hard to > determine what might have become stale. (CMake does a lot of caching > and makes a mess of cache invalidation.) I really don't know what all > is in RDict.db so I can't assess when it might be stale. It apparently > contains the build directory which Debian does not want referenced in > anything it installs. > I think there is a conceptual difference here. "Caching" is the retention of test results to be used in a _subsequent_ run of configure. This is wholly wrong, and we do not do it, as you note. We persist the configure information directly as Python modules in order that a later consumer can get at it. This is safer, since there is no translation between the code that ran in configure and what you output. I think it is easier to debug, because you do not have to debug serialization at the same time. I would also argue its easier to transform because it is already code, but I could see the other side on that. Matt -- 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/>
