pygccxml-development

[pygccxml-development] Another status report...

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

Hi,

unless I find some bugs I'm currently done with the selection stuff in 
the experimental folder. With the current version I can now almost 
create the same bindings as before with only slight adjustments to my 
script. By default, the selection is similar to Allen's initial version 
  but you can "activate" more flexible queries if desired to get 
something that rather resembles my initial version.
The next thing I need to get the same bindings as before is the ability 
to add custom methods, I haven't checked yet if Allen's addMethod() 
method still works or not, I'll try to do that tomorrow....

I have also done some updates in the wiki:

- There's one more goal I added and I even dared adding it to the top of 
the list as I would consider that this is the "ultimate" goal for me: 
pyplusplus  (and its API) should minimize the time it takes to create 
the final bindings for a C++ library. Do you agree on that?

- To most of the issues I added an "Experimental version" section that 
provides a short outline how the current code in the experimental folder 
handles the respective issue. Of course, as this code is still 
"experimental" this doesn't mean that this is how the issue will 
definitely be resolved, but it's rather one proposal that exists in code 
so that it can be tried out to see how well it works in practice.

- I've removed my comments from the "What operations does the selection 
interface provide?" topic as there is no general disagreement on my 
part. But I added a new "open issue" about the overloaded methods.


How should we proceed now to resolve the issues in the wiki? There still 
seems to be some disagreement, but I don't always see how an alternative 
proposal would look like. So should we schedule another chat session and 
go over those issues trying to find a resolution? Or do you already have 
some comments about my latest changes? Could you try them out? Do you 
need more documentation about the usage? Does the selection work for you 
or were you confused when you tried using it? (for me, it's still the 
overloaded methods that can lead to some "surprises")

So what are your plans for the next couple of days? What does our next 
"milestone" look like? I'd like to see the basic principles of 
selection/decoration to be resolved so that we can move on with thinking 
about features that have only been touched so far but that are not yet 
implemented at all.

- Matthias -

Re: [pygccxml-development] Another status report...

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

On 3/15/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> unless I find some bugs I'm currently done with the selection stuff in
> the experimental folder. With the current version I can now almost
> create the same bindings as before with only slight adjustments to my
> script. By default, the selection is similar to Allen's initial version
>   but you can "activate" more flexible queries if desired to get
> something that rather resembles my initial version.
> The next thing I need to get the same bindings as before is the ability
> to add custom methods, I haven't checked yet if Allen's addMethod()
> method still works or not, I'll try to do that tomorrow....

Can you work directly on decl_wrappers? Now I understand that this is a ver=
y
important future.

> I have also done some updates in the wiki:
>
> - There's one more goal I added and I even dared adding it to the top of
> the list as I would consider that this is the "ultimate" goal for me:
> pyplusplus  (and its API) should minimize the time it takes to create
> the final bindings for a C++ library. Do you agree on that?

I don't know, if we achieve all other goals this will be achieved as well.

> - To most of the issues I added an "Experimental version" section that
> provides a short outline how the current code in the experimental folder
> handles the respective issue. Of course, as this code is still
> "experimental" this doesn't mean that this is how the issue will
> definitely be resolved, but it's rather one proposal that exists in code
> so that it can be tried out to see how well it works in practice.

Good.

> - I've removed my comments from the "What operations does the selection
> interface provide?" topic as there is no general disagreement on my
> part. But I added a new "open issue" about the overloaded methods.

I will take a look, later

> How should we proceed now to resolve the issues in the wiki? There still
> seems to be some disagreement, but I don't always see how an alternative
> proposal would look like. So should we schedule another chat session and
> go over those issues trying to find a resolution? Or do you already have
> some comments about my latest changes?

Yes. I have. But I prefer to tell you good news. Almost all features
you need for Maya SDK
already in main branch. There 2 missing features:

adding code creators to decl_wrappers

resolving issue with overloaded functions

> Could you try them out?

I tried them and read your code.

> Do you need more documentation about the usage?

No

> Does the selection work for you or were you confused when you tried using=
 it?

Yes, a little. You mix 2 concepts:
1. what user is searching for
2. where it should be searched.

If you want I can explain what is wrong with it. But I really don't
want. You are doing great
job and I only tell you these or that thing is wrong. I took almost
all your ideas and
added them to main branch.

1. filters, I made for example only cosmetic changes and add more power in =
some
    places

2. select interface. it is now fully implemented.

>(for me, it's still the
> overloaded methods that can lead to some "surprises")
>
> So what are your plans for the next couple of days?

1. First of all I will port all my code to new API. This step will
find bugs and weaknesses.

