pygccxml-development Mailing List for C++ Python language bindings (Page 23)
Brought to you by:
mbaas,
roman_yakovenko
You can subscribe to this list here.
2006 |
Jan
|
Feb
(6) |
Mar
(160) |
Apr
(96) |
May
(152) |
Jun
(72) |
Jul
(99) |
Aug
(189) |
Sep
(161) |
Oct
(110) |
Nov
(9) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(13) |
Feb
(48) |
Mar
(35) |
Apr
(7) |
May
(37) |
Jun
(8) |
Jul
(15) |
Aug
(8) |
Sep
(2) |
Oct
(1) |
Nov
(2) |
Dec
(38) |
2008 |
Jan
(11) |
Feb
(29) |
Mar
(17) |
Apr
(3) |
May
|
Jun
(64) |
Jul
(49) |
Aug
(51) |
Sep
(18) |
Oct
(22) |
Nov
(9) |
Dec
(9) |
2009 |
Jan
(28) |
Feb
(15) |
Mar
(2) |
Apr
(11) |
May
(6) |
Jun
(2) |
Jul
(3) |
Aug
(34) |
Sep
(5) |
Oct
(7) |
Nov
(13) |
Dec
(14) |
2010 |
Jan
(39) |
Feb
(3) |
Mar
(3) |
Apr
(14) |
May
(11) |
Jun
(8) |
Jul
(9) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
(7) |
Apr
|
May
|
Jun
(3) |
Jul
(3) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
2016 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2021 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
From: Ben S. <bsc...@lu...> - 2007-12-10 18:09:51
|
>=20 > I almost agree with you. I could improve the interface,=20 > meanwhile you can use decl_visitor_t (=20 > http://language-binding.net/pygccxml/apidocs/pygccxml.declarat > ions.decl_visitor.decl_visitor_t-class.html > ) > class and apply_visitor function ( > http://language-binding.net/pygccxml/apidocs/pygccxml.declarat > ions.algorithm-module.html#apply_visitor > ) Oh, I didn't know about that functionality. Well, I'll definitely try using it next time... >=20 > > I know this would be useful because I had to search for=20 > decls based on=20 > > their attributes which wasn't a param in=20 > scopedef.member_functions(..)=20 > > so I had to manually test the attributes anyway. >=20 > So why do you need visitor? You already know that you need=20 > member functions, the only thing left is to specialized the=20 > query. This is easily done by passing a callable to the=20 > member_functions function: >=20 > ns.mem_funs( lambda x: len( x.arguments ) > 19 ) >=20 Argg, again, I didn't know about it because its not mentioned anywhere in the documentation. Maybe again a paragraph about decl_visitor_t and callable would make them more clear to the End users. >=20 > P.S. What functionality is missing from the member_functions=20 > interface? The ability to search for decls based on their attributes. This really should be a visitor or callable function because it's entirely string matching and project specific. Cheers Ben |
From: Roman Y. <rom...@gm...> - 2007-12-09 18:43:54
|
On Dec 8, 2007 11:07 PM, Ben Schleimer <bsc...@lu...> wrote: > As a sidenote (for Roman), maybe it would be good to have hooks for a > visiter pattern in declaration_t. > Then it would obvious that if the user programmer wants to traverse the decl > tree, there's a standard interface for doing so instead of the user having > to manually traverse himself. I almost agree with you. I could improve the interface, meanwhile you can use decl_visitor_t ( http://language-binding.net/pygccxml/apidocs/pygccxml.declarations.decl_visitor.decl_visitor_t-class.html ) class and apply_visitor function ( http://language-binding.net/pygccxml/apidocs/pygccxml.declarations.algorithm-module.html#apply_visitor ) > Then the scopedef functionality wouldn't be needed. Instead, we could have a > standard set of visitors which collect different types of decls and return > them as a list or mdecl_wrapper_t like scopedef.*s() does now... Not completely true. Behind the scene, scopedef_t class introduces very powerful 2-level hash optimization declaration type : declaration name : declaration ( this scope only ) and declaration type : declaration name : declaration ( all declarations from this and internal scopes recursively ) On huge projects you feel the difference. I don't have the numbers, but you can play with scopedef_t.clear_optimizer and scopedef_t.init_optimizer functions. > I know this would be useful because I had to search for decls based on their > attributes which wasn't a param in scopedef.member_functions(..) so I had to > manually test the attributes anyway. So why do you need visitor? You already know that you need member functions, the only thing left is to specialized the query. This is easily done by passing a callable to the member_functions function: ns.mem_funs( lambda x: len( x.arguments ) > 19 ) By the way, in this case scopedef_t understands that you are looking for member function, so it cuts the number of comparisons to member functions only. It also selects the shorter list based on "recursive" argument value. P.S. What functionality is missing from the member_functions interface? -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Roman Y. <rom...@gm...> - 2007-12-09 18:27:46
|
On Dec 8, 2007 10:49 PM, Gustavo Carneiro <gjc...@gm...> wrote: > On 08/12/2007, Ben Schleimer <bsc...@lu...> wrote: > > > > No, what you want is to use declarations.full_name function. > > > > Are you sure? It does not seem to include the full signature. Example, > for the methods: > > > > int get_int (const char *from_string); > > int get_int (double from_float); > > > > full_name prints: > > > > '::SomeObject::get_int' > > '::SomeObject::get_int' My mistake, I forgot about arguments > > > > You could use str(declaration). That'll print out the full signature of > the member functions. > > str(declaration) is not good because: > 1. it prints parameter names (which clearly are not part of the > signature); > 2. it adds a redundant "[member function]" description which I do not need > and am afraid might change one day; You are right > 3. I don't think there are any guarantees the string format won't change > in the future. You are right > > > > > > Otherwise, you'll probably have to write your own formatting function. > > I guess I could do it. I was just hoping pygccxml had it already, to save > me some work... :P Not in this case :-(. I think you will have to introduce your own format. I guess you should consider: * function default values * function exceptions * static or not * virtuality * access type * who knows what else May be you should take a look on "cache" functionality ( http://language-binding.net/pygccxml/apidocs/pygccxml.parser.declarations_cache-module.html ). The only problem that it has is that I don't promise to be backward compatible. This is a hard to meet requirement, so I just ask from users to clean the cache every time they upgrade pygccxml. I also found out that this cache is pretty useless, because it doesn't give the desired performance boost. I don't know what is the size of your project, but may be instead of creating some format that will describe the headers content, you will save the whole XML and next time you will compare between 2 XML files? Of course this will not work if we talk about huge projects. Another idea is to take a look on Py++. Recently I implemented functionality that allows user to manage dependencies in multi-module project with a single line of code. Take a look on next file: http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/pyplusplus/utils/__init__.py?revision=1173&view=markup The class, you should look at, is exposed_decls_db_t. As in other cases I will not promise backward compatibility. HTH -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Ben S. <bsc...@lu...> - 2007-12-08 21:07:54
|
Hi, =20 =20 You could use str(declaration). That'll print out the full signature of the member functions. str(declaration) is not good because: 1. it prints parameter names (which clearly are not part of the signature); 2. it adds a redundant "[member function]" description which I do not need and am afraid might change one day;=20 3. I don't think there are any guarantees the string format won't change in the future. =09 Otherwise, you'll probably have to write your own formatting function. I guess I could do it. I was just hoping pygccxml had it already, to save me some work... :P=20 =20 Nope, I guess everyone wants their own version of __str__() ;). =20 As a sidenote (for Roman), maybe it would be good to have hooks for a visiter pattern in declaration_t. Then it would obvious that if the user programmer wants to traverse the decl tree, there's a standard interface for doing so instead of the user having to manually traverse himself. Then the scopedef functionality wouldn't be needed. Instead, we could have a standard set of visitors which collect different types of decls and return them as a list or mdecl_wrapper_t like scopedef.*s() does now... I know this would be useful because I had to search for decls based on their attributes which wasn't a param in scopedef.member_functions(..) so I had to manually test the attributes anyway. =20 Cheers Ben =20 |
From: Gustavo C. <gjc...@gm...> - 2007-12-08 20:49:08
|
On 08/12/2007, Ben Schleimer <bsc...@lu...> wrote: > > > > > No, what you want is to use declarations.full_name function. > > Are you sure? It does not seem to include the full signature. Example, > for the methods: > > int get_int (const char *from_string); > int get_int (double from_float); > > full_name prints: > > '::SomeObject::get_int' > '::SomeObject::get_int' > > > You could use str(declaration). That'll print out the full signature of > the member functions. > str(declaration) is not good because: 1. it prints parameter names (which clearly are not part of the signature); 2. it adds a redundant "[member function]" description which I do not need and am afraid might change one day; 3. I don't think there are any guarantees the string format won't change in the future. Otherwise, you'll probably have to write your own formatting function. > I guess I could do it. I was just hoping pygccxml had it already, to save me some work... :P -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert |
From: Ben S. <bsc...@lu...> - 2007-12-08 20:11:44
|
=20 =09 No, what you want is to use declarations.full_name function. =09 Are you sure? It does not seem to include the full signature. Example, for the methods:=20 =09 int get_int (const char *from_string); int get_int (double from_float); =09 full_name prints: =09 '::SomeObject::get_int' '::SomeObject::get_int' =09 =20 You could use str(declaration). That'll print out the full signature of the member functions. Otherwise, you'll probably have to write your own formatting function. =20 Cheers Ben |
From: Gustavo C. <gjc...@gm...> - 2007-12-08 18:57:30
|
On 08/12/2007, Roman Yakovenko <rom...@gm...> wrote: > > On Dec 8, 2007 3:02 PM, Gustavo Carneiro <gjc...@gm...> wrote: > > Hi Roman and all, > > > > Suppose I wanted to: > > > > 1- Scan header files once; > > 2- Store the definitions found in my own XML format, including for > each > > definition a string that uniquely identifies it; > > 3- Later, I run the same program that scans a new set of > definitions > > 4- At this point the program should be able to detect: a) newly > added > > definitions, b) changed definitions (only changed parameter names), c) > > removed definitions; > > > > For step 4 I need to get a definitions identifier that is stable across > > current and future (py)gccxml versions. Is decl_string the identifier I > > want? > > No, what you want is to use declarations.full_name function. Are you sure? It does not seem to include the full signature. Example, for the methods: int get_int (const char *from_string); int get_int (double from_float); full_name prints: '::SomeObject::get_int' '::SomeObject::get_int' P.S. Be careful with unnamed declarations. I am not sure when I get unnamed declarations. But in any case, one step at a time... :) -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert |
From: Roman Y. <rom...@gm...> - 2007-12-08 18:39:10
|
On Dec 8, 2007 3:02 PM, Gustavo Carneiro <gjc...@gm...> wrote: > Hi Roman and all, > > Suppose I wanted to: > > 1- Scan header files once; > 2- Store the definitions found in my own XML format, including for each > definition a string that uniquely identifies it; > 3- Later, I run the same program that scans a new set of definitions > 4- At this point the program should be able to detect: a) newly added > definitions, b) changed definitions (only changed parameter names), c) > removed definitions; > > For step 4 I need to get a definitions identifier that is stable across > current and future (py)gccxml versions. Is decl_string the identifier I > want? No, what you want is to use declarations.full_name function. P.S. Be careful with unnamed declarations. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Gustavo C. <gjc...@gm...> - 2007-12-08 13:02:46
|
Hi Roman and all, Suppose I wanted to: 1- Scan header files once; 2- Store the definitions found in my own XML format, including for each definition a string that uniquely identifies it; 3- Later, I run the same program that scans a new set of definitions 4- At this point the program should be able to detect: a) newly added definitions, b) changed definitions (only changed parameter names), c) removed definitions; For step 4 I need to get a definitions identifier that is stable across current and future (py)gccxml versions. Is decl_string the identifier I want? Thanks in advance. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert |
From: Roman Y. <rom...@gm...> - 2007-12-05 21:01:22
|
On Dec 5, 2007 8:19 PM, Aron Bierbaum <aro...@gm...> wrote: > I am using pyplusplus to generate bindings for large project and > rather than running gccxml on all headers I have created one large > header that includes the rest of them. This header is a prime > candidate for begin a precompiled header. I am running into an issue > where I can not get pyplusplus to place this file at the top of each > file when calling mb.split_module(). Is there currently a way that I > can get this behavior? Otherwise I have attached a patch that adds > another parameter to split_module that allows the user to specify a > list of pre-compiled headers to place at the start of all generated > files. pre-compiled headers is a problem I cannot find good solution :-(. I prefer to reject the patch and provide you with relatively simple solution, using low-level API: from pyplusplus import code_creators mb = module_builder_t( ... ) mb.build_code_creator( ... ) precompiled_header = code_creators.include_t( 'your file name' ) mb.code_creator.adopt_creator( precompiled_header, 0 ) This should do the work. You need latest versions of Py++ and pygccxml, or you can just modify multiple_files.py and class_multiple_files.py files as explained. Both files contains next line: source_code.append( self.create_include_code( creators, head_headers ) ) You should change it to : source_code.append( self.create_include_code( creators, tail_headers=head_headers ) ) HTH -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Roman Y. <rom...@gm...> - 2007-12-05 19:26:53
|
On Dec 5, 2007 8:31 PM, Ben Schleimer <bsc...@lu...> wrote: > It is hard to come with good example for pygccxml only classes, partly > because declaration classes doesn't contain functionality, but only data. > > For Py++ it is very easy, for example update some property for all selected > declarations: > > decls = class_.decls( some condition ) > decls.xxx = yyy > > Or even > > class_.decls( some condition ).xxx = yyy > > it is much shorter than > > [ d.xxx = yyy for d in class_.decls( some condition ) ) > > But may be you are right. I will think about this point. > > If this functionality works, then it would be VERY good to add the above > comments to the code and/or documentation. My English is not as good as I want. I will appreciate any patch to the documentation: http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pygccxml_dev/docs/query_interface.rest?view=markup > I didn't understand that you could do this before. However, I think that > having query operators that return lists of decls would be good because > it provides more functionality then mdecl_wrapper_t, you can concatenate > lists together and it leaves open the possibility of adding functionality to > decls. In this case I think I will enrich mdecl_wrapper_t interface, may be I can derive it from the list class. I will check. > This doesn't mean you need to remove the mdecl_wrapper_t functions, they are > pretty innovative... Thanks P.S. Your comments were really helpful -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Ben S. <bsc...@lu...> - 2007-12-05 18:31:56
|
=20 =09 =09 However, I think I'll stick to mem_fun*s(..., allow_empty=3Dtrue) for now. It makes more sense... =09 =09 In this case it make more sense to set allow_empty to be always true by =09 scopedef_t. ALLOW_EMPTY_MDECL_WRAPPER =3D True=20 =20 This is what I am doing now. It seems to work ok with the _select_multiple functions. PS. I don't understand how we are avoiding a loop by writing =20 for decl in class_.decls(): =20 wouldn't this be the same if decls() returned a list? And then the benefit of a list would be it's standard operations... =09 =09 It is hard to come with good example for pygccxml only classes, partly because declaration classes doesn't contain functionality, but only data.=20 =09 For Py++ it is very easy, for example update some property for all selected declarations: =09 decls =3D class_.decls( some condition ) decls.xxx =3D yyy =09 Or even=20 =09 class_.decls( some condition ).xxx =3D yyy=20 =09 it is much shorter than =09 [ d.xxx =3D yyy for d in class_.decls( some condition ) ) =09 But may be you are right. I will think about this point. =20 If this functionality works, then it would be VERY good to add the above comments to the code and/or documentation. I didn't understand that you could do this before. However, I think that having query operators that return lists of decls would be good because it provides more functionality then mdecl_wrapper_t, you can concatenate lists together and it leaves open the possibility of adding functionality to decls. This doesn't mean you need to remove the mdecl_wrapper_t functions, they are pretty innovative... =20 Cheers Ben =20 =20 --=20 Roman Yakovenko C++ Python language binding http://www.language-binding.net/=20 |
From: Aron B. <aro...@gm...> - 2007-12-05 18:19:10
|
I am using pyplusplus to generate bindings for large project and rather than running gccxml on all headers I have created one large header that includes the rest of them. This header is a prime candidate for begin a precompiled header. I am running into an issue where I can not get pyplusplus to place this file at the top of each file when calling mb.split_module(). Is there currently a way that I can get this behavior? Otherwise I have attached a patch that adds another parameter to split_module that allows the user to specify a list of pre-compiled headers to place at the start of all generated files. Thank you, Aron Bierbaum |
From: Roman Y. <rom...@gm...> - 2007-12-05 06:51:52
|
On Dec 4, 2007 11:33 PM, Ben Schleimer <bsc...@lu...> wrote: > Um, ok I finally saw this page. having a link to it inside the > documentation would be useful.. > I think that the use of exceptions in this context is overkill, > considering that exceptions should only be used in "exceptional" cases. > I think that java suffered from the same problem of overuse of exceptions. > > However, I think I'll stick to mem_fun*s(..., allow_empty=true) for now. > It makes more sense... > In this case it make more sense to set allow_empty to be always true by scopedef_t. ALLOW_EMPTY_MDECL_WRAPPER = True so you will not be forced to pass the argument every call > > Cheers > Ben > > PS. I don't understand how we are avoiding a loop by writing > > for decl in class_.decls(): > > wouldn't this be the same if decls() returned a list? > And then the benefit of a list would be it's standard operations... > It is hard to come with good example for pygccxml only classes, partly because declaration classes doesn't contain functionality, but only data. For Py++ it is very easy, for example update some property for all selected declarations: decls = class_.decls( some condition ) decls.xxx = yyy Or even class_.decls( some condition ).xxx = yyy it is much shorter than [ d.xxx = yyy for d in class_.decls( some condition ) ) But may be you are right. I will think about this point. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Ben S. <bsc...@lu...> - 2007-12-04 21:33:02
|
Um, ok I finally saw this page. having a link to it inside the documentation would be useful.. I think that the use of exceptions in this context is overkill, considering that exceptions should only be used in "exceptional" cases. I think that java suffered from the same problem of overuse of exceptions. =20 However, I think I'll stick to mem_fun*s(..., allow_empty=3Dtrue) for = now. It makes more sense... =20 Cheers Ben =20 PS. I don't understand how we are avoiding a loop by writing =20 for decl in class_.decls(): =20 wouldn't this be the same if decls() returned a list? And then the benefit of a list would be it's standard operations... =20 ________________________________ From: Roman Yakovenko [mailto:rom...@gm...]=20 Sent: Tuesday, December 04, 2007 12:29 PM To: Ben Schleimer Cc: pyg...@li... Subject: Re: [pygccxml-development] Additional attribute functionality =09 =09 On Dec 4, 2007 9:58 PM, Ben Schleimer <bsc...@lu...> wrote: =09 Hi Roman, Another thing to keep in mind for after 1.0 is that the scopedef is very difficult to work with. When I write class_.member_function("foobar"), I expect either a value or None to be returned. I don't expect an exception to be thrown likewise, I'd like to see class_.member_functions("foobar") to return a list of declarations, zero if no declaration matches. Again, no exception should be through. Then I can take the list and manipulate it like a normal python list. =09 Did you read this http://language-binding.net/pygccxml/query_interface.html document? The behavior you are talking about was implemented intentionally.=20 =09 I prefer to think about "mem_fun" as "get" function, which should raise in error if there is 0 or 2+ member functions with the same name. The behavior you propose doesn't distinct between these cases. On the other side raised exception contains enough information to explain what went wrong.=20 =09 I think about "mem_fun*s*" as a query function, it can return zero or more items that match search criteria. You can customize the behavior of this function. By default it raises an exception if no match was found. Pass "allow_empty=3DTrue" as function argument to disable exception if no match was found. I understand that not everyone agrees with such behavior, so scopedef_t.ALLOW_EMPTY_MDECL_WRAPPER variable was introduced. You can set it to False, after this "mem_fun*s*" method will not raise exception on "no match".=20 =09 Now, the return value of the "mem_fun*s*" method is very carefully constructed class that allows the user to avoid writing of loops. Link to the class http://language-binding.net/pygccxml/apidocs/pygccxml.declarations.mdecl _wrapper.mdecl_wrapper_t-class.html =09 The class implements "container" interface and in general you should not notice the difference between it and the list class.=20 =09 I am using pygccxml for code generation projects. May be you are right and the interface is really "less than intuitive", but it is very valuable for code generation projects maintenance. If the underlying code change, class was removed, renamed or moved, you get immediately very helpful error message.=20 =09 Does it make sense now? =09 P.S. Of course "mem_fun*s*" is just an example and every "query/select" function has same behavior. =09 --=20 Roman Yakovenko C++ Python language binding http://www.language-binding.net/=20 |
From: Roman Y. <rom...@gm...> - 2007-12-04 20:28:41
|
On Dec 4, 2007 9:58 PM, Ben Schleimer <bsc...@lu...> wrote: > Hi Roman, > Another thing to keep in mind for after 1.0 is that the scopedef is > very difficult to work with. > When I write class_.member_function("foobar"), I expect either a value or > None to be returned. I don't expect an exception to be thrown > likewise, I'd like to see class_.member_functions("foobar") to return a > list of declarations, zero if no declaration matches. Again, no exception > should be through. > Then I can take the list and manipulate it like a normal python list. > Did you read this http://language-binding.net/pygccxml/query_interface.htmldocument? The behavior you are talking about was implemented intentionally. I prefer to think about "mem_fun" as "get" function, which should raise in error if there is 0 or 2+ member functions with the same name. The behavior you propose doesn't distinct between these cases. On the other side raised exception contains enough information to explain what went wrong. I think about "mem_fun*s*" as a query function, it can return zero or more items that match search criteria. You can customize the behavior of this function. By default it raises an exception if no match was found. Pass "allow_empty=True" as function argument to disable exception if no match was found. I understand that not everyone agrees with such behavior, so scopedef_t.ALLOW_EMPTY_MDECL_WRAPPER variable was introduced. You can set it to False, after this "mem_fun*s*" method will not raise exception on "no match". Now, the return value of the "mem_fun*s*" method is very carefully constructed class that allows the user to avoid writing of loops. Link to the class http://language-binding.net/pygccxml/apidocs/pygccxml.declarations.mdecl_wrapper.mdecl_wrapper_t-class.html The class implements "container" interface and in general you should not notice the difference between it and the list class. I am using pygccxml for code generation projects. May be you are right and the interface is really "less than intuitive", but it is very valuable for code generation projects maintenance. If the underlying code change, class was removed, renamed or moved, you get immediately very helpful error message. Does it make sense now? P.S. Of course "mem_fun*s*" is just an example and every "query/select" function has same behavior. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Ben S. <bsc...@lu...> - 2007-12-04 19:58:53
|
Hi Roman, Another thing to keep in mind for after 1.0 is that the scopedef is very difficult to work with. When I write class_.member_function("foobar"), I expect either a value or None to be returned. I don't expect an exception to be thrown likewise, I'd like to see class_.member_functions("foobar") to return a list of declarations, zero if no declaration matches. Again, no exception should be through. Then I can take the list and manipulate it like a normal python list. =20 Cheers Ben =20 ________________________________ From: Roman Yakovenko [mailto:rom...@gm...]=20 Sent: Tuesday, December 04, 2007 12:23 AM To: Ben Schleimer Cc: pyg...@li... Subject: Re: [pygccxml-development] Additional attribute functionality =09 =09 On Dec 4, 2007 10:11 AM, Ben Schleimer <bsc...@lu...> wrote: =09 Hi Roman, I have another patch here which contains the previous patch and adds size,align,offset info the correct classes. Again, I hope it makes sense. One thing I would change is more the __read_size/align into the method reading the types and classes. I will apply it later. =20 =09 Maybe it makes sense to have class_t inherit from type_t because they are very similar? =09 =09 You just discovered the awful mistake I made. You are absolutely right - everything should derive from type_t. I cannot fix the mistake, without introducing backward compatibility problems for the users. I prefer to implement this change after official 1.0 release of the project, where I will allow to myself to break it. =09 --=20 Roman Yakovenko C++ Python language binding http://www.language-binding.net/=20 |
From: Roman Y. <rom...@gm...> - 2007-12-04 08:22:49
|
On Dec 4, 2007 10:11 AM, Ben Schleimer <bsc...@lu...> wrote: > Hi Roman, > I have another patch here which contains the previous patch and adds > size,align,offset info the correct classes. > Again, I hope it makes sense. One thing I would change is more the > __read_size/align into the method reading the types and classes. > I will apply it later. > Maybe it makes sense to have class_t inherit from type_t because they are > very similar? > > You just discovered the awful mistake I made. You are absolutely right - everything should derive from type_t. I cannot fix the mistake, without introducing backward compatibility problems for the users. I prefer to implement this change after official 1.0 release of the project, where I will allow to myself to break it. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Roman Y. <rom...@gm...> - 2007-12-04 08:03:44
|
On Dec 4, 2007 5:34 AM, Ben Schleimer <bsc...@lu...> wrote: > This is a followup to Miguel Lobo's patch. > > Hopefully it makes sense.. > It does. I merged the patch into SVN. Thanks -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Roman Y. <rom...@gm...> - 2007-11-29 07:15:11
|
On Nov 29, 2007 1:10 AM, Patrick Hartling <pat...@pr...> wrote: > We have run into a problem with code generated by Py++ involving > pointers to member templates. For example, consider this class: > > class C > { > public: > template<typename T> > T getValue() const > { > return static_cast<T>(mValue); > } > > private: > int mValue; > }; > > The code generated by Py++ to expose C::getValue() will include > something similar to the following: > > typedef int (C::* ptr_type)() const; > ptr_type p = ptr_type(&C::getValue); > > The above does not compile with Visual C++ 7.1, though it does compile > with 8.0 and 9.0. For Visual C++ 7.1, the following syntax must be used: > > typedef int (C::* ptr_type)() const; > ptr_type p = ptr_type(&C::getValue<int>); > > While I do not have a deep familiarity with the C++ standard, > including the template parameter in the pointer-to expression is what > I would try to write if I were coding this up manually. Is the second > form incorrect or just unnecessarily verbose? > > Given that the pointer-to expression without the template parameter > does compile with newer versions of Visual C++, I have to think that > this is a bug in or a limitation of Visual C++ 7.1. If including the > template parameter in the pointer-to expression is valid, could a > change be made to Py++ to include that extra information so that the > code it generates can be built with Visual C++ 7.1? I am aware of this problem and Py++ already contains functionality to solve it. Next code should solve the issue: mb = module_builder_t( ... ) f = mb.mem_fun("C::getValue") f.alias = f.name #use short, user friendly name f.name = f.demangled_name #set name that compiler understands #you need this if you don't use latest SVN version of Py++ and pygccxml f.create_with_signature = True The problem is that GCCXML reports C::getValue as is, instead of C::getValue<int>, so Py++ uses magled name of the function to extract the real name. P.S. Before I make this behavior to be default, I prefer to get feedback from the users, whether it works fine or not in all their use-cases. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Patrick H. <pat...@pr...> - 2007-11-28 23:13:17
|
We have run into a problem with code generated by Py++ involving pointers to member templates. For example, consider this class: class C { public: template<typename T> T getValue() const { return static_cast<T>(mValue); } private: int mValue; }; The code generated by Py++ to expose C::getValue() will include something similar to the following: typedef int (C::* ptr_type)() const; ptr_type p = ptr_type(&C::getValue); The above does not compile with Visual C++ 7.1, though it does compile with 8.0 and 9.0. For Visual C++ 7.1, the following syntax must be used: typedef int (C::* ptr_type)() const; ptr_type p = ptr_type(&C::getValue<int>); While I do not have a deep familiarity with the C++ standard, including the template parameter in the pointer-to expression is what I would try to write if I were coding this up manually. Is the second form incorrect or just unnecessarily verbose? Given that the pointer-to expression without the template parameter does compile with newer versions of Visual C++, I have to think that this is a bug in or a limitation of Visual C++ 7.1. If including the template parameter in the pointer-to expression is valid, could a change be made to Py++ to include that extra information so that the code it generates can be built with Visual C++ 7.1? -Patrick -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ |
From: Patrick H. <pa...@in...> - 2007-10-15 22:46:01
|
We have run up against a problem with code generated by Py++ that involves a very specific combination of circumstances. The attached code shows how to repeat the errors, but the short explanation is that combining the following results in code that does not compile: * A class with a non-public destructor * A const member function in that class that returns one or more values through by-reference parameters * A function transformation to get the by-reference values returned as a tuple What happens is that the wrapper function generated to create the tuple takes its "self" argument by const reference rather than by reference or by pointer. For reasons that I have not yet determined, Boost.Python wants to delete objects that are passed by const reference in this scenario. For regular r-values, that *might* be OK, but not in this case for two reasons: 1) the parameter that would be deleted is the C++ object on which we are operating and 2) the object's class has no public destructor. Is there a workaround that we can apply to handle this situation? So far, we have not been able to figure out any other use of a function transformation that would address this case. What we need to do is remove the const modifier from the "self" parameter. Strictly speaking, I am not sure that this is a Py++ problem. A very closely related issue arose a while back where I wanted to generate code for a method that takes an object by const reference that has no public destructor. Boost.Python decides that the r-value being passed by const reference needs to be deleted explicitly, but that cannot happen because the destructor is not public. The object destruction should not need to happen anyway. -Patrick -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ |
From: Roman Y. <rom...@gm...> - 2007-09-18 20:47:24
|
On 9/14/07, Neal Becker <ndb...@gm...> wrote: > > def write(self): > target_dir = os.path.split( self.file_name )[0] > > This fails if file_name doesn't have a dir component. Thanks for bug reporting, the fix in SVN -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Neal B. <ndb...@gm...> - 2007-09-14 21:24:51
|
def write(self): target_dir = os.path.split( self.file_name )[0] This fails if file_name doesn't have a dir component. |
From: Roman Y. <rom...@gm...> - 2007-08-22 05:22:51
|
On 8/21/07, Allen Bierbaum <al...@vr...> wrote: > Do you have a link to some documentation about this mode? The interactive mode comes with documentation: > python -m pstats % help That's all you need to know to start. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |