|
From: Matthias B. <ba...@ir...> - 2006-09-04 13:41:24
|
rom...@us... wrote: > @@ -121,12 +121,16 @@ > > Returns a reference to the internal list (which may be modified). > """ > + if None is self._function_transformers: > + #TODO: for trivial cases get_size( int&, int& ) Py++ should guess > + #function transformers On what information would such a guess be based? The declaration doesn't contain any reliable information about the intention of the programmer. Will the implicit guess be available when the user also attaches some transformers? And while we're at it, just out of curiosity, why do you initialize _function_transformers with None instead of an empty list? (to me it appears as if this only has disadvantages, mainly that you always have to test it against None if you want to access the attribute) - Matthias - |
|
From: Matthias B. <ba...@ir...> - 2006-09-21 11:15:55
|
rom...@us... wrote: > Log Message: > ----------- > adding support for associated_decl_creators to file writers Can you please elaborate on those changes and let me know what a user has to do to adapt to those modifications? Currently, it seems that the code creators that I add to the associated_decl_creators list don't get written anymore. - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-09-21 11:42:21
|
On 9/21/06, Matthias Baas <ba...@ir...> wrote: > rom...@us... wrote: > > Log Message: > > ----------- > > adding support for associated_decl_creators to file writers > > Can you please elaborate on those changes and let me know what a user > has to do to adapt to those modifications? > Currently, it seems that the code creators that I add to the > associated_decl_creators list don't get written anymore. Yes of course. First of all I committed new version that should fix the problem. (Also the generated code for some reason is not formatted at all) - # Are we dealing with transformed non-virtual member functions? - if maker_cls==code_creators.mem_fun_transformed_t: - # Create the code creator that generates the function source code - fwrapper = code_creators.mem_fun_transformed_wrapper_t(self.curr_decl) - # and add it either to the wrapper class or just to the declaration - # area of the cpp file - if self.curr_code_creator.wrapper is None: - self.curr_code_creator.associated_decl_creators.append(fwrapper) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ You had bug in this line. You did not added fwrapper to code creators tree. Thus you did not defined its logical place. Thus multiple_files_t.associated_decl_creators ignored it. - else: - self.curr_code_creator.wrapper.adopt_creator(fwrapper) - # Set the wrapper so that the registration code will refer to it - maker.wrapper = fwrapper The way I fixed it is to generate class wrapper for this case. In general the idea behind the change is simple: almost every registration requires additional functionality ( wrappers, opaque type registration, overload macro ). These wrappers should be generated in the same file, in the global namespace where the declaration registration will be generated. In order to simplify file writers and to solve some other problems( generate include directive in this or that header, for example ) I added new concept: every "registration_based" code creator will keep a list of associated creators and file writers will be aware of this creators and will generate right code. Hope I was clear. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Matthias B. <ba...@ir...> - 2006-09-21 14:16:41
|
Roman Yakovenko wrote:
> On 9/21/06, Matthias Baas <ba...@ir...> wrote:
>> rom...@us... wrote:
>> > Log Message:
>> > -----------
>> > adding support for associated_decl_creators to file writers
>>
>> Can you please elaborate on those changes and let me know what a user
>> has to do to adapt to those modifications?
>> Currently, it seems that the code creators that I add to the
>> associated_decl_creators list don't get written anymore.
>
> Yes of course. First of all I committed new version that should fix the
> problem.
No, it doesn't (because now the class mem_fun_transformed_wrapper_t is
not instantiated).
Unfortunately, I also have to say that I'm not that happy about the
workaround to force the generation of a wrapper class. This is a step
back from what was already there. The comment you put into the code
("function transformers require wrapper") is not true. The majority of
classes in the Maya SDK (which do use function transformers) do not
require a wrapper class and I'd like to keep it that way. To quote yourself:
"The generated code should not be too different from the one, that human
would write. I don't write code like this."
I know that for some reason you do want to have wrapper classes in all
cases. That's why I would have added an option to control this.
Actually, we could have reused an option that was already there once:
finalize. But as you reacted somewhat testily on this topic I postponed
the implementation of this functionality until this feature is
implemented (besides that, the function transformers already do add
themselves to a wrapper class if there is one, but they just don't force
the creation of a wrapper class).
> self.curr_code_creator.associated_decl_creators.append(fwrapper)
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> You had bug in this line. You did not added fwrapper to code creators tree.
> Thus you did not defined its logical place. Thus
> multiple_files_t.associated_decl_creators ignored it.
All right. I've seen that you moved the associated_decl_creators list to
the class registration_based_t which is a base class for calldef_t. So
far so good. But how is this list used? What are the requirements on the
code creators that may be put into this list?
Just to test how it behaves, I added a code creator to the list of a
wrapper function creator to see where it gets written. But I never
noticed a difference, no matter if it was inside
associated_code_creators or not. If the code creator was not hooked into
any other part of the code creator tree, it didn't get written at all
and if it was added to the root, it just got written into the main C++
file.
So how is this feature used?
- Matthias -
|
|
From: Roman Y. <rom...@gm...> - 2006-09-21 18:10:56
|
On 9/21/06, Matthias Baas <ba...@ir...> wrote:
> > Yes of course. First of all I committed new version that should fix the
> > problem.
>
> No, it doesn't (because now the class mem_fun_transformed_wrapper_t is
> not instantiated).
I am sorry I break it. For my defence I can say that I run
function_transformation
unit test and it passed.
Also if mem_fun_transformed_wrapper_t is not instantiated, than
find_out_mem_fun_creator_classes is broken and we should fix it.
> Unfortunately, I also have to say that I'm not that happy about the
> workaround to force the generation of a wrapper class. This is a step
> back from what was already there. The comment you put into the code
> ("function transformers require wrapper") is not true. The majority of
> classes in the Maya SDK (which do use function transformers) do not
> require a wrapper class and I'd like to keep it that way. To quote yourself:
>
> "The generated code should not be too different from the one, that human
> would write. I don't write code like this."
Actually I do.
When we discussed this feature I explain why I prefer to keep wrappers and
ask you explicitly to create generated code in a wrapper.
> I know that for some reason you do want to have wrapper classes in all
> cases. That's why I would have added an option to control this.
Please don't. This is not an option that should exist. Someday we will fix the
problem in the whole project.
> Actually, we could have reused an option that was already there once:
> finalize. But as you reacted somewhat testily on this topic I postponed
> the implementation of this functionality until this feature is
> implemented (besides that, the function transformers already do add
> themselves to a wrapper class if there is one, but they just don't force
> the creation of a wrapper class).
They should. Can you give me few good reasons to not create wrappers?
> > self.curr_code_creator.associated_decl_creators.append(fwrapper)
> >
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > You had bug in this line. You did not added fwrapper to code creators tree.
> > Thus you did not defined its logical place. Thus
> > multiple_files_t.associated_decl_creators ignored it.
>
> All right. I've seen that you moved the associated_decl_creators list to
> the class registration_based_t which is a base class for calldef_t. So
> far so good. But how is this list used? What are the requirements on the
> code creators that may be put into this list?
They should belong to module_t code creator
> Just to test how it behaves, I added a code creator to the list of a
> wrapper function creator to see where it gets written. But I never
> noticed a difference, no matter if it was inside
> associated_code_creators or not. If the code creator was not hooked into
> any other part of the code creator tree, it didn't get written at all
> and if it was added to the root, it just got written into the main C++
> file.
> So how is this feature used?
This feature is still under development and it is possible I have bugs.
I jus verified that I did not break the working code. I will try to
finish the feature
in a day or two
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
|
From: Matthias B. <ba...@ir...> - 2006-09-21 19:11:04
|
Roman Yakovenko wrote: >> implemented (besides that, the function transformers already do add >> themselves to a wrapper class if there is one, but they just don't force >> the creation of a wrapper class). > > They should. Can you give me few good reasons to not create wrappers? Besides being an unnecessary layer of complexity that doesn't serve any useful purpose and just leads to larger source files and executables, it breaks my regression test. It's the vector class again. This class has a couple of predefined vectors as static members such as, for example, "zero" which is the vector (0,0,0). Doing an operation such as adding two vectors doesn't work anymore if one operand is instantiated in Python and the other one is one of the above predefined vectors: a = Vector(1,2,3) # this will be a Vector_wrapper instance b = Vector.zero # this will be a Vector instance c = a+b # fails I don't know exactly what happens here inside Boost.Python, but my guess would be that the addition is only defined between two *wrapper* classes and not between a wrapper class and the original class. I've experienced such things before with other libraries which is why I'm only creating wrapper classes when it is absolutely necessary. - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-09-21 19:19:17
|
On 9/21/06, Matthias Baas <ba...@ir...> wrote: > > They should. Can you give me few good reasons to not create wrappers? > > Besides being an unnecessary layer of complexity that doesn't serve any > useful purpose and just leads to larger source files and executables, it > breaks my regression test. I understand that you don't like them, but I ask you for reasons :-). "unnecessary layer of complexity" all wrapper functionality for declaration defined in class A could be found in A_wrapper. "larger source files" - this way I think the generated source code is easier to understand and explain > It's the vector class again. This class has a couple of predefined > vectors as static members such as, for example, "zero" which is the > vector (0,0,0). > Doing an operation such as adding two vectors doesn't work anymore if > one operand is instantiated in Python and the other one is one of the > above predefined vectors: > > a = Vector(1,2,3) # this will be a Vector_wrapper instance > b = Vector.zero # this will be a Vector instance > c = a+b # fails > > I don't know exactly what happens here inside Boost.Python, but my guess > would be that the addition is only defined between two *wrapper* classes > and not between a wrapper class and the original class. > > I've experienced such things before with other libraries which is why > I'm only creating wrapper classes when it is absolutely necessary. This is a valid point, that I should check. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Roman Y. <rom...@gm...> - 2006-09-21 19:29:55
|
On 9/21/06, Roman Yakovenko <rom...@gm...> wrote:
> > It's the vector class again. This class has a couple of predefined
> > vectors as static members such as, for example, "zero" which is the
> > vector (0,0,0).
> > Doing an operation such as adding two vectors doesn't work anymore if
> > one operand is instantiated in Python and the other one is one of the
> > above predefined vectors:
> >
> > a = Vector(1,2,3) # this will be a Vector_wrapper instance
> > b = Vector.zero # this will be a Vector instance
> > c = a+b # fails
> >
> > I don't know exactly what happens here inside Boost.Python, but my guess
> > would be that the addition is only defined between two *wrapper* classes
> > and not between a wrapper class and the original class.
> >
> > I've experienced such things before with other libraries which is why
> > I'm only creating wrapper classes when it is absolutely necessary.
>
> This is a valid point, that I should check.
Do you mind to post small test case that reproduce the error?
Also, before you do this, can you check whether redefine_operators = True
solves the problem?
mb = module_builder_t( ... )
mb.class_('Vector' ).redefine_operators = True
Thank you.
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
|
From: Matthias B. <ba...@ir...> - 2006-09-22 13:27:17
|
Roman Yakovenko wrote:
> On 9/21/06, Roman Yakovenko <rom...@gm...> wrote:
>> > a = Vector(1,2,3) # this will be a Vector_wrapper instance
>> > b = Vector.zero # this will be a Vector instance
>> > c = a+b # fails
>> >
>> > I don't know exactly what happens here inside Boost.Python, but my
>> guess
>> > would be that the addition is only defined between two *wrapper*
>> classes
>> > and not between a wrapper class and the original class.
>> >
>> > I've experienced such things before with other libraries which is why
>> > I'm only creating wrapper classes when it is absolutely necessary.
>>
>> This is a valid point, that I should check.
>
> Do you mind to post small test case that reproduce the error?
> Also, before you do this, can you check whether redefine_operators = True
> solves the problem?
This flag hasn't had an influence on the generated code.
Here is an example that demonstrates the problem:
// testlib.h
struct Vector
{
double x;
static const Vector one;
Vector(double ax) : x(ax) {}
Vector operator+(const Vector& other) { return Vector(x+other.x); }
virtual void trigger_wrapper() {}
};
// testlib.cpp
#include "testlib.h"
const Vector Vector::one = Vector(1);
Then, in Python the following line fails:
v = Vector(3)+Vector.one
This produces the following TypeError exception:
TypeError: unsupported operand type(s) for +: 'Vector' and 'Vector'
If you comment out the trigger_wrapper() method everything works fine.
- Matthias -
|
|
From: Matthias B. <ba...@ir...> - 2006-09-22 21:59:02
|
Roman Yakovenko wrote: > They should. Can you give me few good reasons to not create wrappers? I've just stumbled over another problem as I compiled the bindings on Linux. Compilation fails because of a class that has a private destructor. This class only provides static members and a few enums, it isn't meant to be instantiated (let alone sub-classed). - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-09-23 07:53:06
|
On 9/23/06, Matthias Baas <ba...@ir...> wrote: > Roman Yakovenko wrote: > > They should. Can you give me few good reasons to not create wrappers? > > I've just stumbled over another problem as I compiled the bindings on > Linux. Compilation fails because of a class that has a private > destructor. This class only provides static members and a few enums, it > isn't meant to be instantiated (let alone sub-classed). Sometimes static members need wrapper, for example arrays. Can you post small code that reproduce the problem? -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Matthias B. <ba...@ir...> - 2006-09-24 07:13:36
|
Roman Yakovenko wrote:
> On 9/23/06, Matthias Baas <ba...@ir...> wrote:
>> Roman Yakovenko wrote:
>> > They should. Can you give me few good reasons to not create wrappers?
>>
>> I've just stumbled over another problem as I compiled the bindings on
>> Linux. Compilation fails because of a class that has a private
>> destructor. This class only provides static members and a few enums, it
>> isn't meant to be instantiated (let alone sub-classed).
>
> Sometimes static members need wrapper, for example arrays.
> Can you post small code that reproduce the problem?
class Foo
{
public:
static void get_value(int& n) { n = 12; }
private:
~Foo() {}
};
In your generation script you have to assign the output transformer to
get_value:
Foo.member_function("get_value").function_transformers.append(output_t(1))
Compilation will then produce the following error:
testlib.h: In constructor `Foo_wrapper::Foo_wrapper()':
testlib.h:14: error: `Foo::~Foo()' is private
testlib/Foo.pypp.cpp:13: error: within this context
error: command 'gcc' failed with exit status 1
Tested on Linux with gcc 3.3.4 (whereas MSVC 7.1 obviously ignores that
the destructor is private and compiles the above code without problems,
so you have to test with gcc as well).
- Matthias -
|
|
From: Roman Y. <rom...@gm...> - 2006-09-26 18:55:15
|
On 9/24/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > On 9/23/06, Matthias Baas <ba...@ir...> wrote:
> >> Roman Yakovenko wrote:
> >> > They should. Can you give me few good reasons to not create wrappers?
> >>
> >> I've just stumbled over another problem as I compiled the bindings on
> >> Linux. Compilation fails because of a class that has a private
> >> destructor. This class only provides static members and a few enums, it
> >> isn't meant to be instantiated (let alone sub-classed).
> >
> > Sometimes static members need wrapper, for example arrays.
> > Can you post small code that reproduce the problem?
>
> class Foo
> {
> public:
> static void get_value(int& n) { n = 12; }
>
> private:
> ~Foo() {}
> };
>
> In your generation script you have to assign the output transformer to
> get_value:
>
> Foo.member_function("get_value").function_transformers.append(output_t(1))
>
> Compilation will then produce the following error:
>
> testlib.h: In constructor `Foo_wrapper::Foo_wrapper()':
> testlib.h:14: error: `Foo::~Foo()' is private
> testlib/Foo.pypp.cpp:13: error: within this context
> error: command 'gcc' failed with exit status 1
>
>
> Tested on Linux with gcc 3.3.4 (whereas MSVC 7.1 obviously ignores that
> the destructor is private and compiles the above code without problems,
> so you have to test with gcc as well).
I test generated code on two compilers: MSVC 7.1 and gcc 4.0.3.
The generated code does not work. Also I don't see other choice but not to
generate wrapper in this specific case. I will try to fix it in next few days.
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
|
From: Roman Y. <rom...@gm...> - 2006-09-04 13:52:50
|
On 9/4/06, Matthias Baas <ba...@ir...> wrote:
> rom...@us... wrote:
> > @@ -121,12 +121,16 @@
> >
> > Returns a reference to the internal list (which may be modified).
> > """
> > + if None is self._function_transformers:
> > + #TODO: for trivial cases get_size( int&, int& ) Py++ should guess
> > + #function transformers
>
> On what information would such a guess be based? The declaration doesn't
> contain any reliable information about the intention of the programmer.
It is not true. You can treat both arguments as in_out:
boost::python::tuple get_size( int, int ){
return make_tuple( ... )
}
The function "get_size" becomes callable. May be it have bad
interface, but still.
> Will the implicit guess be available when the user also attaches some
> transformers?
Program development is the interactive process. User\programmer will
see that the
interface is not optimal. Programmer will be able to come back and decide,
whether it leaves Py++ created transformations and add his own or replace them.
> And while we're at it, just out of curiosity, why do you initialize
> _function_transformers with None instead of an empty list?
I will add "default( calculated )" transformers on first time. After
this I will not touch it
and user is responsible for it's management. See for example
class_t.indexing_suite
property.
> (to me it
> appears as if this only has disadvantages, mainly that you always have
> to test it against None if you want to access the attribute)
Please read the code:
if None is self._function_transformers:
#TODO: for trivial cases get_size( int&, int& ) Py++ should guess
#function transformers
self._function_transformers = []
return self._function_transformers
None will be never returned from this function.
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
