[perl #39824] [CAGE] tools/dev/check_source_standards.pl -- this should be a test
Jerry Gay
# Please include the string: [perl #39824]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39824 >
=head1 NAME
tools/dev/check_source_standards.pl - Check conformancs of C source
code to PDD 7
=head1 SYNOPSIS
% perl tools/dev/check_source_standards.pl file1 [file2 ...]
% perl tools/dev/check_source_standards.pl all_source
=head1 DESCRIPTION
This script checks that the C source code conforms to the standards in
PDD 7.
To run it on all the C source code files in the distribution pass in
C<all_source> instead of a list of files.
=end
this is part of the coding standards, and should be a test under
t/codingstd/. if necessary, it should be updated to follow the coding
standards laid out in PDD07.
~jerry
Paul Cochrane via RT
> ~ all but one test have been adapted for and moved to t/codingstd/
> ~ remaining test is for not-yet-approved codingstd item
The remaining test complains about more than one '.' in a filename and
filenames which don't conform to the 8.3 format. My feeling is that
these should be guidelines but are not strict enough for a test. What
are people's feelings? Allison: do you wish to make a decision about
this particular coding standard item?
Anyway, can this file (check_source_standards.pl) be removed and this
ticket closed?
Paul
Bernhard Schmalhofer
> On Fri Nov 17 14:17:18 2006, particle wrote:
>
>> ~ all but one test have been adapted for and moved to t/codingstd/
>> ~ remaining test is for not-yet-approved codingstd item
>>
>
> The remaining test complains about more than one '.' in a filename and
> filenames which don't conform to the 8.3 format.
For them the "more than one '.'" issue was a real problem, that
they had to work around before even creating a Makefile.
Regards,
Bernhard
Paul Cochrane
> Paul Cochrane via RT schrieb:
> > On Fri Nov 17 14:17:18 2006, particle wrote:
> >
> >> ~ all but one test have been adapted for and moved to t/codingstd/
> >> ~ remaining test is for not-yet-approved codingstd item
> >>
> >
> > The remaining test complains about more than one '.' in a filename and
> > filenames which don't conform to the 8.3 format.
> I have talked to some VMS people at YAPC::EU 2007.
> For them the "more than one '.'" issue was a real problem, that
> they had to work around before even creating a Makefile.
Attached is a test for multiple dot filenames. We have several such
files in the source[1], so I don't know how useful such a test is, and
whether or not it is worth changing the files around. I could handle
having a restriction on the number of dots in filenames but I don't
think we would be able to handle an 8.3 filename format restriction.
Anyway, a decision would be good about this, then I can clean up and
close a couple of annoying tickets.
Paul
[1] Failed files:
1..1
not ok 1 - No multi-dot filenames
# Failed test (t/codingstd/multi_dot.t at line 57)
# Multi-dot filename found in 77 files:
# README.win32.pod
# apps/p3/parrot.small.png
# config/gen/makefiles/parrot.pc.in
# docs/resources/parrot.small.png
# editor/pir.vim.in
# examples/shootout/ack.pir.output
# examples/shootout/binarytrees.pir.output
# examples/shootout/fannkuch.pir.output
# examples/shootout/fasta.pir.output
# examples/shootout/knucleotide.pir.input
# examples/shootout/knucleotide.pir.output
# examples/shootout/mandelbrot.pir.output
# examples/shootout/nbody.pir.output
# examples/shootout/nsieve-bits-2.pir.output
# examples/shootout/nsieve-bits.pir.output
# examples/shootout/nsieve.pir.output
# examples/shootout/partialsums-2.pir.output
# examples/shootout/partialsums.pir.output
# examples/shootout/pidigits.pir.output
# examples/shootout/recursive-2.pir.output
# examples/shootout/recursive.pir.output
# examples/shootout/regexdna.pir.input
# examples/shootout/regexdna.pir.output
# examples/shootout/revcomp.pir.input
# examples/shootout/revcomp.pir.output
# examples/shootout/spectralnorm.pir.output
# examples/shootout/sumcol.pir.input
# examples/shootout/sumcol.pir.output
# examples/shootout/takfp.pir.output
# languages/LANGUAGES.STATUS.pod
# languages/dotnet/config/N2PConfig.pm.in
# languages/lua/t/shootout/binarytrees.lua-3.lua
# languages/lua/t/shootout/fannkuch.lua-3.lua
# languages/lua/t/shootout/fasta.lua-2.lua
# languages/lua/t/shootout/knucleotide.lua-2.lua
# languages/lua/t/shootout/mandelbrot.lua-2.lua
# languages/lua/t/shootout/message.lua-2.lua
# languages/lua/t/shootout/nbody.lua-2.lua
# languages/lua/t/shootout/nsieve.lua-3.lua
# languages/lua/t/shootout/partialsums.lua-3.lua
# languages/lua/t/shootout/pidigits.lua-2.lua
# languages/lua/t/shootout/regexdna.lua-3.lua
# languages/lua/t/shootout/revcomp.lua-3.lua
# languages/lua/t/shootout/spectralnorm.lua-3.lua
# languages/plumhead/lex.yy.c
# languages/plumhead/y.tab.c
# languages/plumhead/y.tab.h
# t/TESTS.STATUS.pod
# t/configure/101-init_manifest.01.t
# t/configure/101-init_manifest.02.t
# t/configure/102-init_defaults.01.t
# t/configure/102-init_defaults.02.t
# t/configure/103-init_install.01.t
# t/configure/103-init_install.02.t
# t/configure/105-init_hints.01.t
# t/configure/105-init_hints.02.t
# t/configure/105-init_hints.03.t
# t/configure/105-init_hints.04.t
# t/configure/107-inter_progs.01.t
# t/configure/107-inter_progs.02.t
# t/configure/107-inter_progs.03.t
# t/configure/107-inter_progs.04.t
# t/configure/109-inter_lex.01.t
# t/configure/109-inter_lex.02.t
# t/configure/109-inter_lex.03.t
# t/configure/109-inter_lex.04.t
# t/configure/109-inter_lex.05.t
# t/configure/110-inter_yacc.01.t
# t/configure/110-inter_yacc.02.t
# t/configure/110-inter_yacc.03.t
# t/configure/110-inter_yacc.04.t
# t/configure/110-inter_yacc.05.t
# t/configure/113-init_optimize.01.t
# t/configure/113-init_optimize.02.t
# t/configure/113-init_optimize.03.t
# t/configure/113-init_optimize.04.t
# t/tools/pmc2cutils/08-pmc.pm.t
# Looks like you failed 1 test of 1.
Jerry Gay
> On 15/10/2007, Bernhard Schmalhofer <Bernhard.S...@gmx.de> wrote:
> > Paul Cochrane via RT schrieb:
> > > On Fri Nov 17 14:17:18 2006, particle wrote:
> > >
> > >> ~ all but one test have been adapted for and moved to t/codingstd/
> > >> ~ remaining test is for not-yet-approved codingstd item
> > >>
> > >
> > > The remaining test complains about more than one '.' in a filename and
> > > filenames which don't conform to the 8.3 format.
> > I have talked to some VMS people at YAPC::EU 2007.
> > For them the "more than one '.'" issue was a real problem, that
> > they had to work around before even creating a Makefile.
>
> Attached is a test for multiple dot filenames. We have several such
> files in the source[1], so I don't know how useful such a test is, and
> whether or not it is worth changing the files around. I could handle
> having a restriction on the number of dots in filenames but I don't
> think we would be able to handle an 8.3 filename format restriction.
> Anyway, a decision would be good about this, then I can clean up and
> close a couple of annoying tickets.
>
and installable on our target operating systems. citing the PDD01
draft:
=head2 Target Platforms
The ultimate goal of Parrot is portability to more-or-less the same
platforms as Perl 5, including AIX, BeOS, BSD/OS, Cygwin, Darwin,
Debian, DG/UX, DragonFlyBSD, Embedix, EPOC, FreeBSD, Gentoo, HP-UX,
IRIX, Linux, Mac OS (Classic), Mac OS X, Mandriva, Minix, MS-DOS,
NetBSD, NetWare, NonStop-UX, OpenBSD, OS/2, Plan 9, Red Hat, RISC OS,
Slackware, Solaris, SuSE, Syllable, Symbian, TiVo (Linux), Tru64,
Ubuntu, VMS, VOS, WinCE, Windows 95/98/Me/NT/2000/XP/Vista, and z/OS.
Recognizing the fact that ports depend on volunteer labor, the minimum
requirements for the 1.0 launch of Parrot are portability to major
versions of Linux, BSD, Mac OS X, and Windows released within 2 years
prior to the 1.0 release. As we approach the 1.0 release we will
actively seek porters for as many other platforms as possible.
i'd be quite satisfied with a test that verifies that the minimum
filename requirements are met for the list of currently targeted
operating systems, accompanied by a note in the test (and either a
TODO ticket or an item in the porters guide) that this test must be
modified and satisfied to address the requirements of all supported
platforms.
~jerry
Paul Cochrane
Ok, the currently targeted platforms (as given in PLATFORMS) are:
- Darwin
- Linux (various flavours)
- OpenBSD
- FreeBSD (not actually mentioned, but I've seen mention of it
working recently)
- Solaris (versions 8--10)
- OpenSolaris (basically Solaris10)
- Tru64 (I don't know anyone with access to such a machine atm)
- Win32 (XP, 2000; cygwin; mingw) (what have I forgotten here?)
The minimum requirements for filenames should be:
- Any character in the set: a-zA-Z0-9,.-_
- Should we make a rule about multiple dots?
- Should there be a maximum length? 1024 chars? 100 chars? 12 chars?
I'm sure to have missed something here. I'm just trying to get a feel
for what our boundaries are so that they can be codified into a test.
Paul
Allison Randal
>
> Ok, the currently targeted platforms (as given in PLATFORMS) are:
> - Darwin
> - Linux (various flavours)
> - OpenBSD
> - FreeBSD (not actually mentioned, but I've seen mention of it
> working recently)
> - Solaris (versions 8--10)
> - OpenSolaris (basically Solaris10)
> - Tru64 (I don't know anyone with access to such a machine atm)
> - Win32 (XP, 2000; cygwin; mingw) (what have I forgotten here?)
>
> The minimum requirements for filenames should be:
> - Any character in the set: a-zA-Z0-9,.-_
> - Should we make a rule about multiple dots?
> - Should there be a maximum length? 1024 chars? 100 chars? 12 chars?
>
> I'm sure to have missed something here. I'm just trying to get a feel
> for what our boundaries are so that they can be codified into a test.
Let's keep the tests for multiple dots. It won't cost us much to
standardize on single-dot-per-file, and will improve our portability
(those tests that are currently using dots to separate the words in the
file name can use underscores instead).
Long filenames, on the other hand are a huge boost to code
maintainability. So, we won't put a fixed limit on it unless we
absolutely have to. (Though sanity should rule. A 1024 character file
name probably means the programmer is trying to use filenames instead of
documentation, which is just plain wrong.)
At some point we may have to revisit the characters in filenames, but
for now the limited set should be fine. And really, as a standard for
the core distribution, the limited set may always be fine.
Allison
Joshua Juran
> The minimum requirements for filenames should be:
> - Any character in the set: a-zA-Z0-9,.-_
> - Should we make a rule about multiple dots?
> - Should there be a maximum length? 1024 chars? 100 chars? 12
> chars?
I would like to see a maximum no greater than 31 characters, for
compatibility with traditional Mac OS.
Josh
James E Keenan
I'm not necessarily in agreement with this, but I wonder whether you
could you run a 'find' over the Parrot distribution and provide us with
a list of files that are >32 characters.
BTW, are we planning to support pre-OS X Mac?
Sartak
find . | perl -nle 'print if m{.*/(.*)} && length $1 > 31'
./docs/dev/pmc_object_design_meeting_notes.pod
./t/configure/010-verbose_step_number_not_called.t
Shawn
P.S. I will learn how to click Reply to All. I will learn how to click
Reply to All.
Patrick R. Michaud
Running it on my checkout of parrot (r22155), I get
docs/dev/pmc_object_design_meeting_notes.pod (35 chars)
t/configure/010-verbose_step_number_not_called.t (36 chars)
This doesn't include files in .svn/ directories (many of which
exceed 32 characters because of the ".svn-base" extension added
to the name).
Pm
Joshua Juran
> On Tue, Oct 16, 2007 at 10:45:29PM -0400, James E Keenan wrote:
>> Joshua Juran wrote:
>>> On Oct 16, 2007, at 10:52 AM, Paul Cochrane wrote:
>>>
>>>> The minimum requirements for filenames should be:
>>>> - Any character in the set: a-zA-Z0-9,.-_
>>>> - Should we make a rule about multiple dots?
>>>> - Should there be a maximum length? 1024 chars? 100 chars? 12
>>>> chars?
>>>
>>> I would like to see a maximum no greater than 31 characters, for
>>> compatibility with traditional Mac OS.
>>
>> I'm not necessarily in agreement with this, but I wonder whether you
>> could you run a 'find' over the Parrot distribution and provide us
>> with
>> a list of files that are >32 characters.
>
> Running it on my checkout of parrot (r22155), I get
>
> docs/dev/pmc_object_design_meeting_notes.pod (35 chars)
> t/configure/010-verbose_step_number_not_called.t (36 chars)
That's the unanimous opinion.
> This doesn't include files in .svn/ directories (many of which
> exceed 32 characters because of the ".svn-base" extension added
> to the name).
I'm aware of those. For now, they're a non-issue as I haven't yet
ported svn which would create them in the first place.
Josh
Paul Cochrane
there is now a test in t/codingstds called filenames.t which
encapsulates the discussion here. Is this sufficient to now close
this ticket and to remove the old check_source_standards.pl program?
Paul
Jerry Gay
file and resolve this ticket.
~jerry