[perl #60020] [TODO] remove coding standards tests from 'make test' target

# New Ticket Created by Allison Randal # Please include the string: [perl #60020] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=60020 > 1) Remove the coding standards tests from the main 'make test' target.

[perl #52054] [CAGE]: Make all PDDs conform to coding standards

On Mon Sep 08 00:12:44 2008, cotto wrote: > On Mon Sep 08 00:01:08 2008, [EMAIL PROTECTED] wrote: > > Christoph Otto wrote: > > > > > > If those are your thoughts on the subject, then it seems to make sense > > > to add the pdd format test to make test. The attached patch does this. > > > I'll a

[perl #52054] [CAGE]: Make all PDDs conform to coding standards

On Mon Sep 08 00:01:08 2008, [EMAIL PROTECTED] wrote: > Christoph Otto wrote: > > > > If those are your thoughts on the subject, then it seems to make sense > > to add the pdd format test to make test. The attached patch does this. > > I'll apply it and mark this ticket as resolved before the ne

Re: [perl #52054] [CAGE]: Make all PDDs conform to coding standards

Christoph Otto wrote: If those are your thoughts on the subject, then it seems to make sense to add the pdd format test to make test. The attached patch does this. I'll apply it and mark this ticket as resolved before the next #parrotsketch unless there are any objections. Excellent idea. T

Re: [perl #52054] [CAGE]: Make all PDDs conform to coding standards

Allison Randal via RT wrote: Christoph Otto wrote: The non-draft PDDs are all passing t/codingstd/pdd_format.t as of r30810, but two of the draft PDDs aren't. Since they're still drafts and as such are very likely to change, it doesn't seem worthwhile to bring them into compliance or to have

Re: [perl #52054] [CAGE]: Make all PDDs conform to coding standards

Christoph Otto wrote: The non-draft PDDs are all passing t/codingstd/pdd_format.t as of r30810, but two of the draft PDDs aren't. Since they're still drafts and as such are very likely to change, it doesn't seem worthwhile to bring them into compliance or to have a test depend on them. I p

Re: [perl #52054] [CAGE]: Make all PDDs conform to coding standards

James Keenan via RT wrote: The PDDs in docs/pdds/ are now in substantial compliance with the coding standard, those in docs/pdds/draft/ much less so. I'll leave this ticket open, but it's the sort of thing that only needs some cage cleaning attention every month or so. The non-draft PDDs are

[perl #58296] [BUG]: compilers/ncigen: Many coding standards error after recent commits

tewk++ for fixing the remaining tests. We're back to 100% passing: http://smolder.plusthree.com/app/public_projects/report_details/4350

[perl #58296] [BUG]: compilers/ncigen: Many coding standards error after recent commits

# New Ticket Created by James Keenan # Please include the string: [perl #58296] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=58296 > I've spent several hours this morning trying to fix failing coding standar

[perl #52054] [CAGE]: Make all PDDs conform to coding standards

The PDDs in docs/pdds/ are now in substantial compliance with the coding standard, those in docs/pdds/draft/ much less so. I'll leave this ticket open, but it's the sort of thing that only needs some cage cleaning attention every month or so.

[perl #52054] [CAGE]: Make all PDDs conform to coding standards

On Thu Apr 03 12:17:32 2008, [EMAIL PROTECTED] wrote: > I began working on this today and noticed that many PDDs lack a SYNOPSIS > section -- and they do quite well without it. > > I recommend relaxing the requirements in docs/pdds/pdd00_pdd.pod and > t/codingstd/pdd_format.t that each doc have SY

[perl #52054] [CAGE]: Make all PDDs conform to coding standards

Did more work on this tonight. This is a test that, in a certain sense, will probably never pass completely because there will always be oddball lines that have to exceed 78 characters. So it will probably never go into 'make test'. It is interesting to note that there are extensive stretches of

[perl #52054] [CAGE]: Make all PDDs conform to coding standards

I began working on this today and noticed that many PDDs lack a SYNOPSIS section -- and they do quite well without it. I recommend relaxing the requirements in docs/pdds/pdd00_pdd.pod and t/codingstd/pdd_format.t that each doc have SYNOPSIS section. All opposed say "Nay!" within next 24 hours! k

[perl #52054] [CAGE]: Make all PDDs conform to coding standards

All PDDs are supposed to conform to coding standards per docs/pdds/pdd00_pdd.pod. As of r26528 today, we now have a coding standards test which identifies where particular PDDs fail to live up to the standards (cf. http://rt.perl.org/rt3/Ticket/Display.html? id=40653). As you might expect, quit

Re: [perl #47523] [NEW] Coding standards test for spacing after commas and semicolons

On Saturday 17 November 2007 01:43:25 Paul Cochrane wrote: > That's why I posted a patch to the list, so that this could be > discussed. My opinion is that code is easier to read if there are > spaces after commas, and spaces after semicolons (especially in for > loops). +1 -- c

Re: [perl #47523] [NEW] Coding standards test for spacing after commas and semicolons

On Sat, Nov 17, 2007 at 10:43:25AM +0100, Paul Cochrane wrote: > > > One nit I have about C-code is that I think there should be a space > > > after commas and semicolons. > > > > I am not a C-coder, so I don't have an authoritative opinion about this. > > But I would like to ask: In this a comm

Re: [perl #47523] [NEW] Coding standards test for spacing after commas and semicolons

On 17/11/2007, James E Keenan <[EMAIL PROTECTED]> wrote: > Paul Cochrane wrote: > > # New Ticket Created by Paul Cochrane > > # Please include the string: [perl #47523] > > # in the subject line of all future correspondence about this issue. > > # http://rt.perl.org/rt3/Ticket/Display.html?id=475

Re: [perl #47523] [NEW] Coding standards test for spacing after commas and semicolons

Paul Cochrane wrote: # New Ticket Created by Paul Cochrane # Please include the string: [perl #47523] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=47523 > Hi everyone! One nit I have about C-code is that I think there

[perl #47523] [NEW] Coding standards test for spacing after commas and semicolons

ace after commas and semicolons. The attached file adds a new test to the coding standards suite and searches for places where a comma or semicolon is not followed by a space if it does not appear at the end of a line. Is this an ok test to add? Are we at least reasonably happy that this is a good i

Re: [perl #40599] [NEW] Coding standards test of return statements

isn't a firm standard like many of the other coding standards > > tests as it will return a false positive on statements like: > > Hi Paul, > > could you check whether the tests of returns.t are already covered > by t/codingstd/c_parens.t ? > > If so we could close t

[perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

On Tue Dec 19 16:30:34 2006, [EMAIL PROTECTED] wrote: > Nicholas Clark wrote: > > > > To seek clarification - having those as global settings for cperl isn't > > likely to be an issue? Or having them in editor blocks? > > I meant globally. > > It's really not a big deal, though. For the immedia

Re: coding standards for editor hints in PIR files

R files? Is this workable? # Local Variables: # mode: pir # fill-column: 100 # End: # vim: expandtab shiftwidth=4: I'll add it to the coding standards PDD. For pir-mode that looks ok to me. Paul

coding standards for editor hints in PIR files

: pir # fill-column: 100 # End: # vim: expandtab shiftwidth=4: I'll add it to the coding standards PDD. Allison

[perl #41329] [BUG]: Imposition of coding standards breaks tests in t/tools/pmc2cutils/

Tests have been corrected and now pass again. People are aware of problem. Closing ticket.

Re: [perl #41331] Imposition of coding standards breaks tests in tcl.

Failed Test Stat Wstat Total Fail List of Failed --- t/cmd_cd.t 255 65280 36 1-3 t/cmd_exit.t 255 65280 36 1-3 t/cmd_exprOld.t255 6528080 160 1-80 t/cmd_inline.t 255 65

Re: [perl #41329] [BUG]: Imposition of coding standards breaks tests in t/tools/pmc2cutils/

James, In r16751, certain code was repositioned to conform with Parrot coding standards. However, when repositioning code in test files, one is well advised to re-run the tests to see if they all still pass. This apparently was not done. If they had been done, it would have been evident that

Re: [perl #41331] Imposition of coding standards breaks tests in tcl.

To quote ticket 41329: > However, when repositioning code in test files, > one is well advised to re-run the tests to see if they all still > pass. This apparently was not done. Ditto tcl: after the coding standards were blindly applied, the following tests fail in tcl: I di

[perl #41331] Imposition of coding standards breaks tests in tcl.

t; one is well advised to re-run the tests to see if they all still > pass. This apparently was not done. Ditto tcl: after the coding standards were blindly applied, the following tests fail in tcl: Failed Test Stat Wstat Total Fail Li

[perl #41329] [BUG]: Imposition of coding standards breaks tests in t/tools/pmc2cutils/

In each of the 7 affected test files, the initial mention of $topdir in the BEGIN block was replaced by 'our $topdir'. These tests now pass when run via 'make buildtools_tests' or 'prove t/tools/ pmc2cutils/*.t' after running 'Configure.pl' but before running 'make'. I also ran 'make' succes

[perl #41329] [BUG]: Imposition of coding standards breaks tests in t/tools/pmc2cutils/

ake buildtools_tests or prove -v t/tools/pmc2cutils/*.t You will get the output in the attachment. ANALYSIS: In r16751, certain code was repositioned to conform with Parrot coding standards. However, when repositioning code in test files, one is well advised to re-run the tests to see

[perl #41292] [PATCH] make languages/cola/{lexer,parser}.c comply with coding standards

On Mon Jan 22 10:17:48 2007, [EMAIL PROTECTED] wrote: > On Fri Jan 19 01:48:36 2007, ptc wrote: > > Which revision of Parrot was this using? The reason I ask is that > > these files are supposed to be exempt from the coding standards tests > > as they are automatically gener

Re: [perl #41292] [PATCH] make languages/cola/{lexer,parser}.c comply with coding standards

be exempt from the coding standards tests as they are automatically generated by flex/yacc. I just tried it with r16702 and the tests pass even when languages/cola/lexer.c has trailing spaces. Perhaps an 'svn up' makes the tests pass? Thanks for pointing this out though! Regards, Paul

[perl #41292] [PATCH] make languages/cola/{lexer,parser}.c comply with coding standards

# New Ticket Created by "James Bence" # Please include the string: [perl #41292] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41292 > The test t/codingstd/trailing_space.t fails on two files. This patch makes the test pas

[perl #40905] [CAGE] coding standards hammer too big

On Mon Jan 08 10:07:38 2007, particle wrote: > On 1/8/07, Paul Cochrane via RT <[EMAIL PROTECTED]> wrote: > > On Thu Nov 16 05:00:35 2006, coke wrote: > > > Any files that are copied from somewhere else should be immune from > > > our coding standards. &

Re: [perl #40905] [CAGE] coding standards hammer too big

On 1/8/07, Paul Cochrane via RT <[EMAIL PROTECTED]> wrote: On Thu Nov 16 05:00:35 2006, coke wrote: > Any files that are copied from somewhere else should be immune from > our coding standards. > > This includes items in > > lib/Parse/RecDescent.pm, which is from CP

[perl #40905] [CAGE] coding standards hammer too big

On Thu Nov 16 05:00:35 2006, coke wrote: > Any files that are copied from somewhere else should be immune from > our coding standards. > > This includes items in > > lib/Parse/RecDescent.pm, which is from CPAN, or > > languages/tcl/library/*, from tcl's standard

[perl #40905] [CAGE] coding standards hammer too big

On Thu Nov 16 05:00:35 2006, coke wrote: > Any files that are copied from somewhere else should be immune from > our coding standards. > > This includes items in > > lib/Parse/RecDescent.pm, which is from CPAN, or > > languages/tcl/library/*, from tcl's standard

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

On Tue, Dec 19, 2006 at 04:30:08PM -0800, Allison Randal wrote: > Nicholas Clark wrote: > > > >To seek clarification - having those as global settings for cperl isn't > >likely to be an issue? Or having them in editor blocks? > > I meant globally. Ah. There have been times when it would have been

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

It's really not a big deal, though. For the immediate problem, let's just make an exception and leave the hints out of Perl files with __END__ or __DATA__ blocks. Sounds good. I can update the Perl::Critic policy, and make a note in pdd07. Mark it as a cage cleaner task for some point down the

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

All it does is turn on cperl mode for emacs, and set tabs to 4 spaces for vim and emacs. Not likely to significantly interfere with any repository you work on. (I actually gave up on the tab key in vim years ago. I type literal spaces, and my brain automatically adjusts my indenting to the surroun

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

Nicholas Clark wrote: To seek clarification - having those as global settings for cperl isn't likely to be an issue? Or having them in editor blocks? I meant globally. It's really not a big deal, though. For the immediate problem, let's just make an exception and leave the hints out of Perl

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

On Tue, Dec 19, 2006 at 01:08:14PM -0800, Allison Randal wrote: > Nicholas Clark wrote: > >On Tue, Dec 19, 2006 at 10:05:46AM -0800, Allison Randal wrote: > > > >>to every source file, and a maintenance burden. Both vim and emacs allow > >>top-level settings of these preferences, which is a more a

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

Nicholas Clark wrote: On Tue, Dec 19, 2006 at 10:05:46AM -0800, Allison Randal wrote: to every source file, and a maintenance burden. Both vim and emacs allow top-level settings of these preferences, which is a more appropriate place for them. This assumes that all the projects you use the e

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

On Tue, Dec 19, 2006 at 10:05:46AM -0800, Allison Randal wrote: > to every source file, and a maintenance burden. Both vim and emacs allow > top-level settings of these preferences, which is a more appropriate > place for them. This assumes that all the projects you use the editor for have the

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

On Tuesday 19 December 2006 10:05, Allison Randal wrote: > The editor hints aren't actually very helpful, but they do add clutter > to every source file, and a maintenance burden. Both vim and emacs allow > top-level settings of these preferences, which is a more appropriate > place for them. I a

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

s of these preferences, which is a more appropriate place for them. The coding standards tests need to check the format of the source code files directly anyway (for developers who don't use vim or emacs). Why don't we just let them be an exception which doesn't require such edi

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

Having editor hints in the source can have value as it can reduce the cage cleaning load by getting the editor to indent people's code consistently (admittedly this only helps people who use emacs and vim in this case) so in that sense it is worthwhile having them around. The coda is added to all

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

On Tue, Dec 19, 2006 at 05:20:06PM +0800, Lee Duhem wrote: > Allison wrote: > >My vote is on removing all emacs and vim settings from our source code > >files. > and so you can get really bad code appearance. I'm curious, why is that? We're already discouraging (if not disallowing) hard tabs in t

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

My vote is on removing all emacs and vim settings from our source code files. and so you can get really bad code appearance.

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

Paul Cochrane wrote: The problem that I'm trying to solve here is: how do we add the settings information to perl language files such that it doesn't cause problems with __END__ and __DATA__ blocks, is testable by perlcritic, emacs *and* vim pick up their settings values, and it doesn't interfer

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

On Dec 18, 2006, at 1:57 AM, Paul Cochrane wrote: Be aware that you cannot use the verbose form of Emacs settings at the beginning of a file, unless the file is shorter than 3000 bytes. See Perl::Critic::Policy::Editor::RequireEmacsFileVariables policy for more details: So this means we need t

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

Be aware that you cannot use the verbose form of Emacs settings at the beginning of a file, unless the file is shorter than 3000 bytes. See Perl::Critic::Policy::Editor::RequireEmacsFileVariables policy for more details: So this means we need to put the emacs and vim settings at the end of the f

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

From: Bob Rogers <[EMAIL PROTECTED]> Date: Sun, 17 Dec 2006 15:03:10 -0500 From: Chris Dolan <[EMAIL PROTECTED]> Date: Sun, 17 Dec 2006 13:22:53 -0600 . . . Be aware that you cannot use the verbose form of Emacs settings at the beginning of a file, unless th

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

From: Chris Dolan <[EMAIL PROTECTED]> Date: Sun, 17 Dec 2006 13:22:53 -0600 On Dec 16, 2006, at 12:41 PM, Paul Cochrane via RT wrote: > Hi all, > > We could close this ticket if a decision were made as to whether or > not > the emacs/vim formatting information can be put

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

On Dec 16, 2006, at 12:41 PM, Paul Cochrane via RT wrote: Hi all, We could close this ticket if a decision were made as to whether or not the emacs/vim formatting information can be put at the *beginning* of a file in the case where __END__ or __DATA__ blocks are used within a perl source

[perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

Hi all, We could close this ticket if a decision were made as to whether or not the emacs/vim formatting information can be put at the *beginning* of a file in the case where __END__ or __DATA__ blocks are used within a perl source file. What are people's opinions? Would it be too ugly to p

[perl #40905] [CAGE] coding standards hammer too big

# New Ticket Created by Will Coleda # Please include the string: [perl #40905] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40905 > Any files that are copied from somewhere else should be immune from our cod

[perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

Hi all, The attached patch to the coding standards pdd concerns how we handle the parrot emacs/vim coda in perl source files when the files contain __END__ or __DATA__ blocks. The reason for the patch is that vim looks at only the first or last five lines of a file to see if there is any

Re: [perl #40279] [CAGE] C coding standards coda.

Sure. On Nov 12, 2006, at 7:56 AM, Paul Cochrane via RT wrote: On Tue Sep 05 13:13:05 2006, coke wrote: From the recently updated pdd07: C source files, and files largely consisting of C (e.g. yacc, lex, PMC, and opcode source files), must end with this block: /* * Local variables: *

[perl #40599] [NEW] Coding standards test of return statements

s that return statements look like C rather than C. This isn't a firm standard like many of the other coding standards tests as it will return a false positive on statements like: return (void *) malloc( size ); however, it will pick up the instances it is intended to fix. Comments welcome, Pau

[perl #40589] [PATCH] Adding (some) coding standards tests to the default tests

# New Ticket Created by "Paul Cochrane" # Please include the string: [perl #40589] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40589 > Hi, This patch adds the C, C and C tests to the default list of tests run when one p

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

Hi, This patch changes the semantics of the checking for the Perl code coda in Perl::Critic::Policy::CodeLayout::UseParrotCoda. At present the Perl code coda is checked at the end of the file if no __END__ or __DATA__ block is present, and is checked before the __END__ or __DATA__ block if such

Re: [CAGE] perl coding standards...

On Sep 26, 2006, at 10:21 PM, Will Coleda wrote: I took a first pass at a perlcritic test: t/codingstd/ perlcritic.t ; this test isn't run by default. [snip] Cool! Attached is a patch to simplify this test code a little bit by leveraging Test::Perl::Critic. I also reworked CodeLayout::Us

[perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

On Tue Sep 19 10:10:45 2006, [EMAIL PROTECTED] wrote: > On Tuesday 19 September 2006 07:56, jerry gay wrote: > > > ~  all non-perl test files must have a shebang > > > > i strongly suggest that this be extended to cover all test files. > > then, as you say, it can easily be tested, and it's value

[CAGE] perl coding standards...

I took a first pass at a perlcritic test: t/codingstd/perlcritic.t ; this test isn't run by default. It reports on only the following perlcritic rules at the moment: TestingAndDebugging::RequireUseStrict TestingAndDebugging::RequireUseWarnings Variables::ProhibitConditionalDeclarat

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

On Tuesday 19 September 2006 07:56, jerry gay wrote: > ~  all non-perl test files must have a shebang > > i strongly suggest that this be extended to cover all test files. > then, as you say, it can easily be tested, and it's value can be used > in other tests to determine it's file type. if you w

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

On 9/19/06, Paul Cochrane <[EMAIL PROTECTED]> wrote: Jerry, > all new rt tickets are created via parrotbug. it may not be sexy, but > it's what we've got :-) I'm not 100% sure if it worked, as parrotbug gave this warning: Use of uninitialized value in concatenation (.) or string at ./parrotbug

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

Jerry, all new rt tickets are created via parrotbug. it may not be sexy, but it's what we've got :-) I'm not 100% sure if it worked, as parrotbug gave this warning: Use of uninitialized value in concatenation (.) or string at ./parrotbug line 525, line 7. and the ticket doesn't seem to have

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

On 9/19/06, Paul Cochrane <[EMAIL PROTECTED]> wrote: This is going to sound rather silly, but... how does one enter a new ticket to RT? I've got an account, but can't see anywhere on rt.perl.org where one can add a new ticket. There's also no help link I can go to to work out what to do. Shou

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

Jerry, oh, and yes, i believe the shebang should be in all perl files... but this isn't specified *yet* in pdd07. if you can enter the ticket, that would be fantastic, and we'll get a ruling from chip. This is going to sound rather silly, but... how does one enter a new ticket to RT? I've got

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

On 9/19/06, Paul Cochrane <[EMAIL PROTECTED]> wrote: > firstly, line endings are unrelated to this effort and should be a > separate patch. that's no biggie, and alone wouldn't stop me from > applying. I can do that in a separate patch if you want. That's not a major problem, and probably a good

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

Jerry, firstly, line endings are unrelated to this effort and should be a separate patch. that's no biggie, and alone wouldn't stop me from applying. I can do that in a separate patch if you want. That's not a major problem, and probably a good idea. I'd not realised some of the issues you b

Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

is a patch of more Perl files that I missed with my previous patch concerning the perl coding standards coda (the last patch was only .pl files, this one patches as many of the .t files that I could find). Some of the files affected by this patch have also been converted from dos to unix line

Re: [perl #40278] [CAGE] perl coding standards coda.

Hi Bernhard, thanks for adding the codas in the Perl files. No worries! I actually found some more perl files so will make the necessary changes when I get the tuits. Could you also provide a test in t/codingstd/code_coda.t, so that future Perl files will automatically be checked? Will do :

[perl #40349] [PATCH] #40278: [CAGE] perl coding standards coda.

# New Ticket Created by "Paul Cochrane" # Please include the string: [perl #40349] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40349 > Hi, This is a patch to (attempt to) close the Cage Cleaner's RT ticket #40278. The

Re: [perl #40279] [CAGE] C coding standards coda.

On 9/5/06, via RT Will Coleda <[EMAIL PROTECTED]> wrote: From the recently updated pdd07: C source files, and files largely consisting of C (e.g. yacc, lex, PMC, and opcode source files), must end with this block: /* * Local variables: * c-file-style: "parrot" * End: * vim: expandtab

[perl #40279] [CAGE] C coding standards coda.

# New Ticket Created by Will Coleda # Please include the string: [perl #40279] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40279 > From the recently updated pdd07: C source files, and files largely consisting of C (e.g

[perl #40278] [CAGE] perl coding standards coda.

# New Ticket Created by Will Coleda # Please include the string: [perl #40278] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40278 > From the recently updated pdd07: Perl source files must end with this block: # Local V

[perl #39663] [TODO] perl coding standards

# New Ticket Created by Will Coleda # Please include the string: [perl #39663] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=39663 > Need to: 1) Decide on perl coding standards (stealing from PBP) 2) implemen

Re: Coding standards (was Re: typedefs)

On Friday 22 March 2002 19:40, Nicholas Clark wrote: > On Sat, Mar 23, 2002 at 12:55:00AM +0100, Segher Boessenkool wrote: > > Besides, struct etc. are their own namespace, aside from the normal > > variables/functions namespace. No need for any pre/postfix at all. > > Until someone wishes to em

Re: Coding standards (was Re: typedefs)

On Sat, Mar 23, 2002 at 12:55:00AM +0100, Segher Boessenkool wrote: > Besides, struct etc. are their own namespace, aside from the normal > variables/functions namespace. No need for any pre/postfix at all. Until someone wishes to embed the public headers into a C++ program. Or finds themselves

Re: Coding standards (was Re: typedefs)

"Bryan C. Warnock" wrote: > > On Friday 22 March 2002 17:53, Russ Allbery wrote: > > Brent Dax <[EMAIL PROTECTED]> writes: > > > > > Parrot_Foo for external names, FOO for internal names, struct > > > parrot_foo_t for struct names. > > > > POSIX reserves all types ending in _t. I'm not sure th

Coding standards (was Re: typedefs)

ian notation, which I had always abhorred. I've rewritten stacks.[ch] as close to the "coding standards" as I could get it, along with some additional constraints that I'll be putting on types. It's probably not 100%, but an idea of what the code should probably end up loo

Re: Reformatting code/coding standards

standard" is: I want to be able to find function Foo by saying: grep "^Foo". So I have to write void Foo() instead of void Foo() That is ALL it is useful for, in my opinion, and that is not enough for me to write in a style that is generally against the grain. I come from the li

Re: Reformatting code/coding standards

On Friday 08 March 2002 23:02, Melvin Smith wrote: > Just my 2 cents. > > This is my only nitpick with the coding standards. > > I never cared for the style of putting return type on a > separate line above the function declaration header. > > I like it just as the pr

Re: Reformatting code/coding standards

Melvin Smith <[EMAIL PROTECTED]> wrote: > This is my only nitpick with the coding standards. > > I never cared for the style of putting return type on a > separate line above the function declaration header. > > I like it just as the prototype. > > I vote f

Reformatting code/coding standards

Just my 2 cents. This is my only nitpick with the coding standards. I never cared for the style of putting return type on a separate line above the function declaration header. I like it just as the prototype. I vote for non-enforcement of this one. -Melvin

Coding standards PDD is in

Okay, folks, I just added in PDD 7 to the repository, the coding standard PDD. It's the original draft text from last August. It's in good shape, but now is the time to give it one more once-over and get the final form nailed down. -- Dan -

Re: coding standards PDD?

Back on Fri, 28 Sep 2001 20:49:42, Josh Wilmes <[EMAIL PROTECTED]> asked: > What's the state of the coding standards? This is the last draft of it > i've noticed in the archives: > > http://www.mail-archive.com/perl6-internals%40perl.org/msg03422.html > >

coding standards PDD?

What's the state of the coding standards? This is the last draft of it i've noticed in the archives: http://www.mail-archive.com/perl6-internals%40perl.org/msg03422.html Is this going to become a PDD or at least move into the doc directory for parrot? --Josh -- Josh Wilme

Re: coding standards

Gibbs Tanton - tgibbs writes: > I will try to watch things as they go in and make coding standard > changes immediately from now on so we don't have such a massive > change. Alternatively, pumpkings could refuse to apply patches that don't conform. One or two goes around and people will learn to

coding standards

Ok, I just updated every .c and .h file to include the new coding standard. I also updated most of the .pl files to use Parrot_Interp instead of Perl_Interp. Please refresh your copy of the files. I will try to watch things as they go in and make coding standard changes immediately from now on s

RE: coding standards

I don't know, I always liked seeing them separate. I'll change it to $Id:$ to take up less space. -Original Message- From: Russ Allbery To: [EMAIL PROTECTED] Sent: 9/15/2001 2:08 PM Subject: Re: coding standards Gibbs Tanton <- tgibbs <[EMAIL PROTECTED]>> w

Re: coding standards

Gibbs Tanton <- tgibbs <[EMAIL PROTECTED]>> writes: > * CVS Info > * $RCSfile: $ > * $Revision: $ > * $Date: $ If you're going to include all that, why not just use $Id$, which contains all of that information? -- Russ Allbery ([EMAIL PROTECTED])

Re: coding standards

On Fri, Sep 14, 2001 at 11:45:36PM -0500, Gibbs Tanton - tgibbs wrote: > Sorry...forgot the tabs...this one should be right. Thanks, applied.

RE: coding standards

Sorry...forgot the tabs...this one should be right. memory.c

coding standards

Below is memory.c changed to support all (I think) of the coding standards. Please look it over and let me know. Once the powers that be give the ok, I will try to change all the source files to the standard. Thanks! Tanton /* Memory.c * Copyright: (When this is determined...it will go here

Re: [PATCH]coding standards

On Thu, Sep 13, 2001 at 01:57:09PM -0500, Gibbs Tanton - tgibbs wrote: > I'll keep looking for other coding standard changes. Woohoo! Applied with much thanks! Simon

[PATCH]coding standards

This patch implements some of the coding standards in an earlier PDD. Functions such as Allocate_Aligned were changed to lowercase, and all functions in memory.{h,c} had mem_ prepended to them. The only thing I didn't really try to fix were the #define's being lowercase (such as sys_me