pygccxml-development

Re: [pygccxml-development] [pygccxml-commit] SF.net SVN: pygccxml: [570] pyplusplus_dev/pyplusplus

[Roman Y. <rom...@gm...>]

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/

Re: [pygccxml-development] [pygccxml-commit] SF.net SVN: pygccxml: [570] pyplusplus_dev/pyplusplus

[Roman Y. <rom...@gm...>]

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/

Re: [pygccxml-development] [pygccxml-commit] SF.net SVN: pygccxml: [570] pyplusplus_dev/pyplusplus

[Matthias B. <ba...@ir...>]

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 -

Re: [pygccxml-development] [pygccxml-commit] SF.net SVN: pygccxml: [570] pyplusplus_dev/pyplusplus

[Roman Y. <rom...@gm...>]

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/

Re: [pygccxml-development] Adding properties

[Roman Y. <rom...@gm...>]

On 9/21/06, Kevin Bluck <kev...@gm...> wrote:
> Is there a proper way to declare properties in Py++? I've looked around
> but can't find anything apparent. The only way I can see is something like:
>
>  Foo.add_code('add_property("Value", &Foo::getValue)')
>

Take a look on next examples:
A simple one:
http://svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/examples/custom_code_creator/

More complex one:
http://python-ogre.python-hosting.com/file/trunk/python-ogre/properties.py

I know it is not as simple as you expect. If you can wait I plan to
add support for
properties in a week or two

struct Foo{
    int get_x();
    void set_x( int x );
};

mb = module_builder_t( ... )
foo = mb.class_( 'Foo' )
foo.property_( foo.member_function( 'get_x' ), foo.member_function( 'set_x' ) )
#or may be next interface
foo.property_(  'get_x', 'set_x' )

Thoughts?

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] Force bp::no_init

[Roman Y. <rom...@gm...>]

On 9/21/06, Kevin Bluck <kev...@gm...> wrote:
> Roman Yakovenko wrote:
> > Foo = mbuilder.class_( "Foo" )
> > constructors = Foo.constructors()
> > for c in constructors:
> >     if not c.is_copy_constructor:
> >         Foo.remove_declaration( c )
> >
> Thanks, that does work.
>
> Here is the class function I refactored it into:
>
> def force_no_init(self):
>     for c in [ c for c in self.constructors() if not
> c.is_copy_constructor ]:
>         self.remove_declaration( c )

Cool.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] Force bp::no_init

[Kevin B. <kev...@gm...>]

Roman Yakovenko wrote:
> Foo = mbuilder.class_( "Foo" )
> constructors = Foo.constructors()
> for c in constructors:
>     if not c.is_copy_constructor:
>         Foo.remove_declaration( c )
>   
Thanks, that does work.

Here is the class function I refactored it into:

def force_no_init(self):
    for c in [ c for c in self.constructors() if not
c.is_copy_constructor ]:
        self.remove_declaration( c )

--- Kevin

[pygccxml-development] Adding properties

[Kevin B. <kev...@gm...>]

Is there a proper way to declare properties in Py++? I've looked around 
but can't find anything apparent. The only way I can see is something like:

 Foo.add_code('add_property("Value", &Foo::getValue)')

Thanks,

--- Kevin

Re: [pygccxml-development] Force bp::no_init

[Kevin B. <kev...@gm...>]

Roman Yakovenko wrote:
> Foo = mbuilder.class_( "Foo" )
> constructors = Foo.constructors()
> for c in constructors:
>     if not c.is_copy_constructor:
>         Foo.remove_declaration( c )
>   
Thanks, that does work.

Here is the class function I refactored it into:

def force_no_init(self):
    for c in [ c for c in self.constructors() if not 
c.is_copy_constructor ]:
        self.remove_declaration( c )

--- Kevin

Re: [pygccxml-development] [pygccxml-commit] SF.net SVN: pygccxml: [570] pyplusplus_dev/pyplusplus

[Matthias B. <ba...@ir...>]

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 -

Re: [pygccxml-development] [pygccxml-commit] SF.net SVN: pygccxml: [570] pyplusplus_dev/pyplusplus

[Roman Y. <rom...@gm...>]

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/

Re: [pygccxml-development] [pygccxml-commit] SF.net SVN: pygccxml: [570] pyplusplus_dev/pyplusplus

[Matthias B. <ba...@ir...>]

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 -

Re: [pygccxml-development] [FT] recent changes - generated code

[Roman Y. <rom...@gm...>]

On 9/21/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > 1. Boost.Python object.hpp defines "len" function.
> >     This will impove next code:
> >
> >         if (v.attr("__len__")()!=3)
>
> Can you point me to the documentation of this function? At least in
> v1.33.1 it's not a member function of the object class. The following
> didn't work:
>
>           if (v.len()!=3)

boost::python::len, it it defined in boost/python/object.hpp

> > I know we are talking about code generator, but may be we can introduce few
> > convinience functions?
> >
> > namespace pyplusplus{ namespace convinience{
> > void raise_error( exception, message ){
> >     PyErr_SetString(exception, message);
> >     boost::python::throw_error_already_set();
> > }
> > } }
>
> What shall I call the file in the code repository? convenience.py?

