Comment 10 for bug 1010865

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 ...
>> { ... };
>
> 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.

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.

>> 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.

>> - 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.

> 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