On 09/04/2012 11:39 AM, Martin Sandve Alnæs wrote:
> 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 :)
SWIG is nice as long as you play with its rules :)
Johan
_______________________________________________
Mailing list: https://launchpad.net/~dolfin
Post to : dolfin@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dolfin
More help : https://help.launchpad.net/ListHelp
