Dear coreboot folks,
searching for a way to automatically find misspellings I found a post by Jim Meyering on Fedora’s devel list [1], where he suggests to use the project misspellings [2].
Testing this with a simple
$ find src/coreboot/ -name '*.c' | ./misspellings -f -
it indeed finds a lot of misspelling in our code, but as expected there are also false positives. I am going to send in a patch with the fixes after reviewing the list to omit the false positives.
The question is, how to hook this up into our infrastructure. Jim suggests a `make check` rule. The downside is that this would need to be run manually by the user. Running it automatically on every commit by placing a script in `util/lint` to only check changed files would be feasible, but possible false positives are a problem though.
Do you have an idea, how to work around this problem? There is the `--no-verify` switch for `git commit` to not run the hooks, but this also ignores the commit-msg hooks, which then is not able to add a Change-Id for Gerrit.
Thanks,
Paul
[1] https://lists.fedoraproject.org/pipermail/devel/2012-June/168159.html [2] http://github.com/lyda/misspell-check
Paul Menzel wrote:
The question is, how to hook this up into our infrastructure.
As I've mentioned several times: We either have a requirement, or we do not.
If we introduce a requirement for spellchecking then the spellchecker will run as part of verification.
If it runs as part of verification then nobody will bother running it manually. This should be obvious, but is also well-known from experience with abuild.
//Peter
I've red that spell checkers can make contextual errors. Its possible that it's model might be not sophisticated enough.
ron
Am Samstag, den 29.06.2013, 18:21 +0200 schrieb Peter Stuge:
Paul Menzel wrote:
The question is, how to hook this up into our infrastructure.
As I've mentioned several times: We either have a requirement, or we do not.
If we introduce a requirement for spellchecking then the spellchecker will run as part of verification.
I agree. The false positives are the problem. It is the same problem with whitespace errors as there seem to be cases like in patch files, where they are needed [1]. With these problems it is hard to at least hook it up into Jenkins. Or what did I miss.
If it runs as part of verification then nobody will bother running it manually. This should be obvious, but is also well-known from experience with abuild.
Thanks,
Paul
Paul Menzel wrote:
With these problems it is hard
It should come as no great surprise that machines are still quite infantile when it comes to interpreting human output.
//Peter
Am Samstag, den 29.06.2013, 20:49 +0200 schrieb Peter Stuge:
Paul Menzel wrote:
With these problems it is hard
It should come as no great surprise that machines are still quite infantile when it comes to interpreting human output.
So what is the solution then? (Sorry, if I overlooked it.) Hook it up in the pre-commit hook and on error, tell people to double check and if it is a false positive to use the `--no-verify` switch?
Thanks,
Paul
Paul Menzel wrote:
With these problems it is hard
It should come as no great surprise that machines are still quite infantile when it comes to interpreting human output.
So what is the solution then? (Sorry, if I overlooked it.)
Start the discussion by asking *if* we want a stupid automated test, not how to implement.
//Peter
On Sat, Jun 29, 2013 at 12:01 PM, Paul Menzel paulepanter@users.sourceforge.net wrote:
So what is the solution then?
that we, all of us, be granted the serenity to accept the things we cannot change, The courage to change the things we can, And wisdom to know the difference.
ron
-
Paul Menzel -
Peter Stuge -
ron minnich