pygccxml-development

Re: [pygccxml-development] Future of pypp_api...

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

Roman Yakovenko wrote:

> On 8/19/06, Allen Bierbaum <al...@vr...> wrote:
>
>> What are the future plans of the pypp_api?
>>
>> I am in a very frustrating position because I am very happy with the
>> capabilities and code generation abilities of pyplusplus, I have ported
>> all my projects over to using it and am actively promoting it to
>> others.  But I am not at all happy with the pyplusplus builder
>> interface.  I have become frustrated enough with the pyplusplus builder
>> API that I am starting to port my generation scripts over to using the
>> pypp_api.  This API is definitely designed to be much more of a user API
>> that just allows people to get work done.  I would highly suggest that
>> anyone that wants to use pyplusplus to create bindings should be using
>> this API.  It is simple and direct.  I am willing and interested in
>> contributing more to it, but first I wanted to make sure it is going to
>> continue to exist.
>
>
> 1. It is an open source project with very open license

Agreed.  This isn't an issue though.  The question comes down to one of 
will people be using and supporting the pypp_api or are the module 
builder interface and the classes of pyplusplus going to be promoted as 
the user-level API.

>
> 2. I would like to get a list what you think is really bad in current
> API and what
>    is really good with pypp_api.

We have discussed it before, but the goals for pypp_api really sum it up 
well for me. 

https://realityforge.vrsource.org/view/PyppApi/PyppGoals

As you have said, your vision for pyplusplus is to be an API for writing 
code generators.  That is a fine goal, but what I want to use and what I 
want to provide for users is a domain specific language that makes it 
easy to create bindings.

>> I have already run into
>> cases where changes to pyplusplus have broken my generation scripts and
>> that is when I was using the pyplusplus builder API.
>
>
> In most case, when I break API I have good reason. What is your case,
> may be this
> is a bug?

I don't think it is a bug, it is just a changing API.

-Allen

Re: [pygccxml-development] Future of pypp_api...

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

On 8/19/06, Allen Bierbaum <al...@vr...> wrote:
> What are the future plans of the pypp_api?
>
> I am in a very frustrating position because I am very happy with the
> capabilities and code generation abilities of pyplusplus, I have ported
> all my projects over to using it and am actively promoting it to
> others.  But I am not at all happy with the pyplusplus builder
> interface.  I have become frustrated enough with the pyplusplus builder
> API that I am starting to port my generation scripts over to using the
> pypp_api.  This API is definitely designed to be much more of a user API
> that just allows people to get work done.  I would highly suggest that
> anyone that wants to use pyplusplus to create bindings should be using
> this API.  It is simple and direct.  I am willing and interested in
> contributing more to it, but first I wanted to make sure it is going to
> continue to exist.

1. It is an open source project with very open license

2. I would like to get a list what you think is really bad in current
API and what
    is really good with pypp_api.

> I have already run into
> cases where changes to pyplusplus have broken my generation scripts and
> that is when I was using the pyplusplus builder API.

In most case, when I break API I have good reason. What is your case,
may be this
is a bug?

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

[pygccxml-development] Future of pypp_api...

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

What are the future plans of the pypp_api?

I am in a very frustrating position because I am very happy with the 
capabilities and code generation abilities of pyplusplus, I have ported 
all my projects over to using it and am actively promoting it to 
others.  But I am not at all happy with the pyplusplus builder 
interface.  I have become frustrated enough with the pyplusplus builder 
API that I am starting to port my generation scripts over to using the 
pypp_api.  This API is definitely designed to be much more of a user API 
that just allows people to get work done.  I would highly suggest that 
anyone that wants to use pyplusplus to create bindings should be using 
this API.  It is simple and direct.  I am willing and interested in 
contributing more to it, but first I wanted to make sure it is going to 
continue to exist.

Matthias:  Do you think development will continue on this API or do you 
only need it for a single project?

Roman: Will you ever move over to using this API or recommending it as 
the user-level API that people should use?   If you don't, then I am not 
sure how much use this wonderful API will ever get.

The short of it is: Will this API continue to be supported and 
maintained as pyplusplus continues to evolve?  I have already run into 
cases where changes to pyplusplus have broken my generation scripts and 
that is when I was using the pyplusplus builder API.  Is this just going 
to get worse if I use pypp_api?

-Allen

Re: [pygccxml-development] EOL policy

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