>What does our next "milestone" look like?

There are few issues need to be resolved in next week or two:
1. adding code creators to decl wrappers
2. resolving function overload issues
3. fixing finalize concept.
4. add few function/properties to module builder class:
    parser configuration
    code creators ( factory ) configuration

After this point: we should stay backward compatible
( =3D=3D you can use source code from CVS in production ). It means that=20
Maya bindings should work!

After this I plan to release "technology preview" version to
boost.python community.
( Hint: this is the first time that documentation will be integrated
and release :-) )

>I'd like to see the basic principles of
> selection/decoration to be resolved so that we can move on with thinking
> about features that have only been touched so far but that are not yet
> implemented at all.

They already resolved. In order to understand how all works take a look on:
pygccxml/unittests/
    filters_tester.py
    variable_matcher_tester.py
    namespace_matcher_tester.py

pyplusplus/unittests/ relevant code in customize method:
    member_functions_tester.py
    member_variables_tester.py
    operators_tester.py
    regression2_tester.py
    recursive_tester.py

pyplusplus/examples/py_easybmp/create_easybmp.py

> - Matthias -

What do you think?

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

Re: [pygccxml-development] Another status report...

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

Matthias Baas wrote:

> Hi,
>
> unless I find some bugs I'm currently done with the selection stuff in 
> the experimental folder. With the current version I can now almost 
> create the same bindings as before with only slight adjustments to my 
> script. By default, the selection is similar to Allen's initial 
> version  but you can "activate" more flexible queries if desired to 
> get something that rather resembles my initial version.
> The next thing I need to get the same bindings as before is the 
> ability to add custom methods, I haven't checked yet if Allen's 
> addMethod() method still works or not, I'll try to do that tomorrow....
>
> I have also done some updates in the wiki:
>
> - There's one more goal I added and I even dared adding it to the top 
> of the list as I would consider that this is the "ultimate" goal for 
> me: pyplusplus  (and its API) should minimize the time it takes to 
> create the final bindings for a C++ library. Do you agree on that?

Yes, I agree with the condition that we mean minimize the time to create 
the final bindings assuming you already know something about 
boost.python and pyplusplus.  If the user doesn't know either tool yet 
then it may take a while to understand the basics.

>
> - To most of the issues I added an "Experimental version" section that 
> provides a short outline how the current code in the experimental 
> folder handles the respective issue. Of course, as this code is still 
> "experimental" this doesn't mean that this is how the issue will 
> definitely be resolved, but it's rather one proposal that exists in 
> code so that it can be tried out to see how well it works in practice.

Good idea.

>
> - I've removed my comments from the "What operations does the 
> selection interface provide?" topic as there is no general 
> disagreement on my part. But I added a new "open issue" about the 
> overloaded methods.

>
>
> How should we proceed now to resolve the issues in the wiki? There 
> still seems to be some disagreement, but I don't always see how an 
> alternative proposal would look like. So should we schedule another 
> chat session and go over those issues trying to find a resolution? Or 
> do you already have some comments about my latest changes? Could you 
> try them out? Do you need more documentation about the usage? Does the 
> selection work for you or were you confused when you tried using it? 
> (for me, it's still the overloaded methods that can lead to some 
> "surprises")

I really need to get some time to test the new interface.  I have gotten 
swamped by a couple of big projects and have not had time to devote to 
this in about a week. :(

>
> So what are your plans for the next couple of days? What does our next 
> "milestone" look like? I'd like to see the basic principles of 
> selection/decoration to be resolved so that we can move on with 
> thinking about features that have only been touched so far but that are no

I think a good milestone would be an API that would allow the 
capabilities that my original simple prototype allowed.  In other words, 
basic selection, exposing, renaming, and policy.  In a way this will 
really be the core capabilities that most users will need.

-Allen

> t yet implemented at all.
>
> - Matthias -
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> pygccxml-development mailing list
> pyg...@li...
> https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>

Re: [pygccxml-development] Another status report...

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

On 3/19/06, Allen Bierbaum <al...@vr...> wrote:
> > So what are your plans for the next couple of days? What does our next
> > "milestone" look like? I'd like to see the basic principles of
> > selection/decoration to be resolved so that we can move on with
> > thinking about features that have only been touched so far but that are=
 no
>
> I think a good milestone would be an API that would allow the
> capabilities that my original simple prototype allowed.  In other words,
> basic selection, exposing, renaming, and policy.  In a way this will
> really be the core capabilities that most users will need.

I think, that today, after I commit add_code functionality we will have it.

> -Allen
>

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