Thread: [pygccxml-development] How to get back an "emergency API"?
Brought to you by:
mbaas,
roman_yakovenko
Menu
▾
▴
pygccxml-development
|
From: Matthias B. <ba...@ir...> - 2006-03-08 10:28:17
|
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... ;) - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-03-08 11:07:51
|
On 3/8/06, Matthias Baas <ba...@ir...> 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/ |
|
From: Roman Y. <rom...@gm...> - 2006-03-08 11:27:31
|
On 3/8/06, Roman Yakovenko <rom...@gm...> 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/ |
|
From: Matthias B. <ba...@ir...> - 2006-03-08 13:27:33
|
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 - |
|
From: Matthias B. <ba...@ir...> - 2006-03-08 14:23:19
|
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 - |
|
From: Roman Y. <rom...@gm...> - 2006-03-09 05:27:17
|
On 3/8/06, Matthias Baas <ba...@ir...> 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/ |
|
From: Allen B. <al...@vr...> - 2006-03-08 15:27:53
|
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 > pyg...@li... > https://lists.sourceforge.net/lists/listinfo/pygccxml-development > |
|
From: Matthias B. <ba...@ir...> - 2006-03-08 17:46:53
|
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 - |
|
From: Allen B. <al...@vr...> - 2006-03-08 18:01:45
|
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 > pyg...@li... > https://lists.sourceforge.net/lists/listinfo/pygccxml-development > |
|
From: Matthias B. <ba...@ir...> - 2006-03-08 20:52:22
|
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 - |
|
From: Allen B. <al...@vr...> - 2006-03-08 21:13:36
|
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 > pyg...@li... > https://lists.sourceforge.net/lists/listinfo/pygccxml-development > |
|
From: Roman Y. <rom...@gm...> - 2006-03-09 05:31:18
|
On 3/8/06, Allen Bierbaum <al...@vr...> 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/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X