That's awesome! One brief note is that the fortran stubs generator doesn't acquiesce to social shaming and as such its output should probably be ignored. :)
- Peter On Thu, Jan 17, 2013 at 4:05 PM, Karl Rupp <rupp at mcs.anl.gov> wrote: > Hello again, > > I've set up a couple of scripts checking for compliance with the coding > styles and started with the removal of tabs. There's also a little page set > up for tracking the current progress (i.e. the work left to be done): > > http://krupp.iue.tuwien.ac.at/**petsc-style/<http://krupp.iue.tuwien.ac.at/petsc-style/> > The page is automatically generated from a bash script calling the various > checker scripts and may be run nightly via a cron job. Further details on > the violations can be found when clicking on the number of violations > found. My goal is to reach 'all green' within the next couple of days and > then to integrate the 'most failsafe' scripts into Mercurial. > > I'm also thinking about a similar simple overview page for the nightly > tests, but that's a different story... > > Best regards, > Karli > > > > > On 01/15/2013 02:47 PM, Barry Smith wrote: > >> >> On Jan 15, 2013, at 2:42 PM, Karl Rupp <rupp at mcs.anl.gov> wrote: >> >> Dear all, >>> >>> quoting a recent commit: >>> >>> BarryFSmith committed 16 hours ago (raw commit) >>>> >>>> silly code formatting problems; some people still need to read the >>>> style guide >>>> >>> >>> So we have a style guide that is partially respected, partially ignored. >>> Some things are pretty hard to check automatically, while others are rather >>> simple. So let's pick >>> "No tabs are allowed in any of the source code." >>> as an example and run >>> >>> $petsc-dev/src> find . -name *.h -type f | xargs grep -P '\t' | wc -l >>> >>> to pick the number of violations in .h-files. I get 3215 hits, which is >>> still small compared to the 8797 hits in .c-files. >>> >> >> It takes little more time to fix the problem then detect it :-) >> >>> >>> So, what can we do to reduce the number of violations of the style guide >>> and keep the number of violations as small as possible in the future? >>> >>> - First and foremost, eliminate (as many of the) existing violations (as >>> possible) and come to a clean state. >>> >> >> Yes >> >>> >>> - Run pre-push-scripts on bitbucket on the diff. They may not find all >>> violations, but at least check for the most obvious ones. >>> >> >> Yes. Jed is too in love with Git to ever do this so you have to. >> >>> >>> - Add nightly tests on the source tree. We can compare the output of a >>> properly configured uncrustify against the existing source files and >>> complain on a mismatch. >>> >> >> The problem is that uncrustify is exactly the PETSc style so we >> can't do that comparison automatically. Otherwise we would just run >> uncrustify on all pushes. >> >> >>> Unless there are objections, I'm willing to devote some time on that >>> while playing with options for a better testing environment. I don't think >>> that a full elimination of all violations is ever possible nor reasonably >>> attainable. However, a reduction of violations simplifies the handling of >>> the code base considerably and is thus worth the effort. >>> >> >> Yes >> >> >>> Best regards, >>> Karli >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130117/56d5ac0c/attachment.html>