On 2009-09-23 22:09-0700 Alan W. Irwin wrote:
> I have compared revisions 10470 and 10456 with the coloured differences
> webpages I mentioned before (i.e.,
> http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/src/<filename>?view=diff&r1=10470&r2=10456&diff_format=h)
> where <filename> is plarc.c, etc.
>
> I am now in the process of looking at all *.h and *.c files in src using the
> above URL template. At this point I have made it through plcont.c (in
> alphabetical order), and so far I like everything I see.
I got all the way through plgridd.c before I became too bored to continue.
The point it took me a while to realize was the above coloured diff ignores
whitespace changes on the line so it only picks out "big" changes such as
code lines being split (hanging "{" moved to next line), blank lines being
dropped, and nonwhitespace changes such as asterisks starting every
continued comment line. What I did look at gave a very strong indication
that uncrustify is now doing all of these "big" changes correctly (unlike
before where there were some ugly split lines). I have spot checked in a few
files that the whitespace style changes also look good, but mostly at this
point for the whitespace style changes we are relying on Andrew's judgement
that what uncrustify is producing now is fine.
I don't have strong opinions about coding style so I am willing to go along
with whatever Andrew feels is correct here, but those who feel more strongly
than I do should look at some of your favorite code in src to be sure you
are willing to go along with the style currently being enforced by
uncrustify.cfg.
To reword what I said last night, I don't anticipate any further changes on
my part to uncrustify.cfg. Therefore, over to you, Andrew, for
double-checking the C++ style changes that uncrustify makes in bindings/c++,
and committing those changes if you are happy with what you see.
I would now like to move to a related topic which is getting consistent
results from uncrustify on various platforms. (Previous experience left open
the nasty possibility that Andrew's uncrustify runs produced slightly
different results than mine.)
I produced the current committed results in src by running
(for SRC in *.h *.c; do echo $SRC; $UNCRUSTIFY -q -c ../uncrustify.cfg -l c
<$SRC >| /tmp/$SRC; mv -f /tmp/$SRC . ; done)
$UNCRUSTIFY is the full path name of the uncrustify-0.53 executable that I
built and installed myself using Debian stable gcc (Version Debian
4.3.2-1.10). (UNCRUSTIFY=/home/software/uncrustify/install/bin/uncrustify in
my case). Note, I was careful to commit the exact uncrustify.cfg I used to
produce the current src results so Andrew _should_ find when he runs the above
command that there are absolutely no differences in the results.
Note if there are still some differences in the results between our
platforms using the same source code to build the executable, it might be
due to differences in the C library (uncrustify has no other special library
dependencies) or compiler differences between the platforms. Also, there
might be some memory management issues that are generating different results
on different platforms. However, I tested that possibility for plcore.c
(our largest chunk of source code in src) by running
valgrind /home/software/uncrustify/install/bin/uncrustify -q
-c ../uncrustify.cfg -l c <plcore.c >/dev/null
That produced absolutely clean (both errors and leaks) results.
In any case, if there is some platform inconsistency in results produced by
uncrustify, then we should make a small C code test case that demonstrates
this and report the issue to the uncrustify mailing list (including a valgrind
run on the test code).
Hopefully, though, our previous inconsistent results were a false alarm and
Andrew gests consistent results with mine now so we can put this concern to
rest.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