Roman Yakovenko wrote:
>> Just use subversion and set the svn:eol-style.  I would suggest setting
>> it to "native" so files will be treated natively on any platform.  In my
>> experience this works very well for cross-platform development.
> 
> Where I do that?

It's a property like svn:ignore. See here:

http://svnbook.red-bean.com/en/1.2/svn.advanced.props.html#svn.advanced.props.special.eol-style

The annoying thing is that this property has to be set on each file 
individually. So for the already existing files this has to be done with 
the propset command and for new files you can configure svn so that it 
does this automatically based on the file suffix. See here:

http://svnbook.red-bean.com/en/1.2/svn.advanced.props.html#svn.advanced.props.auto

- Matthias -

Re: [pygccxml-development] EOL policy

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

On 8/16/06, Allen Bierbaum <al...@vr...> wrote:
> Roman Yakovenko wrote:
>
> >Hi. I would like to introduce next policy: all end of lines in files
> >should be CRLF.
> >Linux editors handle well these case, while the opposite, Windows LF,
> >is not true.
> >
> >It could be nice, if we can make this policy to work automatically, like in CVS.
> >( When you commit\\update to\\from repository it will convert the eol characters
> >  to the system default. )
> >
> >Thoughts?
> >
> >
> >
> Just use subversion and set the svn:eol-style.  I would suggest setting
> it to "native" so files will be treated natively on any platform.  In my
> experience this works very well for cross-platform development.

Where I do that?

> -Allen
>


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

Re: [pygccxml-development] EOL policy

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

Roman Yakovenko wrote:

>Hi. I would like to introduce next policy: all end of lines in files
>should be CRLF.
>Linux editors handle well these case, while the opposite, Windows LF,
>is not true.
>
>It could be nice, if we can make this policy to work automatically, like in CVS.
>( When you commit\\update to\\from repository it will convert the eol characters
>  to the system default. )
>
>Thoughts?
>
>  
>
Just use subversion and set the svn:eol-style.  I would suggest setting 
it to "native" so files will be treated natively on any platform.  In my 
experience this works very well for cross-platform development.

-Allen

[pygccxml-development] EOL policy

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

Hi. I would like to introduce next policy: all end of lines in files
should be CRLF.
Linux editors handle well these case, while the opposite, Windows LF,
is not true.

It could be nice, if we can make this policy to work automatically, like in CVS.
( When you commit\\update to\\from repository it will convert the eol characters
  to the system default. )

Thoughts?

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

Re: [pygccxml-development] Doc strings in multiple_files_t

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

On 8/15/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> I just noticed that the interface of the multiple_files_t class has
> slightly changed and the "write_main" parameter was moved from write()
> to the constructor. Unfortunately, the doc strings (and the comment
> right before write()) haven't been updated. So this is just a plea to
> Roman: Whenever you do a modification to the code, can you please also
> have a look at the doc strings and update them accordingly so that they
> don't get "out of sync" with the implementation? I would really
> appreciate this. :)

Sorry, you are right. For my excuse I can say, that I run pychecker on the code,
so I forgot to update it.

Also I am going to review docs strings in the whole project.

I will fix the bug this evening

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

[pygccxml-development] Doc strings in multiple_files_t

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

Hi,

I just noticed that the interface of the multiple_files_t class has 
slightly changed and the "write_main" parameter was moved from write() 
to the constructor. Unfortunately, the doc strings (and the comment 
right before write()) haven't been updated. So this is just a plea to 
Roman: Whenever you do a modification to the code, can you please also 
have a look at the doc strings and update them accordingly so that they 
don't get "out of sync" with the implementation? I would really 
appreciate this. :)

- Matthias -

Re: [pygccxml-development] [important]rename pyplusplus

[Lakin W. <lak...@gm...>]

I am not very picky.  I will use whichever you choose.  py++ is the
first on my list.  I don't think we should worry too much about case.

Lakin

On 8/13/06, Roman Yakovenko <rom...@gm...> wrote:
> Hi. This is really important to me.
> A lot of people when start to use pyplusplus, decide to give it a name:
>
> PyPlus
> PyPlusPlus
> pypp
> py++( I am )
> Py++
>
> I'd like to fix the situation. I prefer to change name from pyplusplus to Py++.
>
> I would like to get your opinion.
>
> Thank you.
>
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> pygccxml-development mailing list
> pyg...@li...
> https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>

