dolfin team mailing list archive

[Johan Hake <hake.dev@xxxxxxxxx>]

On 09/04/2012 11:11 AM, Martin Sandve Alnæs wrote:
> 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?

Not having to add it :)

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

SWIG does not like that. We need full type info.

Johan

> Martin
>