On 4 September 2012 11:21, Johan Hake <hake....@gmail.com> wrote:
> On 09/04/2012 11:11 AM, Martin Sandve Alnæs wrote:
>> On 4 September 2012 11:05, Johan Hake <hake....@gmail.com> wrote:
>>> On 09/04/2012 10:58 AM, Martin Sandve Alnæs wrote:
>>>> On 4 September 2012 10:49, Johan Hake <hake....@gmail.com> 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.
Ok, so SWIG understands that e.g. Mesh means dolfin::Mesh when inside
the dolfin namespace, but not when "using namespace dolfin" has been
declared? I remember there was some pain around those issues :)
Martin
_______________________________________________
Mailing list: https://launchpad.net/~dolfin
Post to : dolfin@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dolfin
More help : https://help.launchpad.net/ListHelp
