Comment 11 for bug 1010865

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

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
>