I think yes. Although you can suggest another name

> > It is obvious to me that we have to have hear "ensure_sequence" function
> >
> > template< class ItemType=any >
> > void ensure_sequence( PyObject* x, Py_ssize_t expected_size=-1 ) {
> >     if not sequence: raise
> >     if does not have desired length raise
> >     if items in sequence are not from desired type raise
> > }
>
> I suppose this is also a candidate for the pyplusplus::convenience
> namespace, right? Do you want me to put this into a separate file or can
> I add it to the above convenience file?

I think we can put it in the same "convinience.py" file. Also in
future we can move the
functionality in another( may be better may be more specific ) namespace/file.

> > P.S. Matthias I hope you don't mind I do the review, right?
>
> Not at all.

Cool.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] MAC OS X Support?

[Matthias B. <ba...@ir...>]

Brian OBrien wrote:
> any binaries yet?

Just out of curiosity, why does OSX require a binary? Py++ (and 
pygccxml) are pure Python packages, so couldn't you just install them 
with "python setup.py install"?

- Matthias -

Re: [pygccxml-development] [FT] recent changes - generated code

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
> 1. Boost.Python object.hpp defines "len" function.
>     This will impove next code:
> 
>         if (v.attr("__len__")()!=3)

Can you point me to the documentation of this function? At least in 
v1.33.1 it's not a member function of the object class. The following 
didn't work:

          if (v.len()!=3)

> I know we are talking about code generator, but may be we can introduce few
> convinience functions?
> 
> namespace pyplusplus{ namespace convinience{
> void raise_error( exception, message ){
>     PyErr_SetString(exception, message);
>     boost::python::throw_error_already_set();
> }
> } }

What shall I call the file in the code repository? convenience.py?

> It is obvious to me that we have to have hear "ensure_sequence" function
> 
> template< class ItemType=any >
> void ensure_sequence( PyObject* x, Py_ssize_t expected_size=-1 ) {
>     if not sequence: raise
>     if does not have desired length raise
>     if items in sequence are not from desired type raise
> }

I suppose this is also a candidate for the pyplusplus::convenience 
namespace, right? Do you want me to put this into a separate file or can 
I add it to the above convenience file?

> P.S. Matthias I hope you don't mind I do the review, right?

Not at all.


- Matthias -

Re: [pygccxml-development] [FT] recent changes

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
> 1. rename gil_state_t to gil_controller_t

Done (I renamed it to gil_guard_t as was suggested and approved in 
another mail).

> 2. to put gil_controller_t under pyplusplus::threading namespace
>     pyplusplus is top level namespace, like boost. Every functionality should
>     belong to it's own namespace.

Done.

> 3. creator_t:
>     self.__extmodule.adopt_creator( code_creators.include_t(
> code_repository.gil_state.file_name )
>                                                          ,
> self.__extmodule.first_include_index() + 1)
>     Is there is a reason why do you want to put your file to be the second one?
>     If not, I think you can swith to module_t.adopt_include method

I was just copying this line from another place in Py++, I don't need it 
it at the second position. I noticed that there is even an add_include() 
method which is what I'm using now.

- Matthias -

Re: [pygccxml-development] [FT] recent changes

[Matthias B. <ba...@ir...>]

Allen Bierbaum wrote:
> Roman Yakovenko wrote:
> 
>> Hi. Few comments on committed code:
>>
>> 1. rename gil_state_t to gil_controller_t
>>    In my opinion it is better describes what we are doing
>>  
>>
> Technically the pattern it implements is a guard, so I would suggest 
> gil_guard_t if it was to be renamed.

I was calling it gil_state_t because it wraps the PyGILState_STATE type 
but gil_guard_t is fine with me as well. I've just committed the 
modification.

- Matthias -

Re: [pygccxml-development] MAC OS X Support?

[Roman Y. <rom...@gm...>]

On 9/21/06, Brian OBrien <bob...@ya...> wrote:
> any binaries yet?

Unfortunately not. I don't have access to the platform.


-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] Force bp::no_init

[Roman Y. <rom...@gm...>]

On 9/20/06, Kevin Bluck <tec...@ne...> wrote:
> Is there some way to force a class_ to be instantiated with bp::no_init,
> as in:
>
> bp::class_<Foo>("Foo", bp::no_init)
>
> I have a class that should not be constructible in Python, but instead
> only available via a factory function. The matching C++ class does have
> a public default constructor and is not abstract. It's a third-party
> library so I can't change the declaration.
>
> I couldn't find any apparent decoration method to do this. I tried
> explicitly ignoring the default constructor but that didn't work either.
>

You are not the first person who ask this question. I will add control
to the Py++ over this
functionality. Now possible solution:

mbuilder = module_builder_t( ..., optimize_queries=True, .... )
#execute next code before any other statement.
#this is needed because you modify declarations tree.
#You can not change source code, but you do can change what Py++ sees
Foo = mbuilder.class_( "Foo" )
constructors = Foo.constructors()
for c in constructors:
    if not c.is_copy_constructor:
        Foo.remove_declaration( c )

