[petsc-dev] MEMALIGN

[Matthew Knepley]

On Mon, Aug 22, 2016 at 10:01 PM, Jed Brown <jed at jedbrown.org> wrote:

> Matthew Knepley <knepley at gmail.com> writes:
>
> > On Mon, Aug 22, 2016 at 8:58 PM, Jed Brown <jed at jedbrown.org> wrote:
> >
> >> Matthew Knepley <knepley at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20160824/2892e02d/attachment.html>