C++ Python language bindings

On 3/8/06, Matthias Baas <baas@...> wrote:
> Hi,
>
> some of the recent discussion has become somewhat "theoretical" for me
> as I'm still in a state where I cannot create my bindings. So my
> short-term goal is still to get either my own or Allen's API to a state
> where it's at least partially functional again. In my own version I
> still get that exception I once posted. After the discoveries from
> yesterday I thought the problem might be that I don't provide a
> decl_factory to create decl_wrappers and pyplusplus might depend on
> them. But when I created a factory class that returns decl_wrappers then
> even the parse() step fails with an assertion error in source_reader.py
> (btw, shouldn't such a factory object be part of pyplusplus?).
> And Allen's version still seems to rely on his patched version of
> pyplusplus.
> I'm not sure if Allen is in the same situation or not, but at least for
> me it would be great if I could somehow get any API to work with the
> current cvs version of pyplusplus again.
> Roman, can you provide a small "porting guide" and outline what has to
> be changed so that a script that was working with pyplusplus from 1 or 2
> weeks ago will work again with the current version?
> I'd like to get "back on the road" again as quickly as possible so that
> I can actually move on... ;)

I will try. Did you use directly pyplusplus API or from experimental direct=
ory?

> - Matthias -

Thanks

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

On 3/8/06, Roman Yakovenko <roman.yakovenko@...> wrote:
I will try to help you to use low level api

config =3D parser.config_t( gccxml_path=3Dgccxml_path)

reader =3D parser.project_reader_t( config, None, decl_wrappers.dwfactory_t=
() )
decls =3D reader.read_files( self.__files )
#directly customize decls, by the way decls will contains decl wrappers
#You can use your own filters with declarations.matcher class.

module_creator =3D module_creator.creator_t( decls, module_name, .... )
#directly customize module creator

use file writers

This should work well.

Did this help?
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

Roman Yakovenko wrote:
> reader = parser.project_reader_t( config, None, decl_wrappers.dwfactory_t() )

