dolfin team mailing list archive

[Johan Hake <hake.dev@xxxxxxxxx>]

On 09/04/2012 10:58 AM, Martin Sandve Alnæs wrote:
> On 4 September 2012 10:49, Johan Hake <hake.dev@xxxxxxxxx> wrote:
>> On 09/04/2012 10:00 AM, Marco Morandini wrote:
>>> On 09/03/2012 06:56 PM, Johan Hake wrote:
>>>> Marco!
>>>>
>>>> This is caused by the new automatic parsing of dependencies for
>>>> compiled_modules in Python. It was added so a minimum of dependencies
>>>> are dragged into the compilation, reducing the compilation time
>>>> considerably.
>>>
>>> Yes, I've seen you commits; they really reduce the compilation time.
>>> Thanks!
>>
>> dolfin.h drags in a lot of types...
>>
>>>> I do agree that your case should be supported in a better way than
>>>> adding it as a hack, as you did. Another hack is to introduce a dummy
>>>> public dependency:
>>>
>>> ....
>>>
>>>>
>>>> What we probably need is to expose some more compile options to the
>>>> Expression interface so you can do:
>>>>
>>>>    Expression(cppcode_d1, element=DGe, \
>>>>               system_headers=["dolfin/fem/GenericDofMap.h"])
>>>>
>>>> Other opinions?
>>>
>>>
>>> I think that the dolfin namespace should be automatically dealt with
>>> for code like
>>>
>>> p = Expression('x[0] + x[1]')
>>>
>>> but it should be the user's responsibility to deal with it
>>> whenever this idiom
>>>
>>> delta1 = Expression(cppcode_d1, element=DGe)
>>>
>>> is used.
>>>
>>> I.e.
>>>
>>> p = Expression('x[0] + x[1]')
>>>
>>> should automatically generate
>>>
>>> namespace dolfin
>>> {
>>> class Expression_121446782cdb69f97c3b9ff77a93499b: public Expression
>>> {
>>> public:
>>>   Expression_121446782cdb69f97c3b9ff77a93499b():Expression()
>>>   {  }
>>>   void eval(dolfin::Array<double>& values, const dolfin::Array<double>&
>>> x) const
>>>   { values[0] = x[0] + x[1]; }
>>> };
>>> }
>>>
>>> as it does right now,
>>>
>>> but for
>>>
>>> self.delta1 = Expression(cppcode_d1, element=DGe)
>>>
>>> the (supposedly proficient) user should explicitly
>>> enter the namespace:
>>>
>>> cppcode_d1 = """
>>> #include "whatever_must_be_additionally_included_and_is_not_detected"
>>> namespace dolfin
>>> {
>>> class Delta1 : public Expression
>>> {
>>>  ....
>>> }  //end class Delta1
>>> }; //end namespace dolfin"""
>>>
>>> without having it auto-magically opened and closed.
>>>
>>> I don't know if this is possible, thought. It would perhaps break a lot
>>> of user code but, on the other side, a lot of user code out there is
>>> perhaps broken right now precisely because of this problem, and you
>>> don't see any complaint because few users work with the trunk ....
>>
>> Might be. I have not thought of automatically adding namespace as a
>> problem before. I suppose adding dolfin namespace automatically is a bit
>> surprising for the power users. Especially if one wants to use other
>> namespaces.
>>
>> We could use a regexp to check if a namespace is already added, and
>> adding it if there isn't one?
>>
>> I still think it would be a good idea to add more powerful link and
>> include options to the compiled expression interface. This would fix
>> your case and others who wants more powerful external libraries.
>>
>> Johan
> 
> I don't understand why the user-defined class is placed in the dolfin
> library namespace in the first place?

As I said, it do confuse a power user, and make it just a bit easier for
the average joe making a compiled Expression.

I am not vigorously defending this "feature", just saying it was
introduced as a convenient thing. Most people will generate code which
should reside in the dolfin namespace anyway.

Johan