Thread: [pygccxml-development] improving user experience
Brought to you by:
mbaas,
roman_yakovenko
Menu
▾
▴
pygccxml-development
|
From: Roman Y. <rom...@gm...> - 2006-07-05 17:48:15
|
Hi. I think I found the solution to the problem.
The problem is that there is a lot of information, that pyplusplus has
to say to user,
while it generates the code.
The solution I found is pretty simple and consist from few improvements:
1. Every declaration that user asked to export will be exported. Those
declarations
that could not be exported will be commented out and description of the
problem will be provided. Thus when developer will get question from a user:
why you did not exported declaration "X", developer will be able to go to
generated file and to read an explanation.
2. The monolithic loggers were a mistake. Both pygccxml and py++ will have
loggers hierarchy:
pygccxml logger as root + gccxml logger, performance or query logger
pyplusplus will also has additional loggers.
Thus developer will have better control on information, he wants to get from
py++.
Thoughts?
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
|
From: Matthias B. <ba...@ir...> - 2006-07-06 11:50:14
|
Roman Yakovenko wrote: > 1. Every declaration that user asked to export will be exported. Those > declarations > that could not be exported will be commented out and description of the > problem will be provided. Thus when developer will get question from a user: > why you did not exported declaration "X", developer will be able to go to > generated file and to read an explanation. Good idea! In my case this would have answered my question before I was even posing it (as the first thing I did was to have a look in the generated source file to check if the method is there). > 2. The monolithic loggers were a mistake. Both pygccxml and py++ will have > loggers hierarchy: > pygccxml logger as root + gccxml logger, performance or query logger > pyplusplus will also has additional loggers. > > Thus developer will have better control on information, he wants to get from > py++. Agreed! Now the question is how many loggers are needed, what is their name, where can we get away with separate log levels instead of separate loggers, etc.? - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-07-11 09:13:47
|
Hi. I just committed a set of changes, that should improve usability of pyplusplus. To be more specific: by default only important messages are send to the user: 1. gccxml invocation command line ( info ) 2. warning about declaration, that could not be exported If you want to see all information, that py++ have to say you can change logger level to DEBUG: import logging import module_builder module_builder.set_logger_level( logging.DEBUG ) I did not implemented the original idea: to write as comment declarations that could not be exported - too much work. I'd like to get feedback about current situation. If the situation is still bad, I will do that. Thanks -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Matthias B. <ba...@ir...> - 2006-07-17 09:15:08
|
Roman Yakovenko wrote: > Hi. I just committed a set of changes, that should improve usability > of pyplusplus. > To be more specific: by default only important messages are send to the > user: > 1. gccxml invocation command line ( info ) > 2. warning about declaration, that could not be exported I've noticed two things: - Even though there are several logging streams now I think warning message should still be issued using warning() instead of info() (so that I can set up a file handler at the root logger that only writes true warnings). For example, in calldef_t._exportable_impl() the message about the max_arity thing is still written using info(). Roman, do you mind if I change that to warning()? - Most warnings are still "hidden" from the user until he explicitly obtains them using the readme() method. I did a test and modified the code in decl_wrapper_t.get_exportable() so that any time self._exportable_reason is set to a non-empty string this string is also written to the logger. What I don't know is if the "exportable" attribute will always be obtained by pyplusplus internally, i.e. if get_exportable() will always be called or not. By running my Maya stuff it seems to be the case as I got much more warnings. So should I check that in as well? And are there other methods that create warning/error messages that are only returned as strings instead of being written to a logger? A lot of the above new warnings are about compiler generated constructors (it always seems to be the copy constructor in my case). Is this really worth a message at all? I certainly don't expect pyplusplus to generate wrappers for things that are not there, so I think pyplusplus could just silently ignore those artifical declarations that are only created by gccxml (I don't really know why they are generated at all?). - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-07-17 10:24:10
|
On 7/17/06, Matthias Baas <ba...@ir...> wrote: > Roman Yakovenko wrote: > > Hi. I just committed a set of changes, that should improve usability > > of pyplusplus. > > To be more specific: by default only important messages are send to the > > user: > > 1. gccxml invocation command line ( info ) > > 2. warning about declaration, that could not be exported > > I've noticed two things: > > - Even though there are several logging streams now I think warning > message should still be issued using warning() instead of info() (so > that I can set up a file handler at the root logger that only writes > true warnings). For example, in calldef_t._exportable_impl() the message > about the max_arity thing is still written using info(). Roman, do you > mind if I change that to warning()? Please do it. > - Most warnings are still "hidden" from the user until he explicitly > obtains them using the readme() method. I did a test and modified the > code in decl_wrapper_t.get_exportable() so that any time > self._exportable_reason is set to a non-empty string this string is also > written to the logger. What I don't know is if the "exportable" > attribute will always be obtained by pyplusplus internally, i.e. if > get_exportable() will always be called or not. Yes. Please take a look on _get_ignore method. It will be always called from it. > By running my Maya stuff > it seems to be the case as I got much more warnings. So should I check > that in as well? I don't understand, sorry. What do you want to check/fix? >And are there other methods that create warning/error > messages that are only returned as strings instead of being written to a > logger? decl_wrappers.decl_wrapper_t derived classes should not directly write to log. Instead of this, they should implement _exportable_impl method, that will return string( explanation ) if declaration could not be exported and None if it could. > A lot of the above new warnings are about compiler generated > constructors (it always seems to be the copy constructor in my case). Is > this really worth a message at all? I certainly don't expect pyplusplus > to generate wrappers for things that are not there, so I think > pyplusplus could just silently ignore those artifical declarations that > are only created by gccxml (I don't really know why they are generated > at all?). I thought, I disabled them. I will check one more time. Can you check, whether you are running with latest version? Thanks -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Matthias B. <ba...@ir...> - 2006-07-17 14:22:26
|
Roman Yakovenko wrote:
>> - Even though there are several logging streams now I think warning
>> message should still be issued using warning() instead of info() (so
>> that I can set up a file handler at the root logger that only writes
>> true warnings). For example, in calldef_t._exportable_impl() the message
>> about the max_arity thing is still written using info(). Roman, do you
>> mind if I change that to warning()?
>
> Please do it.
Done.
>> - Most warnings are still "hidden" from the user until he explicitly
>> obtains them using the readme() method. I did a test and modified the
>> code in decl_wrapper_t.get_exportable() so that any time
>> self._exportable_reason is set to a non-empty string this string is also
>> written to the logger.
>> [...]
>> A lot of the above new warnings are about compiler generated
>> constructors (it always seems to be the copy constructor in my case). Is
>> this really worth a message at all? I certainly don't expect pyplusplus
>> to generate wrappers for things that are not there, so I think
>> pyplusplus could just silently ignore those artifical declarations that
>> are only created by gccxml (I don't really know why they are generated
>> at all?).
>
> I thought, I disabled them. I will check one more time. Can you check,
> whether you are running with latest version?
Yes, I have updated earlier today. I did see those messages because of
my own modification that prints every _exportable_reason that is not empty.
Now I've seen your __report_warning() method and realized that the
messages actually should already have appeared in the logger. But
because I only saw 5 messages whereas my code from above printed many
more I thought the user has to call something like readme() himself.
The problem is in __report_warning() which I'd say has a bug. The method
has the following lines right at the beginning:
if reason in decl_wrapper_t.ALREADY_REPORTED_MSGS:
return
decl_wrapper_t.ALREADY_REPORTED_MSGS.add( reason )
But the string "reason" only contains the "raw" message and doesn't
contain anything that is unique to the current declaration. This means
if there is another declaration that cannot be exported for the same
reason, then the warning message for the second declaration will be
suppressed (even though this is a new message as it refers to a
different declaration).
So instead of storing "reason" in ALREADY_REPORTED_MSGS this should
rather be "msg" (which contains the declaration string). Or maybe it
would be more efficient if only a reference to the declaration is stored
instead of an entire string (or can a declaration have more than one
"reason" messages?).
- Matthias -
|
|
From: Roman Y. <rom...@gm...> - 2006-07-17 14:43:02
|
On 7/17/06, Matthias Baas <ba...@ir...> wrote: > Roman Yakovenko wrote: > >> - Even though there are several logging streams now I think warning > >> message should still be issued using warning() instead of info() (so > >> that I can set up a file handler at the root logger that only writes > >> true warnings). For example, in calldef_t._exportable_impl() the message > >> about the max_arity thing is still written using info(). Roman, do you > >> mind if I change that to warning()? > > > > Please do it. > > Done. Thank you! > Yes, I have updated earlier today. I did see those messages because of > my own modification that prints every _exportable_reason that is not empty. > Now I've seen your __report_warning() method and realized that the > messages actually should already have appeared in the logger. But > because I only saw 5 messages whereas my code from above printed many > more I thought the user has to call something like readme() himself. > The problem is in __report_warning() which I'd say has a bug. The method > has the following lines right at the beginning: > > if reason in decl_wrapper_t.ALREADY_REPORTED_MSGS: > return > decl_wrapper_t.ALREADY_REPORTED_MSGS.add( reason ) > > But the string "reason" only contains the "raw" message and doesn't > contain anything that is unique to the current declaration. This means > if there is another declaration that cannot be exported for the same > reason, then the warning message for the second declaration will be > suppressed (even though this is a new message as it refers to a > different declaration). Good catch, I did not think about this at all. > So instead of storing "reason" in ALREADY_REPORTED_MSGS this should > rather be "msg" (which contains the declaration string). Or maybe it > would be more efficient if only a reference to the declaration is stored > instead of an entire string Yes. It will be enough. >(or can a declaration have more than one "reason" messages?). Yes and no. Yes - one function could have many problems. No - actually any message indicates that this declaration has some "fatal" error. Also I completely forgot about "readme" functionality. May be my approach is wrong. May be I need to change the code. I think, that instead of reporting warning from "ignore" property, I need to report it from module_creator/creator.py file. What do you think? If you think, that this approach is better and you have time to implement it, please implement it. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Matthias B. <ba...@ir...> - 2006-07-17 15:16:25
|
Roman Yakovenko wrote: > Also I completely forgot about "readme" functionality. May be my > approach is wrong. > May be I need to change the code. I think, that instead of reporting > warning from > "ignore" property, I need to report it from module_creator/creator.py file. > > What do you think? Well, I have to admit that I actually was somewhat surprised to see the __report_warning() message being invoked when accessing the "ignore" property but then, as long as it works..... But it does sound reasonable to me if problems are reported when the code creator tree is created, so maybe this would make the code more clear. By the way, when exactly is _exportable_impl() called (or when is the exportable property accessed)? Would it also be an option to log a warning message right at the place where it is created? (this is probably what I would have done in the first place) Or is the generated message string used for something else as well? Or is "exportable" already accessed somewhen before the user actually ignored the declaration? (so that the message should not be printed) - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-07-17 17:58:27
|
On 7/17/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > Also I completely forgot about "readme" functionality. May be my
> > approach is wrong.
> > May be I need to change the code. I think, that instead of reporting
> > warning from
> > "ignore" property, I need to report it from module_creator/creator.py file.
> >
> > What do you think?
>
> Well, I have to admit that I actually was somewhat surprised to see the
> __report_warning() message being invoked when accessing the "ignore"
> property but then, as long as it works.....
It was ugly hack, that does not work :-(.
> But it does sound reasonable to me if problems are reported when the
> code creator tree is created, so maybe this would make the code more clear.
I agree.
> By the way, when exactly is _exportable_impl() called
1. When pyplusplus asks for ignore property value. This is happen from code
creators factory. ( That is why I introduced the hack )
2. When user calls for
readme method
exportable property
why_not_exportable property
> (or when is the
> exportable property accessed)? Would it also be an option to log a
> warning message right at the place where it is created? (this is
> probably what I would have done in the first place)
You mean during construction, right? It is not possible. The main
reason for this
is that construction is done in 2 steps ( scanner and linker )
> Or is the generated message string used for something else as well?
No. It's main purpose it to be printed to user.
> Or is "exportable" already accessed somewhen before the user actually
> ignored the declaration? (so that the message should not be printed)
No. I don't think so, but we should be careful to not print same message ( from
same declaration ) twice.
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
|
From: Matthias B. <ba...@ir...> - 2006-07-20 14:30:37
|
Hi, I've noticed that in r317 the location where warnings are generated was moved to creator_t. But with this modification I don't get any warning at all anymore which is not correct. I had a look at the source and only got so far that the list "decls" (after calling make_flatten()) in _prepare_decls() only contains the stuff that is directly in the main namespace (in my case, these are mainly the SDK classes and a few functions). The actual methods of the classes are missing which is why I get no warning message. If I interpret the source code correctly the problem seems to be that class_declaration_t is not derived from scopedef_t anymore (I vaguely remember that there has been a commit message which stated that this was changed, but I'm not sure anymore). That modification had a side effect on make_flatten() that it doesn't work anymore because it only descends the tree if a node is derived from scopedef_t. I'm not sure if this is the true reason for the problem, but currently it sounds like a reasonable explanation to me. - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-07-20 17:55:42
|
On 7/20/06, Matthias Baas <ba...@ir...> wrote:
> Hi,
>
> I've noticed that in r317 the location where warnings are generated was
> moved to creator_t. But with this modification I don't get any warning
> at all anymore which is not correct.
> I had a look at the source and only got so far that the list "decls"
> (after calling make_flatten()) in _prepare_decls() only contains the
> stuff that is directly in the main namespace (in my case, these are
> mainly the SDK classes and a few functions). The actual methods of the
> classes are missing which is why I get no warning message.
>
Yes. Read carefully the code :-)
#leave only declarations defined under namespace, but remove namespaces
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
decls = filter( lambda x: not isinstance( x, declarations.namespace_t ) \
and isinstance( x.parent,
declarations.namespace_t )
, decls )
That is why member functions was not in the list.
I am sorry for introducing such stupid bug. I think I fixed it. I
added unittest.
Sorry. Can you check the behaviuor now?
Thank you.
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
|
From: Matthias B. <ba...@ir...> - 2006-07-21 10:00:57
|
Roman Yakovenko wrote:
> I am sorry for introducing such stupid bug. I think I fixed it. I
> added unittest.
> Sorry. Can you check the behaviuor now?
The warnings are back and now I seem to get all of them.
I have a slight suggestion for an improvement though, in creator.py line
158 the message is prepared like this:
msg = [ 'Declaration "%s" could not be exported.' % full_name ]
That is, the message only contains the name of the declaration (which is
not unique) and sometimes it seems pyplusplus would output several
identical messages (which actually refer to different versions of
overloaded methods but as only the name is printed this is not visible).
So could we just change this to:
msg = [ 'Declaration "%s" could not be exported.' % decl ]
All the declarations already have a suitable __str__() method that
creates the full signature, so the above makes it much easier to exactly
identify the actual declaration.
- Matthias -
|
|
From: Roman Y. <rom...@gm...> - 2006-07-23 06:04:21
|
On 7/21/06, Matthias Baas <ba...@ir...> wrote: > So could we just change this to: > > msg = [ 'Declaration "%s" could not be exported.' % decl ] > > All the declarations already have a suitable __str__() method that > creates the full signature, so the above makes it much easier to exactly > identify the actual declaration. Done. Tell me please, whether it useful now or not. My main concern is that line is too long now. May be I should devide it. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Matthias B. <ba...@ir...> - 2006-07-23 13:59:04
|
Roman Yakovenko wrote:
> On 7/21/06, Matthias Baas <ba...@ir...> wrote:
>> So could we just change this to:
>>
>> msg = [ 'Declaration "%s" could not be exported.' % decl ]
>>
>> All the declarations already have a suitable __str__() method that
>> creates the full signature, so the above makes it much easier to exactly
>> identify the actual declaration.
>
> Done.
>
> Tell me please, whether it useful now or not.
Yes, thanks!
> My main concern is that line is too long now.
> May be I should devide it.
Personally, I'm against splitting lines. Actually, I'd even prefer to
have the entire warning message in one single line so that I see the
entire message when I 'grep' for a particular declaration.
This would also make it easier to write scripts that further process a
log file (e.g. a filter that transforms the single-line log into an
easier to read log or even a set of html pages).
By the way, now I get the following warnings (among others):
.
.
.
Declaration "MTime & MTime::operator--(int arg0) [member_operator]"
could not be exported.
"operator--" is not supported.
See Boost.Python documentation:
http://www.boost.org/libs/python/doc/v2/operators.html#introduction.
Declaration "MTime & MTime::operator--(int arg0) [member_operator]":
Function "MTime & MTime::operator--(int arg0) [member_operator]" takes
as argument (name=arg0, pos=0 ) non-const reference to C++ fundamental
type - function could not be called from Python.
.
.
.
There are two things that I don't understand here:
1) The second message complains about the first argument being a
non-const reference to a C++ fundamental type. But the first argument is
just an ordinary integer (no reference at all). So what's the problem here?
2) Why does the second warning appear at all? The first warning already
told me that the operator cannot be exported anyway. (If it is
intentional that pyplusplus reports all potential problems then that's
fine with me and I'm not arguing that this should be changed. I'm more
confused about the previous point that I don't understand the second
message)
- Matthias -
|
|
From: Roman Y. <rom...@gm...> - 2006-07-23 14:12:37
|
On 7/23/06, Matthias Baas <ba...@ir...> wrote: > Personally, I'm against splitting lines. Actually, I'd even prefer to > have the entire warning message in one single line so that I see the > entire message when I 'grep' for a particular declaration. > This would also make it easier to write scripts that further process a > log file (e.g. a filter that transforms the single-line log into an > easier to read log or even a set of html pages). Yes, but in this case line is toooooo long. Personally, I can not read it. I have an idea, but I will need your help( =time ). All messages written by py++ will be written in single line. py++ will create custom formatter, that will divide message to few lines and will use it by default. You will be able to use the formatter provided by logging package.It could be nice, if you can find time and implement it. > 1) The second message complains about the first argument being a > non-const reference to a C++ fundamental type. But the first argument is > just an ordinary integer (no reference at all). So what's the problem here? Bug. I will try to fix it this evening. > 2) Why does the second warning appear at all? The first warning already > told me that the operator cannot be exported anyway. (If it is > intentional that pyplusplus reports all potential problems then that's > fine with me and I'm not arguing that this should be changed. Yes, it is intentional. py++ will provide user with all information it has. Thanks for feedback. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Matthias B. <ba...@ir...> - 2006-07-24 14:09:21
|
Roman Yakovenko wrote:
> On 7/23/06, Matthias Baas <ba...@ir...> wrote:
>> Personally, I'm against splitting lines. Actually, I'd even prefer to
>> have the entire warning message in one single line so that I see the
>> entire message when I 'grep' for a particular declaration.
>> This would also make it easier to write scripts that further process a
>> log file (e.g. a filter that transforms the single-line log into an
>> easier to read log or even a set of html pages).
>
> Yes, but in this case line is toooooo long. Personally, I can not read it.
> I have an idea, but I will need your help( =time ). All messages written
> by py++
> will be written in single line. py++ will create custom formatter,
> that will divide
> message to few lines and will use it by default. You will be able to
> use the formatter
> provided by logging package.It could be nice, if you can find time and
> implement it.
Sounds good! I've already played around with this a bit and did some
tests. I have some questions though:
readme() returns a list of strings. What exactly are these strings? Is
each string a separate info/warning message or is the concatenation of
the strings one single warning message? In what way is the first string
special? There is the following code in creator_t._prepare_decls() which
I don't quite understand:
...
if not decl.exportable:
reason = readme[0]
if reason in DO_NOT_REPORT_MSGS:
continue
readme = readme[1:]
msg = [ 'Declaration "%s" could not be exported.' % decl ]
msg.append( reason.replace( os.linesep, os.linesep + '\t' ) )
self.decl_logger.warn( os.linesep.join( msg ) )
for msg in readme:
self.decl_logger.warn( 'Declaration "%s": %s' % ( decl, msg ) )
...
Why is the first string in readme treated differently than the other
strings?
By the way, are there other places where warnings are written to the
logger? (it appears to me that this is the only location)
I've already modified the above so that the log message is one single
line. The line consists of two fields containing the declaration string
and the actual message separated by a colon:
<decl>;<msg>
Additionally I wrote a custom formatter that makes the message more
readable again by splitting the declaration string and message up again
and using the textwrap module to prevent long lines. Example:
WARNING: MTime & MTime::operator--() [member_operator]
->
"operator--" is not supported. See Boost.Python documentation:
http://www.boost.org/libs/python/doc/v2/operators.html#introduction.
WARNING: MTime & MTime::operator--(int arg0) [member_operator]
->
"operator--" is not supported. See Boost.Python documentation:
http://www.boost.org/libs/python/doc/v2/operators.html#introduction.
Or an example of a method that spans several lines:
WARNING: static MCallbackId MUiMessage::addCameraChangedCallback(MString
const
& panelName, void (*)( ::MString &,::MObject &,void * ) * func, void *
clientData=0, MStatus * ReturnStatus=0) [member_function]
->
boost.python can not expose function, which takes as argument/returns
pointer to function. See
http://www.boost.org/libs/python/doc/v2/faq.html#funcptr for more
information.
To make it apparent where a new warning message begins, the actual text
is indented by 2 blanks. The '->' line should make the beginning of the
actual message easier to spot (which otherwise can get difficult with
long declarations).
What is the proper place for the new formatter? Currently, I would put
it into the _logging_ module and use it as formatter for the default
stream logger which goes to stdout.
For my additional custom file logger I would simply use a standard
formatter which leaves everything in one line to make it more
'grep'-friendly. So I guess everyone's happy then! :)
Roman, does this sound good to you and can I commit that stuff or do you
have any objections/suggestions, etc?
- Matthias -
|
|
From: Roman Y. <rom...@gm...> - 2006-07-24 14:26:46
|
On 7/24/06, Matthias Baas <ba...@ir...> wrote: > Sounds good! I've already played around with this a bit and did some > tests. I have some questions though: > > readme() returns a list of strings. What exactly are these strings? This list contains different messages py++ wants to pass to users > Is each string a separate info/warning message or is the concatenation of > the strings one single warning message? Every string( item in the list ) is separate message. This is because we have an hierarchy of declarations. So every level within hierarchy add an information it has. > In what way is the first string > special? There is the following code in creator_t._prepare_decls() which > I don't quite understand: Well, it is some kind of work around, laziness, lack of good idea ,... Please take a look on decl_wrapper_t.readme method. If declaration is not exportable, than the reason will be the first item within the string. > By the way, are there other places where warnings are written to the > logger? (it appears to me that this is the only location) It should be the only place, otherwise this is a bug > I've already modified the above so that the log message is one single > line. The line consists of two fields containing the declaration string > and the actual message separated by a colon: > > <decl>;<msg> Good. > Additionally I wrote a custom formatter that makes the message more > readable again by splitting the declaration string and message up again > and using the textwrap module to prevent long lines. Example: That is exactly what I meant. > > To make it apparent where a new warning message begins, the actual text > is indented by 2 blanks. The '->' line should make the beginning of the > actual message easier to spot (which otherwise can get difficult with > long declarations). Good for you - good for me. > What is the proper place for the new formatter? Currently, I would put > it into the _logging_ module and use it as formatter for the default > stream logger which goes to stdout. Yes. > For my additional custom file logger I would simply use a standard > formatter which leaves everything in one line to make it more > 'grep'-friendly. So I guess everyone's happy then! :) I am glad you find time and implemented this feature. > Roman, does this sound good to you and can I commit that stuff or do you > have any objections/suggestions, etc? No. Please commit the code ASAP :-))))). Thank you very much!!! -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Roman Y. <rom...@gm...> - 2006-07-23 18:52:16
|
On 7/23/06, Matthias Baas <ba...@ir...> wrote: > Declaration "MTime & MTime::operator--(int arg0) [member_operator]" > could not be exported. > "operator--" is not supported. > See Boost.Python documentation: > http://www.boost.org/libs/python/doc/v2/operators.html#introduction. > > Declaration "MTime & MTime::operator--(int arg0) [member_operator]": > Function "MTime & MTime::operator--(int arg0) [member_operator]" takes > as argument (name=arg0, pos=0 ) non-const reference to C++ fundamental > type - function could not be called from Python. Matthias, I tried to reproduce this bug, but I cannot. Can you create small test case? Thank you. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Matthias B. <ba...@ir...> - 2006-07-24 08:47:17
|
Roman Yakovenko wrote: > On 7/23/06, Matthias Baas <ba...@ir...> wrote: >> Declaration "MTime & MTime::operator--(int arg0) [member_operator]" >> could not be exported. >> "operator--" is not supported. >> See Boost.Python documentation: >> http://www.boost.org/libs/python/doc/v2/operators.html#introduction. >> >> Declaration "MTime & MTime::operator--(int arg0) [member_operator]": >> Function "MTime & MTime::operator--(int arg0) [member_operator]" takes >> as argument (name=arg0, pos=0 ) non-const reference to C++ fundamental >> type - function could not be called from Python. > > Matthias, I tried to reproduce this bug, but I cannot. Can you create > small test case? Well, I also get the warnings when I just try to wrap this minimal example: class Foo { public: Foo& operator--(int a); }; Here are the warnings: WARNING Declaration "Foo & Foo::operator--(int a) [member_operator]" could not be exported. "operator--" is not supported. See Boost.Python documentation: http://www.boost.org/libs/python/doc/v2/operators.html#introduction. WARNING Declaration "Foo & Foo::operator--(int a) [member_operator]": Function "Foo & Foo::operator--(int a) [member_operator]" takes as argument (name=a, pos=0 ) non-const reference to C++ fundamental type - function could not be called from Python. I don't know if it's of any help but here's the XML output from gccxml v0.6.0: <?xml version="1.0"?> <GCC_XML> <Namespace id="_1" name="::" members="_3 " mangled="_Z2::"/> <Namespace id="_2" name="std" context="_1" members="" mangled="_Z3std"/> <Class id="_3" name="Foo" context="_1" mangled="3Foo" location="f0:6" file="f0" line="6" members="_4 _5 _6 " bases=""/> <Constructor id="_4" name="Foo" artificial="1" throw="" context="_3" mangled="_ZN3FooC1ERKS_ *INTERNAL* " location="f0:6" file="f0" line="6"> <Argument name="_ctor_arg" type="_7"/> </Constructor> <Constructor id="_5" name="Foo" artificial="1" throw="" context="_3" mangled="_ZN3FooC1Ev *INTERNAL* " location="f0:6" file="f0" line="6"/> <OperatorMethod id="_6" name="--" returns="_8" context="_3" mangled="_ZN3FoommEi" location="f0:8" file="f0" line="8" extern="1"> <Argument name="a" type="_9"/> </OperatorMethod> <ReferenceType id="_7" type="_3c"/> <ReferenceType id="_8" type="_3"/> <FundamentalType id="_9" name="int"/> <CvQualifiedType id="_3c" type="_3" const="1"/> <File id="f0" name="source.h"/> </GCC_XML> By the way, the second message does not appear when I remove the reference from the return value, so it seems pyplusplus somehow mixes those up. - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-07-24 09:11:02
|
On 7/24/06, Matthias Baas <ba...@ir...> wrote: > By the way, the second message does not appear when I remove the > reference from the return value, so it seems pyplusplus somehow mixes > those up. This was the detail I missed :-). This bug is fixed and committed. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Matthias B. <ba...@ir...> - 2006-07-24 16:17:07
|
Roman Yakovenko wrote: >> Roman, does this sound good to you and can I commit that stuff or do you >> have any objections/suggestions, etc? > > No. Please commit the code ASAP :-))))). Done. The _logging_ sub-module now contains a new class multi_line_formatter_t that splits long messages into several lines. The class is used just like the logging.Formatter class. The constructor takes one additional argument 'width' (default: 70) that controls the maximum width of the generated text blocks. What the new formatter actually does is that it modifies the 'message' attribute of a log record (i.e. it inserts newlines based on 'width' using the textwrap module). The new formatter is now used for the default handler that outputs the log messages to stdout. So you don't have to do anything to see the new message layout. If anybody wants to use the formatter for his own handlers you can access the class via pyplusplus.multi_line_formatter_t: I left the code structure in creator_t._prepare_decls() as it is and just converted the messages into single-line messages. Maybe this code could be shortened a bit as the generated message for the first item in readme and the subsequent items are actually identical. - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-07-24 17:26:57
|
On 7/24/06, Matthias Baas <ba...@ir...> wrote: > Done. Thank you! Small comment: I think that now when we have multi line formatter, I will take a look on all messages and will make them single line. This became a rule in py++/pygccxml. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
|
From: Roman Y. <rom...@gm...> - 2006-07-25 06:44:29
|
On 7/24/06, Matthias Baas <ba...@ir...> wrote:
> The _logging_ sub-module now contains a new class multi_line_formatter_t
> that splits long messages into several lines. The class is used just
> like the logging.Formatter class. The constructor takes one additional
> argument 'width' (default: 70) that controls the maximum width of the
> generated text blocks. What the new formatter actually does is that it
> modifies the 'message' attribute of a log record (i.e. it inserts
> newlines based on 'width' using the textwrap module).
1. I changed the name of the file to multi_line_formatter.py. I think this
way it more readable
2. I changed a little bit internal logic + how it devides a messages:
If message is not formatted as we expect, that I just apply wrap
algorithm and return it.
Otherwise, I leave declaration as is. I don't wrap it. All other lines
starts with '>' sign.
My editor ( scite ), is able to give a different color to the message. I
assume other editors
are able to do the same thing too.
WARNING: unnamed_enums::color [variable]
> pyplusplus can not expose unnamed variables
> I left the code structure in creator_t._prepare_decls() as it is and
> just converted the messages into single-line messages.
All messages in py++ are now single line messages. From now this is a rule(
law ).
One more thing, I write documentation for "readme" feature. Can you post a
code, that
change multi_line_formatter_t to default one?
Thank you.
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
|
From: Matthias B. <ba...@ir...> - 2006-07-25 14:47:58
|
Roman Yakovenko wrote: > 2. I changed a little bit internal logic + how it devides a messages: > If message is not formatted as we expect, that I just apply wrap > algorithm and return it. Now you have to ensure that the message part of a line does not contain any colon, otherwise the line won't be split properly. By the way, can you please also update the doc string and comments accordingly? Currently, the doc string (+comment) and the implementation don't match anymore (which is probably worse than having no documentation at all). > One more thing, I write documentation for "readme" feature. Can you post > a code, that change multi_line_formatter_t to default one? Erm, what do you mean? The multi_line_formatter_t class already is the default one...? - Matthias - |
|
From: Roman Y. <rom...@gm...> - 2006-07-25 17:28:50
|
On 7/25/06, Matthias Baas <ba...@ir...> wrote: > Roman Yakovenko wrote: > > 2. I changed a little bit internal logic + how it devides a messages: > > If message is not formatted as we expect, that I just apply wrap > > algorithm and return it. > > Now you have to ensure that the message part of a line does not contain > any colon, otherwise the line won't be split properly. Treated. > By the way, can you please also update the doc string and comments > accordingly? Currently, the doc string (+comment) and the implementation > don't match anymore (which is probably worse than having no > documentation at all). You are absolutly right, I will do the change this evening. > > One more thing, I write documentation for "readme" feature. Can you post > > a code, that change multi_line_formatter_t to default one? > > Erm, what do you mean? The multi_line_formatter_t class already is the > default one...? I mean I'd like to see the code you replace multi_line_formatter_t with formatter from logging package. Or you just replace the whole logger? -- 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