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