|
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 - |
