|
From: Matthias B. <ba...@ir...> - 2006-07-05 14:09:23
|
Hi, I have a class with the following static method which can be used to register a callback function "func": static MCallbackId addEventCallback(const MString& event, void (*func)( void* clientData ), void* clientData = NULL, MStatus* ReturnStatus = NULL); Pyplusplus does not generate code for this one even so I did not exclude it explicitly. Basically, this is ok as the function pointer wouldn't work in Python anyway. The thing is just that I don't know *why* it was excluded. Actually I did expect it to show up and that I had to remove it manually (that's what I was about to do) but pyplusplus did something different and I'd just like to know why. So is this a "bug" that it doesn't show up in the generated code or is there some built-in rule that removed it from the output? - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-07-05 14:26:06
|
On 7/5/06, Matthias Baas <ba...@ir...> wrote: > Hi, > > I have a class with the following static method which can be used to > register a callback function "func": > > static MCallbackId addEventCallback(const MString& event, void (*func)( > void* clientData ), void* clientData = NULL, MStatus* ReturnStatus = NULL); > > > Pyplusplus does not generate code for this one even so I did not exclude > it explicitly. Basically, this is ok as the function pointer wouldn't > work in Python anyway. The thing is just that I don't know *why* it was > excluded. Actually I did expect it to show up and that I had to remove > it manually (that's what I was about to do) but pyplusplus did something > different and I'd just like to know why. > So is this a "bug" that it doesn't show up in the generated code or is > there some built-in rule that removed it from the output? Please take a look on decl_wrappers.calldef_t._exportable_impl function (http://svn.sourceforge.net/viewcvs.cgi/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/calldef_wrapper.py?view=markup) It contains code, that checks different conditions, whether function exportable or not. And if not it returns the reason. Using decl_wrapper.decl_wrapper_t.why_not_exportable method, you can find out why a declaration could not be exported. ( http://svn.sourceforge.net/viewcvs.cgi/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/decl_wrapper.py?view=markup ) decl_wrapper.decl_wrapper_t.ignore is calculated property, so when declaration is not exportable, it returns True, thus forcing pyplusplus to skip the declaration. The problem is that, I still looking for a good way to give this information to the user. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Matthias B. <ba...@ir...> - 2006-07-05 15:03:55
|
Roman Yakovenko wrote: > Please take a look on decl_wrappers.calldef_t._exportable_impl function > (http://svn.sourceforge.net/viewcvs.cgi/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/calldef_wrapper.py?view=markup) > > It contains code, that checks different conditions, whether function > exportable or not. > And if not it returns the reason. > > Using decl_wrapper.decl_wrapper_t.why_not_exportable method, you can > find out > why a declaration could not be exported. > ( > http://svn.sourceforge.net/viewcvs.cgi/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/decl_wrapper.py?view=markup > > ) ok, I could add a loop at the end of my script that iterates over all declarations and checks if readme() returns anything else than an empty list and then report those messages.... which is not really ideal. > The problem is that, I still looking for a good way to give this > information to the user. In the above example of _exportable_impl() you already have implemented a second way of reporting issues which I would prefer. The message about the MAX_ARITY thing is not returned but is written to a logger. In my opinion, the other messages should also be directed into some logger so that they appear in the console or in a file. In general, pyplusplus should tell the user about every built-in logic it has applied to some situation (like the above, for example). Or at least the user should have the chance to be informed about them. This has the advantage that 1) it will teach new users how Boost.Python and pyplusplus work and what they do about particular C++ constructs and 2) a user can look up why something didn't turn out to be as he had expected. Whenever the result of running pyplusplus is not as expected, the user has questions about it. In my case, the question was "Why didn't addEventCallback() show up in the generated code?". Now we have to find a way how questions like this can be answered quickly by pyplusplus itself. There are certainly more types of questions a user can have, but I think most of them will all have in common that they refer to one particular (or a group of) declarations that are usually given by name. So given the name of a declaration it should be possible to quickly determine all "interesting" things that pyplusplus has to say about that declaration. One straightforward possibility would be using 'grep' on a log file that contains the full declaration string and a corresponding message. Each such message should be entirely contained within one line (otherwise it would be awkward to use grep) and there might be more such lines in the log file. This is already how I can filter out the decorations that have been applied to a particular declaration by using the log file that's generated in the experimental version. And so far, this method has proven to be useful for me. - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-07-05 17:56:21
|
On 7/5/06, Matthias Baas <ba...@ir...> wrote: > ok, I could add a loop at the end of my script that iterates over all > declarations and checks if readme() returns anything else than an empty > list and then report those messages.... which is not really ideal. I agree with you! > > The problem is that, I still looking for a good way to give this > > information to the user. I just posted the idea, how to solve this problem in another thread :-) >1) it will teach new users how Boost.Python and > pyplusplus work and what they do about particular C++ constructs This is one of the goals of py++ and this is why it has small and simple GUI! New comers to boost can use it as a guide to boost.python library. > and 2) > a user can look up why something didn't turn out to be as he had expected. I learned, that "surprise" is the last thing that users want, when they use code generator, so writing the information into source file is a good idea. > Whenever the result of running pyplusplus is not as expected, the user > has questions about it. In my case, the question was "Why didn't > addEventCallback() show up in the generated code?". Now we have to find > a way how questions like this can be answered quickly by pyplusplus > itself. There are certainly more types of questions a user can have, but > I think most of them will all have in common that they refer to one > particular (or a group of) declarations that are usually given by name. > So given the name of a declaration it should be possible to quickly > determine all "interesting" things that pyplusplus has to say about that > declaration. One straightforward possibility would be using 'grep' on a > log file that contains the full declaration string and a corresponding > message. Each such message should be entirely contained within one line > (otherwise it would be awkward to use grep) and there might be more such > lines in the log file. This is already how I can filter out the > decorations that have been applied to a particular declaration by using > the log file that's generated in the experimental version. And so far, > this method has proven to be useful for me. Do you mind to review and correct py++ messages? Thanks -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Matthias B. <ba...@ir...> - 2006-07-06 11:55:15
|
Roman Yakovenko wrote: > Do you mind to review and correct py++ messages? How should messages be handled internally? There are the loggers but where do the messages for the source files come from (and go)? (also see the other thread) - Matthias - |
