dolfin team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

On 4 September 2012 11:05, Johan Hake <hake.dev@xxxxxxxxx> wrote:
> 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,

Well, you're not explaining :-P

> and make it just a bit easier for
> the average joe making a compiled Expression.

How?

> I am not vigorously defending this "feature", just saying it was
> introduced as a convenient thing.

What's the convenience?

> Most people will generate code which
> should reside in the dolfin namespace anyway.

Why? I don't agree in principle. The dolfin namespace is for the dolfin library.
If you want the dolfin namespace accessible, why not use a "using" statement?

Martin