Ah! I hadn't found the dwfactory_t class. I was only searching for a 
file name with "factory" in its name, I didn't expect it to be "hidden" 
in the __init__ module... ;)
When I also used that factory class, it worked again (which is somewhat 
weird because my own factory class was almost the same, the only 
difference was that I didn't derive from decl_factory_t).

ok, at least the script runs without errors again. But I do get an error 
during compilation but that's another thing now that I first have to 
investigate...(it seems my call policies don't get assigned anymore, but 
that's ok for now).

I think now that pyplusplus relies on seeing its own declaration 
classes, it would be useful to introduce a parse() function in 
pyplusplus (which would use the dwfactory_t class as default instead of 
the factory from pygccxml). At the moment, *every* user of pyplusplus 
would have to pass dwfactory_t explicitly whereas this is rather an 
implementation detail.

- Matthias -

Roman Yakovenko wrote:
>> ok, at least the script runs without errors again. But I do get an error
>> during compilation but that's another thing now that I first have to
>> investigate...(it seems my call policies don't get assigned anymore, but
>> that's ok for now).
> 
> The only thing that I can say is that "it works fine for me". Could
> you investigate the
> problem. If this is a problem in pyplusplus you can commit the fix.

ok (but I think this could just as well be a problem in my old API which 
just has to be updated to the new version of pyplusplus. So far, I'm 
happy that I don't get an exception anymore. :)

>> I think now that pyplusplus relies on seeing its own declaration
>> classes, it would be useful to introduce a parse() function in
>> pyplusplus (which would use the dwfactory_t class as default instead of
>> the factory from pygccxml). At the moment, *every* user of pyplusplus
>> would have to pass dwfactory_t explicitly whereas this is rather an
>> implementation detail.
> 
> Yes and this is exactly the details that will be hidden in Allen class :-)

Oh, ok, but just because we will have a high level API doesn't mean we 
should be "sloppy" and introduce awkward things into the low level API. 
In my opinion, the low level API should still be kept clean and logical 
and also as "easy to use" as possible (without having to introduce new 
concepts that the high level API might already do). Maybe there are 
cases where users have to go back to the low level API for whatever 
reasons...

- Matthias -

Matthias Baas wrote:

> Hi,
>
> some of the recent discussion has become somewhat "theoretical" for me 
> as I'm still in a state where I cannot create my bindings. So my 
> short-term goal is still to get either my own or Allen's API to a 
> state where it's at least partially functional again. In my own 
> version I still get that exception I once posted. After the 
> discoveries from yesterday I thought the problem might be that I don't 
> provide a decl_factory to create decl_wrappers and pyplusplus might 
> depend on them. But when I created a factory class that returns 
> decl_wrappers then even the parse() step fails with an assertion error 
> in source_reader.py (btw, shouldn't such a factory object be part of 
> pyplusplus?).
> And Allen's version still seems to rely on his patched version of 
> pyplusplus.
> I'm not sure if Allen is in the same situation or not, but at least 
> for me it would be great if I could somehow get any API to work with 
> the current cvs version of pyplusplus again.
> Roman, can you provide a small "porting guide" and outline what has to 
> be changed so that a script that was working with pyplusplus from 1 or 
> 2 weeks ago will work again with the current version?
> I'd like to get "back on the road" again as quickly as possible so 
> that I can actually move on... ;)

I would like to get back to a working API as well.  I tried to do this 
last weekend but ran into problems when I couldn't figure out how to get 
back the decl_wrappers with the new interface.  The current problem in 
my API is that when the pygccxml parse returns (after being called with 
the decl_wrapper factory) it does not return a decl_wrapper.  Until I 
find out how to get to the decl wrappers I am at a standstill.

Roman:  How do I get to the decl wrappers.

-Allen

>
> - 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
> pygccxml-development@...
> https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>

Allen Bierbaum wrote:
> Roman:  How do I get to the decl wrappers.

I had a look at pypp_api.py and saw that you're already doing what I 
thought is required....(passing the dwfactory_t object to the 
project_reader)
Do you have you caching enabled? Then you must remove the cache file 
because otherwise you get the old cache content which uses the pygccxml 
declaration objects.

By the way, did I get that right that you won't have the time to work on 
the pypp_api before the weekend? So is the current cvs version also the 
up-to-date version or do you have already a newer version? As one of the 
next things I wanted to have a closer look at it and maybe I can also do 
some modifications to get it to work again....

- Matthias -

Matthias Baas wrote:

> Allen Bierbaum wrote:
>
>> Roman:  How do I get to the decl wrappers.
>
>
> I had a look at pypp_api.py and saw that you're already doing what I 
> thought is required....(passing the dwfactory_t object to the 
> project_reader)
> Do you have you caching enabled? Then you must remove the cache file 
> because otherwise you get the old cache content which uses the 
> pygccxml declaration objects.
>
> By the way, did I get that right that you won't have the time to work 
> on the pypp_api before the weekend? So is the current cvs version also 
> the up-to-date version or do you have already a newer version? As one 
> of the next things I wanted to have a closer look at it and maybe I 
> can also do some modifications to get it to work again....

Sort of right.  I do have time to get the current API working once I 
understand how to get at the wrappers.  I just won't have time to sit 
down and work for more then an hour or two.  I "should" be able to 
dedicate a day to the effort this weekend though.

-Allen

>
> - 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
> pygccxml-development@...
> https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>

Allen Bierbaum wrote:
> Sort of right.  I do have time to get the current API working once I 
> understand how to get at the wrappers.  

Well, it works for me (using the unmodified pypp_api module as it is 
stored in cvs in the experimental directory).
When I print "parsed_decls" in parse() I get:

[<pyplusplus.decl_wrappers.namespace_wrapper.namespace_t object at 
0xb75f50cc>]

Just make sure you don't load an old declaration tree from any cache 
that is still lying around.

But a few lines later I get an exception because 
code_creators.decl_decorator_t doesn't exist. This was a class from your 
patch, right?

- Matthias -

Matthias Baas wrote:

> Allen Bierbaum wrote:
>
>> Sort of right.  I do have time to get the current API working once I 
>> understand how to get at the wrappers.  
>
>
> Well, it works for me (using the unmodified pypp_api module as it is 
> stored in cvs in the experimental directory).
> When I print "parsed_decls" in parse() I get:
>
> [<pyplusplus.decl_wrappers.namespace_wrapper.namespace_t object at 
> 0xb75f50cc>]
>
> Just make sure you don't load an old declaration tree from any cache 
> that is still lying around.
>
> But a few lines later I get an exception because 
> code_creators.decl_decorator_t doesn't exist. This was a class from 
> your patch, right?

Yes.  That is the part I want to fix up.

Good suggestion on the cache.  I will check that tonight (in about 5 
hours).  If that is the problem I should be able to get most of the API 
back up and working tonight.

-Allen

>
> - 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
> pygccxml-development@...
> https://lists.sourceforge.net/lists/listinfo/pygccxml-development
>

On 3/8/06, Matthias Baas <baas@...> wrote:
> Roman Yakovenko wrote:
> >> ok, at least the script runs without errors again. But I do get an err=
or
> >> during compilation but that's another thing now that I first have to
> >> investigate...(it seems my call policies don't get assigned anymore, b=
ut
> >> that's ok for now).
> >
> > The only thing that I can say is that "it works fine for me". Could
> > you investigate the
> > problem. If this is a problem in pyplusplus you can commit the fix.
>
> ok (but I think this could just as well be a problem in my old API which
> just has to be updated to the new version of pyplusplus. So far, I'm
> happy that I don't get an exception anymore. :)
>
> >> I think now that pyplusplus relies on seeing its own declaration
> >> classes, it would be useful to introduce a parse() function in
> >> pyplusplus (which would use the dwfactory_t class as default instead o=
f
> >> the factory from pygccxml). At the moment, *every* user of pyplusplus
> >> would have to pass dwfactory_t explicitly whereas this is rather an
> >> implementation detail.
> >
> > Yes and this is exactly the details that will be hidden in Allen class =
:-)
>
> Oh, ok, but just because we will have a high level API doesn't mean we
> should be "sloppy" and introduce awkward things into the low level API.
> In my opinion, the low level API should still be kept clean and logical
> and also as "easy to use" as possible (without having to introduce new
> concepts that the high level API might already do). Maybe there are
> cases where users have to go back to the low level API for whatever
> reasons...

Like your :-). If you can commit the fix go ahead. If you don't I will
do it next week

> - Matthias -

Thanks

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

On 3/8/06, Allen Bierbaum <allenb@...> wrote:
> Matthias Baas wrote:
>
> > Allen Bierbaum wrote:
> >
> >> Sort of right.  I do have time to get the current API working once I
> >> understand how to get at the wrappers.
> >
> >
> > Well, it works for me (using the unmodified pypp_api module as it is
> > stored in cvs in the experimental directory).
> > When I print "parsed_decls" in parse() I get:
> >
> > [<pyplusplus.decl_wrappers.namespace_wrapper.namespace_t object at
> > 0xb75f50cc>]
> >
> > Just make sure you don't load an old declaration tree from any cache
> > that is still lying around.
> >
> > But a few lines later I get an exception because
> > code_creators.decl_decorator_t doesn't exist. This was a class from
> > your patch, right?
>
> Yes.  That is the part I want to fix up.
>
> Good suggestion on the cache.  I will check that tonight (in about 5
> hours).  If that is the problem I should be able to get most of the API
> back up and working tonight.

Allen if you don't have time this is okey. I do have some. I can
create module builder.
Obviously I will do it wrong  and you will have to fix it. I will be
able to commit it 12/03 morning. What do you think?

> -Allen
>
> >
> > - Matthias -
> >
> >

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