Allow min,max,std::* in Expressions

What do you mean with:

   "Also, it makes symbols like "std::min" ignored, so that if functions that are not
     treated specially are needed, they can be accessed through the namespace."

Means:

1/ Allow ':' as part of symbol name in parsing, so that "std::max" is
parsed as a single token instead of ["std", "max"]

2/ Don't consider symbols with "::" in them as variables.

The purpose is to allow the use of namespace qualifiers in expressions.
Next time I miss something (like min/max in this case), I'll just write
"std::max" instead of creating a bug report.

-j.

On 11 June 2012 08:18, Johan Hake <email address hidden> wrote:

> What do you mean with:
>
> "Also, it makes symbols like "std::min" ignored, so that if functions
> that are not
> treated specially are needed, they can be accessed through the
> namespace."
>
> --
> You received this bug notification because you are a member of DOLFIN
> Team, which is subscribed to DOLFIN.
> https://bugs.launchpad.net/bugs/1010865
>
> Title:
> Allow min,max,std::* in Expressions
>
> Status in DOLFIN:
> New
>
> Bug description:
> The attached patch makes it possible to use min(x,y) and max(x,y) in
> compiled expressions.
>
> Also, it makes symbols like "std::min" ignored, so that if functions
> that are not treated specially are needed, they can be accessed
> through the namespace.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/dolfin/+bug/1010865/+subscriptions
>

On 06/11/2012 08:55 AM, Joachim Haga wrote:
> Means:
>
> 1/ Allow ':' as part of symbol name in parsing, so that "std::max" is
> parsed as a single token instead of ["std", "max"]
>
> 2/ Don't consider symbols with "::" in them as variables.
>
> The purpose is to allow the use of namespace qualifiers in expressions.
> 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. The
problem is to keep the possibilities to

   Expression("something")

concise and not too powerful. As the number of extra magic things we
_could_ put in there easily can explode.

Your:

- "pow", "sqrt", "ceil", "fabs", "floor", "fmod"]
+ "pow", "sqrt", "ceil", "fabs", "floor", "fmod",
+ "min", "max"]

will fix your original problem, right?

Johan

>
> -j.
>
>
> On 11 June 2012 08:18, Johan Hake<email address hidden> wrote:
>
>> What do you mean with:
>>
>> "Also, it makes symbols like "std::min" ignored, so that if functions
>> that are not
>> treated specially are needed, they can be accessed through the
>> namespace."
>>
>> --
>> You received this bug notification because you are a member of DOLFIN
>> Team, which is subscribed to DOLFIN.
>> https://bugs.launchpad.net/bugs/1010865
>>
>> Title:
>> Allow min,max,std::* in Expressions
>>
>> Status in DOLFIN:
>> New
>>
>> Bug description:
>> The attached patch makes it possible to use min(x,y) and max(x,y) in
>> compiled expressions.
>>
>> Also, it makes symbols like "std::min" ignored, so that if functions
>> that are not treated specially are needed, they can be accessed
>> through the namespace.
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/dolfin/+bug/1010865/+subscriptions
>>
>

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

Your:
>
> - "pow", "sqrt", "ceil", "fabs", "floor", "fmod"]
> + "pow", "sqrt", "ceil", "fabs", "floor", "fmod",
> + "min", "max"]
>
> will fix your original problem, right?

Yes.

-j.

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.

Martin

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

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(...))

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 ...
{ ... };

This way
- the cppfile can be a single parameter to any script
- the python script is not polluted with C++ build info
- the build configuration is coupled with the code it configures

Martin

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 ...
> { ... };

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.

> This way
> - the cppfile can be a single parameter to any script

Which you also can d...

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 ...
>> { ... };
>
> 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 ...

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 ...
>>> { ... };
>>
>> Neat, but...

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"],
> >>> ...

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"],
>>>>> ...

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 contain...

I have now applied the patch. Will work on some of the other improvements suggested here.