From: James G. S. (jim) <jg...@sa...> - 2007-12-20 05:22:15
|
Raphael Ackermann wrote: > Hello everybody, > > Disclaimer: I haven't written a single line of python code yet, so > everything I say might be wrong. > > When trying to explore the gramps code base to fix an accelerator bug > in the "Select Place" dialog I realized that I was too used to having > an IDE for programming and decided to install Eclipse and PyDev, an > Eclipse plugin for python. After some configuration I imported the > gramps project as checked out with svn. > > Building gramps resulted in a about 300 errors and 2000 warnings. That > surprised me as I wasn't expecting that many errors. After all gramps > 3.0 can be started and doesn't crash every minute. Looking at the > errors gave some interesting results as far as I can tell. > > There are > > 2 "Duplicated signature" errors. dump_marriage is defined twice in > plugins/FamilyGroup.py Could it be that somebody forgot to delete the > 2nd occurence of this method? > 50 "Method X should have self as first parameter". Most of these are > in test directories, but there are some in "regular" files too. I > cannot judge whether these are false errors in Eclipse or whether they > should be fixed. > 93 "Undefined variable from import: VariableX" I figured that these > could be mostly ignored. > 23 "Unresolved import: Y" These can sometimes be resolved by adding a > from X import Y. > 92 "undefined variable: VariableX" There is at least one, that I > think is a bug. In Arghandler.py there is a line > > except CompressError, msg: > print "Error uncompressing archive:", msg > sys.exit(1) > > and CompressError is not defined and does not appear in any other py > files in gramps. There is however a similarly named class in > tarfile.py see below > class CompressionError(TarError): > """Exception for unavailable compression methods.""" > pass > > I suppose what I am trying to say is that bugs like these could be > easily found by an IDE like Eclipse. The code in question would only > be executed in case of an error which is not very likely to happen and > so could have remained undiscovered for much longer. > > I've attached the errors and warning messages below, in the hope that > they might prove helpful/interesting reading. (email got too long so > haven't done this, but could upload the error messages somewhere if > there is interest) > I'll have a go at responding. Ralph, there may be a number of reasons that those warnings and errors are generated. One might be that you (or eclipse) left out some preparatory step such as running autogen.sh or make. Or maybe not, since you use the term "build". Even if a good portion of errors and warnings are eliminated by this possibility, it is still valid to raise questions as you have. Another might be that some of the program files are work-in-progress, possibly ported code from an earlier version that "haven't been completed" or "haven't been cleaned up yet", or some other explanation that frankly is more of an excuse than a real reason. Another might be that some productive programmer(s) might have been focused on getting his ideas down, and working in some kind of "stream-of-coding "mode with the understanding that although the code was checked in, that it was not fully ready for release. Some of the code modules or portions thereof may even be preliminary (unused) code waiting to be "hooked" in. It is even conceivable that eclipse or the pydev plugin made some mistakes. ==> The bottom line, though, is that such warnings and errors are likely valid things to pay attention to. Programming tools such as pychecker and pylint will confirm some of the same points you raise. (Have confirmed.) So, I would say you have already done a valuable service reminding us of these conditions. I don't know if others might be using eclipse and/or pydev but I wouldn't be surprised if it just happens that no one has done what you did (or hasn't done it recently). In a large project such as the Linux kernel, they have "janitors" that spend all their time going around looking for warnings (and other symptoms of questionable code) -- such contributors are very valuable part of the picture, despite (or sometimes because of) having less expertise than some of the lead programmers. In this particular case, (I would say) a good contribution could be made even better as follows: 1) make sure nothing was skipped or that the tool wasn't being misused 2) collect and prioritize errors and warnings by program module (and related modules) 3) fix and document or propose fixes, where understood and obvious 4) nag developers about making progress on the rest! Really. (maybe others have additional suggestions) Speaking for myself only, I'm not (too) embarrassed or ashamed to admit that I make mistakes, take ill-advised shortcuts, and even do things that seem right at the moment which turn my stomach when I revisit my own code. ;-) So, thanks for the report. If you can take it further, that would be even more of a contribution. Regards, ..jim |