mbuilder.run_query_optimizer()

This should help. If not, comeback and I will add "no_init"
functionality to the class.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[pygccxml-development] MAC OS X Support?

[Brian O. <bob...@ya...>]

any binaries yet?


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[pygccxml-development] Force bp::no_init

[Kevin B. <tec...@ne...>]

Is there some way to force a class_ to be instantiated with bp::no_init, 
as in:

bp::class_<Foo>("Foo", bp::no_init)

I have a class that should not be constructible in Python, but instead 
only available via a factory function. The matching C++ class does have 
a public default constructor and is not abstract. It's a third-party 
library so I can't change the declaration.

I couldn't find any apparent decoration method to do this. I tried 
explicitly ignoring the default constructor but that didn't work either.

Thanks,

--- Kevin

[pygccxml-development] [FT] recent changes - generated code

[Roman Y. <rom...@gm...>]

Hi. Few comments on generated code:

1. Boost.Python object.hpp defines "len" function.
    This will impove next code:

        if (v.attr("__len__")()!=3)
        {
          PyErr_SetString(PyExc_ValueError, "Invalid sequence size
(expected 3)");
          boost::python::throw_error_already_set();
        }

2. The next pattern is comming all the time:

    if( not condition ){
        set python error
        throw boost::python exception
    }

I know we are talking about code generator, but may be we can introduce few
convinience functions?

namespace pyplusplus{ namespace convinience{
void raise_error( exception, message ){
    PyErr_SetString(exception, message);
    boost::python::throw_error_already_set();
}
} }


3.

py_v = pyresult;
          if (!PySequence_Check(py_v.ptr()))
          {
            PyErr_SetString(PyExc_ValueError, "fixed_output_array:
sequence expected as return value for output array 'v'");
            boost::python::throw_error_already_set();
          }
          // Assert that the sequence has the correct size
          if (PySequence_Length(py_v.ptr())!=3)
          {
            PyErr_SetString(PyExc_ValueError, "fixed_output_array:
sequence with 3 values expected as return value for output array
'v'");
            boost::python::throw_error_already_set();
          }

It is obvious to me that we have to have hear "ensure_sequence" function

template< class ItemType=any >
void ensure_sequence( PyObject* x, Py_ssize_t expected_size=-1 ) {
    if not sequence: raise
    if does not have desired length raise
    if items in sequence are not from desired type raise
}

Something like this.

I would like to see these changes. The generated code should not be
too different
from the one, that human would write. I don't write code like this.

P.S. Matthias I hope you don't mind I do the review, right?
-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] [FT] recent changes

[Roman Y. <rom...@gm...>]

On 9/20/06, Allen Bierbaum <al...@vr...> wrote:
> Roman Yakovenko wrote:
>
> >Hi. Few comments on committed code:
> >
> >1. rename gil_state_t to gil_controller_t
> >    In my opinion it is better describes what we are doing
> >
> >
> Technically the pattern it implements is a guard, so I would suggest
> gil_guard_t if it was to be renamed.

Another valid option :-)

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Re: [pygccxml-development] [FT] recent changes

[Allen B. <al...@vr...>]

Roman Yakovenko wrote:

>Hi. Few comments on committed code:
>
>1. rename gil_state_t to gil_controller_t
>    In my opinion it is better describes what we are doing
>  
>
Technically the pattern it implements is a guard, so I would suggest 
gil_guard_t if it was to be renamed.

-Allen

>2. to put gil_controller_t under pyplusplus::threading namespace
>    pyplusplus is top level namespace, like boost. Every functionality should
>    belong to it's own namespace.
>
>3. creator_t:
>    self.__extmodule.adopt_creator( code_creators.include_t(
>code_repository.gil_state.file_name )
>                                                         ,
>self.__extmodule.first_include_index() + 1)
>    Is there is a reason why do you want to put your file to be the second one?
>    If not, I think you can swith to module_t.adopt_include method
>
>
>  
>

Re: [pygccxml-development] [FT] recent changes

[Roman Y. <rom...@gm...>]

On 9/20/06, Roman Yakovenko <rom...@gm...> wrote:

Sorry I push wrong button to earlier

I'd like to say that I propose next changes:

> Hi. Few comments on committed code:
>
> 1. rename gil_state_t to gil_controller_t
>     In my opinion it is better describes what we are doing

I propose to rename ..., to put ...

> 2. to put gil_controller_t under pyplusplus::threading namespace
>     pyplusplus is top level namespace, like boost. Every functionality should
>     belong to it's own namespace.
>
> 3. creator_t:
>     self.__extmodule.adopt_creator( code_creators.include_t(
> code_repository.gil_state.file_name )
>                                                          ,
> self.__extmodule.first_include_index() + 1)
>     Is there is a reason why do you want to put your file to be the second one?
>     If not, I think you can swith to module_t.adopt_include method
>
>
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
>


-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/