On 09/04/2012 11:11 AM, Martin Sandve Alnæs wrote: > On 4 September 2012 11:05, Johan Hake <[email protected]> wrote: >> On 09/04/2012 10:58 AM, Martin Sandve Alnæs wrote: >>> On 4 September 2012 10:49, Johan Hake <[email protected]> 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 > _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
