On Mon, Aug 22, 2016 at 10:01 PM, Jed Brown <[email protected]> wrote:
> Matthew Knepley <[email protected]> writes: > > > On Mon, Aug 22, 2016 at 8:58 PM, Jed Brown <[email protected]> wrote: > > > >> Matthew Knepley <[email protected]> writes: > >> > Not hard. We just add a flag to each value that is flipped on lookup, > >> > like PETSc. > >> > >> It would be nice to be able to offer suggestions for options that > >> BuildSystem queries. For that, we need the set of command line options > >> and the set of options that BuildSystem checked. We can get that by > >> having RDict implement __missing__(self, key) to consult an immutable > >> dict of the direct command line options and logging the query. > > > > Let me rephrase in order to see if I understand you. Suppose the code > > checks for an option that has no value. We currently interactively prompt > > for a value. > > I don't think I've ever had PETSc prompt me for a value, but options are > usually optional (or have defaults) so the code is actually checking > whether it exists rather than demanding its value. I have gotten confused. I was talking about the configure options system above, which will prompt for missing value. > > You would also like us to suggest that one of the original options > > which is close to this was misspelled. This is not hard. > > How do you know the complete list of recognized options at the moment > when one is requested? It seems to me that you have to wait until all > options have been checked before showing the --help documentation for > any options that are spelled similarly to the unrecognized options that > were passed in. Yes. My plan was to add a function right after setupHelp() in Framework that checked the input options against the options in the RDict. > > However, > > > > 1) If the option has a default value, then we cannot see that it is > > missing, > > That's fine; it's what default means. > > > 2) Those options should turn up in the unused list however > > You mean on the list of valid options? I would expect "unused list" > refers to > > set.difference(command_line_options, all_valid_options) Right so I mean that misspelled options will turn up in the unused options list. > >> Is it feasible to check all the options by some point meaningfully > >> sooner than the entire configure execution? It really sucks to wait > >> many minutes for configure to complete only to find out that you > >> misspelled an option. Getting that error message up-front would be a > >> huge usability improvement. > >> > > > > Right now, I am not sure how you would guarantee that the option would > not > > be used in the ensuing run. > > It may be possible to check all the options in __init__ or > setupDependencies (and error if any new option is requested after that). > That has the implicit requirement that all options we wish to use are 'declared' in the setupHelp(). I guess I am fine with that restriction. 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
