Comment 12 for bug 1010865

On Mon, Jun 11, 2012 at 10:55:07AM -0000, Johan Hake wrote:
> On 06/11/2012 11:48 AM, Martin Sandve Alnæs wrote:
> > On 11 June 2012 11:18, Johan Hake<email address hidden> wrote:
> >> On 06/11/2012 10:51 AM, Martin Sandve Alnæs wrote:
> >>> On 11 June 2012 10:18, Johan Hake<email address hidden> wrote:
> >>>> On 06/11/2012 09:52 AM, Martin Sandve Alnæs wrote:
> >>>>> On 11 June 2012 09:40, Joachim Haga<email address hidden> wrote:
> >>>>>>>
> >>>>>>>> Next time I miss something (like min/max in this case), I'll just write
> >>>>>>>> "std::max" instead of creating a bug report.
> >>>>>>>
> >>>>>>> We have intentionally not allowed this, as it will make the interface
> >>>>>>> more busy. It might be a good idea though, but not fully convinced.
> >>>>>>>
> >>>>>>
> >>>>>> No strong opinion. But if you want to be convinced: The complexity is
> >>>>>> completely decided by the user. It will not become necessary or usual to
> >>>>>> use namespace qualifiers. It just makes them work.
> >>>>>
> >>>>> I don't see any problem with this.
> >>>>
> >>>> Me neither, but I wonder if we should expand the functionality while at
> >>>> it. For now there are only a few hard coded headers available for a
> >>>> user,<cmath> and surprise surprise<complex>.
> >>>>
> >>>> Should we make it possible to link other external libraries or home
> >>>> brewed for that case, to the generation of compiled expressions? This
> >>>> particular feature has come up a couple of times, in particular request
> >>>> for the different boost functions.
> >>>>
> >>>> To be able to make this as powerful as we need we could expose the
> >>>> relevant instant.build kwargs:
> >>>>
> >>>> local_headers=[], system_headers=[],
> >>>> include_dirs=['.'], library_dirs=[], libraries=[],
> >>>>
> >>>> to the Expression interface via:
> >>>>
> >>>> configure = dict(
> >>>> local_headers=["my_special_func.h"],
> >>>> system_headers=["some_system_header.h"],
> >>>> include_dirs=["some_obscure_path"],
> >>>> library_dirs=["my_library_path"],
> >>>> libraries=["my_special_func"])
> >>>>
> >>>> Expression(somestr, configure=configure)
> >>>>
> >>>> Then the user need to provide any non system paths manually.
> >>>>
> >>>> Johan
> >>>
> >>> That would be nice. Can it be made working with full expression class
> >>> code as well? E.g.
> >>>
> >>> e = Expression(cppcode="class MyExpr: public Expression {...};",
> >>> configure=dict(...))
> >>
> >> But of course!
> >>
> >> Also FYI there is no need for a kwarg in Expression:
> >>
> >> cppcode=some_code
> >>
> >> just pass some_code and you will be fine.
> >>
> >>> An additional idea: if cppcode is a single line and
> >>> matches "*.h", we can load cppcode from a file.
> >>> Then we can edit the cppcode with proper editor language support...
> >>>
> >>> Third idea:
> >>> e = Expression(cppfile="myexpr.h")
> >>> // with myexpr.h containing both class and configuration in comment:
> >>> /*
> >>> configure = dict(
> >>> local_headers=["my_special_func.h"],
> >>> system_headers=["some_system_header.h"],
> >>> include_dirs=["some_obscure_path"],
> >>> library_dirs=["my_library_path"],
> >>> libraries=["my_special_func"])
> >>> */
> >>> class MyExpr: public ...
> >>> { ... };

Very neat! Just what we need, more magic in the Expression class. :-)

> >> Neat, but that was a heck of a lot of magic... And it needs some
> >> thorough unit testing if implemented. We have to think about how to
> >> implement this properly, as it need to work for the
> >> compile_extension_module interface as well.

I think this would be a very neat addition to the Expression class and
it would only add \epsilon to the overall complexity of it. ;-)

--
Anders

> > Basically:
> > - Check for a marker at the first line (e.g. "configure:" or whatever)
> > - Read lines until "*/"
> > - Eval these lines to get the config dict
> > - Pass config dict to instant
> > Since the config dict details are defined by instant,
> > dolfin testing only needs to cover the reading of such lines.
> > This is a power user feature and doesn't need to be foolproof.
>
> Yes that part is easy. We just need to get it properly into the
> interface and play well with everything else...
>
> >>> This way
> >>> - the cppfile can be a single parameter to any script
> >>
> >> Which you also can do by:
> >>
> >> e = Expression(open("myexpr.h").read())
> >
> > Sure, the below was the main points. But if we automate the
> > file loading, which is easy to do, e = Expression(estr) becomes
> > slightly more dynamic and powerful.
>
> Sure.
>
> >>> - the python script is not polluted with C++ build info
> >>> - the build configuration is coupled with the code it configures
> >>
> >> Sounds attractive.
> >>
> >> The other path would be to provide some automatic configuration, but I
> >> think that would create a living hell for us. It is way easier to force
> >> the user provide the configuration.
> >
> > Exactly. Building issues are a hornets nest, lets keep it simple
> > and transparent instead of automatic and not working.
>
> Agree.
>
> Johan
>
> >> By any coincidence, have you generate some large Expression code
> > lately?
> >
> > Why? :)
> >
> > We do have an important use case for special linking to compiled
> > expressions.
> >
> > Martin
> >
>