[pygccxml-development] [important]rename pyplusplus

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

Hi. This is really important to me.
A lot of people when start to use pyplusplus, decide to give it a name:

PyPlus
PyPlusPlus
pypp
py++( I am )
Py++

I'd like to fix the situation. I prefer to change name from pyplusplus to Py++.

I would like to get your opinion.

Thank you.

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

Re: [pygccxml-development] Code inserters/Arg policies

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

On 8/9/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> >> I have added a section "Summary" that contains the full code for option
> >> 3 with additional comments:
> >>
> >> https://realityforge.vrsource.org/view/PyppApi/CodeInserter#Summary
> >>
> >> I have also slightly modified the code from option 3 so that now the
> >> default_spam() method looks the same as in the initial version (i.e. it
> >> doesn't need any code modifiers).
> >
> > Two comments:
> > 1.  May be I missed something, but it seems to me that registration
> > should also
> >   contain Viking_Wrapper::spam, am I right?
>
> Well, no. Or let's rather say, yes, it should, but it doesn't work. When
> I changed the signature of default_spam() on the original code generated
> by py++ I got compile errors. This was the reason why I started
> investigating other options.
>
> Actually, I haven't found any documentation about this special version
> of the def() function in the Boost.Python reference manual (it's only
> mentioned in the tutorial), so I don't know the requirements on the two
> function references (but it seems that they must have the same
> signature). And I also have to confess that I don't fully understand how
> it works and what it actually does....

I see. We will have to get support from boost.python developers.

> > Sorry I was not clear, multiple inheritance in C++. py++ creates wrapper
> > class
> > for every class in the hierarchy. I am sure this will work. But still,
> > I think it is worse to add such test case.
>
> You mean a C++ class Norwegian that is derived from Viking and that is
> exposed to Python and that has to pass all the tests that Viking had to
> pass, right?

Yes.

> >> I think that should still be the decoration interface as already
> >> mentioned here:
> >> https://realityforge.vrsource.org/view/PyppApi/CodeInserter#Decoration
> >
> > I see. What should be done with wrappers py++ generates?
>
> Eventually, I hope that those wrappers are generated by py++ (and not by
> the high level API) so that there will never be two conflicting wrappers.
>
> > Do you wan to define
> > "default policies" ? "Default policies" does not have to be a class,
> > it could be just a terminology.
>
> Well, if a function only has the "default policies" (=lack of any "code
> modifiers") it just means that there will be no additional code inside
> the wrappers that transforms arguments. But a user doesn't have to
> specify that explicitly, so I'm afraid I don't exactly understand where
> we need to define any "default policies"...?

You just defined them. Also as I said, "default policies" is not a
class, but rather a
behaviour of py++, in case user did not set policies.

>
> Couldn't this lead to confusion because people might mix it up with
> "call policies"?

I forgot about it. May we think about "call policies" as another policy?

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

Re: [pygccxml-development] Code inserters/Arg policies

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

Roman Yakovenko wrote:
>> I have added a section "Summary" that contains the full code for option
>> 3 with additional comments:
>>
>> https://realityforge.vrsource.org/view/PyppApi/CodeInserter#Summary
>>
>> I have also slightly modified the code from option 3 so that now the
>> default_spam() method looks the same as in the initial version (i.e. it
>> doesn't need any code modifiers).
> 
> Two comments:
> 1.  May be I missed something, but it seems to me that registration 
> should also
>   contain Viking_Wrapper::spam, am I right?

Well, no. Or let's rather say, yes, it should, but it doesn't work. When 
I changed the signature of default_spam() on the original code generated 
by py++ I got compile errors. This was the reason why I started 
investigating other options.

Actually, I haven't found any documentation about this special version 
of the def() function in the Boost.Python reference manual (it's only 
mentioned in the tutorial), so I don't know the requirements on the two 
function references (but it seems that they must have the same 
signature). And I also have to confess that I don't fully understand how 
it works and what it actually does....

> 2. In C++ arguments by reference used as: in, out, in and out. May be
>   func_spam callable should take int and return int.

Oh, sorry, I didn't mention it but I was assuming the argument of the 
spam() function is an output argument. But you're right, if it was in or 
in/out, the actual code would have to look slightly different.

> Sorry I was not clear, multiple inheritance in C++. py++ creates wrapper 
> class
> for every class in the hierarchy. I am sure this will work. But still,
> I think it is worse to add such test case.

You mean a C++ class Norwegian that is derived from Viking and that is 
exposed to Python and that has to pass all the tests that Viking had to 
pass, right?

>> I think that should still be the decoration interface as already
>> mentioned here:
>> https://realityforge.vrsource.org/view/PyppApi/CodeInserter#Decoration
> 
> I see. What should be done with wrappers py++ generates? 

Eventually, I hope that those wrappers are generated by py++ (and not by 
the high level API) so that there will never be two conflicting wrappers.

> Do you wan to define
> "default policies" ? "Default policies" does not have to be a class,
> it could be just a terminology.

Well, if a function only has the "default policies" (=lack of any "code 
modifiers") it just means that there will be no additional code inside 
the wrappers that transforms arguments. But a user doesn't have to 
specify that explicitly, so I'm afraid I don't exactly understand where 
we need to define any "default policies"...?

>> That is, there should be at least one decoration operation that allows
>> me to attach "code modifier" objects to one particular function.
>> At this level the user doesn't even have to know about the problem with
>> non-pure virtual functions, it just works the same as with non-virtual
>> functions. Knowing about the details is only necessary when you want to
>> write your own "code modifiers".
> 
> I agree with the solution, but we will have to find better name. May
> be "policies" will be good enough?

Couldn't this lead to confusion because people might mix it up with 
"call policies"?

- Matthias -

Re: [pygccxml-development] Code inserters/Arg policies

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

On 8/8/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > One question: it is not clear how is registration will look like?
>
> I have added a section "Summary" that contains the full code for option
> 3 with additional comments:
>
> https://realityforge.vrsource.org/view/PyppApi/CodeInserter#Summary
>
> I have also slightly modified the code from option 3 so that now the
> default_spam() method looks the same as in the initial version (i.e. it
> doesn't need any code modifiers).

Two comments:
1.  May be I missed something, but it seems to me that registration should also
   contain Viking_Wrapper::spam, am I right?

2. In C++ arguments by reference used as: in, out, in and out. May be
   func_spam callable should take int and return int.

> > There is one more test I'd like to see: multiple inheritance.
>
> Could you please provide more details about that? Multiple inheritance
> in C++ or in Python? Who is deriving from who? And on what instance
> should the method call be made?

Sorry I was not clear, multiple inheritance in C++. py++ creates wrapper class
for every class in the hierarchy. I am sure this will work. But still,
I think it
is worse to add such test case.

>
> > mb = module_builder_t( ... )
> >
> > spam = mb.member_function( '::Viking::spam' )
> > spam.what I should write here in order to get the desired effect
>
> I think that should still be the decoration interface as already
> mentioned here:
> https://realityforge.vrsource.org/view/PyppApi/CodeInserter#Decoration

I see. What should be done with wrappers py++ generates? Do you wan to define
"default policies" ? "Default policies" does not have to be a class,
it could be just
a terminology.

> That is, there should be at least one decoration operation that allows
> me to attach "code modifier" objects to one particular function.
> At this level the user doesn't even have to know about the problem with
> non-pure virtual functions, it just works the same as with non-virtual
> functions. Knowing about the details is only necessary when you want to
> write your own "code modifiers".

I agree with the solution, but we will have to find better name. May
be "policies"
will be good enough?

> > Did you use ctypes package? If not, try to find time and to read about it
> > ( http://starship.python.net/crew/theller/ctypes/ ). I think about
> > introducing
> > fundamental data types to boost.python library or to pyplusplus and
> > teaching py++ to generate Python code.
>
> With Python 2.5 ctypes will be part of the standard Python library, so
> at least it might be worth investigating if we could re-use some code
> here. But to be able to comment on it I would need to know more details
> about what you're planning on doing...

Actually I thought about extending boost.python library with classes that have
interface similar to "fundamental types" in ctypes:

For example:

struct native_int{
    explicit native_int( int v ) : value( v ){}

   int& get_ref(){ return value; }

   const int& get_ref() const { return value; }

   int get_value(){ return value; }

private:
    int value;
};

C++:

void spam( int & ) - will be exported as is

>From Python:
import my_module
i = my_module.native_types.native_int( 23 )
my_module.spam( i )
print i.value

In my opinion, boost.python should understand that user passes native_int
and to generate an appropriate call.

If I understand right the implementation of ctypes, it works directly with
the C stack, we can do the same thing in C++.


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

Re: [pygccxml-development] Code inserters/Arg policies

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

Roman Yakovenko wrote:
> One question: it is not clear how is registration will look like?

I have added a section "Summary" that contains the full code for option 
3 with additional comments:

https://realityforge.vrsource.org/view/PyppApi/CodeInserter#Summary

I have also slightly modified the code from option 3 so that now the 
default_spam() method looks the same as in the initial version (i.e. it 
doesn't need any code modifiers).

>> Are there any use-cases I have forgotten? Are there
>> > other options how this could be implemented?
> 
> There is one more test I'd like to see: multiple inheritance.

Could you please provide more details about that? Multiple inheritance 
in C++ or in Python? Who is deriving from who? And on what instance 
should the method call be made?

> Also, it could be nice to see, how this policy plays well with other.
> For example, return status as exception.

Right, that's one of the next steps to examine at which places such 
policies need to add their own code. The above summary is supposed to 
help out with that.

> mb = module_builder_t( ... )
> 
> spam = mb.member_function( '::Viking::spam' )
> spam.what I should write here in order to get the desired effect

I think that should still be the decoration interface as already 
mentioned here:
https://realityforge.vrsource.org/view/PyppApi/CodeInserter#Decoration

That is, there should be at least one decoration operation that allows 
me to attach "code modifier" objects to one particular function.
At this level the user doesn't even have to know about the problem with 
non-pure virtual functions, it just works the same as with non-virtual 
functions. Knowing about the details is only necessary when you want to 
write your own "code modifiers".

> Did you use ctypes package? If not, try to find time and to read about it
> ( http://starship.python.net/crew/theller/ctypes/ ). I think about 
> introducing
> fundamental data types to boost.python library or to pyplusplus and
> teaching py++ to generate Python code.

With Python 2.5 ctypes will be part of the standard Python library, so 
at least it might be worth investigating if we could re-use some code 
here. But to be able to comment on it I would need to know more details 
about what you're planning on doing...

- Matthias -

Re: [pygccxml-development] Code inserters/Arg policies

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

On 8/6/06, Roman Yakovenko <rom...@gm...> wrote:
> On 8/6/06, Matthias Baas <ba...@ir...> wrote:
> > Hi,
> >
> > I've just updated the "Code inserters" page in the wiki and added a
> > section about non-pure virtual member functions:
> >
> > https://realityforge.vrsource.org/view/PyppApi/CodeInserter#Non_pure_virtual_member_function
> >
> > The new section examines how the Boost.Python code would have to look
> > like to be able to wrap non-pure virtual functions that have a signature
> > that is not compatible with Python.
> >
> > Any comments so far?

I like very much the way you did it.
One question: it is not clear how is registration will look like?

> Are there any use-cases I have forgotten? Are there
> > other options how this could be implemented?

There is one more test I'd like to see: multiple inheritance.

Also, it could be nice to see, how this policy plays well with other.
For example,
return status as exception.

> > The next question (which the text does not deal with yet) is how to
> > accomplish this using pyplusplus. The current proposal of a "code
> > inserter" API is not able to deal with such things yet (not even with
> > pure virtual functions), so this API still needs modifications.

I think it is too early to discuss implementation details. In my
opinion the document
you wrote is missing one section: usage example.

mb = module_builder_t( ... )

spam = mb.member_function( '::Viking::spam' )
spam.what I should write here in order to get the desired effect

May be the right question to ask: what user interface decl_wrapper
should provide?

> > Another question is whether pyplusplus should always create the code
> > from option 3 or if the user should be able to specify that some
> > use-cases are not important and it is ok that pyplusplus creates the
> > simpler code. (So far I would tend to use option 3 in all cases as it is
> > the most general option and I don't think it has a noticeable
> > performance penalty).

This is an experimental feature. In my opinion first we should see how
well it works
and only then to make it more customizable. So, I agree with you.

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

Re: [pygccxml-development] Wiki is up

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

On 8/6/06, Allen Bierbaum <al...@vr...> wrote:
> I updated the footer for all pages to include a reference to this
> license. Please see the footer on the page at:
> https://realityforge.vrsource.org/view/PyppApi/WebHome
>
> Will this work for your needs?

Yes. Thank you very much.


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

Re: [pygccxml-development] Wiki is up

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

Roman Yakovenko wrote:

> On 8/5/06, Allen Bierbaum <al...@vr...> wrote:
>
>> I can add something to the wiki to this effect.  Could you provide me
>> with the text you would like to see?
>
>
> http://boost.org/more/license_info.html
>
> Thanks
>
I updated the footer for all pages to include a reference to this 
license. Please see the footer on the page at: 
https://realityforge.vrsource.org/view/PyppApi/WebHome

Will this work for your needs?

-Allen

Re: [pygccxml-development] Wiki is up

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

Roman Yakovenko wrote:

> On 8/5/06, Allen Bierbaum <al...@vr...> wrote:
>
>> Roman Yakovenko wrote:
>>
>> > On 8/1/06, Allen Bierbaum <al...@vr...> wrote:
>> >
>> >> I just put up a wiki for discussing, documenting, and developing
>> >> pyplusplus and the pypp high-level API.
>> >>
>> >> You can find the page here: https://realityforge.vrsource.org/PyPP
>> >>
>> >> Please let me know if you have any problems.  Also, if anyone has
>> >> artistic skills, I would love to get a nice logo for pypp to put 
>> on this
>> >> page.
>> >
>> >
>> > There is small problem with the project name: pypp.
>> > The original project name is py++. The problem with it, is that it is
>> > not valid Python
>> > identifier. So you can not create package with that name. So I
>> > switched to pyplusplus.
>> > I think you can use one of the forms, but please don't introduce the
>> > 3rd one.
>>
>> I choose the name PyPP for two reasons.
>>
>> 1) I named the wiki based on the name of the pypp_api because I envision
>> this wiki primarily as a place to discuss and document the pypp_api.
>> Sort of a homepage for the high-level API.  It will also be able to
>> support discussion of issues about pyplusplus but I didn't want to
>> confuse people and make them think this may be the homepage for 
>> pyplusplus.
>>
>> 2) I wanted something very short since it will show up in the URL and a
>> number of places on the wiki itself.
>>
>> If people on the list have a better suggestion I am more than willing to
>> consider it.  However, for the reasons above, I would not like to use
>> "pyplusplus" as the name.
>
>
> pypp_api will be good enough.


The wiki path has now changed to:

https://realityforge.vrsource.org/PyppApi

Please let me know if you run into any issues.

-Allen

Re: [pygccxml-development] Code inserters/Arg policies

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

On 8/6/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> I've just updated the "Code inserters" page in the wiki and added a
> section about non-pure virtual member functions:
>
> https://realityforge.vrsource.org/view/PyPP/CodeInserter#Non_pure_virtual_member_function
>
> The new section examines how the Boost.Python code would have to look
> like to be able to wrap non-pure virtual functions that have a signature
> that is not compatible with Python.
>
> Any comments so far? Are there any use-cases I have forgotten? Are there
> other options how this could be implemented?
>
> The next question (which the text does not deal with yet) is how to
> accomplish this using pyplusplus. The current proposal of a "code
> inserter" API is not able to deal with such things yet (not even with
> pure virtual functions), so this API still needs modifications.
> Another question is whether pyplusplus should always create the code
> from option 3 or if the user should be able to specify that some
> use-cases are not important and it is ok that pyplusplus creates the
> simpler code. (So far I would tend to use option 3 in all cases as it is
> the most general option and I don't think it has a noticeable
> performance penalty).

I will comment your ideas later. Just wanted to drop another idea to
the existing ones:
Did you use ctypes package? If not, try to find time and to read about it
( http://starship.python.net/crew/theller/ctypes/ ). I think about introducing
fundamental data types to boost.python library or to pyplusplus and
teaching py++ to generate Python code.

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

[pygccxml-development] Code inserters/Arg policies

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

Hi,

I've just updated the "Code inserters" page in the wiki and added a 
section about non-pure virtual member functions:

https://realityforge.vrsource.org/view/PyPP/CodeInserter#Non_pure_virtual_member_function

The new section examines how the Boost.Python code would have to look 
like to be able to wrap non-pure virtual functions that have a signature 
that is not compatible with Python.

Any comments so far? Are there any use-cases I have forgotten? Are there 
other options how this could be implemented?

The next question (which the text does not deal with yet) is how to 
accomplish this using pyplusplus. The current proposal of a "code 
inserter" API is not able to deal with such things yet (not even with 
pure virtual functions), so this API still needs modifications.
Another question is whether pyplusplus should always create the code 
from option 3 or if the user should be able to specify that some 
use-cases are not important and it is ok that pyplusplus creates the 
simpler code. (So far I would tend to use option 3 in all cases as it is 
the most general option and I don't think it has a noticeable 
performance penalty).

- Matthias-

Re: [pygccxml-development] Wiki is up

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

On 8/5/06, Allen Bierbaum <al...@vr...> wrote:

> I can add something to the wiki to this effect.  Could you provide me
> with the text you would like to see?

http://boost.org/more/license_info.html

Thanks

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

Re: [pygccxml-development] Wiki is up

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

On 8/5/06, Allen Bierbaum <al...@vr...> wrote:
> Roman Yakovenko wrote:
>
> > On 8/1/06, Allen Bierbaum <al...@vr...> wrote:
> >
> >> I just put up a wiki for discussing, documenting, and developing
> >> pyplusplus and the pypp high-level API.
> >>
> >> You can find the page here: https://realityforge.vrsource.org/PyPP
> >>
> >> Please let me know if you have any problems.  Also, if anyone has
> >> artistic skills, I would love to get a nice logo for pypp to put on this
> >> page.
> >
> >
> > There is small problem with the project name: pypp.
> > The original project name is py++. The problem with it, is that it is
> > not valid Python
> > identifier. So you can not create package with that name. So I
> > switched to pyplusplus.
> > I think you can use one of the forms, but please don't introduce the
> > 3rd one.
>
> I choose the name PyPP for two reasons.
>
> 1) I named the wiki based on the name of the pypp_api because I envision
> this wiki primarily as a place to discuss and document the pypp_api.
> Sort of a homepage for the high-level API.  It will also be able to
> support discussion of issues about pyplusplus but I didn't want to
> confuse people and make them think this may be the homepage for pyplusplus.
>
> 2) I wanted something very short since it will show up in the URL and a
> number of places on the wiki itself.
>
> If people on the list have a better suggestion I am more than willing to
> consider it.  However, for the reasons above, I would not like to use
> "pyplusplus" as the name.

pypp_api will be good enough.

> -Allen

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

Re: [pygccxml-development] Wiki is up

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

Roman Yakovenko wrote:

> On 8/1/06, Roman Yakovenko <rom...@gm...> wrote:
>
>> On 8/1/06, Allen Bierbaum <al...@vr...> wrote:
>> > I just put up a wiki for discussing, documenting, and developing
>> > pyplusplus and the pypp high-level API.
>> >
>> > You can find the page here: https://realityforge.vrsource.org/PyPP
>> >
>> > Please let me know if you have any problems.  Also, if anyone has
>> > artistic skills, I would love to get a nice logo for pypp to put on 
>> this
>> > page.
>>
> There is another small problem. I think, we agreed that WIKI will say 
> explicitly
> that every contribution to the WIKI is done under boost software license.
> We need this, in order to allow py++ to borrow good ideas and 
> documentation
> from the WIKI.
>
I can add something to the wiki to this effect.  Could you provide me 
with the text you would like to see?

-Allen

Re: [pygccxml-development] Wiki is up

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

Roman Yakovenko wrote:

> On 8/1/06, Allen Bierbaum <al...@vr...> wrote:
>
>> I just put up a wiki for discussing, documenting, and developing
>> pyplusplus and the pypp high-level API.
>>
>> You can find the page here: https://realityforge.vrsource.org/PyPP
>>
>> Please let me know if you have any problems.  Also, if anyone has
>> artistic skills, I would love to get a nice logo for pypp to put on this
>> page.
>
>
> There is small problem with the project name: pypp.
> The original project name is py++. The problem with it, is that it is
> not valid Python
> identifier. So you can not create package with that name. So I
> switched to pyplusplus.
> I think you can use one of the forms, but please don't introduce the 
> 3rd one.

I choose the name PyPP for two reasons. 

1) I named the wiki based on the name of the pypp_api because I envision 
this wiki primarily as a place to discuss and document the pypp_api.  
Sort of a homepage for the high-level API.  It will also be able to 
support discussion of issues about pyplusplus but I didn't want to 
confuse people and make them think this may be the homepage for pyplusplus.

2) I wanted something very short since it will show up in the URL and a 
number of places on the wiki itself.

If people on the list have a better suggestion I am more than willing to 
consider it.  However, for the reasons above, I would not like to use 
"pyplusplus" as the name.

-Allen