Thread: [Fwd: [pygccxml-development] Updated status]
Brought to you by:
mbaas,
roman_yakovenko
Menu
▾
▴
pygccxml-development
|
From: Allen B. <al...@vr...> - 2006-03-06 14:05:52
|
Second try. Roman: you are on the pygccxml-development list correct? -Allen -------- Original Message -------- Subject: [pygccxml-development] Updated status Date: Sat, 04 Mar 2006 19:03:32 -0600 From: Allen Bierbaum <al...@vr...> To: pyg...@li... A apologize in advance, this e-mail is going to be a little random because it is based on my notes from this afternoon. I started trying to move the pypp_api interface over the the new codebase and these are the things I have run into right away. - Calling parser changed a bit. There seems to be a new interface to calling the project parser. I think I just need to add a decl wrapper factory but I am not for sure. Roman? - How am I supposed to use the decl_wrappers? I am trying to parse with the project reader and then I was expecting that the returned decls would actually be the wrappers/decorators for the decls. Is this how it is supposed to work? - Code complexity: The new decorators does look like a LOT of additional code for what could be done with some grafted flags. Not really a question, more of a comment. I really think the codebase could be simplified a lot. For me at least all the property usage seems like a lot of extra code to read through and maintain for very little payoff. - What is module_builder_t for? Do I have to use it? It looks like Roman's stab at the higher-level interface but what do I need to copy from there into pypp_api. - Why did call policies move to the wrapper module? Those still seem like code_creators. - Decl wrappers don't seem to support everything I needed/added with the decorators. Specifically, how can I add custom creators? In my flag-based version I could add a list of code creators that would automatically be added on when the creator class build the code creators for a decl. - What are all the options that have been added to the wrappers? (see documentation below) - I think Logger should probably use info() for most of the current output. Why put time and level name in log output? My original goal with this output was to have verbose output for users not to provide a debug log to a log file on errors. Any objections to making the output look cleaner by making the info() filter just output the text instead of all the header information? - Comments: We *really* need comments and documentation for the classes and methods in pygccxml and pyplusplus. I think Matthias and I could help out by pointing to areas of the code and saying in our very nicest voice "Roman, please please document this". Toward this goal (and following up on Matthias's comments from last week), I started looking at what it would take to generate documentation using epydoc and restructuredtext. I added a script in "experimental/docs/generate_all_docs.py" that will call epydoc with what I think are the correct parameters to generate html documentation. I also started converting pypp_api over to use restructured text for documentation. The only problem is that it looks like the tags/fields I am using are not being recognized correctly (ex: params, args, etc). According to the docs I am doing things correctly but it is just not working. If either of you have experience with this tool please take a look and let me know if I am doing something wrong. Does this seem like a good direction for documentation? I know we can document classes and methods using this, do we want to document the usage of the modules like this as well? (it is supported but do we want that type of documentation in the code?) That is about all I have for now. Until I find out more about the decl_wrapper's and their use I am at a stand still. :( Thanks, Allen ------------------------------------------------------- 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-06 14:13:37
|
On 3/6/06, Allen Bierbaum <al...@vr...> wrote: > Second try. Roman: you are on the pygccxml-development list correct? Yes. > -Allen > > -------- Original Message -------- > Subject: [pygccxml-development] Updated status > Date: Sat, 04 Mar 2006 19:03:32 -0600 > From: Allen Bierbaum <al...@vr...> > To: pyg...@li... > > > > A apologize in advance, this e-mail is going to be a little random > because it is based on my notes from this afternoon. I started trying > to move the pypp_api interface over the the new codebase and these are > the things I have run into right away. > > - Calling parser changed a bit. > > There seems to be a new interface to calling the project parser. I > think I just need to add a decl wrapper factory but I am not for sure. > Roman? > > - How am I supposed to use the decl_wrappers? > > I am trying to parse with the project reader and then I was expecting > that the returned decls would actually be the wrappers/decorators for > the decls. Is this how it is supposed to work? > > - Code complexity: The new decorators does look like a LOT of additional > code for what could be done with some grafted flags. Not really a > question, more of a comment. I really think the codebase could be > simplified a lot. For me at least all the property usage seems like a > lot of extra code to read through and maintain for very little payoff. > > - What is module_builder_t for? Do I have to use it? It looks like > Roman's stab at the higher-level interface but what do I need to copy > from there into pypp_api. > > - Why did call policies move to the wrapper module? Those still seem > like code_creators. > > - Decl wrappers don't seem to support everything I needed/added with the > decorators. > > Specifically, how can I add custom creators? In my flag-based version I > could add a list of code creators that would automatically be added on > when the creator class build the code creators for a decl. > > - What are all the options that have been added to the wrappers? (see > documentation below) > > - I think Logger should probably use info() for most of the current > output. Why put time and level name in log output? > > My original goal with this output was to have verbose output for users > not to provide a debug log to a log file on errors. Any objections to > making the output look cleaner by making the info() filter just output > the text instead of all the header information? > > - Comments: We *really* need comments and documentation for the classes > and methods in pygccxml and pyplusplus. I think Matthias and I could > help out by pointing to areas of the code and saying in our very nicest > voice "Roman, please please document this". > > Toward this goal (and following up on Matthias's comments from last > week), I started looking at what it would take to generate documentation > using epydoc and restructuredtext. I added a script in > "experimental/docs/generate_all_docs.py" that will call epydoc with what > I think are the correct parameters to generate html documentation. I > also started converting pypp_api over to use restructured text for > documentation. The only problem is that it looks like the tags/fields I > am using are not being recognized correctly (ex: params, args, etc). > According to the docs I am doing things correctly but it is just not > working. If either of you have experience with this tool please take a > look and let me know if I am doing something wrong. > > Does this seem like a good direction for documentation? I know we can > document classes and methods using this, do we want to document the > usage of the modules like this as well? (it is supported but do we want > that type of documentation in the code?) > > That is about all I have for now. Until I find out more about the > decl_wrapper's and their use I am at a stand still. :( > > Thanks, > Allen > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting langua= ge > that extends applications into web and mobile media. Attend the live webc= ast > and join the prime developer group breaking into this new coding territor= y! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat= =3D121642 > _______________________________________________ > pygccxml-development mailing list > pyg...@li... > https://lists.sourceforge.net/lists/listinfo/pygccxml-development > > > -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Matthias B. <ba...@ir...> - 2006-03-06 14:56:16
|
Roman Yakovenko wrote: > On 3/6/06, Allen Bierbaum <al...@vr...> wrote: >> Second try. Roman: you are on the pygccxml-development list correct? > > Yes. The SF site only lists 2 subscribers. I am subscribed and I do receive the mails from the list (e.g. I got Allen's mail). So who else did subscribe and who didn't yet? Please post a quick reply if you got this email (I have posted it to the list only, so this is already a check if you are properly subscribed or not). - Matthias - |
|
From: Allen B. <al...@vr...> - 2006-03-06 15:28:22
|
Matthias Baas wrote: > Roman Yakovenko wrote: > >> On 3/6/06, Allen Bierbaum <al...@vr...> wrote: >> >>> Second try. Roman: you are on the pygccxml-development list correct? >> >> >> Yes. > > > The SF site only lists 2 subscribers. I am subscribed and I do receive > the mails from the list (e.g. I got Allen's mail). > So who else did subscribe and who didn't yet? > Please post a quick reply if you got this email (I have posted it to > the list only, so this is already a check if you are properly > subscribed or not). > > - Matthias - I am getting the messages as well. It looks like Roman is not subscribed. -Allen |
|
From: Roman Y. <rom...@gm...> - 2006-03-07 05:51:32
|
My fault, now I am subscribed. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Roman Y. <rom...@gm...> - 2006-03-07 06:45:13
|
On 3/6/06, Allen Bierbaum <al...@vr...> wrote: > A apologize in advance, this e-mail is going to be a little random > because it is based on my notes from this afternoon. I started trying > to move the pypp_api interface over the the new codebase and these are > the things I have run into right away. > > - Calling parser changed a bit. > > There seems to be a new interface to calling the project parser. I > think I just need to add a decl wrapper factory but I am not for sure. > Roman? Yes > - How am I supposed to use the decl_wrappers? > > I am trying to parse with the project reader and then I was expecting > that the returned decls would actually be the wrappers/decorators for > the decls. Is this how it is supposed to work? Yes. > - Code complexity: The new decorators does look like a LOT of additional > code for what could be done with some grafted flags. Not really a > question, more of a comment. I really think the codebase could be > simplified a lot. For me at least all the property usage seems like a > lot of extra code to read through and maintain for very little payoff. I will explain this on Wiki > - What is module_builder_t for? Do I have to use it? It looks like > Roman's stab at the higher-level interface but what do I need to copy > from there into pypp_api. Nothing, it exists for testers only as temporal solution. > - Why did call policies move to the wrapper module? Those still seem > like code_creators. Short answer: because when user thinks about call policies he does not thin= k about code generation. In future I will remove "code generation functionality" from call policies. > - Decl wrappers don't seem to support everything I needed/added with the > decorators. > > Specifically, how can I add custom creators? In my flag-based version I > could add a list of code creators that would automatically be added on > when the creator class build the code creators for a decl. First of all I missed this future. Sorry. I will add the functionality to decl wrappers. > - What are all the options that have been added to the wrappers? (see > documentation below) I will try to add documentation to all options wrappers have. > - I think Logger should probably use info() for most of the current > output. Why put time and level name in log output? Cut & paste. In one of my projects I had logging configuration code. I will change it to what you proposed. > My original goal with this output was to have verbose output for users > not to provide a debug log to a log file on errors. Any objections to > making the output look cleaner by making the info() filter just output > the text instead of all the header information? No. I will do that. > - Comments: We *really* need comments and documentation for the classes > and methods in pygccxml and pyplusplus. I think Matthias and I could > help out by pointing to areas of the code and saying in our very nicest > voice "Roman, please please document this". Huston, you've got a problem :-). For me it is a huge effort to write documentation. I can not explain my self clearly. If you don't mind, I prefer to answer 1000 question from you and Matthias, but you will write documentation. Please, please, please = :-) > That is about all I have for now. Until I find out more about the > decl_wrapper's and their use I am at a stand still. :( Hope, I helped > Thanks, > Allen -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Matthias B. <ba...@ir...> - 2006-03-07 16:47:19
|
Roman Yakovenko wrote: >> - Calling parser changed a bit. >> >> There seems to be a new interface to calling the project parser. I >> think I just need to add a decl wrapper factory but I am not for sure. >> Roman? > > Yes > >> - How am I supposed to use the decl_wrappers? >> >> I am trying to parse with the project reader and then I was expecting >> that the returned decls would actually be the wrappers/decorators for >> the decls. Is this how it is supposed to work? > > Yes. I was confused about the above two points, but after rummaging in the code some more I also spotted the "decl_factory" argument in the constructor of project_reader_t (shouldn't this also be an argument to the parse() function?). And now the fog is actually clearing and I see what the new implementation gave us.... So when we parse the headers for pyplusplus, we actually don't get a declaration tree that is made of declaration_t objects as provided by pygccxml but of specialized decl_wrapper_t objects that are part of pyplusplus, right? The factory function is required because pygccxml cannot know about those decl_wrappers because they are specific to pyplusplus and pygccxml is an independent standalone package. All right, now I see and this really looks like an improvement to me. But maybe the names *_wrapper is really a bit unfortunate as in my view, they do not "wrap" the declarations, but they *are* the declarations. And I think they are not quite the same than the corresponding objects in our API versions as they cannot serve as a container for declarations. But they are the same insofar that they provide the decoration interface, correct? - Matthias - |
|
From: Allen B. <al...@vr...> - 2006-03-07 23:19:58
|
Matthias Baas wrote: > Roman Yakovenko wrote: > >>> - Calling parser changed a bit. >>> >>> There seems to be a new interface to calling the project parser. I >>> think I just need to add a decl wrapper factory but I am not for sure. >>> Roman? >> >> >> Yes >> >>> - How am I supposed to use the decl_wrappers? >>> >>> I am trying to parse with the project reader and then I was expecting >>> that the returned decls would actually be the wrappers/decorators for >>> the decls. Is this how it is supposed to work? >> >> >> Yes. > > > I was confused about the above two points, but after rummaging in the > code some more I also spotted the "decl_factory" argument in the > constructor of project_reader_t (shouldn't this also be an argument to > the parse() function?). > And now the fog is actually clearing and I see what the new > implementation gave us.... > So when we parse the headers for pyplusplus, we actually don't get a > declaration tree that is made of declaration_t objects as provided by > pygccxml but of specialized decl_wrapper_t objects that are part of > pyplusplus, right? The factory function is required because pygccxml > cannot know about those decl_wrappers because they are specific to > pyplusplus and pygccxml is an independent standalone package. > > All right, now I see and this really looks like an improvement to me. > But maybe the names *_wrapper is really a bit unfortunate as in my > view, they do not "wrap" the declarations, but they *are* the > declarations. They implement a classic decorator pattern. Based on this I would vote to call them *_decorator or something like that. > And I think they are not quite the same than the corresponding objects > in our API versions as they cannot serve as a container for > declarations. But they are the same insofar that they provide the > decoration interface, correct? This is an area where I think we need to discuss further (perhaps on the wiki based on romans summary post). Basically: are the *_decorator classes meant to replace the corresponding DeclWrapper classes in our prototype API. It looks from Roman's description that they are. (this is not a bad thing, I just want to understand the goal). Assuming they are meant to replace the decl wrappers, then does that mean that we need to extend those new classes with the search/lookup interfaces we have been using in the prototype API? There is also the outstanding issue of usablility, but we can address that a little later.... If I get time tonight I will get some of this posted on the wiki for further discussion. -Allen |
|
From: Allen B. <al...@vr...> - 2006-03-07 23:11:18
|
Roman Yakovenko wrote: >On 3/6/06, Allen Bierbaum <al...@vr...> wrote: > > >>A apologize in advance, this e-mail is going to be a little random >>because it is based on my notes from this afternoon. I started trying >>to move the pypp_api interface over the the new codebase and these are >>the things I have run into right away. >> >>- Calling parser changed a bit. >> >>There seems to be a new interface to calling the project parser. I >>think I just need to add a decl wrapper factory but I am not for sure. >>Roman? >> >> > >Yes > > > >>- How am I supposed to use the decl_wrappers? >> >>I am trying to parse with the project reader and then I was expecting >>that the returned decls would actually be the wrappers/decorators for >>the decls. Is this how it is supposed to work? >> >> > >Yes. > > So this may have been where I got off track. I ran my existing pypp_api code and where it gets the decls from the parser the class that is returned is not a wrapper. If I remember correctly it was just a namespace decl. I will check this again tonight against the latest codebase and let you know if things are working correctly. >Short answer: because when user thinks about call policies he does not think >about code generation. In future I will remove "code generation >functionality" from >call policies. > > Okay, I guess that makes sense but the previous way of just importing the "decorating" aspects of call policies seemed to work pretty well. The user only thought of the call policies as decoration but behind the scenes he was giving you the exact classes that you needed to do the code generation. This still seems like a valid separation and it seems like it would be the most simple design. >>- Decl wrappers don't seem to support everything I needed/added with the >>decorators. >> >>Specifically, how can I add custom creators? In my flag-based version I >>could add a list of code creators that would automatically be added on >>when the creator class build the code creators for a decl. >> >> > >First of all I missed this future. Sorry. I will add the functionality >to decl wrappers. > > Thanks. -Allen |
×
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