On Mon, Jun 11, 2012 at 03:12:07PM +0200, Johan Hake wrote:
> On 06/11/2012 02:27 PM, Anders Logg wrote:
> >On Mon, Jun 11, 2012 at 10:55:07AM -0000, Johan Hake wrote:
> >>On 06/11/2012 11:48 AM, Martin Sandve Alnæs wrote:
> >>>On 11 June 2012 11:18, Johan Hake<email address hidden>   wrote:
> >>>>On 06/11/2012 10:51 AM, Martin Sandve Alnæs wrote:
> >>>>>On 11 June 2012 10:18, Johan Hake<email address hidden>     wrote:
> >>>>>>On 06/11/2012 09:52 AM, Martin Sandve Alnæs wrote:
> >>>>>>>On 11 June 2012 09:40, Joachim Haga<email address hidden>       wrote:
> >>>>>>>>>
> >>>>>>>>>>Next time I miss something (like min/max in this case), I'll just write
> >>>>>>>>>>"std::max" instead of creating a bug report.
> >>>>>>>>>
> >>>>>>>>>We have intentionally not allowed this, as it will make the interface
> >>>>>>>>>more busy. It might be a good idea though, but not fully convinced.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>No strong opinion. But if you want to be convinced: The complexity is
> >>>>>>>>completely decided by the user. It will not become necessary or usual to
> >>>>>>>>use namespace qualifiers. It just makes them work.
> >>>>>>>
> >>>>>>>I don't see any problem with this.
> >>>>>>
> >>>>>>Me neither, but I wonder if we should expand the functionality while at
> >>>>>>it. For now there are only a few hard coded headers available for a
> >>>>>>user,<cmath>     and surprise surprise<complex>.
> >>>>>>
> >>>>>>Should we make it possible to link other external libraries or home
> >>>>>>brewed for that case, to the generation of compiled expressions? This
> >>>>>>particular feature has come up a couple of times, in particular request
> >>>>>>for the different boost functions.
> >>>>>>
> >>>>>>To be able to make this as powerful as we need we could expose the
> >>>>>>relevant instant.build kwargs:
> >>>>>>
> >>>>>>      local_headers=[], system_headers=[],
> >>>>>>      include_dirs=['.'], library_dirs=[], libraries=[],
> >>>>>>
> >>>>>>to the Expression interface via:
> >>>>>>
> >>>>>>     configure = dict(
> >>>>>>               local_headers=["my_special_func.h"],
> >>>>>>               system_headers=["some_system_header.h"],
> >>>>>>               include_dirs=["some_obscure_path"],
> >>>>>>               library_dirs=["my_library_path"],
> >>>>>>               libraries=["my_special_func"])
> >>>>>>
> >>>>>>     Expression(somestr, configure=configure)
> >>>>>>
> >>>>>>Then the user need to provide any non system paths manually.
> >>>>>>
> >>>>>>Johan
> >>>>>
> >>>>>That would be nice. Can it be made working with full expression class
> >>>>>code as well? E.g.
> >>>>>
> >>>>>e  = Expression(cppcode="class MyExpr: public Expression {...};",
> >>>>>configure=dict(...))
> >>>>
> >>>>But of course!
> >>>>
> >>>>Also FYI there is no need for a kwarg in Expression:
> >>>>
> >>>>     cppcode=some_code
> >>>>
> >>>>just pass some_code and you will be fine.
> >>>>
> >>>>>An additional idea: if cppcode is a single line and
> >>>>>matches "*.h", we can load cppcode from a file.
> >>>>>Then we can edit the cppcode with proper editor language support...
> >>>>>
> >>>>>Third idea:
> >>>>>e = Expression(cppfile="myexpr.h")
> >>>>>// with myexpr.h containing both class and configuration in comment:
> >>>>>/*
> >>>>>       configure = dict(
> >>>>>                local_headers=["my_special_func.h"],
> >>>>>                system_headers=["some_system_header.h"],
> >>>>>                include_dirs=["some_obscure_path"],
> >>>>>                library_dirs=["my_library_path"],
> >>>>>                libraries=["my_special_func"])
> >>>>>*/
> >>>>>class MyExpr: public ...
> >>>>>{ ... };
> >
> >Very neat! Just what we need, more magic in the Expression class. :-)
>
> And how should I read that?

Just ignore it.

> >>>>Neat, but that was a heck of a lot of magic... And it needs some
> >>>>thorough unit testing if implemented. We have to think about how to
> >>>>implement this properly, as it need to work for the
> >>>>compile_extension_module interface as well.
> >
> >I think this would be a very neat addition to the Expression class and
> >it would only add \epsilon to the overall complexity of it. ;-)
>
> The complexity is a self imposed consequence of being able to do
> compiled expression and to subclass an Expression in Python with the
> same class. I am perfectly happy with having Expression and
> CompiledExpression as two different classes, avoiding alot of
> hassle.

I know. So this would only be a small amount of added complexity.

--
Anders