Matthew Knepley <[email protected]> writes: > 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.
Well, parsing makefile variable statements into a dict is in the standard library. >> >> 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. pickle can serialize code. So when you load from a file, you could end up running arbitrary code. Restricting the serialization to human-readable data eliminates a lot of complications when reasoning about its behavior. Duplication of that data is a separate matter. > 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/>
